Systems Verification Guide e

7/28/2019 Systems Verification Guide e

1/67

G u i d e f o r S y s t e m s V e r i f i c a t i o n

GUIDE FOR

SYSTEMS VERIFICATION

(Including Hardware-in-the-Loop and Software-in-the-Loop Testing)

JULY 2012

American Bureau of Shipping

Incorporated by Act of Legislature of

the State of New York 1862

Copyright 2012American Bureau of Shipping

ABS Plaza

16855 Northchase Drive

Houston, TX 77060 USA


2/67

ii ABSGUIDE FOR SYSTEMS VERIFICATION .2012

F o r e w o r d

Foreword

This Guide contains the technical requirements and criteria employed by ABS in the review and survey ofsystems where the Systems Verification (SV) Notation has been requested. It is applicable to systems that

are installed on board vessels, offshore installations and facilities...

The Guide is applicable during the initial construction and classification process where the SV notation is

initially granted as well as during the service life of the vessel, offshore installation or facility wheremaintenance of the SV Notation is desired. This guide is also applicable for an existing vessel, offshore

installation or facility that, at a point in time after classification or request for classification, wishes to have

the SV Notation granted.

Systems managed, designed, constructed, installed and maintained in accordance with the requirements of

this Guide on an ABS classed vessels, offshore installations or facilities, under ABS engineering review,approval and survey, may be identified in theRecordby an appropriate notation as defined herein.

The Guide has an effective date of 1 July 2012. The application of this Guide and referred Rules andGuides is, in general, based on the contract date for construction between the shipbuilder and the prospective

Owner (e.g., Rules which became effective on 1 July 2012 are not applicable to a vessel, offshore installation orfacility for which the contract for construction was signed on 30 June 2012). At the Owners request and

upon agreement by ABS, this Guide may be applied to existing vessels, offshore installations or facilitiesor to those projects for which the contract date of construction has been signed before 1 July 2012. See also

the ABS Rules for Conditions of Classification (Part 1) or ABS Rules for Conditions of Classification Offshore Units and Structures (Part 1), etc., as applicable.

This Guide is meant to be used with other Rules and Guides issued by ABS and other recognized Industry

Standards.

Users are advised to check periodically on the ABS website www.eagle.org to verify that this version ofthis Guide is the most current.

We welcome your feedback. Comments or suggestions can be sent electronically by email to0H

[email protected].
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


3/67

ABSGUIDE FOR SYSTEMS VERIFICATION .2012 iii

T a b l e o f C o n t e n t s

GUIDE FOR

SYSTEMS VERIFICATION

CONTENTS

SECTION 1 General ...................................................................................................... 11 Application .......................................................................................... 13 Class Notations ................................................................................... 1

3.1 General................................................................................ ............ 13.3 System Verification Notation .................................... ....................... 13.5 Subsystems and Equipment Under Control..................................... 13.7 Scope of Notation ................................................................ ............ 2

5 Stakeholder Roles and Responsibilities ............................................. 25.1 Roles of Stakeholders ..................................................................... 2

7 Quality Program .................................................................................. 59 Training ............................................................................................... 5FIGURE 1 Example of Scope of Verification and Notation ........................ 2FIGURE 2 Verification Communication Scheme ........................................ 3FIGURE 3 Example of Complex Network Connection, Subsystems,

Equipment Under Control (1/3.5) .............................................. 6SECTION 2 Overview of Verification Process ........................................................... 7

1 General ............................................................................................... 73 Verification Methods ........................................................................... 8

3.1 Software-In-the-Loop Testing .......................................................... 83.3 Hardware-In-the-Loop Testing ......................................................... 93.7 System State Estimation (SSE) ..................................................... 103.9 Other Methods of Verification ........................................................ 10

5 Verification Scope ............................................................................. 105.1 General................................................................................ .......... 105.3 Operational Environment and Envelope ........................................ 125.5 System Hardware Scope ............................................................... 125.7 Functional Scope ................................................................. .......... 125.9 Equipment Under Control Scope ................................................... 12

7 Verification Scenarios ....................................................................... 127.1 Testing of Control System Hardware ............................................. 127.3 Testing of Control System Software, Data and Operations ........... 127.5

Testing of Equipment Under Control ............................................. 12

7.7 Testing Scenarios ................................................................ .......... 12


4/67

iv ABSGUIDE FOR SYSTEMS VERIFICATION .2012

9 Verification of System General Hardware, Firmware andFunctions ........................................................................................... 14

FIGURE 1 System Verification Hierarchy and Scope ................................ 7FIGURE 2 Target Control System and Equipment Under Control ............. 9FIGURE 3 Verification by System State Estimation ................................. 10FIGURE 4 Verification Scope Hardware and Functions ........................ 11FIGURE 5 Example of Failed Signal Reference and Dry Contact

Input ........................................................................................ 13FIGURE 6 System General Hardware and Functions .............................. 14FIGURE 7 System Verification Simulation Connection Points .............. 15

SECTION 3 Control Systems ..................................................................................... 161 General ............................................................................................. 163 Computerized Control Systems ........................................................ 17

3.1 General .......................................................................................... 173.3 Hardware ................................................................................ ....... 173.5 Firmware ........................................................................................ 183.7 Applications ................................................................ ................... 193.9 Parameters .................................................................................... 193.11 Common Time Base ............................................................... ....... 193.13 Redundant/Parallel Processors ..................................................... 203.15 Verification Interface ...................................................................... 203.17 Human Factors and Human Machine Interface (HMI) ................... 203.19 Change Detection ................................................................... ....... 203.21 Fault Detection............................................................................... 20

5 Life Cycle Management and Management of Change ..................... 205.1 General .......................................................................................... 20

FIGURE 1 A Simple Control System ........................................................ 16FIGURE 2 A Computer Based Control System ........................................ 17FIGURE 3 Networked Control System w/all I/O on Network .................... 18FIGURE 4 Networked Control System w/Distributed Processing ............ 19

SECTION 4 Simulator and Simulation ...................................................................... 211 General ............................................................................................. 21

1.1 Simulator .................................. ..................................................... 211.3 Simulation ...................................................................................... 211.5 Simulator and Simulation Development ......................................... 21

3 Simulation Operating Environment & Envelope ................................ 225 Simulator Interface ............................................................................ 22

5.1 General .......................................................................................... 225.3 Hardware in the Loop Simulator Interface ..................................... 225.5 Software in the Loop Simulator Interface ....................................... 22

7 Simulator Validation .......................................................................... 229 Simulator and Simulation Verification and Validation Report ........... 24


5/67

ABSGUIDE FOR SYSTEMS VERIFICATION .2012 v

11 Simulator Lifecycle and Maintenance ............................................... 2411.1 Simulation Management of Change Procedure ............................. 2411.3 Maintenance and Support of Simulator Hardware and

Simulation ................................................................. ..................... 24FIGURE 1 Software in the Loop Simulator Interface Single

Computer ................................................................................ 23FIGURE 2 Software in the Loop Simulator Interface Separate

Computers ............................................................................... 23SECTION 5 Information to be Submitted ................................................................. 25

1 General ............................................................................................. 253 Basic Plan and Information Submission Requirements .................... 265 Operational Procedures .................................................................... 267 Additional Plan and Information Requirements ................................ 26FIGURE 1 Verification Submittal Scheme ................................................ 25

SECTION 6 Verification Plan ..................................................................................... 281 General ............................................................................................. 283 Verification Plan Details .................................................................... 28

3.1 General................................................................................ .......... 285 Updates and Maintenance of the Verification Plan ........................... 30

SECTION 7 Verification Process Details ................................................................. 311 Initiation of Development of the Verification Plan ............................. 313 Description of the Functions of the Control System and

Equipment Under Control ................................................................. 315 Development of Life Cycle Management and Management of

Change Procedures .......................................................................... 337 Selection of Verification Method and Verification Organization ........ 339 Development, Verification and Maintenance of Simulators .............. 3411 System(s) Analysis ........................................................................... 34

11.1 General................................................................................ .......... 3411.3 System(s) Analysis of Process and Equipment Under

