End-to-End Connectivity Design with Automotive Ethernet & Service-Oriented Architecture

Transcription

1 End-to-End Connectivity Design with Automotive Ethernet & -Oriented Architecture Wonseon Sim Hyundai Motor Group Seung Jun Lee AirPlug, Inc.

2 Contents -Oriented Architecture Background Benefits End-to-End -Oriented Architecture Challenges & Approach Overall Architecture SoA Adaptor SoA Gateway SD Proxy & Router Use Case Concluding Remarks

3 -oriented Architecture - Background - Benefits

4 [SoA] Background Innovation of Automotive Network : Automotive Ethernet & IP Faster & Unicast/Multicast/Broadcast Support Logical & Dynamic Configuration Innovation also in System/Software area : -Oriented Architecture (SoA) s : reusable, remotely accessible, independently maintainable An application can consume services regardless of service location. s provided through SoA Middleware running on top of Automotive Ethernet & IP. Svc1 Svc2 Svc3 SoA M/W TCP/IP Svc4 Consumer Application SoA M/W TCP/IP Automotive Ethernet Automotive Ethernet Automotive Ethernet Switch (Router)

5 [SoA] Benefit Standardized Interface & Location Transparency Reduced Cost for Manufacturing & Test Reduced Time for Development of Vehicles & Connected Car s Efficient Handling of Models/Options Extendibility Sensing Interfa ce #3 Main Logic 1 Actua ting Se ns ing Standardized API Main Logic 1 Actua ting ECU 1 s Main Logic 2 Interfa ce #2 Main Logic 2 ECU 2 Main Logic 3 Interfa ce #1 Main Logic 3 Cloud Middleware Without SoA With SoA

6 End-to-End -oriented Architecture - Challenges & Approach - Overall Architecture - SoA Adaptor / SoA Gateway - SD Proxy / Router

7 [E2E SoA] Challenges Legacy In-vehicle Network (IVN) Legacy IVN (e.g., CAN) will co-exists with Ethernet at least for a certain time period SoA not directly applicable to these legacy IVN s Needs for -level Interoperation with External Devices External network characteristic different from that of IVN More Critical Security Issues Needs for efficient Handling of -related Information Added and updated frequently Should be accessible from many interested parties Security and Other Issues of SoA from the nature of Distributed System s should be found easily but only by allowed ECU s s should be accessed easily but only by authorized Consumers Interoperability & Resource issues might arise.

8 [E2E SoA] Approach Legacy In-vehicle Network Issues Information/Functions from Legacy IVN transformed to s with SoA Adaptor Needs for -level Interoperation with External Devices -level transparency achieved with SoA Gateway Security and Other Issues of SoA from the nature of Distributed System Centralized Discovery (SD) architecture using SD Proxy Security- or Resource-Critical s made accessible through Router Efficient and Secure End-to-End -oriented Architecture

9 [E2E SoA] Overall Architecture End-to-End -oriented Architecture Extended -level Transparency and Integrated Design Legacy Function & Information s from/to Ethernet ECU s, Legacy ECU s, and External Devices External Function & Information CAN IFC SoA Adaptor s & Consumers Svc Rout SD Prxy SoA G/W Ext. NW IFC Cloud Functions Svc/Protocol Translation Svc/Traffic Mgmt Svc/Protocol Translation Ethernet Switch Legacy IVN Ethernet-based IVN External Networks End-to-End -level Transparency

10 [E2E SoA] SoA Adaptor Legacy In-vehicle Network Many ECU s still work based on legacy IVN like CAN Large portion of vehicle information/functions are from legacy IVN These should be made accessible to new applications on Ethernet-based ECU s. SoA Adaptor Transforms Information/Functions from Legacy IVN to s, which applications on any Ethernet-based ECU s can easily access. On Ethernet side, services are provided on top of SOME/IP protocol. Can be implemented on bridging ECU between legacy IVN and Ethernet-based IVN, like Domain Control Unit, Zone Controller, etc. Also can be implemented on non-bridging ECU s only with Ethernet interfaces. s provided by SoA Adaptor can be changed dynamically.

11 [E2E SoA] SoA Adaptor (Example) SoA Adaptor on Bridging ECU for CAN Networks Signal Extraction & Msg Composition Signal / Transl. Svc-C Svc-P2 Svc-P1 SOME/IP SoA Adaptor Consumer App SOME/IP Get_rpm Subscribe_to _brake_event CAN Interface & CAN Routing TCP/IP Aut. Ethernet TCP/IP Aut. Ethernet rpm signal Bridging ECU Ethernet ECU brake signal Ethernet Switch Legacy ECU s on CAN Networks

12 [E2E SoA] SoA Gateway External Devices on External Network Vehicle needs to interwork with external devices like cloud servers and smart devices. Interworking need gets much larger for ADAS and other connected car services. External networks has very different characteristics compared to IVN : availability, bandwidth, latency, cost, etc. Protocols for external connectivity are usually different from those for IVN. Higher security issues when interworking through external networks. SoA Gateway Handles issues related with external device/network interworking. Converts Protocols and Translates s, when needed. Caches external information to deal with availability & cost issues of external networks. Applies Policy and Performs -level Access Control. Should be implemented on ECU s with external connectivity.

