Standard IEC 61174 ed 4 needs to complemented with a format for the exchange of a route segment in AIS ASM compatible format.

Add procedure in IALA VTS operating procedures

Specification and standard of the initial Voyage object.

Directive 2010/65/EU of the European Parliament and the Council Decision of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States and repealing Directive 2002/6/EC: It should be noted that this Directive aims to simplify and harmonise the administrative procedures applied to maritime transport by establishing a standard electronic transmission of information and by rationalising reporting formalities for ships arriving in and ships departing from European Union (EU) ports. EU countries shall accept electronic reports via a single window as soon as possible and, at the latest, by 1 June 2015. The single window will be the place where all information is reported once and made available to various competent authorities and the EU countries. EU countries must ensure that information received in accordance with reporting formalities is made available in their national SafeSeaNet systems and make available parts of such information to other EU countries via the SafeSeaNet system.

The establishment of SeaSWIM has to address the creation of an appropriate organisational structure for the implementation and operation SeaSWIM; legal basis for the implementation of SeaSWIM would be made possible by the Rule Book or the SeaSWIM contract. The Rule Book would ensure a clear environment ensuring the trust of the involved stakeholders.

IMO Convention provisions tailored to accommodate the new concepts, namely SOLAS Reg V/28+ IMO FAL convention.

Port call synchronization and green / right steaming requires a change in existing contract templates (charter parties) providing incentives for just-in-time approaches and establishing / communicating / committing to port of readiness.

A standardised port call format is to be established supporting the ship-to-shore, shore-to-ship, and shore-to-shore interaction supporting port call synchronization.

This is a new area that needs to be specified
Could be part of IHO S 121

Functional requirement for displaying safety information

A liability regime, possibly through a contractual arrangement, needs to be established. The liability questions is anticipated to be similar to liability issues for existing VTS and pilotage services.

Private service providers with high navigational competence in certain areas, like pilot organisations, are the most logical new actors that can offer different kinds of shorebased assistance. It can be mandatory assistance issued by NCA or additional navigational assistance services provided on commercial basis.

A generic definition of important states to coordinate in enabling the efficient port approach.

A port maturity model for evaluating the efficiency of a port including a measurement system covering which variables to measure is needed for governing the improvement processes.

Incentives for sharing information objects need to be identified

A common defined model for the port call process serves the basis for reflection about performance. A generic model for the port call process is used as a basis for instantiation serving as an important input for EN-101.

The standard is a subset of the Voyage Information format standard. Covers all facts and specefications of the vessel needed for carrying out STM services (e.g Voyage Optimisation, Port call Synchronisation, etc). Exisisting services like Q88.com, SIRE, FairPlay.

Nautical information of an area should be available in a standard format. Today, it is in paper form or not standard format.

All manufacturers of ECDIS and NAV systems have their own format elaborating and presenting routes. In order to eliminate errors and misinterpretations a new standardized format (IEC 61174 ed 4) has been developed within the Monalisa Project and can now freely be used by any vendor.

Definition of roles, consider VTS TOS

Establish organisation that will have the overall responsibility of governing voyage IDs from time of registering the voyage till the end of that voyage.

The establishment of SeaSWIM has to address the creation of an appropriate organisational structure for the implementation and operation of SeaSWIM function. Careful consideration must be given regarding the SeaSWIM organisation’s mission, actions, structure and performance. All the indicated aspects are important for the organisation to be viewed as trustworthy and reliable, which contribute to it being accorded legitimacy for it to be trusted by businesses and authority.

Quality standards indicating requirements, specifications, guidelines or characteristics must be identified to ensure that the SeaSWIM services are fit for each of their purpose. Such standards are generally referred to as the evaluative standards that enable the users to assess service providers and their service quality. The discussion on quality standards also leads to the process of certification that is used to demonstrate compliance with the standards. It has been defined as �the successful conclusion of a procedure to evaluate whether or not an activity actually meets a set of requirements�. Certification simply refers to quality assurance which can either be provided by the service provider itself or by an assessment by a third party.

The specification of SeaSWIM services, core and STM-compliant services, builds upon a standardized service specification language. The language constitutes the ontology of how to describe a service.

Guidelines for liability and responsibility to ensure voyage information correctness need to be established. The source of voyage information, and thereby the one that regulates the management of voyage information by others, is the shipping company. The shipping company is the owner of voyage information why there needs to be routines established to ensure that the information associated with the voyage is managed in a correct way (see EN-109).

IMO to issue standards for this cross-check protocol and to be implemented in IMO 893(21).

Several risks arise from STM operation such as data breaches; data processing errors etc. and these risks should not be underestimated. Legal liability can arise in several areas in context of these risks connected to the STM operations. It is important to note liability issues are important for the creation of legal infrastructure of the STM. The agreements between the service providers and end users should regulate the liability issues which could include provisions for the limitation of liability, identification of dispute resolution mechanism etc.

