The need for Systems Engineering

The need for Systems Engineering is actually very simple. In real life, it is very easy for things to go wrong. Projects overrun, airplanes fall out of the sky, the environment is damaged, people are hurt or killed, software and IT bring organizations to their knees, and whole societies are crippled by non-joined-up government and management, all of which are the result of system failures at one level or another.

Since it is so easy for things to go wrong, it is important to understand why. Fundamentally, there are three main causes for such System failures, which are as follows:

• Complexity, where Complexity is not identified and, therefore, cannot be managed or controlled.
• Communication, where communication fails or is ambiguous.
• Understanding, where different points of view are not taken into account, and assumptions are made.

The problem is actually worse than this as these three main causes feed into one another, so unmanaged Complexity will lead to communication failure and a lack of understanding, communication failure will lead to Complexity and a lack of understanding, and a lack of understanding will lead to increased Complexity and communication problems (Holt, 2001).

These three causes are often referred to as the “Three Evils of Systems Engineering” and each will be discussed in more detail in the following sections.

Complexity

Complexity exists in every system and may be thought of as being one of two types, as shown in the following diagram:

Figure 1.10: Types of Complexity

The diagram in Figure 1.10 shows that Systems manifest Complexity. There are two main types of Complexity:

• Essential Complexity is the natural Complexity that is inherent in the system. The term “Essential” is used here as it refers to Complexity that manifests in the essence of the System. It is not possible to lower the Essential Complexity of a System, but it is possible to manage and control this Complexity, provided, of course, that it has been identified in the first instance.
• Accidental Complexity is not natural and is introduced by inefficiencies in the people, processes, and tools that are employed to implement Systems Engineering, which will be discussed later in this chapter. Accidental Complexity can certainly be lowered, and this forms a natural part of Systems Engineering.

Complexity manifests itself in the relationships between things, whether these are between the System Elements that make up the System or between Systems themselves. There are many subtleties to Complexity, which will be discussed in more detail in the following sections.

An example…

In order to illustrate and, therefore, understand how Complexity has changed and evolved over the last few decades, a simple example of a System will be introduced, which will be used throughout this book to explain the various concepts and techniques that will be used as part of the overall approach to Systems Engineering.

For this example, the System that will be considered is a motor car, so now consider two such cars: one that was developed and built 50 years ago, around 1970, and one that was developed and built in the modern age, around 2020.

Consider the basic Need for the System. The purpose of any car is to transport a number of people from point A to point B. The user interface of the car is, basically, a steering wheel, gear stick, and three pedals (accelerator, brake, and clutch pedals).

This basic Need, or purpose, of a car has not really changed over the last 50 years, but the point of discussion here is that the complexity of the car has changed in four different ways, which will be discussed in turn in the following sections.

The Complexity of the System Elements

In order to illustrate how the Complexity of the System Elements has changed over the last 50 years, each of the cars will be discussed separately and then compared and contrasted:

Figure 1.11: Basic breakdown of a car

The diagram in Figure 1.11 shows a simple example System of a car. There are four System Elements at the next level down that make up the car, which are as follows:

• The Body, which includes lower-level System Elements such as wings, doors, mirrors, and so on.
• The Chassis, which includes lower-level System Elements, such as brakes, wheels, suspension, and so on.
• The Interior, which includes lower-level System Elements such as seats, dashboard, controls, and so on.
• The Drive Train, which includes lower-level System Elements such as the motor and the gearing.

The System Elements that make up the 50-year-old car are entirely mechanical and electrical in nature. On top of this, almost all of the System Elements will be mechanical; very few of them will be electrical.

Electrical System Elements will be limited to the lights, indicators, fan, wipers, and starter motor, and that is really the extent of the electrical System Elements. The mechanical elements, however, will make up all of the other System Elements that relate to the Body, Chassis, Drive Train, and Interior. The vast majority of the System Elements, therefore, are mechanical with only a handful of them being electrical. This means that almost all of the interfaces between the System Elements will be mechanical in nature, with only a few being electrical or electro-mechanical.

In order to build this car, it is largely a matter of integrating self-contained System Elements that have well-defined interfaces. Also, any electrical connections will require quite simple point-to-point wiring.

Now consider the modern car. There are two new major types of System Elements that now exist that did not exist at all on the 50-year-old car, which are electronic and software-based System Elements. The vast majority of System Elements in a modern car will fall into one of these two categories. Electronic System Elements will include the following:

• Controllers (such as light controllers, indicator controllers, and so on)
• Sensors (such as temperature, pressure, rotation, and so on)
• Actuators (such as levers, small gears, motors, and so on)
• Display elements (such as dashboard lights, audio alerts, and so on)

