AUTOSAR Application Software Layer Course (ASWL) | english

Explain how a service software component in the autosar services layer uses a services port and client-server interface to talk to the NVMe and nonvolatile memory, with ECU configuration mapping.

Explain connecting an application software component to the non-volatile memory manager via a non-volatile block software component, with port mappings and auto-generated routing.

Explore how a sensor actuator software component interacts with ECU abstraction and IO hardware abstraction in Autosar to read ADC data and control PWM via the IO stack.

Explore autosar application software layer concepts, including parameter software components for calibration data, service proxy components for remote ecu mode sharing, and composition to assemble interrelated software components.

Explores software components architecture for an emergency auto braking system, using lidar and speed sensors, with D3, D2, D1 thresholds, warnings, and braking actions within an Autosar application layer.

Explore ports and interfaces in the application software layer, including provider and required ports, sender/receiver and client/server interfaces, enabling data transfer and operation calls between components and services.

Examine the sender-receiver interface and the client-server pattern, showing how signals move between software components through ports, queues and FIFO, with configuration shaping final behavior.

Model a sender-receiver interface in ARXML by defining data elements, variable data prototypes, and type references, and specify software implementation policy with queued versus uncued data handling.

Create and configure autosar software components, sender–receiver interfaces, and provider and required ports in a case study walkthrough; define data elements, types, and init values for LiDAR sensor data.

Explore the RTE SR APIs, including sender-receiver interfaces, data elements and ports, and how runnables interact with timing events, with explicit vs implicit communication.

Learn autosar arxml client-server modeling by defining a client-server interface submission with in16, in16, and out32, and implementing provider and requester boards in a lab using Xmlspy.

Explore the client-server interface from a runtime environment perspective, comparing direct hardware calls to Autosar rte mediated communication, including tx call vs tx write, runnable timing, and io abstraction.

Learn how composition groups atomic software components via ports and interfaces, creating composites with assembly and delegation connectors, while contrasting composite view with the flattened RT generation view for ECUs.

Explore runnable entities as the atomic internal behavior of software components, implemented as C functions with runnable names and symbols linked to ports, interfaces, and events.

Explore how the Autosar application software layer uses OS alarms, periodic interrupts, and timing events to activate OS tasks, with mapping and RT generation explained.

Discover how AUTOSAR exclusive areas enable critical sections by synchronizing runnable access between sender and receiver software components through timing events, queues, and enter/leave mechanisms.

Learn how the RTE layer implements the virtual function bus on a single ECU, mapping components to ECUs via the ECU extract and system configuration, and providing sender-receiver APIs.

Learn the client server interface in AUTOSAR RTE, including synchronous and asynchronous operations, timeouts, and runnable components like Interface Underscore Submission and Operation Submission, plus ECU level route configuration.

Explains Autosar data types—base, implementation, and application—how application types define physical quantities with units and scaling, and how mapping to implementation types enables algorithm focus independent of C data types.

Explore Autosar application data types in ARXML, including physical dimension, units, and compute methods; design application and array data types with examples in Eclipse.

Explore implementation data types in Autosar, including platform types, data constraints (internal and physical), short names, and mapping of application data types to unsigned 8-bit C code.

Learn how to implement a simple door sensor and LED control on an STM32 microcontroller using a non-autosar approach, configuring GPIOs, importing drivers, and testing in Proteus.

Divide the software into two components: application software component and io abstraction software component, then implement a door lock indication algorithm reading a sensor and driving an LED.

This lecture introduces AUTOSAR data types and interfaces in ARXML, covering sender-receiver and client-server interfaces, door state and LED switch operations, data constraints, and software base and implementation data types.

learn to implement autosar software components by configuring requester and provider boards, creating assembly connectors for the door lock indication, and validating with r unit in an eclipse workspace.

Configure Autosar swcs, generate dt and c code, and use the r unit to test door sensor and door lock indication software components with implicit reads and led control.

Implement SWCs part5 focuses on building a door lock indication software component and a door sensor abstraction software component, wiring led state through gpio read/write with extern pointers.

Finalize the project and compile by invoking synchronous implementation to call the direct runnable, while organizing a single workspace named stm32 f 301 c for the Kyle Microvision.

Learn to run and debug an auto door lock indication project on Keil uVision and Proteus, stepping through door sensor reads, external variables, and led control with active low indicators.