Ableitung puts a code model for AUTOSAR Classic C on your ECU team's own GPU servers.
When your requirement tool exports the automaker's revised specification as ReqIF, the model answers each QM change with a merge request or a question, against your RTE headers and MISRA set, traced for ASPICE.
Scope a pilotSee the change for 4.2.7
Your code is a trade secret only while you keep it confidential, so no outside code model reads it.
Then bring the model to the code. This one runs on your own GPU servers with no outbound connection; our service in Ohio handles licenses, updates and support tickets.
The price comes before the scoping call: twelve weeks on one ECU project, $10,500.
Then $3,500 per ECU project a month, about a third of one software developer's mean pay in metro Detroit, every engineer included. The GPUs are yours: at least 192 GB of memory in one server.
- Reads your ReqIF exports, generated RTE headers and MISRA set
- Answers each QM requirement: a merge request and test, or a question
- Keeps the trace, exported with a consistency report per baseline
Invoiced once it runs on the hardware your scope names
Stop after the twelve weeks with nothing more to pay
PilotStart here$10,50012 weeks, one ECU project
ECU project$3,500per ECU project / month
What each price covers
Pilot. The first twelve weeks of one ECU project on your own GPU server, scoped in writing; stop at the end with nothing more to pay. We want to try it on one ECU first
Reads your ReqIF export, the generated RTE headers and your rule set. Opens each revised requirement as a merge request with its unit test. Keeps the trace from requirement to unit to test to result. Installed on your server with an engineer on site for half a day.
ECU project. Each ECU project after its pilot, or any further one: one repository, one requirement specification, one rule set. We run it on our ECU projects
Every engineer on the project, no seat count. Quarterly model updates as signed bundles, installed when you decide. Trace export for your requirement tool after every baseline. Support from Detroit, severe problems answered within four business hours.
It writes merge requests against requirements, and stops there.
A team that wants a coding assistant for all its work should leave now: a general agent in the editor and terminal serves it better.
No merge button
Whoever reviews a change merges it
Your GPUs only
No cloud version and no hosted trial
Not autocomplete
Nothing appears as you type
Hands off the ARXML
And off the RTE built from it. A missing port becomes a question
No model in a 2025 study wrote MISRA-compliant code, even when told to.
Every model fixed violations only once they were pointed out. In a Technical University of Munich study, clearing the MISRA checks took more than four rounds on average.
The team's earlier trial in the example went the same way: nine of a general agent's first twelve merge requests failed MISRA C:2025, none naming a requirement.
In the example, one line for 4.2.7 broke Rule 10.4. The model rewrote it before any merge request opened, and the second run was clean.
Read the model's noteYour rule set
As your checker reads it, approved deviations included
Your checker
Up to four sandbox rounds. Still flagged after the fourth: no merge request, a question with its result
A deviation draft
In your template, counted once an engineer signs
Requirement 4.2.7 has two clauses, and your ARXML has a port for only one.
One example revision. The model changed one function in pump_runon.c; the scope check took a debounce its own draft had added back out, into the note for your reviewer.
- The testNamed for 4.2.7, no bare numbers in it
- Where it stoppedThe gateway clause needs a port your generated header lacks, and the symbol lookup refuses calls it does not declare
- The questionThe model rereads 4.2.7 clause by clause. Your setting, strict unless you loosen it, cleared the 40 °C stop; the gateway clause became the question
- Last lineThe reviewer merges it or asks for another commit
Your safety manager classifies this tool. Nobody else can, us included.
Under ISO 26262-8, a tool that can put an error into ASIL B code is TI2; its confidence level rests on how reliably later checks catch it.
It also rests on how your process uses the tool. We hand her a tool description, our test evidence and a list of your later checks.
Until she switches ASIL B on, the model stays off those units. In the example, 7 of 41 requirements wait: the ones your team cares about most.
Wednesday morning, before the first review.
The 41-requirement plan, Tuesday night's build and the deviation the model drafted for 4.3.5: example pages of the web app on your server.
Scope a pilot on one ECUThe trace is kept as each of the model's changes merges, so nobody types those links in before the assessment.
Every test the model writes names its requirement, and every result is traced to its test, as ASPICE 4.1 SWE.4 asks. Your assessor still judges the links.
Trace, revised specification, October
| Requirement | Unit | Test | Result |
|---|---|---|---|
| 4.2.7 Pump run-on after key-off | pump_runon.c | Run-on stops below 40 °C | Waiting for review |
| 4.3.1 Valve position on cold start | valve_position.c | Valve opens on a cold start | Passed |
| 4.3.5 Valve feedback timeout | valve_service.c | Lost feedback is reported | Waiting for review, deviation not yet signed |
| 4.4.2 Coolant level warning to the cluster | No unit changed | No test | Stopped, no port in the ARXML |
| 5.2.9 Reaction to a lost temperature sensor | sensor_monitor.c, ASIL B | Not drafted | Held for the safety manager |
A drawn example, not a customer's trace. It is not your requirement tool and not an assessment result.
Start with one ECU project and the MISRA set it is checked against.
We scope the pilot on those two answers; add your requirement tool, DOORS, Polarion or codebeamer, in the same field.
A scoping call with an engineer in Detroit within two business days, then a written scope at $10,500. No other mail.