• Windows desktop client development for access control system configuration,including controllers, card readers, personnel accounts, etc.
  • Reporting engine development with custom report templates configuration
  • Hardware communication high-level driver development
  • 400+ controllers in one environment/network
  • 500+ transactions per second, 30,000+ transactions per minute
  • Remote VPN-connected offices/departments

Softacom has developed a high-level full-cycle access control system for an access control & burglar alarm systems manufacturer. Full-cycle means we covered the development of software for all stages of the system - starting with receiving signals from controllers, to events visualization at the operator’s workplace.


Our customer is a well-known Eastern European construction holding company with a security system manufacturing division. They have their own turnkey solutions for access control and fire alarm systems. Their core expertise includes full-cycle hardware solution development: from concept, hardware and architecture design to manufacturing, sales and support. One of the most important advantages of our customer is a strong firmware development team with 30+ years of expertise.

Although the client has its own experienced development team, they decided to involve a dedicated offshore team to create a new version of an access control system. The key requirements for a new team were the following: proven expertise in the development of high-load systems with data interchange between desktop systems and hardware, strong skills in the development of modern, fast and rich UI desktop software, and experience in integrating with third party systems via custom interfaces.

Due to our strong relationship and successful history with the customer, they chose Softacom as their strategic partner for this new project.

A modern access control system is a large set of software modules that perform various functions, not only those that are related to the permission for a particular person to enter a given room. Most of these modules are implemented at the software level and are able to expand the capabilities of the hardware access control systems, thanks to working with different types of peripheral equipment.

  • Staff management subsystem (personnel, bureau of permanent passes)
  • Visitors management subsystem (constant and temporary passes for visitors)
  • Vehicle access control (contact, manual, automatic modes)
  • Implementation of a checkpoint for visitors and vehicles, with the ability to control visitors
  • Subsystem of reports and records of employees' working hours, timesheets, etc.
  • Work with biometric devices
  • Admission issuance and much more
  • Integrations with 3rd-party systems for sending reports to ERP, CRM, XMR
  • Gathering information and administration from the higher level integrated security system
  • Integrations with other security subsystems such as showing video from the specified camera on the specified monitor in case of a predefined emergency

Working on this project, we have implemented all of these modules as well as additional functionality. We have applied our extensive experience in developing software for security systems to make the software fully relevant to all current trends and as convenient and rich in functionality as possible.


The client had many hardware and software requirements for this new version. The new version was expected to be much more productive, to work for remote offices, and to interact with remote buildings in real-time and offline modes. Remote buildings can be located even in different cities and all systems will work as one unit.

We had unique challenges related to the data interaction speed - all systems for all online modules should work in real-time. In a security system domain, when it comes to package deliveries or reactions, one second is equal to ages. Reactions to the hardware events should take milliseconds, even if a door is located 100 km away from the central database. We can have dozens of offices, each of them can have 10-50 controllers, and each controller can have 1-4 doors and 1-4 locks and readers (card, biometrics, chip, keypad, etc.).

To meet the customer’s requirements, our team prepared several system architecture designs and proof of concepts. After measuring many parameters (speed, response time, emulation of the specified amount of clients, sensors, signal sources, etc.) we chose a superior solution and introduced several improvements. After we got the skeleton of the future solution we started to split the whole system into subsystems. We used the best practices from the customer's existing solutions and our team’s experience.

Hardware interaction subsystem /h3>

The access control system has multiple objects, data entities and signal sources, including controllers, repeaters, concentrators, converters, doors, locks, readers, etc. During a work day, a system with 100-200 controllers can generate up to 500-1000 events per second. Of course, we cannot implement "classic" architecture for such volumes of information, when we have a single UART/USB port and one hardware driver, which will send data on the fly directly to the database. It can’t be possible as we just won't have the necessary amount of available computing resources.

For dealing with these challenges, we designed a multi-level dedicated data interaction system that works as one unit. All data flows were categorized based on their importance and influence on the system logic. The system has memory cache subsystems, priority queues and other logic blocks.

During the architecture design stage, we set aside time to brainstorm and consider the future of the project. We had to look at several factors and find answers to many questions. What challenges might we face 5 or even 10 years from now? What technologies and trends will dictate the technological rules in the future? These questions are crucial when you are planning investments towards new projects.

Finally, we built the architecture that allowed creating each subsystem from the blocks - logic and functional bricks. Using this concept we can insert logic to AI blocks that do not exist today but can be developed in 2-3 years. Today the system has preconfigured and custom rules and strategies for reacting to system events. But in the future, we have plans to develop self-learning blocks, which will detect "strange" system behaviors, check system state, detect business rule failures, etc.

Data storage subsystem

