UNIT- II

Basics of Vehicle Software Architecture

• Introduction to Electronic Control Units (ECUs) –
• Central vs. distributed control
• Introduction to operating systems in vehicles
• Overview of automotive software platforms (AUTOSAR – basic)
• Sensors and actuators in SDVs

CONTENTS

• Electronic Control Unit (ECU): Embedded system that controls one or more vehicle functions.
• Found in: Engine, transmission, brakes, infotainment, etc.
• Key role in modern and software-defined vehicles (SDVs).

​

Introduction to ECUs

• Engine Control Unit (ECU)
• Transmission Control Module (TCM)
• Brake Control Module (ABS)
• Body Control Module (BCM)
• Infotainment ECU

Types of ECUs

Central vs. Distributed Control

Centralized Architecture:

Fewer, powerful ECUs

Easier data handling, but higher failure impact

Distributed Architecture:

Many specialized ECUs

Better modularity and fault isolation

Function: Controls core engine operations (fuel, ignition, idle, emissions) for a 4-cylinder gasoline engine.

Key Hardware:

Microcontroller: 32-bit automotive-grade (e.g., Infineon/NXP), 300-500 MHz, with 4-8 MB Flash.

Inputs: Analog (e.g., temp, pressure, O2), Digital (e.g., crank/cam position), PWM.(Pulse Width Modulation)

Outputs: Drivers for injectors, ignition coils, PWM for throttle/EGR, relay drivers.

Communication: CAN(Controller Area Network), LIN(Local Interconnect Network), Ethernet.

Power: 9-16V DC, low quiescent current.

Housing: IP(Ingress Protection)67-rated, robust for automotive environment.

Key Software:

OS: AUTOSAR-compliant RTOS(Real-Time Operating System).

Features: Engine control algorithms, OBD-II diagnostics, communication stack.

Safety/Security: ASIL(Automotive Safety Integrity Level)-D functional safety, secure boot, HSM(Hardware Security Module).

Environmental:

Temp Range: -40°C to +125°C.

Robustness: High resistance to vibration, shock, and EMC(Electromagnetic Compatibility)/EMI(Electromagnetic Interference).

Lifetime: Designed for 15 years / 300,000 km.

Many Dedicated ECUs: Vehicles historically used numerous Electronic Control Units (ECUs), with each responsible for a specific function or small group of functions.

Examples: Braking ECU, Drivetrain ECU, Infotainment ECU, Climate ECU, Lights ECU, etc.

Decentralized Control: Each ECU operates largely independently.

Challenges:

• Complex and heavy wiring harness.
• Difficulty in system integration and communication.
• Higher manufacturing costs and design complexity.
• Limited flexibility for software updates and new feature additions.

​

​

​

Distributed Control

​

​

​

Central Control

Central & Zonal ECUs:

• Central ECUs: Powerful, high-performance units consolidating control over multiple domains (e.g., powertrain, infotainment, ADAS).
• Zone ECUs: Distributed units in specific vehicle zones, acting as gateways for local sensors and actuators, connecting them to central ECUs.

Integrated & Software-Defined:

• Simplifies wiring and system integration.
• Enables over-the-air (OTA) software updates and rapid feature deployment.
• Facilitates advanced functions like autonomous driving.

Key Principles:

• Open: More flexible for third-party integration.
• Secured: Enhanced cybersecurity for connected features.
• Universal: Scalable and adaptable across different vehicle platforms.

Central vs. Distributed Control

Operating Systems (OS) in Vehicles

The Role of the OS: Operating Systems are critical for managing this complexity, enabling new functionalities, and ensuring safety and reliability.

Real-Time Performance: Critical for safety-related functions (e.g., braking, airbags) where precise timing is paramount. Low latency and deterministic behavior are a must.

Safety & Reliability (Functional Safety): Must adhere to standards like ISO 26262 (ASIL levels) to prevent hazards caused by electrical/electronic system malfunctions.

Security (Cybersecurity): Protection against hacking, malware, and unauthorized access to safeguard vehicle functions, data, and privacy.

Connectivity: Support for various communication protocols (CAN, LIN, Ethernet, Wi-Fi, 5G) for internal and external communication.

Resource Management: Efficient handling of limited hardware resources (CPU, memory) in embedded environments.

Over-the-Air (OTA) Updates: Ability to update software remotely, crucial for bug fixes, new features, and security patches.

Core Requirements of Automotive OS

Types of Automotive Operating Systems

Real-Time Operating Systems (RTOS):

Purpose: For safety-critical and time-sensitive functions.

Characteristics: Deterministic, low latency, small footprint.

Examples:

AUTOSAR OS: Standardized RTOS often built on OSEK/VDX, widely used in traditional ECUs (e.g., engine, brakes, steering).

QNX Neutrino: Commercial RTOS known for reliability, used in infotainment, ADAS, and digital cockpits.

VxWorks: Another commercial RTOS with strong real-time capabilities.

Diverse OS Landscape in Modern Vehicles

Types of Automotive Operating Systems

Linux-Based OS:

Purpose: For non-safety-critical, feature-rich domains like infotainment, telematics, and digital clusters.

