Do We Need Data Distribution Service (DDS) And Service .

Do we need Data Distribution Service(DDS) and service-oriented architecturefor automotive applications?Prachi Joshi, Prathap Venugopal, Massimo OsellaGeneral Motors

Flow of presentation Future needs of architecture platforms Computation and performance demands on processor Bandwidth demands on communication AUTOSAR Adaptive Service Oriented Architecture Network bindings for ara::com SOME/IP DDS IPC Conclusion

Future ofautomotive FeatureRequirements Highly automated drivingBack-end connectivityV2XElectric vehiclesGrowingdemand on ComputationBandwidth requirementsSoftware qualityRemote software updatesStandardarchitecture Enabling integration of differentmanufacturers’ software, in-housesoftware development

Trends in E/E Architectures New types of in vehicle computersare required to fulfill the needs ofVehicle / Domain Controller Performance, Flexibility and ConnectivityIntelligent Actuators / SensorsIntegration processDeeply Embedded ECUsVehicle ComputerObsolete ECUsDomain FusionCentralizationIntegration But Backwards compatibility with existingsolutions, Fulfillment of increasing requirementsfor safety and security is a must as well.90% of icSupport197019801990LinkedNetworks2000Slide from: T. Scharnhorst, AUTOSAR spokesperson, AUTOSAR Adaptive Platform – Progress on the Software Framework for Intelligent, Safe and SecureMobilityAll majorinnovationsare drivenby E/EVehicles areconnectedto the backend201020204

Future of mobility Software drivenIndustrial IoT Connext Conference 2018: Rick Flores

What is SOA?AUTOSAR standard 19-03 Service oriented architecture defines a ‘server’ which is the provider for aservice/data and a ‘client’ that subscribes to the desired service/data SOA has been used for years in the IT industry for distributed systems Players from IoT world such as Google, Amazon, pave the path to digitalization Applications are loosely coupled and communicate over a service bus asmiddleware

Signal vs SOAMain reasons of adoption: Flexibility, scalability andreusability of code Partial updates of the systemcan be performed “Soft” migration scenarios arealso possibleAUTOSAR Methodology- Robert Sakretz Nov. 2018

AUTOSAR AdaptiveAUTOSAR standard The standard contains interfacesrequired for developing auto-motive ECUs running onstate-of-the-art multicore microprocessors. With the Adaptive Platform, communication between softwarefunctionalities is no longer conducted in cyclic bursts, but is serviceoriented. Lower-level communication is no longer based on CAN or otherclassic automotive bus systems, which use dedicated protocols, buton Ethernet.

Middleware:SOME/IPMiddleware dynamically creates theconnection between the service providerand service consumer at runtime – andnot at system design time.SOME/IP Serialization RPC Service Discovery Publish/Subscribe Segmentation of UDPmessagesDesigned to fit devices of different size,and different OS

Middleware: DDS DDS (Data Distribution Service) targets thebroader Industrial IoT domain.Reference: https://omg.org It is a family of open standards published by the ObjectManagement Group (OMG). Was specifically designed for distributed real-time systems, and isused in many industries including transportation, energy, medicalsystems, industrial automation, aerospace and defense, etc. Uses Real Time Publish Subscribe (RTPS) Offers Quality of Service (QoS) mechanisms DDS was introduced as the network binding for ara::com

How to evaluateSOME/IP vs DDS asnetwork binding forara::com ?Performancebasedevaluation End-to-end latency, throughput,jitter, CPU & memory usageFunctionalevaluation Based on Quality of services(QoS)such as reliability, deadline,priority, ownership, contentfilters, etc., from DDSOtherfactors: Cloud connectivity Compatibility with legacy systems System design capability(toolchain and processes)

Sample use cases for performance basedevaluationUse caseSizeSampling rateLatency req.Lidar250B10ms10msUltrasonic100B20ms20msADAS sensors10KB10ms10ms30fps Video- ADAS(100Mbps)43KB33ms33ms30fps Video- ADAS(1Gbps)43KB10ms16msRaw 30fps Video- Automated driving(10Gbps)6.9MB33ms33msRef: Giancarlo Vasta, Lucia Lo Bello, TechDay 2018

Integration of platformsCloud connectivityEthernetV2XSW-C1 SW-CnCAN (Legacy systems)SOME/IP Use cases include:Communication between Classic and AdaptiveSignal to Service translationLegacy systemsAdaptive AdaptiveApp nApp1Non-AUTOSARApplicationsDDS Use cases include:Cloud connectivityNon-AUTOSAR applicationsMore robust Quality of Service mechanisms13

Applications for automated driving, V2X demand highcomputation and bandwidthConclusionMoving towards Ethernet andSOA- Adaptive AUTOSAR Suitable for ADAS applicationsSOME/IP and DDS as middleware for Adaptive AUTOSAREvaluation of SOME/IP and DDS can be based onperformance, quality of service requirements, applicability.DDS seems promising but we needexperimental data to evaluate Also need to measureoverhead of CPU andmemory usage

Future WorkQuantitative and qualitative analyses withSOME/IP and DDS over ara::comNetwork layer must be integrated with DDSQoS policies to enforce and synchronize timebased guaranteesAnalyze the integration of DDS Ethernet-TSNto enable traffic shaping, priority scheduling,etc., based on application’s QoS requirements

Questions?IEEE Ethernet & IP @ AutomotiveTechnology Day 2019

AcknowledgmentsA note of thanks to Rick Flores, GM Technical Fellow, for his valuablefeedback.

AUTOSAR Methodology - Robert Sakretz Nov. 2018. Main reasons of adoption: Flexibility, scalability and reusability of code Partial updates of the system can be performed “Soft” migration scenarios are also possible Signal vs SOA . AUTOSAR Adaptive AUTOSAR standard