The Refinement of Embedded Software with the B-Method

This paper describes the use of formal refinement within the MIST project. MIST (Measurable Improvement in Specification Techniques) is ESSI application experiment 10228. It is an 18 month project involving three companies: GEC-Marconi Avionics, who are the prime user; Praxis, who are the main subcontractor, acting as an independent reviewer; and B-Core (UK), who provide the tools used and consultancy. The main aim of MIST is to develop practical procedures for applying formal methods in conjunction with current methods for safety critical avionics software development. 
 
The paper describes a specification style developed by the project that models embedded software within a systems context. It also describes a style of refinement, known as structural refinement. The paper illustrate both with a small example and also reports on their application to a large case study within the MIST project. Initially, there were some problems in using the B-Toolkit with structural refinement, but most of these were overcome by a new B-Toolkit. The embedded specification style worked well and allowed the embedded software to be specified with abstract interfaces and refined with concrete interfaces. The structural refinement allowed the design to be partitioned fairly quickly. Overall, refinement was easier than expected, taking 65 days compared to 48 days needed to write the abstract specification. The proof of the refinement was only achieved because the design had been partitioned by the structural refinement.


Introduction
This paper describes the use of formal renement within the MIST project [1,2 ].MIST (Measurable Improvement in Specication Techniques) is ESSI application experiment 10228.It is an 18 month project involving three companies: GEC-Marconi Avionics, who are the prime user; Praxis, who are the main subcontractor, acting as an independent reviewer; and B-Core (UK),who provide the tools and consultancy.The main aim of MIST is to develop practical procedures for applying formal methods in conjunction with current methods for safety critical avionics software development.It is intended that these procedures will be used to meet standards such as DEF-STAN 00-55 [3].There are three main phases in the MIST project.First, to propose an initial set of procedures for using the B-Method on parts of embedded real-time systems.Second, to apply these procedures to an avionics case study allowing the procedures to be improved and data collected on the use of the procedures.Third, to use the data to compare the formal development with a parallel development of the same case study using structured methods.The project developed a style for the application of the B-Method to embedded systems and a BCS-FACS Northern Formal Methods Workshop, 1996 style of renement, known as structural renement, where the B-Method is used for partitioning specications.The rest of this paper is laid out as follows.Section 2 gives an overview of the B-Method.Section 3 describes the MIST development lifecycle.Section 4 gives an overview of the renement s t yles in the MIST project.Section 5 illustrates structural renement with an example and the nal sections contain the results and conclusions.

Overview of the B-Method
The formal method used in the MIST project is the B-Method [4,5] which is supported by the B-Toolkit [6].The extensive support provided by the toolkit was a major factor in the choice of the B-Method.The B-Method is a collection of mathematically based techniques for the specication, design and implementation of software components.Systems are modelled as a collection of interdependent abstract machines, for which an object-based approach is employed at all stages of development.
An abstract MACHINE is described using the Abstract Machine Notation (AMN), a statebased formal specication language in the same school as VDM and Z.A uniform notation is used at all levels of description, from specication, through design, to implementation.Large MACHINEs can be constructed from other MACHINEs using the INCLUDES and SEES constructs.MACHINEs are rened using IMPLEMENTATIONs.IMPLEMENTATIONs are constructed using a numberof IMPORTed lower level MACHINEs.The operations of an IMPLEMENTATION are described using a programming subset of AMN.
The B-Method prescribes how t o c heck the specication for consistency (preservation of invariant) and how t o c heck designs and implementations for correctness (correctness of data renement and correctness of algorithmic renement).

MIST Development Lifecycle
The MIST development lifecycle, shown in gure 1, starts with a set of requirements written in an informal but structured notation.The B-Method is used to respecify these requirements and produce a formal abstract specication written in AMN.The abstract specication models the software within the system context.It describes system operations that interface with the software as well as the operations required to be performed by the software.Some of the lower level details are not included at this abstract level.The abstract specication is animated, formally proved consistent and reviewed.The rst level of renement is carried out on types and constants by enumerating sets and giving values for constants.There are two parallel development routes that produce executable code from the specication containing rened types and constants.The main development route gradually designs and implements the specication through a number of formal renement steps.The entire model, including both the system and the software operations, is rened but only the software operations are translated, by hand, into Ada.The Ada derived from the formal specication is interfaced with informally developed Ada in order to produce executable code.The prototype development route uses the code generation features of the B-Toolkit to rapidly produce a C implementation.The C prototype is used to generate test cases to verify the Ada code against the abstract specication.Most of the initial renements are structural renements, used to partition the design.The smaller specications, resulting from the structural renement, are rened using detail, data or operational renement.Data and operational renements build their implementations from library machines or very low level specications that can be translated into code.Detail renements increase the complexity of the specication and may b e followed by further structural renement.Type renement can be performed at any stage, but it is often the rst renement step.

