CIS 542 Embedded Systems Programming – Summer 2013 Lecture ...

Model-Driven Development
CIS 542 Embedded Systems Programming – Summer 2013
Lecture #3: Model-Driven Development and Verification
Embedded systems typically involve some sort of closed-loop control cycle in which the software (or
“controller”) gets input from the outside world (referred to as the “plant”), decides on some action to
take based on the current state and the input, and then sends some sort of control signal as the output.
The software can be modeled using a state machine that represents each state the software/system can
be in, what causes it to transition to another state, and what is the output when it does so.
The model (state machine) is usually created before the software is written so that any potential
problems can be identified early on: it is well known that, the earlier in the software development life
cycle that problems are detected, the easier/cheaper it is to fix them.
We can use a finite state machine (FSM) to represent the model of our software controller. An FSM is
a graph in which:
• nodes/vertices represent states in the system
• edges represent transitions between states
An extended finite state machine (EFSM) is an FSM that allows for boolean trigger conditions for the
transitions.
As a running example, consider a home security system described as follows:
• when the system is armed, if motion is detected by the sensor, the alarm will sound
• when the alarm is sounding, it can be turned off it the user correctly enters the password, but the
system will still be armed; if the password is entered incorrectly, the alarm will continue to
sound
• the user can disarm the system by entering the password correctly; if the password is entered
incorrectly, the alarm will sound
• once the system is disarmed, the user can choose to arm it
• regardless of whether the system is armed or disarmed, the user can cause the alarm to sound by
using a panic button
We can create an EFSM to model this system like so:

disarmed
disarm &&
input ==
password
arm
armed
panic
disarm &&
input !=
password
panic
motion
alarm
sounding
quiet &&
input == password

The EFSM allows us to verify some desirable properties of this system. For instance:
• it is always possible to sound the alarm (we know this is true because there is a path from each
state to the “alarm sounding” state)
• it is always possible to disarm the system (there are paths from all states to “disarmed” too,
though they require the input to be equal to the password)
These are referred to as liveness properties: desirable things that can always (eventually) happen.
Automata-Based Programming
How would you implement the above EFSM in code? If you don't think it through, this can easily turn
into an unwieldy mess of if/else statements (just look at the original specification!).
A simpler approach, known as automata-based programming, is to use enums to represent the
different possible states and signals, and then simply use switch statements to first figure out which
state you're in, and then which signal you've received, and then act accordingly.
For instance:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
enum states {disarmed, armed, alarm_sounding} state;
enum signals {arm, disarm, panic, motion, quiet};
void handle_signal (enum signals signal) {
switch (state) {
case disarmed:
switch (signal) {
case arm:
state = armed;
break;
case panic:
state = alarm_sounding;
break;
}
break;
case armed:
switch (signal) {
case panic:
state = alarm_sounding;
break;
case motion:
state = alarm_sounding;
break;
case disarm:
if (password_correct()) state = disarmed;
else state = alarm_sounding;
break;
}

32
33
34
35
36
37
38
39
40
41
42
}
break;
case alarm_sounding:
switch (signal) {
case quiet:
if (password_correct()) state = armed;
break;
}
break;
}
Line 1 enumerates all the possible states we could be in, and defines a global variable called state.
Line 2 enumerates all the possible signals we could receive.
Line 4 is the beginning of the function that would represent our controller. We can imagine that another
function gets information from the outside world (either through a sensor or some input device) and
then calls this function to update the state and to take whatever action is necessary.
Line 6 is the start of a switch statement that runs the entire length of the function. It is used to figure
out what to do for the state we're currently in.
For instance, lines 8-17 handle the case where we're in the “disarmed” state. Now we switch on the
signal we've received (line 9). If the signal is “arm” (line 10), we move to the “armed” state (line 11). If
the signal is “panic” (line 13), we move to the “alarm_sounding” state (line 14). For any other signal,
we do nothing, as shown in the EFSM.
Note that, for the “disarmed” state, the number of cases in its switch statement (lines 9-16) is the same
as the number of edges exiting that state in the EFSM. This makes it easy to check that you've included
all transitions and successfully matched the code to the EFSM.
But how do we know it correctly implements the EFSM as drawn above? That is, how do we know that
the transitions it makes are the right ones?
This question can be answered through software testing: we come up with inputs (signals) and, using
the EFSM as our guide, make sure we're always in the state we expect to be in.
If we think of the EFSM as a graph, obviously there are an infinite number of paths through it (because
of the loops), so we can't test all of them. However, we don't need to: the assumption is that it doesn't
matter how we got to a certain state, all that matters is that, when we're in that state, we make the
correct transition for the signal we receive.
We can now create test cases in which we set the state that we want to be in, call “handle_signal” with
the appropriate signal, and then check which state we transitioned to.
state = armed;

handle_signal(motion);
if (state != alarm_sounding) printf(“Test case failed!\n”);
Note that for m states and n signals, we should have mn test cases: one for each combination. So, to
really cover all the possibilities, we should also check to see what happens when we receive signals that
should not change the state:
state = disarmed;
handle_signal(motion);
if (state != disarmed) printf(“Test case failed!\n”);
Now that we have this simple structure in place, we could add function calls to things like sound_alarm
(e.g. between lines 14 and 15), which would either send output signals or take some other action. For
instance (additional changes in bold):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
enum states {disarmed, armed, alarm_sounding} state;
enum signals {arm, disarm, panic, motion, quiet};
void handle_signal (enum signals signal) {
switch (state) {
case disarmed:
switch (signal) {
case arm:
state = armed;
arm_system();
break;
case panic:
state = alarm_sounding;
sound_alarm();
break;
}
break;
case armed:
switch (signal) {
case panic:
state = alarm_sounding;
sound_alarm();
break;
case motion:
state = alarm_sounding;
sound_alarm();
break;
case disarm:
if (password_correct()) {

33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
}
state = disarmed;
disarm_system();
}
else {
state = alarm_sounding;
sound_alarm();
}
break;
}
break;
case alarm_sounding:
switch (signal) {
case quiet:
if (password_correct()) {
state = armed;
arm_system();
}
break;
}
break;
}
Alternatively, we could make “state = armed” the first statement in the “arm_system” function, but you
could conceivably have a situation in which a function is called in two different states, so you
shouldn't bind the state and the functionality too much.
Testing
Let's look at another example. It's the cruise control system for a car. Here's the specification:
• if the driver chooses to accelerate, the speed increases by 10, unless that would put the speed
over 100, in which case it doesn't change
• if the driver chooses to break, the speed decreases by 10; if that would put the speed below 0,
the speed becomes 0
• if the speed is 0, the car stops

