Section
5 Programmable electronic systems (PES)
5.1 General requirements
5.1.1 The requirements of this Section are to be complied with where control,
alarm, monitoring or safety systems incorporate programmable electronic equipment.
Mobility systems, ship type systems and safety critical systems incorporating shared
data communication links and systems which are integrated are to comply with the
additional requirements of Vol 2, Pt 9, Ch 8, 5.2 Data communication links, Vol 2, Pt 9, Ch 8, 5.3 Additional requirements for wireless data communication links,
Vol 2, Pt 9, Ch 8, 5.4 Additional requirements for Mobility category and safety critical systems
and Vol 2, Pt 9, Ch 8, 5.5 Additional requirements for integrated systems as applicable.
5.1.2 Systems
complying with ISO 17894, Ships and marine technology –
Computer applications – General principles for the development
and use of programmable electronic systems in marine applications, may
be accepted as meeting the requirements of this Section in which case
evidence of compliance is to be submitted for consideration.
5.1.3 Where
programmable electronic systems share resources, any components that
can affect the ability to effectively provide required control, alarm
or safety functions are to fulfil the requirements of Vol 2, Pt 9, Ch 8, 5.1 General requirements related to providing those
required functions.
5.1.4 Programmable
electronic equipment is to revert to a defined safe state on initial
start up or re-start in the event of failure.
5.1.5 In the
event of failure of any programmable electronic equipment, the system,
and any other system to which it is connected, is to fail to a defined
safe state or maintain safe operation, as applicable.
5.1.8 Programmable
electronic equipment is to be provided with self-monitoring capabilities
such that hardware and functional failures will initiate an audible
and visual alarm in accordance with the requirements of Vol 2, Pt 9, Ch 7, 4.3 Alarm systems, general requirements and, where applicable, Vol 2, Pt 9, Ch 1, 4.2 Alarm systems for machinery. Hardware failure indications
are to enable faults to be identifiable at least down to the level
of the lowest replaceable unit and the self-monitoring capabilities
are to ensure that diagnostic information is readily available.
5.1.11 Where
it is necessary to store data required for system operation in volatile
memory, a back-up power supply is to be provided that prevents data
loss in the event of loss of the normal power supply. The submission
required by Vol 2, Pt 9, Ch 1, 1.4 Documentation required for design review 1.4.21 is
to include details of any routine maintenance necessary and the measures
necessary to restore system operation in the event of data loss as
a result of power supply failure.
5.1.12 Back-up
power supplies required by Vol 2, Pt 9, Ch 8, 5.1 General requirements 5.1.11 are
to be rated to supply the connected load for a defined period of time
that allows sufficient time for the re-instatement of supply in the
event of loss of the normal power supply as a result of failure of
a main source of electrical power. This period is in any case to be
not less than 30 minutes.
5.1.13 Where regular battery replacement is required to maintain the availability
of volatile memory back-up power supply required by Vol 2, Pt 9, Ch 8, 5.1 General requirements 5.1.11, these are to be included in the schedule of
batteries required by Vol 2, Pt 9, Ch 1, 1.4 Documentation required for design review 1.4.17 and Vol 2, Pt 9, Ch 2, 7.7 Recording of batteries for emergency and essential services,
irrespective of battery type and size. Applicable entries in this schedule are to note
that these batteries are not for safety critical systems, Mobility systems, Ship Type
systems, or emergency services.
5.1.14 Access
to system configuration, programs and data is to be restricted by
physical and/or logical means providing effective security against
unauthorised alteration.
5.1.15 Where
date and time information is required by the equipment, this is to
be provided by means of a battery backed clock with restricted access
for alteration. Date and time information is to be fully represented
and utilised.
5.1.16 Displays
and controls are to be protected against liquid ingress due to spillage
or spraying.
5.1.17 Display
units are to comply with the requirements of an acceptable National
or International Standard, e.g. IEC 60950 in respect of emission of
ionising radiation.
5.1.18 Where
systems detect fault conditions, any affected mimic diagrams are to
ensure that the status of unreliable and incorrect data is clearly
identified.
5.1.19 Multi-function
displays and controls are to be duplicated and interchangeable where
used for the control or monitoring of more than one system, machinery
item or item of equipment. At least one unit at the main control station
is to be supplied from an independent uninterruptible power system
(UPS).
5.1.20 The
number of multi-function display and control units provided at the
main control station and their power supply arrangements are to be
sufficient to ensure continuing safe operation from a multi-function
display and control unit in the event of failure of any unit or any
power supply.
5.1.21 Software lifecycle activities, e.g. design, development, supply and
maintenance, are to be carried out in accordance with an acceptable quality management
system. Project specific software quality plans are to be submitted. These are to
demonstrate that the provisions of ISO/IEC 90003:2014 Software engineering –
Guidelines for the application of ISO 9001:2015 to computer software or an
acceptable International, National or naval standard, are incorporated. The plans are to
define responsibilities for the lifecycle activities, including verification,
validation, module testing and integration with other components or systems.
5.2 Data communication links
5.2.1 Where control, alarm or safety systems use shared data communication links
to transfer data, the requirements of Vol 2, Pt 9, Ch 8, 5.2 Data communication links 5.2.2 are to be complied with. The requirements
apply to local area networks, fieldbuses and other types of data communication link
which make use of a shared medium to transfer control, alarm or safety related data
between distributed programmable electronic equipment or systems.
5.2.2 Data communication is to be automatically restored within 45 seconds in the
event of a single component failure. Upon restoration, priority is to be given to
updating safety critical data and control, alarm and safety related data for Mobility
and/or Ship Type systems. Components comprise all items required to facilitate data
communication, including cables, switches, repeaters, software components and power
supplies.
5.2.4 The properties of the data communication link, (e.g. bandwidth, access
control method, etc.), are to ensure that all connected systems will operate in a safe,
stable and repeatable manner under all operating conditions. The latency of control,
alarm and safety related data is not to exceed two seconds.
5.2.5 Protocols are to ensure the integrity of control, alarm and safety related
data, and provide timely recovery of corrupted or invalid data.
5.2.8 Means are to be provided to prevent unintended connection or disconnection
of any equipment where this may affect the performance of any other systems in
operation.
5.2.10 The installation is to provide adequate protection against mechanical
damage and electromagnetic interference.
5.2.11 Components are to be located with appropriate segregation such that the risk
of mechanical damage or electromagnetic interference resulting in the loss of both
active and standby components is minimised. Duplicated data communication links are to
be routed to give as much physical separation as is practical.
5.2.12 The data communication links are to be resilient as described elsewhere in this section
of the rules to the accumulation of broadcast and multicast network traffic. The audible
and visual alarms required by Vol 2, Pt 9, Ch 8, 5.2 Data communication links 5.2.6 are
to be initiated in the event of such accumulations of traffic occurring and affecting
normal network performance. Demonstration of this resilience is to be shown by a
practical test or other acceptable means appropriate to the communication link, and
documented.
5.3 Additional requirements for wireless data communication links
5.3.3 For
services which need not be in operation continuously, wireless data
communication links may be considered where an alternative means of
operation that can be brought into action within an acceptable period
of time is provided.
5.3.4 Wireless
data communication is to employ recognised international wireless
communication system protocols that incorporate the following:
-
Message integrity:
fault prevention, detection, diagnosis, and correction ensuring the
received message is not corrupted or altered when compared to the
transmitted message.
-
Configuration
and device authentication: is only to permit connection of devices
that are included in the system design.
-
Message encryption:
protection of the confidentiality and/or criticality of the data content.
-
Security management:
protection of network assets, prevention of unauthorised access to
network assets.
5.3.5 The
wireless system is to comply with the radio frequency and power level
requirements of the International Telecommunications Union and any
requirements of the National Administration with which the ship is
registered.
5.3.6 Compliance
with different port state and local regulations pertaining to the
use of radio-frequency transmission that would prohibit the operation
of a wireless data communication link, due to frequency and power
level restrictions, is not addressed by these requirements and is
the responsibility of the Owner.
5.4 Additional requirements for Mobility category and safety critical
systems
5.4.1 The
requirements of Vol 2, Pt 9, Ch 8, 5.4 Additional requirements for Mobility category and safety critical systems 5.4.2 are
to be complied with where control, alarm or safety functions for Mobility
category, or safety critical systems, incorporate programmable electronic
equipment.
-
Safety critical
systems are those which provide functions intended to protect persons
from physical hazards caused by engineering system failures, e.g.
fire, explosion, etc. or to prevent mechanical damage which may result
in the loss of a Mobility category system, e.g. main engine low lubricating
oil pressure shutdown.
-
Functions provided
by Ship Type or Ancillary category systems may also be considered
to be safety critical, e.g. domestic boiler low water level shutdown.
5.4.3 Items
of programmable electronic equipment used to implement control, alarm
or safety functions are to be Type Approved in accordance with LR's
Type Approval System, Test Specification Number 1 (2002).
Type approval to an alternative and relevant National or International
Standard may be submitted for consideration.
5.4.4 The
system is to be configured such that control, alarm and safety function
groups are independent. A failure of the system is not to result in
the loss of more than one of these function groups. Proposals for
alternative arrangements providing an equivalent level of safety will
be subject to special consideration.
5.4.5 For Mobility and/or Ship Type, the system is to be arranged to operate
automatically from an alternative power supply in the event of a failure of the normal
supply.
5.4.6 Volatile
memory is not to be used to store data required to:
- provide a Mobility category system or safety critical function;
or
- ensure safety or prevent damage, including during startup or re-start.
Alternative proposals that demonstrate an equivalent level of
system integrity will be achieved may be submitted for consideration.
5.4.8 Where it is intended that the programmable electronic system implements an
emergency stop functions or safety critical functions, the software is to comply with
the requirements of Vol 2, Pt 1, Ch 3, 21 Software in systems, machinery and equipment and Vol 2, Pt 9, Ch 8, 5.5 Additional requirements for integrated systems of these Rules. Alternative proposals providing an equivalent level of
system integrity will be subject to special consideration, e.g. redundancy with design
diversity, Alternatively, consideration may be given to the use of LR's Software
Conformity Assessment System–Assessment Module GEN1 (1994) or an
equivalent software assessment acceptable to LR.
5.4.9 Control,
alarm and safety related information is to be displayed in a clear,
unambiguous and timely manner, and, where applicable, is to be given
visual prominence over other information on the display.
5.4.10 Means
of access to safety critical functions are to be dedicated to the
intended function and readily distinguishable.
5.5 Additional requirements for integrated systems
5.5.1 The
requirements of Vol 2, Pt 9, Ch 8, 5.5 Additional requirements for integrated systems 5.5.2 apply
to integrated systems such as those providing a grouping of fire safety
or crew and embarked personnel emergency safety functions (see
Vol 2, Pt 9, Ch 7 Control, Alerts and Safety Systems
Vol 2, Pt 9, Ch 8 Programmable Electronic Systems, Vol 2, Pt 9, Ch 9 Fire Safety and Ship Safety Systems and Vol 2, Pt 9, Ch 10 Internal Communication),
power management systems and integrated control, alarm and monitoring
systems for machinery, and include the interconnection of systems
capable of independent operation to provide co-ordinated functions
or common user interfaces.
5.5.2 System
integration is to be managed by a single designated party, and is
to be carried out in accordance with a defined procedure identifying
the roles, responsibilities and requirements for all parties involved.
This procedure is to be submitted for consideration where the integration
involves control functions for Mobility category systems or safety
critical functions.
5.5.4 Reversionary
modes of operation are to be provided to ensure safe and graceful
degradation in the event of one or more failures. In general, the
integrated system is to be arranged such that the failure of one part
will not affect the functionality of other parts, except those that
require data from the failed part.
5.5.5 Where the integration involves control functions for Mobility systems, Ship
Type systems, or safety functions, including fire safety or crew and embarked personnel
or emergency safety functions, the Risk Assessment (RA) required by Vol 2, Pt 1, Ch 3, 3.3 Calculations and specifications 3.3.7 is to additionally to demonstrate that
the integrated system will 'fail-safe', see
Vol 2, Pt 9, Ch 7, 4.4 Safety systems, general requirements 4.4.3 and Vol 2, Pt 9, Ch 7, 4.5 Control systems, general requirements 4.5.4, and that Mobility and/or Ship Type systems in
operation will not be lost or degraded beyond acceptable performance criteria where
specified by these Rules.
5.5.6 The
quantity and quality of information presented to the Operator are
to be managed to assist situational awareness in all operating conditions.
Excessive or ambiguous information that may adversely affect the Operator’s
ability to reason or act correctly is to be avoided, but information
needed for corrective or emergency actions is not to be suppressed
or obscured in satisfying this requirement.
5.5.7 Where
information is required by the Rules or by the System Design Description
requirements to be continuously displayed, the system configuration
is to be such that the information may be viewed without manual intervention,
e.g. the selection of a particular screen page or mode of operation. See also
Vol 2, Pt 9, Ch 8, 5.1 General requirements 5.1.21.
5.5.8 Where
applicable, date and time stamping between separate equipment shall
be synchronised.
5.6 Programmable electronic systems – Additional requirements for the production of software
5.6.1 The requirements of Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems – Additional requirements for the production of software 5.6.1 to Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems – Additional requirements for the production of software 5.6.24 apply to
all software created for programmable electronic systems whose safety hazards have
been classified within categories II, III and IV as defined by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.5. Alternatively, consideration may be given to the use of LR's
Software Conformity Assessment System – Assessment Module GEN1 (1994).
See also
Vol 2, Pt 1, Ch 3, 21 Software in systems, machinery and equipment. A diagrammatic view of the software rules process is shown
in Figure 8.5.1 Software rules process
diagram – Machinery/Engineering system requirements and Figure 8.5.2 Software rules process
diagram – Software production requirements.
Figure 8.5.1 Software rules process
diagram – Machinery/Engineering system requirements
Figure 8.5.2 Software rules process
diagram – Software production requirements
5.6.3 An engineering and safety justification is to be made and documented.
This is to provide compelling, comprehensible and valid arguments that the intent
and requirements of the Rules have been complied with, supported by a body of
evidence that provides a compelling, comprehensible and valid demonstration that the
functional requirements identified in Pt 5, Ch 1, 8.1 Goal, functional requirements
and applicability 8.1.2 have been met. The engineering and safety justification is
to be produced in accordance with ISO/IEC 15026-2 Systems and software
engineering – Systems and software assurance, Part 2: Assurance case or an
alternative standard acceptable to LR.
5.6.5 Configuration management satisfying the requirements of ISO 10007
Quality management systems – Guidelines for configuration management, or
an alternative standard acceptable to LR, is to be used during the production of
software.
5.6.6 Software is to be produced using a quality management system that
satisfies the requirements of ISO 9001 Quality management systems – Requirements
using the guidance of ISO 90003: Software engineering – Guidelines for the
application of ISO 9001: to computer software or an alternative to LR.
Certification documents for the production of software are to be submitted to LR.
5.6.7 A plan for the production of software is to be formulated, documented and used to
direct the production of software. If the plan is incorporated into another
document, the strategy, and the structure of the plan, with appropriate
cross-references to other documentation, are to be documented separately. The level
of detail in the plan is expected to increase as the project progresses through the
lifecycle phases of the production of software. The plan is to be complete with
respect to each lifecycle phase before the phase is initiated.
5.6.8 The plan for the production of software is to include:
- all activities for the production of software, including
production of the justification and supporting evidence required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems – Additional requirements for the production of software 5.6.3;
- the processes, methods, techniques and tools required by the Software
Production Standard and applicable to the degree of reliance placed on the
software by the software safety requirements;
- factors which influence the introduction and mitigation of errors, such as
the size, complexity and novelty of the software;
- any deviations, with justification, from the requirements of the Software
Production Standard; and
- all activities for the creation of the documentation and
testing of the system appropriate to the system category as defined by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.5 and Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.7.
5.6.9 When there are changes to the software safety requirements which affect the plan for
the production of software, the plan is to be revised.
5.6.10 The production of software is to be performed in accordance with the Software
Production Standard and the plan for the production of software.
5.6.12 Where the software development includes the use of previously developed software, the
plan for the development of the software is to include:
- defined software modification processes which are to be part of the
supplier's quality management system;
- assessment of the impact of the modification on the previously developed
software modules, which is to be used to tailor the producer of software’s
management systems for the specific software development modification; and
- integration of any additional software safety requirements
identified by the risk assessment required by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.3, implemented through the configuration of the existing
software, by providing new software to work in cooperation with the existing
software, or by other means acceptable to LR.
5.6.13 During the production of software, the producer of software is to
actively maintain the system safety analysis required by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.2 to
ensure that emerging properties of the software are assessed. Changes in the system
safety analysis are to be documented, endorsed by the System Design Authority and
mitigated through derived software safety requirements.
5.6.15 Where it is not possible to implement the original software safety
requirements, or where updates are necessary as a result of additional system safety
hazards, the producer of software is to communicate this to the System Design
Authority and other affected stakeholders and the software safety requirements are
to be re-evaluated in accordance with Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.1.
5.6.18 Where software has been previously assessed and certified and the
justification for the suitability of the software relies on the previous
certification, 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.3 is to
demonstrate why the existing certification is applicable to the proposed
application. Evidence is to be submitted justifying the applicability of the
software for the specific application, which is to include but is not to be limited
to:
- the configuration(s) of the previously certified software;
- the operating scenario relevant to the previously certified software;
- the standard against which the previous certification was based;
- the applicability of any expected level of risk reduction that was
previously certified;
- the relevance of any conditions of use placed upon the certified software;
- copies of the previous certification for the software;
- a summary of modifications and updates to the software since the issue of
the previous certification; and
- analysis demonstrating that the degree of reliance that can be placed on the
software achieving its safety requirements is less than or equal to that
against which it was previously certified.
5.6.19 Where software has been previously used with development data available,
and the justification for suitability of the software relies on the development
data, 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.3 is to
include, but is not to be limited to, the following evidence:
- The evidence supporting the argument is to be for the same
software version as that of the proposed application.
- The producer of software is to provide access to the
development data so that LR can assess the level of compliance of existing
software with the rules.
- Where the production of software has included the use of
sub-contractor(s), the producer of software is to facilitate access to data
held by the sub-contractor(s).
- The argument is to identify any additional assurance activities
that are necessary to verify that the software safety requirements have been
satisfied.
5.6.20 Where software has been previously used with previous-use data
available, and the justification for suitability of the software relies on the
previous-use data, 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.3 is to
include, but is not to be limited to, the following evidence:
- The use of the software under the same conditions as the
proposed application including, but not limited to, running on the same
hardware and operating system (if applicable), and having the same
functional requirements.
- The producer of software is to provide access to the
development data so that LR can assess the level of compliance of existing
software with the rules.
- Where the software under assessment provides only part of an
engineering system’s software solution, the production of software is to
include validation of the software module as part of the total software
solution.
5.6.21 The System Design Authority is to create during the ship's design and construction
phase a registry of all programmable electronic systems, logical (virtual) servers,
desktops and network communication devices installed on board the ship, identifying
the hardware and software installed within.
5.6.22 The System Design Authority is to maintain the registry required by
Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems – Additional requirements for the production of software 5.6.21 and make it
available to the Surveyors on request. The registry is to record all changes made to
the ship's equipment during the ship's operational life, detailing as appropriate:
- system;
- vendor;
- system version;
- configuration version;
- date tested;
- test record reference;
- plan for production of software document reference;
- static network address; and
- records of reasons for the changes including details of any
alterations to software functionality.
5.6.23 Where remote access features or facilities for enabling temporary connections with
external devices are included for the programmable electronic system, the System
Design Authority is to periodically review the provisions made within the hardware
and software to ensure that new vulnerabilities and dependencies have not occurred
or have been adequately addressed to mitigate the risk related to their possible
exploitation.
5.6.24 The through-life management of the software is to be undertaken by the
System Design Authority in accordance with an acceptable process for the maintenance
of software. The process to be applied is to consider changes to the context of use
and/or amended software in the same manner as the originally developed software by
applying the plans and standards required by these Rules. Alternative processes
acceptable to LR may be applied to the software maintenance activities. The System
Design Authority may delegate the through-life management of software to the
software producer or other organisation when undertaking software modifications.
See also
Vol 2, Pt 9, Ch 1, 1.7 Alterations and additions 1.7.3.
|