ABS 253-2016 GUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS Cyber Safety VOLUME 4.pdf

《ABS 253-2016 GUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS Cyber Safety VOLUME 4.pdf》由会员分享，可在线阅读，更多相关《ABS 253-2016 GUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS Cyber Safety VOLUME 4.pdf（42页珍藏版）》请在麦多课文档分享上搜索。

1、 Guide for Software Systems Verification ABS CyberSafetyTMVolume 4 GUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTMVOLUME 4 SEPTEMBER 2016 American Bureau of Shipping Incorporated by Act of Legislature of the State of New York 1862 2016 American Bureau of Shipping. All rights reserved. ABS

2、Plaza 16855 Northchase Drive Houston, TX 77060 USA 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

3、 the overall safety assessment. This ABS Guide for Software Systems Verification ABS CyberSafetyTMVolume 4 (SSV 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

4、 the initial construction and anytime during the life of the asset. This guide may also be used for new, modifications, retrofits, replacements, or upgrades of computer based control systems. The SSV Guide was amended to harmonize with the ABS Guide for Integrated Software Quality Management (ISQM)

5、(ISQM Guide) and the software development life cycle. The SSV Guide focuses on Hardware-In-the-Loop (HIL) testing of control system software. HIL testing is an acceptable verification method for both the ISQM Guide and the SSV Guide. This revision of the Guide incorporates the following changes: Add

6、ition of BOP control system Additional requirements Engineering drawing change Test cases for individual systems New definitions 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 first day of the mont

7、h 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. ii ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATI

8、ON ABS CyberSafetyTM, VOL 4 .2016 Table of Contents GUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTMVOLUME 4 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 3 5.9 Other . 3 7 Organizations 3 9 Quality Program

9、 and Training for V rather, it is intended to demonstrate only that the software runs without errors. 3.1.1 Software-In-the-Loop Testing Applicability Software-In-the-Loop testing is limited in application. The following considerations are to be agreed upon by V for applications or processes running

10、 on the system in support of system function; and for any sensors or reporting elements that provide critical data back to the system under test. If cybersecurity testing is required to demonstrate or prove security and/or quality of the system against specific threats2, ABS will work with the V the

11、y may include inadvertent error introductions through user interfaces, employee errors in operation, malicious insider actions, and malicious outside actor activities. ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTM, VOL 4 .2016 7 Section 2 Introduction 5.1 Focus on Software This Guides

12、 focus is to test the software of the equipments control system. This Guide puts an emphasis on the selected equipments software and its demonstrated behaviors under different states and network load conditions. This is expected to verify that the software operates in its expected environment and co

13、nforms to its functional description under all conditions, including any areas of concern raised by safety reviews or other safety analysis. This Guide is written as a process to acquire a software-focused notation, and it does not verify any piece of hardware or equipment as to the suitability of s

14、aid equipment for the intended purpose. 8 ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTM, VOL 4 .2016 Section 3: Verification and Documentation SECTION 3 Verification and Documentation 1 General Descriptive documentation of the functionality and functions of the control system to under

15、go the testing (target system) is to be reviewed by ABS, Owner, and SBI. 1.1 Traceability of Functions across Documents (1 September 2016) i) Traceability of functions is important during the safety analysis and selection of functions or functionality to be tested, defect tracing in the simulation p

16、rogramming or control system code. The traceability may be any unique identifier to allow for tracing the function from the system functional description or FDD through safety review(s) or safety analysis, V isochronous, droop, etc. vi) The functions for breaker control vii) The functions for alarms

17、 and system monitoring viii) Functions for Blackout Prevention ix) Functions for Enhanced Generator Protection, if implemented See Subsection A2/3 for a simulation model of the Power Management Control System. 5.5 Thruster Control System The V&V is to verify: i) The automatic control of all thruster

18、 functions as described in the system description (SRS and SDS or FDD). ii) Thruster recovery after a blackout iii) Functions for primary (and auxiliary if available) thruster power unit iv) Local and remote transfer control and alarm functions v) Thruster fast phase back See Subsection A2/5 for a s

19、imulation model of the Thruster Control System. 5.7 Blowout Preventer (BOP) The V&V is to verify: i) The automatic control of all BOP functions as described in the FDD. ii) The interface and communication between 3rdparty and BOP control system iii) Interlocks iv) Subsea-to-surface communication a)

20、Topside communication for BOP b) Surface to subsea communication c) Subsea module communication with connected controls such as acoustic controls, riser control box and power units. v) Emergency control functions: Automatic mode/Deadman and backup power vi) The interface and communication with backu

21、p control systems (if installed) vii) Emergency Disconnect Sequence Systems (EDS) a) Emergency pump and valve control functions b) Autoshear functions c) LMRP functions d) Pipe and blind shear ram functions e) Casing shear ram functions viii) Hydraulic Fluid Mixing Control System functions a) Commun

22、ication to DCU b) Power supply ix) Operational limits See Subsection A2/7 for a simulation model for the BOP control system. 14 ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTM, VOL 4 .2016 Section 3 Verification and Documentation 7 Re-testing (1 September 2016) ABS is to be notified whe

23、n testing or retesting is performed for failed test scenarios and functionality upgrades. i) Re-testing of the control system is to be performed: a) Upon upgrade of the control system software including functionality upgrades b) When desired by the Owner c) On failed test cases from V&V Report d) Wh

