ECUs, microcontrollers, sensors. Firmware revision, hardware variant, serial number.
An evidence and orchestration layer for embedded test workflows
Finnegans maps the missing context between your existing test tools so setup, execution, and evidence stay connected from one run to the next.
For embedded test, HIL, and validation teams – map where setup, tool handoffs, and test evidence break across LabVIEW, TestStand, Vector, dSPACE, OpenTAP, pytest, and custom scripts, before replacing anything.
What does orchestration actually change?
Setup Toil
Version Drift
Evidence Scatter
Tool Handoffs
Knowledge Fragility
Review Stress
Why embedded test labs fail between tools problem Map one workflow before replacing tools method What a paid diagnostic should deliver offer Why HIL repeatability is a workflow problem HIL Test logs vs trusted evidence evidence Test logs vs trusted evidence evidence Example: mapping one HIL workflow example LabVIEW and TestStand handoffs handoff Why labs fail between tools problem HIL repeatability: a workflow problem HIL Map before replacing tools migration Test logs vs trusted evidence evidence Test logs vs trusted evidence evidence What a paid diagnostic should deliver offer Example: mapping one HIL workflow example
Each cluster is a recurring pain. Every link is a note that explains it.
Click around – the mess is the message.
Problem
L0 · Devices
ECU / DUT physical
Microcontroller, CAN, RS-485, SPI, I²C, UART Sensors analog
IMU, temperature, pressure, current Actuators physical
Motors, solenoids, relays, PWM, DIO Debug probes connected
SWD, JTAG – firmware introspection L1 · Interface
CAN transceiver conditioned
120Ω termination, differential pair RS-485 gateway translated
Modbus RTU → TCP/IP tunnel FTDI UART-USB bridged
TTL 3.3V → USB virtual COM Signal conditioning clean
Level shift, noise filter, impedance match L2 · Concentration
Managed switch routing
1Gbps Ethernet per stand VLAN segmentation isolated
Control, data, management planes DHCP + mDNS auto
Auto-IP, stand discovery via multicast 10Gbps backbone scaled
Up to 100 stands aggregate L3 · Nexus
Discovery Service active
UDP broadcast – find stands, devices, drivers Session Manager active
Track sessions, enforce timeouts, prevent conflicts Config Deducer solving
Greedy auto-select best driver + frontend stack Dependency Resolver resolved
Graph traversal – driver → ROS2 → DDS Container Launcher running
Spawn isolated processes per session Health Monitor watching
Keep-alive heartbeat, auto-terminate stale sessions Capability Enforcement locked
Gate NON_DESTRUCTIVE, READ_ONLY, FIRMWARE_UPDATE L4 · Middleware
ROS2 topics pub/sub
device/port/command + telemetry DDS transport real-time
UDP – RELIABLE / BEST_EFFORT QoS HTTP control plane REST
POST /sessions, heartbeat, teardown State sync closed
desired vs actual – feedback loop L5 · Client
pytest scripts testing
Automated test execution CLI tools dev
finnegans discover / session / run Evidence capture recorded
Logs, YAML artifacts, per-run traceability CI/CD integration pipeline
GitHub Actions, Jenkins, GitLab CI Agent-ready manifests future
YAML metadata – LLMs understand topology
Hover a problem on the left to see which layers address it.
Six layers, one orchestration flow.
Works with your existing tools
Not another test runner – an evidence and orchestration layer
around what you already own
LabVIEW TestStand Vector dSPACE OpenTAP pytest
- Setup toilReruns that should take minutes take days.
- Evidence gapsAssembling trust for a review takes hours.
- Knowledge fragilityOne engineer holds the chain end to end.
The product
Six layers. Every handoff visible
The L0–L5 model maps what every test lab already has – whether named or not. An orchestration and evidence layer around your existing tools, not a replacement for them.
dSPACE HIL, Vector interfaces, signal conditioners. Physical bridge between DUT and data.
Network switches, VLANs, DHCP. How signals travel from instruments to orchestration.
Discovery, session management, config deduction, dependency resolution. The orchestrator.
ROS2 topics, DDS transport, HTTP control plane. Typed messaging between components.
Test scripts (pytest), CLI tools, evidence capture, CI/CD integration.
Just reading?
Browse the technical notes on evidence packs, LabVIEW/TestStand handoffs, HIL repeatability, and mapping workflows before replacing tools.
$220K/year handoff tax across 3 test tools
322 forum posts, 793 pain rows, and one concrete CI/CD integration gap between LabVIEW, TestStand, and Jenkins. Read the full case study with the 7-gap scorecard.
Start with one workflow, not a platform migration
Step 1 · Free
Diagnostic Kit
Self-serve templates to map setup, handoff, and evidence gaps in 30–45 minutes. No call, no data shared.
Use the kit → Step 2 · Free 30 minWorkflow Review
A fit/no-fit discussion. Bring one workflow – we'll tell you if the gaps are real or if the timing isn't right.
Book a review → Step 3 · Paid €2k–5kDiagnostic Workshop
1–2 weeks of deep mapping. Deliverable: workflow map, evidence gap scorecard, and a proof-of-concept scope.
Request scope →An evidence pack needs more than a pass/fail log
Our commitments, not our limitations
- We commit to map one workflow before proposing any platform change.
- We commit to respect your existing tools – LabVIEW, TestStand, Vector, dSPACE, OpenTAP, pytest, and custom scripts.
- We commit to say "not a fit" when the pain is too small or the timing is not real.
- We commit to deliver a narrow proof before any broad implementation conversation.
Does this sound familiar?
Common symptoms of a workflow that needs mapping
- Reruns that should take minutes take days.
- An auditor or customer questions a result – and assembling trust takes hours.
- One engineer holds the chain; nobody else understands it end to end.
- You bought a new tool and the handoff gaps didn't go away.
- Map one workflow →
Next step
Map one workflow before changing the toolchain
Use the diagnostic kit to identify setup, handoff, and evidence gaps in one embedded test workflow.