Integrated Software Dependent Systems (ISDS)

Transcription

1 OFFSHORE STANDARD DNV-OS-D203 Integrated Software Dependent Systems (ISDS) DECEMBER 2012 The electronic pdf version of this document found through is the officially binding version

2 FOREWORD DNV is a global provider of knowledge for managing risk. Today, safe and responsible business conduct is both a license to operate and a competitive advantage. Our core competence is to identify, assess, and advise on risk management. From our leading position in certification, classification, verification, and training, we develop and apply standards and best practices. This helps our customers safely and responsibly improve their business performance. DNV is an independent organisation with dedicated risk professionals in more than 100 countries, with the purpose of safeguarding life, property and the environment. DNV service documents consist of among others the following types of documents: Service Specifications. Procedural requirements. Standards. Technical requirements. Recommended Practices. Guidance. The Standards and Recommended Practices are offered within the following areas: A) Qualification, Quality and Safety Methodology B) Materials Technology C) Structures D) Systems E) Special Facilities F) Pipelines and Risers G) Asset Operation H) Marine Operations J) Cleaner Energy O) Subsea Systems U) Unconventional Oil & Gas Det Norske Veritas AS December 2012 Any comments may be sent by to rules@dnv.com This service document has been prepared based on available knowledge, technology and/or information at the time of issuance of this document, and is believed to reflect the best of contemporary technology. The use of this document by others than DNV is at the user's sole risk. DNV does not accept any liability or responsibility for loss or damages resulting from any use of this document.

3 Changes Page 3 CHANGES General This document supersedes DNV-OS-D203, May Text affected by the main changes in this edition is highlighted in red colour. However, if the changes involve a whole chapter, section or sub-section, normally only the title will be in red colour. Changes The document is totally revised.

4 Contents Page 4 CONTENTS CH. 1 INTRODUCTION... 6 Sec. 1 General... 7 A. General... 7 A 100 Introduction... 7 A 200 Objectives... 7 A 300 Organisation of content... 7 A 400 Assumptions... 7 A 500 Scope and application... 7 A 600 Types of software within scope... 8 A 700 Alterations and additions of approved systems... 8 B. References... 8 B 100 International or national references... 8 B 200 DNV references... 9 CH. 2 TECHNICAL PROVISIONS Sec. 1 Principles A. General A 100 Process requirements A 200 System hierarchy Sec. 2 Confidence Levels A. Confidence Levels A 100 Definition of confidence levels Sec. 3 Responsibilities A. Activities and Roles A 100 Activities A 200 Roles Sec. 4 Project Phases and Process Areas A. Project phases A 100 Introduction A 200 Basic engineering phase (A) A 300 Engineering phase (B) A 400 Construction phase (C) A 500 Acceptance phase (D) A 600 Operation phase (E) B. Process Areas B 100 Introduction B 200 Requirements engineering (REQ) B 300 Design (DES) B 400 Implementation (IMP) B 500 Acquisition (ACQ) B 600 Integration (INT) B 700 Verification and Validation (VV) B 800 Reliability, Availability, Maintainability and Safety (RAMS) B 900 Project Management (PM) B 1000 Risk Management (RISK) B 1100 Process and Quality Assurance (PQA) B 1200 Configuration Management (CM) Sec. 5 ISDS Requirements for Owners A. Owner requirements A 100 Requirements under the owner s responsibility A 200 Acceptance criteria for owner assessments A 300 Documentation criteria for the owner Sec. 6 ISDS Requirements for System Integrators A. System integrator requirements A 100 Requirements under the system integrator s responsibility... 22

5 Contents Page 5 A 200 Acceptance criteria for system integrator assessments A 300 Documentation criteria for the system integrator Sec. 7 ISDS Requirements for Suppliers A. Supplier requirements A 100 Requirements under the supplier s responsibility A 200 Acceptance criteria for supplier assessments A 300 Documentation criteria for the supplier Sec. 8 ISDS Requirements for the Independent Verifier A. Independent verifier requirements A 100 Activities for which the independent verifier is responsible CH. 3 CLASSIFICATION AND CERTIFICATION Sec. 1 Requirements A. General A 100 Introduction A 200 Organisation of Chapter A 300 Classification principles A 400 Compliance of Activities A 500 Approval of Documents A 600 Rating of compliance A 700 Reporting and milestone meetings B. Class notation B 100 Designation B 200 Scope C. In operation assessments C 100 Objectives C 200 Scope of annual assessments C 300 Scope of renewal assessments App. A DEFINITIONS AND ABBREVIATIONS A. Definitions A 100 Verbal Forms A 200 Definitions B. Abbreviations App. B REQUIREMENT DEFINITION A. Requirement definition A 100 General A 200 Activity definition basic engineering A 300 Activity definition engineering A 400 Activity definition construction A 500 Activity definition acceptance A 600 Activity definition operation A 700 Activity definition several phases... 94

6 OFFSHORE STANDARD DNV-OS-D203 INTEGRATED SOFTWARE DEPENDENT SYSTEMS CHAPTER 1 INTRODUCTION CONTENTS PAGE Sec. 1 General... 7

