1、Japan Automotive Software Platform and ArchitectureJASPAR,General incorporated associationAutomotive SDN Architecture for Enabling SDVJASPAR Next Generation High-Speed Network WGTatsuya Izumi,Sumitomo ElectricYoshihiro Ito,Nagoya Institute of TechnologyTakumi Nomura,HondaYasuhiro Yamasaki,ToyotaHide

2、ki Goto,Toyota2023 IEEE SA Ethernet&IP Automotive Technology Day 2023 JASPAR All Rights Reserved.2Agenda1.Introduction2.Background&Objectives3.A study of Automotive SDN JASPARs automotive use case&roadmap Functional Requirements for Automotive SDN Architecture(Logical&Physical)4.Future works(Verific

3、ation by PoC)5.Conclusions 2023 JASPAR All Rights Reserved.3Introduction:About JASPARNISSANTOYOTATSUSHOEstablished in September,2004,led by five board companies.2023 JASPAR All Rights Reserved.4Introduction:Next Generation High-Speed Network Working GroupExecutive BoardAuditorAdministratorBoard Memb

4、ersSteering CommitteeFunctionalSafetyWorking GroupsAUTOSARStandardizationCyber SecurityPromotion ConnectivityNext Generation High-Speed NetworkCyber Security TechnicalOTA TechnicalNext Generation High-Speed Network Working GroupTo define standard specification of high reliability technology of in-ve

5、hicle high-speed networks with an eye focused on control system applications,and to define vehicle requirements/problem extraction and solution method of Automotive SDN(Software Defined Networking),Automotive TSN,10Gb/s class Ethernet and SerDes.2023 JASPAR All Rights Reserved.5Introduction:2 presen

6、tations from JASPARNext GenerationTechnology Study TeamHardware Team(Circuit Sub-Team,W/H Sub-Team)Next Generation Technology Study TeamNext Gen.Physical Layer Sub-TeamNext Generation High-Speed NetworkWorking GroupSDN Study&Verification TeamTime SynchronizationStudy&Verification TeamNext Generation

7、 Technology Study TeamTSN Sub-TeamOSI REFERENCEMODEL LAYERS7APPLICATION6PRESENTATION5SESSION4TRANSPORT3NETWORK2DATA LINK1PHYSICALTeam Composition of Next Gen.High-Speed Network WGAll layers are covered2 presentations from JASPARWG is composed by 4 teams and 4 sub-teamsAutomotive SDNAutomotive SDN Ar

8、chitecture for enabling SDVEthernet TSNRequirement of Harmonization amongAutomotive Ethernet Standardizations 2023 JASPAR All Rights Reserved.6Background:JASPARs efforts to date for Automotive SDN.To realize the dynamic configuration of in-vehicle Ethernet,JASPAR has advocated the concept of in-vehi

9、cle SDN since 2017.Ex.1)Change to a communication path that avoids the failed oneEx.2)Network reconstruction that can support functional extension through OTAA study of JASPARs use cases is proceeding under the leadership of OEM.Proposed Automotive SDN to IEEE P802.1DG as JASPARs new use case(2021)P

10、resented Automotive SDN at Ethernet&IP Automotive Technology Day(2022)JASPAR was the first in the world to raise the concept of Automotive SDN,which it had envisioned for some time.JASPAR wants to start considering the architecture with it taking the lead.Y.Ito,et al.“TSN for automotive SDN Update o

11、f Use cases,”IEEE P802.1DG contribution,Mar.2021.T.Nomura,K.Akizuki,et al.“Proposal of Dynamically Configurable In Vehicle Network as an Enabler of Software Defined Vehicle,”IEEE-SA EIP ATD 2022.2023 JASPAR All Rights Reserved.7Background:SDV(Software Defined Vehicle)Before（not SDV）After（SDV）Usage o

12、f vehicleNo function updates after shipping.Functions are updated daily.NetworkImplement a fully equipped design in thedevelopmentstageRedesign and reconfiguration are required in conjunction with function updates.UpdateNetwork design/config.The software will play a leading role in car making.To rea

13、lize SDV,in addition to a flexible software platform such as OTA,hardware and networks must have a mechanism that enables functional updates.The hardware should be ready for future updates.Enablehigh-frequencyredesign andreconfigurationTarget of this presentationSDV：Vehicles that can continue to evo

