Search Results

Embedded software in the car is becoming increasingly complex due to the growing number of software-based controller functions and the increasing complexity of the software itself. Model-based development with Simulink combined with TargetLink for automatic code generation helps significantly to improve the quality of the embedded software. The development of large-scale Simulink models in distributed teams is a challenging task, especially when developing safety-critical software that must fulfill requirements stated in the ISO 26262 [1] safety standard. In practice, many questions on how to avoid the pitfalls of distributed model-based development remain open, such as how to define an appropriate model architecture, handle model complexity, and achieve compliance with ISO 26262. The intent of this paper is threefold. Firstly, we summarize those requirements of ISO 26262 that are relevant for developing complex software in a distributed environment.

This work presents current methods to analyze and improve the architecture of Simulink models. The methods follow the “principles for architectural design” of part 6 on software development of the ISO 26262 functional safety standard for road vehicles, the dominating standard in the automotive industry. The methods presented describe how the abstract architectural principles of the ISO 26262 can be implemented in the context of model-based development using Simulink. Therefore we demonstrate how different metrics can be used to improve or enforce the compliance with the principles. In contrast to previous publications we will not primarily focus on the metrics itself, but emphasize the architectural principles themselves and expose the architectural implications of applying the metrics. As the architectural principles of the ISO 26262 are targeted at reducing the overall complexity, we will also focus on metrics and methods that help to reduce the models complexity.

As demand for ADAS and autonomous systems grows, as well as the need to avoid lawsuits from software bugs, the desire for high integrity and functional safety applications is growing. While there are many process and technical factors that contribute to the overall quality of the software, it is becoming increasingly important to define the software architecture and verify that the implementation satisfies all of the architecture requirements. Because defining the software architecture is new for many companies, there is a need to know what properties are important to specify. Also lacking are techniques needed to verify that the implementation is a “good” architecture.

Model-based software development is a well-established software development process and recognized by ISO26262 [1] as allowing for highly consistent and efficient development. Nevertheless, enhancing a model-based development process in such a way that it is compliant with the ISO26262 safety standard is a challenging task. To achieve ISO26262 compliance, the development team of a safety-related software project faces a multitude of additional requirements for the development process without a corresponding increase of the project budget to fulfill them. The fact that many of the requirements of ISO26262 are defined in a very generic way such that an interpretation is required further hampers their implementation. We propose a 10-step strategy to achieve an ISO26262 compliant model-based software development process. This strategy relates ISO26262 requirements with state-of-the art methods and approaches currently used for model-based software development.

A key component of developing a safety-critical automotive system in compliance with ISO 26262 is developing what is known as the safety case. This delivery justifies that the system is free from unreasonable risk and that the safety requirements are complete and satisfied according to evidence from ISO 26262 work products. However, the standard provides neither practical guidance on how the safety case should be developed, nor how the safety argument should be evaluated in the functional safety assessment process. This paper discusses quality and product readiness of the system under development in the context of safety case generation. We will focus on the software level and ISO 26262-6 requirements that relate to this. We will look at the software lifecycle of the system and how to measure and deliver key data throughout this lifecycle.