Physical Security Information Management (PSIM)

Large enterprise campuses, critical infrastructure sites, and government facilities run security ecosystems composed of 8-15 independent subsystems from different manufacturers, each with its own management software, user interface, credential store, and alerting paradigm. An access control forced-door alarm from Lenel, a motion alert from a Bosch intrusion panel, and a camera with a relevant view in Milestone all relate to the same physical event—but appear in three separate applications with no automatic correlation. Operators must mentally fuse this information while simultaneously monitoring other subsystems.

Incident response procedures in this fragmented environment are document-based: a binder of SOPs that operators must reference manually while managing a live event. This introduces inconsistency—different operators follow procedures differently—and delays—time spent reading procedures is time not spent responding. Post-incident reporting requires manually assembling data from each subsystem into a narrative, a process that can take hours for a single incident and often results in incomplete records.

Compliance mandates for regulated facilities (NERC CIP for energy, CFATS for chemical, FISMA for federal) require demonstrable proof that security events were detected, responded to within defined timeframes, and documented with full audit trails. Manual processes make compliance a burden of reporting rather than a natural byproduct of operations. The security team spends as much time generating compliance documentation as they do performing actual security functions.

Our PSIM architecture uses a middleware integration layer that communicates with each subsystem through its native protocol or API. Access control systems connect via OSDP v2 (for panel-to-reader communication) and vendor SDKs (Lenel OnGuard, Genetec Synergis, AMAG Symmetry) for management-level integration. Video systems integrate via ONVIF Profile S/T for camera control and the VMS SDK for bookmark, clip export, and PTZ operations. Intrusion panels communicate via SIA DC-07-2001.04 (SIA Contact ID over IP) and Ademco Contact ID. Fire alarm systems connect via proprietary panel APIs (Notifier, Edwards, Simplex) or via monitoring receiver integration. Building management connects via BACnet/IP or OPC UA.

The event processing engine normalizes all subsystem events into a unified event ontology that captures the event type, severity, location (mapped to a common spatial model), associated entities (doors, cameras, zones), and temporal context. A rules engine evaluates incoming events against configurable compound-event patterns and triggers automated incident workflows: when an intrusion alarm triggers in a specific zone, the PSIM automatically pulls live video from associated cameras, locks down adjacent access points, sends notifications to designated responders, and creates an incident record pre-populated with all correlated data.

The operator interface presents a single priority-ranked event queue backed by a React-based web application with real-time WebSocket updates. Each event is enriched with contextual information: the nearest cameras are pre-loaded as thumbnails, the affected zone is highlighted on the facility map, the applicable SOP is presented as an interactive checklist, and the responder notification status is visible. Post-incident, the system generates compliance-ready reports that include timeline, actions taken, response times, and all associated evidentiary artifacts—automatically, without manual assembly.

Subsystem integration follows an adapter pattern where each security platform connects through a dedicated integration module that handles protocol translation, connection lifecycle management, and bidirectional command/event flow. Access control integration for Lenel OnGuard uses the DataConduIT API (SOAP/XML) for event subscription and command dispatch; Genetec Synergis uses the Security Center SDK (.NET) wrapped in a gRPC service; AMAG Symmetry uses its REST API. Each adapter publishes normalized events to an internal MQTT broker (EMQX) and subscribes to command topics for bidirectional control (e.g., remote door unlock, badge disable).

Intrusion panel integration supports SIA DC-07-2001.04 (Contact ID over IP), SIA DC-09-2007 (IP-based alarm monitoring protocol with TLS), and direct serial connections to legacy panels via RS-232 to TCP/IP converters. The SIA DC-07 adapter decodes the 16-digit Contact ID event code, mapping it to the unified event ontology using the SIA event code dictionary (document SIA DC-05-1999.09). Fire alarm integration uses the monitoring receiver protocol native to each panel manufacturer, or connects via a universal DACT replacement unit (like Teldat IP) that converts legacy PSTN signaling to IP-based event delivery.

The rules engine uses a Rete-based pattern matching algorithm implemented in Node.js, evaluating event patterns against a rule base stored in PostgreSQL. Rules are defined in a JSON-based DSL that supports temporal operators (within, before, after, sequence), spatial operators (near, within-zone, adjacent-to), and entity-relationship operators (same-credential, same-camera-group). Rule evaluation maintains a rolling temporal window (configurable, default 5 minutes) and achieves sub-50ms evaluation time for rule sets of up to 500 rules against event rates of 1,000 events per second.