891 Guidelines for the on-board use an application of computers

Annex Guidelines for the on-board use an application of computers

Annex

1 Scope

1 - Scope

1.1 These Guidelines are applicable where computer-based systems are used to perform essential functions, such as:

1.  

• propulsion, steering and manoeuvring
  
  
• navigation and communication
  
  
• cargo loading, discharging and control
  
  
• safety of passengers and crew (e.g. fire safety systems and general alarm); and
  
  

• essential calculations, such as ship's stability and loading.
  
  

1.2 The Guidelines are not applicable to equipment or systems for which relevant specific Performance Standards of the Organization exist.

1.3 The Guidelines should also be applied to non-essential functions where loss of control could result in serious damage to the ship or its machinery, or serious injury to personnel, e.g. explosion of domestic water boilers.

2 Definitions

2 - Definitions

In addition to the definitions in the SOLAS Convention the following are necessary for these guidelines:

2.1 Computer
A programmable electronic device for storing and processing data, making calculations, or performing control.

Notes:

1. For the purposes of this document the term "computer" means a "digital computer".
   
   
2. A computer may consist of a stand-alone unit or may consist of several interconnected units and includes any programmable electronic system (PES), including main-frame, mini-computer or micro-computer.

2.2 Computer-based system
A system of one or more computers, associated software, peripherals and interfaces.

2.3 Integrated system
A combination of computer-based systems which are interconnected in order to allow centralised access to sensor information and/or command/control.

Notes:

Integrated systems may, for example, perform one or more of the following operations:

• passage execution (e.g. steering, speed control, traffic surveillance, voyage planning);
  
  
• communications (e.g. radiotelephone, radiotelex, GMDSS);
  
  
• machinery (e.g. power management, machinery monitoring, fuel oil/lubrication oil transfer);
  
  
• cargo (e.g. cargo monitoring, inert gas generation, loading/discharging);
  
  
• safety and security (e.g. fire detection, fire pump control, watertight doors).
  
  

2.4 Interface
A transfer point at which information is exchanged.

Note:

Examples of Interfaces include:

• Input/output interface (used for interconnection with sensors and actuators);
  
  
• Man/machine interface (e.g. visual display units, keyboards, tracker-balls, and dedicated controls and instruments used for communication between the operator and the computer);
  
  
• Communications interface (used to enable serial communications/networking with other computers or peripherals).
  
  

2.5 Node
A point of interconnection to a data communication link.

2.6 Peripheral
A device performing an auxiliary action in the system, e.g. printer, data storage device.

2.7 Software
Programs, data and documentation associated with the operation of a computer-based system.

3 General Requirements

3 - General Requirements

3.1 General

3.1.1 Computer-based systems should fulfill the functional requirements of the system under control for all operating conditions including emergency conditions, taking into account:

• Danger to persons
  
  
• Environmental impact
  
  
• Damage to equipment
  
  
• Usability
  
  
• Operability of non-computer devices and systems, etc.
  
  

3.1.2 If process times for functions of the system are shorter than the reaction times of the operator and therefore damage cannot be prevented by manual intervention, means of automatic intervention should be provided.

3.1.3 A computer-based system should have sufficient capability to:

• perform necessary autonomous operations,
  
  
• accept user commands,
  
  
• inform the user correctly,

under all operating conditions including emergency.

3.1.4 System capability should provide adequate response times for all functions, taking into consideration the maximum load and maximum number of simultaneous tasks, including network communication speed, under normal and abnormal process conditions.

3.1.5 Computer-based systems should be designed in such a way that they can be used without special previous knowledge, otherwise appropriate assistance should be provided for the user, as specified in section 6 - Training.

3.1.6 Computer-based systems should be protected against unintentional or unauthorized modification of programs and data.

 

3.2 Hardware

3.2.1 Hardware should be suitably designed to withstand supply voltage variations and transients, ambient temperature changes, vibration, humidity, electromagnetic interference and corrosion normally encountered in ships.

3.2.2 The design of the hardware should ensure ease of access to interchangeable parts for repairs and maintenance.

3.2.3 Each replaceable part should be simple to replace and should be constructed for easy and safe handling. All replaceable parts should be so arranged that it is not possible to connect them incorrectly or to use incorrect replacements. Where this is not practicable, the replaceable parts, including their means of electrical connection, should be clearly marked.

 

3.3 Software

3.3.1 Systematic procedures should be followed during all phases of the software life cycle (development, installation and subsequent modification).

3.3.2 System tests should be specified, performed and documented. These tests should include all software functions and important combinations of functions, performance, dependability and usability requirements under all modes of operation including emergency conditions and behaviour under failure conditions.