7 Ch.1 Sec.1 Page 7 SECTION 1 GENERAL A. General A 100 Introduction 101 This standard contains requirements and guidance on the process of design, construction, commissioning and operation of Integrated Software Dependent Systems (ISDS). ISDS are integrated systems where the overall behaviour depends on the behaviour of the systems software components. 102 This standard focuses on the integration of the software dependent systems, sub-systems and system components, and the effects these have on the overall performance of the unit (ship, rig etc.) in terms of functionality, quality, reliability, availability, maintainability and safety. This standard intends to help system integrators and suppliers as well as owner to: reduce the risk for delays in new-build projects and modification projects, reduce the risk for downtime and accidents caused by software in the operation phase, improve the processes for maintenance and upgrades of software dependent systems throughout the life cycle, improve the knowledge of the relevant systems and software across the organisations, work within a common framework to deliver on schedule while achieving functionality, quality, reliability, availability, maintainability and safety targets, communicate and resolve key issues related to integration challenges at an early stage and throughout the whole life cycle. A 200 Objectives 201 The objectives of this standard are to: provide an internationally acceptable standard for integrated software dependent systems by defining requirements for the work processes during design, construction, commissioning and operation, serve as a contractual reference document between suppliers and purchasers, serve as a guideline for designers, suppliers, purchasers and regulators, specify processes and requirements for units or installations subject to DNV certification and classification services. A 300 Organisation of content 301 This document is divided into the following chapters and appendices: Ch.1 gives general introduction, scope and references. Ch.2 lists the requirements for the different roles, including assessment and document requirements. Ch.3 gives procedures and principles applicable when this standard is used as part of DNV classification. Appendix A lists definitions and abbreviations used in this standard. Appendix B gives a detailed description of the activities introduced in Ch.2. A 400 Assumptions 401 The requirements of this standard are based on the assumptions that the personnel are qualified to execute the assigned activities. 402 The requirements of this standard are based on the assumptions that the parties involved in the different processes are familiar with the intended function(s) of the system(s) subject for ISDS. A 500 Scope and application 501 The requirements of this standard apply to the processes that manage ISDS throughout the life cycle of a ship or offshore unit, and apply to new-builds, upgrades and modification projects. It puts requirements on the ways of working, but does not contain any specific product requirements. 502 The requirements of this standard apply to systems, sub-systems and software components created, modified, parameterized, tuned and/or configured for the specific project where this standard is applied. This standard focuses on the software aspect in the context of system and unit requirements. 503 The voluntary ISDS class notation, as specified in Ch.3, may be assigned when DNV has verified compliance. DNV s verification activities include all the activities specified under the independent verifier role in Ch.2, for the relevant confidence level.

8 Ch.1 Sec.1 Page 8 A 600 Types of software within scope 601 This standard focuses on achieving high software quality and takes into consideration all typical types of software. The requirements differ depending on whether the software is new or reused: New software (typically application software) developed within the project is qualified for use in the ISDS by showing that the supplier s development process is compliant to this standard. All reused software shall be qualified for use. Reused software is either COTS or base products. The term base product is here used to describe any kind of existing product, component, software library, software template or similar on which the supplier bases the development (or automatic generation) of the custom specific product. The qualification of reused software shall be performed by using one of these options: 1) Demonstrating compliance with this standard. 2) Assessing the quality through due diligence of the software. 3) Demonstrating that the software is proven-in-use. 4) Procurement of COTS software as described in this standard. A 700 Alterations and additions of approved systems 701 When an alteration or addition to the approved system(s) is proposed, applicable ISDS requirements shall be applied and relevant information shall be submitted to DNV. The alterations or additions shall be presented for assessment and verification. B. References B 100 International or national references 101 The standards listed in Table B1are referenced in this standard. Table B1 International or national references Reference Title IEC IEV 191 Dependability and quality of service IEC Functional safety of electrical/electronic/programmable electronic safety-related systems IEC Functional safety Safety instrumented systems for the process industry sector IEC 19501:2005 Unified Modelling Language Specification IEEE :1990 Glossary of software engineering terminology IEEE Software configuration management plan IEEE Software test documentation IEEE 1074:2006 Developing software life cycle processes INCOSE SE 2004 INCOSE System Engineering Handbook, 2004 ISO/IEC 9126 Software engineering Product quality ISO/IEC Life Cycle Management System Life Cycle Processes ISO 9000 Quality management systems SWEBOK 2004 Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 Version

9 Ch.1 Sec.1 Page 9 B 200 DNV references 201 This standard is complimentary to the standards listed in Table B2 and B3. Table B2 DNV Offshore Standards Standard Title DNV-OSS-101 Rules for Classification of Offshore Drilling and Support Units DNV-OSS-102 Rules for Classification of Floating Production, Storage and Loading Units DNV-OSS-103 Rules for Classification of LNG/LPG Floating Production and Storage Units or Installations DNV-OSS-300 Risk Based Verification DNV-OS-A101 Safety Principles and Arrangements DNV-OS-D101 Marine and Machinery Systems and Equipment DNV-OS-D201 Electrical Installations DNV-OS-D202 Automation, Safety and Telecommunication Systems DNV-OS-D301 Fire Protection DNV-OS-E101 Drilling Plant DNV-OS-E201 Oil and Gas Processing Systems DNV-OS-E301 Position Mooring Table B3 Other DNV references Reference Title DNV-RP-D201 Recommended practice for Integrated Software Dependent Systems DNV-RP-A201 Plan Approval Documentation Types Definitions DNV-RP-A203 Recommended Practice for Qualification of New Technology Pt.6 Ch.7 Rules for Classification of Ships - Dynamic Positioning Systems Pt.6 Ch.26 Rules for Classification of Ships - Dynamic Positioning System - Enhanced Reliability DYNPOS-ER SfC 2.24 Standards for Certification - Hardware in the Loop Testing (HIL)

