AccessCORE PACS Middleware

The PACS server publishes configuration and control commands to the NATS JetStream message broker, and the middleware converts them into commands the HID Aero controllers understand. In the other direction, the middleware collects field events such as card reads and door state changes and publishes them to the server.

Server and middleware exchange only Protocol Buffers messages. Commands arrive on three channels for configuration sync, immediate control, and status queries, while results, events, and middleware health go out on six channels of their own, so message types never mix.

Seventeen kinds of settings, nineteen immediate control commands, and ten status queries are converted into device commands, and each command has a matching result channel where the server finds its answer by request ID. When the same command is redelivered within a set period, the middleware checks its processing record and does not run it again.

The middleware runs a dedicated pipeline for each controller. Configuration sync, immediate control, and status query commands are taken in that priority order and run one at a time, so settings are applied in their required order and the device SDK never receives two commands at once.

Configuration commands pass through three stages: validation and conversion, building the SDK command, and serialization and sending. All conversion rules sit in the first stage and the second only copies values, so a change in how a device field is interpreted touches the first stage alone.

Queued control commands and status queries are handled in batches: requests past their validity are not run and are answered as expired, and of duplicate status queries only the newest is run. A controller that stops responding does not hold up the pipelines of the others.

A controller sends an identity report with its MAC address, serial number, and firmware version when it powers up, and the middleware registers it automatically. The list of registered controllers is reported to the server at a set interval, and the server sends each new controller its full configuration.

The full configuration is applied phase by phase in the order the server sends the settings, then saved to the device’s flash memory. If a phase fails, the result reports the last completed phase, and when the server retries with that value the middleware continues from the next one.

The middleware keeps no access configuration of its own; only what re-registration needs, such as controller number assignments, is kept in the broker’s key-value store. After a middleware restart or a controller reboot, the same steps register the controller again and bring it back to the configuration stored on the server.