Considering Safety Requirements Based on ISO 26262 in Model-Based Optimization of Automotive Electrical/Electronic Architectures

Abstract

Considering safety requirements while developing electrical and electronic （E/E） architectures is a prerequisite for the realization of future technologies such as autonomous driving. Following the ISO 26262 standard， safety analyses have to be conducted in the early phase of the development lifecycle in order to detect design flaws and take actions to improve the design. This paper presents a model-based approach for addressing safety requirements conforming to ISO 26262 during the design phase of automotive E/E architectures. Based on the requirements， a set of safety-related constraints is extracted， which can be used in an integer linear programming （ILP） model to optimize E/E architectures.

Keywords

functional safety; E/E architecture; optimization; model-based development

The number of functions and complexity in E/E architectures are increasing due to the transition to Advanced Driver Assistance Systems （ADAS） and autonomous vehicles. Future vehicles are expected to have a centralized architecture in which several high-performance general-purpose Electronic Control Units （ECU） control multiple functions^［1］. The new requirements rising out of these technological innovations lead to an increase in the design complexity of automotive E/E architectures. Safety is one of the key requirements that must be considered during the design phase of future vehicles. Currently， model-based development approaches are drawing the attention of car manufacturers and suppliers as a solution to master design complexity. Therefore， integrating safety concepts into model-based E/E architecture design plays a crucial role to overcome the aforementioned challenges^［2-3］.

ISO 26262 “Road vehicles―Functional safety” is an adaption of the functional safety standard IEC 61508 for the automotive domain^［4］. The safety life cycle according to ISO 26262 influences all phases of vehicle development. Until now， ensuring ISO 26262 compliance is a time-consuming process that is mostly done manually. In this paper， we present a generic framework for model-based optimization of automotive E/E architectures based on safety constraints. There are several studies that present model-based approaches to optimize E/E architectures concerning various attributes， including cost， weight， and power consumption^［5-7］. However， only a few studies take reliability and safety aspects into account. In Ref.［8］， the authors present an approach for optimizing E/E architectures based on reliability. The authors in Ref.［9-10］ took a step further and considered both automotive safety integrity level （ASIL） and reliability requirements. In Ref.［11-12］ ILP formulations are presented to optimize architecture topology and resource allocation in a central computing platform， respectively. Although these studies focused on safety attributes， there are still other safety-related requirements， such as timing requirements， that have yet to be considered. Therefore， we aim to extract constraints from safety requirements in accordance with ISO 26262. These constraints can be added to an ILP optimization model in order to generate a safe architecture. This may bring us one step closer to automating E/E architecture design.

Fig.1 illustrates our approach to integrating ISO 26262 safety requirements into the development process of E/E architectures. The development process follows the well-known V-model. In this paper， we are focusing only on the design process， which means the left branch of the V-model.

Fig. 1  Integrating ISO 26262 safety requirements into the V-model

At the beginning of the development process， functional and non-functional requirements are documented. The next level， i.e.， the function design level， deals with the functions of the vehicle and their interactions. As shown in Fig.1， functional safety requirements according to ISO 26262 are identified during these phases. Based on the hazard analysis and risk assessment， required ASIL levels for each function or a set of functions are determined. Another important aspect in the development of current E/E architectures is timing. Many functions have certain timing constraints. Currently， most automotive functions are distributed functions. At the function design level， timing requirements for function chains， which refer to end-to-end timing constraints， are identified. These are safety-related requirements that must be fulfilled^［13］.

At the next levels， software architecture and hardware topology are designed， respectively. The allocation of functions/software components on hardware nodes is one of the factors that influences the quality of the designed system. According to ISO 26262， safety requirements should be assured when mapping software to hardware components. Consequently， the deployment process is getting even harder when considering the conflicting constraints and the growth in the complexity of architectures^［7］. Therefore， using an optimization algorithm can be helpful to solve this issue and automate this task. An exemplary mapping of the functional network model to a component network model is depicted in Fig.2.

Fig. 1  Exemplary function architecture model; hardware architecture model and a deployment candidate

1 System modeling

This section introduces the parameters of our function and hardware model. These parameters are the input of the optimization algorithm and are summarized in Tab.1. Our model is inspired by the approach in Ref.［5］.

1.1　Hardware component specifications

