Systems integration theory and fundamentals

Abstract

Systems integration is a major challenge across many disciplines, with a large number of technical, project, organisational or environmental problems occurring as a result of improper integration. This article highlights the scope of the challenges facing systems integration and explains why it requires the incorporation of both technical and non-technical domains. Humans, systems and the environment, as well as the interactions among them, significantly contribute to the proper integration of systems. These, however, have been formulated differently across different engineering disciplines. For example, systems engineering considers the human to be part of the system, while railway engineering considers the human to be part of the system environment. This paper explores the fundamentals of integration and lays a theoretical foundation for the integration of systems. It will introduce Safety Cube theory to outline these fundamental aspects of system integration. Example applications are provided at the end of the paper.

Keywords:

• System integration
• safe integration
• integration engineering

1. Introduction

People demand products, systems, or services (PSS) to fulfil their needs. These PPS must function well and perform the tasks required. Furthermore, they should not harm people, or damage their property or the environment. The expectation is that products and services will be able to easily integrate with the related environment and deliver optimal performances. For example, people expect IoT devices to effortlessly connect to the internet, seamlessly communicate with each other and to exchange data at the expected rate. These devices, however, must not be controlled by unauthorised parties or send data to them. The satisfaction of these needs is a fundamental economic driver, which may provide great competitive advantage for different industries.

Harmonious integration creates a unique selling point for businesses. For example, Apple is aware of the importance of seamless integration between its products, aiming to deliver the ultimate user experience. In fact, smooth integration is a prerequisite in modern society. In other words, societies need products and services that can be used effortlessly in the appropriate context. Examples of the need for integration can be found across different disciplines and industries. Augmented Reality and its integration with human life in the form of cameras, wearables, games or educational products reminds us of the need for the integration of technology with everyday life. Artificial Intelligence and machine learning are other examples of technology being used to facilitate higher capabilities and better performance (Rajabalinejad, 2018a).

The optimal integration of products with everyday life faces numerous challenges due to the high pace of technological advancement and the dynamic needs of the environment across the full system lifecycle. Systems must remain fit for purpose and adapt their services according to their environmental dynamics. The optimal integration of new technology with operational systems is becoming increasingly important, with resilient services increasingly demanded (Wied, Oehmen, & Welo, 2020).

Failure to achieve proper integration creates risks and wastes valuable resources. The improper integration of new systems may expose stakeholders to additional costs, lead to suboptimal services, waste scarce resources, harm people, damage assets, or even damage other systems or the environment. Suboptimal integration often leads to the redesign and reengineering of products or services, which can become very expensive if problems are recognised too late, for example in the operational phase or at the end of a project lifecycle. A survey conducted by the Standish Group revealed that risk mitigation during the operational phase may be up to 30 times more expensive than risk management in early design phases (Bijan, Yu, Stracener, & Woods, 2013). Brombacher showed that a high percentage of consumer electronic products are returned to the manufacturer without any fault, primarily because of issues concerning their integration with human life or the environment (Brombacher, 1999).

Engineers must be aware of this need to overcome the integration challenges and deliver the services demanded. They need to design for integration because it ensures that the products are modular, reusable, upgradable, context aware, self-organising and interoperable, as well as offering data-driven capabilities. In relation to systems, integration by design facilitates implementation and operation, and also simplifies the training of operators for capital assets. This implies the need for methods and techniques to support the proper integration of newly developed systems or products. The challenge here is far beyond technical installation and entails more than the integration of hardware, software and humans in relation to a single product or system. In fact, integration issues occur at different levels, and their consequences may extend beyond technical matters. The high pace of technological development demands strategies that not only fulfil the technical requirements but also successfully address the interoperability and dependability of systems, data integrity, security or privacy matters (Rajabalinejad, 2018a).

This paper reviews integration in engineering practices, holistically addresses integration hierarchy levels and offers a systematic approach to the integration of systems. Section 2 reviews integration engineering, providing fundamental definitions and discussing integration during the design and other phases of the lifecycle. Section 3 discusses the hierarchical levels of integration, while Section 4 explains the role of humans in systems integration. Section 5 discusses safe system integration in detail and suggests that three fundamental elements and their interaction are essential to safe systems integration. The outcomes are summarised in the Safety Cube theory discussed in Section 6, while Section 7 presents example applications. Finally, conclusions are drawn in Section 8.

2. Integration engineering

2.1. Definition of integration

‘Integration’ is defined as ‘an act or instance of combining into an integral whole’ (dictionary.com, April 2019). In engineering practices, integration may have different meanings depending on the different phases of the lifecycle and across different disciplines. For example, integration in requirements, software, hardware, design, production or green engineering has different meanings.

According to White (White, 1990), ‘integration’ refers to the activity of combining several implemented system elements and activating the interfaces to form a realised system (product or service) that enables interoperation between the system elements and other systems in the environment to satisfy system requirements, architecture characteristics and design properties. In addition, ‘integration engineering’ is seen as a set of activities that define, analyse and execute integration across the lifecycle, including interactions with other lifecycle processes (White, 1990). In this context, an activity is defined as a set of cohesive tasks in a process. In most engineering standard practices, as suggested in White (White, 1990), the term ‘integration’ is limited to the integration of the system elements in order to realise the system and related activities across the full lifecycle. However, integration engineering also needs to address the integration of a system with its external environment and/or enabling systems. This is the task of integration management, which is a set of activities that plans, assesses and controls integration activities and all other related activities, according to White (White, 1990).

Integration engineering concerns the discovery, analysis, learning, planning, designing, developing, executing, managing and monitoring of integration matters across the full product or system lifecycle. Integration matters may be related to technical systems, humans or the related environment, and may include structural, operational, functional or other technical or non-technical characteristics.

