Modelling the Human Factor into the Design Process

Effective human factors integration can reduce project delivery costs, avoid retro fit or redesign and ensure an enhanced user experience. The human factors integration in engineering design standard in Australia, as defined by the Rail Industry Safety and Standards Board (RISSB) states, “Adequate integration of Human Factors in all phases of a system’s development lifecycle ensures its safety, performance and fitness for purpose”. So begs the question, what is adequate?

Human factors integration, in essence, tries to reconcile the top-down nature of system engineering with the iterative nature of a user-centred design approach (e.g. ISO 6385 or ISO 9241-210). It is often managed by creating a Human Factors Integration Plan (HFIP) that sits alongside or underneath the System Engineering Management Plan (SEMP). The purpose of the HFIP is to define how the human factors engineering activities necessary for the successful delivery of a system will be conducted.

The HFIP establishes the guiding principles to be followed by the project to implement the most appropriate human factors methods. As well as the principles involved, the HFIP should describe the organisation, processes and controls necessary over the entire lifecycle of the system, from the concept phase through to decommissioning.

The initial activity to be conducted in developing the HFIP is the Early Human Factors Analysis (EHFA) or as more commonly known within the Sydney Rail Network, the Human Factors Work Determination (HFWD). Again, like the RISSB standard, it provides guidance on integration. The human factors practitioner needs to adequately integrate human factors through delivering guidance that can be utilised by a design team during the design of a system, engaging all stakeholders to ensure a safe and usable outcome. It is the client organisation’s part to ensure that this is adequate.

It is no wonder that human factors is often a very process-driven discipline within the development of a safety critical system. But, being part of the process, can often be a pinch point deliverable, and does not necessarily mean integration. There is an opportunity here for the practitioner to consider how to use the guidance available alongside the standards to achieve the integration of human factors.

The presence of human factors professionals in the design process is not enough. Integration goes beyond the application of a standard or compliance with rail safety law. Acmena utilise a best for project approach, combing systems engineering, safety assurance and human factors under a Model Based Systems Engineering (MBSE) framework. Adopting this approach ensures human factors is integrated into a project effectively.

 

The Approach

A human factors program of work is governed by its management plan, the HFIP. At Acmena we consider the user as part of the system, and therefore a direct relationship to the SEMP. The SEMP defines the systems engineering framework to be applied, and how the tools and artefacts of the system will be managed.

Figure 1 graphically represents the model-based approach Acmena is using on rail projects in Australia, with Model Based Systems Engineering being defined by The International Council of Systems Engineering (INCOSE) as: “The formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” INCOSE-TP-2004-004-02, Sep 2007). This is reflected in the Acmena approach for HFI in Figure 1.

 

Figure 1

 

Modelling the Human Factor 

Adopting a MBSE approach to better integrate human factors with systems design to include the user in the system was investigated, and it became apparent it was possible to use the functionality of a model to derive task level detail and link to both the configuration of the future Human Machine Interface (HMI) and the Human Factors Issues Register (HFIR). This ensured, most importantly, the activities contained in the HFIP were not conducted in isolation, but were captured as dependencies to the system under development (SUD), putting the user at the centre of the design process.

 

An Example

Consider an operational scenario, or a visual representation of one – a flow block diagram shown in Figure 2. In this example the system under design is a coffee pod machine, within the operational scenario of making a coffee. The white blocks represent functions, or the building blocks of a scenario. These are for both the system and the user. User functions are part of the operational scenarios.

 

Figure 2

 

The user functions in the model are the basis of the user interaction requirements for the future system. As human factors professionals we must ask ourselves, how should the system support the user? These user interaction requirements are detailed within the documents that comprise them, User Interface Specifications. Using the “making a coffee” example, the user interaction requirements would be under “Human to Pod Machine”. The pod machine represents the system under design. How must the pod machine support the user at each step? Depending on the type of project or system, this could form the basis of formative usability assessments (shown in Figure 2), wire framing what information the user needs and how it could be represented.

Each function is assessed for how the system should support the user. In Figure 2 the function “fill and turn on pod machine” represents a user interaction with the system. Written as a requirement and supported by a task analysis, this task breakdown is used to support project activities such as usability assessments to configure the system under design for the needs of the user.

The task analysis is derived from each user function in the model. The human factors team therefore perform an iterative approach, taking the functions to task level detail, and in turn identifying whether the functions support the task level breakdown. If they do not, the human factors team and systems engineering teams work together to ensure the functional flow block diagrams satisfy how the design for the system needs to be updated.

Deriving the task analysis from the model enables an automatic test script for usability assessments. This enables operational representatives, test engineers and front-line staff to understand how the system should support the user.

This innovative modelling approach ensures:

  • A system of systems approach for better whole of life outcomes.
  • A visual relationship between people, process and technology.
  • An aid for stakeholder and front-line staff engagement throughout each phase of the project.
  • A source of knowledge and information collated as a single source of truth.

 

What are the Benefits of a Model-Based Approach? 

This approach represents human factors integration activities based on an MBSE framework developed from concept to design phase. We are currently implementing approach this on railway projects in Australia and will be presenting on it at the RSSB International Human Factors in Rail Conference this year.

The task analysis will continue to develop with the evolving operations and maintenance concepts in the model. A task analysis, derived from the single source of truth, is central to the human factors integration on the project. It is part of the operational integration critical path, with multiple activities and dependencies associated.

The model has enabled the human factors team to coordinate stakeholder and end user engagement into the project single source of truth. This will support usability assessments, verification and validation testing, operational testing and support the competency and learning program.

The use of a common model and the human factors artifacts generated from it means the communication between the human factors team and the stakeholders is mediated not by a systems engineering team, but by the model itself as a common point of reference.

The modelling approach can provide a common language for all the teams involved in a project. The model enables the stakeholders who may not be familiar with the proposed new system to understand how the task analysis has been derived without long descriptions. The context is provided by the functional block diagrams, and many of the human factors deliverables are derived from the model.

In our experience, the use of modelling has helped to integrate the human factors team more effectively within the systems engineering team, assisting in both communication and understanding of technical differences and commonalities. The model provides an effective method of capturing information and focussing discussions where the user to system and user to user interfaces do not initially form an accurate flow of events.

The use of this process has seen Acmena’s HF team involved in an innovative advancement of a system engineering framework on a major rail systems project, which has gone some way to bridging the language barriers that exist within multidisciplinary and multicultural design teams.

 

Summary 

This paper outlines a project example of human factors integration into Model Based Systems Engineering. This approach is based on a current project from the concept and preliminary design phase, which are fundamental phases of a human factors program of work, as we are so often restricted to retrofitting design roles after the event. The system is scheduled to go live in 2023. Through the detailed design, systems integration testing and operational testing conducted over the next two years, we fully expect to see the benefits of this approach, and the successful integration of human factors, become evident through all phases of the project.

 

Daniel Simmons | Principal Consultant 

 

Related Content: To MBSE or not to MBSE?

Expertise

Human Factors

Systems Engineering

For more information