隨著AUTOSAR、SOA、以太網(wǎng)通訊等新技術、新理念的成熟化，面向軟件、硬件、網(wǎng)絡、電氣等多領域的電子電氣系統(tǒng)經(jīng)歷了多代架構方法論的迭代。如何跟隨新技術和新理念的浪潮，構建起新型的汽車電子電氣架構平臺，以實現(xiàn)新老技術的快速更替和融合，優(yōu)化協(xié)同系統(tǒng)架構的搭建將成為主機廠和供應商共同關注的重點。

經(jīng)緯恒潤基于SystemWeaver平臺，按照SOA建模理念為客戶提供了新一代基于SOA的企業(yè)級電子電氣系統(tǒng)協(xié)同設計解決方案，可以有效支持服務和信號的混合架構建模。新型架構下的服務建模分為服務設計、服務系統(tǒng)部署、拓撲設計、服務接口部署、服務實例部署和服務設計檢查和集成六大部分。

01 服務設計

服務Service Interface將在服務設計庫中進行全局維護，系統(tǒng)中的軟件模塊將以引用的方式去調用服務接口。在設計服務接口之前 ，可在統(tǒng)一的數(shù)據(jù)類型庫中進行CppImplementationDatatype的定義和維護，之后將被服務接口引用。

CppImplementationDatatype是適配于C++的Implementation Datatype，常用的有Type Reference、Array、vector、Struct和String類型等。在SystemWeaver中，用戶將可以用便捷的方式進行數(shù)據(jù)類型的定義，其內置的校驗規(guī)則將有效支持數(shù)據(jù)的正確性和完整性。

圖1 數(shù)據(jù)類型維護

此后，將進一步進行服務接口的定義，用戶需要根據(jù)其功能進行詳細的接口設計，明確服務ID、大版本、小版本等基礎信息，并對該服務的使用和內部邏輯進行詳細描述。

服務接口信息主要包括Method、Event和Field三種通訊形式，需要定義其引用的數(shù)據(jù)類型，也就是上一步中定義出的CppImplementationDatatype用來描述其參數(shù)的信息。SystemWeaver將提供良好的用戶界面完成對于服務接口的基本信息填寫和接口定義，同時將支持設計過程中數(shù)據(jù)正確性和完整性的校驗：

• Method、Event和Field的引用數(shù)據(jù)完整性
• 服務信息完整性
• Method參數(shù)的名稱正確性
• Field的類型完整性

圖2 服務接口定義

02 服務系統(tǒng)部署

用戶完成服務接口的定義之后，下一步將描述其在軟件模塊Adaptive Software Component中的交互邏輯，用戶需要設計Software Component軟件模塊之間的服務調動關系，為軟件模塊定義Provided Port或者Consumed Port并進行服務庫的服務引用，以此來表示提供或者消費某個服務。完成設計之后，SystemWeaver將提供各種系統(tǒng)框圖進行查看和導出。

圖3 軟件模塊交互

軟件模塊設計完成之后，還需要進行Executable的生成，并將軟件模塊和Executable進行關聯(lián)；同時需要完成Process Design的定義，并將Executable進行分配。

03 拓撲設計

在ECU層級，除了和傳統(tǒng)架構一樣進行ECU的設計以及軟件模塊的分配之外，還需要對以太網(wǎng)的拓撲進行設計。其主要內容包括：

• ECU對應網(wǎng)絡的設計，包括對其Connector的定義
• VLAN的定義，包括其基本參數(shù)設置和Network Endpoint的定義
• 完成ECU網(wǎng)絡節(jié)點和VLAN 的拓撲結構設計
• Switch的設置和參數(shù)定義
• ECU網(wǎng)絡節(jié)點的controller定義，以及其和connector的關聯(lián)關系構建
• Switch和ECU網(wǎng)絡節(jié)點的Coupling Port關聯(lián)

圖4 拓撲設計

04 服務接口部署

服務接口設計完成了其設計層面上的描述，后續(xù)將進行其在通訊層面上的部署，需要選擇通訊協(xié)議對服務接口完成部署，如 SOME/IP、DDS和IPC等，通常還需要對Eventgroup即訂閱組完成設計。

SystemWeaver將提供服務接口部署界面用于完成接口部署的參數(shù)例如接口ID和端口號的填寫，以及Eventgroup的定義。與此同時，其包含了很多設計準則校驗，將進一步幫助用戶完成低錯誤率的接口部署設計。

圖5 服務接口部署

05 服務實例部署

完成接口部署和通訊設計之后，需要完成服務實例部署，即定義服務實例的通訊方式。首先，需要對提供方和消費方的服務實例完成基本信息設置，如instance ID等。其次，需要對提供方和消費方通訊中提供和消費的訂閱組進行定義，以實現(xiàn)差異化實例的訂閱組信息。最后，需要對通訊的行為進行定義，將定義通訊使用的TCP/UDP 協(xié)議及端口號，和通訊所在VLAN的關聯(lián)。

針對于復雜的服務實例生成，System Weaver將提供自動化部署功能。其中包含了設計中需要遵守的基本準則，根據(jù)Instance ID不能重復、提供方和接收方需要在一個VLAN下等要求進行了自動化部署的設計，幫助用戶快速完成復雜的服務部署工作。

圖6 服務實例部署

06 服務設計檢查和集成

完成服務實例部署之后，服務的整個設計將宣告結束，但服務信息仍需要和下游系統(tǒng)進行集成，所以最后一步是對整個系統(tǒng)的所有信息進行檢查校驗。SystemWeaver針對數(shù)據(jù)類型、服務接口、服務部署、拓撲結構等10個維度進行了200+條校驗，以保證整個系統(tǒng)層面服務設計的合理性和完整性。

數(shù)據(jù)校驗之后，將對數(shù)據(jù)進行導出和下游集成。最常用的文件格式是ARXML格式，此外，服務矩陣表格和IDL格式也都是較為通用的格式。SyetemWeaver可以對多個版本的AUTOSAR標準進行服務文件導出，并支持導出基于單個服務和全系統(tǒng)兩個維度的服務，同時也支持進行定制化服務矩陣和IDL或者JSON格式的文件導出。

如上所述是基于SOA的整個服務流程，但是隨著底層軟件設計成熟度的提升，各個整車廠將對設計流程進行調整和適配，以試用于其自身的架構方法論和工具鏈集成。因此，SystemWeaver也提供了靈活度較高的定制化配置功能，其不僅支持定制化的服務設計方法論，也支持服務設計過程中所有功能的定制化適配。

此外，System Weaver作為平臺類的協(xié)同研發(fā)平臺，其本身優(yōu)異的協(xié)同能力將有效支持包含服務設計在內的整個新型架構的設計，它將支持新技術，例如服務設計、信息安全和軟件架構等；并支持整個V流程“需求—功能—系統(tǒng)—ECU—測試”分層架構設計的融合，實現(xiàn)全系統(tǒng)的數(shù)據(jù)追溯和測試追溯。