WIXLIB

Service Oriented Architecture:Design and Implementation UsingAutomotive Linux BSPMarius RotaruSoftware Architect & Technical DirectorCatalin UdmaLinux Software ArchitectJune 2019 Session #AMF-AUT-T3657Company Public – NXP, the NXP logo, and NXP secure connections for a smarter world are trademarks of NXPB.V. All other product or service names are the property of their respective owners. 2019 NXP B.V.

Agenda Introduction to Service OrientedArchitecture Frameworks NXP’s infrastructure for SoA Applications & Use CasesCOMPANY PUBLIC1

Introduction to Service OrientedArchitecture FrameworksCOMPANY PUBLIC2

Vehicle ArchitecturesMega Trends: Safe and Secure Mobility the semi value per car – today’s standardcar at 380AutonomyElectrificationConnectivity Different sensor types Data fusion:Safe Processing withIntegrated AI capabilities Power Efficiency Battery Management Electrification LevelsHybrid, full electric V2X, 5G, Digital Radio Diagnostics / Prognostic HealthManagement OTA Update Management Analytics (edge to cloud) Fail operation Big Data Broad range of solution Need for standardization Software-centric solutions System securityMajor Changes in Network Topology and E2E ArchitecturesCOMPANY PUBLIC3

Vehicle ArchitecturesDifferent networking models across the 4 optionsCentral GatewayDomain Ethernet BackboneEthernetNetworkServicesCentral Gateway ECUCAN /FlexRayEthernetDCCAN /EthernetNADBody & ComfortChassis & SafetyNetworkControl. ServicesVehicle dynamicsZonal ArchitectureDCADASBrainOBDCAN,EthernetCAN / LINDCDCCAN,EthernetCAN,EthernetVehicleDynamics& SafetyInfotainmentCAN, EthernetADASCentral Compute - StarCamerase.g. CAN,EthernetZonalIO ControlZonalIO Controle.g. CAN,Ethernete.g. CAN,EthernetCentralComputee.g. CAN,EthernetZonalIO ControlEthernet Meshe.g. CAN,EthernetCentralComputeZonalIO Controle.g. CAN,Ethernete.g. CAN,Ethernete.g. CAN,Ethernete.g. CAN,EthernetCOMPANY PUBLIC4

Vehicle ArchitecturesMega Trends: Embedded Software become Softwarethe semi value per car – today’sstandard car at 380Technology TrendsAUTONOMYELECTRIFICATIONCONNECTIVITYE/E Implication ECU Platform Topology Communication OSEK/VDX Signal Comm Static configuration Rich Operating Systems (e.g. Linux) Service Oriented Architecture Dynamic configurationCOMPANY PUBLIC5

Signal vs Service Oriented Communication ParadigmsBackgroundWith signal-oriented data transmission information is sentwhen the sender sees a need, such as when values areupdated or changed, independent of whether these dataare currently needed by a receiver in the networkSignal-oriented data transmission is used on classic bussystems (CAN, LIN, FlexRay)Service-oriented data transmission, a sender only sendsdata when at least one receiver in the network needs thisdata. The advantage of this procedure is that the networkand all connected nodes are not loaded by unnecessarydata.Service-oriented data transmission is mainly using EthernetbusCOMPANY PUBLIC6

Service-oriented Architecture – SoAAll about MiddlewareSource: ISITA World Summit 2015 FUERST Simon for web .pdfSource: AUTOSAR GuidedTour.pptSource: AUTOSAR AdaptivePlatformFor EXP TechnicalOverview.pptxCOMPANY PUBLIC7

Service-oriented Architecture (SoA)Service-orientated Architecture (SoA) is a way of designing software where the participatingcomponents provide and consume services over a predefined protocol over a onA service is a discrete unit of functionality which can be remotely accessed and ANY PUBLIC8

Service-oriented Architecture (SoA)Asynchronous Remote Procedure CallsServer MachineClient teReturnCallCallClient stubReturnServer C RuntimeRPC RuntimeReceiveReceiveSendSendCall PacketResult PacketImplementation of RPC for SoAAsynchronous Remote Procedure CallsCOMPANY PUBLIC9Server

