MARINTEK

Resources

--------
Right-click your mouse over the resource and select "Save Link as..." to download.

Maritime Data Models

⇒ e-Navigation data models

⇒ IEC 61162-1 Navigational data network protocol

⇒ Trade Single Windows

⇒ Maritime Single Window and ISO 28005-2

⇒ Corrigendum to ISO 28005-2 and 28005-1

⇒ Electronic certificates

⇒ Technical Status Index - TSI

⇒ Voyage orders and reporting

⇒ References

Maritime data models are one of the components of the maritime ICT architecture. The definition of a what a data model is varies somewhat, but the basic idea is to give an (abstract) description of information elements in such a way that it can be used to effectively communicate information availability and needs between different parties. Information representation is not necessarily part of the data model itself, but the model will often be described in a way that lets it be directly implemented in some specific data storage or transfer format. This section of the MiTS pages describes some data models that have been developed for the maritime domain.

In particular, it also maintains a list of editorial issues in the ISO 28005-2 data model that has not yet been fixed in the printed version. This list is not authoritative and may not be complete, but is provided as a service to the readers. The resources section also include an XML schema representation of the ISO 28005 data model and message format, adjusted with the corrections (Rødseth Ø.J., 2011).

e-Navigation data models

In e-Navigation it has been decided to develop the CMDS (Common Maritime Data Structure) in the IHO S-100 format. S-100 is based on the ISO 19100 series of geographic information standards. While ISO 19100 is mainly intended for geospatial data, it is believed that S-100 will also be able to handle, e.g., data integration standards such as the IEC 61162-1.

IEC 61162-1 Navigational data network protocol

The IEC 61162-1 standard (IEC, 1995) defines a kind of "implicit data model" in that it contains definitions for a large number of text messages that are used to exchange data between instrumentation and computers in a navigation data network.

There are plans to make this data model explicit through a anew IEC standard that can then be aligned with new e-Navigation standards, but at time of writing, this work has not started.

Trade Single Windows

Trade single window implementations require that different parties from different parts of the world exchange information through a common gateway. This obviously requires standardization and the development of data models are part of this effort.

Currently there are at least three more or less different data models that may be of interest. The oldest and possibly still most important is the United Nations Trade Data Element Dictionary (TDED). This is the basis for the UN/CEFACT supported EDIFACT messages which also includes the ones used to implement the Maritime Single Window. TDED is also standardized as ISO 7372 (ISO, 2005). The TDED has 1083 elements and their definitions are available from the UN/ECE web pages. The TDED model is also very close to implementation as it is directly translatable to UN/EDIFACT data elements. The definition contains the unique numeric code, the name, a description, the representation (here an..25 which is alphanumeric up to 25 characters) and a note. The note may also give further references to coding system if the element is to be represented as a code value. A definition elements for a place or location element is shown below.

Code: 3225
Name: Place/location identification (E)
Desc: Identification of the name of place/location, other than 3164 City name.
Repr: an..25
Note: Use UN/ECE Recommendation No. 16: UNLOCODE. If not applicable, use appropriate
      code set in combination with 1131/3055 

The UN/CEFACT Core Components Library (CCL) could be said to be a further development of the TDED into a wider scope and with a more abstract specification. Currently, there are about 6000 elements defined in the CCL, but not all TDED elements are explicitly included. This is probably due to a more systematic approach in CCL that can represent several TDED elements in a more generalized CCL definition. The definition is also much more extensive and contains a number of fields of various function. The current CCL list can be got from the UN/ECE Repository. An example of part of a definition for a similar concept as the TDED element 3225 is shown below.

Group     : BCC
Entry name: Address. City. Identifier
Definition: The unique identifier of the city for this address, such
            as United Nations Location Code (UNLOCODE).
Class Term: Address
Prop. Term: City
Repr. Term: Identifier
TDED      : 3225

The final data model mentioned here is the WCO (World Customs Organization) data model which is currently in its third version. It is similar to the two above models and to a large degree harmonized with both. The model and associated documentation is not freely available, but can be got by contacting WCO through their WCO data model pages. The definition structure is somewhat different from the two others, but contain more or less the same information elements, including a cross reference to TDED and CCL where applicable.

Maritime Single Window and ISO 28005-2

TDED contains data elements for ship clearance into and out of port. However, they have been developed in the context of international trade and UN/EDIFACT is not always appropriate for the ship management industry. More information about this issue can be found in the Single Window section.

Through a series of EU projects, but mainly MarNIS and Efforts, a new data model for a maritime single window was researched and developed. This research started with an analysis of ship reporting requirements and state of the art within electronic port clearance. This report is included here as the EPC SoA resource (Rødseth Ø.J., de Lijster A., 2006). This work was continued with an in depth analysis of the information requirements and corresponding elements. This report is also available as the EPC Data resource (Rødseth Ø.J., de Lijster A., 2007).

This work was the basis for the development of the ISO 28005-2 (ISO, 2011) standard that was published in 2011. This standard can be got from ISO or your national standards organization. However, an XML schema file covering both the -2 and -1 parts (ISO, 2012) is available in the resources sections (Rødseth Ø.J., 2011).

Corrigendum to ISO 28005-2 and 28005-1

The following paragraphs contains notes on editorial errors in the ISO 28005 series of standards. This information is supplied as a service to the readers, but are not yet officially approved by ISO. Thus, the information is not to be considered as part of the standard. However, they will be provided to the ISO system and will eventually be accepted or rejected by ISO. At such a time, these lists will be corrected as appropriate.

