面向服務(wù)架構(gòu)(SOA)：超經(jīng)典合集
[導(dǎo)讀]隨著汽車智能化、網(wǎng)聯(lián)化、共享化的趨勢，終端用戶對車輛功能的預(yù)期也悄然發(fā)生著改變，汽車在實(shí)現(xiàn)高等級自動駕駛/輔助駕駛功能的同時，也更趨向于提升用戶體驗(yàn)，例如滿足快速的功能更新和升級，可以提供個性化、人性化、差異化的功能與服務(wù)等。面向服務(wù)的軟件架構(gòu)(Service-OrientedA...
隨著汽車智能化、網(wǎng)聯(lián)化、共享化的趨勢，終端用戶對車輛功能的預(yù)期也悄然發(fā)生著改變，汽車在實(shí)現(xiàn)高等級自動駕駛/輔助駕駛功能的同時，也更趨向于提升用戶體驗(yàn)，例如滿足快速的功能更新和升級，可以提供個性化、人性化、差異化的功能與服務(wù)等。面向服務(wù)的軟件架構(gòu)(Service-Oriented Architecture)正為未來的車輛軟件服務(wù)提供良好的解決方案。不同于傳統(tǒng)汽車電子電氣架構(gòu)中面向信號的架構(gòu)，面向服務(wù)的軟件架構(gòu)(SOA)通過標(biāo)準(zhǔn)化的服務(wù)接口，松耦合的服務(wù)機(jī)制以及可組合擴(kuò)展的服務(wù)特性，結(jié)合未來以高性能計算平臺——域控制器——為核心的集中化電子電氣架構(gòu)，將成為未來汽車領(lǐng)域“軟件驅(qū)動創(chuàng)新”的技術(shù)基礎(chǔ)。
原子服務(wù)說到服務(wù)架構(gòu)，關(guān)于原子服務(wù)的話題非?；?，那么，什么是原子服務(wù)？原子服務(wù)有哪些特征？在系統(tǒng)層面如何拆分業(yè)務(wù)服務(wù)并且定義原子服務(wù)？原子服務(wù)對我們的軟件又有什么影響呢？他和服務(wù)的關(guān)系又是什么呢？
我們先從服務(wù)的最小單元——原子服務(wù)講起。原子服務(wù)的定義是：業(yè)務(wù)上最小粒度的一系列操作。原子服務(wù)的特點(diǎn)是松耦合，相對獨(dú)立，且在可預(yù)見的范圍內(nèi)不會對其他原子服務(wù)造成影響。任何一項(xiàng)都劃定了自己的業(yè)務(wù)范圍；他們不用關(guān)心非自己業(yè)務(wù)范圍是如何實(shí)現(xiàn)，對于調(diào)用其他原子服務(wù)，只需要考慮調(diào)用場景及返回結(jié)果如何處理即可。
舉一個例子，先看看下面三句話：
這三句話中的，現(xiàn)金存款、信用卡還款和現(xiàn)金轉(zhuǎn)賬就是服務(wù)，現(xiàn)金交易就是原子服務(wù)，而金融賬戶、銀聯(lián)卡和信用卡則是服務(wù)的業(yè)務(wù)參與方，也是大家熟知的服務(wù)消費(fèi)者和提供方。
通過這個例子，大家應(yīng)該對原子服務(wù)已經(jīng)有了一個基本的概念。那么，服務(wù)是由原子服務(wù)構(gòu)成的，SOA是不是只是簡單地由服務(wù)構(gòu)成的呢？
1. SOA 架構(gòu)的特性
答案很顯然，要實(shí)現(xiàn)真正完整的 SOA 架構(gòu)，只靠原子服務(wù)和服務(wù)是不夠的。首先，我們看一下SOA的基礎(chǔ)定義：
SOA基于服務(wù)的架構(gòu)，繼承了來自對象（指的是“面向?qū)ο蟮募軜?gòu)”）和構(gòu)件設(shè)計的各種原則，例如，封裝和自我包含等。那些保證服務(wù)的靈活性、松散耦合和復(fù)用能力的設(shè)計原則，對 SOA 架構(gòu)來說同樣是非常重要的。
關(guān)于服務(wù)的基本特性如下：
標(biāo)準(zhǔn)接口服務(wù)提供方以統(tǒng)一的方式即標(biāo)準(zhǔn)的接口向消費(fèi)者提供服務(wù)信息，比如車載服務(wù)軟件一般會使用SOME/IP協(xié)議作為實(shí)現(xiàn)基礎(chǔ)。自主和模塊化服務(wù)封裝了那些在業(yè)務(wù)上穩(wěn)定、重復(fù)出現(xiàn)的活動和構(gòu)件，實(shí)現(xiàn)服務(wù)的功能實(shí)體是完全獨(dú)立自主的，獨(dú)立進(jìn)行部署、版本控制、自我管理和恢復(fù)。松耦合服務(wù)請求者可見的是服務(wù)的接口，其位置、實(shí)現(xiàn)技術(shù)、當(dāng)前狀態(tài)和私有數(shù)據(jù)等，對服務(wù)消費(fèi)者而言是不可見的。互操作性、兼容和策略聲明為了確保服務(wù)規(guī)約的全面和明確，策略成為一個越來越重要的方面。例如，一個服務(wù)對安全性方面的要求；也可以是與業(yè)務(wù)有關(guān)的語義方面的內(nèi)容，例如，需要滿足的費(fèi)用或者服務(wù)級別方面的要求，這些策略對于服務(wù)在交互時是非常重要的。
而服務(wù)的最小顆粒度則是上文提到的不可拆分的原子服務(wù)。那原子服務(wù)的顆粒度是不是越小越好呢？答案肯定不是的，如何定義合理的原子服務(wù)，如何把握顆粒度的大小，在服務(wù)架構(gòu)設(shè)計中至關(guān)重要。舉個更形象的例子，原子服務(wù)就類似于電路設(shè)計中的電容和電阻，他們有著統(tǒng)一的標(biāo)準(zhǔn)，看似一樣卻又有著不同的封裝，在不同的ECU控制器中組合成不同的應(yīng)用電路，適當(dāng)調(diào)整又能實(shí)現(xiàn)非常多的新的功能。
2.?SOA架構(gòu)的實(shí)現(xiàn)基礎(chǔ)
有了理論基礎(chǔ)，下一步就是看實(shí)現(xiàn)服務(wù)架構(gòu)的必要條件。很多同學(xué)其實(shí)會問，為什么服務(wù)總是和以太網(wǎng)，DDS或SOME/IP綁定的呢？CAN網(wǎng)絡(luò)上是否可以實(shí)現(xiàn)完整的SOA架構(gòu)？
首先，以SOME/IP舉例，因?yàn)镾OME/IP的完整名稱其實(shí)能回答上面的大多數(shù)問題，SOME/IP = Scalable service-Oriented MiddlewarE over IP。即“運(yùn)行于IP之上的可伸縮的面向服務(wù)的中間件”?？梢?，并不是SOA必須和SOME/IP綁定，而是SOME/IP天生就是為了SOA架構(gòu)而生。SOME/IP的精華在于“Middleware中間件”，這是一種獨(dú)立的系統(tǒng)軟件或服務(wù)程序，分布式應(yīng)用軟件可借助Middleware在不同的技術(shù)之間共享資源。分布式應(yīng)用軟件，在這里指的就是“服務(wù)”；不同的技術(shù)之間，在這里指的就是不同的平臺或操作系統(tǒng)，比如Linux系統(tǒng)或AUTOSAR OS OSEK等。而Scalable Middleware，顧名思義，則是“可伸縮中間件”，指的是該中間件能夠適配于不同的平臺及操作系統(tǒng)，其支撐的平臺可大可小。
簡單來說，SOA是軟件架構(gòu)的一種設(shè)計理念；SOME/IP是一種將軟件接口進(jìn)行打包的打包方式，是一種中間件。而汽車行業(yè)通常所指的"以太網(wǎng)"是泛化之后的概念，涵蓋了基于以太網(wǎng)技術(shù)所實(shí)現(xiàn)的各種相關(guān)技術(shù)手段，包括TCP/IP協(xié)議、DoIP協(xié)議、SOME/IP協(xié)議等。當(dāng)然若通過其他非以太網(wǎng)的通信方式來實(shí)現(xiàn)SOA也是可行的，但通常大家不那么用。比如基于CAN總線的架構(gòu)，由于其基礎(chǔ)的架構(gòu)和通信協(xié)議棧里不存在Middleware中間層的概念，所以要實(shí)現(xiàn)SOA的代價是非常巨大的。
3. SOA 應(yīng)用的優(yōu)勢
正如大家所知，早期的車內(nèi)嵌入式軟件沒有統(tǒng)一標(biāo)準(zhǔn)，基礎(chǔ)軟件和應(yīng)用軟件強(qiáng)耦合，不具可移植性；AUTOSAR Classic 的應(yīng)用，對嵌入式基礎(chǔ)軟件的接口進(jìn)行標(biāo)準(zhǔn)化，讓應(yīng)用開發(fā)者基于統(tǒng)一的基礎(chǔ)軟件接口進(jìn)行應(yīng)用開發(fā)。目前采用SOA軟件服務(wù)架構(gòu)的應(yīng)用打通了車內(nèi)的電子電氣架構(gòu)的壁壘，進(jìn)一步對嵌入式應(yīng)用軟件的接口(即服務(wù)接口)進(jìn)行了標(biāo)準(zhǔn)化，讓APP開發(fā)者基于統(tǒng)一基礎(chǔ)服務(wù)接口進(jìn)行應(yīng)用的迭代開發(fā)，隱藏了不同車型配置下應(yīng)用軟件的差異，真正做到了整車級軟件接口的"標(biāo)準(zhǔn)"和"開放"。
4. SOA 的應(yīng)用實(shí)例
正如上文提到的，一旦自動駕駛域不再成為電子電氣孤島，那么他的傳感器、雷達(dá)、攝像頭都能成為整車功能體驗(yàn)提升的利器。同時，由于區(qū)域控制器ZONE具有服務(wù)轉(zhuǎn)換能力，ADAS計算中心也不需要拖著大量的傳感器，雷達(dá)或攝像頭一一連接，只需要簡單從服務(wù)中間層直接發(fā)起調(diào)度請求即可。下面是一個潛在的開發(fā)實(shí)例：
第一階段也就是目前90%的E/E架構(gòu)中所使用的平行式分布，由于ZONE在初期無法實(shí)現(xiàn)LVDS和攝像頭視頻的處理能力，所以暫時不會動AD的“孤島”。但是其他的比如車身等相關(guān)的會通過區(qū)域控制器的服務(wù)轉(zhuǎn)換能力，將信號打包成業(yè)務(wù)服務(wù)。
當(dāng)然，ZONE區(qū)域控制器并不是簡單的hub，在拆分和打包服務(wù)的同時，也會同步進(jìn)行原子服務(wù)的開發(fā)和豐富，后續(xù)隨著整車的FOTA更新，我們的原子服務(wù)越來越完善，同步也會有更多豐富的業(yè)務(wù)服務(wù)在互聯(lián)互通的大環(huán)境下呈現(xiàn)給用戶。
第二階段在這個階段，隨著區(qū)域下一代產(chǎn)品的發(fā)展，會在硬件上具備一些特殊接口的集成能力，例如上圖中原來AD的專屬武器如雷達(dá)或分布式攝像頭等可以直接連接到區(qū)域控制器，這一步看上去僅僅是硬件兼容的一小步，但卻是E/E架構(gòu)升級的一大步。因?yàn)檫@意味著，環(huán)境感知服務(wù)的使用權(quán)被平等地交付到了每個域手中。
如果說過去的車身域是電子域，一旦環(huán)境感知信號的引入，會讓車身域真正地進(jìn)化出“眼睛”，燈光、雨刮、天窗、門鎖、防盜不再是冷冰冰的電子功能，他們會成為整車人工智能的新入口，從電子域進(jìn)化為智能域。一些過去只存在想象中的功能，例如視覺識別天氣自動調(diào)整雨刮、根據(jù)周圍行人和車輛自動調(diào)整燈光方向、單人使用車輛的時候僅解鎖離車主最近的一扇門，這些功能都不再是幻想。
第三階段也是BOSCH體系定義的電子電氣架構(gòu)最終階段，區(qū)域控制器會“返璞歸真”，將所有特殊接口的能力打包成真正統(tǒng)一的虛擬服務(wù)接口，而這其中的關(guān)鍵條件則在于區(qū)域控制器是否具備了完整的原子服務(wù)，例如，一旦區(qū)域能夠提供“視頻解析”的原子服務(wù)，那么我們無需在區(qū)域上接入LVDS信號，直接通過千兆以太網(wǎng)將視頻服務(wù)“原封不動”地傳遞到區(qū)域上，然后在區(qū)域控制器里會有對應(yīng)的“解碼器”，將這些信號解析、解碼、重構(gòu)、并打包成服務(wù)，以極低的延時和極高的保真率提供給不同的處理單元和控制模塊。
而這個階段一旦實(shí)現(xiàn)，接口的標(biāo)準(zhǔn)化和統(tǒng)一化會上升到新的高度，整車電子電氣架構(gòu)的成本也可以大幅度下降，主干網(wǎng)通過以太網(wǎng)傳遞服務(wù)，支路通過CAN/LIN等傳統(tǒng)總線收集原子服務(wù)需要的信號流，所有的系統(tǒng)、軟件、硬件有條不紊地在自己的服務(wù)領(lǐng)域中開發(fā)。未來，一輛既便宜、又智能的“溫馨智能移動起居室”指日可待。
第一部：面向服務(wù)架構(gòu)(SOA)的汽車軟件及其開發(fā)方法
一. 為什么要引入SOA汽車軟件?
SOA是一種軟件架構(gòu)，同時也是一種軟件設(shè)計方法和理念，在IT領(lǐng)域已有數(shù)十年的應(yīng)用經(jīng)驗(yàn)。SOA具備”松耦合”、”接口標(biāo)準(zhǔn)可訪問”和”易于擴(kuò)展”等特點(diǎn)，使得開發(fā)人員能以最小的軟件變更應(yīng)對迭代多變的客戶需求。在智能網(wǎng)聯(lián)汽車中，大量的功能需要控制器（ECU）間的協(xié)調(diào)工作來實(shí)現(xiàn)，當(dāng)前ECU 間基于信號(Signal-Oriented)的點(diǎn)對點(diǎn)通訊將會變得異常復(fù)雜，且不具備靈活性和擴(kuò)展性，微小的功能改動都會引起整車通訊矩陣的改動(圖1)。因此，聯(lián)合電子將SOA引入到當(dāng)前汽車軟件設(shè)計中(圖2)，車輛功能被以面向服務(wù)的設(shè)計理念架構(gòu)為不同的服務(wù)組件，有別于面向信號的傳統(tǒng)架構(gòu)，SOA中的每個服務(wù)都具有唯一且獨(dú)立互不影響的身份標(biāo)識(ID)，并通過服務(wù)中間件(Service Middleware)完成自身的發(fā)布，對其他服務(wù)的訂閱以及與其他服務(wù)的通訊工作。由此，SOA良好的解決了傳統(tǒng)架構(gòu)中因個別功能增減/變更而導(dǎo)致整個通訊矩陣與路由矩陣都要變更的問題。更進(jìn)一步，由于其”接口標(biāo)準(zhǔn)可訪問”的特性，服務(wù)組件的部署不再依賴于具體特定的操作系統(tǒng)和編程語言，在一定程度上實(shí)現(xiàn)了組件的”軟硬分離”。圖1 面向信號的架構(gòu)(Signal-Oriented Architecture)圖2 面向服務(wù)的架構(gòu)(Service-Oriented Architecture)二. 如何有效的開發(fā)SOA汽車軟件？
對于汽車行業(yè)而言，SOA是一套新引入的技術(shù)，需要一套有效的流程、方法和工具，用以解決如下三個問題：1) 如何分析和設(shè)計服務(wù)架構(gòu)，2) 如何建模和記錄服務(wù)架構(gòu)，3)如何部署和實(shí)現(xiàn)面向服務(wù)的軟件。- 如何分析和設(shè)計面向服務(wù)的架構(gòu)?
- 如何建模和記錄面向服務(wù)的架構(gòu)?
- 如何部署和實(shí)現(xiàn)面向服務(wù)的軟件
三. SOA汽車軟件創(chuàng)新平臺
聯(lián)合電子開發(fā)的域控制器XCU ，提供了部署SOA汽車軟件的平臺。在硬件方面，XCU具備高算力處理器芯片和多路車規(guī)級以太網(wǎng)通道；在軟件方面，XCU搭載POSIX操作系統(tǒng)和AUTOSAR Adaptive平臺。根據(jù)SOA軟件開發(fā)方法，可從兩個切入點(diǎn)開展SOA汽車軟件平臺的開發(fā)。1)自下至上，從車輛基礎(chǔ)功能/信號出發(fā)，將已有的應(yīng)用功能邏輯/信號(eg:車輛車速信息)抽象或封裝成服務(wù)組件，這類組件被稱為基礎(chǔ)服務(wù)層(Basic/Platform Service Layer)組件，具有最高的可復(fù)用性和可組合性，這些組件將為上層(業(yè)務(wù)服務(wù)層Business Service Layer)的服務(wù)組件提供最基礎(chǔ)的支持。2)自上而下，從整車業(yè)務(wù)邏輯和用例出發(fā)，結(jié)合各領(lǐng)域的核心業(yè)務(wù)知識，設(shè)計業(yè)務(wù)服務(wù)層(Business Service Layer)的服務(wù)組件；同時，遵循服務(wù)組件的復(fù)用性和自主性等原則，向下設(shè)計規(guī)劃基礎(chǔ)服務(wù)層(Basic/Platform Service Layer)的服務(wù)組件(圖8)。http://www.uml.org.cn/soa/images/20210603128.webp.jpg圖8 基于域控制器(XCU)的SOA服務(wù)架構(gòu)四. SOA架構(gòu)的核心要素與優(yōu)勢
SOA作為一種面向服務(wù)的架構(gòu)，是一種設(shè)計思想和方法論。在SOA架構(gòu)中，服務(wù)是最核心的抽象手段和系統(tǒng)最基礎(chǔ)的描述單元。每個服務(wù)組件具備獨(dú)立的功能，且可被復(fù)用；服務(wù)組件之間的接口遵循統(tǒng)一標(biāo)準(zhǔn)，可互相訪問，可組合擴(kuò)展。業(yè)務(wù)過程則是帶有狀態(tài)和服務(wù)調(diào)度策略的服務(wù)組件的組合與擴(kuò)展(圖1)。通過SOA架構(gòu)，可整合規(guī)劃OEM在不同操作系統(tǒng)，硬件平臺上(控制器)上的業(yè)務(wù)功能，實(shí)現(xiàn)對功能的快速迭代和重組，應(yīng)對靈活多變的智能網(wǎng)聯(lián)趨勢下的業(yè)務(wù)需求。http://www.uml.org.cn/soa/images/20210603129.png圖9：SOA架構(gòu)模型結(jié)合未來汽車域?qū)蛐碗娮与姎饧軜?gòu)(Domain-Oriented)和區(qū)域?qū)蛐碗娮与姎饧軜?gòu)(Zone-Oriented)，應(yīng)用SOA架構(gòu)可實(shí)現(xiàn)業(yè)務(wù)過程(功能)的快速迭代與靈活重組，為智能網(wǎng)聯(lián)趨勢下的軟件個性化與創(chuàng)新需求提供了良好的平臺性解決方案。SOA架構(gòu)應(yīng)用于汽車新電子電氣架構(gòu)下的優(yōu)勢(圖2):車輛功能軟件實(shí)現(xiàn)軟硬分離由于服務(wù)組件接口“標(biāo)準(zhǔn)可訪問”，且描述方式獨(dú)立于硬件平臺和操作系統(tǒng)，因此組件功能可脫離硬件平臺任意部署移動，對于算力有要求的復(fù)雜功能組件可向具備高帶寬大算力的域控制器移動。車輛功能可被大范圍復(fù)用一些使用頻度很高且基礎(chǔ)的功能可作為基礎(chǔ)服務(wù)組件先被開發(fā)，由于服務(wù)組件的獨(dú)立性以及接口的標(biāo)準(zhǔn)可訪問，基礎(chǔ)服務(wù)開發(fā)完成后可向服務(wù)中間件注冊，并供所有電子電氣架構(gòu)中的控制器訂閱使用。車輛功能在SOP后可新增(擴(kuò)展)“小”的基礎(chǔ)服務(wù)可組合成為“大”服務(wù)，“大”服務(wù)可進(jìn)一步組合擴(kuò)展并最終構(gòu)建出新的業(yè)務(wù)過程，實(shí)現(xiàn)OEM的業(yè)務(wù)目標(biāo)。結(jié)合OTA技術(shù)，用戶可在車輛使用期限里，訂閱一個類似，“預(yù)測性能量管理”的新功能并安裝于域控制器上，新功能的業(yè)務(wù)邏輯依賴于一些已有的服務(wù)組件(eg:預(yù)測性能量管理依賴于能量管理策略，地圖預(yù)測信息等基礎(chǔ)服務(wù))。http://www.uml.org.cn/soa/images/202106031210.png圖10 新汽車電子電氣架構(gòu)中的SOA架構(gòu)應(yīng)用第二部：面向服務(wù)架構(gòu)（SOA）的汽車軟件分析和設(shè)計
面向服務(wù)架構(gòu)的開發(fā)過程從整體上可以概括為6個步驟，分別是：面向服務(wù)分析、面向服務(wù)設(shè)計、服務(wù)開發(fā)、服務(wù)測試、服務(wù)部署和服務(wù)權(quán)限管理，如圖11所示。其中，分析和設(shè)計面向服務(wù)的架構(gòu)是開發(fā)SOA軟件的開端，也是判斷系統(tǒng)是否基于SOA架構(gòu)的最重要且核心的環(huán)節(jié)。聯(lián)合電子對分析和設(shè)計面向服務(wù)架構(gòu)汽車軟件的具體流程與方法進(jìn)行了探索，將面向服務(wù)的分析分解為系統(tǒng)需求分析、系統(tǒng)功能分析、候選服務(wù)分析三個子步驟，將面向服務(wù)的設(shè)計分解為系統(tǒng)架構(gòu)設(shè)計和軟件架構(gòu)設(shè)計兩個子步驟。經(jīng)過架構(gòu)師的良好分析，車輛功能(業(yè)務(wù)邏輯/業(yè)務(wù)過程)將結(jié)合實(shí)際實(shí)現(xiàn)情況，按不同業(yè)務(wù)領(lǐng)域完成解耦，并分解得到候選服務(wù)組件。后續(xù)，經(jīng)過詳細(xì)且不斷迭代的設(shè)計，在候選服務(wù)的基礎(chǔ)上，最終會產(chǎn)出面向服務(wù)(SOA)的軟件架構(gòu)。http://www.uml.org.cn/soa/images/202106031211.png圖11 面向服務(wù)的分析與設(shè)計是服務(wù)架構(gòu)開發(fā)的核心環(huán)節(jié)接下來本文將圍繞這5個子步驟對面向服務(wù)的分析與設(shè)計過程進(jìn)行介紹。- 系統(tǒng)需求分析
- 系統(tǒng)功能分析
- 候選服務(wù)分析
- 系統(tǒng)架構(gòu)設(shè)計
- 軟件架構(gòu)設(shè)計
第三部：面向服務(wù)架構(gòu)（SOA）的汽車軟件實(shí)現(xiàn)和部署
根據(jù)SOA架構(gòu)層級模型(圖18)，業(yè)務(wù)邏輯經(jīng)過面向服務(wù)架構(gòu)(SOA)的軟件分析和設(shè)計過程后，被分解為單個服務(wù)并綁定相應(yīng)的可執(zhí)行軟件單元。以服務(wù)軟件架構(gòu)為輸入，汽車服務(wù)軟件的實(shí)現(xiàn)和部署工作主要在服務(wù)組件層(Service Components)完成(圖1紅色箭頭)。http://www.uml.org.cn/soa/images/202106031217.png圖 18 SOA 層級架構(gòu)模型01 滿足 SOA 架構(gòu)的服務(wù)組件架構(gòu) (Service-Component-Architecture)針對服務(wù)組件，SOA定義了服務(wù)組件的架構(gòu)模型(SCA)(圖19)，在SCA的框架下，服務(wù)組件內(nèi)部被分為業(yè)務(wù)邏輯(Service)與基礎(chǔ)設(shè)施邏輯(Interface和Message)兩部分，并互相解耦：服務(wù)軟件單元(Service)：業(yè)務(wù)/功能邏輯，不關(guān)心操作系統(tǒng)和編程語言，可由熟悉業(yè)務(wù)邏輯的相關(guān)方開發(fā)接口(Interface)：決定對外提供哪些服務(wù)以及自身服務(wù)依賴哪些服務(wù)，不關(guān)心操作系統(tǒng)和編程語言，可由SOA架構(gòu)設(shè)計方完成開發(fā)和部署消息(Message)：接口數(shù)據(jù)的通訊鏈路/環(huán)境綁定，不關(guān)心操作系統(tǒng)和編程語言，可由SOA架構(gòu)設(shè)計方完成開發(fā)和部署整個服務(wù)組件層的工作是對服務(wù)組件進(jìn)行規(guī)范型描述，描述內(nèi)容主要包含兩個部分:服務(wù)組件架構(gòu)模型SCA的配置描述服務(wù)組件內(nèi)部業(yè)務(wù)邏輯和基礎(chǔ)設(shè)施邏輯的集成http://www.uml.org.cn/soa/images/202106031218.png圖19 SOA服務(wù)組件架構(gòu)模型(SCA)02 服務(wù)組件架構(gòu)SCA的配置描述通過SCA架構(gòu)模型，每個服務(wù)軟件單元(Service)以標(biāo)準(zhǔn)的接口形式(Interface)向消費(fèi)方提供服務(wù)內(nèi)容，以統(tǒng)一的通訊協(xié)議傳遞序列化消息(Message)。對于SOA架構(gòu)設(shè)計和應(yīng)用人員，需要通過工具配置SCA架構(gòu)模型中的參數(shù)，使其與服務(wù)管理組件一同實(shí)現(xiàn)SOA軟件的部署和運(yùn)作。http://www.uml.org.cn/soa/images/202106031219.webp.jpg圖20 SCA架構(gòu)模型中的配置信息SCA架構(gòu)模型中的主要元素分為“服務(wù)接口”和“服務(wù)實(shí)現(xiàn)”兩大類。其中，“服務(wù)接口描述”包含服務(wù)軟件單元(Services)，組件接口(Interface)和消息通訊(Message)；“服務(wù)實(shí)現(xiàn)”則包括通訊協(xié)議綁定(Binding)和服務(wù)端口信息等(Endpoint)(圖20)。WebService的SCA架構(gòu)模型配置描述以IT行業(yè)SOA封裝使用較為廣泛的WebService為例，其對SCA架構(gòu)模型的描述遵從如下標(biāo)準(zhǔn)協(xié)議:http://www.uml.org.cn/soa/images/202106031220.png表1 SCA架構(gòu)模型中的配置信息在IBM公司發(fā)布的SOA系統(tǒng)解決方案- 企業(yè)服務(wù)總線(Enterprise-Service-Bus)中提供了WebSphere Integration Developer開發(fā)環(huán)境，該環(huán)境支持配置生成符合WSDL規(guī)范的服務(wù)組件描述文檔。汽車軟件的SCA架構(gòu)模型配置描述在汽車軟件領(lǐng)域，當(dāng)前，聯(lián)合電子采用AUTOSAR Adaptive組織提供的模型描述規(guī)范。AUTOSAR Adaptive組織對SCA架構(gòu)模型的描述遵循如下標(biāo)準(zhǔn):http://www.uml.org.cn/soa/images/202106031221.webp.jpg表2 SCA架構(gòu)模型中的配置信息03 汽車SOA軟件的實(shí)現(xiàn)方案如上文所述，汽車軟件領(lǐng)域，聯(lián)合電子遵循AUTOSAR Adaptive標(biāo)準(zhǔn)來完成SOA中間件的部署和應(yīng)用，AUTOSAR Adaptive組件采用經(jīng)典的代理(Proxy)-框架(Skeleton)模式來完成SCA架構(gòu)模型的描述(如圖21)。http://www.uml.org.cn/soa/images/202106031222.png圖21 Proxy(stub)/Skeleton架構(gòu)模式這種模式將原本直接交互的調(diào)用者(Client)與被調(diào)用者(Server)分離，由代理負(fù)責(zé)傳遞信息來完成調(diào)用，client和server不需要處理通信層詳細(xì)信息。同時，AUTOSAR Adaptive廠商基于C 語言具體實(shí)現(xiàn)代理-框架模式，確保應(yīng)用服務(wù)開發(fā)人員可以靈活配置自定義的服務(wù)接口，并結(jié)合對應(yīng)工具生成SCA架構(gòu)模型代碼(.cpp/.cc)和配置文件(.json)。具體的，這些代碼：封裝了SOME-IP協(xié)議棧和底層通訊細(xì)節(jié)(Middleware Transport Layer)提供了相應(yīng)的服務(wù)虛接口(virtual function)通過1)，服務(wù)組件開發(fā)人員不必再關(guān)心服務(wù)Message對應(yīng)的協(xié)議如何實(shí)現(xiàn)；通過2)，服務(wù)組件開發(fā)人員基于C 的語言特性，可繼承(inherit)虛接口并覆寫(override)虛接口的具體實(shí)現(xiàn)(函數(shù)體)。該機(jī)制保證了“基礎(chǔ)設(shè)施邏輯”和“業(yè)務(wù)(功能)邏輯”的解耦，服務(wù)內(nèi)部業(yè)務(wù)邏輯的改動不影響服務(wù)組件向外的接口提供。04 SOA服務(wù)組件實(shí)現(xiàn)和部署的具體步驟SOA服務(wù)組件“實(shí)現(xiàn)和部署”的整個過程以面向服務(wù)(SOA)的軟件架構(gòu)為輸入，內(nèi)容上除完成第二章提到的“基礎(chǔ)設(shè)施邏輯”配置工作外，還需將業(yè)務(wù)(功能)邏輯與基礎(chǔ)設(shè)施邏輯集成，最終編譯成可執(zhí)行的服務(wù)組件單元(Service Component)(圖22)。http://www.uml.org.cn/soa/images/202106031223.webp.jpg圖22 服務(wù)組件單元(Service Component)如第一章中對服務(wù)組件的SCA描述，整體服務(wù)組件(Service Component)由服務(wù)單元(Service)提供的“業(yè)務(wù)邏輯”和適配目標(biāo)系統(tǒng)環(huán)境相關(guān)的“基礎(chǔ)設(shè)施邏輯”兩部分組成。在開發(fā)過程中，這兩部分是解耦的，可同時進(jìn)行的，且軟件形態(tài)是靈活的。服務(wù)單元(Service)的邏輯可以是源碼或被封裝為SDK形式，且不關(guān)心具體的編程語言；基礎(chǔ)設(shè)施邏輯 (Interface和Message) 則以C 的形態(tài)編碼，與服務(wù)管理中間件一起確保服務(wù)的動態(tài)響應(yīng)性和服務(wù)自身的可擴(kuò)展性，其軟件形態(tài)同樣可以是源碼或SDK形式提供。在流程上方法論上，”實(shí)現(xiàn)和部署”工作主要分為服務(wù)組件接口設(shè)計，服務(wù)組件集成實(shí)現(xiàn)和安裝部署三個步驟：組件接口設(shè)計階段: 聯(lián)合電子編寫arxml完成對服務(wù)組件SCA中“基礎(chǔ)設(shè)施邏輯”的配置開發(fā)，并經(jīng)由AUTOSAR Adaptive中間件供應(yīng)商提供的代碼框架和生成器(Generator)，最終得到相關(guān)的配置文件(.json)和源代碼(.cc/.cpp)；對“服務(wù)單元邏輯”，聯(lián)合電子可同步基于建模工具進(jìn)行開發(fā)；組件集成實(shí)現(xiàn)階段: 聯(lián)合電子編寫APP框架，完成“服務(wù)單元邏輯”與“基礎(chǔ)設(shè)施邏輯”的軟件集成工作；組件安裝部署階段: 聯(lián)合電子編寫編譯和安裝腳本，完成源碼的編譯鏈接和可執(zhí)行文件(App)的安裝，同時，對APP安裝部署權(quán)限和系統(tǒng)環(huán)境做適配調(diào)整。http://www.uml.org.cn/soa/images/202106031224.png“分析和設(shè)計面向服務(wù)的架構(gòu)”、“實(shí)現(xiàn)和部署面向服務(wù)的軟件”是有效開發(fā)SOA汽車軟件的關(guān)鍵環(huán)節(jié)，“實(shí)現(xiàn)和部署面向服務(wù)軟件”的過程是SOA軟件可以“落地”不可或缺的環(huán)節(jié)第四部：面向服務(wù)架構(gòu)（SOA）的應(yīng)用
原子服務(wù)說到服務(wù)架構(gòu)，關(guān)于原子服務(wù)的話題非?；?，那么，什么是原子服務(wù)？原子服務(wù)有哪些特征？在系統(tǒng)層面如何拆分業(yè)務(wù)服務(wù)并且定義原子服務(wù)？原子服務(wù)對我們的軟件又有什么影響呢？他和服務(wù)的關(guān)系又是什么呢？
我們先從服務(wù)的最小單元——原子服務(wù)講起。原子服務(wù)的定義是：業(yè)務(wù)上最小粒度的一系列操作。原子服務(wù)的特點(diǎn)是松耦合，相對獨(dú)立，且在可預(yù)見的范圍內(nèi)不會對其他原子服務(wù)造成影響。任何一項(xiàng)都劃定了自己的業(yè)務(wù)范圍；他們不用關(guān)心非自己業(yè)務(wù)范圍是如何實(shí)現(xiàn)，對于調(diào)用其他原子服務(wù)，只需要考慮調(diào)用場景及返回結(jié)果如何處理即可。
舉一個例子，先看看下面三句話：
- 現(xiàn)金存款是金融賬戶發(fā)生現(xiàn)金交易的收費(fèi)服務(wù)行為。
- 信用卡還款是金融賬戶發(fā)生的，可能有銀聯(lián)參與的、信用卡的現(xiàn)金交易。
- 現(xiàn)金轉(zhuǎn)賬是金融賬戶與交易對手金融賬戶發(fā)生現(xiàn)金交易的收費(fèi)服務(wù)行為。
這三句話中的，現(xiàn)金存款、信用卡還款和現(xiàn)金轉(zhuǎn)賬就是服務(wù)，現(xiàn)金交易就是原子服務(wù)，而金融賬戶、銀聯(lián)卡和信用卡則是服務(wù)的業(yè)務(wù)參與方，也是大家熟知的服務(wù)消費(fèi)者和提供方。
通過這個例子，大家應(yīng)該對原子服務(wù)已經(jīng)有了一個基本的概念。那么，服務(wù)是由原子服務(wù)構(gòu)成的，SOA是不是只是簡單地由服務(wù)構(gòu)成的呢？
1. SOA 架構(gòu)的特性
答案很顯然，要實(shí)現(xiàn)真正完整的 SOA 架構(gòu)，只靠原子服務(wù)和服務(wù)是不夠的。首先，我們看一下SOA的基礎(chǔ)定義：
SOA基于服務(wù)的架構(gòu)，繼承了來自對象（指的是“面向?qū)ο蟮募軜?gòu)”）和構(gòu)件設(shè)計的各種原則，例如，封裝和自我包含等。那些保證服務(wù)的靈活性、松散耦合和復(fù)用能力的設(shè)計原則，對 SOA 架構(gòu)來說同樣是非常重要的。
關(guān)于服務(wù)的基本特性如下：
標(biāo)準(zhǔn)接口服務(wù)提供方以統(tǒng)一的方式即標(biāo)準(zhǔn)的接口向消費(fèi)者提供服務(wù)信息，比如車載服務(wù)軟件一般會使用SOME/IP協(xié)議作為實(shí)現(xiàn)基礎(chǔ)。自主和模塊化服務(wù)封裝了那些在業(yè)務(wù)上穩(wěn)定、重復(fù)出現(xiàn)的活動和構(gòu)件，實(shí)現(xiàn)服務(wù)的功能實(shí)體是完全獨(dú)立自主的，獨(dú)立進(jìn)行部署、版本控制、自我管理和恢復(fù)。松耦合服務(wù)請求者可見的是服務(wù)的接口，其位置、實(shí)現(xiàn)技術(shù)、當(dāng)前狀態(tài)和私有數(shù)據(jù)等，對服務(wù)消費(fèi)者而言是不可見的。互操作性、兼容和策略聲明為了確保服務(wù)規(guī)約的全面和明確，策略成為一個越來越重要的方面。例如，一個服務(wù)對安全性方面的要求；也可以是與業(yè)務(wù)有關(guān)的語義方面的內(nèi)容，例如，需要滿足的費(fèi)用或者服務(wù)級別方面的要求，這些策略對于服務(wù)在交互時是非常重要的。
而服務(wù)的最小顆粒度則是上文提到的不可拆分的原子服務(wù)。那原子服務(wù)的顆粒度是不是越小越好呢？答案肯定不是的，如何定義合理的原子服務(wù)，如何把握顆粒度的大小，在服務(wù)架構(gòu)設(shè)計中至關(guān)重要。舉個更形象的例子，原子服務(wù)就類似于電路設(shè)計中的電容和電阻，他們有著統(tǒng)一的標(biāo)準(zhǔn)，看似一樣卻又有著不同的封裝，在不同的ECU控制器中組合成不同的應(yīng)用電路，適當(dāng)調(diào)整又能實(shí)現(xiàn)非常多的新的功能。
2.?SOA架構(gòu)的實(shí)現(xiàn)基礎(chǔ)
有了理論基礎(chǔ)，下一步就是看實(shí)現(xiàn)服務(wù)架構(gòu)的必要條件。很多同學(xué)其實(shí)會問，為什么服務(wù)總是和以太網(wǎng)，DDS或SOME/IP綁定的呢？CAN網(wǎng)絡(luò)上是否可以實(shí)現(xiàn)完整的SOA架構(gòu)？
首先，以SOME/IP舉例，因?yàn)镾OME/IP的完整名稱其實(shí)能回答上面的大多數(shù)問題，SOME/IP = Scalable service-Oriented MiddlewarE over IP。即“運(yùn)行于IP之上的可伸縮的面向服務(wù)的中間件”?？梢?，并不是SOA必須和SOME/IP綁定，而是SOME/IP天生就是為了SOA架構(gòu)而生。SOME/IP的精華在于“Middleware中間件”，這是一種獨(dú)立的系統(tǒng)軟件或服務(wù)程序，分布式應(yīng)用軟件可借助Middleware在不同的技術(shù)之間共享資源。分布式應(yīng)用軟件，在這里指的就是“服務(wù)”；不同的技術(shù)之間，在這里指的就是不同的平臺或操作系統(tǒng)，比如Linux系統(tǒng)或AUTOSAR OS OSEK等。而Scalable Middleware，顧名思義，則是“可伸縮中間件”，指的是該中間件能夠適配于不同的平臺及操作系統(tǒng)，其支撐的平臺可大可小。
簡單來說，SOA是軟件架構(gòu)的一種設(shè)計理念；SOME/IP是一種將軟件接口進(jìn)行打包的打包方式，是一種中間件。而汽車行業(yè)通常所指的"以太網(wǎng)"是泛化之后的概念，涵蓋了基于以太網(wǎng)技術(shù)所實(shí)現(xiàn)的各種相關(guān)技術(shù)手段，包括TCP/IP協(xié)議、DoIP協(xié)議、SOME/IP協(xié)議等。當(dāng)然若通過其他非以太網(wǎng)的通信方式來實(shí)現(xiàn)SOA也是可行的，但通常大家不那么用。比如基于CAN總線的架構(gòu)，由于其基礎(chǔ)的架構(gòu)和通信協(xié)議棧里不存在Middleware中間層的概念，所以要實(shí)現(xiàn)SOA的代價是非常巨大的。
3. SOA 應(yīng)用的優(yōu)勢
正如大家所知，早期的車內(nèi)嵌入式軟件沒有統(tǒng)一標(biāo)準(zhǔn)，基礎(chǔ)軟件和應(yīng)用軟件強(qiáng)耦合，不具可移植性；AUTOSAR Classic 的應(yīng)用，對嵌入式基礎(chǔ)軟件的接口進(jìn)行標(biāo)準(zhǔn)化，讓應(yīng)用開發(fā)者基于統(tǒng)一的基礎(chǔ)軟件接口進(jìn)行應(yīng)用開發(fā)。目前采用SOA軟件服務(wù)架構(gòu)的應(yīng)用打通了車內(nèi)的電子電氣架構(gòu)的壁壘，進(jìn)一步對嵌入式應(yīng)用軟件的接口(即服務(wù)接口)進(jìn)行了標(biāo)準(zhǔn)化，讓APP開發(fā)者基于統(tǒng)一基礎(chǔ)服務(wù)接口進(jìn)行應(yīng)用的迭代開發(fā)，隱藏了不同車型配置下應(yīng)用軟件的差異，真正做到了整車級軟件接口的"標(biāo)準(zhǔn)"和"開放"。
- 平臺架構(gòu)升級更便于實(shí)現(xiàn)，通過服務(wù)設(shè)計的方式，能夠有效降低架構(gòu)升級帶來的復(fù)雜度；同時，由于操作系統(tǒng)跨平臺的難度大幅度降低，能夠大幅提升用戶體驗(yàn)，能夠?qū)崿F(xiàn)更為便捷的聯(lián)網(wǎng)功能，實(shí)現(xiàn)不同平臺間的各種APP共享等功能；
- 通過“服務(wù)Hub”區(qū)域控制器的引入，各種新功能能夠靈活地與其他域功能，乃至互聯(lián)網(wǎng)接口集成，而無需各個控制器各自進(jìn)行信號到服務(wù)的轉(zhuǎn)換；
- ?一些相對獨(dú)立的域開發(fā)能夠打破界限，找到新的上限，例如自動駕駛功能不再是電子電氣架構(gòu)“孤島”，通過區(qū)域控制器進(jìn)行服務(wù)互通，可以輕松實(shí)現(xiàn)高清地圖的創(chuàng)建、更新及路線預(yù)測等功能，便于實(shí)現(xiàn)車輛信息的上傳及云端指令的下達(dá)；
4. SOA 的應(yīng)用實(shí)例
正如上文提到的，一旦自動駕駛域不再成為電子電氣孤島，那么他的傳感器、雷達(dá)、攝像頭都能成為整車功能體驗(yàn)提升的利器。同時，由于區(qū)域控制器ZONE具有服務(wù)轉(zhuǎn)換能力，ADAS計算中心也不需要拖著大量的傳感器，雷達(dá)或攝像頭一一連接，只需要簡單從服務(wù)中間層直接發(fā)起調(diào)度請求即可。下面是一個潛在的開發(fā)實(shí)例：
第一階段也就是目前90%的E/E架構(gòu)中所使用的平行式分布，由于ZONE在初期無法實(shí)現(xiàn)LVDS和攝像頭視頻的處理能力，所以暫時不會動AD的“孤島”。但是其他的比如車身等相關(guān)的會通過區(qū)域控制器的服務(wù)轉(zhuǎn)換能力，將信號打包成業(yè)務(wù)服務(wù)。
當(dāng)然，ZONE區(qū)域控制器并不是簡單的hub，在拆分和打包服務(wù)的同時，也會同步進(jìn)行原子服務(wù)的開發(fā)和豐富，后續(xù)隨著整車的FOTA更新，我們的原子服務(wù)越來越完善，同步也會有更多豐富的業(yè)務(wù)服務(wù)在互聯(lián)互通的大環(huán)境下呈現(xiàn)給用戶。
第二階段在這個階段，隨著區(qū)域下一代產(chǎn)品的發(fā)展，會在硬件上具備一些特殊接口的集成能力，例如上圖中原來AD的專屬武器如雷達(dá)或分布式攝像頭等可以直接連接到區(qū)域控制器，這一步看上去僅僅是硬件兼容的一小步，但卻是E/E架構(gòu)升級的一大步。因?yàn)檫@意味著，環(huán)境感知服務(wù)的使用權(quán)被平等地交付到了每個域手中。
如果說過去的車身域是電子域，一旦環(huán)境感知信號的引入，會讓車身域真正地進(jìn)化出“眼睛”，燈光、雨刮、天窗、門鎖、防盜不再是冷冰冰的電子功能，他們會成為整車人工智能的新入口，從電子域進(jìn)化為智能域。一些過去只存在想象中的功能，例如視覺識別天氣自動調(diào)整雨刮、根據(jù)周圍行人和車輛自動調(diào)整燈光方向、單人使用車輛的時候僅解鎖離車主最近的一扇門，這些功能都不再是幻想。
第三階段也是BOSCH體系定義的電子電氣架構(gòu)最終階段，區(qū)域控制器會“返璞歸真”，將所有特殊接口的能力打包成真正統(tǒng)一的虛擬服務(wù)接口，而這其中的關(guān)鍵條件則在于區(qū)域控制器是否具備了完整的原子服務(wù)，例如，一旦區(qū)域能夠提供“視頻解析”的原子服務(wù)，那么我們無需在區(qū)域上接入LVDS信號，直接通過千兆以太網(wǎng)將視頻服務(wù)“原封不動”地傳遞到區(qū)域上，然后在區(qū)域控制器里會有對應(yīng)的“解碼器”，將這些信號解析、解碼、重構(gòu)、并打包成服務(wù)，以極低的延時和極高的保真率提供給不同的處理單元和控制模塊。
而這個階段一旦實(shí)現(xiàn)，接口的標(biāo)準(zhǔn)化和統(tǒng)一化會上升到新的高度，整車電子電氣架構(gòu)的成本也可以大幅度下降，主干網(wǎng)通過以太網(wǎng)傳遞服務(wù)，支路通過CAN/LIN等傳統(tǒng)總線收集原子服務(wù)需要的信號流，所有的系統(tǒng)、軟件、硬件有條不紊地在自己的服務(wù)領(lǐng)域中開發(fā)。未來，一輛既便宜、又智能的“溫馨智能移動起居室”指日可待。
下載文檔
