Skip to main content

Image

Space engineering

Human factors engineering

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-E-ST-10-11C Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Division
    ESTEC, ,
    2200 AG Noordwijk
    The
Copyright:     2008 © by the European Space Agency for the members of ECSS

Change log

ECSS-E-ST-10-11A


Never issued


ECSS-E-ST-10-11B


Never issued


ECSS-E-ST-10-11C


31 July 2008


First issue


Introduction

This Standard defines requirements for the integration of the human in the loop for space system products. Thus it provides all requirements to be applied when the presence of the human is planned on-board, or for the nominal or non-nominal interaction of the human with the system, subsystem or equipment to be designed (e.g. a ground based human-computer interface). This Standard identifies requirements for the equipment for implementing a proper manned system that takes into consideration efficiency, effectiveness and wellbeing of the on-board crew, and ground based operators of human-in-the-loop systems. This Standard also identifies the verification methods and related methodologies to be used to confirm compliance to the above mentioned requirements.

This Standard is applicable to both the flight and the ground segment of the space system and refers to the maximum extent possible to already existing HFE non-space domain standards, deviating only when the specific application environment dictates it.

The application of human factors (that in the space domain includes ergonomics) to systems design enhances effectiveness and efficiency, improves human working conditions, and diminishes possible adverse effects of use on human health, safety and performance. Applying ergonomics to the design of systems involves taking account of human capabilities, skills, limitations and needs.

A space system design will consider human factors and especially the two following main aspects from the very beginning of the conceptual phase. Firstly the human being will be correctly taken into account in the design of the hardware, software and operations products and secondly the corresponding organisation and training will be addressed in parallel to the design of the hardware and software.

This standard provides:

a set of requirements for a human centred design process applied to a space system compatible with the ISO Standard 13407:1999 - Human-centred design processes for interactive systems.

A planned accompanying Handbook will provide:

a tailoring guide of the existing standard - ISO STD 17399:2003 previously known as NASA STD 3000 “Space systems - Man-systems integration”.

A key issue of the human centred design approach is the involvement of the stakeholders from the beginning and continuously throughout the project. Benefits of a human centred design include increased productivity, enhanced quality of work, reductions in support and training costs, and improved user satisfaction. This approach aims to help those responsible for managing hardware and software design processes as well as planning for operations to identify and plan effective and timely human-centred design activities. It complements existing design approaches and methods.

The customer’s total cost of ownership will be dramatically reduced if HFE practices are well integrated into all project phases, from the very beginning.

Scope

This Standard forms part of the System engineering branch of the Engineering area of the ECSS system. As such it is intended to assist in the consistent application of human factors engineering to space products by specifying normative provisions for methods, data and models to the problem of ensuring crew safety, well being, best performance, and problem avoidance in space system and payload operations.

This Standard ECSS-E-ST-10-11 belongs to the human factors discipline, as identified in ECSS-E-ST-10, and defines the human factors engineering and ergonomics requirements applicable to elements and processes.

This Standard is applicable to all flight and ground segments for the integration of the human in the loop for space system (this includes hardware and software or a combination of the two) products.

When viewed in a specific project context, the requirements defined in this Standard should be tailored to match the genuine requirements of a particular profile and circumstances of a project.

This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00.

Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references subsequent amendments to, or revisions of any of these publications do not apply. However, parties to agreements based on this ECSS 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 publication referred to applies.

ECSS-S-ST-00-01


ECSS system — Glossary of terms


ECSS-E-ST-10-06


Space engineering – Technical specification


ECSS-E-ST-34


Space engineering – Environmental control and life support (ECLS)


ECSS-E-ST-70


Space engineering – Ground systems and operations


Terms, definitions and abbreviated terms

Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSSSST0001 apply, in particular for the following terms:

operation

procedure

stakeholder

Terms specific to the present standard

context of use
users, tasks, equipment (hardware, software, operations products), and physical, social and organisational environment in which a product is used

crew
an organised group of users on-board a spacecraft or on a planetary surface mission

crew station
an area or volume where the crew operates

crew systems
hardware, software and operations products used to enable space systems to be safely, efficiently and effectively used by the crew

effectiveness
extent to which planned activities are realized and planned results achieved also considering accuracy and completeness with which users achieve specified goals

efficiency
relationship between the result achieved and the resources used where the human resource is the primary one to be considered

human-machine system
system composed by hardware, software and operations products which include human in the loop

For example:

  • this includes the simple tool up to the complete -International Space Station (ISS), passing through a human-robot system;
  • the system can also be multi machine or an organization that interface with a group of people.
    human centred design
    approach to human-machine system design and development that focuses, beyond the other technical aims, on making systems usable

operation
activities and measures to enable, maintain, or both, the intended use of the system, payload, or both

For example:

  • a group of tasks,
  • flight or scientific payloads operations.
    operations nomenclature
    consistent mission terminology and symbology across all items that the users interact with

procedure
set of instructions available to the users for system and payload execution that describe the specific sequence of operations to be performed by the users to logically, safely, and efficiently accomplish nominal and off nominal tasks during the mission

stakeholder
any entity (individual or organisation) with a legitimate interest in the system

For example: managers, users, hardware and software developers, HFE practitioners, operations engineers, curriculum developers and training instructors.

synoptic display
display for providing monitoring and command capabilities to users

task
set of activities that are assigned for a particular actor (human or machine) to perform a specific operation

user
human who has a role in the operation of the system

For example: crew and flight controllers.

Abbreviated terms

For the purpose of this Standard, the abbreviated terms from ECSSSST0001 and the following apply:

Abbreviation


Meaning


CSR


crew station review


DHM


digital human model


HCD


human centred design


HFE


human factors engineering


HMI


human machine interface


NOTE: In the context of HFE, MMI (man-machine interface) and HCI (human-computer interaction/interaction) are synonyms to HMI


NBF


neutral buoyancy facility


PF


parabolic flight


TA


task analysis


VE


virtual environment


Requirements

Overview

Requirements defined in this standard are specific to human factors engineering applied to the design and development of human machine systems for space applications. Furthermore this standard defines the high level requirements for these hardware, software and operation products that are specifically required by the presence of the crew on board. They include requirements aimed at reaching the best efficiency and effectiveness of system that foresee the interaction with the human being.

This document is organised in three different parts namely:

Process requirements: 4.2 to 4.4 clauses are dedicated to process requirements applicable to all space related products – where there are users

Requirement applicable to flight parts (applicable because are related to the crew and or to other “space related operators”):

4.5 is dedicated to human characteristics

4.6 is dedicated to general HFE domain requirements

4.7 to 4.9 are dedicated to the identified crew related systems (crew system, HMI and operations products).

Assessment and verification requirements: 4.10 and 4.11 clauses are dedicated to assessments and verifications for related HFE requirements, especially the process requirements mentioned in 4.2 to 4.4.

Key HFE parameters for human-machine systems

General

Characterization

The HFE parameters listed in 4.2.1.2 to 4.2.1.6 shall be characterised during design, development and assessment of space projects that includes presence of humans in the loop.