As mentioned above, we cannot just write to and read from a database with 10,000 operations per second (note that some queries can take megabytes). Instead, we needed to use a different approach. Classic systems can be built based on a data interaction model, which allows all modules to interact with other modules via data in the database. For instance, after some events were detected by the sensor, we inserted data into the database which triggered an event and notified client apps (operator's working place). For high loads, this approach does not work - we would have signal delays, crashes because of memory problems, system overloads and so on.

That is the main reason we applied a "hybrid" concept for the designed system. This hybrid approach presupposed using database read/write operations only when it's really necessary. All modules can communicate with each other in real-time using sockets and websockets, and share memory and other technologies with data double backup protection (if a module that is responsible for sending data packages crashes it, another module will backup the same package). When data is ready for being saved in the database, it will be saved once without database overloading. Data can be aggregated, stored in the data storage that is not a core one (service local DBs), etc.

Operation and Administration

The client-end software had to be user-friendly, easy to use and modern. The client part for the previous version lacked structure and access to the system's features and functionality. Their developers had been adding new modules and features for the past fifteen years - and it's great software even by today’s standards. In our case, we already had a list of modules, along with their features and requirements for future extensions (such as AI modules for decision making and forecasting).

We built a modular system, where a "host" core app could load necessary administrative and operation modules depending on the requirements for the working place, the current client (users, roles, permissions), the client's available functionality and so on. This includes but is not limited to:

  • Personnel management module
  • Visitors management module
  • Accounts management
  • System users, roles and permissions management
  • UI module with schemas of buildings and representations of system components, including their states (a module consists of two parts - representation and control for operators and an administrative module for system administrators (you should have a way to configure your buildings, schemas, drag and drop doors, controllers to your plans, etc.))
  • Hardware management
  • Hardware diagnostics
  • System failover and backup routines
  • System events logging
  • Rules and strategies configuration
  • Plugins for integrations
  • Settings
  • Cards design and printing module
  • Access points workplaces (for operators or police)

Want to know more about full-cycle access control system software development?
Contact us. We’ll help

Reporting & BI

If you have tons of information, you should have easy access to it. Each client's installation will have standard requirements for the data reports and representation, but approximately 30% of them will be custom requirements for data access or export.

This is why we implemented a solution that combines a classic reporting ideology (with the possibility to define custom reports) and a Business Intelligence (BI) system to ensure better data representation and control. Not all customers can use and pay for standalone or cloud-based BI solutions, but some of them already use systems like Power BI and can get access to data entry points in data storage.


Modern access control systems cannot work in isolation. Data provided by an access control system can be used in enterprise systems such as ERP, CRM, HRM, Payroll and many others.

The previous version had many custom integration modules that were developed for each client. It was too difficult to support these multiple custom integrations, especially when it came to system modernization and updates for each client. Sometimes it was a real nightmare for our customer.

To solve the majority of these problems, we developed an open REST API for any external integrations and extensions. Now, in case of developing a new version or introducing changes to database storage, we support API versioning, obsolete methods and entry points processing, handling data collisions, etc. Eventually, the clients will migrate their software to the latest API versions and we will avoid a system collapse after the introduction of new versions. Of course, to ensure multi-versioning support, we have to support data transition structures, regression tests and other such principles.


Project realization consisted of multiple phases:

  • Business analysis - collecting existing requirements, specifying new requirements, previous experience analysis, modeling and design, mockups creation
  • Research and development - it is absolutely impossible to implement an innovative project without preliminary studies. We had to prove different concepts, make theoretical calculations and compare them with practical results
  • Development phase - performed on a continuous delivery basis (this phase also included business analysis, R&D of subprojects, QA)

At each stage, we applied Agile methodology with all relevant Scrum principles. We held daily meetings for separate teams, sprint reviews, sprint planning and sprint retrospectives.

During the first year, the teams worked on different parts of the software separately and only after this year were we able to implement CI/CD workflows.


The project was implemented with the help of several different technologies and frameworks:

  • Data interaction with the hardware layer is based on Delphi-related technologies. The previous version was developed using Delphi, and we decided to use the existing base for hardware communication. Due to this, we avoided having to rewrite a huge part of the software from scratch. The layer for communication with the firmware includes devices memory maps, partial memory writing techniques, hardware protocols versioning for different versions of controllers, concentrators and other equipment
  • The operational and administrative part was built using the MVVM pattern and .NET WPF framework
  • The report part was developed using the ReportViewer and Ms Power BI technologies

For each module, we used a rich stack of frameworks, components and technologies.


Together with our customer, we have come a long way: from the project concept to its deployment for large clients. Although we faced many concerns, technological challenges and pitfalls along the way, it was a huge success.

By now the project has been successfully installed and is being used by large banks, manufacturing companies, government organizations and sports facilities.

Our relationship with this customer is ongoing even now. We continue to support the project, introduce improvements and provide necessary extensions and integrations.



Softacom helped an access control system manufacturer with the development of a .NET Windows application for configuration, administration and monitoring access security systems and also provided solutions for ensuring communication between hardware devices and desktop software via UART and USB interfaces.