The hardware model consists of a few general-purpose ECUs and communication buses. Although the real architectures contain sensors and actuators， we are not defining them in our model. This is because the mapping of functions to sensors and actuators is not meaningful. However， their effect on the deployment process is considered as localization constraint， which is explained in the next section. As can be seen in Table 1， we denote a set of ECUs as E=｛E₁，…，E_n｝. The ASIL level that E_k supports is considered as A_k. The number of ECU cores and the size of its memory， expressed in MB （megabyte）， are defined as C_Ek and M_Ek， respectively. Our model supports two communication buses， CAN and Ethernet. The data transmission rates of the buses are defined as dr_CAN and dr_ETH. Since the failure rates of the buses are lower than those of the ECUs， we refrain from considering their values in reliability analysis.

Tab.1  Hardware and software architecture parameters

Hardware components
E=｛E1，…，En｝	Set of all ECUs
CEk	Number of CPU cores of Ek
MEk	Memory of Ek
λk	Failure rate of Ek
Ak	ASIL level of Ek
drCAN ， drETH	Data transmission rate of CAN and Ethernet
Software components
S=｛S1，…，Sm｝	Set of all Software components
CSi	Required CPU cores of Si
MSi	Required memory of Si
Li	ASIL level of Si
WCET（i，k，h）	WCET of Si on Ek and ASIL Lh
Fij	Frequency of Si

1.2　Software components specifications

The function model consists of some unmodifiable software components with defined specifications and the connections between them. As shown in Tab.1， we denote a set of software components as S=｛S₁，…，S_m｝. The amount of data being transferred from function S_i to S_j is considered as ds（S_i，S_j）. As already mentioned， for each software component S_i an ASIL level L_i is assigned during software design phase. We defined the Worst-Case Execution Time （WCET） of S_i running on E_k and ASIL L_h as WCET（i，k，h）. Some software components may be executed periodically. Hence， we considered the variable F_ij to express the frequency of S_i with regard to S_j.

2 Extraction of safety constraints

This section explains the formulated requirements， which can be used as constraints for an ILP optimization problem. According to ISO 26262， four ASIL levels， from ASIL A to D， are defined to represent the stringency of safety requirements. ASIL A represents the least and ASIL D dictates the most stringent requirement. In the future， most of the software components are expected to be safety-critical， which means ASIL C or D. However， there are a few available ECUs that can support high ASIL levels. Therefore， action must be taken to enable the mapping of such software functions to these ECUs， while verifying ASIL compatibility. ISO 26262 introduces ASIL decomposition technique to reduce the required ASIL level of a software component by dividing it into multiple redundant components， each with a lower ASIL value^［4］. In order to verify ASIL Compatibility， following constraint is defined：

$\forall E_k\in E,\forall S_i\in S$：

$$Y_{ik}·L_i\le A_k$$

（1）

