Documentation

Conformance Workspace

Conformance Workspace is the semi-automated OSDP conformance and verification workflow in Osprio View. It drives a device under test — a peripheral (PD) or an access control unit (ACU) — through a chosen suite of checks on a two-unit bench, records the bus evidence behind every result, and produces a report you can archive and export. Each run is saved to your account so you can revisit or export it later.

Workspace story ​

Conformance Workspace is a five-step flow, shown as a stepper across the top of the run:

  1. Device — describe the device under test
  2. Plan — choose which tests to run
  3. Bench — assign the two Osprio Mini units
  4. Execute — run the plan and answer any operator prompts
  5. Report — review, then export the result

A separate landing screen (OsprioView Conformance) is the home for the workspace: it holds your saved runs and the New conformance run button. Opening a saved run jumps straight to its report in read-only mode.

Unlike the other workspaces, a conformance run needs two connected devices at once and requires you to be signed in.

What this workspace owns ​

Conformance Workspace owns the conformance-run UX:

  • signing in and listing, opening, and deleting account-saved runs
  • capturing the device-under-test profile and the tester's identity
  • selecting tests from the OSDP conformance catalog and ordering them for minimal operator intervention
  • assigning the conformer and capture roles to two Osprio Mini units
  • running the plan — the whole suite or a single test — in attended or unattended mode
  • prompting the operator for manual steps and recording their answers
  • adjudicating each test against the spec from captured bus evidence
  • presenting and exporting the conformance report

USB transport ownership, cross-tab exclusivity, device leasing, and firmware flashing remain in the shared managers. The tests themselves come from a shared, versioned conformance catalog rather than being hard-coded in the workspace.

Before you start ​

Sign in ​

A sign-in is required to run conformance tests. On the landing screen, an unauthenticated user sees a Sign in to continue button instead of the run UI:

A sign-in is required to run conformance tests. Your runs are saved to your account so you can revisit and export them later.

Every completed run is saved to your account — the device profile, the selected tests, the per-test results, the captured evidence, and the device assignments — so you can reopen it later or export it. Your operator identity (name and company) is stored on your profile and reused across runs.

Hardware: the two-Mini bench ​

A conformance run uses two Osprio Mini units on the same RS-485 multidrop bus:

  • one Mini runs the Conformer app and drives the run — it issues OSDP commands to the DUT (or answers it) and its results are judged against the spec
  • one Mini runs the Capture app and passively records every frame on the bus, supplying the byte-level evidence attached to each test

Flash the driving unit to the Conformer app in App Switcher Workspace first; the second unit stays on the Capture app. The bus is a standard two-terminator RS-485 segment (120 Ω at each end) with the DUT tapped in alongside the two Minis. The independent capture unit is what keeps the evidence trustworthy — the unit generating traffic is not also the sole judge of what happened on the wire.

The stepper and configuration lock ​

The stepper shows Device, Plan, Bench, Execute, and Report. A step only unlocks once its prerequisites are met: Plan needs a valid DUT, Bench needs at least one selected test, and Execute/Report need a ready bench.

A progress pill on the right tracks the run: No DUT → DUT configured → Test plan created → Bench configured → Execution in progress → Executed.

Once execution begins and any test has a result, the Device, Plan, and Bench steps become read-only:

Configuration is locked once execution begins — reset the run on the Execute page to make changes.

Resetting the run on the Execute step clears all results and unlocks configuration again.

Stage 1: Describe the device under test ​

The Device step (Device under test) captures everything that appears on the final report exactly as typed, so it is worth double-checking.

Device type ​

Choose what you are testing:

  • Peripheral Device (PD) — a reader, keypad, or I/O peripheral. The workspace drives it as the controller (ACU) and evaluates its replies.
  • Access Control Unit (ACU) — the controller or panel (CP). The workspace acts as a peripheral on the bus and evaluates the commands the ACU issues.

Switching the type clears any selected tests, because the catalog role changes with it.

Device identity ​

Both types capture:

  • Manufacturer (required)
  • Model (required)
  • Firmware version (required)
  • Serial number (optional)

Secure channel and baseline — ACU only ​

