Overview
A challenge in large organizations is often to get access to rooms which are normally locked. While there are sophisticated access solutions available in which users use a specific card or device (sometimes called transponder) to unlock and lock the door, we have built a key lending system logging which user has lent which key for which room. Moreover, the more keys a user has lent the higher the confusion of the user – of course depending on the user 😉 – which key she/he should take for which room. Labeling each key is not a way around since in case of loosing the key, the finder can have access to this room.
Therefore, we have built an information system called Key-Logger allowing an organization to manage all processes according to lending keys to different users using the key to access a room of interest. While lending processes are typically centrally managed, each user can access the system to get insights into his/her current lending processes and to identify the room each lent key get access for.
Key-Logger Information System
The Key Logger System is designed by a component-based infrastructure (see Section System Architecture blow). A user can access the system in two ways. First, we-based user interface is used for all administrative processes, i.e., all managing users, rooms, keys, and lending processes. The figure below is an animated animated image showing a sequence of lending processes using the web-based user interface of our Key Logger System.
We currently are in the process of extending this system by an Android app allowing a user to get information about the room she/he has access to using a dedicated key. We use the key number that is printed on nearly each key. This key number can be scanned by the app or manually specified to get access information. The user will only get information about rooms the key is locking or unlocking in the case she /he holds a reservation of a key for this room. Therefore, nobody can access room information when she/he finds a key that another has lost. Figure 2 is an animated image that gives an overview how this Android App can be used.
High Level Architecture
The figure below introduces the high level architecture of the Key-Logger infrastructure. The overall system consists of different components. All data about user, keys and rooms as well as their reservations and lendings are managed in a relational database system. We currently use freely available MariaDB but more DBMS will be supported in near future as well. The central component is the Key-Logger Service reading and writing data from and to this database system, checking access rights etc. It communicates with a RESTful application interface with other components and applications. Such components include the web-based user interface and the Android App. The first allows administrative access, i.e., creating reservations and lendings, while the Android App is designed to access information about key reservations / lendings for a specific person. In this way, a user can view all his/her reservations (not those of other persons) and access information about a single key. The latter is important when the user wants to know which can be locked/unlocked by a selected key. The user, therefore, creates a photo of the key including the key number on it within this mobile App. This image will be sent to the central Key-Logger Service that forwards it to Key recognition Service. This service prepares and processes the received images and tries to recognize the key number. In case the key number cannot be be automatically extracted, the mobile App offers the opportunity to specify the key number manually. Using the key number, the central Key-Logger-Service provides information which room can be accessed with with this key, if and only if the person has a current reservation for this room. Hence, a finder of a key that got lost will not get information which room can be opened.
The Key Logger System has been designed and implemented by Lukas Schmitz within a Bachelor Thesis, 2020, under supervision of Josefine Welk.