前言
進來在學習Adaptive AUTOSAR，由於 本人英語水平很一般，所以在閱讀AUTOSAR官方文檔的時候尤爲喫力，而且我發現一個問題，這個官方文檔可能需要經常翻閱的， 但是因爲英語水平有限的緣故，可能每次都得重新使用翻譯工具翻譯一下，顯得有些麻煩， 於是，本人就想着，看一點就翻譯一點，下載再要來翻閱的時候，就可以直接閱讀中文版，方便不少，順便也在博客裏面做一個記錄，一作備忘。
AUTOSAR_TPS_ManifestSpecification的pdf文檔有800多頁，沒法短時間弄完，所以可能也不會按順序記錄。
筆者看的AUTOSAR Adaptive Platform版本是： 19-11
2. Big Picture of Manifest Definition
2.1 Design vs. Deployment
2.1.1 Overview
儘管有這個名稱，這個文檔仍然包含了模型元素的描述，這些元素清楚地綁定到一個設計工作流，並且模型元素與部署方面有很強的關係。
本文檔中討論的模型元素與設計或部署有關，兩組之間沒有重疊。
與部署相關的模型元素將用於上傳到目標平臺的模型中，請參見[TPS_MANI_01000]。這些模型元素主要在本文檔的章節中描述，其中術語“Manifest”是章節標題的一部分。
在沒有更精確的定義的情況下，可以通過與部署無關來標識與設計相關的模型元素。
2.1.2 Relation between Design and Deployment Models
請注意，在許多情況下，與部署相關的元模型部分會在設計領域反映出類似的建模，例如：E2E配置文件參數的定義。
對於設計和部署之間的關係如何影響具體的開發項目，目前還沒有明確定義的屬性，E2E屬性示例在以下場景中可能發生：
- OEM提供AdaptivePlatformServiceInstances的描述，包括E2E屬性的定義。可以肯定的是，模型的後續處理應將E2E屬性視爲已授予，並針對給定屬性開發軟件
- 存在通過ComSpecs定義E2E屬性的軟件。由於各種原因，可能會發生軟件無法更新的情況，因此在E2E屬性定義方面處於“領先”地位。然後，AdaptivePlatformServiceInstances的定義可能必須遵守軟件方面的現有建模。
- 也可能發生現有定義被工程師部分修改的情況，前提是，工程師真正知道那些定義是幹什麼用的。
2.1.3 Structure of the document
本文檔的結構根據設計和部署的映射來劃分，例如，章節：3, 4.1, 5, 12.1 and 6.2 主要講述設計方面的內容，章節：7, 8, 9, 10, 12.2, 13.2 and 13.3 主要是講述部署方面的內容。
2.2 About Manifest
本章將闡明術語“Manifest ”在AUTOSAR自適應平臺中的定義。
[TPS_MANI_01000]{DRAFT} 術語“Manifest ”的定義: Manifest表示AUTOSAR模型描述的一部分，它被創建出來用於支持AUTOSAR自適應平臺產品的配置功能，並上載到AUTOSAR自適應平臺的產品中，可能與包含Manifest應用的可執行代碼的其他工件（如二進制文件）結合使用(RS_-MANI_00015)
必須強調的是，Manifest 的使用確實嚴格限制在AUTOSAR自適應平臺上，並且沒有將該概念移植到AUTOSAR經典平臺的用例。
2.3 Serialization Format
Manifest 定義與其他AUTOSAR模型內容的一個共同點是標準化序列化格式。
[TPS_MANI_01020] {DRAFT } AUTOSAR中Manifest的序列化格式：AUTOSAR中Manifest內容的標準化序列化格式是ARXML。因此，可以根據AUTOSAR XML模式驗證Manifest模型內容。(RS_MANI_00015)
[TPS_MANI_01020]的一個重要結論是：這裏沒有隻允許存在一個”Manifest文件“(即唯一Manifest)的限制。根據AUTOSAR通用結構模板規範[6]中給出的規則，Manifest內容可以分佈在多個物理文件中。
[TPS_MANI_01021]{DRAFT}具體硬件機器上Manifest內容的序列化格式：平臺供應商可以自由選擇用於在計算機上實際上載Manifest的序列化格式，但是，原始ARXML清單的內容和語義需要完全保留(RS_MANI_00015)
可以預料，在許多情況下，Manifest序列化格式的最佳選擇仍然是ARXML，因爲自定義格式顯然必須支持清單元模型的全部複雜性。
請注意，元模型預見到存在從清單相關的元類到設計相關的元類的引用。創建這些引用是爲了清晰起見，但並不強制要求引用的內容實際上需要可解析。
就AUTOSAR建模方法而言，這轉化爲使用原型<<atpUriDef>>裝飾這些引用。更多信息見[6]。
如果引用的元類包含與Manifest級別相關的信息，則此信息將在Manifest級別上覆制（這樣，Manifest級別的模型就不必依賴於設計級別信息的可用性）。
2.4 Scope
如前所述，Manifest的使用僅限於AUTOSAR自適應平臺。但是，這並不意味着在一個以AUTOSAR自適應平臺爲目標的開發項目中生成的所有ARXML都會自動地被視爲Manifest。
事實上，AUTOSAR自適應平臺通常並不專用於車載項目。
一輛典型的汽車很可能還配備了許多在AUTOSAR classic平臺上開發的電子控制單元(ECU)，因此，整個汽車的系統設計必須包括在AUTOSAR classic平臺上構建的電子控制單元(ECU)和在AUTOSAR adaptive平臺上創建的電子控制單元(ECU)。
[TPS_MANI_01019]{DRAFTg}Manifest內容可能適用於AUTOSAR自適應平臺的不同方面：Manifest內容可以應用於模型的不同方面。目前，Manifest內容大致可以分爲三個重點領域：
- 與應用程序相關的Manifest內容描述了應用程序部署的所有方面，包括但不限於應用程序級別上的啓動配置和麪向服務的通信端點的配置。
- 與機器相關的清單內容僅描述了機器的部署，即，機器上沒有運行任何應用程序（包括平臺模塊）。
- 與服務實例相關的清單描述了在傳輸層級別上面向服務的通信如何綁定到應用程序和（在某些情況下）平臺軟件中的端點。
(RS_MANI_00015)
2.5 Manifests described in this Document
原則上，術語Manifest可以定義爲概念上只有一個“Manifest”，並且每個部署方面都將在此上下文中處理。這似乎不合適，因爲很明顯，與Manifest相關的模型元素存在於典型開發項目的完全不同階段中。這方面被認爲是將術語Manifest的定義細分爲三個不同分區的主要動機：
**Execution Manifest **：這種Manifest用於指定在AUTOSAR自適應平臺上運行的應用程序的部署相關信息，執行清單(Execution Manifest)與實際的可執行代碼捆綁在一起，以便支持將可執行代碼集成到計算機上。請在第8節中找到有關此主題的更多信息。
**Service Instance Manifest **：此類Manifest用於指定如何根據底層傳輸協議的要求配置面向服務的通信，服務實例清單(**Service Instance Manifest **)與實現面向服務通信的相應用法的實際可執行代碼捆綁在一起。請在第10節中找到有關此主題的更多信息。
Machine Manifest：這種Manifest應該描述與部署相關的內容，這些內容僅適用於運行AUTOSAR自適應平臺的底層計算機（即沒有在計算機上運行任何應用程序）的配置，機器清單(Machine Manifest)與用於建立AUTOSAR自適應平臺實例的軟件捆綁在一起。請在第7節中找到有關此主題的更多信息。
不同種類清單的定義（和用法）之間的時間劃分導致了這樣的結果：在大多數情況下，不同的物理文件將用於存儲這三種Manifest的內容。但是，與所有類型的ARXML內容一樣，這不是一個綁定規則。