CEERIS (Central and Eastern European Reporting Information System) – SMART Electronic Reporting Platform for IWT

Abstract

In order to increase the competitivity of Inland Waterway Transport (IWT) in Europe the concept of RIS enabled Corridor Management has been developed and was now implemented within the European flagship project RIS COMEX (https://www.riscomex.eu/.) in the 2 integrated platforms EuRIS (fairway information services, traffic information services, services for logistics) and CEERIS (retrieving of reporting requirements, electronic reporting services for skippers, receiving authority services). The novel centralized architecture enables CEERIS users of to fulfil all reporting obligations configured along their route with a central access point for one or more voyages by a single data entry, using his EuRIS data including access and reporting rights for claimed vessels. Thereby, the user does not have to take care about the complexity of reporting procedures and the further delivery of reports to the respective receiving authorities. The smart distribution of reports is managed by the system in the background proving all competent authorities with data based on the respective legal basis and configured means. Thus, reports can be received either through an authority dashboard at a central access point or email as XML (Extensible Markup Language.), PDF or as a graphical template. Data delivery and notifications using webhook is supported as well as the delivery of XML messages via API (Application Programming Interface.). The reporting platforms addresses authorities dealing with traffic management, customs, border police, statistics and ports in addition to the national RIS authorities. A smart user and identity management secures access authorization according to the consent agreement of reporting parties – consequently data can also be accessed and used by authorized third parties such as shippers, fleet managers and other logistics partners for the optimization of their services.

1 Introduction and Background

As described in Haselbauer et al. (2019) Inland Waterway Transports on the Danube waterway and its navigable tributaries were repeatedly facing major administrative barriers concerning the reporting of transported goods and passengers resulting in crucial obstacles for the efficiency and competitiveness of this transport mode. As a result, border crossing transports along the Danube have to transmit the required data to respective competent national authorities several times using different paper forms. These long-winded administrative processes are both time consuming and inefficient and lead to a prolongation of the total idle time, which is subsequently reflected in a prolongation of the total travel time of vessels. Since the costs for vessel operation make up a significant share of transport costs, transportation costs consequently increase as well, threatening the already low profit margins. River Information Services (RIS) can contribute to overcome outdated reporting processes by technologies such as Electronic Reporting (ERI), Vessel Tracking and Tracing (VTT). These River Information Services have been created to enhance Inland Waterway Transport (IWT) in terms of safety and efficiency of transport by means of telematics, with the overall goal to improve its modal split. However, the existing grown fragmentation of services was identified as setback hindering the development of new services towards synchro modality and competitivity of Inland Waterway Transport. Therefore, public authorities still cannot enjoy the full benefits of RIS for traffic management and the logistics users of RIS still have only a few benefits from RIS for transport management, most of them within the limits of national borders or of different quality in different countries. This conference contribution will introduce the implemented Electronic Reporting System CEERIS including a novel system architecture and will highlight benefits for different stakeholders together with further future development possibilities.

2 RIS COMEX

In order to tackle the existing fragmentation of services, the concept of RIS enabled Corridor Management was already established within the EU-project CoRISMa and has now been implemented in the EU-project RIS COMEX. The overarching goal of the CEF co-funded multi-beneficiary project RIS COMEX project was to provide harmonized services and functions through a centralized RIS platform aiming at improved traffic management by authorities and more efficient transport management by the logistics sector and was based on a mutual agreement between waterway authorities along specific transport corridors. RIS COMEX started in the course of 2016 and was finalized by June 2022. The project area covered altogether 13 different European countries having 14 partners joined their forces under the coordination of the Austrian Waterway Administration viadonau. As a result, a new common European RIS platform (EuRIS) was established, enabling the use of a variety of harmonized RIS services in all participating countries with a single access point. As further part of the implementation of new common RIS services, 8 countries with partially available national systems with a lacking interoperability have also developed the common Electronic Reporting platform CEERIS (Central and Eastern European Reporting Information System), which is closely integrated with the services and security features offered in EuRIS.

3 COMEX Electronic Reporting System CEERIS

3.1 Scope

CEERIS comprises the services ILE.10 (provision of information for increased efficiency during vessel inspections), ILE.11a (reporting requirements) and ILE.11b (electronic report gateway service) as specified in RIS COMEX. The scope of the approach related to cross-border electronic reporting and exchange of information for logistics stakeholders was to create a single portal, supported by all competent RIS authorities and available for all types of transport such as dangerous goods transport, non-dangerous goods transport, container transport and passenger shipping. The entry of data is required only once, according to the reporting requirements along the respective transport route. In order to correspond to the prevalent principle of a single access platform and to further use synergies of already existing supporting services, a close integration with the EuRIS platform has been established. The platforms share their identity server for the user management. The reporting platform CEERIS covers a wide scope of receiving authorities, including authorities dealing with traffic management, customs, border police, statistics and ports in addition to the national RIS authorities. In order to be able to cover all responsibilities of these authorities, missing ERI XSDs such as INVRPT¹, WASDIS² and CUSCAR³ were developed in the course of the implementation in order to be able to support reporting of ship stores, waste disposal and bill of lading using XML message transmission via webservice. For this purpose, an extended ERI data pool, the so called SoaD (sum of all data fields) including mapping to all ERI XSDs, was established. Furthermore, the smart user management secures access authorization according to the consent agreement of reporting parties – consequently data can also be used by authorised third parties such as shippers, fleet managers and other logistics partners, expanding the circle of beneficiaries.

3.2 CEERIS/EuRIS System Architecture and Integration

Figure 1 provides an overview of the high-level system architecture of the CEERIS platform, which comprises 3 system environments including development, testing and production and is hosted on a cloud platform in the EU. The production environment is based on redundant servers using load balancing. CEERIS uses the user account information stored within identity server provided by EuRIS for authentication and authorization purposes. Skippers and fleet operators can manage their vessel claims, privacy classes and reporting rights within the EuRIS platform. Furthermore, EuRIS provides route calculations to CEERIS in order to derive route specific reporting requirements. The route information is derived from EuRIS as polyline through the route planner webservice based on basic transport data. Locations used for reporting including trigger locations for report delivery are synchronized via a RIS index API provided by EuRIS.

CEERIS transmits ERINOT and ERIVOY XML messages towards EuRIS to receive ETA updates and voyage information according to the movement of the vessel. CEERIS request ETAs from EuRIS along the remaining route. Recalculations are triggered when the vessel passes dedicated important objects. Active voyages in EuRIS and the related voyage and transport information can be used by authorised 3^rd parties e.g. fleet operators, logistics operators or agents that have been granted access rights. Reporting parties with successful vessel claims can start the reporting for the planned voyage also directly from the EuRIS route planner using and redirection link to CEERIS, handing over route information and basic transport parameters.

Fig. 1.

High level system architecture of the CEERIS and EuRIS platforms

CEERIS address 3 user groups namely national ERI administrators (responsible for requirement configuration), reporting parties (skippers, fleet operators) and national receiving authorities (RIS, customs, statistics) and provides reporting services both through the user dashboards on the website and webservices. Users of external reporting applications as for example BICS can send ERINOT messages towards CEERIS through the interconnected Dutch message server Hermes. Skippers that are also registered in EuRIS and have approved vessel claims can access CEERIS to add missing data in case the reporting requirement along their specific rout cannot be fulfilled solely by the data covered by ERINOT.

Reporting party users can use API to publish voyages (new, update and cancel), retrieve information about his voyages, and retrieve reports generated for his voyages and responses for his reports following the workflow determined in Fig. 2. After publishing the voyage, reporting party can list all of his voyages for a specific vessel, filtered by minimum ETD. Information about the voyages contains common denominator which can be used to retrieve more information about a specific voyage. Using common denominator reporting party can retrieve list of reports generated for a specific voyage. Each report is identified by common denominator and reporting requirement ID. Using this information reporting party can retrieve details about a specific report which includes report data and all responses received from receiving authorities for that report in the form of ERIRSP.

Fig. 2.

Reporting party workflow via webservice

National RIS systems and inhouse systems of national receiving authorities can interconnect to CEERIS though dedicated APIs following the workflow prescribe in Fig. 3. Web-hook notifications can be configured for authorities, which contain identification information of the report which can be used to retrieve details of the report. Web-hook notification also includes all report data in CEERIS specific format and if external receiving authority system uses that format get report step can be skipped. After getting report details, receiving authority can provide response in the form of ERIRSP if it has response permission in the reporting requirement for which report is provided. Receiving authorities can periodically check get reports API to retrieve a list of new reports, provided after a specific time. For each report, report identification is provided in the form of common denominator and reporting requirement id and can be used to retrieve derails of the report. After getting report details, receiving authority can provide response in the form of ERIRSP if it has response permission in the reporting requirement for which report is provided.

Fig. 3.

Receiving authority workflow via webservice

3.3 Access Control - The Principle of Privacy by Design

Administrators of organizations that have claimed vessel ownership determine by unique privacy classes the visibility of information for other users. Proprietors of claimed vessels can grant reporting rights for their vessel to other parties as charter companies, logistics operators or agents by setting a dedicated flag enabling these users to create transport plans for a vessel and submit data and electronic reports for this vessel. This feature support Economic Operators to provide cargo information for a transport. Vessel claims are examined and approved by national identity controllers. Vessel owners can grant access to their vessels with a number of insight privacy classes.

• 1. Position related:

• • Class 1: fully anonymous

• • Class 2: basic non-personal data (default)

• • Class 3: standard AIS information (no SRM)

• 2. Voyage related:

• • Class 4: voyage information (future). This is primarily the destination of the active voyage and the corresponding ETA.

• • Class 5: detailed voyage information (future). All future waypoints and ETA is also available. The voyage can be plotted on a map.

• • Class 6: detailed voyage information (past & future). All information about the current voyage with past (ATAs) & future (ETAs) times can be consulted.

4 CEERIS Implementation

The implementation of the system was finalized in December 2021 followed by a 6 months transition period to system operation, aiming at involving component national receiving authorities and interconnecting CEERIS to the final environment of the EuRIS platform. CEERIS comprises the corridor services ILE.10 (provision of information for increased efficiency during vessel inspections), ILE.11a (reporting requirements) and ILE.11b (electronic report gateway service) as specified in RIS COMEX.

4.1 Flexible Configuration of Reporting Requirements

CEERIS enables ERI national administrators to configure their national reporting requirements based on the requirements of the respective national and international legislation using an extended pool of data that is used in Electronic Reporting and mapped with all standardized or specified ERI messages.

Fig. 4.

Configuration dashboard enabling competent national administrators to configure national reporting obligations.

The configuration of reporting requirements includes a number of steps. In a first step the reporting rules and legal provision are defined. The geographical scope of a reporting requirement is determined by a configured polygon area (see Fig. 4). For reports that are triggered by entering a specific area ETA time triggers can be defined determining e.g. how many hours before entering/navigating in a specific a specified area reports must be submitted to the receiving authorities. Different types of reporting requirements reflect the nature of and processes behind a reporting requirement as arriving to a port or navigating in a specific area. The configuration of receiving authorities allows to set individual permissions for different types of receiving authorities (e.g. response permissions, update actual times permission, issue permit permission) and additional configure e-mail notifications with different reports formats attached (e.g. PDF, XML or graphical templates which appear identical to existing paper forms). In order to account for various different obligation types transport matching criteria are used to determine the transport type affected by an obligation (cargo, dangerous cargo, passenger transports), the travel type (domestic, international, both) and vessel specific criteria (e.g. LNG). In the main configuration steps the data fields required by an obligation are assigned. The reporting data pool is divided into logical groups aligned the ERI messages. Required fields are selected by a checkbox and can either be set to mandatory or optional. Furthermore, more detailed information for a data item can be added as well as links to reference specifications.

Fig. 5.

Service providing an overview of reporting requirements along a specified route.

As a result, the requirements finder service provides information about mandatory and voluntary reporting requirements, reporting requirement type, receiving authorities and data requirements of a reporting requirement along the route of a specific voyage to reporting parties such as skippers (see Fig. 5). Filters support the user in identifying requirements that are related to a specific authority, country, transport level, transport type or reporting requirement type. The user is enabled to retrace which authority receives which data based on which legal basis including rules and conditions for reporting. External systems can retrieve an overview of all configured reporting requirements using the web service infrastructure.

4.2 Electronic Reporting Services for Users

CEERIS enables users registered in EuRIS with approved ownership rights for a vessel or granted reporting rights to access the platform to fulfil reporting obligations for their transports and interact with the receiving authorities. The retrieval of applicable reporting obligations for a planned transport starts with the entry of the route (departure, destination and route points) including estimated departure and arrival times (see Fig. 6). A transport plan can contain multiple voyages which are defined by events such as loading or unloading of goods or passenger movements and entail a change of data. Based on the provided voyage data route calculations are derived from the EuRIS platform using a dedicated webservice. By further defining the transport characteristics, the reporting obligation derived for a route are matched to a specific transport (e.g. transport of dangerous goods). Users receive a graphical (map with their voyages and requirements) and tabular overview of reporting obligations applicable for their voyages as shown in Fig. 8 and are enabled to obtain details on receiving authorities and the data submitted to these authorities. In order to guarantee data sovereignty users can optout individual requirements and fulfil obligations by conventional means. After confirmation of the reporting request, the reporting workflow is started. The overall design principle of “reporting only once with single entry of data” ensures that skippers or fleet operators have to fill-in all data only once, even if the related data field is required by different authorities in different countries and different reporting obligations. The system takes care of creating the individual reports and providing them to the related Receiving Authorities (reporting only once).

Fig. 6.

Entry of departure, destination and route points including ETD and ETA for transport plans supporting multiple voyages with cargo discharge in between.

Fig. 7.

Reporting GUI supporting users to fulfill all reporting requirement only once with single entry of data

Fig. 8.

Overview of reporting requirements and authorities for a specific route fulfilling the set transport matching criteria.

Based on smart data copy functions, the system allows users to complete or adapt only the part of the dataset that was changed by an intervening event. Data entry is supported by extended ERI reference data, which have been translated into all languages of the participating authorities. These reference data also include a mapping between different codes and classifications such as HS, NST and ADN. The entry starts a search query where all codes and names in the reference database are queried. Based on the selection of the user, all mapped data elements are assigned for a report reducing the number of reporting fields for reporting parties. This principle is also applied for locations where based on the assignment of an ISRS code further locations attributes such as hectometre, terminal name and location name are filled-in. By creating favourites for data sets on the main vessel, additional barges, parties such as the vessel operator, agents and invoicing parties, the reporting process can be conducted in increasingly shorter time spans. Additional documents such as certificates can be transmitted to authorities as attachments. During the fill-in workflow users are guided through the data groups via a navigation bar and continuously receive an overview of the overall reporting progress and status (see Fig. 7). Before reports are submitted, the user receives an overview of all created reports and data fields as well as the related receiving authorities to ensure full transparency of the process. After the handover of the dataset, the status per report (missing, prepared and sent) and authorities can be monitored under the respective voyage (see Fig. 9). This also includes the authority responses (pending, rejected or approved) as presented in Fig. 10.

Fig. 9.

Overview of all voyages assigned to a transport plan including response status, response details, ETA

Fig. 10.

Overview and details of authority responses on submitted reports.

Before the submission the status is indicated as draft and is changed to awaiting immediately after the submission. The data provided for a transport plan can be updated at any time by the vessel owner or 3^rd party which has been granted reporting rights. Updates are highlighted both for the reporting party as well as for the receiving authority. Voyages can further be cancelled and discarded after cancellation. The reporting process for passenger vessels is facilitated by an excel import feature that support the import of long passenger list generated by inhouse solutions. Users as skippers or fleet operators can evaluate and export their data for the purpose of statistics and derive e.g. quarterly reports to Statistics authorities.

4.3 Services for 3^rd Parties as Logistics

In addition to granting reporting rights for a vessel, vessel owners have the possibility to grant logistics users access to the voyage and transport information for their vessel in EuRIS either for an individual voyage or a certain time period or even unlimited. This allows logistic users to query and track the current position data of the vessel and transport information based on the ERI messages transmitted toward the EuRIS platform, depending on the granted privacy class. As presented in Fig. 11 the available information is grouped into general information including loaded cargo, transport information as transport mode and transport dimensions, hull information (e.g. hull type) as well as travel plan and position information including ETA, ETD, ATA and ATD for the route. In the notification centre user can subscribe for specific events related to authorized vessels. These events comprise the receiving of ERI messages, ETA changes, stationary situations, the passage of bridges and locks as well as the arrival and departure at berths.

Fig. 11.

Voyage and transport information for 3rd parties as logistics operators based on access rights in the EuRIS platform.

4.4 Receiving Authority Services

Implemented CEERIS receiving authority services aim at providing information to competent receiving authorities via a platform with a central access point enabling them to increase the efficiency of their task and thereby reducing the waiting times for users. The receiving authorities only have access to those data fields covered by their legal basis. The delivery and notification of the receipt of reports at the configured time are based on the respective authority needs and can be accessed either via the dashboard, email notification with report attachments as PDF or XML, webhook notifications or XML via API. In order to be able to support a broad variety of receiving authorities (traffic management, port authorities, statistics, customs and boarder police) also in making use of their inhouse systems and to be able to cover all data needs, the ERI data pool was extended. Furthermore, missing XSDs in the thematic area of customs (CUSCAR), waste (WASDIS) and ship stores (INVRPT) were implemented in addition to amendment of the existing specifications of standardized ERI messages as ERINOT for cargo and dangerous goods, ERIVOY for voyage information and PAXLST for passenger, crew and stowaway reporting. This will enable economic operators to cover the reporting of bill of lading, inland waterway BL and cargo manifest by electronic means in the future. The receiving authority dashboard (see Fig. 13) enables authority users to get an overview of all voyages and reports impacting the authority based on their area of competence and the applicable transport matching criteria. All details of a received report can be inspected and evaluated. Under the management features, user can react on the received report by either approving the report, requesting additional information or rejecting the report. Responses can further be shared together with additional notes with the other receiving authorities belonging to the same reporting requirement (see Fig. 12). In the response message ERIRSP error codes indicate different error types and additional explanations can be provided as free text. Based on national requirements authorities may receive a permission to update actual times and reported data. Access to position information can be configured for individual authorities within their area of responsibility and their legal mandate. Furthermore, reports can be exported in PDF, graphical templates, XML. All reports are anonymized after a maximum storage duration of 30 days and available for statistical evaluations.

Fig. 12.

Authority response service

Fig. 13.

Receiving authority dashboard providing an overview of reports submitted to a specific authority containing data based on the respective national legislation supporting the management of all received reports.

5 Conclusions

The CEERIS system will be released in June 2022 and pursues the goal of gradually reducing existing reporting burdens with an increasing number of participating receiving authorities in the CEE region in the future. This conference contribution will introduce the implemented novel system architecture and highlight benefits for different stakeholders together with further future development possibilities.