Section 2 Systems engineering principles
Clasification Society 2024 - Version 9.40
Clasifications Register Rules and Regulations - Rules and Regulations for the Classification of Offshore Units, July 2022 - Part 3 Functional Unit Types and Special Features - Chapter 15 Integrated Software Intensive Systems - Section 2 Systems engineering principles

Section 2 Systems engineering principles

Parent topic: Chapter 15 Integrated Software Intensive Systems

2.1 General – Scope and objectives

2.1.1 The requirements of this Section aim to ensure that risks to offshore safety and the environment, stemming from the introduction of integrated software intensive systems, are addressed insofar as they affect the objectives of classification. Hereafter, integrated software intensive system includes all systems listed in Pt 3, Ch 15, 1.1 General.

2.1.2 The requirements of this Section are to be satisfied where an integrated software intensive systems is required to be developed, constructed, installed, integrated and tested in accordance with LR’s Rules and Regulations and for which the corresponding machinery class notation is to be assigned, see Pt 1, Ch 2, 2.5 Class notations (machinery).

2.1.3 It is to be noted that as well as the requirements of this Section, the general requirements of LR’s Rules and Regulations are also to be satisfied as far as they are applicable.

2.1.4 Compliance with ISO 15288 Systems and Software Engineering – System Life Cycle Processes or an acceptable equivalent National Standard may be accepted as meeting the requirements of Pt 6, Ch 1, 2.3 Alarm systems, general requirements of the Rules for Ships.

2.2 Information to be submitted

2.2.1 The information described in 2.2.2 and 2.2.3 is to be submitted for consideration.

2.2.2 General description detailing the extent of the integrated software intensive system, the offshore unit services it is to provide, its operating principles, and its functionality and capability when operating in the environment to which it is likely to be exposed under both normal and foreseeable abnormal conditions. The general description is to be supported by the following information as applicable:
  1. System block diagram.
  2. Piping and instrumentation diagrams, communication networks.
  3. Description of operating modes, including:
    • start-up;
    • shut-down;
    • automatic:
    • reversionary;
    • manual, and
    • emergency.
  4. Description of safety related arrangements, including:
    • safeguards;
    • automatic safety systems; and
    • interfaces with offshore units safety systems.
  5. Description of connections to other offshore unit machinery, equipment and systems, including:
    • electrical;
    • mechanical;
    • fluids;
    • automation;
    • communication network; and
    • protocols of the network.
  6. Plans of physical arrangements, including:
    • location;
    • operational access; and
    • maintenance access.
  7. Operating manuals, including:
    • instructions for start-up;
    • operation;
    • shut-down and emergency;
    • instructions and frequency for maintenance;
    • instructions for adjustments to the performance;
    • parameters and functionality; and
    • details of risk mitigation arrangements.
  8. Maintenance manuals, including:
    • Instructions for routine maintenance or repair following failure.
    • Instructions for software configuration management such as upgrading and modification.
    • Disposal of components and recommended spares inventory.
2.2.3 Project process documentation including:
  1. Project management plan, see 2.3.
  2. Quality assurance plan, see 2.4.
  3. Risk management plan, see 2.5.
  4. Configuration management plan, see 2.6.
  5. Requirements definition document, see 2.9.
  6. Design definition document, see 2.8.
  7. Implementation plan, see 2.9.
  8. Integration plan, see 2.10.
  9. Verification plan, see 2.11.
  10. Validation plan, certification and survey, see 2.12.

2.3 Project management

2.3.1 A project management procedure is to be established in order to define and manage the key project processes. The project processes are to include the those described in Pt 6, Ch 1, 2.4 Safety systems, general requirements of the Rules for Ships.

2.3.2 For the entire project, and each of the processes within the project, the project management procedure is to define the following:

  1. Activities to be carried out.
  2. Required inputs and outputs.
  3. Roles of key personnel.
  4. Responsibilities of key personnel.
  5. Competence of key personnel.
  6. Schedules for the activities.
  7. Roles and responsibilities of stakeholders including Owner, Operator, Shipyard, System Integrator, Supplier or Subcontractor for each required activity of project processes from 2.3 to 2.12.

2.4 Quality assurance

2.4.1 A quality assurance procedure is to be established in order to ensure that the quality of the integrated software intensive system is in accordance with a defined quality management system that is acceptable to LR.

2.4.2 The procedure is to define the specific quality controls to be applied during the project in order to satisfy the requirements of the quality management system.

