dnvgl-cg-0564 data collection infrastructure

CLASS GUIDELINE

DNVGL-CG-0564 Edition November 2020

Data collection infrastructure

The content of this service document is the subject of intellectual property rights reserved by DNV GL AS ("DNV GL"). The useraccepts that it is prohibited by anyone else but DNV GL and/or its licensees to offer and/or perform classification, certificationand/or verification services, including the issuance of certificates and/or declarations of conformity, wholly or partly, on thebasis of and/or pursuant to this document whether free of charge or chargeable, without DNV GL's prior written consent.DNV GL is not responsible for the consequences arising from any use of this document by others.

The electronic PDF version of this document, available at the DNV GL website dnvgl.com, is the official, binding version.

DNV GL AS

FOREWORD

DNV GL class guidelines contain methods, technical requirements, principles and acceptancecriteria related to classed objects as referred to from the rules.

© DNV GL AS November 2020

Any comments may be sent by e-mail to [email protected]

This service document has been prepared based on available knowledge, technology and/or information at the time of issuance of thisdocument. The use of this document by others than DNV GL is at the user's sole risk. Unless otherwise stated in an applicable contract,or following from mandatory law, the liability of DNV GL AS, its parent companies and subsidiaries as well as their officers, directors andemployees ("DNV GL") for proved loss or damage arising from or in connection with any act or omission of DNV GL, whether in contract or intort (including negligence), shall be limited to direct losses and under any circumstance be limited to 300,000 USD.

CHANGES – CURRENT

This is a new document.

Changes - current

Class guideline — DNVGL-CG-0564. Edition November 2020 Data collection infrastructure

DNV GL AS

CONTENTS

Changes – current.................................................................................................. 3

Section 1 General....................................................................................................61 General................................................................................................ 62 Document outline.............................................................................. 10

Section 2 Design of data collection infrastructures...............................................121 Introduction to infrastructures..........................................................122 General requirements........................................................................ 153 Functional requirements.................................................................... 164 Hardware requirements..................................................................... 195 Documentation requirements.............................................................19

Section 3 Vessel server.........................................................................................221 General.............................................................................................. 222 Time synchronization.........................................................................233 Source systems..................................................................................23

Section 4 The data relay component.....................................................................251 General.............................................................................................. 252 Data relay requirements....................................................................253 Transport device................................................................................264 Third-party infrastructure as the data relay component.................... 27

Section 5 Remote data server...............................................................................291 General.............................................................................................. 292 Client time zone.................................................................................29

Section 6 End-to-end solutions............................................................................. 301 General.............................................................................................. 302 Variant 1 architecture........................................................................303 Variant 2 and 3 architectures............................................................30

Section 7 Network and data security.................................................................... 311 Network and data security................................................................ 31

Section 8 Data quality management..................................................................... 321 General.............................................................................................. 322 Data management maturity...............................................................32

Contents


DNV GL AS

3 Data quality monitoring.....................................................................32

Section 9 Third-party verification......................................................................... 341 Case by case approval, product certification and type approval........ 34

Appendix A Solution variant summary.................................................................. 361 Solution variant summary..................................................................36

Appendix B Best practices.....................................................................................381 Best practices.................................................................................... 38

Appendix C Threats and failure modes................................................................. 43

Changes – historic................................................................................................46

Contents


DNV GL AS

SECTION 1 GENERAL

1 General

1.1 IntroductionThe digitalization and increased connectivity available for the maritime industry is enabling use of data fordifferent applications at different locations. Efficient scale-up requires reliable data collection and exchange ofdata that will also require a certain level of standardization and data quality management.Digitalization also introduces new risks towards cyber security and data security which should be managed.

1.2 ObjectiveThe objective is to provide a set of requirements enabling the maritime industry to standardize datacollection infrastructures to support a cost effective, scalable, reliable and secure data collection, storage andexchange of data.

1.3 ScopeThis document sets the requirements to a data collection and historization infrastructure and its components.The guideline splits between three variants of infrastructures, one proprietary and two standardized. Thegoal is to ensure that the data flowing through such a data collection infrastructure, from vessel to dataconsumers, is reliable and trustworthy.This document does not cover infrastructures related to the remote control of vessels or autonomousoperation. Neither does it cover distribution of data from remote data center to data consumers on thevessel.

1.4 ApplicationThis document is applicable for certification and type approval of data collection infrastructures and itscomponents. Such certification may be required by the DNV GL rules for class notations, e.g. DNVGL-RU-SHIP Pt.6 Ch.11 or documents describing other DNV GL class services.Requirements in this document apply to data collection infrastructures that include data collection at a vesseland the data flow to a data consumer at the vessel or to a remote data consumer via a data relay componentand a remote data server.The data collection infrastructure may be certified in whole or as individual components. Individualcomponents can be certified as either a vessel server, a data relay component or a remote data server. App.Aprovides an overview of which requirements apply to which component.

1.5 ReferencesTable 1 DNV GL documents

Document code Title

DNVGL-RU-SHIP Pt.4Ch.9

Control and monitoring systems

DNVGL-RU-SHIP Pt.6Ch.5 Sec.21

Cyber security

Section 1


DNV GL AS

Document code Title

DNVGL-RU-SHIP Pt.6Ch.5 Sec.24

Smart vessel - Smart

DNVGL-RU-SHIP Pt.6Ch.11

Digital features

DNVGL-CP-0337 General description of services for certification of materials and components

DNVGL-CP-0338 Type Approval scheme

DNVGL-CG-0339 Environmental test specification for electrical, electronic and programmable equipment andsystems.

DNVGL-CG-0508 Smart vessel

DNVGL-RP-0497 Data quality assessment framework

Table 2 External documents

Document code Title

ISO 19847 Ships and marine technology - Shipboard data servers to share field data at sea

ISO 19848 Ships and marine technology - Standard data for shipboard machinery and equipment

ISO 8000-2 Data quality - Part 2: Vocabulary

ISO 8000-8 Information and data quality: Concepts and measuring

IEC 62541 series OPC unified architecture

ISO 16425 Ships and marine technology - Guidelines for the installation of ship communication networksfor shipboard equipment and systems

IEC 61162-1 Maritime navigation and radiocommunication equipment and systems - Digital interfaces -Part 1: Single talker and multiple listeners

IEC 61162-450 Maritime navigation and radiocommunication equipment and systems - Digital interfaces -Part 450: Multiple talkers and multiple listeners - Ethernet interconnection

IEC 62443-1-1 Industrial communication networks - Network and system security - Part 1-1: Terminology,concepts and models

1.6 Definitions and abbreviations1.6.1 Definition of verbal formsThe verbal forms in Table 3 are used in this document.

Table 3 Definition of verbal forms

Term Description

shall verbal form used to indicate requirements strictly to be followed in order to conform to thedocument

should verbal form used to indicate that among several possibilities one is recommended asparticularly suitable, without mentioning or excluding others

Section 1


DNV GL AS

Term Description

may verbal form used to indicate a course of action permissible within the limits of the document

1.6.2 Definition of termsThe terms defined in Table 4 are used in this document.

Table 4 Definition of terms

Term Definition

information model logical organization of tags or other attributes into a graph or hierarchy that reflectsstructural relationships between the attributes

alias alternate name for an original tag from a source system

cyber security practices, tools and concepts that protect:

— the operational technology (OT) against the unintended consequences of a cyber incident