Control .......................................................... ................................. 3411.5 System(s) Analysis of Control System Hardware .......................... 3511.7 System(s) Analysis of Control System Software ........................... 3611.9 System(s) Analysis Testing ................................................. .......... 36

13 Verification Plan ................................................................................ 3615 Verification Testing, Findings, Observations and Reporting ............. 3717 Analysis and Evaluation of Verification Testing ................................ 3719 Remediation and Regression Testing ............................................... 3721 Integration Verification Testing ......................................................... 3723 Onboard Testing ............................................................................... 38FIGURE 1 Functional Dependency Diagram Precursors ...................... 32FIGURE 2 Functional Dependency Diagram Function Fan Out............ 33


6/67

vi ABSGUIDE FOR SYSTEMS VERIFICATION .2012

SECTION 8 Management of Verified Systems ......................................................... 391 General ............................................................................................. 393 Life Cycle Management .................................................................... 39

3.1 General .......................................................................................... 393.3 Life Cycle Management Plan ......................................................... 395 Management of Change Process ..................................................... 405.1 General .......................................................................................... 405.3 Management of Change Procedure ............................................... 405.5 Change Detection ................................................................... ....... 415.7 Fault Detection............................................................................... 41

7 Maintenance of SV Class Notation ................................................... 427.1 Casualty, Damage and Emergency Repairs .................................. 427.3 Maintenance and Control of Hardware Spares .............................. 427.5 Repair Log and Disposition of Hardware ....................................... 42

SECTION 9 Survey ...................................................................................................... 431 General ............................................................................................. 433 Initial Assignment of SV Class Notation ........................................... 43

3.1 General .......................................................................................... 433.3 Survey ................................................. .......................................... 43

5 Survey After Construction ................................................................. 445.1 General .......................................................................................... 445.3 Survey ................................................. .......................................... 44

APPENDIX 1 Terminology ............................................................................................ 451 Definitions ......................................................................................... 453 Abbreviations .................................................................................... 485 References ........................................................................................ 50

5.1 Risk Analysis and Reliability .......................................................... 505.3 Other References ..................... ..................................................... 50

APPENDIX 2 Example Documents .............................................................................. 521 Verification Plan Outline .................................................................... 52

1 General .......................................................................................... 522 Introduction .................................................................................... 523 Verification Items ........................................................................... 524 Functions to be Verified ................................................................. 535 Approach .................................................................... ................... 536 Verification Deliverables ................................................................ 537 Verification Environment ................................................................ 53Appendix A Executed Verification Cases ................................................... 53Appendix B Verification Case Trace Matrix................................................ 53Appendix C Verification Baseline ............................................................... 53


7/67

ABSGUIDE FOR SYSTEMS VERIFICATION .2012 vii

APPENDIX 3 Specific Systems.................................................................................... 551 Dynamic Positioning Control Systems (DPCS) ................................ 553 Power Management Systems Dynamic Positioning (PMSDP) ......... 565 Power Management Electric Propulsion (PMSEP) ........................... 577 Continuity of Power and Restoration (CP&R) ................................... 58


8/67

This Page Intentionally Left Blank


9/67

ABSGUIDE FOR SYSTEMS VERIFICATION .2012 1

S e c t i o n 1 : G e n e r a l

S E C T I O N 1 General

1 Application

This Guide has been developed to provide guidance and requirements for the verification of systems. A

verified system provides a higher degree of certainty that the system will perform in a planned and specifiedfashion when in an operational, degraded or failed condition. A particular but not exclusive focus of thisGuide is the black box verification of control systems, be they pneumatic, hydraulic, computer based,

etc. An additional result of system verification may include identification of defects in the equipmentunder control. The requirements as specified in this Guide are additional to all other relevant requirements

of ABS Rules and Guides.

3 Class Notations

3.1 General

The Systems Verification (SV) Notation is optional and when requested, may be granted to vessels, offshoreinstallations or facilities which include system(s) complying with the requirements of this Guide. Systems

that have specific requirements for Classification contained in other ABS Rules and Guides (e.g., dynamicpositioning systems, power management systems, etc.), are to fully comply with those requirements in addition

to the requirements contained in this Guide to obtain the SV Notation. The SVNotation may be assignedto a vessel, offshore installation or facility for systems or functions that do not have specific Class requirements

upon special consideration by ABS.

3.3 System Verification Notation

The SV Notation will take the form:

[SV][System]

where:

[System] will identify the system (target system) or function that has been verified and

The method of verification will be detailed in the Verification Plan.

3.5 Subsystems and Equipment Under Control

Subsystems that are an integral part of the system(s) being verified, (e.g., bilge system, ballast system, fuel oil

storage and transfer system integrated within a larger automation system), are to be included in the verificationprocess, for example see Section 1, Figure 2.

Equipment Under Control (EUC) includes systems, subsystems and controllers separate and distinct fromthe primary target system. Equipment Under Control may have controls separate and distinct from the target

system that have the ability to communicate with the target system. Examples include a fuel oil treatmentsystem consisting of purifiers, filtration equipment, etc.

The System Owner [1/5.1.1(a)] may propose to exclude specific subsystems and/or Equipment Under Control

from the verification process, refer to Section 2, Figure 4. The System Owner is to utilize the SystemsAnalysis Techniques, Subsection 7/11, to demonstrate that when the specific subsystems or Equipment Under

Control proposed to be excluded from the system verification process are in an operational, degraded or

failed condition that their exclusion does not invalidate the verification of the target system(s) being verified.See also 1/3.7, 5/3iii)a), and Subsection 2/5 and 2/7.


10/67

Section 1 General

2 ABSGUIDE FOR SYSTEMS VERIFICATION .2012

3.7 Scope of Notation

The scope of the SV Notation assigned to a vessel, offshore installation or facility is defined by the completionof the verification process in accordance with the ABS reviewed Verification Plan. The SV Notation appliesonly to the hardware, firmware and functions of the target system and Equipment Under Control that are

include in the verification plan, Section 1, Figure 1.

FIGURE 1Example of Scope of Verification and Notation

EXCLUDEDFROMVERIFICATION

EXTENTOFVERIFICATION,HARDWARE

EXTENTOFVERIFICATION,FUNCTION

GENERATORCONTROLFUNCTION

TI1

TI2

TI3

PI1

PI2

LI1

POWER

MANAGEMENTFUNCTIONS

XY1

XY2

XI1

XY2

OTHERFUNCTIONS

XY3

ZLO

ZLC

ENGINE +

GENERATOR

D I

ENGINE CONTROL

NETWORK

SWITCH/

HUB S

OPEN

CLOSE

Instrument Air

Supply

EUC, i.e. Valve with OPEN & CLOSE limit

switches

SUPERVISORYCONTRO

LPROGRAM

COMMUNICATION

N1

S1

N2

S2

PI2

N1

N1

NETWORK CONNECTION

D O

N1

N1

N1

N1

GENERATOR CONTROL

N1

CIRCUIT BREAKER

MULTI FUNCTION RELAY

SWITCHBOARD CONTROL

NETWORK

I/O RACK

A I/O

P

T

420

mA

degC

0250

420

mA

BAR

015

420

mA

M3/hr

02

SERIAL

The following definitions apply to the figure above:

Environmental Maximum The maximum ambient forces acting

Operation Envelope The allowable range of values of the system state for selected operation

Extent of Verification The subset of all possible hardware, firmware, software and equipment

under control that is subject to verificationVerification Scenarios The set of all possible verification scenarios

Scope of Verification - The subset of all possible verification scenarios that are executed

5 Stakeholder Roles and Responsibilities

5.1 Roles of Stakeholders

The stakeholders are defined below. In some cases, a single entity may assume the responsibilities and/or

activities of more than one of the stakeholders, (i.e., The Owner could also be the Operator and/or SystemIntegrator; System Integrator (SI) could also be the Verification Organization, etc.). The activity assignments

clarify the roles and deliverables per stakeholder. The responsibility for an activity may not be delegated;performance of an activity may be delegated. The relationship of the various stakeholders is shown in

Section 1, Figure 2.

