Skip to content

Focus topic

AUTOSAR Integration & Configuration

Configure and integrate the layers of an AUTOSAR-based platform so application software runs on the selected microcontroller with defined, reviewable behaviour.

AUTOSAR-related work connects application components to hardware through configured basic software, a runtime environment and a microcontroller abstraction layer. The scope follows the selected platform and stack supplier, and can cover one module, one integration problem or the platform configuration of a control unit.

Layers of an AUTOSAR-based control unit

Application software reaches the hardware through configured layers. Highlighted layers are where configuration and integration work typically sits.

  1. Application software componentsProduct functions
  2. Runtime environment (RTE)Communication between components and services
  3. Basic software (BSW)Services, communication, memory, input/output
  4. Microcontroller abstraction (MCAL)Drivers for the selected microcontroller
  5. Microcontroller and boardHardware

What the work covers

The agreed assignment determines which activities are included and where the responsibility boundary sits.

Basic software configuration

Configure basic software modules for the control unit, including the services the application depends on, and keep the configuration consistent with system and network definitions.

RTE integration

Integrate software components through the runtime environment and resolve interface, timing and scheduling questions between components.

MCAL and hardware adaptation

Configure or adapt the microcontroller abstraction layer to the selected microcontroller, pin allocation and board design.

Platform and multicore integration

Bring configured layers, operating-system settings and supplier-delivered components into one build, including multicore platform integration where relevant.

Configuration baselines and component tests

Keep configuration under version control with the toolchain baseline, and support unit or component testing for the integrated scope.

Typical starting points

  • A new control unit needs its platform configured before application teams can integrate their components.

  • A microcontroller or board change requires the abstraction layer and dependent configuration to be adapted.

  • Supplier-delivered and in-house components disagree on interfaces or timing after integration.

Example engineering outputs

Outputs are assignment-dependent and agreed for each engagement.

  • Configured basic software and runtime environment for the agreed scope.

  • MCAL configuration aligned with the board and pin allocation.

  • Integration build and configuration baseline.

  • Component test results and records of open integration issues.

Common questions

Which AUTOSAR stack and tools do you work with?

The stack, configuration tools and licences are determined by the customer platform. Suitability for a specific stack and version is confirmed during technical scoping before work is agreed.

Can you take over only part of the platform?

Yes. The scope can be a single module, the abstraction layer for a new board or a defined integration task. The responsibility boundary with other teams and suppliers is stated in the assignment.

Do you also develop the application software?

Application and platform work are separate scopes. Embedded software development can be added where the assignment requires it, with its own defined responsibilities.

Part of

Embedded Software & Platform Engineering

Low-level software, platform configuration, drivers and embedded architecture, from hardware interfaces to integrated software baselines.

Discuss an AUTOSAR configuration, integration problem or platform change.

Describe the current state, the interfaces involved and the result you need. Leave confidential technical files out of the first message.

Talk to us