當前，智慧駕駛汽車軟體研發過程中，孤島中的應用程式眾多，由於技術平臺和資料模型的差異，這些應用程式之間很難共享資訊。在基於企業流程管理BPM （Business Process Management） 的應用程式的情況下，整合技術和單個業務應用程式之間存在緊密耦合。每當業務流程發生變化時，整合技術就會發生變化，從而增加運營成本。這種緊密耦合也使這種方法更難改變。當某個流程在影響所有應用程式的多個應用程式中遭到破壞時，必須修改這些受影響的應用程式和接口才能適應更改的業務流程。這涉及龐大的工作量，並不是我們所期望看到的。
SOA （服務導向架構，Service Oriented Architecture） 作為一種架構正規化，展示了技術中立的最佳實踐。其建立在標準之上，可在供應商的廣泛支援下在全球範圍內實現經濟高效的實施。以在企業內部和跨企業建立新業務功能方面重用和重新組合服務，SOA很好的做到了“粗粒度”和“鬆散耦合”的特點，相較於當前分散式物理架構具有更大的靈活性。SOA 最佳實踐建立包含業務流程的設計 —— 並增強將流程外包和擴充套件給業務合作伙伴的能力。此外，SOA也可以複用已有的系統和流程，與傳統的基於孤島的應用程式開發更具戰術性的本質形成對比，可以保留和增強現有投資承建的架構、軟體等實現的部分有用性。
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開發的基本重點，這將在我們後續序列文章中進行一一闡述。
企業管理開發流程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 的重要基礎，支援將流程服務快速組裝和編排成更大的端到端流程。
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的堆疊過程，將訊號遷移到服務會增加延遲/抖動。但是，沒有必要遷移整個訊號效果鏈。可以在服務級別盡最大努力分離功能，而在訊號級別進行硬控制迴圈。
總結
面向服務的架構 （SOA） 概念基於開發可重用業務服務和構建應用程式的原則，而不是在孤島中構建單體應用程式。SOA 不是產品，它是關於透過使用一組設計原則、模式和技術的一組與業務對齊的 IT 服務來彌合業務和 IT 之間的差距。
SOA可以沒有BPM而存在，BPM在沒有對SOA的深刻理解的情況下蓬勃發展。SOA 和 BPM 的組合比兩者本身都更強大。服務連線在一起以形成複合業務流程，SOA 最大限度地減少了業務分析和 IT 開發工作之間的差距。由於對應用程式和資料庫的訪問，可以同時考慮和設計業務流程和資料。