Navigation path

DIGIT - Common Information Sharing Environment

2.5/5 | 8 votes

DIGIT - Common Information Sharing Environment - CISE Incubator

1/5 | 2 votes |


One of the main outputs of the Cooperation Project, namely Work Package 5 (WP5), was the definition of the CISE data model and specifications of the services to be offered by CISE in its initial release. Once translated into implementations, these services should enable different authorities to exchange information in an interoperable way. To verify that the specifications resulting from the Cooperation Project are suited for implementation, the implementations of these specifications will be tested based on predefined usage scenarios, similar to real-life events, or general statements about the safety or the performance of CISE. By doing so, it should be possible to check if the specifications can realistically be implemented into existing systems of different nature in the Member States. If the specifications would be insufficient to implement the services, the required changes can be identified.


If participants wants to exchange information based on the CISE information services with other CISE participants, an implementation of the CISE specifications is required. By implementing the CISE specifications, CISE information services can be offered and consumed. An implementation of the CISE specifications which exposes services to other CISE participants, is considered a CISE nodeDepending on the context of the CISE particpants, different types of CISE Nodes can be deployed:

  • Sectorial CISE Node: The CISE participants is a sectorial participant in a Member State with its respective authority systems (one or more). The CISE sectorial node will be responsible for managing the the communication with the different authority system on one side and with other CISE nodes on the other side. From a CISE perspective, the Sectorial CISE Node acts as an access point for all the connected authority systems in that sector. 



  • National CISE Node: In this scenario, only one CISE node is deployed in a Member State, the National CISE Node. This National CISE node will provide CISE services based on the different information systems in the Member State. 

Depending on the Member State or Sectorial context, different options exist for connecting a CISE node to the existing authority systems:

    • Option 1: The CISE node gathers data from the different authority systems and offers its CISE services based on this data. This means that both the data and the logic for implementing the CISE services will be part of the CISE node.
    • Option 2: As an alternative, the data of the existing authority systems will not be kept in the CISE Node. In this case, the CISE node will be responsible for the the reception and transmission of CISE service related messages between from and to other CISE nodes. Internally, the CISE node will have to transfer and translate the message to the different authority systems.
    • Option 3: A hybrid implementation which combines the techniques of Option 1 and Option 2 can also be selected.

CISE Incubator


To answer the request from the Member States, the Commission has reflected on the best possible approach for launching a Incubator, which takes into consideration: 1) the current and future activities for establishing CISE, 2) the results of the Cooperation Project and 3) the preparation of the POV.

The Commission reached the conclusion that the Incubator should test the feasibility to implement a CISE service on different systems in different Member States. This service will have to comply with the specifications developed by the Cooperation Project. Every service implementation will be tested using a predefined set of test scenarios. Based on the results of the Incubator, lessons will be drawn for the future steps in the establishment of CISE. Based on these same results, the services’ specifications will be further refined after the completion of the Incubator. Both results will help to pave the way for the POV.

The activities to be performed as part of the Incubator will be split between the participating Member States and the Commission. Member States will focus on: 1) the selection, 2) implementation and 3) testing of a service while the Commission takes up the role of facilitator.

More information about the CISE Incubator can be found in the concept paper.


The CISE Incubtoar has the following objectives:

  • Increase stakeholder engagement
    By launching the Incubator, the Member States will be able to work in close collaboration with the Commission and will be able to provide valuable input for the finalisation of the specifications of CISE’s services.
  • Validate the feasibility of implementing a CISE service
    One of the key inputs for the Incubator will be the services’ specifications developed by the Cooperation Project. The Incubator will test the feasibility of implementing these services so that possible issues are identified and resolved before the start of the POV.
  • Draw lessons for future implementation and pave the way for the POV
    By coordinating the entire implementation process, collaborating with the participating Member States and by gathering feedback during the different stages of the process, the participating Member States and the Commission will be able to draw important lessons for the next steps. These lessons should serve as an input to the upcoming Pre-Operational Validation (POV) project and for the refinement of CISE’s requirements.

Incubator Services

