key: cord-0043701-i9g4b6qq authors: Leuschel, Michael; Mutz, Mareike; Werth, Michelle title: Modelling and Validating an Automotive System in Classical B and Event-B date: 2020-04-22 journal: Rigorous State-Based Methods DOI: 10.1007/978-3-030-48077-6_27 sha: ac4c7a8cc17d53731525053e4fe18e244537b754 doc_id: 43701 cord_uid: i9g4b6qq We have modelled parts of the ABZ automotive case study using the B-method. For the early phases of modelling we have used the classical B for software, while for proof we have used Event-B and Rodin. It is maybe surprising that classical B’s machine inclusion mechanism along with operation calls can be used for modular system modelling. Moreover, for one particular style of modelling, the result can then be translated to superposition refinement with event extension in Event-B. Before conducting the proof, we have validated our models using model checking and animation with visualizations. The graphical visualizations were constructed using a new plugin (VisB) which helped uncover errors and transforms our model into an executable, interactive reference specification which can be examined by users without formal background. In this work we have used both classical B and Event-B as modelling languages with ProB and rodin for tool support. The classical B-method [1] is a formal method rooted in predicate logic, set theory, arithmetic. B arose out of Z, with a focus on tool support and successive refinement to derive provably correct software out of high-level specifications. This initial version of B, supported by the tool Atelier-B, is now called classical B or also "B for software". Event-B was developed to enable systems modelling. It also tried to correct a few issues in classical B, simplifying the language (e.g., making it easier to parse and removing the complex inclusion mechanism) and trying to make refinement proofs easier and more scalable. The main addition though is a more flexible refinement concept targeted at systems modelling rather than software development. The foundations of Event-B are laid out in the book [2] . Event-B is supported by the rodin platform [3] , which we have used for proving. In our development of the case study we made heavy use of the animator and model checker ProB [10] which supports both classical B and Event-B. ProB is also available as a plugin for rodin. The goals we set ourselves were as follows: -Validate the usability of the new visualization plugin VisB for ProB, in particular whether images from the case study description [7] can be reused with little effort. -Examine whether systems modelling can be conducted in classical B. -Examine whether a componend-based model in classical B can be converted to Event-B for use by the rodin for proof. Indeed, in earlier work we have often realised that classical B can also be used for systems modelling and may have some advantages. However, for proving systems, Event-B and rodin provide a nice platform and simpler 1 proof obligations than classical B. We have modelled a subset of the lighting system, as well as a subset of the adaptive cruise control system. For the latter some insights found during modelling have led to improvements in the case study specification (see Sect. 6) . In this article we only show details of the lighting system models, which we have developed using a development methodology described in Sect. 2, which consisted of using classical B during the exploration phase and Event-B for the proving phase. The contributions of this article thus consist in showing the usefulness of visualisation using a new lightweight SVG-based tool, comparing classical B and Event-B for systems modelling, and illustrating a development methodology. Together with the visualisation, our model provides an executable reference specification for a subset of the specification, which can be used by domain experts without formal methods training. We plan on extending this subset in future. The methodology we used was inspired by earlier experience on modeling and validating railway systems (e.g., [4, 5] ). We divided the modelling into three phases (see Fig. 1 ): 1. an exploratory modelling phase where one tries to understand the specification and domain and identifies important subcomponents. 2. a synthesis phase, where the subcomponents are integrated to form ever larger subsystems and the integration is at least partially verified. We could have named this also the combination or structuring phase. 3. an exhaustive verification phase, where the completed system is now formally proven to be safe and functionally correct. The exploratory phase 1 is dominated by editing and animation. Here it is important that one can quickly change the model, and one wants to use a maximally powerful language. Hence, in our case, we have used classical B with its rich substitution language for this phase. Also, the fact that we have a textual representation (which was versioned in Git) allows for easy editing and collaboration. Animation and graphical visualization are vital to check the presence of desired functionality, but also to check for unexpected behaviour and to gain The outcome of phase 1 is a first decomposition of the system into functional subcomponent models which can be animated. In phase 2 the model starts to stabilise, but we still experimented with various ways to integrate the components. In a refinement-based approach (e.g., Event-B) one has to decide upon a particular refinement order in which components are integrated, which can be sometimes difficult to find and tedious to change. Hence we again stayed in the classical B paradigm where the powerful machine inclusion features allowed us to experiment with various ways of assembling the entire system (see also Fig. 1 ). To ensure the proper functioning we start to write safety invariants in this phase. The verification in this phase was dominated by (safety) model checking and trace replay in the animator. The outcome of phase 2 is a functional composition into an overall system which can be animated and where various safety invariants can be checked using model checking. The last phase is dominated by proof. Here, the rodin platform's proof system is a key technology and the simplicity of Event-B's proof obligations can pay off. In this phase the decomposition of the system has stabilised and it was hence possible to transform the classical B model into a linear refinement hierarchy. This requires translating machine inclusion to machine refinement and operation calls to event extension (see Fig. 1 and Sect. 4). For functional aspects of the system we complemented proof with LTL model checking. Initially we had modelled a subset of the cruise control system, which led to a few interesting insights and issues (see also Sect. 6). However, to illustrate our modelling strategy (Sect. 2) and new visualization tool (Sect. 2) we then modelled a subset of the light system. Our models are available at: https://github.com/ hhu-stups/abz2020-models. Due to time restrictions we were unable to model the complete case study. We concentrated on the management of the blinkers, i.e., the blinkLeft and blinkRight actuators as influenced by the vertical position of the Pitman arm (PitmanArmUpDown sensor), the hazard warning switch (hazardWarningSwitchOn sensor), as well as obviously by timing constraints. The engineOn and keyState sensor values were also used. At the end of the exploratory phase (see Sect. 2) we had separated out the system into three components (see The purpose of the BlinkLamps component is to separate the management of the blink lamps from a logical state of the system. between the logical variables active blinkers and remaining blinks with the blink lamp actuators. Early versions of our model had several errors in that respect, e.g., when events such that turning an engine on or off changed the system's state without consistently updating the actuators. The PitmanController reacts to changes in the sensors and sets the logical blinking state using the operations provided by the BlinkLamps machine. For example, Listing 1.2 shows how this is achieved using two parallel operation calls, one to to SET EngineOn from the Sensors machine and one to SET BlinkersOn from BlinkLamps shown above in Listing 1.1. It is also interesting to note that the second operation call is wrapped into a conditional. We have modelled time as a discrete integer variable representing elapsed time in milliseconds. The GenericTimers machine partially shown in Listing 1.3 manages a set of deadlines. The parameter TIMERS specifies a set of timers for which one can associate individual deadlines using the AddDeadline operation. Time can be advanced using the IncreaseTime operation, but it cannot proceed beyond a deadline, thus forcing events associated with the deadlines to be executed first. This is a typical scheme to model time in B, but variations and different approaches (e.g., using a controller event executed at fixed intervals). For our modelling we needed two timers: one for the blinking phases and one for the management of "tip blinking". Future extensions of the model will probably require additional deadlines which can be easily added. ( curDeadlines /={} => curTime + delta <= min ( ran ( curDeadlines ))) THEN 12 curTime := curTime + delta 13 END ; ... The complete system model PitmanController TIME then combines the untimed pitman controller with the GenericTimers. The Listing 1.4 shows how a deadline is set for the tip blinking event. When the deadline expires without the pitmanArmUpDown sensor changing the tip blinking is converted to a regular direction blinking. newPos /= pitmanArmUpDown THEN 10 ENV_Pitman_Tip_blinking_short ( newPos , pitman_direction ( newPos )) || 11 AddDeadline ( tip_deadline ,500) 12 END ; 13 ... The above version of GenericTimers in Listing 1.3 is good for simulation or replaying traces with explicit timing information such as the ones accompanying [7] (see Appendix A). As curTime is unbounded, however, it leads to an infinite state space for model checking. Hence we also developed a second "drop-inreplacement" of this machine, which has no curTime variable: the deadlines are always rescaled as if the current time was 0 (see Listing 1.5). In our case this was sufficient to produce a finite state model. Model checking the full system with ProB takes about 2.3 s, generating 2095 states and 16472 transitions. (See [12] or [9] for related ways of model checking timed systems in state-based formal methods.) When translating a classical B composition such as the one in Fig. 2 , one has to linearise the inclusion into a refinement chain. As you can see in Fig. 3 One can see that the translation has resulted in code duplication, making it more tedious to adapt the model. A similar issue occurs at the next refinement level, where we introduce timing. As again we cannot refine multiple components, the code for the timer logic gets interspersed and duplicated in multiple events. Here we show just two instances in the PitmanController TIME MC model, which show how the guards and actions are replicated in multiple events. Event TIME BlinkerOn extends TIME BlinkerOn any delta where grd21: delta ∈ N grd22: blink deadline ∈ dom(curDeadlines) grd23: delta = curDeadlines(blink deadline) grd24: delta = min(ran(curDeadlines)) then actTm: curDeadlines Event TIME BlinkerOff extends TIME BlinkerOff any delta where grd21: delta ∈ N grd22: blink deadline ∈ dom(curDeadlines) grd23: delta = curDeadlines(blink deadline) grd24: delta = min(ran(curDeadlines)) then actTm: curDeadlines : If we want to modify the time management we need to edit multiple events in a consistent fashion, which is tedious and error-prone. The classical B model called the same operation in both cases; changing details about how time is handled just means changing or substituting the GenericTimers machine. Hence the conversion to Event-B in our methodology (Sect. 2) is delayed until the model has sufficiently stabilised. Proof Statistics and Insights. We checked the correctness of our translation by checking the state spaces generated by ProB is identical for those three models that can be compared. The results are summarised in Table 1 . In summary, the translation resulted in a model with many more events and more duplication, but was worth it in the end. The proving process was relatively painless, the rodin prover was easy to use. The proof statistics can be found in Table 2 , and the proving process itself helped to uncover a few interesting invariant properties and some issues in our sub-components (which were not reachable by the model checking, but would have appeared if the subcomponents were used differently). Also, the generation and discharging of the well-definedness proof obligations provides another safety guarantee, which is not exhaustively covered by model checking with ProB. LTL Model Checking. As the rodin model contains a series of events for one particular action, like turning the engine on or off, we wanted to check that it is always possible to turn the engine on or off and that there is exactly one event which describes the system's evolution. For this we introduced the relative deadlock and controller state LTL properties in [8] , which we used here. One particular property is the following one, which was violated by earlier versions of our translation: ENV_Turn_EngineOn_BlinkRight , ENV_Turn_EngineOn_Noblink , 3 ENV_TurnEngineOff_Blink , ENV_TurnEngineOff_Noblink )) Listing 1.6. LTL Formula The core idea of our new ProB plugin called VisB is to have a lightweight visualization engine which can be easily maintained and which make use of graphics generated with off-the-shelf editors. More concretely, VisB makes use of a SVG (scalable vector graphics) file and a JSON markup file. The markup files contains formal model expressions which specify attributes of objects which should be updated according to the current state of a formal model. The present case study description [7] contains several appealing images, which we kindly obtained from the coordinators of the case study. Luckily, some were already in the SVG format and as such relatively little effort was needed to obtain a first visualisation (after about one hour the first visualisation was working). The main work was to combine the images into a single one, iron out a few quirks in the SVG files, and change the relevant object identifiers to mnemonic names and then write a JSON glue file referring to these identifiers. The original, unmodified SVG file is shown in Fig. 4 and the start of the JSON glue file in Listing 1.7. As one can see, it specifies the original SVG file and provides instructions on how to update the attributes of objects (such as stroke-opacity) of particular objects (such as A-right corresponding to the front left light of the car). The value is given by a B expression which can reference the state of the formal model, in this case the active blinkers variable. The glue file also specifies events which should be executed when certain objects are clicked upon. The effect of applying the VisB glue file to the original SVG can be seen in Fig. 5 . This visualization shows the state of the actuators blinkLeft and blinkRight, as well as the state of the sensors keyState, pitmanArmUpDown, hazardWarningSwitchOn and engineOn. It also shows the internal state of the controller, e.g., the active blinkers variable by changing the stroke-opacity and using a light orange fill. This state is an actual error that was spotted thanks to the visualisation: the hazard warning switch is on, but only the right blinkers are on. We can also see that the pitman arm is pushed up, but the controller correctly considers both left and right blinkers to be active, but somehow the blink management component has not set blinkLeft to the expected value (100). VisB works for all of ProB's supported state-based formalisms (B, Event-B, Z, TLA+, Alloy), and as such we reused the same visualization for our classical B and Event-B models. A visualisation of the important states of the validation trace 7 from [7] can be found in Appendix A. In conclusion, with relatively little effort it was possible to generate a visualisation from the graphics of the case study specification. In addition, the visualisation glue file was re-usable for a wide variety of models (several version of the classical B and Event-B models). Some of the issues we found during implementing and especially during model checking the models are: -Per specification, the system is not commutative. In ELS-13 it is stated that any tip-blinking is ignored or will be stopped by the hazard warning lights when hazard warning is active, respectively activated. So, we do have possible traces where at the same time hazard warning light is switched off and tipblinking to either side is activated. Depending on which signal gets processed first, we either get three cycles of blinking or none at all. Same holds for switching on the engine and tip-blinking. -In cruise control: while model checking we got shown errors in the activation of the cruise control as well as in the increasing and decreasing the desired speed, these errors seemed intended or at least directly caused by the specification. Depending on the version of the specification, there were different errors: • The desired speed in an activated cruise control could be lowered arbitrarily in previous versions (up to 1.14). This led to invariant violations while model checking, as by pushing down the lever from a desired speed of 0, it was further decreased. • The same invariant violation was caused by increasing the desired speed further than said maximum. • In the current version (1.17), those are fixed, as some upper and lower thresholds are specified, as well as a minimum velocity when activating it. But as of now, when no previous desired speed is set, the scs is required to be activated at current speed (scs-2) as long as the current speed is above or at 20 km/h. Here an activation at a speed of above 200 km/h should be possible according to the specification, thus directly violating the invariant of being in the range of 1..2000. • As we have a reverse gear specified (but our speed being in the range of 0..5000), obviously the speed is measured in absolutes. That means that activation of the speed control system is also possible when in reverse gear (as long as going over 20 km/h in reverse). With possible high previous desired speed, this should either wreck our motor or gearbox fast if it keeps going and accelerating in reverse. -There was a problem with the distance in adaptive cruise control, as the distance could be set to f.e. 3 s -with speeds of 240 km/h we would have had to measure distances that are outside our possible range. The latest specification solves this issue by setting a maximum target speed of 200 km/h. -Ambient lights: els-19 states the low beam headlight should stay active for 30 more seconds with the interval being reset for example any time a door is opened or shut. We don't have sensors to measure that, as we only have a sensor to state if any door is open. So basically, this requirement has to be changed to either the 30 s cycle being reset continuously until the status of all doors is closed or to the cycle being reset only for the first door opened and respectively the last door shut. The importance of animation and visualization seems now accepted; see e.g. the applications [13] and earlier ABZ case studies [5, 6, 8] . The idea of exploratory phases has also been promoted elsewhere, e.g., in [11] . The modelling approach described in Sect. 2 has been successful. Along the way we gained insights about the relationship between classical B machine inclusion and Event-B refinement. We were successful in re-using existing graphics to generate a custom graphical visualization, which helped us validate the model and allowed us to spot one error at least (cf. Fig. 5) . A weak point of our approach is the manual translation from classical B to Event-B in phase 3. An automated translation of a subset of classical B to Event-B would reduce human effort and avoid errors in the translation. Another alternative would be to stay with Atelier-B and use its Event-B syntax, which does allow a more powerful substitution language. However, we were much more comfortable with the proving environment of rodin, hence the effort to translate the models was worth it for us here (and for an industrial system modeling project undertaken by the first author). Finally, why did we not simply do all of the modelling in Rodin to start with? The reasons are the limited tool support for structuring, editing and sharing of models. Future improvements to rodin could obviate the need to conduct the phases 1 and 2 of Sect. 2 in classical B. These improvements would require improved editing 4 with git integration, improved model composition and decomposition features. For convenience we include a condensed form of the visualisation of trace 7 from https://github.com/hhu-stups/abz2020-models. This shows trace 7 of the case study specification graphically as replayed with ProB and VisB. The B-Book Modeling in Event-B: System and Software Engineering An open extensible tool environment for Event-B Property-based modelling and validation of a CBTC zone controller in Event-B Using a formal B model at runtime in a demonstration of the ETCS hybrid level 3 concept with Real Trains Validating the requirements and design of a hemodialysis machine using iUML-B, BMotion studio, and cosimulation Adaptive exterior light and speed control system Validation of the ABZ landing gear system using proB Real-time model checking is really simple ProB: an automated analysis toolset for the B method A formal modeling tool for exploratory modeling in software development Proved development of the real-time properties of the IEEE 1394 root contention protocol with the event b method The case for using simulation to validate Event-B specifications We thank Frank Houdek, Alexander Raschke and anonymous reviewers for their useful feedback.