Search Results

Preventing systematic software failures is of paramount importance for any highly automatic vehicle control system, in particular for safety-critical AUTOSAR software. Among the most critical software defects are runtime errors like buffer overflows or data races. They may cause erroneous or erratic behavior, induce system failures, and constitute security vulnerabilities. Sound static analysis can be used to report all such defects in the code, or to prove their absence. It can also determine dependencies between software components and show freedom of interference without missing any data and control flow through data or function pointers. In the past, AUTOSAR projects often had to be decomposed or simplified to achieve satisfactory analysis time or memory consumption. Creating the analysis model, i.e., determining the tasks and ISRs to analyze, their priorities, synchronization, etc., required significant manual effort.

Safety-critical embedded software has to satisfy stringent quality requirements. One such requirement, imposed by all contemporary safety standards, is that no critical run-time errors must occur. Runtime errors can be caused by undefined or unspecified behavior of the programming language; examples are buffer overflows or data races. They may cause erroneous or erratic behavior, induce system failures, and constitute security vulnerabilities. A sound static analyzer reports all such defects in the code, or proves their absence. Sound static program analysis is a verification technique recommended by ISO/FDIS 26262 for software unit verification and for the verification of software integration. In this article we propose an analysis methodology that has been implemented with the static analyzer Astrée. It supports quick turn-around times and gives highly precise whole-program results.

Safety-critical embedded software has to satisfy stringent quality requirements. All contemporary safety standards require evidence that no data races and no critical run-time errors occur, such as invalid pointer accesses, buffer overflows, or arithmetic overflows. Such errors can cause software crashes, invalidate separation mechanisms in mixed-criticality software, and are a frequent cause of errors in concurrent and multi-core applications. The static analyzer Astrée has been extended to soundly and automatically analyze concurrent software. This novel extension employs a scalable abstraction which covers all possible thread interleavings, and reports all potential run-time errors, data races, deadlocks, and lock/unlock problems. When the analyzer does not report any alarm, the program is proven free from those classes of errors. Dedicated support for ARINC 653 and OSEK/AUTOSAR enables a fully automatic OS-aware analysis.

Model-based development is the established way of developing embedded control algorithms, especially for safety-critical applications. The aim is to improve development efficiency and safety by developing the software at a high abstraction level (the model) and by generating the implementation (the C code) automatically from the model. Although model-based development focuses on the models themselves, downstream artifacts such as source code or executable object code have to be considered in the verification stage. Safety standards such as ISO 26262 require upper bounds to be determined for the required storage space or the execution time of real-time tasks, and the absence of run-time errors to be demonstrated. Static analysis tools are available which work at the code level and can prove the absence of such errors. However, the connection to the model level has to be explicitly established.

Developers of safety-critical real-time systems have to ensure that their systems react within given time bounds. Ideally, the system is designed to provide sufficient computing power and network bandwidth, is cost efficient and provides the necessary safety level. To achieve this goal, three challenges have to be addressed. First, it must be possible to account for timing during early development stages in the architecture exploration phase. Second, during software development, timing behavior and the effects of software changes on timing must be observable. Third, there must be a technology for formally verifying the final timing behavior for industry-size applications. In this article we present a comprehensive methodology for dealing with timing which addresses all three issues based on state-of-the-art commercial tools.

Modern automotive embedded systems are characterized by timing constraints at different levels in the design hierarchy and flow. System-level functions like modern active-safety functions are characterized by end-to-end constraints that span several ECUs and buses. ECU-level functions, like fuel injection controls need to cope with stringent resource requirements, tight time constraints and event-driven computations with different execution modes. This paper introduces some of the models, the techniques and the tool integration methods developed in the context of the INTERESTED project to guarantee timing correctness at all levels in the flow. In addition, we outline the issues arising from the application of these techniques to a fuel injection case study.

Software developers in the automotive sector must achieve high quality objectives. Many design and implementation errors are avoided by synthesizing code from model-based software specifications using automatic code generators such as ETAS' ASCET. To verify non-functional properties of the implementation, model-based design processes should be complemented with static program analysis tools like AbsInt's StackAnalyzer and timing analyzer aiT. ASCET, StackAnalyzer and aiT can be integrated in a way that the analysis results for code generated by ASCET are conveniently accessible from within the ASCET development environment. This gives ASCET users a direct feedback on the effects of their design decisions on resource usage, allowing to select more efficient designs and implementation methods. In the paper, we present the tools, the experimental integration, preliminary results and plans for further tool integration.

Failure of a safety-critical application on an embedded processor can lead to severe damage or even loss of life. Here we are concerned with two kinds of failure: stack overflow, which usually leads to run-time errors that are difficult to diagnose, and failure to meet deadlines, which is catastrophical for systems with hard real-time characteristics. Classical validation methods like code review and testing with repeated measurements require a lot of effort, are expensive, and do not really help in proving the absence of such errors. AbsInt's tools StackAnalyzer and aiT (timing analyzer) provide a solution to this problem. They use abstract interpretation as a formal method that allows to obtain statements valid for all program runs with all inputs.