In the above constraint， L_i is an integer value between 1 and 4， which L_i=1 represents ASIL A and L_i=4 represents ASIL D. We assume Y_ik=1， if S_i is mapped to E_k. If the above constraint is not satisfied， an ASIL decomposition， similar to the approach in Ref.［9］， should be performed. In this case， another constraint should be defined to prevent the execution of redundant software components on the same ECU. Another requirement that should be satisfied is timing constraint. When designing a software architecture， an end-to-end timing requirement can be defined for a software component chain. Constraint （2） ensures that the end-to-end timing requirement T for the function chain $S^{\text{'}}\subseteq S$is fulfilled.

$\forall E_k\in E,\forall S_i\in S^{\text{'}}$：

$$\sum \mathrm{M}\mathrm{a}\mathrm{x}\left(Y_{ik}·\mathrm{W}\mathrm{C}\mathrm{E}\mathrm{T}\left(i,k,h\right)\right)+t_{\mathrm{c}\mathrm{o}\mathrm{m}}\le T$$

（2）

Due to the redundancy caused by ASIL decomposition， there might be different paths for the defined functional chain. Therefore， we consider the maximum reaction time for a functional chain to guarantee the fulfillment of the timing requirement. In the above constraint， t_com refers to the data transfer time between corresponding ECUs and can be estimated using equations （3） and （4）. We assume that the communication buses between ECUs are identified in the hardware architecture. We store the ECUs that only have a CAN interface in$E^{\text{'}}$.

$\forall E_k\in E,\forall (S_i,S_j)\in S^{\text{'}}\left|Y_{ik}=Y_{jk}=\mathrm{1}\right.$：

$$t_{\mathrm{c}\mathrm{o}\mathrm{m}}=\mathrm{0}$$

（3）

$\forall E_k\in E^{\text{'}},\forall (S_i,S_j)\in S^{\text{'}}$：

$$t_{\mathrm{c}\mathrm{o}\mathrm{m}}={\displaystyle \sum _{\left(S_i,S_j\right)\in S^{\text{'}}}^{}}[(Y_{ik}+Y_{jk})·\frac{\mathrm{d}\mathrm{s}\left(S_i,S_j\right)}{\mathrm{d}{\mathrm{r}}_{CAN}}+$$

$$+(\mathrm{1}-\left(Y_{ik}+Y_{jk}\right))·\frac{\mathrm{d}\mathrm{s}\left(S_i,S_j\right)}{\mathrm{d}{\mathrm{r}}_{\mathrm{E}\mathrm{T}\mathrm{H}}}]$$

（4）

The reliability of S_i running on E_k with L_h is ［9］：

$$R\left(S_i,E_k,L_h\right)={\mathrm{e}}^{-{\lambda }_k\mathrm{W}\mathrm{C}\mathrm{E}\mathrm{T}(i,k,h)}$$

（5）

Equation （6） can be used to ensure the fulfillment of reliability constraint for the whole system. This equation is valid only for systems without redundancy. If performing ASIL decomposition and consequently adding redundant components is needed， then the approach introduced by Ref.［9］ can be used to calculate reliability of the system.

$$\prod _{S_iϵS:Y_{ik}=\mathrm{1}}R\left(S_i,E_k,L_h\right)\ge R_{\mathrm{r}\mathrm{e}\mathrm{q}}$$

（6）

In order to verify that ECUs provide sufficient CPU cores and memory for software components which run on them， constraints （7） and （8） can be used^［5］.

$\forall E_k\in E$：

$${\sum }_{S_i\in S}^{}{Y}_{ik}{C}_{S_i}\le C_{E_k}$$

（7）

$${\sum }_{S_i\in S}^{}{Y}_{ik}{M}_{S_i}\le M_{E_k}$$

（8）

A localization constraint， equation （9）， can be defined to prevent deploying a software component on a particular ECU. For example， loc（S₂）=E₁ means that S₂ should not be executed on E₁.

$\forall E_k\in E,\forall S_i\in S\left|E_k\in \mathrm{l}\mathrm{o}\mathrm{c}\left(S_i\right)\right.$：

$$Y_{ik}=\mathrm{0}$$

（9）

Constraint （10） ensures that an ECU has sufficient CPU capacity to execute its tasks. In order to satisfy CPU utilization constraint， it must be ensured that the CPU utilization doesn't exceed its threshold value （U_t）.

$\forall E_k\in E$：

$$\frac{\mathrm{1}}{C_{E_K}}\sum _{S_i\in S}{Y}_{ik}\cdot \mathrm{W}\mathrm{C}\mathrm{E}\mathrm{T}\left(i,k,h\right)\cdot F_{ij}\le U_t$$

（10）

In addition to the above constraints， an objective goal such as minimizing cost can be added to an optimization problem. Minimizing cost can be formulated as follows：

$$\mathrm{m}\mathrm{i}\mathrm{n}\sum _{S_i\in S}\mathrm{c}\mathrm{o}\mathrm{s}\mathrm{t}(S_i,L_h)$$

Our proposed workflow is depicted in Fig.3. The output of the optimization algorithm is a cost-effective safe candidate for the deployment problem.

Fig.3  Workflow of the proposed approach

3 Conclusion and future work

In this paper， a model-based approach for function mapping and E/E architecture optimization based on safety constraints for future centralized architectures is presented. We derived safety requirements that are not application-specific from ISO 26262 and formulated them as ILP-based constraints. By adding these constraints and an optimization objective such as cost to an optimization algorithm， achieving a cost-effective safe architecture is possible. We consider the presented work as a first step and we are aware that our approach is far from complete. In future， we will apply this model to AMPL tool and a solver （CPLEX or Gurobi）， to find the best solution for our ILP optimization problem.