ASPICE (Automotive SPICE) and ISO 26262 are critical frameworks in the development of safety-critical automotive systems, such as electronic control units (ECUs) and autonomous driving functionalities. Both standards emphasize the importance of architectural models for system and software development, but they differ slightly in focus and scope. ASPICE is primarily concerned with process improvement and maturity in software engineering, while ISO 26262 focuses on functional safety in automotive systems. Together, these frameworks provide a structured way to ensure that complex automotive systems are developed safely and efficiently.
In this article, we will discuss the architecture topologies that are compliant with ASPICE and ISO 26262, and explain how these topologies support Model-Based Systems Engineering (MBSE). We will also explore how these topologies can be scaled to support highly complex systems, such as those found in electric vehicles (EVs), autonomous driving platforms, and advanced driver-assistance systems (ADAS).
1. Understanding ASPICE and ISO 26262 Architectures
ASPICE Architecture Overview
ASPICE defines a structured process reference model for software and system development, helping automotive organizations achieve a high level of process maturity. The V-Model (a variation of the traditional waterfall model) is frequently used in ASPICE-compliant projects. This model emphasizes traceability from requirements to system verification, ensuring a clear flow from design to implementation.
Key Elements of ASPICE Architecture:
- System Requirements and Analysis: High-level requirements are captured, focusing on both functional and non-functional aspects of the system.
- Software Requirements and Architecture: Breaks down system-level requirements into software-specific requirements, forming the basis of software design.
- Software Design and Implementation: Structured to ensure traceability back to the system and software requirements.
- Testing and Validation: Verification at multiple levels (unit, integration, and system) to ensure compliance with the specified requirements.
ISO 26262 Architecture Overview
ISO 26262 mandates a functional safety architecture that focuses on mitigating risks caused by system failures. The standard introduces the concept of ASIL (Automotive Safety Integrity Levels) to classify and manage safety-critical functions. A robust safety architecture ensures that the system meets the necessary safety requirements throughout the development lifecycle.
Key Elements of ISO 26262 Architecture:
- Hazard and Risk Analysis (HARA): Identifies potential hazards and assesses their risks based on severity, exposure, and controllability.
- Functional Safety Concept: Translates safety goals into technical safety requirements, leading to the definition of a safety architecture.
- Technical Safety Requirements and Architecture: Defines the technical safety measures required to meet the system’s functional safety goals.
- Verification and Validation: Ensures that the implemented safety mechanisms comply with the defined technical safety requirements.
2. Architecture Topologies for ASPICE and ISO 26262 Compliance
Functional -> Logical -> Technical -> Component Architecture (FLTC)
This architecture pattern, commonly used in Model-Based Systems Engineering (MBSE), provides a layered approach for mapping system requirements to detailed designs and implementations. It follows a hierarchy that starts with high-level functional requirements and ends with concrete components.
| Level | Description |
|---|---|
| Functional | Captures the high-level system goals and the primary functionalities that the system must deliver. |
| Logical | Translates the functional requirements into logical models (block diagrams, SysML models) showing interactions between different subsystems. |
| Technical | Defines the technical requirements (e.g., processor speed, memory limits) necessary to implement the logical design. |
| Component | Maps the technical architecture to physical components, such as ECUs, sensors, actuators, and software modules. |
Diagram: Architecture Topology (FLTC)
graph TD
A[Functional Level] --> B[Logical Level]
B --> C[Technical Level]
C --> D[Component Level]In this layered architecture, each step builds on the previous, providing clarity and structure for the system development lifecycle. This approach ensures that:
- ASPICE requirements for traceability and modularity are respected.
- ISO 26262 functional safety requirements are addressed by integrating safety mechanisms at both the technical and component levels.
3. Benefits of Architecture Topologies for Model-Based Engineering
3.1 Improved Traceability
Both ASPICE and ISO 26262 emphasize traceability—the ability to trace requirements from high-level objectives to implementation and testing. The layered approach in FLTC ensures that every component is linked back to a functional or safety goal, making it easier to verify that the system meets both safety and performance criteria.
3.2 Scalability for Complex Systems
As systems become more complex—particularly with the advent of electric vehicles and autonomous driving—this architecture topology remains scalable. MBSE tools like Enterprise Architect, SysML, and PREEvision can manage this complexity by providing system-wide visibility into the relationships between components, subsystems, and safety-critical features.
| Tool | Role in Architecture Development |
|---|---|
| Enterprise Architect | Manages system models, requirements, and traceability across the entire system architecture, supporting both ASPICE and ISO 26262. |
| PREEvision | A powerful tool for developing and visualizing architecture, particularly for electric and autonomous vehicles. |
| Simulink | Provides detailed simulations of system components, making it easier to test functionality before physical testing. |
3.3 Alignment with ISO 26262’s Safety Mechanisms
The component level in the FLTC topology is critical for implementing ASIL-rated safety mechanisms. This is where components that handle safety-critical tasks (such as ECUs or brake control systems) are designed with redundancy, fault detection, and diagnostic capabilities in mind.
4. Scaling the Architecture for Highly Complex Systems
As the complexity of automotive systems grows, especially with advancements in autonomous vehicles (Level 4/5), electric powertrains, and V2X communication, scaling the architecture becomes crucial. The following practices ensure that architecture topologies can handle this complexity:
4.1 Modularization and Abstraction
To manage complexity, systems can be modularized into smaller, independent units. Each module should handle a specific function and interact with other modules through clearly defined interfaces. This approach ensures that changes in one part of the system do not cascade into other subsystems.
| Level | Example in EV System |
|---|---|
| Functional | High-level function such as battery management or vehicle propulsion. |
| Logical | Interaction between subsystems, e.g., the battery interacting with the powertrain control. |
| Technical | Specifications such as battery voltage, controller power ratings, and communication protocols. |
| Component | Physical components like Battery Management System (BMS) or ECU for power control. |
4.2 Safety Partitioning for ISO 26262
For ISO 26262, complex systems can be partitioned to segregate safety-critical from non-safety-critical components. This not only simplifies the safety validation process but also reduces the cost of developing and certifying non-critical parts.
| ASIL Level | Example |
|---|---|
| ASIL D | Critical functions like autonomous emergency braking (AEB) require the highest level of safety assurance. |
| ASIL A | Less critical functions such as infotainment controls can be developed with less rigorous safety constraints. |
5. How Model-Based Systems Engineering (MBSE) Supports These Architectures
MBSE is central to managing the complexity of systems built around ASPICE and ISO 26262 frameworks. MBSE tools like SysML, Enterprise Architect, and Simulink help model the functional, logical, and technical aspects of the system, ensuring that all safety and performance requirements are met.
| MBSE Benefit | How it Supports ASPICE/ISO 26262 Compliance |
|---|---|
| Traceability | Ensures that all components can be traced back to safety goals, facilitating easier safety audits. |
| Simulation and Testing | Enables early validation through simulation, reducing the need for costly physical prototypes and identifying potential hazards early. |
| Requirements Decomposition | Breaks down high-level safety and functional requirements into smaller, manageable tasks, ensuring that nothing is overlooked. |
Conclusion
By leveraging architecture topologies like Functional -> Logical -> Technical -> Component in the context of ASPICE and ISO 26262, organizations can achieve both process maturity and functional safety. These topologies help ensure that complex automotive systems are scalable, traceable, and meet the necessary safety standards, while Model-Based Systems Engineering (MBSE) provides the tools to manage this complexity efficiently.
Scaling this architecture for highly complex systems like EVs, ADAS, and autonomous vehicles ensures that as automotive technology evolves, safety and performance standards are met without increasing development costs or time-to
-market, engineers can continue to meet the functional safety and process maturity requirements of modern vehicle platforms. This ensures safety, performance, and reliability, while handling the increased complexity that new technologies demand.