3.3.3 Modifications of program contents and data, as well as a change of version, should be documented.

Note: ISO 9000-3 gives guidelines for the application of ISO 9001 to the development, supply and maintenance of software.

4 System Configuration

4 - System Configuration

4.1 General

4.1.1 The hardware and software should be of a modular, hierarchical, design in order to maximise the fault tolerance of the system.

4.1.2 The selection of the computer equipment should be consistent with safe operation of the system under control.

4.2 Self-test

4.2.1 Computer-based systems should be monitored for correct operation and an alarm should be given for an abnormal condition.

4.3 Power supply

4.3.1 The power supply should be monitored for failure and should give an alarm in the event of an abnormal condition.

4.3.2 Program and data held in the system should be protected from corruption by loss of power.

4.3.3 Redundant systems should be selectively fed and separately protected against short circuits and overloads.

4.4 Installation

4.4.1 Equipment and its associated cabling should be installed in accordance with an appropriate code of practice to minimize electromagnetic interference between the equipment concerned and other equipment on board.

4.5 Cables

4.5.1 Cables used for data communication should be of adequate mechanical strength, suitably supported and also protected from mechanical damage.

4.6 Data communication

4.6.1 The data communication link should be continuously self-checking, for detecting failures on the link itself and data communication failure on nodes and should give an alarm in the event of an abnormal condition.

4.6.2 When the same data communication link is used for two or more essential functions, this link should be redundant. Redundant data communication links should be routed with as much separation as practical.

4.6.3 Switching between redundant links should not disturb data communication or continuous operation of functions.

4.6.4 To ensure that data can be exchanged between various systems, standardized interfaces should be used.

4.7 Failure to safety

4.7.1 In the event of a failure of a computer-based system, that system should automatically revert to the least hazardous condition.

4.7.2 The failure and restarting of computer-based systems should not cause processes to enter undefined or critical states.

4.7.3 Control, alarm and safety functions should be arranged such that a single failure will not affect more than one of these functions.

4.8 Integration of systems

4.8.1 Operation with an integrated system should be at least as effective as it would be with individual, stand-alone equipment. Where multifunction displays and controls are used they should be duplicated and interchangeable.

4.8.2 Failure of one part (individual module, equipment or subsystem) of the integrated system should not affect the functionality of other parts, except for those functions directly dependent upon information from the defective part.

4.8.3 A complete failure in connectivity between parts should not affect their independent functionality.

4.8.4 An alternative means of operation, independent of the integration, should be available for all essential functions.

4.8.5 When systems under control are required to be duplicated and in separate compartments this should also be applied to computer-based systems.

5 User interface

5 - User interface

5.1 General

5.1.1 Computer-based systems should be designed for ease of handling and user-friendliness and should follow ergonomic principles.

5.1.2 The operational status of a computer-based system should be easily recognizable.

5.1.3 A user guide should be provided. This user guide should describe for example:

• function keys
  
  
• menu displays
  
  
• computer-guided dialogue steps, etc.
  
  

5.1.4 An alarm should be displayed at relevant operator stations for failure or shutdown of a subsystem.

5.2 Input devices

5.2.1 Input devices should have clearly definable functions, be reliable in use and operate safely under all conditions. The acknowledgement of the instruction given should be recognizable.

5.2.2 Dedicated function keys should be provided for frequently recurring commands and for commands which must be available for rapid execution. If multiple functions are assigned to keys, it should be possible to recognize which of the assigned functions is active.

5.2.3 Control panels on the bridge should be provided with separate lighting. The level of lighting and the brightness of visual display units should be controllable.

5.2.4 Where equipment operations or functions may be changed via keyboards appropriate measures should be employed so as to limit access of such operations to authorized personnel only.

5.2.5 If the operation of a key is able to cause dangerous operating conditions, measures should be taken to prevent the instruction in question from being executed by a single action such as:

• use of a special key lock,
  
  
• use of two or more keys.
  
  

5.2.6 Conflicting control interventions should be prevented by means of interlocks or warnings. The active control status should be recognizable.

5.2.7 The operation of input devices should be logical and correspond to the direction of action of the controlled equipment.

5.3 Output devices

5.3.1 The si_{ze, colour and density of text and graphic information displayed on a visual display unit should be such that it may be easily read from the normal operator position under all operational lighting conditions. The brightness and contrast should be capable of being adjusted to the prevailing ambient conditions.}

_{5.3.2 Information should be displayed in a logical priority.}

_{5.3.3 If alarm messages are displayed on colour monitors, the distinctions in the alarm status should be ensured even in the event of failure of} a primary colour.

5.4 Graphical user interface

5.4.1 Information should be presented clearly and intelligibly according to its functional significance and association. Screen contents should be logically structured and their representation should be restricted to the data which is directly relevant for the user.

5.4.2 When using general purpose graphical user interfaces, only the functions necessary for the respective process should be available.

5.4.3 Alarms should be visually and audibly presented with priority over other information in every operating mode of the system; they should be clearly distinguishable from other information.

5.4.4 All display and control functions in control stations operated by the same operators should adopt a consistent user interface. Particular attention should be paid to:

• symbols;
  
  
• colours;
  
  
• controls;
  
  
• information priorities;
  
  
• layout.

6 Training

6 - Training

6.1 Training should be provided at a level required to effectively operate and maintain the system and should cover normal, abnormal and emergency conditions. The user interface for training should correspond with the real system.

6.2 Documentation should be provided to support the training and should be available for repeated use on board.

6.3 Where a training mode is incorporated in a computer-based system it should be clearly indicated when the training mode is active.

6.4 Whilst in the training mode the operation of the system should not be impaired, and neither should any system alarms or indications be inhibited.

7 Testing

7 - Testing

7.1 Evidence should be furnished to the satisfaction of the Administration that the installed computer-based systems have been designed, manufactured and tested in accordance with these Guidelines.¹ In the case of any integrated systems such evidence should be furnished by a single party responsible for the integration.

7.2 In addition to these Guidelines manufacturers should ensure by means of a quality control system that their products meet with their specifications.

7.3 Tests and inspections should be carried out with the aim of establishing the correct operation and the quality of a product (see also 3.3.2).

7.4 Modifications of program contents and data, as well as a change of version, should be tested (see also 3.3.3).

---

¹  Reference is also made to the following International Electrotechnical Commission (IEC) Publications:
92 - Electrical Installation in Ships.
533 - Electromagnetic compatibility of electrical and electronic installation in ships.
945 - Marine navigational equipment - General requirements - Methods of testing and required results.

Appendix Guidelines for shipboard loading and stability computer programs

Appendix - Guidelines for shipboard loading and stability computer programs

1 Scope

1 - Scope

These guidelines may be applied where computer-based systems are used to perform functions, such as:

• predicting draughts and trim and verifying that limiting stability parameters, such as "required GMT" are met;
  
  
• tank instrumentation systems used to provide direct electronic input of liquid loads (cargo, fuel, ballast, etc.) into the computer, bypassing the human measurement and data entry steps;
  
  
• operators of containerships may want to verify that over-the-bow bridge visibility requirements are met;
  
  
• operators of chemical parcel tankers may want to integrate chemical compatibility data to create voyage-specific/cargo-specific loading plans, thereby optimizing cargo flexibility;
  
  
• similarly, OBO operators may want a system which can accommodate multiple bulk cargoes of different densities and compute bending stresses with more precision;
  
  
• a program system could be used to monitor real-time hull bending stresses during loading/discharging operations, or due to sea conditions while under way via sensor systems that provide direct input to the computer; and
  
  
• a calculating damage stability conditions integrating loading data and flooded compartment characteristics.

2 General requirements

2 - General requirements

2.1Units: Basic stability calculations are performed using weights, typically Ltons or Mtons. However, some cargoes are more commonly measured in short tons, TEUs, or barrels. Other liquid loads (fuel and ballast) might be initially measured as soundings or ullages. The program developer may wish to make its program more convenient for the user to enter data in these alternate units. If so, the program should minimize chances for unit confusion and, wherever possible, weight conversions should be calculated by the computer. Screen displays and print-outs should then present both the entered value and the computational weight value side-by-side.

2.2Data and program protection: Although the program should be flexible enough to allow the user to override default data, certain data, such as lightship characteristics, allowable bending stress, required GM, as well as the program itself, should be protected against user revision. This could be achieved by furnishing the ship with compiled or read-only versions.

2.3Back-up of data: Copies of all constant data residing in computer files, such as ship geometry and tables, should be available on independent storage units, such as tape of floppy disks. The number of such copies should not be less than two.

3 User interface

3 - User interface

3.1"Home" screen: The program should have a simple command (keystroke/icon) that returns the user directly to a familiar "home" screen from any of the loading screens. This allows a "lost" user (who may have got disoriented among various loading screens) to quickly re-establish their orientation.

3.2 "Help" functions: The program should have easily-accessed "help" functions such as designated function keys, or an on-screen menu bar.

3.3Defaultloading: A default loading condition should reflect any special loading or operating requirements imposed by the ship's stability booklet (such as locked-in ballast requirements).

