OsprioView — Emulator Workspace
Live

OSDP Emulator

Test the device you have against the device you need

Emulator Workspace is the Osprio View OSDP emulator — it stands in as either side of the OSDP link, an ACU (Access Control Unit / control panel) or a PD (Peripheral Device such as a reader), and emulates any behavior the OSDP specification defines. Point it at your own reader or controller and test your product against a fully controllable, spec-complete peer — run the secure channel, send OSDP commands and events, and script repeatable fault tests with reusable actions.

Launch Osprio View ↗OSDP emulator docsOsprio View brochure (PDF)
OSDP Emulator

Be the ACU or the PD — and emulate any OSDP feature

This is what the emulator is for: it faithfully plays either role in the OSDP conversation — the ACU (Access Control Unit / control panel) or a PD (Peripheral Device such as a reader) — and can emulate any capability the specification supports. That makes Osprio the reference peer you test your own product against: bring your reader and let Osprio be the ACU, or bring your controller and let Osprio be the PD.

01

PD capabilities emulation

In PD mode the profile editor opens into a full device-definition workflow. Declare the identity the emulator should present — OSDP version, model number, vendor code, serial number, and firmware version — so the peer on the bus sees a device with a real, consistent fingerprint rather than a bare placeholder.

Then describe what the device can actually do: contact and input monitoring, output behavior, reader-facing LEDs and audible feedback, text display, communication and security support, and general capacity hints. Each capability shapes how the emulated PD answers capability queries and behaves during a session.

Use it to stand in for a specific class of reader or controller you need to test against — model the device you already have, or the device you are about to deploy, without the hardware in hand.

02

Slot-backed profiles

Configurations live as profiles in slots on the device itself, not buried in host-side files. Load the slot table from connected hardware, then create a new profile in an empty slot, open one read-only for inspection, or promote one to the active runtime profile.

Switching between saved devices is then just selecting a slot — no re-entering addresses, keys, baud rates, or capability sets each time you change what you are emulating.

Profiles import and export as JSON, so a known-good configuration moves cleanly between sessions, machines, and test environments, and can be version-controlled alongside the rest of a test setup.

03

Secure channel support

Every managed PD in a CP profile carries its own Secure Channel Base Key (SCBK) and per-PD flags, including secure-channel enforcement and unsolicited-response handling, so you configure the peer exactly as the deployment expects it.

From there the session negotiates the OSDP secure channel and runs encrypted, authenticated traffic against a peer you fully control — the right setup to exercise secure-channel establishment, key handling, and encrypted command and reply flows end to end.

Live state distinguishes a plain online link, an active secure channel, and a secure channel running on the default key (SCBK-D), so install-key fallback is something you can see rather than guess at.

04

Live CP/PD status

A compact strip of status cards summarizes every managed PD while a session runs. Cards are ordered by PD offset from the profile and capped at the eight devices the device side currently surfaces, so the state that matters stays readable at a glance.

Each card carries a single icon for its most important live state: grey for unknown or offline, green for online without a secure channel, a green lock for an active secure channel, and an amber lock when that channel is running on SCBK-D.

Hover a card for the full textual state and how long ago it last updated — Online, Online SC Active, Online SC Active with SCBK-D, and so on. The strip is driven by live notifications from the device, which is why notification support is always enabled in the profile model.

05

OSDP commands and events

Drive the protocol directly from the UI. In CP mode, build an OSDP command and send it to a target PD; in PD mode, submit an event toward the control panel. The available base operation follows the emulator role automatically.

Construct the payload, pick the target PD index, and fire — no scripting required for one-off traffic, and no need to leave the active session to do it.

Anything you send by hand can also be saved as a reusable action, so an ad-hoc command becomes a repeatable building block the moment it proves useful.

06

Actions building block

Base actions are the leaf operations that actually emit traffic — a CP command aimed at a PD index, or a PD-originated event submission. Save one and it becomes a card you can run with a single click.

Those base actions are the foundation for everything higher up: wrap them in repetitions, chain them into sequences, or fire them from triggers, building complex behavior from small, proven pieces instead of re-typing commands.

The actions toolbar supports an action-library workflow, so definitions can be preserved outside the current session UI and reused across runs.

07

OSDP logs and events

The upper runtime pane splits into two live views side by side: an Event Log of incoming OSDP report activity, and a LibOSDP Logs pane of device-side log output. Watching both at once lets you line up protocol activity with what the device firmware is actually doing.

The event log carries command reports, PD event reports, and notification reports, and expands any entry for full payload inspection — so you see not just that a report arrived, but exactly what it contained.

The libosdp pane streams logs live with per-PD context tags and runtime log-level filtering, so a busy multi-PD session stays legible while you focus on one device or one severity.