2.2. Integration in design

Integration is an important concern of design engineers because integration issues influence the major performance indicators of cost, time and quality. In other words, improper integration can delay the delivery time, result in unexpected costs or compromise on quality. Engineering design practices are generally formulated in terms of several steps, starting with an analysis of the problem, identifying requirements, generating ideas and concepts, and embodying the chosen concept, followed by detailed design and testing, as discussed for example by Pahl, Beitz, Feldhusen, and Grote (2007). Another widely accepted approach is the V model practised by systems engineers, which follows a similar pattern (ISO/IEC/IEEE, 2015). This V model emphasises the two pillars of design and integration. These practices mainly focus on the integration of system elements with the aim of realising the system. In this context, the integration of a system or product with its environment is often treated as a requirement which must be addressed during the design process. In the course of design, many design scenarios or failure-related considerations entail integration analysis. For example, Failure Mode and Effect Analysis (FMEA) is commonly used to explore possible failure scenarios and their effects or consequences. Fault Tree Analysis (FTA) or Event Tree Analysis (ETA) are also often used to represent a potential failure and/or its consequences. These methods are commonly based on component or subsystems failure and their propagation through the entire system (ISO, 2013a).

The methods mentioned above often focus on internal interactions (or internal integration), product functionalities and the user interface. They also often assume that if a product does as intended, there will be no failure and the product will have no functional issues. In this context, reliability is thought to be similar to safety and the tools applied become less capable of capturing a situation which is improperly integrated but not due to failure. The shortcomings of these approaches and assumptions are becoming more obvious as systems become more complex. Moreover, the systems engineering (SE) handbook highlights human and system integration (HSI), which considers domains such as human factors in engineering or occupational safety (Walden, Roedler, Forsberg, Hamelin, & Shortell, 2015).

2.3. Integration across the lifecycle

In practice, integration activities take place across the full lifecycle. In early project phases, the project team needs to integrate the market demands, stakeholder needs and system requirements. This is because proper design starts with a thorough understanding of the stakeholders and their needs. In addition, concept design entails the integration of functionalities with non-functional demands. Detailed design requires the integration of components in order to deliver functionalities. Production is about producing different parts and integrating them in order to deliver a product: this is called ‘internal integration’. Use is about the integration of a product and its values with everyday life. Such integration of a product with its environment is also called ‘external integration’. Finally, phasing out is about recycling and hopefully sending the product safely into the environment.

However, integration failures are often strongly present in both the internal and external integration phases. Internal integration starts when the manufactured parts and components, including the user interface, are integrated in order to make a functional subsystem or system. This is often reported as a problematic phase in the literature (ISO, 2013b; Rajabalinejad & Dongen, 2018; Zhaoa, Huob, Selen, & Yeung, 2010).

External integration occurs when the system is implemented in its operational environment. From this point of view, integration failures often occur in the early phases of implementation. These failures are also called ‘childhood diseases’. This has been represented by the ‘bathtub curve’, which shows the number of failures in a system or component as a function of time. The bathtub curve shown in Figure 1 represents a relatively steady rate after the early failure period, followed by a period of increasing failures. These early failures often refer to both internal and external integration.

Figure 1. The number of internal and external integration failures are higher in the early implementation phase.

Furthermore, integration failures are often disputable because they are not usually seen earlier in the requirements or design phases and because they generally arise from multiple factors. From this perspective, the issues related to responsibility – mainly with respect to external integration failures – are rather complex in a multistakeholder context (Chan, Chan, Fan, Lam, & Yeung, 2008). Several examples of integration failures in railway systems, for example, have been presented by Rajabalinejad (2018a).

2.4. Safe integration

Safety has been defined as ‘freedom from those conditions that can cause death, injury, occupational illness, or damage to or loss of equipment or property, or damage to the environment’ (DoD, 2012). Safe integration involves a level of integration in which the system, humans and the environment of the system are properly addressed. In fact, integration is similar to safety from several perspectives that have a multidisciplinary nature, where different techniques and methods can be used for seamless and safe integration. For example, the Swiss cheese model of accidents developed by J. Reason presents a model for the integration of different system layers, in which the risk of a threat may become a reality (Reason, Hollnagel, & Paries, 2006).

Safe integration concerns the minimum level of integration accepted by society. In other words, a safely integrated system will be in compliance with both national and international regulations and will offer functions and services that meet safety requirements (Rajabalinejad, 2019a). Relevant regulations and standards often aim to ensure reliable services and accepted levels of safety and quality. For example, standards such as ISO 55000 focus on quality control for performing functions (NEN-ISO, 2014). IEC 61508, a seminal standard for functional safety, addresses the issues of system safety validation and system integration (tests), including architecture, software and integration tests (IEC, 2010a). ISO 12100, the reference standard for the safety of machinery, pays special attention to safety matters during the assembly of a machine or its integration with the surrounding environment (ISO, 2010).

Directives and regulations also often focus on safe integration. One example here is the European Directive for Railways (Parliment, 2016). While governments push industries to standardise to protect people, they must also ensure economic growth, affordable products and the use of available technologies. As shown in Figure 2, this creates a dilemma for the authorities and hinders a transparent policy on the relationship of innovation and regulation. Furthermore, the rapid pace of technology makes it difficult for the authorities to regulate every new innovation; however, they must be safely integrated with operating systems, humans and the environment. In fact, safe integration strongly influences the acceptance of new innovations or technologies.

Figure 2. Safe integration influences the acceptance of new innovations or technologies.

The technology readiness level (TRL), integration readiness level (IRL), safety by design and safety cubes are methods used to ensure the better integration of products or systems. In other words, societies are more likely to accept innovations and new technologies if they are safely integrated with the environment. Energy transition is an example of this, in which societies demand innovative and safe technologies that can supply the energy necessary for economic growth. Figure 2 visualises the importance of safe integration as a point of equilibrium.

