Edge and Embedded Systems Engineering

Consequential Data Engineering

Device software for medical equipment and mission hardware where a missed deadline or a stuck state is a safety event. We build explicit state machines, characterize scheduling latency on your target board under your load, and keep every run in a local SQLite log that feeds the IEC 62304 verification record.

IEC 62304:2006+A1:2015 PREEMPT_RT Linux ISO 14971:2019 Local SQLite Evidence Log

The Customer Problem: Four Embedded Failure Patterns

Priority inversion under load

A low-priority logging task holds a mutex the motor-control loop needs, a medium-priority task preempts it, and the control loop misses its deadline. It never shows on the bench, only under field load.

Silent sensor clock drift

Each sensor stamps readings with its own oscillator. Over hours the clocks diverge, fused readings stop describing the same instant, and nothing records that it happened.

An unisolated GPIO panic

A fault in one driver takes down the process that also owns the safety interlock outputs, and they stay in whatever state they last held.

Unversioned firmware flashing

Field units are flashed by hand from a laptop. Nobody can say which build runs on which device, or show that an unsigned image would be refused.

The Consequential Solution: Deterministic Behavior You Can Measure

  • Explicit state machines. Every operating mode, transition and guard is written down as a table and implemented as one. An event with no defined transition is rejected and logged, never improvised.
  • Latency measured, not assumed. PREEMPT_RT Linux lowers scheduling latency; it does not prove a bound. We measure on your board under your load and keep the histogram as IEC 62304 verification evidence.
  • Isolation at the fault boundary. Safety outputs are driven by a separate process or core with a watchdog, so a fault elsewhere sends them to a defined safe state.
Where each class of deadline runs, and how it is shown
Deadline class Where it runs How it is shown
Hard (a miss is a hazard)An RTOS or a dedicated microcontrollerWorst-case execution analysis on the target, plus a test per deadline
Firm (bounded jitter)PREEMPT_RT Linux on isolated corescyclictest histograms recorded under the field load profile
Soft (telemetry, display)Standard Linux user spaceThroughput and backlog counters in the local log

What Netspective Delivers: Engineering Responsibility

State machine and transition table

The operating modes, transitions and guards as a reviewed table, the implementation checked against it, and one test per transition.

Latency characterization record

cyclictest runs on your target hardware under the field load profile, each histogram kept in the device log with the budget its deadline is held to.

Firmware integrity chain

Signed images, a verified boot path where the hardware supports one, the previous image kept for rollback, and a test proving an unsigned image is refused.

The lifecycle evidence these produce follows the IEC 62304 practical guide; the firmware threats come from the connected-device cybersecurity guide. Named Netspective engineers write and sign each record.

Mechanics and System Contracts

  1. Sensors and actuatorsSPI, I²C or CAN, each with a declared sample period
  2. Driver layerIts own process, so a driver fault stays contained
  3. Control loopSCHED_FIFO on an isolated core
  4. State machineThe transition table, enforced
  5. Local SQLite logAppend-only rows on the device or gateway
Every stage writes what it did to the local log, which is copied off the device into the verification record.

Interfaces and their contracts

Each interface, its contract and the check that shows it holds
Interface Contract Checked by
Sensor busSample period and timestamp source declared per sensorThe drift query (Panel 3)
Control loop to state machineA bounded shared-memory ring buffer; an overflow is a logged event, not a silent dropThe overflow counter in the log
Safety outputs (GPIO)A defined safe state on watchdog expiryA fault-injection test per output
Firmware updateSignature checked before the image is written; the previous image keptThe unsigned-image rejection test
Telemetry exportAppend-only rows copied off the device, not streamed raw to a vendor cloudRow-count reconciliation per copy

Latency and Telemetry Explorer

Three steps a reviewer can re-run. Each panel says whether it is a public command or a synthetic illustration, and every query is SQLite.

Panel 1: Characterize latency on the target board

Confirm the kernel, then measure scheduling latency for an hour under the load profile the device will see in the field.

# Confirm the running kernel was built with PREEMPT_RT
uname -v | grep -o 'PREEMPT_RT' || echo "not a PREEMPT_RT kernel"

# One hour with the device workload running: locked memory, one measuring
# thread per core at priority 80, 200 µs interval, histogram up to 400 µs
sudo cyclictest --mlockall --smp --priority=80 --interval=200 \
  --distance=0 --duration=1h --histogram=400 --quiet > run-r1.hist

Public command Writes: a latency histogram file, one per run. cyclictest is part of the open-source rt-tests suite. Run it with the device's real workload alongside, or the numbers describe an idle board.

Panel 2: Worst-case latency per run

Load each histogram into the device's local SQLite log, then compare kernels and load profiles against the latency budget (100 µs here).

-- Synthetic illustration: worst-case scheduling latency per test run, from
-- cyclictest histograms loaded into the device's local SQLite sink.
-- TEMP stand-ins: they vanish with the session and never touch the file.
CREATE TEMP TABLE IF NOT EXISTS latency_run (
  run_id TEXT PRIMARY KEY, board TEXT NOT NULL, kernel TEXT NOT NULL,
  load_profile TEXT NOT NULL, started_utc TEXT NOT NULL
);
CREATE TEMP TABLE IF NOT EXISTS latency_bucket (
  run_id TEXT NOT NULL REFERENCES latency_run(run_id),
  latency_us INTEGER NOT NULL, samples INTEGER NOT NULL
);

