AUTOSAR Development Services, Classic and Adaptive

Let the function decide. Hard real-time control on a microcontroller — braking, powertrain, body, battery management — is Classic territory: static configuration, deterministic schedules, signal-based communication. High-performance functions that need runtime flexibility — ADAS pipelines, zonal compute, applications updated over the vehicle’s life — call for Adaptive on POSIX-capable silicon. Many current architectures run both, with Classic ECUs at the edge and Adaptive on the domain or central computers, so the real question is usually how the two interoperate rather than which one wins.

AUTOSAR development is configuration and integration of the standard platform: BSW, MCAL and RTE configuration, the communication, diagnostic and security stacks, and Adaptive services. Embedded software engineering is the code we write ourselves: MCAL-level and Complex Device Drivers, bootloaders and application software. Many ECU programmes need both, and Agnile can deliver them together as one work package.

It is the layered set of AUTOSAR Classic modules that gives software access to cryptography. The Crypto Service Manager (Csm) offers crypto services to applications and other BSW modules, the Crypto Interface (CryIf) routes jobs to Crypto Drivers backed by software or a Hardware Security Module, and the Key Manager (KeyM) handles keys and certificates. SecOC uses it to authenticate messages.

Yes. On Adaptive and Ethernet-connected Classic ECUs we configure SOME/IP service interfaces and service discovery, and DoIP as the transport for UDS diagnostics and reprogramming over Ethernet. Both are integrated with the security concept: diagnostic access through secure diagnostics, and service communication protected with SecOC or TLS according to the programme’s cybersecurity requirements.

It depends on scope rather than a rate card: the number of ECUs and BSW modules to configure, whether an ECU extract and communication matrix already exist, Classic versus Adaptive, the depth of security-stack work such as SecOC and HSM integration, ASIL requirements, and the number of release iterations. We quote each work package after a scoping call.

A Classic ECU with a usable ECU extract typically reaches an integrated, tested build in eight to twelve weeks. Security-stack roll-outs across a vehicle network, missing inputs or a new microcontroller target extend that. Adaptive Platform bring-up depends on the platform stack and the number of services and is scoped separately; team-extension engagements run as long as the programme needs.

Both, and the layers in between. Engagements range from pure BSW and MCAL configuration for a new microcontroller target, through Complex Device Drivers and RTE integration, to full application Software Component development against your requirements. We also take on rescue work — stacks that build but do not behave, integrations that stall before a milestone — where the fastest path is engineers who have seen the failure mode before.

As part of development, not a bolt-on review. The AUTOSAR security modules — Csm, CryIf, KeyM, SecOC — are configured alongside the rest of the BSW, key and freshness concepts are designed together with the network, and Hardware Security Module integration is planned with the MCAL bring-up. Because Agnile’s Automotive Cybersecurity practice sits next to the development team, the ISO/SAE 21434 Work Products assessors expect from the development phase — cybersecurity specifications, integration and verification reports — are produced from the engineering work itself rather than reconstructed after the fact.

Yes. Code is written to MISRA C guidelines with static analysis enforced in Continuous Integration, deviations are documented and justified rather than waved through, and delivery follows ASPICE-aligned engineering processes with bidirectional traceability from requirements through architecture to code and test. If your programme is assessed at a given capability level, we deliver inside your process framework so the work package never becomes an audit finding.

AUTOSAR Classic work runs on the established automotive microcontroller families — Infineon AURIX, NXP S32, and Renesas RH850 are the common targets — and AUTOSAR Adaptive work on POSIX-capable SoCs. On tooling we are deliberately neutral: we work inside whichever AUTOSAR toolchain and stack your programme has licensed, in your build system and your version control, so the configuration stays maintainable by your own team after handover.