AP AUTOSAR核心概念（擰乾毛巾沒有水分）

1.背景

傳統ECU	控制軟體為目標車輛而設計 在車輛使用壽命期間不會發生重大變化
智慧ECU	高度自動駕駛的到來 車輛中高效能CPU的引入 OTA技術的搭載

AUTOSAR經典平臺（CP）標準滿足了深度嵌入式ECU的需求，而智慧ECU的需求無法滿足。因此，AUTOSAR指定了另一個軟體平臺，即AUTOSAR自適應平臺（AP）。AP主要提供高效能的計算和通訊機制，並提供靈活的軟體配置，例如支援OTA技術。

2.技術驅動因素

① 乙太網

車載網路不斷增長的頻寬要求導致引入了乙太網。

與傳統的車載通訊技術（例如CAN）相比，乙太網具有高頻寬並具有交換網路、可以更有效地傳輸長訊息、實現點對點通訊等 。

CP儘管支援乙太網，但主要是針對傳統通訊技術而設計的，並且已經為此進行了優化，因此很難充分利用基於乙太網的通訊功能並從中受益。

 

 

② 處理器

隨著汽車的智慧化程度越來越高，處理器的效能要求也大大提高。原本為單核MCU設計的CP雖然可以支援多核，但它設計起來卻力不從心。

隨著越來越多的處理元件（例如多核處理器）被組合在一個晶片中，這些處理元件之間的通訊變得比傳統的ECU間通訊更快，更高效新型的處理器互連技術（如片上網路NoC）使這成為可能。

更大的處理能力和更快的晶片內通訊速度的這種綜合效果，也促使人們需要一種新的平臺，以適應不斷增長的系統要求。

 

 

3.AP的特點

AP採用了各種傳統上尚未被ECU充分利用的成熟技術

C++

AP中使用C++對應用程式進行程式設計，可以更快地適應新演算法並提高應用程式開發效率。

SOA

AP遵循面向服務的體系結構SOA(service-oriented-architecture)。

SOA基於以下概念：

系統由一組服務組成，其中一個服務可以依次使用另一個服務，應用程式可以根據其需要使用一個或多個服務。

服務可以駐留在應用程式執行的本地ECU上，也可以位於正在執行AP另一個例項的遠端ECU上。

並行處理

由於不同的應用程式使用不同的服務集，因此SOA具有並行處理的特點。

利用現有標準

開發AP規範的重點是，不會僅僅因為現有標準提供了所需的功能就隨意引入了新的介面。

Safety和Security

AP設計的系統通常需要某種級別的安全性，可能是最高階別。

AP結合了架構、功能和程式方法。該體系結構基於SOA的分散式計算，從而使每個元件變得更加獨立且不受意外干擾、有助於實現Safety和Security的專用功能、以及使用C ++編碼來促進安全性。

 

計劃動態

AP支援應用程式的增量部署，這意味著可以動態管理資源和通訊，以減少軟體開發和整合的工作量，從而縮短迭代週期。

計劃的動態示例可能是： 

·僅將動態記憶體分配限制為啟動階段

·除了基於優先順序的計劃外，還需要公平的計劃策略

·將程式固定分配給CPU核心

·僅訪問檔案系統中的現有檔案

·應用程式對AP API使用的限制

·僅執行經過驗證的程式碼

 

敏捷開發

敏捷開發至關重要的一點是，系統的基礎體系結構是可增量伸縮的，並且有可能在部署系統後對其進行更新。AP的體系結構可以實現這一點，能應對快速變化需求的軟體開發。

 

 

 

 

 

 

4.經典、自適應和非

AUTOSAR ECU的整合

 

 

 

 

 

AP不會取代CP平臺或IVI/COTS中的非AUTOSAR平臺。 相反，它將與這些平臺和外部後端系統（如路邊基礎架構）進行互動，以形成一個整合系統。

 

圖1 不同平臺的示例性部署

 

圖2 AP和CP的示例性互動

---

 

---

架構篇

1.邏輯檢視

① ARA

圖1表示的是AP的體系結構。從圖中可以看出以下幾點：

1. 自適應應用程式（AA）在自適應應用程式的AUTOSAR執行時（ARA）之上執行。

2. ARA由功能群集提供的應用程式介面組成，這些群集屬於Adaptive Platform Foundation或Adaptive Platform Services。Adaptive Platform Foundation提供AP的基本功能，而Adaptive Platform Services提供AP的平臺標準服務。

3. 任何AA也可以向其他AA提供服務，在圖中以非平臺服務形式說明。

 

從AA的角度來看，功能叢集的介面（無論是Adaptive Platform Foundation的介面還是Adaptive Platform Services的介面）都無所謂——它們僅提供指定的C ++介面或AP將來可能支援的任何其他語言的介面。

另外，請注意，在ARA介面下，包括在AA上下文中呼叫的ARA庫，可以使用ARA以外的其他介面來實現AP規範，這取決於AP實現的設計。

圖1 AP架構邏輯檢視

 ②語言繫結，C++標準庫和POSIX API

這些API是基於C ++，並且C ++標準庫也作為ARA的一部分提供。

關於OS API，AA只可使用PSE51介面

建議不要將C ++標準庫執行緒介面與本機PSE51執行緒介面混合使用，以避免複雜化。

但是，C ++標準庫沒有涵蓋所有PSE51功能，例如設定執行緒排程策略。在這種情況下，可能需要同時使用兩個介面。

③應用程式啟動和關閉

應用程式的生命週期由執行管理（EM）管理。

應用程式的載入/啟動是通過使用EM的功能進行管理的，並且需要在系統整合時或執行時進行適當的配置才能啟動應用程式。

實際上，從EM的角度來看，所有功能叢集都是應用程式，除了EM本身以外，它們也以相同的方式啟動。圖2應用程式說明了AP內部和AP上不同型別的應用程式。

 

圖2 應用程式型別

EM不會決定應用程式的啟動時間和終止時間。

應用程式的啟動時間和終止時間是狀態管理（SM）控制的，SM是一種特殊的FC，它根據系統的設計命令EM，仲裁不同的狀態，從而控制整個系統的行為。

SM還與其他FC互動以協調整體機器行為。SM應該僅使用標準ARA介面來維護不同AP堆疊實現之間的可移植性。 

④應用程式互動

AA之間沒有直接進行互動的介面，不能通過IPC（程式間通）進行直接互動。

AA之間要想互動需要通過通訊管理（CM）

AA可以直接呼叫POSIX OS的PSE51介面，但是不能呼叫POSIX OS的非PSE51介面

CM還為Machine內和Machine間提供面向服務的通訊

注意：其他ARA介面可能在內部觸發AA之間的互動，但是，這不是顯式的通訊介面，而只是相應ARA介面提供的功能的副產品

⑤非標準介面

AA和功能叢集可以使用任何非標準介面，只要它們不與標準AP功能衝突，並且它們符合專案的安全性要求即可。

除非它們是純的應用程式本地執行時庫，否則應注意使此類使用最少，因為這將影響軟體在其他AP實現上的可移植性。

2.物理檢視

 

在此討論AP的物理體系結構。

注意：本節中的大多數內容僅用於說明目的，並且不構成AP的正式要求規範。

① 作業系統，程式和執行緒

每個AA被實現為一個獨立的程式，具有自己的邏輯記憶體空間和名稱空間。

請注意，單個AA可以包含多個程式，並且可以將其部署到單個AP Instance上或分佈在多個AP  Instance上。

每個程式都由OS從可執行檔案例項化。可以從單個可執行檔案例項化多個程式。同樣，AA可以構成多個可執行檔案。

功能叢集通常也被實現為程式。功能叢集也可以用單個過程或多個（子）過程來實現。自適應平臺服務和非平臺服務也被實現為程式。

所有這些程式可以是單執行緒程式或多執行緒程式。但是，根據程式所屬的邏輯層，它們可以使用的OS API有所不同。如果它們是執行在ARA之上的AA，則它們只能使用PSE51。

如果該程式是功能叢集之一，則可以自由使用任何可用的OS介面。

綜上所述，從作業系統的角度來看，AP和AA只是形成一組程式，每個程式包含一個或多個執行緒——這些程式之間沒有區別。這些程式確實通過IPC或任何其他可用的OS功能相互互動。請注意，AA程式可能不會直接使用IPC，而只能通過ARA進行通訊。

②基於庫或基於服務的功能叢集實施

如圖1 AP體系結構邏輯檢視中所示，功能叢集可以是Adaptive Platform Foundation模組或Adaptive Platform Service。如前所述，這些通常都是程式。為了使它們與AA（也是程式）互動，它們需要使用IPC。有兩種替代設計可以實現此目的。

一種是“基於庫”的設計，其中由功能叢集提供並連結到AA的介面庫直接呼叫IPC。

另一個是“基於服務”的設計，該程式使用通訊管理功能，並且具有連結到AA的Server Proxy庫。Proxy庫呼叫通訊管理介面，該介面在AA程式和伺服器程式之間協調IPC。請注意，AA是僅通過通訊管理直接執行IPC，還是通過Proxy庫與Server 直接IPC混合，由實施定義。 

選擇功能性叢集設計的一般指導原則是，如果僅在AP例項中本地使用它，則基於庫的設計會更合適，因為它更簡單且效率更高。

如果以分散式方式從其他AP例項中使用它，則建議採用基於服務的設計，因為無論客戶端AA和服務的位置如何，通訊管理都將提供透明的通訊。顧名思義，屬於Adaptive Platform Foundation的功能叢集是“基於庫的”，而Adaptive Platform Services是“基於服務的”。 

注意：允許FC的實現以庫的形式實現，即：AA和FC之間的互動將是常規程式呼叫，而不是如前所述基於IPC。

③功能叢集之間的互動

功能叢集之間的一種典型互動模型是使用功能叢集的受保護介面來提供實現功能叢集的特殊功能所需的特權訪問。

從AP18-03開始，引入了功能間群集（IFC）介面的新概念。它描述了FC提供給其他FC的介面。注意，它不是ARA的一部分，也不構成AP實施的正式規範要求。這些介面在相應的FC SWS的附件中進行了描述。

④機器/硬體

AP將執行在其上的硬體視為一臺Machine。其背後的原理是獲得一致的平臺檢視，而不考慮可能使用的任何虛擬化技術。該Machine可能是一臺真正的物理Machine，一臺全虛擬化的Machine，一臺半虛擬化的OS，一個OS級虛擬化的容器或任何其他虛擬化環境。

在硬體上，可以有一個或多個Machine，並且在一臺Machine上僅執行一個AP例項。通常認為，該“硬體”包含一個晶片，可容納一臺或多臺Machine。但是，如果AP允許的話，也有可能多個晶片組成一臺Machine。

 

3.方法論和Manifest

對功能應用程式的分散式，獨立和敏捷開發的支援需要一種標準化的開發方法。

AUTOSAR自適應方法論涉及工作產品的標準化，用於描述諸如服務，應用程式，Machine及其配置之類的工件。以及定義這些工作產品應如何互動以實現針對自適應平臺產品開發所需的各種活動的設計資訊交換的相應任務。

圖3給出瞭如何實施自適應方法的概述草案。

 圖3 AP開發流程

 

4.Manifest

Manifest代表一段AUTOSAR模型描述，該描述是為了支援AUTOSAR AP產品的配置而建立的，並且會上載到AUTOSAR AP產品中，並可能與其他包含Manifest檔案的可執行程式碼的工件（如二進位制檔案）結合使用。

Manifest的使用僅限於AUTOSAR AP。但是，並不是說在針對AUTOSAR AP的開發專案中生成的所有ARXML都會自動被視為清單。

一輛典型的汽車很可能還配備了許多在AUTOSAR CP上開發的ECU，因此，整個汽車的系統設計必須同時涵蓋兩個方面——在AUTOSAR CP上構建的ECU和在AUTOSAR AP上建立的ECU。

在應用程式設計時，有必要將術語Manifest的定義細分為三個不同的分割槽：

應用設計 

這種描述指定了所有與設計相關的方面，這些方面適用於為AUTOSAR AP建立應用程式軟體。不一定需要將其部署到自適應平臺Machine，但是應用程式設計有助於在執行Manifest和服務 Instance Manifest中定義應用程式軟體的部署。

 

執行Manifest 

這種Manifest用於指定在AUTOSAR AP上執行的應用程式的與部署相關的資訊。執行Manifest與實際的可執行程式碼捆綁在一起，以支援將可執行程式碼整合到計算機上。

服務Instance Manifest 此類Manifest用於根據基礎傳輸協議的要求指定如何配置面向服務的通訊。服務Instance Manifes與實際的可執行程式碼捆綁在一起，該可執行程式碼實現了面向服務的通訊的相應用法。

Machine Manifest 這種Manifest應該描述與部署相關的內容，這些內容僅適用於執行AUTOSAR AP的基礎計算機（即，該計算機上沒有執行任何應用程式）的配置。Machine Manifest與用於建立AUTOSAR AP例項的軟體捆綁在一起。 

不同種類的Manifest的定義（和用法）之間的時間劃分得出這樣的結論：在大多數情況下，將使用不同的物理檔案來儲存這三種Manifest的內容。

除了應用程式設計和不同種類的Manifest外，AUTOSAR方法論還支援系統設計，它有可能在一個單一模型中描述將在系統中使用的兩個AUTOSAR平臺的軟體元件。

不同的AUTOSAR平臺的軟體元件可以以面向服務的方式相互通訊。但是也有可能描述訊號到服務的對映，以在面向服務的通訊與基於訊號的通訊之間建立橋樑。

5.應用設計

應用程式設計描述了所有與設計相關的建模，這些建模適用於為AUTOSAR AP建立應用程式軟體。應用程式設計側重於以下方面：

1) 用於對軟體設計和實現的資訊進行分類的資料型別

2) Service Interface是面向服務的通訊的關鍵要素

3) 定義應用程式如何訪問面向服務的通訊

4) Persistency介面是訪問永續性資料和檔案的關鍵要素

5) 定義應用程式如何訪問永續性儲存

6) 定義應用程式如何訪問檔案

7) 定義應用程式如何訪問加密軟體

8) 定義應用程式如何訪問平臺執行狀況管理

9) 定義應用程式如何訪問Time Base

10) 序列化屬性，用於定義如何序列化資料以在網路上傳輸的特徵

11) REST Service Interface是通過REST模式與Web服務進行通訊的關鍵要素

12) Client 和Server 功能的描述

13) 對應用程式進行分組，以簡化軟體的部署。

 

在應用程式設計中定義的工件獨立於應用程式軟體的特定部署，因此可以簡化針對不同部署場景的應用程式實現的重用。

6.執行Manifest

執行Manifest的目的是提供將應用程式實際部署到AUTOSAR AP所需的資訊。

總體思路是保持應用程式軟體程式碼與部署方案儘可能獨立，以增加應用程式軟體可以在不同部署方案中重用的機率。

通過執行Manifest，可以控制應用程式的例項化，因此可以：

1) 在同一臺計算機上多次例項化同一應用程式軟體，或者

2) 將應用程式軟體部署到多臺計算機上，並在每臺計算機上例項化應用程式軟體。

執行Manifest集中於以下方面：

1) 啟動配置，定義應如何啟動應用程式例項。啟動包括啟動選項和訪問角色的定義。每次啟動可能取決於Machine狀態和/或Function Groups狀態。

2) 資源管理，尤其是資源組分配。

 

7.服務Instance Manifest

在網路上實現面向服務的通訊需要特定於所使用的通訊技術（例如SOME / IP）的配置。由於通訊基礎結構在服務的提供者和請求者上的行為相同，因此服務的實現必須在雙方上都相容。

服務Instance Manifest集中於以下方面：

1) Service Interface部署，用於定義如何在特定的通訊技術上表示服務。

2) Service Instance 部署，以為特定的提供和所需的服務例項定義通訊技術所需的憑據。

3) E2E保護的配置

4) Safety保護的配置

5) 日誌和跟蹤的配置

8.Machine Manifest

Machine Manifest允許配置執行在特定硬體（機器）上的實際自適應平臺例項。

Machine Manifest 集中於以下方面：

1) 配置網路連線並定義網路技術的基本憑據（例如，對於乙太網，這涉及設定靜態IP地址或定義DHCP）。

2) Service Discovery技術的配置（例如，對於SOME / IP，這涉及要使用的IP埠和IP多播地址的定義）。

3) 使用的Machine狀態的定義

4) 使用的Function Group的定義

5) 自適應平臺功能叢集實現的配置（例如，作業系統提供具有特定許可權的OS使用者列表）。

6) 加密平臺模組的配置

7) 平臺健康管理的配置

8) 時間同步的配置

9) 可用硬體資源的文件（例如，可用的RAM數量；可用的處理器核數量）

 

---

作業系統

1.概述

作業系統（OS）負責Adaptive Platform上所有應用程式的執行時排程，資源管理（包括策略記憶體和時間限制）以及程式間通訊。

執行管理負責平臺的初始化，作業系統與執行管理協同工作，執行應用程式的啟動和關閉。 

Adaptive Platform沒有為高效能處理器指定新的作業系統。而是定義了作業系統介面（OSI），供自適應應用程式使用。 

OSI規範包含作為ARA（自適應應用程式的標準應用程式介面）一部分的應用程式介面。OS本身可能會提供執行管理啟動應用程式所需的其他介面，例如建立程式。但是，提供此類功能的介面尤其不能作為ARA的一部分使用，並且應定義為與平臺實現有關。 

OSI提供C和C ++介面。對於C程式，應用程式的主要原始碼業務邏輯包括POSIX標準中定義的C函式呼叫，即IEEE1003.13 [1]中定義的PSE51。在編譯期間，編譯器會確定平臺作業系統中的哪個C庫提供了這些C函式，並且應在執行時連結應用程式可執行檔案。對於C ++程式，應用程式軟體元件的原始碼包括在C ++標準及其標準C ++庫中定義的函式呼叫。

 

 

2.POSIX

市場上有幾種作業系統，例如 提供POSIX相容介面的Linux。但是，與平臺Service和Foundation相比，應用程式對作業系統使用會更受限制。 

一般的假設是，Application-Level型別的應用程式應使用PSE51作為OS介面，而Platform-Level型別的應用程式則可以使用完整的POSIX。

如果Application-Level型別的應用程式需要更多功能，這些功能將取自POSIX標準，並且在可能的情況下不會重新指定。 

Adaptive Platform Foundation和Adaptive Platform Services功能的實現可以使用其他POSIX呼叫。特定呼叫的使用將對實施者開放，並且不會標準化。

 

 

3.排程

作業系統提供了多執行緒和多程式支援。標準排程策略是SCHED_FIFO和SCHED_RR，它們由POSIX標準定義。

允許使用其他排程策略（例如SCHED_DEADLINE或任何其他特定於作業系統的策略），但要注意的是，這可能無法在不同的AP產品上實現移植。

 

4.記憶體管理

支援多程式的原因之一是要實現不同功能叢集和AA之間的“無干擾”。

OS的多程式支援迫使每個程式位於一個獨立的地址空間中，並與其他程式分開並加以保護。同一可執行檔案的兩個Instance在不同的地址空間中執行，因此它們可以在啟動時共享相同的入口點地址和程式碼以及資料值，但是，資料將位於記憶體中的不同物理頁中。

 

5.裝置管理

裝置管理將在POSIX PSE51介面下提供。有關詳細資訊，請參閱POSIX規範。

 

執行管理

1.概覽

執行管理負責系統執行管理的所有方面，包括平臺初始化和應用程式的啟動/關閉。

執行管理與作業系統結合使用，以執行應用程式的執行時排程。

2.系統啟動

啟動計算機後，將首先初始化作業系統，然後啟動執行管理作為作業系統的初始過程之一。然後，執行管理將啟動Adaptive Platform Foundation的其他功能叢集和Application-Level型別的應用程式。

Adaptive Platform Foundation啟動並執行後，執行管理將繼續啟動Adaptive Applications。Platform-Level型別的應用程式和Application-Level型別的應用程式的啟動順序由執行管理根據Machine Manifest和執行Manifest資訊確定。 

圖1 AP啟動順序

執行管理（可選）支援經過身份驗證的啟動，其中從信任“錨”開始，在保持信任鏈的同時啟動Adaptive Platform。在經過身份驗證的啟動過程中，Execution Management會驗證應用程式的真實性和完整性，如果檢測到違規，將阻止其執行。

通過這些機制，可以建立可信平臺。

3.執行管理責任

執行管理負責Adaptive Platform執行管理和應用程式執行管理的所有方面，包括：

①平臺生命週期管理

執行管理是Adaptive Platform啟動階段的一部分，它負責對Adaptive Platform和已部署的應用程式進行初始化。

② 應用程式生命週期管理

執行管理負責部署的應用程式的有序啟動和關閉。執行管理根據Machine Manifest和執行Manifest中的資訊確定已部署應用程式的集合，並根據宣告的應用程式依賴性匯出啟動/關閉的順序。根據Machine狀態和Function Group狀態，已部署的應用程式會在Adaptive Platform啟動或更高版本期間啟動，但是，由於許多應用程式將為其他應用程式提供服務，因此，預計不會所有的Application立即開始活動工作。 