10 OFFSHORE STANDARD DNV-OS-D203 INTEGRATED SOFTWARE DEPENDENT SYSTEMS CHAPTER 2 TECHNICAL PROVISIONS CONTENTS PAGE Sec. 1 Principles Sec. 2 Confidence Levels Sec. 3 Responsibilities Sec. 4 Project Phases and Process Areas Sec. 5 ISDS Requirements for Owners Sec. 6 ISDS Requirements for System Integrators Sec. 7 ISDS Requirements for Suppliers Sec. 8 Requirements for the Independent Verifier... 34

11 Ch.2 Sec.1 Page 11 SECTION 1 PRINCIPLES A. General A 100 Process requirements 101 This standard provides requirements for a process. These requirements are formulated as a set of activities that apply for specific roles during specific project phases and at specific confidence levels. A 200 System hierarchy 201 In order to describe the different parts that make up Integrated Software Dependent Systems, this standard uses the hierarchy defined in Fig.1. Figure 1 The hierarchy terms used in this standard

12 Ch.2 Sec.2 Page 12 SECTION 2 CONFIDENCE LEVELS A. Confidence Levels A 100 Definition of confidence levels 101 Confidence levels are assigned by the owner to a selection of the unit s functions and systems, based on evaluations of the importance of these functions in relation to reliability, availability, maintainability and safety. 102 Confidence levels define the required level of trust that a given function (implemented by one or more systems) will perform as expected. This standard defines the confidence levels 1 through 3 where the higher confidence level will require a higher project ambition level with the aim of increasing the dependability of the systems in scope. The higher confidence levels also include the activities required for the lower ones. 103 Table A1 shows the difference between confidence levels 1, 2 and Ch.3, Sec.1, B200 shows the recommended confidence levels for systems and components relevant for selected unit types (drilling unit, FPSO etc.). See DNV-RP-D201 for general guidance on the principles of assigning confidence levels to functions and systems. Table A1 The difference between the confidence levels Confidence level Characteristics Focus Key activities 1 Basic software confidence System Project management Defined ways of working Design and verification of software within a system 2 Enhanced integration confidence Systems System integration 3 Enhanced quantified confidence Systems System integration High dependability Interface definition Describing interaction between systems Traceability of requirements Qualitative RAMS Obsolescence management Quantitative RAMS High involvement of independent verifier Enhanced verification

13 Ch.2 Sec.3 Page 13 SECTION 3 RESPONSIBILITIES A. Activities and Roles A 100 Activities 101 Each requirement of this standard is formulated as an activity which is assigned to a role, a defined project phase, and a confidence level. The activities are listed in Sec.5 to 7 and described in detail in Appendix B. Each required activity has a unique identifier. The identifier is structured in three parts: Z.YYY.NN. The first part ( Z ) of the activity identifier refers to the project phase. The second part ( YYY ) of the activity identifier refers to the process area. The third part ( NN ) of the activity identifier is a unique number for the activity. For example, A.REQ.2 is the identifier of the 2 nd activity of the requirements process area for the basic engineering phase. Some activities are performed in 2 or several phases. In this case, the activity s phase is described as an X. Each X activity describes in which phases it shall be performed.x.req.1 is the common activity no. 1 for the requirements process area for managing requirement changes in all phases. 102 Several activities require communication between different roles to be carried out. For these activities the contributing role(s) are specified, in addition to the responsible role. The expected contributions are specified in this standard, and the contributing role shall provide the specified information to the responsible role when requested. Figure 1 An overview of communication and exchange of information between the roles.

14 Ch.2 Sec.3 Page 14 A 200 Roles 201 This standard defines requirements on several organisations with responsibilities within the system life cycle. Each role is assigned activities and has the responsibility to perform the activity with an outcome that fulfils the specified criteria. 202 Each organisation is assigned one of four predefined roles. The four roles are: Owner (OW): In the context of this standard the owner is the organisation who decides to develop the unit (ship, rig etc.), and provides funding. The operator of the system can be part of the owner's organisation, or can be a subcontractor acting on behalf of the owner. For a definition of the term owner reference is also made to DNV-OSS-101 Ch.1, Sec.1, B. System integrator (SI): Responsible for the integration of all systems included in the scope of this standard. The system integrator is normally the shipyard, but parts of the integration may be delegated to other parties. In such case this shall be clearly defined and documented. Supplier (SU): Responsible for the integration and delivery of one or more single systems (drilling control system, power management system etc.). If the supplier purchases products and services from other organisations, these are regarded as sub-suppliers, and are under the supplier's responsibility. Independent verifier (IV): An organisation that is mandated to independently verify that the system is developed according to this standard. As part of the classification process for the ISDS notation, DNV shall take the role of independent verifier.