14、lve with a software update 2023 JASPAR All Rights Reserved.8Agenda1.Introduction2.Background&Objectives3.A study of Automotive SDN JASPARs automotive use case&roadmap Functional Requirements for Automotive SDN Architecture(Logical&Physical)4.Future works(Verification by PoC)5.Conclusions 2023 JASPAR

15、 All Rights Reserved.9Use cases where SDN can be expected to applySince SDN has a high affinity with the evolution of SDV,it will significantly increase the added value of cars.Hardware update 2023 JASPAR All Rights Reserved.10Trends in existing technology(ICT field)The concept of SDN is usefulbut i

16、t isnt easy to apply the technology of the ICT field directly to vehicles.JASPAR is considering an architecture suitable for in-vehicle use.ReliabilityProvideL2/L3 connectivity serviceGuarantee of Quality of Service(QoS)ScalabilityNetwork virtualizationSeparation of logical and physicalconfiguration

17、Separation of addressesIsolation of trafficVirtual Machine(VM)MobilityAvailabilityAutomatic provisioningService detectionOperation,Administration,Management*Current main applications:data centers and telecommunications carriersUntil now,setting configuration and updating have been carried out for ea

18、ch network device(each switch).SDN that can dynamically update configuration through centralized control is gradually being put to practical use.AdvantageReduced workload(controller change only)Quick configuration changeDisadvantageHigh processing load on the controllerCommunication between the cont

19、rollerand switches is mandatory.Example of SDN protocol implementationOpenFlow(not an L2 switch)2023 JASPAR All Rights Reserved.11JASPARs Automotive SDN RoadmapAdapt to updates(software/hardware)+Adapt to change of vehicle status(APP.ON/OFF,Link failure,etc.)Cooperates with environment outside vehic

20、le(Smart City、V2X,etc.)Select from preset configurationsConfigure by dynamic calculationStopped(at startup)During runtime(vehicle speed is zero)GenerationSDNv1（202X-）SDNv2（203X-）SDNv3Select configuration at startupSelect configurationDuring runtimeConfigure in real timeFunctionCompletein the carCoop

21、eration with cloudIn the future,it would be ideal for updating dynamically and in real-time,like inthe ICT field,but operations will be as static as possible for the time being.Completein the car 2023 JASPAR All Rights Reserved.12How to proceed with architecture studyRequirements analysis,requiremen

22、ts definitionArchitecture study1.Analysis of upper requirements (SDV as conceived by JASPAR)2.SDV Requirement analysis for in-vehicle SDN3.Determine the assumed scenario from typical U/C4.Define basic requirements(common items)for in-vehicle SDN from multiple assumed scenarios.5.Analysis of current

23、architecture (In-vehicle or ICT field)6.Study on in-vehicle architecture(JASPAR proposal)7.Architecture embodiment(SDNv1 as an example)Requirements study Logical Arch.Physical Arch.Define basic requirements of in-vehicle SDN from the upper-level requirements(SDV),and study the in-vehicle architectur

24、e suitable for the basic requirements.2023 JASPAR All Rights Reserved.13Requirement analysis:analysis of upper requirements(SDV)Image of SDV defined by JASPARIn addition to being reprogrammable by OTA,the car canautomatically and instantlyswitch configurationsaccording to the users request and conte

25、xt without software reprogramming nor necessarily being connected to the cloudHere,context means the state where the vehicle,driver,etc.,are placed;it can change frequently and reversibly.Examples:Enable/turn off the functions depending on the driver,Activate/deactivate the functions according to lo

26、cation and time etc.For networks,it is equivalent to switch network configuration.Function 2023 JASPAR All Rights Reserved.14Requirement analysis:Requirement analysis for automotive SDNStudy requirements by applying them to concrete use cases(scenarios)Plug and play(change configuration after adding

27、 ECU)OTA(change configuration after software update)OTA(temporary change configuration during software download)Requirements for automotive SDN(from the JASPARs SDV image)A mechanism that can switch(network)configurationsautomatically and immediatelyaccording to user requests and contextwithout repr

28、ogramming softwareor necessarily connecting to the cloud.2023 JASPAR All Rights Reserved.15Example of assumed use case(Configuration change after Plug and Play)EthernetSwitchEthernetSwitchECUECUAdditionalECUExisting communicationAdditional comm.Cope with additional communications by changing configu

29、rations such as paths using SDN.Post-mount ECU to a vehicle after SOP(Plug and Play:PnP)I.Connect an additional ECU to a free port(Trigger for the start of SDN)II.Collect topology/application information of the whole network.III.Based on the information,derive an appropriate network configuration.IV

