Since 2013 CDS 3.1 became Open Source, all source code and pcb layouts are available under the Creative Commons (CC) license.
One of the bigger projects I did the last years (starting 2004) was the CDS (Campus Door System) project. The goal of the project was to build access system mainly focused to the needs of education facilities. The system is designed to work with every RFID reader which can be interfaced via serial protocols. Mostly RS-485 is used because it can be used effectively over long distances and in electrically noisy environments.
Strictly speaking the first prototype of the CDS with raw access control functionality was developed by a student (Christian E. with project lead Helmut W.) – he programmed the first core micro controller functionality.
The new system should be build up from scratch with an new designed PCB (Printed circuit board) which hosts the four main parts of the access system:
- The Rs485 bus interface
- The MultiUART (FPGA)
- The C167CR (access control and RFID reader manager)
- The embedded system for managing the whole system
1. The Rs485 bus interface:
The newest version of the CDS v3.x has 16 separate RS-485 bus interfaces and the number of RFID readers is only limited to the used baud rates and because of that the maximum allowed pooling intervals. Version 2.x which is mainly in service has only 8 interfaces.
The bus interface is galvanically isolated from the logic part of the PCB. The RS485 transceivers are mounted through IC sockets.
2. The MultiUART:
Since I use devices with serial protocols I needed an UART (Universal asynchronous receiver/transmitter) and in that case I needed 8 respectively 16. The MultiUART should be interfaced through the used micro controllers external data bus. In my case I took the Infineon C167 the battleship amongst the micro controller family.
I learned very fast that digital design for FPGA could be very challenging – even if you have some sort of asynchronous circuit design. Then you have to deal for example with metastability and other nice stuff concerning signal runtimes 🙂 At that time I was a completely rookie concerning FPGA stuff. I was lucky enough to have a colleague who told me the common mistakes which you could make with FPGA designed. Thanks to Hermann Sterner – you saved me a couple of months 🙂
In the end I got a stable design with 16 UART designs, every UART could be configured independently. That means for every request to a serial slave the system could set the needed baud rate on the fly. Every UART has a 1024 Byte TX FIFO and a 128 BYTE RX FIFO.
Every UART internally communicates with an Interrupt Controller which notifies the micro controller of new RX events.
Every UART is mapped to an certain location in the higher address space.
3. The access controller (Infineon C167CR)
As I already mentioned before I used the C167 for the real-time part. The used C167CR module comes from pytec. With 2MB RAM and 2MB Flash this module has plenty of space for the access tables.
The code which runs on this micro controller is based on the preliminary work of Christian E., the student which developed the first system. In the process of developing I rewrote or adopted a huge part of the code but some parts are still unchanged from the old system and are still in productive use.
The newest version of the access controller is capable to communicate with devices via different protocols and different baud rates. Because of that the protocol stack for the RFID readers is designed modular. The system can easily be adopted for new protocols.
Firmware updates are done through the embedded system (Web interface). At version 3.x the update process does not need a down time for the system. After successfully downloading the firmware to the flash the system switches seamless to the new program code (switch time >100ms).
4. The embedded system (Web interface, internal database, …)
The whole access system can be administered through a web interface. The used embedded system is the DIMM-PC®/520-IE. I wrote some details about in one of my last posts. As this system only has 32MB RAM and 32MB FLASH I needed an OS which is highly customizable. -> GNU/Linux is the OS of choice 🙂 .
The core elements I used are:
- Apache 1.3.x (build-in opcode cache) size < 900kB
- PHP 3.5.x
- openSSL (minimal cipher suit) size <1MB
- Linux Kernel 2.6.1x special patch set and configuration < 800kb
- uclibc 0.9.x
- sqlite 3.x
- MySQL 5.1.x size <1MB (Community Edition)
BSP ptxdist powered, for DimmPC (AMD Elan) optimized, Build/Toolchain ready to download.
This part was the most interesting one. Due to the fact that I could not find commercial tools for building embedded GNU/linux OS which suit my needs, I began using open source tools (ptxdist) and build my own toolchains. I learned how to build optimized cross compile toolchains for the used CPUs and in the end I got a highly flexible tool/buildchain for building a whole GNU/Linux with bootloader and all the small things which make the system running 🙂
The embedded system is the core device for administration. Every aspect of the system can be configured through the WEB. All HTTP connections are secured via SSL. The embedded system is holding all persons with there tags, all access rights, all doors respective the RFID readers wired together with access rights in a database system.
The backend of the WEB-Frontend consists of a completely self-written tiny CMS system. Focused to have a very low memory footprint and CPU resources. The initial design of the CDS Web frontend /backend was done by Georg Gut 🙂 thx – well done.
We are using a special patched PHP 3.5.x running one a patched (tuned) apache 1.3.x to get good performance results. with our CMS system.
On every change on the access data the system generates the access tables for the micro-controller system and updates the tables through the SPI interface.
The version before I used the parallel port for transmitting data between DimmPc and micro-controller. But it turns out that this interface was not stable enough, so I decided to change this interface to SPI with 1Mb/s transfer mode.
- 16x RS485 bus interfaces, number of readers only limited to selected baudrates (poll times).
- Multiple readers vendors on one bus segment.
- Manage person rights
- Manage person-groups
- Manage doors
- Manage door-groups
- Manage access rights between person/person-groups and doors/door-groups
- All rights can be time limited.
- RealTime View of all door actions (door status, last action, last person), AJAX driven
- Manually open/close door leafs through the WEB interface
- Automatically door/groups open/close actions at a certain time.
- Temporally overrule of access rights (student groups for example) on holidays.
- Log Facility
- Access log WEB frontend
- System user action/access/view logging
- Door log, reader and separate door leaf actions
- Detailed per person logging
- Detailed per door/object logging
- Person/object statistics
- System Management
- Select the use of an internal or external database
- NTP server configuration
- Log history length
- Internal database backup/restore
- Web interface user rights administration
- LDAP /AD User Authentification
- System Clustering
- Up to 4 separate CDS can be administered from one master system.
- The Web interface exposes an API for third party application to hook into the CDS system.
- FTP access table upload
- The access table can also be uploaded through FTP from third party applications.
- Set Notification handlers on User/Door actions.
- Get Emails on definable events. For example on door actions between a defined time period.
- Smartphone ready GUI, special version for IPad/Android tablets
Check out the gallery for some impressions about the System.
Systems in service: