當前，智能駕駛汽車軟件研發過程中，孤島中的應用程序眾多，由于技術平臺和數據模型的差異，這些應用程序之間很難共享信息。在基于企業流程管理BPM （Business Process Management） 的應用程序的情況下，集成技術和單個業務應用程序之間存在緊密耦合。每當業務流程發生變化時，集成技術就會發生變化，從而增加運營成本。這種緊密耦合也使這種方法更難改變。當某個流程在影響所有應用程序的多個應用程序中遭到破壞時，必須修改這些受影響的應用程序和接口才能適應更改的業務流程。這涉及龐大的工作量，并不是我們所期望看到的。

SOA （服務導向架構，Service Oriented Architecture） 作為一種架構范式，展示了技術中立的最佳實踐。其建立在標準之上，可在供應商的廣泛支持下在全球范圍內實現經濟高效的實施。以在企業內部和跨企業創建新業務功能方面重用和重新組合服務，SOA很好的做到了“粗粒度”和“松散耦合”的特點，相較于當前分布式物理架構具有更大的靈活性。SOA 最佳實踐創建包含業務流程的設計 —— 并增強將流程外包和擴展給業務合作伙伴的能力。此外，SOA也可以復用已有的系統和流程，與傳統的基于孤島的應用程序開發更具戰術性的本質形成對比，可以保留和增強現有投資承建的架構、軟件等實現的部分有用性。

01 SOA流程開發在自動駕駛車企中布局

在 SOA 中，由一組與業務相關的 IT 服務組成，其中的資源（即跨越企業內或跨多個企業的多個應用程序）可供價值網絡、企業或業務線的參與者使用，這些服務共同實現了組織的業務流程和目標。

當然，企業在應用 SOA 的解決方案時也會面臨一些比較大的業務挑戰，主要包含如下：

a） 定義和驗證服務、管理重用和分配成本 ；

b） 在企業的軟件開發方法中適應 SOA 方法 ；

c） 設計支持 SOA 的底層基礎設施并選擇支持 SOA 的技術 ；

d） 管理服務集合并將服務編排到業務流程中；

e） 處理任何缺乏 SOA 專業知識和經驗的問題。

對于主機廠未來的研發布局來說，其開發SOA的戰略目標可概括如下：

– 增加內在互操作性

– 增加各子單元之間的關聯性，SOA 支持設計可互操作的服務來交換數據

– 增加業務和技術一致性

– 增加供應商多樣化選擇

– 提高投資回報率

– 提高組織敏捷性

– 減少 IT 系統管理負擔

如下圖所示，表示了四家主流車企的SOA架構開發布局。其中，寶馬和奧迪希望將汽車硬件與軟件分開，兩家領先的汽車制造商正在帶頭開發新的電子架構。

GuardKnox、NXP 和 Green Hills Software 合作開發先進、安全的汽車平臺……實現軟件定義和面向服務的車輛的商業部署。大陸集團的新服務器概念是在高度連接的 ID 電動汽車中轉換為面向服務的電子架構的核心要素。華為認為SDV（軟件定義汽車）的成果對汽車產業的革命起到關鍵作用。

如上也是整個SOA開發的基本重點，這將在我們后續序列文章中進行一一闡述。

02 企業管理開發流程BPM

與SOA軟件架構開發之間的關系

目前在多數主機廠汽車軟件過程開發中，采用開發方法論/工具基本適配于BPM技術，BPM解決了組織如何識別、建模、開發、部署和管理其業務流程，包括涉及 IT 系統和人機交互的流程。這使企業能夠指定漸進性業務流程。當然需要說明的是，沒有服務的 BPM 需要流程層直接訪問底層業務應用程序。這個過程會使用有關當前應用程序、它們提供的 API、它們的內部數據模型以及實現它們的技術中不必要的詳細信息。

SOA可以在沒有 BPM 的情況下存在，而 BPM 在沒有對 SOA 的深刻理解的情況下是無法蓬勃發展的，SOA 和 BPM 的組合比單獨使用更強大。實現 SOA 的主要目的是提供一個松散耦合的集成平臺，允許應用程序實例在不影響核心集成技術的情況下改變和發展。SOA 提供了創建流，確保SOA 與 BPM 松散耦合，自動創建可以跨企業以多種方式重用的服務，以及可以持續改進的多個流程。通過整合可以將 BPM 和 SOA 相關聯，以創造更大的業務敏捷性。因此，SOA 公開了服務，BPM 需要建立相應的流程完成使用服務。SOA 為 BPM 打開了大量服務清單，以便“結合”成一個綜合流。不管這是否是復合的，都可以處理關鍵業務流程。

下圖描繪了 BPM和SOA之間的關系。其中BPM 負責對流程進行建模、模擬和重新設計，SOA基礎架構則協調業務流程并協調服務提供商。

同樣，需要不同應用程序相互通信的流程修改，則不應改變核心集成技術以及應用程序實例。這種流程和服務的獨立性有助于建立業務流程建模和應用程序實現之間的關系。當服務被公開時，用于各種進程，此時服務的更改將不應影響流程。流程更改將根據需要重用各種服務。流程變更將在企業升級中更快地實現，因為 SOA 同時也將流程與應用程序實現解耦，流程和應用程序之間的通信僅通過SOA集成發生。這種 SOA 集成將最大限度地減少了流程建模和應用程序實現之間的差距。

BPM 有助于融合流程服務以構建復合業務流。BPM 功能是使用狀態機構建的，狀態機有助于保持業務流程的完整性并跟蹤調用許多服務的流程。

通過使用 BPM，SOA 被綁定到流程服務以開發復合業務流。BPM 為服務組合增加了額外的運行時能力和修改流以換取更多運行時復雜性的能力。BPM 還可以確保執行長時間運行的流程穩定性，并在出現故障時運行任何必要的補償事務。BPM 通過向 SOA 公開的服務添加靈活、敏捷的運行時層來利用和擴展 SOA 的功能。

BPM 和 SOA 為企業的車端軟件開發提供了完美的組合。BPM 為定義業務流程以及監控和管理這些流程的其他重要功能提供了更高級別的抽象，而SOA服務則為這些過程的能力提供支持。SOA 可以提供用于組合服務以及支持和創建敏捷、靈活的流程開發模式提供幫助。沒有 SOA 的 BPM 可用于構建應用程序，但難以擴展到企業。沒有 BPM 的 SOA 可用于創建可重用且一致的服務，但缺乏將這些服務轉變為敏捷、有競爭力的企業的能力。

SOA 為定義可重用業務功能提供了理想的抽象級別，完全封裝了 BPM 系統中的底層應用程序和技術平臺。SOA 生成封裝業務邏輯和普遍接受的接口的模塊化業務組件。這些模塊可以輕松地執行流程中的步驟。SOA 是 BPM 的重要基礎，支持將流程服務快速組裝和編排成更大的端到端流程。

03 SOA的兩種不同開發模式原理

在汽車領域軟件開發工程實踐中，結合 SOA 汽車軟件分層模型，定義了基于SOA的汽車軟件兩種典型的開發方法，其一是基于“業務驅動型”的開發方法，其二是基于“平臺驅動型”的開發方法，兩種方法適用于不同的應用場景。

1、業務驅動型開發

即整個服務的開發的前提是項目通過各種手段獲取業務用例，從用戶使用案例出發，以服務用戶為設計導向，基于SOA采用正向流程對汽車軟件進行設計。由用例驅動的開發活動，可以建立需求和服務操作之間清晰的追溯關系，為抽象和封裝服務提供充足的語境信息。 整個設計過程主要解決兩個問題：即需要構建服務內容有哪些，每個服務應該實現封裝的邏輯有哪些。

如前所述的企業流程管理BMP中，通常與業務驅動型流程方法論相結合。通過將這些服務編排成復合應用程序并通過標準協議調用它們。業務流程管理和面向服務的架構的結合將使 IT 專業人員和業務用戶受益。沒有業務流程管理基礎設施，面向服務的架構就無法發揮作用。BPM 是面向服務的應用程序開發 （SODA） 的核心元素。它通常用于組裝新的應用程序，因為 SOA 和 BPM 在這種情況下作為天然的合作伙伴攜手合作。每個業務流程都被建模為一組單獨的處理任務，這些任務通常作為企業內的服務來實現。BPM 有助于創建流程模型，流程自動化，以調用服務的形式。

SOA的服務層為業務驅動的流程層提供了理想的平臺，具有以下優化特征：

業務服務線提供映射到業務流程中不同粗粒度的任務；

業務流程不負責了解底層應用程序和技術平臺的任何細節，因為業務服務線的服務協議為訪問服務提供了定義明確的接口信息；

服務層提供的服務注冊和服務設施確保業務流程層可以動態定位和訪問服務；

服務級別數據模型是基于業務領域定義的，獨立于任何特定應用程序使用的數據模型；

服務級安全模型提供單點登錄和基于角色的訪問控制，以確保流程任務被授權使用服務。

構建服務內容實際就是業務過程的分析過程，即由系統設計人員和測試評價人員從用戶角度考慮功能需求和系統實現。實現服務封裝的過程實際是通過服務操作operation實現，該操作在實現過程中相當于軟件函數或方法。整個封裝過程需要通過操作分析實現系統用例的分析細化，得到系統與參與者、系統與外部系統的界限及信息交互，提出對系統的功能需求，并由此作為各個構建服務的操作類型。隨后，通過業務邏輯抽象和封裝，從開發角度實現最優化服務部署，其中需要考慮重用性和自主性的面向服務設計原則。SOA需要設計良好的基礎服務和元服務，當業務用例增加，原有業務用例發生變更時，可以很好的保證重用性，減少軟件變更量，從而實現更快速高效的版本管理。

如下圖所示，表示了一種服務層由與特定業務領域對齊的業務服務線，該服務線可以跨多個業務領域共享可重用的技術服務，同時允許定義和利用服務平臺組成以一種獨立于底層應用程序和技術平臺的組織方式。

最近，越來越多的公司開始專注于使用更具戰略性和實用性得實例化業務驅動型開發的流程工具鏈。例如，微軟在新版本的 Visual Studio 中添加了一些進程管理功能。IBM 以其 WebSphere 品牌提供了一套業務流程工具。Oracle 通過其新的融合中間件平臺專注于流程，SAP 通過與 IDS Sheer 的強大合作伙伴關系重新關注業務流程。

那么我們將如何利用SOA的思想增強業務流程設計呢？

SOA 創建模塊化業務組件，這些組件使用了接口封裝業務邏輯和數據，其創建的模塊用于執行流程中的各個步驟。業務流程中的所有流程步驟可能與 SOA 服務相關，也可能不相關。BPM 可以將 SOA 派生服務、對集成的代理和其他非 SOA 服務的調用相結合。

SOA 是一種用于設計業務流程的工具。可以加入服務以提供復合業務功能或業務流程。可以在以下上下文中重用單個服務或多個業務流程。SOA 幫助業務所有者設計支持業務流程的 IT 系統。這提高了過程變更的適應性，增加了重用性，并提高了過程一致性。SOA 方法會影響 IT 運營的整體效率，特別是在多個流程中以重用公共、共享業務服務的形式對應用程序進行開發。由于大型組織，業務流程、業務規則和策略管理都是不一致的，并且為每個新應用程序和流程重新定義。SOA 就有助于減少創建定義明確和管理的業務服務形式的不一致性，確保這些業務服務在多個系統之間共享，而實現則與底層技術實現無關。

后面系列文章，我們將針對業務驅動型SOA的完整開發流程，以實例分章節進行詳細描述和分析。

2、平臺驅動型開發

針對已經完成平臺化開發的量產項目，其物理邏輯已經完成構建，我們只需要將物理邏輯封裝為SOA中的底層元服務，這些物理邏輯必須是已經成型，并且相對較為成熟的，如制動系統中一些關于基礎制動控制相關的功能控制（ABS、HBA、HDC等），也可以將部分元服務進一步組合為基礎服務。

下面說明下平臺驅動開發的好處。

對于SOA的軟件開發來說，其核心內容是如何將以前的信號級別通信更新為以服務為包的通信模式。其中服務與信號之間的轉換點可以位于從云端到傳感器/執行器級別的某個位置，需要在信號到服務轉換級別之間的做出權衡。如下圖表示了一種典型的平臺驅動型SOA整車開發架構模式。

如上圖所示，如果在當前架構上完全重新開發SOA架構，至底向上會有較多的信號向服務的轉化過程，這可能不是最好的方法。在很多情況下，是不需要重新發明輪子的。因此，在我們實際開發過程根據實際用例逐步添加東西，這樣可以逐漸滿足當前的解決方案，可能是更好的方法。

服務由應用程序組件通過網絡上的通信協議提供。汽車以太網通過開放的標準化車輛接口（例如，GENIVI CVII）實現硬件軟件抽象。對于SOA開發來說，應該是逐漸插入的，即在處理 SOA 實現的遺留組件過程中，具有較高的復雜性。目前為止，仍然沒有關于服務名稱和屬性的標準通用定義。對于討論的接口定義可參考開放標準（例如 AUTOSAR、GENIVI VSS VSC、ENSORIS、SOME/IP）的組合，其在多個方面具有制定統一服務標準的可能性。

運行時環境的時序會影響基于信號的效果鏈的性能。對于SOA的堆棧過程，將信號遷移到服務會增加延遲/抖動。但是，沒有必要遷移整個信號效果鏈。可以在服務級別盡最大努力分離功能，而在信號級別進行硬控制循環。

04 總結

面向服務的架構 （SOA）概念基于開發可重用業務服務和構建應用程序的原則，而不是在孤島中構建單體應用程序。SOA 不是產品，它是關于通過使用一組設計原則、模式和技術的一組與業務對齊的 IT 服務來彌合業務和 IT 之間的差距。

SOA可以沒有BPM而存在，BPM在沒有對SOA的深刻理解的情況下蓬勃發展。SOA 和 BPM 的組合比兩者本身都更強大。服務連接在一起以形成復合業務流程，SOA 最大限度地減少了業務分析和 IT 開發工作之間的差距。由于對應用程序和數據庫的訪問，可以同時考慮和設計業務流程和數據。

審核編輯：郭婷