Here's the code for the controller:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
enum states {moving, stopped};
enum events {accel, brake};
int control(int speed, enum events event, enum states *state) {
}
int new_speed;
switch (*state) {
case moving:
switch(event) {
case accel:
if (speed

We've already seen how to make sure that it progresses to the right state, but now we also want to
check that it correctly updates the speed.
Obviously, the solution here is testing. Testing is the activity of giving input to the code to see how it
behaves. The goal of testing is not to show that it is correct, but rather to show that there are bugs (or
faults, as we say).
Broadly speaking, there are two ways to create test cases for a piece of code:
• Black-box testing: look at the specification and come up with inputs that exercise as much of
the spec as possible, i.e. try all the different conditions that are described
• White-box testing: look at the code and come up with inputs that exercise as many
statements/paths/branches as possible, i.e. try all the code
Let's start with black-box testing. Consider this part of the spec:
“if the driver chooses to accelerate, the speed increases by 10, unless that would put the speed over
100, in which case it doesn't change”
There are two conditions here that we'd want to check:
1. the driver chooses to accelerate, but that doesn't put the speed over 100
2. the driver chooses to accelerate, and that does put the speed over 100
For each of these, we make the assumption that if it works correctly for some input, it will also work
correctly for “similar” inputs. This is known as equivalence partitioning. For instance, if we decide to
use 20 as the speed for #1, and it works correctly, we probably don't need to also test 21, 22, 30, 40, 80,
etc.
So we can now create some test code like this:
/* this tests accelerating but not going over 100 */
int curr_speed = 20;
enum events event = accel;
enum states curr_state = moving;
int new_speed = control(curr_speed, event, &curr_state);
if (new_speed != 30)
printf(“control returned wrong speed!\n”);
if (curr_state != moving)
printf(“control returned wrong state!\n”);
/* this tests accelerating but trying to go over 100 */
curr_speed = 95;
event = accel;
curr_state = moving;
new_speed = control(curr_speed, event, &curr_state);
if (new_speed != 95)
printf(“control returned wrong speed!\n”);
if (curr_state != moving)
printf(“control returned wrong state!\n”);

Because programmers often make off-by-one errors, we also want to include test cases that what
happens when values are very close to the boundary between different parts of the spec. These are
known as boundary conditions. In this case, it would be if we try to accelerate and the speed becomes
exactly 100.
/* this tests accelerating but and going exactly 100 */
curr_speed = 90;
event = accel;
curr_state = moving;
new_speed = control(curr_speed, event, &curr_state);
if (new_speed != 100)
printf(“control returned wrong speed!\n”);
if (curr_state != moving)
printf(“control returned wrong state!\n”);
What about white-box testing? In this approach to identifying test cases, we pick a particular statement,
path, or branch, and then come up with inputs that cause it to be executed.
For instance, if we wanted to cover the statement (line 20) in which we switch the state to “stopped”,
then we'd have to figure out the inputs that would get us there. Clearly, we need:
• *state == moving, so that we go to line 9 in the outer switch statement
• event == brake, so that we go to line 16 in the inner switch statement
• new_speed

A tool you can use to measure coverage is called “gcov”. To use gcov, run the following:
gcc -fprofile-arcs -ftest-coverage myprog.c -o myprog
./myprog (this creates myprog.gcda/data and myprog.gcno/graph)
gcov myprog.c (this creates myprog.c.gcov)
gcov -b myprog.c will also give branch coverage info
Verification
Testing is nice and easy but, as has been famously pointed out, “testing can only prove the existence of
bugs, not their absence.” This is because, when we test, we pick representative inputs but we don't
choose all possible inputs and/or all possible behaviors.
It would be better to actually prove certain properties of the code. This is known as verification. In the
systems we're interested in here, these are often referred to as safety properties: we want to be able to
prove that there are certain bad things that can never happen.
For instance, in this case we may want to prove that the speed is always less than or equal to 100. This
can be done using a technique called model checking: we want to show that our code adheres to this
“model of correctness”.
Here is a piece of code that would use our control method:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
drive_car() {
}
int speed;
enum states state;
while (1) { // keep looping and waiting for signal
}
// assume this is our interface with the hardware
int signal = get_signal_from_driver();
enum events event;
if (signal == 0) event = brake;
else if (signal == 1) event = accel;
else continue; // illegal signal
speed = control(speed, event, &state);
To prove that the speed is always less than equal to 100, we can use a tool called BLAST. When using
this tool, we attempt to show that the property can never be violated: that is, that it is impossible for the
speed to go over 100.
Here is an updated version of the code that could be used with BLAST:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
drive_car() {
}
int speed;
enum states state;
while (1) { // keep looping and waiting for signal
}
// assume this is our interface with the hardware
int signal = get_signal_from_driver();
enum events event;
if (signal == 0) event = brake;
else if (signal == 1) event = accel;
else continue; // illegal signal
speed = control(speed, event, &state);
if (speed > 100) {
// oh no!
goto ERROR;
ERROR: break;
}
What's going on here? We are going to try to use BLAST to show that the line labelled “ERROR” (line
21) is unreachable. That would prove that line 18 can never be true, which means that speed can never
be more than 100. We need the goto statement on line 20 because if there is no reference to the label,
the compiler will take it out.
When you run BLAST, it will tell you one of three things:
• the line is reachable: the program is unsafe
• the line is not reachable: the program is safe
• BLAST can't figure out whether it's reachable: so it assumes the program is unsafe
If you use BLAST on this code, you'll see that it says that the program is unsafe! Why is that?
The reason is that we have not initialized speed and state on lines 3 and 4. Because they are stack
variables, they will inherit the values that are there when this function is invoked. And if speed just so
happens to be over than 100, and state just so happens to be 1 (which is “stopped”), and the event is
brake, then we'll end up on line 33 of the control function, in which we return the same speed, which
would be over 100. Oops!
Note that verifying that the speed is never over 100 is not the same as “proving correctness” in this
case. After all, if we just had our control function always return 8, this property would be satisfied.
That's why we need test cases, too!