All modern cars contain a vast amount of software and, in every case, this software will be split across multiple nodes across the whole vehicle. On top of the software itself, the software must be connected to its associated electronic components, which will, in turn, lead to the need for communication buses, such as Controller Area Networks (CANs), which will themselves use communication protocols.

In order to build the modern car, it is no longer a matter of simply integrating System Elements because the interfaces between the elements are now far more complex and will involve subtle changes in voltage and current levels, data transfer, communication protocols, and complex wiring.

The complexity of the System Elements that make up the car has, therefore, greatly increased between the two vehicles. Indeed, not only has it increased in terms of the number of System Elements but also in their nature.

The Complexity of Constraints

It has already been stated that the basic Need for a car has not really changed at a high level in the last 50 years. The basic Need is to transport people from point A to point B. In the past, the emphasis of most cars was to make them go as quickly as possible with little regard for anything else. One of the major things that has changed over the last 50 years is not necessarily the basic needs, but the Constraints that are now imposed on those Needs:

Figure 1.12: Simple Constraints

The diagram in Figure 1.12 shows a simple Need that is named Develop car, and there are two main Constraints associated with this, which are Be safe and Be fast. This diagram here represents, at a very high level, the basic Needs and Constraints associated with the 50-year-old car.

The number of Constraints associated with the older car is very small compared to that of the modern car, which is shown in the following diagram:

Figure 1.13: Complex constraints

The diagram in Figure 1.13 shows the Constraints associated with the modern car. The first thing to notice when comparing the two sets of Constraints is that the number of Constraints themselves has increased dramatically. There are new sets of Constraints that simply did not exist in the older car; for example, Be secure is now an issue that was not really a main consideration previously. Likewise, there is a whole set of new Constraints associated with Provide a positive driving experience. This increase in the number of Constraints will lead to an increased number of relationships between the basic Needs and Constraints, which will naturally lead to an increase in the Complexity of the Needs and Constraints.

It is not just the increase in the number of Constraints that leads to an increase in Complexity but also the Complexity of individual Constraints has increased. There are a number of Constraints now that are related to best-practice models, such as Comply with standards and Comply with legislation. This is interesting from a Complexity point of view as these Constraints will also relate directly to other Constraints. Consider Be safe, which was previously seen as a standalone Constraint. In the modern vehicle, this Constraint will also have both of the compliance Constraints associated with it. Since there are far more legislation and standards in place now that apply to cars that did not exist 50 years ago, the Complexity of individual Constraints has increased, along with the increase in dependencies between Constraints.

The Complexity of a System of Systems

Another area where the car has increased in Complexity over the last 50 years occurs when a higher-level System of Systems is considered. A System of Systems is not just a collection of interacting Systems; it is a collection of interacting Systems exhibiting some behavior that is not exhibited by any of its Constituent Systems. Therefore, it can be argued that a fleet of vehicles is not a System of Systems, as it is simply a collection of Systems that does little more than make the overall System slightly more complicated. A true higher-level System of Systems may be the transport network that a car forms part of. The overall transport System of Systems exhibits a number of behaviors, such as ensuring an efficient journey from end to end, keeping traffic moving when accidents occur, and providing seamless links with smart cities and other transport systems, such as rail.

A modern car is now truly part of a System of Systems as the vehicle itself interacts with other Systems, such as smart cities, smart roads, the cloud, satellites, and so on, which did not occur with an older vehicle. The modern car also takes over some of the skills that were previously the sole domain of the driver, such as parking, maintaining constant speeds, identifying potential dangers, and so on.

The Complexity of the car System has therefore increased due to the fact that the car is now truly part of a wider System of Systems.

Complexity shift

The final aspect of increased Complexity that will be discussed does not necessarily manifest as an increase in the same type of Complexity but, rather, represents a shift in Complexity due to increases in other aspects of Complexity.

Consider again the older car and its motor. The motor in the 50-year-old car is an internal combustion engine, which mainly comprises mechanical System Elements with a handful of electrical System Elements. The internal combustion engine may be considered to have quite a high level of mechanical Complexity, which is naturally exhibited.

Now consider a modern electric car. The motor in the modern electric car is an electric motor that has a single moving part, that of the motor shaft. The mechanical Complexity of the modern car is practically non-existent when compared with the older car. The Complexity of the modern car lives mainly in the software that monitors the rest of the car and controls the electric motor. There is no software whatsoever in the older car.

