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

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;