RIS COMEX
[pic]
Implementation of River Information Services in Europe
Document History:
|Version |Comments |Date |Authorised by |
|v0p1 |Initial version of the document |16.11.2011 |via donau |
|v0p2 |Draft version with all content |19.12.2011 |via donau |
|v0p3 |Draft final version |23.12.2011 |Project Management Team |
|v1p0 |Final version |31.01.2012 |IRIS II Project Consortium |
Responsible for the content:
|Organisation(s) |Author(s) |
|via donau, AT |Mario Kaufmann |
| |Christoph Plasil |
| |Mario Sattler |
| |Lukas Seemann |
| |Stefan Simon |
|RSOE, HU |Robert Rafael |
| |Csaba Farago |
|KIOS, SK |Michal Chochula |
| |Lucia Karpatyova |
|SPS, SK |Stefan Chalupka |
|RWS, NL |Jos van Splunder |
| |Cas Willems |
| |Peter Oudenes |
| |Marianne de Jong |
| |Frank Turkenburg |
| |Lex Kampert |
| |Rene Visser |
Table of Content
Abbreviations 5
1 Activity 4 – Harmonization of Quality of Information Services for RIS 7
1.1 Background information 8
1.2 Objectives 9
1.3 Work approach 10
1.4 Results 12
1.5 Conclusions & recommendations 14
2 Introduction 17
3 SuAc 4.1 Definition of QoIS in the RIS Context 20
3.1 Introduction 20
3.2 Sphere of influence for QoIS 20
3.3 Quality of Information Services in the RIS context 31
3.4 Elaborating selected Quality Aspects and RIS services 37
3.5 Demonstrating selected Quality Aspects 37
4 SuAc 4.2 Definition of QoIS for Notices to Skippers 38
4.1 Introduction 38
4.2 Quality of Information Services for NtS 38
4.3 Results 40
4.4 Experiences and recommendations 40
5 SuAc 4.3 Definition of QoIS for Electronic Reporting 41
5.1 Introduction 41
5.2 Quality of Information Services for ERI 41
5.3 Results 47
5.4 Conclusions 47
6 SuAc 4.4 Definition of QoIS for RIS Index 49
6.1 Introduction 49
6.2 Quality of Information Services for RIS Index 54
6.3 Results 56
6.4 Conclusions 59
7 SuAc 4.5 Definition of QoIS for Vessel Tracking and Tracing 62
7.1 Introduction 62
7.2 Quality of Information Services for VTT 62
7.3 Summary 62
7.4 Conclusions 63
List of Tables 64
List of Figures 64
Abbreviations
|Ac |Activity |
|ADN |European Agreement concerning international transport of dangerous goods over inland waterways |
|ADNR |European Agreement concerning international transport of dangerous goods over the Rhine river (the CCNR |
| |adoption of the ANR, a similar agreement for road transports) |
|AIS |Automatic Identification System |
|BICS |Binnenvaart Informatie en Communicatie Systeem |
|CAS |Calamity Abatement Services |
|CBS |Statistics Office in the Netherlands |
|CKR |Central Commission for Navigation on the Rhine |
|CCTV |Closed Circuit Television |
|ECDIS |Electronic chart and display information system |
|EDIFACT |Electronic Data Interchange for administration commerce and transport |
|EF |Efficiency aspect |
|EN |Environmental aspect |
|ENC |Electronic Navigational Charts |
|ENI |European unique hull identification number |
|EPC |Electronic Port Clearance |
|ERDMS |European Reference Data Management System |
|ERI |Electronic Reporting |
|ERINOT |ERI notification message (EU inland shipping data exchange standard) |
|ETA |Estimate time of arrival |
|FIS |Fairway Information Service |
|FTM |Fairway and Traffic related message |
|GPRS |General Packet Radio Service (= a mobile data communications service) |
|GPS |Global Positioning System |
|GSM |Global System for Mobile communication |
|HS |Harmonized commodity description and coding System |
|IECDIS |Inland Electronic Chart Display and Information Service |
|IMDG |International Maritime Dangerous Goods Code |
|IMO |International Maritime Organization |
|IMO FAL |International Maritime Organization defined Facilitation messages |
|ISO |International Standards Organization |
|ISPS |International Ship and Port facility Security Code |
|IVS90 |Traffic management system in the Netherlands |
|IRIS Europe (II) |Implementation of River Information Services in Europe |
|LBM |Lock and Bridge management services |
|MADT |Maximum Allowable Downtime |
|MaxTTR |Maximum Tolerated Time to Repair - the maximum tolerated time required to repair a failed system/service, |
| |including also the time from when the failure occurs until it is detected, so the entire time the |
| |system/service is not available |
|MIB |Traffic management system in Germany |
|MTBF |Mean Time Between Failures - the (predicted) average elapsed time between inherent failures of a system |
| |during operation |
|NtS |Notices to Skippers |
|QoIS |Quality of Information Services |
|PIANC |World Association for Waterborne Transport Infrastructure |
|PMT |Project management team of IRIS Europe II |
|RIS |River Information Services |
|RPR |Rijnvaartpolitiereglement 1995 |
|RTA |Requested time of arrival |
|RWS |Rijkswaterstaat |
|SA |Safety Aspect |
|SHMU |Slovak Hydro Meteorological Institute |
|SLA |Service Level Agreement |
|SPS |State Navigation Administration |
|STI |Strategic Traffic Image |
|SuAc |Sub Activity |
|SVP |Slovak Waterway Management Enterprise |
|TLS |Transport Logistics Services |
|VHF |Very High Frequency |
|VTMC |Vessel traffic management centre |
|VTS |Vessel Traffic Services |
|VTT |Vessel Tracking and Tracing |
|WP |Work Package |
|WRM |Water level related message |
Activity 4 – Harmonization of Quality of Information Services for RIS
Background information
In the context of RIS, monitoring and management of Quality of Information Services is essential for the acceptance of RIS Services. RIS users will only rely on RIS services and introduce RIS services in their daily operational processes, when sufficient and guaranteed, service levels are established.
Activity 4 dealt with the definition, harmonization, implementation of Quality of Information Services and related measures with such a European context in mind, focusing on the selected RIS key technologies Notices to Skippers, Electronic Reporting, Vessel tracking & Tracing as well as the RIS Index.
Objectives
The main objective of this Activity with relation to harmonization and introduction of Quality of Information Services for RIS was to elaborate a European definition of Quality of Information Services for the RIS key technologies, namely Vessel Tracking and Tracing, Notices to Skippers and Electronic Ship Reporting as well as for the RIS Index.
Work approach
SuAc 4.1, which acted as a kind of coordination activity for the SuAcs 4.2-4.5, was organised as common activity by the involved SuAc partners whereas the majority of the preparatory work was done by the Dutch partners who also moderated the held meetings.
The SuAcs 4.2-4.5 were coordinated by the nominated SuAc leaders who consolidated, presented and updated the related QoIS documents based on the input of the SuAc partners whereas each partner was nominated to define specific QoIS requirements. Furthermore, the SuAc leaders presented the preliminary results to the RIS Expert Groups in order to gather their feedback and further input.
Results
A work programme was elaborated and the QoIS in the RIS context was defined in detail. Specific services and information elements as well as the most relevant quality parameters and user groups were identified and documented. Within SuAcs 4.2-4.5, the minimum quality requirements towards the related services and information elements were investigated, discussed and documented.
As it was experienced that the effort for this took much more time than expected due to different viewpoints, it was agreed to focus on the elaboration of the minimum requirements of selected subsets of information elements and quality parameters. In the end lots of experiences and know-how in relation to the definition of QoIS for RIS was gained by all participating partners and results are available which can form a solid basis for further work in that field.
Conclusions & Recommendations
It is difficult to define a unique and harmonized level of quality for RIS services (key technologies) throughout Europe due to differences in business processes, traffic- and navigational conditions as well as different view points.
It is recommended to ensure, that the requirements of real RIS users will be examined in more detail from the practical point of view.
1 Background information
1 Requirements
In general, the term “quality of service” is a measure for the performance of systems services. Certain goals are defined and service levels determine the percentage to which these goals should be met. Examples for service levels include the percentage of calls answered in a call centre within a defined timeframe, or the maximum number of customers on hold during defined timeframes.
In the context of RIS, monitoring and management of Quality of Information Services is essential for the acceptance of RIS Services. RIS users will only rely on RIS services and introduce RIS services in their daily operational processes, when sufficient and guaranteed, service levels are established.
The introduction of European service level parameters is considered as a first step and will eventually allow for all RIS services to operate on an equal and consistent quality level throughout the EU fairway system.
Activity 4 was intended to deal with the definition, harmonization, implementation of Quality of Information Services and related measures with such a European context in mind, focusing on the selected RIS key technologies Notices to Skippers, Electronic Reporting, Vessel tracking & Tracing as well as the RIS Index.
2 Preliminary work
There was no specific preliminary work done related to the definition of quality parameters for specific RIS services and technologies. Nevertheless, it was identified during various implementations, tests and evaluations, that there is a clear lack of well defined quality parameters which would serve as a guideline for the required quality during implementation of RIS.
3 Challenges
Main challenges were to focus the work within Activity 4 due to the fact that not all services, information elements, viewpoints and quality parameters can be considered. As it was the first trial to defined quality criteria for RIS, an agreement had to be reached on a subset of services / information elements and on specifically selected quality parameters to be investigated.
Another challenge that was identified during the execution of Activity 4 was to consolidate the partly very different viewpoints on required quality towards recommended minimum quality requirements.
4 Other relevant background information
There was always a special focus within Activity 4 to integrate practical experiences and to cooperate with the RIS expert groups, especially when discussing the first available results and the next steps related to the definition of quality requirements for RIS.
At the beginning of the project IRIS Europe II, it was stated that also within the project RISING special works are being done in the field of examination the quality of services, namely in the work package dedicated to the so called RIS Service Performance Profile. From that perspective it was decided that mutual cooperation between both projects is necessary. The only difference between quality related activities in both projects is that whereas IE II focuses mainly on the description of quality requirements on RIS services from the authority point of view, in RISING focus has been placed mainly on the description of requirements from the (logistics) user’s point of view on the newly developed RIS TLS services. Representatives of both projects met during the several projects meetings dedicated to QoIS, where results from RISING project has been presented to IE II (and vice versa).
In project RISING it was decided to use the portfolio of quality aspects as defined within the project IRIS Europe II for the description of qualitative requirements of RIS TLS services developed as the pilot within the WP4 of project RISING. On the other hand, RISING project has delivered requirements of logistics users on the service FIS.6 – Temporary obstructions in the fairway (input has been considered within the document QoIS for NtS) and on CFM.2 - Information on the cargo to be transported (input has been considered within the document QoIS for ERI).
2 Objectives
1 Specific objectives
The main objective of this Activity with relation to harmonization and introduction of Quality of Information Services for RIS was to elaborate a European definition of Quality of Information Services for the RIS key technologies, namely Vessel Tracking and Tracing, Notices to Skippers and Electronic Ship Reporting as well as for the RIS Index. The RIS key technology Inland ECDIS was not considered separately in detail due to the fact that the Inland ECDIS Expert Group had already started a similar initiative. The definitions had to be elaborated in close cooperation with the RIS Expert Groups.
A selected and agreed set of measures for provision of Quality of Information Services had to be further specified, so they can be implemented as pilot installations in the respective countries. National particularities and requirements had to be considered for each service.
In Sub-Activity 4.1 the specific requirements for the pilot implementations in Sub-Activities 4.2, 4.3, 4.4, and 4.5 had to be elaborated. Based on the specific requirements a task description had to be included into an updated version of the SAP, and activity leaders had to be assigned.
2 Planned results
The following results were initially planned to be achieved within Activity 4 and its sub-activities:
• Definition of Quality of Information Services in the RIS Context
• Definition of Quality of Information Services for NtS, ERI, RIS Index, VTT
• Evaluation of national RIS Implementations according to the Quality of Information Services
• Pilot implementation of Quality of Information Services for NtS, ERI, RIS Index, VTT
• Definition and demonstration of best practices for Service Levels
• Recommendations to achieve a European harmonized level of the Quality of Information Services for RIS
• Provision of the result to the involved Expert Groups and, if applicable, provision of adaptation and amendment requests on the existing standards and/or draft standards to the involved Expert Groups
3 Amended tasks and results
The following amendments took place related to the planned results:
• Evaluation of national RIS implementations according to the Quality of Information Services
o It was agreed by the Project Management Team together with the responsible persons for Activity 4 to declare this task respectively expected result as optional based on the results achieved within the SuAc 4.2 – 4.5 and depending on the existence and status of related national infrastructure.
• Pilot implementation of Quality of Information Services for NtS, ERI, RIS Index, VTT
o Due to the fact that the definition of meaningful and practicable quality indicators and the minim requirements on those took much more time and effort than expected, it was identified that the clear focus has to be put on the theoretical work before starting with the enhancement of national pilot infrastructure based on not agreed quality requirement. Therefore this task respectively expected result was agreed to be skipped and to be investigated further based on the results out of Activity 4.
• Definition and demonstration of best practices for Service Levels
o It was agreed by the Project Management Team together with the responsible persons for Activity 4 to declare this task respectively expected result as optional based on existing infrastructure and experiences which allow the definition of a best practice example.
3 Work approach
1 Activity partners
|Country |Partner organisation |Role within Activity |Responsibility |
|NL |RWS |Activity leader (SuAc 4.1) |Activity coordination; SuAc 4.3 leader; SuAc 4.2, |
| | | |4.4, 4.5 partner |
|AT |via donau |Activity leader (SuAc 4.1) |Activity coordination; SuAc 4.5 leader; SuAc 4.2, |
| | | |4.3, 4.4 partner |
|BG |BPI |SuAc partner |SuAc 4.2, 4.3 partner |
|HU |RSOE |Activity partner (SuAc 4.1) |SuAc 4.4 leader; SuAc 4.2, 4.3, 4.5 partner |
|SK |KIOS |Activity partner (SuAc 4.1) |SuAc 4.2 leader; SuAc 4.3, 4.4, 4.5 partner |
|BE |CETUS |Observer |Activity 4 observer |
|CZ |MDCR and RVCCR |Observer |SuAc 4.4 observer |
|DE |BMVBS and WSV |Observer |Activity 4 observer |
|HR |CRUP |Observer |Activity 4 observer |
Table 1-1: Partners Activity 4
2 Work approach
SuAc 4.1, which acts as a kind of coordination activity for the remaining SuAcs 4.2-4.5, was organised as common activity by the involved SuAc partners whereas the majority of the preparatory work was done by the Dutch partners who also moderated the held meetings.
The SuAcs 4.2-4.5 were coordinated by the nominated SuAc leaders:
• SuAc 4.2 QoIS for NtS: Slovakian partner KIOS
• SuAc 4.3 QoIS for ERI: Dutch partner RWS
• SuAc 4.4 QoIS for RIS Index: Hungarian partner RSOE
• SuAc 4.5 QoIS for VTT: Austrian partner via donau
The SuAc leaders consolidated, presented and updated the related QoIS documents based on the input of the SuAc partners whereas each partner was nominated to define specific QoIS requirements.
Furthermore, the SuAc leaders presented the preliminary results to the RIS Expert Groups in order to gain their feedback and further input.
3 Meetings
Due to efficiency reasons it was agreed to organise common Activity 4 meetings instead of separate SuAc 4.1-4.5 meetings:
• SuAc 4.1 Kick-Off meeting, 16.09.2009, Rotterdam
o Objectives
o Parameters to be considered (quality aspects, services, data elements, user groups)
o Identification of necessity to focus only on most important subsets of all parameters
• SuAc 4.1 meeting, 04.12.2009, Vienna
o Work to be done (planning and resources)
o Relation with other initiatives
o Selection of specific RIS sub-services and focus on specific user groups
• SuAc 4.1 meeting, 24.02.2010, Vienna
o Activity work programme
o Nomination of national experts per SuAc
o QoIS in the RIS context document
• SuAc 4.1 meeting, 09.04.2010, Budapest
o QoIS in the RIS context document
o QoIS tables (data elements / quality aspects / user groups)
o Elaboration guide
o Nomination of the SuAc 4.2-4.5 leaders
• SuAc 4.1 meeting, 01.06.2010, Rotterdam
o First results (QoIS for RIS Index; QoIS for ERI)
o Work programme
o QoIS in the RIS context document
o SuAc 4.2-4.5 working documents and elaboration guide
o Time schedule next steps
• Activity 4 meeting, 23.-24.09.2010, Varna
o Presentation, feedback and discussion of the first results
• Activity 4 meeting, 20.-21.01.2011, Vienna
o Presentation, feedback and discussion of QoIS documents
o Discussion about evaluation and demonstration of pest practices within Activity 4
o Definition of quality parameter “availability”
o Progress and next steps
• Activity 4 meeting, 12.05.2011, Nijmegen
o Feedback of workshops held in NL and DE
o Status quo and next steps
o Preparation for presentation of preliminary results to RIS expert groups
• Activity 4 meeting with RIS expert groups, 17.06.2011, Rotterdam
o Introduction of Activity 4 and objectives
o Presentation and discussion about SuAc 4.2 (QoIS for NtS) results
o Presentation and discussion about SuAc 4.3 (QoIS for ERI) results
o Presentation and discussion about SuAc 4.4 (QoIS for RIS Index) results
o Presentation and discussion about SuAc 4.5 (QoIS for VTT) results
• Activity 4 meeting, 13.10.2011, Bucharest
o Finalisation of results
o Conclusions and recommendations
4 Results
The work within this activity was started by SuAc 4.1 by the investigation and definition of the work that shall be done within the remaining SuAcs 4.2-4.5. A work programme was elaborated and the QoIS in the RIS context was defined in detail.
Furthermore, within SuAc 4.1 the specific services and information elements as well as the most relevant quality parameters and user groups were identified and documented. Furthermore the QoIS documents that had to be elaborated within SuAcs 4.2-4.5 were drafted as templates and handed over to the SuAc 4.2-4.5 leaders for further elaboration together with elaboration guidelines in order to ensure a unique level of detail and structure of the results.
Within SuAcs 4.2-4.5, the minimum quality requirements towards the related services and information elements were investigated, discussed and documented. As it was experienced that the effort for this took much more time than expected due to different viewpoints and understandings it was agreed to focus on the elaboration of the minimum requirements and handle other expected results as optional (as stated in chapter 3.3).
In the end lots of experiences and know-how in relation to the definition of QoIS for RIS was gained by all participating partners and results are available which can form a solid basis for further work in that field.
1 Documentation
|Title |Content |Organisation |
| |Work programme per SuAc |RWS and via donau |
|Activity 4 work programme | | |
| | | |
|2010-01-26 IRISII Act4 work programme_v0p1c.doc | | |
| |Selected services and quality |RWS |
|QoIS in the RIS context |parameters | |
| | | |
|2010_06_01_M6_QoIS_in_the_RIS_Context_v0p5_draft_final.doc | | |
| |Guide how to elaborate the QoIS |via donau |
|Elaboration guide |documents for NtS, ERI, RIS Index | |
| |and VTT | |
|2010_06_01_QoIS_elaboration_guide_v0p6_draft_final.doc | | |
| |Overview on selected services / |via donau |
|QoIS tables per SuAc |information elements, quality | |
| |parameters and user groups | |
|QoIS_for_NtS_v0p2.xls | | |
|QoIS_for_ERI_v0p2.xls | | |
|QoIS_for_RIS_Index_v0p5.xls | | |
|QoIS_for_VTT_v0p2.xls | | |
| | | |
|QoIS documents for review by RIS expert groups |Definition of minimum quality |SuAc leaders and |
| |requirements |partners |
|1_2011_05_20_QoIS_NtS_v1p0_draft_EG_review.pdf | | |
| | | |
|2_2011_05_20_QoIS_ERI_v0p8b_EG_review.pdf | | |
| | | |
|3_2011_05_20_QoIS_RIS-Index_v0p11_EG_review.pdf | | |
| | | |
|4_2010_05_20_QoIS_VTT_v0p91_EG_review.pdf | | |
Table 1-2: Documentation Activity 4
2 Benefits
The main potential future benefits out of well defined and agreed minimum quality requirements on certain RIS key technologies and services would be:
• Provision of a minimum quality level of operational systems and services beyond national borders. This potentially contributes to the increased acceptance and usage of RIS within the inland navigation transport sector and therefore indirectly contributes to the general main aims of RIS, the increase of safety, efficiency and environmental friendliness of inland navigation.
• An agreed definition of minimum quality requirements is a solid basis for the justification of infrastructure investments in order to provide a certain quality level.
• Detailed discussions about the quality topic for RIS during the numerous Activity 4 meetings have led to several recommendations, how to provide specific RIS service from the point of view of certain quality parameters. These recommendations can in certain extent contribute to increase the quality of RIS provision without big effort and costs.
5 Conclusions & recommendations
Together with the experts in the RIS Expert Groups it was concluded that IRIS Europe II provided a most suitable approach for dealing with the complex topic of “Quality of River Information Services”. The identified services and quality parameters were agreed, and the methodology was much appreciated by the RIS Experts. However, the elaboration of the values for the selected quality parameters requires more time and special attention.
Awareness and a common understanding were created that the intention of the work related to Quality of RIS was not to duplicate existing standards but to build, where applicable, bridges between existing standards / technologies and operational requirements. In addition, operational requirements currently not addressed in standards or regulations shall be identified. The RIS Expert Groups were identified as the most suitable platform for bringing together these requirements.
The IRIS Europe II consortium does in no way conclude the content of the Sub-Activity reports within Activity 4 as finalised, as it reflects a first attempt to gather ideas and experiences how to identify and define relevant quality requirements. The further work and output related to Quality of RIS strongly depends on the experience and expertise of the experts in the field of River Information Services, whereas for the Sub-Activity reports the specific expertise of the Vessel Tracking and Tracing Expert Group, the Inland ECDIS Expert Group, the Notices to Skippers Expert Group, the Electronic Reporting International Expert Group, the Inland Navigation Branch Organisations and inland waterway transport sector will be unconditionally required.
1 Experiences and conclusions
• “Quality of RIS Services” is in general a complex topic: it involves many different quality aspects of many different RIS services, provided for different users each involved with different business processes and hence with different quality requirements. The diversity in demands on quality extends even further: it may depend on local, navigational, hydrological or meteorological conditions and it may be different up to the level of individual information elements provided by a service. The approach to handle this complexity during the project involved:
o Selection of a subset of quality parameters: only the most important / relevant ones were taken into consideration.
o Limitation of the number of services to be evaluated: only the most important services, i.e. those related to current developments within the participating countries, were evaluated
o Provision of clear definitions of the chosen quality parameters.
• Several different understandings of specific quality parameters were identified in the course of selection of a subset of quality parameters that made it even more difficult to agree on a certain definition and to reach a common understanding of the quality parameter in relation to RIS.
• Furthermore it was experienced that one and the same quality parameter might have different meanings for different information elements.
• It was experienced that the requirements towards a minimum quality level differs enormously from user group to user group and from business case to business case. Therefore it can be concluded that the strictest minimum requirement for a specific information element shall define the related minimum quality level.
• It was also experienced that different persons of the same user group (e.g. fleet managers) have very different requirements concerning the quality level (e.g. accuracy of vessel position information), which makes it complicated to identify a solid minimum quality level.
• “Availability” aspects have been investigated from a systems owner perspective. In other words a maintenance setting where availability is measured from historic events (e.g. over the last week/month/year this service has been available for such and such). Other views on availability are possible but were not specifically investigated.
• Some parameters need to be 100% accurate because processes use them as (primary) keys to access databases. A good example is the ships number (ENI or IMO number); in many services this number is used as e key to store and access data related to a particular ship. A wrong number can make services fail or deliver wrong data.
• It is only hardly possible to define a unique and harmonized level of quality for RIS services (key technologies) throughout Europe.
• In certain cases, it is not possible to define minimum quality level for certain quality parameter (as in case of availability). Only the methodology how to ensure a sufficient quality level can be specified.
2 Recommendations
• It is recommended to continue the activities related to the definition of minimum quality requirements for RIS and to enhance existing infrastructure in order to fulfil these requirements. The framework of “expert groups” may provide an excellent vehicle to continue this ongoing work on a continuous basis.
• Although there are European wide quality levels needed for many RIS information elements, the operational necessity for quality enhancements is expected to be most beneficial when established from a corridor perspective.
• It is recommended that meaningful minimum quality requirements become part of existing RIS standards. Furthermore it is recommended that existing quality requirements within the RIS standards are further investigated and developed.
• It is recommended to ensure, that the requirements of real RIS users will be examined on more detailed level from the practical point of view (not theoretical).
• Definition of SLA (or revision of existing SLA) for RIS provision on national level considering the results and recommendations out of Activity 4.
• The use of standards and guidelines is no guarantee that the quality of systems or the quality of information provided by these systems is adequate or on the same level as implementations of the same service based on the same standards in other countries. When interconnecting these services across borders many differences may show up and many differences in quality may become evident. Therefore it is recommended that the development of implementation guidelines is continued and extended along with additional (international) cooperation. These guidelines should be based on implementation experience as much as possible. They can provide the insight in implementation aspects needed to achieve minimal quality differences in services throughout Europe.
• Inland shipping is not an isolated economic activity; it has many interconnections with the maritime world, with road traffic, customs, harbour authorities etc. Some quality aspects are defined or are under development in these other transport related areas. A good example is for instance the IALA developments on availability parameters for equipment at (coastal/sea-harbour) vessel traffic management centres; much of this equipment can also be found in inland shipping traffic centres. Therefore it is recommended to closely monitor these developments and where appropriate to adopt or refer to standards and guidelines from other disciplines for inland shipping processes.
• In some cases “quality” cannot easily be expressed in numbers. This does not mean that QoIS cannot be addressed; the processes involved in producing and providing the RIS information can be viewed at. Within the European context of inland shipping this means that the production of RIS information itself should be looked at and where needed be aligned and harmonized with the information production processes in other countries. This will eventually lead to harmonization of quality, without the need for numeric reference values on quality levels. In practice this means that international cooperation between EU countries is needed up to the level of (day to day) operational activities.
3 Envisioned next steps
• Quality of River Information Services shall become a permanent agenda item at each meeting of the various RIS Expert Groups (Inland ECDIS EG, Notices to Skippers EG, Vessel Tracking and Tracing EG and Electronic Reporting International EG).
• The Experts within the RIS Expert Groups shall conclude on the most important quality aspects and quality parameters for each key RIS technology to be further elaborated on (e.g. accuracy of water level integration into Inland ENCs)
• Fairways and requirements are different; further fine-tuning of QoIS is required, reflecting and considering the local needs (e.g. Danube is different to Rhine). Focussing attention to quality requirements within inland shipping corridors may prove to be most beneficial
• Specific expertise of the Inland Navigation Branch Organisations and inland waterway transport sector will be unconditionally required
• Investigate the dependencies between the quality parameters, the business process, operational processes of the authorities and national legislation
• Investigate the benefits of increased quality compared to the costs the implementation of such quality
• Establish a RIS Service Directory of all operational RIS Services in Europe. This Service Directory can be the basis for further investigations on quality of RIS
• Analyse national implementations according to identified quality parameters and give national authorities and organisations guidance on how to improve the quality of the provided services (can be done by a specialised “Evaluation / Quality Assurance Task Force”)
• Investigate best practice examples and existing Service Level Agreements for already operational RIS Services
• Put specific emphasis on the quality aspects and quality parameters that are important for the interoperability of RIS Services throughout Europe. The establishment of a RIS Service Directory and of a RIS Service oriented architecture will be important milestones for achieving improved interoperability of RIS.
Introduction
This document contains a description of the work that was done in relation to quality aspects within RIS. It has been produced as part of the work within Activity 4 of the IRIS Europe II project and cannot fully be understood without having knowledge of this work and the contents of other documents produced as part of Sub Activities 4.1 through 4.5. This foreword attempts to answer some of the questions that a reader, not familiar with mentioned work and documents, may run in to.
General setting
Activity 4 of the IRIS Europe II project addresses “Quality of (RIS) Information Services” with the emphasis on 4 so called “key technologies”:
1) Notices to Skippers services
2) Electronic reporting services
3) The RIS index (meaning the index with fairway network reference data)
4) Vessel traffic services
There are many different RIS services, many different quality aspects, many different business processes using RIS services, many different (groups of) data elements supplied by services and many different circumstances under which information is used. During various Activity 4 meetings it became clear that choices had to be made; it would have been impractical in terms of usefulness and manpower to try covering all quality aspects of all information elements supplied by all RIS services for all circumstances. It was decided that a selected choice of services and quality aspects were to be addressed and that the work on this was to be divided amongst the project partners, each with a lead responsibility for one particular key technology. The consequences of these limitations have yet to be elaborated.
Selection of services
Baseline for selecting services has been the PIANC version of the RIS guideline. This guideline lists over 70 different services which, even when limiting them to mentioned key technologies, would amount to a lot of services to cover, so a subset was chosen based on the following criteria:
• The service is currently or soon available/operational in 1 or more EU countries;
• Practical experience with these services has shown quality related issues;
• Quality issues are not only local or national but also play a role in international RIS implementations of the service.
Chosen quality aspects
After considering some of the quality issues currently at hand in the participating countries, the following parameters were chosen:
Availability:
• Ability to use data and facilities (meaning hardware, software, network/communication facilities etc.)
Correctness of information:
• Accuracy: Deviation from real world (information content)
• Age: Time passed by since measurement or creation (information age)
• Completeness (in particular for the RIS index data)
Quality parameter definitions
From the very beginning of the project it was obvious that clear and unambiguous definitions of quality parameters are essential. Without these, results will be misinterpreted and lead to permanent confusion. The definitions used in the Sub Activity 4.n documents are the following:
Availability:
The Availability definition is based on a functional demand; when all hardware, firmware, software and network facilities all perform their designed main functions, the RIS service is considered “available”. This basic requirement is extended for the situation where involved system/network components are being repaired and bypassed with an acceptable workaround. Obviously the latter requires a definition of “acceptable”.
Therefore it was agreed (for all RIS key technologies), that availability shall be expressed as a percentage (%) of a year that the service has to be available and is always accompanied with a maximum allowable downtime (MADT) of the system/service, expressed in hours per disturbance. The allowable downtime is measured between the moment that a service has been alerted as non functioning till the moment the service is operational again (without or with workaround, see “total handling time” in schematic below). The maximum value is, in general, based on a user requirement.
[pic]
Figure 1: Quality parameters
Note1: A single availability figure without the MADT does not make much sense. An availability of 95.8% could mean “all year long available except for 1 hour each day”; it could also mean “once per year not available for 15 days in a row”. This first might be acceptable and the last clearly not, hence the accompanying “maximum allowable downtime” to availability figures.
Note2: Availability should not be confused with “completeness of information”; when data is missing this is generally not a hardware/software/network problem of the RIS service facility itself.
Accuracy:
This parameter is defined as the deviation from real world and is expressed as a percentage above and below the parameter value (for example water level = 366 cm +/- 5%).
Age:
Some information has a tendency to age and becomes less appropriate / useful or even misleading as time passes by. The “age” quality parameter is expressed as time passed by since measurement or creation of the information element.
The appropriateness / usefulness of an information element may become less gradually in time or degrade very abrupt. For both cases a description may be added to indicate the usefulness of aged data for the business processes using the particular services.
For some parameters this is not appropriate. For example a “water level value” ages much faster in a tidal area than in a canal and may be subject to sudden aging beyond usefulness when a hydroelectric power plant is started or a floodgate is opened. For such cases a description of the age requirements may be listed.
Completeness:
The examination of the completeness quality parameter refers to data coverage of data in relation to the objects mentioned in RIS Index.
Minimum requirements
For all of the above listed quality parameters, in certain cases there are also minimum requirements values mentioned in individual tables. If the concrete value is proposed, the source where it is taken from is mentioned also in the footnote. In certain cases, the minimum required values are left blank. In this case the minimum required value is not specified. In certain cases, it is not possible to provide “one” minimum requirement value, which could be applicable thorough Europe, since the requirements on provision of RIS services differs per region, per user group, per traffic density, etc. In these situations only methodology how to ensure the required service level is given (e.g. above mentioned approach how to specify availability of service).
SuAc 4.1 Definition of QoIS in the RIS Context
1 Introduction
IRIS Europe II, Activity 4 deals with the introduction of Quality of Information Services in the RIS context. Main objective is the elaboration of harmonised European (minimum) quality requirements and definitions for RIS services. Due to the complexity of this activity, it is clear that within IRIS Europe II only a representative selection of QoIS can be elaborated and defined. Therefore the focus lies on selected services / information elements for the following RIS key technologies:
• Notices to Skippers (further explored in SuAc 4.2)
• Electronic Reporting (further explored in SuAc 4.3)
• Vessel Tracking and Tracing (further explored in SuAc 4.5)
In addition to the RIS key technologies the following reference data with high importance for the RIS key technologies and several RIS services is taken into account:
• National RIS Indices (further explored in SuAc 4.4)
The results out of Activity 4 shall provide a solid basis for the further harmonised definition of European (minimum) quality requirements in the RIS context. This document is an outcome of SuAc 4.1 defining the general approach and the focus of Activity 4 by selecting the most relevant services / information elements and quality aspects. This document also aims on fulfilling the IRIS Europe II milestone M6 (Results documented for the definition of service levels in the RIS Context).
2 Sphere of influence for QoIS
1 Information chain
The quality of a River Information Service is a complex matter, it depends on the quality of several individual components in the information chain (source data, interconnections and facilities, etc.) used to create and publish the data. The figure below illustrates the focus of the work.
[pic]
Figure 2: Information Chain Overview
2 Structure of “quality”
In general the quality of River Information Services can be split into:
• The quality of the information itself, which is built up by:
o The quality of the information that is provided by the service to its users. Depending on the type of data, this quality is expressed in terms of accuracy, reliability, age, completeness, correctness, conformity to standards, etc.
o The quality of the input data. Many services read information from sources, transform this one way or another and then provide it to users. The quality of this input data is expressed in similar terms as for the previous one.
• The quality of the service facilities, which can be divided into:
o The quality of the delivery facilities, used for information to reach users. This is in general determined by the availability, reliability, security, performance, etc of the supplying systems and facilities;
o The quality of the access facilities for data sources, in general determined by the availability, reliability, security, performance etc of the systems and facilities used by data suppliers/sources (such as "other systems", shippers/skippers, authorities, etc.)
3 Influences
SuAc 4.1 deals with the definition of minimum recommendable quality aspects and parameters for the RIS services. In exploring these quality aspects four interrelated fields need to be considered:
[pic]
Figure 3: Influences on quality level
RIS services:
RIS comprises a variety of services; many but not all will be considered in sub activity 4.1. Following the division and grouping of services presented in the "Guidelines and recommendations River Information Services" from the International Navigation Association (PIANC) a choice will be made of services to be considered. Arguments to include a service in the quality requirements analysis are in general:
• The service is to be implemented to comply with the RIS directive
• The international exchange of information for and/or provided by the service may require harmonized quality
• The service entails one of the considered key technologies covered by SuAcs 4.2 through 4.5
Information elements:
• Each Service provides elements of information to users (more accurate: to inland shipping business processes). Some of these elements may be provided by several (different) services (e.g. "position information" about ships is used / provided by several different services to different processes with different usage). Based on the initial grouping in "services", an inventory is presented for specific information elements.
Process requirements:
• In general inland shipping processes require information to run properly. "Process requirements" include the quality demands these processes impose on the information they use. When for example a skipper is planning a journey, the planning process requires information such as water levels (current and/or predicted) with a certain accuracy, actuality etc. User requirements are closely related to, but not quite the same as process requirements ("skipper" versus "voyage planning" in the previous example). Since RIS is about services providing information for business processes, this document addresses "process requirements" rather than "user requirements".
Quality parameters:
• There are many different aspects that add up to the "quality" of a service. Some of these, but not all, can be expressed in a parameter with a value. Before establishing parameter values, it has to be clear what the parameter is about and that requires clear and unambiguous definitions of these quality parameters. So the fourth angle of exploration will be the definition of quality parameters specific for the RIS context. These definitions will be used throughout all documentation on Ac 4 and related SuAcs.
4 RIS services and related key technologies
As mentioned above, not all RIS Services can be taken into account for the work to be done within Activity 4, due to its complexity. Therefore the most relevant RIS services / information elements need to be identified for being further investigated in detail. For the identification of the relevant RIS services, the RIS Guidelines were used.
In the table below the RIS services are presented in the same order and grouping as in the "Guidelines and recommendations for River Information Services" from the International Navigation Association (PIANC) and as contained within Directive 414/2007. In the columns next to the description of the service / information element, the relevant RIS users are indicated (as defined within the RIS Guidelines). Within SuAc 4.1 the allocation of the RIS services / information elements towards the considered RIS key technologies was elaborated and is as well indicated in the table below.
|Functional decomposition River Information Services (table 4.6 from PIANC guidelines) | RIS Technology |
| | |Information level |
| |RIS service | |
|No. | | |
| |RIS sub-service | |
| | | |
| |RIS function | |
| |(Information Element) | |
|1.1 |Content | |
|1.1.1 |Relevancy of information |The information supports effectively the execution of daily operations, including|
| | |planning, making decisions, reporting to authorities |
|1.1.2 |Granularity and aggregation |The level of detail or aggregation of capturing, processing, recording and |
| | |presenting data. Information to policy makers need a high aggregation level; with|
| | |calamity abatement support very detailed information is needed for identifying |
| | |and locating dangerous goods. Sensoring physical measures will be on a very |
| | |detailed capturing level, after which data will be summarized. |
| | | |
|1.2 |Usability | |
|1.2.1 |Understandability |Users' ease to understand a system's working without great, to be repeated effort|
| | |for learning input, output and operational control. If this quality is not |
| | |present, the user will be demotivated to keep using the system; the correctness |
| | |of data may diminish. |
|1.2.2 |Helpfulness |Built in user assistance to use a system without human interference and |
| | |consulting user manuals; user's errors are prevented and detected by system; |
| | |transparent menu structures. |
|1.2.3 |Clarity/ease of interpretation |Users' ease to understand and interpret immediately the input and output data, |
| | |without recurring education courses |
|1.2.4 |Representation consistency |The consistency of presentation of identical data in information chains. |
| | |Inconsistent representation will give avoidable misinterpretations of data. |
|1.2.5 |Explicitness of every action |The current status of each step in the data process in progress is clear to the |
| | |user. The consequences of the manipulation of data are clear in advance; |
| | |preceding steps which have been executed don't have to be guessed. |
|1.2.6 |Ease to input source data |Users' ease to input data from originating points in the information chains, by |
| | |availability of a variety of means to input data and clear screen layouts |
|1.2.7 |Ease of access, updating, maintaining |Users' effort for access, updating, maintaining and management without the |
| |and management of data |technical assistance of service providers |
|1.2.8 |Variety of languages |The parallel translation into other languages will avoid misunderstanding and |
| | |miscommunication |
|1.2.9 |Facilities to forward reports and |Users' ease to send information along the information chains to a variety of |
| |messages |national and international destinations by different means |
|1.2.10 |One time reporting |Degree to which one time reporting is sufficient and comprehensive to reach all |
| | |destinations |
|1.2.11 |Push facilities |Facilities for distributing periodical and ad hoc information on the initiative |
| | |by the data supplier, without the request by the individual user |
|1.2.12 |Pull facilities |Facilities for distributing periodical and ad hoc information upon request by the|
| | |individual user |
| | | |
|1.3 |Safety | |
|1.3.1 |The likelihood that incorrect or |Incorrect or unavailable data in mission critical systems used in vital traffic |
| |unavailable data don't lead to threats |management processes may lead to these threats. If this not the case, the data |
| |for human life, limb and health or |are supposed to be "safe" . |
| |environment, or to serious disruption of| |
| |society | |
|1.3.2 |The likelihood of a safety-related |This quality aspect indicates the degree of reliance you may put in a safety |
| |system satisfactorily performing the |related system. Safety of the safety-related system is not endangered, because |
| |required safety functions under all |the system will be functioning satisfactorily even under bad conditions. |
| |stated conditions within a specified | |
| |period of time | |
| | | |
|1.4 |Interoperability (systems, cross border,|Interoperability represents the degree to which information can be exchanged |
| |transport modes) |between two or more systems and be used mutually. |
|1.4.1 |Effort needed for realizing |This aspect describes how easy it is to connect systems and to exchange data |
| |interoperability | |
| | | |
|1.5 |Flexibility | |
|1.5.1 |Ease of adaptive and perfective |Adaptive maintenance modifies data processes to keep them usable in a changed or |
| |maintenance |changing environment; perfective maintenance modifies data processes to improve |
| | |performance or maintainability. As these types of maintenance take lesser effort,|
| | |the system is assumed to be more flexible. |
|1.5.2 |Portability to another environment |Ability of software to be transferred from one environment to another, which is |
| | |made easier by conformance to standards or conventions relating to portability |
|1.5.3 |Adaptability |Accommodating new environments doesn't demand already provided actions or adding |
| | |new means |
|1.5.4 |Installability of software in a |The effort needed to install the software in a specified environment |
| |specified environment | |
|1.5.5 |Replaceability by other software |The possibility and effort of using software in the place of specified other |
| | |software in the environment of that software |
| | | |
|2 |Efficiency | |
|2.1 |Resource behaviour |Indicates the amount of resources used and the duration of such use |
| | | |
|3 |Availability | |
|3.1 |Ability to use data and facilities as |Proportion of time users have access to data and facilities with stated minimum |
| |expected |performance, at stated locations, to stated data, including stated delivery and |
| | |access facilities, related to the stated time |
|3.2 |Performance |Response times, processing times, throughput rates, end to end cycle time for |
| | |information chain, under stated conditions |
| | | |
|4 |Correctness/integrity |degree to which recorded data correspond with reality |
|4.1 |Accuracy | |
|4.1.1 |Authority |The originating point of the source data possesses authority by expertise or |
| | |recognized official status and objectivity, so no doubt about the correctness is |
| | |warranted |
|4.1.2 |Deviation from real world |The difference between the data value produced by data processes and the real |
| | |value |
|4.1.3 |Deviation from surrogating data source |The difference between the data value produced by data processes and the value of|
| | |source data |
|4.1.4 |Existence of object |The object of which data are captured, processed and presented does exist in real|
| | |world |
|4.1.5 |Non-duplication of data |The data of an object are only once recorded in a record, file, database |
|4.1.6 |Semantic consistency in data chain and |The data in a filed, record, dataset have the same, identical meaning in one ore |
| |parallel data chains |more data chains |
|4.1.7 |Synchronization of data in data chain, |Synchronized data demand for identical criteria for adding/deleting objects and |
| |data chains and distributed data |identical time schedules for updating data |
|4.1.8 |Validity of values |The data are supposed to be valid, because they don't exceed value constraints |
| | |("business rules"); the meaning of a null value is clear (null value is "O.K." or|
| | |"data value not known") |
|4.1.9 |Referential integrity within data base |Every value of one attribute (column) of a relation (table) exists as a value of |
| | |another atribute in a different or the same relation (table) |
|4.1.10 |Completeness consolidation/aggregation |All values of one ore more attributes of individual objects have been computed |
| | |correctly to one value for the population of objects |
|4.1.11 |Compliance to data related standards or |I.E. recorded data comply with data protection acts |
| |conventions or regulations in laws and | |
| |similar prescriptions | |
| | | |
|4.2 |Age | |
|4.2.1 |Time passed by since measurement or |Data are getting older if not timely refreshed. At a certain point of time "old" |
| |creation |data become useless or even misleading. |
|4.2.2 |Data decay rate |The rapidity with which data become useless or even misleading by time passing |
| | |by. Gives an indication for the necessity for periodical refreshment. |
|4.2.3 |Throughput rate |The cycle time required for processing data from originating point to |
| | |distribution |
| | | |
|4.3 |Completeness | |
|4.3.1 |missing fields, records, data sets, |incomplete data could affect the performance of daily operations |
| |distributed data sets | |
|4.3.2 |data coverage |degree to which the data of all objects, time periods, geographic areas are being|
| | |covered |
|4.3.3 |completeness distribution to internal |all users receive all the information intended to be received by them |
| |and external users | |
| | | |
|4.4 |traceability of data and data processes |the ability to explain a current data value from source data, executed data |
| |to source data, data processes and |processing and individuals who have added, deleted and modified data |
| |individuals | |
| | | |
|5 |Exclusiveness (confidentiality) |the degree to which the access to personal and business data is reserved to |
| | |individuals and parties |
| | | |
|6 |Reliability | |
|6.1 |the probability that during a certain |this quality aspect describes the expectations which exist regarding future |
| |amount of time a system performs the |availability. |
| |functions described in the specification| |
| |of requirements under the stated | |
| |conditions | |
|6.2 |the probability that the performance of |this quality aspect describes the expectations regarding the effective protection|
| |a system is resilient and resistant to |against well described faults and problems. |
| |the presence of a limited number of | |
| |hardware or software faults incl. | |
| |interface problems or changing | |
| |environment | |
|6.3 |recoverability to re-establish the usual|this quality aspect describes the ability to return to normal performance if |
| |level of performance, in case of failure|threats have materialized |
|6.4 |degradability to a lower level of |this quality aspect describes the ability to stay "live" by killing temporarily |
| |performance, maintaining the most vital |resources consuming functionalities |
| |functionalities and switching off | |
| |certain functionalities | |
Table 3-2: Full list of quality aspects and their definition
Based on the table above, a subset of quality aspects has to be selected for further evaluation by certain criteria (e.g. contribution to optimizing the capacity and efficiency of transport infrastructure as well as enhancing safety and reliability of operations).
Important notice: When implementing systems / services, a quality aspect like "availability of production / distribution facilities" is determined by the information element with the highest availability demands that is supported by the facilities on which it is residing / transported from.
For example: If a FIS platform distributes highly dynamic water level data and almost static legal information, the availability of the system / network / software etc. is determined by the demands that users of the water level data demand from this platform. This mechanism in effect creates a different view on many quality aspects imposed on data elements. The service(s) used for distributing the information with the highest quality demands dictate the quality levels and hence other elements can be discarded in the quality assessments.
3 Quality of Information Services in the RIS context
At the very beginning of the activities, it was identified that not all of the services / information elements and quality aspects can be considered due to the complexity. Therefore the first task was to focus on specific relevant services / information elements and quality aspects.
1 Need for and process of focusing the work
The main goal of Ac 4 is demonstrating the perspectives for introducing European service level parameters, allowing RIS services to operate on an equal and consistent quality level throughout the EU fairway system. To reach this goal, it is not useful nor practical or manageable to include all RIS sub services / information elements and all quality aspects in the scope of work of Ac 4. This results in the need to select manageable subsets. The figure below gives an overview of the selection process used.
[pic]
Figure 4: Quality aspects filtering and scoping approach
The primary purpose of RIS services is to provide inland shipping processes with information which allow for safe, secure and efficient transports as well as to utilize inland waterways to their fullest potential. In other words: intelligent transport systems have to contribute in optimizing the capacity and efficiency of existing and new inland shipping transport infrastructures as well as enhancing safety and reliability. Capacity, safety and reliability of operations are prime subjects when selecting RIS services and quality aspects to be included in Ac 4.
2 Selected RIS Services / information elements per key technology
The following subchapters list for each of the considered RIS key technologies the selected RIS services / information elements to be explored for relevant quality demands.
The selected RIS services / information elements have strong relations with the capacity, safety and reliability of operations.
Selected RIS Services / information elements for NtS
• FIS.4 Long time obstructions in the fairway
• FIS.6 Temporary obstructions in the fairway
• FIS.7 Present and future water levels at gauges
• FIS.9 Restrictions caused by flood and ice
Selected RIS Services / information elements for ERI
• STI.4 Presentation of vessel’s characteristics
• STI.5 Presentation of cargo’s characteristics
• STI.6 Presentation of intended destination
• LBM.2.1 = PTM.2.1 Provision of ETAs of approaching vessels
Selected RIS Services / information elements for VTT
• TTI.1 Presentation of own vessel’s position
• TTI.2 Presentation of other vessel’s position
• STI.2 = VTS.1 Presentation of vessel’s positions in large surroundings
• VTS.3 = CAS.2 Short term assessment of traffic situation
• LBM.1.2 Presentation of short term planning of lock/bridge (ETAs / RTAs of vessels, waiting places, lock/bridge positions)
3 Selected RIS key technologies and priority objects for RIS Index
The following RIS key technologies were identified to use the RIS Index as important reference data:
• Notices to Skippers
• Electronic Reporting
• International RIS data exchange based on the RIS Data Exchange Reference Documentation (as defined within IRIS Europe I and to be brought into operation within IRIS Europe II)
Vessel Tracking and Tracing is not considered due to the fact that the relation with the RIS Index is only minor.
Inland ECDIS is not considered due to the fact that only Inland ECDIS standard version 2.0 or higher supports the ISRS LocationCodes but most of the countries still work with older versions. Therefore an investigation and especially evaluation would not be feasible from that point of view.
The following RIS Index objects are prioritised and thus considered for the elaboration of QoIS for RIS Index:
• Gauges
• Locks
• Bridges
• Ports and terminals
Fine-tuning of this priority list might occur when the final list of prioritised RIS Index objects is available out of the PLATINA project.
4 Selected quality aspects
Some 50 quality aspects have been identified in scanning recent literature on information quality (see chapter 2.5).
The 50 potential quality aspects have been linked to the selected RIS services / information elements. During a filtering process some quality aspects have emerged as the dominant quality factors that need attention.
Besides the grouping of the quality aspects into categories (effectiveness, efficiency, availability, etc.), there is a further relevant allocation based on the individual components within the information chain (see chapter 2.1):
• Quality of data sources (in particular third party data sources)
• Quality of input data
• Quality of the services (processing of data, provision of information to users)
• Quality of information provided to the users
To have quality measurable, each quality aspect has been specified into one or more parameters. The table below provides the definitions of the selected quality aspects, their allocation to the category and relevancy to the components of the information chain as well as the considered RIS key technologies for which the quality aspects will be investigated.
|# |Category / Subcategory |Description of quality aspect |Relevant for information chain: Quality of … |
| |Quality aspect | | |
|1 |Availability |Proportion of time users have normal access to RIS service (data and facilities) with |Proportion of acceptable total uptime after deduction of any unacceptable degradation time|
| |Ability to use data and facilities |stated minimum performance, at stated locations, to stated data, including stated |or downtime of RIS service that reasonably could have resulted in consequences, measured |
| |as expected |delivery and access facilities, related to 8760 hours/year, after deduction of any |during a period of time |
| | |RIS service degradation or RIS service downtime (failure identification, diagnosis, | |
| | |isolation, procurement, calling up stand by personnel, recovery, maintenance, upgrade, | |
| | |calibration, administrative actions) | |
|2 |Availability |Response time at users’ locations (getting an usable answer in reaction to a prompt by |Proportion of total time during which an acceptable level of response times has been |
| |Performance |a user). |achieved, without any unacceptable performance that reasonably could have resulted in |
| | | |consequences, measured during a period of time |
| | |Processing time, i.e. number of minutes/seconds needed for automatic and manual |Proportion of total time during which acceptable processing times have been achieved |
| | |processing |without any unacceptable processing time that reasonably could have resulted in |
| | | |consequences, measured during a period of time |
| | |Throughput rate, i.e. number of manually/automatic processed transactions per hour |Proportion of total time during which acceptable throughput rates have been achieved, |
| | | |without throughput rates which reasonably could have resulted in consequences, measured |
| | | |during a period of time |
| | |End to end cycle time, i.e. the number of minutes/seconds needed for manually/automatic|Proportion of total time during which acceptable end to end cycle times have been |
| | |processing source data, starting at receipt time at processor location and ending at |achieved, without any unacceptable end to end cycle time that reasonably could have |
| | |receipt time at the final user location |resulted in consequences, measured during a period of time |
|3 |Correctness / Accuracy |Errors in: time (days, hours, minutes, seconds); ID’s and names; coordinates; value |The rate of occurrences where a realized unacceptable accuracy reasonably could have |
| |Deviation from real world / data |references; |resulted in consequences, in relation to total number of occurrences, measured during a |
| |source |measured/predicted values |period of time |
|4 |Correctness / Accuracy |Amount of unique or conflicting data, data sets |The rate of occurrences where unique data or data sets are available more than once so |
| |Non-duplication of data | |that consequences could have resulted, in relation to total number of considered data or |
| | | |data sets |
|5 |Correctness / Accuracy |Validity of values, i.e. permitted date/time range; permitted RIS-index/ISRS; mandatory|The rate of occurrences where a realized unacceptable validity of rules reasonably could |
| |Validity of values |international standard formats and permitted codes (NtS, ERI, VTT) |have resulted in consequences, in relation to total number of occurrences, measured during|
| | | |a period of time |
|6 |Correctness / Age |Time passed by since measurement or creation |The rate of of occurrences where a realized unacceptable level of age reasonably could |
| |Time passed by since measurement or| |have resulted in consequences, in relation to total number of occurrences, measured during|
| |creation | |a period of time |
|7 |Correctness / Completeness |Missing fields, data, data sets |The rate of occurrences where fields, data or data sets were missing so that consequences |
| |Missing fields, records, data sets,| |could have resulted, in relation to total number of occurrences, measured during a period |
| |distributed data sets | |of time |
|8 |Correctness / Completeness |Data coverage |The rate of non acceptable not recorded fairway length on a set day whose non recording |
| |Data coverage | |reasonably could have resulted in consequences, in relation to total fairway length; |
| | | | |
| | | |The rate of non acceptable missed events, whose missing reasonably could have resulted in |
| | | |consequences, in relation to total number of events, measured during a period of time; |
| | | | |
| | | |The rate of non acceptable missed objects that reasonably could have resulted in |
| | | |consequences, in relation to total number of objects, measured during a period of time |
Table 3-4: Parameters of selected quality aspects
4 Elaborating selected Quality Aspects and RIS services
Out of the input from SuAc 4.2 – 4.5, a goal of Ac 4 is to formulate minimum values for the quality parameters. Thus, in SuAc 4.2 - 4.5 the selected quality aspects will be elaborated for the selected RIS services / information elements separately per considered RIS key technology respectively for the RIS Index.
For that purpose separate tables have been elaborated within SuAc 4.1 containing a matrix with the selected services and quality aspects per RIS key technology respectively for the RIS Index. A prioritization of the quality aspects and the services, respectively the objects for the RIS Index, was done. Those prioritized parts are to be elaborated whereas the non-priority parts shall be elaborated additionally in case that the SuAc 4.2 – 4.5 resources allow this after the elaboration of the prioritized parts. The reason for this approach is to keep certain flexibility due to the fact that the effort for the elaboration of the minimum quality requirements cannot be estimated.
Furthermore, working documents were drafted by SuAc 4.1 to be handed over to SuAc 4.2 – 4.5 for being filled. A detailed elaboration guide on how to fill the documents is also provided as another output by SuAc 4.1.
5 Demonstrating selected Quality Aspects
Due to the high effort during the elaboration and definition of quality requirements within the SuAcs 4.2 – 4.5, it was identified and confirmed by the Project management Team of IRIS Europe II that implementation and demonstration of the defined quality requirements are not feasible anymore within this project with the available budget and resources.
SuAc 4.2 Definition of QoIS for Notices to Skippers
1 Introduction
IRIS Europe II, Activity 4 deals with the introduction of Quality of Information Services in the RIS context. Main objective is the elaboration of harmonised European (minimum) quality requirements and definitions for RIS services. Within SuAc 4.1 the general approach as well as selection of relevant services and quality parameters was elaborated and the approach for the definition of the QoIS was defined.
Based on these results, the QoIS for NtS were investigated within SuAc 4.2. This document provides the QoIS for the most relevant quality parameters for a representative selection of NtS services. The results out of Activity 4 shall provide a solid basis for the further harmonised definition of European (minimum) quality requirements in the RIS context.
2 Quality of Information Services for NtS
As the result of activity 4.1 – Quality of Information Services RIS there were following fairway information services (FIS) identified as relevant services provided via NtS:
• FIS.4 Long time obstructions in the fairway (low priority)
• FIS.6 Temporary obstructions in the fairway (high priority)
• FIS.7 Present and future water levels at gauges (high priority)
• FIS.9 Restrictions caused by flood and ice (low priority)
As indicated in brackets, it was further decided, that FIS.6 and FIS.7 will be primarily elaborated in any case from the point of view of minimum quality requirements on these services. FIS.4 and FIS.9 will be elaborated optionally if there will be some resources left after examination of FIS with high priorities.
Following qualitative aspects and user requirements to these aspects are examined for FIS.6:
|Quality aspect/Minimal requirements on |General description of quality aspect |Related FIS |
|Availability / Ability to use data and |Proportion of time users have access to data and facilities with |FIS.6 |
|facilities |stated performance, at stated locations, to stated data, including |FIS.7 |
| |stated delivery and access facilities, related to the stated time | |
|Correctness / Accuracy / Deviation from real |The difference between the data value provided to the users / |FIS.6 |
|world |services and the real value respectively the value of source data |FIS.7 |
|Completeness/ Missing fields, data, data sets|Wherever data(sets) consist of more than one data field (value) it |FIS.6 |
| |is expected that all relevant values are contained in order to do | |
| |not affect the data / service negatively by missing values | |
|Correctness / Age / Time passed by since |Time between measurements or creation of the data towards provision|FIS.6 |
|measurement or creation |to the relevant users / services |FIS.7 |
General description of FIS.6 and FIS.7 as well with the elaboration of selected quality aspects for these services represents the core content of the remaining part of this document. For better illustration what are the respective FIS about, examples from countries where NtS services are in operation are mentioned (e.g. Austria, Slovakia). These processes and the way these services are provided can be however different from country to country.
Legislation relevant for provision of Notices to Skippers
Provision of NtS by respective member countries is stipulated by the DIRECTIVE 2005/44/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 7 September 2005 on harmonised river information services (RIS) on inland waterways in the Community and its article 4, section 3d which reads as follows:
In order to set up RIS, Member States shall ensure that notices to skippers, including water level (or maximum allowable draught) and ice reports of their inland waterways, are provided as standardised, encoded and downloadable messages. The standardised message shall contain at least the information necessary for safe navigation. The notices to skippers shall be provided at least in an accessible electronic format.
Guidelines for the planning, implementation and operational use of the services (RIS guidelines) as well as technical specifications of NtS as referred to in article 5 of RIS directive are stipulated by COMMISSION REGULATION (EC) No 416/2007 of 22 March 2007 concerning the technical specifications for Notices to Skippers as referred to in Article 5 of Directive 2005/44/EC of the European Parliament and of the Council on harmonised river information services (RIS) on inland waterways in the Community.
Member States shall ensure that Notices to Skippers are provided according to these technical specifications in XML-format downloadable on the Internet. In order to enable a specific download, Internet services should provide a possibility to select:
• a specific waterway section or
• a specific part of a waterway, defined by the river-km of the starting and the end point,
• a time of validity (starting date and end date),
• and a date of publication of the notice (date of publication).
Notices according to this standard can additionally be provided for example by:
• WAP (Wireless Application Protocol) services,
• E-mail services.
Data exchange between the authorities is recommended. All the authorities using this standard can integrate Notices to Skippers of other authorities and countries in their own services. The participating parties (authorities) can agree the procedure of transmitting the XML messages by push or pull services directly.
3 Results
The investigations resulted in the elaboration of detailed tables defining the minimum requirements towards the selected quality parameters for the selected services / information elements.
The detailed results are contained in the SuAc 4.3 Report.
4 Experiences and recommendations
(delivered by SuAc1.3 – Enhanced notices to skippers)
Experiences:
• For the reliability of NtS and its acceptance by fairway users the quality of the information used as input for the NtS services is crucial.
• Implementation of technologies for automatic data transfer from sensors (gauges, meteostations etc.) significantly spares time, human work, errors and is a generally good solution. Specific emphasis should be laid on data quality checks, because due to failures on sensors, data transmissions etc. wrong data could be detected, resulting in unreliable information distributed through NtS that confuses fairway users.
• Large number of inputs could improve information quality, but it needs sophisticated evaluation before distribution to users who need simple information via NtS.
• Mathematical models are a modern solution that could help the decision process by RIS authorities. With usage of on-line data from a network of sensors on waterways it is possible to model water flows and ice situation with relatively good accuracy and reliability. Models that run several times per day could detect future important situations on time, with good advance for reactions.
• There are no significant methods for prediction of fog situation on waterways, in particular in narrow, deep and winding valleys, where classic weather forecast models give different predictions. For navigation safety information about fog is very important.
Recommendations:
• The input data should be checked in order to guarantee the quality of information published through NtS services, in order to supply reliable information to the fairway users.
• NtS should use automatically detected, transferred and evaluated data where possibly, e.g. water levels, weather situation, lock operation status. However manual quality checks are needed in order to avoid failures and wrong values. A completely automated system (without human control) could be risky in non-standard situations.
• Mathematical modelling needs large number of data inputs that improve prediction quality. For stable operation system must overcome temporary failures of particular data inputs.
• Special emphasis should be done on general forecast modelling, as weather and hydrological models that in many cases have crucial impact on forecast quality of phenomena on waterways.
SuAc 4.3 Definition of QoIS for Electronic Reporting
1 Introduction
IRIS Europe II, Activity 4 deals with the introduction of Quality of Information Services in the RIS context. Main objective is the elaboration of harmonized European (minimum) quality requirements and definitions for RIS services. Within SuAc 4.1 the general approach as well as selection of relevant services and quality parameters was elaborated and the approach for the definition of the QoIS was defined.
Based on these results, the QoIS for ERI were investigated within SuAc 4.3. This document provides the QoIS for the most relevant quality parameters for a representative selection of ERI services. The results out of Activity 4 shall provide a solid basis for the further harmonized definition of European (minimum) quality requirements in the RIS context.
2 Quality of Information Services for ERI
1 Introduction
Electronic Reporting (ER) is considered one of the key services of RIS. The information provided by ER services is currently primarily used by lock and bridge operators, by VTM operators, by organizations responsible for handling and the abatement of calamities, by waterway authorities and by organizations producing statistical information on waterway traffic. Future usage will include that by mentioned users in similar and in more sophisticated ways and may also include the usage by new users. In some EU countries ER information is used for taxation and in law enforcement[1].
ER services provide information on voyages of ships, the cargo and the crew/passenger numbers. In some European countries (e.g. Netherlands) some of the most critical components of the ER systems have been designated as "mission critical systems" since disruption of these services may deteriorate safety and reduce waterway transport efficiency. For this reason demands on quality parameters like "systems availability" are considerable.
The most important ER services referred to in the RIS guidelines are the following:
• STI.4 Presentation of vessel’s characteristics
• STI.5 Presentation of cargo’s characteristics
• LBM.2.1 = PTM.2.1 Provision of ETAs of approaching vessels
and, with less priority:
• STI.6 Presentation of intended destination
In the following paragraphs various quality parameters for the data gathered and distributed through these ER services are detailed. Secondly quality parameters for the systems and facilities involved in the services are detailed. For the latter some basic information chains have been examined. Since there are architectural differences in various (national and international) implementations of ER systems, these system performance parameters have been diversified for the most common configurations currently used in Europe.
The use of ER services is not a stationary process; throughout Europe different developments can be seen, ranging from first implementations to replacement of 1st and 2nd generation equipment. Recently the Central Commission for the Navigation of the Rhine (CCNR) introduced mandatory ER for container vessels on the Rhine River; the Netherlands has extended this obligation for all its major waterways. On the Danube pilot implementations for ER were carried out within IRIS Europe I in AT, SK, HU and HR. In the project IRIS Europe II AT, SK and HU will bring their pilot implementations in pilot operation including the incorporation of users.
Mandatory ER is expected to cover more inland waterway transports in the future. Both the increasing dependency on ER information as well as the enforcement of the reporting obligation will impose higher quality demands on the reporting facilities in the future.
2 ERI process description
This paragraph gives a short description of the ER process; the steps for ER summarized here, are from the skippers’ point of view.
In the figure below an example is presented of the ER process and the context in which it is used in the Netherlands.
[pic]
Figure 5: Electronic reporting context example
In this example skippers can either use BICS, a stowage application[2] in combination with BICS or another ER application to electronically report voyage and cargo details to the waterway authority. The voyage and cargo information is stored in a receiving system (e.g. IVS90 in the Netherlands, the MIB in Germany and distributed to traffic management centres covering the waterways that the ship will travel on / pass during its voyage.
When a vessel which is undertaking a cross-border voyage, for example from NL to DE, and it approaches the border, the Dutch system (IVS90) automatically transfers the related voyage and cargo data to its sister system the MIB-II in Germany. The reverse of this process takes place for ships that are crossing the border from Germany to the Netherlands.
In case of a calamity or accident, vessel, voyage and cargo data of the involved vessels will be available for all authorities handling the calamity / accident. They will also have access to information of vessels approaching the accident location.
The standardized ERINOT 1.2 EDIfact message is used to electronically report the voyage and cargo information to the authorities. This standard message is also used between RIS authorities to exchange voyage and cargo information for cross-border voyages. ERInot messages contain the following:
• Voyage data:
o Transport means i.e vessel name, vessel identification number, type of transport, operational dimensions (tonnage, length, width, draught and height).
o Origin and destination (including terminal info)
o Number of persons on board.
o Number of cones or B-flag.
• Barge data (if it’s a transport combination):
o Barge names, identification numbers and dimensions
• Container data:
o Total number of loaded and empty containers per category.
• Cargo data:
o Cargo loading and discharging location (incl. terminal).
o Dangerous cargo UN nr + Classifications + pack. Group + name (ADNR data), IMDG code or
o HS code and the name (for non-dangerous cargo).
o Cargo weight (be sure the units are the same).
• If cargo is in a container then these additional information items are applicable:
o Container number
o Container type
o Stowage location
In the context of ER the following key users are identified:
• Ship master (skipper) or Fleet manager, responsible for submitting the correct and actual electronic reports (voyage and cargo information).
• Receiving authority, such as VTM operator, Lock or Bridge operator, who will receive the electronic reports and are able to retrieve the correct and actual voyage and cargo information for traffic management when necessary.
• Logistics users, such as terminal operators, who will receive the list of vessels to load and unload including the correct cargo (container) information to optimize their logistic process (terminal and load/unload planning).
• Calamity abatement (calamity centre), who will receive the voyage and (dangerous) cargo information in case of an accident or calamity.
The following table lists contains an overview:
|ERI process per |Ship master |VTS operator |Logistic Users |Calamity abatement |
|Service / User | | | | |
|STI.4 Vessel’s |Operational vessel dimensions |Dimensions are used for |Parameters like vessel |Vessel dims are used for |
|characteristics |(lxbxd, type) are reported to |lock planning and can be |tonnage can be used for |handling calamity incidents |
| |the authorities so they can use|used for fairway (stretch)|(initial) planning the |(impact, follow-up actions).|
| |it in their planning activities|planning. |cargo transports |Maneuverability and handling|
| |(lock, fairway stretch etc). |The operator can also |(distribution of cargo |the vessel in case of an |
| |Correct and actual vessel |inform or warn the skipper|over several vessels). |incident can depend on the |
| |dimensions are also important |for special situations | |size and tonnage of the |
| |for route planning by the |regarding the current | |vessel. |
| |skipper in combination with |dimensions of his vessel | | |
| |fairway network information and|and limitations on the | | |
| |NtS. |waterway. | | |
|STI.5 Cargo’s |Correct, actual (dangerous) |Dangerous cargo |Cargo information |Correct, actual (dangerous) |
|characteristics |cargo information (weight, type|information (weight and |(weight, type, load, |cargo information (weight, |
| |and container info) is |type) is used for lock |unload location and |type and container info) is |
| |essential for authorities in |planning (certain vessels |container info) is used |essential for authorities in|
| |case of an accident/calamity. |with cones are not allowed|for planning the cargo |case of an |
| |The skipper is responsible for |together in a lock). This |transports. Such as |accident/calamity. |
| |submitting correct information |could also be the case for|distributing the cargo |Based on this information |
| |to the waterway authority |certain fairway stretches.|over the vessels, |the proper measures and |
| |before departure. |Based on the dangerous |terminal (load/unload) |action can be taken (handle |
| |Normally the skipper will get |cargo information the VTS |and route planning. |incident, inform and warn |
| |the cargo information |operator can inform/warn |Finally the cargo |other related |
| |(transport order) from a |the skipper for special |information can be used |users/skippers, re-route |
| |shipping company or other |(safety) situations. |to inform the other |traffic etc) |
| |client from the shore. | |parties in the logistic | |
| | | |chain (cargo receivers | |
| | | |etc) | |
|LBM.2.1=PTM.2.1 |Vessels will report their |ETA information can be |ETA information can be |ETA information can be used |
|Provision of ETAs |destination ETA via ER when |used for Traffic |used for optimizing |to roughly estimate current |
| |reporting their voyage and |management (lock, fairway |terminal planning and |position and intentions of a|
| |cargo data (i.e before |stretch and terminal/berth|usage. |ship/skipper, which may be |
| |departure). Based on the ETA, |planning etc). | |of interest during |
| |authorities and other parties | | |calamities. |
| |are able to plan lock passages,| | | |
| |do berth planning etc. | | | |
|STI.6 Intended |Destinations (with ETA’s) are |Destinations together with|Destinations together |Destination information can |
|destination |reported and necessary for |ETA’s are used for traffic|with ETA’s are used for |be used to identify the |
| |fairway stretch planning. |management activities |optimizing terminal |correct reported voyage in |
| | |(international versus |planning and usage. |case of a calamity. |
| | |local destinations, | | |
| | |fairway planning, traffic | | |
| | |intensity). | | |
The picture below gives a general overview of the scope of the ER services being investigated. The blue text items describe the boundaries of the aspects covered. Basically the work has been limited to the RIS service itself and not on the systems and or facilities of the information sources. In the ER context this means that for example BICS or other systems on board or located at agents, customs, harbors, logistic companies etc are not part of the scope. Note that in the next paragraphs this scope is indicated with red boundaries
[pic]
Figure 6: Information chain RIS
3 Message Chains
Current messaging principles include the following information chains:
[pic]
Figure 7: ER messaging
(on board reporting based on GSM modem / GPRS; example configuration Rhine countries)
In the table above "classic" BICS configuration is sketched; the Ship master reports voyage, cargo and crew information (or changes) to the authority using a GPRS connection or GSM modem. The data itself has been collected / entered onto an on-board computer, running the BICS application. Messages are received ashore by a secure e-mail service and are forwarded to a database system which can be accessed by end users. End users can also become suppliers of data by manual entry of new data or by manual corrections on existing data. Everything in the red marked rectangular is part of the research scope for 4.3; in NL this part is designated as "mission critical".
[pic]
Figure 8: ER messaging
(on board reporting based on internet connection; example config Rhine countries)
The configuration in the figure above is similar to the one on the previous page; difference is that instead of using a GPRS connections or GSM modems, reporting is done using an internet connection. Shipmasters, carriers or terminal operators report voyage, cargo and crew information (or changes) to the authority using a dedicated PC application (internet BICS version) that transmits data (secure e-mail messages) over an internet connection. Quality aspects like availability of services / functions of systems are similar to the ones applicable for the configuration illustrated on previous page; the section designated as "mission critical" is basically the same. The components like the individual data entry stations and the internet are not part of the mission critical systems setup.
To illustrate the complexity of quality issues related to interconnected systems, the following example lists the results of an analysis done for a chain of ER systems operated in Germany and the Netherlands
During the analysis, the exchange of ER information throughout the entire chain was evaluated at a number of interception points (marked with yellow hexagons). The information (messages) found at these interception points were compared against the information initially submitted by the skipper (the initial ER message detailing voyage, cargo and container data).
[pic]
Figure 9: Information chain analysis setup (DE – NL)
The following (interceptions) points were examined:
1. The source data from BICS (the BICS message and BICS printout).
2. The information as received in IVS90 for voyages from NL->DE and the information as exchanged between IVS90 and MIB-II.
3. The information as received in MIB-II for voyages from DE->NL and the information sent to IVS90.
The following data elements were checked comparing the information at the described check points:
• Voyage data
• Barge data (for transport combinations)
• Container data
• Cargo data
3 Results
The investigations resulted in the elaboration of detailed tables defining the minimum requirements towards the selected quality parameters for the selected services / information elements.
The detailed results are contained in the SuAc 4.3 Report.
4 Conclusions
The analysis revealed several mismatches / incompatibilities; some of which can be categorized as originating from "independent systems and application development in two different countries". The lessons learned include:
• The use of standards and guidelines is no guarantee that the quality of systems or the quality of information provided by these systems is adequate or on the same level as implementations of the same service based on the same standard in other countries. When interconnecting these services across borders many differences may show up and many differences in quality may become evident.
• It is recommended that the development of implementation guidelines is continued and extended along with additional (international) cooperation. These guidelines should be based on implementation experience as much as possible. They can provide the insight in implementation aspects needed to achieve minimal quality differences in services throughout Europe.
• The use of "optional" elements in messaging standards can lead to differences that show up when data is transferred from one system across a border to another system.
• Coding standards should be the same.
• Inland shipping is not an isolated economic activity; it has many interconnections with the maritime world, with road traffic, customs, harbour authorities etc. Some quality aspects are defined or are under development in these other transport related areas. A good example is for instance the IALA developments on availability parameters for equipment at (coastal/sea-harbour) vessel traffic management centres; much of this equipment can also be found in inland shipping traffic centres. It is recommended to closely monitor these developments and where appropriate to adopt or refer to standards and guidelines from other disciplines for inland shipping processes.
• When a system has a fail rate of e.g. 1/9th, the availability is 88.9%. Doubling such a system can theoretically improve the availability to approx. 98.8%; the chance that both fail at the same time ≈ 1/9th *1/9th. The opposite of availability improvement is also possible: two systems both with an availability of 88.9% that each do part of the total task will have a combined availability of approx. 77.7%; the chance that the combination of them fails is the sum of both fail rates ≈ 1/9th +1/9th. This mechanism (redundancy versus dependency) applies for example to situations where an accident happens near a border and calamity abatement depends on the information coming from systems on both sides of the border. From an availability point of view there should be a strong commitment to share data and interconnect systems in such a way that systems on both sides of a border will operate as each other’s back-up rather than each other’s complement. To prevent deterioration of availability near borders (all borders, not only country borders) a joint approach from the neighbors is needed. It is recommended to stimulate this cooperation between corridor partners and to review interconnected RIS systems in relation to the data collections they provide. This can pinpoint any gaps in availability from a user point of view.
• Due to legal / regulatory obligations the facilities to receive electronic messages with ship/trip/cargo data should have a high availability. Regulations require that ships cannot start a voyage until cargo/voyage data is reported to the authorities. If message receiving systems would have a low availability that would pose problems on departing ships, either in the sense of damages (not leaving means loss of time and time = money) or ships would depart anyway and authorities would not know this nor what is on board.
• Some parameters need to be 100% accurate because systems use them as (primary) keys to access databases. Identifying numbers in messages (ENI number, MMSI-number, IMO number) play a crucial role in storing and retrieving ships data. Using wrong numbers may lead to a variety of problems. It is recommended to implement checks on these numbers both in systems and in operational procedures whenever and wherever feasible/appropriate. Reference data describing the relation between MMSI number and ENI number requires special attention. Specific operational procedures may be needed to maintain adequate quality of this reference data.
• Information which is retrieved through VHF communication is usually validated by operators entering this information into systems. For electronically received information this type of validation is not feasible but systems can scan data and apply validation rules. It is recommended to share these validation rules between EU countries implementing ER services.
• In those cases where “quality” cannot be expressed in numbers, the processes involved in producing and providing the RIS information should be looked at. Within the European context of inland shipping this means that the production of RIS information itself should be looked at and where needed to be aligned and harmonized with the information production processes in other countries. This will eventually lead to harmonization of quality, without an immediate need for matching against numeric values on quality levels. In practice this means that international cooperation between EU countries is needed up to the level of (day to day) operational activities.
SuAc 4.4 Definition of QoIS for RIS Index
1 Introduction
IRIS Europe II, Activity 4 deals with the introduction of Quality of Information Services in the RIS context. Main objective is the elaboration of harmonised European (minimum) quality requirements and definitions for RIS services.
Within SuAc 4.1 the general approach as well as selection of relevant RIS key technologies and quality parameters was elaborated and the approach for the definition of the QoIS was defined.
Based on these results, the QoIS for RIS Index were investigated within SuAc 4.4. This document provides the QoIS for the most relevant quality parameters for RIS Index from the point of view of selected RIS key technologies.
The results out of Activity 4 shall provide a solid basis for the further harmonised definition of European (minimum) quality requirements in the RIS context.
Please note that unlike on case of other QoIS documents in case of RIS index the so-called bottom-up approach was also considered
The following technical modification proposals were discussed about the RIS index:
• Restructuring the RIS index to have relational model instead of flat one
• Providing the exact location of the object
• River identification
• Location of the object related to the fairway
• Defining fairway section
• Information about ports
• Direction of the limitation
• Reference data for bridges
• Lock data
• Communication information
Please note that this has been removed from this document and moved to the competence of the Joint Task Force of the RIS index. The first JTF meeting was held in Prague, 18th February, 2011. These issues were presented.
Important remark: During the elaboration of this document the RIS Index Encoding versions 0p7 and 0p8 (provided by PLATINA) have been taken into account.
1 RIS Index in general
Preconditions for interoperable and open RIS are Standards for RIS technologies making excessive use of internationally standardised messages and codes, whereas the codes can be summarised by the term “RIS Reference Data”. Among the many RIS reference data the encoding of locations (e.g. objects along the waterways, in ports, etc.) by means of location codes establishes a link between the various RIS technologies, implying the highest level of unambiguousness for the encoding of locations.
Location codes are utilised by Tracking and Tracing technologies, Inland Electronic Navigational Charts, Notices to Skippers and Electronic Ship Reporting. Until now only the international Standards and Regulations regarding the technical specifications for Electronic Ship Reporting in inland navigation contain a definition of the locations codes, also referred to as ISRS location codes (ISRS, International Ship Reporting Standard). Although a definition of the ISRS location code exists, a uniform encoding scheme for the ISRS location code has not been introduced into international RIS Standards and Regulations yet.
Already in the early days of RIS there was awareness for the importance of a uniform encoding scheme for the ISRS location codes, as applications started to face severe interoperability issues. This led to the introduction of the RIS Index, intended to be a register of all locations with relevance for RIS and supplying to RIS users all relevant data concerning navigation and voyage planning on inland waterways.
The RIS Index is a list of ISRS location codes with additional information on the objects.
[pic]
It should contain all the objects, which are relevant for
• Electronic Reporting (start, passing and end points of voyages),
• Inland ECDIS (all the objects with the unlocd attribute),
• Notices to Skippers (all the objects, which might be affected by Notices to Skippers)
• and Inland AIS (gauges, when water level information is transmitted via Inland AIS)
Article 4 paragraph 3 a) of the RIS Directive contains the requirement, that the Member States shall supply to RIS users all relevant data concerning navigation and voyage planning on inland waterways. These data shall be provided at least in an accessible electronic format.
The data, which is required by the RIS Directive can be provided in electronic navigational charts (Inland ENCs) in accordance with the Inland ECDIS standard. But the data can also be provided in form of a list for smaller waterways, if there are no Inland ENCs available. The RIS Index provides a template for such a list.
Each country has to produce its own RIS Index. Neighbouring countries should work together for the location codes in the border sections. A bridge in a border section should not have two different location codes, for example. Software providers have to compile the various national indexes to a European RIS Index for their purposes. The use of a common template is the basis for an effective compilation.
2 Overview of elements in the RIS Index
In the following table the main elements of the RIS Index are summarized with the categorization whether they are to be filled mandatory / optionally / conditionally / automatically.
|ELEMENT NAME |FILL OUT |CONDITION NATURE |
|Country code |Mandatory |External |
|UN location code |Mandatory |External |
|Fairway Section Code |Mandatory |Internal |
|Terminal code[3] |Mandatory |Internal |
|Hectometre |Mandatory |External |
|ISRS location code |Automatic |Internal |
|Function |Mandatory |External |
|Object name |Conditional |External |
|Location name |Optional |External |
|Waterway name |Mandatory |External |
|Route name |Optional |External |
|Related ISRS |Optional |Internal |
|Section node |Optional |External |
|Latitude and longitude |Mandatory |External |
|Related ENCs |Conditional |External |
|Communication information |Optional |External |
|National gauge code |Optional |External |
|Start date for applicability of the data set |Conditional |Internal |
|End date for applicability of the data set |Conditional |Internal |
Figure 10: Overview of elements in RIS index
3 Basic elements of the RIS index
Country code – column K
The country code is a mandatory field. It consists of two letters and is defined in ISO standard 3166-1. The official list of country codes is published at the following page:
Possible quality aspects:
• In case of country code change it should be adopted within a reasonable time.
UN location code – column L
The UN location code is a mandatory field. It consists of three letters. The codes are assigned by UN CEFACT. The official list of location codes is published for each country at the following website:
If there is no location code for a place, the location code “XXX” has to be used until an official location code is assigned by UN CEFACT.
Possible quality aspects:
• An official code should be requested for every location.
• In case of location code change it should be adopted within a reasonable time.
Fairway Section Code – column M
The fairway section code is a mandatory field. It consists of five alphanumerical digits and has to be assigned by the national authorities. It represents the coding of a fairway section within a national network and is only unique in combination with the country code.
Possible quality aspects:
• Provide the contacts of the related authority.
• Provide an exact definition of the code (name of the fairway, river hectometre section etc.).
• In case of waterway code change it should be adopted within a reasonable time.
Terminal code (Object reference code, as proposed by Platina) – column N
The object reference code is a mandatory field. It consists of five alphanumerical characters and has to be assigned by the national authorities.
Possible quality aspects:
• Provide the contacts of the related authority.
• In case of location code change it should be adopted within a reasonable time.
Hectometre – column O
The hectometre code is a mandatory field. It consists of five numerical digits.
Possible quality aspects:
• Provide the contacts of the organization which made the measurement.
• In case of any change it should be adopted within a reasonable time.
• The accuracy should meet a defined minimum requirement.
ISRS location code – column P
The ISRS location code is generated automatically from the previous fields.
Possible quality aspects:
• The field should always be consistent with the related fields. (Remark: providing both the single elements and the ISRS code is redundant.)
Function – column Q
The table functions of the template of the RIS Index contains a list of standardized values for this field with explanations and the connection to the function codes
Possible quality aspects:
• The same function codes should be used in every national RIS index.
• The codes should be more homogenous and self-explanatory.
Object name – column R
The object name has to be provided, if it exists (if a berth has a name, for example).
Possible quality aspects:
• Encoding of the names. (Currently the “Basic Latin Unicode” is preferred, which a bit confusing. (The Unicode is 16 bit long, but the Basic Latin is only 7 bits.) It is recommended to really use the 16 bits Unicode, e.g. due to the Cyrillic Bulgarian names.)
• In case of name change it should be adopted within a reasonable time.
Location name – column S
The location name can be used to provide the name of the location (e.g. the city), where the object is situated.
Possible quality aspects:
• Encoding (see above).
• In case of name change it should be adopted within a reasonable time.
Waterway name – column T
Possible quality aspects:
• Encoding (see above).
• The waterway name could be redundant because of the waterway section code.
Route name – column U
Possible quality aspects:
• Encoding (see above).
Related ISRS – column V
The related ISRS location code can be used to establish a connection between the various openings of a bridge and the bridge itself or similar relations.
Possible quality aspects:
• It could also be used to handle the multiple ISRS code for the same object problem.
Section node – column W
It is used in the Dutch RIS Index and contains national 4 digit codes for sections.
Possible quality aspects:
• As this is used only in one national index, it should be considered to reformat it to become a more general one.
Latitude and longitude – columns X and Y
Possible quality aspects:
• Accuracy.
• Availability (currently this is an optional field, but it could be mandatory).
4 Additional elements of the RIS Index
Related ENCs – column Z
If the object is also part of an Inland ENC, the file name of the IENC has to be provided here.
Possible quality aspects:
• The RIS index and the IENC have to be consistent.
Communication information – column AA
Communication information (e.g. of a lock) can be provided as a standardized XML file in accordance with the Inland ECDIS standard edition 2.0. The name of such a file can be entered here.
Possible quality aspects:
• The RIS index and the ECDIS have to be consistent.
National gauge code – column AB
This field is optional and is provided by the national authority, if the country finds it necessary. National gauge code is utilized in order to create link to national encoding systems.
Possible quality aspects:
• Provide the contacts of the related authority.
• It should be consistent with the national gauge code. Any updates should be adopted within a reasonable time.
Start and end date for applicability of the data set – column BZ and CA
If the data of a specific object is only applicable in a specified period (e.g. due to replacement, building, other changes), the dates have to be entered here. [4]
Possible quality aspects:
• Correctness of the dates provided
2 Quality of Information Services for RIS Index
Availability
Availability in RIS context generally means that the related data are simply available. More specifically:
• 3.1 Ability to use data and facilities as expected: Proportion of time users have access to data and facilities with stated minimum performance, at stated locations, to stated data, including stated delivery and access facilities, related to the stated time
o Available for all the relevant actors (e.g. RIS centres, ERDMS, skippers etc.).
• 3.2 Performance: Response times, processing times, throughput rates, end to end cycle time for information chain, under stated conditions
Correctness – Accuracy
The following aspects could be considered within the topic accuracy:
• 4.1.1 Authority: in case of all the fields the source of the data could be provided.
• 4.1.2 Deviation from real world: as the RIS index is a relatively static list, and the sensitivity is relatively high (e.g. providing the river hectometre only 50 meters accuracy can be expected), the most possible precise data can be expected.
• 4.1.4 Existence of object: in this case this can be twofold: if something exists in the real world (e.g. a new bridge is build) then it is enlisted on the RIS index, too, on the other hand if something is enlisted on the RIS index, then it really exists (e.g. a not-used gauge should be removed from the RIS index).
• 4.1.5 Non-duplication of data: it is expected that the ISRS code is unique in two ways: two different objects don’t hold the same ISRS code on one hand; one ISRS code is related to exactly one object on the other hand. (Remark: it can be discussed if the latter one can be changed.)
• 4.1.8 Validity of values: all the used codes are defined (e.g. function codes); none of the data are out of range (e.g. river hectometres, latitude-longitude etc.).
o The data are available in such a format which is required by the target (which is in most of the cases software).
Correctness – Age
As the RIS index is a static list in short term, and dynamic list on long term, this aspect has a lower significance. The following aspects can be taken into account:
• 4.2.1 Time passed by since measurement or creation: it could be useful to know when a specific data has been modified last. (A 10 years old data can also be actual, of course.)
• 4.2.3 Throughput rate: this means how much time passes between the change in the real world and the RIS index. Some measurements can be defined here, maybe separately for every types of infrastructure (e.g. a new bridge should be announced within x days (or before y days of the handover)). Is some minor cases in can be defined that it should be updated at the next global update, like every x months.
Correctness – Completeness
In the field of completeness the following aspects can be investigated within the RIS index:
• 4.3.1 Missing fields, records, data sets, distributed data sets: there are mandatory, conditional and optional fields. All of the mandatory fields and if needed the conditional fields should be provided.
• 4.3.2 Data coverage: 100% coverage of the defined types of infrastructure is expected. (The total sum of the items to be used by the RIS index is relatively low.)
o Available for every relevant country.
o Every required infrastructure types are available (e.g. gauges, bridges etc.).
o Every single object within every type is available (e.g. every Danube bridge within the country).
o All the mandatory fields are available.
o All the optional fields which provides extra relevant information or useful for some applications.
• 4.3.3 Completeness distribution to internal and external users: this requirement means handling the RIS index, and doesn’t relate to the RIS index itself.
1 Quality aspects of selected objects in the RIS index
Locks
The total sum of the different types of locks is relatively low, and they have critical importance in the inland waterway transport (IWT) planning very strict requirements can be formed regarding to locks.
Bridges
The total sum of the bridges is a bit higher and the importance is a bit lower than in the case of locks, but similar strict requirements can be formed regarding to the bridges, too.
Gauges
The gauges themselves don’t have high influence on the IWT, but the measurements provided by the gauges have got, especially in case of high deviation from the normal conditions. The possible gauge related change according to the relevance on IWT can be divided into 2 categories:
• New gauge: this has got medium significance, and medium requirements can be formed. The reason: the IWT related actors, tools etc. hadn’t relied on the data provided by that specific gauge before the installation.
• Modification of the gauge or removing it: it has a critical significance, and the modification in the real world has to be accompanied by the modification in the RIS index as quick as possible. The reason: it is better not to have any data at all, than having a bad data or relying on a data which doesn’t exist.
Berths, ports and harbours
The significance of up-to-date information of the berths, ports and harbours is very high, so strict requirements can be formed regarding to this types of data.
3 Results
Proposal for a tabular presentation of the selected objects:
|Object category |Selected objects in the RIS Index |Quality aspects |
|Bridges |All types of bridges |The total sum of the bridges is a bit higher and the |
| | |importance is a bit lower than in the case of locks, but |
| | |similar strict requirements can be formed regarding to the|
| | |bridges, too. |
|Locks |Lock basin |The total sum of the different types of locks is |
| | |relatively low, and they have critical importance in the |
| | |inland waterway transport (IWT) planning very strict |
| | |requirements can be formed regarding to locks. |
| |Lock basin part | |
|Ports, harbours and terminals|Port area |The significance of up-to-date information of the berths, |
| | |ports, harbours and terminals is very high, so strict |
| | |requirements can be formed regarding to this types of |
| | |data. |
| |Harbour basin | |
| |Harbour area | |
| |Terminal | |
|Turning basin |Turning basin | |
|Berths, anchorage |Anchorage area | |
| |Anchorage berth | |
|Gauges |Waterway gauge |The gauges themselves don’t have high influence on the |
| | |IWT, but the measurements provided by the gauges have got,|
| | |especially in case of high deviation from the normal |
| | |conditions. The possible gauge related change according to|
| | |the relevance on IWT can be divided into 2 categories: |
| | |New gauge: this has got medium significance, and medium |
| | |requirements can be formed. The reason: the IWT related |
| | |actors, tools etc. hadn’t relied on the data provided by |
| | |that specific gauge before the installation. |
| | |Modification / Removal of the gauge: it has a critical |
| | |significance, and the modification in the real world has |
| | |to be accompanied by the modification in the RIS index as |
| | |quick as possible. The reason: it is better not to have |
| | |any data at all, than having a bad data or relying on a |
| | |data which doesn’t exist. |
|Others |Exceptional Navigational Structure |Tbd. |
Which objects should be encoded:
List of priority objects indicating for what services (ENC/ERI/VTT/NtS/Voyage Planning) these objects are used (black/white). The table below has been established during various meetings with the experts concerning this topic. The respective experts are issuing with the four RIS-technologies, participate in the four RIS-expert groups and are responsible for their national implementation and often involved in European programs
Explanation of table below
• First column: priority indication (recommendations for encoding sequence)
|* |Highest priority (immediately implementation is required) |
|** |High priority but after change request handling Inland ECDIS standard (not yet available in the Inland ECDIS |
| |Standard) |
|*** |Objects to be investigated for extension (joint taskforce) |
|**** |Probably out of the scope |
• Second column: object (mostly in accordance with Inland ECDIS Encoding Guide)
• Third column: reference to respective chapter in the Inland ECDIS Encoding Guide
• The following columns indicate the use of objects within RIS-services
Remark: The importance of several objects will have to be checked by the Joint Task Force.
Remark: The need for this objects have been identified during the elaboration of this document. Although these objects are at the moment not part of the priority list, in the opinion of experts these object will have an added value (e.g. you need a codification of a RIS Centre, don’t you?). Whether these objects should be included in the RIS-index, should be decided by the Joint Task Force. Possibly they might be used as “additional objects”.
1 Quality aspects according to the RIS key technologies
The RIS index has got some importance in every RIS technology, in different levels. The ISRS location code is the only machine readable link between Electronic Reporting, Inland ECDIS and Notices to Skippers.
Notices to Skippers
The RIS index has got high importance in the field of NtS RIS technology. The Notices to Skippers standards require the location code for the definition of the waterway section, where a message is applicable, and the definition of the affected object. It refers to the definition of the location code in the Electronic Ship Reporting standards.
Electronic Reporting
The importance of the RIS index in the field of ERI is almost as high as in the case of NtS. ERI requires location codes for start and end point and all the passage points to define the route of a vessel.
International RIS data exchange based on R2D2 (RIS data exchange Reference Documentation)
Several processes as defined within the R2D2 require reference data out of the RIS index in order to ensure the proper functioning (e.g. destination or position based request defined based on the RIS Index; e.g. checking of access rights matching the users location with the destination of a vessel; etc.)
Inland ECDIS
The Inland ECDIS Standard (Edition 2.0) requires the location code for all the objects, which are relevant for voyage planning. It refers to the definition of the location code in the Electronic Ship Reporting standards.
Vessel Tracking and Tracing
The RIS index has got the least significance in this RIS technology, but it is not negligible. Water level information can be transmitted via Inland AIS, and the gauge related data can be important.
The most important function is the connection of the various services: Inland ECDIS charts are containing the dimensions of locks or bridges. If these dimensions are temporarily reduced due to maintenance or repair works the information is distributed by Notices by Skippers. The location code provides the possibility to link the information in a voyage planning application. Without the RIS Index the voyage planning application would not be able to recognize, whether there is an additional lock or bridge or the dimensions of an existing one have changed.
2 Other important requirements on QoIS towards RIS Index
• Uniqueness to objects contained in the ENCs
• RIS Index needs to be the basis for all RIS Services and RIS key technologies in order to ensure interoperability among those (e.g. comparison of vessel destination out of ERI (reference tables of BICS and other ERINOT reporting facilities) with user location out of R2D2 access rights check mechanism)
• The up-to-dateness of the data should be ensured. This can be achieved in the following ways:
o Ongoing quality ckecks of the national RIS Index. All the object should be checked regularly (e.g. in every 6 months).
o In case of any modification (e.g. building a new bridge) the related organization should send a notification to the maintainer of the RIS index, and a new version of the RIS index should be released. The gross amount of time passed between the modification and release of new version of the RIS index should not exceed a certain time (e.g. one month). In case of objects which are being build long (e.g. bridge) this should be latest announced specified time before the handover (e.g. one month).
• Use of a bottom-up approach: During the meeting in Varna it was discussed that it is more efficient in the RIS Index context to define concrete “problems” and do the investigation with relation to those. These concrete “problems” can be:
o timeframe within a new object has to be encoded in the RIS Index (preferably already during its building)
o how to encode these object during their building (different traffic rules can be applicable during the building of a bridge and when it is in normal use)
• Connection to ERI: it is clear that in ER a different location database is used, meaning that the BICS tables:
o do not only contain European locations
o do not use the RIS Index content
Therefore it can be a topic for investigation how to ensure that RIS Index tables will be inserted into the BICS tables. In this respect the ERDMS works have to be considered.
3 Detailed results
RIS index has still several open issues, and the quality aspects may depend on the end users needs. For detailed information please check the SuAc 4.4 Report.
4 Conclusions
To be able to use the RIS Index for multiple purposes close co-ordination and co-operation need to be set up with the following stakeholder groups:
• NtS Expert Group and Task Forces
• ERI Expert Group
• Joint Task Force on the RIS Index
• IRIS Europe II SuAc 1.3 (Enhanced NtS) and 1.5 (National reference data management systems)
• PLATINA / ERDMS
• NEWADA (Act. 5.4 Danube FIS Portal)
1 Checklist – minimum quality criteria defined
|Name |Description |Status |Remarks |
|Uniqueness |Unique ISRS code is required for all |agreed |to be checked if the |
| |types of data. | |requirement is met |
|Validity |100% up-to-dateness is required for all|disputed, see the comment + chapter 6.3.2 |to be discussed |
| |types of data. |(Other important requirements on QoIS | |
| | |towards RIS Index) | |
|Age |The last check of data should not |open |to be checked if fulfilment of |
| |exceed 2 years for all types of data. | |this requirement is feasible or|
| | | |not |
|Data coverage |100% of any kinds of listed objects |disputed, see validity |to be discussed |
| |(existing) have to be encoded by means | | |
| |of RIS index. | | |
|Using RIS index for |It should be checked if the RIS index |open |to be discussed |
|ERI |could be used for ERI purposes. | | |
2 Checklist – modification on RIS index
|Name |Description |Status |Remarks |
|Relational data model |Restructuring of the RIS index is necessary, using relational data |pending |issue raised at JTF on |
| |modelling instead of the flat one. | |18.02.2011 |
|Exact location of the |Most of the objects are not punctual, therefore the position should be |pending |issue raised at JTF on |
|object |provided with help of polygon instead of just a simple coordinate-pair. | |18.02.2011 |
|River identification |Globally unique identification of rivers is necessary. |pending |issue raised at JTF on |
| | | |18.02.2011 |
|Location of the object |It should be indicated on which bank of the river the object resists. |pending |issue raised at JTF on |
| | | |18.02.2011 |
|Section of fairway |The current RIS index doesn’t provide the possibility to define a |pending |issue raised at JTF on |
| |section, just a river hectometre, which is point information. Either the| |18.02.2011 |
| |length or a hectometre-pair should be supported. | | |
|Information about ports |Port related extra information (cargo handling profile and inter |pending |issue raised at JTF on |
| |modality) should be supported. | |18.02.2011 |
|Direction of the |It should be indicated if the limitation is relevant upstream, |pending |issue raised at JTF on |
|limitation |downstream or both. | |18.02.2011 |
|Reference data for bridges|It should be indicated that the vertical clearance information is valid |pending |issue raised at JTF on |
| |for which reference value. | |18.02.2011 |
|Lock data |A new tab for lock data like number of chambers etc should be created. |pending |issue raised at JTF on |
| | | |18.02.2011 |
|Communication information |OpenEcdis should be standardized for extra information. |pending |issue raised at JTF on |
| | | |18.02.2011 |
3 Checklist – bottom-up approach
The following quality criteria should be discussed and in case of agreement should be elaborated.
|Name |Description |Status |Remarks |
|New objects |The timeframe should be specified within the new object (under construction) |new |to be elaborated |
| |should be encoded in the RIS index. | | |
|Objects under |If a reconstruction takes a longer period of time, it should be ensured that |new |to be elaborated |
|reconstruction |correct data appear in the RIS index during the reconstruction. | | |
|Code changes |In case of code change it should be adopted within a reasonable time. The |new |to be elaborated |
| |following should be considered: country code, location code, waterway section | | |
| |code. | | |
The list could be extended with the items listed in the following chapters:
• 6.1.3 – Basic elements of the RIS index
• 6.1.4 – Additional elements of the RIS Index
• 6.2 – Quality of Information Services for RIS Index
• 6.2.1 – Quality aspects of selected objects in the RIS index
SuAc 4.5 Definition of QoIS for Vessel Tracking and Tracing
1 Introduction
IRIS Europe II, Activity 4 deals with the introduction of Quality of Information Services in the RIS context. Main objective is the elaboration of harmonised European (minimum) quality requirements and definitions for RIS services. Within SuAc 4.1 the general approach as well as selection of relevant services and quality parameters was elaborated and the approach for the definition of the QoIS was defined.
Based on these results, the QoIS for VTT were investigated within SuAc 4.5. This document provides the QoIS for the most relevant quality parameters for a representative selection of VTT services. The results out of Activity 4 shall provide a solid basis for the further harmonised definition of European (minimum) quality requirements in the RIS context.
2 Quality of Information Services for VTT
Based on the identified and prioritised quality aspects and information services, the following chapters provide detailed descriptions of the selected services, their relation to the quality aspects and the minimum requirements per quality aspect and service as well as the consequences, conditions and effort, conclusions and recommendations concerning the identified minimum requirements.
The clear focus is put on Inland AIS and Inland ECDIS as these are the RIS key technologies providing VTT; especially considering the general strategy in more and more countries to bring Inland AIS carriage requirements into force.
Certainly Radar technologies are widely used and are considered as a basic navigation tool on board the vessels. Nevertheless, the following subchapters focus on information elements providing relevant data for VTT in addition to radar as the quality requirements for radar technology are already defined (2006/87/EG, Annex IX).
Important note: The visualisation of the own vessel and of other vessels in the vicinity on the IENC onboard is only for providing additional information to the skipper (information mode). It is not allowed to navigate only relying on this service. For navigational purposes radar is mandatory. A combination of radar and the mentioned service is provided by the technology radar- map- matching visualising the vessel’s positions on the radar (navigation mode).
3 Summary
The detailed results are contained in the SuAc 4.3 Report.
Awareness and a common understanding were created that the intention of the work related to Quality of RIS was not to duplicate existing standards but to build, where applicable, bridges between existing standards / technologies and operational requirements. In addition, operational requirements currently not addressed in standards or regulations shall be identified. The RIS Expert Groups were identified as the most suitable platform for bringing together these requirements.
The IRIS Europe II consortium does in no way conclude the content of this document as finalised, as it reflects a first attempt to gather ideas and experiences how to identify and define relevant quality requirements. The further work and output related to Quality of RIS strongly depends on the experience and expertise of the experts in the field of River Information Services, whereas for the document at hand the specific expertise of the Vessel Tracking and Tracing Expert Group, the Inland ECDIS Expert Group, the Inland Navigation Branch Organisations and inland waterway transport sector will be unconditionally required.
4 Conclusions
Together with the experts in the RIS Expert Groups it was concluded that IRIS Europe II provided a most suitable approach for dealing with the complex topic of “Quality of River Information Services”. The identified services and quality parameters were agreed, and the methodology was much appreciated by the RIS Experts. However, the elaboration of the values for the selected quality parameters requires more time and special attention.
The following items were identified as main subjects for future discussions:
• Recommendations for improvement of the structure of the document
• Recommendations for improvement of the content
• Input about existing definitions related to quality requirements within VTT
o Which standards contain which definitions related to QoIS for VTT?
o What is missing in these standards related to QoIS for VTT?
o What would make sense to be separately specified (e.g. in this document)?
• There are existing requirements in force (e.g. requirement to have rate-of-turn indicator on board, several AIS carriage requirements already in force and more are expected in the near future, etc.). These requirements actually require already a 100 % availability and correctness of specific technology and data as without this, navigation is not allowed. Is this correct?
o Which existing related requirements, etc. are in force and what do they define?
• Do the defined quality parameters within this document make sense?
o Is a split into Position, COG and SOG resp. Heading and ROT necessary in all cases? E.g. for availability, if there is no position, other information elements are also not available, etc.
o Is the definition of availability in MTBF and MaxTTR (see Abbreviations) useful for specifying availability related to VTT?
• Shall the manual data (e.g. vessel name, ENI number, etc.) transmitted by VTT vessel equipment also be considered when defining quality requirements?
• What are the ideas of the experts related to the definition of minimum quality requirements for VTT (not reflecting the content of this document but on general level, what would make sense to do related to this topic)?
List of Tables
Table 1-1: Partners Activity 4 10
Table 1-2: Documentation Activity 4 13
Table 3-1: RIS Services and relevance to selected RIS key technologies 26
Table 3-2: Full list of quality aspects and their definition 30
List of Figures
Figure 1: Quality parameters 18
Figure 2: Information Chain Overview 20
Figure 3: Influences on quality level 21
Figure 4: Quality aspects filtering and scoping approach 31
Figure 5: Electronic reporting context example 42
Figure 6: Information chain RIS 45
Figure 7: ER messaging 45
Figure 8: ER messaging 46
Figure 9: Information chain analysis setup (DE – NL) 46
Figure 10: Overview of elements in RIS index 51
-----------------------
[1] Depending on the country this use can vary from "everything always accessible for enforcement authorities" to "only accessible with a court order".
[2] The electronic submission of data to the authorities can be prepared based on the (electronic) cargo lists received from the commissioning party/cargo terminal. Additional software e.g. a container planner or stowage application is used to process the electronically submitted lists and create the on-board stowage (cargo loading) plan. Currently some of these Stowage applications have the capability to communicate with a BICS module via a standardised interface. So the prepared voyage and cargo data can be send from the Stowage application to the waterway authority, using an integrated BICS module.
[3] Object reference code according to the new terminology.
[4] The original objective to propose adding this attribute by the Netherlands is to get information if the object (record) is valid. Each record should have a start date (so a mandatory attribute). The object (record) will get an end date if the object is not valid anymore. By this method the ISRS code will ever exist for use i.e. for (historical) statistics.
The Joint Task force is asked to reconsider the definition of this attributes (Start & End Date) or to add another two attributes for this reason. Point of attention is that only NL makes use of this attribute.
-----------------------
Final Technical Report
Part E – Activity 4
Publication date (final version): 31.01.2012
IRIS Europe II – Implementation of River Information Services in Europe
The European Union's TEN-T programme supporting …
A project implemented by the
IRIS Europe II Consortium
This project is co-funded by the European Commission / DG-MOVE / TEN-T
|Title of Report |
|Final Technical Report |
| |
| |
|Part E – Activity 4 |
| |
|Version |
|v1p0 (final) |
|Date of version |
|January 31, 2012 |
|Status |
|Public |
|Consolidating authors |
|via donau |Mario Kaufmann |
| |Brigitte Hintergräber |
[pic]
This project is co-funded by the European Commission / Directorate General for Mobility and Transport within the “Trans European Networks – Transport” programme
ISRS Location Code
information on the object
RIS Index
The contents of this publication are the sole responsibility of the IRIS Europe II consortium
and can in no way be taken to reflect the views of the European Union.
The contents of this publication are the sole responsibility of [pic][5] |
EíÚÀÀ˜…˜s\K:%)h!7h®~ B*CJ$^J[6]aJ$mH phMMMsH h!7h®~ CJ^J[7]aJmH sH h!7h®~ CJ$^J[8]aJ$mH sH ,jh!7h®~ 5?CJ ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.