[SE] System Architectural Design Guidelines

Hi there! Nice to meet you again in the #SystemsEngineering series.

In my previous post, I have shared my understanding about Types of requirement in Systems Engineering - which is belong to the part SYS.2: System Requirement Analysis in the ASPICE process. So in this article we will continue investigating the necessary development steps in the SYS.3: System Architectural Design in the ASPICE process.

1. ASPICE Overview

The ASPICE development model starts with the SYS.1?Requirements Elicitation process where the customer’s stakeholder requirements are received, analyzed, discussed, and understood.

• Using the customer’s stakeholder requirements as a foundation, the system requirements are created, updated, and reviewed during the SYS.2 System Requirements Analysis process.
• Trailing a little behind SYS.2 activities, system tests are developed and linked during the SYS.5 System Qualification Test process providing early feedback about the system requirements.
• Next, during the SYS.3?System Architectural Design process, the system’s architecture is designed and documented. System integration tests are developed in parallel during SYS.4 System Integration and Integration Test.

The cycle repeats in software: SWE.1 develops software requirements, SWE.6 develops their tests. SWE.2 designs the software architecture and SWE.5 works on software integration tests. At the bottom, the tip of the “V”, the SWE.3 Software Detailed Design and Unit Construction process focuses on the details of the software design and actual programming while creating unit tests for the SWE.4 Software Unit Verification process.

When looking at the entire development process, a pattern of linking between previous and next processes (and to the right’s tests) emerges. Each link (up/down, left/right) provides traceability to why this or that is the way it is and gives an opportunity for review and feedback.

Defined for each ASPICE process is a set of “base practices”. Following and implementing the base practices, and providing evidence, is essentially how an organization shows compliance with ASPICE.

Note #1: The base practices cover the essential activities that ensure a system and its software is developed in a sane and traceable manner. However?ASPICE does not stipulate?how?to conform to its base practices.

2. SYS.3: System Architectural Design Development Guidelines

From Wikipedia, the free encyclopedia [1], a System Architecture is defined as following:

A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.         

In the reference [2], the authors also define:

"The system architecture design defines system behavior and structure characteristics in accordance with derived requirements.? The architecture ensures that the system elements operate together in the applicable operating environment to satisfy Stakeholder needs."

Note #2: The keyword of a system architecture attributes are: structure, behavior, and views.

So we can understand that: The architecture of a system reflects how the system is used and how it interacts with other systems and the outside world. It describes the interconnection of all the system’s components and the interface between them. The architecture of a system reflects the way it is thought about in terms of its structure, functions, and relationships.

Several types of systems architectures (underlain by the same fundamental principles) have been identified as follows [1]:

• Hardware architecture
• Software architecture
• Enterprise Architecture
• Collaborative system architectures (such the Internet, intelligent transportation systems, and joint air defense systems).
• Manufacturing system architectures .
• Strategic system architecture .

In an automotive ECU, a systems architecture makes use of elements of both software and hardware and is used to enable the design of such a composite system.

Note #3: While Hardware architecture describes the physical structure of the product and interconnection of HW elements, then Software architecture is a set of principles that define the way software components (SWCs) are designed and developed, and data link between them. Software alone is not a system!

2.1 Developing the system architecture

The ASPICE-SYS.3 process is a key part of the system engineering activities, typically undertaken after the system requirements have been defined and documented. It focuses on the design of the system architecture in such a way that it aligns with the requirements, considers trade-offs, and is capable of satisfying performance, safety, and regulatory standards.

The main goal is to define a clear and structured architecture for the system that facilitates:

• Integration of subsystems
• Management of interfaces
• Verification of design decisions
• Support for further detailed design and development

While the system requirements define WHAT a system should do, the system architecture define HOW this should be accomplished, and HOW the system should be structured. Usually, the development of requirements and architecture overlap at system level. With a well-established product, the architecture is often already in place and not many changes are required.

For example: Supplier X is developing an ECU for Traction Inverter for customer Y. The supplier X has a well-established ECU architecture platform. In the new project, 90% of the system architecture can be carried over and just a small percentage needs to be newly developed, such as the housing and connectors.

Note #4: Neglecting non-functional requirements as an input is a typical mistake when developing a system architecture, such as: performance, safety, security, testability, portability, etc.

2.2 How the system architecture should be structured?

System architecture diagrams provide a visual illustration of a system's various components and show how they communicate and interact with each other. These diagrams document a system's structure and architecture. This allows for a clear understanding of how the system works and how it can be improved.

In general, system architecture views can include:

• The default is the static architecture view or diagram which breaks the system down into its elements/modules (or sub-system), and describes the interconnection between them. This helps to map the requirements and allocate the work to teams and individuals.
• The dynamic architecture view (typical mistake, if missing) which models the behavior of the system. This means systems engineer must consider the system operation modes (modeled or described by State Machine Diagram, such as: Start-up, Ready, Standby, Run, Shutdown, Failure mode, etc.), and other runtime behavior may be modeled by modeling methods such as: Sequence diagrams, Use Case Diagrams, State transition diagram, etc. See in more details about these methods in [3].
• In addition, depending on the modeling tool, there may also be a functional architecture view that shows how functionalities relate to each other. Functionalities are modeled with concepts such as features, sub-features, functions, etc. which are linked to the corresponding requirements on one side and to the elements of the static architecture on the other. In this way, the requirements drive the development of the architecture.