15 Ch.2 Sec.4 Page 15 SECTION 4 PROJECT PHASES AND PROCESS AREAS A. Project phases A 100 Introduction 101 All activities in this standard are mapped to the typical project life cycle, see Fig The transitions between the phases represent ISDS milestones. At each milestone the following information shall be reported by the involved roles: status for the compliance to this standard, action plans for handling non-conformities, risk observations made by the independent verifier. 103 At each milestone a milestone meeting should be arranged. The system integrator is responsible for arranging such meetings at all milestones, except M5 for which the owner is responsible. 104 An ISDS milestone is completed when the owner, the system integrator and the independent verifier endorse the information presented at the milestone. Figure 1 Process chart describing the relationship between project phases (A to E) and ISDS milestones (M1 to M5). ISDS milestone M5 is only applicable for modifications made during the operation phase. A 200 Basic engineering phase (A) 201 During this phase the technical specification and design of the unit are established, including RAMS requirements. The main systems which will be included in the scope for ISDS requirements and their confidence levels are identified. The contract between the owner and the system integrator is established during this phase. The following activities normally take place before the contract between the owner and the system integrator is signed, depending on the confidence level for the different systems: Define mission, objectives and shared vision (A.REQ.1, CL1 and above). Define operational modes and scenarios to capture expected behaviour (A.REQ.3, CL2 and above). Define RAM related requirements and objectives (A.RAMS.2, CL2 and above). Define procedures (owner) (A.PQA.1, CL1 and above). A 300 Engineering phase (B) 301 In this phase contracts are established with suppliers, and the suppliers are involved in setting up the development/configuration of each system. The detailed design of the unit and systems is documented. The verification, validation, testing and integration strategies, and major interfaces are established, and RAMS analyses are carried out. The ISDS process is normally aligned with the overall building schedule so that steel cutting takes place towards the end of the ISDS engineering phase. Normally, only one phase B activity takes place before the contracts between the system integrator and the suppliers are signed: Submit proposals to system integrator with compliance status (B.REQ.1, CL1 and above).

16 Ch.2 Sec.4 Page 16 A 400 Construction phase (C) 401 In this phase the construction and integration of the systems are carried out. Detailed software design, coding and/or parameterization are performed. Systems and interfaces are tested, validated and verified as part of this phase. A 500 Acceptance phase (D) 501 In this phase, the functionality, performance, RAMS requirements and other aspects of the integrated systems are validated, through commissioning activities, integration testing, and sea trials. A 600 Operation phase (E) 601 In this phase the unit is in operation. Maintenance and small upgrades are performed as deemed necessary by the owner. 602 Large upgrades should be managed as separate projects, following a distinct lifecycle based on this standard. Any planned upgrade resulting in the shutdown of the unit or ship for any extended period of time should be regarded as a large upgrade. B. Process Areas B 100 Introduction 101 Activities are logically grouped in process areas based on the typical engineering discipline they address. Each process area spans multiple project phases. B 200 Requirements engineering (REQ) 201 The requirements engineering process area covers the activities needed to define, document and manage the requirements on the unit, the systems and the related software. On CL1, the overall goal and vision for the unit are defined and the requirements on the unit and relevant systems are specified. A dialogue between the owner/system integrator on one hand and the potential suppliers on the other is expected to take place in order to align the requirements with the supplier s systems. The allocation of requirements to systems shall be documented. No specific methods or formats for the unit or system requirements are expected. On CL2, operational modes and scenarios are defined in order to put the requirements into an operational context, and to detail the interaction between different systems. A trace from requirements to design and verification shall be documented and maintained. CL3 introduces additional independent verifier activities. B 300 Design (DES) 301 The design process area consists of activities to establish a design on different levels. Together with the interface related activities in the integration process area (INT), this creates the design basis from which the systems and related software can be produced and verified. On CL1, each system is designed with identification of major sub-systems and components. The external interfaces shall be documented and coordinated with other relevant systems. On CL2, the unit design is documented, maintained, and analysed with focus on integration of the systems. A strategy for handling of current and future obsolescence is expected to be defined, and design guidelines to be established. The architecture of relevant systems and software components is detailed and documented, including new, reused, and parameterized software. The documentation related to any base-products shall be kept up to date. CL3 introduces additional independent verifier activities. B 400 Implementation (IMP) 401 The implementation process area covers the coding and configuration activities needed to create and customize software modules in order to fulfil the specified design. In addition, associated support documentation shall be created. On CL1, the software components are programmed, parameterized and tested based on a baselined design. On CL2, implementation guidelines and methods are expected to be used as additional input to the programming and parameterization, and support documentation like user manuals is produced. CL3 does not add any requirements.

