0% found this document useful (0 votes)
158 views13 pages

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
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
158 views13 pages

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
We take content rights seriously. If you suspect this is your content, claim it here.
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