How to Simulate ONVIF Door Controllers and Access Control Systems with ONVIF Server

Why Simulate ONVIF Access Control Devices?

Testing access control integration is traditionally expensive: you need physical door controllers, card readers, electric locks, exit buttons, and door sensors. Happytime ONVIF Server eliminates this barrier by emulating all access control components in software, enabling:

• VMS Platform Testing: Verify that your Video Management System correctly discovers, monitors, and controls ONVIF-compliant doors and access points.
• Integration Development: Develop and debug access control client software without waiting for hardware procurement and installation.
• Scalability Testing: Simulate dozens or hundreds of doors to validate system capacity before production deployment.
• Training & Demonstration: Showcase access control features to stakeholders in a controlled, repeatable environment.

Happytime ONVIF Server is one of the few tools on the market that supports the full ONVIF Profile C (Door Management) and Profile A (Access Control) specifications, making it a uniquely capable access control simulator.

Understanding ONVIF Access Control Profiles

Before configuring the simulator, it is important to understand the two ONVIF profiles that govern access control:

Profile C — Door Management

Profile C defines how an ONVIF client can discover and control physical doors. A Profile C compliant device exposes:

• Door state monitoring: Open, Closed, Unknown, Fault
• Door control: Lock, Unlock commands
• Door alarm events: Forced Open, Door Held Open, Tamper
• Physical I/O mapping: Sensors (door contact) and actuators (lock relay)

Profile A — Access Control

Profile A extends Profile C with identity-based access management:

• Credentials: Card numbers, PIN codes, biometric identifiers
• Access Rules: Which credential can access which door at which time
• Schedule Service: Time-based access windows (e.g., M-F 8:00-18:00)
• Access Events: Access Granted, Access Denied, Unknown Credential

Happytime ONVIF Server implements all ONVIF services required by both profiles: Access Control Service, Door Control Service, Credential Service, Access Rules Service, Schedule Service, Device IO Service, and Event Handling.

ONVIF Access Control Services Reference

The following table summarizes the ONVIF web services that ONVIF Server implements for access control simulation, and what each service enables the client to do:

Step 1: Configure the Device Type as Access Control

Happytime ONVIF Server supports multiple device type simulations in a single instance. In the configuration file, specify the device type to enable the appropriate ONVIF services.

The device type determines which ONVIF web service endpoints the server exposes. For access control simulation, the device should be configured as an Access Control or Door Controller type, which activates the Door Control, Access Control, Credential, Access Rules, Schedule, and Device IO services.

Example: Basic Access Control Device Configuration

<config>
    <!-- Device identity -->
    <name>Building-A-Access-Controller</name>
    <manufacturer>Happytimesoft</manufacturer>
    <model>ONVIF-AC-1000</model>
    <hardware_id>AC-A-001</hardware_id>

    <!-- Network settings -->
    <http_port>8080</http_port>
    <https_port>443</https_port>
    <rtsp_port>554</rtsp_port>
    <ip_address>192.168.1.200</ip_address>
    <ipv6_enable>0</ipv6_enable>

    <!-- Enable ONVIF services -->
    <device_type>AccessControl</device_type>

    <!-- Access control configuration -->
    <access_control>
        <access_point_token>Door-01</access_point_token>
        <access_point_name>Main Entrance</access_point_name>
        <access_point_description>Building A main entrance door</access_point_description>
        <access_point_enabled>true</access_point_enabled>
    </access_control>

    <!-- Log settings -->
    <log_enable>1</log_enable>
    <log_level>1</log_level>
    <log_path></log_path>
    <log_mode>loop</log_mode>
    <log_max_size></log_max_size>
</config>

Key configuration points:

• <device_type> determines which ONVIF profiles are advertised during discovery. For Profile C/A compliance, set to AccessControl.
• The device identity fields (name, manufacturer, model) appear in ONVIF client discovery results — use descriptive values that match your test scenario.
• Network ports must be reachable by the ONVIF client. The HTTP port (default 8080) carries all SOAP/XML web service traffic.

