Car Lock
You should design the controller of a car lock. The controller is one of several modules in the car, which are connected via a CAN-bus, that sends signals between the modules.
The controller gets input from the remote car key, which can send the commands key_unlock
and key_lock
. (The necessary encryption and security mechanisms are implemented between the car key and the key component, but not detailed here.) The controller send the signals unlock
and lock
to the lock component. It can also detect if the car door was opened or closed, via the signals door_opened
and door_closed
. Below is a diagram that illustrates all components and the CAN bus.
The following are the functional requirements for the controller:
- R1.1: When the button
Unlock
is pressed, the door is unlocked. - R1.2: When the button
Lock
is pressed, the door is locked. - Assume that the controller starts in a state where the door is closed and the lock is locked.
The following signals are sent between the components via the CAN-bus:
- From Remote Key Controller to Car Lock Controller:
key_unlock
,key_lock
- From Car Lock Controller to Door Controller:
unlock
,lock
- From Door Controller to Car Lock Controller:
door_opened
,door_closed
To send a signal, use method send_signal('...')
with the signal name as argument.
To react on the reception of a signal, simply write that signals as the trigger of a transition.
Task 1: Design a state machine in for the Car Lock Controller that keeps track of the state of the door and the lock, and that implements the functional requirements from above.
Task 2: Now, add the following functional requirement and create another version of the state machine. (Edit as a copy of the sheet.)
- R2.1: If a door is unlocked but not opened, it is locked again after 60 seconds.
Solution
This implies that we add a timer to the state machine with a transition reacting to it once the timer expires. We do this in the state machine below. It is important that we use the exit/stop_timer(t) action to state closed_unlocked
, to prevent a sequence where the user quickly opens the door, then closes it again, then the timer (which was not stopped) to expire and the lock to close. This is prevented by explicitly stopping the timer.
Another solution adds an additional state, here called closed_unlocked_timed
. This state covers explicitly that the timer is active, and we leave this state either by the timer expiration or by opening the door.