AUTOSAR COM Stack

Explore CAN, the controller area network, and its bus-based, bidirectional communication between ECUs, showing how the CAN bus reduces wiring complexity in automotive and beyond.

Learn how a CAN bus uses frames and arbitration to transmit messages between nodes, with data and RTR frames, dominant bits, and 11- or 29-bit identifiers.

Explains the can frame structure, including the rtr bit, 11- and 29-bit identifiers, the six-bit control field and its dlc, and the data, crc, and ack sections.

Understand transmitter and receiver nodes in Autosar com stack: idle recessive state, broadcasting and receiving frames, and how local intelligence and a filter use the identifier field to select frames.

Broadcast a frame from node b onto the bus; each node’s filter checks identifier bits to decide entry. Node d matches and receives the frame.

Explain frame arbitration on the CAN bus with three nodes, showing how the dominant zero bits outrank recessive one bits in the arbitration field and 11-bit identifiers determine the winner.

Discover how bit timing keeps CAN bus nodes synchronized amid clock tolerances, as the bit time splits into four segments with time quanta, SJW, and the sample point.

Explore how bit stuffing enables 100% synchronization in Can frames by inserting an opposite polarity after every five bits. Edge timing uses time quanta to align bit times.

Examine how CAN nodes detect bit errors, stuff errors, form errors, and CRC/acknowledgement errors, send error frames, and manage transmit/receive error counters across active, passive, and bus-off states.

Explain how the CAN protocol uses error frame and overload frame to handle errors and delays, detailing six dominant bits and eight recessive bits for the error flag and delimiter.

Explain the can physical layer with shielded twisted pair wiring, where differential voltage on high and low signals defines dominant or recessive bits, and termination prevents reflections per ISO 11898.

Explore how the can driver and can module provide a microcontroller independent API to manage multiple can controllers in one can hardware unit, including rx/tx callbacks and mailbox buffers.

Explore Autosar can stack terminologies such as can controller, can hardware unit with ram and buffers, hardware object, cam driver, and priority inversion concepts for network arbitration and channel control.

Explore inner priority inversion with a single transmit buffer, where a low-priority message blocks a higher-priority one waiting for the bus; multiple transmit buffers prevent it.

Explain outer priority inversion with a two-node can bus example where a high-priority message waits for a lower-priority one due to interframe space, and avoid it by shortening the gap.

Initialize the can module for on-chip or off-chip controllers, with the port driver handling i/o, SBI interaction for off-chip, Gan module using synchronous APIs without callbacks, and OS counter polling.

Manage the can driver state machine with two states, can uninitialized and can ready, initializing controllers via can init and starting each with can set controller mode started.

explains the four CAN controller states—uninitialized, stopped, sleep, and started—and how software services and hardware events drive state transitions via interrupts or polling, with callbacks updating software and hardware states.

Describe can controller state transitions from uninitialized to stopped by init, and between stopped, sleep, and started via set baudrate and set controller mode, hardware wakeup and bus off events.

See how the can driver converts lpdu data to a hardware format, transmits to the microcontroller, and uses interrupt or polling confirmations; reception copies data and classifies frames.

Detect wake ups via interrupt or polling in autosar com stack; the can driver informs ecu state manager, who validates wake ups and triggers MQ module via callbacks.

Explain reentrancy criteria for can functions, ensuring atomic variables and single thread context, and enable hardware timestamping for ingress and egress timestamps; review development and runtime errors.

Learn CAN FD support and flexible data rate, switching to a higher baud rate during arbitration, with configurable baud rate and FD frames up to 64 bytes.

Standardize Autosar CAN APIs across vendors, enabling modules to share function names with vendor-specific logic.

Explore canned can configurations with tools or Excel, generate modules and dot c/dot h files, resolve generation errors, and configure key parameters like baud rate, bit timing, and controller settings.

The can interface module in autosar layered architecture sits in the abstraction layer between the mql layer and services layer, covering canim, can tp, and pdu router.

The lecture introduces the can interface as a hardware‑independent layer that bridges upper communication layers and the can driver, handling transmit, receive, error notifications, and state changes.

Introduce can terminologies, including can protocol data unit with identifier and length, can service data unit, kernel pdu, hardware receive and transmit handles, and physical channel with transmit buffer pool.