— information and communications systems and the information contained therein fromdamage, unauthorised use or modification, or exploitation

— against interception of information when communicating and using the internet

data reinterpretable representation of information in a formalized manner suitable forcommunication, interpretation, or processing, see ISO 8000-2.In this context data refers to time series data, event data (including IEC 61162-1 sentences),time series metadata and information models.

data collectioninfrastructure

hardware and software which provide end to end communication of data from a vessel to aremote data server or a specific data consumer

data consumer application end point that consumes data. A data consumer can be either a local dataconsumer or a remote data consumer

data relay component the intermediary component in the data collection infrastructure which ensures data flowbetween the vessel and the remote data server or data consumer

data quality measurement to which degree data meet the implicit or explicit expectations andrequirements of users or systems utilizing the dataInformation and data quality are defined and measured according to syntactic, semantic andpragmatic quality. Syntactic and semantic quality is measured through a verification process,whereas pragmatic quality is measured through a validation process, see DNVGL-RP-0497

data quality management coordinated activities to direct and control an organisation with regards to data quality, seeISO 8000-2

demilitarized zone perimeter network segment that is logically inserted between internal and external networks,see IEC 62443-1-1. Can also be referred to as level 3.5 in a Purdue Enterprise ReferenceArchitecture

event data condition data, events, alarms and alerts. Individual events typically have an event type, asource, a time stamp, a message and a severity

gateway relay mechanism that attaches to two (or more) computer networks that have similarfunctions but dissimilar implementations and that enables host computers on one network tocommunicate with hosts on the otherSee IEC 62443-1-1

historization storage of data with an associated time dimension

Section 1


DNV GL AS

Term Definition

infrastructure variant standardized or proprietary infrastructure variants, as defined in Sec.2 [1]

local data consumer an application that consumes data from the APIs of the vessel server

metadata contextual data providing descriptive context to time series data.Metadata may be, but is not limited to, such attributes as name, description, location,engineering unit, range, compression settings, etc.

network communication network restricted in scope to a vessel, see ISO 16425

OPC UA client an software implementation of a client according to IEC 62541. In this document this meansa client which implements client facets of ISO 62541: The Core 2017 Client Facet, the DataAccess Client Facet, the Event Subscriber client facet, and the Historical Raw, Aggregate andData At Time Client Facet

OPC UA server an software implementation of a server according to IEC 62541. In this document this meansa server which implements server facets of ISO 62541: The Core 2017 Server Facet, theData Access Server Facet, the Standard Event Subscription Server Facet and the HistoricalRaw, Aggregate and Data At Time Server Facet

remote data server target server or server cluster on which data is persisted, and from which collected data ismade available to remote data consumers

remote data center organizational unit with ownership of the remote data servers

remote data consumer an application that consumes data from the remote data center component.The remote data consumer can also obtain data directly from a source system (infrastructurevariant 1)

semantic data quality the degree to which data correspond to what it representsE.g. a sea temperature of 60°C do not correspond with the realistic or correct value andtherefore the semantic data quality in this case is low, see ISO 8000-8

source system system or instrument which exposes data to the data collection infrastructure

syntactic data quality the degree to which data conforms to its specified syntax, i.e. requirements stated by themetadata, see ISO 8000-8

tag fixed reference or identifier that is unique to the vessel and which points to a measured/calculated value or system state that may provide a data stream over time

transport device device or system capable of transporting data from the vessel server to a data consumeror the remote data center without having any knowledge to the content of the data or anypossibilities for altering the data

time series data series of time stamped values associated with a tag. Individual time series data values maybe associated with a quality attribute or annotation

vessel the source location from which the data originates. This could for instance be a ship or anoffshore rig. A vessel may contain one or more source systems and one or more vesselservers

vessel server data server or buffer on the vessel which collects data from source systems

1.6.3 AbbreviationsThe abbreviations described in Table 5 are used in this document.

Section 1


DNV GL AS

Table 5 Abbreviations

Abbreviation Description

API application programming interface

DMZ demilitarized zone

NTP network time protocol

ODBC open database connectivity

OEM original equipment manufacturer

OPC object linking and embedding for process control

2 Document outline

Figure 1 Requirement structure

The document covers the various requirements that a data collection infrastructure needs to satisfy. Therequirements are detailed in the following chapters as outlined below and in Figure 1.Sec.2 specifies the generic functional requirements to the data collection infrastructure in terms of thecapabilities that need to be available.Sec.3 specifies the requirements that are specific to the vessel server of the infrastructure.Sec.4 specifies the requirements that are specific to the data relay component of the infrastructure.Sec.5 specifies the requirements that are specific to the remote data server of the infrastructure.Sec.6 specifies the requirements to an end-to-end solution using proprietary protocols for the data relay.Sec.7 specifies the requirements to network and cyber security.Sec.8 specifies the requirements specific to data management.Sec.9 specifies the elements involved in third party verificationApp.A provdies a reference table with a summary of key requirements.App.B reviews some best practices which impacts data quality in data collection infrastructures.

Section 1


DNV GL AS

App.C reviews some data quality threats and failure modes which may affect data collection infrastructures.

Section 1


DNV GL AS

SECTION 2 DESIGN OF DATA COLLECTION INFRASTRUCTURES

1 Introduction to infrastructuresA vessel may have one or several data collection infrastructures. These infrastructures may be certifiedaccording to the proprietary variant 1 solution or one of the standardized variants 2 or 3. The figures belowillustrate the conceptual data flow in such infrastructures, and should not to be interpreted as networktopology examples.

Figure 1 Example of a split infrastructure

Figure 1 shows an example of a split infrastructure where the upper red part may qualify as a proprietaryinfrastructure variant 1 while the lower blue part may be either a proprietary infrastructure variant 1 or astandardized variant 2 or 3 infrastructure.

Section 2


DNV GL AS

Figure 2 Example of several vessel servers and shared data relay component

Figure 2 shows example of a vessel with two infrastructures, one proprietary and one standardized that shareuse of a data relay component.Each infrastructure may be assessed and certified independently but the certification will address the sharedcomponents in terms of e.g. bandwidth, priority and cyber security.

Section 2


DNV GL AS

Figure 3 A common standardized infrastructure

Figure 3 shows a variant 2 or 3 infrastructure where all data communication passes through a single vesselserver and data relay component.

Section 2


DNV GL AS

Figure 4 An example of a split and chained data collecion infrastracture

Figure 4 show an example of an infrastructure that includes both data flow from a standardized vessel serverto a remote data center but also a flow of data transported through an OEM infrastructure before it is sent tothe remote data center.

2 General requirements

2.1 IntroductionA data collection infrastructure shall be capable of collecting and preserving the states and values receivedfrom one or many source systems. The infrastructure includes those components necessary to collect,manage and relay data from a vessel to the data consumer. Different infrastructure architectures may beused. This guideline defines following infrastructure variants:

— infrastructure variant 1: a proprietary infrastructure established specifically for the purpose of collecting apredefined set of tags from a specific source system, at a specific rate and with specific quality criteria

— infrastructure variant 2: a standardized infrastructure established for the purpose of collecting of a flexibleset of tags from a range of different source systems. Variant 2 infrastructures supports data interfacing asspecified by ISO 19847 and ISO 19848