As part of the Incubator, different types of services have been made available. These services can be grouped into different categories:

  • Ping service: The purpose of this service is to verify if a CISE participating node is available
  • Echo service: The purpose of this service is to send a dummy (echo) request to a CISE node and receive a dummy (echo) response
  • Entity services: The entity services are developed based on the different entities of the CISE data model as developed in work package 5 of the Cooperation Project ( The current version of the Incuator only supports Vessel, Anomaly, Document, Aircraft, Operational Asset, Risk, Maritime Safety Incident  and Location entities and offers the following operations:
    • Query: Through the query service, entities can be requested based on a filter object. The filter object currently has the same attributes as the actual entity object and will serve as a template for entity retrieval.

      Result: The result of the find service will be a list of internal identifiers. These identifiers should allow the unique retrieval of the entity upon request. Besides the internal identifiers, a limited set of information about the entity is available.

      SOAP operations: For each entity, the find operation can be called using the SOAP operation called ENTITY_NAMEQueryRequest (e.g. VesselQueryRequest, OperationalAssetQueryRequest). The body of such a get request, is an entity filter (e.g. VesselFilter, OperationalAssetFilter). The result of the get request, is a ENTITY_NAMEQueryResponse (e.g. VesselQueryResponse, OperationalAssetQueryResponse) containing a list of identifier. The current implementation of the incubator, considers each of the attributes specified in the entity fitler as part of an AND query. This means that the result of the get request, will be a list of identifiers of data entities which match each of the specified attributes.

    • Get:Based on the internal identifiers delivered by the find operation, detailed information about specific entities can be requested through the get operation. Detailed information can be requested for one entity at the time.

      Results: As a result detailed information of the entity corresponding to the internal identifier will be provided. 

      SOAP operations: The Get operations allow the retrieval of detailed information about an entity based on a specified identifier. In general, this identifier will be the results of the previous Query operation. For each entity, a SOAP operation ENTITY_NAMEGetRequest (e.g. VesselGetRequest, OperationalAssetGetRequest) is available. The body of the request message only contains the identifer of the data entity for which the detailed information is requested. The result is a ENTITY_NAMEGetResponse (e.g. VesselGetResponse, OperationalAssetResponse) containing an entity object.

    • QueryDetails: Through the query details service, entities can be requested based on a filter object. The filter object currently has the same attributes as the actual entity object and will serve as a template for entity retrieval.

      Result: As a result detailed information of the entity corresponding to the internal identifier will be provided.

      SOAP operations: The soap operations for the query details service use the same attributes as the query request and the get response. This means that no intermediate step (based on identifiers) is required to get the detailed entity information. The operations availale for the query details service are ENTITY_NAMEQueryDetailsRequest (e.g. VesselQueryDetailsRequest, OperationalAssetQueryDetailsRequest) with a filter in the message body and the ENTITY_NAMEQueryDetailsResponse (e.g. VesselQueryDetailsResponse, OperationalAssetQueryDetailsResponse) with a set of detailed data entities.

  • Notification services: The current version of the notification service, enables the exchange of notification messages based on a multicast push message exchange pattern. This means that a CISE node will store a subscription list, containing a list of subscribed nodes as well as their topics of interest.

    Notification messages can be published by a provider through the notificationRequest operation for general notifications or through specific operations for different entities called ENTITY_NAMENotificationRequest (e.g. VesselNotificationRequest, OperationalAssetNotificationRequest) . The incubator will - based on a subscription list - dispatch the message to the relevant destinations. A notification message is composed of a message payload and one or more topics. Topics consists of a selector which represents the topic category and the value for that topic category. Both, the selector and the value, are free text fields with no predefined values.

NOTE: The different data entities in the CISE datamodel have relationships that link them together. As part of the incubator, the following relationships have been implemented:

  • Object involvement in Location
  • Object involvement in Event
  • Object involvement in Risk
  • Event involvement in Location
  • Location described by Document
  • Object described by Document

Each of these relationships is available for information exchange through a set of SOAP operations. Unlike the entity operations, only 2 sets of operations are available for these relationships:

  • Query (e.g. ObjectInvolvementInLocationQueryRequest/Response): These operations behave like the query details operations available for data entities. The currently implemented relationship services are based on abstract data entities (e.g. Object is the parent of Vessel and Aircraft). It is however possible to make more specific queries by adding the specific data entity to the filter object. This means that an ObjectInvolvementInLocationFilter which contains a Vessel entity as Object, would only query on Vessels.
  • Notification (e.g. ObjectInvolvementInLocationNotification): This operation works in the same way as the notifications for data entities. A notifiation about a relationship can contain the 2 involved data entities (e.g. Vessel and Event) and an entity describing the relationship.


Notification service functionality

When the CISE incubator starts up, it will initiate all subscribers from the table TA_SUBSCRIPTIONS. It is in this table that subscriptions should be added, modified or removed. This table contains a "HOST_NAME" and "SELECTOR" field. The "HOST_NAME" represents the address of the subscriber whereas the "SELECTOR" is a string in the form of "SELECTOR = VALUE". This means that whenever a notification message is published, the incubator will evaluate whether this selector string matches with one of the topics of the message. If true, the message is sent to the corresponding destination URL specified in the "HOST_NAME" field of the TA_SUBSCRIPTION table. 

The following picture provides an example of a notification scenario.

1. A notification message is sent with the following topics: WHEATHER = SUNNY and FIRE = ONGOING;
2. The CISE incubator queries the database for subscriptions on one of these topics and retrieves the corresponding hostnames;
3. The message is dispatched to gateway X and Y.

The same concept is explained in the following sequence diagram:

A general overview of the Incubator is represented below:  






Process flow

The diagram below shows the messaging flow to request and get data from another entity.




The full CISE data model was created as part of WP5 of the Cooperation Project ( A subset of this data model will be used during the CISE incubator project. The idea is to start simple with one central entity (Vessel) and extend the model during the different iterations of the incubator. The data model used by the incubator will be referred to as the incubator data model.

The current version of the incubator data model is based on the Vessel, Anomaly and Location entities.


A vessel is an extension of the abstract Vehicle object which again extends the abstract Object object. In order to keep the incubator data model as simple as possible in its initial stage, the following relationships between Object/Vehicle/Vessel and other entities have been removed:

  • Agent
  • Metadata
  • Object

The different Period attributes and the Object involvement in Location and Anomaly relationships have been kept in order to test the modelling of a relationship and the usage of attribute objects. In addition, all related enumerations have also been kept: 

  • Enumeration NavigationalStatusType
  • Enumeration SensorType
  • Enumeration SanitaryMeasureType
  • Enumeration FishingGearType
  • Enumeration HullMaterialType
  • Enumeration ConditionOfTheCargoAndBallastType
  • Enumeration PlacementProcessType
  • Enumeration INFClassType
  • Enumeration INFClassType
  • Enumeration VesselType
  • Enumeration ShipConfigurationType
  • Enumeration ISPSSecurityLevelType

The diagram below represents the "Vessel" data entity and the associated attributes.



The class Aircraft is a sub-class of the class Vehicle. Aircraft has the same associations and relationships than its parent-classes Vehicle and Object. Thus it can have relationship with Document, Risk, Event, Location, and Agent. 


Anomaly & Incident

An Anomaly or an Incident is an extension of the abstract Event object. In order to keep the incubator data model as simple as possible in its initial stage, the following relationships between Event/Anomaly and other entities have been removed:

  • Event
  • Agent
  • Location
  • Metadata

The different Period attributes and the Event involvement in Object relationships have been kept in order to test the modelling of a relationship and the usage of attribute objects. In addition, all related enumerations have also been kept: 

  • ObjectRoleInEventType
  • NatureType
  • AnomalyType

The class "Incident" has a sub-class "MaritimeSafetyIncident" which is used to determine types of incidents related to maritime safety as defined by the SafeSeaNet project


The diagram below represents the "Anomaly" and "Incident" data entities and the associated attributes.




A Location is a separate entity which is realted to many other entities in the data model. Within the scope of the incubator, only the relationship between Locations and Objects has been included in the data model. A location is also related to the following attribute entities:

  • Geometry
  • MeteoOceanographicCondition

The different related enumerations have been kept:

  • WeatherCondition
  • OperationalPurpose
  • Metoc
  • LocationZone
  • LocationQualitativeAccuracy

The diagram below represents the "Location" entity and the associated entities and attributes.




Document is one of the fundamental entities of the overall data model of the information sharing environment. A Document allows tracing and exchanging information in a persistent manner in almost any possible electronic format; this information is expected to provide details on and express specific associations between other Entity Classes such as Agents, Objects, Events, Risks, Locations etc.In particular, the class "LocationDocument" is a sub-class allows the identification and exchange of Location related documents and material in electronic format.
The diagram below depicts the class "Document" and its sub-class "LocationDocument" :
The classes "LocationDescribedByDocument" and "ObjectDescribedByDocument" are used to describe the associations document-location and document-object. The diagram below depicts these associations:

Operational Asset

An Operational Asset is an Object (in particular means of observation or transportation, but also including associated sensors, means of communication and means of intervention such as deterrence or neutralization of threats, fire fighting, pollution containment etc.) enabling operational Actions (most often at sea or on sea shores) of the Agents mandated by public Organizations in charge of Maritime Safety and Security.
The diagram below represents the class"Operational Asset":



Risk is used to represent a more or less probable situation involving exposure to danger concerning the maritime domain. The notion of risk is usually very subjective and, in a first step, we decided to keep the definition of the class simple in order to ease its adoption. Further work could be used to detail the risk definition and introduce metrics regarding probability and severity.
The diagram below depicts the class "Risk" :

Main relationships 

The relationships between the "Object" class and "Event" and "Location" entities have been identified in two specific entities represented on the diagram below:


The currently implemented relationships in the data model used in the incubator are summarized in the image below:



Next Steps

After the implementation and testing activities, the Commission will process the provided test results and feedback from the participating Member States and update the service specifications. Finally, the Commission will write conclusions and recommendations for the future steps in the definition of CISE.


The agenda, status and responsabilities attribution for the iterative tasks are available here: