ABS 189-2014 GUIDE FOR SYSTEMS VERIFICATION.pdf

《ABS 189-2014 GUIDE FOR SYSTEMS VERIFICATION.pdf》由会员分享，可在线阅读，更多相关《ABS 189-2014 GUIDE FOR SYSTEMS VERIFICATION.pdf（35页珍藏版）》请在麦多课文档分享上搜索。

1、 Guide for Systems Verification GUIDE FOR SYSTEMS VERIFICATION JULY 2014 American Bureau of Shipping Incorporated by Act of Legislature of the State of New York 1862 Copyright 2014 American Bureau of Shipping ABS Plaza 16855 Northchase Drive Houston, TX 77060 USA ii ABSGUIDE FOR SYSTEMS VERIFICATION

2、 .2014 Foreword Foreword The marine and offshore industries are increasingly relying on computer-based control systems. Therefore, the verification of the software used in control systems and their integration into the system is an important element within the overall safety assessment. This ABS Gui

3、de for Systems Verification (SV Guide) provides requirements and recommendations for software verification of integrated and non-integrated control systems aboard ships or offshore assets. This Guide is applicable during the initial construction and anytime during the life of the asset. This guide m

4、ay also be used for new, modifications, retrofits, replacements, or upgrades of computer based control systems. The SV Guide was amended to harmonize with the ABS Guide for Integrated Software Quality Management (ISQM) (ISQM Guide) and the software development life cycle. The SV Guide focuses on Har

5、dware-In-the-Loop (HIL) testing of control system software. HIL testing is an acceptable verification method for both the ISQM Guide and the SV Guide. This Guide is meant to be used with other Rules and Guides issued by ABS and other recognized industry standards. This Guide becomes effective on the

6、 first day of the month of publication. Users are advised to check periodically on the ABS website www.eagle.org to verify that this version of this Guide is the most current. We welcome your feedback. Comments or suggestions can be sent electronically by email to rsdeagle.org. ABSGUIDE FOR SYSTEMS

7、VERIFICATION .2014 iii Table of Contents GUIDE FOR SYSTEMS VERIFICATION CONTENTS SECTION 1 General 1 1 Purpose and Scope 1 3 Basis of Notation . 1 5 References 1 5.1 ABS . 1 5.3 IEEE 2 5.5 IEC 2 5.7 ISO 2 5.9 Other . 3 7 Organizations 3 9 Quality Program and Training for V isochronous, droop, etc. v

8、i) The functions for breaker control vii) The functions for alarms and system monitoring See Subsection A2/3 for modeling parameters for the Power Management Control System. 5.5 Thruster Control System The V&V is to verify: i) The automatic control of all thruster functions as described in the FDD.

9、ii) The thruster recovery after a blackout iii) The functions for primary (and auxiliary if available) thruster power unit iv) The local and remote transfer control and alarm functions See Subsection A2/5 for modeling parameters for the Thruster Control System. 7 Retesting ABS is to be notified when

10、 testing or retesting is to be performed. i) Re-testing of the control system is to be performed: a) Upon major upgrade of the control system software including major functionality upgrades b) When desired by the Owner ii) It is recommended that re-testing be performed: a) With new or added function

11、ality that is not defined as a major upgrade b) When desired by the Owner iii) The documents listed in Subsection 3/3 are to be updated, as required, and reissued. Section 3 Verification and Documentation ABSGUIDE FOR SYSTEMS VERIFICATION .2014 13 9 Simulation Program Maintenance i) The V&V and the

12、Owner are to agree upon simulation program archiving. ii) It is recommended that the V&V maintain a backup of the simulation program and any modeling. iii) The V&V is to update the simulation, as required for new functions added to the control system at the time of retesting. iv) The SP is to update

13、 the functional description with minor and major updates, changes or with additional functionality prior to retesting. 14 ABSGUIDE FOR SYSTEMS VERIFICATION .2014 Section 4 : Survey s After Construction and Maintenance of Class SECTION 4 Surveys After Construction and Maintenance of Class 1 General T

14、he provisions of this Section are requirements for the maintenance of classification of the control system(s) associated with the System Verification (SV) Notation. These requirements are in addition to the provisions noted in other ABS Rules and/or Guides, as applicable to the vessel or facility. F

