Modelling the Human Factor into the Design Process

Effective human factors integration can reduce project delivery costs, avoid the need for expensive retro fits or redesigns, and ensure an enhanced user experience. The Australian standard for human factors integration in engineering design, 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”.

The question is, what is adequate?

Human factors integration, in essence, works to reconcile the top-down nature of systems engineering with the iterative nature of a user-centred design approach. It is often managed by creating a Human Factors Integration Plan (HFIP) that sits alongside or underneath the Systems 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. In addition to the principles involved, the HFIP should also 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). Again, like the RISSB standard, it provides guidance on integration. The human factors practitioner needs to integrate human factors by 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 an acceptable application of the standard.

 

Ensuring Effective Integration 

When it comes to delivering effective human factors support for complex projects, integration must go beyond the application of a standard, or compliance with rail safety law. Human factors is often considered to be a process-driven discipline within the development of safety critical systems; however, just being part of the process does not necessarily mean that the discipline has been successfully integrated into the project.

To ensure successful integration, an HF practitioner must choose the most effective method of providing guidance in line with the relevant standards. For Acmena, combining the human factors with the systems engineering and safety assurance programs though the use of a Model Based Systems Engineering (MBSE) framework, has proven to be one of the most effective integration methods for large-scale projects.

 

The MBSE Approach

At Acmena, we consider the user to be part of the system. In this user-centred approach the HFIP, which governs the human factors program, has a direct relationship to the SEMP. In turn, 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 uses 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 definition is reflected in the Acmena approach for human factors integration in Figure 1.

 

Modelling the Human Factor 

Adopting an MBSE approach to better integrate human factors with systems design to include the user in the system makes it 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 ensures, most importantly, the activities contained in the HFIP are not conducted in isolation, but are captured as dependencies to the system under development (SUD), putting the user at the centre of the design process.

An Example

Consider the operational scenario, or a visual representation of one, as shown in a flow block diagram (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.

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.

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? 

Underpinning human factors integration activities with an MBSE framework developed from concept to the design phase is an approach Acmena is currently implementing on rail projects in Australia. It is also a topic we will be presenting on at the 2021 RSSB International Human Factors in Rail Conference.

As shown in Figure 1, the task analysis can be a key activity in human factors integration and will continue to develop with the evolving operations and maintenance concepts in the model, which represents the single source of truth for the project. A task analysis, derived from the model, is central to successful human factors integration on projects. It is part of the operational integration critical path, with multiple activities and dependencies associated.

The model enables the human factors team to coordinate stakeholder and end user engagement into the project single source of truth.

This also supports usability assessments, operating and support hazard analyses, verification and validation testing, operational testing, and the competency and learning program.

The use of a common model and the human factors artefacts 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 also enables the stakeholders, who may not be familiar with the 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 also provides an effective method of capturing information and focusing 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 teams involved in the innovative advancement of a systems engineering framework on major rail systems projects, 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 current projects 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. Through the detailed design, systems integration testing and operational testing that will be conducted over the next few years, we fully expect to see the benefits of this approach become evident through all phases of Acmena’s current projects.

 

Daniel Simmons | Principal Consultant

 

Related Content: Model Based Systems Engineering