In short: requirements come in from your requirements tool, engineers turn them into tests and try them on a simulated bench, the tests run on the real bench and every night, failures go to Jira and the team chat, a test lead reviews and releases, and the same tests then run in operator mode on the line and in service. Reports and the audit log keep the evidence at every step.
The cycle at a glance
| Stage | Who | In Ecuhawk | Other tools |
|---|---|---|---|
| 1. Requirements | System engineer | Requirement IDs; requirement documents read by the AI to draft tests | Polarion, DOORS, Jama, Jira, Excel |
| 2. Test design | Test engineer | Test table editor or Python; AI drafts saved as drafts | Git for review |
| 3. Try it early | Test engineer | Simulated bench with ECU models, before the hardware exists | FMU / Simulink models |
| 4. Real bench | Test and bench engineers | Power, relays, CAN, UDS; hard limits and safe state | Lab equipment |
| 5. Failures | Test engineer, developer | Trace, recording, anomaly finder, report | Jira, Teams, Slack |
| 6. Regression | Integration team | Command-line run, started by your CI or scheduler | GitLab, GitHub, Jenkins; email |
| 7. Review and release | Test lead, quality | Review status, coverage, reports, audit log | Confluence, release notes |
| 8. Production | Operator, EOL engineer | Operator mode, serial numbers, a report per unit | MES / plant systems |
| 9. Field service | Service technician | Operator mode, diagnostics, DTC reading | Service tickets |
1. Requirements come in
Requirements usually live in a requirements tool or a spreadsheet. Each test in Ecuhawk carries the IDs of the requirements it checks, so coverage can be shown later. The AI can read a requirement document from the project and propose tests for it. INCLUDED AT LAUNCH Reading text, Markdown and CSV works today; import from ReqIF, Polarion and DOORS is COMING SOON.
2. Tests are designed
Engineers write tests in the test table (steps, limits, timing) or in Python. A test written by the AI is checked against the bench before it is saved: unknown signals, wrong units and missing parameters are refused. It is always saved as a draft. NO CODE NEEDED
3. Tried early, on a simulated bench
The same test runs against simulated ECUs and models, so a test can be written and debugged weeks before the hardware arrives. Drafts can only run here. INCLUDED
4. Run on the real bench
On the real bench, the engine enforces hard limits and interlocks for every user, script and AI request, and switches every output to its safe value on a fault. Only approved or released tests run here. SAFE BY DESIGN
5. Failures reach the right people
A failed test leaves a report, a recording and an audit trail. The anomaly finder lists timeouts, gaps, wrong cycle times and checksum errors from the trace. Planned next: a Jira ticket with the failure text and report, and a message in the team's Teams or Slack channel. COMING SOON
6. Regression, every night
The command-line run executes tests without a window and returns the verdict as an exit code, so it fits any CI server. INCLUDED A nightly summary by email is INCLUDED AT LAUNCH, and JUnit results for CI dashboards are COMING SOON.
7. Review and release
A test lead moves tests from draft to in review, approved and released. Reports carry the project, DUT, variant, operator and verdict, and requirement coverage shows what is tested and what is missing. This supports the test evidence that ASPICE asks for. INCLUDED AT LAUNCH
8. Production end-of-line
The released tests run in operator mode: scan the serial number, press Start, read PASS or FAIL. The limits and diagnostic data are the ones development used. INCLUDED AT LAUNCH
9. Field service, and back to the start
Service stations use the same tests and diagnostics to check a returned unit. What fails in the field becomes a new requirement or a new test, and the cycle starts again.
Questions
Do we have to change our requirements tool?
No. Ecuhawk only needs the requirement IDs on each test. Import from ReqIF, Polarion and DOORS is planned; text, Markdown and CSV can be read today.
Can the same test run in the lab and on the production line?
Yes. That is the idea of the cycle: the test, limits and diagnostic data stay the same, and operator mode gives the line a simple, locked screen.
Can Ecuhawk run in our CI pipeline?
Yes. A command-line run without a window returns the verdict as an exit code and writes the report. JUnit output is planned.
How do failures get to developers?
Today through the report, recording and audit log. Jira tickets and Teams or Slack messages for failed tests are planned.