3. Hierarchy of integration

This section provides a conceptual overview of a system hierarchy and presents an organisational (both internal and external) view of the structure of systems. Hierarchy entails a specific arrangement of items (objects, names, values, categories, etc.), in which these items are represented as ‘above’, ‘below’ or ‘at the same level as’ one another. This logical or conceptual hierarchy is used in different disciplines, such as risk assessment or system governance, as presented for example by Leveson (Leveson, 2015). The international community of systems engineers acknowledges the challenge of defining the system structure with respect to the required hierarchical level. It considers a system hierarchy to be the organisational representation of a system structure. It is important to note that the depth of the hierarchy is adjusted to fit the complexity or nature of the system of interest, and a system may focus more on some levels than on others. This facilitates a view of integration maturity beyond a specific level, as the full hierarchical chain often requires consideration. Such an overview helps in understanding the system as an integral whole which is composed of components interacting with each other or with their environment. It also presents the logical relationship between each component and its environment, differing from the component lifecycle perspective, which conceives of every component returning directly to the natural environment at the end of its life (Rajabalinejad, 2019b).

Here, the sequence of system, subsystem and component or element is used to refer to the breakdown of a system into smaller parts. The terms ‘system’ and ‘subsystem’ may be used interchangeably (EN, 2015). The following subsections define several hierarchical levels of integration: subsystem, system, human systems, system of systems, sociotechnical system, political system and environmental system integration.

3.1. Subsystem integration

Subsystem integration, or integration at the subsystem level, refers to a combination of two or more components or elements that make a subsystem. In other words, the integration of components or elements results in a subsystem. Subsystem integration is often among the earliest actions in physical integration. The integration of components often occurs in the production or assembly stages. Although a subsystem is the result of the integration of components or elements, it is important to note that components, elements or subsystems cannot function independently. To clarify this, Figure 3 presents an example of the railway system, in which three subsystems are presented: train, catenary and rail.

Figure 3. Different levels of integration for passenger transport.

3.2. System integration

System integration, or integration at the system level, refers to the integration of components, elements or subsystems, or human interactions in order to realise a system that accomplishes the system objectives. Therefore, it here refers to technical systems integration. In other words, the focus of system integration is mainly on the integration of components, subsystem internal/external interfaces and human interactions. For example, Figure 3 shows the technical integration of the railway system, involving the integration of the train, rail and catenary subsystems with the other subsystems.

Nevertheless, there is no single definition of the system across different disciplines. For example, the SE community considers humans to be system elements. It defines a system as ‘an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, Information, techniques, facilities, services, and other support elements’ (ISO/IEC/IEEE, 2015). However, this definition is not adopted in its entirety across all disciplines. The other seminal approaches to system definition will be discussed in detail in Section 4 of this paper.

In addition, the SE handbook defines integration as a technical process involving the integration of the elements of a system. In this context, successful integration leads to a system that works and delivers the required functionalities without failure. However, this means that the integration of the human and the system becomes an issue, because this aspect does not entail a completely technical process. The SE handbook in fact recognises that the integration of the human and the system is not a technical process and recommends focussing on human systems integration (HSI) across the design or engineering of systems (Walden et al., 2015).

3.3. Human systems integration

Human Systems Integration (HSI), or human technical systems integration, refers to the integration of the human and technical systems. The ISO (ISO, 2011) defines HSI as the interdisciplinary technical and management process for integrating human considerations within and across all system elements. HSI focuses on the human, an integral element of almost every system, over the system lifecycle. HSI is an essential enabler of SE practice as it promotes a ‘total system’ approach that includes humans, technology (e.g., hardware, software), the operational context and the necessary interfaces between and among the elements to ensure they all work in harmony (Walden et al., 2015). Figure 3 illustrates human systems integration for the railway example, where the railway manager, operator and owner must work with the technical system in order to operate and manage it. In practice, the integration of the human and the technical system occurs within two layers of operation and management of the system.

HSI considers domains such as human factor engineering (human performance, human interface, user-centred design), workload (normal and emergency), training (skills, education, attitude), personnel (ergonomics, accident avoidance), working conditions and health and safety (hazard avoidance). In other words, HSI aims to address the human expectations, proper user interfaces, trained personnel and controlled performance. It is important to note that HSI focuses on human needs within the scope of the system of interest.

3.4. System of systems (SoS) integration

System of systems integration refers to the integration of two or more systems, or integration at the system of systems level. A system of systems (SoS) consists of a combination of two or more independent systems. According to the SE handbook, SoS is a system whose elements are managerially and/or operationally independent. Therefore, the interoperability of the integrated systems or subsystems is usually not achievable by an individual organisation. The relationship between one system and others has been discussed elsewhere, for example by Mo Jamshidi in the context of SoS (Jamshidi, 2008). Jamshidi considers integration as the key to the viability of any system of systems. Integration means systems can communicate and interact through different interfaces, which take forms such as hardware and software. In this respect, a system uses services from other systems or delivers services to other systems. This requires collaboration between different organisations. The key factors in delivering optimal results are shared objectives among organisations, the co-creation of desired capabilities and the co-integration of interoperable services (Rajabalinejad & Dongen, 2018). The effects of a system and its behaviour on the related environment are discussed in the literature on safety, which will be further discussed in the following sections.

As an illustration, Figure 3 shows that the railway system must offer interoperable services, working with the metro, bus or international rail services. The integration of these systems to provide interoperable services can be considered an example of system of systems integration.

3.5. Sociotechnical systems integration

