SYSTEM DESIGN 17
Authentication Module
The Authentication Module features three unique peripherals that interact with the microcontroller through different communication methods Strategically located outside the lab entrance, this module includes an additional button that allows for manual door access from the inside.
The PN532 is configured in I2C mode.
The microcontroller is designed to command the RFID chip to scan for targets every 80 milliseconds Upon successfully detecting a target, the reader sends 4 bytes of UID data back to the microcontroller, enabling the system to support approximately 4 billion unique identifiers This capacity allows for the assignment of unique IDs to up to 4 billion individuals or devices Alternatively, the reader can be configured to transmit 7 bytes of UID, although this option requires additional resources.
The R503 fingerprint scanner utilizes a GPIO pin to transmit a wake-up signal to the microcontroller upon activation of the touch surface It employs a pattern matching technique to process fingerprints, which involves three essential operations.
• Comparison: Iterate the flash storage in order to look for the matching fingerprint.
To register fingerprints, utilize the Comparison function to identify duplicates and store unique fingerprints in designated flash storage locations These locations are assigned programmatically, allowing for data overwriting To prevent overwriting existing data, we maintain a database table on the server to track storage usage Further details will be provided in the subsequent section.
• Deletion: Remove the fingerprint data at a specific location of the flash storage The loca- tion is provided progammatically.
The R503 processing procedure begins with the scanner remaining idle until a user activates its sensor Upon activation, a GPIO signal is sent to the MCU, signaling that the module is ready for commands The MCU then transmits data to the chip, which processes the information using its local storage containing all fingerprints Finally, the results of the command are sent back to the MCU.
An RTOS thread is dedicated to continuously sending data frames to the R503 scanner, ensuring the device remains operational and ready for input throughout the operating system's runtime.
The keypad operates without a specific communication protocol, needing only 7 GPIO pins for connectivity To detect button presses, we employ a polling method using a timer, similar to the PN532 Our microcontroller follows a systematic procedure to scan for the state of pressed buttons.
• The microcontroller sets each column pin to HIGH.
• While a column pin is HIGH, the mictrocontroller checks the signal of each row on that column.
• If a row on that column is HIGH, that means a button at that row-column position is pressed Otherwise, nothing happens.
The memory buffer for the passcode is cleared after 5 seconds of inactivity, meaning that if the microcontroller doesn't receive a new digit within that timeframe, it discards the incomplete passcode, eliminating the need for a backspace button Additionally, the system automatically submits the passcode once the 6th digit is entered, removing the necessity for an enter button.
OLED displays play a crucial role in providing visual feedback to users, such as displaying the passcode being entered They also indicate the identity of users during RFID or fingerprint scanning Additionally, when the system fails to recognize any input, the OLED screen presents an error message for clarity.
Storage Module
The Storage Module features a second RFID reader, which is essential for registration and hardware request processes, while being identical to the reader in the Authentication Module Additionally, the cabinet serves a dual purpose by securely storing the lab's hardware and providing a protective chassis.
The cabinet features an additional OLED display on its front, and each of its four compartments is secured with a 12-volt electric lock Access to these locks is exclusively granted through a web interface, ensuring enhanced security and control.
Figure 30: The cabinet interior with the MCU.
Microcontroller Configuration
GPIO pins are crucial components in microcontroller products, enabling effective debugging and functionality verification By utilizing GPIO, we can connect multiple LEDs to our system, which serve as visual indicators to help identify code failures and confirm that functions execute as intended.
GPIO pins are also used to exchange signals between peripherals and the microcontroller:
The PN532 features a RST pin that, when triggered with a falling edge signal, resets the entire board This functionality is particularly advantageous during initialization, as it eliminates the need to power the board off and on again each time the microcontroller resets while remaining powered.
When a person interacts with the R503, it triggers a GPIO signal that is sent as active HIGH from the scanner to the microcontroller, indicating that the microcontroller is awake and prepared to receive commands.
Electric locks operate by unlocking in response to a GPIO active HIGH signal and locking again with an active LOW signal To ensure the locks are only unlocked for a brief period—sufficient to open the door without causing damage—we implement an output falling edge signal that lasts approximately 200 milliseconds.
The USART3 channel on our MCU enables data transmission to a computer through the ST-Link interface and Micro-USB port Utilizing this feature allows any serial monitor program on the computer to function as a valuable debugging console, provided that data is sent through this channel; otherwise, it remains ineffective.
USART2 facilitates communication with the R503 Fingerprint module, requiring specific channel configurations that align with the R503's default settings, which include a baud rate of 57600 and the activation of FIFO mode.
Our MCU is equipped with four I2C channels, allowing us to connect multiple devices, including two PN532 modules and two SSD-1106 OLED displays Each I2C channel can support numerous slave devices, providing us with a variety of flexible wiring options for our project.
The first wiring option for I2C involves daisy chaining all four devices to a single bus, which seems feasible in theory However, due to our hardware selection, this approach is not practical Each device comes with a hardcoded, unmodifiable I2C address; both PN532s are set to the same address (0x48), and the displays also share the same address (0x3C) Consequently, if we implement this setup, the MCU will be unable to identify which device to communicate with, as the devices share identical addresses.
The second option involves utilizing two I2C buses, with each bus connecting a PN532 and a display, effectively eliminating the address conflict present in the first option.
Utilizing all four I2C channels on the MCU to connect distinct devices offers a straightforward solution, ensuring no conflicts between peripherals This approach enables the precise configuration of each I2C bus's specifications tailored to individual devices.
To resolve the issue of conflicting addresses in I2C communication, we can incorporate additional equipment while maintaining multiple devices on the same channel For instance, by connecting a power switch to each I2C device, we can selectively activate the desired device for communication while keeping others idle Another effective solution is to introduce an I2C multiplexer into the circuit, enabling us to choose which data line to activate for seamless communication.
Timers are essential for measuring time intervals in programming By utilizing timers to generate interrupts, various program components can operate simultaneously without interruption To determine an interval on an STM32 board, the process involves multiplying the clock's prescaler value by the counter period and then dividing the outcome by the clock speed.
The MCU is equipped with two timers: one that triggers an interrupt for keypad input every 50ms and another for RFID input every 80ms Programmers have the flexibility to start and stop these timers as needed.
One of our major concerns during development was connecting the microcontroller to the Node.js server.
Our very first test setup used MQTT protocol over Wi-Fi for message exchanges with a local broker, but this was a dead-end from the start for two reasons:
1 Bad and complicated setup: The microcontroller doesn’t have any Wi-Fi controller, so we had to connect an ESP-32 and let it handle all MQTT operations As a result we had to program two boards with different architectures On the server level, a separate MQTT server must be created This was deemed too much and too complicate.
2 No practicality: MQTT was never meant for one-to-one communication, but rather built for IoT applications where there are alot of participants and hardware involved So, the use of MQTT is wasted here as it was never used to its full potential.
Complete Datasheet
This chapter outlines the key features of the system, emphasizing the web UI as the central element for user engagement The web UI serves as the foundation for interacting with various functionalities, making it integral to nearly all other features developed within the system.
The registration process of both human and hardware is very similar To register a user on the website, navigate to theUsers tab and for hardware, theInventory tab.
The hardware registration modal form requires managers to input a new user's name, ID, and designated role within the lab The system will automatically reject any duplicate IDs entered Additionally, each user has the option to create a maximum of one RFID key and one fingerprint key for access.
To effectively manage hardware, each component must be assigned a unique name, and identical models should share the same name Unlike users, each RFID key must be registered to individual components for unique identification within the system Hardware can be stored in any designated locker or cabinet chosen by the system manager, and each component should also be physically labeled with a number, serving as a visual identifier In summary, RFID tags are used for system identification, while labels cater to human recognition During the registration process, any new RFID or fingerprint key will be checked against the existing database; if it is already registered, the key will be rejected to prevent duplication.
SYSTEM IMPLEMENTATION 42
This chapter outlines the key features of the system, focusing on our analytical approach and insights The web UI stands out as the primary feature, serving as the main entry point for user engagement with the system, and it is integral to nearly all other functionalities we have developed.
The registration process of both human and hardware is very similar To register a user on the website, navigate to theUsers tab and for hardware, theInventory tab.
To register hardware for a new user, a manager must complete a form that includes the user's name, ID, and designated role within the lab The system will automatically reject any duplicate IDs entered Additionally, each user has the option to create one RFID key and one fingerprint key for added security.
To effectively manage hardware, each component must have a unique name, with duplicates allowed for identical models Unlike users, each RFID key must be registered to individual hardware to ensure unique identification within the system Hardware can be stored in any designated locker or cabinet, and each component should be physically labeled with a number, serving as a visible identifier for easy recognition The registration process involves verifying new RFID or fingerprint keys against the existing database; if a key is already registered, it will be rejected to prevent duplication.
The Authentication Module consists of three key hardware components: an RFID reader, a fingerprint scanner, and a keypad, each offering distinct authentication methods—RFID tags, fingerprints, and passcodes A microcontroller is responsible for collecting data from these components and transmitting it as a TCP message to the server, where the information undergoes further processing.
• First, the packet is decrypted to get the message head and the authentication key.
• The message head determines how the data gets treated and which database query to issue.
• The server retrieves all available authentication keys from the database, depending on the method used.
• The current key is compared against all the hashed keys from the database by using the npm modulebcrypt.
• If a key exists, the server will issue a command to the microcontroller to unlock the entrance door Else, an error message is shown on the OLED display.
Figure 39: Entrance Authentication Use-case Diagram
To access the web UI, users must have a single account designated for the system manager After logging in, a server session is initiated to monitor the browser client, allowing only one active session at a time This means the system manager can only be logged in from one device simultaneously When the browser is closed, the server terminates the active session, enabling the account to be accessed from another device or at a later time.
To access the full list of registered users and hardware, navigate to the corresponding tab on the web interface This allows the system manager to modify each entity and make necessary updates.
When a user is removed from the system, their authentication keys are also deleted, which involves erasing all associated records from the database However, the history of their activities will still be retained.
The primary and most challenging aspect of the project involves human participation in the process, reminiscent of the library management system we previously examined.
We adopted what works best for their system and then made our own improvement upon that, so everything from here on out should look familiar.
This procedure requires the web interface To begin, the system manager must navigate to theManagement tab and open the request form modal.
1 The system requires a user to provide their unique system RFID.
2 The manager selects which hardware to issue The system then searches and automatically opens the correct cabinet locker containing the hardware.
3 Once the hardware is retrieved from the locker, its RFID tag is scanned For each request, a user is tied to only one hardware entity.
4 Having provided sufficient information, the request form is submitted to the server and procedure is complete The system puts this request into the database records for moni- toring.
Figure 40: Request modal form There are two possible errors in this procedure:
• A non-existent (not registered in the system) RFID tag is scanned.
• The RFID tag of a hardware component that has already been requested is scanned once again.
When RFID data is checked, any illegal actions will trigger an error notification in the web UI from the server The system manager has the ability to easily retry and correct this error.
This procedure does not require the web interface Returning hardware is just as easy as seen in the library system.
1 Scan the returning device’s RFID tag This is the only action needed in this procedure.The rest is performed by the server.
2 The database record for the request is updated with the time of returning and marked as a complete request.
3 The assigned cabinet locker is automatically opened so the manager can return the hard- ware Otherwise, they can always manually open said locker using the web UI.
The Hardware tab on the web UI provides essential information for system managers, featuring a comprehensive inventory report that shows the total quantity of each board, along with their availability status Additionally, a detailed table below offers insights into the specific boards stored in each cabinet and their current status, indicating whether they are in the cabinet or currently borrowed.
The Management tab for hardware features a clear layout, showcasing ongoing requests in distinct cards for easy visibility Below, a separate table lists all completed requests, ensuring that any issues requiring resolution can be quickly addressed This design prioritizes urgent matters for the manager's attention while keeping non-urgent information readily accessible.
The system manager utilizes AJAX calls to control the microcontroller's behavior via the web, while the server transmits TCP messages to the microcontroller Upon receipt, LWIP manages the incoming data, and FreeRTOS executes the instructions contained in the message.
A manager can easily open doors or cabinet compartments through a web interface by clicking buttons Initially designed to test TCP data communication for timely data packet reception by the microcontroller, this feature was later utilized to evaluate the performance of electronic locks.
⋄ Web Password and Door Passcode
The system manager can also change the website password to whatever they want The door passcode must conform to a format: a six character long string and only digits are allowed.
All activities within the system are logged in the database, which can be accessed through the web UI in the Event log tab These records are organized into categories, enabling managers to utilize the DataTable’s search feature for efficient filtering While nearly all events and actions are documented, trivial occurrences are excluded from the logs.
• Who enters the lab, at what time, using which authentication method.
• Additional information added to the system (RFID, fingerprint, new hardware/user).
• Modification to hardware information This includes deletion and changing name.
• When the web interface gets logged in or out.
Recording all actions during development is essential for effective code testing, as it allows us to verify that processes are functioning as intended By reviewing logs, we can identify and rectify any unintended triggers, while the absence of logs indicates potential errors in the program.
The manager can take advantage of the log to monitor the whole system, track other users’ activities and take action if necessary.
Figure 46: TheEvent log tab The system under a quick test run within 30 minutes has logged some actions:
• Registration of a user named Đạt Vũ and their subsequent removal shortly after.
• The entrance door was unlocked four times, three of which were by some user with the
ID 1752169 and the other time was with the passcode Since this passcode is shared for everyone, we can’t know who it was.
• A new user named Trí Hoàng is registered and he was provided an RFID key and a finger- print key.