0% found this document useful (0 votes)
414 views18 pages

ECU Architecture

Uploaded by

Virag Jain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
414 views18 pages

ECU Architecture

Uploaded by

Virag Jain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

ECU Architecture

The Electronic Control Unit (ECU) architecture is a hierarchical and multi-layered system.
The ECU architecture can be broadly divided into hardware and software layers, each with
sublayers that work together to perform specific tasks.
Software stack follows the AUTOSAR (Automotive Open System Architecture) standard
1. ECU Hardware Architecture:
• The hardware of an ECU is the physical component that interacts with vehicle sensors, actuators,
and other systems. It provides the foundation for the software to operate on.
• Main Components:
•Microcontroller (MCU):
• The heart of the ECU, responsible for executing software instructions.
• It includes a CPU, memory, and peripherals for managing the input/output operations.
•Memory:
• RAM: Used for temporary data storage while the ECU is running.
• Flash Memory: Stores the ECU software/firmware and calibration data.
• EEPROM: Stores data that needs to be retained even after power-off (e.g., system configuration, error logs).
•Power Supply:
• The ECU operates on a vehicle’s power supply, typically 12V or 24V systems.
• Voltage regulation is provided to power the MCU and other components safely.
•Communication Interfaces:
• ECUs need to communicate with other systems in the vehicle.
• Key communication protocols include CAN (Controller Area Network), LIN (Local Interconnect Network),
FlexRay, and Ethernet for high-speed communication.
•Input/Output Interfaces:
• Sensors: Input data to the ECU (e.g., temperature, pressure, speed,
etc.).
• Actuators: Output control signals from the ECU to perform actions
(e.g., fuel injectors, relays, etc.).
•Signal Conditioning:
• Includes components like analog-to-digital converters (ADC), digital-
to-analog converters (DAC), and signal filters to process sensor
inputs before they are used by the MCU.
2. ECU Software Architecture:
• The ECU software stack is generally organized into several layers, each
with a specific purpose. The software architecture, often based on
AUTOSAR, ensures modularity, scalability, and interoperability ( It is
a characteristic of a product or system to work with
other products or systems)
A. Microcontroller Abstraction Layer (MCAL):
B. Basic Software (BSW):
C. Runtime Environment (RTE):
D. Application Layer:
E. Calibration Layer:
A. Microcontroller Abstraction
Layer (MCAL):
• This layer provides abstraction between the hardware and higher
software layers. It offers standardized interfaces to access hardware
resources.
• Hardware Abstraction: Accesses low-level hardware components like
timers, ADCs, communication controllers (CAN, LIN, etc.).
• Driver Libraries: Includes drivers for controlling hardware peripherals.
Examples of components:
• GPIO (General Purpose Input/Output) drivers
• PWM (Pulse Width Modulation) drivers
• UART (Universal Asynchronous Receiver/Transmitter) drivers
• The MCAL ensures portability across different microcontrollers by
providing a uniform interface.
• MCAL make higher software layers independent of microcontroller.
B. Basic Software (BSW):
• The BSW is the layer that sits above the MCAL and contains the essential software services
required by the application layer.
1. System Services:
• Manages the core functions of the ECU such as bootloader, watchdog handling, and
power management.
• Bootloader: The ECU's bootloader is the first program that runs.
A bootloader is a small, specialized program responsible for:
• Initializes essential hardware components (e.g., microcontroller, memory, communication interfaces)
to get the ECU ready for operation.
• After initialization, the bootloader loads the main software application (firmware) from non-volatile
memory (like Flash) into RAM for execution. It transfers control to the main application after loading.
• The bootloader facilitates updating the ECU’s firmware, which can be done via a diagnostic tool or
through Over-the-Air (OTA) updates in modern vehicles.
• Ensuring that the system boots up correctly and securely.
• Watchdog Handling:
• A watchdog is a hardware or software timer that helps monitor the health of the
ECU. It ensures that the ECU remains functional by resetting the system if it detects
that the software has become unresponsive or is stuck in an error state (e.g., a
software crash or infinite loop).
• Responsible for:
• Monitoring System Health:
• The watchdog timer needs to be regularly “kicked” or reset by the ECU software at specific intervals. If
the software is functioning normally, it will keep resetting the watchdog timer. If the timer is not reset
within a predefined time (due to a software error), the watchdog will assume the system has failed.
• Resetting the ECU:
• If the watchdog is not reset in time, it triggers a system reset. This ensures that the ECU does not
remain stuck in an unresponsive state and can restart to resume normal operations.
• Safety-Critical Applications:
• In safety-critical systems (such as braking or airbag control), the watchdog is crucial for ensuring the
ECU can recover from unexpected software failures and continue functioning correctly.
• Type of Watchdog Timer:
• Hardware Watchdog: A dedicated hardware component that monitors the ECU's operation.
• Software Watchdog: Implemented in software, typically using an OS timer that is monitored
within the ECU software.
Power Management:
• Power management refers to the processes and mechanisms within the ECU to manage and optimize
power consumption, ensuring efficient energy use while maintaining system functionality.
• Power Modes:
ECUs often operate in different power modes depending on the vehicle's status. These include:
• Active Mode: Full operation when the vehicle is running or in use.
• Sleep Mode: Reduced power consumption when the ECU is idle, but still capable of quickly waking up
to handle critical tasks.
• Deep Sleep Mode: The ECU draws minimal power, typically when the vehicle is turned off or parked
for extended periods. The ECU can only wake up from external events (e.g., keyless entry or a
diagnostic tool).
• Power State Transitions:
• Power management involves handling transitions between these power modes smoothly. For example,
the ECU might enter sleep mode when the vehicle is parked, and then quickly wake up when the driver
unlocks the car or presses the start button.
• Voltage Regulation:
• The power management system ensures that the ECU operates within a safe voltage range. It monitors
the battery voltage and adjusts power consumption accordingly to avoid over-voltage or under-voltage
2. Memory Services:
• Manages access to non-volatile memory (e.g., EEPROM, Flash) and ensures the integrity of stored data.
3. Communication Services:
• Handles communication between ECUs via network protocols like CAN, LIN, and Ethernet.
• Includes protocol stacks for message handling, error handling, and time synchronization.
4. Diagnostic Services:
•Manages diagnostics of the ECU, including the processing of Diagnostic Trouble Codes (DTC).
•UDS (Unified Diagnostic Services): Standard diagnostic protocol for communication between the ECU and diagnostic
tools.
5. Operating System (OS):
• Typically based on a real-time operating system (RTOS).
• This provides task scheduling, resource management, and interrupt handling to ensure deterministic performance.
• Key features of the ECU OS:
• Multitasking: Runs multiple tasks (e.g., sensor reading, control logic) simultaneously.
• Task Prioritization: Assigns priority to tasks to ensure real-time constraints are met.
6. Crypto services
Yet to understand….