The following editorial errors apply to ISO 28005-1 (Message structures). The corrections have been applied to the XSD V9 files.

  1. Clause 6.2.4 and 6.2.5: The clause should define that all XSD data block definitions should end with the XSD line "<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> to allow new elements to be added in later versions of the standard without breaking old XSD's.
  2. Clause 6.3, 6.6 and 6.7: When Table 6 and 7 are converted into an XSD file, one need to prefix local data elements such as "EPCClearanceStatusType" with "epc:", i.e., "epc:EPCClearanceStatusType".

The following editorial errors apply to ISO 28005-2 (Data model) and has been included in the XSD version 9:

  1. Clause 7.2.4: Heading should have upper case 'O' as in NameOfMasterType. The corresponding XSD entry was missing in v8. The text in the clause is wrong, it should refer to the name of the master.
  2. Clause 7.3.7: The header is wrong, it should say "DutiableCrewEffectsType" with an 's' in Effects. The XSD is right.
  3. Clause 7.6.3: The header should read "PortCallListType". PortCallsListType.
  4. Clause 7.9.8: The header and XSD should both read "CallPurposeType" instead of "CallPurpose". The "PurposeOfCall" text should read "CallPurposeCode" in all instances of the XSD (in tag and types).
  5. Clause 7.9.17: The header should read "NavigationalStatusContent" and not "Contents".
  6. Clause 7.9.24: The header should read "Communications" with an upper case 'C'.
  7. Clause 7.9.31: The header should read "WeatherInformationType" to match XSD.

We would appreciate any feedback from other users that have found other misprints in the standards. You can find our contact details on the home page.

Electronic certificates

The IMO Facilitation Committee at its 39th meeting (FAL 39 - September 2014) approved a new circular that asks member states to accept ship certificates in electronic form. Electronic certificates have become more common recently, but normally as PDF type "electronic paper". The e-Compliance project (http://www.e-compliance-project.eu/) provided an information paper through ISO to the meeting, describing how a fully electronic certificate could be implemented, based on the ISO 28005 set of standards (IMO FAL 39/INF.2 2014). This would allow fully automated processing of certificates, greatly simplifying management for issuer, operator, ship crew and inspectors.

Technical Status Index - TSI

The TSI concept was developed in the Flagship project and as a concept shall ensure that technical information from various ship sensors and subsystems and from different makers (pumps, valves, filters, motors, heaters, etc.) is available for the different technical management systems. The technical information may comprise i.e. fault reports, alarms, and status information. In a typical example a decision support system receiving an alarm from a safety critical pump shall be able to check the status of the back-up systems and group the alarm accordingly into a lower or a higher priority thus releasing the operator from further own investigation of the actual system status. A description of the concept was reported in (Rødseth Ø.J. et al, 2008).

The concept was not deployed in any actual ship, but is a component of other projects system descriptions. Annex D provides a hierarchical decomposition of ship systems and a possible starting point for the hierarchy. This is based on data provided by the author of (Vindøy, V. 2008). The model is available as a CSV file under (Vindøy, V. 2008).

Voyage orders and reporting

In the period 2007 to 2011, MARINTEK developed a system for digital communication of voyage orders and voyage status reports between fleet management operations and ships. The system was developed for the LNG trade and used a relatively complex Time Charter Party structure, similar to the ShellLNGTime format. This required among other things the development of a formal data model for the voyage description.

Voyage data model

The project developed a number of message formats related to different parts of the work process on shore and on board. The process and the reporting formats are illustrated below.

Reporting work flow

The project also developed an Excel work book for use on board the ship. This work book allowed the master to view received XML files as well as enter data for outgoing status reports. The message interface could be via e-mail or directly through http. This was the ship's "Reporting tool".

The whole work process was integrated by also representing the Time Charter Party (TCP) as an XML file, including all penalty clauses and legal exception. This was used to analyze final voyage summary reports to see the overall performance of the voyage and to determine any penalties.

More information about this project can be got by contacting the author.

References

ISO, (2005). ISO 7372:2005, Trade data interchange - Trade data elements directory. Edition 3.

Rødseth Ø.J., de Lijster A., (2006). Electronic Port Clearance: State of the Art, MarNIS Deliverable D1.3.D1 - WP1.3 Information services in port, Version 1.3, 2006-06-08.

Rødseth Ø.J., de Lijster A., (2007). Standardized/generalised electronic documents, Comparison of EPC document formats, MarNIS deliverable D1.3D2, Version 1.3, 2007-08-22.

ISO, (2011). ISO 28005-2:2011, Security management systems for the supply chain - Electronic port clearance (EPC) - Part 2: Core data elements

ISO, (2012). ISO 28005-1:2012, Security management systems for the supply chain - Electronic port clearance (EPC) - Part 1: Message structures

Rødseth Ø.J., (2011). XSD file for ISO 28005, V9 2013-02-13: Developed through many EU project in years 2006 to 2011.

Rødseth Ø.J. et al, (2008). TCI and status indicator specification, Flagship deliverable D-D1.1 V1.2 2008-09-26

Vindøy, V. (2008). A Functionally Oriented Vessel Data Model Used as Basis for Classification, 7th International Conference on Computer and IT Applications in the Maritime Industries, COMPIT 08, Liège, 21-23 April 2008.

Vindøy, V. (2008). A Functionally Oriented Vessel Data Model Used as Basis for Classification, Extract of model in CSV format, supplied by author.

IMO FAL 39/INF.2 (2014). Information paper from ISO TC8 on technical options, for implementing electronic certificates

IEC, (1995). IEC 61162-1:1995 Ed. 1, Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 1: Single talker and multiple listeners



-----
Last updated 2014-10-02 by Ø.J.Rødseth @ MARINTEK