The older car, therefore, has high mechanical Complexity and zero software Complexity. The modern car has very low mechanical Complexity and very high software Complexity.

The Complexity in the modern car has therefore shifted in nature – in this case, away from mechanical Complexity and toward software Complexity.

Bringing it all together

It can be seen that the Complexity of a typical System has increased dramatically over the last few decades. In the example we have used, the car increases in Complexity for four different reasons, which have been discussed.

This increase in Complexity does not apply just to automotive systems but to any and all types of Systems. In reality, these four types of increased Complexity will actually have interdependencies, which, in turn, will also increase the overall Complexity. For example, the increase in the Complexity of the System Elements will also lead to a complexity shift and, potentially, an increase in the System of Systems Complexity, which, in turn, will lead to an increase in the number of Constraints.

Identifying Complexity

The key to managing Complexity is identifying where the Complexity lives in a System. This is a topic that will be followed up throughout the book, particularly when artifacts and models are discussed.

The next section discusses the problems associated with communication, which, alongside Complexity and understanding, is one of the Three Evils of Systems Engineering.

Communication

Communication is key to successful Systems Engineering. It has already been discussed that Systems Engineering naturally brings together people from multiple and disparate backgrounds, which will lead to an increase in potential communication problems. Poorly-specified information, Language, and protocols lead to ambiguity, which will lead to poor or inefficient communication.

Communication can exist at many levels, such as the following:

• Between people: The obvious form of communication is between people. People interacting with other people is key to any successful project and is a matter that is more complex than it first appears, as will be discussed in this section.
• Between and within organizations: A successful business relies on different organizations or organizational units within the same company being able to communicate effectively. The media for these communications may be through documents, agreements, contracts, and so on but the same communication problems will occur.
• Between and within Systems and System Elements: It is essential that the Systems that are relied upon for our business and projects can also communicate effectively. This includes IT systems, other technical systems, and service-based systems, to name but a few.

When thinking about communication, another way to think about it is that communication must be effective and efficient between all Stakeholders, whether they are represented by people, organizations, or things (such as Systems). When considering communication in the world of Systems Engineering, it is inter-Stakeholder communication that is being addressed.

These communication problems are further compounded by the fact that communication can also exist between these different types, such as between people and Systems, people and organizations, and so on.

Defining common Languages

One of the main solutions that is vaunted for improving communication is to get all parties to “speak a common Language.” This is an obvious solution and an important one, but speaking a common Language is actually more complex than it may at first appear.

When considering a common Language, there are actually two types of Language that must be defined, as shown in the following diagram:

Figure 1.14: Aspects of the common Language

The diagram in Figure 1.14 shows that Stakeholders communicate using a Language, so it is essential that this Language is as clear and unambiguous as possible. This Language, however, has two aspects: Spoken Language and Domain-Specific Language.

The first aspect that will be considered is that of the Spoken Language, which provides a basic mechanism for communication. An example of Spoken Language is the fact that this book is written in the English Language. In order to understand the information in this book, it is essential that the reader can speak English. Clearly, there are many more spoken Languages than the English Language, but the decision that has been made for this book (or System) was to select English as the chosen Spoken Language. This is clearly an obvious decision that needs to be made, but just because everyone reading this book speaks English does not mean that there will be no ambiguity or misunderstandings. This is because the second aspect of Language that needs to be considered is Domain-Specific Language.

Domain-Specific Language defines the specific concepts and terminology that will be used for a given application or domain. For example, consider the word “function.” The word “function” is a common English Language word but a word that will actually take on different meanings, depending on which Stakeholder is reading it.

It is essential that the Domain-Specific Language is defined, as it forms the cornerstone for successful Systems Engineering. This chapter actually defines the Domain-Specific Language for Systems Engineering that is used throughout this book. Each diagram in this chapter contributes toward defining the full set of concepts and the associated terminology that is used for Systems Engineering in this book.

Languages for Systems Engineering

When it comes to Languages that can be used for Systems Engineering, both the Spoken Language and the Domain-Specific Language must be defined:

• In terms of the Spoken Language, there are several standard Languages that can be adopted that are used throughout the industry across the world, such as the Unified Modeling Language, Systems Modeling Language, and Business Process Modeling Notation, among others. For the purposes of this book, the Spoken Language that has been selected is the Systems Modeling Language (SysML), which will be discussed in more detail in Chapter 2, Model-Based Systems Engineering.
• In terms of the Domain-Specific Language, this will be different for every organization. A generic Domain-Specific Language for Systems Engineering is defined in this chapter and used throughout this book, and may be used as a basis for readers to use in a Language that fits their specific business.

