Adam Dej edited this page Jan 29, 2016 · 9 revisions

Project Deadlock

RFID Physical Access Control System

... for opening doors.

This project aims to create an open-source system for our university that will allow ISO/IEC 14443a compatible cards (like International Student/Teacher Identification Cards) to be used for accessing doors. We want this system to be:

  • Reliable and secure. The access will be granted when and only when is should be.
  • Easy to use and maintain. Access rules configuration should be fast and simple. Potential failures of certain components should be quick and easy to fix.
  • Fast to deploy and configure. Minimal overhead should be included in deploying this system (cables, etc...)
  • Available. Hardware parts should be cheap to manufacture and components for them should either be available in the future or painlessly replaceable by their newer alternatives.
  • Extensible. The whole system, including the hardware components, should be extensible to perform some function not needed right now in the future.
  • Done. The project is about a year overdue. We really want this system to be done.

(I am sorry, I sound like a businessman. That's not intentional and I'll stop that right now.)

We will provide a complete system for managing access rules (integrated with the university's electronic info system), and the embedded hardware and software.

(OK, I mean it this time. No more businessman)

To better understand these requirements you can read about our motivation and history of the project here.

Under development

The whole system is under active* development. Some things we are talking about here do not exist yet, do no longer exist, have never existed or may never exist.

(* for the proper definition of the word active. But hey, we are doing what we can!)

Here is a Trello board you can use to monitor the development progress: https://trello.com/b/eUShodyG

Architecture

TODO a nice picture :)

Server

Project Deadlock has a centralized model, and the Server is the centralized manager of the whole system. It stores the access database, compiles it to a format suitable for small embedded Controllers and distributes it. It is a caretaker of the whole system, managing firmware upgrades of other embedded components and, of course, storing logs.

It will have a nice API and 2 frontends, one script-friendly CLI and the other human-friendly Web.

Controller

This is an embedded device with network connectivity to the server. It's job is to open and close single door it controls when it receives information about a card from the Reader. It also tells Server about everything that is happening with the door (like usage of a manual lock override (opening doors with a physical key) or manual door override (like kicking the door out)). It can be connected to up to 2 readers (possibly more with a proper extension board).

This device will be gradually developed, with 2 models. First model (Controller Model A) will be able to function only if it has an active connection to the server, later more advances model (Controller Model B) will be able to perform it's decisions offline if the server is down.

It will also be extensible with 'Controller Extension Boards', that can provide extended functionality.

Reader

Reader is the small box people touch with their cards. It provides simplistic visual and auditory interface (it blinks and beeps). It also reads the card and provides the controller with necessary information for deciding whether to open the door.

The Reader is connected to the Controller using a cable, utilizing a simple serial interface. It will also be developed in more models, Reader will only have the serial interface, Reader+ will also have USB capability, for use with other systems.

Repositories

The project has many components, and that means we have many repositories for them.

Server and frontends

  • server. This repository hosts the source code for the server. It is also main repository for the documentation of the whole system. Design issues and issues not specific against any single component should be opened in this repository.

Other server-related repositories do not exist yet.

Controller

  • controller-hw. This repo will contain schematics and PCB designs for the Controller.
  • controller-sw. Software for the Controller.
  • temp-controller.py. We needed to deploy 2 prototypes right away, so this is a temporary jerry-rigged controller software to be used on Raspberry Pi. Will be obsolete soon.
  • libmfrc522.py. This is a library for controlling the MFRC522 module used in the Reader. It is the module that actually reads cards. It is used in temp-controller, because the deployed prototype is using an older concept of the reader, which cannot read cards on its own, it just mediates communication between the MFRC522 module and the Controller. In the new concept it will not be needed, and will be obsolete soon.

Reader

  • reader-hw. Schematics and PCB design of the Reader.
  • reader-sw. Software for the Reader.
  • libreader.py. This is a Python library for interfacing with the Reader. It was made for the temporary controller, bud will be kept up-to-date as it allows almost any Python-capable system to use the Reader. It also allows for easier debugging and development of the Reader.

Utilities

  • hw-testing. This repo contains library for testing STM32 MCU powered embedded devices, like Reader and Controller. It also contains tests for these boards. New tests are written easily, and it is used in development of the system, as well as during the manufacturing for final checkout of the hardware.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.