For more information and inquiries about the conference, please contact “Niu Xiaoka” WeChat: NewCarRen
Abstract
With the development of autonomous driving, vehicles are experiencing significant multidimensional innovations across various automotive specialties. In particular, the amount of software used in embedded safety-critical systems is rapidly increasing to realize new functions. Therefore, safety analysis must be conducted according to automotive standards today to ensure software safety. These analyses enable engineers to assess the safety of designs and determine whether modifications are needed to meet safety objectives. However, faced with the complexity of today’s automotive software architectures, traditional methods for performing these analyses are both cumbersome and limited. Currently, safety analysis is performed manually, and the results depend on the experience of safety experts. As a result, they are highly subjective and do not guarantee thoroughness. To overcome these issues, this paper explores the use of model-based safety approaches in the context of safety-critical automotive embedded software. We propose a methodological suggestion that relies on software architecture models to build dedicated safety models, from which safety analyses can be automatically derived. The method has been experimentally tested in case studies.
1. Introduction
Our society is undergoing profound technological and social changes, with vehicles (cars, drones, etc.) becoming increasingly automated. Their architectures involve multiple cyber-physical systems, which embed numerous software components to achieve this autonomy. In this context, society needs to ensure and safeguard vehicle safety, thereby ensuring system and software safety. In the automotive field, software safety analysis is currently based on traditional manual techniques. The quality of the analysis, with a focus on general quality standards, primarily depends on the experience of safety experts. Safety analysis is not truly formalized and does not even allow for partial reuse, sometimes providing approximate safety assurances. Therefore, in this ever-changing context, it is necessary to improve current industrial practices to better address societal and economic issues.
On the other hand, the current trend in engineering is to adopt model-based approaches. They can enable formal analysis, better communication and collaboration between interdisciplinary teams, rapid prototyping and simulation, and improve reusability. Thus, using model-based approaches to assess software safety seems promising, as it will help address current issues related to safety-critical software analysis.
Therefore, the purpose of this paper is to explore the feasibility of using model-based approaches for safety analysis of embedded automotive software. To achieve this goal, this paper first outlines model-based approaches and emphasizes their interest in software engineering and safety assessment. It compares the state of scientific knowledge in the field of automotive software engineering with the state of industrial practice to identify areas for improvement in software safety analysis practices. We propose a methodological suggestion that includes automatically generating software safety analyses based on specially constructed safety models. Then, we provide the application results of this proposal in a real case study where the lateral control software component is part of the autonomous driving software, functioning to keep the vehicle within the lane. Finally, we point out some interesting research avenues to further develop this work.
2. Model-Based Approaches in Software Engineering and Safety
The growing complexity of systems necessitates the implementation of development methods to control cost, time, and quality. Traditional, document-centric, and test-based approaches are inadequate for developing multidisciplinary and distributed intelligent systems. Model-based (or model-driven) approaches address this complexity through a model-centered, front-loaded engineering methodology that focuses on creating and utilizing domain models as the primary means of information exchange among engineers, rather than relying on document-based information. This section quickly reviews the principles and hot topics of model-based approaches in software engineering, followed by their use in safety analysis.
2.1 Model-Based Software Engineering
Model-Based Systems Engineering (MBSE) is defined as “the formal application of modeling to support system requirements, design, analysis, verification, and validation activities, starting from the conceptual design phase and continuing through development and later lifecycle phases.” This definition also applies to software engineering, where MBSE is proposed as a promising software development method to overcome the limitations of traditional programming-based approaches. MBSE advocates the use of modeling languages to describe software abstractly; it is used for modeling requirements, functionalities, and physical architectures, but it also supports simulation, code generation, and verification by providing methods for automatically generating various development artifacts (such as code and documentation) from models.
2.2 Model-Based Safety Assessment
Model-Based Safety Analysis (MBSA) applies MBSE techniques to support safety analysis. However, while MBSE models the nominal (non-failure) functional behavior of systems, MBSA models their failure (malfunctioning) behavior. In fact, the purpose of safety analysis is to determine whether the modeled system has weaknesses. Executing them can analyze whether the failure of system components would lead to severe failures at the system level, or identify the possible root causes of system failures. To achieve this goal, safety engineers draw conclusions from traditional models (e.g., FMEA or FTA) that they manually elaborate based on the available system specifications and design artifacts produced during the design phase.
Adopting model-based approaches in safety engineering includes constructing models of system functional malfunctioning that show the system behavior when failures occur (reasoning through failure propagation), from which traditional analyses (minimal cuts, FTA, and FMEA) can be derived. This particularly allows for easily and quickly generating new safety analyses in cases where the system architecture changes, thereby reducing costs and improving the quality of the safety analysis process.
2.2.1 MBSA Methods
MBSA methods can be classified based on two main criteria: the construction of malfunctioning models and the semantics of component interfaces.
The first criterion relates to the process of defining safety models and their relationship with system design models: malfunctioning models can be extensions of design models or dedicated models. We found an example of an extended model, where a nominal functional model was first constructed during the design process, and failure modes were added for the purpose of safety analysis. The main advantage of the model extension approach is the consistency in construction between safety analysis and system design models. Additionally, development and safety processes can share common modeling environments, languages, and tools. However, it has some drawbacks. One is that it does not allow independence between system and safety models. In the case of dedicated models, safety engineers construct a unique “independent” malfunctioning model based on their understanding of the information available in design documents and functional models. The main advantage of this approach is that it is more pragmatic to implement, as it ensures independence and separation of concerns (between safety and engineering disciplines). However, one of its drawbacks is the need for supplementary means to ensure consistency with the design model.
The second criterion relates to the semantics of malfunctioning models (component behavior) and the type of information passed through component interfaces (nominal flow or failure flow). This criterion leads to distinguishing between Failure Logic Modeling (FLM) (using failure flow) and Failure Effects Modeling (FEM) (using nominal flow). Early proposals adopted the FEM approach, but with the development of disciplines, FLM has become prevalent, and most pioneering MBSA methods (e.g., FPTN, HiP-HOPS, and AltaRica) rely on it.
Various modeling languages support MBSA. Some are dedicated to safety, such as AltaRica, SAML, or Figaro. Others are multipurpose modeling languages (e.g., UML) and architecture description languages (e.g., AADL or EAST-ADL) that extend their core semantics and syntax to support safety analysis through configuration files and error attachments.
2.2.2 AltaRica Language
AltaRica is a high-level modeling language dedicated to risk analysis, supporting safety, reliability, and performance analysis. In AltaRica, model elements are represented as nodes. Each node consists of states, events, transitions, and assertions. States are declared using domains. A domain is an enumeration that contains multiple states. Currently, several tools support AltaRica: OCAS, Simfia, SimfiaNeo, Open AltaRica, and AltaRica Studio.
In summary, among the current MBSA methods, we find the use of dedicated models and the FLM approach to be the most interesting, as it adopts safety-oriented modeling; when combined with dedicated models, this can ensure independence between system design and safety (which is a critical requirement for system certification). For the case study analysis, we chose AltaRica due to its simplicity and proven practicality in system environments. However, it remains to be seen whether AltaRica can adapt well to software failure modeling.
3. Automotive Practices in Software Engineering and Safety Assessment
3.1 Document-Based Software Development Process
The automotive software development process centers around two standards: ASPICE (quality) and ISO 26262 (functional safety). ASPICE (Automotive SPICE) is a standard that provides guidance for improving software development processes and evaluating suppliers. ISO 26262 “Functional Safety of Road Vehicles” is the standard for functional safety of electrical and/or electronic systems in automotive production. It provides references for the automotive safety lifecycle. It also defines Automotive Safety Integrity Levels (ASIL), representing the severity of automotive hazards and the rigor applied when specifying and implementing safety requirements and measures. ASIL ranges from A to D, with D representing the most stringent level, A the least stringent, and QM (Quality Management) assigned to projects that have no impact on safety. ISO 26262 is divided into 11 parts; Part 6 discusses the development of products at the software level (more specifically targeting the software engineering environment).
Figure 1 shows the ISO 26262 phase model for software-level product development. The left side of the cycle covers the “Software Safety Requirements Specification,” “Software Architecture Design,” and “Software Unit Design and Implementation” phases. Software safety requirements are often informal, expressed in natural language, and managed through tools like Rational DOORS. In the software architecture design phase, the use of semi-formal modeling languages (such as UML) to support design and analysis remains quite immature and unskilled. Therefore, the software architecture design process primarily relies on informal models and natural language descriptions. However, in the software unit design phase, tools like Simulink can be effectively used for prototyping, simulation, and code generation.
The right side of the cycle includes the “Software Unit Verification,” “Software Integration and Verification,” and “Embedded Software Testing” phases. The purpose of each phase is to verify and validate whether the corresponding left-side (design phase) stages have been implemented as required. As shown by the arrows in Figure 1, traceability is maintained between relevant phases.
3.2 Document-Based Safety Assessment Process
In current automotive practices, the document-based safety assessment process is conducted as part of the design process and follows ISO 26262. This process involves manually constructing safety files and safety analyses in document templates (Excel, Word, PowerPoint formats). Unfortunately, these analyses are highly subjective and depend on the skills of the engineers. Their traceability to design artifacts is primarily maintained through naming conventions and sometimes through hyperlinks in collaborative tools. The final FTA is usually produced through a review and consensus-building process between system and safety engineers. Even with consensus, the analysis results are unlikely to be complete, consistent, and error-free, partly due to the informal models used as the basis for the analysis. In fact, the lack of precise models of system architecture and its failure modes often forces safety analysts to invest substantial effort in gathering information about system architecture and behavior and embedding this information into safety artifacts such as FTAs. Under these conditions, it is challenging to ensure rigorous safety analysis and traceability.
Ideally, this situation could be significantly improved if engineers generated formal models of the system being developed, then extended the model with malfunctioning models, and subsequently performed safety analyses by deriving FMEAs and FTAs from the latter. However, since the current design models are not formal enough to leverage, we believe that the first step to bridging the gap with this ideal situation might involve manually but traceably constructing malfunctioning models. Achieving this goal motivates our methodological proposal.
4. Methodological Proposal
Our proposal includes constructing a malfunctioning software model from which minimal cut sets, FTAs, and FMEs can be automatically generated. Referencing what is elucidated in Section 2.2.1, it relies on the use of dedicated models and failure logic modeling techniques and supporting languages.
The outline of the proposal is illustrated in Figure 2. It is divided into three steps: 1) malfunctioning modeling, 2) functional to malfunctioning logic transformation, and 3) safety analysis.
Step 1 involves constructing a hierarchical architecture of malfunctioning software from the software functional architecture. For each software component, Step 2 transforms the software functional logic into failure propagation logic. This step allows writing the output states of each component, taking into account not only the internal states of the components but also the states of the inputs. Step 2 produces a malfunctioning model, which is used in Step 3 to perform safety analysis and generate classical safety models (such as minimal cut sets, FTAs, and FMEs) from failure conditions and constraints.
4.1 Step 1: Malfunctioning Modeling
We propose constructing a formal malfunctioning model from the software functional architecture to capture the failure behaviors of the software.
Using various information captured from the software architecture documents (which contain informal design models and their functional descriptions), we define and assign abstract states (e.g., active, failed, or transient failure) and related transitions (e.g., failure, partial failure, disabled, canceled) to software components. We perform the same operation on the interfaces between components, assigning abstract states (e.g., normal, no data, lost, erroneous data). This results in a malfunctioning model characterized by software components and how they are interconnected through failure dependency links. Due to its graphical representation, this model is easy to understand; as a formal model, it can be used for simulation, analysis, and proof. Various forms can be used to construct this model, including state/transition diagrams and other dedicated safety modeling languages, such as AltaRica or AADL.
To illustrate this proposal, Figure 3 provides an example. It shows three software components A, B, and C, with internal state variables assigned (representing their possible states). Each component has two states (normal or failed). Inputs and outputs are also represented using states (normal, no data, erroneous). In this example, if the software component B fails (due to its internal state or erroneous input), its output can replicate this failure to the software component C, which can relay it to the failure condition.
Completing Step 1 results in a malfunctioning architecture that includes software components (whose behaviors are modeled using states) and their interconnections.
4.2 Step 2: Functional Logic to Malfunctioning Logic Transformation
The goal of Step 2 is to express the dependencies between the inputs and outputs of the components, which is how failures propagate through the software architecture. To ensure consistency between the functional model and the malfunctioning model, we propose transforming functional logic into malfunctioning logic.
Therefore, we continue using failure truth tables. We refer to (FTT) as the “Failure Truth Table,” which systematically maps normal flows (from functional logic) to failure flows (malfunctioning logic). To construct the failure truth table, we first analyze the functional logic of the components. Then, using the states defined in Step 1 (nominal, erroneous, lost), we set inputs (nominal, erroneous, or lost) and derive the corresponding outputs (nominal, erroneous, lost). Repeating this process allows constructing the FTT using all possible combinations of inputs and corresponding outputs in the malfunctioning flow.
To illustrate the construction of the FTT, Figure 4 provides a simple example of the functional logic of a software component (in the boxes). This is a simple function that returns outputs based on the values of two inputs marked as 1 and 2. Using our proposal, we set the internal states as inputs and report the corresponding output states to the table. We reiterate this for all possible combinations of input states.
The results are shown in Table 1. In this example, if both inputs are “nominal,” the output is also “nominal.” If either input is “lost,” the output state is “lost.” Otherwise, the output state is “erroneous.”
To obtain a computable expression of this logic, we convert the information from the FTT into logical expressions of malfunctioning outputs:
The advantage of this FTT is that it allows changing perspectives (from functional to malfunctioning) and expressing failure behavior in a syntactic and formal way that can be used to write logical expressions of outputs (for software engineers) as well as in natural language (for communication). Additionally, when the design logic changes, the FTT can be updated accordingly, helping to maintain consistency. In the long run, they can also be reused to capture more complex logic.
Completing Step 2 produces well-expressed failure logic and a complete malfunctioning model generated from the FTT, which can be used in Step 3 to perform safety analysis.
4.3 Step 3: Safety Analysis
This step includes utilizing the malfunctioning model produced in Step 2 for simulation and generating safety analyses, such as FMEAs, minimal cut sets, and FTAs. To achieve this goal, failure conditions that represent violations of safety software-related objectives are added to the architecture.
In summary, Step 3 can help assess system safety through simulation and generating classical models (minimal cut sets, FTAs, FMEAs). This can save time and help safety engineers complete their tasks.
4.4 Discussion
This proposal offers various benefits and significantly improves current practices, mainly due to the adoption of model-based approaches. By automatically generating safety analyses from malfunctioning software models, if the model changes, new analyses can be easily and quickly processed. Assuming that the malfunctioning model is correctly established based on the functional model, this method can prevent biases introduced during manual construction of FTAs or FMEs due to potential interpretations by safety analysts. To best execute the transformation from functional to malfunctioning models, consistency and traceability between models are ensured through failure truth tables. Furthermore, this method allows maintaining safety analyses when designs change.
However, this proposal still has some limitations. First, if certain behavioral properties of software components have already been articulated in the design model, manual modeling could be improved. In this case, partial imports could be considered. This highlights the need for improvements in model-based practices regarding design. The second limitation lies in the manual logical transformation through failure truth tables; this could be improved if an automated form of model transformation based on one model were used.
5. Case Study
In vehicles, Advanced Driver Assistance Systems (ADAS) and autonomous driving (AD) achieve software-based functionalities that assist drivers and improve their driving experience. The selected case study is a subsystem of the AD software system. As shown in Figure 5, it consists of three main software components: Hands-Off Detection (HOD), longitudinal control, and lateral control. This case study is part of a broader system, and we also consider other components of the system that must be included (e.g., state inputs) to perform analyses and locate software components based on their environment.
At autonomous driving level 1 (corresponding to assisted driving), even with AD functionalities activated, drivers still need to keep their hands on the steering wheel. In this case, the role of Hands-Off Detection (HOD) is to detect whether the driver’s hands are off the steering wheel. To ensure effective and reliable detection, two redundancy strategies are used: capacitive hands-off detection based on capacitive sensors and torque-based hands-off detection based on measurements of the force applied by the driver on the steering wheel. Both strategies provide a unified HOD state for lateral and longitudinal control. Longitudinal control manages acceleration, deceleration, and braking. Lateral control keeps the vehicle in the lane. It is involved in critical functions, steering, and user alerts. Its activation depends on the states of HOD and longitudinal control, as well as various environmental and vehicle data (lane, steering angle, vehicle speed) provided by state input (software components feeding data to HOD, longitudinal, and lateral control).
5.1 Tool Selection for Supporting the Method
Let us remember that we chose to use dedicated malfunctioning models and FLM methods. This allows us to have a more safety-oriented view of the system and strengthens independence and separation of concerns (functional features and safety considerations).
We chose an AltaRica-based solution due to its simplicity and formal aspects. AltaRica allows expressing malfunctioning behaviors through clearly defined semantics. Moreover, this language has proven useful in many cases (e.g., safety assessments of aerospace systems). Among the AltaRica-based tools, we selected SimfiaNeo because it has more innovative features and a user-friendly interface based on Eclipse. SimfiaNeo has a built-in step simulator, provides an FMEA generator, and has a built-in model checker to directly generate minimal cut sets and FTAs from the malfunctioning architecture.
5.2 Application of the Methodology
We then applied the different steps of the method: first, in Step 1, we defined and modeled the states and basic failures of the software components; then in Step 2, we modeled failure propagation using logical expressions that connect outputs to inputs and internal states; finally, in Step 3, we used the resulting malfunctioning architecture to perform safety analysis.
5.2.1 Step 1: Malfunctioning Modeling
We used information from the AD software functional architecture (documentation and informal models) to construct a basic malfunctioning model. First, using SimfiaNeo’s graphical modeling interface, we modeled the software components with model blocks.
Then, using AltaRica, we defined the domains of the components (see Section 2.2.2) as well as the inputs/outputs, states, and related transitions (represented as events in AltaRica) for each component. The top-level view of this model is shown in Figure 6. The red rectangle delineates the scope of the case.
We now need to complete this malfunctioning model with failure propagation logic to be able to perform safety analysis.
5.2.2 Functional to Malfunctioning Logic Transformation
The logical transformation is used to assist in building failure propagation and ensure better consistency between the malfunctioning model and the design model. To do this, we used the FTT to convert the logic retrieved from the Simulink model into AltaRica logic.
Figure 7 illustrates this transformation. The functional logic comes from the subcomponents of the HOD software component. From a functional perspective, this logic returns a state (HODConsolidationHandsOn) based on whether two signals (HandsOff and HandOff_mirror) are equal. The output (HandsOffState) captures this state.
The goal of transforming functional to malfunctioning logic is to shift perspectives from functional to malfunctioning. To achieve this, we assign states (predefined in Step 1) to inputs (in functional logic) and write the corresponding output states in the FTT. We reiterate this for all possible combinations of input states. This will create the corresponding failure table containing all possible output states, as shown in Figure 7. Using the FTT, we can now write output expressions (for the corresponding malfunctioning blocks) in AltaRica.
This step is repeated for all software components of the AD. These tables can serve as templates to model more complex components and systems. This helps save time through reuse. Overall, Step 2 completes the malfunctioning model initiated in Step 1. Thus, the malfunctioning model is more consistent with the functional model and can be used for safety analysis in Step 3.
5.2.3 Step 3: Safety Analysis
This step involves using SimfiaNeo to check the functionality from the malfunctioning model to generate classical safety models, such as FMEAs, minimal cut sets, and FTAs. To achieve this goal, we used the malfunctioning model from Step 2 and failure conditions identified in the early stages of the safety lifecycle. We continue by adding failure conditions through direct connections of the outputs of software components or through combinations of assertions expressed in AltaRica. Once this is done, we can now perform safety analysis. First, we conduct simulations. Then we directly generate FMEAs from the malfunctioning architecture. After that, we calculate minimal cut sets from which we can immediately generate FTAs.
To perform simulations, we use the built-in simulator in SimfiaNeo. It allows us to interactively evaluate the malfunctioning behavior of the system. For this, we manually trigger basic failure events (at the component level) and observe their effects on other components and failure conditions (previously added through AltaRica observers) by color changes.
SimfiaNeo can automatically generate and export FMEA tables directly from the software malfunctioning model. Given the complexity of the software architecture and multiple basic failures (at the component level), this leads to a large number of failure modes (in the FMEA table). Therefore, we find that in our case, the relevance of the FMEA table is lower compared to more compact and comprehensive minimal cuts and FTAs. However, while generating FMEA is immediate, generating FTAs requires (somehow fast and simple) configuration. Before creating FTAs, minimal cut sets are generated first. To generate minimal cuts, we specify the failure conditions of the top event, the (calculated) maximum order, and some other parameters, such as the type of generation (random, permutations, or combinations). We can also add some constraints in the configuration indicating any conditions we want to check (e.g., “no single point failures”). Once the calculation starts, it returns a table (as shown in Figure 8) listing the basic failure events (in the “elements” column), their order (the number of basic events contributing to the top event), and their probabilities.
FTA essentially contains the same information as the minimal cut set but has the advantage of presenting it in a more intuitive way. Figure 9 shows an example of an FTA. It is built from the minimal set of events that lead to the loss of the ADAS “lateral control” functionality.
The top of the tree is the top event (loss of lateral control). In the leaves, we see the basic failure events and their probabilities (not displayed in our example). The FTA graphically shows that the loss of lateral control may be due to a single failure of the lateral control component (Lateral_Ctrl.failure) or the failure of HOD (HOD.HODStateFinal) in conjunction with failures of the Fusion (Fusion.failure) or Status Input (Status_IN.failure) software components. Furthermore, the FTA can effectively capture inconsistencies that are not visible through the functional view in the ASIL breakdown. For instance, the lateral control component is rated ASIL B, while one of the contributing basic events in this FTA (Status_IN.failure) bears no ASIL requirements. Therefore, using the FTA can effectively check whether the ASIL of triggering event combinations is inconsistent for a given safety objective.
This step demonstrates how to generate classical safety models from the malfunctioning architecture we built in Steps 1 and 2.
5.3 Case Study Conclusion
The results of the case study indicate that using our proposed method, model-based software safety analysis approaches can be applied and benefit the automotive industry. It also demonstrates the usefulness and efficiency of using basic and practical tool features (such as the simulation and failure cause and consequence provided in the tools). Moreover, this method makes it easier for engineers to conduct safety analyses by generating them based on tool-based traditional safety analyses. Overall, the method enhances safety by allowing engineers to focus on obtaining the correct models and spending less effort generating analyses, thereby improving the quality of these automatically generated analyses. The possibility of one-click generating FTAs is particularly interesting. In fact, if the software functional model changes, the malfunctioning model can be updated, and FTAs can be regenerated without additional effort. This implies that the malfunctioning model should be maintained. However, since the construction of the malfunctioning model and logical translation is done manually, there are some limitations. First, manual modeling and logic transformation make the application of this method impractical for large and complex software systems. This manual modeling approach can certainly be improved to ensure better consistency of our models with design models. Second, the AltaRica language is system-oriented and lacks semantics for certain categories of software failures. Expressing and simulating time and value-related failures is challenging. For example, we cannot model and observe failures such as temporary deactivation of lateral control or values out of range. In this regard, we believe a reevaluation of the use of AltaRica is needed. Nevertheless, the proposed method meets our current needs as it represents a significant improvement over manual techniques.
6. Perspectives and Conclusions
This paper proposes a methodological suggestion for automotive software safety analysis using MBSA. It involves constructing a malfunctioning architecture of automotive software from functional high-level nominal architectures using compatible semantics and syntax and transforming functional logic into malfunctioning logic. Then, based on this malfunctioning model, safety engineers can automatically generate minimal cut sets, FTAs, and FMEs for interpretation and as safety evidence when needed. We applied this method to a real industrial case study involving the use of SimfiaNeo and AltaRica. We conclude that the method is feasible and useful. Combined with the languages and tools we used, it brings added value and improves current manual safety analysis practices. The limitations we found will be addressed in future work. This will include improving the modeling of malfunctioning, for which we will consider partial automation of model construction and logic transformation. We will also explore languages with better semantics for software failures (e.g., AADL EMV2). Finally, we will strive to integrate the proposed model-based software safety analysis methodology with model-based software development to ensure better consistency and higher quality safety analyses.
🎁Apply for a free trial of the REANA cybersecurity analysis tool by scanning the QR code and adding Niu Xiaoka’s enterprise WeChat, replying “REANA”
🎁Static and dynamic code testing toolsApply for a free trial by scanning the QR code and adding Niu Xiaoka’s enterprise WeChat, replying “Software Testing”
Automotive Safety Premium Services
For more industry news, technical interpretations, and inquiries, please visit the official website of Niu Ka Network i-newcar.com
Argumentation ideas for processes and products in automotive safety files
Automotive cybersecurity verification and validation testing
Knowledge and skills requirements for automotive electronic software design and testing
Safe and reliable UDS refresh via CAN bus
ASPICE compliance in agile software development processes (Part 1): Data collection methods and analysis strategies
Automotive software quality management integrating ASPICE, ISO 26262, ISO 21448, and ISO 21434
Design and implementation process of an advanced driver assistance system based on open-source AUTOSAR
Attacking AUTOSAR using software and hardware means
Functional safety of automotive Ethernet
Encrypted storage of automotive data
Automotive ECU software testing will face huge challenges
Integration of ISO 26262 and ISO 21448 development processes for autonomous systems
Comparison of classic and adaptive AUTOSAR software architectures with functional safety
Chip-level defense against cybersecurity in intelligent vehicles
Using GPIO to meet automotive functional safety requirements
Key points of functional safety design for automotive ADAS SoCs
Zero-based hands-on guide to FMEDA
Estimation of basic failure rates for semiconductor functional safety using IEC62380 and SN29500
