EMBEDDED SOFTWARE · AUTOSAR · MISRA C · ASPICE

Embedded Software for Production Vehicle Systems.

Agnile develops embedded software for automotive control units and safety-critical systems, spanning AUTOSAR Classic and Adaptive, MCAL and complex device drivers, diagnostics, communication stacks, bootloaders, and production-quality application software. Our teams work close to target hardware, integration constraints, safety requirements, cybersecurity controls, and release evidence.

Schedule a 60-minute callContact Us
AUTOSAR CLASSIC + ADAPTIVEASPICE LEVEL 2+MISRA C COMPLIANTPRODUCTION PROVEN

AUTOMOTIVE ECU SOFTWARE FOCUS

Automotive ECU Software Focus.

This page focuses on automotive ECU software, AUTOSAR, MCAL, CDD, diagnostics, communication stacks, bootloaders, and vehicle software integration. For broader firmware, RTOS, embedded Linux, gateways, OTA, and connected-device platforms, see Embedded & IoT Engineering.

Explore Embedded & IoT Engineering

CAPABILITY AREAS

Embedded software close to silicon.

AUTOSAR Classic & Adaptive

BSW configuration, RTE integration, application software components, Adaptive services, platform integration, and toolchain support.

MCAL & Complex Device Drivers

Low-level driver development, board bring-up, peripheral configuration, external device interfaces, sensor/actuator interfaces, and validation on target hardware.

Diagnostics & Communication

UDS, OBD, J1939, CAN, CAN-FD, LIN, FlexRay, Ethernet, SOME/IP, diagnostic event handling, and service implementation.

Application Software & Integration

Control application development, model-based design integration, hand-written embedded C/C++, software integration, static analysis, and release support.

WHAT WE DELIVER

What we deliver.

  • AUTOSAR configuration package
  • MCAL/CDD source
  • Integration guide
  • Test report
  • Static-analysis report
  • Release notes
  • Traceability matrix

ENGAGEMENT MODELS

How we engage on embedded software programmes.

Full AUTOSAR stack integration on a target MCU, MCAL or Complex Device Driver development for new silicon, or a focused diagnostic-stack delivery. We scope the actual work on the call.

  • ES-01·8–12 weeks

    AUTOSAR Stack Integration

    Full AUTOSAR Classic stack integration on your target MCU — architecture through release. BSW configuration (Vector / EB tresos), MCAL tuning, RTE generation, SWC integration, and release. Includes diagnostics, SecOC, and the build artefacts your CI consumes.

    ENGAGEMENT FLOW

    Architecture + ARXML
    2w
    MCAL + BSW
    4w
    RTE + SWC
    3w
    Diag + Release
    3w

    DELIVERABLES

    • Configured BSW + MCAL
    • Integrated RTE + SWC build
    • UDS/SecOC diagnostic stack
    • ASPICE-traceable evidence
  • ES-02·6–10 weeks per family

    MCAL / CDD Driver Development

    MCAL configuration for new silicon variants or Complex Device Drivers for vendor IP that doesn't fit AUTOSAR. Typical work: HSM, custom DMA, ECC, vendor-specific transceivers. We deliver the source, integration guide, and target tests.

    ENGAGEMENT FLOW

    MCAL config
    2w
    CDD development
    5w
    Integration + Verification
    3w

    DELIVERABLES

    • MCAL configuration set
    • CDD source + unit tests
    • Integration guide + sample app
  • ES-03·4–6 weeks

    Diagnostic Stack Implementation

    UDS / OBD-II / J1939 diagnostic stack tailored to your transport (CAN-TP, DoIP). Security access, ECU programming flow, DTC management, and routine control — with the service mapping document your vehicle programme needs at acceptance.

    ENGAGEMENT FLOW

    Service Mapping
    1w
    Stack Configuration
    3w
    Verification
    2w

    DELIVERABLES

    • UDS / OBD-II / J1939 stack
    • Security access (0x27, 0x29) implementation
    • Service mapping document

WHY AGNILE

What we do differently.

  • 01

    AUTOSAR Classic and Adaptive engineers in the same team. We carry both stacks, so when your domain-controller workload moves from Classic to Adaptive, the same engineers move with it.

  • 02

    Production-proven on AURIX, RH850, S32K, S32G, and TDA4. Code running on series ECUs under audit.

  • 03

    Vendor-stack agnostic — we work in Vector, Elektrobit, EB tresos, or whatever your existing toolchain runs.

  • 04

    MISRA C:2012 compliance enforced via Polyspace, Helix QAC, or LDRA — and the deviation rationale documented in the ASPICE evidence pack.

  • 05

    ASPICE Level 2+ delivery aligned to your existing process. We meet your assessor where they are.

STANDARDS DEPTH

Standards we work to.

The AUTOSAR layers, coding rules, and process standards we deliver against.

  • AUTOSAR Classic R20-11+

    Layered architecture for deeply embedded ECUs

    We deliver ARXML system designs, MCAL configurations, BSW integration with Vector / Elektrobit / EB tresos, RTE generation, and SWC implementations on AURIX, RH850, S32K production silicon.

  • AUTOSAR Adaptive R23-11+

    POSIX-based platform for high-performance compute

    ARA-API integrations, service-oriented architecture using SOME/IP, Adaptive Platform manifest generation, and POSIX application development for ADAS / AD domain controllers on S32G, TDA4, automotive Linux.

  • MISRA C:2012 + AMD3

    Coding rules for safety-critical software

    Polyspace, Helix QAC, or LDRA integrated into the build. Mandatory and required rules enforced; deviations configured with written rationale and bundled into the ASPICE evidence pack.

  • ASPICE

    Automotive SPICE process maturity

    Process areas SWE.1 through SWE.6 — system requirements, software requirements, architecture, design, code, and test bidirectionally maintained for ASPICE Level 2+ assessment.

  • ISO 14229 (UDS)

    Unified Diagnostic Services

    UDS sessions, security access (0x27, 0x29), routine control (0x31), DTC reading (0x19), ECU reset, and the ECU programming flow (0x34/0x36/0x37) — across CAN-TP and DoIP transports.

HOW WE BUILD — THE ECU LIFECYCLE

From ARXML to released ECU build.

Six stages, each with named AUTOSAR layers / standards and an explicit deliverable. Scroll to walk through what we deliver at each stage.

  1. 01

    Architecture & ARXML

    AUTOSAR Methodology

    We extract or build the system-level ARXML — ECU descriptions, system signal database, network topology, software-component contracts. Outcome: a configuration-managed ARXML the rest of the toolchain consumes.

    → System ARXML + ECU Extracts

  2. 02

    MCAL & CDD

    AUTOSAR BSW L1

    MCAL layer configured for the target MCU — MCU, PORT, DIO, CAN, FlexCAN, SPI, ADC, GPT. Complex Device Drivers written for vendor IP that doesn't fit AUTOSAR.

    → MCAL config + CDD source

  3. 03

    BSW Integration

    AUTOSAR BSW L2

    BSW stack integrated and tuned — OS, ComM, NvM, EcuM, BswM, WdgM, Crypto, DEM, DCM. Stack vendor split (Vector / Elektrobit / EB tresos) handled.

    → Integrated BSW + Build Pack

  4. 04

    SWC Implementation

    AUTOSAR App Layer

    Application Software Components developed against the RTE — runnables, interfaces, and inter-runnable variables. MISRA C:2012 compliance enforced via static analysis.

    → SWC source + reviews

  5. 05

    Diagnostics & Comms

    ISO 14229 / J1939

    UDS diagnostic services configured — sessions, security access (0x27), ECU programming (0x36/0x37), routine control. SecOC for secure messaging.

    → Diagnostic config + service mapping

  6. 06

    Integration Test & Release

    ASPICE SWE.4–6

    On-target integration tests covering BSW services, RTE behaviour, and SWC interaction. Release notes, change log, and ASPICE-traceable test report bundled.

    → Tested ECU build + ASPICE pack

CASE STUDY

What this looks like in practice.

Anonymised by request. References available on qualified enquiry.

Anonymised engagement summary. Customer identity and programme details withheld under NDA. Metrics reflect internally documented delivery outcomes.

GLOBAL VEHICLE PROGRAMME · ADAS DOMAIN CONTROLLER

AUTOSAR Adaptive bring-up on a TDA4 platform — Linux, ARA, SOME/IP.

CONTEXT

A global automotive engineering team was bringing up an ADAS domain controller on a TI TDA4VM platform running automotive Linux. The team had Classic AUTOSAR experience but no production Adaptive deliveries. They needed a working Adaptive Platform manifest, ARA service skeletons, and SOME/IP comms across six software components — under their existing ASPICE Level 2 process.

APPROACH

Agnile sized the manifest, modelled six service interfaces in ARA, generated POSIX-compliant application skeletons, integrated DoIP diagnostics, and wired up SOME/IP service discovery + binding. Test framework reused the team's existing GoogleTest harness with a target adapter. Ten weeks from manifest to release qualification.

WHAT WE DELIVERED

  • Adaptive Platform manifest set
  • Six service skeletons (ARA::com)
  • SOME/IP service discovery + binding
  • DoIP transport for UDS over Ethernet
  • ASPICE-traceable test pack (SWE.4 + SWE.5)

WHAT THE CUSTOMER GOT

  • First Adaptive build flashed at week 7
  • ASPICE Level 2 process compliance preserved
  • Internal team upskilled — handover at week 10

TDA4VM · 6 SWCs · ASPICE L2 · 10 weeks

FAQ

Talk to an embedded software engineer.

A 60-minute call: scope an ECU bring-up, plan a Classic-to-Adaptive migration, or sanity-check your AUTOSAR vendor split. We respond to qualified enquiries within one business day.