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

More documents

Recommendations

Info

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()) {
Page 1 and 2: Model-Driven Development CIS 542 Em
Page 3: The EFSM allows us to verify some d
Page 7 and 8: Here's the code for the controller:
Page 9 and 10: Because programmers often make off-
Page 11: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?