2.4.3 The quality management system is to satisfy the requirements of ISO 9001 Quality management systems. Requirements and software development is to satisfy the requirements of ISO 90003 Software engineering – Guidelines for the application of ISO 9001 to computer software, or other equivalent acceptable National Standard.

2.5 Risk management

2.5.1 A risk management procedure is to be established in order to ensure that any risks stemming from the introduction of the integrated software intensive system are addressed, in particular risks affecting:
  1. The structural strength and integrity of the offshore unit’s hull.
  2. The safety of integrated software intensive system onboard of the offshore unit.
  3. The safety of crew.
  4. The reliability of the systems identified by Pt 3, Ch 15, 1.1 General and emergency systems.
  5. The environment.
  6. Offshore drilling operations with introduction of integrated software intensive systems.

2.5.2 The procedure is to consider the hazards associated with development, integration, installation, operation, maintenance and disposal, both with the integrated software intensive system functioning correctly and following any reasonably foreseeable failure.

2.5.3 The procedure is to take account of stakeholder requirements, see Pt 3, Ch 15, 2.7 Requirements definition.

2.5.4 The procedure is to take account of design requirements, see Pt 3, Ch 15, 2.8 Design definition.

2.5.5 The procedure is to ensure that hazards are identified using acceptable and recognised hazard identification techniques, see Pt 3, Ch 15, 2.5 Risk management 2.5.9 to 2.5.14, and that the effects of the following influences are considered:
  1. Offshore unit operations, including:
    • Underway, manoeuvring, pilotage, docking, alongside and maintenance, jacking or dynamic positioning, well drilling, well completion, well control, training exercises, emergency abandon, commissioning and trials.
  2. Offshore unit conditions under normal and reasonably foreseeable abnormal operating conditions arising from failures or misuse of equipment or systems onboard of offshore unit, including:
    • Normal operation, blackout, loss of position, fire in a single compartment, explosion in a single compartment and flooding of a single compartment.
  3. Configuration and modes of operation provided for the intended control of integrated software intensive system, including:
    • Start-up, running, shut-down, automatic, reversionary, manual and emergency.
  4. Environmental conditions, including:
    • Temperature, pressure, humidity, water spray, salt mist, vibration, shock, inclination, vocanic activities, seabed conditions, hurricane or storm, subsea acoustic noise, electrical fields and magnetic fields.
  5. Dependencies, including:
    • Power, fuel, air, cooling, heating, mud, cement, data, and human input.
  6. Environmental impact of the offshore unit throughout its lifecycle, including:
    • Emissions to air, discharges to water, noise and waste products.
  7. Failures, including:
    • Human error, supply failure, system, software, communication network, machinery, equipment and component failure, random, systematic and common cause failures.
2.5.6 The procedure is to ensure that risks are analysed using acceptable and recognised Risk Based Analysis techniques, see 2.5.9 to 2.5.14, and that the following effects are considered:
  1. Local effects: Loss of function, component damage, fire, explosion, electric shock, harmful releases and hazardous releases.
  2. End effects on: Loss of services essential to the safety of the offshore unit, services essential to the safety of personnel onboard of offshore unit and services essential to the protection of the environment.

2.5.7 The procedure is to ensure that risks are eliminated wherever possible. Risks which cannot be eliminated are to be mitigated as necessary.

2.5.8 Details of risks, and the means by which they are mitigated, are to be included in the operating manual, see Pt 3, Ch 15, 2.2 Information to be submitted 2.2.2.

2.5.9 Risk Based Analysis (RBA) technique is to be selected from IEC/ISO 31010 Risk Management – Risk Assessment Techniques. The technique selected is to be carried out in accordance with the relevant International Standard or applicable National Standard and with 2.5.10 to 2.5.14. A justification is to be provided which demonstrates the suitability of the Standard and analysis technique chosen.

2.5.10 The RBA is to demonstrate that suitable risk mitigation has been achieved for all normal and foreseeable abnormal conditions. The scope of analysis required for each system is defined in 2.5.11 to 2.5.14 and in the respective parts of the Rules.

2.5.11 The RBA is to be organised in terms of items of equipment and function. The effects of item failures or damage at stated level and at higher levels are to be analysed to determine the effects on the system as a whole. Actions for mitigation are to be determined.

