EN 
DE Systematically identify safe and cost-effective solutions
Authors: Dr. Ulrich Becker, Method Park; Dr. Isabella Stilkerich, Schaeffler Technologies; Dr. Ralf Münzenberger, INCHRON
Contribution – Embedded Software Engineering Congress 2017
An increasing number of embedded systems are safety-critical, often characterized by a combination of high availability and strict real-time requirements. Safety and assistance functions in the automotive sector are a typical example of this system category. If real-time requirements are considered only late in the process, costly changes to the system, software, and hardware architecture often result. This article presents a consistent approach from safety analysis through functional architecture to technical architecture. Safety-relevant causal chains are identified, end-to-end real-time requirements are assigned, and time budgets are derived. Various technical architecture variants can be derived from the functional architecture. These architectural variants can be simulated with regard to their real-time characteristics and systematically evaluated, enabling the selection of the optimal variant in terms of both safety and cost.
As a case study, a fictitious pedestrian airbag system (FABSY) is used, designed to protect pedestrians from physical injury in a collision with a car. The system detects when a collision between the vehicle and a pedestrian is unavoidable and, in this case, deploys a pedestrian airbag mounted in the front of the vehicle.
In considering functional safety, in addition to the heThe desired airbag deployment should also take into account that a andThe desired triggering could endanger vehicle occupants and other road users. Analysis of the FABSY function reveals strict real-time requirements, for example, regarding the timing of airbag deployment.
Hazard and risk analysis
The hazard and risk analysis defines the safety objectives that must be observed throughout the entire subsequent development process. These safety objectives are assigned a criticality indicator, ranging from... Amotor Safety Iintegrity LSafety Integrity Level (ASIL) A (low critical) to ASIL D (highly critical). For FABSY, this means specifically: "Prevent unintended airbag deployment" (Safety Objective 1/ASIL D), and "If a collision with a pedestrian is unavoidable, guarantee airbag deployment" (Safety Objective 2/ASIL B).
Functional architecture
In functional architecture, FABSY is broken down into functional blocks from a purely functional perspective, and their interaction is described. Examples of functional blocks include image acquisition and pedestrian detection.
The functional architecture abstracts from the concrete technical implementation. It leaves open which control unit and which technology a functional block is implemented on. This allows for different variants of the technical system architecture, which can then be systematically compared.
The functional blocks inherit their ASIL from the safety objectives they help implement – for example, person detection receives ASIL D. However, a function like person detection cannot be guaranteed with the reliability required for ASIL D using either cameras or radar. This can be addressed in the functional architecture itself with the architectural measure "ASIL decomposition": The chain from image acquisition to the decision to deploy the airbag is implemented redundantly using different technologies. The airbag is only deployed if radar-based and Camera-based detection leads to the same decision. If the radar- and camera-based subsystems do not unintentionally interfere with each other ("freedom from interference"), the ASIL of these functional blocks can be reduced from ASIL D to ASIL B (D).
(see. PDF, Image 1)
Technical architecture
The technical architecture describes the specific technical implementation and forms the basis for the technical safety concept. It describes which control units are involved and how they are networked; it also shows how the functional blocks are distributed across the control units.
The previous section on functional architecture already addressed the concept of freedom from feedback, which now needs to be established in the technical architecture. This is the basis for redundancy techniques and ASIL decomposition. It relates to three aspects, which are also listed in Part 6 of ISO 26262:
- Spatial isolation of the components
- Temporal isolation of the components
- Secure exchange of information between components
Isolation means that potential failures in one component cannot propagate to other components. Isolation domains can be established through physical separation as well as through software- and hardware-based techniques. The selection of suitable mechanisms falls within the realm of architectural decisions in the various disciplines. system, software and Hardware.
The decision for one option or the other is based on the functional and non-functional properties of the respective solutions, as well as on considerations of functional safety within the framework of Failure Mode and Effects Analysis (FMEA). In the following, we assume that these analyses have already been carried out.
Within the context of this case study, an integrated architecture and a federated architecture are now considered as exemplary alternatives:
- Variant "Dedicated ECUs": In this federated architecture, the camera- and radar-based pathways are executed on the dedicated Camera ECU and Radar ECU. The plausibility checks for the two trigger decisions and the actual airbag deployment take place on the FABSY ECU. Using dedicated ECUs allows for very good hardware isolation of the two pathways.
- Variant „CDAC ECU“: This integrated architecture utilizes a high-performance CDAC (Central Driver Assistance Controller) control unit. All processing, from image acquisition to the decision on airbag deployment, is performed on the CDAC ECU for both camera- and radar-based pathways. Decision validation and airbag deployment are handled by the FABSY ECU, as in the „Dedicated ECUs“ variant. Consolidating radar and camera processing, as well as potentially other driver assistance functions, onto a single high-performance control unit can offer advantages in terms of cost, weight, and installation space; however, it necessitates measures in the system and software architecture to isolate the pathways.
The different technical architecture options can be evaluated based on their ability to meet real-time requirements, hardware costs, and other criteria. However, for a more cost-effective option to be viable, it is crucial that all real-time requirements are met.
Real-time requirements
The FABSY system must meet strict real-time requirements: Certain tasks have a deadline by which they must be completed. must, Otherwise, system functionality and the associated security objectives cannot be guaranteed. We consider the following real-time requirements as examples:
- Correct scheduling must be ensured and multiple activations prevented.
- The latency between a pedestrian entering the car's path and the airbag being triggered must not exceed 150 ms.
A model-based analysis of the dynamic behavior makes it possible to ensure early on that no systematic temporal errors are contained in an architecture.
Analysis at different architectural levels
An initial evaluation of the variants can already be carried out at the functional architecture level: From the functional architecture, causal chains are derived, and time budgets and activations are assigned to the individual functional blocks. Even with such a hardware-independent timing model based on a causal chain, an initial verification of requirement 2 is possible.
A detailed analysis of the technical architecture is performed in a hardware-dependent manner, taking into account, among other things, the following properties in a timing model:
- Buses (FlexRay, CAN)
- ECUs, processors and cores
- Assignment of software components and tasks
- Tasks, mapping of tasks/ISRs to CPUs and cores
- Scheduling properties of tasks
The first three points must be taken into account in accordance with ISO 26262 Part 4 when verifying the system design, points four and five in accordance with ISO 26262 Part 6 when verifying the software design.
The following describes how the variants of the technical architecture are analyzed, optimized, and verified.
Evaluation of the two variants
Real-time errors often occur during the initial design of a system or software architecture. The allocation of software components and tasks, as well as the scheduling properties of the tasks, are degrees of freedom that can be changed relatively easily. At the same time, these properties have a strong influence on compliance with real-time requirements.
In an efficient development process, these properties are analyzed and optimized using a model-based approach. Creating a timing model, verifying requirements, and making necessary architectural optimizations are integral parts of the development process.
To account for scheduling in the detailed analysis, task execution times are specified as net times, meaning the pure execution time of a task without interruptions. Often, the net execution times of the software cannot be measured on the target processor during the design phase because an implementation does not yet exist. In this case, the net execution times are defined as time budgets. These budgets can be based on specifications, expert estimates, or measurements from previous projects.
A timing model based on the technical architecture allows requirements to be verified before implementation using a suitable analysis tool (Verification of system design, ISO 26262-4). Here, the verification of requirement 1 (correct scheduling, no multiple activations) is a direct result of a scheduling analysis. For requirement 2, however, a causal chain is modeled, abstractly describing the data flow. Each step in this causal chain is a relevant communication point where data is buffered, read, and subsequently processed or written. For each triggering event (in the case of requirement 2, the occurrence of an object), a new instance of the causal chain is created during the simulation, and its requirements are verified.
In image 2 (see. PDFThe analysis of the dynamic behavior is shown as output from the real-time simulator chronSIM. An instance of the chain of events (ochre lines) from requirement 2 is depicted: After an object enters the system, the radar data (upper part of the chain) and the camera data (lower part of the chain) are processed, transmitted via a CAN or FlexRay bus to the FABSY ECU, validated, and finally, the airbag is deployed.
The presented approach allows for efficient optimization of the technical architecture. After just a few optimization iterations, it becomes clear that both variants ("Dedicated ECU" and "CDAC ECU") meet their real-time requirements. The decision can then be made based on further criteria, such as cost.
Further steps can refine the real-time model. The presented top-down specification approach, which considers task properties and scheduling, can be supplemented by a bottom-up analysis. This allows experimentation with different resource allocation configurations. Incorporating application-specific information enables more optimistic predictions about the program's real-time performance on specific hardware. Furthermore, predefined time budgets can be refined based on measurement data.
Conclusion
The presented approach enables a cost-effective comparison of different architectural variants, software and hardware configurations, and implementations in the context of ISO 26262 and hard real-time. The described approach positively impacts security requirements, quality characteristics, and cost considerations.
authors
Dr. Ulrich Becker He works as a trainer, consultant, and coach at Method Park. He is involved in various client projects focusing on software architecture, application lifecycle management, and improving development processes.
Dr. Isabella Stilkerich She works as a software architect and researcher in the field of e-mobility at Schaeffler Technologies AG & Co. KG. Her main areas of expertise are real-time systems, embedded systems, functional safety, and AUTOSAR.
Dr.-Ing. Ralf Münzenberger He is responsible for Professional Services at INCHRON GmbH. He has advised clients on more than 160 projects regarding timing and performance, architecture optimization, and functional safety.
Our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.
Training & coaching on the other topics in our portfolio can be found here. here.
Quality, Safety & Security – Expertise
Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
