Formal Verification of Automotive Embedded Software Vassil Todorov, Frédéric Boulanger, Safouan Taha
Total Page:16
File Type:pdf, Size:1020Kb
Formal verification of automotive embedded software Vassil Todorov, Frédéric Boulanger, Safouan Taha To cite this version: Vassil Todorov, Frédéric Boulanger, Safouan Taha. Formal verification of automotive embedded soft- ware. FORMALISE: 6th International Conference on Formal Methods in Software Engineering, Jun 2018, Gothenburg, Sweden. 10.1145/3193992.3194003. hal-01768687 HAL Id: hal-01768687 https://hal.archives-ouvertes.fr/hal-01768687 Submitted on 17 Apr 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Formal verification of automotive embedded software Vassil Todorov Frédéric Boulanger Safouan Taha LRI, Groupe PSA, Université LRI, CentraleSupélec, Université LRI, CentraleSupélec, Université Paris-Saclay Paris-Saclay Paris-Saclay ABSTRACT not so critical. Actually, the driver had a mechanical control over The ever-increasing complexity of automotive embedded systems the steering and the brakes and could stop in case of emergency. and the need for safe advanced driver assistance systems (ADAS) However, in the near future, autonomous vehicles will bring represent a great challenge for car manufacturers. Furthermore, new requirements for higher software correctness and probably we expect that in the near future, authorities require a software a software certification issue. At the same time, software is certification in order to get convinced that ADAS are safe getting more and more complex. We think that a way to manage enough. Theoretical research and experience show that when using the complexity issue and to guarantee a high confidence and conventional design approaches it is impossible to guarantee high integrity in safety-critical software is to use formal methods. It will confidence to those systems. The way taken by some industries bring a higher reliability, robustness and confidence. Moreover, (e.g. aerospace, railway, nuclear) was by partially using formal using formal methods in an early design phase results in a verification techniques. better specification, maintenance and early design validation thus In this paper, we first present a background of the formal reducing the overall V&V cost. verification techniques and how they can contribute to achieve In this paper, we present our experience in applying formal the requirements of some safety standards. Next, we share our verification techniques to a software written the way automotive experience with the application of those techniques that seem to be is doing it today. In Section 2 we present a brief overview of mature enough to be used in an industrial context: Static analysis formal methods and comment on some tools. In Section 3 we based on Abstract Interpretation, SMT-based software Model discuss safety standards, tools and cost, which are the factors checking and Deductive proof. Finally, we make a detailed analysis that could help introducing formal methods in the development about our experiments and propose an approach introducing formal process. In Section 4 we give a detailed analysis of our experiments. methods into the development of automotive embedded software. Our approach for introducing formal methods in the development process is presented in Section 5, before concluding in Section 6. CCS CONCEPTS • Software and its engineering → Software verification; 2 OVERVIEW OF FORMAL METHODS The first works on formal methods date back to the 1960s. The KEYWORDS central idea is to guarantee the behavior of a computing system Software verification · Formal methods · ADAS · Certification using mathematical methods. ACM Reference Format: For many years, formal methods have essentially been used in Vassil Todorov, Frédéric Boulanger, and Safouan Taha. 2018. Formal academia. Today, formal methods get more and more connected verification of automotive embedded software. In FormaliSE ’18: FormaliSE with applied engineering and many industries are using them in ’18: 6th Conference on Formal Methods in Software Engineering , June 2, 2018, their development process. They are better applied in the electronic Gothenburg, Sweden. ACM, New York, NY, USA, 4 pages. hardware design because the hardware tools are more standardized and stable. Software tools and technology (such as requirements 1 INTRODUCTION and design methodology) are still changing rapidly. Automotive software has a major role in today’s vehicle control and We shortly discuss here the three main categories of formal entertainment features. It is developed according to prescription methods that provide some guarantee of quality and that are highly rules defined by the ISO 26262 standard. Verification and validation automated. activities (V&V) have to be performed in order to guarantee the compliance of the software to the standard. These activities are a 2.1 Abstract Interpretation key concern on complex systems particularly for the safety-critical Abstract Interpretation is a kind of static analysis introduced in 1977 ones and require a great effort to avoid unexpected behaviors. by Cousot et al. [9] that automatically computes information about For many years, the automotive industry has relied on reviews, the program behavior without executing it. Most questions about analysis and tests for V&V activity. The reason was the cost this behavior are either undecidable or it is practically impossible effectiveness of those methods and the fact that the software was to compute an answer. The main goal of abstract interpretation is Permission to make digital or hard copies of part or all of this work for personal or to efficiently compute an approximate or abstract representation of classroom use is granted without fee provided that copies are not made or distributed a program and bring sound guarantees about dynamic properties. for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. Sound means that the approximation is reliable and that bugs are not For all other uses, contact the owner/author(s). missed (no false negatives). A spurious alarm also known as a false FormaliSE ’18, June 2, 2018, Gothenburg, Sweden positive is a warning about a bug that does not exist in the program. © 2018 Copyright held by the owner/author(s). False positives can be generated because of the approximation. FormaliSE ’18, June 2, 2018, Gothenburg, Sweden V. Todorov et al. This method has been implemented in static analysis tools to • Availability of supporting tools that are easy to use by the check for runtime errors like division-by-zero, out of bound array engineers; access, overflows and others. Some tools extend it also to check • An overall cost for using them which is less than without MISRA coding rules [16], SEI CERT Secure C rules [20] and MITRE using formal methods. Common Weakness Enumeration CWE rules [15]. Astrée from AbsInt, Polyspace Code Prover from MathWorks and TrustInSoft 3.1 Standards Analyzer from TrustInSoft are commercial tools for sound static For the automotive industry, ISO 26262 is the standard for functional analysis. Other tools like Coverity and Klocwork are based on safety management. This standard recommends the use of formal heuristics and do not guarantee to find all runtime errors. They are methods for its most critical levels. out of the scope of this paper. In rail transport, EN 50128 recommends the use of formal methods for the less critical levels and highly recommends their 2.2 Model Checking use for the most critical levels, making it de facto mandatory. Model checking is a formal method introduced in the early 80s In the aviation domain particularly, there is a special supplement by two teams: E. M. Clarke, E. A. Emerson [7], and J. P. Queille, DO-333 to the DO-178C which modifies, deletes and adds objectives J. Sifakis [18]. It determines if a formal model of a system satisfies specific to formal methods. Thus using formal methods can replace a correctness property from the specification. It provides a better some heavy duty tasks like MC/DC 100% coverage testing. expressiveness for properties than Abstract Interpretation but is The “Common Criteria” software security standard requires the less scalable due to some limitations (e.g. nonlinear arithmetic, use of formal methods for its highest critical level (EAL7). combinatorial explosion). The most valuable feature of Model Static analysis is also recommended or required by some checking for system design engineers is the counterexample standards. Performing it with abstract interpretation tools brings produced when the property is violated. It shows an execution better guarantees for the absence of runtime errors. trace leading to a state in which the property is not verified. There exist different types of model checkers but for our use 3.2 Tool support cases (checking safety properties on embedded software), the most Using formal methods requires appropriate tools. There has been suitable are the ones that use induction and SMT (Satisfiability many tools developed for some particular cases and there is no Modulo Theories) solvers, for example Kind2 (University of universal tool covering all types of formal methods. We can also Iowa) [5], JKind (Rockwell Collins) [10], Prover Plugin also known say that the maturity of the tools for each formal method is different. as Design Verifier (Prover Technologies) and GATeL (CEA). They For example, static analysis based on abstract interpretation tools generally translate a model written in a synchronous dataflow are mature enough to be used, although the precision needs to be formal language such as Lustre [3] into first-order logic formulas improved. Model checking based tools for software are less robust which are then checked for satisfiability by the solver.