17 Ch.2 Sec.4 Page 17 B 500 Acquisition (ACQ) 501 The acquisition process area includes activities related to when a supplier uses sub-suppliers to develop or deliver components/systems. It covers both the situation where configuration and development of the software components is subcontracted and the situation where the supplier buys 'commercial off the shelf' (COTS) systems. On CL1, specific contracts between the supplier and the sub-supplier are established and followed-up. The components or systems are verified at delivery and it shall be ensured that the delivered component/system can be integrated into the system/unit in question. On CL2, the COTS systems are selected based on defined criteria. Intermediate deliveries are reviewed, and acquired components or systems are monitored with regards to obsolescence during the operation phase. CL3 does not add any requirements. B 600 Integration (INT) 601 The integration process area covers the assembly of the systems into the unit, and activities to coordinate the interfaces between the systems. On CL1, the responsibilities regarding each system and how it is to be integrated are defined. On CL2, a specific integration plan is produced. Inter-system interfaces are coordinated and systems checked against pre-defined criteria before the integration takes place. CL3 introduces additional independent verifier activities. B 700 Verification and Validation (VV) 701 The verification and validation process area addresses the quality assurance activities needed to ensure that that each software component, each system and the integrated systems in concert perform as expected and fulfil the needs of the intended use. On CL1, the focus is on the individual systems. It is required that a verification strategy is defined, and that basic verification activities like FAT, peer reviews, and qualification of reused software are prepared and performed according to this strategy. It is also expected that the owner performs validation testing during the acceptance phase, and when modifications and upgrades are performed during the operation phase. On CL2 the focus is on the functionality and performance of the integrated systems working together, and on early verification of the correctness and the completeness of requirements, interface specifications, user interfaces, and design documentation. The verification and validation results are expected to be analysed and compared with defined targets. On CL3, the focus is on an elaborated system testing, and that an independent party performs testing on the system(s). Additional independent verifier activities are also introduced. B 800 Reliability, Availability, Maintainability and Safety (RAMS) 801 The reliability, availability, maintainability and safety (RAMS) process area gathers the activities dealing with the definition, analysis and verification of the RAMS properties of the unit and specific systems. Security aspects are also included. On CL1, the focus is on the safety part, meaning that applicable laws and regulations regarding safety are identified, and that software and software failures are taken into account when doing safety analysis. In the operation phase a structured way of doing maintenance is required. On CL 2, the focus is on the reliability, availability and maintainability (RAM) of the systems in question. Goals regarding RAM are established, analysed and verified, but the goals can be qualitative in nature. Risks and mitigations related to the RAMS aspects are managed. The activities related to handling of the RAMS aspects are planned and followed-up during the project. Security aspects are dealt with by performing security audits. On CL3, the focus is on RAM objectives that are explicitly defined, analysed and proven fulfilled. In order to achieve this, the RAM objectives need to be quantitative. Additional independent verifier activities are also introduced. B 900 Project Management (PM) 901 The project management process area covers the activities required to make sure that the project plans for the different organizations involved are created, synchronized and followed-up. On CL1, basic project management activities regarding project planning and tracking are required, and there are no additional requirements at CL2 and CL3.

18 Ch.2 Sec.4 Page 18 B 1000 Risk Management (RISK) 1001 The risk management process area covers activities related to identifying, mitigating and tracking product and project risks related to systems and software. Based on the risks, the different systems are assigned a confidence level. On CL1, risks are identified, reviewed, tracked, and updated. On CL2, also the risk mitigation actions shall be tracked to verify that they have the expected effect on the risk. CL3 introduces additional independent verifier activities. B 1100 Process and Quality Assurance (PQA) 1101 The process and quality assurance process area covers the activities needed to define and follow up the way of working within the project. It also covers the activities needed to make sure that the involved organizations fulfil the requirements in this standard. On CL1, the applicable procedures for each organization are defined and when necessary coordinated with the other roles. The adherence to the defined procedures is followed-up by each organization. DNV will follow-up on the adherence to the requirements in this standard. There are no additional requirements at CL2 and CL3. B 1200 Configuration Management (CM) 1201 The configuration management area covers activities to make sure that changes to documents and software are performed in a controlled way, and to ensure the integrity and consistency of the systems, their configuration, and all related work products (requirements, design, interface specifications, specifications, source code, documentation, etc.). On CL1, the configuration management area includes all required activities, and there are no additional requirements at CL2 and CL3.

19 Ch.2 Sec.5 Page 19 SECTION 5 ISDS REQUIREMENTS FOR OWNERS A. Owner requirements A 100 Requirements under the owner s responsibility 101 The following Table A1 lists the requirements under the owner s responsibility. See also Table A2 for the associated acceptance criteria and Table A3 for documentation criteria. 102 The owner shall also contribute to requirements that are under the responsibility of other roles. 103 Appendix B fully specifies the requirements for all roles. Table A1: Requirements under owner s responsibility Reference Required activity Contributor(s) Phase CL A.PQA.1 Define procedures (owner) Basic engineering CL1 A.RAMS.2 Define RAM related requirements and objectives Basic engineering CL2 A.REQ.1 Define mission, objectives and shared vision Basic engineering CL1 A.REQ.3 Define operational modes and scenarios to capture expected behaviour Basic engineering CL2 A.RISK.1 Define a strategy for risk management System integrator Basic engineering CL2 A.RISK.3 Assign confidence levels System integrator Basic engineering CL1 A.VV.1 Validate the concept of the unit with the users System integrator Basic engineering CL2 B.DES.5 Define obsolescence strategy System integrator, Supplier Engineering CL2 D.VV.1 Perform validation testing System integrator, Supplier Acceptance CL1 D.VV.2 Perform validation with operational scenarios System integrator, Supplier Acceptance CL2 D.VV.3 Analyse validation results with respect to targets Acceptance CL2 E.CM.1 Manage change requests during operation Operation CL1 E.CM.2 Perform configuration audits Supplier Operation CL1 E.PQA.1 Define procedures for problem resolution, change handling, and maintenance activities Supplier Operation CL1 E.RAMS.1 Maintain and execute the plan for maintenance in operation Supplier Operation CL1 E.RAMS.2 Collect RAMS data Operation CL2 E.RAMS.3 Analyse RAMS data and address discrepancies Operation CL2 E.RAMS.4 Perform RAMS impact analysis of changes Operation CL2 E.RAMS.5 Periodically perform security audits of the systems in operation Operation CL2 E.VV.1 Perform validation testing after changes in the systems in operation Supplier Operation CL1 E.VV.2 Perform validation with operational scenarios after changes in the systems in operation Supplier Operation CL2 X.PQA.1 Control procedures (owner) Several CL1 X.PQA.4 Follow-up of ISDS assessment gaps (owner) Several CL1

20 Ch.2 Sec.5 Page 20 A 200 Acceptance criteria for owner assessments 201 The following Table A2 lists the acceptance criteria for assessments of the owner. The following evidence shall be presented to the independent verifier during assessments to document that the required activities have been performed. 202 See also Table A3 for the required documentation criteria. Table A2: Acceptance criteria for assessments of owner Reference Assessment criteria A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, clear roles and responsibilities and defined ways of A.PQA.1 interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others). Listing of RAM requirements. A.RAMS.2 For CL2: qualitative requirements are acceptable. For CL3: quantitative requirements (objectives) are required. Unit design intention and philosophy: The vision of the unit/system, descriptions of the unit/systems A.REQ.1 overall behaviour and the expected business/safety/environmental performance. A.REQ.3 Vessel specification: description of the operational modes and corresponding key operational scenarios, detailed to the level of the different systems. A.RISK.1 Risk management procedure. Blank risk register. A.RISK.3 Confidence level matrix for the relevant systems. Unit concept presentation: Simulations and Minutes of System Concept Review Meeting. A.VV.1 FEED study. Obsolescence management plan: Authorised vendor list, Spare parts list (hardware & software), stock, B.DES.5 alternate spare parts list, management of intellectual property. Obsolescence criteria for software. Manufacturer preferred equipment list. Test procedure: black box tests, boundary tests, software behaviour and parameterisation and calibration. D.VV.1 Test reports: executed consistent with procedure. Test issue list: deviations (punches) and variations. Test procedure: operational scenarios. D.VV.2 Test reports: tests performed in compliance with procedure and coverage of scenarios. Test procedure: quality criteria. D.VV.3 Test reports: analysis of the results. Test issue list. Change requests Impact analysis Change orders E.CM.1 Work orders Problem reports Release notes Maintenance logs E.CM.2 Configuration audit reports. Configuration management plan. Configuration management procedure: migration issues and software obsolescence (ref E.ACQ.1). Maintenance procedures: procedures for the maintenance, software update, migration and retirement, E.PQA.1 backup and restore procedures and procedures for receiving, recording, resolving, tracking problems and modification requests. Change management procedure. Issue tracking and resolution procedure. Maintenance plan: configuration items, audit activities, maintenance activities, expected software update, migration and retirement activities, maintenance intervals and tailored procedures for the maintenance in E.RAMS.1 operation. Malicious software scan log files records. Maintenance logs. RAMS data collection system. E.RAMS.2 RAMS data collected. E.RAMS.3 RAMS analysis. E.RAMS.4 Impact analysis showing RAMS evaluation. E.RAMS.5 Security audit report.

21 Ch.2 Sec.5 Page 21 Table A2: Acceptance criteria for assessments of owner (Continued) Reference Assessment criteria E.VV.1 Test procedure: includes black box tests and includes boundary tests. Test reports: consistent with procedure. E.VV.2 Test procedures: Covering relevant Operational scenarios. Test reports: tests performed in compliance with procedure and analysis of the results. X.PQA.1 Proof that process adherence is being assessed: Quality control records, Project control records and Minutes of meetings, or other relevant information. X.PQA.4 Corrective action plan: Responsibility allocation for actions, Records of actions taken and Evidence of implementation of the actions. A 300 Documentation criteria for the owner 301 The table below lists all documents to be sent to the independent verifier and in which activities the independent verifier is going to use the different documents. 302 When the independent verifier is expected to comment on the document, the word reviewed is employed. For documents which serve as background information to put the reviewed documents in a context, the word used is employed. 303 Most documents are provided for information (FI). The only document that is sent to the independent verifier for approval (AP) is the corrective action plan. Table A3: Documents required for review Reference Documents A.PQA.1 No documentation to be submitted to DNV for review. List of RAM requirements unit (FI): A.RAMS.2 - reviewed in A.IV.2 and B.IV.4 at CL3 - used in D.IV.3 at CL3. List of RAM requirements system (FI) used in C.IV.3 at CL3. A.REQ.1 Design Philosophy (FI) used in A.IV.1 at CL3. A.REQ.3 Vessel specification (FI) reviewed in A.IV.1 at CL3. A.RISK.1 No documentation to be submitted to DNV for review. Vessel specification (confidence levels) (FI): A.RISK.3 - reviewed in A.IV.1 at CL3 - used in A.IV.2 and B.IV.4 at CL3. A.VV.1 No documentation to be submitted to DNV for review. B.DES.5 No documentation to be submitted to DNV for review. Test procedure for quay and sea trials (FI) and Report from quay and sea trials (FI) reviewed in D.IV.1 at D.VV.1 CL2 and CL3. Report from quay and sea trials (FI) used in D.IV.2 at CL3. D.VV.2 Test procedure (FI) and Test report (FI) reviewed in D.IV.1 at CL2 and CL3. Test report (FI) used in D.IV.2 at CL3. D.VV.3 Verification analysis report (FI) reviewed in D.IV.2 at CL3. E.CM.1 No documentation to be submitted to DNV for review. E.CM.2 No documentation to be submitted to DNV for review. E.PQA.1 No documentation to be submitted to DNV for review. E.RAMS.1 No documentation to be submitted to DNV for review. E.RAMS.2 No documentation to be submitted to DNV for review. E.RAMS.3 No documentation to be submitted to DNV for review. E.RAMS.4 No documentation to be submitted to DNV for review. E.RAMS.5 No documentation to be submitted to DNV for review. E.VV.1 Test procedure (FI) and Test report (FI) reviewed in E.IV.1 at CL3. E.VV.2 Test procedure (FI) and Test report (FI) reviewed in E.IV.1 at CL3. X.PQA.1 No documentation to be submitted to DNV for review. X.PQA.4 Corrective action plan (AP) reviewed and approved in X.IV.1.

