AEGIS and the project ISTS arranged a workshop on Harmonized Ship-Shore Exchange of Administrative and Operational Data

17. March 2022

On the 8th of March 2022, the AEGIS project together with the project Intelligent Ship Transport Systems held a workshop in Oslo/Teams with the topic Harmonized Ship-Shore Exchange of Administrative and Operational Data. 20 persons attended the meeting physically while another 33 persons joined via Teams. The 14 presenters coming from Norway, Sweden, Finland and the Netherlands represent both maritime authorities, shipping lines, standardization bodies, software developers and research. The main conclusion was that the good collaboration that has started between the different stakeholders, especially through the work done by IMO on their Reference Data Model, need to be continued to address remaining tasks. Some of the issues that were raised during this session includes:

  1. Importance of defining common specifications, e.g. for identities and code lists. It is also important to define who is maintaining each identity and code list. For code lists used in the IMO reference data model (https://svn.gefeg.com/svn/IMO-Compendium/Current/index.htm), this has been clearly defined for each case.
  2. Who makes the standards? The IMO reference model is maintained by all relevant and interested standards organizations. Each organization (e.g. ISO, UNECE, WCO) defines their own technical standards for their respective domains, but the IMO reference model, which is a conceptual model, covers the intersecting parts and thus ensures interoperability in these intersections.
  3. The EU is defining its own reference model through their work on EMSWe, but parts A and B are the ones of main interest for the IMO reference model (mandated in FAL Convention – A, or European instruments – B). Part C is national specific requirements with limited harmonization due to differences in national legislation.
  4. ISO 28005-2 is a relatively flat data model and is not a traditional API. The benefit is that a single API can be used for all types of message exchanges, that data items easily can be reused from different messages that have already been sent, and that one also can implement, e.g. data pull from authorities. The drawback is that specialized APIs are easier to implement and to understand.
  5. There is an issue of data ownership that may be easier to enforce in a flat data model rather than an API.
  6. There may be a need to develop new business models to implement a higher degree of digitalization. How can this be done?
    1. New demands may require new solutions
    2. A reference architecture can better define roles than party relationships and simplify move of roles to new parties.
    3. Data ownership/governance will be an important factor.
    4. Google type solutions (“big data”) may not be appropriate for business critical data services. Data used for critical operations (e.g. invoicing) must be reliable and traceable to source.
  1. There is a need to define port area, with or without pilot boarding place. Different definitions exist.
  2. Port geographic data can be both asset oriented or navigational assistance oriented.
  3. There may be a need to harmonize S-100 operational data attributes with the IMO reference data model.
  4. European Maritime Single Window Environment will change how information is exchanged between parties in Europe. However, it is not clear how the changes will look like as there are several interfaces:
    1. Ship/agent to MSW
    2. Between MSWs in Europe
    3. Backend from MSW to parties on land
  1. EMSWe will not necessarily help non-European ships or European ship owners that operate all over the world.

Presentations from the workshop can be found here:

Agenda, Introduction, IMO, ISO, ITPCO, PortAsset, S-131, SSNN, FinnishSSN, GC, Stamford, Unikie, NCL, NAVTOR