Engineering · Embedded Software
AUTOSAR Development Services, Classic and Adaptive
BSW and MCAL configuration, RTE integration, application Software Components, and the security stack most teams leave until last. Agnile’s Embedded Software engineers deliver AUTOSAR Classic and AUTOSAR Adaptive work packages for OEM, Tier-1, and Tier-2 programmes — from a single Complex Device Driver to complete ECU software integration.
What do AUTOSAR development services cover?
AUTOSAR development services cover the engineering of ECU software on the two AUTOSAR platforms: configuring the Basic Software (BSW) and MCAL against the target microcontroller, generating and integrating the RTE, developing application Software Components, and bringing up the communication, diagnostic, and security stacks. Agnile delivers this work within its Embedded Software Engineering practice — as scoped work packages or embedded team capacity — with the Crypto Stack, SecOC, and Hardware Security Module integration that most teams treat as a specialist add-on handled as a core competence.
Offerings
What We Deliver
Four areas, one team. The engineers who configure the BSW also write the application code and integrate the security modules — which is exactly why the security work does not stall the schedule.
AUTOSAR Classic Development
The Classic Platform remains the backbone of hard real-time ECUs, and most of the effort is in the configuration. We configure BSW and MCAL stacks against your target microcontroller, develop Complex Device Drivers where the standard stack ends — our guide to secure MCAL and CDD development shows how we approach that boundary — and bring up communication stacks across CAN, CAN FD, and Automotive Ethernet. Diagnostics is covered end to end: UDS services, DoIP for Ethernet-connected ECUs, and the security-access behaviour that assessors increasingly probe.
AUTOSAR Adaptive Development
For high-performance ECUs, the Adaptive Platform replaces static schedules with a POSIX-based, service-oriented architecture. We design and implement Adaptive Applications against ara::com, model services in SOME/IP with runtime discovery, and handle Execution Management, State Management, and platform bring-up on POSIX operating systems. For programmes heading toward the software-defined vehicle, we structure applications so they can be updated and extended over the vehicle’s life — which is the point of Adaptive in the first place.
Security Stack Specialization
Many AUTOSAR teams treat the security modules as someone else’s problem; for us they are the core competence. We configure and integrate the Crypto Stack — Csm, CryIf, and KeyM, deploy SecOC for authenticated on-board communication, and carry out Hardware Security Module integration from key provisioning to crypto offload on HSM-equipped silicon such as Infineon AURIX, NXP S32, and Renesas RH850. Secure Boot, Secure Flashing, and key management land in the same work package.
MISRA C and ASPICE-Aligned Development
Delivery quality is process-backed, not asserted. We write to MISRA C guidelines with static analysis gates in Continuous Integration, keep bidirectional traceability from requirements through architecture to code and test, and align delivery with ASPICE expectations so our work packages drop into your assessed processes without friction. Where your ECU carries ASIL A–D requirements, development runs inside your ISO 26262 process.
Comparison
AUTOSAR Classic vs AUTOSAR Adaptive
The platforms are complements, not competitors — a current vehicle architecture typically runs both, Classic at the edge and Adaptive on the domain and central computers. The condensed comparison is below; our AUTOSAR Classic vs Adaptive guide covers the decision in depth, including migration paths.
| Dimension | AUTOSAR Classic | AUTOSAR Adaptive |
|---|---|---|
| Typical use cases | Hard real-time control on resource-constrained microcontrollers; function set fixed at build time | High-performance, service-oriented applications that evolve over the vehicle’s life — the SDV workload |
| Communication | Signal-based: CAN, CAN FD, LIN, FlexRay, and Automotive Ethernet with statically configured routing | Service-oriented: SOME/IP over Automotive Ethernet with runtime service discovery |
| Safety and security patterns | Static schedules and OS partitioning for ASIL A–D coexistence; SecOC message authentication; Crypto Stack backed by an HSM | POSIX process isolation and Identity and Access Management; TLS alongside SecOC; managed secure updates |
| Typical ECUs | Body controllers, powertrain and battery management, braking and chassis, gateways | ADAS domain controllers, zonal and central high-performance computers, telematics units |
Security Engineering
ISO/SAE 21434 Evidence, Produced from Development
UNECE R155 pushed cybersecurity evidence into every serious AUTOSAR programme, and ISO/SAE 21434 expects a large share of its Work Products to come from the development phase — not from a compliance team writing documents after the code has shipped. When the engineers doing the AUTOSAR work know the standard, that evidence falls out of the engineering itself:
- Requirements traced into configuration. SecOC freshness and key concepts, Csm job configuration, and Secure Diagnostics access control are documented as they are designed — not reverse-engineered for the assessor later.
- Specifications aligned with the concept phase. Cybersecurity specifications at the software architecture level stay traceable to the Cybersecurity Concept and Cybersecurity Goals your TARA produced.
- Verification evidence from real test campaigns. Integration and verification reports are generated from the communication, diagnostic, and security-stack testing that the programme runs anyway.
For the process side — CSMS build-out, TARA, and the full 42 Work Products — see our ISO/SAE 21434 consulting practice. On AUTOSAR programmes the two engagements interlock: one team writes the code, the other makes sure the evidence holds up in front of an assessor.
Engagement models
Three Ways to Engage
Feature and Work-Package Delivery
A defined scope delivered against milestones — a BSW configuration for a new ECU, a Complex Device Driver for a custom peripheral, a SecOC roll-out across a vehicle network, or an Adaptive service migration. Fixed deliverables, clear acceptance criteria.
Team Extension
Agnile engineers embedded in your AUTOSAR programme — working in your toolchain, your build system, and your reviews, carrying configuration, application, and integration work as part of the team for as long as the programme needs it.
Integration and V&V Support
Bring-up, integration debugging, and Verification & Validation for AUTOSAR stacks — from communication timing analysis to Fuzz Testing of the diagnostic and security surfaces, run together with our Automotive Cybersecurity practice.
FAQ
AUTOSAR Development Questions
Scope Your AUTOSAR Work Package
A 60-minute scoping call: bring your ECU list, your integration blocker, or the security modules nobody on the team wants to own. We respond to qualified enquiries within one business day.