go back to normal mode automatically when the user steps into the room and the PIR sensors are triggered. This is helpful in the case when user authenticate himself but for some reason doesn’t enter the room. The room will be armed again after thirty seconds.
6.2.3 RQ # 2(c)
Unauthorized users will not get access to the premises. If someone enter his/her credentials at the entry point where he/she is not authorized the system will simply ignore it. The process of authentication goes through all the steps mentioned earlier but in the end when the user is not found the systems simply ignore it by going into theelsestatement.
Figure 6.11: User is valid but not authorized
More functionalists can be implemented like restricting or blocking the user after several attempts.
Figure 6.12: Requirements Number 3
6.3.1 RQ # 3(a)
The components of the alarm and access control system were interfaced with the board one by one and were checked regularly to ensure the proper functionality of the system. In the end all of the interfaced components worked together as a single unit. The prototype with interfaced components was placed inside the office room and used for several days to check the validity of the system. The figure below shows the installation of prototype in the AdeoOS office room.
Figure 6.13: Running prototype installed in the AdeoOS office room
The door was controlled with the electric lock and each day was locked and un-locked using the developed prototype. The system worked as it should and no problem
6.3.2 RQ # 3(b)
The firmware performs the local processing inside the controller board before sending the data to the sever. This processing helps to ease down the load on the server by filtering out the useless data. For example, if there is no motion in the room we don’t want this data to be sent to the server every second. As this data is of no interest and during the night huge amount of similar data will be generated. Therefore, non critical data is filtered out and sent after some time delay.
Another example is discarding the key presses if the user doesn’t provide the RFID tag. As the system supports multi-factor authentication and sending only key presses to the server without providing RFID tag is going to result in failed authentication . Therefore, key presses can be discarded at the controller level to avoid invoking the server unnecessarily.
6.3.3 RQ # 3(c)
The response given back by the server on each call of the controller board consist of all the necessary instructions and configurations for that particular board. The example of the server response to the controller board is shown in the figure below.
Figure 6.14: Server Response Message
The important tags are highlighted in the red colored boxes. The first tag <con-fig> is about the configuration settings of the micro controller. It consists of eight letters each of which represent pins A0-A7 of the controller board. The pins can be configured to receive various forms of inputs like digital(Buttons), analog (Sensors) etc. The table below shows the letters indicating what kind of inputs can be accepted by our controller board.
Figure 6.15: Configuratuon Settings
Currently, we are using the first two letters whereas third and fourth one are implemented in the firmware but not used right now. The future plan is to use one for door bell and other for window sensors.
The next tag doorStatus is the instruction for the door lock. It is either Open or Closed. Open means that the controller should unlock the door whereas Closed means that controller should lock the door. The final important tag state is about the state of the alarm. The figure??shows the actions taken by the controller board depending on the different states provided by the server.
Figure 6.16: Alarm states and corresponding controller actions
To call the emergency service is not implemented in the firmware but is one of our future plan.
Figure 6.17: Door lock control in firmware
As the comments suggest that the HIGH signal will open the door and LOW will close the door.
6.3.5 RQ # 3(e)
The data received from the attached components is smoothly sent to the server by wrapping it into HTTP request body. The example of request body is shown in the figure 6.18.
Figure 6.18: Request Body
A simple test of client server interaction was conducted during the early develop-ment of the system where the system was left on running for one whole night. The number of successful calls completed and failed were counted in the test. The results are shown below.
Figure 6.19: Successful and failed calls between client and server
Approximately 2000 calls were made out of which only 1 failed for some unknown reason. However, the overall system didn’t crashed during the failed call.
6.3.6 RQ # 3(f)
There are two types of scenarios in which the system alerts the server immediately without causing any delay. First one is when motion is detected and another one is when input is received from the reader so that the user credentials can be sent for authentication. Both the scenarios are important due to which priority is given to them as compared to other situations.