執行管理不負責應用程式的執行時排程，因為這是作業系統的事。

但是，執行管理負責OS的初始化/配置，以使其能夠根據執行管理從Machine Manifest和Execution Manifest中提取的資訊執行必要的執行時排程。

4.確定性執行

確定性執行提供了一種機制，使得使用給定輸入資料集進行的計算始終在限定時間內產生一致的輸出。執行管理區分時間和資料確定性。前者指出輸出總是在截止日期之前產生的，而後者則指從相同的輸入資料集和內部狀態產生相同的輸出。

執行管理提供的支援集中於資料確定性，因為它假定時間確定性已通過提供足夠的資源來處理。對於資料確定性，執行管理提供了DeterministicClient API，以支援對內部流程的控制，確定性工作人員池，啟用時間戳和隨機數。對於軟體鎖步，DeterministicClient與可選的軟體鎖步框架進行互動，以確保冗餘執行的流程具有相同的行為。DeterministicClient與Communication Management進行互動，以使資料處理與週期啟用同步。 

圖2 Deterministic Client說明了DeterministicClient支援的API及其與應用程式的互動

5.資源限制

自適應平臺允許在同一臺機器上執行多個自適應應用程式，因此確保不受干擾是系統屬性。因此，行為不當的自適應應用程式應受到影響其他應用程式的能力的限制，例如，應避免某個應用程式消耗比指定時間更多的CPU時間，因為這可能對其他應用程式的正常執行產生潛在影響。

執行管理通過配置一個或多個分配了應用程式程式的ResourceGroup來支援不受干擾。然後，可以為每個ResourceGroup分配CPU時間或記憶體限制，以限制應用程式的可用資源。

6.應用程式恢復

執行管理負責流程啟動/停止的狀態相關管理，因此它必須具有啟動和停止流程的特殊許可權。平臺執行狀況管理會監視程式，並可以觸發恢復操作，以防任何程式的行為不在指定引數之內。整合商根據平臺執行狀況管理的軟體體系結構要求定義恢復操作，並在執行清單中進行配置。

7.受信任的平臺

為了保證系統的正確功能，確保平臺上執行的程式碼具有合法來源至關重要。保留此屬性使整合商可以構建受信任的平臺。

實施受信任平臺的系統的關鍵屬性是信任“錨”（也稱為信任根）。信任“錨”通常被實現為儲存在安全環境中的公鑰。在不可修改的永久記憶體或HSM中。

系統設計者負責確保至少系統以信任“錨”開始，並保持信任直到啟動執行管理。根據系統設計者選擇的建立信任鏈的機制，可能已在系統啟動時檢查了整個系統的完整性和真實性。但是，如果系統設計者僅確保已經檢查過已執行的軟體的完整性和真實性，則執行管理在接管系統控制權時將接管繼續信任鏈的責任。在這種情況下，系統整合商負責確保正確配置了執行管理。

從信任“錨”向作業系統和自適應平臺傳遞信任的一個示例（即建立信任鏈）可能看起來像這樣：信任“錨”-根據定義是一個真實的實體-在啟動載入程式之前對載入程式進行身份驗證。在引導過程的每個後續步驟中，應首先對要啟動的可執行檔案進行身份驗證。真實性檢查應由已經過身份驗證的實體完成，例如，真實性檢查可以通過以下方式完成：例如，由先前啟動的可執行檔案或某些外部實體（例如HSM）決定。

作業系統可靠啟動後，它將啟動執行管理作為其第一個過程。在啟動執行管理之前，作業系統應確保執行管理的真實性已由已經過身份驗證且因此可信賴的實體進行了驗證。

注意：如果未通過Trust Anchor本身的功能（根據定義是真實的）檢查身份驗證，則在應用該軟體之前必須對用於驗證可執行檔案真實性的軟體進行身份驗證。例如，如果將使用Crypto API來驗證可執行檔案的身份驗證，則在使用Crypto API本身之前，必須先由某些受信任實體對Crypto API進行身份驗證。

執行管理現在負責啟動自適應應用程式，然後再啟動它們。但是，存在不止一種可能性來驗證可執行程式碼的完整性和真實性。在SWS_ExecutionManagement中，提供了完成此任務的可能機制的列表。