Data Renement
Data renement i s the most general form of renement.It is used to implement abstract state variables using concrete variables.In the MIST project, data renement w as only applied to small component specications in order to make v erication practicable.
The Renement o f E m bedded Software with the B-Method The concrete state and operations on that state are dened in a concrete machine, such as library machines.This machine is IMPORTed into the IMPLEMENTATION machine which implements the abstract operations using concrete operations.The IMPLEMENTATION links the abstract and concrete variables by a renement relation.This relation is usually dened in a separate context machine.For example, an abstract state could an enumerated set of values representing hardware registers and their concrete representation could be an array of booleans.

Operational Renement
Operational renement is a specialisation of data renement where the abstract and concrete types are the same.This makes it easier to verify than general data renement.
Operational renement rewrites the abstract operations with concrete operations.Abstract operations are specied using abstract statements such as parallel composition and unbounded choice, whereas concrete operations use concrete statements such as sequential composition and loops.

Structural Renement
Structural renement is a specialisation of operational renement where the changes to the operation specications are minimised.It allows the design to be partitioned and each part to be rened independently.Structural renements are the largest renements performed on the development, and hence it is important t o k eep the complexity of the renement as simple as possible.
Generally, large abstract specications are built up from a tree of INCLUDEd machines.The principal step in structural renement is to write an IMPLEMENTATION for the top level abstract machine and IMPORT lower level abstract machines.The structure of the lower level abstract machines will partition the development i n to specications which can be rened independently.Machines with state variables of the same type will be grouped together.
In the lower level machines the interface to operations must use concrete values so that when the operations are used in the top level IMPLEMENTATION the parameter passing between operations is concrete, enabling the operations to be translated directly into code.The lower level machines will also have t o p r o vide enquiry operations for their state variables.State variables can be examined directly in abstract specications but are only visible in IMPLEMENTATIONs through enquiry operations.New operations are also provided which perform the abstract functions from the top level abstract specication.An example of structural renement i s g i v en in section 5.

Detail Renement
Detail renement i s a s t yle of renement that is used to remove under-specication.It expands abstract state variables and respecies the abstract operations to show h o w they act on the expanded state.As detail renement is usually performed on a small specication, after the overall design has been partitioned using structural renement, it is usually relatively easy to verify.An example of detail renement is splitting an abstract message validation function, and its associated check data, into several concrete validation functions.
BCS-FACS Northern Formal Methods Workshop, 1996 The Renement o f E m bedded Software with the B-Method

Type Renement
Type renement is a specialisation of detail renement where only the types and constants are rened.A new context machine is written that INCLUDES the abstract context machine and expands the denitions of the types and constants.An example is where a deferred set is given explicit values.The verication demonstrates that the concrete values for the types and constants introduced by the type renement, meet their abstract specications.

Verication and Validation of Renement
All the renements are syntax and type checked by the B-Toolkit.The B-Toolkit also generates the proof obligations to show the correctness of the renement.For type renement there are only context proof obligations.All the renements are reviewed to validate the design.The detail and type renement reviews also validate the extra information, added in the specication, against the informal requirements.

Example of Structural Renement
This section uses a small example to illustrate the process of structural renement.The example is a simple, embedded software system.The software receives inputs commands from one hardware interface.It validates the commands and sets the appropriate hardware registers.The starting point is an abstract specication, which is a formal description of the functionality of the system encapsulated within a collection of abstract MACHINEs.Structural renement i s then performed to partition the top level structure into two parts that can be rened independently.

Abstract Specication
The abstract specication models the system and software operations to input, validate and process commands and read the registers.This functionality is described in three separate machines which are combined into one top level machine, as shown in gure 2. This structuring provides a clear view of the system boundary by separating the input commands from the software functions.COMMAND !!REGISTER ĉommandsToRegisters = f com1 7 !reg1 , com2 7 !reg1 , com3 7 !reg2 g END Figure 3: Example System Input and Context Machines specication and allows several machines to make use of the same denitions.The Input machine provides a system operation, LoadCommand, to update the system input.The input commands are validated in the Validation machine, shown in gure 4. The state variable checkcom, of the type subset of COMMAND, represents the software copy of the input commands after they have been validated.This state is set by the operation RecordCheckedCommand which has a precondition that all the inputs must be in specialCom.The constant specialCom is a subset of COMMAND, as dened in the Context machine.All the processing of the commands and the resultant setting of hardware registers is performed in the Processing machine, shown in gure 4. The hardware state is modelled as the variable registers.The operation SetRegisters takes valid commands as input and sets the appropriate hardware register using the constant function commandsToRegisters, dened in the Context machine.The state of the hardware registers is retrieved by the system operation, GetRegisters.The TopLevel abstract specication, shown in gure 5, combines the lower level machines using the INCLUDES structuring mechanism.This provides visibility t o all the state and the ability to use all of the operations in the INCLUDEd machines.The system operations to update the input commands (LoadCommand) and to retrieve the output state (GetRegisters) are PRO-MOTEd directly which means that these become operations at the TopLevel and are visible to the The AMN is structured carefully to enforce the constraints on the embedded software.For example, the load operation in the Input machine is externally visible but should not be accessible by the software functions in the abstract specication.This is achieved by INCLUDing the Input machine at the TopLevel but only SEEing it from the software machines, Validation and Processing.