While SoS integration focuses mainly on functional, operational or managerial aspects, sociotechnical systems integration spotlights the integration of the system of systems or related services with society. In other words, a system of systems needs to be properly integrated with societal needs to ensure optimal delivery of its services. Moreover, SoS integration must be in compliance with societal (national) regulations in order to be able to deliver services. From this perspective, it is not only social demands but also societal or cultural values that play a major role in determining optimal performance (Woo & Vicente, 2003). For example, the language of communication, accepted norms and values, the performance demanded, or the services expected will have an impact on a sociotechnical system and its sustainable performance (Davis, Mazzuchi, & Sarkani, 2013). Figure 3 shows the sociotechnical system integration in the hierarchy. It illustrates that the railway system must not only collaborate with other systems, such as the metro, but must also address societal demands, such as interoperable services, the quality of travel experience, and mobility as a service.

3.6. Political system integration

Sociotechnical systems must be controlled or monitored by national governments and reflect societal values, norms and policies. Organisational chains of responsibility, authority and communication are required to ensure measurement and control mechanisms that effectively drive the organisation of complex systems and enable people to perform their respective roles and fulfil their responsibilities (Cantor, 2006). With respect to the railway system, the interests of political parties, the need to stimulate public transport, or the adoption of international regulations are examples of this, as shown in Figure 3.

3.7. Global system integration

Human societies have shared concerns, which may, for example, be represented by international regulations. Global concerns, for example, include the use of green energy, reducing reliance on fossil fuels and minimising CO₂ emissions. The proper integration of systems must take these issues into account at the highest hierarchical level (White, 1988).

Figure 3 as a whole presents a graphical overview of the seven levels of hierarchy discussed here in relation to the rail industry. The purpose of this figure is to reveal the differences between the different levels of integration; it does not intend to present a complete picture of all the relevant system elements.

4. Humans in system integration

This section will clarify the different ways of dealing with integration in several engineering disciplines and discusses the advantages and disadvantages of these different approaches. In the most basic sense, system integration requires system elements to be integrated. For this purpose, various components need to be integrated to form subsystems, which in turn need to be integrated to form a system. Systems often need to be operated or managed by humans to form an operational system. In the literature, the role of humans in such system integration is formulated in various ways. The following subsections present three seminal approaches to dealing with humans in the context of the system and its operating environment.

4.1. Railway RAMS approach

The RAMS (Reliability, Availability, Maintenance, Safety) standard for railways ensures a consistent approach to the management of the rail network across the European Union (EN, 2015). RAMS defines the system as a ‘set of elements which interact according to a design, where an element of a system can be another system, called a subsystem and may include hardware, software and human interaction’. In this standard, human interactions (rather than human beings) are considered part of the system. This standard defines a system level approach which has three levels of hierarchy: (a) the system under consideration, (b) the environment of the system under consideration, and (c) the components or subsystems of the system under consideration. According to this standard, the system environment consists of anything that could influence, or be influenced by, the system under consideration. The environment includes anything to which the system is connected, such as interfaces, humans and procedures. From this perspective, the human is seen as a part of the environment of the system under consideration. Figure 4(a) summarises the RAMS standard approach. As the figure shows, the RAMS standard does not consider humans to be part of the system under consideration (as represented by the unbroken black line). In other words, the focus of this standard is on the system under consideration only, with humans connected to but not a part of it. The figure attempts to illustrate that the human is a part of the operating environment (broken line), which includes a supersystem, which may be a system in itself.

Figure 4. Three different views of the relationship between the human, the system under consideration and the environment. (a) Railway RAMS approach. (b) Systems engineering. (c) Safety management approach.

4.2. Systems engineering approach

