This document will be of great help if you are looking for a partner who specializes in building IoT solutions.
Our platform team shares how the access control and management system was created. From the idea of a customer to its transition into a commercial product.
Breakdown of the solution:
If you require expert advice and support for the implementation of an IoT solution, do not hesitate to contact us at firstname.lastname@example.org and send a description of your difficulties. We strive to help solve business-related problems.
During the construction of a cottage village, an ACS was required. The client needed to organize access control for the staff and residents. At this time, ready-made solutions did not work for various reasons.
Disadvantages of hardware platforms:
Disadvantages of software platforms:
To deal with the problem at hand, we had to develop compact controllers capable of working with typical access control equipment. Additionally, we had to develop an intuitive interface for configuring the system and providing cloud infrastructure.
The requirements were as follows:
Before proceeding to the development of a controller prototype, it is necessary to understand what equipment such a device would control. As a result of the research, two main groups of controlled devices were identified:
Their fundamental difference is that electric drives are dry contact devices that require a relay to control. Electric locks (devices with a “wet” contact), do not require a relay in the controller design.
It was discovered that in addition to the controlled devices, the ACS network controller must interact with equipment such as tag readers of various formats, and exit buttons.
The exit button is the most straightforward device that closes an electrical circuit. As for the tag readers, it turned out that these devices interact with ACS controllers using several interfaces. The most popular being: Wiegand, Dallas Touch Memory, RS-485, OSDP, Parsec, and Clock & Data. Having studied the features of all interfaces, Wiegand 26 was chosen as the most dominant on the market. Tag readers that interact with the controller using this protocol can be found in all price categories of devices.
When creating a prototype, ESP32 was chosen. One of the best platforms on the market in terms of price/performance ratio. The ESP32 microcontroller has a built-in Wi-Fi module and is compact. Not only is the ESP platform actively developed and supported by the manufacturer, but it is well documented and freely solves most of the tasks in the discussion of connected solutions.
The firmware for the prototype was developed based on the Arduino IDE. It is less functional than native ESP IDF but much easier to develop. This made it possible to speed up the testing.
Assignments that were completed using the prototype of the controller built at this stage:
The prototype was assembled on a breadboard. Standard libraries for managing locks were installed, and then testing began.
At the research stage, it turned out that some devices are controlled through a relay and some directly. Initially, the relay was connected to the prototype only when needed.
However, at this stage, a setback occurred. Requiring one of two solutions:
The main advantage of the first option is the universal scheme it adopts. Advantages of the second option include: it being the simpler choice for mounting devices with a “wet” contact on controllers without relays and reducing the cost of controllers without relays.
We went with the latter. To prepare two versions of the controller for devices with different types of contact. Since the general scheme of the device is the same (only one difference in an additional element), the production of two versions is possible without costs increasing.
At this stage, it was discovered that the principle of the operation of different types of electric locks varies. Electromagnetic locks require a constant power supply, and the mechanism of electromechanical locks are activated by a short electrical impulse. This was taken into account in the design of the controller.
While testing the prototype, it turned out that one Wi-Fi connection interface is not enough and the system is not fault-tolerant. Under real circumstances, Wi-Fi may not cover the installation site and may be unstable.
It became clear that the controller must function correctly in case of loss of online connection. The device memory must contain the current access settings for processing open requests from the tag reader. An offline access event log should also be maintained. The access settings and event log should be synchronized with the data on the server when the connection is restored.
During the field test, we got familiar with additional equipment in the form of sensors for opening/closing gates and barriers. Their signals should prevent the gates or barriers from closing while the vehicle is passing. The requirements for their support were taken into account in further work.
After confirming the attainability of the idea and identifying the key technical nuances, our specialists proceeded to the next stage, the production of a Minimum Viable Product (MVP).
The technical assignment of an MVP came with the following requirements for the controller’s functionality:
When writing firmware for an MVP, it is recommended to refuse the Arduino IDE development environment and use the native ESP32 – ESP IDF. What it lacks in workability, it makes up for in functionality.
Having started the development of the minimum viable product, our engineers kept the requirements set by the results of testing the prototype in the controller circuitry in mind:
During development, the platform SDK was used. The firmware created with this set of tools includes the following strongpoints:
The admin panel is a lightweight web interface integrated into the controller’s non-volatile memory.
Along with the hardware support and the ability to configure access for ACS subjects when developing the controller firmware, it was required to complete several additional tasks. Some of which demanded a bold approach.
The offline capability has become one of the key requirements for a minimum viable product. In principle, it was decided that the current access rules for each subject will be stored in the built-in memory of the controller.
Access settings can be changed at any time, therefore actual information must be stored in the memory of each of the system controllers. The data should be updated within a few minutes and synchronization should happen automatically across the entire system.
During the development of the firmware, the functionality of regular data synchronization between the server and the controller was added. At the same time, further requirements were formed and taken into account:
The implementation of these requirements became a key objective. Our team’s specialists have prepared a unique protocol for storing and synchronizing data with the main feature being the minimum requirements needed for the amount of built-in memory. The standard ESP32 four megabytes is enough to store access rules for thousands of users. The synchronization process has been optimized so that it’s only the data that needs updating is changing.
An unapparent obstacle, encountered while preparing an MVP, was the need to synchronize the Time Zone settings. The firmware must consider the seasonal time change, otherwise, the time schedules for the ACS subjects will be faulty. The corresponding functionality has also been added to the firmware.
A batch of 50 controllers has been prepared in-house. Having received a working device on a breadboard, our team prepared a printed circuit board project, and then the finished boards were ordered from China.
All the necessary components were also acquired. After receiving the batch of printed circuit boards, the controllers were then assembled by hand.
It took four months from the initial setting of the problem to the release of the MVP.
Following the preparation of an MVP, our team worked on the software part of the ACS. A web application for the administrator and a mobile application for system users were developed.
The web application is used to regulate the system, which is the main center for the ACS settings. Principal requirements for its functionality include:
One of the main features of a web application, according to the wishes of the customer, is a simple and intuitive interface. Most systems on the market were developed in the 1990s and 2000s and inherited an outdated approach to ergonomics.
While developing a web application for access control administration, our team relied on modern usability standards. The result is a user-friendly web application, which the customer learned to configure on their own after a simple 15-minute demonstration.
The 2Smart Cloud platform provides its mobile application for remote control of IoT devices. On its basis, an application was prepared for ACS users. The main idea is that a mobile phone can replace a card or other tag. (It should be possible to open access points from the application interface.)
Using the platform’s existing tools for remote device control, we also implemented the functionality of voice command control, the ability to share access, and the ability to control via a phone call.
The finished controllers were configured and installed on-site while the web application was installed on a private cloud server. Field testing took place over one month. During this time, the ACS has been working without interruption, performing the assigned tasks to perfection. The customer was completely satisfied with the results.
Based on the results of field testing, the entire zero batch of 50 controllers were installed at the facilities in the village. Including the houses of residents. Additional controllers were manufactured at the request of users, whose reviews were also positive. The system continues to work and develop well.
Built-in analytics tools allow the administrator to monitor the state of the system and monitor its “health”.
Based on the results following the field testing of a new access control system, the customer had an idea to scale the product to a commercial one. He presented our team with the task of conducting a detailed study of the access control market. Based on the results of such a study, a list of necessary improvements was prepared and options for positioning the product in the B2B and B2C market were proposed.
As part of business analysis, our team’s specialists once again studied the solutions existing on the market. If, as part of the initial task, the technical nuances and functionality of current systems were investigated, it was necessary to analyze the positioning of competitors along with their business model and pricing policy.
The goal of this procedure is to form a unique selling proposition by specifying a list of necessary technical improvements and suggesting an optimal business model.
Based on the results of the business analysis, two promising market opportunities for product promotion were identified: in the B2B, and B2C segments. Each of them was offered their own positioning and product configuration.
During the study of the B2C niche, the existing market problem was highlighted. Most solutions for the remote control of gates to a site or garage are outdated and not ideal.
Disadvantages of radio remote controls and key fobs:
Disadvantages of GSM modules:
The solution prepared as part of the original task does not have the listed disadvantages. At the same time, it combines the advantages of both methods of remote gate control and also provides users with more functionality.
For the B2C segment, it was proposed to position the product as a universal solution for controlling gate or garage automation using a mobile phone instead of traditional control methods.
Since the controller is already performing the necessary tasks, no product reevaluation was required. The only recommendation that appeared at this stage is to place the controller in a plastic case to make the device more presentable.
For B2C segment it was decided to offer customers a ready-made mobile application that comes with the 2Smart Cloud platform.
By using the application, users have the following control methods:
If necessary, you can quickly share access to gate control within the app.
A finished product was offered to the B2C audience. No additional improvements and financial investments were required to enter the market.
The peculiarity of the offer for private users is that the necessity of an access control system at the facility is not needed. The user installs one or more controllers and binds them to a mobile application that allows you to manage access points.
Additionally, there are restrictions set – the user can register no more than 20 physical access tokens for family members in the application.
A unique selling point is the ability to abandon remotes and GSM modules in favor of controlling the gate from a smartphone.
Target audience: owners of suburban real estate, residents of private houses, and owners of garages.
Business analysis for the B2B market included a study of the functionality of both popular, and little-known access control systems. In addition, the current market demands were studied and the customer’s experience was kept in mind when searching for an access control system.
As a result, additional functionality of the system was brought into the discussion, which will increase its competitiveness:
Unique selling points include an ACS with the possibility of self-configuration without training and the presence of a mobile application as a way to manage access points.
Target audience: cottage settlements, office centers, parking lots, businesses with a large number of access points.
During the stage of business analysis, the following needs of potential buyers of controllers and access control systems were identified:
The decision was made to move forward with additional improvements. This will allow the introduction of a line of devices on the market to meet the listed customer needs.
It was discovered that residential complexes require support for the functionality of intercoms and elevators. The residential complex market was recognized as promising for businesses, however, finalizing the functionality of these wishes requires financial resources and time. Such improvements were included in the long-term plans.
If a test batch of controllers was manually manufactured in the 2Smart Cloud lab, a third-party manufacturer of electronic devices had to be used for mass production. It was decided to establish production at factories in China. To speed up the process and simplify the legal side, an agreement was made to work with the manufacturer through an intermediary company registered in the PRC.
It is essential to personally audit the production site and internal quality control procedures. After that, it is necessary to approve the product reference sample before starting mass production.
Further quality control should include:
Since the components for the controller are also produced in the PRC, the manufacturer was entrusted with the choice of suppliers. By doing so, they must rely on the received specifications and the reference sample.
Considering that even a direct prohibition in the contract for copying the design of the device is not always effective, it was decided to provide the manufacturer with only the minimum required documentation. In particular, the manufacturer did not receive the source code for the controller firmware, which would make it possible to copy the entire solution. The controllers are flashed after receiving the finished batch, after which the devices go through the final stage of quality control.
The requirements put forward by the customer have been fully met:
The stage of work from the moment the customer addressed us to the completion of field testing took five months. Another three months passed from the start of the business analysis to the arrival of the first batch of finished devices from China.
If you too are seeking support with IoT solutions, send a description of your interests: email@example.com We will find the best solution for you.