access control integration architecture

Access control integration architecture

Security Center supports different integration models for access control. The correct model depends on which system owns the access decision, which system owns the access control data, and where the physical hardware connects.

This page compares two access control integration architectures:

• A Synergis™ RIO (Readers, Inputs, and Outputs) integration, where third-party hardware connects to a Synergis appliance and Synergis Softwire makes the access decision
• A plugin integration for an external physical access control system (PACS), where Security Center connects to another access control system that keeps its own server, database, controllers, and decision logic

Use this reference to identify the correct integration model before writing code.

Integration models

Choose the integration model based on which system makes the access decision. If Synergis makes the access decision, use a Synergis RIO integration. If another access control system makes the access decision, use an external PACS plugin integration.

Model	Use this model when	Access decision owner	Security Center role	External system role
Synergis RIO integration	You manufacture or control access control hardware that must behave like native Synergis-connected hardware	Synergis Softwire	Configures the access control model, evaluates access rules, monitors events, and sends commands	Reports hardware events and executes commands
External PACS plugin integration	You integrate an existing physical access control system (PACS) that already has its own server, database, controllers, and logic	External PACS	Mirrors entities, monitors events, and routes operator commands	Owns the access control model, makes decisions, and controls hardware

Synergis RIO integration architecture

RIO is a hardware-level integration for third-party access control panels or interface modules. The third-party device communicates with a Synergis appliance over HTTPS. The appliance runs Synergis Softwire, which owns the access control logic.

In the diagram, REX stands for request to exit.

flowchart LR
    subgraph SC[Security Center]
        CT[Config Tool]
        SD[Security Desk]
        DIR[Directory]
        AM[Access Manager]
    end

    subgraph SY[Synergis appliance]
        CL[Synergis Cloud Link or Synergis appliance]
        SW[Synergis Softwire]
        RIO[RIO channel and bus]
    end

    subgraph HW[Third-party hardware]
        PANEL[Panel or interface module]
        READER[Readers]
        INPUTS[Door contacts, REX, and inputs]
        OUTPUTS[Locks, relays, and outputs]
    end

    CT <--> DIR
    SD <--> DIR
    DIR <--> AM
    AM <--> CL
    CL <--> SW
    SW <--> RIO
    RIO <-- HTTPS --> PANEL
    PANEL <--> READER
    PANEL <--> INPUTS
    PANEL <--> OUTPUTS

Loading

In this architecture, the third-party hardware isn't an independent access control system. It is an interface into Synergis. The hardware reports credential reads, PIN entries, input state changes, and online or offline state. Softwire evaluates access rules, schedules, antipassback, interlocks, first-person-in behavior, and other Synergis access control logic. Softwire then sends commands to the hardware, such as activating an output or providing reader feedback.

RIO doesn't require a separate middleware server. The hardware communicates directly with the Synergis appliance through the RIO API.

RIO runtime behavior

A typical RIO event path looks like this:

sequenceDiagram
    participant Reader
    participant Panel as Third-party panel
    participant RIO as RIO API
    participant Softwire as Synergis Softwire
    participant SC as Security Center

    Reader->>Panel: Credential presented
    Panel->>RIO: Report card swipe or PIN entry
    RIO->>Softwire: Forward access request
    Softwire->>Softwire: Evaluate access rules and door state
    Softwire->>RIO: Send output and reader feedback command
    RIO->>Panel: Return command through polling
    Panel->>Reader: Display feedback
    Panel->>Panel: Unlock or keep locked
    Softwire->>SC: Publish access event

Loading

The access decision happens in Softwire. The third-party panel doesn't decide whether the cardholder has access, except when the integration implements supported offline access decisions and the panel is configured to make those decisions.

External PACS plugin integration architecture

An external PACS plugin integration connects Security Center to another complete access control system.

The external PACS keeps its own access control server, database, controllers, readers, inputs, outputs, and decision logic. The Security Center plugin role synchronizes or maps data from that system, receives events, and routes commands back to that system.

flowchart LR
    subgraph SC[Security Center]
        CT[Config Tool]
        SD[Security Desk]
        DIR[Directory]
        PLUGIN[Plugin role]
        PDB[Plugin database or mapping store]
        CLIENT[Optional client extensions]
    end

    subgraph PACS[External PACS]
        SERVER[PACS server]
        DB[PACS database]
        CTRL[Controllers]
        READER[Readers]
        IO[Inputs and outputs]
        LOCKS[Locks and door hardware]
    end

    CT <--> DIR
    SD <--> DIR
    CLIENT <--> CT
    CLIENT <--> SD
    DIR <--> PLUGIN
    PLUGIN <--> PDB
    PLUGIN <-- Vendor API or SDK --> SERVER
    SERVER <--> DB
    SERVER <--> CTRL
    CTRL <--> READER
    CTRL <--> IO
    CTRL <--> LOCKS

