Pt C, Ch 3, Sec 3
SECTION 3 COMPUTER BASED SYSTEMS
1 General requirements
1.1 General
1.1.1 The characteristics of the system are to be compatible
with the intended applications, under normal and abnormal
process conditions. The response time for alarm function is
to be less than 5 seconds.
1.1.2 When systems under control are required to be dupli-
cated and in separate compartments, this is also to apply to
control elements within computer based systems.
1.1.3 As a rule, computer based systems intended for
essential services are to be type approved.
1.1.4 Programmable electronic systems are to fulfil the
requirements of the system under control for all normally
anticipated operating conditions, taking into account dan-
ger to persons, environmental impact, damage to ship as
well as equipment, usability of programmable electronic
systems and operability of non computer devices and sys-
tems, etc.
1.1.5 When an alternative design or arrangements deviat-
ing from these requirements are proposed, an engineering
analysis is required to be carried out in accordance with a
relevant International or National Standard acceptable to
the Society. See also SOLAS Ch II-1/F, Reg. 55.
Note 1: As a failure of a category III system may lead to an accident
with catastrophic severity, the use of unconventional technology
for such applications is only to be permitted exceptionally in cases
where evidence is presented that demonstrates acceptable and reli-
able system performance to the satisfaction of the Society.
1.2 System type approval
1.2.1 The type approval is to cover the hardware and basic
software of the system. The type approval requirements are
detailed in Ch 3, Sec 6. A list of the documents to be sub-
mitted is provided in Ch 3, Sec 1.
1.3 System operation
1.3.1 The system is to be protected so that authorised per-
sonnel only can modify any setting which could alter the
system.
1.3.2 Modification of the configuration, set points or
parameters is to be possible without complex operations
such as compilation or coded data insertion.
1.3.3 Program and data storage of the system is to be
designed so as not to be altered by environmental condi-
tions, as defined in Ch 2, Sec 2, [1], or loss of the power
supply.
112 Bureau Veritas
1.4 System reliability
1.4.1 System reliability is to be documented as required in
Ch 3, Sec 1, [2.3.4].
1.4.2 When used for alarm, safety or control functions, the
hardware system design is to be on the fail safe principle.
1.5 System failure
1.5.1 In the event of failure of part of the system, the
remaining system is to be brought to a downgraded opera-
ble condition.
1.5.2 A self-monitoring device is to be implemented so as
to check the proper function of hardware and software in
the system. This is to include a self-check facility of input
/output cards, as far as possible.
1.5.3 The failure and restarting of computer based systems
should not cause processes to enter undefined or critical
states.
1.6 System redundancy
1.6.1 If it is demonstrated that the failure of the system,
which includes the computer based system, leads to a dis-
ruption of the essential services, a secondary independent
means, of appropriate diversity, is to be available to restore
the adequate functionality of the service.
1.7 System categories
1.7.1 Programmable electronic systems are to be assigned
into three system categories as shown in Tab 1 according to
the possible extent of the damage caused by a single failure
within the programmable electronic systems.
Consideration is to be given to the extent of the damage
directly caused by a failure, but not to any consequential
damage.
Identical redundancy is not to be taken into account for the
assignment of a system category.
1.7.2 The assignment of a programmable electronic system
to the appropriate system category is to be made according
to the greatest likely extent of direct damage. For examples,
see Tab 2.
Note 1: Where independent effective backup or other means of
averting danger is provided, the system category III may be
decreased by one category.
July 2011 with January 2012 amendments
 Pt C, Ch 3, Sec 3

Table 1 : System categories

Category Effect System functionality

I Those systems, failure of which will not lead to danger- • Monitoring function for informational/administrative
ous situations for human safety, safety of the ship and/or tasks
threat to the environment
II Those systems, failure of which could eventually lead to • Alarm and monitoring functions
dangerous situations for human safety, safety of the ship • Control functions which are necessary to maintain the
and/or threat to the environment ship in its normal operational and habitable conditions
III Those systems, failure of which could immediately lead • Control functions for maintaining the ship propulsion
to dangerous situations for human safety, safety of the and steering
ship and/or threat to the environment • Safety functions

