# Automotive

> Vehicle software, with every write to an ECU approved by an engineer.

Source: https://neuralinverse.com/industries/automotive/

---

![](/photos/bench.jpg)

[Industries / Mobility and devices](https://neuralinverse.com/industries/)

# Vehicle software, with every ECU write approved.

For network, ECU, validation, diagnostics and calibration engineers. Your interfaces, databases and vendor tools stay as they are.

Standards

ISO 26262 · ISO/SAE 21434 · ASPICE

Databases

DBC, LDF, ARXML, A2L, ODX

Protocols

CAN, LIN, UDS, DoIP, XCP

Interfaces

Vector, PEAK, Kvaser, python-can

Deployment

Self-hosted, your cloud or air-gapped

What your team gets

## CAN, diagnostics and calibration in the IDE.

Govern features are in use today. Domain modules are pre-release; their state is listed under Tools and formats.

- **Network databases:** DBC, LDF and ARXML as tables and bit layouts, with consistency checks and navigation.
- **The bus on your bench:** Vector, PEAK and Kvaser interfaces through each vendor's own library, or a virtual bus for tests and CI.
- **Traces and simulation:** Decoded traces and a live bus monitor; the rest of the network simulated from the database.
- **Diagnostics and calibration:** UDS diagnostics on CAN or DoIP; XCP measurement and calibration from the A2L.
- **Generated code protected:** The automotive template denies agent edits to Embedded Coder output and the AUTOSAR RTE. Changes to safety components, A2L and ARXML wait for a named approver.

Who uses it

## One environment for every role around the vehicle network.

- **Network engineers:** Maintain DBC, LDF and ARXML databases and check them for consistency.
- **ECU software engineers:** Write and debug ECU code with the bus and its signals beside it.
- **Validation engineers:** Run software-in-the-loop tests on a virtual bus in CI, and replay recorded traces.
- **Diagnostics engineers:** Read fault memory, data identifiers and routines over UDS.
- **Calibration engineers:** Measure and calibrate over XCP from the A2L.

Tools and formats

## What the Automotive module handles, and how far each is verified.

The module turns on by itself in a trusted workspace that holds automotive work.

- **Databases and descriptions:** Read, checked and navigated; encoding and decoding; C code generated from a database. DBC and ARXML reading, the codec and ODX are verified on vendor and standards-body sample files, which are demo size.
- **Bus interfaces:** Each vendor's interface through its own installed library. The bus monitor is verified on python-can's virtual interfaces. Vector, PEAK and Kvaser are kit shipped: run only against test libraries.
- **Diagnostics and calibration:** UDS over CAN and DoIP; XCP from the A2L. XCP is verified against XCPlite.
- **Traces and tests:** CAN traces and Ethernet captures opened and decoded; CANoe test units run through CANoe4SW Server Edition. Modelled.

Tested on Linux only, with no CAN hardware and no real ECU, and nothing the module writes has yet been opened in the vendor tools. Domain modules are pre-release. Nothing is verified by a customer yet, and nothing is verified on Windows. Do not rely on a capability for production work until it is verified for your tools, versions and operating system. Product names belong to their owners.

How a change moves

## A person decides before anything leaves the desk.

1.  Propose
    
    An engineer or agent drafts a change to ECU software.
    
2.  Verify
    
    Your qualified tools build, check and test it.
    
3.  Approve
    
    Changes to safety components and calibration data wait for a named approver.
    
4.  Record
    
    Change, results and approval kept together in the audit record.
    

Standards

## Evidence for your safety and security cases. The certification is yours.

- **ISO 26262:** Evidence toward ISO 26262: changes to safety-relevant components with their named approver, and generated code kept out of agents' reach.
- **ISO/SAE 21434:** Evidence toward ISO/SAE 21434: agent reads of ECU keys and certificates are denied and logged.
- **ASPICE:** Evidence toward ASPICE assessments: every change kept with its reason, review and approval.

Neural Inverse provides evidence toward these standards. Certification stays with your organisation and assessor.

Products used

[Neural Inverse Build →

Editor, Agents and CLI with the domain tools your engineers need.](https://neuralinverse.com/build/)[Neural Inverse Govern →

Policy, approvals and audit for every AI tool your teams use.](https://neuralinverse.com/govern/)

Product names belong to their owners.

Related industries[Semiconductors and FPGA](https://neuralinverse.com/industries/semiconductors/)[Industrial automation](https://neuralinverse.com/industries/industrial/)[Avionics](https://neuralinverse.com/industries/avionics/)

![](/photos/team.jpg)

## Talk to our team.

Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.

[Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)