On September 15th GlobalLogic held MeetUP "Future Intelligent Mobility with Adaptive AUTOSAR - Transforming Vehicle E/E Architecture". Our speaker was software engineer Abhishek Babhulkar.
Learn about the huge transformation the industry is going through, among other things, because of the rapid electrification and the rise of autonomous driving.
At the center point of this transformation is automotive electronics, and Adaptive AUTOSAR is driving this transformation. Adaptive AUTOSAR came with a paradigm shift in the design, with the delivery strategies of automotive software and with introduced technologies like POSIX based OS, OTA updates and SOA, to name a few to automotive embedded systems. All leading OEM’s are adapting Adaptive AUTOSAR to power their class-leading features.
In this presentation, we will see the "Why, How, and What" of Adaptive AUTOSAR, the networking in the automotive embedded systems, and an overview of SOA for communication to understand the future of communication among systems in vehicles.
About the speaker:
Abhishek Babhulkar, Software Engineer has been working in the Embedded industry for around 6 years, out of which he spent a significant amount of time working in AUTOSAR. He also has experience in industrial IOT and automation.
He has worked with premium partners of the AUTOSAR consortium, during which he contributed to AUTOSAR classic 4.4 and AUTOSAR adaptive 20.11.
5. 5
Confidential
Evolution of the Architecture
Future
SOP
Today
Vehicle Cloud
Computing
Vehicle Fusion
Domain Fusion
Domain
Centralization
Integration
Modular
Increasing number of vehicle
function in the cloud
Domain independent
“(Central) Vehicle Control Computer” with potential “Zone ECUs”
Domain overlapping
“Cross Domain Control Units” / “Cross Domain
Computer”
Domain specific
“Domain Control Units ” / “Domain
Functional Integration
Each function has its ECU
(“Function Specific Control Units”)
Vehicle Centralized E/E Architecture
domain independent
central vehicle brain(s)
(Cross) Domain Centralized E/E
Architecture
increasing cross domain function
Distributed
E/E Architecture
typ. state of the art automotive ECUs (function specific)
Performance ECUs e.g(Cross-) Domain control Unit,
(Cross-)-Domain Computer, Vehicle Control Computer
Optional ECUs (e.g Central Gateway)
Domain independent Zone ECUs
Sensor/Actuators ECU= Electronic Control Unit
Domain specific Zone ECUs (e.g todays Door ECU)
increasing SW amount
6. 6
Confidential
Challenges
External Communication
Flexibility
Time to market
Vehicle Lifetime
Communication Bandwidth Differentiation
Driver expect new features and
improvements in a fast pace
Future E/E system needs to allow
swift SW sharing & introduction of
new innovations
Leads to higher data traffic and
significant security risks
OEM wants to focus on
differentiating instead of
non-differentiating features
Inter-domain and cross-domain
communication bandwidth not
sufficient for future data traffic
OEM wants revenue streams during
the whole vehicle lifetime
8. 8
Confidential
AUTOSAR’s answer to the upcoming challenges
• Ethernet as a backbone of network
• Flexible use of HW resources
• No function oriented wiring
• Installation and update over the air
Service Interface
Switch
9. 9
Confidential
AUTOSAR’s answer to the upcoming challenges
Source: autosar.org
Computing Power
Low
~1000 DMIPs
High,
>20000 DMIPs
High,
~10000 DMIPs
Safety Criticality
High,
Upto ASIL- D
High,
Upto ASIL-B
Low,
QM
Real Time
Requirements
High,
In micro-sec
Mid,
In Milli-sec
Low,
In sec
10. 10
Confidential
Classic Vs Adaptive Platform
Based on OSEK Os Based on POSIX Os
Fixed task configuration
Support of multiple (dynamic) scheduling strategies
safety critical system ASIL-D
Upto ASIL-B
Efficient on microcontrollers High-performance computer
Optimized for signal-based communication
Service-oriented communication
Flexible software
configuration (OTA)
12. 12
Confidential
Logical Overview
• Fully interface compatible with classic platform
• Foundation and service interface are specified towards app. only
• Interfaces to foundation clusters by API and service by ara::com middleware
(Virtual) Machine / Container / Hardware
Service
Instance
• Service deployments (provided, required)
• Service technology bindings (i.e. SOME/IP).
• Configuration of E2E- and Security protections
Execution
Manifest
Startup configuration (machine state dependent)
• Startup options, dependencies
• Access roles
• Functional groups
POSIX Executable
Adaptive User Application
13. 13
Confidential
Development Flow
Platform Configuration
B
Adaptive Application
C
D
Network com. config.
- SOME/IP SD = adr + port
- Com. Connector = adr per process
● Service interface deployment
● Service instance deployment
● Mapping of service instance to machine
● Mapping of service instance to application
endpoints
Service Definition
A
Real Adaptive HW/ECU or
Adaptive SW demonstrator
(PC based emulator)
15. 15
Confidential
Packages distribution to vehicle
Vendor C
Executable
SWCL
Packager
Integrator signing package
for traceability
Available for OEM
Vendor A
Executable
Persistency
Vendor B
Configuration files
Persistence
AA UCM developer
(OEM, vendor)
Integrator
repository
18. 18
Confidential
AUTOSAR Adaptive Platform – ara::com
ara::com Middleware
Note :
ARXML : C++ImplementationDataType =>
Serialization is specified for the each transport
type (SOME/IP, DDS, UserDefined)
● Intra-process communication
● Inter-process communication
● Inter-ECU/machine communication
Scope of communication
19. 19
Confidential
Communication scope
Applications
Adaptive Platform X
S
P
Service A
Service B
Network Binding
Service C
Service D
ara::com ara::com
Some/IP, DDS, local Some/IP, DDS, local
Service Cluster
Applications
P P
S P S
P
P
P
S
S
P
1 2 3 2
1
Adaptive Platform Y
Classic Platform 1
Classic Platform 2
Service A: 3 x consumer (P), 2 x providers (S)
Service B: 3 x consumer (P), 1 x providers (S)
Service C: 1 x consumer (P), 1 x providers (S)
Service D: 1 x consumer (P), 1 x providers (S)
21. 21
Confidential
AUTOSAR Services – Service Design Criteria
Service Elements : AUTOSAR Usage Model
C++ API C and RTE API
Data (sync./async.) with
temporal cache/buffer support
Setup/Config setting (async.) + ACK
Setup/Config setting (async.) + No ACK
Trigger
Config Register set by Server & Client