Step 2: Configure Doors and Access Points

An access control system models the physical world: doors, readers, locks, and sensors. ONVIF Server lets you define these components in the configuration.

Door Configuration

Each door is represented as an access point in ONVIF terminology. An access point links together the door's physical components: the door sensor (input), the lock (output), and optionally a card reader and exit button.

<doors>
    <!-- Door 1: Main Entrance -->
    <door>
        <token>Door-01</token>
        <name>Main Entrance</name>
        <description>Building A main entrance door</description>
        <initial_state>Closed</initial_state>
        <initial_lock_state>Locked</initial_lock_state>
    </door>

    <!-- Door 2: Server Room -->
    <door>
        <token>Door-02</token>
        <name>Server Room</name>
        <description>Restricted server room access</description>
        <initial_state>Closed</initial_state>
        <initial_lock_state>Locked</initial_lock_state>
    </door>

    <!-- Door 3: Emergency Exit -->
    <door>
        <token>Door-03</token>
        <name>Emergency Exit</name>
        <description>South wing emergency exit</description>
        <initial_state>Closed</initial_state>
        <initial_lock_state>Locked</initial_lock_state>
    </door>
</doors>

Door states reference:

Lock states reference:

Step 3: Define Device IO (Sensors and Actuators)

The Device IO Service maps physical hardware signals to logical ONVIF data points. For each door, you define the digital inputs (door contact sensor, exit button) and digital outputs (lock relay) that the ONVIF client can monitor and control.

<device_io>
    <!-- Door 1 IO -->
    <door_token>Door-01</door_token>

    <!-- Digital inputs (sensors) -->
    <digital_input>
        <token>DI-01-Contact</token>
        <name>Door Contact Sensor</name>
        <type>DoorContact</type>
        <initial_state>High</initial_state>  <!-- Normal state when door is closed -->
    </digital_input>

    <digital_input>
        <token>DI-01-ExitButton</token>
        <name>Exit Button</name>
        <type>REX</type>
        <initial_state>Low</initial_state>
    </digital_input>

    <!-- Digital outputs (actuators) -->
    <digital_output>
        <token>DO-01-Lock</token>
        <name>Door Lock Relay</name>
        <type>DoorLock</type>
        <initial_state>High</initial_state>  <!-- Energized = Locked -->
    </digital_output>
</device_io>

Common IO types for door control:

• DoorContact: Magnetic reed switch or hall-effect sensor that detects whether the door is physically open or closed.
• REX (Request to Exit): Exit button or PIR motion sensor on the secure side that triggers the door to unlock momentarily without requiring a credential.
• DoorLock: Relay that energizes/de-energizes the electric lock or door strike. When the relay is energized (High), the door is typically locked (fail-secure) or unlocked (fail-safe), depending on lock type.
• Tamper: Sensor that detects if the controller enclosure has been opened.

Step 4: Create Credentials

Credentials define the identities that can request access. ONVIF Profile A supports multiple credential types. For testing purposes, you configure a set of known credentials that your test scenarios will use.

<credentials>
    <credential>
        <token>CRED-001</token>
        <type>Card</type>
        <format>Wiegand26</format>
        <value>00012345</value>
        <holder_name>Zhang Wei</holder_name>
    </credential>

    <credential>
        <token>CRED-002</token>
        <type>PIN</type>
        <format>Numeric4Digit</format>
        <value>5801</value>
        <holder_name>Li Ming</holder_name>
    </credential>

    <credential>
        <token>CRED-003</token>
        <type>Card</type>
        <format>Wiegand34</format>
        <value>0000006789</value>
        <holder_name>Wang Fang</holder_name>
    </credential>

    <credential>
        <token>CRED-004</token>
        <type>Biometric</type>
        <format>Fingerprint</format>
        <value>FP-Sample-0001</value>
        <holder_name>Chen Yu</holder_name>
    </credential>
</credentials>

Credential types supported:

Step 5: Define Access Rules and Schedules