15、or purposes of this Section, the commissioning date will be the date on which a Surveyor issues an Interim Class Certificate to the vessel or facility with the SV notation. 3 Surveys for the System Verification (SV) Notation 3.1 Survey Intervals and Maintenance Manuals/Records All Annual and Special

16、 Periodical Surveys associated with the SV notation are to be carried out at the same time and interval as the periodical classification survey of the vessel or facility in order that they are recorded with the same crediting date. An Annual Survey of the control system(s) associated with the SV not

17、ation is to be carried out by a Surveyor within three months either way of each annual anniversary date of the initial certification survey. A Special Periodical Survey of the control system(s) associated with the SV notation is to be carried out within five years of the initial certification survey

18、 and at five-year intervals thereafter. SV surveys may be offered for survey prior to the due date when so desired, in which case, the survey will be credited as of that date. Maintenance records are to be kept and made available for review by the attending Surveyor. The maintenance records will be

19、reviewed to establish the scope and content of the required Annual and Special Periodical Surveys that are to be carried out by a Surveyor. During the service life of the software system components, maintenance records are to be updated on a regular basis. The Owner is to inform ABS whenever an IL3

20、Software Module is modified or installed in a control system with an SV notation. ABS may audit the vessel upon notification of an IL3 Software Module modification or installation. 3.3 Annual Surveys At each Annual Survey, the Surveyor is to perform an integrated software and hardware configuration

21、audit to include verification of the following: i) Change control procedures, including periodic audits to confirm that procedures are also being followed ii) Examination of Control Equipment Registry (see 8/3.3.1 of the ISQM Guide) iii) Examination of Software Registry (see 8/3.3.2 of the ISQM Guid

22、e) iv) Review of Integrated Control Systems Hardware Registry (see 8/3.3.3 of the ISQM Guide) Section 4 Survey and Maintenance ABSGUIDE FOR SYSTEMS VERIFICATION .2014 15 3.3.1 Examination of Control Equipment Registry i) Identify control equipment that has been changed since the last audit. ii) Exam

23、ine the current version of the control system registry. iii) Record each changed equipment item. iv) List all software hosted on the changed equipment. v) Identify all documentation impacted by the change. vi) Record each documentation change. vii) Note any changes identified that were not listed on

24、 the registry. 3.3.2 Examination of Software Registry i) Identify all control software that has been changed since the last audit. ii) Record each software item change. iii) Inspect all software hosted on the changed equipment identified in 8/3.3.1 of the ISQM Guide. iv) Record software changes on c

25、hanged equipment in the Software Registry. v) Identify all documentation impacted by the changes. vi) Record all changed documentation in the software registry. vii) Note any software changes identified that were not listed on the registry. 3.3.3 Review of Integrated Control Systems Hardware Registr

26、y i) Assess how closely the software MOC is followed by interviewing relevant Owner/DCO and vendor crew as well as reviewing supporting documentation. ii) Where possible, identify weaknesses and recommend improvements to the process. 3.5 Special Periodical Surveys The Special Periodical Survey is to

27、 include all items listed under the Annual Survey to the satisfaction of the attending Surveyor. 5 Modifications, Damage and Repairs When it is intended to carry out any modifications to the software system that affects the SV notation of the vessel or facility, the details of such modifications are

28、 to be submitted for approval, and the work is to be carried out to the satisfaction of the Surveyor. When a control system that affects the SV notation of the vessel or facility has suffered any damage which may affect classification, ABS is to be notified, and the damage is to be assessed by a Sur

29、veyor. Where a control system suffers a failure, and is subsequently repaired or replaced without Surveyor attendance, details of the failure and corrective actions are to be retained onboard for examination by the Surveyor during the next scheduled survey/visit. 16 ABSGUIDE FOR SYSTEMS VERIFICATION

30、 .2014 A ppendix 1: Terminology APPENDIX 1 Terminology 1 Definitions The following definitions are applied to the terms used in this Guide: Component: One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components. Note: The terms “module”

31、, “component”, and “unit” are often used interchangeably or defined to be sub-elements of one another in different ways depending upon the context. The relationship of these terms is not yet standardized. Control: The process of conveying a command or order to enable the desired action to be effecte

