Fuel Level
Last updated
Last updated
This example demonstrates how to specify a software and to implement it by using a modular architecture.
We are considering to estimate the remaining amount of fuel in a tank. This information is critical for a plane, for example, because an error in the estimation might lead to a crash.
So we would like to develop a piece of software that would make the pilot aware of the situation (fuel level below a given capacity). This is in fact the main property of our software, independently from the way the fuel level is estimated.
As the sensors are likely to provide inaccurate / erroneous measures, the architecture of the system includes redundancy (2 ultrasonic level sensors, 3 flowmeters) and the estimation of the fuel left in the tank is performed in two steps:
initial level in the tank is estimated with the 2 ultrasonic level sensors (minimum value of the two measures)
each cycle, current level is estimated by substracting the maximum value given by the 3 flowmeters)
When the estimated level is less or equal to a given value, an alarm is raised.
With the B modelling, the objective is:
estimating the remaining amount of fuel
making the pilot aware of any fuel shortage
The resulting modelling contains 7 files:
fuel0 is the top level specification of our software.
fuel_i is its implementation, that requires services from measure and utils
measure is a basic machine, in charge of acquiring data from sensors. This component is implemented manually.
utils is a stateless machine offering 2 services: minimum of 2 NATURAL numbers, maximum of 3 NATURAL numbers.
utils_i is its implementation
ctx contains the definition of constants
ctx_i is its implementation. The values of the constants are provided, in order to be checked against their properties. Constants are then demonstrated to be implementable.
The machine fuel0 contains two operations:
compute_initial_level: initial estimation of the amount of fuel in the tank
compute_remaining_fuel: called repeatidly to estimate consumption and remaining fuel
The main property of this component is: (estimated_level <= WARNING_CAPACITY => status = LOW_LEVEL)
The variable status is used to raise an alarm.
This implementation fuel_i implements the two operations defined in fuel0, and imports services from measure and utils.
The component measure provides two services: measure_level and measure_consumption. These two operations have to be developped manually.
The component utils provides two services: minimum and maximum.
The component utils_i implements the two services defined in utils
The component ctx contains the constants of the software.
The component ctx_i contains the values of the constants.
Once the project is created (software development), add the various machines starting with ctx, utild, measure, then fuel0. Then create the implementations. Each time, create the component empty then copy-paste the contents from this page.
Once all the components are in the project:
generate the proof obligations (button Po on the toolbar)
execute the proof in force 0 (button F0 on the toolbar)
execute the proof in force 1 (button F1 on the toolbar)
You should obtain the following status below from the Top-Bottom graphical view. The color green indicates that the components are fully proven.
When everything is proved:
generate C code for the implementations fuel_i, Utils_i, and Ctx_i,
Generate C code for the machine Measure: you obtain a skeleton for your C file. Complete measure.c manually, using for example a random number generator to simulate fuel consumption.
Create main.c such as
void main(void ) {
fuel0__compute_initial_level();
while(fuel0__estimated_level>0) {
fuel0__compute_remaining_fuel();
printf("Consumption = %d, Level = %d, status = %d\n",
fuel0__estimated_consumption,
fuel0__estimated_level,
fuel0__status);
}
}
Compile main.c fuel0.cpp utils.c measure.c
Execute the resulting software