Systems engineering is an interdisciplinary approach which aims to enable the realisation of successful systems. In this approach, a system is defined as a combination of interacting elements organised to achieve one or more stated purposes (ISO/IEC/IEEE, 2015). In this view, a complete system includes all of the associated equipment, facilities, material, computer programmes, firmware, technical documentation, services and personnel required for operation and support to the degree necessary for self-sufficient use in the intended environment. In other words, system elements may be hardware, software, data, humans, processes (e.g., processes for providing services to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities, or any combination of these elements. The systems engineering view considers humans to be part of the system, as shown in Figure 4(b).

The systems engineering approach defines the integration process as a technical process. It describes the purpose of the integration process as the synthesis of a set of system elements into a realised system (product or service) that satisfies system requirements, architecture and design. This integration approach was discussed above in Subsections 2.2 and 3.2. Interfaces are identified and activated to enable interoperation of the system elements as intended. This process integrates the enabling systems with the system of interest to facilitate interoperation.

The SE integration process treats humans like the other system elements in the integration process. However, the integration of technical components and the integration of people require different considerations and processes. In this approach, the integration of the human and the system becomes a distinct issue, because it is not a completely technical process. Further elaboration of human systems integration is not included in system engineering standard practice. However, the SE handbook recognises that the integration of the human and the system is a non-technical process and recommends focussing on human systems integration (HSI) across the design or engineering of systems (Walden et al., 2015). In this respect, the human and its integration with a system must by fully considered, as discussed above in Subsection 3.3.

In summary, the systems engineering approach focuses on the system of interest and considers the human to be a part of it. However, the integration processes as defined for the integration of system elements does not support the full integration of all system elements. HSI is a remedy aiming to integrate people with the system, which is not included in systems engineering standard practice (ISO/IEC/IEEE, 2015).

4.3. Safety management approach

The ICAO (the International Civil Aviation Organisation) safety management manual provides guidance on the development of safety programmes for all countries around the world (ICAO, 2013). It is one of the most successful safety management programmes in the world, successfully implemented across the globe in the aviation industry. This standard of practice accepts the possible risks associated with human activity or human-made systems, leading to safety risks for the aviation industry, and it aims to manage these risks and maintain an appropriate level of control.

ICAO uses the SHELL conceptual tool, which analyses the interaction of multiple system components. The SHELL model consists of software (S), hardware (H), environment (E) and liveware (L). In this respect, software includes training, procedures and support; hardware includes machines and equipment; liveware is the human in workspace; and the environment is the work environment in which the L-H-S system must function.

The ICAO view is illustrated in Figure 4(c) in which the technical system represents both software and hardware.

To summarise, the three elements of the human, the system under consideration (or technical system) and the environment of a system have been approached differently across different practices, as shown in Figure 4. This figure highlights the fact that the relationship between the human and the system has been formulated in various ways across different disciplines. The following subsections elaborate on these elements.

5. Systems integration fundamentals

One of the primary tasks for engineering design, systems engineering, or risk management is to ensure at least the safe but, preferably, the optimal integration of a system with its environment. To do otherwise would lead to extra costs. Addressing the relationships between the system, subsystems, the environment and people is paramount for safe system integration. These relationships, or interfaces, are thus one of the core issues in proper integration. Systems engineering focuses on the system of interest (of which the human is a part) and the environment of the system of interest. The RAMS standard, in contrast, focuses on the system under consideration and its environment (of which the human is a part), while the ICAO safety management manual focuses on the hardware and software, the human and the environment. The safety management approach thus more explicitly defines the role of the human in the system.

Figure 5 schematically shows the main building blocks for safe integration and the relationships between them. In this figure, the human, the system under consideration (or the technical system) and its environment have been numbered from 1 to 3, respectively. The rounded rectangles represent different categorisations of these three elements. The systems engineering and railway RAMS perspectives are represented by the rounded rectangles numbered 4 and 5, respectively, as discussed in the previous section. The rounded rectangles numbered 6 and 7 represent the two categories of warm bodies (the human) and cold bodies (the technical system). The system environment can include both warm and cold bodies. In this view, integration between warm and cold bodies often occurs through regulations, tasks, processes or interfaces. Below, we explain the fundamentals of integration in detail.

Figure 5. Three different views of the human, the technical system and the environment.

5.1. Building blocks for integration

System, human and environment are the three building blocks of safe integration, as discussed in previous literature (Rajabalinejad, 2018b). These are discussed in further detail below.

5.1.1. The system

The system whose lifecycle is under consideration by stakeholders is called the ‘system under consideration’ by the RAMS standard (EN, 2015). This ISO standard for railway safety defines the system as ‘a set of elements which interact according to a design, where an element of a system can be another system, called a subsystem and may include hardware, software and human interaction’ (EN, 2015). These elements include products, processes, procedures, information, techniques, facilities or services. Thus, human interaction is included in the definition of a system of interest, but the human is not an integral part of it. We find this an appropriate definition for a discussion of the systems integration process. In this paper, the terms ‘system under consideration’, ‘technical system’, ‘system of interest’ and ‘system’ are used interchangeably. A technical system is essentially hierarchical and it can be decomposed into other systems, subsystems or components. As applied by the ISO RAMS standards, this describes the concept of nested systems, where ‘systems’ and ‘subsystems’ can also be used interchangeably. Furthermore, the system has a lifecycle and its elements can change in different phases of this lifecycle.

5.1.2. The human

The ‘human’, ‘people’, or ‘stakeholders’ may refer to an individual, a group of individuals or organisations which have connections to the system in the form of owners, users, operators, managers, service providers, suppliers, producers or other stakeholders, who directly or indirectly have an interest in the system. They may cooperate or compete with the system of interest, or regulate, design, build, implement, install, operate, monitor, manage, maintain, replace or dismantle it. Humans interact with the system at different levels of the hierarchy and across different phases of a lifecycle. Stakeholders have different interests and degrees of power to influence the system. They may be users, operators, owners, service providers, producers or other humans, who directly or indirectly have an interest in the system.

Humans have their own individual or organisational culture. They are not standardised to the same degree as hardware, and they do not always interface perfectly with various components of the system. In order to avoid tensions that may compromise human performance, the effects of irregularities at these interfaces must be well understood, and the other components must be carefully matched to humans (ICAO, 2013).

It is not only the relationship between the human and the system that may influence the system of interest, but also the relationships between humans. The human-human interface is the relationship between people within or outside the working environment. For example, operational staff, system managers, maintenance engineers and other operational personnel function in groups. Thus, it is important to recognise that communication and interpersonal skills, as well as group dynamics, play a role in determining human performance (ICAO, 2013). The relationship between staff and management, as well as the overall organisational culture, are also within the scope of the human-human interface.

5.1.3. Environment of the system

The environment consists of all of the relevant parameters that can influence or be influenced by the system of interest in any lifecycle phase. The related environment may be referred to as the ‘context’, ‘surrounding’ or ‘supersystem’. Relevant regulations, industry standards or supporting facilities involved in the course of normal or specific operational conditions are part of the system environment. As we saw above, functional safety and railway safety standards define the human as a part of the environment, while systems engineering practice considers the human as a part of the system (ISO/IEC/IEEE, 2015; EN, 2015; IEC, 2010b).

Here, the human is not considered a part of the environment, which furthermore does not merely concern the climate or the weather conditions. The environment of a system includes the operational environment, enabling systems and infrastructure. The system under consideration uses services from the environment and provides functions or services. Regulations and legislation at the national or international levels that influence the system are also part of the environment. Moreover, the system environment has different levels of hierarchy and it changes across the lifecycle.

5.2. The interactions

This section describes the interactions between the building blocks explained above in Subsection 5.1.

5.2.1. System – environment

The system of interest has a relationship with its environment. This relationship between a system and its environment may be physical or non-physical.

A physical relationship (or interface) is often realised through technical installations. It often takes the form of a mechanical, energy or informational interface (ISO, 2010). Other non-physical factors that are related to the system include laws, regulations, policy, market demands and political interests, which may influence or be influenced by the system. An external view of a system will introduce elements that do not belong to the system but which will interact with it. This collection of elements is called the ‘related environment’.

5.2.2. Human – system

As explained above, the human can play different roles and consequently have different kinds of relationships with the system of interest. The relationship may be physical, logical or emotional, for example. This relationship can also influence or be influenced by the system of interest. Human factors, and operational and safety culture, fall under the category of a human-system relationship.

The human-system interface refers to the relationship between the human and the attributes of equipment, machines and facilities of a system. The interface between the human and technology is commonly considered with reference to human performance in the context of operations, and there is a natural human tendency to adapt to human-machine mismatches (ICAO, 2013). Nonetheless, this tendency has the potential to mask serious deficiencies, which may only become evident after an adverse event. The human-system interface can also refer to the relationship between the human and the supporting systems, such as work regulations, manuals, checklists, publications, standard operating procedures and computer software.

5.2.3. Human – environment

The human-environment relationship often falls beyond the scope of the system of interest in the technological design phase, but it may have a dominant influence on the system of interest. A change of regulations in a dynamic and competitive political context, or policymaking that influences the system, are examples of human-environment relationships influencing the system of interest. These relationships often become very complex for systems in which multiple stakeholders are involved.

The human-environment interface (HEI) involves the relationship between the human and both the internal and external workplace or system environments. The internal workplace environment includes physical elements such as temperature, noise, vibration and air quality. The external environment includes operational aspects, such as weather factors or other collaborating or competing systems. HEI therefore involves the relationship between the human internal environment and the external environment. Psychological and physiological forces, including illness, fatigue, financial uncertainties and relationship and career concerns, may be either induced by human-environment interaction or originate from external sources. Additional environmental aspects may be related to organisational attributes that may affect decision-making processes and create pressure to develop workarounds or minor deviations from standard operating procedures (ICAO, 2013).

6. Safety cube

6.1. Theory

Section 5 laid the foundation for proper systems integration through six fundamental aspects. Six essential views are represented by six faces of a cube, which we call the Safety Cube. Safety Cube theory formalises the most fundamental elements of safe integration, emphasising the seven pillars of safe integration. To summarise, these are: 1. the system under consideration (technical system or system); 2. the human who has a relationship or is associated with the system; 3. the operating environment or related environment of the system; 4. human-system integration; 5. system-environment integration; 6. human-environment interfaces that influence the system; and 7. Human-system-environment or the complete system integration.

6.2. Visualisation

Figure 6 shows the six fundamental aspects of safe integration in the six faces of the Safety Cube. The three-dimensional visualisation of the Safety Cube is presented in Figure 7. Safety Cube theory considers both the technical and non-technical aspects of integration. The Safety Cube can also capture both the hierarchical and behavioural aspects of integration. Its vertical and horizontal axes represent hierarchy and lifecycle (time), respectively. Furthermore, the hierarchical perspectives can be represented in the system or system-environment aspects, and the behavioural or operational perspective can be represented in the human-system and human-environment aspects. However, this requires further research. Nevertheless, the Safety Cube is an easy to grasp concept which visually supports system integration, not in isolation from but as a part of the human and/or environmental context required for optimal integration (Rajabalinejad, 2019c). The Safety Cube requires knowledge in the disciplines of systems engineering, risk management and safety engineering; prerequisites for safe and optimal integration (Rajabalinejad, Frunt, Klinkers, & van Dongen, 2019).

Figure 6. Six sides of the Safety Cube.

Figure 7. Visualisation of the Safety Cube: six fundamental aspects of safe integration are presented on the six faces of the Safety Cube for Human-System-Environment (HSE).

6.3. System definition

Table 1 provides an overview of the information needed to form a Safety Cube. The diagonals of this table specify the human, the system under consideration and the environment of the system, while the other cells provide information about the interactions between the diagonals. The off-diagonals should be read clockwise in such a way that the associated row provides input for the associated column. For example, the human-system cell in the top row describes human output as input for the system, while the system-human cell in the second row describes the system output as input for the human. Table 1 summarises the system definition and provides an overview of the building blocks and their connections for safe integration. It is important to note that Table 1 summarises the major system elements and their interactions which re required for proper system integration. It is possible to further elaborate both of the system elements and their interactions by the design structure matrix (DSM). This subject is beyond the scope of this paper.

Table 1. The elements of the Safety Cube for safe integration.

	Human	System	Environment
Human	Users, direct/ indirect stakeholders, operators	Human input for the system, intended use or misuse scenarios	Human input for the environment or its system of systems, use or misuse scenarios
System	System inputs, functions, malfunctions, or services for human	System of interest, its structure, functions, procedures, etc.	System input for the environment, intended use or misuse scenarios
Environment	Environmental inputs, functions, malfunctions, or services for human	Environmental inputs, functions, malfunctions, or services for the system	Cooperating or competing systems, physical environment, policy, regulations

6.4. Application domains

Although several principal domains were thoroughly reviewed above in Section 4, on the basis of which the Safety Cube was developed, its application domains remain beyond the above-mentioned domains. Thus, Table 2 compares the literature in other domains and reveals that different domains and disciplines use comparable terminology. This table shows that terms such as ‘people’, ‘human’, ‘staff’, ‘liveware’, ‘organisational’ or ‘social’ are all used to refer to the human, whether as individuals, groups, organisations or societies. Terms such as ‘technical’, ‘product’, ‘asset’, ‘soft/hardware’, ‘system under consideration’, ‘technical system’ or ‘system of interest’ predominantly refer to technical aspects of systems. The terms ‘environment’, ‘related environment’ or ‘infrastructure’ may also refer to the product environment.

Table 2. The fundamental elements of integration across different disciplines.

Discipline	Human	Technology	Environment	References
Social science	Social	Technical	Environmental	(Collier, Lambert, & Linkov, 2018)
TOE framework	Organisational	Technical	Environmental	(Bosch-Rekveldt, Jongkind, Mooi, Bakker, & Verbraeck, 2011)
HSE framework	Human	System	Environment	(Rajablinejad, 2019a)
Systems engineering	Human	System of interest	Related environment	(ISO/IEC/IEEE, 2015)
Railways	Human	System under consideration	Environment	(EN., 2015)
Aviation	Liveware	Soft/hard ware	Environment	(ICAO, 2013)
Machinery	People	Product	Environment	(ISO, 2010)
Management science	Knowledge	Technical system	Managerial system	(Leonard-Barton, 1992)
Asset management	Staff	Assets	Infrastructure	(van Dongen, Frunt, & Rajabalinejad, 2019)

Figure 8(a,b) visualise Safety Cubes from the sociotechnical environment perspective, and from the assets, staff and infrastructure perspective, respectively.

Figure 8. Visualisation of the Safety Cube for (a) the sociotechnical environment (TSE) and (b) assets, staff, infrastructure (ASI).

7. Example applications

7.1. Safe integration of bicycles in The Netherlands

This section presents an example application of the safe integration of bicycles into the urban environment. This is an interesting example because cycling has social, economic and health aspects and is a green form of urban transportation. Nevertheless, the safety of cyclists is essential to ensure that it remains a popular form of urban transportation. In the Netherlands, about 35% of people use bicycles on a daily basis, which means the public demand for safety must be taken seriously. In 1970, people protested against the high number of child deaths on the roads and started the movement called ‘Stop child murder’ because of the high rate of casualties, especially at crossings (Noordzij, 1976).

This demand influenced government policy in the Netherlands, which perceived the bicycle as a critical means of safe transportation in urban areas. Along with geographical considerations, bike-friendly infrastructure and bike-friendly policy are the keys to the safe integration of bicycles into the system (Terzano, 2013).

Here, the elements of safe integration have been described and listed using the approach introduced earlier in this paper. For this purpose, the three elements of the human, system and the environment are the starting points. Table 3 presents these three elements and their connections. The table shows the requirements for creating a safe cycling experience for users. It goes far beyond the design of a safe bicycle and a safe helmet, requiring an integral view that combines proper infrastructure with supportive policy and a culture that embraces it in order to achieve the optimum results. It is important to note that the table presented here for this example does not present all the detailed information required for the safe integration of bicycles into urban areas.

Table 3. The elements of a safety cube for the safe integration of bicycles.

	Human	System	Environment
Human	Cyclist, other road users, regulators, service providers	Traffic rules, quality & condition control, human-power input, steering	Driving culture of e-bikes, cars, motorcycles, or other road users
System	Safe, comfortable, economic, healthy, and enjoyable personal transport	Bicycle	Visibility in day light, night, or in rain
Environment	Traffic regulations, and traffic management system, climate requirements	Bicycle (or safe) path, spare parts, fallen trees, snow or ice on the path, fallen trees or bushes	Road, signs, curbs, markings, other road-vehicles, crossing, parking, climate, policy, regulations

In order to verify whether the proposed approach could capture the essential elements of safe integration, a number of references were reviewed, as mentioned earlier in this section. The results confirm that the elements of safe integration were captured by this approach, as discussed in Rajabalinejad (2019c) and Liefland (2019).

7.2. Safe integration of automatic train operation (ATO)

With continuous increase in the need for transportation, more and more passengers and cargo have to be carried by rail. In recent years, railway faced tremendous growth but with limited increase in capacity, making railway network more and more saturated (Lagay & Adell, 2018; Rao, Montigel, & Weidmann, 2013a). Consequently, the railway industry is facing a range of challenges to improve the existing system aiming for a high-quality system which increases capacity and efficiency of the railway network, more eco-friendly systems with energy cost reduction, and higher customer satisfaction. Two major methods to tackle these challenges are real-time rescheduling and automatic train operation (ATO). Real-time rescheduling increases efficiency of infrastructure management by dealing with deviations, breakdowns and incidents, while automatic train operation is an on-board approach available to minimise the loss of efficiency caused by manual operation. ATO is regarded as a promising solution to meet abovementioned challenges (Lagay & Adell, 2018). ATO is an on-board concept for all phases of the train operation, from acceleration to precise stopping, which implements train-level optimisation to help train operators realise automation and exact operation (Lagay & Adell, 2018). With the rapid development of communication, control and computer technologies in the last several decades, the driver achieves more and more supports. ATO is assumed to aid in increasing capacity of the track, minimising disruptions, increasing punctuality, increasing efficiency in deployment of train drivers and aid in more effective energy consumption. As technology advances in railway systems, one theoretically challenging and practically significant problem is how to integrate the ATO system, to make the current railway network more efficient with higher capacity, lower cost and improved quality of service by optimised railway traffic management and train operation (Rao, Montigel, & Weidmann, 2013b). According to Schutte (2001) and Yin et al. (2017) there are different Grades of Automation (GoA) of trains indicated in Table 4 which could aid in achieving distinct goals.

Table 4. Grades of automation (GoA) in automatic train operation (ATO).

Grade of automation	Train control	Door handling	Stop	Train control in case of disruption
GoA 0
On-sight train operation	Driving without controlling the train	Train driver or train attendant	Train driver	Train driver
GoA 1
Manual train operation	Driving with train control	Train driver or train attendant	Train driver (eventually braking system)	Train driver
GoA 2
Semi-automatic train operation (STO)	Automatic control with train driver	Train driver or train attendant	Automatic	Train driver
GoA 3
Driverless train operation (DTO)	Automatic control without train driver	Train attendant	Automatic	Train attendant
GoA 4
Unattended train operation (UTO)	Automatic control without staff	Automatic	Automatic	Automatic

7.2.1. Safe integration of ATO

Integration of ATO into the operating railway system requires proper understanding of the system, its goals, related humans, and the operating environment. For example, GoA 1 entails manual train operation and the train driver is driving without automated controls. The system under consideration here is the GoA level 1 system (IEC 2009). The human element consists of e.g., the train driver, train attendants, and passengers. The operating environment includes the rails, the signals along the tracks, or other elements of natural environment. There are monitoring or control interfaces between the train driver and the train, and there are physical interfaces between the train and tracks or transmission lines. In GoA 1, the train driver is responsible for braking, door handling, (un)coupling, monitoring the operating environment (including signal recognition and obstacle detection) and managing calamities/disruption during operation.

When the system under consideration is GoA 2, which entails semi-automatic train operation, a better execution of timetable and a higher energy efficiency is expected. For this system, some functionalities e.g., the braking and stopping of the train will be automated as indicated in Table 4. Here, the train driver and train attendant are still the human elements interacting with the system. Yet there are more automated interactions among the system under consideration and its environment e.g., stations, railways, other trains.

For GoA 3, or unattended train operation, no train driver is available. GoA 3 covers all functionalities which were previously related to the train driver. The system should enable braking, door handling, (un)coupling, monitoring the operating environment (including signal recognition and obstacle detection) and managing disruption during operation. The human element here is the train attendant. All (sub)systems in the environment, e.g., stations, signalling system, or control room must fluently communicate with this system.

For GoA 4, a conflict-free track must be guaranteed, and the train must properly be controlled in case of disruptions. Moreover, the train itself must also be protected against obstacles and dangers on and along the track. Hence al (sub)systems which aid in doing so, are also parts of the environment of the system under consideration.

The abovementioned examples indicate that a higher grade of automation means higher functionalities for the technical system. Different train types, nearly saturated railways, and timetable planning can significantly influence ATO. Therefore, proper understanding of the functionalities of system, related human, and its environment is required. On the other hand, integration of ATO requires some significant changes to the qualifications of staff. In other words, routine driving work disappears, and the staff concerned with ATO requires a deeper knowledge of all the key systems, as well as a global overview on the functional interactions among them. Proper training of the railway staff is needed. In addition, ATO is subject to numerous rules, regulations and standards to be safely operated. Whether Dutch or European, these have significant influence on the operation of the system under consideration and hence can be considered environment. These aspects indicate that attention to be paid to not only to the system under consideration (ATO), but also its environment and human aspects in order to make sure its proper integration with the railway system.

8. Conclusions

People are increasingly demanding up-to-date technologies that are seamlessly integrated with their everyday life. The increasing complexity of high-tech systems raises the need for supporting tools enabling proper integration of newly developed technologies. The challenge is far beyond technical systems and requires more than the integration of hardware, software and humans in relation to a single product or system.

Integration activities take place across the full lifecycle and are not limited to the design or production phases. To understand the hierarchy of integration, it is necessary to look beyond the system scope into other related systems.

The role of humans in systems integration is defined differently in different disciplines. This study concludes that an understanding of the role of humans in safety standards will facilitate systems integration. The study also found that the role of the technical system, humans and the environment are fundamental to systems integration. This conclusion forms the principles of Safety Cube theory.

Safety Cube theory presents the principal domains which need to be taken into account to ensure safe and optimal integration. The different faces of the Safety Cube present the fundamental views of the integration of systems. The Safety Cube simultaneously covers the hierarchical and behavioural aspects of integration. Finally, the metaphor of a cube visually supports the principal views required for the safe integration of systems and services.

Acknowledgements

The authors acknowledge the support of the Dutch Railways (NS), ProRail and HTSM, who made this research possible through the framework of the SIRA (Systems Integration for Railways Advancement) project: see www.integration.engineering for further information. The authors would also like to acknowledge the peer-review feedback which led to the improvement of this paper.

Disclosure statement

No potential conflict of interest was reported by the authors.

Additional information

Notes on contributors

Mohammad Rajabalinejad

Mohammad Rajabalinejad, PhD, is an Assistant Professor at the University of Twente. He is interested in safety as a designer, systems engineer, teacher, citizen, human, and as a father. He has practiced different disciplines including Civil, Mechanical, and Industrial Engineering. He is leading several projects including SIRA (system integration for railway advancement). He serves the scientific community as associate editor. He has organized several special sessions and chaired conferences. He is a member of the ISO committee for “Safety of Machinery”.

Leo van Dongen

Leo A.M. van Dongen has worked for the Netherlands Railways for 35 years. He retired as Chief Technology Officer, responsible for the asset management of the rolling stock fleet, workshops and maintenance equipment, in August 2019. Since 2010 he is a Professor in Maintenance Engineering at the Faculty of Engineering Technology, in the the Department of Design, Production and Management of the University of Twente. He is a mechanical engineer and completed his doctoral research at Eindhoven University of Technology on energy efficiency of drive trains for electric vehicles.

Merishna Ramtahalsing

Merishna M. Ramtahalsing is a first-year PhD candidate at the University of Twente in Enschede, the Netherlands. She is part of the Department of Design, Production & Management within the Faculty of Engineering Technology. Her doctoral research focuses on system definitions related to interorganisational projects within the complex railway context, to facilitate effective integration and improve system performances. She holds a master's degree in Mechanical Engineering from the University of Twente and is specialised in Maintenance Engineering.