Belgian Maritime Incident Management
The Maritime Rescue and Coordination Center (MRCC) is the first point of contact for incidents at sea involving vessels or persons in distress, for lost and found objects, for pollution at sea and for other incidents and accidents. The today’s ICT application did not answer its needs for monitoring maritime safety, coordinating SAR activities, deploying resources and reporting about and evaluating its activities.
MRCC manages different incident types. MRCC coordinates first search and rescue actions and only secondly fulfils its reporting obligation. Information about these incidents must be submitted to SafeSeaNet in order to facilitate international cooperation, an obligation as regulated by European legal instruments. Other information must also be shared with Belgian coast guard partners. And information about ships, voyage, cargo, dangerous and polluting goods, and people on board is reported to the Belgian Maritime Single Window based upon the Reporting Facilities Directive.
The challenge was to define a solution architecture which supports operational processes by making maximum use of available data and which supports reporting by making maximum use of operational data captured during the management of the incident. And taking into account a clear distinction between operational and reporting data.
Action
Incident management was discussed with the different parties (MRCC, SafeSeaNet national authority, VTS authority, Shipping Assistance Division, and external parties). The resulted has been the “System Requirements Specification (SRS) Incident Management” document stipulating the requirements of an incident management system. In first instance focus is on the business processes of Shipping Assistance Division. Key elements described in the SRS document are:
- Data requirements, in order to have clear definitions for all 33 (sometimes grouped) incident types, such as:
- a data model and a simplified entity relationship diagram
- a data dictionary defining all data for all incident types, categorized in 5 groups: transactional, master, reference, reporting, temporary and configuration data;
- inventory of data, such as wind parks, pipelines, cables, and search and rescue unit
- inventory of reference data, such as type of rescue equipment and pyrotechnic equipment
- inventory of focal points, being things operators should think about when managing an incident.
- User interface requirements, in order to make it easy to use, such as:
- clear data management for different incident types
- clear data management for different phases of incidents (intake, management, reporting, evaluation)
- usability requirements, such as “multi multi’s” (such as, multi-incident meaning one user can work on more than one incident at the same time and multi-user defined as more than one person can work on the same incident
- Defining user interface behaviour rules
- Defining user interface control meanings
- Snapshot mode enabling “data picture taking” at key moments of the incident
- System requirements, in order to make the system work as stand alone and connected to database
- Stand-alone working modus without connection to the database
- Smooth and conflictless “connection” of stand-alone to database
- Behaviour, in order to have good user hygiene influencing the quality of the data
- List of use cases structured in logical use case classes (such as manage a new incidents for different main categories of incidents such as vessel, people, object and structure type of incidents, or coordinate search and rescue actions such as firefighting actions and deployment of search and rescue units, or retrieve on board information on ship, voyage, contact, dangerous goods and people from the central broker system)
- Possibility to group incidents (such as collision followed by fire)
- Administrative parameters and managing the incident status, user interface behaviour, type user access rights…
- Monitoring of data quality, statistical reporting, logging and audit trail
- Training requirements, in order to keep all concerned informed
Results
- Establishment of SRS document
- Open Item List or action plan for issue resolution
- Phased implementation plan