Access rules bind credentials to access points and define when access is permitted. This is the core logic that determines whether a credential-bearer can enter a specific door at a specific time.

Schedule Definition

First, define the time windows that govern access. Schedules support recurring weekly patterns and special-day overrides.

<schedules>
    <schedule>
        <token>Schedule-BusinessHours</token>
        <name>Business Hours (M-F 8:00-18:00)</name>
        <monday>
            <start>08:00</start>
            <end>18:00</end>
        </monday>
        <tuesday>
            <start>08:00</start>
            <end>18:00</end>
        </tuesday>
        <wednesday>
            <start>08:00</start>
            <end>18:00</end>
        </wednesday>
        <thursday>
            <start>08:00</start>
            <end>18:00</end>
        </thursday>
        <friday>
            <start>08:00</start>
            <end>18:00</end>
        </friday>
    </schedule>

    <schedule>
        <token>Schedule-24x7</token>
        <name>24/7 (All Day, Every Day)</name>
        <sunday>
            <start>00:00</start>
            <end>23:59</end>
        </sunday>
        <monday>
            <start>00:00</start>
            <end>23:59</end>
        </monday>
        <tuesday>
            <start>00:00</start>
            <end>23:59</end>
        </tuesday>
        <wednesday>
            <start>00:00</start>
            <end>23:59</end>
        </wednesday>
        <thursday>
            <start>00:00</start>
            <end>23:59</end>
        </thursday>
        <friday>
            <start>00:00</start>
            <end>23:59</end>
        </friday>
        <saturday>
            <start>00:00</start>
            <end>23:59</end>
        </saturday>
    </schedule>
</schedules>

Access Rule Definition

Now create access rules that combine a credential, an access point (door), and a schedule. Multiple rules can apply to the same door for different credential holders.

<access_rules>
    <!-- General employee: all doors during business hours -->
    <rule>
        <token>Rule-001</token>
        <name>General Staff Access</name>
        <credential_token>CRED-001</credential_token>
        <access_point_token>Door-01</access_point_token>
        <schedule_token>Schedule-BusinessHours</schedule_token>
    </rule>

    <rule>
        <token>Rule-001-Emergency</token>
        <name>General Staff Access (Emergency)</name>
        <credential_token>CRED-001</credential_token>
        <access_point_token>Door-03</access_point_token>
        <schedule_token>Schedule-24x7</schedule_token>
    </rule>

    <!-- IT staff: server room, 24/7 -->
    <rule>
        <token>Rule-002</token>
        <name>IT Staff Server Room Access</name>
        <credential_token>CRED-002</credential_token>
        <access_point_token>Door-02</access_point_token>
        <schedule_token>Schedule-24x7</schedule_token>
    </rule>

    <!-- Biometric-only access to server room -->
    <rule>
        <token>Rule-003</token>
        <name>Senior Admin Biometric Access</name>
        <credential_token>CRED-004</credential_token>
        <access_point_token>Door-02</access_point_token>
        <schedule_token>Schedule-24x7</schedule_token>
    </rule>
</access_rules>

Step 6: Complete Configuration Example

Below is a full working configuration for a single ONVIF Server instance simulating an access controller with 3 doors, 4 credentials, 2 schedules, and 4 access rules:

<config>
    <name>Building-A-Access-Controller</name>
    <manufacturer>Happytimesoft</manufacturer>
    <model>ONVIF-AC-1000</model>
    <hardware_id>AC-A-001</hardware_id>
    <http_port>8080</http_port>
    <https_port>443</https_port>
    <rtsp_port>554</rtsp_port>
    <ip_address>192.168.1.200</ip_address>
    <ipv6_enable>0</ipv6_enable>
    <device_type>AccessControl</device_type>
    <log_enable>1</log_enable>
    <log_level>1</log_level>
    <log_path></log_path>
    <log_mode>loop</log_mode>
    <log_max_size></log_max_size>
</config>

Step 7: Testing with an ONVIF Client

