Section
21 Software in systems, machinery and equipment
21.1 Goal, functional requirements and applicability
21.1.1 Goal: The use of software in systems, machinery and equipment is not to
compromise the functionality or safety of those systems, machinery and equipment.
21.1.3 Applicability: These rules apply to all systems, machinery and equipment
mentioned in the remaining Parts of Vol 2 Machinery and Engineering Systems of these Rules where
software is used as an implementation technology. They also apply to software where
the software is used in a role that has an identified impact upon the safety of the
ship. Instances where the operational performance of the software can only be
characterised accurately in probabilistic terms, e.g. Machine Learning or Artificial
Intelligence based systems, will require further and more extensive consideration
beyond the scope of this set of Rules. See also
Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems – Additional requirements for the production of software.
Figure 3.21.1 Software rules process diagram
– Machinery/Engineering system requirements
Figure 3.21.2 Software rules process diagram
– Software production requirements
21.2 Definitions
21.2.1 Software: Intellectual creation comprising the programs, procedures, data, rules and
any associated documentation relating to the operation of a data processing system
or complex hardware, where complex hardware includes but is not limited to custom
micro-coded components including application specific integrated circuits (ASIC),
programmable logic devices (PLD), field programmable gate arrays (FPGA) or similar
electronic technologies.
21.2.2 Software module: A standalone executable element of code that provides specific and
closely coupled functionality.
21.2.3 System Design Authority: Person or organisation that is responsible for the design of
the system. In this context, the single designated party responsible for system
functionality in its entirety at each lifecycle stage, from concept to disposal.
21.2.4 Software producer: The organisation responsible for producing and/or maintaining the
software module.
21.2.5 System safety hazards: The hazards to the safe operation of the ship resulting from
failure or unintended behaviour of a system, item of machinery or equipment which
incorporates software.
21.2.6 Software safety requirements: Requirements placed on the software which define what
the software must do and what the software must not do to address system safety
hazards including the degree of reliance placed upon the software.
21.2.7 Level of rigour task: A specification of the depth and breadth of software analysis
and verification activities necessary to provide a sufficient level of confidence
that a software module will function as required.
21.2.8 Software Production Standard: An International or National Standard to be applied to
the production of software
21.3 Performance requirements
21.3.1 The System Design Authority is to identify and document the system safety
hazards related to software, categorise the system, and assign the software control
categories to each software module. It is then to identify the resulting level of
rigour tasks to be applied to each software module utilising processes identified in
this Section of these Rules, or an equivalent process acceptable to LR. The
resulting software safety requirements and any safety-related statutory and
classification software requirements are to be documented and provided to the
software producer.
21.3.2 Software safety requirements are to be derived from the identified system
safety hazards and their categorisations. Consideration is to be given to the
effects of failure of a software module or unintended behaviour of a software module
which could credibly
- result in a system safety hazard;
- impair the mitigation of a system safety hazard; or
- impair recovery after a system safety hazard has occurred.
The traceability between software safety requirements and system safety
hazards is to be documented as part of this process. The establishment of a Systems
Risk Register is to be considered to assist the identification of system safety
hazards and tracing the resulting software safety requirements. Where the risk
assessment technique required by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.3 requires
the creation of a Systems Risk Register, this is to be submitted for information.
21.3.3 System safety hazards resulting from failure or unintended behaviour of
software in systems, machinery or equipment incorporating software modules are to be
established in accordance with IEC/ISO 31010 Risk Management – Risk Assessment
techniques and/or an appropriate standard acceptable to LR.
21.3.4 Where two systems or items of machinery are intended to function as
redundant components, the risk of the software introducing common mode failures that
result in the loss or unintended behaviour of both components is to be considered as
part of the hazard assessment.
21.3.5 System safety hazards are to be identified and the system categorised in
accordance with the failure effects in Table 3.21.1 System categories or an
equivalent categorisation acceptable to LR.
Table 3.21.1 System categories
| Category
|
Effects
|
Typical System Functionality
|
| I
|
Those systems, failure of which will not lead to
unsafe conditions for human safety, safety of the ship and/or
threat to the environment.
|
Monitoring function for informational or
administrative tasks
|
| II
|
Those systems, failure of which could eventually
lead to unsafe conditions for human safety, safety of the ship
and/or threat to the environment.
|
Alert and monitoring functions
Control functions which are necessary to maintain
the ship in its normal operational and habitable
conditions
|
| III
|
Those systems, failure of which could immediately
lead to unsafe conditions for human safety, safety of the ship
and/or threat to the environment.
|
Control functions for maintaining the vessel’s
propulsion and steering
Protection and safety functions
|
| IV
|
Those systems, failure of which would usually
result in loss of the ship, death, and/or irreversible
significant environmental impact.
|
Control systems for which manual intervention to
avert danger in the event of failure or malfunction is not
possible
|
21.3.6 Software modules are to be assigned a software control category in
accordance with the module’s degree of control over the system hardware, sub-systems
or components as given in Table 3.21.2 Software control
categories or an
equivalent categorisation acceptable to LR.
Table 3.21.2 Software control
categories
| Software Control Category
|
Name
|
Description
|
| 1
|
Full Control Authority
|
Software module that exercises autonomous control
authority over potentially safety-significant hardware systems,
sub-systems or components without the possibility of
predetermined safe detection and intervention by a control
entity to preclude the occurrence of a hazard.
|
| 2
|
Supported Control Authority
|
Software module that exercises control authority
over potentially safety-significant hardware systems,
sub-systems or components, allowing time for predetermined safe
detection and intervention by independent safety mechanisms to
mitigate or control the hazard.
|
| Software module that displays information requiring
immediate Operator intervention to execute a predetermined
action for mitigation of or control over a hazard. Software
exception, failure, fault or delay will allow, or fail to
prevent, hazard occurrence.
|
| 3
|
Shared Control Authority
|
Software module that issues commands over
safety-significant hardware systems, sub-systems or components
requiring a control entity to complete the command function. The
system detection and functional reaction includes redundant,
independent fault tolerant mechanisms for each defined hazardous
condition.
|
| Software module that generates information used to
make critical decisions. The system includes several redundant,
independent fault tolerant mechanisms for each hazardous
condition, detection and display.
|
| 4
|
Influential
|
Software module that generates information used to
make decisions by the Operator but does not require Operator
action to avoid a hazard.
|
21.3.7 The Level of rigour tasks to be applied to each software module during
production are to be determined in accordance with the Software safety criticality
Matrix in Table 3.21.3 Software safety
criticality matrix or an equivalent categorisation acceptable to LR.
Table 3.21.3 Software safety
criticality matrix
|
|
System Category
|
| Software Control Category
|
I
|
II
|
III
|
IV
|
| 4
|
SwCI 1
|
SwCI 1
|
SwCI 1
|
SwCI 3
|
| 3
|
SwCI 1
|
SwCI 1
|
SwCI 2
|
SwCI 3
|
| 2
|
SwCI 1
|
SwCI 2
|
SwCI 3
|
SwCI 4
|
| 1
|
SwCI 1
|
SwCI 2
|
SwCI 4
|
SwCI 4
|
|
|
|
|
|
|
|
|
Level of rigour tasks
|
| SwCI 1
|
Safety-specific
testing.
|
| SwCI 2
|
Analysis of requirements and
architecture; and conduct in-depth safety-specific
testing.
|
| SwCI 3
|
Analysis of requirements,
architecture and design; and conduct in-depth safety-specific
testing.
|
| SwCI 4
|
Analysis of requirements,
architecture, design and code; and conduct in-depth
safety-specific testing.
|
21.3.8 The Software Production Standard selected by the System Design Authority
to develop the software must be able to evidence the Levels of rigour tasks as
equivalent to those determined by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.7. The justification leading to the selection of the Software
Production Standard is to be documented and is to include the tasks described in
Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.1 to Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.7. The evidence supporting the case that the required Level of
rigour tasks have been undertaken is to be collated by the software producer and
included within the engineering and safety justification required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems – Additional requirements for the production of software 5.6.1.
Software Conformity Assessment (SCA) may be used for this purpose.
21.3.9 Where a system or item of machinery or equipment includes more than one software
module, the software safety requirements for each software module are to be
specified separately.
21.3.10 Where a system or item of machinery or equipment includes more than one software
module, the System Design Authority is responsible for the successful integration
and performance of the software modules. In such cases, the System Design Authority
is to assume those responsibilities of the software producer that relate to software
integration.
|