1. Overview of MCAL

1.1. Overview of AUTOSAR Stack

AUTOSAR (AUTomotive Open System ARchitecture) is an open and standardized automotive software architecture jointly developed by automobile manufacturers, suppliers, and tool developers. AUTOSAR focuses on main strategic targets such as modularity, configurability, and transferability of software modules, and the standardization of their interfaces to accomplish the project objectives. AUTOSAR is based on the concept of separation between infrastructure and application. AUTOSAR software component implementation is independent of the infrastructure.

AUTOSAR infrastructure consists of the following layers in the architecture:

Runtime Environment (RTE): Middleware layer which provides communication services for the application software and makes the components independent of a specific MCU.
Basic Software (BSW) Layer: Software layer with basic services and drivers to leverage features of the underlying hardware, and enables interface to application and RTE layer.
Services Layer: Offers basic services, Memory Services, Diagnostic Services, and state management for components in the basic layer.
ECU Abstraction Layer: Interfaces the drivers of MCAL and makes higher software layers independent of hardware layout and offers access to I/O signals.
Microcontroller Abstraction Layer (MCAL): The lowest software layer designed to make higher-level software independent of a microcontroller.
Complex Driver: Collection of complex sensor and actuator control or non-standardized drivers that may need migration.

1.2. What is MCAL

Microcontroller Abstraction Layer (MCAL) is a software module that enables direct access to on-chip MCU peripheral modules and makes the upper software layer independent of the MCU.

The Microcontroller Abstraction Layer (MCAL) is the lowest layer of the AUTOSAR Basic Software architecture. MCAL contains drivers with direct access to the microcontroller internal peripherals and memory-mapped microcontroller external devices. MCAL is a hardware-specific layer that ensures a standard interface to the Basic Software. It manages the microcontroller peripherals and provides the components of the Basic Software with microcontroller-independent values. MCAL also implements notification mechanisms to support the distribution of commands, responses, and information to processes.

MCAL software (which is part of the package that includes the hardware platform) needs to be configured for the specific automotive application. For example, the CAN BUS (MCAL) driver needs to be configured for in-vehicle networking applications. Similarly, several drivers like LIN BUS, FlexRay, PWM, SPI, and Ethernet have to be configured based on the specific requirements of an automotive application.

Configuration of these drivers is carried out using specialized tools for code generation and configuration; for example, EB Tresos. The source files generated using the tool consist of structures with elements such as configuration values. These configuration files are generated based on the values specified in the Parameters Definition File. The configuration values need to be fed to the peripheral registers, address pointers, macro definitions, etc. The MCAL drivers implement the software specification as mentioned in the AUTOSAR 4.3.1 release. Additionally, examples to demonstrate MCAL driver usage have also been included.

1.3. What is CDD

CDD stands for Complex Device Drivers. A Complex Driver is a software entity which provides the possibility to integrate special-purpose functionality/drivers that are not defined in AUTOSAR. A CDD is a specific module located in the Complex Drivers Layer of the Basic Software which interacts with standard BSW modules or RTE.

A CDD may need to interface with modules of the layered software architecture
A module of the layered software architecture may need to interface with a CDD
A CDD may need to interface with SW-Cs via RTE

Fig. 1.2 CDD in Layered Software Architecture

The main goal of the CDD is to implement complex sensor evaluation and actuator control with direct access to the microcontroller using specific interrupts and/or complex microcontroller peripherals, external devices (communication transceivers, ASIC, etc.) to fulfill the special functional and timing requirements. In addition, it might be used to implement enhanced services/protocols or encapsulate legacy functionality of a non-AUTOSAR system. CDD implementation might be application, microcontroller, and ECU dependent. Finally, the CDD can serve as a mechanism of migration to introduce existing or new concepts into the AUTOSAR Software Architecture.

Refer to the AUTOSAR_EXP_LayeredSoftwareArchitecture document for more details on CDD-related configurations.

1.4. MCAL Safety Strategy

1.4.1. Safety Certified MCAL Modules

MCAL is a collective package of Safety Certified Driver Modules (ASIL D/B depending on device). It is developed with a process that is certified to be compliant with ISO 26262.

Drivers implement the HW safety mechanisms listed for the specific peripherals in the HW Safety Manual to manage random faults. Each of the MCAL releases will include a CSP. However, only the final safety release will be assessed for functional safety.

1.4.2. CSP

Safety Certification for MCAL and Compiler

The Safety certification process of TI MCAL is compiler options agnostic and is certified in a systematic approach, i.e. the Safety certification of MCAL will not be violated if the compiler options are changed to a different options other than the ones mentioned in the MCAL user guide.
The safety qualification of TI ARM Compiler is done using compiler qualification kit with set of recommended options and flags. The safety qualification can be done again if compiler options are changed. Refer to this page on our approach of QKIT How to apply the TI Compiler Qualification Kit for functional safety development

Steps to follow if compiler options are changed:

Review the content of the Compiler qualification kit.
Revalidate the compiler based on the new options selected.
Ensure that compiler qualification test reports are consistent with the reports provided by TI compiler.
If any discrepancies are found, reported them to TI compiler team.
Validate the use case at the system level with new compiler options and ensure that MCAL functionality is as expected.

1.5. Software Offering

TI offers MCAL and CDD drivers (source code) for MCU devices along with the licensed Configurator Package. The rest of the AUTOSAR Basic Software is provided by the AUTOSAR Vendors (Vector, Elektrobit, ETAS, etc).

Customers get:

MCALs and EB Configurator Tool from TI.
AUTOSAR BSW/RTE from their preferred vendor with an OS port for the target TI device.

Customers integrate these deliverables based on integration guides provided by AUTOSAR vendors and TI.