Rainer Gmehlich

On fitting a formal method into practice

The development of the Event-B formal method and the supporting tools Rodin and ProB was guided by practical experiences with the B-Method, the Z specification notation, VDM and similar practical formal methods. The case study discussed in this article -- a cruise control system -- is a serious test of industrial use. We report on where Event-B and its tools have succeeded, where they have not. We also report on advances that were inspired by the case study. Interestingly, the case study was not a pure formal methods problem. In addition to Event-B, it used Problem Frames for capturing requirements. The interaction between the two proved to be crucial for the success of the case study. The heart of the problem was tracing informal requirements from Problem Frames descriptions to formal Event-B models. To a large degree, this issue dictated the approach that had to be used for formal modelling. A dedicated record theory and dedicated tool support were required. The size of the formal models rather than complex individual formulas was the main challenge for tool support.

Towards a formalism-based toolkit for automotive applications

The success of a number of projects has been shown to be significantly improved by the use of a formalism. However, there remains an open issue: to what extent can a development process based on a singular formal notation and method succeed. The majority of approaches demonstrate a low level of flexibility by attempting to use a single notation to express all of the different aspects encountered in software development. Often, these approaches leave a number of scalability issues open. We prefer a more eclectic approach. In our experience, the use of a formalism-based toolkit with adequate notations for each development phase is a viable solution. Following this principle, any specific notation is used only where and when it is really suitable and not necessarily over the entire software lifecycle. The approach explored in this article is perhaps slowly emerging in practice - we hope to accelerate its adoption. However, the major challenge is still finding the best way to instantiate it for each specific application scenario. In this work, we describe a development process and method for automotive applications which consists of five phases. The process recognizes the need for having adequate (and tailored) notations (Problem Frames, Requirements State Machine Language, and Event-B) for each development phase as well as direct traceability between the documents produced during each phase. This allows for a stepwise verification/validation of the system under development. The ideas for the formal development method have evolved over two significant case studies carried out in the DEPLOY project.

Experience of Deployment in the Automotive Industry

This chapter sets out the experience of deployment in the automotive components company Bosch (Robert Bosch GmbH). An analysis of the typical challenges and practices is followed by a detailed description of the process used to experiment with the adoption of more formal methods by Bosch Research. One conclusion is that there is a need for semi-formal methods for bridging the gap between the initial (natural language) requirements and the creation of a formal model in Event-B. It is also important to note that the process of development reveals differences between refinement as used in the Problem Frames Approach and that envisaged in Event-B. Finally, the experience gained by the main support contact (Newcastle University) is analysed in the hope that these lessons will assist future projects.

Specification and Validation of Embedded Systems using LUSTRE and ARGOS. Case Study: The Automatic Headlight Leveling System

In thisarticle, the design, modeling and validation of embedded systemsis examined. There exist commercial tools for the developmentof control- or data-flow dominated systems, e.g.STATEMATE for control dominated systems and MATLAB for data-flowdominated systems, but there are problems to describe mixed systems.The system is split in a control and a transformation part. Thecontrol part is described with the graphical language ARGOS,the transformation part with the data-flow language LUSTRE. Integrationis done based on their common synchronous architecture. The designprocess is shown in a case study on an industrial application,the automatic headlight leveling system. A validation strategyaccording to the separation of the system is shown. Safety propertiesof the control part are proved with model checking, functionalcorrectness is shown in two steps by simulation and hardwarein the loop simulation.