Design and analysis of embedded access control monitoring system based on ARM9 and Linux

　　Access control, also known as access control system, is a digital management system for managing people's access. At present, with the development of industrial automation and people's increasing demand for applications, access control monitoring systems have been used more and more, but traditional access control monitoring systems generally adopt the implementation method of separating access control and video image recording, which brings a lot of inconvenience to on-site wiring and greatly increases its cost. The embedded access control monitoring system based on ARM9 and Linux mentioned in this solution integrates access control and image recording functions, and describes the software design of the system in detail. This access control system uses B/S software architecture, adopts embedded server boaserver, combines CGI technology, embedded database and embedded graphics library to meet the needs of the access control system.

　　1 System working principle and composition

　　1.1 System Working Principle

　　This access control monitoring system adopts B/S architecture (Browser/Server, browser/server mode). The access control monitoring system based on B/S architecture is firstly an access control controller with Ethernet interface; secondly, this access control controller has built-in Ethernet TCP/IP protocol and WEB service program; when the system is connected, the user can regard the access control controller as a computer with broadband network interface and directly connect it to the network switch. When users manage access control, they do not need to install any additional software, and can directly manage the access control system through the browser, which is convenient and simple to operate.

　　1.2 System composition

　　As shown in Figure 1, the system server consists of an ARM9-based access controller, card reader, electric lock, front-end camera, etc. When someone enters or exits the gate and swipes a card, the card reader can sense the card and send the card information to the access controller. The access controller checks the card legitimacy by reading the user database to see if there is corresponding cardholder information for this card number. If so, it checks the corresponding permission information of this card. After all matches are successful, it decides whether to open the door. This ensures the security of the system. At this time, the access controller also performs image recording operations, that is, while opening the door, the front-end camera records the picture and transmits it to the corresponding storage device for user access.

　　The client can remotely access the access controller (server) and perform corresponding permission operations through the browser, which can realize functions such as user information entry and authorization management, hardware settings, entry and exit image monitoring, door opening, data browsing, etc. Figure 1 shows the system structure model.

　　2 Access Controller Hardware Design

　　This system uses ATMEL's AT91RM9200 (hereinafter referred to as 9200) as MCU. The processor is based on the ARM920T core, with a working frequency of 180MHz and a performance of 200 MI/S. The system uses the open source LINUX OS. The kernel version is 2.6.25. The system uses 1 Nor-Flash with a capacity of 64 MB and 2 SDRAMs with a capacity of 32 MB each. As shown in Figure 2, this access control controller is based on ARM9200 as the core, and is also connected to an LCD controller, which can be connected to a display screen for easy user debugging. In addition, this access control system can connect up to 256 card readers and corresponding cameras. The schematic diagram of the system hardware composition is shown in Figure 2.

　　3 System Software Architecture Design

　　The whole system is divided into two parts: front and back. The back monitoring program will always monitor whether the card reader has card swiping information and respond to the card swiping information. The front desk will respond to the client access request by calling the CGI service program through the boa server. The system function model is shown in Figure 3.

　　3.1 Front-end design

　　The system front end is mainly composed of the boa Server and CGI service program running on the access control controller. The boa server will always monitor whether there is any remote user access. When a client access request arrives, it will call the corresponding CGI service program in the corresponding directory through the boa server configuration file. After the processing is completed, the boa server will return the processing result to the client.

　　3.1.1 Introduction to CGI and its working principle

　　The full name of CGI is "Common Gateway Interface", which is a program method based on browser input and running on a Web server.

　　The working principle of CGI is that the browser first points to the URL of a CGI application through an HTML form or hyperlink request. After receiving the request, the server executes the specified CGI application. The CGI application performs the required operations (usually based on the content entered by the browser) and formats the results into a document (usually an HTML web page) that the web server and browser can understand. Finally, the web server returns the results to the browser.

　　3.1.2 Embedded Server boa server

　　boa Server is a small single-task embedded server that supports CGI. The executable code is only about 60 kB. It is small in size, fast in speed, and has good security, which can meet the development of this project. Boa Server needs to be cross-compiled into a program that can run on the ARM platform. In the PC environment, after cross-compiling boa server using the cross compiler arm-linux-gcc, you need to modify its configuration file boa.conf. The key configurations include creating a directory where the log file is located, creating a main directory for HTML documents, storing static web pages in this directory, and creating a directory where the CGI script is located, storing the cgi script in this directory.

　　3.2 Backend design

　　When the system is running, the access controller will always run the main monitoring program. The main monitoring program has two working modes, namely debugging mode and monitoring mode.

　　3.2.1 Debug Mode

　　In debugging mode, you can make some basic settings for the access controller: including the IP setting of the access controller, the username and password setting of the system administrator, the card permission setting, etc. In this part, a graphical environment is required for debugging. This system uses the minigui embedded graphics library.

　　The communication under MiniGUI is a message mechanism similar to Win32. It is a free software developed by a company and follows the LGPL protocol. It can establish a fast, stable and lightweight graphical user interface support system for embedded Linux systems.

　　3.2.2 Monitoring Mode

　　In working mode, the background resident program will always monitor whether there is card swiping information. After detecting the card swiping information, the background resident program will compare the card information by accessing the database. Only when the comparison is passed can the door be opened.

　　Because the picture needs to be saved to the database at the same time as the door is opened, and at this time, there may be a client access to the system stored picture, which will cause an access conflict to the same database. Therefore, when the system receives a client request to access the system stored picture, the front-end CGI service program communicates with the background monitoring program through the inter-process communication method of the named pipe to obtain the database access handle. After the client access ends, the front-end CGI service program will release the database handle.

　　Since this system involves frequent database access operations, the database selected is Berkeley DB based on the ARM9 hardware platform. Berkeley DB is an embedded database system with a long history, mainly used on UNIX/LINUX operating systems. Its design concept is simple, compact, reliable and high-performance, which meets the needs of this system.

　　4 System software functional module design

　　4.1 User information entry and authorization management

　　User information entry and authorization management are set by users with administrator privileges. On the client side, users with administrator privileges enter the administrator username and password through the browser and send it to the access controller. After receiving the request, the access controller verifies whether the authority is legal by calling the corresponding CGI service program. After confirming that it is legal, it enters the next level page, where user information entry and authorization management can be completed.

　　The main functions include entering user personal information, binding with a specific card, and granting card permissions. When a user swipes a card to open a door, the system first checks whether the card has corresponding cardholder information and whether the cardholder information matches the format defined by the system, which can prevent the use of illegal cards. If this step is matched successfully, the next step is to check the permission information corresponding to the card, including which doors can be controlled by this card and during which time periods.

　　4.2 Data browsing

　　System registered users can browse system authorization information on the client, and only users with administrator privileges can delete system registered users.

　　4.3 Hardware Setup

　　Administrator users can remotely test and set the access controller system on the client, including detecting the controller status according to the access controller address, setting the current time and week for the access controller, reading the current controller time, delaying the door opening, manually opening the door, editing and reading the device name, clearing the authorization file, clearing the card swiping record, etc.