SELECT r.run_id,
       r.kernel,
       r.load_profile,
       MAX(b.latency_us)  AS worst_case_us,
       SUM(b.samples)     AS samples,
       SUM(CASE WHEN b.latency_us > 100 THEN b.samples ELSE 0 END) AS over_budget
FROM latency_run r
JOIN latency_bucket b ON b.run_id = r.run_id
WHERE b.samples > 0
GROUP BY r.run_id, r.kernel, r.load_profile
ORDER BY worst_case_us DESC;

Synthetic illustration The tables are TEMP stand-ins with an illustrative layout, not a product schema; on a real log, drop the CREATE TEMP TABLE lines. A worst case observed in a run is evidence, not a proof of a bound. Runs as written in SQLite 3.

Panel 3: Sensor clock drift past tolerance

Readings whose device timestamp has drifted more than 5 ms from the monotonic receive clock since the first reading of the run.

-- Synthetic illustration: sensor readings whose device timestamp drifts from
-- the monotonic receive clock by more than the agreed tolerance (5 ms).
CREATE TEMP TABLE IF NOT EXISTS sensor_reading (
  sensor_id TEXT NOT NULL, seq INTEGER NOT NULL,
  device_ts_us INTEGER NOT NULL, received_mono_us INTEGER NOT NULL,
  PRIMARY KEY (sensor_id, seq)
);

SELECT sensor_id, seq, drift_us
FROM (
  SELECT sensor_id,
         seq,
         (received_mono_us - device_ts_us)
           - FIRST_VALUE(received_mono_us - device_ts_us)
               OVER (PARTITION BY sensor_id ORDER BY seq) AS drift_us
  FROM sensor_reading
)
WHERE ABS(drift_us) > 5000
ORDER BY sensor_id, seq;

Synthetic illustration A TEMP stand-in; nothing is written. Window functions need SQLite 3.25 or later. The 5 ms tolerance comes from your hazard analysis, not from us.

Verified Proof Ledger (Engineering Ground Truth)

What each claim on this page rests on. No row is marked as tested until it cites a recorded run, and none does yet: this practice's engagement records are not published.

Proof ledger: each claim, its status and what it rests on
Claim Status What it rests on
Scheduling latency characterized with cyclictest on the target board, under loadDesigned and documentedA standard rt-tests procedure, run per engagement on your hardware. No recorded run yet.
Explicit state machine with every state and transition enumerated and testedDesigned and documentedDelivered per engagement as a transition table and its tests. No published record yet.
Local SQLite evidence log on the device or gatewayDesigned and documentedThe pattern shown in the explorer; scoped per engagement. No recorded run yet.
Signed firmware images with a test proving an unsigned image is rejectedDesigned and documentedA mitigation in the connected-device cybersecurity guide on this site; built per engagement. No recorded run yet.
A proven hard real-time bound from PREEMPT_RT LinuxNot establishedPREEMPT_RT lowers observed latency; measurement does not prove a worst case. Hard deadlines go to an RTOS or a dedicated microcontroller with their own analysis.
Electrical and mechanical safety certification (IEC 60601-1)Not establishedThe device maker and an accredited test lab own it; we supply the software evidence.

Typical Engagements

These describe the shape of an engagement in each setting. They are not named client results.

Patient transfer robotics: motor control and interlocks

A lift-assist device whose motor loop shares a process with logging. The work separates the control loop from the interlock outputs and records latency under motor load as IEC 62304 verification evidence.

Bedside monitor gateway: sensor fusion

Readings from several sensors timed against one monotonic clock, with drift past the hazard-analysis tolerance logged and alarmed instead of silently fused.

Field-deployed government sensor: firmware chain

Hand-flashed units replaced by signed images with a recorded version per device, supporting the NIST SP 800-171 Rev. 2 configuration-management requirements (3.4.1 to 3.4.9) behind CMMC Level 2.

Scoped Pilot: The 2-Week Embedded Architecture Sprint

What the two weeks deliver

Week 1: read and model

Read the current architecture and hazard analysis, write the state and transition table, and set up the latency test on one board.

Week 2: measure and hand over

Run the latency characterization under load, review the isolation boundaries, and hand over the findings, the table and the test scripts.

Boundaries

  • We measure on your hardware or a representative board you provide; results on other hardware do not carry over.
  • Measured latency is evidence for your verification record, not a proof of a worst-case bound.
  • Electrical and mechanical safety under IEC 60601-1 stays with the device maker and its test lab.
  • This is engineering work, not regulatory counsel. FDA and notified bodies decide outcomes.
Runtime today

Please don't attach schematics, firmware or patient data to the first message; we agree how they move during scoping.

Just start a conversation

Sign in or sign up

Enter your email to receive a temporary sign-in link.

By continuing, you agree to our Terms of Service and Privacy Policy.