The can interface coordinates with the can driver, PDU router, and comm module to send and receive PDUs, using CAN TP for larger frames and ensuring data integrity with buffers.

Explore three CAN interface modes: interrupt, polling, and mixed—showing how ISR-driven events, periodic flag checks, and combined approaches govern CANIF operations, including write, read, wakeup, and transceiver handling.

Describe hardware object handles for transmission and reception, showing how HOH and HRH act as abstract references to CAN mailboxes and map to CAN driver interfaces and registers.

Explore hardware receive handles for basic and full can reception with canid filtering, and hardware transmit objects mapping to controller mailboxes for basic or full can transmission, with buffers.

Illustrate how a network uses multiple physical channels of can controllers and transceivers, with one-to-one and one-to-many mappings, and how wakeup and sleep requests flow via the can driver.

Explore static and dynamic lpdu handling in autosar com stack, detailing id, data length, and data flow between lower and upper layers, and runtime can-id filtering.

Cover basic can versus full can reception and transmission, with software acceptance filtering to pass predefined can IDs, and initialize Can.if via the ECM module to map to drivers.

Transmit data requests flow through can interface by validating initialization, selecting the correct can driver and hardware object, and calling can write to can controller, returning E_OK or E_NOT_OK.

Enable transmit buffering to store lpu requests in the can mailbox or lpddr2 buffer, fetch data via trigger transmit, and guarantee data integrity with exclusive areas and confirmations.

Enable multiple can driver support by configuring Caniff to map can drivers to a common interface, deriving SDH/HRH mappings from the LST and translating parameters to the canned driver.

Explore sequence diagrams for transmit requests in single and multiple can-driver configurations, detailing upper-layer input, LPU handling, hardware handles, and transmit confirmation flows.

Explain the reception flow in the Autosar com stack, including CAN driver input, LPU data handling, software filtering, data length checks, and forwarding to upper layers via PDU indications.

Learn how the can SME and can driver coordinate controller state transitions for multiple can controllers, including wakeup validation, NM message handling, and bus recovery.

Examine the sequence diagram of the Statcan network, focusing on the can controller, can driver, can interface, and upper layer interactions for controller mode indications and start transitions.

Group lpds into dedicated can channels tied to network a and network b, enabling channel-level mode control, switching between offline active and online with can_if video mode APIs.

Apply software receive filtering for can networks, using basic or full can, can ID ranges, and algorithms like linear, table, or hash search to route PDUs to upper layers.

Ensure data integrity by protecting shared transmit and receive buffers with critical sections and managing controller interrupts, while performing data length checks against configured pdu lengths.

Follow can controller receive-indication sequence diagram with interrupt. The driver copies data to a temporary buffer, then passes it to upper layer after software filtering and data length check Eaoc.

Handle notifications for multiple can drivers by processing interrupts from can controllers, applying software filtering and data length checks, and notifying the CanIf upper layer before copying data.

The lsda dispatcher inside canif identifies the destination upper layer for a received lz2 and dispatches receive indications; it also handles tx confirmations after lpu transmission, with configured notification services.

Polling mode handles transmit, receive, and errors via software, with scanf notification unchanged across polling and interrupt modes and per-controller configuration harmonized.

Explore partial networking to wake up selected ECUs while others sleep in low power mode, and see how the PA and TX filters on CAN interface decide which PDUs pass.

Explore CAN FD support for high baud rates and 64-byte payloads, with driver and interface configurations to map conventional and CAN FD frames via id type handling.

When enabled, security event reporting sends can fc errors, adc errors, state parser transitions, and bus off events to the IDs module, flagging suspicious can activity.

Identify development and runtime errors in the canif module, such as invalid can id, hardware object, pdu id, controller id, wakeup or transceiver settings, and length violations.

Demonstrate bus-off detection and recovery in the Autosar COM stack, guiding the can controller into stop mode, notifying the upper layer, and restarting via the recovery algorithm and can API.

Explore the nif and canif api set in autosar com stack, covering initialization, controller mode, transmission, reception, and transceiver wakeup and baud rate configuration.

Explore callback notifications in the Autosar com stack that enable CanIf to interact with can modules through transmit checks, PDU handling, buffer size validation, and controller mode or error notifications.

Understand mandatory interfaces. Enable can driver interaction via get controller error state, get controller error counter, set controller mode, write; use enter and exit exclusive area for data integrity.