30、.Apply the new configuration to each Ethernet switch.V.A new communication path is established between the existing ECUs and the additional one.Detail of“Switch configurations according to user requests and context”Note that the blue parts are common and do not depend on the use case.SOP:Start Of Pr

31、oduction 2023 JASPAR All Rights Reserved.16Definition of Requirement:Study on SDN requirements(Minimum requirements)Trigger acceptanceFunction to detect trigger of configuration changeInformation collection/Configuration derivationFunction to derive appropriate network configuration according to net

32、work topology(Connection status)Function to derive appropriate network configuration according to application demandsReflection of configurationFunction to reflect the derived network configuration to the Ethernet switches.Define basic requirements for automotive SDNbased on the common requirements

33、of the assumed use casesAssume use casesBasic requirements for automotive SDNEthernetSwitchEthernetSwitchECUECUAdditionalECUExisting communicationAdditional comm.Cope with additional communications by changing configurations such as paths using SDN.Post-mount ECU to a vehicle after L/O(Plug and Play

34、:PnP)EthernetSwitchEthernetSwitchECUECUExisting communicationAdditional comm.Cope with additional communications by changing configurations such as paths using SDN.ECUFunctional updateby OTA(Adding a service)EthernetSwitchEthernetSwitchECUECUExisting communicationAdditional comm.Cope with additional

35、 communications by changing configurations such as paths using SDN.ECUFunctional updateby OTA(Adding a service)2023 JASPAR All Rights Reserved.17Analysis of existing architecture(Automotive/ICT field)Conventional in-vehicle network devices(Non-SDN switches)SDN-supported network devicesin the ICT fie

36、ld(e.g.,OpenFlow)ArchitectureFeaturesAutonomous distributed network controlComplete controls within each switch(SW)Centralized network controlSeparate control function and data transfer functionThe SDN controller collects information from the whole network and centrally controls SWs.Basic actionsOpe

37、rates based on fixed network(NW)configuration input during SOPAt receiving an unknown flow,SW asks the controller.The controller derives new NW configurations(flow table)by dynamic calculation.SW sets the configuration at the controllers request.IssuesWorks with no controller(brain)and fixed configu

38、ration(multiple SWs work individually)All switches need to be reprogrammed every time the NW configuration is changed.Since the processing load on the controller is large,it is unsuitable for automotive use.No automotive SW-IC supports OpenFlow.(HW processing is mandatory for satisfying performance.

39、)It is necessary to consider an architecture suitable for automotive use to deal with the above issues.2023 JASPAR All Rights Reserved.18Study on automotive architecture(JASPARs proposal)Hybrid architecture(assuming in-vehicle SDNv1)ArchitectureFeatureCombine distributed and centralized network cont

40、rolBasic actionsHold multiple NW configurations during SOP.Normally work with preset fixed configuration.Controller selects a new configuration based on an external trigger and collected information.SWs set the config.by controllers instruction.DelightReduction of processing load on the controllerRe

41、duction of reprogramming for configuration changeCentralizedDistributedCentralizedDistributedAn architecture that keeps the advantages of centralized controland compensates for its disadvantages by combining distributed one 2023 JASPAR All Rights Reserved.19Realization of Architecture:Study on Requi

42、rements for SDNv1BasicrequirementsDemandFunction requirements独立型集中型Trigger acceptanceReady for updates(Software/Hardware)Function to detect SDN execution triggers or receive SDN execution requests from other functionsInformation collectionReady for updates(Software/Hardware)Function to collect topol

43、ogy information and software configuration,or receive them from other functionsConfiguration derivationSelect from preset configurationsFunction to store verified configurations in advanceFunction to select appropriate configuration based on the combination of collected topology information and soft

44、ware configurationConfiguration reflectionStopped(at startup)Function to request configuration changes to switchesFunction to save the selected configuration in a non-volatile areaFunction that can read the new configuration at the next startup(IG:OFF to ON)Software:Reprogramming/OTAHardware:Plug an

45、d PlayDistributedCentralizedCorresponding architectureSubdivide functional requirements into more detailed onesbased on requirements for SDNv1 2023 JASPAR All Rights Reserved.20Realization of Architecture:Role of SDN System(an Example)Control flowDate flowLegendsDetecttriggerSDN systemUser/Existing