08

File transfer

When a profile drives an OSDP file transfer, the session tracks it directly so the operator can watch and manage the exchange rather than running it blind.

Outgoing transfers (CP → PD) send a registered file and show a live progress bar against the total size. Incoming transfers (PD ← CP) arrive as file cards that move through transferring to complete or failed, and a completed card holds the received bytes so the file can be downloaded.

Because a transfer is real in-flight work and a received file may not yet be saved, the workspace warns before close while one is mid-flight, so the work is never lost silently.

Actions

Automate protocol behavior instead of typing commands

The actions pane turns Emulator Workspace into a lightweight automation system. Define what should happen, when it should repeat, and what should trigger it — then let the workspace drive the session while you watch the results.

01

Commands and events

Base actions are the starting point of the actions pane. Create one that sends an OSDP command to a target PD in CP mode, or submits an event toward the control panel in PD mode — the type on offer follows the current emulator role.

Each base action is saved and reusable: a named building block you can run on demand or fold into the higher-level automation types, rather than rebuilding the same payload every time.

02

Repetitions

A repetition runs another action many times on a configurable cadence. Equal mode fires a fixed count at a fixed interval — say ten times every two seconds — for predictable, evenly spaced traffic.

Random mode spreads the same count randomly across a total duration window, closer to how real traffic actually lands. Together they cover stress testing, polling validation, repeatable test cases, and soak-style load that does not fall on a tidy beat.

03

Sequences

A sequence runs several actions in order, with a configurable delay between each step. It captures a multi-step exchange as one reusable unit instead of a handful of commands you fire by hand and hope you timed right.

Use it to model multi-step device behavior, reproduce a known command or event progression, or script a repeatable workflow — the timing is baked in, so the run comes out the same every time.

04

Triggers

A trigger fires a target action automatically when a source condition is met, turning the pane into a lightweight event-automation system rather than a command palette.

Peer-activity triggers react to traffic on the bus. Match on any activity, or build clause groups — evaluated as OR across groups and AND within a group — where each clause tests the OSDP type code, the PD index, or a path inside the decoded payload against an expected value. A clause set can even be seeded from an observed packet.

Interval triggers fire on a timer instead, at a fixed period or randomly within a window. Every trigger has its own enabled or disabled state, controlled right from its card.

05

Drag-sortable action cards

Every saved action shows up as a card in a reorderable grid, badged with its action kind and emulator mode, with edit and delete controls and a clear run-state or trigger-state indicator.

Run any non-trigger action with one click, or flip a trigger between enabled and disabled in place. Drag cards to reorder them so your most-used actions stay at the front of the pane, and active or executing actions lock against conflicting edits and duplicate runs.

06

Import and export

The whole emulator UI configuration — your action library included — exports to JSON and imports back in a single step, so a known-good action set loads in seconds instead of being rebuilt from scratch.

That makes action libraries portable across sessions, machines, teams, and test environments, and easy to keep under version control alongside the profiles they exercise.

FAQ

We get these questions a lot

Is the OSDP simulator the same as an OSDP emulator?

It is often searched for as an OSDP simulator, but strictly speaking it is an OSDP emulator. Emulator Workspace stands in for real hardware — a control panel (CP) or peripheral device (PD) — and speaks the real OSDP protocol over the RS-485 bus, so a live peer treats it as genuine hardware rather than a model of one. "Simulator" is the common label; "emulator" is the accurate term, because the software is interchangeable with a real device on the wire.

Can I test a reader without a real OSDP controller?

Yes. Emulator Workspace stands in as the Control Panel (CP) so you can drive and validate a physical PD or reader with no real controller on the bus — or emulate a PD to test your controller. Either side can be the software peer.

Can the OSDP emulator run secure channel?

Yes. It negotiates the OSDP secure channel with full SCBK and SCBK-D handling, so you can exercise encrypted sessions and install-key fallback against a peer you fully configure.

Can I automate OSDP test sequences?

Action cards turn any OSDP command or event into a reusable building block you can repeat on a cadence, chain into sequences, or fire from triggers — automating protocol behavior instead of typing commands.

Have a question? Ask us →

Related OSDP Tools

Explore the rest of the toolkit

OSDP Protocol Analyzer

Sniff a live RS-485 bus and decode every OSDP command and reply.

OSDP Provisioning Tool

Set address and baud, then key the SCBK secure channel in install mode.

OSDP Conformance Testing

Run semi-automated conformance tests and produce repeatable reports.

Hardware

Choose your Osprio hardware

Osprio Pro

Run Emulator Workspace on battery-backed field hardware that carries every Osprio View workspace in one firmware image.

Osprio Mini

Switch into the emulator firmware app on compact bench hardware for focused simulation and validation work.