Service Oriented Middleware – SOME/IPSOME/IP Scalable service-Oriented MiddlewarE over IP SOME/IP provides service oriented communicationover a network SOME/IP supports a wide range of middlewarefeatures: Serialization Remote Procedure Call (RPC) Service Discovery (SD) Publish/Subscribe (Pub/Sub) Segmentation of UDP messages SOME/IP can be implemented on different operatingsystems SOME/IP is used for inter-ECU Client/ServerSerialization SOME/IP allows applications to communicate.Source: SOME-IPIntro.pdfCOMPANY PUBLIC10

Service Oriented Middleware – SOME/IPServices Request/Response – a method call with Request and Responsemessages Fire&Forget – a method invocation with just a Request message(does not support answers and errors) Event – a Fire&Forget callback, that is sent out by the Server(e.g. cyclically or on change)– Sent from Server to Client (Similar to regular CAN messages) Field – represents a remote accessible property that includesGetter/Setter and/or Notification (similar to a property on MOST)COMPANY PUBLIC11

Service Oriented Middleware – SOME/IPService Discovery - SDSOME/IP-SD is used to: Locate service instances. Detect if service instances are running. Implement the Publish/Subscribe handlingImage /COMPANY PUBLIC12

Service Oriented Middleware – SOME/IPPros and Cons[1]Main Advantages:Possible Issues: Coexistence with existing system Computational Overhead due to No functional Losscomplex architectures High Data Rate and Unicast Increase Storage Requirements Increase data transfer amount Single Point of Failure (e.g. Switch Low Transportation OverheadMalfunction) Dynamic IP Addressing Gain in maintainability and flexibilityRecommended usage: Suitable for driver assistance and Infotainment systems Still to complex for Hard Real-time system (e.g motor control)Several Open Source implementations (e.g. GENIVI vsomeip)[1] eoriented-middleware-over-ipCOMPANY PUBLIC13

Service Oriented Middleware – DDSDDS Data Distribution SoftwareStandard-based Integration Infrastructure for Critical ApplicationsFamily of specificationsImages a-gateway-specificationCOMPANY PUBLIC14

Service Oriented Middleware – DDSDDS Standard DDS is the Proven Data ConnectivityStandard for the IoT OMG: world’s largest systems softwarestandards org– UML, DDS, Industrial InternetConsortium DDS: open and cross-vendor– Open Standard and Open Source– 12 implementationsImages MG: Object Management GroupRTPS: Real-Time Publish/SubscribeDDS Wire Protocol (RTPS) Peer to peer Transport-independent QoS-aware and ReliableCommunication– 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 sources– Multiple network paths High performance native “wire” speedsCOMPANY PUBLIC15

Service Oriented Middleware – DDSCommunication pattern based on Data-centric Publish/SubscribeProvides a “Global Data Space” that is accessible to allinterested applications.- Data objects addressed by Domain, Topic and Key- Subscriptions are decoupled from Publications- Contracts established by means of QoS- Automatic discovery and configurationImages source: NY PUBLIC16

Service Oriented MiddlewareDDS as Core Connectivity FrameworkImages source: NY PUBLIC17