Table 2 : Examples of assignment 3 Software

to system categories
Category Effect
I Maintenance support systems
Information and diagnostic systems
II Alarm and monitoring equipment
Tank capacity measuring equipment
Control systems for auxiliary machinery
Main propulsion remote control systems
Fire detection systems
Fire extinguishing systems
Bilge systems
Governors
III Machinery protection systems / equipment
Burner control systems
Electronic fuel injection for diesel engines
Control systems for propulsion and steering
Synchronising units for switchboards
Note 1: The examples listed are not exhaustive.
3.1 General
3.1.1 The basic software is to be developed in consistent
and independent modules.
A self-checking function is to be provided to identify failure
of software module.
When hardware (e.g. input /output devices, communication
links, memory, etc.) is arranged to limit the consequences of
failures, the corresponding software is also to be separated
in different software modules ensuring the same degree of
independence.
3.1.2 Computer based systems are to be configured with
type approved software according to Ch 3, Sec 6, [2.3].
3.1.3 Application software is to be tested in accordance
with Ch 3, Sec 6, [3.4].
3.1.4 Loading of software, when necessary, is to be per-
formed in the aided conversational mode.

3.1.5 Software versions are to be solely identified by num-

2 Hardware ber, date or other appropriate means. Modifications are not
to be made without also changing the version identifier. A
2.1 General record of changes is to be maintained and made available
upon request of the Society.

2.1.1 The construction of systems is to comply with the

requirements of Ch 3, Sec 4.
2.2 Housing
2.2.1 The housing of the system is to be designed to face
the environmental conditions, as defined in Ch 2, Sec 2,
[1], in which it will be installed. The design will be such as
to protect the printed circuit board and associated compo-
nents from external aggression. When required, the cooling
system is to be monitored, and an alarm activated when the
normal temperature is exceeded.
2.2.2 The mechanical construction is to be designed to
withstand the vibration levels defined in Ch 2, Sec 2,
depending on the applicable environmental condition.
3.2 Software development quality
3.2.1 Software development is to be carried out according
to a quality plan defined by the builder and records are to
be kept. The standard ISO 9000-1, or equivalent interna-
tional standard, is to be taken as guidance for the quality
procedure. The quality plan is to include the test procedure
for software and the results of tests are to be documented.
4 Data transmission link
4.1 General
4.1.1 These requirements apply to system categories II and
III using shared data communication links to transfer data
between distributed programmable electronic equipment or
systems.

July 2011 with January 2012 amendments Bureau Veritas 113

