[Systems Engineering] #5. Understanding Systems engineering

Introduction of Understanding Systems Engineering

In this post, we will explore systems engineering.

To help you understand the definition of systems engineering, let’s first look at definitions from several sources.

GPT: Systems engineering is the process of planning, designing, and managing complex systems, where many parts come together to achieve a greater purpose. For example, automobiles require the work of systems engineers, who are responsible for understanding how each part works and affects each other and aligning them toward an overall goal. This is important for complex systems to function efficiently.
ISO/IEC 15288: Systems engineering is a multidisciplinary approach to developing high-quality systems that meet the requirements of stakeholders considering the entire life cycle.
EIA/IS-632: Systems engineering is a multidisciplinary approach that includes all technical activities necessary to develop and validate integrated, life cycle balanced systems that meet customer needs.
IEEE P1220: Systems engineering is a multidisciplinary, collaborative research approach that derives, develops, and validates life cycle balanced system solutions that meet customer expectations.
Matlab – TechTalk: Systems engineering is a process for developing complex projects efficiently, where ‘efficient’ means minimizing rework, detecting errors early, and communicating effectively. It is the process of looking at a system as a whole, understanding its interaction with the outside world and the influences between its internal components. Additionally, it plays an important role in the engineering processes required to build and achieve project goals.

If you look at these definitions carefully, there are some common keywords:

Stakeholder requirements considering life cycle
High quality and balanced system
Multidisciplinary approach

In conclusion, systems engineering is a multidisciplinary approach that translates the needs of various stakeholders into balanced system solutions.

Now that you have a general idea of what systems engineering is, let’s talk about it in more detail.

Understanding Systems Engineering : The complexity of modern systems and the need for systems engineering

Challenges of multidisciplinary projects : Modern systems are expected to deliver high performance and cost-effectiveness in a variety of fields. However, when the project spans multiple disciplines, it becomes a major challenge. Creating and coordinating interfaces between disciplines is a complex challenge. Misunderstandings and conflicts that arise in these multidisciplinary projects are common problems.

Difficulty in finding the optimal solution : What’s interesting is that the best solution in each area may not be the best solution for the entire system. The lack of overall vision of the project causes these problems. For example, cost-cutting measures in one department may reduce the efficiency of another department.

History and Importance of Systems Engineering : Systems engineering is a discipline that has been addressing these problems for over 50 years. This discipline considers the complex relationships between elements in a system (Complexity) and the number of elements (Intricacy). Complexity and Intricacy are key challenges in this discipline, and systems engineers use a variety of techniques and approaches to solve these problems.

Understanding Systems Engineering : So, What is systems engineering?

Systems engineering is a multidisciplinary approach to developing balanced system solutions for the needs of a system’s diverse stakeholders.

Systems engineering applies both management and technical processes to achieve this balance and mitigate risks that may affect the success of a project.

Systems engineering management processes are applied to ensure that development cost, schedule, and technical performance objectives are met. Typical management activities include planning technical efforts, monitoring technical performance, managing risks, and controlling system technical baselines.

Systems engineering technical processes are applied to specify, design, and verify systems. The practice of systems engineering is not static and is constantly evolving to address increasing requirements.

In other words, it is a life cycle process that not only addresses the requirements of the end product we want to develop through the systems engineering technology process, but also effectively develops, implements, tests, operates, maintains, and disposes of this end product. It is important to also consider the requirements of the enabling product through the systems engineering management process.

If you look closely, you can see that standards such as A-SPICE, ISO-26262 (Functional Safety), and ISO/SAE-21434 (Cyber Security), which give us headaches in the field, are also made up of management and technology processes.

For example, in A-SPICE, the Systems Engineering Process Group (SYS) and Software Engineering Process Group (SWE) are the representative technical processes, and the remaining parts are management processes to ensure the completeness of the system we will deliver. For reference, in the case of functional safety, Parts 2 and 8 can be considered management processes, and Parts 3, 4, 5, 6, and 7 can be considered technical processes. (As you can see here, functional safety seems to be more focused on technical processes.)

The systems engineering management process is effectively the PM’s responsibility. That’s why we, as systems engineers, are more interested in technical processes.

This picture is a diagram showing the entire processes of A-SPICE. You can see that A-SPICE is also based on system engineering. and Understading A-SPICE is helpful in Understanding Systems Engineering — The entire process of A-SPICE

Understanding Systems Engineering : Technology Process

This Picture shows a simplified view of the System engineering technical process. — a simplified view of the systems engineering technical process

The figure above is a simplified view of the systems engineering technical process.

The system specification and design process is used to specify system requirements and assign configuration requirements to meet stakeholder needs. The component is then designed, implemented, and tested to ensure that it meets the requirements.
The System Integration and Test process includes activities that integrate components into a system and ensure that system requirements are met. These processes are applied iteratively throughout system development, with continuous feedback between the different processes.
In more complex applications, there are multiple levels of system decomposition, starting at the enterprise or System Of System level. In these cases, a variation of this process is applied recursively to each intermediate level of design, up to the level at which components are purchased or manufactured.

In particular, “System Specification and Design,” which is the main task of a systems engineer (like me), includes the following activities to provide a balanced system solution that takes into account the requirements of various stakeholders.

