System State Machine

The docking station management is administered through the implementation of a state machine. Four system states exist, each relating to specific state-entry paths and actions. The states are: standby, locked, unlocked and alarm. The command handler function presented in Section 8.7.1 administers the commands initiated by the user and the system, and integrates the command with the change state function. The change state function presented in Section 8.7.2 administers the state navigation and implementation.

Figure 53: System State Machine Flow Diagram

Figure 53 above illustrates the state machine flow, as well as the main actions performed upon state entry and exit. Upon system start-up, the standby state is entered. All locking mechanisms remain unlocked and the sensors inactive. Upon receiving the lock command, the system enters into the locked state. Upon entry of the lock state, three actions are performed; the theft detection sensors are calibrated and tested, the latching mechanisms are engaged, and the theft detection system is activated. Sensor calibration prevents the system from locking and activating without a bicycle being present, or with the sensors being in an unstable state. Only if all actions are performed successfully does the system enter the locked state. While the system is in the locked state, the latches remain engaged and the theft detection system remain active to detect any attempts of theft. Upon receiving the unlock command, the system initiates entry into the unlocked state. Entry into the locked state includes disengaging the latching mechanisms, and deactivating the theft detection system. In the case that the system is in the

locked state, and the alarm flag is triggered by the theft detection system, the system moves

into the alarm state. Upon entry of the alarm state, an audible alarm is activated, while relevant parties are notified of an identified attempt of theft. The system is then in the alarm state. To exit the alarm state, an unlock command from the user is required. Exiting the alarm state disengages the audible alarm, and places the system in the standby state – with the latching mechanism still engaged and the signal processing software still active. To exit the alarm state, the unlock command is required from the user.

8.7.1 Command Handler Function

The command handler function administers the reception of commands from the user though the serial-communication gateway, and integrates the command with the change state function. The command handler function is situated in the main program loop, and responds to any data that is available on the Serial1 channel which interfaces with the Photon Particle IoT gateway. In the case of the function responding to data available on the Serial1 interface, the relevant command is extracted from the data according to the protocol discussed in Section 8.5. The command is then translated to the corresponding format, and forwarded to the change state function – which then interprets the state change and administers the functions related to the command’s corresponding state change request.

In the case of the theft detection sensor systems detecting an attempted theft, the alarm flag is raised. This results in an “alarm” command being created by the theft detection system, which is then processed by the command handler function to administer the actions relating to the

8.7.2 Change State Function

The change state function is situated outside the main program loop, and is executed upon call- up from the command handler function. The function manages the state navigation as illustrated in Figure 53 on page 78, and administers the actions and functions to be executed that relates to a specific state change. Figure 54 presents the function flow diagram of the

change state function.

Figure 54: State Change Function Flow Diagram

The function structure is a switch-case implementation that receives the desired state as input and switches accordingly. State navigation is performed by the switch implementation, which channels the execution into relevant lock, unlock, status or alarm streams.

If the lock state is requested, the calibration(), lockPin_Lock() and inputInterON() functions are called. These functions checks weather the sensors are stable, locks the latching mechanism and activates the sensors. If all three functions are executed successfully, the current state is changed to locked and the function ended. If the unlock state is requested, the function checks to see what the current state is in order to determine the required actions based on the state exiting from. If the locked state is the current state, the lockPin_Lock() and inputInterON() functions are called. This disengages the latches and deactivates the sensors. The bicycle can now be removed from the dock. If the unlock state is requested, and the current state is the

alarm state, the audible alarm is deactivated with deActivateAlarm(), and the standby state is

entered. If the alarm state is requested, the activateAlarm() and notifications() functions are executed. These trigger the audible alarm and executes the relevant parties’ notifications. In the case that the status state is requested, the returnState() function is executed which send the current state to the Serial1 gateway, with no permanent state changes that are made. All these functions’ relevant source code is found in Appendix O on page 123.

9 Results

This chapter presents the performance results of the resulting research model developed. The chapter consists of three parts. The first part presents the final research model that was obtained, and consequently used to perform the tests and experiments contributing to the performance results of this chapter. This model is presented in Section 9.1. The second part presents five test setups that was used to determine the performance of different performance areas relating to the resulting model. The test setups, procedures performed, and results for the respective tests, are presented in Section 9.2. The last part uses the results obtained from the performance tests, and interprets them to determine the model’s compliance to the requirements defined at the beginning of the research – in order to determine the overall performance of the developed solution. This compliance to requirements of the solution is presented in Section 9.3.