new conceptual standard for scc design (including hmi) · 2013. 9. 17. · hmi principles ......

ATOMOS II

Task 1.7

Conceptual Standard for SCC Design (including HMI)

Contract number WA - 95 - SC.205 ID - code: A217.00.11.052.001E

Date: 1998.12.03

ATOMOS II Task 1.7 Final Report of 70

CLASSIFICATION AND APPROVAL Classification: Confidential Confidential: The document is for use of the ATOMOS II Contractors within the ATOMOS II Consortium as regulated by EC Contract No. WA-95-SC.205, and shall not be used or disclosed to third parties without the unanimous agreement within the ATOMOS II PMC and subsequent EC approval/agreement. Authors: Name: Signature Date CMR - Ricardo González Partners Approval: LRS - Jonathan Earthy SCL – Erik Styhr Petersen TNO – Peter Passenier LMC – Henrik Jerslev Jensen Approved for release by: CMR - J.Carbajosa

ATOMOS II Task 1.7 ID A217.00.11.052.001E Date: 1998-12-03

ATOMOS II Task 1.7 Final Report of 70

DOCUMENT HISTORY Issue Date Initials Revised

Pages Short Description of Changes

001A 1998.09.25 RGB First issue. 001B 1998.10.25 RGB All Reviewer comments all Partners. 001C 1998.11.30 ESP All Correction of Format 001D 1998.12.03 ESP - Inclusion of review comments LMC, LRS,

TNO 001E 1998.12.03 ESP All Formatting DISCLAIMER Neither the ATOMOS II consortium nor any of its officers, employees of agents shall be responsible or liable in negligence of otherwise howsoever in respect of any inaccuracy or omission herein. Without derogating from the generality of the foregoing neither the ATOMOS II Consortium nor any of its officers, employees or agents shall be liable for any direct or indirect or consequential loss or damage, personal injury or death, caused by or arising from any information, advice or inaccuracy or omission herein.

ATOMOS II Task 1.7 ID A217.00.11.052.001E Date: 1998-12-03

Reference number of working document: ATOMOS II ID A217.00.11.053.001B Date: 1998-10-25

Reference number of document: ISO/Pre-WD

Committee identification: To be submitted to ISO/TC 8/SC 9/10

ISO/Pre-WD ©ATOMOS II CONTENTS

1. FOREWORD. ........................................................................................................................................7

2. INTRODUCTION ...................................................................................................................................8

3. SCOPE ..................................................................................................................................................9

4. CONFORMANCE................................................................................................................................10

5. NORMATIVE REFERENCE(S)...........................................................................................................11

6. TERM(S) AND DEFINITION(S)...........................................................................................................12

7. SYMBOLS (AND ABBREVIATED TERMS).......................................................................................16

8. CONCEPT AND GENERAL PRINCIPLES.........................................................................................17 8.1. THE SCC IN CONTEXT............................................................................................................................. 17

8.1.1. USERS .................................................................................................................................................. 17 8.1.2. TASKS................................................................................................................................................... 17 8.1.3. EQUIPMENT ......................................................................................................................................... 18 8.1.4. ENVIRONMENT .................................................................................................................................... 18

9. LIFECYCLE ISSUES FOR SCC & HMI..............................................................................................19 9.1. DEVELOPMENT OF COMPLEX COMPUTER-BASED SYSTEMS........................................................... 19 9.2. SAFETY LIFECYCLE................................................................................................................................. 19 9.3. HUMAN CENTRED LIFECYCLE. .............................................................................................................. 19

9.3.1. INTRODUCTION. .................................................................................................................................. 19 9.3.2. PLANNING THE HUMAN-CENTRED PROCESS ................................................................................. 21 9.3.3. UNDERSTAND AND SPECIFY THE CONTEXT OF USE .................................................................... 21 9.3.4. SPECIFY THE USER AND ORGANISATIONAL REQUIREMENTS ..................................................... 23 9.3.5. PRODUCE DESIGN SOLUTIONS ........................................................................................................ 24 9.3.6. EVALUATE DESIGNS AGAINST REQUIREMENTS ............................................................................ 25 9.3.7. CONTROL CENTRE IMPLEMENTATION............................................................................................. 26

10. GUIDELINES FOR MARITIME HUMAN CENTRED DESIGN. ......................................................27 10.1. INTRODUCTION........................................................................................................................................ 27

10.1.1. MANPOWER..................................................................................................................................... 27 10.1.2. PERSONNEL .................................................................................................................................... 28 10.1.3. TRAINING ......................................................................................................................................... 28 10.1.4. HUMAN FACTORS ENGINEERING ................................................................................................. 29 10.1.5. SAFETY ............................................................................................................................................ 30 10.1.6. HEALTH AND SAFETY..................................................................................................................... 30

11. ADVICE ON SCC LAYOUT. ...........................................................................................................31 11.1. INTRODUCTION........................................................................................................................................ 31 11.2. APPLICABLE STANDARDS AND GUIDELINES....................................................................................... 31

11.2.1. ENVIRONMENTAL STANDARDS APPLIED TO THE SPACE INSIDE THE SCC............................ 32 11.2.2. STANDARDS RELATING TO THE PHYSICAL SPACE INSIDE THE SCC...................................... 32

11.3. PHYSICAL SCC LAYOUT DESIGN PRINCIPLES..................................................................................... 32 11.3.1. OUTSIDE VIEW AND WINDOWS..................................................................................................... 32 11.3.2. ACCESSIBILITY................................................................................................................................ 33

12. ADVICE ON WORKSTATION DESIGN. ........................................................................................34 12.1. INTRODUCTION........................................................................................................................................ 34 12.2. APPLICABLE STANDARDS AND GUIDELINES....................................................................................... 34 12.3. WORKSTATION DESIGN PRINCIPLES ................................................................................................... 35

12.3.1. GENERAL PRINCIPLES................................................................................................................... 35 12.3.2. FUNCTIONAL PRINCIPLES ............................................................................................................. 35

13. ADVICE ON HMI DIALOGUE. ........................................................................................................37 13.1. INTRODUCTION........................................................................................................................................ 37 13.2. APPLICABLE STANDARDS AND GUIDELINES....................................................................................... 37 13.3. HMI PRINCIPLES ...................................................................................................................................... 37

14. ANNEX A - EXAMPLE OF SAFETY ASSESSMENT MODEL (INFORMATIVE). .........................40 14.1. GENERAL.................................................................................................................................................. 40 14.2. FUNCTIONAL MODEL .............................................................................................................................. 40

14.2.1. HAZARD IDENTIFICATION .............................................................................................................. 41 14.2.2. RISK ASSESSMENT ........................................................................................................................ 41

15. ANNEX B - ATOMOS II STYLE-GUIDE (INFORMATIVE).............................................................43 ATOMOS II Task 1.7 of 70

ISO/Pre-WD ©ATOMOS II 15.1. ABOUT THIS DOCUMENT........................................................................................................................ 43

15.1.1. PURPOSE AND SCOPE................................................................................................................... 43 15.2. INTRODUCTION AND SUMMARY............................................................................................................ 43 15.3. CONTEXT.................................................................................................................................................. 43

15.3.1. DEFINITION OF HMI SYSTEM......................................................................................................... 43 15.3.2. STATE-OF-THE-ART BRIDGE LAYOUT.......................................................................................... 43 15.3.3. COVERAGE OF THIS REPORT....................................................................................................... 43

15.4. HMI SYSTEM CONCEPT. ......................................................................................................................... 43 15.4.1. HARDWARE ARCHITECTURE. ....................................................................................................... 43 15.4.2. SOFTWARE ARCHITECTURE. ........................................................................................................ 44

15.5. HMI SCREEN AREAS. .............................................................................................................................. 45 15.5.1. PARTITION OF SCREEN AREA....................................................................................................... 45 15.5.2. STATUS AREA. ................................................................................................................................ 46 15.5.3. APPLICATION AREA........................................................................................................................ 47 15.5.4. COMMON CONTROL AREA. ........................................................................................................... 48

15.6. HMI STYLE GUIDE.................................................................................................................................... 49 15.6.1. ALLOWED COMPONENTS .............................................................................................................. 49 15.6.2. DESIGN OF COMPONENTS............................................................................................................ 50 15.6.3. MENUS ............................................................................................................................................. 50 15.6.4. DIALOGUE BOXES .......................................................................................................................... 51 15.6.5. TREE................................................................................................................................................. 52 15.6.6. LETTERING ...................................................................................................................................... 52 15.6.7. MENU BUTTONS.............................................................................................................................. 53 15.6.8. BUTTONS IN DIALOGUE BOXES.................................................................................................... 54 15.6.9. COLOURS......................................................................................................................................... 54

15.7. HMI OPERATING ...................................................................................................................................... 55 15.7.1. GENERAL REQUIREMENTS ........................................................................................................... 55 15.7.2. OPERATING DEVICES .................................................................................................................... 56 15.7.3. INPUT AND NAVIGATING MODELS................................................................................................ 56 15.7.4. OPERATION OF TREE..................................................................................................................... 57 15.7.5. HELP SYSTEM ................................................................................................................................. 58 15.7.6. INTRODUCTION............................................................................................................................... 58

16. ANNEX C - ASSOCIATED WORK PRODUCTS (INFORMATIVE) ...............................................59 16.1. LISTS OF ASSOCIATED WORK PRODUCTS FROM HUMAN-CENTRED LIFECYCLE PROCESSES .. 59

17. ANNEX D – EXAMPLE OF CONCEPTUAL BRIDGE LAYOUTS (INFORMATIVE). ....................64 17.1. INTRODUCTION........................................................................................................................................ 64 17.2. CONCEPTUAL LAYOUTS......................................................................................................................... 64

17.2.1. STATE-OF-THE-ART SCC ............................................................................................................... 64 17.2.2. FUTURE SCC ................................................................................................................................... 67

18. BIBLIOGRAPHY .............................................................................................................................68 18.1. STANDARDS............................................................................................................................................. 68 18.2. ATOMOS II REFERENCES ....................................................................................................................... 69 18.3. DISC REFERENCES ................................................................................................................................. 69 18.4. OTHER REFERENCES ............................................................................................................................. 69

ATOMOS II Task 1.7 of 70

ISO/Pre-WD ©ATOMOS II

1. Foreword ISO (the International Organisation for Standardisation) is a world-wide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organisations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electromechanical Commission (IEC) on all matters of electromechanical standardisation. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. This document is presented in the form and format of an ISO standard by the ATOMOS II Consortium as part of a final project report to the EC. ISO format is used because the ATOMOS II Consortium intend to submit the document as a supporting document to a new work item to TC8, either SC9 or SC10. However, this version is the property of the ATOMOS II Consortium and is copyright to ATOMOS II not ISO. ATOMOS® is a registered trademark of the ATOMOS II Consortium. The proposed standard covers new areas for TC 8. It is intended to be used before and in conjunction with existing and proposed TC 8 SC9 and SC10 standards. The proposed standard is a product standard based on standards and regulations from ISO TC 159 Ergonomics, CEN/TC 122 Ergonomics, IMO, IACS WP/HE and IEC SC65A Functional Safety. This interpretation is for marine use of Safety and Ergonomics standards. The annexes are informative.



2. Introduction This standard is developed with the purpose of enhancing the operational effectiveness and commercial efficiency of waterborne transport through improved design of the ship control centre. This goal can be achieved through decreasing the risk and increasing the user friendliness of the ship control centre and its equipment. User friendliness can be defined in a number of ways, all of which address some aspect of quality in use of a system or product. Attributes such as learnability, consistency and conformance with user expectations, or measures such as task effectiveness, efficiency and user satisfaction are commonly used in attempts to define user friendliness. Regardless of the definition there is agreement that the means of achieving user friendliness is increased human-centredness in design. The principles of human-centred design and the required activities necessary to develop user friendly products are known, and are now standardised in the forthcoming ISO FDIS 13407 ‘Human-centred design processes for interactive systems’. These principles and activities represent an essential component of best practice in the development of interactive systems, including ship control centres. This standard describes how to apply a human-centred approach in the development of ship control centres and associated human machine interfaces. A human-centred approach entails defining requirements, taking account of existing knowledge about users, and refinement and validation of the design with representative users. These activities provide a means of reducing the risk of incorrect specification and design of the control centre, ease the process of commissioning a control centre and also provide a way of monitoring how effective the centre is in operation. The reduction in development risk resulting from the human-centred approach reduces the development cost of the ship. Further, the increase in operational effectiveness increases its operational safety and reduces its through-life cost. Correct design of the SCC offers improved operational safety in terms of increased vigilance, flexibility of operation, precision of control and operator’s situational awareness. An SCC developed and operated according to the principles presented in this standard can reduce the incidence and/or effect of human error and increase the ability of seafarers to manage their ship in both normal and emergency conditions. The examples in this version of the standard are drawn from work on the EC project ATOMOS II (EC DG VII Contract WA-95-SC.205), and are copyright of the ATOMOS II Consortium. ATOMOS II proposes a human-centred, risk based approach to the layout of the ship control centre, the interface between the seafarer and the ship and the development of open-architecture automation technologies. The objectives are: - to develop a conceptual standard for a ship control centre working environment including the

corresponding human machine interface which enhances safety and efficiency through improved operator comfort, workload and awareness, screen presentation and other relevant factors.

- to enhance maritime operational safety and efficiency through an improvement of ship-borne command, control, alarm and information systems as much as practically possible, taking cost-benefit issues into account.

The design of the ATOMOS II ship control centre takes account of human capabilities and limitations. Information processing is used to enhance the capabilities of the user to achieve greater safety and efficiency. In ATOMOS II, a standard concept gives a safe, efficient and open ISC system which allows cost-effective interoperability and interconnection between system components from different suppliers. In order to facilitate interoperability ATOMOS II defines a harmonised user interface and provides a standardised process network. The proposed standard and assessment scheme take into account cost-benefit issues, classification requirements and relevant standards.



3. Scope This conceptual standard describes human and safety-centred activities during the specification, design and operation of a ship control centre and its human machine interface. The standard is a tool for ship control centre design and operation. The standard is to be used throughout the lifecycle of a ship control centre. NOTE: Although much of the technical detail in this standard addresses the use of networked computers to support activities on a ship’s bridge it is possible to apply the concept and general principles of the standard to all control centres on all ships, regardless of scale, type of ship or control technology. The users of this conceptual standard include the following groups: - Shipowners and others who purchase and operate ship control centres. - Yards and others who specify and/or supervise the design, construction and integration of ship control

centres. - P&I clubs, insurers, investors, financiers, banks who are involved in the financial risk of ship

operations. - National Authorities and Employees’ organisations who are concerned with crew well-being. - Classification Societies, test laboratories, type approvers and other test houses. - Maritime training organisations and others who are concerned with the education of future maritime

officers. - Designers, builders and installers of ship control centres, human machine interfaces, integrated ship

control systems and applications for ISC systems.



4. Conformance Claims of conformance to this standard shall demonstrate that a ship control centre, its development processes and associated work products fulfil the requirements of this standard. Claims of conformance shall also provide evidence that the recommendations in the standard have been considered and applied as appropriate to the context of the particular ship and lifecycle.



5. Normative reference(s) The following normative documents contain provisions which, through reference in this text, constitute provisions of this International Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards. - ISO 6385 Ergonomic principles in the design of work systems - ISO DIS 13407 Human-centred design processes for interactive systems - ATOMOS II A225.04.08.055.001 Programmable system development guidance1 - ISO 9241-11, 1998, Ergonomic requirements for office work with visual display terminal (VDTs) -

Guidance on Usability - ISO 8468, 1990, Ship’s bridge layout and associated equipment - Requirements and guide-lines

1 This document has been submitted to ISO TC8 SC10 as a NWI, May 1998.



6. Term(s) and definition(s) TERM DEFINITION SOURCE

Acceptable 1. Worth accepting, welcome 2. Satisfactory 3. Adequate Dictionary

Adequate 1. Sufficient 2. Competent. Dictionary

Configuration Functional an physical characteristics of a product as defined in technical documents and achieved in the product.

ISO10007

Configuration control Activities comprising the control of changes to a configuration item after formal establishment of its configuration documents.