Loading

The plugin role isn't a replacement for Access Manager or Softwire. It does not turn external controllers into Synergis controllers. It gives Security Center a server-side integration point that can synchronize entities, display status, raise events, answer reports, and route operator commands according to what the external PACS API supports.

The plugin copies the entities that operators need to monitor: cardholders and their pictures, credentials, doors, readers, units, inputs, outputs, and areas.

The plugin creates Security Center entities. Operators monitor an imported door the same way they monitor any other door, and they find imported cardholders, credentials, and areas in the same tasks, maps, and reports as the rest of the system.

The difference is ownership: the plugin role owns these entities, not an Access Manager role. Security Center has no connection to the physical hardware; the external PACS controls the hardware. The state of a door, reader, unit, input, or output reflects what the external PACS last reported. When an operator sends a command to one of these entities, Security Center passes the command to the external PACS, and the external PACS operates the hardware.

The plugin doesn't copy access rules or schedules. The external PACS decides who can go through which door, so the access rules and schedules stay in the external PACS. Each access event already identifies the cardholder and the door, and that is enough to monitor activity and run reports.

Plugin runtime behavior

External PACS events originate outside Security Center. The plugin receives those events and represents them in Security Center.

sequenceDiagram
    participant Panel as External controller
    participant PACS as External PACS server
    participant Plugin as Security Center plugin role
    participant SC as Security Center
    participant SD as Security Desk

    Panel->>PACS: Access event
    PACS->>Plugin: Event notification or poll response
    Plugin->>SC: Raise or map event
    SC->>SD: Display event and associated context

Loading

The external PACS continues to generate events while the plugin is disconnected. The plugin role can restart, the network path can fail, or the external PACS server can go offline. The integration must define how it recovers the events generated during the disconnection.

A recoverable event path has three parts:

• The plugin persists a recovery marker for the last processed event, such as an event sequence number or timestamp assigned by the external PACS.
• After a reconnection, the plugin queries the external PACS for the events generated after the marker, stores them with their original timestamps so reports stay complete, and then resumes the live feed.
• The plugin deduplicates recovered events against events already received, because a push channel can redeliver events during a reconnection.

Recovered events represent past activity. Store them for reports and history, and reserve live event monitoring for current activity.

Event recovery depends on the external PACS API. If the API can't return events for a past time range or replay missed notifications, events generated during a disconnection are lost. Confirm this capability during API evaluation, before implementation.

Commands follow the opposite path. Security Center doesn't directly energize the lock. Security Center requests an operation from the plugin, and the plugin requests the operation from the external PACS.

sequenceDiagram
    participant SD as Security Desk
    participant SC as Security Center
    participant Plugin as Security Center plugin role
    participant PACS as External PACS server
    participant Panel as External controller

    SD->>SC: Operator command
    SC->>Plugin: Plugin request or action
    Plugin->>PACS: Vendor API call
    PACS->>Panel: Controller command
    Panel->>PACS: Command result
    PACS->>Plugin: Result or event
    Plugin->>SC: Update status or raise event

Loading

The command set depends on the external PACS API and the plugin implementation. The Plugin SDK doesn't guarantee unlock, lock, lockdown, reset, and group commands. The plugin must explicitly map each operation to a supported external PACS operation.

Criteria for selecting an integration architecture

Choose an integration model based on these requirements:

• Which system makes the access decision
• Which system owns cardholders and credentials
• Which system owns doors, elevators, areas, schedules, and access rules
• Which physical device connects to the reader, lock, REX, and door contact
• Which events must appear in Security Center
• Which commands operators must run from Security Center
• Whether commands target Synergis hardware or an external PACS API
• Whether controller, reader, input, and output status must appear in Security Center
• Whether the external system provides an API, SDK, event stream, or database contract

See also

• Synergis RIO developer guide: Minimum implementation path for an access control integration using the RIO protocol
• About the Plugin SDK: Server-side plugin role architecture
• Plugin SDK entity mappings: Patterns for mapping Security Center entities to external system records