ENVIRONMENTALMAXIMUMOPERATIONALENVELOPE

EXTENTOFVERIFICATIONVERIFICATIONSCENARIOS

SCOPEOFVERIFICATION


11/67

Section 1 General


FIGURE 2Verification Communication Scheme

INDEPENDENT VERIFIER

SYSTEM OWNER

SIMULATION

DEVELOPER

VERIFICATION

ORGANIZATION

SYSTEM

INTEGRATOR

SUPPLIERS

OWNERSUPERVISED

COMMUNICATION

CHANNEL

SUPPLIERS

PREFERRED

COMMUNICATION

CHANNEL

SYSTEM OWNERSYSTEM OWNER

SHIP YARD/

OWNER

OWNER/

OPERATOR

The following definitions apply to the figure above:

Preferred Communication Channel Free communication allowed.

Supervised Communication Channel Allowable communication with copy to System Integrator

5.1.1 Owner Organization

The Owner is the entity that provides funding and initiates the project. The Shipyard or Buildermay be the Owner during the construction of the vessel, offshore installation or facility. The Owner is

to have a quality program as described in Subsection 1/7 that is capable of fulfilling the requirementsof this notation.

5.1.1(a) System Owner (SO). The System Owner is the entity that makes the initial request for

classification and is subsequently the entity that is responsible for maintenance of Classification and

maintenance of the optional SV Notation throughout the lifecycle of the vessel, offshore installation

or facility.Upon delivery, the System Owner will typically be the Registered Owner of the vessel, offshoreinstallation or facility as indicated in the ABS Record/ABS Eagle Survey Manager. The SystemOwner is to have a quality program as described in Subsection 1/7 that is capable of fulfilling the

requirements of this notation.

Some of the activities required of the System Owner may be delegated to other entities in whichcase the activity specific requirements would pass from the System Owner to the delegated entity.The responsibility for completion of each System Owner activity will always remain with the SystemOwner.

It is anticipated that the System Owner will change over the course of the life cycle of the vessel,offshore installation or facility as different organizations assume the function of the Registered Owner.An organization planning to assume the responsibilities of the Registered Owner is to coordinatewith the current Registered Owner to facilitate the assumption of the responsibilities and activitiesof the System Owner.


12/67

Section 1 General


5.1.2 Verification Organization

The Verification Organization is to be selected by the System Owner. Selection of the VerificationOrganization is to be in accordance with Subsection 7/7; the selection will be reviewed by ABS. The

Verification Organization is to have a quality program as described in Subsection 1/7 that is capable

of fulfilling the requirements of this notation. The Verification Organization is to verify the

systems in accordance with the Verification Plan (see Section 6). The Verification Organization maybe part of the System Integrators, or a control system developer organization or may be independent,

as directed by the System Owner.

i) Verification Organization Independence. It is recognized that a third party that is independent

of the system procurement process is a preferred entity for performance of verificationtesting. ABS also recognizes that if a system developer or integrator has a quality programas described in Subsection 1/7, self verification may be acceptable if the verification process

meets all of the Class requirements for the SV Notation and the members of the verificationteam are themselves part of a separate group within the organization and have not participatedin the development of the control system or integration process. ABS will audit the

Verification Organization to verify the above and ABS will Survey the verification process.In all cases, the relationship of the Verification Organization to the maker and integrator

will be explicitly indicated in the Verification Plan.

5.1.3 Simulator Developer

The Simulator Developer develops the simulation and the simulator (Section 4). The SimulatorDeveloper may be the Verification Organization. The Simulator Developer is to have a quality

program as described in Subsection 1/7 that is capable of fulfilling the requirements of this notation.

5.1.4 Independent Verifier Organization

Monitors involved parties, including Suppliers for compliance with this Guide. The Independent

Verifier is to have a quality program as described in Subsection 1/7 that is capable of fulfilling the

requirements of this notation. For the purposes of the SV Notation, ABS is the Independent Verifier.

5.1.5 System Integrator

The System Integrator is responsible for managing the development of the integrated system, be

the constituent components from a single maker or multiple makers. The System Integrator isresponsible for global design of the integrated system, supplier management, and integration. The

System Integrator or Shipyard is not to transfer responsibilities when delegating System Integrator

activities to a third party. If the project size does not warrant a System Integrator, then theseresponsibilities are to be taken by the System Owner, Operator or a Supplier organization as

selected by the System Owner. The System Integrator is to have a quality program as described in

Subsection 1/7 that is capable of fulfilling the requirements of this notation.

It is recommended that the System Integrator and the Shipyard make Suppliers aware of the

verification requirements and activities.

5.1.6 OperatorThe Operator is the user of the integrated system(s) and the Operator could also be the Owner orSystem Owner. The Operator is to have a quality program as described in Subsection 1/7 that iscapable of fulfilling the requirements of this notation.

5.1.7 Supplier or Subcontractor

The Supplier is any contracted or subcontracted provider of components, equipment or software

under the coordination of the System Integrator or Shipyard. The Supplier is to provide specificationand constraints of the package(s) being supplied. The component may be custom built or a stock

component. The Supplier or Subcontractor is to have a quality program as described in Subsection1/7 that is capable of fulfilling the requirements of this notation.


13/67

Section 1 General


5.1.8 Shipyard Organization

The Shipyard is to contract with a System Integrator or may use a division within the ShipyardOrganization if the division meets the requirements listed for the system integrator. The shipyard

is to have a quality program as described in Subsection 1/7 that is capable of fulfilling the requirements

of this notation.

7 Quality Program

Throughout this Guide, reference is made to the quality program of the various Stakeholders. Each Stakeholder

quality program is to be appropriate for the activities and responsibilities of the Stakeholder in the system

verification process. The quality program is to be based upon the principles of the ISO 9001 series ofstandards as is applicable to the activity being performed by each Stakeholder. Quality programs may be

augmented with Capability Maturity Model Integration (CMMI) Level 2 maturity level and ISO 20,000series of standards if applicable to the activities being performed.

In addition, the following requirements for delivered products are applicable for each product, whether theproduct is hardware, firmware or software, equipment or subsystems:

i) Life Cycle Management Plan (see Subsection 8/3)ii) Management of Change Procedure (see Subsection 8/5)

iii) Training, as described in Subsection 1/9

ABS will review the quality program to verify that it includes the elements mentioned above and to verify

that the quality program is capable of providing support throughout the service life of the vessel, offshoreinstallation or facility.

9 Training

Each Stakeholder is to provide training to their staff in accordance with their quality system that is appropriate

and adequate for the activities and responsibilities of the Stakeholder in the system verification process.


14/67

FIGURE 3Example of Complex Network Connection, Subsystems, Equipment Under C

6

ABSGUIDEFOR

SYSTEMSVERIFICATION

.

2012


15/67


S e c t i o n 2 : O v e r v i e w o f V e r i f i c a t i o n P r o c e s s

S E C T I O N 2 Overview of Verification Process

1 General

The verification of systems extends the existing practice of Classification to provide a higher degree of

confidence that the systems are capable of and do function in a planned and specified fashion under a varietyof states. The hierarchy of the Verification Process is depicted in the figure below.

FIGURE 1System Verification Hierarchy and Scope

LOGIC

SOFTWARE

VESSEL

SYSTEMS

HULL COMPARTMENT MACHINERY CONTROL SYSTEMS ELECTRICAL

EQUIPMENT CONTROL

HARDWARE

LOGIC

CONTROL EQUIPMENT

HARDWARE

HARDWARELOGIC

EXTENT OF SYSTEM VERIFICATION

