Abstract

International audience; The ever-increasing complexity of automotive embedded systems and the need for safe advanced driver assistance systems (ADAS) represent a great challenge for car manufacturers. Furthermore, we expect that in the near future, authorities require a software certification in order to get convinced that ADAS are safe enough. Theoretical research and experience show that when using conventional design approaches it is impossible to guarantee high confidence to those systems. The way taken by some industries (e.g. aerospace, railway, nuclear) was by partially using formal verification techniques. In this paper, we first present a background of the formal verification techniques and how they can contribute to achieve the requirements of some safety standards. Next, we share our experience with the application of those techniques that seem to be mature enough to be used in an industrial context: Static analysis based on Abstract Interpretation, SMT-based software Model checking and Deductive proof. Finally, we make a detailed analysis about our experiments and propose an approach introducing formal methods into the development of automotive embedded software. CCS CONCEPTS • Software and its engineering → Software verification; KEYWORDS Software verification · Formal methods · ADAS · Certification ACM Reference Format: Vassil Todorov, Frédéric Boulanger, and Safouan Taha. 2018. Formal verification of automotive embedded software. In FormaliSE '18: FormaliSE

Abstract

International audience; This SIG focuses on the engineering of automation in interactive critical systems. Automation has already been studied in a number of (sub-) disciplines and application fields: design, human factors, psychology, (software) engineering, aviation, health care, games. One distinguishing feature of the area we are focusing on is that in the field of interactive critical systems properties such as reliability, dependability, fault-tolerance are as important as usability, user experience or overall acceptance issues. The SIG targets at two problem areas: first the engineering of the user interaction with (partly-) autonomous systems: how to design, build and assess autonomous behavior, especially in cases where there is a need to represent on the user interface both autonomous and interactive objects. An example of such integration is the representation of an unmanned aerial vehicle (UAV) (where no direct interaction is possible), together with aircrafts (that have to be instructed by an air traffic controller to avoid the UAV). Second the design and engineering of user interaction in general for autonomous objects/systems (for example a cruise control in a car or an autopilot in an aircraft).

Abstract

International audience; The Machine Learning (ML) world is in constant evolution, as the amount of different algorithms in this context is evolving quickly. Until now, it is the responsibility of data scientists to create ad-hoc ML pipelines for each situation they encounter, gaining knowledge about the adequacy between their context and the chosen pipeline. Considering that it is not possible at a human scale to analyze the exponential number of potential pipelines, picking the right pipeline that combines the proper preprocessing and algorithms is a hard task that requires knowledge and experience. In front of the complexity of building a right ML pipeline, algorithm portfolios aim to drive algorithm selection, learning from the past in a continuous process. However, building a portfolio requires that (i) data scientists develop and test pipelines and (ii) portfolio maintainers ensure the quality of the portfolio and enrich it. The firsts are the developers, while the seconds are the operators. In this paper, we present a set of criteria to be respected, and propose a pipeline-based meta-model, to support a DevOps approach in the context of Machine Learning Pipelines. The exploitation of this meta-model, both as a graph and as a logical expression, serves to ensure continuity between Dev and Ops. We depict our proposition through the simplified study of two primary use cases, one with developer's point-of-view, the other with ops'.