ISO10007

Context of use The users, goals, tasks, equipment (hardware, software and materials), and the physical and social environments in which a product is used.

[ISO9241-11]

Control system A system which responds to input signals from the process and/or from an operator and generates output signals causing the equipment under control to operate in the desired manner.

[IEC1508-4]

Define 1. to decide 2. to fix the bounds or limits of 3. to determine with precision 4 to describe accurately 5. to fix the meaning of.

Dictionary

Dependability The collective term used to describe the availability performance and its influencing factors: reliability performance, maintainability performance and maintenance support performance.

Note: Dependability is used only for general descriptions in non-quantitative terms.

IEC50(191)

BS4778-3.2: 1991

Document A structured amount of information for human perception, that can be interchanged as a unit between users and/or systems

ISO8613-1

Effectiveness

(performance)

The ability of an item to meet a service demand of given quantitative characteristics.

IEC50(191)

BS4778-3.2:1991

Effectiveness The accuracy and completeness with which users achieve specified goals.

[ISO9241-11]

Efficiency The resources expended in relation to the accuracy and completeness with which users achieve goals

[ISO9241-11]

Equipment under control

Equipment/machinery/apparatus/plant used for marine activities for which designated safety-related systems could be used to prevent hazardous events associated with the equipment under control from taking place or mitigate the effects of the hazardous event.

[IEC1508-4]

Error A discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition

IEC50(191)

BS4778-3.2:1991

Error An error is that part of the system state which is liable to lead to failure. A failure occurs because the system is erroneous.

[IEC1508-4]

Failure The termination of the ability of an item to perform a required IEC 50(191)


ISO/Pre-WD ©ATOMOS II TERM DEFINITION SOURCE

function. BS4778-3.2

Failure An event which occurs when the delivered service deviates from the intended service. It is the effect of an error on the intended service.

[IEC1508-4]

Failure mode The effect by which a failure is observed BS4778-3.1: 1991

Fault The state of an item characterised by inability to perform a required function, excluding the inability during preventive maintenance or other planned actions, or due to lack of external resources.

IEC50(191)

BS4778-3.1: 1991

Foresee To be aware of or realise (a thing) beforehand Dictionary

Function Elementary operation performed by the system which, combined with other elementary operations (system functions), enables the system to perform a task.

[BS61069-1]

Functional safety The ability of a safety related system to carry out the actions necessary to achieve a safe state for the equipment under control or to maintain a safe state for the equipment under control

[IEC1508-4]

Functionality 1: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.

2: The capability of the software to provide functions which meet stated and implied needs when software is used under specified conditions.

[ISO9126-1]

[ISO9126-1]

Functionality A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.

[ISO9126-1]

Hazard A situation that could occur during the lifetime of a product, system or plant that has the potential for human injury, damage to property, damage to the environment, or economic loss.

BS4778-3.1: 1991

Hazard A physical situation with a potential for human injury [IEC1508-4]

Implied needs In a contractual environment, needs are specified, whereas in other environments, implied needs should be identified and defined.

ISO 8402: 1994

Interactive system Combination of hardware and software components that receive input from and communicate output to a human user in order to support his or her performance of a task

[ISO13407]

Level of Performance

The degree to which the needs are satisfied, represented by a specific set of values for the quality characteristics.

[ISO9126-1]

Mistake A human action that produces an unintended result IEC50(191)

BS4778-3.2 :1991

Mistake Human error or fault. A human action (in carrying out any system lifecycle activity) that may result in unintended system behaviour (failure)

[IEC1508-4]

Modification

(of an item)

The combination of all technical and administrative actions intended to change an item.

IEC50(191)

BS4778-3.2:1991



Operator 1. The person or persons given the task of installing, operating, adjusting, maintaining, cleaning, repairing or transporting machinery.

2. Organisation managing and using ships as part or all of their business.

[BS292-1]

Principle 1. A fundamental truth on which others are founded or from which they spring.

2. A law or doctrine from which others are derived.

Dictionary

Proprietary Legally made only by a person or body of persons having special rights.

Dictionary

Programmable Electronic System

A system based on one or more programmable electronic devices, connected to (an including) input devices (e.g. sensors) and/or output devices/final elements (e.g. actuators), for the purposes of control, protection or monitoring2

[IEC1508-4]

Prototype A model or preliminary implementation suitable for evaluation of system design, performance, and production potential; or for better understanding or determination of the requirements.

ISO/IEC 2382-20: 1990

Quality The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs

ISO8402

Redundancy In an item, the existence of more than one means for performing a required function.

IEC50

Reliability

(performance)

The ability of an item to perform a required function under given conditions for a given time interval.

IEC 50(191)

BS4778-3.2: 1991

Requirement 1: A condition or capability needed by a user to solve a problem or achieve an objective

2: A condition or capability that must be met or possessed by a system or a system component to satisfy a contract, standard, specification or other formally imposed documents

IEEE610.12

Risk The probable rate of occurrence of a hazard causing harm and the degree of severity of the harm.

IEC51

Safety Freedom from unacceptable risk of harm IEC51

Safety Freedom from unacceptable risk of personal harm BS4778-3.1: 1991

Safety lifecycle The necessary activities involved in the implementation of safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when none of the safety-related systems are any longer available for use.

[IEC1508-4]

Safety-related system

A system that implements the required safety functions necessary to achieve a safe state for the equipment under control or to maintain a safe state for the equipment under control and is intended to achieve, on its own or with other safety-related systems, the necessary level of safety integrity for the implementation of the required safety

[IEC1508-4]

2 The term PES includes all elements in the system, including power supplies, extending from sensors or other input devices, via data highways or other communicating paths, to the actuators, or other output devices.



functions3

Satisfaction Freedom from discomfort, and positive attitudes to the use of the product

[ISO9241-11]

Simulation The use of a data processing system to represent selected behavioural characteristics of a physical or abstract system.

ISO/IEC 2382-20: 1990

Software All or part of the programs, procedures, rules, and associated documentation of an information processing system

ISO2382-1 : 1993

Specify 1. to mention particularly 3. to make specific 4. to set down as requisite.

Dictionary

Specification The document that prescribes the requirements with which the product or service has to conform.

ISO8402

Stakeholder A person, group of people or an organisation that has an interest or stake in any system product. NOTE - For an SCC the stakeholders include the crew manning the SCC, the crew affected by routine or emergency operation controlled by the SCC, the owner/operator of the ship, the insurers of the ship, national authorities, the maintainers of the equipment installed in the SCC, the crew in other ships, etc.

ISO15288

System 1:A system is defined to consist of a set of components which interact according to a design. A component of a system can be another system (called a subsystem). Such components (subsystems) may be, depending on the level, a controlling or controlled system; and hardware, software, human interaction.

[IEC1508-4]

System 2: A collection of components organised to accomplish a specific function or set of functions.

IEEE610.12

Systematic Methodical, according to plan and not casually or at random Dictionary

System lifecycle The activities occurring during a period of time that starts when a system is conceived and ends when the system is no longer available for use.

[IEC1508-4]

Task The smallest indivisible part of an activity when it is broken down to a level best understood an performed by a specific user.

BS4778-3.1: 1991

Timely 1. In good time, early. 2. Well timed. Dictionary

Usability The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

[ISO9241-11]

User documentation Documentation describing the way in which a system or component is to be used to obtain desired results.

IEEE610.12

Valid 1. Sound. 2. Legally or logically good, adequate, or efficacious.

Dictionary

Validation Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled.

IEC8402:1994

Verification Confirmation by examination and provision of objective evidence that the specified requirements have been fulfilled.

IEC8402:1994

3 The IEC1508 notes further explain the term e.g. the overlap with control systems, and they state ‘A person could be part of a safety-related system’.



7. Symbols (and abbreviated terms) ATOMOS II Advanced Technology to Optimise Maritime Operational Safety

Integration and Interface COTS Commercial Off The Shelf. See Proprietary. ECDIS Electronic Chart Display HMI Human Machine Interface HW Hardware ISC Integrated Ship Control PC Personal Computer SCC Ship Control Centre SW Software TCP Transaction Communication Protocol ARPA Automatic Radar Plotting Aid PES Programmable Electronic System ISM International Safety Management [Code] STCW International Convention on Standards of Training, Certification and

Watchkeeping for Seafarers, 1995 ISO International Organisation for Standardisation IMO International Maritime Organization IACS International Association of Classification Societies IEC International Electrotechnical Commission GMDSS Global Maritime Distress and Safety System DIN Deutche Industrie Norm BS British Standard GUI Graphical User Interface AIPA ATOMOS Information Presentation Agent FSA Formal Safety Assessment ALARP As Low As Reasonable Practical FMEA Failure Mode and Effect Analysis FTA Fault Tree Analysis ETA Effect Tree Analysis ECDIS Electronic Chart Display and Information System CRT Cathode Ray Tube LCD Liquid Crystal Display NWI New Work Item



8. Concept and General Principles Ships designed with a risk-based and human-centred approach will demonstrate an improvement in efficiency and safety of maritime operations. The first principle of the concept is that operational efficiency and effectiveness may be enhanced by the application of a human-centred design process. The underlying assumption is that the correct definition of the required and desirable working environment will enable optimum operational safety. The second principle of the concept is that risk may by controlled through a structured, verifiable product life-cycle. The underlying assumption is that this will enable all stakeholders objective decisions on acceptable and desirable levels of functional safety. NOTE: The application of the concept is expected to provide user requirements to, and subsequently benefits from a number of design solutions, in terms of: - operational safety, through improved operator comfort, improved operator awareness and reduced operator

workload; - functional safety, through a unified human-machine interface with dynamic management of applications, cross-

system information processing and presentation, context-sensitive support for decision-making and procedural issues (including ship- & owner-specific ISM procedures).

8.1. The SCC in context This Clause describes the general context of use for SCCs covered by this standard. The context of use for any particular SCC should be defined in detail. This definition should follow the recommendations and examples given in ISO9241-11 Guidance on Usability. 8.1.1. Users The users of the SCC described in this document are marine officers standing bridge watch on board ships, irrespectively of trade. In terms of user background, STCW-95 compliance is assumed. Apart from system familiarisation and training, no special user skills should be assumed. NOTE: The users that have access to the SCC may be of the following three types: Officers with knowledge of the system and experienced in its use. For these users any novelties introduced will be of help and will not introduce any difficulties. - Users who are faced with the system for the first time. - Users who use it every so often (pilots for example) 8.1.2. Tasks The SCC described in this document is suitable for all tasks normally undertaken by the officer-of-the-watch, including voyage planning, navigation, docking and harbour operations, loading and unloading, communications, monitoring of platform status (machinery, aux. systems, safety systems etc.) and other such activities. No limitations as relates to normal practice are considered. The SCC can support the officer-of-the-watch acting as a sole look-out, also during periods of darkness, but no assumptions are made in this direction, and nothing in the SCC constrains the strategy in this issue. Similarly, the SCC can support that the officer-of-the-watch acts alone also during emergencies, but again, no assumptions are made in this direction, and nothing in the SCC dictates this procedure. NOTE: In the ATOMOS II experimental instance of the SCC, there is physical support for a second operator, envisaged to act during emergency conditions.


ISO/Pre-WD ©ATOMOS II 8.1.3. Equipment Equipment in the SCC will be selected and designed to meet user requirements as well as any statutory requirement applicable to the ship type and operational profile. NOTE: Attention should be given to the fact that ‘user requirements’ in the above context relates to other groups of stakeholders than on-board users, and includes at least owners and operators. NOTE: Coherency in the design of the SCC and the supporting technical solutions are to be catered for in the best possible fashion. In consequence, the second principle of the concept - that risk may by controlled through a structured, verifiable product life-cycle - applies also to all equipment in the SCC, and the likely integration of such equipment. NOTE: In the ATOMOS II instance of the SCC, the governing principle is that ‘The Programmable Electronic System (PES) shall be demonstrably suitable for the user and the given task in a particular context of use. It shall deliver correct, timely, sufficient and unambiguous information to its users and other systems. The hardware and software of the PES shall respond correctly throughout its lifecycle’. In support of this principle the ATOMOS II ISC design solution includes an open, standardised architecture with separated, but interconnected real-time and non-real-time networks. It further features full data transparency and consistency, definition and use of companion standards and conformance classes in support of interconnectivity and interoperability, and a modular approach that will allow targeted upgrades in line with life-cycle requirements. 8.1.4. Environment The environment in the SCC will be specified and designed to meet user requirements as well as any statutory requirement applicable to the ship type and operational profile.



9. Lifecycle Issues for SCC & HMI.

