[bss-opensof] 07 Demo & Test Procedures
Repeatable demonstrations, acceptance tests, verification steps and expected results. Edition: BSS — OpenSOF (opensof.bss.dev).
- Start Here
- Demo and Test Index
- Foundational Tests
- Operational Workflows
- Track-to-Task Workflow
- OpenEyes Sensor Product Workflow
- OpenRF Spectrum Workflow
- OpenLVC and FlightGear Workflow
- Acceptance & Evidence
Start Here
Start Here
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Documentation structure and release scan |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Purpose
This book turns demonstrations into repeatable tests. Every procedure should state prerequisites, exact steps, expected results, evidence to capture and cleanup/reset actions.
Contents
| Section | What it contains |
|---|---|
| Foundational Tests | Platform, service, interface and dependency smoke tests. |
| Operational Workflows | Repeatable demonstrations that cross components and preserve evidence. |
| Acceptance & Evidence | API and release acceptance with expected/actual results. |
How to maintain this book
Generated sections are replaced from release evidence on each run. Put reviewed corrections, deployment-specific facts, links and decisions in the Maintainer Notes area below the generated block. Mark pages as reviewed only after testing them against the named distribution and release.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Demo and Test Index
Demo and Test Index
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference test catalog |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Demo/test catalog
| Procedure | Operational point | Primary capabilities |
|---|---|---|
| Platform Smoke Test | Core service and public-route readiness | All enabled editions |
| Track-to-Task Workflow | Collect, associate, collaborate and task | OpenTrack, OpenCOP, OpenTask, OpenBus |
| OpenEyes Sensor Product | Capture/upload, persist, display, associate and share imagery | OpenEyes, OpenFiles, OpenBus |
| OpenRF Spectrum Workflow | Edge processing and real-time spectrum product | OpenRF, SDR agent, OpenPNT |
| OpenLVC / FlightGear Workflow | Live/virtual track interoperability and tasking | OpenLVC, FlightGear, OpenTrack, OpenCOP |
| API Acceptance | Authentication, schema, error and policy behavior | Published REST/WebSocket interfaces |
| Release Acceptance | Full deployment gate and rollback decision | 0.15.1 |
Evidence package for every run
- Distribution/release version and source fingerprint.
- Date/time, tester, environment and participating devices/services.
- Configuration profile with secrets excluded.
- Exact test data/commands, screenshots or recordings, logs and correlation identifiers.
- Expected versus actual result, timing/quality measures and pass/fail rationale.
- Cleanup/reset completed and defects/tasks created.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Foundational Tests
Managed documentation for Foundational Tests.
Platform Smoke Test
Platform Smoke Test
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference smoke test plus detected health routes |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Objective
Prove the release is running, routed correctly, connected to required shared services and able to complete one representative transaction before a deeper demonstration.
Prerequisites
- Release activated and rollback target known.
- DNS/TLS and time synchronization healthy.
- Test user/service identities available without exposing credentials.
- Representative dependencies and test data available.
Candidate health routes
- No candidate health route detected; use verified local/public roots and primary APIs.
Procedure
- Record active release and service state.
- Verify local backend response on each enabled instance.
- Verify public HTTPS route for
opensof.bss.devand certificate. - Log in with a non-admin test user and verify expected edition/branding.
- Exercise one read and one authorized write operation.
- Verify the operation appears in the intended UI/API and audit/log trail.
- Review logs for new errors and measure response time.
Pass criteria
All intended services remain stable; public and local paths return expected results; authorization is correct; a representative transaction completes; and no critical error/security regression appears.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Operational Workflows
Managed documentation for Operational Workflows.
Track-to-Task Workflow
Track-to-Task Workflow
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference cross-component acceptance test |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Objective
Demonstrate the operational chain from track ingestion through visualization, semantic association, collaboration and an acknowledged/completed task.
Prerequisites
- OpenTrack, OpenCOP, OpenTask and required OpenBus/knowledge services are healthy.
- A controlled track generator or recorded input is available.
- Two test users/roles are available for assignment and acknowledgement.
Procedure
- Create or ingest a uniquely identified test track with known position, time, type and source.
- Verify OpenTrack receives/updates it and OpenCOP displays it in the correct location/type.
- Open the track details and confirm source time, provenance and semantic type.
- Create an OBSERVE, INVESTIGATE, TRACK or other allowed task from the track.
- Assign it to the second user/asset; acknowledge, execute and complete it.
- Verify task state is visible in OpenTask/OpenCOP and correlated to the original track.
- Capture messages/events/logs proving the state transitions.
Pass criteria
Track position/type/time are correct; task creation and authorization succeed; all state transitions are visible and correlated; duplicate updates do not create duplicate tasks; evidence is retained.
Cleanup
Delete or mark the test track/task complete according to the test-data policy and verify no generator continues publishing.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
OpenEyes Sensor Product Workflow
OpenEyes Sensor Product Workflow
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference operational demonstration |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Objective
Demonstrate that imagery captured by OpenEyes or uploaded from a phone persists as a sensor product, appears in the OpenEyes product strip, carries source/time/context metadata, and can be associated or pushed to an OpenFiles workspace/release group.
Prerequisites
- OpenEyes asset/device session is healthy and authorized.
- Local sensor-product storage is writable and persistence survives page refresh/service restart.
- Phone upload script has endpoint/token configured outside the script or uses a safe prompt.
- OpenFiles target workspace/release group exists and permissions are verified.
Procedure
- Capture one image from the FPV view and record the asset/session ID and capture time.
- Verify a thumbnail appears in Sensor Products and opens the full image.
- Refresh the page and restart only the OpenEyes service; verify the product remains.
- Run the phone upload script with a uniquely named image and verify it appears in the same product strip.
- Inspect metadata: product ID, device/uploader, source time, receipt time, MIME type, size, checksum and optional position/track/task.
- Push the product to the selected OpenFiles workspace/release group and verify recipient access.
- Verify audit/provenance links from OpenEyes product to the OpenFiles artifact.
Pass criteria
Both captured and uploaded images persist, render correctly, have accurate metadata/checksum, are access-controlled, transfer once without corruption, and retain the source-to-share provenance trail.
Negative tests
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
OpenRF Spectrum Workflow
OpenRF Spectrum Workflow
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference SDR/edge demonstration plus technology indicators |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Objective
Demonstrate registered SDR discovery, synchronized/located collection, edge spectrum processing and a low-latency spectrum or detection product visible through OpenRF without transporting unnecessary raw samples.
Procedure
- Register the radio agent/device with stable ID, driver, capabilities, location profile and time source.
- Confirm agent health, radio enumeration and selected center frequency/sample/bandwidth/gain settings.
- Start a bounded scan or known FM/spectrum example and observe local processing load/drop indicators.
- Open the OpenRF view and verify live spectrum/detection product, labels, units and timestamps.
- Change one authorized setting and verify acknowledgement plus visible result.
- Record latency, update rate, sample/drop quality and time/PNT status.
- Stop the task and verify radio resources are released.
Pass criteria
Correct radio/profile is used; settings are bounded and authorized; product units/time are correct; view remains responsive; loss/degradation is visible; stop releases hardware; no raw bandwidth flood occurs across the WAN.
Observed technology indicators
| Indicator | Occurrences |
|---|---|
| PTP/PPS | 1064 |
| camera/video | 362 |
| UHD/USRP | 324 |
| AIS | 154 |
| FlightGear | 121 |
| DIS | 85 |
| PlutoSDR | 56 |
| HackRF | 55 |
| SoapySDR | 54 |
| ADS-B | 46 |
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
OpenLVC and FlightGear Workflow
OpenLVC and FlightGear Workflow
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference LVC integration test |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Objective
Demonstrate a virtual FlightGear entity entering the same operational representation used by live tracks, then being observed, correlated, tasked and replayed without hiding its simulation provenance.
Procedure
- Start a controlled FlightGear scenario with known aircraft, position, heading, speed and scenario time.
- Start the OpenLVC bridge and verify its input/output endpoint and entity identifier.
- Verify OpenTrack receives updates with correct coordinates, altitude, velocity, time and LVC provenance.
- Display the entity in OpenCOP and compare against the FlightGear state.
- Create an observation/follow/intercept task and verify state transitions without issuing unsafe real-world effects.
- Record scenario/event stream for OpenAAR-MR and replay the segment.
- Verify live and virtual entities remain distinguishable by source/provenance while sharing common semantics.
Pass criteria
Track error remains within test tolerance; update rate/time mapping is stable; provenance is explicit; task workflow completes; replay reproduces the operational sequence; no virtual input crosses a prohibited live-effect boundary.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Acceptance & Evidence
Managed documentation for Acceptance & Evidence.
API Acceptance Test
API Acceptance Test
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Static API inventory plus acceptance standard |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Scope
Test the 11 REST/HTTP and 8 WebSocket candidates identified by the static scan, then publish only verified interfaces as authoritative.
Per-endpoint test matrix
| Test | Expected |
|---|---|
| Authorized valid request | Documented success status and schema. |
| Unauthenticated request | Rejected without data leakage. |
| Authenticated but unauthorized | 403/policy rejection and audit event. |
| Malformed/invalid data | Deterministic validation error; no crash/partial mutation. |
| Duplicate/retry | Idempotent result or explicitly documented duplicate behavior. |
| Rate/size/timeout boundary | Controlled rejection/backpressure and observable metric/log. |
| Dependency failure | Safe error, no secret/stack leakage, recovery after dependency returns. |
| Audit/correlation | Actor, action, target, outcome and correlation ID present. |
Evidence record
Endpoint and release:
Authentication role:
Request (secrets removed):
Expected status/schema:
Actual status/schema:
Latency/size:
Audit/correlation ID:
Pass/fail and defect/task:
Tester/date:
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Release Acceptance Test
Release Acceptance Test
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Release evidence and acceptance standard |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Release gate
- Artifact/version/checksum/source recorded.
- Configuration diff and secret rotation requirements reviewed.
- Database/ontology/data migrations tested with backup and rollback.
- Service, local health, public TLS/proxy and WebSocket checks pass.
- Primary workflows for enabled components pass with correct authorization.
- Performance/latency/resource behavior acceptable for demo/operational load.
- Logs/audit show no critical regression or credential leakage.
- Backup/restore and rollback path remain available.
- Known issues, owners and workarounds documented.
- Release approved by named technical/operational reviewer.
Static coverage indicators
| Area | Count |
|---|---|
| Files inventoried | 1383 |
| Detected components | 23 |
| REST candidates | 11 |
| WebSocket candidates | 8 |
| Service candidates | 10 |
| Nginx candidates | 1 |
Decision record
Decision: APPROVE / APPROVE WITH LIMITATIONS / REJECT / ROLL BACK
Release:
Environment:
Tests executed:
Open defects/limitations:
Operational risk:
Rollback state:
Approver/date:
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.