Note #5: The architecture model includes multiple views of the system design features with the information necessary to address each stakeholder’s viewpoint and concerns.?

Interfaces exists between interacting system elements/components and between the system and its operating environment. Considering what the nature of a system is and the most of the internal interfaces are between engineering disciplines or Hardware-Software Interface (HSI).

The system architecture is the basic for the System Integration and Integration Test (SYS.4), which requires a clear and complete definition of dynamic behavior and interfaces (typical mistake, if missing or poorly described).

2.3 Traceability between system requirements (SYS.2) and system architecture (SYS.3)

It is part of the architecture process that engineers consider which new architectural elements are needed or which existing architectural elements can implement the requirements (or requirements clusters). Depending on the modeling tool this can be done by connecting requirements to functional architecture elements and from there to static architecture elements. This is referred to as "Allocation of requirements to System elements". This allocation may be tentative because it is a creative process and engineers are discussing alternatives. But once they have decided, traceability must be established - this is how SYS.2 and SYS.3 are linked together.

Note #7: System architecture ensures requirements compliance and it is the implementation blueprint of a product as well.

In summary, the Key Objectives of SYS.3

1. Define System Architecture:

• The system architecture must be defined based on the requirements and constraints that were gathered in earlier phases.
• This includes defining the main components, subsystems, and their interconnections, as well as how they will work together to meet the system requirements.

2. Allocate Requirements:

• The system architecture should allocate functional and non-functional requirements to different parts of the system (components, subsystems, etc.).
• Requirements related to safety, performance, and reliability should be considered during this allocation process.

3. System Design Decisions:

• The architecture involves making key decisions about how different parts of the system will interact and how design trade-offs (e.g., cost vs. performance) will be handled.
• Identify critical system design parameters and constraints.

4. Traceability:

• Every design decision should be traceable back to the original system requirements.
• This traceability is essential for ensuring that the system architecture will meet the original requirements and can be verified and validated throughout the development process.

5. System Validation and Verification Planning:

• At this stage, a plan should be developed to verify and validate that the system architecture fulfills the requirements and works as intended in real-world conditions.

6. Risk Management:

• Identify risks associated with the system architecture and plan for mitigation strategies.
• Address safety, security, and regulatory compliance concerns.

A system architectural design approach is proposed in [2] showing in the Figure 3:

3. Practical Steps for Compliance with ASPICE SYS.3

To ensure compliance with ASPICE, you'll need to demonstrate the following:

1. Documentation: Maintain clear, consistent, and detailed records of all decisions, models, and analysis performed.
2. Traceability: Ensure that there is full traceability from the requirements through to the architecture and that each architectural decision is linked back to the original requirements.
3. Design Reviews: Conduct regular design reviews to evaluate the architecture against requirements, risks, and constraints. Ensure that these reviews are documented.
4. Verification & Validation: Plan for how the system architecture will be verified and validated once implemented. This includes test strategies, acceptance criteria, and relevant methodologies.
5. Continuous Improvement: Apply lessons learned and continuously improve the architectural design process, incorporating feedback from verification activities.

4. Conclusion

Systems architecture refers to the conceptual blueprint of a system, outlining its structure, components, interactions, and behavior. It serves as a fundamental framework that guides the development, integration, and management of various subsystems within a larger system. By providing a holistic view of the system, it enables efficient decision-making and ensures the alignment of technology with business goals.

SYS.3: System Architectural Design is a critical process in ASPICE, as it directly influences the system’s ability to meet stakeholder requirements and regulatory standards. To ensure ASPICE compliance, your team must rigorously follow a structured design approach that includes requirements analysis, architecture definition, traceability, verification planning, and reviews. By thoroughly documenting decisions and implementing a robust review process, your system architecture will meet both the technical and process-related demands of ASPICE.

P/S: In ISO 26262, the System Architecture Design process is a key part of ensuring functional safety in automotive systems. It lays the foundation for creating a safe and reliable system architecture that can meet both functional and safety requirements throughout the system lifecycle. The System Architecture Design phase, as defined in Part 3 of ISO 26262 (specifically, in "Concept phase" and "System level design"), involves translating safety goals into system architecture, ensuring that the safety requirements are met, and considering various fault conditions that might affect the system. You can refer one of my previous article [5] to know more details the role and position of System Architecture Design (SyAD) in Technical Safety Concept development to be compliant with ISO26262.

Finally, thank you for reading this quite long article. And I hope that it's helpful for you while practicing ASPICE and ISO26262 in your application. As usual, I'm looking forward to hearing your different opinions or your additional comments about this topic.

References:

[1] https://en.wikipedia.org/wiki/Systems_architecture

[2] System Architecture Design Definition, SEBoK: Guide to the Systems Engineering Body of Knowledge.

[3] [SE] An Introduction to SysML (System Modeling Language) by Duong Tran

[4] https://www.edrawsoft.com/article/system-architecture-diagram.html

[5] Understanding about Technical Safety Concept (TSC) Development by Duong Tran

[6] https://www.alooba.com/skills/concepts/systems-architecture/#:~:text=Systems%20architecture%20plays%20a%20vital,bottlenecks%20and%20improving%20overall%20performance.

[7] https://www.orientsoftware.com/blog/system-architecture/