Structural Renement
In this section the example abstract specication is structurally rened.The purpose of structural renement is to allow the design to be partitioned so that each part can be rened independently.In the abstract specication, provided the input commands are valid two operations, Record-CheckedCommand and SetRegisters, are called in parallel.In the renement this parallel composition is replaced by a sequence of operations to record the valid input commands and then set the appropriate hardware registers.The RecordCheckedCommand is reused from the abstract specication because it does not have a n y input or output parameters.Operations with parameters are rewritten to use concrete types.The type of the parameters passed between internal operations must be concrete because they cannot bechanged and need to be translated directly into code.For example, the SetRegisters operation is replaced by a new operation, SetRegisters2.The only dierence between the two operations is their interface.SetRegisters receives commands of the abstract type whereas SetRegisters2 receives commands of the concrete type.The result of applying the operations is the same -the state variable registers is updated.

BCS-FACS Northern Formal Methods Workshop, 1996
The Renement o f E m bedded Software with the B-Method SetRegisters2 is specied in a new machine, Processing2, as shown in gure 9. Processing2 IN-CLUDES the Processing machine and has visibility to the registers state variable and the Se-tRegsiters operation.This allows SetRegister2 to accept concrete parameters as input, convert these into their abstract equivalent and call the original SetRegisters operation.In the abstract specication, TopLevel can directly examine state variables of INCLUDEd machines.In TopLevelI the state is not directly visible because IMPORTing machines only allows access to operations.Hence, the value of the parameter used in SetRegisters2 must be retrieved using a new enquiry operation, GetCheckedCommands.This operation is specied in ValidateInput.

MACHINE
The IMPLEMENTATION TopLevelI along with its IMPORTed abstract machines is a renement of the abstract specication.The two new abstract machines, ValidateInput and Processing2, can be separately rened.
The Renement o f E m bedded Software with the B-Method

Experiences of Rening a Case Study
The Case Study used for the MIST project addresses part of the software controlling a Station Unit on a military aircraft.The Station Unit holds one store (a fuel tank or missile).The Station Unit receives commands from a central armament control unit.These commands can order a store to be armed or released, or the Station Unit to perform tests on itself.Before reacting to any commands, the Station Unit checks that the message containing the command is valid by performing a number of data encoding checks.The Case Study is restricted to the main control and function of the Station Unit and covers about 20% of the total software.It is estimated to be equivalent to approximately 3,000 lines of Ada.In total, 15 renement steps were performed during the MIST project.The rst renement w as a type renement that gave explicit values, although still abstract, for many of the abstract types and constants.This rst renement w as used as the starting point for both the prototype and the remaining formal renements.Table 1 shows that 8 new context machines were used to capture these explicit values.There were 31 context proof obligations (shown in the Proofs from Mach column) generated from the types renement.
The other proof gures for the abstract specication and other renement stages do not include context proof obligations.These were found to be dicult existential proofs that were repeated as the context was built up.It was thought more appropriate to review these obligations.
Of the 793 proof obligations generated from the renement steps, 790 were proved.The remaining 3 proof obligations were dicult existential proofs produced by a non-deterministic operation which reset state variables.It was thought more appropriate to review these proof obligations.The top level renement, Level 1, was functionally equivalent to the abstract specication.It described exactly the same operations as the abstract specication, only in a more concrete style.Thus, the renement w as expected to be larger than the specication.It was larger but because of the reuse of the abstract specication, there were only 14 pages of new items in the renement (shown in the Pages of Implementations and Machines).This is compared with 80 pages in the abstract specication.It can also be seen that the renement operations were, on average, smaller than the abstract operations.This is because many of the renement operations simply provided new interfaces to abstract operations and enquiry operations to retrieve the value of state variables.A similar pattern is exhibited in the second and third structural renements, Level 1.1 and 1.2 where there were a total of 24 pages of new items.

