Embed Size (px)
Citation preview
Introduction of ARA::COM as common communication middlewareApril, 2018
This work is licensed under a Creative Commons Attribution-Share Alike 4.0 (CC BY-SA 4.0)GENIVI is a registered trademark of the GENIVI Alliance in the USA and other countries.
Copyright © GENIVI Alliance 2018.
Objective of the document Introduce AUTOSAR® ARA::COM and ask whether it could be a solution for a Common Communication middleware
Sources :
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
All information given in this presentation are available publicly at:• https://www.autosar.org/fileadmin/user_upload/2017_ELIV_AUTOSAR_proofs_to_be_THE_automotive_software_platfo
rm_for_intelligent_mobility.pdf• Generally : www.autosar.org
agenda
• AUTOSAR® Context (adaptive/classic) – Contributors, date creation, …
• General architecture (ARA overall) – Security, exec manager, persistency
• IDL and Build chain • Pro/cons to use ARA::COM in applicative SoC• Licencing ?
Adaptive vs Classic
Classic Platform Adaptive Platform
Based on OSEK Based on POSIX (PSE51)
Execution of code directly from ROM Application is loaded from persistent memory into RAM
Same address space for all applications (MPU support for safety)
Each application has its own (virtual) address space (MMU support)
Optimized for signal-based communication (CAN, FlexRay)
Service-oriented communication
Fixed task configuration Support of multiple (dynamic) scheduling strategies
Specification Standard is defined by specification code as reference implementation
ARA = AUTOSAR Runtime for Adaptive Applications
General ARA architecture
ARA includes multiple SW blocks:
• Execution Management• Communication <-- We are here • Persistency• Platform Health Management• Time Management• Log & Trace• HW Acceleration• Security• Config Management
ARA::COM architecture
Client Implementation
Client Implementation
Service ProxyService Proxy
Middleware Transport LayerMiddleware Transport LayerBindingBinding
Client Application
Service Implementation
Service Implementation
Service SkeletonService Skeleton
BindingBinding
Service Application
Service Interface Definition (ARXML)
Service Interface Definition (ARXML)
generated fromgenerated from
- Bindings can be implemented for REST, DDS or other Middleware Transport Layers that support publish / subscribe / event patterns
- SOMEIP is the default transport layer available on the shelf for ARA::COM- Transport Layer is not necessary network, it can be shared memory or direct function calls if client and
service are running the same ECU / address space.
ARXML
- A neutral and explicit interface description
- Strongly typed arguments
- Feeds the tool chain for code generation
Tool chain
9 | 5/8/18 | Copyright © GENIVI Alliance 2017
ECU2 buid env
runtm
e lib
s
ECU1 buid env
ECU2
Client implementatin
Prixy Skeletin
Service implementatin
runtm
e lib
s
bin
der
Serializatin
RPC/Messages/events encap.
Transpirt (IP layers, …)
Service discy
ECU1
ARXML
Developper
API tiils
Generate Generate
BuildBuild
Implement
runtm
e lib
s
Backends (e.g SOME/IP, DDS, …)
Cimmunicatin ramewirk (ARA::COM)
Interface owner
Developper
Implement
runtm
e lib
s
bin
der
Serializatin
RPC/Messages/events encap.
Transpirt (IP layers, …)
Service discy
Question of inter-operability
What about reusing AR::COM framework in Applicative SoC or non AUTOSAR OS ?
Genivi
Android
Linux
WindowsAUTOSAR
Common communication
framework?
Common communication
framework?
Advantages and Drawbacks of using ARA::COM in applicative SoC
11 | 5/8/18 | Copyright © GENIVI Alliance 2017
Advantages DrawbacksBy definition, communication become compatible between Autosar and Applicative OS
Licencing issue ? (have to be AUTOSAR member to use it ? See next slide)
Same IDL definition methods/Same tooling for code generation (proxy/skeleton)
No open source code for the ARA::COM stack so far
Possibility to move services between Autosar and applicative OS (check other OS dependencies)
ARA imposes the use of PSE51 (POSIX) for applications implementation
ARA brings other tools like security or log that could be used as compatible solution between AUTOSAR ADAPTIVE and applicative OS.
May introduce dependencies with other ARA APIs (ARA::LOG, …).May break safety guarantee ? (need extra analysis)
Licencing question
• Would it be OK if there were an open source implementation of ARA::COM in GENIVI ?– Useable by anyone or only AUTOSAR partners ?– Remark : as a beginning of answer, we have the example of SOME/IP
protocol where the specifications are defined in AUTOSAR consortium and open source code is in GENIVI.
12 | 5/8/18 | Copyright © GENIVI Alliance 2017
Thank you!
Visit GENIVI at http://www.genivi.org or http://projects.genivi.org
Contact us: [email protected]
This work is licensed under a Creative Commons Attribution-Share Alike 4.0 (CC BY-SA 4.0)GENIVI is a registered trademark of the GENIVI Alliance in the USA and other countries.Copyright © GENIVI Alliance 2018.
