Search Results

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.

The release of the ISO 26262 in November 2011 was a major milestone for the safeguarding of safety-related systems that include one or more electrical and / or electronic (E/E) systems and that are installed in series production passenger cars. Although no specific requirements exist for a model-based software development process, ISO 26262 compiles general requirements and recommendations that need to be applied to model-based development. The second edition of the ISO 26262 has been distributed for review with a final publication scheduled for 2018. This revised edition not only integrates the experiences of the last few years but also extends the overall scope of safety-related systems. In order to determine the necessary adaptions for already existing software development processes, a detailed analysis of this revision is necessary. In this work, we focus on an analysis and the impact on model-based software development of safety-related systems.

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.

Managing ISO 26262 software development projects is a challenging task. This paper discusses major challenges in managing safety-critical projects from a high-level perspective, i.e. from a manager's point of view. We address managers (directors) with full project responsibility including software and hardware teams. Rather than discussing how to fulfill (technical) requirements stated by the ISO standard, we highlight major challenges and tough decisions a manager has to face on her way from project start up to delivery of the safety case. We discuss important project management topics and best practices such as negotiation issues with the contractor (OEM), selection of the appropriate functional safety manager, general ISO 262626-related project management matters, as well as contractual issues with supplier such as development interface agreement. We discuss the topics on the basis of real-life experience we collected during several ISO 26262 management projects.

In the automotive industry, the model-based approach is increasingly establishing itself as a standard paradigm for developing control unit software. Just as code reviews are widespread in classical software development as a quality assurance measure, models also have to undergo a stringent review procedure – particularly if they serve as a starting point for automatic implementation by code generators. In addition to these model reviews, the generated production code is reviewed later in the development process by performing auto code reviews. This article will present procedures for and give an account of experiences with model and code reviews which have been adapted to the model-based development process.