
Overview about AUTOSAR consortium
Need for the development of AUTOSAR
Motivations and Advantages of AUTOSAR Architecture
Explore how the CAN embedded stack spans network, transport, measurement and calibration, and diagnostic layers under multiple standards to enable cross-supplier software integration for adaptive cruise control.
Explore microcontrollers as programmable semiconductor devices with an on-chip processor, memory, and input/output, and contrast hardware and software roles while introducing local interconnect network protocols in Autosar contexts.
Explore electronic control units (ECUs) and how microcontrollers, sensors, and an application-specific integrated circuit process data to control systems, and how ECUs communicate over networks with other controllers.
Explore the Autosar application scope, detailing electronic control units that drive braking, suspension, and steering, with sensors and actuators, and real-time software on 16-bit microcontrollers using internal or external flash.
Explore the Autosar layered architecture, detailing the basic software (bsw), runtime environment (rte), and application layer, and how standardized interfaces separate software from hardware for flexible integration.
Explore the microcontroller abstraction layer and its software drivers, revealing how memory-mapped I/O enables drivers to manage MCU peripherals, including SPI communication, timer, and watchdog.
Explore the microcontroller abstraction layer in Autosar by learning how applications access microcontroller registers only through a hardware independent standard interface, enabling hardware independent access to basic software models.
Explore the big picture of microcontrollers, their peripherals and drivers, including input/output, ADC, PWM, memory (flash, ram), and communication interfaces like SPI, CAN, LIN, and FlexRay.
Explore the service layer in automotive software, detailing operating system functionality, network management, memory and diagnostic services, and how microcontroller interfaces provide hardware-independent application support.
The lecture explains how complex device drivers extend standardized architecture with non-standardized functionalities, enabling integration of complex hardware where standard interfaces fall short.
Explore the AUTOSAR RTE and BSW architecture, detailing memory, crypto, and communication services, input/output access, and how the IP layer mediates between application software and hardware.
Describe the non-autosar workflow, including exchange of BBC five X and LDL four files with suppliers, and how a software function bus links components across ECUs and enables OEM-driven configuration.
Explore the AUTOSAR workflow from OEM to tier 1, detailing software component and system description files, templates, and exchange formats, and show how configuration and interfaces drive executable ECU generation.
Examine how a blind-spot detection system uses three sensors and intra- and inter-ecu communication to detect obstacles and trigger buzzer and lights.
Contrast Autosar classic and adaptive platforms to highlight architecture and deployment differences. Explore how embedded software platforms enable safe, deterministic execution across sensors, buses, and the application layer.
Explore the three types of autosar interfaces and how software components communicate through them. The lecture shows internal, standardized, and c language interfaces for accessing ecu services and diagnostics.
Learn to generate xml, c, and dot h files for Autosar compliant project, and implement software components by creating ports, interfaces, runnables, and mapping them in a temperature controller application.
Create three application software components in an Autosar project—temperature control, led control, and coil control—and learn to add ports in the next video.
Add ports to software components by defining provided and required ports, such as led on off and coil on off, and connect them via sender receiver and client server interfaces.
Declare basic data types and variables to enable data exchange between software components through ports and sender–receiver interfaces, including boolean for on/off, unsigned int types, and a temp read variable.
Configure AUTOSAR interfaces for software components, including ports and data types. Implement sender-receiver and client-server interfaces, name them, declare elements, and prepare to connect interfaces to ports.
Link ports to interfaces in autosar software components by configuring sender-receiver and client-server interfaces, setting initial values, and mapping each port to its corresponding interface.
Explore Autosar software components, their runnables, and how to define and connect runnables across components using ports, data axes, and client-server and synchronous server call points in the Cordoba tool.
Explore creating runnables for allied control, coil control, and temperature control, wiring ports to interfaces, and mapping data flow across components using the Cordoba tool.
Configure periodic events for software components to acquire data and update outputs every second, enabling led on/off and temperature read with threshold-based control.
Learn how Autosar composition software components aggregate atomic components, configure their connections and runnable entities, and use tools to map and link hardware abstraction modules with software components.
Walk through arxml and source files for software components, including dot c and dot h, runnables, ports, interfaces, and hardware abstraction modules, and review the contract and generation page.
Generate software component XMLs with the Cordoba tool during the RTE contract phase and build assembly connectors among control, temp control, and hardware abstraction.
Explore the generated rte artifacts after contract and generation steps, including the .c source files, header contract files, typedefs, data types, and top-level xml and extract xml structures.
Explore how RTE read and write function calls enable data flow from temp control to LED control via the TX, hardware abstraction, and driver to the hardware.
BSW configuration is not covered in this course
AUTOSAR stands for Automotive open system architecture, It is a standard for software architecture for Automotive applications. It is a consortium formed by OEMs, suppliers, tool developers, and semiconductor vendors.
AUTOSAR is now the worldwide standard for Automotive application development, almost all the OEMs and Automotive ECUs developers are part of the AUTOSAR consortium.
This course is ideally suited for a beginner of AUTOSAR, who wants to learn the basics of AUTOSAR fundamentals and AUTOSAR architecture. In this course, you will learn about the Basic software modules such as MCAL (Microcontroller abstraction layer), ECU abstraction layer, Service layer, SWCs, RTE, VFB, AUTOSAR concepts such as Multicore, E2E, Partial networking concept, J1939, Autosar methodology, tools and technologies involved in the development of AUTOSAR compliant ECUs. Motivation for the development of AUTOSAR, Autosar partnership, objectives goals, benefits, major players in Autosar. Autosar workflow, Communication flow, RTE, SWCs, MCAL, ECU abstraction layer, application layer, service layer.
The course also discusses Inter ECU communication and Intra ECU communication. There are basically two types of AUTOSAR frame works classic AUTOSAR and Adaptive AUTOSAR. Differences between the two frameworks are also discussed in the course. We also discuss AUTOSAR ECU executables. Tools required to generate the ECU executable and AUTOSAR workflow about the generation with respect to OEMs part and suppliers part.