The PD and ACU setups differ because of who configures the secure channel:

  • For a PD DUT, the conformer assigns the address, baud rate, and SCBK to the peripheral over the broadcast channel during the run, so you do not enter a key or confirm a baseline.
  • For an ACU DUT, you configure the panel yourself, so two extra steps appear:
    • Secure channel key (SCBK) — a 32-hex-character key, with Randomize SCBK and Copy SCBK helpers.
    • Confirm the DUT baseline — a required checkbox stating that you have configured the ACU to talk to a PD at the given address, baud, and SCBK. This confirmation re-arms itself whenever the address, baud, or key changes, so a stale baseline can never be carried forward.

Tested by ​

The operator identity is required and appears on the report:

  • First name
  • Last name
  • Affiliation / company

These fields are saved to your profile; already-set fields show read-only with an Edit in profile link.

When the required fields are complete, Continue to plan advances to the next step.

Stage 2: Build the test plan ​

The Plan step is split into a Test pool on the left and a Run plan panel on the right.

The catalog ​

Tests come from a shared, versioned OSDP conformance catalog — 119 entries across 14 suites, of which 93 are active (selectable) and 20 of those are manual (operator-adjudicated). The rest are informational note or disabled rows shown greyed-out for reference. The catalog is informed by the SIA OSDP test matrix and extended by the Osprio team.

Suites are filtered by DUT role:

  • PD DUT — 8 suites: physical / data-link / framing, commands and status, NAK and error handling, reader output (LED / buzzer / text / card / keypad), COMSET and comms, secure channel, file transfer, and biometrics / PIV / manufacturer extensions.
  • ACU DUT — 6 suites: link-layer framing, commands observed, fault and response injection, secure channel, file transfer, and manufacturer / PIV extensions.

Selecting tests ​

The test pool groups tests by suite. You can:

  • search by id, title, summary, or tag (Search tests, e.g. SCBK, osdp_LED, baud…)
  • filter by All, Auto, or Manual
  • add or remove a whole suite with its Add all / Remove all toggle, or pick individual tests

Each test row shows its OCT_* id, title, an Auto or Manual chip, and metadata badges such as ambient (arises from normal traffic), needs SC / needs no SC, fresh session, and destructive (voids the DUT baseline).

The run plan ​

The Run plan panel summarizes the selection: the total tests selected, split into automated and manual counts, per-suite bars, and an estimated duration. It also lists Quick plans presets, including Full conformance — all {N}, Unattended — no operator steps ({n}), and Required only ({n}).

Tests always run in a minimal-intervention order rather than catalog order: tests are grouped so that session state (fresh session, secure channel) is set up as few times as possible, and every destructive test is pushed to the very end so at most one baseline restore is needed. An expandable Predicted operator interventions list previews the manual steps a run will ask for — computed from the catalog without touching the bus.

Select devices moves on to the bench.

Stage 3: Set up the bench ​

The Bench step (Bench setup) is where you assign the two Minis. It draws a signal-path schematic — tester → Osprio View → USB → the two Minis on a terminated RS-485 bus → the DUT — so the topology is explicit.

There are two roles:

  • Conformer device — "Drives the conformance sequence — issues OSDP commands to the DUT and evaluates replies against the spec."
  • Capture device — "Passively captures every frame on the RS-485 bus. Supplies the byte-level evidence attached to each test."

Each role lists the eligible connected devices. If none are available, the empty state tells you what to do:

  • Conformer: "Flash the Conformer app onto an Osprio Mini in App Switcher, then connect it."
  • Capture: "Connect an Osprio device running the Capture app to capture the bus."

Click a device to assign it; it takes a cross-tab lease for that role and shows an Assigned badge with an Unassign option. A device already in use in another tab is disabled. When both roles are set, the footer reads Bench ready — {conformer} driving, {capture} capturing and Continue advances to execution. Running with a conformer but no live capture device is allowed but discouraged — capture-based checks go inconclusive without bus evidence.

Stage 4: Execute the plan ​

The Execute step runs the plan. The header offers Start run, then Pause (which stops cleanly at the next test boundary) and Resume, plus a Reset that clears all results. Live counters track pass / fail / n-a / inconclusive and {done}/{total}, and two pills show the assigned conformer and capture serials.

Whole suite or a single test ​

Start run drives the entire plan in minimal-intervention order. Alternatively, select any test in the run queue and use Run test (or Re-run once it has a result) to run just that one — useful while iterating on a fix.