Once the ONVIF Server is running, you can test the access control simulation using any ONVIF-compliant client (such as Happytime ONVIF Client, ONVIF Device Manager, or your own VMS platform).

Test Flow 1: Door State Discovery

1. Use the ONVIF client to discover the device on the network via WS-Discovery.
2. Verify that the device shows up with the name, manufacturer, and model you configured.
3. Navigate to the Door Control or Access Control section in your client.
4. Verify that all three doors (Main Entrance, Server Room, Emergency Exit) are listed.
5. Confirm that each door shows its initial state (Closed, Locked).

Test Flow 2: Door Lock/Unlock

1. Select a door (e.g., Main Entrance).
2. Send an Unlock command via the client.
3. Verify that the door state changes from Locked to Unlocked on the client display.
4. Send a Lock command.
5. Verify the state returns to Locked.

Test Flow 3: Access Request (Simulating a Card Swipe)

1. Use the client's access request function to submit a credential at a specific door.
2. Test with CRED-001 at Door-01 during business hours (8:00-18:00 M-F) — should result in Access Granted.
3. Test with the same credential at Door-02 (Server Room) — should result in Access Denied (no rule exists for CRED-001 at Door-02).
4. Test with CRED-002 (PIN) at Door-02 — should result in Access Granted.

Test Flow 4: Event Subscription & Notification

1. In the ONVIF client, subscribe to access control events.
2. Simulate an access request with a valid credential — verify that an Access Granted event is received with the credential token, door token, and timestamp.
3. Simulate an access request with an unknown credential — verify that an Access Denied or Unknown Credential event is received.
4. Change the door state to Open — verify that a Door State Changed event with details propagates to the subscriber.

Test Flow 5: Door Alarm Simulation

1. Simulate a Forced Open alarm: the door transitions to Open without a prior valid access request or exit button activation.
2. Verify that the client receives a Forced Open alarm event.
3. Simulate a Door Held Open alarm: the door remains Open beyond the configured held-open timeout.
4. Verify that the client receives a Door Held Open alarm event.
5. Simulate a Tamper alarm: the controller enclosure is opened.
6. Verify that the client receives a Tamper alarm event.

Step 8: Run and Verify

1. Save the onvifserver.cfg file.
2. Launch the ONVIF Server executable. It will read the configuration and start listening on the specified HTTP/HTTPS ports.
3. Check the logs (with <log_enable>1</log_enable>) to confirm that the ONVIF services have started successfully and the device is ready for discovery.
4. Discover the device using your ONVIF client on the same network. The device should appear with WS-Discovery (multicast) or can be added manually by IP address.
5. Run through the test flows described in Step 7 to validate each access control service.

Troubleshooting

Best Practices

• Start with a Single Door: Configure one door with one credential and one rule first. Confirm end-to-end functionality (discovery, lock/unlock, access request, events) before adding more complexity.
• Use Descriptive Tokens: Use meaningful token names (Door-01, CRED-Admin-001) rather than opaque UUIDs. This makes configuration maintenance and test scenario documentation much easier.
• Log Everything During Testing: Set <log_level> to 0 (TRACE) or 1 (DEBUG) during initial setup. The detailed SOAP request/response logs are invaluable for diagnosing access control integration issues.
• Test Schedule Edges: When testing time-based access rules, test exactly at schedule boundaries (e.g., 08:00:00, 17:59:59, 18:00:00) to verify that your VMS handles edge cases correctly.
• Simulate Real-World Alarm Scenarios: Test Forced Open and Door Held Open alarms with realistic timing. Many VMS platforms have configurable alarm hold-off and grace periods — verify that your platform processes alarms as expected.
• Use Separate Instances for Different Profiles: If you need to test both Profile C (basic door control) and Profile A (full access control with credentials/rules), consider using separate ONVIF Server instances or configurations to isolate test scenarios.
• Document Your Test Configuration: Keep a copy of each test scenario's configuration file for regression testing. This ensures that future VMS software updates can be validated against the same simulated access control environment.