Inside AUTOSAR Classic Application, RTE, BSW and Hardware
How does AUTOSAR Classic separate vehicle-function software from the actual ECU hardware? This lesson builds the complete Classic architecture from Application Software and the RTE down through BSW, ECU Abstraction, MCAL and the microcontroller.
You will learn:
• Where Application Software sits
• What the Runtime Environment, or RTE, actually does
• Why Basic Software, or BSW, exists
• How Services, ECU Abstraction and MCAL fit together
• Where Complex Drivers belong in the architecture
• Why MCAL is part of BSW
• How a temperature measurement and cooling-fan request can be traced conceptually through the stack
• How to sketch the architecture in an AUTOSAR interview
This is Module 3, Lesson 19 of the Automotive Software & AUTOSAR From Zero course.
Subscribe if you want to build the architecture layer by layer instead of memorizing disconnected AUTOSAR acronyms.
▶ Watch the complete Automotive Software & AUTOSAR course:
• AUTOSAR Made Simple
Next lesson:
Application Software Layer — what belongs inside AUTOSAR Software Components and what should stay outside the application.
TimeStamps
00:00 Why AUTOSAR Classic needs layers
00:31 The complete Classic architecture
01:11 Application Software and SWCs
01:53 Runtime Environment — RTE
02:46 Basic Software — BSW
03:21 Services, ECU Abstraction, MCAL and Complex Drivers
06:09 Follow a temperature-to-fan path
07:08 Interview-ready architecture recap
AUTOSAR FROM ZERO — COMPLETE COURSE
• AUTOSAR Made Simple
Key Learning Points
• AUTOSAR Classic has three major software layers: Application Software, RTE and BSW.
• Application Software contains vehicle-function Software Components.
• The RTE forms the application-facing communication and integration boundary.
• BSW provides standardized ECU infrastructure and hardware abstraction.
• BSW includes Services, ECU Abstraction and MCAL, plus Complex Drivers as a distinct area.
• MCAL is part of BSW and is the hardware-facing standardized driver layer.
• Software does not directly provide actuator power.
• Layering reduces unnecessary coupling between vehicle-function logic and ECU hardware details.
Sources Used
AUTOSAR, Classic Platform, Current Release R25-11.
Used to verify the current release and the core architecture: Application Software,
RTE and BSW;
the RTE as the application interface;
and BSW subdivision into Services,
ECU Abstraction and Microcontroller Abstraction,
plus Complex Drivers.
The same official page also describes separation of hardware-independent application software from hardware-oriented BSW as a central architectural concept.
AUTOSAR, Release Event 2026.
Used to verify that R26-11 is scheduled for December 3, 2026 and therefore is not yet the current production release as of August 25, 2026.
ACCURACY NOTE
This lesson uses AUTOSAR Classic R25-11 as the currently verified baseline. R26-11 is scheduled for December 2026, so release-sensitive material should be rechecked when that release becomes available.
The Application → RTE → BSW → microcontroller representation is intentionally the beginner mental model. BSW is then expanded into Services, ECU Abstraction and MCAL, with Complex Drivers represented separately within the BSW architecture.
The temperature-sensor and cooling-fan path is a conceptual teaching flow, not a claim that every production ECU uses the same sensor interface, BSW modules, signal route, electrical output stage or configuration. Exact architecture depends on MCU, ECU hardware, OEM/Tier-1 design, AUTOSAR configuration, safety concept and implementation.
Likewise, “hardware-independent application software” should not be interpreted as automatic portability without engineering work. Real reuse still depends on compatible interfaces, configuration, integration assumptions and system requirements.
Finally, a microcontroller output is a control signal, not actuator power. A real cooling-fan implementation requires an appropriate electrical/power-driver stage between low-power control electronics and the motor.
Production automotive software additionally requires requirements engineering, functional-safety consideration, cybersecurity consideration, timing analysis, configuration, integration, validation and testing.
#autosar #AUTOSARClassic #automotivesoftware