United States
A year ago, we set out on a difficult task. We wanted to preserve the best parts of the existing Ajax Hub (2G) operating system while removing any weaknesses and laying a solid foundation that would allow us to further develop the Ajax security system. After all, the hub is like a brain trust. It needs to be the most exceptional and reliable link in the chain. Thousands of engineering hours, hundreds of iterations and several elegant software solutions led us to OS Malevich. It’s not just another update. It’s a completely new hub operating system.
Once you’ve reached a dead end, don’t be afraid to turn back
Three years ago, we decided to create an intelligent security management center— Ajax Hub (2G). We wrote out the technical requirements and began to think about how to do it. There were three options— use C, use a real-time operating system or use Linux.
A typical C program that would ensure the absolute control as an operating system since we would have written every component of the system ourselves. The trade off was that the project would have taken a long time, its scalability would have been poor and it would have required a lot of debugging.
Linux offered a lot of ready-made solutions, as well as the possibility of parallel and, therefore, rapid development. We would be able to program in high-level languages, make use of abstractions and build a more complex application. But at the same time, we would have vulnerabilities, we wouldn’t have time limits for operations and we often wouldn’t have the best drivers. This would be unacceptable— we sell safety and reliability.
So we chose a real-time operating system (RTOS). It gave us the opportunity to create a simultaneously multifunctional and reliable application. Real-time operating systems are used in elevators, car brakes and ballistic missiles. They are maximally reliable, because, if a mechanism does not work within a strict timeframe, then the event no longer makes sense and a catastrophe occurs. This is a key difference between RTOS and Linux, where operations wait in an execution queue. And this is one of the reasons why Linux isn’t used in professional security systems.
Development took a year and a half. We created an OS that supports advanced cloud communication protocols over several channels. It manages a network of hundreds of radio devices. It can simultaneously send alarm messages over IP channels, dial telephones and send SMS. It possesses all needed professional security system capabilities and protects from attacks. So, we were able to accomplish our initial goal. We provided extensive functionality while ensuring high reliability.
But as soon as the Hub (2G) was released, there was a wave of requests for new features. Security companies asked for a direct connection to the hub, bypassing our cloud. Our Norwegian partners wanted one fire detector to be able to set off all fire detectors in a system when it detected a fire, and they wanted that to happen with the speed of wire fire alarms. The German market demanded that the product meet Grade 2 European standards and support a security system keyboard. In Malaysia and Denmark, users wanted extensive home automation capabilities. For Italy, a separate role for installers was very important.
The existing architecture did not allow us to expand functionality rapidly. We could quickly add features to the mobile applications because they had high-level development environments, but writing hub software required more time. Changes were difficult to test and implementing them required too many resources. In order to build complex logic, we needed a new level of abstraction, a separation between hardware and software.
We had to decide how to build the system further. Did we need to switch to Linux? Gradually refine our OS? We needed to maintain the reliability and stability of the real-time operating system, but at the same time, we needed the scalability of a high-level operating system like Linux. Once again, the ready-made solutions didn’t work for us, so we had to come up with our own.
Simplicity only has value if it’s rooted in complexity
The basis of our new OS was the idea of simplification. We set conditions for ourselves: adding features should not complicate the system or reduce development speed. In order not stray off course, the project was codenamed “Malevich,” in honor of the famous Kyiv-born artist, Kazimir Malevich. His “Black Square” is a vivid example of a brilliant idea based in infinite simplicity.
In order to create OS Malevich, we had to change everything— the architecture, the programming approach, the coding and design standards, the organization of work, the development environment. Although the operating system continued to focus on process execution time, it started gaining features of Linux. We implemented a similar mechanism for allocating CPU time. As a result, the hub processor uses a maximum of 20%, even when performing resource-intensive tasks. The system also became modular; standard APIs are used to allow interaction between elements. It’s easy to work with modules, errors can be quickly identified and eliminated, and it’s simple to increase functionality and experiment to reach the ideal efficiency.
We set Ajax products equal in terms of development speed. We can implement new features for the hub, server and app equally quickly. There are no technical limitations to our ideas.
As of today, a computer program is not usually considered an art object. Its beauty is not understood by the masses. But we’re confident that, over time, the ideas we’ve implemented will become a classic in the Internet of things.
Read more:
