NAZCA is a system of many possibilities, but it must be implemented in the right way. In this post, we explain what the two virtualisation methods are and show which solution will work better in specific customer deployments.
Virtualisation within the customer network
The first method of virtualisation takes place in a private network. This requires a suitable IT infrastructure (e.g. servers) - planned and implemented at the customer's premises. Hypervisors capable of handling NAZCA may also be its property.
The NAZCA component runs on a virtual machine running the Windows operating system, while the virtual machine itself runs on the hypervisor (physical computer) of the virtual machine. This can be a server or a set of servers that have software running to host the virtual machine. A virtual machine, on the other hand, is a runtime environment for NAZCA that the customer does not have to deal with physically, or manually. This can be likened to an operating system being 'invisible' from the user's perspective.
We recommend that BMS devices (e.g. access control devices) and external systems (marked "Auxiliary" in the diagram; e.g. stand-alone alarm system or stand-alone CCTV monitoring) operate on a separate computer network. It is therefore a separate part of the computer network from the building and customer network infrastructure, which would be used for communication between NAZCA and the BMS infrastructure and external systems.
Will this method of virtualisation be suitable? It is certainly better operationally, easier to use, and has fewer failures. Unfortunately, its disadvantage is that it requires space to be organised at the client's premises. It is its responsibility to provide and maintain the infrastructure and to employ specialists to ensure that it operates correctly. Despite these inconveniences, most of APA's customers opt for this option.
Virtualisation in cloud services
The second option is to implement and run NAZCA outside the client installation. In this case, the functioning of the system is possible thanks to the cloud provider.
In this solution, the physical software is on the cloud provider's side, while the customer is free to use it. The virtual machine is therefore not on the network belonging to the customer, but outside, in the cloud. This is basically the main difference between this way of virtualisation and virtualisation of the first type.
The advantages of this type of virtualisation are maintenance-free and savings on infrastructure. This is because the customer does not have to maintain the servers themselves. Their proper operation and maintenance is taken care of by an external entity.
This does not mean that the option described is without drawbacks. On the contrary, there may be more of them than in the case of internal network handling. Sometimes the continuity of communication between the NAZCA and the private elements in the network is disrupted. Its controllability is diminished, as network traffic must be "passed" across the Internet. When an ISP access failure occurs, the system is cut off from the software controlling it and the user loses the ability to operate it. The fault itself is much harder to troubleshoot compared to a local network solution, as the troubleshooting path is more complicated.
Virtualisation via the cloud unfortunately also comes at a security disadvantage. It is much more difficult to implement security outside the internal network.
As you can see, this way of implementation will not be appropriate always and everywhere. However, it works well for specific applications, for example when the customer has dispersed installations in dozens or hundreds of sites. If these are connected to the Internet anyway, and in addition there is no server room or it is located too far away, the risk is included in the price of doing business from the beginning. The second use of such virtualisation is for demonstration purposes, as it is easier to provide customers with access to the cloud than to the internal network.
CASE STUDY: NAZCA server virtualization at Tesko Steel facility
Moving the NAZCA server to a virtual machine in Tesko Steel Sp. z o.o., a company which is one of the most modern steel centers in Poland, was an example of implementation within the client's network. In this case, we relied on automatic backup of the entire server operating system. By the way, it was changed from Windows 7 to Windows 10 IoT.
The benefits have paid off nicely. The virtual server protects against physical hard disk failure or other hardware breakdown. In the event of a server software malfunction, it is possible to remotely reboot the entire server. If necessary, this task can also be automated to ensure the shortest possible downtime for the BMS and parking system.
During such virtualization, the customer benefited as follows, by gaining:
- ease of server management.
- data security.
- shorter failure recovery times.
- resistance to hardware breakdowns.
- increased server cyber-security.