9.1. Development of Complex Computer-based Systems The dependable development and operation of an SCC can be assured through a structured development process and early and continuous checking of the emerging design. At an early stage this means checking the suitability of the proposed development process. During the development this means examination of the work products associated with the definition, design and production of the components of the SCC. In operation this means monitoring how well the users and the SCC control the ship. The process recommendations, principles and criteria in ATOMOS II Programmable electronic system development guidance (ref. A225.04.08.055.001; http://www.atomos.org) shall be used as the basis for development and operation of the SCC. Figure 9.Error! Unknown switch argument. - Practical Steps in the Application of this Standard shows the steps in the application of this Standard in the development of an SCC.

9.2. Safety Lifecycle It may be possible with an uncontrolled development process to produce a safe system. However, the probability of this occurring is very small and one cannot depend upon that outcome. The SCC presents an environment in which there is potential for causing risk to the ship, its crew and the environment from the operation of the ship in both normal and emergency conditions. There is also a limited risk to its users. The recommended approach for identifying, assessing and managing these risks in the design and operation of the ship is to follow a safety lifecycle. The safety lifecycle described in IEC (FIDIS/CDV) 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems (seven parts) should be applied in the development of the SCC. An example of a safety lifecycle for a maritime project is described in ATOMOS 2310 Recommendations for Safety Evaluation (ref. 2310.00.08.061.003; http://www.atomos.org). An example of a ship safety assessment is given in section 14.

9.3. Human Centred Lifecycle. 9.3.1. Introduction. To achieve an efficient, healthy and safe interaction of users with the ship through the SCC and its HMI, Human Factors should be taken into account during the lifecycle of the ship. This is achieved through extension of the normal specification, development and operational processes with processes which concentrate on the inclusion of information about the users of the SCC. The following clauses detail the particular lifecycle processes required to make the SCC and its HMI human-centred. Consideration of human elements applies not only to the control of the ship but also to the installation, maintenance, cleaning and repair of the SCC and its equipment. The objective is to make the SCC consistent with crew capabilities, limitations and needs, throughout its life. Design details may influence each other. Any interactions between details of the design should be considered during the design process and re-considered if any aspect of the context of use changes. Design and monitoring should focus on the interaction between the SCC and the human carrying out each of the above activities. The core human-centred processes described in the following clauses are intended to be carried out in an iterative loop. This loop will be cycled several times during a typical development. The first process covers management and control. It should be carried out during the development and implementation of the SCC. It uses information generated by the overall project management and takes feedback from the other human-centred processes. The planning process ensures that information produced by human-centred processes is available at the right time and in the right format. The context of use, requirements specification, design development and evaluation processes are performed iteratively until a design which fulfils the user requirements is produced. In order to minimise cost this iteration should be carried out as early as possible in the development of the ship not after the SCC is built and into commissioning. Prototypes, existing systems, paper and cardboard mock-ups and simulators can be used in place of


ISO/Pre-WD ©ATOMOS II finished equipment. The control centre implementation process starts near the beginning of the development and continues throughout the life of the SCC. It is concerned with the introduction and operational monitoring of the performance of the SCC. Verification and validation examines all aspects of the development and operation of the SCC and is performed throughout the lifecycle.

Specify Context of Use

Produce Design

Plan Human CenteredDesign Process

Apply ATOMOS IIConceptual Standard for

SCC Design?No Do something else!

Begin

Yes

Identify Usersand Attributes

Identify Ship andMission

Identify Tasks

IdentifyEnvironment &

Constraints

Specify Requirements fromStakeholders

Specify Acceptance Criteria

Evaluate Design

Acceptance Criteria Fulfilled?

Yes

No

End

Design Physical SCC Design Layout ofConsoles Design HMI Dialogue

Verification andValidation

Figure 9.Error! Unknown switch argument. - Practical Steps in the Application of this Standard

NOTE - The context of use, requirements and design processes will overlap to some degree depending on how tight the cycle of iteration for the project. The tighter the cycle, the less the overlap.


ISO/Pre-WD ©ATOMOS II NOTE - More detailed descriptions of human-centred lifecycle processes can be found in ISO 13407 Human-centred design processes for interactive systems and its support Technical Report Human-centred lifecycle processes for interactive systems. Processes generate and use material such as prototypes, specifications, plans, reports etc. These work products are used or generated by other project processes in the development of the SCC. The work products typically generated and used by human-centred processes are listed in Annex C. NOTE - If the SCC is one of a series, or an evolutionary development of a previous design then many of the activities within each process may be based on the results of previous studies. 9.3.2. Planning the human-centred process This process specifies how human-centred activities fit into the development and operation of the SCC. As a result of successful implementation of this process: - the project plan will allow for iteration and incorporation of user feedback - resources will be allocated for effective communication between the design team participants - potential conflicts and trade-offs between human-centred and other issues will be reconciled This process comprises the following activities: - Define and analyse the roles of each group of user stakeholders likely to be affected by the SCC.

Assess the significance of the SCC to each stakeholder group.

NOTE - The preliminary risk assessment may be used to select and rank stakeholders depending on whether they can cause harm or are affected by operations controlled by the SCC. - Establish structures, mechanisms and procedures to ensure that relevant stakeholders are effectively

involved and consulted in each significant aspect of the design and implementation of the SCC. - Decide on the most effective way to elicit user input at each stage of the project, taking best

advantage of established good practice in team working and appropriate user involvement. - Decide which methods will be included and how they will link together in the development process.

Define how this will interface to the particular lifecycle methodology being used in the development of the SCC.

- Establish a multi-disciplinary culture in the project team. Maintain staff focus on human-centred development. Identify the specialist skills required and plan how to provide them.

NOTE - Clause 8 provides details of the relevant human factors expertise which may be required in the design of an SCC. NOTE - In addition ton the collection of relevant skills in the project team it is beneficial to extend the project team, or a management team, to include representatives from all partners in the development and operation of the SCC. For example representatives from the owner, the yard/integrator, equipment suppliers and users. This team should be formed early in the lifecycle and meet frequently. - Develop a plan specifying how the human-centred activities integrate into the overall system

development process.

NOTE - A human-centred design plan establishes that input from human-centred design processes has been used in the design. A human-centred design plan allows for iteration where necessary. A human-centred design plan includes long term monitoring of the use of the system. 9.3.3. Understand and specify the context of use This process identifies, clarifies and records the characteristics of the users and other stakeholders, their tasks and the organisational and physical environment in which the SCC will operate. As a result of successful implementation of this process the following will be defined: - the characteristics of the intended users - the tasks the users are to perform - the organisation and environment in which the SCC is used. This process comprises the following activities: - Describe the activities which users perform to achieve operational goals.


ISO/Pre-WD ©ATOMOS II NOTE - Task descriptions are not solely in terms of equipment functions or features. - Describe the relevant characteristics of the end-users of the SCC. This will include knowledge,

language, physical capabilities, level of experience etc. - Describe the relevant social and organisational milieu, operational structure and practices etc. - Describe the relevant characteristics of equipment to be used. NOTE - This aspect of the context of use may be only be available at the late stage of the development. At an early stage in a “green fields” project the need for and type of equipment will not be defined. - Describe the location, workplace equipment and ambient conditions.

NOTE - The conditions under which the ship will operate and the activity carried out determines the manner in which it is configured in relation to the whole ship in general, and to the meaning of the equipping and layout of the bridge in particular. Figure 2 gives an example of a task-orientated procedure for the elicitation of user tasks in the SCC.



SH IP description

A ctivity - carriage of crude o il- chem ical products- passengers- ocean surveys, etc.

O perations- load/unload- navigation/ m anoeuvring- anchor chain , etc.

Processes/A pplications

Procedures that m ake up eachoperation

L oading tanker

- take on tem perature,- pressure control,- volum e, etc.

Ship at anchor

- prepare chain ,- w indlass ready,- anchor dow n, etc.

R outine

E m ergency

S.C .C .

A T O M O S ship , concept

Figure 9.Error! Unknown switch argument. - Example of a Procedure for Eliciting the Tasks to be carreid out in the SCC

9.3.4. Specify the user and organisational requirements This process establishes the organisational and user requirements for the SCC. This process takes full account of the needs, competencies and working environment of each relevant stakeholder in the SCC. As a result of successful implementation of the process, the following will be defined: - required performance of the SCC against operational and efficiency objectives - relevant statutory or legislative requirements - co-operation and communication between users and other relevant parties - the users’ jobs (including the allocation of tasks, users’ comfort, safety, health and motivation) - task performance - work design, and organisation practices and structure - feasibility of operation and maintenance - objectives for the operation and/or use of the software and hardware components of the SCC. This process comprises the following activities: - Describe the objectives which the stakeholders want to achieve through use of the SCC.


ISO/Pre-WD ©ATOMOS II - Review the safety, health and well-being risks to the stakeholders of the SCC. Relate this to the

overall risk assessment for the ship. - Set and agree the required functions and performance of the SCC in terms of the total experience of

the user and/or user organisation with the SCC (e.g. goals for suitability, acceptability and efficiency of the end user). The total experience covers each aspect of the user’s relationship with the SCC from its commissioning to its de-commissioning.

- Create an explicit statement of the user and organisational requirements for the SCC. NOTE - Requirements may be ranked in order of importance. NOTE - Statutory requirements regarding safety, health and safety, working environment and workload are to be taken into account. NOTE: The degree of integration of the equipment within the SCC is one requirement to be addressed. - Generate and agree measurable criteria for the required quality in use of the SCC.

NOTE - The quality in use may be stated as required levels of safety and usability for the SCC or its component parts in the context of particular tasks based on performance requirements. 9.3.5. Produce design solutions This process creates potential design solutions by drawing on established state-of-the-art practice, the experience and knowledge of the participants and the results of the context of use analysis. As a result of successful implementation of the process: - the whole socio-technical system in which any technical components operate will be considered in the

design - user characteristics and needs will be taken into account in the purchasing of SCC components - user characteristics and needs will be taken into account in the design of the SCC - existing knowledge of best practice from socio-technical systems engineering, ergonomics,

psychology, cognitive science and other relevant disciplines will be integrated into the system - communication between stakeholders in the SCC will be improved because the design decisions will

be more explicit - the development team will be able to explore several design concepts before they settle on one - stakeholder feedback will be incorporated in the design early in the development process - it will be possible to evaluate several iterations of a design and alternative designs - the interface between the user and the software, hardware and organisational components of the SCC

will be designed - user training and support will be developed. NOTE - The development of design solutions may require contributions in all of the areas described in Clause 8. This process comprises the following activities: - Analyse the task model and the context of use to distribute functions between the human, machine

and organisational components of the SCC best suited to doing the work. - Develop a feasible model of the user’s new tasks from existing knowledge of best practice, the

requirements, context of use, allocation of function and design constraints for the SCC. - Generate and analyse a range of design options for each aspect of the SCC related to its use and its

effect on stakeholders. NOTE - This includes recommendations on the level of automation and degree of integration of equipment. - Analyse legislation and best practice for applicability to the SCC. Include the user and organisational

requirements, context of use, international standards, legislative requirements, existing patents, good practice, style guides and project standards etc. in the design.

NOTE - Clauses 9 to 11 of this standard contain principles for and examples of best practice in SCC design. - Produce a design for the user-related components of the SCC. Change design in the light of feedback

from evaluations.


ISO/Pre-WD ©ATOMOS II NOTE - The specification can include, but is not limited to, one or all of the following: description of user’s jobs, user’s tasks, working environment, design of hardware, software, user documentation, interface functionality etc. - Make the design solution more concrete using simulations, models, mock-ups etc. Develop simulation

or trial implementation of key aspects of the SCC for the purposes of testing with users or user representatives.

- Identify, specify and produce the training required to enable relevant stakeholders to perform tasks effectively using the new SCC. Cover or include any proposed changes in business processes, job design, user tasks and safety procedures.

- Identify, specify and produce the user support services for the SCC and its components. Take into account the operational philosophy and job design.

9.3.6. Evaluate designs against requirements This process collects feedback on the developing design. This feedback will be collected from end users and other representative sources. As a result of successful implementation of this process: - feedback will be provided to improve the design - there will be an assessment of whether user and organisational objectives have been achieved or not - long-term use of the SCC will be monitored In the case of evaluation to identify improvements to the system (formative evaluation), successful implementation of the process will reflect: - potential problems and scope for improvements in: the technology, supporting material, organisational

or physical environment and the training - which design option best fits the functional and user requirements - feedback and further requirements from the users. NOTE - Formative evaluation is generally carried out using fairly informal, open-ended, collaborative techniques (e.g. focus groups) early in the lifecycle in order to provide information for the requirements and design process. Summative evaluation is generally carried out as a validation activity using more formal, closed methods (e.g. assessment against product standards). In the case of evaluation to assess whether objectives have been met (summative evaluation), successful implementation of the process will demonstrate: - how well the system meets its organisational goals - that a particular design meets the human-centred requirements - conformity to international, national and/or statutory requirements. NOTE - Evaluation may be carried out in the short term (e.g. trials by potential users during design in order to compare features of prototypes) or in the long term (e.g. a post-installation study to validate the specification, monitoring of sickness records for health and safety problems or a survey to identify the requirements for the next version of a system). NOTE -The opportunities for end user involvement are investigated for each evaluation. If end users are not involved the risks are assessed. NOTE: Trials should be carried out to evaluate novel SCC designs. These trials should be performed with actual navigators in a way such that costs and benefits with respect to safety and efficiency are clearly verified. Such trials may be performed as described in the ATOMOS II, A216.03.11.055.003A Task 1.6.3 report: in which the improvements in efficiency and safety are verified by comparative simulator trials. The new integrated bridge design was in these simulations compared to a conventional bridge design representing a typical state-of-the-art bridge. This process comprises the following activities: - Describe and verify the conditions under which an SCC is tested or otherwise evaluated. Describe the

relationship, and especially discrepancies, between the context of measurement and the context of use.

- Benchmark competitor SCCs using relevant criteria. Test the usability of competing/alternative SCCs and/or concepts. Use prototypes to stimulate stakeholder input to system requirements. Test stability of requirements.


ISO/Pre-WD ©ATOMOS II - Collect user input on the quality in use of the developing SCC. Present the results to the design

team(s) in the most appropriate format. - Check SCC against organisational, user and usability requirements. - Check SCC for adherence to applicable good practice, style guides, standards, guidelines, and

legislation. - Test the final and/or operational SCC to ensure that it meets the requirements of the users, the tasks

and the environment, as defined in its specification. NOTE - This includes routine contact with a representative number of users using a defined procedure to elicit information about human-centred aspects of the system by means of questionnaires, reports, logs, interviews etc. This also includes feedback to stakeholders. NOTE - Evaluation of the system in use can also be used to assess whether the requirements and the resulting specification were correct. 9.3.7. Control Centre Implementation This process establishes the user-related aspects of the support and implementation of the SCC. As a result of successful implementation of this process: - the needs of the stakeholders of the SCC will be communicated to the project - the management of change, including the responsibilities of users and developers, will be specified - the support requirements of users, maintainers and other stakeholders will be addressed - there will be compliance to health and safety procedures - user reactions will be collected and the resulting changes to the SCC reported back to stakeholders. This process comprises the following activities: - Ensure and oversee the human-centred aspects of SCC implementation. NOTE - This includes re-organisation of job design and working practices, group/teamwork, training, new business processes, reporting responsibilities etc.. NOTE - The context of use may change (or evolve) during the life of the SCC. - Assess the human and organisational impact of the SCC. - Deliver training and workshops to users to meet identified training needs and facilitate the transition to

new designs of jobs and new teamworking arrangements. - Maintenance of contact with users and the client organisation throughout the definition, development

and introduction of the SCC. - Survey of SCC, users and training programmes to ensure that the software, hardware, operations,

environment and support meet the requirements of legislation.



10. Guidelines for Maritime Human Centred Design.

10.1. Introduction In this standard the term ‘Human Factors’ refers to a multidisciplinary field of science and its application. Human-centred design applies human factors knowledge in the light of experience. In applying human factors to the design and operation of the SCC it is important to take human capabilities, skills, limitations and needs into account when exploring the interaction between people, technology and the work environment. The SCC should be seen as a work system which has the goal of operating the ship safely and efficiently. This work system consists of the users, equipment, software, space, environment, roles, duties, operations and command structure and the interactions between them. The equipment, even the ISC, is only one aspect of the work system of the SCC and should not be considered in isolation. Good design starts with the user and takes into account how the user is expected to interact with the equipment and how the equipment fits into the system as a whole. Human factors knowledge may be divided into the following set of sub-areas: - Manpower - Personnel - Training - Human Engineering - Safety - Health & Safety Input should be taken from each of these sub areas at each stage in the lifecycle. Advice on how this should be done is given in the DERA Guide for Industry, Building Human Factors into Systems Design (1998). The following clauses describe the components of each of listed above. For any SCC the sub-areas and the considerations should be reviewed against the particular context of use and the requirements for the SCC (for example, manning level, operational philosophy, etc,). The specific considerations which are generated should be addressed at the earliest possible point in the lifecycle. 10.1.1. Manpower The number of personnel required and potentially available to operate, maintain, sustain and provide training for the SCC. The following factors influence the choice and number of qualified people required to operate an SCC: - Phasing. Planning the availability of people at introduction and throughout the life of the SCC. With

emphasis not only to operation, but management of change, training, maintenance and support personnel.

- Work structure. The SCC supports new ways of working in which the control of the ship is mediated by equipment and software. This may require a change in philosophy in respect to crewing since the conventional structure of a crew may no longer be applicable.

- Availability. The proportion of labour resources and their demography required for all of the specified task involved, including operation, maintenance and support.

- Workload. The amount of work expected to operate, maintain and support the SCC. Factors affecting this are the balance between manning and task sustainability.

NOTE: Modern merchant ships possess a working structure that is mainly based on the type of activity they carry out. Planning, work structure, availability and work load will determine how many crew members are to man an SCC. For example, the number of crew members on a passenger vessel differs significantly from a chemical carrier when considering their total number. However the number of technicians does not vary so greatly. That is - A passenger ship carrying out cruises in the Mediterranean sea may carry, for example, 2,000 passengers and

300 crew. The technical staff of the crew will probably be approximately 30 people and the rest will be catering staff, office staff, passenger service staff, etc.

- A medium tonnage chemical carrier will carry a total of 12 to 15 people.


ISO/Pre-WD ©ATOMOS II The reason for the difference is in the activity carried out. Technically speaking, personnel increases on passenger ships because of work and functions to do with attending to the passengers, not because of the complex ship system. For example, the chemical carrier would not have a communications officer whereas the passenger vessel would have two or three. The passenger vessel will have three people dedicated to maintenance whereas the chemical carrier would only have one person. 10.1.2. Personnel The cognitive and physical capabilities required to be able to train for, operate, maintain and sustain the SCC and provide optimum quality and quantity of the crews to man a modern ship fitted with an SCC. - Physical. Current and future profiles including fitness levels, physical size, gender and not-typical

specific requirements. These are defined in IMO STCW95. - Cognitive. Current and future profiles including trainability and mental aptitude. These are defined in

IMO STCW95. NOTE: As part of ISM requirements, shipowners should address crew preparedness and training for all expected on board situations. - Recruitment/retention. Engaging new personnel or maintaining current personnel. Modular design and

standardisation of applications is an advantage since it facilitates a quick familiarisation with the particularities and characteristics of the equipment and favours the exchange of officers among ships.

NOTE - Crew retention is a serious problem for the shipowner, because loss of crew requires constant training of new crew. Some shipowners have provided a solution consisting in wage increases and improvements of living conditions on board ship. Time spent at sea is rewarded by longer holidays. - Cultural/Social factors. Influential factors based on maritime and/or national culture. Expectations with

regard to career prospects, ambience and aesthetics. - Previous experience/training. Attributes that are inherent with the predicted resource pool, which will

provide closer match or disparity with requirement; such as educational requirement and achievement, current trade, career pattern, knowledge of parallel systems.

NOTE - Shipowners are asking for increased consistency of operations and equipment on their ships. This assists crew members when they have to change ships. - Human-human interaction. Structure of envisaged tasking roles between people, whether based on

team or individual work, likely role of the personality in interaction. 10.1.3. Training The instruction or the education, and on-the-job or part-task or full-mission training required to provide personnel with their essential job skills, knowledge, values and attitudes. These are defined in IMO STCW95. NOTE - Resolution 9 of the final Act of the 1995 Training Conference, states that international ruling is necessary to legislate on the physical condition of seafarers. Governments are invited to construct such legislation that reflects recommendations that arise from opinions and rulings of the International Labour Organisation and the World Health Organisation. - Legacy transfer. Main or sub systems that require switch between different styles of operation. This

could be due to multiple style sub-systems, or retrofit of differently styled sub-systems. “De-skilling” can occur when some basic functions are automated.

NOTE: On the other hand, familiarisation with a human-centred SCC can be faster than for conventional bridges since the controls and elements are designed to facilitate work and diminish fatigue, and may result in increased safety levels. - Type. Mix of training technologies (for example, synthetic environment, computer-based simulation,

use of individual versus group sessions, instructors with actual experience versus simulated



experience etc. and the effects of each on performance),. Definition of standards and fidelity of performance (For example, through IMO ISM 94).

NOTE: Orders and working procedures may change in character because instructions can be based on a more thorough analysis of a situation. - Availability. Timing and proportion of initial training and continuation for new and existing personnel.

Therefore requiring facilities for correct type and size. Minimisation of training “bottleneck”. NOTE: Resolution 4 of the 1995 Training Conference, states that the Governments should adopt all necessary measures to guarantee that before 1st February 1999, there will be a sufficient number of people available with training and certificates in GMDSS radioperators. With respect to training that is necessary for SCC ships personnel should be chosen in accordance with their knowledge and skills. crew members should attend training and refresher courses covering the following subjects before they join an SCC ship. - Education in the handling and function of the new equipment. - Training to provide agility in the procedures in order to avoid mininterpretation of the information. - Refresher training in order to forget antiquated concepts and defective use of conventional systems. 10.1.4. Human Factors Engineering The comprehensive integration of human characteristics into the definition, design development, and evaluation of the SCC to optimise Human Machine performance under specified conditions. Computer technology may be used to support flexibility in operating concept for ships of different type, role, operating environment and tonnage. Standardisation of equipment may be possible for ships of the same type. If modularity in design is used to achieve, for example improved economy, there should be provision for customisation. Computer support should leave a margin of action by the officer in cases where there is uncertainty. Alternative solutions and their predicted consequences should be presented. The officer should always have the option of giving the final order. - User System Interface: The point at which the user carries out the required tasks. The user may

include the operator, maintainer or supplier. Performance factors of the interface will be physical and cognitive i.e. physical matching of the interface to the user, comprehensibility of the interface, etc. A central operations workstation in the SCC may be configured with fewer screens for data presentation (by use of all the current guidance related to equipment). This is the equivalent of diminishing the number of operational controls and the need for very quick data identification and reduces the number of opportunities for human error.

- Task Allocation: Matching of tasks with individuals and groups with associated performance effect on stress, fatigue, workload and motivation. Task and information analysis of SCC operations should be used to design each application and the required data exchange with other applications. SCC applications software may be provided to support all ship operations. Examples are: Ship Administration, Cargo Management, Hull Stress Monitoring, Robust Fault detection, Navigation, Propulsion, Communications, Manoeuvres, Maintenance.

- Environment: All external effects based primarily on neighbour work stations and users. Where appropriate this should include accommodation and habitability as a separate issue. The size and type of ship may restrict the space available for the SCC. Since the SCC is manned continuously the effect of layout, decoration and design on crew well-being should be considered. The operability of the SCC in both routine and emergency operations should be considered. Operability factors include: having all instruments to hand, working space sufficient to allow for easy movement, ergonomically designed equipment, adequate/ appropriate surroundings. Design for increased interaction by communication or sharing of information may give operational advantages in both routine and emergencies operations. The system may be designed to accumulate experience of routine operations.

The crew member must be prepared to react to the SCC needs. He must specially get to know the work procedures so that his decision making processes are supported by the computer applications and equipment provided by the SCC.


ISO/Pre-WD ©ATOMOS II The complexity of the decisions to be made is further increased in emergency situation where it is required to analyse, evaluate and decide on what action to take in just a few seconds. The IMO is conscious of these difficulties and has drawn up certain ruling, such as, for example, “Guidelines for drawing up on board emergency plans in the case of hydrocarbon pollution (1992)” (MERSAR); and aids for operations, such as, for example, “Search and Rescue Manual for Merchant Ships (1993)” or the “IMO Search and Rescue Manual (1993) (IMOSAR)”. 10.1.5. Safety The risks occurring when the SCC is functioning in a normal or abnormal manner: The design and operation of the centre will influence, and be decisive at the moment proper decisions need to be taken. The human factors safety domain should be regarded as the area where, within each phase of the SCC human centred design process, the human element should be systematically considered as one of the possible source of hazard during the use of the system. The key issue is to identify and understand the factors that affect human performance in relation to the technical systems being operated and the environment in which work is taking place. NOTE: This task should start from the early stage of the SCC definition and should refine its results as the design progresses, giving the necessary retrofits at different levels: from changes in concept definition to requirement modifications/extensions. Human error analysis should also integrate with the traditional engineering approach during the phases of the overall safety lifecycle. The activities under this domain should, at least, consider the following key aspects: - Error sources. The use of the SCC in general, or of one of its subsystems, which is likely to lead to

error. For example, long, complex procedures for simple operations. - Use behaviour. Misuse and abuse of subsystems which have safety implications for the user. For

example, inadequate materials, skill and attitude of the system’s operator, ergonomic design, and the interpretation of information received, are all aspects that have a direct influence on checking human error.

- Surroundings. External environmental conditions which have safety implications for the SCC user or third parties involved in ship’s operations. e.g. piracy, extreme weather, dangerous cargo (chemical, biological, explosion and fire)

10.1.6. Health and Safety The identification, assessment and amelioration of short- or long-term hazards to health occurring as a result of normal operation of the SCC. - Noise/vibration. Continuous/impulse sound or vibration that causes damage to hearing or vibration

injuries in the short- or long-term.. The values and references that cover the conditions that spaces on board ship should meet, are to be found in the IMO Code for “Noise levels on board ship”.

- Toxicity. Poisonous materials or fumes generated by equipment, capable of causing injury or death in the short- or long-term. Also allergies

- Electrical. Equipment which may provide easy exposure to electrical shock. - Mechanical. Exposed equipment with moving parts that are capable of causing injury. - Musculoskeletal. Task that adversely affect either the muscles or skeleton separately or in

combination, e.g. lifting of heavy weights, repetitive movements, incorrect disposition of displays and/or commands, etc.

- Heat/cold. Sources that provide potential hazards from equipment generation. - Optical. Equipment that is most likely to provide ocular injury. - Electromagnetic radiation. Other electromagnetic sources e.g. magnetic fields, microwaves, etc. NOTE: Several of these considerations are studied under several MARPOL chapters, where information needed to correctly handle dangerous merchandise is given.



11. Advice on SCC Layout.

11.1. Introduction This clause describes an SCC configuration analysis founded on existing legislation. General principles are given for SCC layout. NOTE: The layout design may be approached from several points of view in order to offer a futuristic vision that could be applicable to all ship types. For this purpose, the design and validation of conceptual bridge layouts carried out in ATOMOS II, will serve as an example of how to apply these principles. It is evident that the increasing automation and concentration of functions in ship control centres requires a thorough study to achieve an optimal design. Application of new systems may lead to a poor design with respect to reachability, readability or even visibility of instruments. The same problems will arise when an additional workstation is introduced to implement the new system. In this case, accessibility and safety can be endangered. The resulting ship bridge is far from optimal with regard to the human-machine interface and other ergonomic issues. However, due to technological developments, the possibility to integrate separate systems will be increased, which is likely to have an impact on the layout of ship control centres. In general, a higher level of automation and integration may lead towards a more compact bridge design. A compact design is one of the most important aspects to guarantee central information presentation and the workability and safety of the complete system, especially with small crews. For an example design of the SCC layout according to these principles, see Annex D. This example design is the result of the ATOMOS II 1.2 task, which has been validated by nautical experts using Virtual Environment (VE) techniques. For an overview of this work, see the ATOMOS II deliverable A212.03.10.055.006. The design will in the following subclauses be referred to as “EXAMPLE”.

11.2. Applicable Standards and Guidelines

The following standards on physical and environmental ambience should be considered when designing the SCC workspace: NOTE: In Europe, the European Directive 90/270/EEC on display screen equipment addresses minimum requirements necessary to meet objectives for the usability of operator-computer interfaces. Although these issues seem rather vague, standards are under development by international organisations like the International Organisation for Standardisation (ISO). The general consensus is that these ISO standards will become the most likely candidates for future international standards. They are also adopted by the European Standardisation Organisation (CEN) as part of the creation of the Single Market. CEN standards will also replace national standards in the EC and EFTA member states (e.g. DIN, BS and NEN). Furthermore, ISO or its European equivalents are often referenced to by EC member states to implement the obligations placed on them by the European Directive 90/270/EEC on ergonomic requirements for display screen workstations. In doing so the member states transpose these obligations into appropriate national laws and regulations. So, the message is, that the best strategy is to focus on the ISO standards. - ISO 8468, 1990, Ships bridge layout and associated equipment - Requirements and guidelines, - ISO 6385:1981, Ergonomic principles in the design of work systems - ISO 8468:1990, Ship’s bridge layout and associated equipment – Requirements and guidelines - ISO 9241, Ergonomic requirements for office work with visual display terminals (VDTs) - BS EN 614-1:1995, Safety of machinery - Ergonomic design principles - ISO 8995:1989, Principles of visual ergonomics - The lighting of indoor working systems - ISO 2631-1, Evaluation of human exposure to whole body vibrations - ISO 5349:1986, Mechanical vibration: Guidelines for measurement and the assessment of human

exposures to hand transmitted vibration. - ISO 1996-1:1982, Acoustics: description and measurement of environmental noise. - ISO 7779:1988, Acoustics: Measurement of airborne noise emitted by computer and business

equipment.



11.2.1. Environmental standards applied to the space inside the SCC

ISO 8468, clause 7, specifically refers to the bridge working environment. It contains the following subclauses:

- 7.1: General, referring to required facilities for a good working environment - 7.2: Vibration - 7.3: Noise - 7.4: Alarms - 7.5: Lighting - 7.6: Heating and ventilation - 7.7: Surfaces - 7.8: Interior - 7.9: Safety of personel

ISO 11064 also provides guidelines which may be applied to the inside environment of the bridge:

- Part 6: Environmental requirements for control rooms

ISO 9241 contains the following part on environmental aspects of the workspace:

- Part 6: Guidance on the work environment

NOTE: Regarding environmental requirements, by means of the IEC 1987 ruling the different attributes are defined that later determine the characteristics that should be found, for example: sound and noise, accommodation, optimum climatic conditions, glare, adaptation, brightness, colour rendering, colour rendering index, etc. 11.2.2. Standards relating to the physical space inside the SCC Regarding the design of the physical workspace, ISO 8468 contains the following subclauses:

- 4.1: Field of vision - 4.2: Windows - 5.1: Location and interrelation of workstations - 5.4: Miscellaneous, covering topics on accessibility

ISO 11064 contains the following parts that are relevant to the physical workspace design:

- Part 1: Principles for design of control centres - Part 2: Principles of control suite arrangement - Part 3: Control room layout

11.3. Physical SCC Layout Design Principles 11.3.1. Outside view and windows

- An optimal outside view shall be provided from all workplaces on the ship bridge.

NOTE: Under certain conditions e.g. a docking procedure, the officer of the watch will operate from the bridge wing. At an open bridge wing, one can have a good view during docking by leaning over the railing. Of course, a closed bridge wing might be a good alternative when the need for information at the bridge wing will be provided by good instrument panels. This approach has been followed in the example design proposed for the future SCC (See Annex D). In this example, for an unobstructed and direct view between the ship and the quay during docking, the width of the SCC, including the bridge wings, is the same as the width of the ship itself. A defogging installation can be added to each window.


ISO/Pre-WD ©ATOMOS II - The shape of the bridge should be designed to accommodate optimally the outside view of a sitting or

standing officer of the watch.

EXAMPLE: The frontal annex of the bridge in which the navigation workstation is placed, provides an optimal forward and sideways view. The outer front walls of the SCC are oriented in line with the view of the officer of the watch (sitting or standing behind the navigation workstation) to minimise the obstruction of sight. The design disables crew members to obstruct the outside view of the officer of the watch by standing in front of him, no passage way in front of the navigation workstation is allowed. - The rim of the workstations shall be as low as possible to enlarge the view standing or sitting behind

the workstations (Punte et al., 1997).

EXAMPLE: In the future SCC, the use of flat panel displays results in a lower rim and of the workstation, and thus, in a better view. - The SCC should be surrounded by windows to offer a maximum field of view.

EXAMPLE: In the example design, the only obstruction is the toilet. From the position behind the navigation workstation, it is recommended to place the toilet in line of sight with the funnel to minimise obstruction of the outside view by both objects. Whenever possible, it is recommended to minimise the diameter of the funnel or to make a transparent design for the funnel housing. - The number and size of window posts should be as small as possible.

EXAMPLE: Large windows are already applied at state-of-the-art SCC. A window breadth of 2.5 till 3 metres is technically possible (Punte & Post, 1997b).The visibility from the navigation workstation to the stern of the ship can be provided by windows from floor to ceiling at the back of the SCC, see Figure 15.2. To permit an optimal view on deck, windows are extended from floor to ceiling also at both sides of the navigation workstation, the windows are divided by a horizontal bar in the middle. - To avoid reflections of light, windows should be inclined out from the vertical plane.

11.3.2. Accessibility

- There should be no obstructions between the entrance of the bridge and the navigation workstation.

EXAMPLE: Access to the SCC from a lower deck is provided by a staircase, positioned at the back of the bridge. In the state-of-the-art SCC, the shape of the planning workstation supports a broad passageway between this workstation and the front of the bridge. The passageway between the planning workstation and the back of the SCC (kitchenette, toilet and staircase) enables quick access of the bridge wings and a fast and unobstructed passage between both bridge wings. According to Oudenhuijzen et al. (1996), the width of passageways at the SCC should be at least 1200 mm. - The bridge design should enable controlled access to all workplaces, also under extreme motion

conditions

EXAMPLE: During heavy weather conditions, personnel has the possibility to cling to a railing which is fixed to the walls of the SCC and the front of the planning workstation.



12. Advice on Workstation Design.

12.1. Introduction Standards and guidelines covering general issues for workstation design such as reachability, visibility and readability of instruments. General principles are given for functional aspects of workstation design. NOTE: Given the current technological developments, the future ship bridge is foreseen to be an operational centre from which the main vessel functions are monitored and to some extent controlled by the human supervisor. In such a situation, the operator supervises multiple systems concurrently, occasionally adjusting set-points. Consequently, the required interaction with the systems should be carefully analysed, as a basis for allocating the different functions to the workstations. Again, as in the previous clause, the conceptual bridge layouts as designed within the ATOMOS II framework will serve as an example. In this example design process, ergonomic principles for integrated information presentation are incorporated, as an outcome of the work carried out in the 1.3 task. Validation of these concepts has been carried out on the basis of part-task simulator experiments with subjects from the nautical field (see the ATOMOS II deliverable A213.02.10.55.004 for an overview of this work).


Regarding the design of workstations on the bridge, ISO 8468 contains the following subclauses:

- 5.2: Location of instruments and equipment - 5.3: Configuration and dimensions of consoles - 6.1: Bridge equipment, General - 6.2: Instruments - 6.3: Illumination and individual lighting of instruments - 6.4: Outer shape of instruments

ISO 11064 provides general rules that should be applied to the design of workstations in the SCC. These are grouped in the following parts:

- Part 4: Workstation layout and dimensions. - Part 5: Displays and controls. - Part 7: Principles for the evaluation of control centres. - Part 8: Ergonomic requirements for specific applications.

The BS EN 614-1:1995 provides design principles which are recommended to be followed during the process of designing work equipment and comprises the following sections:

- Design considering anthropometry and biomechanics - Design considering mental ability - Design of displays, signals, and control actuators - Interactions with the physical work environment - Interactions in the work process - Ergonomics of task to be performed - Development of design specifications in accordance with ergonomics principles

ISO 9241 contains several parts that must be considered when designing the SCC workstations: NOTE: The Subcommission SC 4 of TC 159 - „Ergonomics of human-system interaction„ developed the ergonomic standards on visual displays ISO 9241. The standard is organised into a number of parts, each dealing with a different aspect of VDT use. The requirements described in these parts are originally intended for office work, and consequently, primarily focus on the presentation of characters and texts. Still, although the workstations on the bridge are likely to be based on a combination of graphical displays, many of the ISO 9241 recommendations are still worth considering. - Part 1: General introduction.


ISO/Pre-WD ©ATOMOS II - Part 2: Guidance on task requirements. - Part 3: Visual display requirements. - Part 4: Keyboard requirements. - Part 5: Workstation layout and postural requirements. - Part 7: Display requirements with reflections - Part 8: Requirements for displayed colours - Part 9: Requirements for non-keyboard input devices

ISO CD 13406 Part 2 Flat panel display ergonomic requirements NOTE: Because the ISO 9241 parts mentioned above are primarily based on CRT technology, ISO TC 159 SC 4 is preparing the standard ISO 13406-2 that deals with the special issues that arise from the use of flat panel displays. This is done in liaison and consultation with IEC TC 47 (responsible for flat panel engineering standards).The standard presents the requirements for VDUs based on flat panels (LCD). The legibility of the panel is of principal concern. The requirements are largely based on ISO 9241 Parts 3, 7 and 8, but modified and extended to consider the unique trade-offs of flat panels. Especially the issues of viewing distance, viewing direction and screen illumination depart somewhat from the precedents of ISO 9241-3. NOTE: The visual information to be shown on the display(s) of Electronic Navigational Charts (ENC) is quite extensive and diverse. This explains why the development of specifications and guidelines, already initiated in 1988 by the International Hydrographic Organization (IHO), is still in progress. The Colours & Symbols Working Group (C & SWG) is the committee that mainly is responsible for drafting these specifications in the IHO Presentation Library provided with the Colour & Symbols Specifications for ECDIS (IHO SP52, 1994).

12.3. Workstation Design Principles 12.3.1. General principles

The dimensions of workstations and the positions of instruments should be based on the following considerations (see also Punte & Post, 1997b):

- Workstations will be suited for standing as well as sitting; - Optimal maintainability; - Good survey ability of the workstation panels; - Arrangement of instruments based on reachability, visibility, readability and priority of components. EXAMPLE: The design of the workstations described in Annex D is based on an extrapolated anthropometric database considering northern European men and women between 18 and 40 years until the year 2015. To guarantee proper reachability, visibility and readability of all instruments and to guarantee an unobstructed outside view during standing as well as sitting, the chairs are heightened (300 mm with regard to normal sitting on floor level). The maximum height of the proposed workstations is 1416 mm. Taking into account the heightening of the reference level of 300 mm during sitting, the workstation does not exceed the 1200 mm rule as stated by Det Norske Veritas (1991). The height of the chairs must be adjustable for an ergonomic optimized sitting posture for all operators. Besides, the chairs must be equipped with an adjustable footrest. It should be taken into consideration that the use of the proposed workplaces will require changes to Class requirements, for instance Det Norske Veritas (1991). Figure 15.3 shows in detail the design of the navigation workstation for the state-of-the-art SCC. This workstation is suited for navigation, communication and monitoring of platform, cargo, passengers and crew. The "cockpit like" set-up has been designed as compact as possible to support central information presentation. The operator has the possibility to gain all information at a glance. 12.3.2. Functional principles In order to derive specific guidelines for the functional aspects of workstation design, a distinction can be made between three different characteristics of supervisory control tasks that are relevant for accurate task performance:

1. Monitoring: signal deviations and filter frequently occurring false alarms; 2. Compensation: minimize deviations between actual and desired state; 3. Anticipation: control the process on the basis of future process evolution.

At each task level, important functional aspects are whether the required information is available, whether the presentation of this information is compatible with user information needs, and whether the information is assessible in relation to other information elements which are required for task execution.



12.3.2.1. Monitoring

- The operator should - in addition to actual monitored status values - be provided with information about references, history and trends.

- Indicators should support the detection of changes. - It should be easy to compare actual and desired states. EXAMPLE: Part of the ATOMOS tactical display (see Figure 13.3 in Annex B) is reserved for the presentation of status information related to the own ship. For this purpose, analogue indicators are used, presenting information on the ship’s desired course, actual course and rate of turn in a combined graphical format. The same principle may be used for the control elements (rudder and RPM). - Alarms should be clearly distinguishable from normal conditions. - It should be considered whether alarms can be presented according to the conditions related to

various operations (e.g. it is useful to suppress the alarm in situations when it does not indicate an alarm situation, for example during maintenance procedures). The most important criterion, however, is the safety of the process.

12.3.2.2. Compensation

- It should be ensured that changing of views and actions (e.g. switching from monitoring to control) on several VDU’s and control panels does not lead to unnecessary effort.

EXAMPLE: For the state-of-the-art SCC, controls for rudder, thrust, and autopilot are added as hardware instruments at the middle part of the navigation workstation. Track-pilot information is integrated in the tactical display. The rudder is handled by a side stick (for both sitting/standing positions within direct hand reach). The thrusters and autopilot are handled by buttons. These instruments are positioned within the reach envelop of both positions. At the future SCC, the bridge engine controls are expected to be further integrated in the software and are controlled by the keyboard and display. However, the intuitive interface of the side stick to steer the ship will not be replaced by other means of control in the near future. Therefore, also at the future navigation console, both positions are equipped with a side stick under direct hand reach. Further, for the switching between different views, the common control area as described in Annex B provides direct access to different applications from each operator position. - Important control functions on a VDU should remain permanently visible on the same location. - Unequivocal protocols for the meaning (on/off, min/max) of the state of control panels should be used. EXAMPLE: Several of the aspects mentioned here are covered in a more broad sense in the ATOMOS II style guide (Annex B), a.o. dealing with important aspects like compatibility and consistency of the user-interface design. - The actual control mode (e.g. manual, automatic) of the various subsystems should be indicated. - The use of various strategies for alarm handling should be enabled. EXAMPLE: Experimental research in the ATOMOS 1.3 task has demonstrated the benefits of an information aid in alarm handling. According to this approach, the user is assisted in an interactive way to develop an efficient strategy in handling the different alarms from the different subsystems. Depending on the context of the actual problem at hand, the user is guided in the selection of available state information, taking the physical dependencies between the different subsystems into account.

12.3.2.3. Anticipation

- It should be ensured that the operator receives information concerning future references and disturbances in order to maintain a future perspective.

- When various information sources are interrelated (for instance, planning, monitoring and control), an integrated presentation format should be considered.

EXAMPLE: The ATOMOS tactical display is designed for supporting effective anticipation during voyage execution by integrating the planned track and fairway (from ECDIS), other traffic information (from ARPA) and essential conning information for control of the own ship. For the integration, predictive models are used to calculate the ‘Predicted Capability Envelope’, providing overview at a glance to judge the effect of different course settings of the own ship in relation to the other traffic (see Figure 15.Error! Unknown switch argument. - Layout of the Tactical Display for Navigation Support in Annex B).



13. Advice on HMI Dialogue.

13.1. Introduction. This clause provides advice on the design of the HMI dialogue, taking general human-factors principles into account. An overview on applicable standards and guidelines is given. General principles are given for HMI design. NOTE: For demonstration purposes, the general principles are illustrated by informative examples referring to the ATOMOS II style guide. This style guide is enclosed in this document as Annex B. Further, reference is made to the ATOMOS II guidelines for information management and human computer interaction. NOTE: The information visualised should be delivered in a timely fashion for each action, avoiding filling up the screen with unnecessary data, that will only cause problems for a novel user. Help messages should be classified by levels, facilitating a rapid learning process of the system in order to speed-up the necessary training phase.


ISO 9241 contains the following parts on high-level ergonomic principles which apply to HMI design:

- Part 10: Dialogue principles - Part 11: Guidance on usability - Part 12: Presentation of information - Part 13: User guidance - Part 14: Menu dialogues - Part 15: Command dialogues - Part 16: Direct manipulation dialogues - Part 17: Form filling dialogues BS EN 894-1:1997 Safety of machinery – Ergonomics requirements for the design of display and control actuators, Part 1, contains general principles for human interactions with displays and control actuators.

13.3. HMI Principles Basic human-factors principles underlying many of the guidelines on HMI design are: NOTE: In the 80's, the Graphical User Interface (GUI) became familiar to more and more users who did not have specific computer expertise. These interfaces were based on the ‘WIMP’-concept (Windows, Icons, Mouse and Pull-down/pop-up menus). In particular the direct manipulation, provided by WIMP-interfaces, was thought to improve the usability for non-expert users. In the 90's, GUI’s are becoming widespread and a standard “look-and-feel” has been developing for user interfaces of different platforms (Mac, Motif, PM, Windows). Usability guidelines and style guides have been developed for these interfaces. Many of these guidelines are of a more or less overlapping nature (see, for instance, Williges et al., 1987 for a classification scheme or Smith & Mosier, 1986 for an extensive review of guidelines for software interface design). - Compatibility - minimise the amount of information re-coding that will be necessary

EXAMPLE: Task compatible units: state information should be presented in units which have a direct meaning for the user (e.g. speed of a vessel always presented in a recognised unit such as knots). - Consistency - minimise the difference in dialogue both within and across various user interfaces

EXAMPLE: Standardised Dialogue Windows: General functions within a dialogue window should be accessible always in the same way for all windows. Identical classes of data or function (help, exit) should appear at the same screen location. If the user changes from one window to the next one, the appearance should be as equal as possible. Successive dialogue windows should be integrated by a reference (perceptual landmark). This measure ensures, that the principle of consistency is achieved. It is characterised by the „Visual momentum" which is a measure for the operators ability to extract information across the various displays. In the case of high visual momentum there is a continuity across successive views. When visual momentum is low, each transition to a new


ISO/Pre-WD ©ATOMOS II display becomes an act of total replacement. Consequences are the "getting lost" phenomena [Annex B] [ATOM 1.3.2] - Memory - minimise the amount of information that the user must maintain in short-term memory

EXAMPLE: Context Related Data Presentation: According to the ATOMOS style guide, data is always presented in context with specific attributes like identifier name, quality indicator, safety level information, and priority level. If applicable a comparison is given with previous values (history) or corresponding values in a second system (compare engine 1 & 2). This measure minimises the short-term information, which the user has to keep in mind. [ATOM 1.3.2] - Structure - assist the user in developing a conceptual representation of the structure of the system so

that they can navigate through the interface

EXAMPLE: Navigation Tree: The navigation tree shows a hierarchical diagram with the available applications and their sub-menus. It gives direct access to the sub-menu of an application. This feature ensures, that the operator has a quick overview about the complete ISC system and can access sub-menus directly without further search. [ Annex B ] EXAMPLE: Structured Screen Area: The screen area is divided into three independent parts, a status line at the top showing the most important navigational data, an application area in the centre, and a control line at the bottom with quick selection buttons for the most important applications and settings. This measure ensures that the user has an immediate overview of what is going on in the ISC. [Annex B] EXAMPLE: Grouped Dialogue Windows: All dialogue windows for a certain operation task should be grouped together. Further on all windows for a certain operation procedure should be grouped from top to bottom, from overview to detail. This measure ensures that the user develops a conceptual representation of the structure of the system. [ ATOM 1.3.2 ] - Feedback- provide the user with feedback and error-correction capabilities

EXAMPLE: Mapped windows: Mapped windows are used in order to show where a user came from, what he did and which choices are available. For this purpose all previously entered windows for a specific operation are overlaid. The headline of each window remains visible. [ Annex B] EXAMPLE: Context Sensitive Help: Context sensitive help should be available for every dialogue window (in every context) and provide specific help for the actual situation. The access to the help function should be equal for all windows and situations. The help information should not interfere the current users activity. The help window should explain possible actions and resulting consequences. The level of help should automatically adapt to the users abilities i.e. by logging the last user activities and assessing them in the light of deviations from normal user behaviour. [ Annex B ] [ ATOM 1.3.2] - Workload - keep user mental workload within acceptable limits - Individualisation - accommodate individual differences among users through automatic adaptation or

user tailoring of the interface EXAMPLE: Information Filtering: In the ATOMOS 1.3.3 task, several recommendations for the ATOMOS Information Presentation Agent (AIPA) were given: - System-initiated interface adaptation should only be used when immediate danger requires all attention of the

operator (i.e. in short-term adaptation). In all other cases operator-initiated adaptation of the interface is preferred although the system may propose adaptations that require approval of the operator. As an alternative to system-initiated short-term interface adaptations, the operator may also be protected by a sophisticated warning and alert system, including trend alarms. Warnings should be self-explaining in order to minimise workload and should prevent fright reactions. An elegant way of human-initiated interface adaptation is implicit adaptation. This implies that the operator is capable of controlling the different ship systems on several hierarchical levels which reduces the need for explicit communication.

- Long-term interface adaptation should preferably also be human-initiated and should allow operators to create an interface adapted to their own wishes. The system may also make proposals when the operator is changing the interface. These proposals should be based on research that has indicated how transfer of training from the novice mode to the expert operator mode is maximal.

- No matter who initiates the adaptation of the interface, any adaptation should be clearly indicated (e.g. by the colour of the instrument lights). Also, usual operator actions should be allowed to be executed in the normal way - only the interface presentation format may change, not the way it is controlled.

Interface adaptation should involve postponing messages that load the operator. Also, information can be presented in another modality or in a changed format. However, care should be taken with such adaptations - even when human-initiated - since unexpected changes or messages in an unfamiliar format, e.g. in a mentally loading situation,


ISO/Pre-WD ©ATOMOS II may increase operator workload even more. Most probable candidates of operator tasks to be changed are those tasks that do not improve much with experience. When operator tasks that are high practice are changed, workload will increase consider-ably. The successful introduction of adaptive interfaces will inevitably depend on user understanding and acceptance. This implies that ambiguity and lack of operator control should be prevented in any case. On the other hand, the user may become over-reliant and will not even consider the possibility of a failure. The AIPA should be designed to prevent such misunderstandings.[ ATOM 1.3.3 ]



14. Annex A - Example of Safety Assessment Model (Informative).

14.1. General. This Annex provide an example of the methodology to follow during the process-based safety assessment required throughout the SCC life-cycle discussed under Clause 7.2. In the following Clauses the three phases of the methodology are outlined, together with some preliminary examples of tools and formats which could be adopted. Reference is also made to ATOMOS II ID A218.02.05.052.002A Safety Assessment: Draft of Models [8].

14.2. Functional Model As proposed by IMO the first step of the analysis is to define a generic functional model. The generic functional model for a generic ship is assumed to be the one presented by the IMO [9] and here outlined in Figure 14.

NavigationOthers Emergengy

Mooring/Towin Bunkering/Storin Communication

HabitablePayload

StructureGeneric Manoeuvrabilit

Anchorin

Power/PropulsioPollution Stability

Figure 14- Generalised Ship Functions (IMO, 1996). This generic functional model should be detailed fofunctional models should be developed for tho

r each of the identified functions. Separate detailed se functions identified as critical, a preliminary selection of

ese functions can be (but should not be limited to) the following:

tress.

th- Propulsion; - Navigation; - uvrability;

Ship Management; Steering/Manoe

- Cargo Handling and Stowage; -

Structure/Hull S- Moreover, these functional models can be characterised upon other parameters such as ship type and GRT tonnage, to adapt the safety assessment methodology to the chosen SCC design option.



he next step of the FSA study is to identify the particular hazards to which the system is subject. This rocess should be developed by means of standard techniques like:

spect to those systems involved in

cannot be taken as an exhaustive

hase. Thus the subsequent screening and ranking of the

ritised list of possible hazards to be further analysed in the next ent pha

4.2.2. Risk Assessment

nd Analysis, the possible underlying causes of some of the risk as the most critical and/or the most influenced by the new concept

Fault Tree Analysis (FTA)

acc In ap

or a set of the identified hazards a FTA analysis should be performed. This analysis will follow the tandard procedure, consisting in building a fault tree starting from a specific "top event".

e obtained g the following:

e identified if:

The functional model can be performed by means of standard techniques such as Functional Block Diagrams (FBD) and is the basis for the subsequent development of the other phases of the Safety Assessment process. 14.2.1. Hazard Identification Tp- Brainstorming; - Hazard and Operability (HAZOP) studies; - Failure Modes, Effects and Criticality Analysis (FMECA); - Safety Audits.

he FMECA and HAZOP exercises should be mainly developed with reTthe functions identified as most significant for the safety of the ship (such as those listed in the previous Sub-clause). is highlighted that, even if the analysis of world accident databasesIt

source for the identification of all possible hazards, it can be stated that "at least" those hazards that are the most frequently experienced or, better, the most critical in terms of their consequences, should be onsidered in the subsequent risk assessment pc

identified hazards (a step foreseen also by the IMO FSA methodology), should be performed also on the basis of casualties databases analyses. The final outcomes of this phase is a priosk assessm se. ri

1 Following the Hazard Identification aexposure sources, i.e. those identified

a fully integrated SCC, should be furof ther explored using techniques such as and the possible outcomes traced using Event Tree Analysis (ETA). It is highlighted that in these analyses the human factor has to be taken into account, both in the identification of the fault trees leading to the specific hazard and in the analysis of the event chains that can lead or not to undesired escalation of the hazard into an accident. The final scope of this risk assessment is to determine if the designed SCC is associated to an

eptable risk following the ALARP principle.

the next sub-clause FTA and ETA techniques will be further described together with some examples of plication.

14.2.2.1. Fault Tree Analysis Fs

ach of th ates should be identified as in E- OR gate, with the usual meaning; - AND gate, with the usual meaning; - Basic Event, when the event is considered not to be further developed; - Separate Tree, when the event comes as the result of a sub-tree building. Considering the new concept that is adopted designing a new SCC/ISC-based ship, it should be helpful also to identify in this analysis whether or not each of the identified gates is influenced by this new ntegrated approach, with respect to the conventional one. This "sensitiveness" can bi



ists of a physical/functional reliability that in the new integrated concept will be improved by enhanced redundancy philosophy,

stic of the system and to a human factor involvement, being perhaps the latter the most influenced by the SCC concept;

14.2.2.2. Event Tree Analysis For each of the top events analysed with the FTA technique, a ETA should be performed to analyse the event chain linking each hazard with the possible expected consequences. The ETA is aimed to the quantification of the probability that a specific hazard arises to an accident scenario. For this purpose a sequence of events is considered, starting from an initiating event already quantified in terms of frequency of occurrence in the previous FTA, and a numeric assessment is performed to evaluate for each of the events the probability of occurrence. These are mostly events concerning protection system/procedures, mitigating measures, human factors, etc. For each event chain’s element some other information should be provided, such as the possible reason for escalation to the next gate and other actions and precautions to be taken. As already performed for the FTA, also in the ETA the "new SCC concept sensitiveness" should be analysed in detail while building the event trees. Each event tree should be therefore resolved in terms of probability of occurrence of different accident’s magnitude. The magnitude should be expressed in the most appropriate units such as lives lost, tonnes of generic released pollutant, money loss, etc.

- the gate represents a basic event that is influenced, in terms of reliability data, by the adoption of an integrated ISC system. This could happen, for example, if the event cons

innovative architecture, innovative HMI design, etc.. It is evident that this applies both if the gate is related to a physical or functional characteri

- the gate represents a sub top event of another fault tree that is expected to be developed in a significantly different way if applied to an ISC ship.



15. Annex B - ATOMOS II Style-guide (Informative).

15.1. About this Document. 15.1.1. Purpose and Scope. This document summarises the results of subtask 2.3.3: "HMI Concept and Style-guide" of the ATOMOS II project (Advanced Technology to Optimise Maritime Operational Safety, Integration & Interface). The main objective of subtask 2.3.3 is the definition of the HMI concept and the style-guide. The concept describes the SW technology, which integrates different system applications into a common HMI. The style-guide describes shape, size, colour etc. of screen elements and ensures that different system applications have the same „look and feel“ on the screen.

15.2. Introduction and Summary The early definition of a unified development and target platform - with special emphasis on the HMI - is vital to ensure optimal and coherent results which later in the lifecycle can be integrated into a unified concept. This report starts with a definition of the HMI system followed by an overview about the system in context. It shows, how the HMI system is integrated into the future HW platform of the ATOMOS bridge and how the equipment is arranged. Further on it shows, how the different system applications can be linked together on one workstation by today’s software technology although they are not developed by one company and not compiled together. Finally, a main part of this report covers the common style-guide for the HMI. It defines the partition of the screen layout and the shape, size, colour, behaviour etc. of the HMI elements on the screen. The procedure for the operation of certain user actions is defined in addition.

15.3. Context. 15.3.1. Definition of HMI System. The HMI system comprises all necessary elements for the interaction between the operator and the ISC system. In general it covers the whole bridge layout with discrete push buttons for specific functions, with keyboards, controls, levers and all displays. 15.3.2. State-of-the-art Bridge Layout A typical bridge layout, providing an idea about the context for the HMI system is described in Annex D of this document. 15.3.3. Coverage of this Report This report is focusing on the design of the workstation user interface only.

15.4. HMI System Concept. 15.4.1. Hardware Architecture. 15.4.1.1. Hardware Platform


ISO/Pre-WD ©ATOMOS II For the purpose of this document, the hardware platform for the HMI is an Intel-based PC-type workstation. 15.4.1.2. Operating System For the purpose of this document, the MS Windows NT 4.0 operating system has been assumed. 15.4.1.3. Network Interconnection For the purpose of this document, it is assumed that all workstations required to operate the ship are interconnected by the real-time ATOMOS network. 15.4.1.4. Safety Precautions For the purpose of this document, it is assumed that all safety critical parts of the ISC system are protected against power failure. Recommendations on this issue is considered to be outside the scope of this report. 15.4.1.5. Display Quality All visual display units in the SCC should conform to relevant international standards, including ISO 9241 - Part 3 Visual display requirements (ISO, 1992), and should focus on the characteristics of the visual display which determine its effectiveness in presenting an image to the user. The hardware concept includes at least two different workstation performance levels. - The highest level is required for radar applications, which should provide a 29“ colour display which

can be easily read by the helmsman from a distance of 2 or 3 meter. In case of a completely seated bridge design as proposed for the future with a view distance of less than one meter, a 21“ display would be sufficient!

- The next level is required for chart and conning applications as well as standard control tasks. They should have at least a 21“ colour display. The HMI screen layout, as introduced in the following paragraphs, has been optimised for this screen size based on a resolution of 1280 x 1024 pixel. All buttons and indicators are oversized compared to a standard Windows design so that they can be hit by the track-ball in a bad weather situation.

- A further level with 17“ display might be used for administration tasks in an office room, where small buttons and fields will cause no problem during operation. This size may also be used for the HMI development phase, where a full range of equipment is not available.

15.4.2. Software Architecture. 15.4.2.1. Basic Tool-set The software architecture is based on the functions and capabilities of the selected tool (Microsoft Visual Basic 5.0) and 3rd party tool-kits for the development of applications. 15.4.2.2. Application Manager The concept comprises a frame program, here called the application manager, and a number of system applications in the centre. Only one system application is shown at a time. Switching between applications is initiated only manually and managed by the application manager. The application manager displays the status line on top of the screen and the basic function line at the bottom. The system applications are arranged in the centre part.


ISO/Pre-WD ©ATOMOS II 15.4.2.3. System Applications System applications are independent programmes which have been developed and compiled separately using the selected tool-set and the current style-guide. The application manager detects available system applications during the system initialisation phase. Safety relevant control and supervisory applications are executed permanently. They are started immediately after the initialisation phase. The proper execution is watched periodically. If one of these applications fails, it is started automatically again. Examples for these types of system applications are: - Alarm handling system - Fire control system - Tactical display - Procedural management system - Hull stress monitoring system - Administrative applications are not to be used in the SCC. The application manager includes all available applications in the application tree. They can be activated by clicking the corresponding tree element. 15.4.2.4. Network Server Every system application shall be connected to the real-time process network. For this purpose a communications server is running on each workstation. Every application has access to this server. The communication between different applications is performed as follows: - A link between two applications on the same workstation is always build up via the server. No other

connections are supported. - A link between two applications on different workstations is build up via the server and the real-time

process network. - An indirect link between two applications is achieved by a common ISC data base. - Direct links between two applications without the network server are not supported except of the

connection between application manager and system application.

15.5. HMI Screen Areas. 15.5.1. Partition of Screen Area The overall HMI screen is divided into the following three areas: - Status area in the top line - Application area in the centre - Common control area in the bottom line The status area displays at all times important navigational and alarm information and has no controls. The application area opens a free space for one single system application. The common control area offers at all times ten buttons for control of the system applications. All areas together cover the complete screen with 1280 x 1024 pixel. The pixel size and the position of said areas are always the same irrespective of the working place and the activated application.



Figure 15. Screen Areas.

15.5.2. Status Area. 15.5.2.1. Design Principle. The place a user first looks for information is an important consideration in the implementation of a control system. Culture and interface design decisions can govern this principle. People in Western cultures, for example, look at the upper left corner of the screen or window for the most important information. In reflection of that, this instance of the HMI positions the top-priority information in the top left corner (alarm status) followed by the most important navigational information. 15.5.2.2. Size. The height of the status line has been designed to the necessary minimum in order to support the system applications with as much space as possible. The size is 60 x 1280 pixel. 15.5.2.3. Contents. The status line only displays information. Control buttons are not arranged in this area in order to allow the subsequent system application having its buttons directly underneath. The status line comprises the following data starting from the left side: - Alarm Status - Distance and bearing to next way-point or target


ISO/Pre-WD ©ATOMOS II - Speed and course - Rate of turn and water depth - Revolutions per minute for engine 1 & 2 - Time and date - Company logo (In this instance the ATOMOS logo) 15.5.2.4. Overlapping The status line is shown at all times and must not be covered by any application. The presentation is equal for all working places independent from the actual application. 15.5.3. Application Area. 15.5.3.1. Size All system applications cover the whole application area with 1280 x 920 pixel. 15.5.3.2. Contents It is recommended for all applications to divide the application area in a greater left subpart for graphical presentation (e.g. chart, engine arrangement) and a smaller right subpart for menu control and display of information. At the top of the right subpart there is always the equipment status placed. Left and right subpart may be divided further depending on the actual application as convenient. 15.5.3.3. Temporary Overlapping It is allowed to overlap temporarily every part of the application area with dialogue boxes opened by one of the common control buttons. The dialogue box has to be minimised as much as possible. If the tree function for the selection of system applications is activated, the whole application area is covered. 15.5.3.4. Example for the Application Area An example for the design of the application area is given here by an integrated navigation display. It has been taken from research carried out in the ATOMOS II project and demonstrates a.m. layout principles. It may be used as a basis for further development.



Figure 15.Error! Unknown switch argument. - Layout of the Tactical Display for Navigation Support

15.5.4. Common Control Area. 15.5.4.1. Design Principle Following the design principles for the top line again here the most significant control buttons are arranged starting from the left side. Safety critical applications like alarm handler or fire control system are directly accessible within one step. Less critical applications are accessible via the application tree within only two steps. 15.5.4.2. Size The height of the control line has been designed to the necessary minimum in order to support the system applications with as much space as possible. The size is 44 x 1280 pixel. 15.5.4.3. Contents The control line is used for the management of applications. It provides direct access to safety critical applications by control buttons for: Alarm handler opened by the first button from left Fire control system second button from left Three further important applications following buttons Navigation opens the tactical display Further on the control line provides access to common functions, which are directed to all applications like:


ISO/Pre-WD ©ATOMOS II Default switches the presentation to working place related default settings Brightness opens the menu for adaptation of the colours and intensities to the environment Tree opens the tree dialogue-box with the path to all applications and top-level menus Help opens the help dialogue-box with general on-line help about the application manager 15.5.4.4. Overlapping The control line is shown at all times and must not be covered by any application. The presentation is equal for all working places independent from the actual application.

15.6. HMI Style Guide The user interface should be developed according to the general principles of the Microsoft Windows Style Guide, but in this instance with a number of limitations taking the marine control application environment into account: - Control application windows are not allowed to be changed in size or as icons. - The user should not be able to manipulate the operating system, indicating that the ‘Taskbar’ of

Windows NT should not be visible in the control applications - Menus are designed slightly different according to the subsequent section (Error! Unknown switch

argument.) The first two exemptions are made to ensure that the user cannot inadvertently change to another application and thus loose control. 15.6.1. Allowed Components There is a number of interactive components provided by the chosen operating system (Windows NT 4.0 in this instance). These components provide a consistent structure and set of interface conventions. In the following an allowed set of interactive components is listed: 15.6.1.1. Menus Pop-up Menus (see also section Error! Unknown switch argument.) 15.6.1.2. Buttons - Command Buttons - Option Buttons - Check Boxes 15.6.1.3. List Boxes - Single Selection List Boxes - Drop-down List Boxes - Extended and Multiple Selection List Boxes - List View Controls - Tree View Controls 15.6.1.4. Text Fields - Text Boxes - Rich-Text Boxes - Combo Boxes - Drop-down Combo Boxes - Spin Boxes - Static Text Fields


ISO/Pre-WD ©ATOMOS II - Short Key Input Controls 15.6.1.5. General Controls - Group Boxes - Column Heading Controls - Tab Controls - Property Sheet Controls - Scroll Bars - Sliders - Progress Indicators - Tool-tip Controls - Wells - Toolbars - Status Bars 15.6.1.6. Pen-Specific Controls (only for Pen Input Device) - Boxed Edit Control - Ink Edit Controls 15.6.1.7. Primary Windows - Normal Windows - Multiple Document Interface Windows (MDI) 15.6.1.8. Secondary Windows - Property Sheets - Dialogue Boxes (as described later) - Palette Windows - Message Boxes - Pop-up Windows 15.6.2. Design of Components Homogeneous components in different menus and dialogue boxes have to be designed equally throughout the whole HMI system. Homogeneous components arranged horizontally or vertically in line have the same size. Details are as follows: 15.6.2.1. Line - Height 1 15.6.2.2. Buttons - Height 35 - Width if there is a single button in a menu line 240, if there are three buttons in a menu line 80 - Width of Command Button in Dialogues 120 - Appearance 3D - Alignment for Option Buttons and Check Boxes left justify 15.6.3. Menus

15.6.3.1. Contents of Menus Menus may contain all a.m. components, but they do not contain other menus or dialogue boxes. 15.6.3.2. Arrangement and Size of Menus


ISO/Pre-WD ©ATOMOS II The top level menu has to be placed in the right subpart of the application and cover it completely. A lower level menu has to cover the upper one completely except the menu name. It shall not exceed the area of the upper menu. The label with the upper menu name becomes a push button, if the lower menu is opened. This rule ensures, that on top of an activated sub-menu the whole menu path is shown. 15.6.3.3. Arrangement of Components within a Menu At the top the menu name is shown as a label within a frame. At the bottom below a separator a command button is shown (yes, no ,OK etc.). In-between the function components are arranged in a clear way. Gaps, frames or lines might be used for separation. In general components are left justified. Only labels or push buttons with the menu name are centred. Components arranged side by side are to be left as well as right justified in total. The arrangement of components has to be static and must not change with the situation. Components of functions, which under certain conditions are not operable, are indicated ‘disabled’ by colour switching but remains visible. Menus with similar contents should have similar appearance. 15.6.3.4. Decoration Frames and shadows have to be designed generally in such a way, that the upper menu is clearly separated from the lower one (in the area of the menu name). 15.6.4. Dialogue Boxes Dialogue boxes appear as an own window. A temporary dialogue box is a secondary window with a context specific dialogue and a long term dialogue box is a menu window. 15.6.4.1. Contents Dialogue boxes may contain all a.m. components. But they do not contain menus and other dialogue boxes. 15.6.4.2. Arrangement and Size of Dialogue Boxes The default position of every dialogue box shall allow operation with a minimum of cursor movements. The dialogue box should cover only a minimum of context specific information. Dialogue boxes can be moved by the operator to any place within the application area. Dialogue boxes may have fixed or operator changeable size. Every dialogue box with changeable size shall have a default size, which covers only a minimum of context specific information. Minimum size of changeable Dialogue Boxes - All components have to be visible - In lists shall appear a minimum of one line - Dialogue boxes must not change to an icon Maximum size of changeable Dialogue Boxes


ISO/Pre-WD ©ATOMOS II - Not greater than necessary to show all components - Neither the left subsection nor the right subsection of the application area are allowed to be covered

completely, thus a dialogue box still appears as a window. 15.6.4.3. Arrangement of Components within Dialogue Boxes Same as with menus, but the name of the dialogue box appears in a title bar. 15.6.4.4. Decoration Frames are always used. Dialogue boxes with fixed size have a thin frame, dialogue boxes with changeable size have a slightly thicker frame. The system menu box is always present. The title bar is always present. The maximise button is always present in dialogue boxes with changeable size. The minimise button is not allowed. 15.6.5. Tree The tree is a special control (tree view) in a secondary window, that can be opened by means of the Tree Button on every working place. 15.6.5.1. Contents The tree view control contains objects with a label and an optionally bitmap. Besides the tree view control there are command buttons for certain actions (see also picture xx). 15.6.5.2. Arrangement and Size of Tree The tree window covers the whole application area, the size is unchangeable. 15.6.5.3. Arrangement and Size of components within tree

On the very left level there are the tree view objects of the available applications. On the following levels to the right the tree view objects of the first two menu levels related to the selected application are shown (if available). At the bottom outside the tree view control there are a number of command buttons (see also section 7.4). 15.6.5.4. Decoration Frame thin and without corner markings The system menu box, the title bar, the maximise button and the minimise button are not present. 15.6.6. Lettering 15.6.6.1. Font and Size The standard font for all text should be Arial bold with 16 pixel height


ISO/Pre-WD ©ATOMOS II 15.6.6.2. Language English (UK) 15.6.6.3. Capital Letters Standard English headline lettering except dialogue boxes, where standard English is used. 15.6.6.4. Arrangement of Lettering Labels within frames are to be left justified. Exemption: Menu names in a menu path are centred 15.6.6.5. Designation of Buttons without direct Function Three dots have to be added to the title, if immediately following the activation a menu or a dialogue box is opened. 15.6.6.6. Consistency of Button and Menu Names Menu names have to be equal to the designation of the corresponding command button (only without dots). 15.6.6.7. Documentation It should be possible, to use all text labels also for the user manual. 15.6.6.8. Button Names for Standard Functions Standard functions should be accessible by buttons with the same name in all applications. 15.6.7. Menu Buttons The following buttons according to the MS Windows Style Guide should be used for menus and dialogue boxes. 15.6.7.1. File Instead of ’File’ the application specific names like Track, Map, Text, Diagram etc. should be used. 15.6.7.2. Edit, View, Window As Microsoft Windows Style Guide. 15.6.7.3. Help The Help button allows access to context specific information in an application. For global help information there is a help button in the basic menu.


ISO/Pre-WD ©ATOMOS II 15.6.7.4. New, Open, Save, Save as…, Print As Microsoft Windows Style Guide. 15.6.7.5. Close Close must not be used. 15.6.7.6. Exit, Undo As Microsoft Windows Style Guide. 15.6.7.7. Cut Cut must not be used. 15.6.7.8. Copy, Paste, Clear, Delete As Microsoft Windows Style Guide. 15.6.8. Buttons in Dialogue Boxes The following button names should be used in dialogue box according to the MS Windows Style Guide and if not otherwise stated also applicable to menus. 15.6.8.1. Yes, No, OK, Apply, Retry, Stop, Reset, Cancel As Microsoft Windows Style Guide. 15.6.8.2. Help This button is used to access context sensitive help for an application. 15.6.9. Colours. 15.6.9.1. System Colours and their Usage. In the following the name of the system colour and the corresponding name of the colour value in table 9.6.2 are listed: - Scroll Bar colour of scroll bars is set to background colour - Desktop colour of desktop is set to background colour - Active Title Bar colour of active title bar is set to highlight colour - Inactive Title Bar colour of inactive title bar is set to background - Menu Bar not applicable - Window Background colour of window background is set to background colour - Window Frame colour of a window frame is set to foreground colour - Menu Text not applicable - Window Text colour of text in windows is set to foreground colour - Title Bar Text colour of text in titles, in size changing buttons & scrollbars set to foreground colour - Active Border border colour of the window with the focus is set to active border colour


ISO/Pre-WD ©ATOMOS II - Inactive Border border colour of a window without focus is set to inactive border colour - Application Workspace background colour of MDI applications is set to background colour - Highlight colour of selected control elements is set to highlight colour - Highlight Text text colour of selected control elements is set to foreground colour - Button Face colour of button background is set to background colour - Button Shadow colour of button shadow is set to bottom shadow colour - Grey Text colour of inactive text is set to bottom shadow colour - Button Text colour of button text is set to foreground colour - Inactive Caption Text text colour of inactive captions is set to foreground colour - 3D Highlight top shadow colour of 3D elements is set to top shadow colour 15.6.9.2. RGB Values of System Colours The RGB values of the system colours depend on the ‘Brightness’-setting as shown in the following table:

RGB Values

Component Colour

Bright Day

Day Dark Day

Bright Night Night Dark Night

Background 220;220;220

190;190;190

160;160;160

70;70;70 35;35;35 21;21;21

Foreground 0;0;3 0;0;0 200;200;200

105;105;105

52;52;52 31;31;31

Bottom Shadow

125;125;125

105;105;105

80;80;80 40;40;40 20;20;20 12;12;12

Top Shadow 240;240;240

205;205;205

190;190;190

75;75;75 37;37;37 22;22;22

Highlight 251;95;95 213;81;84 182;69;72 120;54;11 60;27;5 36;16;3

Arm 185;185;185

160;160;160

120;120;120

90;90;90 45;45;45 27;27;27

Select

Alarm

Active Border

Inactive Border

Table 14.1: RGB Values of System Colours

15.7. HMI Operating 15.7.1. General Requirements


ISO/Pre-WD ©ATOMOS II The HMI layout of each system application has to be designed so that all functions can be activated by the track-ball and are available at all working places. Input of alphanumeric information has to be minimised as much as possible and should in general not be allowed as a selection method. The reason is that alphanumeric input requires the full keyboard, which will may not be available at all the navigation working places. 15.7.2. Operating Devices The following devices are used: 15.7.2.1. Function Keyboard The function keyboard includes: - Track-ball with Do and More key - Numeric keyboard with cursor The function keyboard is used for the navigation working places. They ensure a quick and safe operation. 15.7.2.2. Alphanumeric Keyboard

- PC compatible MFII keyboard, US keyboard layout The alphanumeric keyboard is used for all other working places and allows complete editing operations with text. 15.7.3. Input and Navigating Models The MS windows specific models are used with the following exemptions: 15.7.3.1. Input Device Model A track-ball is used as the pointing device. The relations of keys to the MS Windows Style Guide are as follows: - Left track-ball key with the Do function relates to the mouse button 1 (commonly the leftmost button) - Right track-ball key with ‘Information’ function relates to the mouse button 2 (commonly the rightmost

button) The system allows the user to swap the mapping of the buttons. The following actions of the pointing device are supported: - Pointing without using the mouse button - Clicking pressing and releasing a mouse button without moving the pointer - Double-clicking pressing and releasing the mouse button twice in rapid succession without

moving the pointer - Pressing pressing the mouse button (it is often the begin of a click or drag operation) - Dragging pressing down the mouse button, while holding down the button moving the pointer Actions like chording (pressing multiple mouse buttons simultaneously) and multiple clicking (triple- or quadruple-clicking) are not recommended, because these behaviours require more user skill. 15.7.3.2. Navigating Model


ISO/Pre-WD ©ATOMOS II All applications can be addressed directly from the tree dialogue box. On top of an opened menu the headlines of all preceding menus are shown. By clicking to one of these headlines the menu opens and all others in this line are closed. The control of focus frame within a menu or dialogue box is done by the cursor keys. If the menu or dialogue box is divided into parts, the focus frame can be moved from one to the other with the tab-key. By positioning the pointer on a graphical object and pressing the ‘Information’ key of the track-ball (commonly the most right one), a context sensitive pop-up menu will be opened, which shows possible actions with relation to the pointed object. 15.7.4. Operation of Tree The tree dialogue box is activated with the ‘Tree’ button of the basic menu. The tree shows the tree view control objects for the selection of applications. The following level of the tree shows the top level menu buttons of the available applications. Subsequent levels show the top level items of subsequent menus. At the bottom line of the tree dialogue box there are the following three buttons: - The ‘Cancel’ button for closing the tree dialogue box; - The ‘Exit’ button for closing down all control application; - The ‘Power Down’ button for shutdown of the workstation.

Figure 14.2. Example of Application Tree

The above example is just a draft and will be updated within the tool-set development phase. The arrangement of buttons and symbols will be more precisely adapted to the style-guide.


ISO/Pre-WD ©ATOMOS II 15.7.5. Help System

15.7.6. Introduction Online user assistance is an important part of a product’s design and can be supported in a variety of ways, from automatic display of information based on context to commands that require explicit user selection. Its content can be composed of contextual, procedural, explanatory, reference, or tutorial information. But user assistance should always be simple, efficient, and relevant so that a user can obtain it without becoming lost in the interface. For the ATOMOS HMI the help system is arranged in two independent steps: The general help system for the application manager Application specific help systems for each application The division has been made in order to de-couple the application manager as much as possible from the underlying applications. This step reduces the messages between these units as much as possible and ensures an efficient system integration. 15.7.6.1. General Help System By activating the ‘Help Button’, placed at the right side of the common control line, the general ‘Help Dialogue-box’ is opened, which shows the help text for the application manager. 15.7.6.2. Application Help System By activating the ‘Help Button’, placed at the bottom right side of the application window the specific ‘Help Dialogue-box’ is opened, which shows a context sensitive help text for the actual application.



16. Annex C - Associated Work Products (Informative) 16.1. Lists of associated work products from human-centred lifecycle processes The following sections list the typical work products which are used by, and which originate from, human-centred lifecycle processes. Many of these products are exchanged or shared with the system development and safety processes in the SCC development. Many of these products are elaborated or revised by subsequent processes. Because of the iterative nature of the human-centred lifecycle work products may be revised several times. Table C.1 - Plan the human-centred design process

Input Output

- Development plans for system - Staff skills profiles - Human-centred methods and tool

descriptions - Test method descriptions - Project management statistics - Project monitoring data - General usability objectives - Human and organisational requirements

- List of human centred activities to be carried out

- Procedure for integrating human centred activities with other development activities

- The individuals and organisation(s) responsible for the human-centred design activities and the range of skills and viewpoints they provide

- Procedures for establishing communication on human-centred design activities as they affect other design activities and methods for recording these activities

- Milestones during the design and development process, e.g. through specification of life cycle documents

- Procedures for ensuring full use of feedback from all pilots, trials and evaluations

- Suitable timescales to allow feedback to be incorporated into the design schedule

- Assignment of usability objectives to elements of the system

- Definition of evaluation criteria following from usability objectives

- Indication of test method(s) for evaluations - Advice on the degree of iteration


ISO/Pre-WD ©ATOMOS II Table C2 - Understand and specify the context of use

Input Output

- System Requirements - User Requirements Specification - Organisational Requirements Specification - Project scope - User representatives - Work instructions - Time and format of the provision of context

of use information to the development team

- Specification of the range of intended users, tasks and environments

- Stakeholder information - User information - Task information - Organisational analysis - The sources from which the context of use

information was derived

Table C3 - Specify the user and organisational requirements

Input Output

- Project scope - User representatives - Work instructions - Legislation - Industry, National and International

standards - Context of use - Competitor systems - Time and format of the provision of

requirements to the development team

- The range and relevance of users and other personnel in the design

- Human factors risk assessment - A statement of the human centred design

goals - User Requirements Specification - Organisational Requirements Specification- Priorities for different requirements - Specific Measurable Usability Goals - Benchmarks against which the design can

be tested - List of statutory or legislative requirements - The sources from which the user and

organisational requirements were derived


ISO/Pre-WD ©ATOMOS II Table C4 - Produce design solutions

Input Output

- System Requirements Specification - User Requirements Specification - Organisational Requirements Specification - Context of use - Measurable Usability Goals - Ergonomic requirements - Standards and Guides - Style Guide(s) - Expertise - Feedback from evaluations

- The sources of existing knowledge and the standards used, with an indication of how they have been incorporated (or why they have not been followed, if appropriate)

- User Interaction Specification - Dialogue detail - Look and feel - Layout and other UI issues - Simulations of specification - Prototypes of part/all of system - Task model - Assignment of functions - Worksystem design - Prototypes - List of standards used and how applied - Justification of deviations from any

standard to meet particular user requirements

- Report on how conflicts between design requirements and existing knowledge were dealt with in the design

- Means of feedback and use of results in other design activities

- The steps taken to ensure that the prototype covered key requirements and followed good practice

- Evidence of revision in accordance with results of evaluations

- Training plans for users and maintainers of the system

- Definition of user support services for the system

Table C5 - Evaluate designs against requirements



Input Output - Project plan - System Requirements Specification - User Requirements Specification - Organisational Requirements Specification - Context of use statement - Measurable Usability Goals - Standards - Legislation - Guidelines - Standards for HF activities - Test criteria - Testing staff - Test specifications/plans - Assessment tools - Work instructions - Working practices - Users - User details - Questionnaires - Comissioning objectives - In-use user and organisational satisfaction

objectives - Long-term health, safety and well-being

objectives - Description of the usability, health and

safety requirements

- Which parts of the system are to be evaluated and how they are to be evaluated

- Context of evaluation - Full description of the system tested and

its status - Number of users taking part in testing,

including evidence of adequacy of number of users and their representativeness of those identified in the context of use

- Testing and data collection methods, including evidence of appropriateness of these methods for the system and context of use

- Results in detail and appropriate statistical analysis.

- A report of major and minor non-compliances and observations and an overall assessment

- A clear pass/fail decision in relation to the requirements

- Evidence of the competence of the assessor(s) and the selection and use of relevant procedures

- Evidence that sufficient parts of the system were tested to give meaningful results for the system as a whole

- Source of evaluation feedback - Usability and ergonomic defects - Recommendations for improvement - Video and audio tapes from trials - User observation logs - Trial plans and records - Revisions to requirements - Interview transcripts - Measurements of ergonomic parameters - Survey criteria - Survey plan - Survey report


ISO/Pre-WD ©ATOMOS II Table C6 - Facilitate human-system implementation

Input Output

- System/product vision

- Context of Use Statement

- System Requirements Specification

- User Requirements Specification

- Organisational Requirements Specification

- Comissioning plan

- Client’s business plan

- Stakeholder information

- User information

- Task information

- Organisational analysis

- User representatives

- Stakeholder representatives

- Standards, Guidelines and Legislation

- Training plans for users and maintainers

- Definition of user support services

- Implementation development plan

- Implementation plan

- Client representative

- Identified stakeholders

- Organisation structure

- Job descriptions

- Work Instructions

- Human and Organisation impact assessment

- Training specifications

- Training plan

- Training material

- Trainer training material

- Impact reports

- Membership of user panel

- Monitoring criteria

- Monitoring programme

- Monitoring reports

- Workplace Audits

- Recommendations for enhancements to the system in the user organisation Information for future development projects.



17. Annex D – Example of conceptual Bridge layouts (Informative).

17.1. Introduction In this section two conceptual bridge layouts are described, applied to the SCC design of a chemical tanker (conforming to the agreement of the ATOMOS II Consortium). The mission of such a chemical tanker can be defined as "fast, safe and economical transportation". On this ship normal procedures will be carried out by one operator. However, the design must enable two-men ship operation for emergency operations, training purposes and redundancy. Subtask 1.2.1 of the ATOMOS II project specified the function and task analysis which can be considered as the starting point of a conceptual design of the layout of the future ship bridge, (ATOMOS II deliverable A212.01.10.052.002). The main objective of the function and task allocation is to define the specific functions and tasks that need to be carried out on the future ship bridge. The aim of subtask 1.2.2 was to decide how functions (or tasks) could be fulfilled, by humans or by technology or by a mix of both. The result of this function allocation is a specification of operators and instrumentation which have to be present on the bridge. The detailed specification of humans and technology on the basis of human factors criteria has been described in (ATOMOS II deliverable A212.02.052.001). Subsequently, two general layouts have been constructed as different design alternatives. The two variants are called the ‘state-of -the-art SCC’ and the ‘future SCC’, mainly differing with respect to the level of automation. The result of the design process was a ship bridge with two workplaces in the state-of-the-art SCC, and a ship bridge with one workplace at the future SCC. During this design process, compromises had to be made between technical solutions and human factors requirements. Therefore, the design had to be thoroughly evaluated, which has been carried out using different techniques: human modelling systems virtual environment techniques (ATOMOS II deliverable A212.03.10.055.006).

17.2. Conceptual Layouts 17.2.1. State-of-the-art SCC The state-of-the-art SCC suits one-man operation of the bridge by the integration of ARPA, ECDIS and conning information and central information presentation. Still, the operator has the possibility to use conventional charts. Further, the design enables two man ship operation for emergency operations, training purposes and redundancy. Instruments for navigation control are partly integrated in a tactical display, other instruments will be present as separate hardware as in the traditional bridges (for instance thrust, rudder and communication). Error! Unknown switch argument. and Error! Unknown switch argument. presents the final design of the state-of-the-art SCC in a bird’s eye view.



Figure 17.Error! Unknown switch argument. - Layout of the State-of-the-art SCC (Looking forward)

Figure 17.Error! Unknown switch argument. - Layout of the State-of-the-art SCC (Looking aft)

EXAMPLE: This example design of the State-of-the art SCC consists of the following parts: - A navigation workstation is placed at the front of the bridge. The navigation workstation consists of a workplace

where navigation takes place (A) and a second workplace for training, emergency and redundancy (B). - A planning workstation (C) is placed at the centre of the bridge. This workstation supports the planning and

preparation of voyage. At each side of the state-of-the-art SCC, open bridge wings are added (D and E). These bridge wings support a good outside view during mooring and unmooring or man-overboard procedures.

- At kitchenette (F) and a toilet (G) are positioned at the back of the SCC.


ISO/Pre-WD ©ATOMOS II The state-of-the-art SCC is surrounded by windows. Access to the SCC is enabled by the use of a staircase (H) at the back of the bridge. Navigation Workstation: Figure 15.3 shows in detail the design of the navigation workstation for the state-of-the-art SCC. This workstation is suited for the navigation, communication, and maintain and monitor crew, passengers, platform and cargo. The "cockpit like" navigation workstation has been designed as compact as possible to support central information presentation. The operator has the possibility to gain all information at a glance.

Figure 17-3 - Close-up of the Navigation Workstation

Displays: The number of displays at the navigation workstation is four, see figure 15.3: - A display to present tactical information or ECDIS (I); - A display to present conning information (II); - An integrated monitoring and control (IMCS) display (III); - A redundant display to present tactical information or ECDIS (IV). ECDIS is used to plan a certain track before voyage, or for "short-term" adjustments during voyage execution. At the state-of-the-art SCC it is also possible to plan the track at the planning workstation. The use of conventional sea charts is possible at the planning workstation. The tactical display is used during voyage and integrates the planned track and fairway (from ECDIS), ARPA or other traffic information and essential conning information for control of the own ship. This tactical display combines ship control information and avoidance of collision and grounding (Passenier et al., 1997). The conning display presents the complete set of conning information, which for instance describes information on thruster states and mode of operation. Information concerning monitoring and maintaining cargo, crew, passengers and platform is integrated in the IMCS display. Instruments: Controls for rudder, thrust, and autopilot are added as hardware instruments at the middle part of the navigation workstation. Track-pilot information is integrated in the tactical display. The rudder is handled by a side stick (for both sitting/standing positions a side stick, within direct hand reach). The thrusters and autopilot are handled by buttons. These instruments are positioned within the reach envelop of both positions. Communication: The communication equipment necessary for the officer of the watch seated at starboard is a normal phone which can switch between all types of communication channels and a specific VHF telephone. The normal phone can be connected to a head set or the telephone receiver can be used. Both options are available in the navigation workstation.The port side seat is also equipped with a normal phone with multi-switch channels and an additional sound powered phone which is used to contact the engine room in case of an emergency. Chairs: A good reachability and visibility of all instruments and a proper outside view during sitting as well as standing postures is achieved due to the 300 mm increased height of chairs and workstations. Both chairs can be placed under the desk or moved backwards to offer the operator free space to stand behind the workstation. Planning workstation: The planning workstation consists of an ECDIS display for voyage planning and preparation. This display is equipped with keyboard and tracker-ball, positioned in front of it. To enable the use of conventional sea-charts, a chart table is integrated at the planning workstation. The angle between the chart table and the ECDIS


ISO/Pre-WD ©ATOMOS II station supports an improved view and reachability over a straight desk design. The communication equipment necessary at the planning workstation is a normal phone which can switch between all types of communication. The phone is positioned between the ECDIS station and the chart table to be reachable from both parts of the planning workstation.The ECDIS station is suited for standing and sitting postures. The heightened sitting position is also advantageous in having an unobstructed outside view. The chair can be placed under the desk or moved backwards to offer the operator free space to stand behind the workstation. The chart table is only suited for a standing working posture. The space under the chart table is used to store charts. 17.2.2. Future SCC The future SCC is based on future technological developments. Starting point for this design was again one-man operation and central information presentation. All systems and instruments are integrated into a minimum of computer-systems to achieve a very compact workstation design. The design enables two-men ship operation for emergency operations, training purposes and redundancy. The use of traditional charts will fall into decay. Navigation controls are integrated and computer-driven. Instead of the traditional CRT monitors, LCD’s are applied for information presentation to improve the outside view. Further, a closed wing concept was assumed to be part of the future design. For this purpose, bridge wing control panels have been added to the design.

Figure 17.Error! Unknown switch argument. - Layout of the Future SCC (Looking forward)

Bridge wing control panel: The workstation is used entering and leaving port and when the ship needs to be anchored. This means that the information shown must be constantly updated in order to reflect the condition of the different equipment involved. This workstation must be placed near to the bridge wing from the bridge in order to have a wide field of vision of the manoeuvres areas. Ruling and standards applied to these workstations in general, use all that has been described in the previous paragraph, but they have certain peculiarities that are dealt with here below. It must be taken into account that the work for which these workstations are designed is done standing up, which means that it must comply with measurements in accordance with the average height of the operator. The panel consists of a flat panel display which presents all necessary conning information, a side stick to steer the ship during docking procedures and a normal phone witch multi-switch channels for communication during docking. The phone can be connected to a head set. There is enough space for a operator to stand in the front corner of the bridge wing. In that case, the side stick will be within direct hand reach.



18. Bibliography

18.1. Standards - International Maritime Organisation (IMO), 1996, “Formal Safety Assessment - Draft guidelines for

FSA application to the IMO Rule-Making Process, submitted by the Chairman of the Working Group on Formal Safety Assessment”, IMO MSC 67/13.

- [IMO STCW95] International Convention on Standards of Training, Certification and Watchkeeping for seafarers, 1995

- [BS292-1] BS EN 292-1 Safety of machinery. Basic concepts, general principles for design Basic terminology Methodology

- [BS292-2] BS EN 292-2 Safety of machinery. Technical principles and specifications - [BS4778] BS 4778 : Section 3.2 : 1991 IEC 50(191) : 1990 Quality Vocabulary Part 3. Availability,

reliability and maintainability terms Section 3.2 Glossary of international terms - [BS61069-1] 1993 Industrial-process measurement and control - Evaluation of system properties for

the purpose of system assessment Part 1. General considerations and methodology - [BS61069-2] 1994 Industrial-process measurement and control - Evaluation of system properties for

the purpose of system assessment Part 2. Assessment methodology - [BS61069-5] BS EN 61069-5 : 1994 Industrial-process measurement and control - Evaluation of

system properties for the purpose of system assessment Part 5. Assessment of system dependability - [IEC1209] Future Publication IEC 1209, Integrated Bridge Systems (IBS), Operational and

performance requirements, methods of testing and required test results, issue 7.0, 19.02.97 - [IEC1508-1] Draft IEC 1508-1: Functional Safety - Safety related systems Part 1: General

Requirements, 65A/179/CDV, June 1995 - [IEC1508-2] Draft IEC 1508-2: Functional Safety - Safety related systems Part 2: Requirements for

E/E/PES, 65A/180/CD, June 1995 - [IEC1508-3] Draft IEC 1508-3: Functional Safety - Safety related systems Part 3: Software

requirements, 65A/181/CDV, June 1995. - [IEC1508-4] Draft IEC 1508-4: Functional Safety - Safety related systems Part 4: Definitions and

Abbreviations of Terms, 65A/182/CDV, June 1995. - [IEC1508-7] Draft IEC 1508-7: Functional Safety - Safety related systems Part 7: Bibliography of

techniques and measures, 65A/185/CD, June 1995. - [IEC51] Safety aspects - Guidelines for their inclusion in standards. - [IEC92504] IEC 92-504 : 1977 Electrical Installations In Ships - Part 504: Special Features. Control

And Instrumentation. - [ISM] International Management Code For The Safe Operation Of Ships And For Pollution Prevention

(International Safety Management [ISM] Code), IMO. - [ISO13407] [ISO13407] Human-centred design processes for interactive systems, 1997-01-10. - [ISO9126-1] [ISO9126-1] Information Technology - Software quality characteristics and metrics - Part

1: Quality characteristics and sub-characteristics, version 6.3, 5-Jan-97. - [ISO9241-10] ISO/DIS 9241-10.2 Ergonomic requirements for office work with VDTs - Part 10:

Dialogue principles, 19 Jun. 1996. - [EN894-1] prEN 894-1 : 1996 Safety of Machinery - Ergonomic requirements for the design of displays

and control actuators - Part 1: General principles for human interactions with displays and control actuators.

- ISO 6385:1981, Ergonomic principles in the design of work systems - ISO 8468:1990, Ship’s bridge layout and associated equipment – Requirements and guidelines - ISO 11064, Ergonomic design of control centres - ISO 9241, Ergonomic requirements for office work with visual display terminals (VDTs) - ISO 8995:1989, Principles of visual ergonomics - The lighting of indoor working systems - ISO 2631-1, Evaluation of human exposure to whole body vibrations - ISO 5349:1986, Mechanical vibration: Guidelines for measurement and the assessment of human

exposures to hand transmitted vibration. - ISO 1996-1:1982, Acoustics: description and measurement of environmental noise.


ISO/Pre-WD ©ATOMOS II - ISO 7779:1988, Acoustics: Measurement of airborne noise emitted by computer and business

equipment. - ISO 13406:1995, Part 2 Flat panel display ergonomic requirements (Committee Draft International

Standard) - BS EN 614-1:1995, Safety of machinery – Ergonomic design principles. - BS EN 894-1:1997, Safety of machinery – Ergonomics requirements for the design of displays and

control actuators 18.2. ATOMOS II References - Doorne, H. Van, Schuffel, H., (1996), Function and task analysis, ATOMOS II, Task 1.2.1, ID code:

A212.01.10.052.002, TNO Human Factors Research Institute, Soesterberg. - Essens, P.J.M.D., (1997), Function allocation, ATOMOS II, Task 1.2.2, ID code: A212.02.10.052.001,

TNO Human Factors Research Institute, Soesterberg. - Oudenhuijzen, A.J.K., Punte, P.A.J., Bergem, P.M. van, Werkhoven, P.J. (1996), Workspace design,

guidelines and design tools, ATOMOS II, Task 1.2.3-1, ID code: A212.03.10.052.003, TNO Human Factors Research Institute, Soesterberg.

- Punte, P.A.J., Oudenhuijzen, A.J.K., Hin, A.J.S. (1997), Design and evaluation of a conceptual layout for a standardised SCC, ATOMOS II, Task 1.2.3-2, ID code: A212.03.10.052.004, TNO Human Factors Research Institute, Soesterberg.

- Punte, P.A.J. et al, (1998), Design of the layout of standardised Ship Control Centres, ATOMOS II, Task 1.2.3, ID Code: A212.03.10.055.006, TNO Human Factors Research Institute, Soesterberg.

- Passenier, P.O., Breda, L. van, Kerstholt, J.H. (1997), The effect of an integrated navigation display on supervisory control tasks on-board ships, ATOMOS II, Task 1.3.1, ID code: A213.01.10.052.002, TNO Human Factors Research Institute, Soesterberg

- Passenier, P.O., Breda, Kerstholt, J.H. (1997), Human Computer Interaction Guidelines for Ship Bridge Interfaces, ATOMOS II, Task 1.3.2, ID code: A213.02.10.052.001, TNO Human Factors Research Institute, Soesterberg

- Passenier, P.O., Breda, L. van, Kerstholt, J.H. (1998), Instrumentation in the Standardized SCC: Integration and Recommendations, ATOMOS II, Task 1.3.2, ID code: A213.02.10.055.004, TNO Human Factors Research Institute, Soesterberg

- Jensen, H.J. et al. (1998), Information management, ATOMOS II, Task 1.3.3, ID code: A213.03.04.063.001.

- ATOMOS II ID A218.02.05.052.002A Safety Assessment: Draft of Models[

18.3. DISC References - [DISC] Research In Waterborne Transport Area 6.33/26(2nd Call): Demonstration of ISC - DISC Final

Report, D101.00.01.047.003, 1997.04.21, DISC Consortium

18.4. Other References - [IACS GUIDE] Proposed guidelines for on board use and application of computers, IACS, 19.04.1996 - [RULES PT6] Classification Of Ships Rules And Regulations Part 6 Control, Electrical, Refrigeration

and Fire, Lloyd’s Register, July 1998 - Det Norske Veritas, 1991, Rules for classification of ships, Special equipment and systems, additional

class - Punte, P.A.J., Post, W.M., (1997b), Detailontwerp van de brug en brugvleugels van het

Luchtverdedigings en Commando Fregat, Report TM-97-A016, TNO Human Factors Research Institute, Soesterberg (in Dutch).

- International Hydrographic Organization (1994). Special Publication no. 52, Colour & Symbol specifications for ECDIS. Report prepared by IHO COE Working Group on Colours and Symbols.

- Det Norske Veritas, (1991), Rules for classification of ships, Special equipment and systems, additional class, Part6/Chapter8/Section2 Version 7/1991.


ISO/Pre-WD ©ATOMOS II - Williges, R.C., Williges, B.H. & Elkerton, J. (1987). Software Interface Design. In: Handbook of Human

Factors, Salvendy, G. (ed.), John Wiley & Sons, New York. - Smith, S.L. & Mosier, J.N. (1986). Guidelines for Designing User Interface Software, MITRE-report

MTR10090, MITRE Corp., Bedford, MA, 1986


new conceptual standard for scc design (including hmi) · 2013. 9. 17. · hmi principles ......

Documents