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.
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.
| Deadline class | Where it runs | How it is shown |
|---|---|---|
| Hard (a miss is a hazard) | An RTOS or a dedicated microcontroller | Worst-case execution analysis on the target, plus a test per deadline |
| Firm (bounded jitter) | PREEMPT_RT Linux on isolated cores | cyclictest histograms recorded under the field load profile |
| Soft (telemetry, display) | Standard Linux user space | Throughput 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
- Sensors and actuatorsSPI, I²C or CAN, each with a declared sample period
- Driver layerIts own process, so a driver fault stays contained
- Control loop
SCHED_FIFOon an isolated core - State machineThe transition table, enforced
- Local SQLite logAppend-only rows on the device or gateway
Interfaces and their contracts
| Interface | Contract | Checked by |
|---|---|---|
| Sensor bus | Sample period and timestamp source declared per sensor | The drift query (Panel 3) |
| Control loop to state machine | A bounded shared-memory ring buffer; an overflow is a logged event, not a silent drop | The overflow counter in the log |
| Safety outputs (GPIO) | A defined safe state on watchdog expiry | A fault-injection test per output |
| Firmware update | Signature checked before the image is written; the previous image kept | The unsigned-image rejection test |
| Telemetry export | Append-only rows copied off the device, not streamed raw to a vendor cloud | Row-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.
| Claim | Status | What it rests on |
|---|---|---|
| Scheduling latency characterized with cyclictest on the target board, under load | Designed and documented | A standard rt-tests procedure, run per engagement on your hardware. No recorded run yet. |
| Explicit state machine with every state and transition enumerated and tested | Designed and documented | Delivered per engagement as a transition table and its tests. No published record yet. |
| Local SQLite evidence log on the device or gateway | Designed and documented | The pattern shown in the explorer; scoped per engagement. No recorded run yet. |
| Signed firmware images with a test proving an unsigned image is rejected | Designed and documented | A 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 Linux | Not established | PREEMPT_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 established | The 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.