2.5.12 RBA is to:
  1. Identify the equipment or sub-system and their mode of operation;
  2. Identify potential failure modes and damage situations and their causes;
  3. Evaluate the effects on the system of each failure mode and damage situation;
  4. Identify measures for reducing the risks associated with each failure mode;
  5. Identify measures for failure mitigation; and
  6. Identify trials and testing necessary to prove conclusions.

2.5.13 At sub-system level it is acceptable, for the purpose of these Rules, to consider failure of equipment items and their functions, e.g., failure of a pump to produce flow or pressure head. It is not required that the failure of components within that pump be analysed. In addition, failure need only be dealt with as a cause of failure of the pump.

2.5.14 Where RBA is used for consideration of systems that depend on software based functions for control or co-ordination, the analysis is to investigate failure of the function rather than a specific analysis of the software code.

2.6 Configuration management

2.6.1 A configuration management procedure is to be established in order to ensure traceability of the configuration of the integrated software intensive system, its subsystems and its components.

2.6.2 The procedure is to identify items essential for the safety or operation of the integrated software intensive system (configuration control items) which could foreseeably be changed during the lifetime of the integrated software intensive system, including:
  1. Documentation.
  2. Software.
  3. Sensors.
  4. Actuators.
  5. Instrumentation.
  6. Valves.
  7. Pumps.
  8. BOP stacks.

2.6.3 The procedure is to take account of the design requirements, see Pt 3, Ch 15, 2.8 Design definition.

2.6.4 The procedure is to include items used to mitigate risks, see Pt 3, Ch 15, 2.5 Risk management.

2.6.5 The procedure is to ensure that any changes to configuration control items are:
  1. Identified.
  2. Recorded.
  3. Evaluated.
  4. Approved.
  5. Incorporated.
  6. Verified.

2.6.6 The procedure is to specify the required software testing for any changes to configuration control items for the whole lifecycle of the integrated software intensive system.

2.7 Requirements definition

2.7.1 A requirements definition procedure is to be established in order to define the functional behaviour and performance throughout the whole lifecycle of the integrated software intensive system required by individual stakeholders, in the environments to which the integrated software intensive system is likely to be exposed under both normal and foreseeable emergency conditions.

2.7.2 The procedure is to take account of requirements resulting from key stakeholders, including:
  1. Owner.
  2. Operator.
  3. Crew.
  4. Shipyard.
  5. Systems integrator.
  6. Maintenance personnel.
  7. Surveyors.
  8. Manufacturers and suppliers.
  9. National Administration.
  10. LR.
2.7.3 The procedure is to take account of requirements resulting from the following influences:
  1. Offshore unit operations, see Pt 3, Ch 15, 2.5 Risk management 2.5.1).
  2. Ship conditions, see 2.5.5(b).
  3. Environmental conditions, see 2.5.5(d).
  4. Applicable provisions, including:
    • Statutory legislation;
    • classification requirements;
    • international standards;
    • national standards; and
    • codes of practice.
  5. Expected users, including:
    • Multi-national users with a range of national languages and cultures
    • fatigued users;
    • users without dedicated training; and
    • maintenance and survey personnel.
  6. Design, construction and operational constraints, including:
    • Effect of particular design decisions or component choices on other aspects of design, risk and production engineering compromises, verification, integration and validation considerations, maintenance and disposal, and changes in use.

2.7.4 The procedure is to specify the functional behaviour and performance requirements and is to identify the source of the requirements.

2.7.5 The requirements specification is to fully specify, either directly or by reference to other submitted documents, all external interfaces between the software product and other software or hardware.

2.7.6 The procedure is to detail required functions the integrated software intensive system is to perform under both normal and foreseeable abnormal conditions.

2.7.7 The procedure is to define specific boundary conditions of each required function of the integrated software intensive system.

2.7.8 The procedure is to ensure overall integrity of the system requirements through verification and analysis of integrity of sets of requirements.

2.8 Design definition

2.8.1 A design definition procedure is to be established in order to define the requirements for the design of the integrated software intensive system which satisfies stakeholder requirements, quality assurance requirements, risk mitigate requirements and complies with basic internationally recognised design requirements for safety and functionality.

2.8.2 The procedure is to ensure that the design of the integrated software intensive system satisfies:
  1. Statutory legislation.
  2. LR’s requirements.
  3. International Standards and Codes of Practice where relevant.

2.8.3 The procedure is to take account of stakeholder requirements, see 2.7.

2.8.4 The procedure is to take account of quality assurance requirements, see Pt 3, Ch 15, 2.4 Quality assurance.