HFE Interrelated parameters

The following key HFE interrelated parameters shall be characterized in defining a human-machine system:

  • Users populations,
  • Operations or tasks,
  • Organisational environments,
  • Physical and psycho-physiological environments.

User populations

A user population for the different roles to be played in the human-machine system shall be defined.
The characteristics of the intended user population shall be defined in terms of:

  • Knowledge,
  • Skill,
  • Experience,
  • Education,
  • Psycho-Physical attributes,
  • Habits,
  • Preference and capabilities (including different nationality etc.), and
  • Level of Certification.

Task

The characteristics of a task of the human-machine system shall be characterised in terms of:

  • Objectives,
  • Availability of Resources,
  • Human functions,
  • Type (e.g. in case of tasks: cognitive, physical, automated … e.g. in case of operations: autonomous, maintenance, guided, proximity),
  • Complexity (e.g. when fast reaction are needed, multiple users are involved, uncertainties may occur, collaboration with autonomous or semi-autonomous systems),
  • or life criticality, and
  • Plans and Schedules.

Organisational environment

Organisational environment shall be characterised in establishing the users’ roles within the system.
The organisational environment shall include:

  • users roles,
  • crew size and compositions, and
  • share of control between users.

Physical and psycho-physiological environments

Physical environment shall be characterised in terms of:

  • Gravity,
  • Illumination, ambient light and colours,
  • Radiation (of cosmic origin and manmade sources),
  • Contamination (e.g. trace-gasses, microbiological, and particles),
  • “Comfort box” (temperature and humidity),
  • Air composition, ventilation and pressure,
  • Noise,
  • Vibration,
  • Acceleration,
  • Day-Night cycle, and
  • Environmental Hazard (e.g. electromagnetic fields, sharp corners). The following space related items that can impact on the psycho-physiological state of the users shall be characterised:
  • Habitable volumes and confined environment,
  • Privacy and personal items,
  • Aesthetics, colours and local “1-g” orientation,
  • type and duration,
  • Communications capabilities (private medical conferences; family contacts voice, television programs or movies),
  • Distance from Earth,
  • Autonomy and control policies,
  • Safe haven or emergency escape system,
  • Food and diet,
  • Leisure,
  • Crew size and composition,
  • Medical and psychological supervision,
  • Social monotony,
  • Sensory deprivation, and
  • Sleep and circadian rhythm.

Context of use

Context of use analysis shall be performed
Existing reports on previous systems and missions (if available) shall be used.
The context of use shall be defined in terms of:

  • Tasks that the users have to perform,
  • Overall goal of the system, and
  • Implication on health and safety. The set of potential exceptions and anomalies shall be identified.

HFE role and mission context

General

The HFE practices shall be applied from the beginning of the project in the design of all systems and their related missions, during all system mission phases when human beings are involved.

HFE role

Throughout the project the HFE shall:

  • be responsible for establishing and updating of the users’ roles,
  • be responsible for the definition, maintenance and verification of system human related requirements,
  • support and approve establishing and updating of users manuals, operations nomenclature and procedures,
  • support and approve definition, design, development and assessment of the required Crew Systems,
  • support and approve definition, design, development and assessment of the required Human Computer Interface software,
  • support and approve definition, design, development and assessment of the required Training Materials.

Operations nomenclature

The operations nomenclature shall be univocally defined not later than phase B of the program in cooperation with the engineering development and kept under configuration control.
Operations nomenclature shall assign operationally relevant terminology to hardware, HMI and database items.

Users manual

The user manual shall provide all the design and operational information for the space segment that is used by the ground segment and the operations team to prepare for and implement mission operations.
The user manual shall be developed in parallel with the development of the project; starting from PDR.
The user manual shall follow project review cycles, and be kept under configuration control.
The user manual shall include the description of all interfaces, operating modes and their constraints, telemetry, resources, and associated procedures for both nominal and contingency operations, and detailed requirements for ground mission-specific processes needed during operations.

This manual forms the basis for many operation products.

The user manual shall include the operational schematics.

Operational schematics can be represented by drawings depicting information about the functional design of equipment with respect to power, plumbing, signal flow, location and range of sensors and destination of their measurements, relays, valves, fans, and other operating systems. New formats taking advantage of model based design can be used.

Training approach

The approach for basic, mission specific and incremental or on the job training shall be characterised in the early phases of the program.
The system design and development planning process shall establish cooperation between training development and engineering development.
The training approach shall be characterised for all users.
Training facilities and organisation shall be defined not later than the system design phase of the program.

  • 1    This to identify and utilise design and development products and by-products that can be useful in the training program.
  • 2    This according to the users established roles and within the system selected mission.
    The schedule of the system design and development shall include training models design and development and crew training system development and implementation.

phases

phases shall be defined prior to the establishment of the HFE, requirements.
Crew and ground personnel roles shall be:

  • defined in the feasibility phase,
  • their tasks established in the system design phase.

Identification of requirements

HFE requirements related to each mission phase shall be defined in project feasibility phase and kept up to date following the increase of details generated in the development of the project.

For project phases and planning, see ECSSMST10.

Human centred design requirements

General

Applicability

The Human Centred Design (HCD) process described within clause 4.4.1 is applicable to the design of all human-machine systems.

Human centred design approach

The adoption of a HCD approach shall be characterised by the implementation and maintenance of the following:

  • user and task requirements,
  • allocation of functions between users and technology (operation analyses),
  • requirements iterations with all stakeholders,
  • involvement of users, their representatives, or both, in continuous evaluation of the design solutions, by means of the utilisation of simulations or mock-ups (either physical or virtual), and
  • multi-disciplinary design that includes experts of the various human aspects of the design, and subject matter experts.

Human centred design early implementation

The incorporation of the human centred design into the overall project structure shall be initiated during the feasibility phase.

To avoid risk of late and costly redesign or incorrect human integration.

Planning the human-centred design process

A human-centred design process plan that specifies how the human-centred activities fit into the overall system development process shall be prepared in conformance with Annex A and included as part of the overall system engineering plan.
During project planning, the capability to interact with and incorporate stakeholder feedback shall be provided.
The plan shall include the activity for the identification of complex or critical tasks and related scenarios definition.

Human-centred design activities

Overview

Below are the four human-centred design activities besides the normal engineering practice that take place during the development of a space human-machine system managed by the HFE responsible.

Human centred design activities

The human-centred design activities shall:

  • support and approve the operations activities and perform task analysis,
  • specify the user populations and organisational requirements,
  • produce design solutions with related rationales that can be evaluated by the stakeholders,
  • evaluate designs against operation scenarios and related key HFE requirements,
  • iteratively evaluate designs.

Task analysis (TA)

The human activities linked with the operations of the other parts of the system shall be defined.

This activity is called TA. The TA takes into account the context of use.

To provide for the allocation of functions to the crews the TA shall be developed during phase A when human in the loop is foreseen.
The TA shall be maintained throughout all project and utilisation phases.

User and organisational requirements

User populations and organisational requirements shall be specified and fed into the system requirements for the subsequent phases.