— infrastructure variant 3: a standardized infrastructure established for the purpose of collecting of a flexibleset of tags from a range of different source systems. Variant 3 infrastructures support data interfacing asspecified by the OPC UA client and -server in addition to relay of ISO 61162-450 sentences and the abilityto define scheduled exports of data on the formats specified by ISO 19848.

App.A gives a short summary of the specific requirements for each variant.

Section 2


DNV GL AS

All variants shall fulfill the requirements for cyber security and data quality management as described inSec.7 and Sec.8.

2.2 Architecture(s)Infrastructure variant 1: the system architecture of the infrastructure shall be documented. The architectureshall clearly identify the source system(s) from which data is obtained, the local or remote target systemto which data is directed and all intermediary components to satisfy generic requirements. The architectureshould also specify the local or remote target system to which data is directed.Infrastructure variant 2 and 3: the infrastructure architecture must include an embedded generic datastorage with standardized data protocols for communication with data clients.

2.3 Data flowThe direction of data flow shall be from the vessel in the direction of the remote data server, implementingsecure unidirectional communication when crossing network boundaries.

Guidance note:The requirements to unidirectional communication apply to the data flow in the data collection process. Data consumers willusually relate to data extraction API's exposed by servers on the same network segment.

---e-n-d---o-f---g-u-i-d-a-n-c-e---n-o-t-e---

3 Functional requirements

3.1 IntroductionThe functional requirements apply to the end-to-end functional capabilities of the data collectioninfrastructure. Specific components that fulfill the role of source system, vessel server, data relay componentor remote data server separately need to align with the applicable requirements stated in section 2.

3.2 Supported tagsThe maximum number of tags supported for collection by the infrastructure shall be provided.In order to support data extraction, tags defined in each server component of the infrastructure shall beunique. Vessel servers shall be able to disambiguate between identical tags from separate connected sourcesystems. Remote data servers shall be able to disambiguate between identical tags from separate connectedvessel servers.

3.3 AliasesThe infrastructure shall have the ability to assign aliases to source system tags which can be used by dataconsumers when querying data.

Guidance note:Ability for assigning aliases should be available both at vessel server and remote data server.


3.4 Information modelThe infrastructure shall have the ability to define an information model as an organization of tags in graphsor hierarchies that reflect relationships between the tags.Variant 2 and 3 infrastructures shall allow browsing of the information model by data consumers.

Section 2


DNV GL AS

Guidance note:For compability with DNV GL product model, see ISO 19848 Annex C.


3.5 Data collectionThe data collection infrastructure capacity in terms of data volume shall be provided.Decoding of source data during collection shall ensure that validity and integrity information which is encodedwith the data is preserved for data consumers.

Guidance note:Volume can for instance be specified as the number of raw values that the infrastructure is capable of collecting per second.


3.6 HistorizationInfrastructure variant 1:data may be delivered directly to the data consumer end point which may be aspecific data consumer without intermediate historization.Infrastructure variant 2 and 3: the data shall be historized for at least 30 days on the vessel. Data historyshall be available for at least 3 years at the remote data server.

3.7 Buffering and recovery capabilitiesThe infrastructure shall be capable of buffering data on the vessel for at least 30 days. There shall be arecovery mechanism to automatically re-establish data communication links when such links or associatedhardware has been offline. There shall be a recovery mechanism for buffered data to avoid data loss in theremote data server.

3.8 Data extractionInfrastructure variant 1: the infrastructure shall provide data according to the specific data use case needs.Infrastructure variant 2: the infrastructure shall provide data extraction according to ISO 19847 and ISO19848.Infrastructure variant 3: the infrastructure shall provide data extraction either from the vessel or from aremote data center and shall provide data extraction according to the OPC UA server and IEC 61162-450 (asreceived). This variant shall also have the capability to schedule data export according to ISO 19848 formats.

3.9 Data consumer APIsThere shall be provided an API (application programming interface) for handling of the followingrequirements:

— Tag search: the vessel server may and the remote data server shall provide data consumers with an APIfor filtered search mechanism of available tags. Search queries shall be capable of returning matchingtags and their metadata.

— Information model: information model browsing as specified in [3.4] shall also be made available throughan API on the remote data server and may be made available from an API on the vessel server.

3.10 CompressionTime series data may be filtered and hence compressed through a mechanism of data reduction in theinfrastructure. If a filter compression strategy is used, it shall be documented. It shall also be documentedwhere in the infrastructure compression algorithms are executed.

Section 2


DNV GL AS

3.11 Data transfer delayThe infrastructure shall have a known data transfer delay. This shall be measured as the time it takes fromwhen a value changes in a source system to the time when the change in value is reflected to local- andremote data consumers. For infrastructures that are based on bulk transfer of data from local buffers to theremote data server the transfer delay as perceived by the remote data consumer shall be evaluated in termsof the mean time between bulk transfers.

Guidance note:The actual transfer delay should be recalculated at least hourly and be stored as a time series available to data consumers. Thecalculation may either be based on the perceived delay when updating a single tag, or take multiple tags into consideration. If theinfrastructure is designed with distinctly different data transfer approaches for different groups of tags (e.g. one set of continuouslytransferred data, and one set of data which is bulk transferred when the vessel is in port), then the infrastructure should have acalculated data transfer delay for both approaches.


3.12 Service availabilityThe services that are key to maintaining throughput of data through the data collection infrastructure shallbe monitored for service availability. The means by which availability is monitored shall be documented. Asummary of availability metrics for all source systems as well as the local-, remote- and relay components inthe infrastructure shall be available.

3.13 System diagnosticsSystem internal diagnostic messages (warnings, errors, etc.) shall be collected for all the services that arekey to maintaining throughput of data through the infrastructure. As a minimum a daily metric of the numberof diagnostic messages in each severity category shall be maintained for each node in the infrastructure.

Guidance note:See Sec.8 [3.2] for a list of possible data collection infrastructure diagnostics which may be collected.


3.14 MetadataVessel servers and remote data servers in the infrastructure shall be capable of maintaining metadata foreach tag. For time series tags the components in the infrastructure shall have the possibility to assign name,description, location, engineering unit and valid range. For event data the infrastructure shall keep track ofevent source identifiers.The mechanism through which metadata is synchronized between the source systems and the remotedata server shall be documented. Either well defined manual roles and work processes or automatedsynchronization via automated source system connectors are acceptable mechanisms.

3.15 Preservation of data quality codingThe data collection infrastructure shall ensure that the quality coding of input values is preserved andprovided to clients accessing the APIs offered through the vessel server or the remote data server. Qualitycodes may refer to OPC quality codes or to quality coding elements as specified in ISO 19848.

Guidance note:Original data quality coding from each source system should as far as practicable be preserved and be available for the dataconsumer. If data coding is converted from original format to another format that is used through the infrastructure, then theconversion should only be performed at the interface between source system and the vessel server.


Section 2


DNV GL AS

3.16 Audit trailsThe data collection infrastructure shall maintain an audit trail of changes to the system. This includeschanges to the system configuration settings applied through administrative interfaces, changes made toinformation models, metadata and manual changes made to the raw values being collected through theinfrastructure.

3.17 Source system integrityInterface to source systems shall comply to the applicable standards for interface used.A faulty internal state in the data collection infrastructure shall not adversely impact the source system fromwhich data is collected.

3.18 System administration interfaceAll infrastructure components in the data collection infrastructure shall have mechanisms to restrict useraccess through an administration interface.