22 Ch.2 Sec.6 Page 22 SECTION 6 ISDS REQUIREMENTS FOR SYSTEM INTEGRATORS A. System integrator requirements A 100 Requirements under the system integrator s responsibility 101 The following Table A1 lists the requirements under the system integrator s responsibility. See also Table A2 for the associated acceptance criteria and Table A3 for documentation criteria. 102 The system integrator shall also contribute to requirements that are under the responsibility of other roles. 103 Appendix B fully specifies the requirements for all roles. Table A1: Requirements under system integrator s responsibility Reference Required activity Contributor(s) Phase CL A.CM.1 Establish a baseline of requirements for the unit Owner Basic engineering CL1 A.DES.1 Establish the unit design Owner Basic engineering CL2 A.PM.1 Establish the master plan Owner Basic engineering CL1 A.PQA.2 Define procedures (system integrator) Basic engineering CL1 A.RAMS.1 Determine safety rules, standards and laws applicable Owner Basic engineering CL1 A.RAMS.3 Develop the RAMS plan for the unit Owner Basic engineering CL2 A.REQ.2 Collect requirements for the unit and systems Owner Basic engineering CL1 A.REQ.4 Allocate functions and requirements to systems Owner Basic engineering CL1 A.REQ.5 Consult potential suppliers for acquiring of systems Owner Basic engineering CL1 A.REQ.6 Establish traceability of requirements Basic engineering CL2 A.RISK.2 Jointly identify risks Owner Basic engineering CL1 A.VV.2 Verify the unit and system requirements Basic engineering CL2 B.CM.1 Establish baselines of requirements and design Owner Engineering CL1 B.CM.2 Establish and implement configuration management Owner Engineering CL1 B.DES.3 Use established design guidelines and methods Engineering CL2 B.DES.4 Analyse and refine the unit design Owner, Supplier Engineering CL2 B.INT.1 Define integration plan Supplier Engineering CL2 B.INT.2 Coordinate inter-system interfaces Supplier Engineering CL2 B.PM.1 Establish the project plan for each organisation Owner Engineering CL1 B.PM.2 Coordinate and integrate the project plans with the master plan Owner, Supplier Engineering CL1 B.RAMS.1 Identify software-related RAMS risks and priorities Owner Engineering CL2 B.RAMS.2 Identify RAMS risk mitigation actions Engineering CL2 B.VV.1 Define verification and validation strategy Owner Engineering CL1 B.VV.2 Review the design with respect to requirements and design rules Owner Engineering CL2 B.VV.3 Review consistency between design and operational scenarios Engineering CL2 B.VV.4 Review interface specifications Engineering CL2 B.VV.5 Validate critical or novel user-system interactions Owner, Supplier Engineering CL2 Check readiness status of systems and components before C.INT.1 integration Construction CL2