3.4Input and output data screening: The program should check data entered by the user for reasonableness in order to screen out possible input errors, for example, a cargo tank entry which exceeds the capacity of the tank. The program should not reject the entry as there may be special loading scenarios where unusual data must be entered, but it should clearly indicate to the user that the entry is out of expected bounds. Similarly, the program should alert the user if an output parameter such as "predicted GM" is out of expected bounds.

3.5Alerts: The system should alert the user if an output indicates a critical, or possibly dangerous situation. Alerts should, when possible, be augmented by audio signals. It is recommended that the graphical presentation and audio signals are different in case of critical events and user errors.

3.6Extra loading entry lines: In most cases, load entries will be of the fixed-location type where LCGs, VCGs, etc., are pre-displayed and the user only needs to enter a weight value. However, the program should include several extra blank lines to allow additional non-fixed load entries where the user can enter VCG, LCG, TCG, etc. Examples of non-fixed load entries might be an unusual deck cargo, temporary ballast or damaged stability calculations (where a flooded compartment could be entered as if it were a tank).

3.7Print-outs: Each loading condition print-out should automatically contain the name of the ship and the date of print-out; user should be prompted to enter a title for the condition as well. This information should be repeated on each page of the print-out.

4 Training and documentation

4 - Training and documentation

4.1User training: Training/tutorial material should be provided, as appropriate, for the sophistication of the program. This may range from formal classroom sessions to tutorial videotapes and/or self-study lesson plans.

4.2Documentation: The software should be accompanied by a user's manual and a programmer's manual.

4.2.1 The user's manual should be written for the direct user (ship's officers) and should include the following elements:

1. Identification: the manual should have a unique identification number that matches an on-screen ID number in the program. It should also clearly identify the stability booklet from which the lightship data is taken.
   
   
2. System requirements: identifies computer system hardware and software requirements such as compatible computers, operating system, memory requirements and other special requirements, such as video graphics, mouse, printer, etc.
   
   
3. File management: a list of all relevant software files, giving name, size, date and a brief description of each. The manual should also explain how any user-generated files, such as saved loading conditions, are named. These measures should allow the user to review the disk directory and verify that the correct current files are present.
   
   
4. Instructions: a clear explanation of how to install, use, and troubleshoot the program. The instructions should be user-friendly, recognizing that the user is a ship officer.
   
   
5. Information sources: a list of all ship-specific plans, drawings, tables, other documents, etc., which provided information used in the program. In most cases, this information will probably come from the ship's approved stability booklet; however, other sources should be clearly identified. Ideally, all such information sources should themselves be annotated to the effect that they were used in developing the program (so that future revisions to the drawing will also prompt a review of the program).
   
   

4.2.2The programmer's manual is not expected to be furnished to the ship; it is for use by select persons familiar with programming (but who may not necessarily the original program writers) when it becomes necessary to revise the program as a consequence of changes to the ship. The programmer's manual should carefully document the program's workings, and include a flowchart and an annotated program listing. This manual should explain how to edit the program, especially to revise ship-specific data (lightship data, hydrostatic characteristics, weight and moment data, tank capacities, etc.).

4.3Program and documentation control: A careful procedure should be established so that revisions to the program are properly tracked and forwarded to the ship. Each revision delivered to the ship should include change pages to the user's manual and instructions on how to delete obsolete files and install replacement (revised) files. The process should include an "action complete" report back to shoreside management.

5 Program functionality

5 - Program functionality

Program functionality: A manner for independently verifying the program's functioning should be provided. Ideally, the opening screen (when the program is first brought up) should present a self-diagnostic report on program functioning. Alternatively, a range of sample loading conditions can be furnished (on paper) which can be manually entered into the program for comparison with correct draughts, trim and available GM. The sample conditions may be the same as found in the ship's approved stability booklet, or separate samples included in the program's user manual.

• Informatietype: Internationaal
• Documentsoort: Circulaire niet in wetten.nl
• Toegangsrechten: Extern
• Identificatie: PUC_1786_14
• Versie: 2
• Datum beschikbaarheid: 15-10-2012
• Geldigheid van: 21-12-1998
• Wijzigingsdatum: 24-11-2016
• Titel: 891 Guidelines for the on-board use an application of computers
• Organisatie: International Maritime Organization (IMO)
• Taal: Nederlands
• Onderwerp: Veiligheid / Safety
• Hoofdtaak: Koopvaardij / Merchant Shipping
• Thema: Zeevaart / Seagoing ships / Information / IMO Instruments (Informative) / Circulars (Informative) / MSC Circulars (Informative) / 0800 until 0999