3.19 BackupIt shall be possible to perform backup of the system configuration and the data storage on the vessel serverand on the remote data server.There shall be a defined procedure for how to restore backups.

Guidance note:During backup, stored data should still be available to data consumers. During a backup, write operations to the data store may bepaused, but there should be no permanent loss of data.


3.20 Multiplicity and identifiersOne vessel server shall be able to receive data from many source systems. One remote data server shallbe able to receive data from many vessel servers. The source system ID and vessel ID shall be possible toassign and maintain in the infrastructure.

4 Hardware requirementsElectronic components installed onboard should be suitable for marine use and comply with environmentalrequirements in DNVGL-RU-SHIP Pt.4 Ch.9 (i.e. approved in accordance with DNVGL-CG-0339).Electronic components located other places than onboard should comply with the regional requirementsapplicable, e.g. EU declaration of conformity.

5 Documentation requirements

5.1 Type approval5.1.1 IntroductionThe scope for type approval may vary depending on the solution and customer preferences. See Sec.9 formore information about type approval. The next paragraphs list the expected documentation for a standardtype approval according to this guideline.

Section 2


DNV GL AS

5.1.2 Vessel serverFollowing information should be submitted for type approval of a vessels server:

— system topology diagram if more than one component— design documentation including:

— type designations of all components/modules— information about operational limits— method for measuring data transfer delay— documentation of cyber security measures— functional description of vessel server functions including built-in data quality monitoring features ifimplemented

— user documentation as manuals

— installation documentation

— test reports for tests performed at accredited laboratory

— test procedure for tests that need witnessing

— calculated or measured storage usage per 24 hours based on maximum or used number of tags

— calculated budget for bandwidth usage considering buffer and recovery requirements

— software change handling procedure.

5.1.3 Data relay componentFollowing information should be submitted for type approval of a data relay component:

— system topology diagram if more than one component— design documentation including:

— type designation of all components/modules— identification of included or compatible data transport component(s)— information about operational limits— documentation of cyber security measures— functional description of data relay component functions including built-in data quality monitoringfeatures if implemented

— user documentation as manuals

— installation documentation

— test reports for accredited tests performed at laboratory


— software change handling procedure.

5.1.4 Remote data serverFollowing information should be submitted for type approval of a remote data server:

— identification of remote data center— system topology diagram if more than one component— design documentation including:

— type designations of all components/modules— information about operational limits— method for measuring data transfer delay— documentation of cyber security measures— functional description of remote data server including built-in data quality monitoring features ifimplemented

Section 2


DNV GL AS

— software change handling procedure


— data quality and security management documentation.

5.1.5 End-to-end data collection infrastructureDocumentation requirements as specified in [5.1.2], [5.1.3] and [5.1.4]. Interfaces between Vessel serverand data relay component and between data relay component and remote data server may however beproprietary. Operational limitations in proprietary protocols shall be identified and documented.

5.2 Product certificate5.2.1 IntroductionProduct certification in this section refers to DNVGL-RU-SHIP Pt.6 Ch.11 Sec.1 for D-INF. For documentationrelated to other class notations or digital class enhancement, see related rules or guidelines fordocumentation requirements.The list of documents required below presuppose that the referred component/solution is type approved.The type approval certificate may state document requirements that differ from this generic list. If no typeapproval exists, the scope of the product certification will include the type approval scope and the list ofdocuments in [5.1].

5.2.2 Vessel serverFollowing information should be submitted for product certification of a type approved vessels server:

— Z283 Reference to type approval certificate.— I071 Inventory list, list of parts included in the vessel server.— I110 List of monitored data points, including tag names/aliases and metadata used.— I320 SW change handling procedure, configuration of vessel server, data and metadata.— Z252 Test procedure at manufacturer

5.2.3 Data relay componentFollowing information should be submitted for product certification of a type approved data relay component:

— Z283 Reference to type approval certificate(s).— I071 Inventory list, list of parts included in the data relay component (incl. data transport component andother intermediate components needed to send data to dedicated remote data server)

— I320 SW change handling procedure, configuration of data relay component.— Z252 Test procedure at manufacturer.

5.2.4 End-to-end solutionFollowing information should be submitted for product certification of a type approved end-to-end solution:

— Z283 Reference to type approval certificate.— I071 Inventory list, list of parts included in the solution.— I110 List of monitored data points, including tag names/aliases and metadata used.— I320 SW change handling procedure, configuration of components, data and metadata.— Z252 Test procedure at manufacturer.

Section 2


DNV GL AS

SECTION 3 VESSEL SERVER

1 GeneralThe vessel server is a system component that can collect data through one or more data collection interfaces,store data in a data buffer and serve data to clients through one or more data server interfaces. Figure1 illustrates the input and output schematics of a vessel server. The required features of a variant 2infrastructure is colored orange and the required features of a variant 3 infrastructure is colored blue. Avessel server is not a required component in a variant 1 infrastructure. Variant 1 architectures may still bedesigned with a component that collects, stores and serves data, thus acting like a vessel server, withoutsatisfying the standardized interface requirements of a variant 2 or 3 architecture.Optionally, the vessel servers in variant 2 and 3 may utilize additional data collection and server interfaces,based on other standards or proprietary solutions.

Figure 1 Vessel server

A vessel server may be comprised of several hardware components.

Section 3


DNV GL AS

Figure 2 A redundant and mirrored vessel server

Figure 2 shows an installation with a redundant server on L3 and a duplication server in DMZ on L3.5.Working together as a system, all these servers will be regarded as one vessel server.All relevant requirements in Sec.7, Sec.8 and Sec.9 also applies to the vessel server. See App.A for anoverview of functional requirements.

2 Time synchronizationThe vessel server of the data collection infrastructure shall have a function to synchronize its internal timewith a master clock or satellite positioning system clock. The vessel server shall also have the possibility toassign time stamps to the event data and time-series data collected.

3 Source systemsSource systems are systems that provide data to the data collection infrastructure.The source system as such is outside the scope of a certification of a vessel server or a data collectioninfrastructure. However, the source system may in some cases be an autonomous vessel server by itself. Inthis latter case the source system can be considered as a part of the complete data collection infrastructure.Figure 3 illustrates how a server on L2 may be chained together with servers on L3 and L3.5. The possiblepresence of multiple vessel servers is also suggested in the variant 2 and variant 3 infrastructures in Sec.4Figure 2.

Section 3


DNV GL AS

Figure 3 Vessel server including a server in source system on L2

Guidance note:An OEM may provide a data storage system, which is in itself a vessel server that collects data from multiple subcomponents whichin turn feeds into the vessel server that acts as the parent system for all the source systems.


Section 3


DNV GL AS

SECTION 4 THE DATA RELAY COMPONENT

1 GeneralThe data relay component is the intermediary component in the data collection infrastructure which ensuresdata flow between the vessel server and data consumers or the remote data server.Depending on the specific situation, the data relay component shall be either:

— a data transport network with the appropriate gateways and bandwidth according to Sec.7— an entire 3rd party data collection infrastructure in accordance with this standard. Sec.2 Figure 3.

All relevant requirements in section Sec.7, Sec.8, Sec.9 also apply to the data relay component. See App.Afor an overview of functional requirements.

Guidance note:As part of a certification of the data relay component, transport devices will only be assessed towards availability, bandwidth,priority configurations and cyber security. Additionally, transport units are expected to fulfill applicable international requirements,e.g. CE marking or system specific requirements as for Inmarsat C.


