AUTOSAR Explained: Classic BSW, Architecture & ECU Software

Explore the memory stack's non-volatile storage, preserving data after power off, and review its HAL and MCAL components—NVM service layer, MemIf, and Fee or EA drivers for flash or EEPROM.

Understand the NVM module that manages non-volatile data for EEPROM or flash emulation, including NV, RAM, ROM, administrative blocks, CRCs, headers, and MemIf mapping.

Abstracts the NVM details via the EA, providing a 32-bit virtual addressing scheme and uniform segmentation with configurable, virtually unlimited erase cycles and read/write APIs.

Configure the memory stack with Nvm and Fee modules, covering the Nvm common, block descriptors, ram and rom blocks, and read all and write all behaviors for ECU memory.

Explore the Autosar com stack, its purpose, and key components like PduR, can/lin interfaces, and drivers. Learn how signals from the oem become pdus for ecu communication across buses.

Explore the com transmission modes, direct and periodic, and learn how direct mode transmits a Pdu when a signal is sent via Com_SendSignal(), while periodic mode buffers signals.

Learn how Autosar com provides callbacks for pdu transmission and timeouts. It groups pdus into transmit or receive groups and uses Com_IpduGroupStop, Com_sendSignal, and Com_receiveSignal to manage buffering and deadlines.

Understand Com signal filtering with eight algorithms that pass or drop new values, then learn how Com packs signals into pdus, triggers ten-ms transmissions, and offers reception callbacks.

The com module collects signals from the application, prepares the PDU, and passes it to the lower layer through the PduR router, which abstracts LIN and CAN buses.

Explore how the PduR routing engine uses the input Pdu ID and interface to consult a routing table, select a destination index, and forward data with a target Pdu ID.

Discover how the PduR gateway routes CAN frames to LIN without application involvement, using PduR_CanIfRxIndication and LinIF_Transmit, and configure Pdu routes between COM stack modules.

Explore CanIf as an interface module that abstracts hardware drivers for upper-layer modules. Learn how it handles internal and external can chips and provides access to can and transceiver drivers.

CanIf initiates transmission via the CanIf_transmit interface for can pdus, selects the can driver, and uses the hardware transmit handle to pass id and data length for write and confirmation.

Explore how CanIf handles transmission confirmations in AUTOSAR, invoking CanIf_TxConfirmation callbacks, routing to PduR_TxConfirmation, and tracking interfaces for each Pdu, with reception indication services to follow.

Explain how CanSM coordinates controller modes for a CAN network via CanIf, performing sleep and wake transitions while the CAN driver carries out the hardware changes asynchronously.

Explore how CanIf groups PDUs into logical channel groups, map them to dedicated CAN channels, and use CanIf_setPduMode and CanIf_getPduMode to switch between CanIf_Offline, CanIf_Tx_Offline, CanIf_Offline_Active, and CanIf_Online.

Initialize the CAN driver to configure CAN controllers and their mailboxes, handle PDU transmission and reception via rx_indication, and notify the upper layer about bus off and wake up events.

Explore how the CAN driver translates Pdu content to hardware formats, triggers transmission, and handles CanIf tx confirmation through interrupt or polling modes, emphasizing data protection during buffer copy.

Understand how hardware events are detected by interrupts or polling status flags, with hardware-dependent polling options and callbacks in upper layers that can run in ISR or main context.

Understand how the can module initializes CAN controllers and configures baud rates via registers. CanSM decides state changes; the module provides Can_Init, Can_setBaudrate, Can_setControllerMode, and handles Pdu writes and Rx indications.

Configure the com stack from a CAN DBC by defining IPDUs and signals, set tx/rx time bases and transmission modes, and route PDUs through the PDUR between com and canif.

Discover how the runtime environment (Rte) sits at the heart of Autosar ECU architecture, realizing the interfaces of the Autosar virtual function bus and introducing the virtual function bus concept.

A software component is the main unit of an Autosar application that interacts with other components through ports, as shown by the doorlock manager using vehicleSpeed, actuators, and doorState.

Explore how ports enable interactions between software components by using typed port interfaces, distinguishing provided and required ports, and mapping operations like LockDoor() through ActuatorControl.

Explore how two atomic software components, door lock and door status, form a composition with ports and connectors, and how a virtual function bus connects them across ECUs.

See how the RTE triggers runnables through timing, initialization, data received, and external triggered events, driven by sender-receiver signals, illustrated by the DoorLockManager example.

Explore how the virtual function bus and the RTE realize an atomic software component via ports and port interfaces, with runnables for init and a 20 ms cyclic task.

Explore Autosar standardization and how tier two suppliers like Vector, Elektrobit, and ETAS provide ready to use software packages. Configure and integrate using Da Vinci, Geny, EB Tresos, and Isolar.

Explore autosar.org to access AUTOSAR standards and documentation, browse the classic platform, and explore releases, stacks, templates, tools, and service layer documentation.

Explore Autosar documentation sources, including SRS and SWS for the Com component, and learn how to read change histories, functional overviews, requirements, APIs, sequence diagrams, and configuration specifications.