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.