2 Data relay requirements

2.1 BandwidthThe bandwidth shall support the planned data throughput accommodating for peak load.

2.2 ArchitectureThe data relay component shall exist as a mandatory intermediary component for both variant 1, 2 and 3infrastructures.If one vessel contains multiple infrastructures that share the same data relay component, then the impact ofthe combined data collection load on the data relay component shall be considered.Figure 1 illustrates the data relay component of a variant 1 architecture. Variants 2 and 3 are illustrated inFigure 2. Dotted lines illustrate components of the Variant 1 architecture that are optional.

Figure 1 Variant 1 infrastructure

Section 4


DNV GL AS

Figure 2 Data relay component architecture variant 2 and 3

3 Transport deviceA data relay component may include use of transport devices that are used to route data from the vesselserver to data consumers or to a remote data server. Data distributed via the transport devices shall beencrypted and tunneled (VPN) according to the cyber security requirements in Sec.7. The exception is if thedata consumer is located in the same controlled network as the server. Then no additional security measuresare required unless stated elsewhere e.g. as for the voluntary class notations Cyber Secure.

Guidance note:Examples of transport devices within an uncontrolled network are routers, switches or hubs. Examples of transport devices withina controlled network may be cyber secure switches or forwarders. Examples of transport devices from vessel to shore are InmarsatC, Fleet, VSAT.


Section 4


DNV GL AS

Figure 3 Example of data relay component

4 Third-party infrastructure as the data relay componentAs illustrated in Figure 4, a 3rd party infrastructure may act as a data relay component. Data then flows fromthe standardized vessel server to another OEM vessel server that forwards the data to an OEM remote datacenter. The remote data server then receives the data from the OEM remote data center. Implementationof this configuration requires that the requirements specified in Sec.2 [3.7], Sec.2 [3.11], Sec.2 [3.15] areevaluated for the infrastructure as a whole.

Section 4


DNV GL AS

Figure 4 Third party infrastructure as the data relay component

Section 4


DNV GL AS

SECTION 5 REMOTE DATA SERVER

1 GeneralThe remote data server is the recipient of data from the vessel server through the data relay component. Theremote data server is also responsible for serving data to remote data consumers.Protocol support requirements for variant 2 infrastructures are colored orange in Figure 1, whereas protocolsupport requirements for variant 3 infrastructures are colored light blue.Optionally a remote data server can receive and serve data using other standards and proprietary interfaces.

Figure 1 Remote data server

All relevant requirements in section Sec.7, Sec.8, Sec.9 also apply to the remote date server. See App.A foran overview of functional requirements.

2 Client time zoneThe remote data server component needs to provide time stamps including the time zone in order to allowclients with different time zone settings than the internal time zone of the system to interpret the timestamps correctly.

Section 5


DNV GL AS

SECTION 6 END-TO-END SOLUTIONS

1 GeneralAll relevant requirements in section Sec.2 [2] Sec.2 [3], Sec.2 [5], Sec.2 [5], Sec.3 [1], Sec.4, Sec.5 [2],Sec.7, Sec.8 and Sec.9 also apply to end-to-end solutions.

2 Variant 1 architectureA variant 1 architecture is an architecture for data collection which is associated with customizedrequirements. A variant 1 architecture shall comply with the requirements to having a data relay component.All other requirements shall be defined by the specific data collection use case.A Variant 1 architecture does not have a defined external data interface. A variant 1 architecture mayselectively implement external interfaces as specified by variant 2 or Variant 3.

3 Variant 2 and 3 architecturesVariant 2 and 3 solutions may be implemented as end-to-end solutions. Requirements for vessel servers,data relay components and remote data servers in Sec.3, Sec.4 and Sec.5 also apply in such solutions butthe interface between the vessel server and the remote data server may be implemented using a proprietaryinterface. This is illustrated in Figure 1.

Figure 1 End-to-end solution using proprietary interface

Section 6


DNV GL AS

SECTION 7 NETWORK AND DATA SECURITY

1 Network and data securityMinimum requirements for network and data security are defined in DNVGL-RU-SHIP Pt.6 Ch.11 Sec.1 [2.8].Optional class notations or digital class enhancements (e.g. DNVGL-RU-SHIP Pt.6 Ch.5 Sec.21 and DNVGL-RU-SHIP Pt.6 Ch.5 Sec.24) may introduce additional requirements to network and data security. S

ection 7


DNV GL AS

SECTION 8 DATA QUALITY MANAGEMENT

1 GeneralThe components of the data collection infrastructure and the organizations that implement, deploy, operateor maintain these components shall fulfil certain requirements to data management maturity, data qualitymanagement and data quality monitoring according to the D-INF requirements in the DNV GL rules fordigital features DNVGL-RU-SHIP Pt.6 Ch.11.

2 Data management maturityHaving the appropriate data management maturity in the context of organizations with responsibility forinfrastructure components means having a defined approach to the different data management capabilityareas: governance, organization and people, processes, process efficiency, requirements definition,architecture/tools and technology, metrics and dimensions and data standards. In order for the approachto each capability area to be defined there needs to be a formalized approach to the specific capability areawhich applies throughout the organization.The process of establishing and measuring data management maturity is further elaborated in DNVGL-RP-0497.Both data infrastructure system component vendors, yards that are establishing standardized data collectioninfrastructure configurations as well as original equipment manufacturers and vessel owners shall ensure thattheir data management capabilities are at a sufficient level of maturity.

3 Data quality monitoring

3.1 Design quality capabilityIn order to monitor data quality in a data collection infrastructure or its subcomponents, the first step is todocument the design capability of the infrastructure with respect to data quality.Submitted documentation shall explain how the challenges of data quality are being addressed by thecomponents of the infrastructure and for the end-to-end infrastructure.A starting point of topics relevant for discussion of data quality design for the I020 - System functiondescription can be found in App.B. The document shall state the level of data quality which the individualcomponents and the end-to-end infrastructure is designed for using data quality metrics. Exactly whichmetrics to use to describe the data quality design capabilities can be decided by vendor, but the discussionshall relate to the semantic, syntactic and pragmatic types of data quality defined by ISO 8000-8 andincorporate metrics for how dimensions of data quality such as timeliness, completeness, consistency,integrity, conformity and accuracy are accounted for. If different groups of tags or different parts of theinfrastructure may be designed with different data quality capabilities this should be detailed.Features and solutions mentioned in the I020 - System function description shall be made available forinspection.

3.2 Operational monitoringThe components of the data collection infrastructure shall have mechanisms for operational data qualitymonitoring. The end-to-end infrastructure shall have mechanisms to ensure that data quality monitoring onthe component level is visible to data consumers acting in the role of data stewards.The purpose of the data quality monitoring is to ensure that operational quality of the infrastructure isaligned with the data quality design capabilities to the greatest extent possible, and to ensure that significantdata quality deviation from the design capabilities are transparently conveyed to data consumers. Submitteddocumentation shall discuss the approach to data quality monitoring. Typical failure modes relevant for dataquality monitoring are mentioned in App.C.

Section 8


DNV GL AS

Data quality monitoring can either be done indirectly through monitoring of system diagnostics with knownexpected impact on data quality, or it can be done directly through signal analysis on individual data streams.Possible data quality metrics which may be derived by indirect monitoring of system diagnostics are:

— CPU load on control modules in automation systems— network traffic in an automation network— automation system alarms and event statistics (bad actors, chattering alarms, etc.)— server and operating system alarms and events— heartbeat signals from data interface services— network bandwidth consumption statistics— continuous end-to-end data transfer delay measurements— calibration metrics— time synchronization metrics— response time (and satisfaction) to sensor system error/quality report submissions by end users— database integrity check results— metadata synchronization logs.

Possible data quality metrics which may potentially be used for monitoring of direct data quality in individualsignals are:

— detection of outliers— detection of record duplication— detection of stale or frozen tags— internal diagnostics from smart instruments— fault signals from instruments (0-4 mA)— error or quality codes recorded and preserved with each raw value.

The degree of data quality monitoring shall be sufficient to establish that the risk of the infrastructureproviding bad data quality or data consumers ending up using data with bad quality is sufficiently low.

Section 8


DNV GL AS

SECTION 9 THIRD-PARTY VERIFICATION

1 Case by case approval, product certification and type approvalCertification of a data collection infrastructure may be required by DNV GL rules. The certification shall verifythat the data collection infrastructure is complying or has the capability to be set up in compliance with allthe requirements in this guideline, as well as requirements from the ship specific class notations and/orsurvey regimes, as applicable.The certification may be done individually per component (vessel server, data relay and remote server) or forthe whole data infrastructure. The certification process normally includes case by case approval and survey/testing at the manufacturer. For more information about the process for product certification or case by caseapproval see DNVGL-CP-0337.The scope for assessment and testing during product certification may be reduced by a type approval.The generic type approval scheme is described in class program DNVGL-CP-0338. The objectives of the typeapproval are to prove that the data collection infrastructure and its components have the capability to fulfillthe generic requirements outlined in this guideline.The scope and test requirements for the type approval shall be agreed with the Society, for each case.If type approved as individual components, each component shall comply to the generic requirementsand support the overall concept by including standardized interfaces between each certified component.Infrastructures certified in whole may use proprietary protocols within the infrastructure.A type approval certificate will be issued to the manufacturer responsible for the product and is not linked toa specific vessel.A vessel specific product certificate will normally be required for the manufacturer responsible for the productdelivery to a specific vessel. The TA certificate will specify the documentation and certification requirementsfor a specific delivery.A type approval may include scope from other class notation and/or survey regimes, and if so, these shouldbe identified in the type approval certificate.As an alternative to product certifications for remote servers may the remote data center be assessedaccording to this guideline for a generic approval. Such an approval will follow the type approval process, butinstead of assessment of a manufactures ability to produce an approved design, assessment and audits willbe performed to ensure that the remote data center have the solutions and processes necessary to fulfill therequirements in this guideline. The scope and requirements shall be agreed with the Society, for each case.

Figure 1 Schematic view of the scope for a product certification where parts are covered by a typeapproval

Section 9


DNV GL AS

Figure 2 Schematic view of the scope for a product certification where parts are covered by a typeapproval for either an end-to-end solution or individual components

Figure 3 Schematic view of the scope for a type approval

Section 9


DNV GL AS

APPENDIX A SOLUTION VARIANT SUMMARY

1 Solution variant summaryThe table below summarizes the functional requirements of this guideline.The applicability column (Appl.) specifies where the requirement is applicable. Due to high number ofdifferent architectures the indications in this table may not be definitive:Optional means voluntary during implementation for general approval. Depending on the service that thedata collection infrastructure shall fulfill, specific requirements may still be relevant.The capability column specifies the functional concept. The variant 1, 2 and 3 columns specify therequirements as they apply to that architecture variant. The Reference column points to the section in theguideline which details the requirement.

Table 1 Variant summary table

Capability Variant 1 Variant 2 Variant 3 Appl. Reference

Vessel serverincluded (Onboardhistorization)

Optional1) Yes Yes V Sec.2 [3.6]

Minimum datastorage

Enough forpurpose

30 days vessel, 3years remote

30 days vessel, 3years remote

V/R Sec.2 [2.2] andSec.2 [3.6]

Time coordination Optional1) Yes Yes V Sec.3 [2]

Client time zone Optional Yes Yes R Sec.5 [2]

Alias function Optional1) Yes Yes V/R Sec.2 [3.3]

Information model Optional1) Yes Yes V/R Sec.2 [3.4]

Minium datacollection rate

As specified bymanufacturer

ISO 19847/ISO19848

N/A V/D/R Sec.2 [3.5]

Data relaybandwidth



N/A V Sec.2 [5.1.2]

Minimum datachannels/points


ISO 19847/ISO19848

N/A V/D/R Sec.2 [3.7]

Maximum datachannels/points




V/D/R Sec.2 [3.2]

Tag identifierdisambiguation

Optional1) Yes Yes V/R Sec.2 [3.2]

Minimum localbuffering &recovery

Optional1) Buffering 30days + recoveryfunction

Buffering 30days + recoveryfunction

V/D/R Sec.2 [3.7]

Mandatory inputdata

Adequate ref.spec.

ISO 19847/ISO19848 Incl IEC61162-1/61162-450

OPC UA Client +IEC 61162-450

V/R Sec.2 [3.8]

Appendix A


DNV GL AS

Capability Variant 1 Variant 2 Variant 3 Appl. Reference

Mantatory outputdata

Adequate ref.spec.

ISO 19847/ISO19848 Incl IEC61162-450

OPC UA serverISO 19848(export) IEC61162-450 (asreceived)

V/R Sec.2 [3.8]

API tag search Optional Yes Yes R Sec.2 [3.9]

API informationmodel browsing

Optional Yes Yes R Sec.2 [3.9]

Filter compression Optional1) Optional Optional V Sec.2 [3.10]

Data transferdelay/calculation


Service availabilitymonitoring

Yes Yes Yes V/D/R Sec.2 [3.12]

Systemdiagnostics

Yes Yes Yes V/D/R Sec.2 [3.13]

Metadatamaintenance


Preseration ofquality coding

Yes, for applicabledata1)

Yes Yes V/R Sec.2 [3.15]

Audit trails Optional1) Yes Yes V/R Sec.2 [3.16]

Source systemintegrity

Optional1) Yes Yes V Sec.2 [3.17]

System adm.interface

Optional1) Yes Yes V/D/R Sec.2 [3.18]

Backup Optional1) Yes Yes V/R Sec.2 [3.19]

Source ID/VesselID


1)For a variant 1 infrastructure with a vessel server to be compliant with D-INF(P), this feature is a mandatoryrequirement.

V= vessel server, D= data relay component, R= remote data server.

Appendix A


DNV GL AS

APPENDIX B BEST PRACTICES

1 Best practices

1.1 Data chain extentThe number of hops in the data historization infrastructure between the point of data collection and thepoint of consumption is a key contributor to deterioration in data degradation. Intermittent interface outagebetween any to links in the data chain can cause data loss at higher levels. Good data quality is easier tomaintain when data passes more directly to the data consumer.

1.2 Historization aggregation and resampling frequencyWhen collecting historized data for long term storage, each parameter being collected is collected at acertain predefined polling frequency. The historians generally also use filter compression techniques whichwill lower the rate of values stored. Proper configuration of polling or, even better, publishing values intothe infrastructure allows for better data quality. Filter compression should be used consciously so to avoidsignificant signal quality loss.

