This is a fictitious example. The company, people, workflow, and tool versions are invented. It reflects real patterns we see in embedded test labs. Use it to understand how a workflow map works – then apply the same method to your own workflow.
The scenario
A German automotive Tier-2 supplier builds ECU firmware for an electric power steering module. They run a HIL regression suite before every release. The team owns the workflow, but every release week brings the same friction: results are doubted, context is missing, and one senior engineer spends two days assembling evidence by hand.
The lab uses three tools:
- LabVIEW 2023 – drives the HIL simulator (steering rack model, CAN bus simulation).
- Vector CANoe 15 – monitors CAN traffic and generates trace logs.
- Python 3.11 scripts – post-processes CANoe exports into a PDF report.
The team is not planning to replace any of these tools. But the workflow between them is brittle.
The trigger
A release ticket arrives from the firmware team: “v4.7.1 regression, stand 3.”
The test engineer begins the workflow.
The workflow: step by step
| Step | What happens | Tool | Context lost? |
|---|---|---|---|
| 1. Stand setup | Engineer powers on the HIL rack, checks wiring against a paper checklist, loads the steering model version r14.2. | Manual + LabVIEW | Yes. The model version is not recorded in the test log. Wiring check is on paper. |
| 2. DUT flash | Firmware v4.7.1 is flashed to the ECU via a separate tool (not in the sequence). | Vendor flasher | Yes. Firmware version is noted in a Slack message, not in the formal evidence. |
| 3. LabVIEW sequence | A LabVIEW VI runs 18 test cases. Each case sets CAN signals, measures ECU response, and writes pass/fail to a log file. | LabVIEW 2023 | Partially. The VI version is not logged. Parameter assumptions are in the VI diagram – not visible after the run. |
| 4. CAN trace capture | Vector CANoe records all CAN traffic during the sequence. | Vector CANoe 15 | Yes. The CANoe config file version and database (DBC) version are not captured. |
| 5. Report generation | A Python script reads CANoe exports and generates a PDF with signal plots and a pass/fail summary. | Python 3.11 + custom script | Partially. The Python script version is in a Git repo, but which commit was used is not recorded. Script arguments are not logged. |
| 6. Review | The engineering manager opens the PDF, checks the pass/fail summary, and signs off – or asks questions. | PDF + email | Yes. If the manager asks “was the model r14.2 or r14.1?”, the engineer checks Slack and their paper notebook. |
The handoff gaps
Mapping this workflow reveals four handoffs where context disappears:
| Handoff | What breaks | Impact |
|---|---|---|
| Setup → LabVIEW | Model version, wiring checklist, operator identity. | Reviewer cannot confirm the simulator was configured correctly. |
| LabVIEW → Vector CANoe | CANoe config version, DBC version, timing alignment between VI steps and CAN traces. | CAN logs cannot be reliably correlated with test steps. |
| Vector CANoe → Python script | Script commit, script arguments, export file format assumptions. | Report generation is not reproducible without the engineer who wrote the script. |
| Python script → Reviewer | No link from the report back to setup, versions, or anomalies. | Reviewer must ask questions that should be answered by the evidence itself. |
What the team learned
The exercise took 45 minutes with a whiteboard and a text editor. It did not require sharing confidential data. It showed that:
- The LabVIEW sequence itself works well. The tool is not the problem.
- The evidence chain breaks at every handoff. Setup, firmware version, CANoe config, and script version are invisible to the reviewer.
- Fixing one handoff – e.g., auto-capturing the model version and firmware version – would remove the most common source of reviewer questions.
- A full tool migration would move the same gaps into a new stack. Mapping first makes the next step smaller and cheaper.
How to do this for your workflow
- Pick one workflow that creates recurring confusion.
- Write down the trigger, the steps, the tools, and the handoffs.
- For each handoff, ask: does the next tool or person receive enough context to trust what came before?
- Mark the gaps. Do not fix them yet – just make them visible.
- Decide whether the gaps are worth a closer diagnostic.
Use the diagnostic kit to do this with templates for workflow map, toolchain handoff map, and evidence gap scorecard.
See a concrete example of how to map one embedded HIL test workflow before changing tools.