導讀：隨著集中式電子電氣架構的穩步發展，汽車行業越來越多開始關注基于服務實現的軟件架構（Service Oriented Architecture）。勿容置疑，未來的軟件開發一定會以"服務"為主戰場。如何開發出適用于下一代電子電氣架構的軟件服務，緊跟主流車型和客戶需求的變化，開發出兼具靈活性與競爭力的軟件，是我們時刻關注的話題之一。
一、原子服務
說到服務架構，關于原子服務的話題非常火，那么，什么是原子服務？原子服務有哪些特征？在系統層面如何拆分業務服務并且定義原子服務？原子服務對我們的軟件又有什么影響呢？他和服務的關系又是什么呢？
我們先從服務的最小單元——原子服務講起。原子服務的定義是：業務上最小粒度的一系列操作。原子服務的特點是松耦合，相對獨立，且在可預見的范圍內不會對其他原子服務造成影響。任何一項都劃定了自己的業務范圍；他們不用關心非自己業務范圍是如何實現，對于調用其他原子服務，只需要考慮調用場景及返回結果如何處理即可。
舉一個例子，先看看下面三句話：
現金存款是金融賬戶發生現金交易的收費服務行為。
信用卡還款是金融賬戶發生的，可能有銀聯參與的、信用卡的現金交易。
現金轉賬是金融賬戶與交易對手金融賬戶發生現金交易的收費服務行為。
這三句話中的，現金存款、信用卡還款和現金轉賬就是服務，現金交易就是原子服務，而金融賬戶、銀聯卡和信用卡則是服務的業務參與方，也是大家熟知的服務消費者和提供方。
通過這個例子，大家應該對原子服務已經有了一個基本的概念。那么，服務是由原子服務構成的，SOA是不是只是簡單地由服務構成的呢？
二、SOA架構的特性
答案很顯然，要實現真正完整的 SOA 架構，只靠原子服務和服務是不夠的。首先，我們看一下SOA的基礎定義：
SOA基于服務的架構，繼承了來自對象（指的是“面向對象的架構”）和構件設計的各種原則，例如，封裝和自我包含等。那些保證服務的靈活性、松散耦合和復用能力的設計原則，對 SOA 架構來說同樣是非常重要的。
關于服務的基本特性如下：
標準接口
服務提供方以統一的方式即標準的接口向消費者提供服務信息，比如車載服務軟件一般會使用SOME/IP協議作為實現基礎。
自主和模塊化
服務封裝了那些在業務上穩定、重復出現的活動和構件，實現服務的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢復。
松耦合
服務請求者可見的是服務的接口，其位置、實現技術、當前狀態和私有數據等，對服務消費者而言是不可見的。
互操作性、兼容和策略申明
為了確保服務規約的全面和明確，策略成為一個越來越重要的方面。例如，一個服務對安全性方面的要求；也可以是與業務有關的語義方面的內容，例如，需要滿足的費用或者服務級別方面的要求，這些策略對于服務在交互時是非常重要的。
而服務的最小顆粒度則是上文提到的不可拆分的原子服務。那原子服務的顆粒度是不是越小越好呢？答案肯定不是的，如何定義合理的原子服務，如何把握顆粒度的大小，在服務架構設計中至關重要。舉個更形象的例子，原子服務就類似于電路設計中的電容和電阻，他們有著統一的標準，看似一樣卻又有著不同的封裝，在不同的ECU控制器中組合成不同的應用電路，適當調整又能實現非常多的新的功能。
三、SOA架構的實現基礎
有了理論基礎，下一步就是看實現服務架構的必要條件。很多同學其實會問，為什么服務總是和以太網，DDS或SOME/IP綁定的呢？CAN網絡上是否可以實現完整的SOA架構？
首先，以SOME/IP舉例，因為SOME/IP的完整名稱其實能回答上面的大多數問題，SOME/IP = Scalable service-Oriented MiddlewarE over IP。即“運行于IP之上的可伸縮的面向服務的中間件”。可見，并不是SOA必須和SOME/IP綁定，而是SOME/IP天生就是為了SOA架構而生。SOME/IP的精華在于“Middleware中間件”，這是一種獨立的系統軟件或服務程序，分布式應用軟件可借助Middleware在不同的技術之間共享資源。分布式應用軟件，在這里指的就是“服務”；不同的技術之間，在這里指的就是不同的平臺或操作系統，比如Linux系統或AUTOSAR OS OSEK等。而Scalable Middleware，顧名思義，則是“可伸縮中間件”，指的是該中間件能夠適配于不同的平臺及操作系統，其支撐的平臺可大可小。
簡單來說，SOA是軟件架構的一種設計理念；SOME/IP是一種將軟件接口進行打包的打包方式，是一種中間件。而汽車行業通常所指的"以太網"是泛化之后的概念，涵蓋了基于以太網技術所實現的各種相關技術手段，包括TCP/IP協議、DoIP協議、SOME/IP協議等。當然若通過其他非以太網的通信方式來實現SOA也是可行的，但通常大家不那么用。比如基于CAN總線的架構，由于其基礎的架構和通信協議棧里不存在Middleware中間層的概念，所以要實現SOA的代價是非常巨大的。
四、SOA應用的優勢
正如大家所知，早期的車內嵌入式軟件沒有統一標準，基礎軟件和應用軟件強耦合，不具可移植性；AUTOSAR Classic 的應用，對嵌入式基礎軟件的接口進行標準化，讓應用開發者基于統一的基礎軟件接口進行應用開發。目前采用SOA軟件服務架構的應用打通了車內的電子電氣架構的壁壘，進一步對嵌入式應用軟件的接口(即服務接口)進行了標準化，讓APP開發者基于統一基礎服務接口進行應用的迭代開發，隱藏了不同車型配置下應用軟件的差異，真正做到了整車級軟件接口的"標準"和"開放"。
平臺架構升級更便于實現，通過服務設計的方式，能夠有效降低架構升級帶來的復雜度；同時，由于操作系統跨平臺的難度大幅度降低，能夠大幅提升用戶體驗，能夠實現更為便捷的聯網功能，實現不同平臺間的各種APP共享等功能；
通過“服務Hub”區域控制器的引入，各種新功能能夠靈活地與其他域功能，乃至互聯網接口集成，而無需各個控制器各自進行信號到服務的轉換；
一些相對獨立的域開發能夠打破界限，找到新的上限，例如自動駕駛功能不再是電子電氣架構“孤島”，通過區域控制器進行服務互通，可以輕松實現高清地圖的創建、更新及路線預測等功能，便于實現車輛信息的上傳及云端指令的下達。
五、SOA的應用實例
正如上文提到的，一旦自動駕駛域不再成為電子電氣孤島，那么他的傳感器、雷達、攝像頭都能成為整車功能體驗提升的利器。同時，由于區域控制器ZONE具有服務轉換能力，ADAS計算中心也不需要拖著大量的傳感器，雷達或攝像頭一一連接，只需要簡單從服務中間層直接發起調度請求即可。下面是一個潛在的開發實例：
第一階段
也就是目前90%的E/E架構中所使用的平行式分布，由于ZONE在初期無法實現LVDS和攝像頭視頻的處理能力，所以暫時不會動AD的“孤島”。但是其他的比如車身等相關的會通過區域控制器的服務轉換能力，將信號打包成業務服務。
當然，ZONE區域控制器并不是簡單的hub，在拆分和打包服務的同時，也會同步進行原子服務的開發和豐富，后續隨著整車的FOTA更新，我們的原子服務越來越完善，同步也會有更多豐富的業務服務在互聯互通的大環境下呈現給用戶。
第二階段
在這個階段，隨著區域下一代產品的發展，會在硬件上具備一些特殊接口的集成能力，例如上圖中原來AD的專屬武器如雷達或分布式攝像頭等可以直接連接到區域控制器，這一步看上去僅僅是硬件兼容的一小步，但卻是E/E架構升級的一大步。因為這意味著，環境感知服務的使用權被平等地交付到了每個域手中。
如果說過去的車身域是電子域，一旦環境感知信號的引入，會讓車身域真正地進化出“眼睛”，燈光、雨刮、天窗、門鎖、防盜不再是冷冰冰的電子功能，他們會成為整車人工智能的新入口，從電子域進化為智能域。一些過去只存在想象中的功能，例如視覺識別天氣自動調整雨刮、根據周圍行人和車輛自動調整燈光方向、單人使用車輛的時候僅解鎖離車主最近的一扇門，這些功能都不再是幻想。
第三階段
也是BOSCH體系定義的電子電氣架構最終階段，區域控制器會“返璞歸真”，將所有特殊接口的能力打包成真正統一的虛擬服務接口，而這其中的關鍵條件則在于區域控制器是否具備了完整的原子服務，例如，一旦區域能夠提供“視頻解析”的原子服務，那么我們無需在區域上接入LVDS信號，直接通過千兆以太網將視頻服務“原封不動”地傳遞到區域上，然后在區域控制器里會有對應的“解碼器”，將這些信號解析、解碼、重構、并打包成服務，以極低的延時和極高的保真率提供給不同的處理單元和控制模塊。
而這個階段一旦實現，接口的標準化和統一化會上升到新的高度，整車電子電氣架構的成本也可以大幅度下降，主干網通過以太網傳遞服務，支路通過CAN/LIN等傳統總線收集原子服務需要的信號流，所有的系統、軟件、硬件有條不紊地在自己的服務領域中開發。未來，一輛既便宜、又智能的“溫馨智能移動起居室”指日可待。
來源：聯合電子