These requirements are derived from the specified context of use (preliminary TA).

Produce design solutions

Simulations, models and mock-ups (either physical or virtual) representing design solutions shall be used by the design team to communicate with all stakeholders.
Design solutions shall be integrated into a representative context of use.
The fidelity level of the design solution shall be compatible with the assessment objective.
Constraints imposed by the fidelity level shall be communicated to the evaluators.

Evaluate design

Overall objectives of design evaluations shall be established in accord with the stakeholders.
User’s evaluation criteria shall be established during phase A.
Design evaluation, as specified in 4.4.3.6e, shall take place at all stages of the system life cycle.

The objective is to allow each project phase evaluation to be performed with the utilisation of dedicated prototypes of the required fidelity.

Design evaluations shall be organised into Evaluation Events
An evaluation plan (part of human-centred design process plan) shall contain the following:

  • Task goals,
  • What part of the system is being evaluated, how and when,
  • How the evaluation is performed and the related procedures,
  • How to select, prepare, or both, the test operators and test evaluators, and
  • How the results are evaluated and documented. Evaluation events shall produce an evaluation report to be made available to all stakeholders.

For example crew Station Review.

Evaluation reports shall reflect the consensus of the group of test operators and test evaluators.
Evaluations with prototypes (including virtual representation/ modelling) shall be used to guarantee user’s safety and at the same time demonstrate effectiveness and efficiency of the design.

Human reference characteristics

Anthropometry and biomechanics

The Space System design shall use the anthropometric and biomechanics characteristics of the user population as defined for each part that foresees human involvement.

See also European Committee for standardization CEN: EN 1005-4 “Safety of machinery – Human physical performance – Part 4: Evaluation of working postures and movements in relation to machinery (17 February 2005).

Electronic mannequin

To perform the required anthropometric analyses when only configuration CAD data are available an electronic mannequin shall be used.

For detailed data and characteristics (n. of degrees of freedom), limb dimensions and joints characteristics) of the electronic mannequin refer to Document in Annex E – (this is for both IVA and EVA).

When the electronic mannequin is used for EVA or for IVA activities analysis where a dedicated suit is worn by the crew member, suit limitations to human movements and its encumbrances shall be characterized.
The electronic mannequin shall be used during in-flight maintenance procedure development and validation.

Physical performance and fatigue

The Space System design that foresees the presence of the human in the loop shall analyse human physical performances and impacts that can be caused by fatigue or by adverse environmental conditions.

Cognitive performance and fatigue

The space system design that foresees the presence of the human in the loop shall characterise human cognitive performances and impacts that can be caused by cognitive fatigue, and by adverse environmental conditions or both.
Normal daily activity and rest pattern (work/rest cycle) shall be scheduled.

  • 1    The humans are allowed to adjust the pattern specified in b according to their momentary needs.
  • 2    The scheduling of sleep is taking into account the:
  • circadian rhythm disturbances,
  • uncomfortable sleeping positions (microgravity),
  • headward redistribution of fluids (e.g. blood), and
  • space sickness/space adaptation syndrome.
    During space flights, measures shall be recorded on the sleep, alertness, fatigue, and cognitive performance of each crew member.

For an assessment of these effects on system and crew operations design, see Hancock, P.A. & Desmond, P.A. (ed.) (2001). Stress, Workload and Fatigue. , , Erlbaum Associates.

HFE requirements

General

The design of human-machine systems shall conform to the HCD process detailed in clause 4.4.

Requirements process

Functional high level human in the loop requirements shall be established for PRR within the system technical specification in conformance with ECSS-E-ST-10-06.
Final HFE requirements shall be established for SRR within the final system technical specification in conformance with ECSS-E-ST-10-06.

Instead of developing new requirements, the adoption of existing standards or document is a good practice. The list of standards and other documentation in Annex E can be used as reference.

HFE evaluation points, (e.g. Crew Station Reviews), shall be identified and inserted into the project design and development process and linked to the project reviews.

Details about project phases and reviews are provided in ECSS-M-ST-10.

Safety

The following safety related issues shall be characterised for on-board activities:

  • Mechanical Safety,
  • Electrical Safety,
  • Environmental Safety,
  • Operational Safety, and
  • Psycho-physiological Safety. Safety shall also characterise all mission related ground activities and possible cumulative effects on the users.

The General processes for hazard and safety analyses and control plans are listed in ECSSQST40.

Hardware ergonomics

To achieve the most effective overall system design, the following factors shall be characterised:

  • Anthropometrical characteristics of user population,
  • Human capabilities and skill,
  • Environment,
  • Tasks complexity and constraints and inherent or collateral physical stress that can be generated, and
  • Machine capabilities and autonomy level. Human-machine interface design shall provide:
  • Visual, audio or tactile cues and information on interface characteristics and task performance,
  • Interface customisation, and
  • Identification of safety related controls.

Environmental ergonomics

To create an environment that supports and maintains human health, safety and well-being all relevant functions and resources shall be provided as specified in ECSS-E-ST-34.
To create an environment that supports and maintains a positive psycho-sociological attitude of the on-board crew both as an individual and as group specific functions shall be identified according to the mission profile and resources and implemented.

To create an environment able to support human presence on-board it is important to define the habitability and aesthetic requirements according to the mission profile and resources. For social aspects family teleconferences are a good solution.

Cognitive ergonomics

To achieve the most effective overall system design, the following factors shall be characterised:

  • Human capabilities and knowledge profiles and boundaries,
  • Environment,
  • Tasks complexity and constraints and inherent or collateral stress that can be generated, and
  • Machine capabilities and autonomy level. The fit between human cognitive abilities and limitations for safety related data and controls shall be characterised.

Traditional aspects of software ergonomics are included in this clause and in clause 4.6.7.

Operations design ergonomics

The job design shall identify working hours, off-duty hours and rest days.
Physical exercise shall be counted as working hours.

  • 1    It is important that the design and development activities take into consideration the organisational environment aspects.
  • 2    For example when the design and development concerns a complete Human Space System, the existing organisation’s socio-technical characteristics of the infrastructure (e.g. Launch Facilities, Astronaut Training Centre, Ground Stations etc.) that is going to support the utilisation of the system itself it is important to be taken into consideration.

Crew systems

Overview

This clause is applicable to all systems to be used in missions that foresee participation of a human crew/explorer.

Habitable environments

The habitable pressurised environment design shall include:

  • living areas organisation,
  • human related equipment arrangement, and
  • harmonisation of compartments and crew stations. Additional items see from 4.7.3 up to 4.7.9 shall be present to complete the various living areas including, traffic flow and translation paths, hatches and doors.

Labels and cues

Labels and cues (i.e. location, orientation, identification, logistics and instructions) shall be provided for crewmembers to identify, interpret, follow procedures, or avoid hazards.
Labels and cues shall be provided as memory aids for the user.
The information conveyed by the label and cues shall be univocal and coherent and compliant with operations nomenclature.
Labels and cues shall be provided in all spacecraft areas regardless if crew operations (either nominal or contingency) are performed.

Architecture complements