Pt C, Ch 3, Sec 3
4.1.2 The performance of the network transmission
medium (transfer rate and time delay) is to be compatible
with the intended application.
4.1.3 When the master/slave configuration is installed, the
master terminal is to be indicated on the other terminals.
4.1.4 System self-checking capabilities are to be arranged
to initiate transition to the least hazardous state for the com-
plete installation in the event of data communication fail-
ure.
4.1.5 The characteristics of the data communication link
are to be such as to transmit that all necessary information
in adequate time and overloading is prevented.
4.2 Hardware support
4.2.1 Loss of a data communication link is not to affect the
ability to operate essential services by alternative means.
4.2.2 The data communication link is to be self-checking,
detecting failures on the link itself and data communication
failures on nodes connected to the link. Detected failures
are to initiate an alarm.
The data communication link is to be automatically started
when power is turned on, or restarted after loss of power.
4.2.3 Where a single component failure results in loss of
data communication, means are to be provided to automat-
ically restore data communication.
4.2.4 The choice of transmission cable is to be made
according to the environmental conditions. Particular atten-
tion is to be given to the level characteristics required for
electromagnetic interferences.
4.2.5 The installation of transmission cables is to comply
with the requirements stated in Ch 2, Sec 11. In addition,
the routing of transmission cables is to be chosen so as to be
in less exposed zones regarding mechanical, chemical or
EMI damage. As far as possible, the routing of each cable is
to be independent of any other cable. These cables are not
normally allowed to be routed in bunches with other cables
on the cable tray.
4.2.6 The coupling devices are to be designed, as far as
practicable, so that in the event of a single fault, they do not
alter the network function. When a failure occurs, an alarm
is to be activated.
Addition of coupling devices is not to alter the network
function.
Hardware connecting devices are to be chosen, when pos-
sible, in accordance with international standards.
When a computer based system is used with a non-essential
system and connected to a network used for essential sys-
tems, the coupling device is to be of an approved type.
114
4.3 Transmission software
4.3.1 The transmission software is to be so designed that
alarm or control data have priority over any other data, and
overloading is prevented. For control data, the transmission
time is not to jeopardise efficiency of the functions.
4.3.2 The transmission protocol is preferably to be chosen
among international standards.
4.3.3 A means of transmission control is to be provided
and designed so as to verify the completion of the data
transmitted (CRC or equivalent acceptable method). When
corrupted data is detected, the number of retries is to be
limited so as to keep an acceptable global response time.
The duration of the message is to be such that it does not
block the transmission of other stations.
4.4 Transmission operation
4.4.1 When a hardware or software transmission failure
occurs, an alarm is to be activated. A means is to be pro-
vided to verify the activity of transmission and its proper
function (positive information).
4.5 Redundant network
4.5.1 Where two or more essential functions are using the
same network, redundant networks are required according
to the conditions mentioned in [1.6.1].
4.5.2 Switching of redundant networks from one to the
other is to be achieved without alteration of the perfor-
mance.
4.5.3 When not in operation, the redundant network is to
be permanently monitored, so that any failure of either net-
work may be readily detected. When a failure occurs in one
network, an alarm is to be activated.
4.5.4 In redundant networks, the two networks are to be
mutually independent. Failure of any common components
is not to result in any degradation in performance.
4.5.5 When redundant data communication links are
required, they are to be routed separately, as far as practica-
ble.
4.6 Additional requirements for wireless
data links
4.6.1 These requirements are in addition to the require-
ments of [4.1] to [4.4] and apply to system category II using
wireless data communication links to transfer data between
distributed programmable electronic equipment or systems.
For system category III, the use of wireless data communica-
tion links is to be in accordance with [1.1.5].
4.6.2 Functions that are required to operate continuously
to provide essential services dependant on wireless data
communication links are to have an alternative means of
control that can be brought in action within an acceptable
period of time.
Bureau Veritas July 2011 with January 2012 amendments