32、d. Control, Remote: A device or array of devices connected to a machine by mechanical, electrical, pneumatic, hydraulic, or other means and by which the machine may be operated remote from and not necessarily within sight of the operator. Control System: An assembly of devices interconnected or othe

33、rwise coordinated to convey the command or order. Defect: A software coding error. Defects, Major: These are severe defects, which have not halted the system, but have seriously degraded the performance or caused unintended action or incorrect data to be transmitted. Defects, Minor: Defects which ca

34、n or have caused a low-level disruption of function(s). Such defects can result in data latency but not in essential or IL2 or IL3 functions. The integrated system and the function continue to operate, although with a failure. Such a disruption or non-availability of some functionality can be accept

35、able for a limited period of time for IL1 functions. Minor defects could cause corruption of some non-critical data values in a way that is tolerable for a short period. Failure Modes, Effects, and Criticality Analysis (FMECA): The criticality analysis is used to chart the probability of failure mod

36、es against the severity of their consequences. The analysis highlights failure modes with relatively high probability and severity of consequences. Failure Modes, Effects, and Criticality Analysis Testing: Testing to verify that the system performs as predicted upon introduction of failure. Function

37、: The purpose of the Equipment Under Control (i.e., the hydraulic power unit, winch, power management system). Hardware: Physical equipment used to process, store, or transmit computer software or data. Human Machine Interface (HMI): A display and operator input device. Instrumentation: A system des

38、igned to measure and to display the state of a monitored parameter and which may include one or more sensors, read-outs, displays, alarms, and means of signal transmission. Integrity Level (IL#): A number assigned by Owner and/or Operator to a function based upon the severity of the consequence of a

39、 failure of the function, where 0 has little consequence to 3 where the consequence of a function failure is of significant concern with corresponding consequences. Load Sharing: When more than one generator are running in parallel, load sharing distributes equal real (kW) and reactive (kVA) loading

40、 on all in order to provide more efficient operation. Load Shedding: When the power demand is higher than the supply, certain loads are disconnected to prevent overload (and subsequently a total blackout) and so that essential services remain online. Please refer to the Steel Vessel Rules for the lo

41、ad shedding hierarchy. Appendix 1 Terminology ABSGUIDE FOR SYSTEMS VERIFICATION .2014 17 Maintenance, Software: Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. Native Computer: The pro

42、gram is being executed on the hardware that it will execute upon when installed. Non-native Computer: The program is being executed on an emulation of the target hardware using an emulator. Nonoperational: Not in working order or ready to use. Operational: (1) Pertaining to a system or component tha

43、t is ready for use in its intended environment. (2) Pertaining to a system or component that is installed in its intended environment. (3) Pertaining to the environment in which a system or component is intended to be used. Peer Review: A process where a document or authors work is scrutinized by ot

44、hers who are competent or are considered experts in the same field. Retirement: Withdrawal of active support by the operation and maintenance organization, partial or total replacement by a new system, or installation of an upgraded system Safety: The ability of a system to avoid catastrophic behavi

45、or. Safety Analysis: A risk assessment tool used to identify safety related risks in a given control system and all the functions within. Safety Review: Review of safety report or other to help design a safe system and meet the system requirements. Self-Descriptiveness: The extent of softwares abili

46、ty to provide an explanation of the implementation of a function or functions. Software: Computer programs, procedures, test scripts, and associated documentation and data pertaining to the operation of a computer system. Software Design Specification: A document that describes the design of a syste

47、m or component. Typical contents include system or component architecture, control logic, data structures, input/output formats, interface descriptions, and algorithms. Software Module: A smaller set of program code to carry out a logical subset of control actions controlled by the overriding progra

48、m (i.e., A Software Module with program code to open a valve, monitor that the valve did open, and alarm if feedback is not provided within the prescribed time). Another example would be an analog loop where the main shaft is to rotate at 20 rpm and a closed loop control would adjust the drives moto

49、r speed to maintain 20 rpm. Software Requirements Specification (SRS): Documentation of the essential requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces. Software Risk: The potential loss due to failure during a specific time period. Test, Regression: Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements. Testing, Black Box: Testing that is performed without knowledge of the int