Architecture complements specified in 4.7.4c shall be provided for all elements being part of a mission infrastructure that foresee the presence of human crew either in the pressurised or un-pressurised parts.

Architecture complements functions are provided according to the mission and functions of the human infrastructure.

It shall be demonstrated that the architecture complements include all items needed to complete the internal layout to make it habitable and suited for human utilisation.
The following architecture complements shall be included in the design of a pressurised spacecraft or habitat according to its mission duration and related constraints.

  • Mobility Aids: provided to support human movements.
  • Panels and Partitions: provided for flexibility in the organisation of the living areas.

For an orbital or habitation environment: to cover all volumes that are not considered primary living areas, to avoid free objects to drift in areas where their recovery by the on-board crew might be difficult.

  • Aesthetic complements and different colours schemes.
  • Crew restraint: provided for all pressurised and un-pressurised environments to restrain or support the crew member in their activities.
  • Mechanical restraint for loose objects: provided to enable the crew member to attach equipments and other loose items for task execution.
  • Ambient illumination, provided to support human presence both inside and outside the pressurised areas.
  • 1    It is important that ambient illumination is in line with the pressurised environment local orientation scheme.
  • 2    It is important that ambient illumination is designed accordingly with the pressurised area functions.
  • Complements for protection of the crew (e.g. radiation, touch temperature, hazardous atmosphere, sharp edges).

Components and provisions for crew stations

Crew stations shall be identified either inside or outside of a pressurised spacecraft according to its mission objectives, duration and related constraints.
Components and provisions shall be provided for areas defined as crew station according to the mission environments and the function(s) of the crew station itself.

  • 1    An analysis is the prime tool to show compliance to this requirement.
  • 2    Typical components of a crew station are the following:
  • Tools,
  • Illumination: compatible with the foreseen station activities and the ambient illumination of the area where the station is located,
  • Crew restrains and mobility aids,
  • Other fixed and portable restraints, and
  • Systems for access and/or interaction to information.
    Crew station layouts shall use the human body preferred posture according to the mission environment (0-g for on-orbit) as starting posture for operations connected to the station itself.
    Crew station layouts shall be designed to take advantage of the human body preferred attitudes and movement capabilities made possible by the specific mission environment.
    Environment respecting the requirements for human presence as per 4.2.1.6 shall be provided.

Work stations

All places where it is foreseen that the crew operates either for nominal or non nominal operations (maintenance) for periods exceeding one hour, or 30 minutes if the related task is recurrent, shall be defined as work station.
Work station shall be either outfitted with equipment (including lights) and tools (including restrains) to support the foreseen crew activities or shall be provided with the necessary restraints and hook points to enable their outfitting.
Analyses shall be performed and included into the design documentation to decide which of the below listed workstation shall be implemented and with which characteristics.

  • Element control and communication work station,
  • Maintenance and servicing work station,
  • Payload work station, and
  • Windows work station.

Off duty stations

Off duty station shall be implemented in one of the following way:

  • outfitted with equipment (including lights) and supports (including restrains) to enable the foreseen crew activities, or
  • provided with restraints and hook points to enable their outfitting.

All locations where it is foreseen that the crew operates during their off duty periods for periods exceeding one hour, or 30 minutes if the related task is recurrent, can be defined off duty station.

Analyses shall be performed and included into the design documentation to decide which of the below listed off duty workstations shall be implemented and with which characteristics.

  • Crew quarter and crew personal areas,
  • Galley/meeting centre,
  • Communication/leisure area/facility,
  • Body and teeth cleaning facility,
  • Toilet,
  • Shower,
  • Food preparation and storage facility, and
  • Washing facility.

Physical maintenance stations

The physical exercise facility to maintain crew health and well being shall be classified as a duty station.

Medical facilities and provisions

It shall be demonstrated that medical facilities and provisions including capability to handle specific illness or injuries shall satisfy the need for the number of crew members, mission duration and related mission constraints.
Analyses shall be performed and included into the design documentation to decide which of the below listed medical facilities and provisions shall be implemented and with which characteristics.

  • monitor and control crew health and well being,
  • monitor and treat one or more injured crew person,
  • monitor, isolate and treat one or more ill crew person,
  • quarantine one or more crew person, and
  • isolate/handle at least one or more deceased crew person.

Extra vehicular/planetary activity requirements and supports

When for a manned space infrastructure it is foreseen to use the on-board crew outside the spacecraft either for nominal or not nominal operations an extra vehicular activity (EVA) suit shall be provided for each crew member operating outside the spacecraft.
The limitation and constraint of the EVA suit shall be included in designing the spacecraft and habitat and its mission.
For external operations, the work station and exclusions zones or primary and secondary translation path shall be defined.
For external operations, following items shall be provided:

  • Crew and equipment restraints,
  • Crew and equipment mobility aids,
  • Illumination (both local and ambient), and
  • Labels and visual cues. Equipment, tools, restraints and mobility aids and any other systems that have to interface with the crew members wearing the EVA Suit shall be designed accordingly to their context of use.
    EVA Operations shall be defined analysing the impact of:
  • EVA suit design,
  • physiological constraints as specified in clause 4.5.
  • constraints related to airlock design (e.g. depressurization and re-pressurization performances), and
  • decompression sickness prevention. Analyses shall be performed and included into the design documentation to decide which of the below listed components shall be implemented and with which characteristics.
  • Tools and Equipment for external activities,
  • Airlock,
  • EVA Suit maintenance and servicing station,
  • Robotic support, and
  • Transportation system (Rovers). When an EVA is supported by a robot, the EVA crew shall have a direct override capability on the robot operations.

Informatics support

Context of use and task analysis shall determine the implementation for a given task.
Informatics applications containing an interface to a user shall be analysed, developed and evaluated as per clauses 4.4 and 4.6.6 above.

Information and requirements concerning software implementation are provided e.g. in ECSS-E-ST-40 and ECSS-Q-ST-80.

Operation products

Procedures

The operations plan including Operations procedures shall be established after SRR in conformance with ECSS-E-ST-70.
The requirements included in the document shall be applied independently from the selected procedure delivery media.
A board of stakeholders shall define and control the process (including validation) and products through the procedures life cycle.
Operations nomenclature shall be applicable to procedures and HMI development.

  • 1    For example it can include crew, safety, medical doctors and operations representatives.
  • 2    An example of procedure authoring guideline is the “Operations Data File Standards” (SSP 50253) established for the ISS Program.
  • 3    Apart from strictly manual instructions, a procedure can include dynamic elements, such as navigation buttons, data display fields, symbols, and/or command buttons.
  • 4    This clause 4.9.1 is applicable to mix initiative procedures (semi-automatic).

Cue cards

Cue cards shall be provided as reminder for tasks execution.
Cue cards shall be consistent with the related procedure(s).

  • 1    Any suitable media can be used as cue card according to the context of use.
  • 2    Cue cards are essentials of a procedure especially used for often occurring tasks, which can need only a general guide through a task for the crew onboard for execution.

Timeline

