systems verification guide e
TRANSCRIPT
-
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
-
7/28/2019 Systems Verification Guide e
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
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected] -
7/28/2019 Systems Verification Guide e
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
-
7/28/2019 Systems Verification Guide e
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
-
7/28/2019 Systems Verification Guide e
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
-
7/28/2019 Systems Verification Guide e
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/28/2019 Systems Verification Guide e
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
-
7/28/2019 Systems Verification Guide e
8/67
This Page Intentionally Left Blank
-
7/28/2019 Systems Verification Guide e
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.
-
7/28/2019 Systems Verification Guide e
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
-
7/28/2019 Systems Verification Guide e
11/67
Section 1 General
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 3
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.
-
7/28/2019 Systems Verification Guide e
12/67
Section 1 General
4 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
13/67
Section 1 General
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 5
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.
-
7/28/2019 Systems Verification Guide e
14/67
FIGURE 3Example of Complex Network Connection, Subsystems, Equipment Under C
6
ABSGUIDEFOR
SYSTEMSVERIFICATION
.
2012
-
7/28/2019 Systems Verification Guide e
15/67
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 7
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)
-
7/28/2019 Systems Verification Guide e
16/67
Section 2 Overview of Verification Process
8 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
17/67
Section 2 Overview of Verification Process
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 9
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.
-
7/28/2019 Systems Verification Guide e
18/67
Section 2 Overview of Verification Process
10 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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
-
7/28/2019 Systems Verification Guide e
19/67
Section 2 Overview of Verification Process
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 11
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
-
7/28/2019 Systems Verification Guide e
20/67
Section 2 Overview of Verification Process
12 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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
-
7/28/2019 Systems Verification Guide e
21/67
Section 2 Overview of Verification Process
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 13
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
-
7/28/2019 Systems Verification Guide e
22/67
Section 2 Overview of Verification Process
14 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
23/67
FIGURE 7System Verification Simulation Connection Points
ABSGUIDEFOR
SY
STEMSVERIFICATION
.
2012
15
-
7/28/2019 Systems Verification Guide e
24/67
16 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
25/67
Section 3 Control Systems
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 17
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.
-
7/28/2019 Systems Verification Guide e
26/67
Section 3 Control Systems
18 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
27/67
Section 3 Control Systems
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 19
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.
-
7/28/2019 Systems Verification Guide e
28/67
Section 3 Control Systems
20 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
29/67
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 21
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.
-
7/28/2019 Systems Verification Guide e
30/67
Section 4 Simulator and Simulation
22 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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
-
7/28/2019 Systems Verification Guide e
31/67
Section 4 Simulator and Simulation
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 23
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
-
7/28/2019 Systems Verification Guide e
32/67
Section 4 Simulator and Simulation
24 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
33/67
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 25
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
-
7/28/2019 Systems Verification Guide e
34/67
Section 5 Information to be Submitted
26 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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
-
7/28/2019 Systems Verification Guide e
35/67
Section 5 Information to be Submitted
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 27
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)
-
7/28/2019 Systems Verification Guide e
36/67
28 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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
-
7/28/2019 Systems Verification Guide e
37/67
Section 6 Verification Plan
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 29
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
-
7/28/2019 Systems Verification Guide e
38/67
Section 6 Verification Plan
30 ABSGUIDE FOR SYSTEMS VERIFICATION .2012
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.
-
7/28/2019 Systems Verification Guide e
39/67
ABSGUIDE FOR SYSTEMS VERIFICATION .2012 31
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
-
7/28/2019 Systems Verification Guide e
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