Scribd
Upload
125 views

Service Oriented Architecture For Software Driven Vehicles

The document discusses the evolution of vehicle E/E architectures towards a more centralized and software-defined model to enable features like over-the-air updates. It introduces the concept of service-oriented vehicle diagnostics (SOVD) as defined by ASAM to address the need for diagnosing software components on high-performance computers running complex software stacks.

Uploaded by

wen hu
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
125 views

Service Oriented Architecture For Software Driven Vehicles

The document discusses the evolution of vehicle E/E architectures towards a more centralized and software-defined model to enable features like over-the-air updates. It introduces the concept of service-oriented vehicle diagnostics (SOVD) as defined by ASAM to address the need for diagnosing software components on high-performance computers running complex software stacks.

Uploaded by

wen hu
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Powered by

Service-oriented architecture for


software-driven vehicles
Whom are you listening to?

Omkar Panse
Vice President and Head,
Digital Connected Solutions,
KPIT
Agenda

01. An overview of the E/E architecture evolution

02. Insight into the future of vehicle E/E architectures

03. What does it mean for vehicle diagnostics- Introduction to ASAM SOVD

04. Q&A

3
E/E Architecture Evolution | The Premise

Software-defined vehicles with software centric integration need


new integration workflow, tools & methodology
BCM: Body Control Module | IC: Instrument Cluster | HUD: Head-Up Display | IVI: In-Vehicle Infotainment 4
E/E Architecture | How is it Evolving?
Central Compute
Zonal Architecture

Domain Architecture
Digital Cockpit, AD/ADAS,
EPT
Distributed architecture,
multiple ECUs making it
difficult to perform full
vehicle software update

Existing challenges & requirements are driving E/E architecture evolution to meet
demands of connected, software-defined vehicles
5
Future vehicle architectures
Demands of connected, software-defined vehicle

Hardware-
Software
Decoupling
Data driven
Faster
sellable
feature
features
upgrades
and
and updates
Services
Software
Defined
Vehicles

Seamless Robust, end


Software to end
Integration cybersecurity

Multi-OS /
Multi-
Domain
Software
Reuse

10/11/2021 6
Future vehicle architectures
Technical and Operational Challenges
Faster feature Service and Signal
OTA multi-domain On-board and off-
development, validation oriented domain
Technical

software update board diagnostics


and release integration

Legacy architecture Startup time, shutdown Secure, Deterministic,


support & software and power low latency End to end security
reuse management communication

Uniform Development Uniform tooling and


Agile development CI/CD and DevOps
Operational

and Integration collaboration


methodology infrastructure

OEM specific
Compliance to OEM Functional Safety Virtualization and
extensions and
quality specifications Procedure validation
specialization

E/E Architecture of Software-defined vehicles need focus on


addressing multiple technical and operational challenges
10/11/2021 7
Future vehicle architectures
Communication requisites

Software-defined vehicles will need E/E Architectures that


support multiple co-existing communication paradigms
10/11/2021 8
Implication on Vehicle Diagnostics
Current E/E architectures: Future architectures :
Distributed set-up Central/zonal set-ups with HPCs

Focus on: Additional requirement:


▪ Errors of sensors / actuators or their circuits To analyze & diagnose the S/W running on
▪ Errors in the bus communication HPCs (High performance computers), in
addition to hardware
ECU software considered to be ‘perfect’ time-
sliced tasks

In traditional control systems, Diagnostics Events are intended to detect malfunction of


sensors or actuators, but there are no diagnostics run on ECU S/W
9
Limitations of UDS in diagnosing HPCs

Classic ECUs Complex, concurrent multiple processes


Control-oriented functionality Continuously evolving, large software footprint
Sensor / actuator diagnostics Need to diagnose software
UDS is sufficient UDS is insufficient to diagnose and re-program

HPCs are characterized by SOA based software and ML models


running on POSIX operating system
Software module Feature development 10
Hardware / SoC
from KPIT for OEM
ASAM-SOVD | The Future of Diagnostics
▪ Supports new vehicle E/E
architecture
▪ Newer communication
Remote Diagnostics technologies
▪ Robust identity and access
management
▪ Provides Classic Diagnostic
ara Diag
ara Service Adapter
Adapte
r
UDS ▪ Diagnostics data access
Local Service (DTCs, sensors)
UDS Diagnostics
▪ Bulk data transfer
▪ Configuration updates
▪ Software update
▪ Software log file access

Service Oriented Vehicle Diagnostics (SOVD) will help bridge multiple diagnostics paradigms

11
KPIT’s SOVD building block
▪ Low memory footprint
▪ Cross platform support (Embedded
Linux, Windows, Android, iOS)
▪ Supports multiple protocols (UDS,
KWP2K, J1939 etc.)
▪ Low maintenance through data-
driven architecture
▪ All diagnostics use-cases supported
▪ ISO standard (ODX/OTX) compliant
▪ Aligned to future use-cases –
Service oriented architecture
(SOVD)
▪ Integrated security through license
and certificate management

KPIT is a part of the ASAM-SOVD working group, and provides its


Diagnostic runtime environment as a service-oriented diagnostics solution
12
Thank You for
participating

You might also like