1.3 Data transfer delay preventionWhen data is collected and transferred through different nodes in an infrastructure, there is an increasedperceived delay as the data moves further and further from the point of origin. The interfaces configuredto replicate, and poll data can usually be configured to execute the data replication more often (moreoptimized) in order to reduce delay. However, there may be certain tradeoff issues with such delay preventionefforts. If replication is too immediate, there is a risk that the underlying source hasn't yet been updated withall the relevant values applicable to the span for which data is fetched. Efforts to reduce delay at each stepthe data flows through is recommended.

1.4 Graceful buffering and recoveryIn order for data collection schemes to have high quality, there needs to be robust data collection recoverymechanisms in place. Recovery mechanisms will ensure that data replication is realigned with the source(including intermediate raw values) after an interface outage has happened. Robust recovery schemes ensurethat data recovery is facilitated between multiple nodes downstream to where the interface experienceddowntime. Each node in the infrastructure should have buffering capabilities harmonized with the risk ofexperiencing certain periods of disconnection.

1.5 Redundancy in designThe more redundant a data collection infrastructure is, the better the data quality of that infrastructure willbe. On level 1 & 2 in the purdue reference model it is common for both hardware and network infrastructurecomponents to be implanted with redundancy and failover mechanisms in place. Hence, the reliability of thedata streams is very good. Data collection mechanisms further up the value chain can benefit from usingdata collection drivers that leverage the underlying redundancy (e.g. ODBC drivers which implicitly targetsthe master data source) when fetching data. More design redundancy should mean less downtime and betterdata quality.

1.6 Dynamic flexibility in designWhen instrumentation and data collection infrastructures are designed and planned there can be significantdifferences between infrastructures that adapt well to dynamically changes in configuration versusinfrastructures that are difficult to manage when dynamic changes happen. Using templates for defining

Appendix B


DNV GL AS

equipment types, synchronizing changes and having excellent change management routines are key toachieving such flexibility. Designing the sensor system to be adaptive to change is a best practice whichimpacts data quality.

1.7 Legacy system debtOver time a big plant will usually accumulate many generations of technology in multiple layers of thedata collection infrastructure. Legacy components might have a particular way of relaying information,whereas more modern components might have different data communication signatures. The problem growspolynomially as multiple vendors may all have such potential issues with legacy component behavior. It istherefore not uncommon to see equipment that should inherently belong to the same class or category ofinstruments behave differently from different areas in the plant. This makes data difficult to interpret and useconfidently.

1.8 Maintenance and service contractsThe nature and legal structure of maintenance and service contracts may be key to having either poor orhigh data quality. Poorly designed service contracts may reward vendors who repeatedly have to interveneto troubleshoot the same problem instead of vendors who fix the problem once and for all. Making vendorsresponsible for good data quality and rewarding vendors who deliver on this performance indicator is a keyelement to maintaining good data quality.

1.9 Upgrade and refitting practicesWhen planning and executing an upgrade or refitting project it is important to assess the consequences thatthis may have for the data collection infrastructure and to act towards mitigating any negative impacts andplan for changes in advance.

1.10 Initial planning and development practicesWhen planning and implementing completely new industrial projects it is key to start thinking aboutdata collection and preparation for data analytics in the very early phases of the project. Even before theautomation and control systems have matured to a point where templates can't be changed. This allowsfor the right type of instrumentation to be included and the proper data to be collected by the automationsystems.

1.11 End user feedback systemsEnd user feedback is a very valuable source of corrective input into a sensor system infrastructure. End usersneed to have the technical tools available to report poor quality when they encounter it.

1.12 Heartbeat signalsHeartbeat signals, or signals communicated simply for the purpose of communicating that the source systemservices are running, can be very valuable diagnostics in complicated infrastructures. Lack of heartbeatsignals from interfaces will increase the likelihood that interface failures go undetected and that prolongedperiods of data loss may happen.

1.13 Asset Management systemsAsset management systems are tools used to collect, organize and monitor equipment diagnostic informationfor the purposes of doing condition based maintenance. Such tools, as well as tools for calibrating fielddevices are by themselves enablers of good data quality.

Appendix B


DNV GL AS

1.14 Alarm management, monitoring and statistics solutionsAlarm management solutions allow for master management of alarm levels and for monitoring the statisticsrelated to alarms and events occurring in the system. Such solutions are excellent for detecting andeliminating bad actors and data noise which constitute poor data quality.

1.15 Infrastructure monitoring systemsA good infrastructure monitoring system which collects system health and diagnostics as well as heartbeatsignals from all nodes in the sensor infrastructure is a key tool for data custodians and systems managers tomaintain high quality data throughput from a large infrastructure.

1.16 CalibrationInstuments/sensors should be calibrated in order for the measurements performed to be reliable. Sometimescrosschecking multiple instruments in the same part of a process can be used as an indicator that calibrationis required. Sometimes smart instruments will have internal diagnostics indicating that calibration isadvisable. Without proper calibration, the data quality will suffer.

1.17 Sufficient instrumentationIn order for pragmatic data quality to be sufficient for a particular use case it is necessary to have sufficientinstrumentation. If only 90% of the relevant measurements are being being performed, then the usefulnessof the data use case may perhaps only be 10% of the scenario where all the measurements are available.Completeness in terms of data quality is closely linked with having sufficient instrumentation at the sufficientlevel of quality/detail.

1.18 Sufficient granularity of system flagsIn order to make good use of data it is often imperative to know the exact simultaneous system state of theautomation system. If the internal system flags in the automation system are too coarse grained, then it maybe difficult for data consumers to distinguish between analytically different states of the system as a whole.

1.19 Structured I/O federationSignals and data flow to the automation, control and safety systems should be federated in a coherent wayusing consistent modern standards that allow for proper granularity, precise time stamping and consistentconceptualization.

1.20 I/O control module loadThe frequency with which data driven properties of the plant are recalculated in the system is usuallydependent on the load put on each I/O control module. Heavily loaded modules will recalculate outputs lessfrequently.

1.21 I/O control loop qualityFaulty or poorly tested control loops can result in fault signals rather than measured instrument data tobe relayed to source system controllers. This is a potential cause of bad data quality from a data collectioninfrastructure. Good test practices of control loops and monitoring of fault signal statistics are two ways tocombat data quality loss due to poor control loop quality.

Appendix B


DNV GL AS

1.22 Intrinsic instrument qualitiesEach instrument will have defined capabilities with respect to data generation. Both how often it is capable ofrecalculating its own internal state and the precision with which it measures the underlying physical propertywhich it is measuring. A sensor can also have capabilities with respect to eliminating noise or producinginternal diagnostics.

1.23 Time synchronizationIssues relation to time synchronization between nodes in a system is a common cause for imprecision indata being collected. Even systems that follow every recommendation available (like using a satellite-timebased NTP time server and configuring NTP stratums for the entire infrastructure) will still have a level ofgranularity at which time stamps are somewhat uncertain and where sequence of events become difficult todetermine.

1.24 Sufficient hardware and server capacityHaving sufficient hardware and server capacity is important. Both in the control nodes where I/O signals andcontrol blocks are constantly reevaluated, but also in the processing nodes in the infrastructure to collect thedata. A high load on servers, typically mean less frequent reevaluation of signals, and hence more coarse-grained data.