4.6.3 Wireless data communication is to employ recogn-
ised international wireless communication system protocols
that incorporate the following:
a) Message integrity: fault prevention, detection, diagnosis,
and correction so that the received message is not cor-
rupted or altered when compared to the transmitted
message
b) Configuration and device authentication: shall only per-
mit connection of devices that are included in the sys-
tem design
c) Message encryption: protection of the confidentiality
and or criticality the data content
d) Security management: protection of network assets, pre-
vention of unauthorised access to network assets.
4.6.4 The wireless system is to comply with the radio fre-
quency and power level requirements of International Tele-
communications Union and flag state requirements.
Note 1: Consideration should be given to system operation in the
event of port state and local regulations that pertain to the use of
radio-frequency transmission prohibiting the operation of a wire-
less data communication link due to frequency and power level
restrictions.
4.7 Protection against modifications
4.7.1 Programmable electronic systems of categories II and
III are to be protected against program modification by the
user.
4.7.2 For systems of category III, modifications of parame-
ters by the manufacturer are to be approved by the Society.
4.7.3 Any modifications made after performance of the
tests witnessed by the Society as per item No. 6. of Ch 3,
Sec 6, Tab 2 are to be documented and traceable.
5 Man-machine interface
5.1 General
5.1.1 The design of the operator interface is to follow ergo-
nomic principles. The standard IEC 60447 Man-machine
interface or equivalent recognised standard may be used.
5.2 System functional indication
5.2.1 A means is to be provided to verify the activity of the
system, or subsystem, and its proper function.
5.2.2 A visual and audible alarm is to be activated in the
event of malfunction of the system, or subsystem. This
alarm is to be such that identification of the failure is simpli-
fied.
5.3 Input devices
5.3.1 Input devices are to be positioned such that the oper-
ator has a clear view of the related display.
The operation of input devices, when installed, is to be log-
ical and correspond to the direction of action of the con-
trolled equipment.
July 2011 with January 2012 amendments
Pt C, Ch 3, Sec 3
The user is to be provided with positive confirmation of
action.
Control of essential functions is only to be available at one
control station at any time. Failing this, conflicting control
commands are to be prevented by means of interlocks
and/or warnings.
5.3.2 When keys are used for common/important controls,
and several functions are assigned to such keys, the active
function is to be recognisable.
If use of a key may have unwanted consequences, provision
is to be made to prevent an instruction from being executed
by a single action (e.g. simultaneous use of 2 keys, repeated
use of a key, etc.).
Means are to be provided to check validity of the manual
input data into the system (e.g. checking the number of
characters, range value, etc.).
5.3.3 If use of a push button may have unwanted conse-
quences, provision is to be made to prevent an instruction
from being executed by a single action (e.g. simultaneous
use of 2 push buttons, repeated use of push buttons, etc.).
Alternatively, this push button is to be protected against
accidental activation by a suitable cover, or use of a pull
button, if applicable.
5.4 Output devices
5.4.1 VDU’s (video display units) and other output devices
are to be suitably lighted and dimmable when installed in
the wheelhouse. The adjustment of brightness and colour of
VDU’s is to be limited to a minimum discernable level.
When VDU’s are used for alarm purposes, the alarm signal,
required by the Rules, is to be displayed whatever the other
information on the screen. The alarms are to be displayed
according to the sequence of occurrence.
When alarms are displayed on a colour VDU, it is to be
possible to distinguish alarm in the event of failure of a pri-
mary colour.
The position of the VDU is to be such as to be easily read-
able from the normal position of the personnel on watch.
The size of the screen and characters is to be chosen
accordingly.
When several control stations are provided in different
spaces, an indication of the station in control is to be dis-
played at each control station. Transfer of control is to be
effected smoothly and without interruption to the service.
5.5 Workstations
5.5.1 The number of workstations at control stations is to
be sufficient to ensure that all functions may be provided
with any one unit out of operation, taking into account any
functions which are required to be continuously available.
5.5.2 Multifunction workstations for control and display
are to be redundant and interchangeable.
5.5.3 The choice of colour, graphic symbols, etc. is to be
consistent in all systems on board.
Bureau Veritas 115
Pt C, Ch 3, Sec 3

5.6 Computer dialogue 6.1.4 Alarm messages for essential functions are to have
priority over any other information presented on the display.
5.6.1 The computer dialogue is to be as simple and self-
explanatory as possible.
7 Expert system
The screen content is to be logically structured and show
only what is relevant to the user.
7.1
Menus are to be organised so as to have rapid access to the
most frequently used functions. 7.1.1 The expert system software is not to be implemented
on a computer linked with essential functions.
5.6.2 A means to go back to a safe state is always to be
accessible. 7.1.2 Expert system software is not to be used for direct
5.6.3 A clear warning is to be displayed when using func- control or operation, and needs human validation by per-
tions such as alteration of control condition, or change of sonnel on watch.
data or programs in the memory of the system.
8 System testing
5.6.4 A ‘wait’ indication is to warn the operator when the
system is executing an operation.
8.1
6 Integrated systems 8.1.1 The system tests are to be carried out according to Ch
3, Sec 6.
6.1 General
8.1.2 All alterations of a system (hardware and software)
6.1.1 Operation with an integrated system is to be at least are to be tested and the results of tests documented.
as effective as it would be with individual, stand alone
equipment. 9 System maintenance
6.1.2 Failure of one part (individual module, equipment or
subsystem) of the integrated system is not to affect the func- 9.1 Maintenance
tionality of other parts, except for those functions directly
dependant on information from the defective part. 9.1.1 System maintenance is to be planned and docu-
mented.
6.1.3 A failure in connection between parts, cards connec-
tions or cable connections is not to affect the independent 9.1.2 Remote software maintenance may be considered on
functionality of each connected part. case by case basis.

116 Bureau Veritas July 2011 with January 2012 amendments