Elicit and analyze stakeholder requirements to identify problems to be solved, goals the system is intended to support, and effectiveness measures needed to evaluate how effectively the system supports those goals. Understand the metrics.
- Systems engineers must first identify stakeholders and analyze their needs (problems to be solved, goals the system is intended to support). Stakeholders include customers, project managers, software and hardware developers, system users, production and maintenance personnel, and laws or regulations. Obviously, the interests of each stakeholder are not of equal importance in the development of the system, so the importance of each requirement must be weighted appropriately.
- Analysis is needed to define effectiveness indicators for each requirement to determine whether stakeholder requirements have been appropriately implemented. Not only is this used to constrain the solution space, evaluate alternatives, and differentiate from competing solutions, but it also serves as a measure of whether we have implemented the system correctly.
Supports goals and effectiveness measurements by specifying the system’s required functions, interfaces, physical and performance characteristics, and other quality characteristics.
- System requirements are defined taking into account stakeholder requirements and relevant effectiveness measures. This begins by defining the System Boundary to establish clear interfaces between the system and external systems and users. External systems, users, and the physical environment must be specified to clearly indicate system boundaries and their interfaces.
- Functional requirements are specified by analyzing what the system must do to support the overall goals of the system. Functional requirements analysis also includes specifying the sequence and sequence of functions. Additionally, functional requirements must be evaluated to determine the level of performance required.
- Additionally, non-functional requirements must be analyzed to address stakeholder concerns. Non-functional requirements include performance, security, safety, availability, and reliability.
- System requirements must be clearly linked to the needs of stakeholders and validated to ensure that the requirements address their needs. Early and ongoing involvement of representative stakeholders is critical to the success of the overall development effort.
Break down the system design into components to synthesize alternative system solutions that can meet system requirements.
- System design involves identifying system components and specifying the requirements for those components needed to meet system-level requirements. This may involve first developing a logical system design that is independent of the technology, and then developing a physical system design that reflects the specific technology choice.
- Solutions are often subject to design constraints. A common kind of constraint is to reuse certain components.
- Components are specified so that if their requirements are met, the system requirements are also met. The performance and physical requirements of a component are derived by performing an engineering analysis to determine what is needed from the component to meet system requirements.
Perform trade-off analysis to select the preferred solution that provides the optimal balance to meet system requirements and achieve overall effectiveness measures.
- System design alternatives are evaluated to determine the preferred system solution that achieves a balanced design that addresses multiple competing requirements.
Maintain traceability from system goals to system and component requirements and the design of each component to system verification results to ensure requirements and stakeholder requirements are met.
- Component requirements are input into the Component Design, Implementation, and Test process in the picture above. Component developers can provide feedback or request that configuration requirements be reassigned to the systems engineering team to ensure that the configuration requirements can be met by their design. This is an iterative process throughout development that is often necessary to achieve a balanced design solution.
- System test cases are also defined to ensure that system requirements are met. As part of the System Integration and Test process, verified components are integrated into the system and system test cases are executed to ensure that system requirements are met.
- As shown in the figure below, requirements traceability is maintained between Stakeholder Needs, System Requirements, and Component Requirements to ensure design integrity.

This Picture show requirements traceability

As expected, these are processes we have experienced a lot while working with the current A-SPICE or functional safety process. As engineers who design systems, we derive, collect, and develop requirements from various stakeholders, including customers, create SR (Sourcing Requirement) documents, and discuss with customers to confirm the top-level requirements of the system.

And from these requirements, we derive the requirements of the system we will develop, that is, system requirements, and write a system requirements specification. These system requirements specifications include functional and non-functional requirements and specific attributes for each requirement, as described above. And finally, based on these system requirements, we identify the components of the system through system design, that is, system architecture creation, specification, and process, derive the requirements for each component, and create a system design specification. . Based on this, each engineering expert builds it, and the project manager manages the project through a management process to prevent problems during this process.

In this way, the work we do as systems engineers in the automotive electronics industry is not much different from general systems engineering.

Outro of Understanding Systems Engineering

Systems engineering is so broad that what is explained in this post accounts for less than 10% of systems engineering. And also, since I’m not an expert in this field, this article made me think, “Oh, this is what we’re doing in the electronics industry!?” I hope you can feel the extent. I will end this post by sharing three additional pieces of information about systems engineering below.

In the next post, we will discuss our role: systems engineer.

Should all systems be developed through systems engineering as mentioned above? Systems engineering provides a useful solution when the problem you are trying to solve is so complex that you cannot fully figure out how to design it without first breaking it down into smaller components. In other words, a simple system may not need to be developed through systems engineering.
Some challenges in systems engineering
- New problems arise when a system is decomposed into its components. Now we need to consider what is the best way to simplify this complexity, that is, how best to decompose the system functionally, logically, and physically.
- What should each component do to meet the requirements of the higher-level system?
- How do we ensure that all components are compatible with each other and ultimately meet the requirements of the project, even if different people build them in different locations and at different times?
Systems engineering is a side job. For example, architecture description, review, and trade-off research are additional tasks. In other words, it is completely separate from the work that needs to be done to develop and build the system. So why should systems engineering be applied to automotive electronics?

In other words, automotive electronics are becoming increasingly complex. If the system you are developing is very complex, you will need requirements reviews, architecture diagrams, and everything else. The additional time and effort required for systems engineering will be less than the time and effort required to rework and modify a system that was not initially designed and defined correctly.
You probably think that if we were to participate in a project, we would first brainstorm what we wanted to do, figure out all the parts roughly, and then design and build the components on our own. And if there is any question as to whether the interaction between components will be carried out properly, you may think that it can be resolved through discussion among the people in charge.
This is systems engineering. It was just explained in very small units. Everyone is a systems engineer on a small project.
Because the problem is simple, a group of engineers can share all important information in a collective memory or temporary memo so everyone can work toward the overall goals of the project. However, problems arise in complex projects where the high-level goals and interdependencies between different functions and components are unclear or too numerous for an ad-hoc approach to suffice.
Therefore, we need to use processes and tools to decompose the system into reasonable components and design how these components should interact with each other, what they should do, and how they should be tested. Additionally, model-based methods allow you to quickly evaluate your system and quickly arrive at an effective design.