Automated vs manual tests ​

Every test is either:

  • Automated (Auto) — the host runs the steps, evaluates the expectations, and records the verdict without supervision. This is what makes unattended runs and CI-style re-checks practical; the Unattended preset selects exactly the automated tests that need no operator action.
  • Manual (Manual) — the operator's answers determine the verdict, so execution pauses and opens the manual wizard (see below).

Firmware primitives return facts only; the host does the judging, so a run is a repeatable procedure rather than a pile of ad-hoc commands. Internally each test moves through an arrange → exercise → observe → adjudicate lifecycle, surfaced as live phase labels (Preconditions, Running, Waiting, Evidence, Finalizing).

Verdicts ​

Each test resolves to one of:

  • Pass — the check held.
  • Fail — the check did not hold. A fail is sticky: a later pass cannot silently overwrite it without an explicit re-run.
  • N/A — the test was skipped, either marked not-applicable by the operator or blocked by an unmet precondition.
  • Inconclusive — the evidence was insufficient (for example a capture gap), so the result is deliberately neither pass nor fail.
  • Untested — never run.

When every planned test reaches a terminal verdict, the header shows Run complete and a View report → button.

Manual (operator) steps ​

When execution reaches a step that needs a person at the bench, the test enters a waiting state and a wizard opens: Manual test · operator action required. It shows the test id, title, summary, the expected outcome, and a destructive warning where relevant, plus step-by-step progress.

Steps come in a few kinds:

  • DUT stimulus — an action the DUT side must perform, shown verbatim (for example "Present the configured credential at the reader now." or "Make your ACU sound the reader buzzer (osdp_BUZ) now."). Confirm with Done — continue.
  • Do this — a plain instruction to complete, then continue.
  • Confirm — a yes/no question (for example "Did the LED show the commanded colour/pattern?") answered with Yes / No.
  • Answer — a free-text response, optionally checked against an expected value.
  • Your verdict — a direct Pass / Fail decision.

Every prompt also offers Mark N/A & skip and Pause run. The operator's answers are recorded with timestamps, fed back to the adjudicator to decide the verdict, and shown later in the report as Operator confirmations.

Stage 5: The report ​

The Report step (Conformance report) is the deliverable. Its header restates the DUT, firmware, serial, generation time, and Tested by {name} · {company}.

It contains:

  • a hero verdict — PASS, FAIL, or an Incomplete tag — where fail wins if anything failed, a run with pending or inconclusive tests reads incomplete, and pass requires at least one real pass
  • stat tiles — passed, failed, n-a, inconclusive, and pass rate
  • a rollup by family — per-suite cards with a stacked result bar and a Pass / Fail / Partial badge
  • all results — an expandable list where each test shows its timing (start, finish, duration), summary, expected vs actual outcome, any operator confirmations, and the evidence: the specific captured packets the adjudicator selected (hex bytes with direction), backed by the full archived bus capture

Exporting and revisiting ​

Export report downloads the run as a JSON file (conformance-<model>.json) containing the DUT profile, the overall verdict, the counts, and every per-test result. The run is also auto-saved to your account and reopens read-only (Saved run · read-only) from the landing screen. "Signed-off" here means the report is attributed to the operator identity and archived — it is not a cryptographic signature, and the workspace does not itself grant OSDP Verified certification.

Terminology ​

  • Run — one end-to-end conformance session against a DUT; the saved unit is a conformance run.
  • DUT (device under test) — the peripheral (PD, shown as Peripheral) or controller (ACU) being tested.
  • Bench — the two-Mini rig on a shared, terminated RS-485 bus.
  • Conformer — the Mini that drives the run and whose results are judged. Runs the Conformer app.
  • Capture — the Mini that passively records the bus as evidence. Runs the Capture app.
  • Suite / family — a group of related tests; called a suite in the pool and a family in the report rollup.
  • Automated vs manual — host-adjudicated (unattended-capable) vs operator-adjudicated (attended) tests.
  • Destructive — a test that voids the DUT baseline and forces an operator restore; these run last.
  • SCBK — the 16-byte Secure Channel Base Key, entered as 32 hex characters (ACU DUT only).
  • Evidence vs full capture — the specific packets the adjudicator selected for a verdict, versus the complete archived bus trace behind them.