46、systemTopologyinformationSoftwareconfigurationNetworkconfiguration契機検出CollectInformationReflectconfigurationDeriveconfigurationNetworkconfigurationDealer tools、Other functions such as OTA systemNetworkstatisticsCentralizedDistributedCentralizedCentralizedDistributedConfigure the SDN system based on

47、the functional requirementson the previous slide(Concretion of roles)Centralized 2023 JASPAR All Rights Reserved.21Materialization of Architecture:Logical Architecture of SDNv1OTAsystemPnPsystemSDNControllerReflect SDNconfigurationTopology informationSoftware configurationNW configuration selectionN

48、W configurationEthernetswitchNWconfigurationFunctionOverviewDistributedCentralizedSDN controllerSelect an appropriate configuration according to the network status and instruct the SDN configuration reflection function to change the switch-related parameters.SDN configuration reflectionChange switch

49、-related parameters according to the requests from the SDN controller function.SDN controller function and SDN configuration reflection functionare defined as inevitable functions.Other function/system 2023 JASPAR All Rights Reserved.22Materialization of Architecture:Physical architecture for SDNv1(

50、an Example)ECUECUAdditionalECU新通Support additional communications by changing the Ethernet switch configuration by SDNPost-mount ECU to a vehicle after SOP(Plug and Play:PnP)Ethernet switch(Central ECU)Ethernet Switch(Zonal ECU)Reflect SDN configurationSDNControllerSwitch functionReflect SDN configu

51、rationSwitch functionOTA Master(Head of OTA system)PnP Master(Head of PnP system)CentralizedDistributedDistributedIn the case of central&zonal architecture,the controller function is placed in the central ECU,and the network configuration of the zonal ECU is centrally managed.(The switching function

52、 of each zonal ECU works autonomously.)CentralizedCentralized 2023 JASPAR All Rights Reserved.23Agenda1.Introduction2.Background&Objectives3.A study of Automotive SDN JASPARs automotive use case&roadmap Functional Requirements for Automotive SDN Architecture(Logical&Physical)4.Future works(Verificat

53、ion by PoC)5.Conclusions 2023 JASPAR All Rights Reserved.24Configuration of PoC system(planned)Single board computer(commercial product)Switch IC Evaluation boardCentral ECU(Emulated)Zonal ECU(Emulated)End ECU(Emulated)SDNconfiguration reflectionSDNControllerSDN設定反映Switchingfunction中継機能OTAMasterPnPM

54、asterFunctions to be verifiedPeripheral functions required for PoC(not subject to verification)Single board computerInformation provision function to OTA/PnP masterCommunicationfunctionSingle board computerSwitch ICEvaluationboardSDNconfiguration reflectionSwitchingfunctionEquipped with non-automoti

55、ve SoCApplication implementation on automotive OS(AGL)Data transmissionfunctions(Data plane)CentralizedDistributedDistributed100BASE-T1To quickly verify the feasibility of the architecture,it consists of a combination of commercial boards.(Automotive products are selected for the vital switch IC.)Th

56、e lower layer of SDN is based on the IEEE 802.1 TSN standard.Controlfunctions(Control plane)CentralizedCentralized(Other functions)Automotive Switch IC（RTL9071C series）(Joint demonstration)2023 JASPAR All Rights Reserved.25Evaluation planThe results of our verification will be fed back to the functi

57、onal requirements and architecture for SDNv1 and will be publishedas a JASPAR standard document(March 2024).Evaluation items(draft)Verification of a flow of functionsFrom Trigger acceptance to Configuration reflectionStatic/Dynamic configuration of switchesProcessing timeLatency,configuration time,e

58、tc.Amount of traffic for SDN controlBandwidth usage of the trafficResourcesCPU loadAmount of memory.2023 JASPAR All Rights Reserved.26ConclusionsTo realize SDV,dealing with the trinity of software,hardware,and network is essential.Automotive SDN is a general term for technologies that can dynamicall

59、y change the configuration and functions of networks;it is highly compatible with the evolution of SDV and can coexist with existing technologies(OTA reprogramming,etc.).It isnt easy to directly apply SDN technology in the ICT field to vehicles.JASPAR is studying architecture suitable for automotive

60、 use.This presentation proposes a novel hybrid architecture that combines the advantages of distributed network control and centralized network control.After proof by PoC,the results will be published as a JASPAR standard document(March 2024).2023 JASPAR All Rights Reserved.27Thank you for your kind attention.