2.8.5 The procedure is to take account of risk management requirements, see Pt 3, Ch 15, 2.5 Risk management.

2.8.6 The procedure is to ensure that the requirements for the design of major components and subsystems of the integrated software intensive system can be verified before and after integration.

2.8.7 The procedure is to specify the design requirements and is to identify the source of the requirements.

2.8.8 Any deviations from stakeholder requirements are to be identified, justified and accepted by the originating stakeholder, communicated to involved stakeholders and documented.

2.9 Implementation

2.9.1 An implementation procedure and technology is to be selected in order to realise specific integrated software intensive system that satisfies the design requirements of the machinery or an engineering system or integrated software intensive system through verification, see Pt 3, Ch 15, 2.11 Verification and satisfies stakeholder requirements through validation, see Pt 3, Ch 15, 2.12 Validation.

2.9.2 The procedure and technology is to take account of quality assurance requirements, see 2.4.

2.9.3 The procedure and technology is to take account of design requirements, see 2.8.

2.9.4 Software lifecycle activities are to be carried out in accordance with an acceptable quality management system, see Pt 6, Ch 1, 2.13 Programmable electronic systems - Additional requirements for essential services and safety critical systems 2.13.2 and Pt 6, Ch 1, 2.13 Programmable electronic systems - Additional requirements for essential services and safety critical systems 2.13.7 of the Rules for Ships. Appropriate safety related processes, methods, techniques and tools are to be applied to software development and maintenance by the manufacturer.

2.9.5 To demonstrate compliance with 2.9.4:
  1. software quality plans and safety evidence are to be submitted for consideration;
  2. an assessment inspection of the manufacturer’s completed development is to be carried out by LR. The inspection is to be tailored to verify application of the standards and codes used in software safety assurance accepted by LR; and
  3. for software development lifecycle, an evidence of satisfying internationally recognised standards and practices that are acceptable to LR is to submit for consideration of satisfying 2.9.4(b).

2.10 Integration

2.10.1 An integration procedure is to be established in order to ensure that the integrated software intensive system is assembled in a sequence which allows verification of individual system, individual subsystems and major components following integration in advance of validating the entire integrated software intensive system.

2.10.2 The procedure is to take account of the verification requirements, see 2.11.

2.10.3 The procedure is to identify the subsystems and major components, the sequence in which they are to be integrated, the points in the project at which integration is to be carried out, and the points in the project at which verification is to be carried out.

2.11 Verification

2.11.1 A verification procedure is to be established in order to ensure that systems, subsystems and major components of the integrated software intensive system satisfy their design requirements.

2.11.2 The procedure is to verify design requirements, see Pt 3, Ch 15, 2.8 Design definition.

2.11.3 The procedure is to identify the requirements to be verified, the means by which they are to be verified, the verification methods and techniques, and the points in the project at which verification is to be carried out.

2.11.4 The procedure is to be based on one or a combination of the following activities as appropriate:
  1. Design review.
  2. Product inspection.
  3. Process audit.
  4. Product testing.

2.12 Validation

2.12.1 A validation procedure is to be established in order to ensure the functional behaviour and performance of the integrated software intensive system meets with its functional and performance requirements in its intended operational environment.

2.12.2 The procedure is to validate stakeholder requirements, see Pt 3, Ch 15, 2.7 Requirements definition.

2.12.3 The procedure is to validate arrangements required to mitigate risks, see Pt 3, Ch 15, 2.5 Risk management.

2.12.4 The procedure is to validate the traceability of the configuration control items, see Pt 3, Ch 15, 2.6 Configuration management.

2.12.5 The procedure is to identify the requirements to be validated, the means by which they are be validated and the points in the project at which validation is to be carried out, including:
  1. Factory acceptance testing.
  2. Integration testing.
  3. Commissioning.
  4. Sea trials.
  5. Survey.
Copyright 2022 Clasifications Register Group Limited, International Maritime Organization, International Labour Organization or Maritime and Coastguard Agency. All rights reserved. Clasifications Register Group Limited, its affiliates and subsidiaries and their respective officers, employees or agents are, individually and collectively, referred to in this clause as 'Clasifications Register'. Clasifications Register assumes no responsibility and shall not be liable to any person for any loss, damage or expense caused by reliance on the information or advice in this document or howsoever provided, unless that person has signed a contract with the relevant Clasifications Register entity for the provision of this information or advice and in that case any responsibility or liability is exclusively on the terms and conditions set out in that contract.