Transcription
Using DDS with TSN andAdaptive AUTOSARBob Leigh, Director of Market Development, Autonomous VehiclesReinier Torenbeek, Systems Architect
Agenda Intro to Data Distribution Service(DDS) Use Cases for DDS in Automotive AUTOSAR and other platforms DDS and TSN
Intro to DDS
DDS and the Industrial Internet of ThingsDeployed in 1000s of SystemsIndustrial IoT Systems Reliability: Severe consequencesif offline for 5ms (or 5 min) Real-time: measure in ms or µs Interface scale: 10 applications/teams Dataflow complexity: data hasmany destinations Architecture: Next generation IIoT3 Yes?INDUSTRIESEnergy, Industrial Control, Transportation, Healthcare, Defense
RTI Connext DDS in Autonomous Vehicles Commercial systems7 Passenger vehicles8 EV startups5 Software platforms7 Trucks, mining vehicles,forklifts2 Flying taxi services2 Hyperloop & other2 Autonomous ships2 Underwater robots Many defense systems (land,sea, air) Many research programs(companies, universities, etc.)
The DDS Standard DDS is the Proven Data ConnectivityStandard for the IoT OMG: world’s largest systemssoftware standards orgUML, DDS, Industrial InternetConsortiumInteroperability between sourcewritten for different vendorsDDS APIDistribution Fabric DDS: open and cross-vendorOpen Standard and Open Source12 implementationsDDS-RTPS ProtocolReal-Time Publish-SubscribeInteroperability between applicationsrunning on different implementations
DDS Wire Protocol (RTPS) Peer to peer Transport-independent QoS-aware and Reliable Communication Including multicast, for 1-many reliable communication Any data size over any transport. Automatic Discovery and Presence Plug and Play Decoupled Start applications in any order Support for Redundancy Multiple data sourcesMultiple network paths High performance native “wire”speeds
What most systems of systems look likeWhat happensto the systemwhen yourneeds evolveHow the system is initially designed
DDS Creates This DDS DataBusWhat happensto the systemwhen yourneeds evolveDDS DataBus
Use Cases
owlFataDevissaMdeNesmetsySsoumnootAu
Dataflow ChallengeData SourceData TypeCamerasVideo StreamLidarData ListRadarPoint cloudGPSBin data structControl CmdBin data structErrorText StringData VolumeQoSData Frequency Carbots needmany yDestination A singledatabus thatcan handle allgreatlysimplifies thesystem
Quality of Service CapabilitiesUse TSN?Use TSN?
Distributed Architectures for Higher AutonomyData Centricity thus enables newarchitectures that are fast, distributed,and reliable.
Connected & SecureTraditional Method Secure the System Secure the Host Secure the NetworkApp 1App 2Security does notneed to be blackand white
Fine-Grained, DDS SecurityApplicationData Flow Security, by TopicAuthenticationAccess ControlEncryptionData TaggingRTI CoreLibraryLoggingAny Transport(e.g., TCP, UDP, multicast,shared memory, )DDS Data Distribution Service
DDS Across Platforms, Industries, and Networks Integration in larger systems
Connext DDS as Core Connectivity FrameworkOpenFMB AppOpenFMBTypesOpenICE AppDDS APIDDSOpenICETypesAUTOSAR ComponentDDS APIDDSFACETypesFACETSSDDSROS2 NodeROSTypesara::comAPIDDSDDS DATABUSFACE AppAppTypesrcl APIrmw / DDS
Adaptive AUTOSAR and DDS
What is AUTOSAR? AUTOSAR (AUTomotive Open System ARchitecture) is aworldwide development partnership of vehiclemanufacturers, suppliers, service providers and companiesfrom the automotive electronics, semiconductor andsoftware industry. 270 partners includingCore Partners: BMW, Bosch, Continental, Daimler, Ford, GM, PSA,Toyota, and VW.RTI joined as a Development Partner in 2017
Overview ara::com is the Communication Management API for theAUTOSAR Adaptive Platform.EXP AraComAPI.pdf provides an overview of the API.SWS CommunicationManagement.pdf provides the formal spec. Developed in 2014 in the context of Adaptive AUTOSAR FT-CMAims to be communication framework independentWas initially built around SOME/IP and follows most of its principlesBased on a proxy/skeleton SOA architectureEspecially tailored for Modern C (C 11 in External APIs, C 14 inInternal APIs)
Architecture
Adaptive AUTOSAR
Network StackDDS Application(Standard C API)AUTOSAR ApplicationROS2ApplicationAUTOSAR(ara:com API)ROS2DDS Application(Standard C API)DDS[Secure] DDSI-RTPSTSN / Ethernet(802.1, 802.3)UDP/IPEthernetTCP/IPEthernetSharedMemory
The Network is the CarDDS can simplify widedeployment and use of TSN,across systems and platforms
DDSTSNHow do the two fit together?
How do DDS and TSN fit together Intuitively, DDS and TSN are a good fitFundamentally both are about predictable and faulttolerant one-to-many delivery with bound latenciesTSN could provide QoSes and mechanisms to DDS at anetworking levelDDS could provide TSN mechanisms at higher level ofabstraction
How do DDS and TSN fit together What does DDS provide to TSN?–Simplified usage by means of a higher level abstraction TSN can be complicated to configure and use, compared to DDSBest practices for real-time data distribution, which aredesigned into DDSA standardized API for applications to use, in several languagesAdoption by industry frameworks that already have selectedDDS (for example ROS2, AUTOSAR, )
How do DDS and TSN fit together What does TSN provide to DDS?–Possibilities to truly implement certain DDS QoSes that live atthe network levelThe concept of TSN data flows that naturally match DDS dataflows, allowing for intuitive integration of the two all the waydown to the network level
Problem statement DDS-TSN seems to have three different integration points.Looking at it from the DDS perspective, these are:1.2.3. Design-time system definition to include TSN-related propertiesRun-time DDS implementation to leverage TSN networkDeployment-time actions to instruct TSN-enabled equipmentAll three need to be addressed by the OMG DDS-TSNstandardisation
Design-time system definition In order to allow DDS-TSN integration, DDS design-timesystem definitions need to be extended, for example with:DDS data flow properties such as “criticality” and “periodicity”- DDS endpoint location information, in combination with theunderlying network topology-
Run-time DDS implementation DDS implementations should know how to interact withthe TSN network and do it in a standardized wayFor certain use cases, using the Level-3 (UDP/IP) stack in theright way is good enough- For other uses cases, Level-2 (ETH) access is required and nostandardized TSN APIs mechanisms seem to be available for that- Again, need to collaborate with TSN standardization body-
DDS TSN (Time Sensitive RDR2021DWTperiod 1msTperiod 4ms
OMG RFP OBJECT MANAGEMENT GROUP ISSUES DDS-TSN REQUESTFOR PROPOSALSALLOWS DDS INFRASTRUCTURES BE DEPLOYED ON, ANDLEVERAGE, TSN-ENABLED NETWORKS htm
Thank youBob LeighDirector of Market Developmentbobl@rti.comRTIwww.rti.comExamples, forum, paperscommunity.rti.comIICwww.iiconsortium.orgDDS portalportals.omg.org/dds/
DDS-TSN seems to have three different integration points. Looking at it from the DDS perspective, these are: 1. Design-time system definition to include TSN-related properties 2. Run-time DDS implementation to leverage TSN network 3. Deployment-time actions to instruct TSN-enabled equipment All three need to be addressed by the OMG DDS-TSN