Develop a standard framework for the information elements in the voyage object (plan).

All the information related to a ships voyage e.g. route, cargo, next port of call etc needs to be standardized.

A common standard for time stamps (ETA, ETD, ETB etc.) is approved by the international maritime community.

Dynamic separation of traffic, when traffic density is low and safety precautions allows it, requires revision of IMO regulations for TSS and possibly other ships routeing sytems

Established federation for the definition of which data to share and to quality assure that information sharing is made in a trustworthy way,

In STM there will be information services that continually provide with information reaching a certain set of criteria. Methods for accessing such services, that either could be provided by the information owner or by a third-party actor, is defined by this enabler.

Establish procedures and rules for creating, updating and exchange of voyage information.

Guideline, procedures and criterias needs to be developed with regards to number of waypoints to be exchanged, etc. The procedures and criterias needs to tested and validated in testbeds and simulator trials.

Create processes to maintain data up to date. Procedure to allow automatic, semi automatic or manual reporting (selected by the operator).

Route exchange acceptance as alternative to VHF-based ship reporting

Based on the generic state chart the definition of different variances of processes for the particular port needs to be defined in order to identify which information object that are relevant to be shared.

New technical function needed, standard needed

Add procedure in IALA VTS operating procedures

Generic procedures for evaluation to be used for each actor is defined for supporting them to perform evaluations of their role in conducted port calls.

As an important source for ports with its actors to improve is to look upon other actors performance. Guidelines for evaluation covering what to look upon are therefore needed enabling ports to compare data with each other.

Procedures for onboard, shore and ship shore interaction. Use and update IALA VTS TOS procedures

The identity registry needs to be structured in accordance with actor characteristics. The role of a certain actors in the Sea Traffic Management ecosystem forms the basis of such characterization (as e.g. port, port actor, etc.) and then further appropriate specialisations.

Analysis of new possibilities for statistics with more information

A commonly accepted process for including a service in the service registry of a particular service as it has been approved for being provided in the STM eco-system.

Develop procedures and rules on how to issue and use Voyage ID�s.

Procedures and rules for EN-134 as well as regulating the use of voyage IDs (such as e.g. for how long voyage ID�s should be possible to access after the voyage has been conducted).

Services constitute the core of the service-oriented-architecture applied in SeaSWIM allowing possible [peer-to-peer] interactions between information providers and information consumers. In order to allow for the provisioning and consumption of services, as carriers of the information being exchanged/shared, processes/procedures of how to publish and discover services need to be defined (as e.g. how does the process look for including a service in the service registry and for discovering a particular service).

In order to allow changes of the service specification language and keep the language up-to-date, there has to be processes/procedures for how to change the service specification language

For each area of operations, i.e. in the coverage of the different concepts, there needs to be service approval processes established in which proposed services need to be met by certain criteria agreed among the members of the federation (such as the Port CDM council).

Established routines for how to feedback reviews, based primarily on use, to the service provider

In order to drive continual quality development and continuous improvement of services there will be tools associated with STM that allow for validating/assessing the used services. This both concern the possibility for �letting the crowd� give their remarks on used services as well as statistics for usage. The result of the validation is an important input for the process of improving existing services (service lifecycle management) by the service provider.

Establishing a set of specefications of how SeaSWIM enabled information services shall perform, in order to qualify as SeaSWIM service (availability, performance, data quality etc).

Procedural templates for organsations, system users, informaiton providers, service providers of SeaSWIM enabled infroamtion services, in how information can be shared in SeaSWIM informaiton sharing environment.

Route cross-check is a new service made possible by route exchange and new procedures for ship and shore interaction is needed.

Training in procedures for monitoring actual against planned route and establish roles and responsibilities concerning route proposals to ship.

To be part of IMO STCW and detailed in IMO model course for deck officers at operational level.

New roles or organisations providing shore based assistance (e.g. VTS) or monitoring services.

Consider to be part of IMO STCW and detailed in IMO model course for deck officers at operational level.

Consider Human factor effects of added information in ECDIS
All information should not be displayed on the ECDIS screen

Standards simply indicate how things should be done and they have significant consequences for all stakeholders. The process of standard making is important and it must reflect the choices by industry. In addition, standards should be flexible enough to appeal to the wider community and not only to certain stakeholders. Connected to this is also the process of their development and the consideration of the organisation through which the standards will be developed.

Making the systems STM compliant.

Access rights to information services is designed so that the information owner can assign rights to segments (and parts of segments) of the information object, using templates for different actor categories. E.g. an appointed agent for a certain port call of the voyage, shall have access to the route-segments from the prior port to the actual port.)

Introduce standards for implementing connectors to existing systems to allow services of STM to access and distribute voyage information to/from different systems

Technologies enabling continuous updates on ETA and Port of Readiness (e.g. estimated, requested, confirmed, committed and actual times)

Functionality in SeaSwim (connectors) to add option of Auto-nomination of geo-location based actors (e.g. VTS, Ports, SRS, reporting areas).

The port call optimization service will provide statistics and performance measures for the port for internal use. This enabler is an information service accessible to other actors retrieving a standardized set of performance measures describing the port (potentially to be used for assessing the port�s performance in accordance with the Port Maturity Model).

A generic public-key-infrastructure provided by SewSwim (implemented in the SeaSwim connector), ensuring the identity of the information requester/publisher so that the information owner/consumer do not have to provide any information security measures other those prescribed/implemented in the SeaSwim connector.

The identity registry need to be kept up-to-date and have such a status that it becomes used. This requires services for provisioning and consuming actor identities. To identify and qualify a certain actor as an identity in the identity registry existing registries, as managed by diverse associations, forms an important basis.

In order to access information services there is a need for SeaSWIM connectors. The allowance of accessing these do however need to be done by (electronically) ask the information provider whether the information service is allowed to be accessed by checking the nomination schema. For each connector such access verification module need to be implemented according to the standards for access management.

A framework supporting the implementation of SeaSWIM access management for SeaSWIM enabled information services (who, what, when, with what usage rights)

A list of what information services (types) are available in SeaSWIM

A generic functionality in SeaSwim enabling the discovery of a service as the carrier of the information that is requested. E.g a port will be able through its SeaSwim connector, subscribe for VoyageID�s with planned destination to the port, without knowing anything about logical or physical address where the information can be retrieved. That information is provided by the service discovery mechanism.

An univeseral service registry provides a list of all services possible to access when certain criteria are met � such as e.g. geographical region.

The commonly accepted information model describing all used information objects of STM, the parts of which the object consists, and the elements specified in those parts. A logical model, not a technical.

The description of any SeaSwim governed information service, covering technical, logical, description of requirements, service level and other delimiting characteristics.

The identity registry constitute one of the core enablers in the information sharing environment. High accessability is therefore required enabled by a good technical infrastructure.

The system needs to keep track of contract that regulates the possibility to use performance data (estimates and actuals) for evaluation purposes

Real time and historical data extraction from actors port community systems.
Enabled tracking of historical state changes. Connectors to existing systems necessary or more data generated manually requiring good interfaces.

When a Port Actor System (Agent system, port community system, Tug-operator system etc), is to be integrated with SeaSWIM, this will be done by a specified and well defined set of rules and standards, identifying with information services the actor system can (and will) support. Vendors of standard systems will develop standard connectors which can be used in every implementation of the system, whereas proprietary actor systems, will develop a dedicated SeaSWIM connector based on standardised framework, open source code or blueprints for SeaSWIM connectors.

The term Automated Single Windows refer to when the national reporting infrastructures (today referred as Single Window, NSW), have the capability to subscribe for the required information directly from SeaSwim. A route published by a ship, with a destination in any port state, would (if the option of Auto-nominate is set, give automatic notification to the NSW of the destination port state, enabling them to retrieve the information needed.

The nautical information, today broadcasted, in non-machine readable format, will be digitised in standardised formats, so that the information can be automatically imported in any bridge system supporting these standards.

Status: IHO ongoing work

Standards and technology for store/publish/share information valid for a specific area or place. There should be a possibility to match any route or location, and use as an index or key for obtaining data in the service providing the geo-located information.

The objective is to provide unique voyage identity.

The objective is to nominate and set access rights to collaborators around information object (e.g. Voyage Object).

The objective is a lifecycle approach to the facilitation of the development, publishing, maintenance, use and liquidation of services necessary for the functionality of SeaSWIM.

The objective is to provide functionality to access services and information sources based on the desires of the service provider to enable trusted information exchange.

The objective is to establish a single page for updated:
– Legal and environmental requirements,
– Nautical information, which is today contained in Pilot books,
– Environmental information e.g weather, ice, currents, tidal water, and
– Safety warning.

The objective is to enhance the situational awareness by providing surrounding vessels routes and displaying them on onboard ECDIS or shore based equipment.

A common route exchange format for route sharing between ship and shore.

A set of services within SeaSWIM or other providers will have to be developed for the full implementation of the nomination process, including automatic nomination. Geo-location of; reporting lines, regulation, entering- or leaving, depth restrictions and so on, in addition to time-regulations (ETA-dependent) will need to be established in order for the full implementation of the nomination process.

The objective is to perform enhanced traffic optimisation in restricted geographical areas with high traffic density in order to increase safety of navigation and the efficiency of ship traffic.

The objective is to provide weather information on route.

The objective is to provide information regarding a particular voyage accordance to access rights.

The objective is to coordinate and adjust actions related to other actors shared intentions and performances based on the set of states for a particular port call.