Boundary conditions, scheduled procedures usage, flight rules, medical and safety regulations shall be reflected in a timeline.
The timeline shall contain system and experiment operations, attitude and pointing, dataflow operations.
All resources and boundary conditions shall be compatible with the work/rest cycles of the crew as defined according to clause 4.5.4.
During the HFE process compatibility of the timelines (schedules) of the various teams (onboard, on ground) shall be demonstrated.

The timeline is the translation of requirements and constraints into a timely ordered, feasible sequence of events, which is executed and, if necessary, updated during the mission or flight increment.

Displays

The design of the display products shall comply with the output of the task analysis.

For example task analysis will determine if the main use of a display is of supervisory character, or of low-level manual reconfiguration type.

Clause 4.4 shall apply for display product development.
Displays and procedure development shall be coordinated.
The project specific operations nomenclature shall be used.

This includes labels, system messages, telemetry measurements and command names.

It shall be provided capability to ground users to have real time access to (at least) the identical display set available on the space segment.
A project specific display standard shall be developed prior the manufacturing of any displays.

  • 1    Instead of developing new standards, it is a good practice to adopt existing standards or documents.
  • 2    The display standard specifies a common ‘look and feel’ across the various display products to be developed.
  • 3    An example display standard is the “Display and Graphics Commonality Standards” (SSP 50313) established for the ISS Program.
    Symbol-set used for displays shall be common to that used for procedures and training material.

Training requirements

Training objectives and requirements for ground and flight personnel shall be established and specified.
Training requirements shall be developed in parallel with the design process.
Training curriculum and related training models and simulators shall be specified.

These are specified based on the previously established training objectives and requirements.

Continuous assessment instruments

Continuous assessment process

General

Stakeholders including users (or their representatives) shall assess the system being designed according to the human centred design approach.
Continuous assessment (iterative process) shall be supported by techniques of rapid prototyping.

Sample of rapid prototyping techniques are artistic impressions, moulding techniques to produce physical models and finally virtual or augmented environments

A continuous assessment plan (part of human-centred design process plan) shall be established.
The continuous assessment plan shall include the planned evaluation events (e.g. usability reviews).

The continuous assessment plan is normally implemented with the utilisation of concurrent design techniques and instruments (e.g. concurrent design facility).

The continuous assessment plan shall be maintained.

I.e. must include additional events not foreseen in the initial plan whenever a modification affecting the human vs. machine interfaces is being evaluated for implementation in the project.

After each evaluation event a report shall be issued.

Models and techniques used for the continuous assessment are important to be compatible with each project phase and the related size of the project.

The technique and the models used for the continuous assessment shall be analysed for their quality of representativeness before each assessment is made.
HFE continuous assessment process test report shall be prepared in conformance with Annex C.
The model used for the assessment shall be capable to be incrementally updated to represent the achieved definition of the system under evaluation.

This is aimed at avoiding project cost impact that can be caused by the implementation of the continuous assessment.

Assessment report principles, guidelines, measures and techniques

Table 41 provides an overview of human factors principles and techniques and the technological design space, applied in different stages (analysis, design, implementation and maintenance) of the continuous evaluation process. Techniques in italics shall be done always, whereas the other elements are recommended for more complex and/or critical systems.
Table 41: Overview of human factors principle and techniques

Development stage


Principles, guidelines and measures


Specification


techniques


Assessment


techniques


Technological design space


Task Analysis


procedures


HMI


support



task decomposition


task allocation


task features


data model, flows


scenarios, use cases


action sequences


User requirements


task load analysis


interaction analysis


User requirements validation



hardware


software


functional components



Prototype Design


procedures


HMI


accessibility


content


multimedia


navigation


control panel


speech


sketching


procedure structure


user interface structure


story-boarding


dialogue definition


graphics definition


prototyping


user interface requirements


expert review


user walkthrough


DHM


thinking aloud


constructive interaction


user test


user test in Space analogue environments


hardware


software


architecture


operation products


Prototype Implementation


effectiveness


efficiency


satisfaction


learnability



consistency check


final test


user feedback


algorithm design


coding


hardware development


operation products




Information acquisition techniques





focus groups


interview


questionnaire


observation


document analysis


comparative analysis


critical incidents


logging



Events

Usability review

Usability review for the human machine system operated by a user or users shall include:

  • Experts evaluation, and
  • Users’ evaluation. For complex and critical tasks human in the loop evaluation shall be conducted.

HFE shall take part in every project design review of equipment or systems in which a crewmember can be exposed or is foreseen to operate.

As design maturity evolves these are called crew station reviews (at different levels: payload, system) because they are defined and held with crew participation.

Project design reviews shall include functionality demonstrations and fit checks of all equipment (e.g. connectors), accessibility checks, and the operability (labelling, intermediate stowage) of the equipment to be used.

In order to ensure a hardware design which organically incorporates the HFE requirements, the very early instrument for implementation is the requirements reviews (PRR and SRR).

The specifications presented in the project design reviews shall show that all relevant HFE requirements have been incorporated.
At PDR it shall be demonstrated that the design is compliant with HFE requirements.

As a minimum these aspects of the system and its components must be taken into account:

  • Size (e.g. distances of connectors, access space for hands and tools),
  • Shape (e.g. big corner radii, position of required handles, interface requirements to surrounding systems),
  • Draft User Manuals,
  • Operation nomenclature compliances,
  • Installation and test procedures for AIT processing,
  • Positions of displays, labels, connectors, switches and knobs,
  • Illumination,
  • Noise,
  • Design for hardware replacement, maintenance and servicing,
  • Safety, and
  • Fields of view. At CDR it shall be demonstrated that all HFE design requirements are implemented.
    The last Crew Station Review shall take place before or be connected with QR.

This is to also ensure multiple or interconnected functional performance requirements verification.

Crew station reviews

The human-centred design process plan mentioned in 4.4.2 shall include Crew Station Reviews (CSR).
Every hardware and software item and their combination, with crew interfaces shall be subject of at least one CSR.
The CSR shall include the crew foreseen to operate the equipment or a crew familiar with the operational environment.

(Whole) System simulations

Whole System Simulations shall be included in the System Engineering Plan.

  • 1    In order to avoid so called “human errors” and regardless if Phase C/D and Phase E are in two separated contracts several Whole System Simulations must be held when the flight segment is operatively tested/verified with the ground segment and with the users that are operating them.
  • 2    The purpose of Whole System Simulations is also to verify achievement of high level human in the loop requirements together with timeline and other ops products feasibility considerations and communication verification

Tools

General

An assessment of the fidelity of the tool representation shall be made.
This assessment shall be used in the evaluation of the results.

Simulation tools

Utilisation of simulation tools (e.g. Virtual Reality – Virtual Environments (VR/VE) techniques, including Augmented Reality or Mixed Reality) shall be considered for analyses and assessment support in the Human Centred Design process plan.

Development tests

Hardware or software used for development testing shall be of representative fidelity for the part or aspect that is under test.
All the related affecting environment characteristics that have influence on the test results shall be of representative fidelity.
Fidelity of representation of equipment or operational tools and approaches under test and their related test environments shall be included in the test report.
HFE test reports shall be prepared according to the DRD in Annex D.