Adaptive AUTOSARas Service Oriented Communication Framework Was initially built around SOME/IP andfollows most of its principles Based on a proxy/skeleton SOAarchitecture Especially tailored for Modern C (C 11 in External APIs, C 14 inInternal eApplicationASW::XYZASW::ABCNon-PF ServiceNon-PF ServiceUser Applicationsara::restara::tsyncara::sm serviceara::diag serviceRESTfulTime SynchronizationStateManagementDiagnosticsara::s2s serviceara::nm serviceSignal to ationMgnt.IPC(local) Aims to be communication frameworkindependentAdaptiveApplicationSOME/IP ara::com is the CommunicationManagement API for the AUTOSARAdaptive Platform.ara::perara::phmPersistencyPlatform Health Mgnt.ara::coreara::execara::iamara::logCore TypesExecution Mgnt.Identity Access Mgnt.Logging & TracingPOSIX PSE51 / C STLara::cryptoara::ucm serviceOperating SystemCryptographyUpdate and Configuration ManagementAUTOSAR Runtime for Adaptive Applications (ARA)(Virtual) Machine / Container / HardwareLegendSERVICENon-PF ServiceSERVICEPlatfrom ServiceFCsAUTOSAR Runtime for Adaptive Applications Σ of all Functional Cluster APIs /ServicesAPI or Service Interface of a Functional Cluster.APIPlatformFoundation FCsSource: AUTOSAR AdaptivePlatformFor EXP TechnicalOverviewCOMPANY PUBLIC18

Service Oriented Middleware – Adaptive AUTOSARARA::COM - Service-oriented Communication – Proxy/Skeleton ParadigmTwo code artifacts are generated fromAUTOSAR ARXML service description. Service Proxy: facade: an instance of agenerated class, which provides methods forall functionalities the service provides. Service Skeleton: instance of a generatedclass which allows to connect the serviceimplementation to the CommunicationManagement transport layer Bindings can be implemented for REST, DDS or other Middleware Transport Layers that supportpublish / 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 andservice are running the same ECU / address spaceSource:AUTOSAR AdaptivePlatformFor EXP TechnicalOverviewCOMPANY PUBLIC19

AUTOSAR Adaptive – Architectural OverviewARA::COM – Language and Network BindingExecutable An Adaptive Applicationmay use differentcommunication bindingsunderneath the ara::comcommon API. DDS is placed parallel toother network bindingssuch as SOME/IP.Application layerAPIARA::COM APIAPILanguage BindingOperatingsystemExecutionManagementSOME/IP Communication BindingIPCBindingDDS Communication DDSCommunicationMiddlewareAdaptive AUTOSAR FoundationNot standardized- analog toCom SendSignal()Source:AUTOSAR AdaptivePlatformFor EXP TechnicalOverviewCOMPANY PUBLIC20

Service Oriented Middleware – ROS(A) ROS Community: ROS Distributions, RepositoriesCarnegie MellonNode5Node4Node 1Laser Scanning(B) Computation Graph: Peer-to-Peer Network ofROS nodes(processes).Node 2:Map BuildingNode 3:PlanningNode6Node7(C) File-system level: ROS Tools for managing source code, buildinstructions, and message definitions.COMPANY PUBLIC21

SW Environment: SoASoAAppSoAAppService Oriented ArchMiddlewareHLOSHypervisors(Containers)CPU(e.g. Cortex-A)DefinitionWhy e.g. AdaptiveASAR, ROS,MQTT?e.g. Linux,QNXSoA: Service Oriented Architecture Applications built with ‘service’ layer ofabstraction SoA App is not bound to specific OS,SOC, or even ECU e.g. XEN(LXC) Motivation Ease of development, deployment& integration OEMs move away from deployfeatures by ECU, to features bySoA Apps.SoA Apps also referred to as‘Services’ Tier1 moves to deliver SoA Appsto OEMs, rather than ECUs.Framework that will transform howvehicle features are built and deployed– portability at forefront (static ordynamic) Simplifies the OTA deploymentSoA Framework examples: Adaptive AUTOSAR MQTT ROS Challenges for SOC Arch Difficult to HW enforce isolation ofSoA Apps for security / safety SoA Framework dictatesperformance, security & safety.Framework provider & SOCprovider need to work closely tomake use of hardware features.COMPANY PUBLIC22

NXP’s Infrastructure for SoAAutomotive Linux BSPCOMPANY PUBLIC23

Overview of Automotive Linux BSP A Linux BSP for all NXP AutomotivePlatformsOpenSource Targeting ADAS, C&S and Disty MarketIntegrated with SDKs (Vision, tforms& BoardsAutomotiveLinux BSPUbuntuBenchmarks Quarterly Releases A single package for multiple SOCsSecurityMulticoreCOMPANY PUBLIC24

Automotive Linux BSP – Ready for SOA PrototypingActuatorsSafetyCriticalSafe APDLinux EcosystemIPCFSafe HypervisorNXP NG HWCommunicationCores (R, M)Computational Cores (A)We are building an Infrastructure leveraging huge open source ecosystem and various communities targetedautomotive softwareCOMPANY PUBLIC25

Automotive Linux BSP - Product IDDLEWAREProvidedby SDKsNXP URITYCRYPTOSECUREBOOTYOCTOIPCFSERVICESHypervisor (XEN)SOCSoC1SoC2SoC3SoC4BlueBoxCOMPANY PUBLICS32X 26