A common misconception is that high-rate application tasks cannot be scheduled within an Autosar system. This article explains the mechanisms in place within the Autosar operating system to handle the application scheduling requirements and how a successful configuration of the OS allows the software engineer to continue running the high-rate task schedules within an Autosar system.
The Drivers for Autosar
In recent years, the electrical and electronic (E&E) functions inside the vehicle have grown exponentially, both in number and complexity. This trend has been driven by a number of factors within the automotive industry, including an increased demand for E&E- based end-customer features, the advent and proliferation of ADAS systems and increasingly demanding legislation in diagnosing E&E system faults and Electronic Control Unit (ECU) failures.
The newest vehicle functions have reached such a level of complexity that traditional automotive ECU capabilities and supplier development methods can no longer fulfil the demands imposed by the modern vehicle E&E architecture. In 2003, this increasing level of complexity led automotive vehicle manufacturers and their suppliers to form the AUTomotive Open System ARchitecture (Autosar) development partnership; where their mutual goal has been to define a common and standardised software architecture for use within the vehicle ECUs, that would ultimately provide the software features, mechanisms and support necessary to meet the higher demands of the vehicle’s underlying E&E architecture.
Before Autosar was defined, the primary focus of the vehicle manufacturers for an ECU’s embedded software was often limited to the network communication stack and diagnostics. But with Autosar, the underlying software within an ECU has undergone significant expansion; Autosar “Basic Software” covers not only areas such as network communications for CAN, LIN, FlexRay, Ethernet and diagnostics protocols, but also now includes system and watchdog initialisation and state-handling, a non-volatile memory software stack for various memory devices, an abstraction driver layer for the microcontroller peripherals and also the operating system (OS).
Increased Processing Demand from the