C. Runtime Environment (RTE):


• The RTE serves as the middleware that connects the application layer
with the BSW. It manages the communication between software
components, providing independence between them.
• Inter-Component Communication: Manages data exchange between
software modules, whether they are running on the same ECU or different
ECUs.
• Interface Abstraction: Offers abstraction of how data is transferred, making it
independent of the hardware layer.
• The RTE is a key feature of AUTOSAR-based ECUs, ensuring modularity
and easier integration across different vehicle platforms.
D. Application Layer:
• This is the topmost layer of the ECU software stack and contains the logic specific
to the ECU's purpose. The application layer implements the actual functionality of
the ECU, such as controlling the engine, braking system, or infotainment system.
1. Functional Software Components: These components execute specific tasks
based on inputs from sensors and other ECUs. For example:
• Engine Control Module (ECM): Controls fuel injection and ignition timing.
• Transmission Control Module (TCM): Controls gear shifting and torque converter.
2. Control Algorithms: Mathematical models and control algorithms (e.g., PID
control) are implemented in this layer to manage vehicle functions like speed,
emissions, or air conditioning.
3. Safety and Security Features: Ensures that safety-critical tasks (e.g., airbag
deployment, ABS) operate correctly.
• Implements functional safety mechanisms as per ISO 26262.
• Includes security mechanisms to protect against cyberattacks (e.g., secure boot, secure
communication).
E. Calibration Layer:
•Calibration Data: Stores parameters that can be modified without changing the ECU software (e.g.,
fuel maps, sensor thresholds).
•Calibration Tools: External tools (like CANape, ETAS INCA) are used to adjust and fine-tune the
calibration data for optimal performance.

3. Additional Layers (Optional):


•Vehicle Communication Layer:
• Interfaces the ECU with external communication networks (CAN, Ethernet, etc.) to transmit or receive
data from other ECUs or off-board diagnostic tools.
•Middleware:
• In more complex ECU systems, middleware can be used to handle vehicle-to-cloud communication,
Over-the-Air (OTA) updates, and remote diagnostics.
AUTOSAR
• Why AUTOSAR ?
• Biggest Problem: Software must be rewritten from scratch when hardware is changed.
• BSW Standardization: AUTOSAR standardized the BSW software. Now OEM will only prefer to
pay only for Application Software but not for BSW.
• Hardware Abstraction: AUTOSAR provides a hardware abstraction i.e., software module called
as Microcontroller Abstraction Layer (MCAL) that makes the Basic Software (BSW) and the
application layer independent of the Microcontroller. The software developer can now focus
on building the application rather than on worrying about configuring the Microcontroller.
• Reusability of functions: Add functions, reuse functions to an existing ECU without large
efforts. Partitioning and relocation of functions also possible with AUTOSAR.
• Standardization of exchange formats: Before AUTOSAR every supplier to the OEM developed
products in an ad-hoc mode. This created a lot of compatibility issues as OEM works with
different suppliers for different products. AUTOSAR is working on standardizing the
specification of exchange formats. Interfaces has been standardized.
AUTOSAR Basic Software Module
• AUTOSAR has defined a set of BSW modules. They are responsible for
different tasks:
 Operating System
 Access to non-volatile memory
 Communication via CAN, LIN, FlexRay and Ethernet
 Handling the diagnostics using UDC
 Access to I/O ports
 System services like ECU state management
 In addition, so called Complex Device Drivers can be integrated into
an AUTOSAR ECU. They are used to access the features of the ECU,
which are not covered by the standard BSW of AUTOSAR.
ECU Abstraction Layer

You might also like