Space analogues development tests (NBF and PF)

Development test of local human machine interfaces and equipment assembling shall be performed.
According to the level of representativeness required by the characteristics of the task being tested either space analogues facilities (NBF and PF), or software simulations (e.g. test with an electronic mannequin) shall be used for development tests.
For final development evaluation and qualification purposes tests which simulate the 0-g environment and limitations of IVA and EVA space suits shall be performed for:

  • Full human body action,
  • Handling of one or more of the following: Removable and portable entire units,

Units with large volumes (≥0,03 m³),

Units with unmanageable shape.

  • Operations within restricted areas/volumes,
  • Operations with time constraints under above circumstances. The selection of the space analogues environment shall be done between Neutral Buoyancy Facilities (NBF) and Parabolic Fights (PF).
  • 1    The choice is generally based on the capability of the environment used in representing the real utilisation environment, both in term of dimensions and crew task duration. PF are usually capable to provide representative “zero-g” environment for around 20 seconds (depending from the airplane characteristics and profile of the selected trajectory). Longer crew tasks that cannot be subdivided in elementary tasks are generally tested using the NBF.
  • 2    During NBF tests, it is important to consider the significantly increased movement resistance caused by the water on the crew members, and on voluminous and plate items that they can be used to operate.
    Data collection techniques used during NBF or PF tests shall include as a minimum video, still camera.
    HFE test reports shall be prepared in conformance with Annex D.

Consensus report

A human-machine system assessment shall be documented in a consensus report.

A consensus report can address a specific part or the whole human machine system.

The fidelity of the environment, simulators and products used shall be documented in the consensus report.
Users or their nominated representatives shall sign-off a consensus report.

A minimum of three signatures is recommended. This report may include a minority comments.

Verification methods requirements

Overview

The verification methods as described in clauses 4.1, 4.2 and 4.3 of ECSSEST10-02 are integrated accordingly to what is described from clauses 4.11.2 to 4.11.4. When there is no mention to a verification method the ECSSEST-10-02 method is to be applied as is described in the mentioned document. The clauses included here are complementing the continuous assessment instrument described in clause 4.10 and are to be used when the human is involved.

The modifications and detailed explanations of the methods of verification to be applied to respect special HFE needs are presented with consideration of the principles given in clauses 4.1, 4.2 and 4.3 of ECSS-E-ST-10-02.

This clause gives an appropriate interpretation of the "classical" formulation in light of the HFE verification peculiarities.

Analysis and similarity

Overview

For verification of HFE requirements analyses are the preferred methods.

Analysis techniques for verification of requirements can typically include computer simulations, statistics, qualitative analyses, and analogous modelling.

As verification by analysis or similarity for HFE requirements the following methods can be applied e.g.

Simulation with digital human model (DHM),

Other computer aided simulation,

Provision of astronauts flight experiences.

HFE analysis and simulation report

HFE analysis and simulation reports shall be prepared in conformance with Annex B.

Digital human model (DHM)

When DHM are use for verification purposes, a Digital Mock-Up shall be used in conjunction to represent the context of use and the environment.

Ground HFE test

General

For testing on ground an assessment of the gravity effects shall be performed.

  • 1    Ground HFE Test with human subjects is considered representative only when effect of gravity have limited influence or when ground simulation using zero-gravity space analogue environments (NBF or PF) typical limitations (water resistance and buoyancy of objects and subjects for NBF and time limitations for the PF) have limited influence on the test objectives.
  • 2    NBF and PF test are considered ground HFE tests.

HFE demonstration

HFE demonstrations shall be used as formal verification event for some HFE related requirements. They are of two types:

  • Not user population representative: too few test subjects for an ergonomic review, and
  • Not representative environment: the environment used for the demonstration is not representative of the real environment of use. HFE demonstrations shall be used only when there are available analyses, simulations or development tests that can be integrated into the results of the demonstration.
    The HFE demonstrations shall be used to verify conformity to the HFE requirements in terms of habitability, usability and maintainability of the human-machine system.
  • 1    Usability/Crew Work Station Reviews are normally used in the evaluation of the HFE Demonstration.
  • 2    The insertion of "demonstration" as a separate event is complementary to the verification method “demonstration” as defined in ECSSE-ST-10-02.

System simulations

The system simulation events shall be used to close out high level human machine system requirements.

  • 1    The system simulation events can be used to close human in the loop requirements such as timeline feasibility considerations and communication verification.
  • 2    This is when a space human-machine system is tested in its full operational environment (using flight hardware, related supporting simulators, operations products, its ground segment, crew – if any – and operation personnel).
  • 3    Simulations on different levels are also used to train and certify the different teams (users) involved in a mission and to verify and validate their performance and interaction for a specific mission. This comprises especially operational communication and operational products (onboard and ground procedures, timeline, command databases, etc.) across the whole system or selected parts of it.

ANNEX(normative)HCD process plan - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-10-11, requirement 4.4.2a.

Purpose and objective

The HCD process plan defines the approach, methods, procedures, resources and organization for the integration of the human in the loop for space system products.

Expected response

Scope and content

Introduction

The HCD process plan shall contain a description of the purpose, objective, content and the reason of prompting its preparation. More specifically it shall identify the human in the loop roles that originate the need for such a plan.
Applicable and reference documents

The HCD process plan shall list the applicable and reference documents to support the generation of the document.
Terms and definitions, abbreviated terms and symbols

The HCD process plan shall include any additional definition, abbreviation or symbol used.
Elements of the plan

The HCD process plan shall complement the system plans identify the major steps for the integration of the human in the loop.
More specifically this plan shall specify how the following issues are approached and specify their relation especially regarding their schedule with the system development actions as detailed in the other system plans:

  • Definition of user populations
  • Identification of the organisational environment related to the system being developed.
  • Identification of Stakeholders.
  • Identifications of the operational concept, and associated communication and decision lines within the system.
  • List the results of the Human vs. Automated Trade-off (performed in the project feasibility phase) with the identification of the major tasks assigned to the human part of the system.
  • Among the tasks identified in 4. identification of complex or critical human tasks and related scenarios definition.
  • Definition of the physical and psycho-physiological environments.
  • Definition of the context of use for the various components of the system that foresees a human interaction.
  • Establishment of the evaluation approach and related continuous assessment plan and reviews with the identification of the schedule and content for the:
    • Crew station reviews (CSR).
    • System simulations.

At these events it is expected that the status of the planned HFE analysis and simulation and test reports are reviewed.

  • Define the flight Crew Systems (if any) design and development plan.
  • Establish the final Demonstrations and Verification Approach for the human in the loop related requirements.
  • Related to point 10. definition of the time frame for analytical /simulation and test verification.
  • Related to point 10. definition of the location(s) and responsibilities for verification implementation (either analytical or test).

Special remarks