Explore configurable interfaces in the autosar com stack, generating APIs from caniff configuration to enable upper and lower layer interactions for PDU transmission, confirmation, and wake-up events.

Explore detailed configurations for the autosar com stack, including caniff modules, private and public cfg, init cfg, rcs pdu cfg, tcs pdu cfg, and transceiver, driver, and hrh mappings.

Explore can tp, the transport protocol between pdu router and can interface, enabling segmentation and reassembly of data beyond eight or sixty-four bytes with first, consecutive, and flow control frames.

Explain CAN flow control per ISO 5765, detailing single, first, consecutive, and flow control frames in the canopy module, including data limits, NS2 size, block size, and timing.

The canopy module manages initialization and shutdown with canopy off/on states, and performs segmentation and reassembly during on state, providing asynchronous transmit, cancel, and upper-layer confirmations via can.if.

Describe the services provided to the lower layer in AUTOSAR com stack, including transmit confirmation and reception indication via canopy and the Caniff module, in ISR or polling contexts.

Follow the nsdu reception flow in the autosar com stack, from start of reception, through buffer management and data copy, to upper-layer indication.

The upper layer initiates N-SDU transmission by calling canopy transmit with id and length; canopy copies data to a buffer, starts the NCS timer, and returns EOK when complete.

Lock the upper-layer buffer during transmit and receive to maintain data consistency, using APIs like PDR, DCM, and Com to copy data until an indication unlocks the buffer after transmission.

Link can nsduId using network address information with lsdu id and target address to classify frames as flow control, single, first, or consecutive for correct routing.

Explore how the can tp module supports concurrent connections from multiple testers with independent buffers, timers, and state machines, and configure n-pdu padding to eight bytes via the padding byte.

Explore common development and runtime errors in the canopy module, including invalid parameters, null pointers, uninitialized API use, invalid IDs, padding issues, and timeout or communication errors in can tp.

Configure the canned tp module of the autosar com stack, including ns2 and rt ns2 channels, pdus, and main function period, with addressing and padding options.

Explore the pdu router module that routes data from lower layers caniff or canopy to upper layers like comm or dcm, keeping above pdu protocol independent and below pdu dependent.

The PDU router module translates source PDU IDs to destination IDs using routing tables and router engine, forwarding PDUs to DCM or comm modules via reception, transmission, and gateway operations.

Utilize a static IPU id to map each PDU to its source and destination, routing communication to the Com module or diagnostic requests to the DCM module via lookup tables.

Describe how ipu reception to the upper module triggers indications for adc interfaces or ptp transport protocols, copies data into the upper buffer, and invokes tp upon successful transfer.

Cancel transmit and cancel receive APIs let upper-layer modules such as DCM or comm request cancellations via the PDR module to manage IP2 and TP frame handling.

The PDR module has uninitialized, online, and init states. After power up it enters uninitialized, then online for routing PDUs via routing tables; in init it configures default PDO buffers.

Group routing paths into enableable sets and control them at runtime; the Swmm module enables or disables a network's routing paths, such as diagnostics or communication paths, with immediate effect.

Classify errors in the PDR module, including invalid configuration pointer, uninitialized state, invalid PDR id, routing path ID, and parameter pointer, and issues like TX request rejected and PDU loss.

Explore sequence diagrams for the PDR modules in the Autosar com stack, detailing can data transfers in single and multi-frame scenarios, buffer management, and completion signaling.

Explore the PDR module APIs in the AUTOSAR COM Stack, covering init, version info, configuration id, routing enable and disable, upper and lower layer data transfer, copy and reception workflows.

Explore the autosar com stack PDR configuration details, including general, routing paths, pure routing paths, buffers, and API enablement flags for cancel, transmit, and indication.

Explore the Autosar com module’s signal oriented interfaces, packing and unpacking ipdu signals, gateway routing, and transmission control with reception monitoring and filters.

Explain how a frame holds a PDU with signals and how a PDU carries an SDU and PCI added by the sender and removed on reception, within eight byte limit.

Explore how the com module interfaces with other BSW modules, initializes via com init, and handles PDU reception, fragmentation, and signaling through PDR, PDU router, and tcp/can paths.

Initialize com module with the comm init API; IPUs initialize per configuration, startup code sets globals and statics, no communication occurs during init, and IPUs remain stopped until module starts.

