Compliance claims become repeatable evidence
Conformance Workspace is the Osprio View tool for semi-automated OSDP conformance testing and interoperability verification. Drive a structured test plan against a peripheral (PD) or controller (ACU) at your desk and take away a detailed report of exactly how it behaved — command by command, down to the physical layer — to qualify a device in CI and ease the path to SIA OSDP Verified.
A conformance run is split across three responsibilities on a shared RS-485 bus. Osprio View orchestrates the whole thing from your host; a first Osprio Mini plays the opposite role to your device under test and actively exercises it; a second Osprio Mini does nothing but listen, so the evidence behind every verdict comes from an independent witness rather than the device that generated the traffic.
Osprio View owns the run end to end: it walks the plan, tells the conformer what to do at each step, and gates progress on the results. When a step completes it reads the captured bus trace, checks the exact bytes and their timing on the wire against what the spec requires, and records a pass, fail, or not-applicable — then rolls it all into the report.
One Osprio Mini stands in as the counterpart your device expects to talk to — an ACU when you are testing a PD, a PD when you are testing an ACU. The host drives it to issue commands, provoke edge cases, and inject faults, so the DUT is exercised by a controlled peer whose behaviour is known exactly.
A second Osprio Mini sits silently on the same bus and records every frame in both directions. Because it never transmits, the timing and byte-level evidence it collects is impartial — the unit generating the traffic is not also the sole judge of what landed on the wire, which is what makes a verdict defensible.
Every test in the catalogue runs the same four stages, whether it is fully automated or needs an operator at the device. That uniformity is the point: a result is only worth something if the conditions that produced it are declared up front and the same run repeats identically next week, on someone else's bench, against a later firmware build.
The executor sets up the test's preconditions — capabilities present, secure channel up or down, session freshly baselined. A DUT that can't meet them is skipped as not-applicable, not failed.
The conformer runs the procedure — issuing commands, arming replies, injecting faults, or prompting an operator for a physical action at the reader. Every step is declared up front, so the same run repeats identically tomorrow.
The capture unit records every frame on the bus while the procedure runs. The evidence behind a verdict comes from an independent witness, not from the unit that generated the traffic.
The host — not the firmware — checks the captured evidence against the expectation the test declares. Without conclusive proof the verdict is inconclusive, never a pass.
"Vendor says it's compliant" is not a test result. Conformance Workspace turns that claim into something you can reproduce, measure, and disagree with — early, on your own bench and in CI — so issues surface while they're still cheap to fix. Here's what it does.
Point the workspace at either side of the bus. When your device under test is a peripheral (PD), the conformer stands in as the controlling ACU and drives it; when it is a controller (ACU), the conformer plays the PD and answers it — so the same tool qualifies readers and controllers alike.
Declare the device once — manufacturer, model, address, firmware — and the workspace tailors the plan and the setup steps to what you are actually testing, then carries that identity through to the saved report.
Prepare the test topology right in the UI. Conformance runs on two Osprio Mini units on the same RS-485 bus: one takes the conformer role and drives the exchange, while the other sits in capture mode and passively records every frame.
That independent capture unit is what makes the results trustworthy — the device generating the traffic is not also the sole judge of what happened on the wire, so the timing and framing evidence stands on its own.
Select a plan, then let the executor work through it — pausing for you only where a check genuinely needs a person at the device. Every test it can draw on is published in full further down this page.
Kick off the whole plan and let the executor work through it, or drill into any one test and run it on its own while you iterate on a fix. Each check lands as pass, fail, or not-applicable against the OSDP spec, with the actual reply bytes captured alongside the expectation.
Because a plan is a structured, repeatable procedure rather than a pile of ad-hoc commands, the same run you step through at the bench doubles as a regression guard — re-run it on every firmware build to catch a conformance regression the moment it appears.
Some checks touch the physical world — present a card, trip a tamper, confirm an LED or buzzer fired. When a test needs a person at the device, execution pauses and a prompt spells out exactly what to do, then waits for the operator before grading the result and moving on.
Human-in-the-loop checks live in the same recorded plan as the automated ones, so nothing that requires an operator quietly falls out of coverage.
Every run produces a detailed, signed-off report: per-command results with the bytes that were exchanged, a physical-layer summary of turnaround and timing, and an ordered audit trail of exactly how the device behaved, step by step.
The packet capture behind each verdict travels with the report as evidence, and the whole thing is saved to your account to revisit or export — a self-contained artifact you can archive, compare across builds, or hand to a customer or auditor.
Each run produces a detailed conformance report that records how the device behaved against the OSDP command set and the physical-layer expectations — to gauge a device's readiness, compare candidates side by side, or attach to an internal interop deliverable.
Each command-level check lands as pass, fail, or partial, with the actual reply bytes captured against the expectation — so an engineer sees exactly how the device diverged from the spec, not merely that it failed.
Turnaround and timing metrics roll up alongside the command-level checks, so one report covers protocol behaviour and bus behaviour — and a device that answers correctly but too slowly shows up as exactly that.
An ordered record of every scenario the plan ran and how the device answered each one, so you can revisit its behaviour in a specific situation later, not just whether it passed overall.
Export it for a customer, integrator, or auditor. Every run is structured the same way, so a recipient can compare two devices without re-learning the format each time.
Runs draw on a deep catalogue of checks organised into suites — link-layer framing, command and status handling, NAK and error behaviour, reader outputs, COMSET, secure channel, file transfer, and the manufacturer and PIV extensions. Nothing is hidden behind a run: every test below declares its preconditions, its exact procedure, and the expectation the verdict is judged against. You are never forced to run all of it — pick the suites and individual tests that matter for this device or this build.
This catalogue is published while it is still being built. The internal DSL we use to describe a test is evolving quickly, and both the set of cases and the way each one is exercised move with it.
Read it as an accurate account of what we test today, not as a stable specification to build against. Test identifiers, preconditions, procedures, and expected outcomes may be added, renamed, re-scoped, or withdrawn at any point — with no version bump and no deprecation notice. Nothing here is fixed until it is formalised.
No tests match your search
The "envelope" layer: is the PD speaking clean OSDP on the wire? Correct wiring, baud, framing, CRC. Ordinary polling traffic already proves almost all of it — once the Driver (as CP) has exchanged eight conforming frames, the baseline link-layer requirements are satisfied without any separate stimulus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
At least 8 conforming OSDP frames observed on the bus.
Changes persistent DUT state, so it is scheduled last and the operator is warned before it runs.
The osdp_COM reply, then the ACK/PDID/COM poll reply at the new speed.
This does not claim every one of the 256 byte values survives the link — only that the values most likely to be mistaken for framing do, in one frame, without desynchronising the reader. A PD that treats one of them as a delimiter, an escape, or a resync signal fails here: either the vendor message itself fails its checksum, or the reader is no longer in step on the poll that follows.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A frame carrying the chosen boundary bytes, and a healthy exchange after it.
A reader slow to reply holds up every other device on the shared bus, which is why the 200 ms window is measured on the reply itself, whatever code it carries.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The time between the poll leaving the wire and the reader's reply arriving.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A CRC-valid OSDP frame observed on the bus.
Messages can be as large as 1440 bytes, and a reader must cope with one that big — either acting on it or refusing it cleanly. What it must not do is overrun its own buffer, which typically leaves the device unresponsive rather than merely wrong.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The reader's answer to a maximum-length message, and a healthy exchange after it.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
At least 8 conforming OSDP frames observed on the bus.
A freshly baselined session, so the sequence number restarts at 0.
A frame carrying sequence 0 observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
At least 8 conforming OSDP frames observed on the bus.
A reader that answers to another device's address makes the shared bus unusable.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Silence when another reader's address was polled, and a reply when its own was.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
At least 8 conforming OSDP frames observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
At least 8 conforming OSDP frames observed on the bus.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. An established secure channel — the executor handshakes first if one is not already up.
A frame carrying a security block observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACK/NAK/PDID/PDCAP/LSTATR/ISTATR/OSTATR/RSTATR/RAW/KEYPAD/COM/BUSY reply observed on the bus.
A PD reply outside the valid reply set is a failure.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACK/NAK/PDID/PDCAP/LSTATR/ISTATR/OSTATR/RSTATR/RAW/KEYPAD/COM/BUSY reply observed on the bus.
Caveat: a bad checksum is tolerated, not failed.
DUT must advertise the check character capability; otherwise the test is skipped as N/A.
A CRC-valid OSDP frame observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A CRC-valid OSDP frame observed on the bus.
Kept as a disabled placeholder, not deleted, so a reader does not go looking for a bad-CRC-reply test in the PD-DUT framing suite and wonder if it was missed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
This id's title and summary claimed the ACU must detect a corrupted PD reply, but its mechanism can only corrupt the frame the Driver-as-CP is about to send — flipping the CRC ahead of its own outgoing osdp_POLL, never the real PD's reply, which this harness does not control. So what ran here was the PD's handling of a garbled command, precisely what OCT_PERR_06 already tests with a real assertion (a NAK carrying BAD_CHECKSUM, or a conformant silent discard). The claim this id's title makes — an ACU rejecting a corrupted PD reply — is verified from the role that can actually produce it, in the ACU-DUT suite as OCT_ALNK_08.
Covered by OCT_PERR_06, OCT_ALNK_08
The config address accepts only the few commands needed to identify and configure a device.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The identity reply, given when the reader was addressed on the setup address.
Pass on successful transmission of the rogue poll.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The stimulus frame was transmitted on the wire (pass on successful send).
This is what makes firmware updates over OSDP possible; see the file-transfer suite for the end-to-end test.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Splitting and reassembling an oversized payload is exercised end to end by the file transfer tests, which cannot pass unless it works. Testing it separately would assert the same thing twice.
Covered by OCT_PFT_01
The everyday OSDP conversation: the Driver (as CP) issues each mandatory command — POLL / ID / CAP / LSTAT / ISTAT / OSTAT / RSTAT / OUT / ACURXSIZE — and checks the PD's reply structure and content. Each command passes once it has been sent and the PD answers sensibly; the paired reply check confirms the reply itself is well-formed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACK/LSTATR/ISTATR/OSTATR/RSTATR/RAW/FMT/KEYPAD reply observed on the bus, within the reply window.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACK reply observed on the bus.
A valid PDID passes; an all-zero manufacturer OUI, or a NAK to the ID request, is a failure. A valid PDID also confirms the reader is responding correctly at the current signalling speed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The PDID reply observed on the bus.
A per-capability record is produced for each capability the PDCAP reports; those values set context used by later tests (e.g. secure-channel tests are disabled if the PD reports no secure-channel support).
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The PDCAP reply observed on the bus.
A well-formed LSTATR satisfies the local-status check — the reader answers the request with a standards-conformant reply.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The LSTATR reply observed on the bus.
A well-formed ISTATR satisfies the input-status check. If the PD advertised inputs but NAKs the ISTAT request, that is a failure.
DUT must advertise the contact status monitoring capability; otherwise the test is skipped as N/A.
The ISTATR reply observed on the bus.
A well-formed OSTATR satisfies the output-status check. A NAK to OSTAT when outputs were advertised is a failure.
DUT must advertise the output control capability; otherwise the test is skipped as N/A.
The OSTATR reply observed on the bus.
The command send is automated; the physical actuation is confirmed manually.
DUT must advertise the output control capability; otherwise the test is skipped as N/A.
Operator confirms: Did the relay/output physically actuate per the commanded control code and timer?
A well-formed RSTATR satisfies the reader-status check. Because RSTAT is deprecated, a NAK is tolerated rather than treated as a failure.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The RSTATR/NAK reply observed on the bus.
Automated on send; a NAK is a failure.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACK reply observed on the bus.
Confirms ISTATR to ISTAT when inputs are advertised.
DUT must advertise the contact status monitoring capability; otherwise the test is skipped as N/A.
The ISTATR reply observed on the bus for a PD with supervised inputs.
Checks the PD's NAK replies: whether it produces a well-formed NAK with a valid reason code when it should, and — the audit-critical part — whether a NAK on a command tied to an advertised capability is treated as invalidating that capability claim, rather than brushed aside as a one-off failure.
Automated, unconditional on any NAK. Trigger may also be passive, or induce-NAK to force one. Reason 0 is not a defined NAK reason (see OCT_PERR_03) and fails this check like any other undefined value.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A well-formed NAK carrying one of the defined reason codes, observed on the bus.
Zero is not one of the defined rejection reasons — it is the code that means "no error". A reader that rejects a command while claiming nothing went wrong leaves the controller with no way to react, so this checks it never does.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The rejection carried a real reason code, not the reserved zero.
When a reader rejects a command it says why, using a numbered reason. A conforming reader picks the reason that actually matches the error rather than a catch-all.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
This entry is the index of the reason-code family rather than a test of its own; each individual reason code is checked by its own test.
Covered by OCT_PERR_06, OCT_PERR_07, OCT_PERR_08, OCT_PERR_09, OCT_PERR_10, OCT_PERR_11, OCT_PERR_12, OCT_PERR_13, OCT_PERR_14, OCT_PERR_15, OCT_PERR_16
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A NAK with reason BAD_CHECKSUM (or a conformant silent discard) on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A NAK with reason CMD_LENGTH (or a conformant silent discard) on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A NAK with reason UNKNOWN_COMMAND on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A NAK with reason SEQUENCE on the bus.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A.
A NAK with reason SC_COND on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A NAK with reason SC_UNSUP on the bus.
Enable once a cleartext-in-secure-context stimulus is available. Expect NAK reason SC_COND.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Provoking this needs the test runner to send an unencrypted command to a reader that is enforcing encryption — a stimulus it cannot produce yet.
Enable once BIOREAD stimulus params are modelled. Expect NAK reason BIO_TYPE.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Provoking this needs the test runner to ask for a specific biometric type and template format, which it cannot yet express.
Enable once BIOREAD stimulus params are modelled. Expect NAK reason BIO_FORMAT.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Provoking this needs the test runner to ask for a specific biometric type and template format, which it cannot yet express.
Enable once an invalid-record stimulus is modelled. Expect NAK reason CANNOT_PROCESS.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
What counts as an unusable command record differs by reader, so no single stimulus provokes this reliably on an arbitrary device.
Informational; a PD may use GENERIC for unspecified errors. Expect nak reason GENERIC when seen.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
This is the catch-all a reader may use for anything the numbered reasons do not cover. Nothing can force it on demand, so it is recorded when seen rather than tested for.
The PD's human-facing outputs (LED, buzzer, text display) and inputs (card read, keypad). Outputs can't be verified by a bus sniffer, so the Driver sends the command and a human confirms what actually happened at the reader — those tests are manual. Inputs are different: the credential or keys are presented (by a person, or by the engine when it controls the DUT), and the resulting osdp_RAW / osdp_KEYPAD reply on the bus is what's checked, so the card-read and keypad tests are automated.
DUT must advertise the led capability; otherwise the test is skipped as N/A.
Operator confirms: Did the LED show the commanded colour/pattern?
Red and green have dedicated confirmation steps; other colours use the generic operator confirm. A NAK to an LED command fails that colour.
DUT must advertise the led capability; otherwise the test is skipped as N/A.
Operator confirms: Did the LED display exactly the commanded colour?
DUT must advertise the audible output capability; otherwise the test is skipped as N/A.
Operator confirms: Did the buzzer sound with the commanded on/off/repeat pattern?
A NAK to the TEXT command is a failure. A max-length text variant also exercises the packet-size path (see 01-link-layer-framing.yaml).
DUT must advertise the text output capability; otherwise the test is skipped as N/A.
Operator confirms: Did the commanded text appear correctly on the display?
DUT must advertise the card data format capability; otherwise the test is skipped as N/A.
The osdp_RAW credential report observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The osdp_KEYPAD report observed on the bus.
Changing the PD's address / baud via osdp_COMSET and validating the osdp_COM reply. The PD must reply at its old settings, switch to the new ones, echo the change in an osdp_COM reply, and come back reachable at the new address/speed. Includes a robustness case: a garbage baud must be rejected, not bricked onto the bus.
A successful COMSET is confirmed by the returned osdp_COM, which verifies both the reconfiguration and the new signalling speed.
Changes persistent DUT state, so it is scheduled last and the operator is warned before it runs.
The COM reply observed on the bus.
COMSET is 1-to-1 (single PD, no collision), so the PD replies osdp_COM at its old settings and then applies the change. The returned osdp_COM confirms the reconfiguration; the follow-up poll at the new baud confirms the new signalling speed.
Changes persistent DUT state, so it is scheduled last and the operator is warned before it runs.
The osdp_COM reply at the old baud plus the follow-up poll reply at the new speed.
Sending the bad COMSET is automated; whether the PD correctly rejected it is for the operator to confirm by watching its response, or the absence of a speed change.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the PD reject/ignore the bad COMSET and stay reachable at its current speed (did not switch to a garbage rate or drop off the bus)?
The Driver-as-CP drives the OSDP Secure Channel handshake (CHLNG / CCRYPT / SCRYPT / RMAC_I) and validates the PD's AES-128 crypto replies. This is where the checks are the most exacting: cryptograms must decrypt to the expected random values, the cUID must be non-zero, and key install / paired-key / rotation are exercised.
Reaching CCRYPT confirms the challenge step; the CCRYPT itself passes only when the secure-channel state, key, and client cryptogram over RND.A are all correct, and fails on an all-zero cUID, wrong state, key mismatch, or RND.A mismatch. Negative cases arm a fault intent and expect the channel to stay down.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
The secure-channel handshake exchange observed on the bus.
RMAC-I completes the handshake and the channel becomes operational; the accepted status octet depends on the OSDP edition (IEC 60839 vs OSDP 2.2), and a pre-edition device fails. A later MAC mismatch silently resets the channel. Injecting a bad RMAC-I is an ACU-DUT test.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
The secure-channel handshake exchange observed on the bus.
This passes when the PD ACKs the KEYSET. A NAK is a failure. Whether a subsequent handshake actually succeeds under the new key is not checked here — see OCT_PSC_05.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. An established secure channel — the executor handshakes first if one is not already up. Changes persistent DUT state, so it is scheduled last and the operator is warned before it runs.
The ACK reply observed on the bus.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
The secure-channel handshake exchange observed on the bus.
Security policy usually requires the encryption key to be changed periodically. A reader must accept a new key while running and come back up encrypted under it — otherwise rotating keys means physically revisiting every door. osdp_KEYSET is itself only ever sent once the channel is already secure, so this test first establishes that channel on the key the session started with, then changes the reader's key, then puts the original back before it finishes.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG. Changes persistent DUT state, so it is scheduled last and the operator is warned before it runs.
The entry key's channel established, the new key accepted, a fresh encrypted session established under it, and the original key restored.
The Driver-as-CP pushes a file to the PD via osdp_FILETRANSFER fragments and validates the PD's osdp_FTSTAT progress replies, exercising the multipart / large-data machinery including inter-fragment and final delays. The supporting ACURXSIZE and KEEPACTIVE commands advertise the ACU buffer size and hold the session open during long transfers.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The FTSTAT reply observed on the bus.
A reader that needs time — to write a page of firmware, say — can ask the controller to wait before sending the next chunk, so a fast controller does not overrun a slow reader.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Only the reader can request this pause, so it cannot be provoked when the reader is the device under test. The same behaviour is verified from the controller side, where the test rig plays the reader and requests the pause itself.
Covered by OCT_AFT_02
At the end of a transfer the reader reports the file received and asks for time to finish the job — commit the firmware, restart — before the controller treats the transfer as done.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Only the reader can signal this final pause, so it cannot be provoked when the reader is the device under test. It is verified from the controller side instead, with an operator confirming that the controller waited before treating the transfer as complete.
Covered by OCT_AFT_03
No procedure is defined for this entry yet — it is catalogued so the coverage gap stays visible.
A reader must recover cleanly when the controller abandons a transfer part-way through, rather than stalling while it waits for fragments that will never arrive.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Cancelling a transfer part-way needs a control the test runner does not expose yet.
Automated on send; a NAK is a failure.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACK reply observed on the bus.
The advanced/optional reader families, all conditional on special hardware or a manufacturer feature: biometric capture/match, PIV data and cryptographic authentication (GENAUTH/CRAUTH, some card-triggered), manufacturer-specific commands (MFG), and extended/transparent smart-card mode (XWR/XRD). Checked on the response side — a well-formed reply passes, a NAK to an advertised feature fails.
A NAK when biometrics are advertised is a failure.
DUT must advertise the biometrics capability; otherwise the test is skipped as N/A.
The BIOREADR reply observed on the bus.
A NAK is a failure.
DUT must advertise the biometrics capability; otherwise the test is skipped as N/A.
The BIOMATCHR reply observed on the bus.
A well-formed PIVDATAR satisfies the read. Checking the reply is automated; presenting the PIV card is manual.
DUT must advertise the smart card capability; otherwise the test is skipped as N/A.
The PIVDATAR reply observed on the bus.
A GENAUTHR within the maximum message size passes; an oversize response header fails.
DUT must advertise the smart card capability; otherwise the test is skipped as N/A.
On-device reply-size measurement, checked against the window in expect.
The GENAUTH is armed as the reaction to the next card read (RAW), so it fires in realistic card-read-then-authenticate order. Asserting on the raw binding requires that a real card-read report actually preceded the GENAUTH — without it, this would only be OCT_PEXT_04 sent from a different trigger.
DUT must advertise the smart card capability; otherwise the test is skipped as N/A.
The RAW card read that armed the reaction, then the GENAUTHR reply observed on the bus.
A CRAUTHR within the maximum message size passes; an oversize response header fails.
DUT must advertise the smart card capability; otherwise the test is skipped as N/A.
On-device reply-size measurement, checked against the window in expect.
The CRAUTH is armed as the reaction to the next card read (RAW). Asserting on the raw binding requires that a real card-read report actually preceded the CRAUTH — without it, this would only be OCT_PEXT_06 sent from a different trigger.
DUT must advertise the smart card capability; otherwise the test is skipped as N/A.
The RAW card read that armed the reaction, then the CRAUTHR reply observed on the bus.
Manual on pd-dut: a generic PD implements no real vendor command, so an MFGREP round-trip needs the operator to supply concrete MFG command details (vendor code + command id + expected reply) that the DUT's host handler answers. Headless runs skip it. An MFGREP with a success status confirms the round-trip.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The MFGREP reply observed on the bus.
The error counterpart of a vendor-specific reply: when the reader cannot carry out a vendor command, it answers with a vendor-defined error rather than staying silent.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
This error reply has to come from the reader, so it cannot be provoked when the reader is the device under test. It is verified from the controller side, where the test rig plays the reader and sends the error itself.
Covered by OCT_AEXT_02
Pass on successful send.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The stimulus frame was transmitted on the wire (pass on successful send).
Automated on send/receive: the XWR command is dispatched and the XRD response parsed.
DUT must advertise the smart card capability; otherwise the test is skipped as N/A.
The XRD reply observed on the bus.
Enable against a DUT whose vendor command set produces an MFGSTATR. Expect an MFGSTATR reply, distinct from the MFGERRR error path (OCT_PEXT_09).
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Which vendor command produces this status reply is specific to each manufacturer, so there is no stimulus that works against an arbitrary reader. This test can be pointed at a device whose vendor command set produces one.
Per-capability PDCAP coverage mirroring SIA OSDP-Verified group 05: for each capability function code the PD advertises, confirm it appears in a well-formed osdp_PDCAP reply. Each test is gated on its capability precondition, so it runs only when the DUT claims that function and is skipped (n/a) otherwise. The overall PDCAP structure is checked by OCT_PCMD_04; the behaviour behind LED / buzzer / text / card / secure-channel / biometrics / smart-card / receive-buffer / CRC capabilities is checked by the dedicated tests in the other suites. This suite adds the per-function advertisement checks SIA lists individually but that had no dedicated behaviour test.
DUT must advertise the contact status monitoring capability; otherwise the test is skipped as N/A.
A PDCAP reply advertising the contact-status-monitoring capability.
DUT must advertise the output control capability; otherwise the test is skipped as N/A.
A PDCAP reply advertising the output-control capability.
DUT must advertise the combined message size capability; otherwise the test is skipped as N/A.
A PDCAP reply advertising the largest-combined-message-size capability.
DUT must advertise the secure pin entry capability; otherwise the test is skipped as N/A.
A PDCAP reply advertising the secure-PIN-entry capability.
DUT must advertise the osdp version capability; otherwise the test is skipped as N/A.
A PDCAP reply advertising the OSDP-version capability.
Validates the ACU's link-layer fundamentals from the PD's position — correct signalling, valid framing — which ordinary polling traffic already proves once eight conforming frames have passed. Then injects abnormal PD replies (bad CRC, invalid reply code, oversize, missing) to probe the ACU's error handling; an operator watches the controller's reaction and confirms it recovered cleanly.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
At least 8 conforming OSDP frames observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A frame carrying sequence 0 observed on the bus.
Correct behaviour is unicast to the PD's assigned address, with 0x7F reserved for setup commands only.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Checking which address a controller used needs the test language to be able to match on a frame's address, which it cannot do yet.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. An established secure channel — the executor handshakes first if one is not already up.
A frame carrying a security block observed on the bus.
An unknown ACU command is a failure.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Absence of the defect frame(s) in the capture.
Caveat: a bad checksum is tolerated.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
A CRC-valid frame observed on the bus.
Kept as a disabled placeholder, not deleted, so a reader does not go looking for a bad-CRC-command test in the ACU suite and wonder if it was missed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
This requirement is the PD's, not the ACU's: a conforming ACU never sends a corrupt command, so nothing on the ACU side can provoke the behaviour this id names. The PD side can and does — a corrupt command is provoked and the Driver-as-CP's detection of it is verified as OCT_PERR_06 (PD-DUT). The opposite direction (a corrupt reply the ACU must reject) is verified in this suite as OCT_ALNK_08.
Covered by OCT_PERR_06, OCT_ALNK_08
A sequence number is state the ACU owns and increments itself; a suite cannot know in advance what value a retransmission will carry, only that it will repeat the value the rejected exchange used. That is what is checked here: two (or more) commands sharing one sequence number, in the window that opens right after the corrupted reply was staged. An ACU that instead moved on to the next sequence number would be showing it had accepted the corrupt reply.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's command frames in the window after the corrupted reply all carry the same sequence number, showing it retransmitted rather than advanced.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU reject/NAK or safely ignore the unknown reply code (no crash)?
A controller must survive a reply far larger than it expected — from a faulty device, or a hostile one — without overrunning its own buffer. Carrying on polling afterwards is the proof.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The controller went on polling normally after being handed an oversized reply.
Readers go quiet — a cable is pulled, a power supply fails. A controller must notice, keep trying, then set the reader aside and come back to it later, all without stalling the rest of the bus. This test silences the reader, watches the controller retry and give up, then lets the reader answer again and checks that normal polling resumes.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Repeated commands while the reader was silent, no reply among them, and normal traffic resuming once the reader answered again.
The flip side of the PD command tests: instead of sending commands, the PD confirms the ACU correctly issues each one (POLL, ID, CAP, status queries, LED/BUZ/TEXT, COMSET, ..). The Driver's PD persona auto-answers, so this is almost entirely passive observation — the ID request is the one command that can actually reject the ACU, NAKing a malformed id block type.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's POLL command observed on the bus.
Bad ID block type: a normal or extended ID request is answered with a PDID; any other block type is a failure and is NAKed as UNKNOWN_COMMAND.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's ID command observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's CAP command observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's LSTAT command observed on the bus.
DUT must advertise the contact status monitoring capability; otherwise the test is skipped as N/A.
The ACU's ISTAT command observed on the bus.
DUT must advertise the output control capability; otherwise the test is skipped as N/A.
The ACU's OSTAT command observed on the bus.
DUT must advertise the output control capability; otherwise the test is skipped as N/A.
The ACU's OUT command observed on the bus.
DUT must advertise the text output capability; otherwise the test is skipped as N/A.
The ACU's TEXT command observed on the bus.
DUT must advertise the led capability; otherwise the test is skipped as N/A.
The ACU's LED command observed on the bus.
DUT must advertise the audible output capability; otherwise the test is skipped as N/A.
The ACU's BUZ command observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's COMSET command observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's ACURXSIZE command observed on the bus.
The PD can answer with a MFGREP (see the manufacturer/PIV/extended command family).
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The ACU's MFG command observed on the bus.
Arms abnormal or event-driven PD replies — BUSY, NAK with a chosen reason, tamper/power/input status, card read, keypad entry — and observes how the ACU copes with the unhappy path. The BUSY test is the one case a capture alone can confirm; for the rest the Driver generates each event automatically, but a human judges the ACU's reaction from the trace.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The relevant OSDP frames observed on the bus.
The Driver emits the NAK; the ACU's reaction is observed. The specific reason codes are captured from the trace for the operator to judge, rather than checked automatically one by one.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU parse the NAK reason and react appropriately (retry / drop / re-key / re-sequence) rather than desyncing?
Event generation automated; ACU alarm reaction observed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU raise the appropriate tamper alarm/event?
Event generation automated; ACU reaction observed. (PD reporting Power=1 on first poll after boot).
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU consume the power status event (log / act on it)?
Event generation automated; ACU reaction observed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU consume the polled input status and act on it?
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU consume the local-status reply?
Event generation automated; the ACU's decode/grant decision is observed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU receive the RAW card data and decode it correctly (bits/format), making a sensible grant/deny decision?
No procedure is defined for this entry yet — it is catalogued so the coverage gap stays visible.
The whole feedback loop end to end: a card is presented, and the controller's decision comes back as light on the reader. Builds on the card read in OCT_AINJ_07.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Chaining a card read straight into an automatic LED response needs a reaction control the test runner does not expose yet.
Event generation automated; ACU consumption observed.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU consume the keypad input and act on it (e.g. PIN verification)?
The mirror image of the PD-side secure-channel tests — the ACU drives the CHLNG/SCRYPT/KEYSET handshake and the Driver-as-PD responds. One deliberate fault injection forces the final RMAC-I to report failure, to verify the ACU aborts or re-keys rather than trusting a failed handshake.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
The secure-channel handshake exchange observed on the bus.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
The secure-channel handshake exchange observed on the bus.
After a failing RMAC-I the ACU must not treat the channel as operational — proceeding anyway would mean trusting a session key it never verified.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
Operator confirms: Did the ACU refuse to treat the channel as operational (abort/re-key) rather than proceeding as if secure?
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A.
The expected frame observed on the bus.
A controller must be able to change the encryption key of a reader already in service and bring the encrypted channel straight back up, so that rotating keys across a site does not mean visiting every door.
DUT must advertise the secure channel capability; otherwise the test is skipped as N/A. No secure channel: the executor tears any existing session down so the handshake starts from a clean CHLNG.
The controller's new key observed on the bus, and a fresh encrypted handshake completing under it.
The controller side of file transfer (usually a firmware push) — the ACU streams osdp_FILETRANSFER fragments and the Driver-as-PD answers with osdp_FTSTAT, injecting abnormal delay/status values to exercise the ACU's file-transfer state machine and its obedience to pacing requests.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The expected frame observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU pause the requested time before sending the next fragment? Backed by a measured gap of at least the 500 ms delay that was injected.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the controller wait the requested time before treating the transfer as complete, rather than closing it out immediately once the reader said it was done?
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU react correctly to the non-OK status (retry/abort as specified) rather than pushing a broken update?
No procedure is defined for this entry yet — it is catalogued so the coverage gap stays visible.
The controller must clean up after a cancelled transfer — no hang, no half-applied firmware, and ready to start again.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Aborting a transfer part-way needs a control the test runner does not expose yet.
Optional families where the ACU issues manufacturer-specific, PIV/auth, or extended/transparent-mode commands and the Driver-as-PD answers. Mostly passive observation of the ACU driving the exchange, plus a couple of operator-armed reply types (MFGREP, MFGERRR).
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The expected frame observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Operator confirms: Did the ACU handle the manufacturer error reply gracefully (no hang / stuck state)?
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The expected frame observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The expected frame observed on the bus.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
The expected frame observed on the bus.
No procedure is defined for this entry yet — it is catalogued so the coverage gap stays visible.
A complete high-security door sequence: a card is presented, the reader reports it, the controller starts the PIV challenge, and the full authentication exchange runs — the three stages joined into the one flow a real installation performs.
None — the test is indifferent to session state and needs no declared capability. It runs anywhere in the plan.
Driving the card read, the PIV challenge and the authentication as one chained scenario needs an action-hook control the test runner does not expose yet.
Yes. The suite runs every scenario it can drive over the bus unattended, so the same plan fits into CI — re-check each firmware build and catch conformance regressions the moment they appear.
No. Conformance Workspace is an independent pre-certification and CI regression tool. It is not affiliated with SIA, and its reports do not grant OSDP Verified certification — they help you find issues before formal verification.
Two Osprio Mini units: one drives the device under test — a PD or an ACU — while the other independently monitors the bus for trustworthy timing, with no lab gear to buy.
Have a question? Ask us →
Sniff a live RS-485 bus and decode every OSDP command and reply.
Stand in as an ACU or PD and script tests against real readers and controllers.
Set address and baud, then key the SCBK secure channel in install mode.
The checks in the catalogue above are based on the public information the Security Industry Association (SIA) publishes about the OSDP Verified program — the documented test vectors and test cases that define what a Verified device has to demonstrate. We implement every vector and test case we can source, then layer our own engineers' tests on top for behaviour the published matrix does not reach. A clean run here is therefore a strong predictor of how a device will fare in formal verification.
Conformance Workspace is an independent pre-certification and CI regression-testing tool. Osprio is not affiliated with, endorsed by, or sponsored by the Security Industry Association (SIA). "OSDP" and "OSDP Verified" are programs and marks of SIA; SIA's OSDP Verified certification is a separate process carried out by SIA and runs orthogonally to this product.
The reports this workspace produces reflect your own testing and do not constitute, grant, or replace OSDP Verified certification. Its purpose is to help you validate a PD on your own bench and in CI — easing your way into the verification process and reducing the time-to-market delays that verification surprises can cause.