Characteristics: Open-source, flexible, rich ecosystem, powerful graphics capabilities.

Examples:

AGL (Automotive Grade Linux): Collaborative open-source project.

Google Android Automotive OS: Designed for in-car infotainment.

Diverse OS Landscape in Modern Vehicles

Hypervisors

Purpose: Allows multiple OS (e.g., RTOS for safety, Linux for infotainment) to run simultaneously and independently on a single powerful processor.

Benefits: Resource isolation, consolidation, reduced hardware, increased flexibility.

Examples: QNX Hypervisor, Green Hills INTEGRITY.

​

What is AUTOSAR?

Definition: AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of automotive OEMs, suppliers, and tool developers.

Goal: To standardize the software architecture of Electronic Control Units (ECUs) within the automotive industry.

Why it's needed:

• Increasing software complexity in modern vehicles.
• Need for reusability of software components across different ECUs and vehicle lines.
• Facilitate collaboration and interoperability among different suppliers.
• Reduce development costs and time -to-market.

​

​

Overview of Automotive Software Platforms

• Layered Architecture: AUTOSAR defines a layered software architecture that separates application software from hardware-dependent software.
• Application Layer: Contains the actual vehicle functions (e.g., engine control, braking, infotainment). These are hardware-independent.
• Runtime Environment (RTE): Acts as a communication layer between application software components and the basic software.
• Basic Software (BSW): Hardware-dependent software that provides services to the application layer. Further divided into:
• Services Layer: Standardized services (e.g., operating system, communication, memory management).
• ECU Abstraction Layer (ECUAL): Abstracts hardware specifics from the services layer.
• Microcontroller Abstraction Layer (MCAL): Direct interface to microcontroller peripherals.
• Software Components (SWCs): Reusable, atomic units of application software that communicate via ports.

​

​

Key Concepts & Layers

• Increased Software Reusability: Reduces development effort and improves quality by using pre-validated components.
• Improved Scalability & Flexibility: Easier to integrate new features and adapt to different hardware platforms.
• Enhanced Interoperability: Standardized interfaces enable seamless communication between components from various suppliers.
• Reduced Development Costs & Time: Streamlines the development process and accelerates market entry.
• Higher Quality & Reliability: Standardized processes and testing contribute to more robust software.
• Focus on Innovation: Developers can concentrate on core vehicle functions rather than low-level hardware interactions.

​

Benefits of AUTOSAR

• Classic Platform: The foundational AUTOSAR standard, primarily for embedded real-time systems with static configurations.
• Adaptive Platform: A newer standard designed for high-performance ECUs (e.g., for ADAS, autonomous driving, infotainment) with dynamic configurations, service-oriented communication (SOME/IP), and POSIX OS compatibility.
• Future Trends:
• Increased adoption in highly automated driving systems.
• Integration with cloud services and over-the-air (OTA) updates.
• Cybersecurity considerations becoming even more critical.
• Continued evolution to meet the demands of software-defined vehicles.

AUTOSAR Evolution & Future

• Software-Defined Vehicles (SDVs): Vehicles where functions are primarily software-driven, allowing OTA updates and new capabilities.
• Sensors (The "Eyes & Ears"): Collect real-time data on internal vehicle state and external environment.
• Actuators (The "Muscles"): Translate software commands into physical actions, controlling vehicle behavior.
• Core Principle: SDVs rely on sophisticated software orchestrating vast sensor networks and intelligent actuators.

​

Introduction to Sensors & Actuators in SDVs

Perception:

• Cameras: Visual data for object/lane detection, traffic signs.
• Radar: Distance/velocity, for ACC, blind-spot monitoring. (Works in adverse weather).
• Lidar: High-res 3D mapping, crucial for autonomous driving.
• Ultrasonic: Short-range proximity for parking.

Vehicle State:

• IMU: Vehicle motion, orientation (acceleration, gyros).
• Wheel Speed: For ABS, traction control.
• Steering Angle, Pressure, Temperature Sensors: Monitor vehicle vitals.

Key Sensors for SDVs

• Motion Control:
• Electronic Throttle: Precise engine power control.
• Brake-by-Wire: Electronic braking for AEB, ABS/ESC.
• Electric Power Steering (EPS): Enables lane-keeping, automated parking.
• Active Suspension: Electronically controlled ride comfort/handling.
• Transmission Actuators: Smooth, efficient gear changes.
• Comfort & Safety:
• HVAC: Automated cabin climate control.
• Electric Seats: Personalized adjustments.
• Adaptive Headlights/Wipers: Automated based on environment.
• Airbag Systems: Pyrotechnic deployment.

​

Key Actuators in SDVs

• Sensor Fusion: Combining data from multiple sensors for robust environmental understanding.
• Redundancy & Fail-Safes: Critical for safety-critical actuator systems.
• Data Processing: Massive sensor data requires powerful ECUs and edge computing.
• OTA Updates: Software updates can re-program sensor processing or actuator control for new features.
• Challenges: Cybersecurity, cost, complexity, reliability, and standardization.

​

Synergy & Future Outlook

Challenges in SDV