On this page (3)
With devices that the server connects to, the IT department receives a request: ‘please open inbound ports to fourteen devices in the yard, list of addresses attached’. The network administrator reads it once, replies ‘no’, and is right to. A device on a post by the gate that can be reached from outside is exactly the piece of infrastructure that post-incident reports end up being written about. In TraxSystem no such request arises, because the communication runs the other way.
Devices behind NAT: what it changes on the network
TraxSystem controllers and the SMS gateway can sit behind NAT, in a separate subnet, with no public addresses. All the traffic consists of outbound connections to a single server, so the network configuration needs no port forwarding and no port map: one rule instead of fourteen exceptions.
The system judges whether a device is alive from its regular check-ins, without pinging it. Industrial controllers are sometimes deaf to ping, whereas a check-in that has stopped arriving is unambiguous: the system raises an alert before the gate staff notice anything is missing.
Device firmware is updated remotely, through the server. Changing a controller’s network settings works in two stages: the device tries the new settings and reverts to the old ones by itself if it cannot connect within a few minutes. A typo in the network gateway address does not knock out the controller on its post, and it does not end with someone driving out with a ladder.
Command latency in the pull model
In the pull model, a command from the server waits until the device comes to collect it. With a polling cycle of roughly once a second, a person standing at the barrier will not notice the difference. The controller collects the opening pulse without acknowledging receipt, though, and the system does not resend it, because a pulse repeated late would hit a boom that is already coming down. Every command stays in the log with the person and the source, so in the system a barrier that never received a command does not look like one that did.
What devices do when they lose the connection to the server
Losing the connection to the server matters differently for each device. The barrier controller has no access logic of its own, so without the server security operates the gate by hand. Access control points keep working from the list of cards stored in the device, limited to date ranges, and they buffer events and send them on once the connection is back. The relay module can be configured so that, if the server is lost, it switches all its outputs on as an emergency measure, for example opening the barriers instead of leaving them closed.
An overview of the devices is on the devices at the gate and access points page, and the server’s place in the infrastructure is described on the architecture and deployment models page.
See also: Do you need new barriers and cameras to implement the system · Edge vs cloud ANPR: what is the difference