MarNIS Information brief

The MarNIS framework architecture

Rationale
The maritime sector includes national authorities, port authorities, vessel owners, captains,
providers of nautical services, etc. The objectives of MarNIS - safety, efficiency, security and
environmental protection - very much depend on interactions between these parties across
national and organisational borders. The framework architecture must therefore describe
generic solutions, which can be used in all regions of Europe and in all ports, incorporating
existing and new technologies, while respecting international regulations.
The architecture is not concerned with how the actual stakeholders are organised, as this may
vary between different regions, countries and ports. Rather, it focuses on the core
responsibilities that have to be handled everywhere, for example because of international
agreements and regulations. The architecture combines responsibilities into generic roles that
can be played by different stakeholders and organisations. The architecture also specifies the
generic tasks executed by these roles and the working procedures involving interactions
between the roles. Local working procedures, in specific ports, are not addressed.
Much of the development was based on ARKTRANS, the multimodal Norwegian framework
architecture (common to all transport modes - road, sea, rail and air). We also looked at the
COMPRIS architecture related to the inland shipping sector, and the Finnish PORTNET
initiative, in relation to specifications of reporting to authorities. The European
KAREN/FRAME initiative for road transport was also considered.

Existing architecture initiatives

+ experience from use of such Architecture activity:
architectures: Harmonize and make/update
- ARKTRANS the preliminary maritime
framework architecture
- COMPRIS architecture
- Others description

MarNIS results (deliverables etc.

from MarNIS work packages
and activities)

Work package: Architecture activity:

Evaluate and provide input Make current version of
the framework achitecture
(through discussions,
available to WPs
comments, etc.)

Figure 1 Iterative improvement process

Content
The decision to make a generic, responsibility-centred architecture influences the content of
the architecture as well as its structure. This also implies a top-down approach.
 Overall
level Reference Roles
model

Logical
level Tasks Information Processes

Technical Communication
level

Figure 2 The architecture content

The reference model

The reference model provides an overall depiction of the transport and transport sector by
dividing it into responsibility-centred domains and sub-domains. This model also simplifies
communication with stakeholders, while structuring input. It is easy to find the relevant parts
of the architecture, as each responsibility domain focuses on issues related to a limited set of
responsibilities. This makes it easy to map stakeholders, activities, products, challenges, etc.
into the reference model.
.

Figure 2 The reference model

Responsibility domains
The Maritime Transport Network Management responsibility domain focuses on how to
arrange safe, secure, environmental friendly and efficient vessel traffic. This domain is
divided into sub-domains dealing with different responsibilities:
 Maritime Transport Network Infrastructure Management: This addresses the
management of fairways, including navigation aids, and the provision of information
about fairways. (This responsibility domain is not dealt with by MarNIS);
 Maritime Transport Network Utilisation: The utilisation of the fairways and marine areas;
nautical support; and traffic management during normal and abnormal sailing conditions
are addressed (in port areas as well as at sea). This sub-domain is highly emphasized in
MarNIS and further specified in the architecture;
 Maritime Transport Policy: This focuses on the establishment of agreements, laws and
regulations for maritime traffic and transport. However, this sub-domain is not further
specified in MarNIS;
 Maritime Regulation Enforcement: The responsibilities of the authorities are addressed.
The management of safety-related information is one of the main issues addressed. This
sub-domain is emphasized in MarNIS and further specified in the architecture;
 Maritime Emergency Management: Emergency preparedness, preventive actions and the
handling of emergencies is targeted, including search and rescue, pollution response and
maritime assistance. This sub-domain is highly emphasized in MarNIS and further
specified in the architecture;
 The Transport Demand domain addresses the need for transport, the planning and
booking of transport-related services (provided by carriers and terminals) and the
management of on-going transport tasks. These aspects are to a large extent outside the
scope of MarNIS, except that this domain is the origin of cargo information.
 The Transport Service Management responsibility domain addresses the provision of
transport related services (performed by carriers, terminal operators, e.g. freight transport,
cargo handling, etc.). Bookings from the Transport demand domain are received and
handled, and the required transport related operations initiated and followed up. These
aspects are only within the scope of MarNIS to a small extent.
 The On-board Support and Control responsibility domain addresses issues on-board the
vessels. External information sources and on-board equipment provide information that
supports the transport operations as well as the operation of the vessel. Access to relevant
information combined with decision support, information management, and functionality
supporting vessel operation improve safety and efficiency. The domain is emphasized in
MarNIS and further specified in the architecture.
 The Service Management domain is responsible for the provision of services that support
maritime traffic and transport-related activities and information exchange. This sub-
domain is further specified in the architecture.

Roles
The responsibility domains and sub-domains in the reference model provide a top-level view
of the architecture. A role belongs to just one domain or sub-domain and represents a set of
responsibilities. By means of such roles we can make references to stakeholders in a generic
way and bridge problems caused by differences in European countries, regions and ports. A
stakeholder can play one or more roles and can dynamically switch between roles at any
moment. The roles are independent of organisational issues and will persist through
organisational changes.

Tasks
A role must execute one or more tasks to accomplish its responsibilities. The tasks are
described in a formal way according to the OEDA circle (Observation, Evaluation, Decision,
and Action) in Figure 3.
Situational aware ness

Evaluation Decision

Observation Action

Input Output

Maritime World
-
Figure 3 The steps of a task: Observation – Evaluation – Decision – Action
Data and information are acquired and observed. Information is put into a wider context and
evaluated. Based on the situational awareness established after this evaluation, decisions
about prospective actions are made and actions undertaken based on these decisions.

Processes
Within the context of the maritime framework architecture, a process is defined as a
collaboration of roles to achieve one or more goals. This often implies exchange of
information. The information needs and interaction requirements are analysed for each role. A
process emerges when different roles at the task level start using and providing information
from and to each other.

Role 1

Role 2

Information flow Role 3

Figure 4 The information flows between tasks executed by roles

The framework architecture has specified processes that describe the required interactions
between roles belonging to the different responsibility domains and sub-areas of the reference
model.
Information
The exchange of information is essential for coordinated actions between roles, in order to 
perform activities (see Figure 4). It is therefore essential to define the content of the 
information flows that have been identified in the respective processes. The same information
elements may be used in several information flows. This means that information exchange
can be harmonized to a greater extent than at present. The same information will always be
provided in the same way.

Communication
The information flows are specified in a way that is independent of technology. Information
may be exchanged in several ways. For selected information flows MarNIS will either specify
the technical execution using existing standards, or will identify standardisation requirements.

Usefulness of the framework architecture

Feedback received so far indicates that the usefulness of the architecture extends beyond the
MarNIS project. Maritime organisations, dealing with the definitions of operational solutions
and practices for the maritime world, will benefit from adopting the generic and location-
independent descriptions, as well as the mechanisms and methods employed.
MarNIS will lead to new concepts representing solutions and practices within the maritime
sector, for example a tighter collaboration between traffic management and emergency
management that facilitates improved safety. These concepts are being defined by means of
the architecture elements. In addition to the concepts elaborated in MarNIS, other concepts
also need more precise definition. The eMaritime and eNavigation concepts are, for example,
frequently referred to, but are not clearly defined. They can be specified by means of the
maritime framework architecture. The scope of the concepts can be indicated in the reference
model and the responsibilities and roles included in the concepts can be identified, together
with the corresponding tasks and processes.