1.25 BandwidthNetwork bandwidth is important to data quality. This is particularly an issue when dealing with installationsthat are dependent on satellite connections. The satellite link often becomes a bottleneck which limits thethroughput of data and dictates either aggressive compression strategies, low sampling rates or batchtransfer of collected data (low timeliness) when the unit is sporadically connected to high capacity networks.

1.26 Plant model synchronization and scalingAn understanding of what constitutes an appropriate model of the plant, the interrelationships betweenattributes, measurements, is a laborious task assemble. Once assembled, it is desirable to be able tosynchronize changes to this model from one subsystem to another. This is usually a great challenge, notonly because there needs to be an appropriate model communication mechanism in place which is mutuallyunderstood by both communicating systems, but because the 'proper' model at one abstraction level may notbe ideal at another abstraction level. Hence, most plants have suboptimal or non-existing synchronizationand scaling of plant models implemented in their infrastructure. Misalignments of models being a majorsource of errors and poor system performance.

1.27 Metadata synchronization across layersMetadata, here understood as a fixed set of descriptive attributes associated with a dynamic process value(a measurement of an equipment state), also needs to be synchronized between systems in the plantinfrastructure. These are attributes such as ranges, engineering units, descriptive text. Lack of metadatasynchronization and shared metadata understanding is a typical source of data deterioration in sensor systeminfrastructures.

1.28 Inconsistent data transfer standards and schemasThe means by which data the same type of data is relayed between different layers in an infrastructureshould be the same. If two layers use different standards and schemas to relay the same type of information

Appendix B


DNV GL AS

the data quality of the net throughput will be determined by the common denominators represented bycapabilities within both standards and schemas. This is a common data deterioration cause.

1.29 Single point of truthAny significant piece of information should have a master storage location. A single point of truth. Thecurrent state of that truth should then be replicated to other locations in the infrastructure where that truth isneeded. A

ppendix B


DNV GL AS

APPENDIX C THREATS AND FAILURE MODESTable 1 lists typical data quality threats and associated failure modes for a sensor system. This list isinformative and not exhaustive. Other threats and failure modes may also be of relevance.

Table 1 Sensor system failure modes

ID Threat Failure Mode How to detect

1 Allowing data server clockto drift.

Incorrect timestamping.

Compare data server clock to satellite/GPS time.

2 Allowing clock oncontrol nodes or smartinstruments to drift.

Incorrect timesynchronization(when usingsource timestamps).

The degree to which sequentially received events are receivedout of order in accordance to source time.

3 Improper reset/reloadof control nodes causingsystem time to startcounting from zero-+(e.g. Jan 1st, 1970).

Incorrect timestamp.

Receiving data with time stamps with year 1970.

4 Incorrect time zonesettings on sourcesystems.

Incorrect timestamping.

Data from different sources are reported with discrete offsets ofmultiples of an hour.

5 Poor calibration ofmeasurement equipment.

Incorrect valuereported.

Compare drift in sliding average between adjacent/similartransmitters (where possible). Monitor the time since the lastcalibration (compared with calibration recommendation).

6 Network link fromcollector to source systemis temporarily broken.

No new data isreceived while thelink is broken.

As it happens, no new data is received from the system.A heartbeat signal would stop updating. If no recovery isconfigured, there will be a long-term data gap.

7 Network link betweennodes in collectioninfrastructure is broken.

No new datais received(downstream)while the link isbroken.

As it happens, no new data is received (downstream) from thesystem. A Heartbeat signal would stop updating. If no recovery isconfigured, there will be a long-term data gap (downstream).

8 Source system goesoffline.


As it happens, no new data is received from the system. Aheartbeat signal would stop updating. If the source system assuch is offline, then it is difficult to avoid a long-term data gap(even with recovery).

9 A node in the collectioninfrastructure goes offline.


As it happens, no new data is received from the system. Aheartbeat signal would stop updating (downstream). There couldbe long-term data gap (depending on recovery mechanisms).

10 Data collection settingsin a source system areinadvertently changed oromitted during systemmaintenance.

The data point(tag) stopsupdating orupdates tooinfrequently.

The amount of raw data from a particular tag starts reportingless frequently over a period of time, compared with priorperiods. The amount of raw data for a tag stops correlatingwith the amount of raw data for other tags (which had priorcorrelation).

Appendix C


DNV GL AS


11 Data collection nodeconfiguration isinadvertently changed oromitted during systemmaintenance or upgrade.

Data archivesettings becomeincorrect or sourcesystem dataproviders may beomitted.

Data archive size stops growing, or the growth rate changes.

12 Data collection settingsfor an individual tag isconfigured to use toomuch filter compression.

Imprecise data isrecorded for a tag.

End-user feedback?

13 Automated metadatasynchronization is haltedor stops.

Incorrect metadataprovided to dataconsumer.

14 Data buffering settingsin source system orcollection node areincorrect or missing.

System downtimeor networkdowntimecompounds tocreate data gaps.

Heartbeat signals from specific source systems flatline. Heartbeatsignal configured for collection node flatlines.

15 Data recovery settings orcapabilities in collectionnode are missing orinsufficient.

System downtimeor networkdowntimecompounds tocreate data gaps.

Heartbeat signals from specific source systems flatline. Heartbeatsignal configured for collection node flatlines.

16 Data volumes exceed theavailable bandwidth.

Missing data orgradual increasingdata transferdelay.

The latest value recorded by the data collection infrastructurelags behind current time by a predefined time interval threshold.

17 Event signature for thesame underlying eventchanges during upgradeor modification.

Discrepant eventcharacteristic overtime.

Difficult to detect automatically - manual periodic reviewrequired.

18 Event signatures forconceptually similar orgrouped events divergeas equipment is upgradedor modified.

Discrepantevent groupingcharacteristics overtime.

Difficult to detect automatically - manual periodic reviewrequired.

19 Underlying data qualityinformation is dropped bycollection infrastructure.

Bad data isreported as good.

A complete absence of quality deterioration coding issymptomatic. One possibility is to have a diagnostic tag in thesource system which alternates between showing valid dataand all the possible diagnostic states in a controlled mannerand to monitor continuously that these diagnostic states can beperceived by data consumers in the other end.

20 Control node isresponsible for too muchI/O.

Infrequent re-evaluation ofsystem state.

Monitor control node KPIs for load.

21 Desired instrumentationmissing.

No value beingmeasured.

Difficult to detect - manual assessment required.

Appendix C


DNV GL AS


22 Measurement or statereporting doesn’tsufficiently discriminatebetween internal systemstates.

Reportedmeasuredvalue/state isn’tuseful for thecategorizationrequired by theuse case.

Difficult to detect - manual assessment required.

23 Sensor drifting over time. Inaccurate data. Periodic calibration using reference instruments. Comparingreadings with multiple sensors (different brands).

Appendix C


DNV GL AS

CHANGES – HISTORICThere are currently no historical changes for this document.

Changes – historic


DNV GL AS

About DNV GLDNV GL is a global quality assurance and risk management company. Driven by our purpose ofsafeguarding life, property and the environment, we enable our customers to advance the safetyand sustainability of their business. We provide classification, technical assurance, software andindependent expert advisory services to the maritime, oil & gas, power and renewables industries.We also provide certification, supply chain and data management services to customers across awide range of industries. Operating in more than 100 countries, our experts are dedicated to helpingcustomers make the world safer, smarter and greener.

SAFER, SMARTER, GREENER

dnvgl-cg-0564 data collection infrastructure

Documents