23 Ch.2 Sec.6 Page 23 Table A1: Requirements under system integrator s responsibility (Continued) Reference Required activity Contributor(s) Phase CL C.PQA.1 Establish procedures for problem resolution and maintenance activities in the construction and acceptance phases Supplier Construction CL1 C.VV.9 Arrange independent testing Supplier Construction CL3 D.CM.1 Manage software changes during commissioning Owner, Supplier Acceptance CL1 D.CM.2 Establish a release note for the systems in ISDS scope Acceptance CL1 D.CM.3 Transfer responsibility for system configuration management Owner, to owner Supplier Acceptance CL1 D.RAMS.1 Demonstrate achievement of unit RAMS requirements Supplier Acceptance CL2 D.RAMS.2 Collect data and calculate RAM values Supplier Acceptance CL3 D.RAMS.3 Perform a security audit on the deployed systems Acceptance CL2 D.VV.4 Perform systems integration tests Supplier Acceptance CL2 X.CM.1 Track and control changes to the baselines Several CL1 X.PM.1 Monitor project status against plan Owner, Supplier Several CL1 X.PM.2 Perform joint project milestone reviews Owner, Supplier Several CL1 X.PQA.2 Control procedures (system integrator) Several CL1 X.PQA.5 Follow-up of ISDS assessment gaps (system integrator) Several CL1 X.REQ.1 Maintain requirements traceability information Several CL2 X.RISK.1 Track, review and update risks Owner, Supplier Several CL1 X.RISK.2 Decide, implement and track risk mitigation actions to closure Owner Several CL2 X.VV.2 Detail procedures for testing Several CL1 A 200 Acceptance criteria for system integrator assessments 201 The following Table A2 lists the acceptance criteria for assessments of the system integrator. The following evidence shall be presented to the independent verifier during assessments to document that the required activities have been performed. 202 See also Table A3 for the required documentation criteria. Table A2: Acceptance criteria for assessments of system integrator Reference Assessment criteria Approved and controlled unit requirements document. A.CM.1 Revision history of unit requirements document. A.DES.1 Unit design: unit design specifications, systems/network topology and functional descriptions. A.PM.1 Master plan: Activities, work breakdown structure (WBS), schedule, and milestones. A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, clear roles and responsibilities and defined ways of A.PQA.2 interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others). Listing of regulatory requirements that apply regarding safety. A.RAMS.1 Resolution of conflicting rules. Application guidelines. Plan(s) showing the methods, tools, and procedures to be used for RAMS activities. Schedule of RAMS activities. A.RAMS.3 Expectations on the suppliers RAMS plan. RAM data to be collected (CL3). A.REQ.2 Vessel specification: operational requirements, functional requirements, non-functional requirements and technical constraints. A.REQ.4 Design specification (or requirements) for the relevant systems. System request for proposal (RfP): functional specifications, generic system requirements and A.REQ.5 obsolescence information. Requirements compliance information (on CL2 and above). Traceability information between requirements on unit level and requirements on the different systems. A.REQ.6 Defined mechanisms and ambition-level regarding requirements traceability. Project risk list: risk list with risks related to e.g. requirements, schedule, effort, quality, performance, A.RISK.2 consistency and obsolescence (for both hardware and software).

24 Ch.2 Sec.6 Page 24 Table A2: Acceptance criteria for assessments of system integrator (Continued) Reference Assessment criteria Review records of the unit requirements. A.VV.2 Review records for the system requirements. Baseline repositories. Identification of baselines. B.CM.1 Approved and controlled documents (baselines) for: unit specifications, unit design, system requirements, system design, interface specifications and base products. Configuration management plan: Definition of a Change Control Board (CCB) process or similar, identification of required baselines, required baseline content, change request forms. B.CM.2 Change requests and change decisions. Version history information of baselines. Defined rules and mechanisms for version control. Effective implementation of version control mechanisms. System design guidelines: including RAMS related aspects. B.DES.3 Unit design guidelines: including RAMS related aspects. B.DES.4 Updated unit design documentation: unit design specifications, systems/network topology with software components, interface specifications, and functional descriptions. Plan for integration of systems into unit: The responsibilities of the different organizations, dependencies among systems, sequence for integration, integration environment, tests and integration readiness criteria. B.INT.1 Plan for integration of sub-systems and components into systems (when required): Dependencies among systems, sub-systems and components, sequence for integration, integration environment, tests and integration readiness criteria. Interface overview/matrix information with assigned responsibilities. B.INT.2 Agreed inter-system interface specifications containing: protocol selected, definition of commands, messages, data and alarms to be communicated and specifications of message formats. Interface definition and verification status. Schedule. Project plan: WBS, technical attributes used for estimating, effort and costs estimates, deliverables and B.PM.1 milestones, configuration management plan. Resource allocation. Master plan. B.PM.2 Project plans. RAMS hazard and risk list showing consideration of software risks. B.RAMS.1 Defined risk identification and analysis methods. Relevant risks are communicated to other roles. RAMS hazard and risk mitigation list showing mitigation actions for software risks. B.RAMS.2 Relevant mitigation actions are communicated to other roles Verification strategy: which part to verify: unit, system, sub-system, component, module, design documents. Method specification documents, etc.: which methods to use for this verification: testing, inspection, code analysis, simulation, prototyping, peer review techniques, quality criteria and targets, which test B.VV.1 types to use: functional, performance, regression, user interface, negative, what environment to use for verification and identification of the test stages (e.g. sea trials, integration tests, commissioning, FAT, internal testing, component testing) to be used for the verification and the schedule for those tests. Validation strategy: products to be validated, validation criteria, operational scenarios, methods and environments. Documented design review records addressing: requirements verification, design rules and verification B.VV.2 of uncertainties. B.VV.3 Minutes from review: review results considering consistency of interface/function/component/scenarios. Interface specification reviews addressing at least: consistency between input and output signals, B.VV.4 frequency and scan rates, deadlocks, propagation of failures from one part to another, engineering units, network domination. Validation records including: workshop minutes, user representative s participation and comments and B.VV.5 agreed action lists. C.INT.1 Integration readiness criteria fulfilled per component and per system. Agreed maintenance procedures: Procedures for general system maintenance activities and procedures for software update, backup and roll-back. C.PQA.1 Agreed problem resolution procedures: Procedures for receiving, recording, resolving, tracking problems (punches) and modification requests. Test procedure: covering the system and its interfaces. C.VV.9 Test report.