Integration
Adoption path: domain-by-domain vs full transition
Two ways onto ASG: one domain at a time on an existing platform, or a full transition on a new programme.
In one sentence ASG can be adopted one vehicle domain at a time, with the zone modules translating CAN, LIN and Ethernet during the transition, or as a full architecture change on a new programme.
Route A: domain by domain
Bring one contained domain onto ASG, for example the body or the exterior lighting, and keep the rest of the vehicle as it is. Expand the converted footprint vehicle by vehicle and model year by model year.
The interface to the untouched domains is built into the zone module. It translates their CAN, LIN or Ethernet messages, synchronises them into the shared vehicle state on each 1 ms commit, and sends messages back out in the format each sub-system expects. No separate gateway or bridge box is added.
Lower risk, because the change is contained and can be unwound. The payoff is partial and arrives gradually, and the vehicle carries two architectures for as long as the transition runs.
Route B: full transition
Re-architect the whole E/E platform onto ASG for a new programme. One ring replaces the buses and much of the power distribution; universal modules replace the ECU set; functions are written against the shared vehicle state.
The highest payoff, because the full harness reduction, the full ECU reduction and the development-speed gain all apply from launch. It needs a programme where the architecture is still open.
Side by side
| Domain by domain | Full transition | |
|---|---|---|
| Where it fits | An existing platform, mid-cycle | A clean-sheet programme |
| Scope | One domain onto ASG; the rest reached over CAN, LIN or Ethernet, translated at the zone module | The whole E/E architecture on ASG |
| Risk | Lower: the change is contained and reversible | Higher: it is the platform’s architecture |
| When the saving lands | Partial, on the converted domain | Full, from launch |
| Harness reduction realised | Proportional to the domain moved | The full 200–300 m target |
| Development-speed gain | On new functions in the converted domain | Across the whole vehicle programme |
| What it needs | A pilot domain, with its node inventory and I/O map; bus translation is built into the module | A programme slot and a full node inventory |
Where the saving compounds
Whichever route, the economics are a platform-scale effect. A per-vehicle difference in harness, control units and integration labour is multiplied by every unit built and by every year of the model cycle. The worked example shows the per-vehicle picture; the methodology page sets out how the figures are derived.
Software: who writes it
ASG is the hardware and the protocol. What runs on top of it - the functions that dim a light, fold a mirror, manage a battery - can be written in more than one way, and the right one depends on how much of that work an OEM or Tier 1 wants to keep in-house.
-
Hardware and direct control
ASG’s zone modules and protocol only. No ASG-authored application software - the OEM or Tier 1’s own team writes every function from the ground up.
-
Partnership development
ASG’s engineers work alongside the OEM or Tier 1’s own team to co-develop the software together.
-
Self-authored from documentation
ASG hands over full technical documentation with the platform, and the OEM or Tier 1 writes its own functions against it, in whole or in part, at its own pace. This is the default: every ASG adoption includes this documentation, and it is how most functions get written.
-
Full turnkey development
ASG writes the software entirely, against the customer’s own technical requirements.
Lighting is a good example of where this lands in practice: it is software written on the nodes, and if an OEM tells us how it wants its lights to behave, we can write that node software directly. The same applies to mirrors, windows and similar body functions.
More complex, safety-critical functions - ADAS, braking, battery management - are technically possible the same way, but full turnkey development is not the path we recommend as the sole route for them. The same principle that shapes our functional-safety position applies here: the vehicle-level safety case belongs to the OEM, so safety-critical software is best either co-developed in partnership or written entirely in-house, using our documentation. We will write it to specification if asked; it just is not where we point customers by default.
Security
Any software ASG writes, or reviews as part of a partnership, is developed to automotive-grade standards: secure by design, following ISO/SAE 21434 cybersecurity-engineering practice and current automotive security norms. We do not hold or claim a specific cybersecurity certification for it - the same principle as our functional-safety position - but the engineering discipline behind it is the same enterprise-grade practice the team has already delivered on production and demonstration programmes.
Where a programme wants more, additional hardening - for example secure boot, encrypted communication and update channels, or intrusion detection on the network - is available as an add-on, scoped to what that programme actually needs.
Questions
Can we pilot ASG on a single function?
Yes. A common entry point is one contained domain, for example body or exterior lighting, run on ASG while the rest of the vehicle stays as it is, reached through the zone module’s built-in bus translation.
Does a domain-by-domain transition need a separate bridge to the legacy buses?
No. The zone module translates CAN, LIN and Ethernet itself: it reads the legacy message, synchronises it into the shared vehicle state, and replies in the original format. The two architectures run side by side during the transition with no gateway box added.
Which route gives the numbers quoted on the site?
The full figures assume a full transition, because that is where the whole harness and the whole ECU set are replaced. A domain-by-domain move realises a proportion of them, on the domain it converts.
Which route do most OEMs start with?
A contained domain on an existing platform is the lower-risk way in. A full transition is usually tied to a new programme, where the architecture can be chosen from the start.