In short: managers get requirement coverage, trends and an audit trail; test leads get reviewable tests and plans; engineers get test authoring, simulation, bus analysis and diagnostics in one app; operators get a locked screen with a Start button and a clear PASS or FAIL. Everyone works from the same test files and reports.
Engineering and quality management
What they need: to know whether the product is ready, without reading traces. Which requirements are tested, which fail, whether the trend is getting better, and whether the results would stand up in an audit.
| Ecuhawk gives | Status |
|---|---|
| Test reports in HTML, PDF and JSON with run context: project, DUT serial number, variant, operator, bench mode and date | INCLUDED |
| An audit log of every write, refused write, approval and safe-state event | INCLUDED |
| Requirement IDs on every test and step, with a coverage table: tested, passed, failed, not covered | INCLUDED AT LAUNCH |
| A nightly summary by email or in Teams: "47 passed, 3 failed", with the report attached | INCLUDED AT LAUNCH |
| Trend and coverage dashboards across benches and releases | COMING SOON |
Test managers and test leads
What they need: to plan what gets tested, assign the work, review tests before they count, and release a version with clear evidence. They also need failures to reach the right developer quickly.
| Ecuhawk gives | Status |
|---|---|
| A review status on every test: draft, in review, approved, released. Only approved or released tests run on a real bench | INCLUDED AT LAUNCH |
| AI-drafted tests that always start as drafts, so a person decides what counts | INCLUDED AT LAUNCH |
| Plain-text test files that live in Git, so every change is reviewed and versioned | INCLUDED |
| Test plans, variants and profiles: one test for every ECU variant and bench | COMING SOON |
| A Jira ticket opened for a failed test, with the failure text, trace summary and report | COMING SOON |
Test, system and diagnostic engineers
What they need: to turn requirements into tests fast, try them before the hardware is ready, and find out why something failed without hours in a trace.
| Ecuhawk gives | Status |
|---|---|
| A test table editor and runner: setup, main and cleanup steps, checks with limits and timing, diagnostic steps | INCLUDED |
| A simulated bench with ECU models (FMU, DLL), so tests run before hardware arrives | INCLUDED |
| CAN trace, graphics, recording and offline analysis with DBC decoding | INCLUDED |
| UDS diagnostics: read and write DIDs, read and clear DTCs, sessions, security access | INCLUDED |
| Fault injection: stop a message, change its cycle, corrupt the CRC, freeze the alive counter | INCLUDED |
| AI that drafts tests from a requirement document and finds anomalies in the trace | INCLUDED AT LAUNCH |
Bench and hardware engineers
What they need: a bench that is quick to set up and cannot damage an ECU, whoever is using it.
| Ecuhawk gives | Status |
|---|---|
| Power supplies, relays and I/O as plain signals, described in a bench file | INCLUDED |
| Hard limits and interlocks the engine enforces for every user, script and AI request | INCLUDED |
| A safe state that switches every output to its safe value on a fault or an emergency stop | INCLUDED |
| The same project on Windows and Ubuntu Linux | INCLUDED |
Software and integration teams
What they need: ECU tests that run in the build pipeline like any other test, and results their CI can read.
| Ecuhawk gives | Status |
|---|---|
| A command-line run with no window: exit code for the verdict and the report path printed | INCLUDED |
| A scripting API in Python for anything the test table cannot do | INCLUDED |
| JUnit XML results for GitLab, GitHub Actions and Jenkins | COMING SOON |
Operators: lab, end-of-line and service
What they need: to run the test correctly every time, without training in test tools, and to know at once what to do with the unit in front of them.
| Ecuhawk gives | Status |
|---|---|
| Operator mode: serial number, a Start button, guided prompts and a full-screen PASS or FAIL | INCLUDED AT LAUNCH |
| Locked limits and tests; a password switch back to engineer mode | INCLUDED AT LAUNCH |
| A report saved for every unit, ready to print or share | INCLUDED |
Questions
Do managers need to install Ecuhawk to see results?
No. Reports are HTML and PDF files, and summaries can go out by email or chat. A shared dashboard is planned.
Can an operator change a test limit by mistake?
No. In operator mode, tests and limits are locked. Hard limits are also enforced by the engine, so no user, script or AI can exceed them.
Who decides whether an AI-written test counts?
A person. AI-drafted tests are saved as drafts and run only on a simulated bench until an engineer approves them.
Does every role need its own licence type?
Licensing is still being designed. Tell us in the beta form how your team is organised, and we will take it into account.