Pages of Operations in
During the structural renements of Levels One of the abstract specications produced by the last structural renement w as expanded with detail renement.(The size of the last structural renement is shown in the rst row of table 3).It was expected that the detail renements of this specication would result in a large number of new specications required to capture the extra information.This is reected in the gures in table 3. The higher level detail renement is the same size as the specication of the last structural renement e v en though it only forms a third of the actual renement step.Similar conclusions can be drawn from the lower detail renement.Again, it is only a partial renement of the higher level and is of a comparable size.
The lowest level renements were data or operational renements.These use library machines and so generally introduced fewer new abstract specications.The number of proof obligations generated by data renement w as dependent on the programming style of the AMN implementations.For example, one data renement initially generated an excessive number of proof obligations (over 4000) as a result of a large number of paths through the code (over 1000).The renement was re-written to reduce the number of paths and this reduced the number of proof obligations to 94, but increased their complexity.Far fewer proof obligations were generated for the machines used to support the renement than were generated for the abstract specication (102 vs. 311, as shown in table 1).This was expected, as the abstract specication had a number of complex invariants stating important properties of the system.The new specications used by the renements tended to have simpler invariants.
The Renement o f E m bedded Software with the B-Method In total, 13 errors were found during renement.Two of these were in the abstract specication and were discovered whilst writing the renement.Writing a renement forces an engineer to carefully review and understand the specication.The required corrections to the abstract specication did not have a large impact on the renement.The remaining 11 errors were in the renement and were discovered during proof.
In the MIST project the eort taken to specify, prove and document all 15 renement steps was 65 days, as shown in table 4.  The table is dominated by the eort needed to prove the four dicult data renements, over 75% of the proof time and almost half the total time spent on the renement.This is not a general problem with data renements, the other data renements were proved in a single day, but reects the complexity o f these particular data renements.A signicant length of time was needed to prove the detail proof obligations, but the structural proof obligations were relatively easy.Overall, if the dicult proofs are ignored, the renement took less time than the abstract specication.This was a very surprising result | it was expected that the renement would take much longer.Even including the dicult proofs the renement took only slightly longer.As renement was thought to be harder than specication, more experienced engineers performed the renements.Even allowing for this, the renements were written and veried with much less eort than expected.The major gain in eort in the renement process was due to the substantial reuse of the abstract specication during structural renement.All 5 structural renement steps were completed in less than a third of the time it took to write the abstract specication.

Spec
The nal product of the renement process was a collection of AMN IMPLEMENTATIONs and simple specications of interfaces, mainly hardware.Ada source code was produced for part of the Case Study.The AMN IMPLEMENTATIONs were translated into 800 lines of Ada source code.A further 1400 lines were informally developed from the simple specications.It was estimated that 600 more lines of Ada would be produced from the remainder of the Case Study.

Conclusions
The renement of the MIST case study has been very successful, in particular the style of specication and renement used to model embedded software and to partition the top level design has worked well.

Figure 4 :
Figure 4: Example Validation and Processing Machines

Figure 5 :Figure 6 :Figure 8 :
Figure 5: Example Top Level Machine The structure of the example renement is shown in gure 6.

Figure 9 :
Figure 9: Example Rened Processing and Context Machines op level renement proofs were not proved.6 d a ys of animation and 8 days of review on the abstract specication.7 d a ys of review on the renements.
The Renement o f E m bedded Software with the B-Method In the MIST project there were several styles of rening abstract specications:1.Data Renement | to replace abstract states with concrete states, 2. Operational Renement | to replace abstract algorithms with concrete algorithms, 3. Structural Renement | to partition the top level structure, 4. Detail Renement | to expand the abstract state and functions, 5. Type Renement | to fully dene deferred types and constants.

Table 1 :
Size of Case Study RenementsFollowing type renement, ve structural renements were performed ( Level 1 to 1.1.2).A more detailed breakdown of the gures for structural renement i s g i v en in table 2.

Table 2 :
1, 1.1 and 1.2 a problem was encountered with the Proof Obligation Generator (POG) of the B-Toolkit.The algorithms used by the POG needed a lot of temporary storage and early versions of the B-Toolkit failed to generate all the proof Size of Structural Renements obligations.For example, one operation in Level 1.2 had a seven-way CASE statement (in both the specication and the renement) which led to 49 copies of each proof obligation (of which 42 were trivially true).Other renements, in Level 1.1, were simply large and had large proof obligations.Later versions of the B-Toolkit, with more ecient POG algorithms, managed to generate all the proof obligations for the second level renements (Levels 1.1 and 1.2).However, the top level renement, Level 1, which w as large and had a CASE statement, is still too complex for the current v ersion of the B-Toolkit (3.1).However, B-Core are making improvements to the POG algorithm so that it can cope with renements of the size and complexity of the top level.Once generated, the proof obligations for the structural renement w ere easy to prove.

Table 3 :
Size of Detail Renements