Both types of Language must be defined for successful Systems Engineering.

The next section discusses the problems associated with understanding, which, alongside complexity and communication, is one of the Three Evils of Systems Engineering.

Understanding

It is essential that all Stakeholders share an understanding of the System; however, different Stakeholders will perceive the System in different ways due to their different backgrounds and knowledge, which creates a potentially large problem. This problem may be addressed by considering the concept of “Context.” In order to understand the concept of Context, consider a set of generic Stakeholders, as shown in the following diagram:

Figure 1.15: Generic set of Stakeholders

The diagram in Figure 1.15 shows a generic set of Stakeholders associated with the car System.

There are three broad categories of Stakeholder, which are as follows:

• Customer, which represents the set of roles that will ultimately benefit from the System that is being developed. The diagram here shows that Customer has two types, which are User, such as the Driver of the vehicle, and Operator, such as the Maintainer of the vehicle.
• External, which represents the set of roles that have an interest in the System that will limit or restrict the system in some way. The diagram here shows that there is a single type of External Stakeholder, which is Standard.
• Supplier, which represents the set of roles that are interested in developing and delivering the Systems, such as Engineer.

The identification of Stakeholders is an essential part of Systems Engineering, as it is this complete set of Stakeholders whose expectations need to be understood and managed, rather than just the end user of the System.

When considering the complete set of Stakeholders, it should be kept in mind that different Stakeholders may look at the same System and perceive different Needs or, as in almost all Systems, they may look at the same Need and interpret it in a different way, depending on their point of view. When something is interpreted in a different way from a different point of view, this is referred to as a “Context.”

The concept of Context is one of the single most important aspects of representing a System that must be understood for successful Systems Engineering, yet is one that is often overlooked or ignored altogether.

In order to illustrate this crucial concept of Context, imagine that there is a statement of Need associated with a System, which is the System must be safe. At first glance, this may seem like a straightforward statement with little or no room for ambiguity, but the actual meaning of this statement will be different for each of the different Stakeholders. For example, from the point of view of the Driver, this statement may be interpreted as the car must have seatbelts, airbags, driver-assist technology, and so on. From the point of view of the Maintainer, this statement may mean that the Drive Train must be developed in such a way that the battery can be turned off to ensure that no parts of the car are live when maintaining the vehicle. From the point of view of the Standard Stakeholder, there may be several safety aspects, such as meeting specific requirements for crash impact. Finally, from the point of view of the Engineer, the system may have to satisfy a number of scenarios relating to the safety case for the vehicle.

The point here is that there are multiple interpretations for the same set of Needs. In order to manage the expectations of all Stakeholders, it is important that all of these different points of view, or Contexts, can be understood.

Now that the Three Evils of Systems Engineering have been discussed, it is time to consider the implementation of Systems Engineering

The implementation of Systems Engineering

In order to implement Systems Engineering successfully, there are three aspects of implementation that must be considered, which are shown in the following diagram:

Figure 1.16: The classic systems engineering mantra – People, Process, and Tools

The diagram in Figure 1.16 shows three main concepts: People, Process, and Tools. These are referred to as the Systems Engineering Mantra (Holt and Perry, 2019).

These three concepts are very important, but it is the relationships between them that provide a true understanding of what information is being conveyed. It is important that these People enable the overall Process, as the competencies associated with the People are worth nothing if they do not enable the overall approach. Also, the overall approach must drive the choice of Tools, rather than the Tools affecting the Process.

These concepts are expanded upon in the following diagram:

Figure 1.17: Expanded concepts of People, Process, and Tools

The diagram in Figure 1.17 shows the expanded concepts that were first introduced in Figure 1.16. By considering each of the main concepts in turn, it is possible to enhance the original descriptions:

• People: It is the Competence of the people that is of interest, rather than the presence of the people themselves. It is essential that people have the appropriate sets of knowledge and skills and the attitude that is required to do the task at hand effectively and efficiently. It is also important not to confuse the concept of People with that of Stakeholders. As was discussed previously, People may hold any number of Stakeholder roles and it is the Competence associated with these roles that may be thought of as the ability of the individual.
• Process: It is the overall approach that is being followed, rather than just a set of individual processes. The term Process here may be thought of as the overall ability of the organization or organizational unit to carry out a specific task.
• Tools: The set of software, resources, or, in fact, anything that is intended to allow People to carry out their Process in a more effective or efficient manner. Such Tools may include software design and modeling tools, management tools, pen and paper, standards, notation, and so on.

Overall, it is important that there is a balance between People, Process, and Tools to enable successful Systems Engineering.