Trace the transmit data flow from the application to the CAN hardware through the Autosar Com module, PDU router, and CAN interfaces, ending with a TX callback.

Follow the receive data flow from the controller through the receive interrupt, canned driver, Kaniff indication, video router, com indication, and TX callback. The application reads data from TX.

Explore endianness concepts, including little endian and big endian, and configure signal endianness; learn data types in Autosar com stack, such as boolean, uint8/16/32, signed types, and float32/64.

Begin message reception when the underlying layer indicates success. Copy the PDU into the IPU after the IP due call-out, then unpack, filter, and deliver to the application via RT.

Explore reception filtering in the Autosar COM stack, where a configurable message filter uses algorithms on new and old values, masks, ranges, and occurrence to decide if a message passes.

Configure transfer properties to choose among triggered, triggered on change, and pending, and set transmission modes direct, mixed, or periodic for IP signals.

The minimum delay timer (MDT) enforces the time gap between Com to PDU router requests. MDT reinitializes at IPO start and restarts on transmit; it is disabled when not configured.

Explore Autosar com stack use cases to master transfer properties, filter algorithms, and transmission modes, including periodic, triggered, and direct with repetitions and minimum delay times.

Explore signal invalidation in the Autosar com stack, learning how com signal data invalid value triggers com send signal, and how com data invalid action determines notify or replace behavior.

Describe how ipu groups organize ipus by direction in the com module, with active or implicit activation, and configurable maximum groups, including start/stop through com ipu group apis.

Start and stop IPU groups to control transmit and receive of signals. Starting initializes timeouts, clears update bits, resets shadow buffers, and prepares Com data and filters.

Explore signal indication in the Autosar com stack, comparing immediate interrupt driven and deferred polling driven modes, including IPU unpacking, data copying to a buffer, and notification timing.

Monitor reception deadline for periodic messages on the receiver side to ensure delivery within a configured time interval, and handle timeouts via replace, substitute, or none actions with notifications.

Monitor transmission deadlines on the sender side to ensure lower-layer transmissions occur within a defined time frame, with configurable Com first timeout and Com timeout values.

Explore Autosar com signal groups and complex data types, using a shadow buffer for atomic synchronization with the IPU, and learn init, receive group, and notification mechanisms.

Access signal groups via a uint8 array, with serialization outside the Com module and direct data transfer to the IPU, using start and end positions for precise copying.

Explore large data types and large signals that exceed a single lpda, requiring a large ipu and bus-specific transport protocols like can tp, can fd, frp, or lin tp.

Configure the maximum length for dynamic length signals at configuration time, ensure canopy 4k compliance, use com signal type uint8 dynamic, and specify the actual length at send.

Autosar com module interfaces only with the PDU router, operating in normal or TCP IP use modes, and exposing APIs such as com transmit and start of reception.

Explains how Autosar com uses update bits to indicate updated signal or signal group data before pdu routing, with at most one bit per signal or group and internal handling.

Explore how the Autosar com module's signal gateway routes signals and signal groups via com gw mapping, handles transmission mode and update bits, and decouples interrupt routines for IPDU routing.

Identify error classifications in the autosar com stack: wrong parameter (com e param) 0x01, init uninitialized 0x02, parameter pointer 0x03, init field 0x04, and skip transmission 0x005.

Explore Autosar com module function definitions, including com init, ipu group start/stop, and deadline monitoring, plus sending, receiving, and grouping signals across ipu and shadow buffers.

Explore how callback functions manage transmissions and receptions in Autosar com stack, performing buffer checks, copying data into the buffer pointed to by the data pointer, and updating length.

Configure mandatory pdr com transmit interfaces for pdu transmission and optional error reporting interfaces, and use ipo call out functions to enable receiver filtering, cancel transmit, and sender pre-transmission processing.

Explore common general configurations in the Autosar com stack, including cancellation support, com configuration, mdd or cyclic transmission, signal group array API, metadata support, retry on failure, and IPU groups.

Learn to configure the AUTOSAR com stack, including com data memsize, com max IPU count, gateway mapping, IPU groups, main function routing, signal processing, IPDU configuration, and transfer properties.

Express gratitude to learners, invite feedback and topic suggestions, and provide contact channels via Udemy and LinkedIn for the Autosar com stack course.