出品?|?汽車電子與軟件
在AUTOSAR CP平臺中，軟件集群（Software Clusters）方法被設計以充分考慮多個ECU的內部拓補結構，這些結構對軟件系統的整體性能和功能很是重要。這一核心理念在下圖所呈現的概念元模型中得到了直觀且深入的體現。
車輛拓撲中ECU、Machine和軟件集群的層次結構
具體而言，車輛的拓撲結構由多個ECU組成，進一步地，每個ECU可以根據需要配備1到N個控制器，以處理各種復雜的計算和控制任務。
在一個微控制器上，可以托管一個或多個Machine。當微控制器托管多個Machine時（即N大于1時），這些Machine是虛擬化的，它們共享微控制器的硬件資源，以實現更高的資源利用率和靈活性。此外，每個機器都配備了一個完整的Machine，從AUTOSAR的角度來看，這構成了CP平臺架構的一個具體實例，為上層應用提供了穩定而強大的支撐。
#02
通過軟件集群的方法，CP的整體軟件被巧妙地劃分為多個獨立的部分。每個軟件集群都是一個獨立的構建單元，它包含了實現特定功能所需的全部組件和代碼。而集群特定的構建過程則會產生相應的二進制對象，這些對象可以在目標ECU上運行，從而實現預期的功能和性能。
?
AUTOSAR分層軟件體系結構中的軟件集群連接
參考上圖，在集群式軟件系統中，現有的分層架構得到了擴展，這一擴展是通過引入一個新的構建塊——軟件集群連接（Software Cluster Connection）來實現的。軟件集群連接包含以下三個主要的子模塊：
1.二進制清單（Binary Manifest）：此模塊提供了在同一臺Machine上部署的二進制對象之間的連接手段。
2.跨集群通信（Cross Cluster Communication）：該模塊提供了軟件集群之間的虛擬功能總線（VFB）通信功能。不過，服務接口并不包含在此模塊的功能范圍內，因為對BSW模塊的訪問是通過代理模塊來實現的。
3.代理模塊（Proxy Modules）：代理模塊分為高層代理模塊和低層代理模塊。高層代理模塊在應用軟件集群中替代非本地的BSW模塊，并與主機軟件集群中的低層代理模塊進行連接。低層代理模塊則進一步連接到實際的BSW模塊。高層代理模塊暴露的接口與真實BSW相同。
主機軟件集群（Host?Software Cluster）包含了BSW的大部分內容，特別是那些依賴于微控制器的模塊，如操作系統。因此，Machine的動態行為主要由主機軟件集群決定，并負責實現調度。應用軟件集群的實現必須遵循主機軟件集群的調度策略。
在應用軟件集群中，可以集成應用軟件組件以及受到嚴格限制的BSW模塊。如果應用軟件集群中本地沒有可用的基礎軟件模塊，但其接口對于集成軟件來說是必需的，那么這些模塊將由代理模塊進行替代。
一些RTE功能可能會受到限制，因為這些功能的實現可能不具備可擴展性，或者可能對其他軟件集群產生意外的副作用。例如，跨軟件集群的同步客戶端-服務端調用需要實現完全的上下文解耦，這在單個軟件集群范圍內很難準確預見其對整體調度的影響。
盡管存在這些限制，仍然可以通過同步客戶端-服務端調用訪問BSW。對于采用軟件集群的軟件系統而言，實現多核BSW分發概念是確保系統可擴展性和良好性能的關鍵前提。
#03
軟件集群旨在提升AUTOSAR系統設計與實施的靈活性，并通過模塊化手段確保集群內部變更的影響得以局部化。這一特性使得架構變更能夠逐步引入，同時部分實施變更無需重建整個軟件系統。
盡管軟件集群有助于減少變更的頻率，但每個軟件集群，包括主機軟件集群，在必要時仍可重建。部分使用場景可能僅能通過此概念部分解決，甚至完全無法解決，仍需對BSW進行變更，并重建主機軟件集群。
這一概念所具備的功能將簡化對基礎軟件的變更過程，可能導致主機軟件集群的重建頻率有所增加。但與此同時，它也促使基礎軟件的變更從以往罕見且規模較大的情況，轉變為更為頻繁但規模較小的變更。
#04
F：此ECU上的一個分區的定義。一個分區將使用一個Os-Applications。
Software Cluster概念主要面向資源受限嚴重的控制器，其核心在于盡可能減少開銷，實現“按需付費，所得即所付”的原則。這一理念在軟件集群與Ecu-Partitions的關系中得到了充分體現。
Ecu-Partitions為功能分離提供了可能，它們通過OsApplications實現，能夠在一定程度上實現內存訪問和運行時行為的隔離。然而，多個OsApplications的執行也會帶來相對較大的開銷，包括執行任務切換（可能消耗數百個處理器周期）以及額外的管理開銷（如更改執行級別、重新配置MPU等）。隨著Ecu-Partitions數量的增加，這些開銷可能會變得尤為顯著。因此，為了提高資源利用率，可以在多個軟件集群中重用同一個Ecu-Partition。
同時，系統設計者往往希望在一個軟件集群內組合來自不同Ecu-Partitions的功能，以滿足大功能中不同ASIL要求或車載診斷相關的分離需求。例如，一個制動功能集群可能包含來自不同ASIL級別的功能，其中有些功能與安全相關，負責制動操作，而其他功能則與安全無關，如評估行駛平穩性的功能。因此，一個軟件集群可以包含多個Ecu-Partitions，以實現所需的功能組合。
為了滿足這些需求，軟件集群與Ecu-Partitions之間形成了n:m的關系，即一個軟件集群中可以包含多個Ecu-Partitions，同時一個Ecu-Partition也可以在多個軟件集群之間共享。然而，如果Ecu-Partition在軟件集群之間共享，那么在運行時可能無法強制分離其包含的不同軟件集群中的SWC。盡管如此，由于軟件集群在邏輯上和內存地址區域上是分離的，這種做法仍具有一定的可行性。某些違規情況可能不是在ECU的運行時檢測到的，而是通過ECU外部的靜態檢查來發現。
如果資源限制允許，最好不要在軟件集群之間共享Ecu-Partitions，以更好地實現軟件集群的分離。然而，在實踐中，這通常難以避免，因此應盡可能減少這種共享，以降低開銷并提高系統的可維護性和安全性。
#05
通常，微控制器的總內存由多種不同類型的內存組成，如RAM、FLASH程序ROM和FLASH數據ROM等，每種內存都有其特定的用途。此外，即使是同一類型的內存，其不同段在不同用例下也可能表現出不同的性能，例如不同微控制器核心的訪問速度差異。因此，在將整體式的CP軟件架構拆分為可獨立構建的單元時，每個軟件集群的提供者必須明確了解哪種內存可用于什么目的。
由于微控制器通常不支持內存虛擬化，所以在為軟件集群分配內存時，不僅需要就內存量達成一致，還需要就具體的地址范圍進行明確劃分。為此，建議采取以下方法：
機器架構師應將總內存劃分為多個邏輯內存插槽，并為每個插槽指定其可用的目的。這些指示應與內存插槽的物理屬性（如RAM或FLASH）相對應，同時也應與軟件分區（如MPU的空間分離）、功能分組（如校準數據集的內存）和性能目標相匹配。下圖展示了不同內存如何被分配給軟件集群的原則性示例。
?
軟件集群分配內存
接下來，根據每個軟件集群所包含功能的預測內存消耗和所需的內存類型，為每個軟件集群分配不同的內存插槽。這種分配可以直接體現在鏈接定位文件中，并作為AUTOSAR內存映射初始配置的一部分。軟件集群特定的鏈接定位文件確保在構建過程中，軟件集群只分配為其預留的內存。
除了靜態內存使用外，堆棧使用也是需要考慮的重要因素。當主機軟件集群調用應用軟件集群的“代理”操作系統任務時，這些任務可能會進一步調用主機軟件集群中的BSW功能。由于這種復雜的調用關系，堆棧的估算和尺寸確定必須綜合考慮主機軟件集群和各個應用軟件集群的軟件架構。
通過這樣的規劃和分配，可以確保軟件集群在微控制器上高效、穩定地運行，同時充分利用有限的內存資源。
#06
?
示例概覽
該示例包含兩個Software Compositions：
Compo_AHB，包含三個SWC：Anton、Hugo和Bernd。
Compo_Host，包含兩個SWC：Claus和Celine。
這些SWC各自擁有Providing Ports和Requiring Ports，其中一些Ports在頂層視圖中相互連接。
此外，還存在兩個軟件集群：
SwClu_AHB，包含Compo_AHB。
SwClu_Host，包含Compo_Host。
它們基于必要的系統元素分別進行描述。當然，在實際系統中，一個集群通常會包含多個Ports。
在上圖中，這兩個軟件集群具有以下接口：
IF_Celine：端口從SwClu_Host連接到SwClu_AHB。
IF_Bernd：端口從SwClu_AHB連接到SwClu_Host。
IF_Hugo：SwClu_Host上的開放R-Port端口。
IF_Anton：SwClu_AHB上的開放P-Port端口。
圖中也展示了相關的服務依賴關系，通過這些依賴關系，一個配置正確的Host軟件集群及其操作系統可以運行AHB軟件集群。
對于所需的操作系統服務，采用了操作系統代理模式。在此示例中，基本配置包含兩個操作系統任務：OsTask_50ms和OsTask_10ms。每個任務在應用軟件集群中都有兩個入口點供所謂的調度器使用：
OsTask_10ms：
Disp_10ms_Ph1（10ms任務調度器，階段1）
Disp_10ms_Ph2（10ms任務調度器，階段2）
OsTask_50ms：
Disp_50ms_Ph1（50ms任務調度器，階段1）
Disp_50ms_Ph2（50ms任務調度器，階段2）
在AHB軟件集群中，遵循操作系統高代理模式，為操作系統提供了本地實現，包含兩個代理任務：ProxyT_10ms和ProxyT_50ms。軟件組件的定時事件（TimingEvents）與這兩個代理任務相匹配。
圖未顯示的是OsBaseSocket_AHB和BaseConfigCheck_AHB。OsBaseSocket_AHB用于軟件集群AHB本地操作系統代理的初始設置。BaseConfigCheck_AHB用于確保由Host軟件集群實現的配置滿足AHB軟件集群的需求。
有了所有這些設置，該示例的系統設計就完成了。
