Search Results

Huge Simulink controller models often consists of (almost) identical subsystems, very often resulting from copy-and-paste operations and only slight adaptation of the subsystems by the model engineer. Although this “copy-and-paste” approach might help to achieve initial results very fast, in the long-run such subsystem clones can create considerable problems. Like code clones, model clones increase the effort for testing and maintenance. Model clones also tend to influence the code efficiency and code quality in a negative way in case the Simulink model is used as a basis for code generation. JUST SIMPLIFY is an approach for detecting model clones in a Simulink model automatically based on model metrics calculations. This approach has been implemented in our model metrics and complexity measurement tool M-XRAY. JUST SIMPLIFY allows reducing the effort for model refactoring by avoiding time consuming manual search for model clones.

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.

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.

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.

Requirements-based functional testing of model-based embedded software is a crucial requirement of the ISO 26262 safety standard for passenger cars [1]. Test assessment of requirements-based test cases is a laborious task and checking test results manually is prone to error. The intent of this paper is as follows: We introduce a method for requirements-based testing, which allows testing and automatic evaluation of single as well as several (grouped) requirements with one test sequence. Within a large-scale industrial project we have already shown that our new approach reduces testing expenditures and susceptibility to errors. Within this paper we shall present a method which facilitates the fulfillment of requirements traceability stipulated by ISO 26262. This method supports automated test case generation from test specifications, which then can be executed and assessed by a test tool automatically.

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.

Model-based development of embedded automotive control software is characterized by the use of executable models throughout the entire development process. Modeling and simulation tools that are frequently used in this context include, for example, Simulink and Stateflow from The MathWorks. Code generators such as TargetLink make it possible to automatically generate efficient C code directly from these models. The quality of the models used for code generation has a direct influence on the quality of the generated C code. This is why it is vital that specific quality criteria be fulfilled when developing safety-relevant systems, for example, conformity with modeling guidelines starting at the model level. MISRA modeling guidelines exist for use with the TargetLink code generator. Conformity with these guidelines ensures a safe language subset and significantly improves the safety of generated code, for example, by avoiding ambiguous semantics.

The approach taken in developing embedded software in the automotive field has shifted towards the paradigm of using executable graphical models at all stages of development: from the initial design phase through to implementation (model-based development). Models are designed with common graphical modeling languages, such as Simulink / Stateflow from The MathWorks. New approaches allow for the automatic generation of efficient controller code from the Simulink and Stateflow models directly via code generators, such as TargetLink by dSPACE or the Real-Time Workshop/Embedded Coder by The MathWorks. The usage of a code generator can lead to significant improvements in productivity in the software implementation phase. Furthermore, the level of quality gained by early quality assurance at the model level can also lead to higher quality code. Automotive software is often deployed in safety-critical systems and therefore cannot contain errors.

This paper examines state-of-the-art quality assurance (QA) techniques for model-based software development in the automotive domain. Both the aims and effort required to apply a certain method are discussed for all relevant QA techniques. Since QA techniques can only be used effectively if they are seamlessly integrated within the overall development process and among each other, an appropriate interconnection and order of application is important. Based on our experience from automotive software development projects, we suggest a QA strategy that includes the selection of QA techniques and the sequence of their application.

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.