Mealtime cannot stop because of a network fault. This post compares the two deployment models and explains how data is stored at the counter.
A factory meal period is short and serves workers continuously. If the counter devices depend entirely on a connection to the server, one network fault at mealtime stops meal service for the whole line.
This post sets out the two deployment models for Sol26 Canteen, how the components connect, the security layers and the mechanism that keeps the counter running during an outage.
System components
The application architecture is the same in both models. Where the service layer sits determines whether the system is on-premise or in the cloud.
- A recognition terminal on each line, each paired with a computer driving the display screen
- Web clients for administrators, the kitchen and users placing orders
- The service layer: web server, MQTT broker, database and storage behind a load balancer
- UPS power for counter devices
Devices and the service layer communicate over port 1883/TCP for MQTT and 443/TCP. Devices receive user information and collection rights, then send back successful scans for display at the counter.
On-premise deployment
In the on-premise model the service layer runs on the customer's server. That server can be a standalone physical machine or a virtual machine on the factory's existing infrastructure. Staff data, face photos and collection history stay on the internal network.
One server specification proposed for a four-counter project was a tower server with a 6-core, 12-thread Intel Xeon CPU, 32GB ECC RAM, a 480GB SSD, three 4TB hot-plug SAS drives with a RAID controller and dual 600W power supplies. This model suits factories with a server room and IT staff to run it.
Cloud deployment
In the cloud model the service layer runs on a private cloud, where devices are managed, monitored and configured remotely. The factory does not need its own server, and counter devices connect out through the two ports above.
The differences between the models are where the data sits, who is responsible for running the server and how much the system depends on the factory's Internet link.
Layered security and roles
The security diagram places three firewall layers around the devices, web clients, load balancer, service layer, web application, database and storage. One of these layers combines a firewall with role-based access control.
- Users (staff, workers): order meals, view orders, change password
- Kitchen: view the order list and monitor collection
- Administrators: configure shifts, lines, dishes, menus and users, and export reports
Why the counter must work offline
Counter data sync and storage is an optional feature in the solution proposal and is licensed per counter machine. Data from the server is synchronised in real time to each mini PC. If the network connection is lost, the counter machine keeps working from locally cached data.
In the cloud model, the point to protect is the outbound Internet link. In the on-premise model, it is the internal network and power supply. Counter storage covers connectivity, and the UPS covers power.
In one quoted configuration, a 1kVA double-conversion online UPS runs for about 9 minutes 51 seconds at half load and 3 minutes 12 seconds at full load.
Frequently asked questions
- Should we choose on-premise or cloud?
- On-premise suits factories that want staff data and face photos kept on the internal network and have IT staff to run a server. Cloud suits factories that do not want to invest in their own server.
- Can workers still collect meals during a network outage?
- Yes, if the counter data sync feature is deployed. The counter machine uses locally stored data to keep working.
- Which network ports does the system use?
- Devices connect to the service layer over port 1883/TCP for MQTT and port 443/TCP.
- Can a virtual server be used?
- Yes. The customer server can be a standalone physical machine or a virtual machine.