13 [E2E SoA] SoA Gateway (Example) SoA Gateway for Cloud Function Interworking Get_RoadCond Get_WeathFcst Consu. App SOME/IP Location Veh. speed SoA G/W Svc SOME/IP Policy & Ctrl Prot. Conv. Svc Trans. Cach ing MQTT, CoAP, etc. Cloud Functions & s TCP/IP Aut. Ethernet TCP/IP Aut. Ethernet TCP/IP Ext. NW. Interface Get_Loc Get_Speed RoadCond WeathFcst ECU inside Vehicle ECU with External Network Interface Cloud Servers Ethernet Switch

14 [E2E SoA] SD Proxy Centralized SD can be achieved using SD Proxy discovery messages are exchanged through one central S/W module, called SD proxy. SOME/IP-SD message can be used also for communication between ECU and SD Proxy Security and Traffic issues of distributed SD approach can be handled by Centralized SD Each service can be found and subscribed to by only allowed ECU s. availability and search/subscription attempt can be efficiently monitored. ECU 1 Provider ECU with SD Proxy ECU 2 Consumer SD Proxy Discovery Information Information

15 [E2E SoA] Router Issues from distributed nature of SoA can be handled using Router s can be consumed only through Router. Routing can be applied for selected services : e.g., services with high security level, non-time-critical services, service use across domain. SD Proxy can be used for efficient service routing implementation. Security and Resource Issues can be efficiently handled. access can be controlled based on domain, ECU, service or even method. Policy can be also applied dynamically, e.g., depending on IDS module. ECU 1 Provider ECU with Router Router SD Proxy ECU 2 Consumer ECU 3 Consumer Discovery Information Information

16 Use Case

17 [Use Case] Battery Status Check & Notification Case 1 Check battery status & Notify status to user Ethernet Switch Provided Provided (not used) Consuming Head Unit Comm. Unit Ignition Battery CAN IFC SoA Adaptor Noti_BatteryStatus Ignition_ON/OFF Door Lock/Unlock Batt. Check Svc Rou ter User Noti. Send_Noti2User Ext. Device Comm. Send_Noti2Device Speaker SoA G/W Ext. NW IFC Ignition_ON/OFF Send_SMS2Device Cloud Functions Send_SMS2Device Display(MIL) Battery Check App consumes two services Gets battery status information : subscribing to Noti_BatteryStatus Checks the battery status, Notifies to user, if battery low: invoking Send_Noti2User

18 [Use Case] Battery Status Check & Notification Case 2 Add function to notify message to user s handset Ethernet Switch Provided Provided (not used) Consuming Head Unit Comm. Unit CAN IFC SoA Adaptor Noti_BatteryStatus Batt. Check Svc Rou ter User Noti. Ext. Device Comm. Send_Noti2Device SoA G/W Ext. NW IFC Ignition_ON/OFF Cloud Functions Send_SMS2Device Ignition Battery Ignition_ON/OFF Door Lock/Unlock Send_Noti2User Speaker Send_SMS2Device Display(MIL) User Noti. App Detects that the driver is not in the car : checking Ignition On/Off status and Door Lock/Unlock status Sends notification to user s handset via external network (Bluetooth or SMS) : invoking Send_Noti2Device Ext. Device Comm. App Detects user s handset is not connected through Bluetooth Sends SMS to the handset: invoking Send_SMS2Device (provided by Cloud through SoA G/W)

19 [Use Case] Battery Status Check & Notification Case 3 Send command (from external device) to vehicle legacy system Provided Consuming Ethernet Switch Head Unit Comm. Unit CAN IFC SoA Adaptor Noti_BatteryStatus Batt. Check Svc Rou ter User Noti. Ext. Device Comm. Send_Noti2Device SoA G/W Ext. NW IFC Ignition_ON/OFF Cloud Functions Send_SMS2Device Ignition Battery Ignition_ON/OFF Door Lock/Unlock Send_Noti2User Speaker Send_SMS2Device Lamp Cloud Function Gets user s ignition-on command to re-charge Remotely turn on ignition : invoking Ignition ON (provided by SoA Adaptor through SoA G/W) (Note that Ignition ON/OFF method invocation is routed and access-controlled by Router)

20 Concluding Remarks Automotive Ethernet & IP brought innovation in automotive system/software architecture : -oriented Architecture (SoA) SoA concept can be extended to End-to-End ranging from legacy ECU s to external devices. SoA Adaptor and SoA G/W can be used for legacy and external devices, respectively. SoA can be efficiently managed by using other SoA Entities like SD proxy and Router. End-to-End SoA enables fast and efficient deployment of various connected car services. Other features like variant handling or Plug-and-Play can also benefit from End-to-End SoA. Joint design of SoA and SDN is in progress.