Embedded · Field notes
The ground the decision stands on
Nine dimensions, five drawings checked against the primary documents, the legal situation off the road, and a teaching case with no client in it. Where a claim has a source, the source sits under it. Where there is none, the text says so.
The question
What make-or-buy actually hangs on
Not on the stack. On dimensions that come out differently per building block and that every variant multiplies — and the answer runs on three axes: build, buy, and in which model.
Licence versus own build
What the bought block costs per control unit and per programme — against the effort of building it yourself and keeping it current yourself.
Safety evidence
Who delivers the evidence, who maintains it through every change, and what happens when the supplier loses interest.
Tool lock-in
Who owns the configuration, what format it lives in, and whether a tool change is a migration or a restart.
Supplier dependence
What a switch costs when the vendor's prices, roadmap or ownership change — and whether a second path exists.
People
Which competence is in the house, which you would have to build, and which you can keep over time.
Time to start of production
What buying saves in months — and what integration eats back.
Maintenance across the lifecycle
Ten to fifteen years of care, updates and replacement: the cost after start of production usually exceeds the cost before it.
Intellectual property
What the company owns at the end — and what it has merely used.
The model
Buying is not one option but many: how it is licensed, what is delivered, and who maintains it over the service life. There are no verifiable public prices for this — anyone quoting you a licence bill without an offer is guessing. Which model you choose ties up money, tools and people differently.
Sources: the AUTOSAR partnership model (autosar.org) and the R25-11 release overviews. On the models: vendor stack prices are consistently non-public; the only publicly readable figures are the consortium's partnership fees — 10,000 euros a year for small companies up to 90,000 euros plus six full-time staff at the top tier (autosar.org, retrieved 31 Aug 2026).
The architecture, drawn
Two platforms, where they meet — and who supplies which layer
There are five figures, and they do not come from the same source. Three are drawn from the AUTOSAR R25-11 documents. The fourth, the supply boundary, is assembled from vendor statements and training material and carries an explicit label: common practice, not specification. It exists nowhere publicly, although it decides make-or-buy. The last one sets a widespread depiction beside the November 2025 state of the standard.
Classic Platform
At the highest abstraction level AUTOSAR distinguishes three software layers — application, runtime environment and basic software — running on a microcontroller. The basic software divides into four more: services, ECU abstraction, microcontroller abstraction and complex drivers.
- Application Layerapplication components — above the runtime environment the style changes from “layered” to “component”
- Runtime Environment (RTE)generated individually per ECU; neither application nor basic software
- Services Layersystem, memory, crypto, communication, off-board communication
- ECU Abstraction Layerseparates function from this board; the I/O abstraction sits here too
- Microcontroller Abstraction Layerusually supplied by the semiconductor manufacturer
- Microcontrollerthe hardware — in the official picture the substrate, not a software layer
Complex Drivers — a layer of its own, spanning from the hardware to the runtime environment. For everything AUTOSAR does not specify, that has very hard timing constraints, or that comes from a migration. It is not an extra but the only intended opening: non-standard modules enter as complex drivers, and further layers cannot be added. In agricultural machinery ISOBUS is classically integrated right here, as a complex driver alongside the basic software. Nothing prescribes that; it is the route the tool world has taken for years.
Configured through ARXML/ECUC — the tie to the toolchain is created here, not in the code.
Adaptive Platform
Adaptive applications run on ARA, the AUTOSAR runtime for adaptive applications. ARA consists of interfaces provided by functional clusters — not modules, and not a further stack of layers.
- Adaptive Applicationsrestricted to the PSE51 single-process profile
- ARA — Functional Clusters21 clusters in R25-11, grouped into foundation, platform services and others
- POSIX OSthe platform OS itself must be multi-process capable
- Machinephysical, virtualised or a container — AUTOSAR's own term
Communication Management (ara::com) — one cluster among many — and still the only intended path. Architecturally, communication management is a functional cluster like the others, not a layer above them. Its weight comes from elsewhere: because the single-process profile provides no on-device inter-process communication, the specification makes it the only explicit interface between adaptive applications. That is why it is highlighted here, not elevated.
Two official views of the same clusters: by group (foundation, platform services …) and by category (runtime, communication, storage, security, safety, configuration, diagnostics).
Where the two platforms actually meet
Since R25-11 the classic platform also carries service-oriented communication over DDS. What is shared is not a component and not a layer but a protocol: the classic side adopts the adaptive side's service discovery, explicitly for compatibility across both solutions. The building blocks for it sit inside the stacks, not above them.
Who supplies which layer — the drawing that does not exist publicly
This is the line on which make-or-buy is decided, and no public layer diagram marks it. It is not a standard but common practice — and the topmost boundary is a matter of negotiation, not technology.
- OEM or supplierapplication components, integration, evidence — and more or less of it depending on the model
- Stack vendorhardware-independent basic software and the tool that generates the runtime environment
- Semiconductor manufacturermicrocontroller abstraction and operating system, plus the matching generators
Movable: some manufacturers license the base software themselves and pass it on pre-integrated, others only specify and leave implementation and integration to the supplier. Large suppliers build their own base software and thereby act as vendors themselves.
How it gets drawn — and what the standard has said since November 2025
This figure contradicts another one. The widespread coexistence depiction shows the classic platform on the bus, the adaptive one on Ethernet, and a gateway ECU in between translating signals into services. It is not wrong, only no longer complete. Since R25-11 there is a second route that does without that translator. Where protocols, data models, networks or security boundaries diverge, the gateway is still needed.
Classic versus adaptive
Ten differences — and where each one comes from
The widespread comparison has circulated in trade articles for years, usually without a source. Here it carries provenance: verified means read against an AUTOSAR primary document, unverified means a vendor claim with no evidence. Two of ten rows survive that check — the rest is plausible and unevidenced.
- Operating system
- Classic platformOSEK/VDXAdaptive platformPOSIX, PSE51 profile
- ✓Verbatim in the AUTOSAR platform design document R25-11: “PSE51 interface, a single-process profile of POSIX standard”.
- Language
- Classic platformCAdaptive platformC++
- ✓The adaptive codebase sits at C++17 minimum per the R25-11 release overview.
- Communication
- Classic platformsignal-orientedAdaptive platformservice-oriented
- !Out of date since R25-11: the classic platform has carried service-oriented communication over DDS since November 2025. The row holds for older releases.
- Execution
- Classic platformdirectly from ROMAdaptive platformload, then execute
- ?Plausible and uncontested in substance, but unevidenced as phrased.
- Runtime updates
- Classic platformnoAdaptive platformyes
- ?Uncontested as an adaptive design goal; the absoluteness of the “no” is not evidenced.
- Scheduling
- Classic platformstaticAdaptive platformdynamic
- ?Common description, with no source given in the original depiction.
- Real time
- Classic platformmicrosecondsAdaptive platformmilliseconds
- ?Figures without evidence. The order of magnitude follows hardware and configuration, not the platform.
- Processing power
- Classic platformabout 1,000 DMIPsAdaptive platformover 20,000 DMIPs
- ?Vendor figures with no source. Not load-bearing for a decision.
- Safety requirement
- Classic platformup to ASIL DAdaptive platformfrom ASIL B
- ?Unevidenced and misleading: the classification follows the hazard in the vehicle, not the platform choice.
- Functionality
- Classic platformfixedAdaptive platformflexible
- ?A characterisation, not a verifiable statement.
| Aspect | Classic platform | Adaptive platform | Provenance |
|---|---|---|---|
| Operating system | OSEK/VDX | POSIX, PSE51 profile | ✓Verbatim in the AUTOSAR platform design document R25-11: “PSE51 interface, a single-process profile of POSIX standard”. |
| Language | C | C++ | ✓The adaptive codebase sits at C++17 minimum per the R25-11 release overview. |
| Communication | signal-oriented | service-oriented | !Out of date since R25-11: the classic platform has carried service-oriented communication over DDS since November 2025. The row holds for older releases. |
| Execution | directly from ROM | load, then execute | ?Plausible and uncontested in substance, but unevidenced as phrased. |
| Runtime updates | no | yes | ?Uncontested as an adaptive design goal; the absoluteness of the “no” is not evidenced. |
| Scheduling | static | dynamic | ?Common description, with no source given in the original depiction. |
| Real time | microseconds | milliseconds | ?Figures without evidence. The order of magnitude follows hardware and configuration, not the platform. |
| Processing power | about 1,000 DMIPs | over 20,000 DMIPs | ?Vendor figures with no source. Not load-bearing for a decision. |
| Safety requirement | up to ASIL D | from ASIL B | ?Unevidenced and misleading: the classification follows the hazard in the vehicle, not the platform choice. |
| Functionality | fixed | flexible | ?A characterisation, not a verifiable statement. |
✓verified against a primary document!out of date since R25-11?vendor claim, unevidenced
Why this sits here rather than on a cheat sheet: **anyone choosing a platform from this table is choosing eight tenths of the way on unevidenced claims.** The two verified rows are also the only ones that carry a decision — the OS profile and the language determine which tool chain, which people and which verification options are available at all.
Comparison after a widespread market depiction (vendor article, retrieved 1 September 2026); the “provenance” column verified against the AUTOSAR platform design and release overview documents R25-11. No third-party graphic used.
Where the arithmetic tips
Off the road, a different arithmetic applies
AUTOSAR describes its work as developed for automotive applications, and since 2016 it has explicitly opened up beyond them. Underneath, the arithmetic is still passenger-car arithmetic: high volumes across which licences and tool chains spread. That is my thesis; AUTOSAR says it nowhere. Off the road it tips. Small series, long service life, many variants, and regulation that cuts differently. Tractors, trailers and towed equipment (categories T, R and S) fall outside UN R155. R156 names them explicitly: M, N, O, R, S and T, provided the vehicle permits software updates. On top of that the Cyber Resilience Act applies, and for agricultural and forestry machinery the relevant series is ISO 25119, not ISO 26262. Carry the passenger-car arithmetic over here and you buy a platform your volume will never repay, and you often justify the purchase with a regulation that does not reach these vehicles at all.
Sources: UN regulations R155 and R156 (UNECE); Cyber Resilience Act (EU) 2024/2847, application 11 Dec 2027, reporting duties from 11 Sep 2026; Machinery Regulation (EU) 2023/1230 Art. 2(2)(i), application from 20 Jan 2027; ISO 25119 series; AUTOSAR R25-11 standard documents (disclaimer) and “Openness for non-Automotive Applications” (since 2016). R156, section 1, verbatim: “This Regulation applies to vehicles of Categories M, N, O, R, S and T that permit software updates.”
Where AI helps
AI produces evidence. A human decides.
The bottleneck is not judgement but stocktaking: the artefacts exist, yet nobody can read them in reasonable time. That is where AI helps — and only there.
Reading the inventory
Holding configurations, specifications, requirements and supplier contracts against actual demand — in days instead of quarters.
Extracting the real variant matrix
Pulling out of existing artefacts which variants actually exist — instead of estimating them in a workshop.
A human signs. Where an agent may write at all, and what must additionally be true when it does, is set out as a rule in the Platform Rulebook (§ 4) — four zones, separated by verifiability. The stocktake runs as an engagement on your infrastructure; contracts and prices do not leave your house.
Sources: tool vendor product announcements 2026 (test environment with AI package, 08/2026; AI assistant on a platform certified for functional safety; integration automation); configuration by language model at publication stage (IEEE, ATLAS); limits per ISO 26262-8 (tool confidence level) and ISO/PAS 8800 (AI in the product, not in the tool).
Gaps, opportunities, AI
Where it jams, and what becomes possible now
Leading a field means naming its fracture points. Four of them, as a position.
The toolchains leave gaps
Industry research from 2026 — a commercial vehicle manufacturer together with a university — describes the shift precisely: on the adaptive platform, complexity has moved from integration into comprehensibility. Developers reverse-engineer their vendor's behaviour or re-implement minimal abstractions of their own; the friction points named there are explicitly vendor lock-in and the weight of the configuration files. Where the chain breaks, hand work appears — and hand work does not scale across variants.
The licence models no longer fit the architecture
The models come from a world of fixed control units; the architecture has become service-oriented. Since 27 November 2025 the classic platform also carries service-oriented communication over DDS, with its own module and explicit compatibility with the adaptive side's service discovery. The dividing line along which many contracts are cut no longer runs there technically. If you do not resolve that in the contract, you pay for the architecture twice.
Open-source building blocks are maturing
Building open is real at protocol level and not at platform level. In agricultural machinery AgIsoStack++ is a live open ISOBUS stack under MIT. For classic basic software and the adaptive platform there is no complete, production-ready, demonstrably conformant open-source implementation. There is movement all the same, and it runs in a direction you only see on second look. Eclipse OpenBSW is alive, but for licensing reasons it may not contain AUTOSAR's basic software and runtime environment at all. Instead of ara::*, Eclipse S-CORE deliberately builds its own interface world. And since 20 August 2026 CAPI 1.0 has put an adaptive implementation of the fifteen core functional clusters openly on GitHub, at the level of adaptive release R20-11, under AUTOSAR's own note “for informational purposes only”. Anyone may read it; only a licence holder may use it. The fence stands where it stood; what is new is that you can see through it. How wide the gap runs shows in the largest community-curated embedded list: 9,063 stars, last maintained in August 2026 — and zero hits for ISO 26262, zero for MISRA, zero for ASIL. Its “Automotive” section holds four entries; both AUTOSAR ones describe themselves as an example and a study environment. Not every building block needs a licence agreement. But every one needs someone accountable for it.
AI moves the make-or-buy boundary
If AI lowers the cost of building in-house, building blocks that were buy-only yesterday become buildable again — not all of them, and not everywhere. That is my thesis and I mark it as one: it is not evidenced, there are only vendor figures. What is documented is which products exist in 2026: test and integration. How widely they run in production is not documented. Configuration by language model is research.
Sources: industry research 2026 (commercial vehicle manufacturer and university) on the adaptive platform; AUTOSAR CP release overview R25-11 (DDS on the classic platform, 27 Nov 2025); Eclipse OpenBSW (licensing note on base software and runtime layer); AgIsoStack++ (MIT), maturity checked 31 Aug 2026.
Teaching case
Model, not a client caseOne ECU family, four questions, one record
Worked through on a model programme: no company, no brand, no invented prices. Four ECU classes, classic and service-oriented mixed, mid volume, twelve years of service life, an existing fleet that grew over time. Exactly the situation in which the decision gets hard.
The architecture
What gets built, and how is it cut?
The four classes do not get the same answer. Where hard timing matters it stays classic; the high-performance computer becomes service-oriented; in between sits the question whether the connection is a component of its own or a property of both sides. The cut decides what a change costs later — not the choice of vendor.
Decision rights
Who is allowed to decide — and who must be able to overrule?
The part almost nobody writes down, and the one that costs most programmes. Not every decision belongs to the same place: the architectural cut belongs to architecture, the choice of supplier to procurement, the release to safety — and none of them may silently overwrite another. So it is recorded per building block who decides, who must consent, who is consulted and who is merely informed. If that is not settled, the schedule decides in the end.
The legacy
What migrates, what stays, what gets a bridge?
An existing fleet is not switched over, it is carried across — in parts, over years, while it keeps running. Three categories are enough: what comes along, what stays until it runs out, and what gets a bridge because it has to survive both. The most expensive answer is the fourth one nobody says out loud: all of it at once. What the path costs, incidentally, is stated by no public source. Any figure comes from projects nobody discloses, which makes it uncheckable.
Scaling in the age of AI
What has to be architecturally true for AI to help at all?
AI helps where holdings are machine-readable and decisions traceable — configuration, requirements, contracts, test cases. An architecture that does not allow for this does not get faster with AI, only less legible. The limit is set by § 4 of the rulebook: writing happens where a machine can refute. Cut today, and you cut for both.
Common questions
What gets asked
On the subject: AUTOSAR as of 2026
No — tractors, trailers and towed equipment fall outside the scope of R155. Three caveats belong with that answer: R156 on software updates names exactly those vehicle categories explicitly; the Cyber Resilience Act covers agricultural machinery in full from 11 December 2027, with reporting duties from 11 September 2026; and the industry is building ISO 24882, an off-road cybersecurity standard aligned with it: circulated as a draft since October 2025, with the ballot on that draft closed as of September 2026, and not published as a standard. Deciding architecture today means deciding for the Cyber Resilience Act regime, not for quiet.
For agricultural and forestry machinery the relevant series is ISO 25119, derived from IEC 61508 and more compact than ISO 26262. It is calculated in AgPL from QM to e and the SRL derived from it — not in ASIL. ISO 26262 becomes relevant where road approval enters the picture: one manufacturer had its off-highway control unit family certified additionally under ISO 26262 for exactly that reason. Confuse the two worlds and you plan for the wrong evidence — and find out late.
The specifications are readable, commercial use needs a licence – the route is partnership, from EUR 10,000 a year for small firms. How far that fence reaches shows in the Eclipse Foundation's open basic-software project: the standard's basic software and runtime layer are explicitly out of scope there for licensing reasons. There is no live open classic stack. The licence does not forbid you from implementing it yourself; it requires the partnership, and after that it costs you the work. In practice, conformant therefore almost always means buying, and building open means building outside conformance – two decisions often treated as one.
Coexistence is designed in, not tolerated: the shared foundation enforces interoperability, the November 2025 release explicitly strengthens the interplay between both sides, and service-oriented communication on the classic platform adopts the adaptive side's service discovery so the two fit together. The adaptive platform does not replace the classic one; the classic one stays where hard determinism counts. What does not exist is any public figure for migration cost. Anyone quoting you one without opening the data behind it is quoting an estimate you cannot check.
As a product no, as research yes – as of August 2026. What is available are AI agents for test and integration: a test environment with an AI package, an assistant on a platform certified for functional safety. That the products exist is documented; how widely they run is not. Generating configuration files by language model is publication-stage, not a deliverable tool. Where an agent may write at all is governed by § 4 of the rulebook – by verifiability, not by confidence.
In real programmes the two exist side by side. A separate gateway is not a general precondition for that: since R25-11 the classic platform also carries DDS and a service discovery aligned with the adaptive platform. Where protocols, data models, networks or security boundaries diverge, a gateway remains sensible or necessary. For the make-or-buy question that means it is asked twice, because the building blocks, suppliers and competences of the two worlds barely overlap — not because something must sit in between.
Every answer in this section rests on a dated primary source: the AUTOSAR R25-11 documents, UN regulations R155 and R156, the Cyber Resilience Act (EU) 2024/2847 and the ISO 25119 series.
On working together
Buying is often right — for the base, almost always. The expensive mistakes sit one level up: buying what the house must be able to do permanently, or building what a vendor maintains for many customers. The answer differs per building block, and it changes with every variant. Hence a matrix, not a policy.
It can read large inventories: configurations, requirements, contracts — and pull the real variant matrix and an evidenced template out of them. It cannot decide what the house must master and what it may buy: that is a question of strategy and accountability, and underneath it stands a signature, not an output.
From your inventory: contracts, offers, effort data, staffing. Every line of the file points at its artefact. Where a number is an estimate, it says so — a file that presents model values as measurements would be worthless.
No. I sell no building block and receive nothing from any vendor — which is why the file can recommend buying per block, and often does. What I deliver is the decision between the paths, evidenced and signable.
No, and that is the point. Your specialists or the vendor configure the stack. What sits with me is the lead: knowing the landscape completely, systematising the decision and being accountable for it — as chief product owner, head of engineering or platform lead for a fixed period. The expensive mistakes in these programmes are rarely configuration mistakes. They are decision mistakes.
No. Approvals and standards testing sit with the test bodies and your specialists for them; I name no standard I cannot evidence. What the file contributes: it makes visible who delivers and maintains which evidence — one of the dimensions of the matrix.