end-to-end connectivity design with automotive ethernet & … · 2020. 9. 2. · services...

2018 IEEE-SA Ethernet & IP @ Automotive Technology Day

End-to-End Connectivity Design with

Automotive Ethernet & Service-Oriented Architecture

Wonseon SimHyundai Motor Group

Seung Jun LeeAirPlug, Inc.


Contents

• Service-Oriented Architecture• Background• Benefits

• End-to-End Service-Oriented Architecture• Challenges & Approach• Overall Architecture• SoA Adaptor• SoA Gateway• SD Proxy & Service Router

• Use Case

• Concluding Remarks


Service-oriented Architecture- Background- Benefits


[SoA] Background

• Innovation of Automotive Network : Automotive Ethernet & IP• Faster & Unicast/Multicast/Broadcast Support

• Logical & Dynamic Configuration

• Innovation also in System/Software area : Service-Oriented Architecture (SoA)• “Services” : reusable, remotely accessible, independently maintainable

• An application can consume services regardless of service location.

• Services provided through SoA Middleware running on top of Automotive Ethernet & IP.

Automotive Ethernet

TCP/IP

SoA M/W

Svc1 Svc2 Svc3

Automotive Ethernet

TCP/IP

SoA M/W

Svc4 Consumer Application

Automotive Ethernet Switch (Router)


[SoA] Benefit

• Standardized Interface & Location Transparency• Reduced Cost for Manufacturing & Test

• Reduced Time for Development of Vehicles & Connected Car Services

• Efficient Handling of Models/Options

• Extendibility

Without SoA With SoA

Actua tingMain Logic 1

Main Logic 2

ECU 1

ECU 2

Main Logic 3

Cloud

Sens ing

Interface#3

Interface#2

Interface#1

Sens ing Actua tingMain Logic 1

Middleware

Main Logic 2

Main Logic 3

Services

StandardizedService

API


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


[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 Service-level Interoperation with External Devices • External network characteristic different from that of IVN• More Critical Security Issues

• Needs for efficient Handling of Service-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 • Services should be found easily but only by allowed ECU’s• Services should be accessed easily but only by authorized Service Consumers• Interoperability & Resource issues might arise.


[E2E SoA] Approach

• Legacy In-vehicle Network Issues Information/Functions from Legacy IVN transformed to “Services” with SoA Adaptor

• Needs for Service-level Interoperation with External Devices Service-level transparency achieved with SoA Gateway

• Security and Other Issues of SoA from the nature of Distributed System

Centralized Service Discovery (SD) architecture using SD Proxy

Security- or Resource-Critical Services made accessible through Service Router

Efficient and Secure End-to-End Service-oriented Architecture


[E2E SoA] Overall Architecture

• End-to-End Service-oriented Architecture

• Extended Service-level Transparency and Integrated Service Design

CANIFC

SoAAdaptor

Ethernet Switch

Services & Consumers

SvcRout

SDPrxy

SoAG/W

Ext.NWIFC

CloudFunctions

Ethernet-based IVN External NetworksLegacy IVN

External Function& Information

Legacy Function& Information

Services from/toEthernet ECU’s, Legacy ECU’s, and External Devices

End-to-End Service-level Transparency

Svc/ProtocolTranslation

Svc/TrafficMgmt

Svc/ProtocolTranslation


[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 “Services”,

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.

• Services provided by SoA Adaptor can be changed dynamically.


Svc-CSvc-P2

[E2E SoA] SoA Adaptor

• (Example) SoA Adaptor on Bridging ECU for CAN Networks

CAN Interface& CAN Routing

Ethernet Switch

Consumer App

Legacy ECU’son CAN Networks

• Get_rpm• Subscribe_to

_brake_event

Signal Extraction &

Msg Composition

Signal/ServiceTransl.

Svc-P1

TCP/IPAut. Ethernet

Bridging ECU

SoA Adaptor

TCP/IPAut. Ethernet

SOME/IP

brake signal

rpm signalEthernet ECU

SOME/IP


[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 Services, when needed.

• Caches external information to deal with availability & cost issues of external networks.

• Applies Policy and Performs Service-level Access Control.

• Should be implemented on ECU’s with external connectivity.


[E2E SoA] SoA Gateway

• (Example) SoA Gateway for Cloud Function Interworking

TCP/IPExt. NW. Interface

Ethernet Switch

Svc

SOME/IP

TCP/IPAut. Ethernet

ECU with External Network Interface

SoA G/W

Consu. App

TCP/IPAut. Ethernet

SOME/IP

ECU insideVehicle

Service

• Location• Veh. speed

• Get_RoadCond• Get_WeathFcst

CloudFunctions

&Services

MQTT,CoAP, etc.

Svc Trans

.Prot.Conv.

Policy & Ctrl

• RoadCond• WeathFcst

• Get_Loc• Get_Speed

Cloud Servers

Caching


[E2E SoA] SD Proxy

• Centralized SD can be achieved using SD Proxy• Service 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.

• Service availability and search/subscription attempt can be efficiently monitored.

ECU 1

ServiceProvider

ECU 2

ServiceConsumer

ECU withSD Proxy

SDProxy

Discovery InformationService Information


[E2E SoA] Service Router

• Issues from distributed nature of SoA can be handled using Service Router• Services can be consumed only through Service Router.

• Service 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.

• Service 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

ServiceProvider

ECU 2

ServiceConsumer

ECU withService Router

SDProxy

Discovery InformationService Information

ServiceRouter

ECU 3Service

Consumer


Use Case


[Use Case] Battery Status Check & Notification

CANIFC

SoAAdaptor

Ethernet Switch

SoAG/W

Ext.NWIFC

CloudFunctions

BatteryIgnition

User Noti.ServiceNoti_BatteryStatus

Send_Noti2User

• Case 1 – Check battery status & Notify status to user

“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”

Provided Service

Provided Service(not used)

Ext. DeviceComm. Service

Head Unit Comm. Unit

Ignition_ON/OFF

Ignition_ON/OFF

Send_SMS2Device

Send_Noti2Device

Display(MIL)

Speaker

Service Consuming

Send_SMS2Device

Door Lock/Unlock

Batt.Check

Svc Router



CANIFC

SoAAdaptor

Ethernet Switch

SoAG/W

Ext.NWIFC

CloudFunctions

BatteryIgnition


Send_Noti2User

• Case 2 – Add function to notify message to user’s handset

“User Noti. Service” 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. Service” 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)

Provided Service

Provided Service(not used)


Head Unit Comm. Unit

Ignition_ON/OFF

Ignition_ON/OFF

Send_SMS2Device

Send_Noti2Device

Display(MIL)

Speaker

Service Consuming

Send_SMS2Device

Door Lock/Unlock

Batt.Check

Svc Router



CANIFC

SoAAdaptor

Ethernet Switch

Batt.Check SoA

G/W

Ext.NWIFC

CloudFunctions

BatteryIgnition


Send_Noti2User

• Case 3 – Send command (from external device) to vehicle legacy system

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 Service Router)

Provided Service


Head UnitComm. Unit

Ignition_ON/OFF

Send_SMS2Device

Send_Noti2Device

Lamp

Speaker

Service Consuming

Send_SMS2Device

Ignition_ON/OFF

Door Lock/Unlock

Svc Router


Concluding Remarks

• Automotive Ethernet & IP brought innovation in automotive system/software architecture

: Service-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 Service 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.

end-to-end connectivity design with automotive ethernet & … · 2020. 9. 2. · services...

Documents