The HCD process plan when part of the System Engineering Plan shall maintain its integrity and not be separated throughout the various different system plans.
The HCD process plan shall consider all human in the loop issues for the space system project regardless if it concerns the space segment or its ground infrastructure.
Any requirements contained in this standard intentionally not taken into account shall be rationalised in this plan.

ANNEX(normative)HFE analysis and simulation report - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-10-11, requirement 4.11.2.2a

Purpose and objective

The HFE analysis and simulation report defines the scope, methods, procedures, resources and organization for the performance of HFE analyses and for the related simulations especially when using the DHM and the DMU.

The contents listed below are applicable to all parts of the report itself, i.e. it can be used as environment to develop procedures for the real description of the actual verification methods, tools, steps such that the goal of the verification is never forgotten during the verification itself.

Expected response

Scope and content

Introduction

The HFE analysis and simulation report shall contain a description of the scope, purpose, objective, content and the reason of prompting its preparation.
Applicable and reference documents

The HFE analysis and simulation report shall list the applicable and reference documents to support the generation of the document.
Terms and definitions, abbreviated terms and symbols

The HFE analysis and simulation report shall include any additional definition, abbreviation or symbol used.
Elements of the document

The HFE analysis and simulation report shall contain the following elements:

  • Reference to the relevant requirements.
  • Description of the reason for and objectives of the analysis.
  • Identification of the user population and definition of their related characteristics that are applicable to the role the user(s) is (are) playing in the analysis and/or simulation.
  • Identification of the environments (e.g. physical, organisational, psycho-physiological) related to the part under analysis.
  • Identification of the context of use (scenario) for the object (e.g. interface, software) or activity under analysis.
  • Presentation of the analysis and simulation approach used.
  • Description of the applicable simulated test article and/or human/machine interface or activity.
  • List of input assumptions, e.g. operational status of simulated test objects.
  • Description of the input data used with reference to the source of the data.
  • Description of the analytical/simulation tools used and, if applicable, indication about nodal break down.
  • Assessment of the representativeness of the analysis/simulation related to the simulation tools hard/software used.
  • As far as hardware or software item of the system under development is used in the simulation the following issues shall be included:
    • A list of the human interfaces taken into account.
    • Description of applicable human interfaces with respect to physical characteristics (such as surface temperature, roughness, other tactile properties, sensitivity to mechanical loads), or to cognitive aspects (e.g. colours, type of menus).
    • Description of the identified, possible, interrelating effects between physical and cognitive aspects.
    • Description of the predictions made on the affecting properties towards the item and the human in the loop.
    • Description of the results of a sensitivity analysis for the interface data, performed to assess the modelling and simulation uncertainties.
  • Description of the analysis and simulation performance with details on the analytical steps, performance evaluation criteria, pass/fail criteria.
  • Conclusions and recommendations with respect to the item technical baseline, its operations manual and related operation products.
  • Description and assessment of the impact on the baseline design of the item under analysis and on the handling and performance of the other related items that are part of the system or subsystem and that may be affected by the results of the analysis (this include for example training materials, ground infrastructures).

Special remarks

The HFE analysis and simulation report is applicable to the analyses and simulations presented for the verification process of human in the loop related requirements but it is suggested to use a very similar structure for the analyses and simulations performed during the development phase and reissue the same document with the proper conclusions as final verification report.

ANNEX(normative)HFE continuous assessment process report - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-10-11, requirement 4.10.1.1h.

Purpose and objective

The HFE continuous assessment process report collects the results of the implementation of the HCD process plan (specifically the synthesis of the DRDs of ECSS-E-ST-10-11, Annex B and Annex D is included) in the various stages of the process.

Expected response

Scope and content

The HFE continuous assessment process report shall be the primary tool to control the implementation of the HCD process plan.
The HFE continuous assessment process report shall provide the information presented in the following clauses:
Introduction

The HFE continuous assessment process report shall contain a description of the purpose, objective, content and the reason of prompting its preparation.
Applicable and reference documents

The HFE continuous assessment process report shall list the applicable and reference documents to support the generation of the document.
Terms and definitions, abbreviated terms and symbols

The HFE continuous assessment process report shall include any additional definition, abbreviation or symbol used.
Elements of the report

The HFE continuous assessment process report shall include according to the stage of the project and the activities performed in the phase the item listed below.

  • Definition of user populations.
  • Identification of Stakeholders.
  • List of the reports prepared and under preparation and their status.
  • List the Crew Systems components being evaluated and how.
  • List of the analyses and simulation performed.
  • List of the tests performed, for the tests the following items shall be included:
    • Description of the purpose of the test and of the equipment/software packages or operation item being tested.
    • Test subjects characteristics (including the training performed).
    • Test plan and procedures used.
    • Representativeness of the test environment (both physical and psycho-physiological) and of the equipment/software (either subject of the test or for support) used for the test (representativeness analysis).
    • Context of use for the items being tested.
    • Definition of used depended and independent variables and their validity with respect to the objectives of the test and the pass/fail criteria.
    • Definition of the methods used to collect the results.
    • Definition of the methods used to analyse the results and their sensitivity to the aim of the test.
    • Test implementation and discussion of the related validation results.
  • List the evaluation events performed in the period of the report.
    • Crew station reviews (CSR),
    • System simulations.

Special remarks

The HFE continuous assessment process report is part of the documents prepared for the system project events. It shall be established once and then updated in the subsequent events.

ANNEX(normative)HFE test report - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-10-11, requirements 4.10.3.3d and 4.10.3.4f.

Purpose and objective

The HFE test report collects the results of a test where human subjects are used to evaluate the proposed solution either during the development or verification phase.

Expected response

Scope and content

Introduction

The HFE test report shall contain a description of the purpose, objective, content and the reason of prompting its preparation.
Applicable and reference documents

The HFE test report shall list the applicable and reference documents to support the generation of the document.
Terms and definitions, abbreviated terms and symbols

The HFE test report shall include any additional definition, abbreviation or symbol used.
Elements of the report

The HFE test report shall include according to the stage of the project and the test activities performed in the phase the item listed below:

  • Definition of user populations used for the test and their representativeness w.r.t. the real user population as described in the HCD process plan.
  • Identification of Stakeholders (or confirmation of those defined in the HCD process plan).
  • List the systems components being evaluated and how.
  • Assessment of differences between test hardware and design baseline (based on CIDL).
  • List of the applicable requirements being tested against the design solution or the design to be verified.
  • List and results of the support analyses and simulation performed to define the subject of the test.
  • Test plan (expected) with the definition of locations and responsibilities for test performance and timelines.
  • Test procedures for both test subjects and test conductors and evaluators.
  • Special provisions (if any) adopted to reduce the number of depended variables, i.e. test subject training, subjects selection etc.
  • Tools used to collect the results of the human testing (e.g. questionnaires, video) and the related data analysis instruments.
  • Test results including stakeholder consensus report.

Special remarks

The HFE development test report can be used in the verification campaign as verification test report combined with some dedicated analysis, simulation or demonstration aimed at compensating for a used test item not necessarily identical to the final solution being adopted in the design to be verified.
The HFE verification test report is part of the documents prepared for the system project test verification campaigns.

