Linked Knowledge Nuggets: arrow_forward "Designing for maintainability from day one"
personAuthor: Process Fellows
Think maintenance when architecting. Clear structures, good naming, minimal duplication, and comments that explain why (not what). Maintainability isn’t added later — it’s built in.
arrow_forward "System Architectural Design"
personAuthor: Process Fellows
SYS.3 – System Architectural Design defines a logical, technology-independent system structure based on requirements. It balances static and dynamic aspects while ensuring traceability and a robust foundation for implementation.
school
PF_SYS.3_System Architectural Design_Extract.pdf Short Overview of the SYS.3 System Architectural Design Process covering base practices, some examples and a comparion between Automotive SPICE® version 3.1 and 4.0
arrow_forward "Systems Engineering - Why the heck do we need this?"
personAuthor: Alexander Feulner
The increasing complexity, shortened development times, distributed development, heightened cost pressures, technological change, and organizational transformations are just a few of the challenges facing the current development.
If these statements seem unfamiliar to you, we congratulate you warmly. For all those who are confronted with these challenges on a daily basis, we present the methodology of ‘Systems Engineering’ in our webinar and answer the question: "Why the heck do we need this?". This webinar is tailored not only for system developers but also for professionals in various domains including software development, hardware development, testing, project management and more.
school
Webinar recording and slides
arrow_forward "The role of the architect"
personAuthor: Process Fellows
Not a bureaucrat, but a facilitator. Someone who translates goals into structures, moderates conflicts, aligns toolchains, and keeps the big picture stable across sprints and handovers. By the way, this is true for product related architects as well for process architects.
# PROCESS PURPOSE
The purpose is to establish an analyzed system architecture, comprising static and dynamic aspects, consistent with the system requirements.
# PROCESS OUTCOMES
O1
A system architecture is designed including a definition of the (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) with their behavior, their interfaces, their relationships, and their interactions.
O2
The system architecture is analyzed against defined criteria, and special characteristics are identified.
O3
Consistency and bidirectional traceability are established between system architecture and system requirements.
O4
The agreed system architecture and the special characteristics are communicated to all affected parties.
# BASE PRACTICES
BP1
Specify static aspects of the system architecture. (
O1 )
Specify and document the static aspects of the system architecture with respect to the functional and non-functional system requirements, including external interfaces and a defined set of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) with their interfaces and relationships.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a functional system architecture, a logical system architecture and a physical system architecture?"
personAuthor: Process Fellows
There are various approaches available how to define a system architecture. One exemplary approach uses views like a functional architectural view, a logical architectural view and a physical architectural view.
Functional Architecture:
The functional architecture defines what the system must do. It describes the system’s functions, their inputs and outputs, and how they interact to fulfill the system’s purpose. This level is technology-independent and focuses purely on the capabilities and behavior of the system.
Example: A car’s functional architecture might include functions like “accelerate,” “brake,” “steer,” and “monitor speed.”
Logical Architecture:
The logical architecture defines how the system functions are logically grouped and interact. It introduces logical components and their interfaces, but still remains independent of the concrete physical parts. It serves as a bridge between functional needs and physical realization.
Example: In the car example, logical components might include “Powertrain Control Unit,” “Brake Control Module,” and “User Interface Module,” each responsible for a set of functions. So, it could be decided already that there is the need e.g. for a CPU, but this is more like a categorization and it is not about picking a concrete physical part!
Physical Architecture:
The physical architecture defines with what the system is implemented. It maps the logical components to real hardware, software or mechanical parts, including e.g. sensors, actuators, processors, and communication buses. This level is technology-specific and considers constraints like cost, space, and performance.
Example: The “Brake Control Module” might be implemented using a specific microcontroller, connected to wheel speed sensors and hydraulic actuators.
arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP2
Specify dynamic aspects of the system architecture. (
O1 )
Specify and document the dynamic aspects of the system architecture with respect to the functional and non-functional system requirements including the behavior of the (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) and their interaction in different system modes. Note 1: Examples of interactions of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus systems.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a functional system architecture, a logical system architecture and a physical system architecture?"
personAuthor: Process Fellows
There are various approaches available how to define a system architecture. One exemplary approach uses views like a functional architectural view, a logical architectural view and a physical architectural view.
Functional Architecture:
The functional architecture defines what the system must do. It describes the system’s functions, their inputs and outputs, and how they interact to fulfill the system’s purpose. This level is technology-independent and focuses purely on the capabilities and behavior of the system.
Example: A car’s functional architecture might include functions like “accelerate,” “brake,” “steer,” and “monitor speed.”
Logical Architecture:
The logical architecture defines how the system functions are logically grouped and interact. It introduces logical components and their interfaces, but still remains independent of the concrete physical parts. It serves as a bridge between functional needs and physical realization.
Example: In the car example, logical components might include “Powertrain Control Unit,” “Brake Control Module,” and “User Interface Module,” each responsible for a set of functions. So, it could be decided already that there is the need e.g. for a CPU, but this is more like a categorization and it is not about picking a concrete physical part!
Physical Architecture:
The physical architecture defines with what the system is implemented. It maps the logical components to real hardware, software or mechanical parts, including e.g. sensors, actuators, processors, and communication buses. This level is technology-specific and considers constraints like cost, space, and performance.
Example: The “Brake Control Module” might be implemented using a specific microcontroller, connected to wheel speed sensors and hydraulic actuators.
arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP3
Analyze system architecture. (
O2 )
Analyze the system architecture regarding relevant technical design aspects related to the product lifecycle, and to support (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) management regarding (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) estimates, and derive special characteristics for non-software (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
). Document a rationale for the system architectural design decisions. Note 2: See MAN.3.BP3 for (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) feasibility and MAN.3.BP5 for (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) estimates. Note 3: Examples for product lifecycle phases are production, maintenance and repair, decommissioning. Note 4: Examples for technical aspects are manufacturability for production, suitability of pre-existing (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) to be reused, or availability of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
). Note 5: Examples for methods being suitable for analyzing technical aspects are prototypes, simulations, and qualitative analyses (e.g., FMEA approaches) Note 6: Examples of design rationales are proven-in-use, reuse of a product platform or product line), a make-or-buy decision, or found in an evolutionary way (e.g., set-based design).
Linked Knowledge Nuggets: arrow_forward "Analysis of an architectural design"
personAuthor: Process Fellows
The analysis of an architectural design is a substantive examination of the quality of an architecture.
It should never depend on the background knowledge or experience of a single person.
For this reason, the analysis must involve a (interdisciplinary) team of experts, be based on predefined criteria and the analysis method should be documented in a comprehensible manner.
Examples of analysis criteria can be found in the Automotive Spice Guideline, but please do not hesitate to define additional criteria that are appropriate to the task and the environment!
BP4
Ensure consistency and establish bidirectional traceability. (
O3 )
Ensure consistency and establish bidirectional traceability between the elements of the system architecture and the system requirements that represent properties or characteristics of the physical end product. Note 7: Bidirectional traceability further supports consistency, and facilitates impact analysis of change requests, and demonstration of (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other. Note 8: There may be non- (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.) that the system architectural design does not trace to. Examples are do not address, or represent, direct properties or characteristics of the physical end product. Such requirements are still subject to (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.).
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP5
Communicate agreed system architecture. (
O4 )
Communicate the agreed system architecture, including the special characteristics, to all affected parties.
# OUTPUT INFORMATION ITEMS
15-51
Analysis results (
O2 )
Identification of the object under analysis.
The analysis criteria used, e.g.:
selection criteria or prioritization scheme used
decision criteria
quality criteria
The analysis results, e.g.:
what was decided/selected
reason for the selection
assumptions made
potential negative impact
Aspects of the analysis may include
correctness
understandability
verifiability
feasibility
validity
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
MAN.5 Risk Management
MAN.6 Measurement
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
PIM.3 Process Improvement
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
13-52
Communication evidence (
O4 )
All forms of interpersonal communication such as
e-mails, also automatically generated ones
tool-supported workflows
meeting, verbally or via meeting minutes (e.g., daily standups)
podcast
blog
videos
forum
live chat
wikis
photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Management of Products for Reuse
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Performance Management
13-51
Consistency Evidence (
O3 )
Demonstrates bidirectional traceability between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g.,
tool links
hyperlinks
editorial references
naming conventions
Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain, e.g., by
performing pair working or group work
performing by peers, e.g., spot checks
maintaining revision histories in documents
providing change commenting (via e.g., meta-information) of database or repository entries
Note: This evidence can be accompanied by e.g., Definition of Done (DoD) approaches.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
17-57
Special Characteristics (
O2 )
Special Characteristics in terms of relevant standards such as IATF 16949, VDA 6.x Guidelines, ISO 26262.
Special Characteristics according to IATF 16949:2016-10 [15], Chapters 8.3.3.3, are product characteristics or production process parameters that may have an impact on safety or compliance with official regulations, the fit, the function, the performance or further processing of the product.
Special characteristics shall be verifiable according to VDA vol. 1
Note: A typical method for identifying and rate special characteristics is an FMEA.
Used by these processes:
HWE.2 Hardware Design
SYS.3 System Architectural Design
04-06
System Architecture (
O1 )
A justifying rationale for the chosen architecture.
Individual behavior of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
)
Interrelationships between (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
)
Settings for system parameters (such as (Application parameter = An application parameter is a software variable containing data that can be changed at the system or software levels; they influence the system’s or software behavior and properties. The notion of application parameter is expressed in two ways:
The specification (including variable names, the domain value range, technical data types, default values, physical unit (if applicable), the corresponding memory maps, respectively).
The actual quantitative data value it receives by means of data application.
Application parameters are not requirements. They are a technical implementation solution for configurability-oriented requirements.))
Manual/human control actions, e.g., according to STPA
Interface Definitions:
Technical characteristics of interfaces for relationships between two (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
)
Interfaces between (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) e.g.:
bus interfaces (CAN, MOST, LIN, Flexray etc.)
thermal influences
(Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-software-interfaces (HSI), see below
electromagnetic interfaces
optical interfaces
(Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-mechanical-interfaces (e.g., a cable satisfying both mechanical and electrical requirements, housing interface to a PCB)
(Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-mechanical interconnection technology such as connectors, pressfit
creepage and clearance distances
Fixations such as adhesive joints, screw bolts/fitting, riveted bolts, welding
System interfaces related to EE (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) e.g.:
analogue or digital interfaces (PWM, I/O) and their pin configurations
SPI bus, I2C bus, electrical interconnections
placement, e.g., thermal interfaces between (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.) (heat dissipation)
soldering
creepage and clearance distances
Interfaces for mechanical engineering e.g.:
friction
thermal influences
tolerances
clutches
fixations such as adhesive joints, screw bolts/fitting, riveted bolts, welding
forces (as a result of e.g., vibrations or friction)
placement
shape
A (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-software interface, e.g.:
connector pin configurations and floating IOs for μCs/MOSFETs
signal scaling and resolution to be reflected by the application software
Mechanical- (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) interfaces e.g.
such as mechanical dimensioning
positioning of connectors
positioning of e.g., hall sensors in relation to the bus-bar
tolerances
Dynamics of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) and system states:
Description of the system states and operation modes (startup, shutdown, sleep mode, diagnosis/calibration mode, production mode, degradation, emergency such as “limp-home”, etc.)
Description of the dependencies among the system components regarding the operation modes
Interactions between (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) such as inertia of mechanical components to be reflected by the ECU, signal propagation and processing time through the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) and software and e.g., bus systems
Explanatory annotations, e.g., with natural language, for single elements or entire diagrams/models.
SYS.3
System Architectural Design