`

EXTENT

OF

SOFTWARE VERIFICATION

EXTENT OF HARWARE in the LOOP TESTING

OUTSIDE of VERIFICATION

SCOPE

SOFTWARE

LOGIC

SOFTWARE

OPERATIONAL ENVELOPE

EXTENT OF VERIFICATION

VERIFICATION SCENARIOS

SCOPE OF

VERIFICATION

The SV Notation is also available to verify systems that do not have Classification requirements (see 1/3.1)on a case-by-case basis upon request. The verification process relies upon the steps identified below. The

ordering of the steps is suggestive and many of the steps may be performed concurrently to facilitate a timelyconclusion of the process. A more detailed description of the verification process is presented in Section 7.

1. The System Owner initiates development of the Verification Plan (Subsection 7/1)

2. Development of a functional description for each of the control systems and the Equipment UnderControl (Subsection 7/3)

3. Development of Life Cycle Management Plan and Management of Change Procedures(Subsection 7/5)

4. Selection of a verification method and Verification Organization (Subsection 7/7)


16/67

Section 2 Overview of Verification Process


5. Development and Verification of Equipment Under Control simulation and interface to control system(Subsection 7/9)

6. Development and performance of System(s) Analysis utilizing techniques such as FMECA, Fault

Tree Analysis (FTA) and Markov Techniques (MT) for the controlled system(s) and control system(s)including hardware, firmware, software, communication media and networks (Subsection 7/11).

7. Completion of Verification Plan from System(s) Analysis and functional description (Subsection 7/13)

8. Verification, FAT, FMECA and System(s) Analysis testing including recording of result(Subsection 7/15)

9. Analysis, evaluation and classification of testing results (Subsection 7/17)

10. Monitoring remediation of defects and Regression Testing as required (Subsection 7/19)

11. System Integration Verification Testing (Subsection 7/21)

12. On Site Integration Testing (Subsection 7/23)

3 Verification Methods

The method of verification is to be specified by the System Owner in the Verification Plan utilizing a method

or combination of the methods identified in this Guide. Verification scenarios (Subsection 2/7) are to be

described in the Verification Plan and are to be sufficient to verify the systems to:

i) ABS Rules

ii) The requirements of this Guide

iii) Regulatory requirements

iv) Any specific System Owner/Operator requirements

3.1 Software-In-the-Loop Testing

In Software-In-the-Loop verification, the control systems program is being executed on non-native hardwareand the simulation is being executed on the same or a separate computer. Software-In-the-Loop verification

does not verify the networked connections, input or output hardware modules, or the processor unless the

item is included in the simulation. The Equipment Under Control is represented by models that include bothmathematical and logical functions in the simulation program. The simulation should be of sufficient fidelity

to allow the control system emulation to operate as if it were connected to the Equipment Under Control

without superfluous alarm and to exercise functions whose operation is dependent upon parameter valuesand/or scheduled execution timing.. Software-In-the-Loop verification allows for a number of scenarios to

be run to test the integrated systems code and allows for evaluation of system alternatives. Refer toSection 2, Figure 4, and Section 4, Figures 1 and 2.


17/67



FIGURE 2Target Control System and Equipment Under Control

3.3 Hardware-In-the-Loop Testing

In Hardware-In-the-Loop verification, the integrated systems program is being executed on its native hardware(native processor, native firmware) and the simulation is being executed on a separate machine. The EquipmentUnder Control is represented by models that include both mathematical and logical functions in the simulation

program. The simulation should be of sufficient fidelity to allow the control system emulation to operateas if it were connected to the Equipment Under Control without superfluous alarm and to exercise functions

whose operation is dependent upon parameter values and/or scheduled execution timing...

Hardware-In-the-Loop verification may allow for the verification of communication networks utilized by

the systems dependent upon the point of coupling of the simulation to the control system (refer to Section 2,Figure 7 and 4/5.3).

Hardware-In-the-Loop verification does allow for a number of scenarios to be run to test the integratedsystems code and allows for evaluation of system alternatives.


18/67



3.7 System State Estimation (SSE)

System State Estimation utilizes the estimation of system state by the control system to provide input to

coordinated programmed system state variable manipulation and process stimulation. Proposals for use ofSSE verification method should be discussed with ABS as early as possible for review prior to execution.

FIGURE 3Verification by System State Estimation

PROCESS CONTROLLER

G(X)PROCESS

SET POINTESTIMATION of SYSTEM STATE

PROGRAMMED SIGNAL MANIPULATION

PROCESS VARIABLE(s)MANIPULATED PROCESS VARIABLE (S)

PROCESS STIMULATION

PROCESS VARIABLE(s)PROCESS STIMULATION

MANIPULATED PROCESS VARIABLE (S)

3.9 Other Methods of Verification

Acceptance of other methods of verification will be at the sole discretion of ABS upon review of a satisfactory

proposal.

5 Verification Scope

5.1 General

The scope of verification is to be determined by the System Owner with input from the Operator, SystemIntegrator, Shipyard, Suppliers and ABS [see 1/3.5, 2/5.7 and 6/3.1vii)].

The Verification Scope is defined by:

i) The operational envelope of the verified system

ii) The extent of verification of the elements constituting the verified system

iii) The verification testing scenarios executed on the selected elements that make up the verified system

In developing the scope of verification, the System Owner is to:

i) Identify the operational envelope of the verified system

ii) Identify the extent of the elements of the verified system

a) Control system hardware

b) Control system functions

c) Equipment Under Control


19/67



FIGURE 4Verification Scope Hardware and Functions

EXCLUDED FROM VERIFICATION

EXTENT OF VERIFICATION, HARDWARE

EXTENT OF VERIFICATION, FUNCTION

GENERATOR

CONTROL

FUNCTION

TI1

TI2

TI3

PI1

PI2

LI1

POWER

MANAGEMENT

FUNCTIONS

XY1

XY2

XI1

XY2

OTHER

FUNCTIONS

XY3

ZLO

ZLC

ENGINE +

GENERATOR

D I

ENGINE CONTROL

NETWORK

SWITCH/

HUB S

OPEN

CLOSE

Instrument Air

Supply

EUC, i.e. Valve with OPEN & CLOSE limit

switches

SUPERVISORYCONTROLPROGRAM

COMMUNICATION

N1

S1

N2

S2

PI2

N1

N1

NETWORK CONNECTION

D O

N1

N1

N1

N1

GENERATOR CONTROL

N1

CIRCUIT BREAKER

MULTI FUNCTION RELAY

SWITCHBOARD CONTROL

NETWORK

I/O RACK

A I/O

P

T

420

mA

degC

0250

420

mA

BAR

015

420

mA

M3/hr

02

SERIAL

iii) Identify the testing scenarios to be utilized

To develop the scope of verification, the System Owner is to:

i) Utilize:

a) Safety reviews, System(s) Analysis (FMECA, FTA, etc) to determine consequence of thecontrol system in a degraded or failed condition and rank the EUC

b) Safety reviews, System(s) Analysis (FMECA, FTA, etc) to determine consequence of anEUC in a degraded or failed condition and rank the EUC

c) The EUC functions to be tested

ii) Rank each system function having undesirable consequences when degraded or failed utilizing the

following considerations:

a) Safety

b) Environmental

c) Although not a requirement of this Guide, it is recommended that the possible businessimpacts be considered when ranking the EUCs.

OPERATIONAL ENVELOPE

EXTENT OF VERIFICATION

VERIFICATION SCENARIOS

SCOPE OF

VERIFICATION


20/67



5.3 Operational Environment and Envelope

The operational envelope referrers to the values of simulation modeled system parameters that are passed

to the control system for action. For example:

i) Dynamic Positioning System. Position, heading, draft, wind velocity, track, required position

ii) Power Management. System load per bus and aggregated, generation (consumed and reserve) onlineper bus and aggregated, system voltage, system frequency

iii) Temperature Control. Process set point, process temperature, heating/cooling medium temperature,

flow rate, pressure

5.5 System Hardware Scope

The system hardware verification scope is defined by the envelope and extent subject to verification by theexecution of verification scenarios, as shown in Section 2, Figure 4. For example if the control system

networks, communication links, sensors and signal conditioners (converters) are included in the verification.

5.7 Functional Scope

The scope of the functional verification is defined by the envelope and extent subject to verification by theexecution of verification scenarios, as shown in Section 2, Figure 4. System functions that are excludedfrom the test scope are listed in 1/3.5 and 6/3.1vii).

5.9 Equipment Under Control Scope

The scope of the Equipment Under Control verification is defined by extent of the Equipment Under Control

that are subject to verification and the verification scenarios executed. Equipment Under Control may beexcluded from the verification plan; this is discussed in 6/3.1vii).

7 Verification Scenarios

Verification scenarios are developed from the System Analysis (see Subsection 7/11) and other analysis

and evaluations of the control system(s) and equipment under control.

7.1 Testing of Control System Hardware

Thebasis for the hardware testing scenarios of the control system hardware should be developed in theSafety Reviews, System(s) Analysis (FMECA, FTA, etc.). The testing procedure of control system hardware

should be developed in the verification plan and include other relevant scenarios as appropriate.

7.3 Testing of Control System Software, Data and Operations

The basis for the functional testing scenarios of the control system software should be developed in the

Safety Reviews, System(s) Analysis (FMECA, FTA, etc.). The testing procedure of control system softwareshould be developed in the verification plan and include other relevant scenarios as appropriate.

7.5 Testing of Equipment Under Control

The basis for the testing scenarios of the Equipment Under Control should be developed in the Safety

Reviews, System(s) Analysis (FMECA, FTA, etc.). The testing procedure of the Equipment Under Control

should be developed in the verification plan and include the interface, commands data and include otherrelevant scenarios as appropriate.

7.7 Testing Scenarios

7.7.1

Operational testing scenarios including:

i) Switching between control stations, as applicable, refer to the ABS Rulesii) Switching between operational units, (i.e., Fuel Oil Pump No. 1 to No. 2)ii) Other testing appropriate to the system under test the operating environment & envelope


21/67



iii) Switching between operational units, (i.e., Fuel Oil Pump No. 1 to No. 2)

iv) Other tests as specified by the Owner/Operator

v) FAT testing incorporated into the scope of the verification process

vi) Safety Reviews, System(s) Analysis (FMECA, FTA, etc.) testing incorporated into the scope

of the verification process

7.7.2

Non-operational or degraded testing scenarios to be developed from the Safety Reviews, System(s)

Analysis (FMECA, FTA, etc.) and other analysis as appropriate to the circumstances:

i) Power supply failure (loss of power) and system restart

iii) Over and under ranging of analog values

iv) Failure of system set point (signal reference), see Section 2, Figure 5

v) Value does not change over a given period of time (stuck sensor), as applicable

vi) Input of mutually exclusive inputs (e.g., a valve with open & closed limit switches indicating

the valve is full open and full closed at the same time), see Section 2, Figure 5vii) Failed communication between the target control system and the Equipment Under Control

viii) Failed communications, expected results of the scenarios

ix) Loss of one processor of the control system (if redundant)

x) Loss of one processor of the Equipment Under Control (if redundant), as applicable

FIGURE 5Example of Failed Signal Reference and Dry Contact Input

0 24

Volts

mA

4-20

SIGNAL CONVERTER A PROGRAMMABLE ELECTRONIC COMPUTER (PEC) CONTROLLED FUNCTION

BREAK in

POTENTIOMETER

0 24

Volts

mA

4-20

SIGNAL CONVERTER B

STATION A

In COMMAND

STATION B

In COMMAND

FUNCTION DESCRIPTION A B

89 STATION A IN COMMAND X

90 STATION B IN COMMAND X

STATION IN COMMAND

SYSTEM SET POINT/

SIGNAL REFERENCE

UTILZATION of SINGLE or

MULTIPLE SIGNAL REFERENCE

7.7.3

Failed component(s)

i) Failsafe states

7.7.4

Other scenarios as directed by the System Owner


22/67



9 Verification of System General Hardware, Firmware and Functions

Hardware, firmware and functions within systems that are used repeatedly without change may be verifiedone time, subject to periodic audit and survey upon request of system developers or system integrator. The

system developer or system integrator will need to demonstrate that changes to the balance of the system

will not invalidate the verification system general hardware, firmware and functions. The requirements ofClassification and this Guide including management of change and verification required as a result of

change are to be complied with for the function, refer to Section 8 and Subsection 8/5. Vessel specificverification is to be performed in accordance with the ABS reviewed Verification Plan.

FIGURE 6System General Hardware and Functions

GENERAL FUNCTIONS/SOFTWARE

GENERAL HARDWARE

OPERATING SYSTEM

COMMUNICATION

SV PORT

HMI PORT

N2

N1

PWR SUP 1

BACKPLANE

PWR SUP 2

PROCESSOR

FUNCTION

FUNCTION

SU

PERVISORY

CONTROL

APPLICATION

FUNCTION

FUNCTION

MEMORY

HDD

In order to facilitate the development of control systems, control system developers and integrators arerecommended to have a management of change procedure for their control system development environment.


23/67

FIGURE 7System Verification Simulation Connection Points

ABSGUIDEFOR

SY

STEMSVERIFICATION

.

2012

15


24/67


S e c t i o n 3 : C o n t r o l S y s t e m s

S E C T I O N 3 Control Systems

1 General

This Section of the Guide addresses both individual/stand alone control systems as well as the integration of

multiple individual/stand alone control systems into a larger system. An example of a standalone controlsystem is shown in Section 3, Figure 1. An example of an integration of control systems is shown in Section 3,Figures 2, 3 and 4.

FIGURE 1

A Simple Control SystemFEED FORWARD

T,P,F

VALVE

POSITIONER

INNER PROCESS VARIABLE

VALVE POSITION

PROCESS

CONTROLLER

(INNER LOOP)

CASCADE

OUTER PROCESS VARIABLE

T,P,F

PROCESS

CONTROLLER

(OUTER LOOP)

CASCADE

T,P,F

OUTER

PROCESS

SET POINT

FEED FORWARD

CONTROLLER

INNER PROCESS SET POINT

Multiple individual/stand alone control systems may be from a single vendor or multiple vendors utilizingvarying technology such as pneumatic, hydraulic, electrical, electronic and programmable electronic. Often,a control system will be constructed from the integration of the multiple technologies mentioned above,

utilizing programmable electronic computers for certain functions and hard wired electric mechanical relays,pneumatics, hydraulics, etc., for other functions.

Rules for control systems are located in the ABSRules for Building and Classing Steel Vessels (Steel Vessel

Rules). Rules for Remote Propulsion Control and Automation are contained in Part 4, Chapter 9. Rules forRemote Control and Monitoring for Auxiliary Machinery and Systems Other Than Propulsion are contained

in Part 4, Chapter 10. Additional requirements for specific systems are located throughout the Steel Vessel

Rules.


25/67

Section 3 Control Systems


3 Computerized Control Systems

3.1 General

Computerized Control (Section 4-9-6 of the Steel Vessel Rules) systems are an assembly of hardware, firmware,

software that operate a process(s) or system(s). In some instances, an interface is provided that may becapable of reporting the status and condition of the process(s) or system(s) controlled and may be allow forthe adjustment of the operation of the process(s) or system(s).

FIGURE 2A Computer Based Control System

It is recommended that the control system have some agreed upon capacity for future expansion.

The specific implementation of the hardware, firmware, software is widely varied; in some instances all of theelements can be contained in a single (or few) device(s) located in close proximity to each other. In otherinstances the elements may distributed throughout the vessel; interconnected via dedicated direct wiring(home run), a serial communication link, a wired or wireless communication network (Ethernet), etc. (see

Section 3, Figures 3 and 4).

3.3 Hardware

Rules for control systems hardware are described in Part 4, Chapter 9 and more specifically in 4-9-6/7,Appendix 4-9-6A1 and Section 4-9-7 of the Steel Vessel Rules. The hardware of the control system and

ancillary devices should be designed and manufactured to an appropriately applied recognized standardthat is acceptable to the ABS.

Computerized control systems typically contain some or all of the following hardware elements: rack, power

supply, processor, process input/output, measurement, control, HMI input/output, network communicationand fault detection/annunciation capability, firmware and application software. The hardware components

of the control system are to be suitable for the ambient environment in which they are installed and utilizedand they are to be suitably selected and applied for the specific application. Utilization of Type Approved

hardware will facilitate the control system review process. Utilization of Type Approved hardware does noteliminate the need for engineering review of the hardware for the specific application.


26/67



FIGURE 3Networked Control System w/all I/O on Network

OPERATOR STATION

(HMI)

PROCESS STATION

No. 1

OPERATOR STATION

(HMI)

DI

DO

N1

AI/O

BACK PLANE

N2

PWRSUP2

SERIAL

NETWORK I/O RACK

N1 + N2 CONNECTION

PWRSUP1

PROCESS STATION

No. 2

NETWORK No. 2

NETWORK No. 1

NETWORK I/O RACKN1 + N2 CONNECTION

CONTROL NETWORK EXHIBITING REDUNDANT NETWORKREMOTE I/O AND REDUNDANT PROCESS STATION

3.5 Firmware

Rules for control systems firmware (software) are described in Part 4, Chapter 9 and more specifically in

4-9-6/7, Appendix 4-9-6A1 and Section 4-9-7 of the Steel Vessel Rules. The firmware of the control systemhardware consists of computer instructions and data that is closely tied to specific versions of the hardware

and allows the hardware to function with application software. Firmware is usually embedded in non volatileread only memory.


27/67



FIGURE 4Networked Control System w/Distributed Processing

DI

DO

N1

AI/O

N2

PWRSUP2

SERIAL

PWRSUP1

3.7 ApplicationsRules for control systems software are described in Part 4, Chapter 9 and more specifically in 4-9-6/9 and

Appendix 4-9-6A1 of the Steel Vessel Rules Applications are the software or computer code that run on thehardware under the supervision of the operating system.

Applications may be developed with the intention of operating on a specific hardware platform or may be

developed with the capability of operating on a variety of hardware platforms. Applications are developed

in varying environments that may include graphical and other software tools. Application developmentenvironments are themselves specialized applications that have been constructed to allow for the programmingof the control system in a rapid, reliable and economical manner.

One facility of application development tools is the ability allow for the development of functional blocks ofsoftware code (sub programs, sub routines, etc.) that can be reliably and repeatedly used and the ability to

interconnect the functional blocks in a meaningful manner that in fact is the logic of the control system. Theability of software development applications to allow for the reuse of software code (functional blocks) in

lieu of starting from scratch each time a function is required provides the ability to accelerate the applicationdevelopment process, refer to Subsection 2/9.

3.9 Parameters

Values of parameters are determined by the environment, envelope and the Owner of the applicable systems.

3.11 Common Time Base

It is recommended that control systems and integrations of control systems for which SV Notation is requestedshould be synchronized to a common time base; it is recommended that the common time base be the vessel

central clock or time base used by navigational systems. The common time base should propagate down tothe lowest level components of the systems that keep time. The common time base is used for reporting

and to assist in fault diagnosis.


28/67



3.13 Redundant/Parallel Processors

If redundant or parallel processors or automatic control systems are fitted; it is recommended that the redundant

automatic control systems be independent, self monitoring and arranged such that, should one fail, controlis automatically transferred to a non failed automatic control system.

3.15 Verification InterfaceIt is recommended that control system manufactures and/or control system integrators provide built in

dedicated verification interface ports to facilitate for verification, refer to Section 2, Figure 7. Verification

ports should exist for controlled system (process) simulation and for control system HMI simulation. Theverification interface is to be documented and shall be included in the System Analysis. The verification

interfaces may be used at the makers works as well as after the control system is installed, allowingverification activities to proceed, possibly without the need to physically disconnect the control system from

control networks and controlled systems. It is further recommended that the verification interfaces besuitably configured to allow for the verification testing of the control system and equipment under control

while installed and accommodate multiple/parallel processors.

3.17 Human Factors and Human Machine Interface (HMI)

The (HMI) consisting of some combination of tactile screens, push buttons, knobs and levers, indicating gaugesand meters is a window for the operator into the control system(s) and the equipment under control. The

HMI allows for observation, operator intervention and remote manual control of the control system and theEquipment Under Control.

Management of the amount of information transmitted to the operator for action is highly encouraged. Theprocess(s) or system(s) being controlled may be so many, so complex, so extensive, computationally intensive

that it is effectively impossible for an operator to see the big picture, understand all that is happeningin real time and to be able to provide supervision and control. It is recommended that HMI development

consider Human Factors to facilitate operator understanding of the information being provided, operator

manipulation and interaction with the control system and to provide for minimization of operator interventionerror. With multiple monitors programmed with tens or hundreds of pages of graphical information the rateof operator required intervention during casualties should be determined and control systems should bedesigned to limit the number of interventions to that which an operator can effectively handle.

3.19 Change Detection

Please refer to 8/5.5.

3.21 Fault Detection

Please refer to 8/5/7.

5 Life Cycle Management and Management of Change

5.1 General

There is to be a life cycle management program and a Management of Change Procedure for the control

system. Requirements of Life Cycle Management and Management of Change are contained in Section 8.Details of the requirements for Life Cycle Management are contained in Subsection 8/3. Details of the

requirements for Management of Change are contained in Subsection 8/5.


29/67


S e c t i o n 4 : S i m u l a t o r a n d S i m u l a t i o n

S E C T I O N 4 Simulator and Simulation

1 General

1.1 Simulator

Simulators are the computer hardware, firmware and operating system (software) that run computer codeknown as a simulation.

1.3 Simulation

Simulation is the program (code) developed from models that include both mathematical and logical functions,

interface requirements and commands to simulate the Equipment Under Control. The simulation is to includethe capability to execute scenarios that are used to verify the systems under test. The simulation should beof sufficient fidelity to allow the control system or control system emulation to operate as if it were connected

to the Equipment Under Control without superfluous alarm and to exercise functions whose operation isdependent upon parameter values and/or time; examples include consequence analyzers, control loops with

proportional/ integral/derivative (PID) control, with or without feed-forward and/or cascade control, KalmanFiltering, etc..

1.5 Simulator and Simulation Development

Development of the simulation is to take into account the functional scope and the intended use of thesimulation. The simulator and simulation is to be developed based upon the requirements below:

i) Simulator and simulation development is to be guided by the intended use of the simulation, the

accuracy and required operating envelope (see 2/5.3).

ii) Simulator and simulation development is to be specific to the vessel, offshore installation or facilityfor which the SV Notation is requested and is to be based upon system specifics and the EquipmentUnder Control.

iii) The simulation is to be built from the functional description which is included in the Verification Plan.

iv) The simulation is to be built from the functional description of control system and Equipment Under

Control

v) The simulation is to be different than any simulation or mathematical models utilized within the control

system

VERIFICATION NOTE: Simulations utilizing the same models may be specifically approved for limited use by ABS for

verification testing of specific functions within a larger control system, for example ship and thrustermodel and interaction in a dynamic positioning system where it is desired to test the functionality ofthe dynamic positioning system consequence analyzer (see 2/3.7, System State Estimation).

vi) The simulation execution speed is to be selected appropriate to the nature of the control system,

interfaces and the Equipment Under Control.

vii) The simulation is to be verified and validated to the requirements of 4/1.5i) through 4/1.5vi) aboveand Subsection 4/7 and verified to operate on specific simulator hardware and firmware prior tocontrol system verification activities. Verification of simulator hardware and firmware to include all

relevant simulation computer hardware, networking devices, etc.

viii) The simulator is to present and allow for the presentation and manipulation of information in a readily

understood manner.


30/67

Section 4 Simulator and Simulation


ix) Changes to the simulator hardware or firmware requires the Verification Organization to:

a) Verify the simulation for correct operation on the new hardware or firmware.

b) Validate the operation of the simulation on the simulator.

c) If the simulator hardware and firmware does not change, re-verification/validation is not

required of an unchanged simulation.

3 Simulation Operating Environment & Envelope

The simulation developer is to define the operating envelope of the simulation; identifying operating regionsand parameters where the simulation is proposed to be accurate and regions where the simulation is not valid(refer to 2/5.9).

5 Simulator Interface

5.1 General

The simulator and target system are to be provided with:i) An interface that is suitable for communication

ii) The interface between the target system and the simulator is to be tested and verified to confirm that

the interface allows for proper communication between the simulator and the control system(s).

iii) The interface verification plan is to be made a part of the Verification Plan (see Section 6).

5.3 Hardware in the Loop Simulator Interface

The interface between the target control system and the simulator is depicted in Section 2, Figure 7 and

may be:

i) Dedicated Simulator Interface Port on the target control system

ii) Target control system communication connections that may include one or more of the following:network, serial port, etc.

iii) Target control system network

5.5 Software in the Loop Simulator Interface

The interface between the emulation and the simulator may be:

i) Control system emulation and Equipment Under Control simulation running on single computer,(see Section 4, Figure 1).

a) Data transfer between emulation application and simulation application

ii) Control system emulation and Equipment Under Control simulation running on different computers,

(see Section 4, Figure 2).

a) Communication connection (network, serial port, etc.)

7 Simulator Validation

The simulator developer is to validate the simulation. The simulator developer is to submit the proposedmethod of simulator validation to ABS for review. Validation of the simulation is to:

i) Verify the simulation coding, parameters and data

ii) Validate the simulation programming to confirm that it is appropriate for the intended use

a) Defining the operating environment and envelope of the Equipment Under Control

b) Identifying regions where the simulation is proposed to be accurate and regions where thesimulation is not valid


31/67



iii) Validate that the simulator and simulation programming has sufficient fidelity to verify the functions

of the control system and the functions of the Equipment Under Control

iv) Validate the simulation to the specific simulator hardware

v) Validate simulation parameters

vi) Validate the simulator interface to the target(s) that the simulator can connect to the target(s) withouterror or alarm

FIGURE 1Software in the Loop Simulator Interface Single Computer

FIGURE 2Software in the Loop Simulator Interface Separate Computers


32/67



9 Simulator and Simulation Verification and Validation Report

The Simulator and Simulation Developer is to prepare a Simulator and Simulation Verification and Validation

Report. The report is to be submitted via the System Owner to ABS for review. The report is to include:

i) The scope and the intended use of the simulation correlated with the functional description of the

control system and the Equipment Under Control

ii) The mathematical models and approximations used in the development of the simulation

iii) The process of conversion of the mathematical models into computer code

iv) The simulation parameters and data

v) The method used to verify the simulation (see Subsection 4/7)

vi) Results of the verification of the simulation coding

vii) Simulation operating environment, envelope and accuracy

viii) The method used to validate the simulator interface to target(s) and result of validation

ix) The hardware, firmware and software of the simulatorx) The method used to identify change to the simulator

The report details are to explicitly define the operating environment and envelope of the simulator identifying

regions where the simulation is proposed to be accurate and regions where the simulation is not valid.

VERIFICATION NOTE: Additional details of simulation are provided in Subsection 7/9.

11 Simulator Lifecycle and Maintenance

The simulator, consisting of the simulation code and the simulator hardware is to remain available andfunctional throughout the life of the control system to allow for verification of the control system and theEquipment Under Control in the event of change to either the control system or the Equipment Under Control.

Alternately, simulator hardware may be upgraded over time to reflect newer technologies and capabilities;in such a case the simulation will need to be validated to the new simulator platform. Verification may be

at the request of the System Owner or at the direction of ABS upon notification of change in accordance

with the system Management of Change Procedure.

11.1 Simulation Management of Change Procedure

The Simulator Developer is to develop a Management of Change Procedure to control change to the simulationand the simulator.

11.3 Maintenance and Support of Simulator Hardware and Simulation

The simulation is to be verified and validated for use on the simulator hardware each time the systems are

to be verified unless no change has occurred to both the simulation and the simulator. Refer to Subsections

4/7 and 4/9.


33/67


S e c t i o n 5 : I n f o r m a t i o n t o b e S u b m i t t e d

S E C T I O N 5 Information to be Submitted

1 General

It is recommended that all information be submitted electronically to ABS. However, hard copies will alsobe accepted.

The scope of plans and data that are required to be submitted is to be adequate for the purpose of systemverification; as a minimum the plans and data required are to meet the classification requirements containedin the ABS Rules that are applicable to the system(s) to be installed aboard the vessel, offshore installationor facility for which the SV Notation has been requested and any additional requirements of this Guide.Plans, data and other documents are to be specific to the vessel, offshore installation or facility and to the

system that is being verified. The plans are to clearly describe the materials, components, equipment andsystems to be provided including the specific model number and catalog number with all supplied options andvariants identified. Individual components, equipment and systems are to be uniquely and uniformlyidentified throughout all plans, data and documentation.

It is the responsibility of the System Owner to make all submissions, execution of this activity may be delegated.

It is recommended that the initial System Owner make provision with all suppliers to insure that all futureSystem Owners will have permission to fully access those submissions throughout the lifecycle and toutilize those submissions in fulfillment of the responsibilities of maintenance of the SV Notation.

FIGURE 1Verification Submittal Scheme

INDEPENDENT VERIFIER

SYSTEM OWNER

SIMULATION

DEVELOPER

VERIFICATION

ORGANIZATION

SYSTEM

INTEGRATOR

SUPPLIERS

OWNER

VERIFICATION SUBMITTAL FLOW

AND

COMMUNICATION CHANNEL

SUPERVISED

COMMUNICATION

CHANNEL

SUPPLIERS

PREFERRED

COMMUNICATION

CHANNEL

SYSTEM OWNERSYSTEM OWNER

SHIP YARD/

OWNER

OWNER/

OPERATOR


34/67

Section 5 Information to be Submitted


3 Basic Plan and Information Submission Requirements

The following plans, data and manuals are to be submitted for review by ABS.

i) List of proposed submissions and timeline of submissions coordinated with the production/ delivery

schedule

ii) Functional Description of the target control system for all modes of operation

iii) Functional description of each piece of Equipment Under Control that may have an impact on the

target control system for all modes of operation.

a) See 1/3.7 for comments on the Extent of Notation and 1/3.5 on Equipment Under Control

iv) Plans, schematics and manuals that provide a functional description and operational sequence ofthe Equipment Under Control for all modes of operation

v) Plans, schematics and manuals that provide a functional description and operational sequence of thecontrol system(s) hardware, firmware and software for all operating modes, (e.g., transfer of controlbetween the engine control room and the bridge and between different maneuvering stations on

the bridge)

vi) Plans, schematics and Manuals for the integration of the target control system (including subsystems)and the Equipment Under Control for all modes of operation

VERIFICATION NOTE: The functional description may be included as part of other documents known as theConcept of Operations Document, Software Requirements Specification and Software

Design Specification. See Section 7.

vii) Schematic and functional block diagrams that identify the arrangement and interconnections among:power supply, internal network, external communications, media converters, sensor topology, functions

mapping to hardware components, and signal and message flow of all of the components of thecontrolled system. These diagrams should represent each operating mode of the system under control.

viii) Systems Analyses such as Failure Mode Effect and Criticality Analysis (FMECA), Fault Tree Analysis

(FTA) of the target control system(s) and the Equipment Under Control and the integration asapplicable, including functional dependency diagrams

VERIFICATION NOTE: Refer to Subsection 7/11 for additional details.

5 Operational Procedures

The following operational procedures are to be submitted for review by ABS.

i) Life Cycle Management Plan (see Subsection 8/3)

ii) System Management of Change Procedure (see Subsection 8/5)

iii) Simulation Software Development Life Cycle Plan (see Subsection 4/11)

iv) Simulation and Simulator Management of Change Procedure (see Subsection 4/11)

v) Verification Plan (see Section 6 and Appendix 2)

a) Changes to the Verification Plan (see Subsection 6/5)

7 Additional Plan and Information Requirements

The following plans or information are to be submitted for review if applicable:

i) The System Owner Quality Plan (see 1/5.1.1 and Subsection 1/7) including quality plan for the

Shipyard while it is acting as the System Owner during construction

ii) Verification Organization Quality Plan (see 1/5.1.2 and Subsection 1/7)

iii) Operator Quality Plan (see 1/5.1.6 and Subsection 1/7) if distinct from the System Owner


35/67

Section 5 Information to be Submitted


iv) Simulator Developer proposal for verification and validation of simulator (see Subsection 4/7)

v) Simulator Verification and Validation Report (see Subsections 4/9 and 6/5)

vi) Simulator Developer Quality Plan (see 1/5.1.3 and Subsection 1/7)

vii) Justification (Rationale) of the method of System Analysis (see Subsection 7/1)


36/67


S e c t i o n 6 : V e r i f i c a t i o n P l a n

S E C T I O N 6 Verification Plan

1 General

The System Owner is to lead the development, update and maintenance of the Verification Plan and its

constituted component documents throughout the life cycle. It is anticipated that the System Owner willdelegate the development, update and maintenance of the component documents. However the responsibilityfor these functions remains with the System Owner. The System Owner is to submit the Verification Plan

and its constituent parts to ABS for review (see Section 5, Figure 1).

VERIFICATION NOTE: Recall that the System Owner can be the Shipyard during construction (see 1/5.1.1).

The Verification Plan is to be developed by the System Owner in order to meet the requirements of theABS SV Class Notation.

The Verification Plan is an assembly of individual documents that in their entirety contribute to the definition

and understanding of the systems and provides the scope and procedure for verification testing. The

documents that comprise the Verification Plan are listed in Subsections 5/3, 5/5 and 5/7.

The verification plan is to be suitable for the purpose of verification of the system in accordance with:

i) ABS Rules

ii) Requirements of this Guide

iii) Regulatory requirements

iv) System Owner/Operator Requirements

The verification plan is to be:

v) Broad enough in scope to test operational scenarios of the control system and the Equipment UnderControl

vi) Developed from the functional description, the Safety Reviews, System(s) Analysis (FMECA,FTA, etc.) as well as the other documents that are submitted as part of the classification process

(i.e., the plans and data that describe the control system(s) and the Equipment Under Control)

3 Verification Plan Details

The verification Plan is to include the following as appropriate:

3.1 General

i) Scope of the Verification Plan

ii) Identify the following:

a) Vessel via ABS ID Number

b) Owner

c) System Owner

d) Operator

e) Verification Organization

f) System Integrator


37/67

Section 6 Verification Plan


g) Method of Verification

h) Details of the simulator and the simulation

i) Details of the control system and its developer

j) Other pertinent details necessary to quantify and qualify the verification

iii) Include criteria when verification is to occur throughout the systems life cycle. It is to be contained

within the system Management of Change Procedure or referenced by the MOC procedure.

iv) Utilize a unique identifier for each verification test. Each verification test is to be associated witha specific system function as identified in the Functional Description.

v) Utilize a unique function identifier and description based upon the content of the FunctionalDescription (refer to 7/3.3i) for additional details on the functional identification number and

traceability).

vi) The Scope of Verification, Subsection 2/5).

a) Operational Environment and Envelope of the system to be verified (see 2/5.3)

b) Extent of Verification

1) Hardware Extent (see Section 1, Figure 1 and 2/5.5)

2) Functional Extent (see 2/5.7)

c) Verification Scenarios

vii) Subsystems and Equipment Under Control (see 1/3.5) that are included or excluded from theverification process are to be detailed and the analysis justifying their exclusion is to be submitted

for review. See also 1/3.7, 1/5.3 and 2/5.7.

viii) Reference documents

ix) Definitions of terms

x) Present the proposed method and format for recording the results of the verification testing.Note:automated recording of results is acceptable. As a minimum the following is to be included foreach test item:

a) Date

b) Venue

c) System(s)

d) Maker(s)

e) Function tested including function number and test number

f) Disruption

g) Expected/observed result

h) Variance of observed result with expected result

i) Ranking of variance

j) Proposed remediation

k) Resolution

l) Name, title and representation of participants.

m) Variance of observed results (see Item x)h), above) with the expected, is to be recorded

for analysis and resolution


38/67

Section 6 Verification Plan


n) Observed variance of verification results with the expected results are to be categorizedand ranked according to the following criteria:

1) Class related

2) Regulatory related

3) Owner requirements

4) Safety related

5) Essential systems or functions

6) Criticality as per the Owner/Operator from Safety Reviews, System(s) Analysis

(FMECA, FTA, etc.)

6) Observations voided by analysis

5 Updates and Maintenance of the Verification Plan

The functional description part of the Verification Plan is to be maintained current throughout the period

when the SV Notation is assigned to the vessel, offshore installation or facility. Update, maintenance andsubmission of the Verification Plan is the responsibility of the System Owner (see Section 5, Figure 1).Changes to systems are to occur as guided by the systems Management of Change Procedure. The

individual documents that comprise the Verification Plan as described in Subsections 5/3, 5/5 and 5/7 areto be updated and maintained to reflect the current systems status as change occurs.

With regard to verification related to change, the System Owner is to provide the following:

i) Identification of the functions to be changed or added.

a) For changed functions, the unique function identifier and verification test identifier is to

be utilized.

b) For new functions, a unique function identifier is to be generated and a proposed verification

test item and procedure is to be generated.ii) Reason for the change

iii) Extent and nature of the change (hardware, firmware, application), Equipment Under Control

iv) Name of organization making the change as well as contact information.

v) Updates to Systems Analysis (FMECA, FTA, etc)

vi) Proposed updates to the Verification Plan constituent documents are to be submitted by the System

Owner for review by ABS.

Upon review of the above, ABS will advise if system verification is required.

If upon review of proposed control system changes, ABS advises that system verification is required, the

System Owner is to amend the Verification Plan to provide updated procedures to verify existing functions,provide procedures to verify new functions and justify the proposed scope of verification, see Subsection 7/19.

The most recent ABS reviewed verification plan is to be used at each verification.


39/67


S e c t i o n 7 : V e r i f i c a t i o n P r o c e s s D e t a i l s

S E C T I O N 7 Verification Process Details

1 Initiation of Development of the Verification Plan

The System Owner [see 1/5.1.1(a)] is to initiate development of the Verification Plan.

3 Description of the Functions of the Control System and Equipment

Under Control

A functional description is to be developed to describe the operations of the Control System and the EquipmentUnder Control and their expected response during operational, degraded and failed condition. The functional

description is used to develop the control system logic, software and to facilitate the development of theSafety Review, System(s) Analysis (FMECA, FTA, etc.) and Verification Plan.

3.1

It is recommended that the concepts described in IEC 61508 or ISA 84 for process safety system verification beutilized in evaluating the criticality of functions and the consequences of their failure, additional details on

System Analysis are presented in Subsection 7/11. In addition, the unique function identifier described in7/3.3i) is to be utilized. If the control system is identified as a process safety system in accordance with the

requirements of IEC 61508 or ISA 84 the requirements of the SV Notation will be subordinate to therequirements contained within the aforementioned standards.

3.3

A detailed description of the functions of the control system and the Equipment Under Control is to be

developed. The description of the functions is to be of sufficient detail to allow for simulation developmentand verification of the functions of the target system and Equipment Under Control. The detailed description

is to include the following:

i) Each function identified is to be provided with a unique function identifier that is to be used uniformlythroughout all references and verifications and simulations.

ii) The dependencies (including function identifier of each function on other functions and data (seeSection 7, Figure 1).

iii) The distribution of data or calculated values to other functions (see Section 7, Figure 2).

iv) Description of the function of the Equipment Under Control be it controlled or monitored

v) Description of directly controlled functions. These functions may be controlled via local or remote

I/O modules or a communication network.

vi) Define if the function is an essential function or the equipment is an essential system

vii) Define if the function is general safety, environmental or process safety system.

viii) Operational states of the target system and Equipment Under Control.

ix) Non-operational states of the target system and Equipment Under Control identified from Safety

Reviews, Systems Analysis (FMECA, FTA, etc.) including:

a) Failure or degradation of individual components

b) Failure or degradation of directly connected


40/67

FIGURE 1Functional Dependency Diagram Precursors

2475START FUEL OIL

TRANSFER PUMP

384

125

34FUEL TRANSFER

PERMISABLE

68

398

95

1482479N

STOP FUEL OIL

TRANSFER PUMP

68

398

2479E

EMERGENCY STOP

FUEL OIL

TRANSFER PUMP

68HH

398HH

2479

STOP FUEL O

Systems Verification Guide e

Documents

Transcript of Systems Verification Guide e