24、en an IL3 software module is modified (refer to 4/3.1) e) Prior to installation of software patches on safety-critical systems ii) It is recommended that re-testing be performed: a) With new or added functionality that is not defined as a upgrade b) When system interfaces or network connections chan

25、ge c) After a system insecurity or safety-related malfunction iii) The documents listed in Subsection 3/3 are to be updated, as required, and reissued. 9 Simulation Program Maintenance (1 September 2016) i) The V&V and the Owner are to agree upon simulation program archiving. ii) It is recommended t

26、hat the V&V maintain a backup of the simulation program or 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 the functional description with software updates, changes or with additional

27、functionality prior to retesting. ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTM, VOL 4 .2016 15 Section 4 : Survey s After Construction and Maintenance of Class SECTION 4 Surveys After Construction and Maintenance of Class 1 General The provisions of this Section are requirements for

28、the maintenance of classification of the control system(s) associated with the Software Systems Verification (SSV) Notation. These requirements are in addition to the provisions noted in other ABS Rules and/or Guides, as applicable to the vessel or facility. For purposes of this Section, the commiss

29、ioning date will be the date on which a Surveyor issues an Interim Class Certificate to the vessel or facility with the SSV notation. 3 Surveys for the Software Systems Verification (SSV) Notation 3.1 Survey Intervals and Maintenance Manuals/Records (1 September 2016) All Annual and Special Periodic

30、al Surveys associated with the SSV 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 SSV notation i

31、s 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 SSV notation is to be carried out within five years of the initial certification survey and a

32、t five-year intervals thereafter. SSV 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 revie

33、wed to establish the scope and content of the required Annual and Special Periodical Surveys that are to be carried out by a Surveyor5. During the service life of the software system components, maintenance records are to be updated on a regular basis. Re-test requirements, noted in Subsection 3/7,

34、are to be included in maintenance records when re-tests are required. The Owner is to inform ABS whenever an IL3 Software Module is modified or installed in a control system with an SSV notation. ABS may audit the vessel upon notification of an IL3 Software Module function modification or installati

35、on. 3.3 Annual Surveys At each Annual Survey, the Surveyor is to perform an integrated software and hardware configuration 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 Con

36、trol Equipment Registry (see 8/3.3.1 of the ISQM Guide) iii) Examination of Software Registry (see 8/3.3.2 of the ISQM Guide) iv) Review of Integrated Control Systems Hardware Registry (see 8/3.3.3 of the ISQM Guide) 5Maintenance records and the FDD are to include software version control logs, chan

37、ge management logs, and the functional testing logs. These records, with other documentation specific to each asset, will support Surveyor assessment scope and content. 16 ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTM, VOL 4 .2016 Section 4 Surveys After Construction and Maintenance o

38、f Class 3.3.1 Examination of Control Equipment Registry i) Identify control equipment that has been changed since the last audit. ii) Examine the current version of the control system registry. iii) Record each changed equipment item. iv) List all software hosted on the changed equipment. v) Identif

39、y all documentation impacted by the change. vi) Record each documentation change. vii) Note any changes identified that were not listed on the registry. 3.3.2 Examination of Software Registry i) Identify control software that has been changed since the last audit. ii) Record each software item chang

40、e. iii) Inspect all software hosted on the changed equipment identified in 8/3.3.1 of the ISQM Guide. iv) Record software changes on changed equipment in the Software Registry. v) Identify all documentation impacted by the changes. vi) Record all changed documentation in the software registry. vii)

41、Note any software changes identified that were not listed on the registry. 3.3.3 Review of Management of Change (MOC) Policy (1 September 2016) i) Assess how closely the software MOC is followed by interviewing relevant Owner/DCO and SP as well as reviewing supporting documentation. ii) Where possib

42、le, identify discrepancies and weaknesses, and recommend improvements to the process. 3.5 Special Periodical Surveys The Special Periodical Survey is to include all items listed under the Annual Survey to the satisfaction of the attending Surveyor. 5 Modifications, Damage and Repairs (1 September 20

43、16) When it is intended to carry out any modifications to the software system that affects the SSV notation of the vessel or facility, the details of such modifications are to be submitted for approval, and the work is to be carried out to the satisfaction of the Surveyor. When a control system that

44、 affects the SSV 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 Surveyor. Where a control system suffers a failure, and is subsequently repaired or replaced without Surveyor attendance during op

45、erations, details of the failure and corrective actions are to be retained onboard for examination by the Surveyor during the next scheduled survey/visit. When major modifications are conducted, the system is to be tested as required by this Guide applicable for the specific system, and additional t

46、esting of the control system conducted in order to verify compliance with this Guide as deemed necessary the attending Surveyor. ABSGUIDE FOR SOFTWARE SYSTEMS VERIFICATION ABS CyberSafetyTM, VOL 4 .2016 17 Appendix 1: Terminology APPENDIX 1 Terminology (1 September 2016) 1 Definitions The following

47、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”, “component”, and “unit” are often used interchangeably or defined to be sub-eleme

48、nts 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 effected. Control, Remote: A device or array of devices connected to a machine by mechanic

49、al, 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 otherwise 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 can or have caused a low-level disruption of