ANNEX(informative)Related ISO and other European standards

ISO – 13407 – 1999 - Human-centred design processes for interactive systems

ISO – 9241

  • ISO 9241-1:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 1: General introduction.
  • ISO 9241-1:1997/Amd 1:2001.
  • ISO 9241-2:1992 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 2: Guidance on task requirements.
  • ISO 9241-3:1992 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 3: Visual display requirements
  • ISO 9241-3:1992/Amd 1:2000.
  • ISO 9241-4:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 4: Keyboard requirements.
  • ISO 9241-4:1998/Cor 1:2000
  • ISO 9241-5:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 5: Workstation layout and postural requirements.
  • ISO 9241-6:1999 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 6: Guidance on the work environment.
  • ISO 9241-7:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 7: Requirements for display with reflections.
  • ISO 9241-8:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 8: Requirements for displayed colours.
  • ISO 9241-9:2000 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 9: Requirements for non-keyboard input devices.
  • ISO 9241-10:1996 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 10: Dialogue principles.
  • ISO 9241-11:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability.
  • ISO 9241-12:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 12: Presentation of information.
  • ISO 9241-13:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 13: User guidance.
  • ISO 9241-14:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 14: Menu dialogues.
  • ISO 9241-15:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 15: Command dialogues.
  • ISO 9241-16:1999 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 16: Direct manipulation dialogues.
  • ISO 9241-17:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 17: Form filling dialogues. ISO 1996: Acoustics - Description, measurement and assessment of environmental noise

ISO 1999:1990 Acoustics - Determination of occupational noise exposure and estimation of noise-induced hearing impairment.

ISO 5807:1985 Information processing - Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts.

ISO 6385:2004 Ergonomic principles in the design of work systems.

ISO/IEC 6592:2000 Information technology - Guidelines for the documentation of computer-based application systems (available in English only).

ISO 7250:1996 Basic human body measurements for technological design.

ISO 7731:2003 Ergonomics - Danger signals for public and work areas - Auditory danger signals.

ISO/CIE 8995:2002 Lighting of indoor work places (available in English only).

ISO 9186:2001 Graphical symbols - Test methods for judged comprehensibility and for comprehension.

ISO 9355

  • ISO 9355-1:1999 Ergonomic requirements for the design of displays and control actuators - Part 1: Human interactions with displays and control actuators.
  • ISO 9355-2:1999 Ergonomic requirements for the design of displays and control actuators - Part 2: Displays. ISO 9921:2003 Ergonomics - Assessment of speech communication.

ISO 10015:1999 Quality management - Guidelines for training.

ISO 10075

ISO 10075:1991 Ergonomic principles related to mental work-load - General terms and definitions.

ISO 10075-2:1996 Ergonomic principles related to mental workload - Part 2: Design principles.

ISO 11064

  • ISO 11064-1:2000 Ergonomic design of control centres - Part 1: Principles for the design of control centres.
  • ISO 11064-2:2000 Ergonomic design of control centres - Part 2: Principles for the arrangement of control suites.
  • ISO 11064-3:1999 Ergonomic design of control centres - Part 3: Control room layout
  • ISO 11064-3:1999/Cor 1:2002. ISO 11226:2000 Ergonomics - Evaluation of static working postures.

ISO 11228

ISO 11228-1:2003 Ergonomics - Manual handling - Part 1: Lifting and carrying

ISO 11399:1995 Ergonomics of the thermal environment - Principles and application of relevant International Standards.

ISO 11428:1996 Ergonomics - Visual danger signals - General requirements, design and testing.

ISO 11429:1996 Ergonomics - System of auditory and visual danger and information signals.

ISO 13406

  • ISO 13406-1:1999 Ergonomic requirements for work with visual displays based on flat panels - Part 1: Introduction.
  • ISO 13406-2:2001 Ergonomic requirements for work with visual displays based on flat panels - Part 2: Ergonomic requirements for flat panel displays. ISO 13688:1998 Protective clothing - General requirements.

ISO/IEC 14756:1999 Information technology - Measurement and rating of performance of computer-based software systems (available in English only).

ISO 14915

  • ISO 14915-1:2002 Software ergonomics for multimedia user interfaces - Part 1: Design principles and framework.
  • ISO 14915-2:2003 Software ergonomics for multimedia user interfaces - Part 2: Multimedia navigation and control.
  • ISO 14915-3:2002 Software ergonomics for multimedia user interfaces - Part 3: Media selection and combination. ISO/IEC 15411:1999 Information technology - Segmented keyboard layouts (available in English only).

ISO 15534

  • ISO 15534-1:2000 Ergonomic design for the safety of machinery - Part 1: Principles for determining the dimensions required for openings for whole-body access into machinery (available in English only).
  • ISO 15534-2:2000 Ergonomic design for the safety of machinery - Part 2: Principles for determining the dimensions required for access openings (available in English only).
  • ISO 15534-3:2000 Ergonomic design for the safety of machinery - Part 3: Anthropometric data (available in English only). ISO 15535:2003 General requirements for establishing anthropometric databases.

ISO/DIS 15536: Ergonomics - computer manikins and body templates.

ISO/IEC 16022:2000 Information technology - International symbology specification - Data Matrix (available in English only).

ISO/TS 16071:2003 Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces

ISO/TR 16982:2002 Ergonomics of human-system interaction - Usability methods supporting human-centred design.

ISO/PAS 18152:2003 Ergonomics of human-system interaction - Specification for the process assessment of human-system issues (available in English only).

ISO/TR 18529:2000 Ergonomics - Ergonomics of human-system interaction - Human-centred lifecycle process descriptions (available in English only).

ISO/TR 19358:2002 Ergonomics - Construction and application of tests for speech technology (available in English only)

ISO/IEC 18019:2004 Software and system engineering - Guidelines for the design and preparation of user documentation for application software (available in English only).

ISO/IEC 18035:2003 Information technology - Icon symbols and functions for controlling multimedia software applications (available in English only).

ISO 81714

  • ISO 81714-1:1999 Design of graphical symbols for use in the technical documentation of products - Part 1: Basic rules.
  • IEC 81714-2:1998 Design of graphical symbols for use in the technical documentation of products - Part 2: Specification for graphical symbols in a computer sensible form, including graphical symbols for a reference library, and requirements for their interchange. EN 1005-4 “Safety of machinery – Human physical performance – Part 4: Evaluation of working postures and movements in relation to machinery (17 February 2005).

Bibliography

ECSS-S-ST-00


ECSS system – Description implementation and general requirements


ECSS-E-ST-10


Space engineering – System engineering general requirements


ECSS-E-ST-10-02


Space engineering – Verification


ECSS-E-ST-34


Space engineering – Environmental control and life support (ECLS)


ECSS-E-ST-40


Space engineering – Software general requirements


ECSS-M-ST-10


Space project management – Project planning and implementation


ECSS-Q-ST-40


Space product assurance — Safety


ECSS-Q-ST-80


Space product assurance – Software product assurance


ISO STD 13407:1999


Human-centred design processes for interactive systems