1. AUTOSAR方法
AUTOSAR在系統開發的某些步驟需要通用的技術方法。這一方法就叫“AUTOSAR方法”。“AUTOSAR方法”既不是完整的過程描述也不是商業模型，這個方法中並沒有定義“角色”和“責任”之類的東西，而且也不規定要執行那些活動。AUTOSAR方法僅僅是一個“工作產品流”（work-product flow），定義“工作產品流”中活動的相互依賴性。
AUTOSAR方法並不定義整體的時間線，也並不定義迭代怎樣和何時執行。例如在系統設計中，同樣的行為（即系統配置行為）會在不同的精確度上重複執行。第一個“粗糙”配置和最後一個“精確”配置依賴於實際配置甚至是ECU的實現。
AUTOSAR方法概述
上圖給出了運用AUTOSAR方法描述ECU從設計到構建、集成的過程。
1. 首先要定義System Configuration Input，選擇軟、硬件組件，標識系統總體限制，這是系統設計或者體系的任務。AUTOSAR傾向於通過信息交換格式（軟件組件、ECU資源、系統限制）和模板來減少這些初始系統設計決定的正式描述。所以定義System Configuration Input就意味著填寫和編輯適當的模板。是從頭填寫模板還是重用模板（可能也需要一些改動）取決於用例。基本上AUTOSAR方法允許對模板的高度重用。
2. 活動Configure System主要是將軟件組件映射到關於資源和計時要求的ECU上。
3. Configure System的輸出是System Configuration Description。這一描述包括所有系統信息（如總線映射、拓撲等）和關於軟件組件定位到哪個ECU的映射。
4. 活動Extract ECU-Specific Information從System Configuration Description中提取特定ECU所需的信息。
5. 然後輸出到ECU Extract of System Configuration。
6. 活動Configure ECU為實現添加了所有必需的信息，如任務調度、必需的BSW（基礎軟件）模塊、BSW的配置、任務中可運行實體的賦值等。
7. 活動Configure ECU的結果將輸出給ECU Configuration Description，它負責收集所有關於特定ECU的局部信息。通過這些信息可以構建該特定ECU的可執行軟件。
8. 在最後一步中，活動Generate Executable根據從ECU Configuration Description中得到的信息生成可執行軟件。這一步通常涉及生成代碼（如為RTE和BSW生成代碼）、編譯代碼（編譯生長的代碼或編譯軟件組件的源代碼）、將所有編譯後的代碼連接成為可執行軟件。
9. 得到可執行ECU軟件。
在這些簡短介紹的AUTOSAR方法過程中，同時還需要將軟件組件集成為整個的系統，比如生成組件API，實現組件功能等。雖然這些沒有在上圖中表現出來，不過軟件組件的實現或多或少與ECU的配置無關。
2. AUTOSAR模型
2.1. 起源
AUTOSAR允許通過對嵌入式控制器和對應軟件執行單元組成的分佈式系統的各個方面進行精確的和正式的描述，以建立一個非常靈活卻又穩定而可靠的軟件工程生命週期。
這個描述的覆蓋範圍從高層的軟件組件的接口要求，到底層的特定總線消息的字節限制。由AUTOSAR中的不同工作包決定需要從各種描述中獲得的信息。而這些描述就是AUTOSAR模型。
AUTOSAR模型屬於UML2.0的一個子集，是UML2.0元模型的簡化。因為UML2中高度模塊化的結構和對類、屬性、關聯重定義的過度使用，有時很難在用一兩副圖展現某個特定方面的同時又保持清晰的可讀性。所以，這裡簡化了UML2.0元模型，只包含部分元素。
2.2. 術語
2.3. 元模型體系
完整的AUTOSAR模板元模型體系共有五層：
M0層：AUTOSAR對象
這是對AUTOSAR系統的實現：真實的ECU執行包含雨刷控制軟件的軟件映像。
M1層：AUTOSAR模型
這一元層的模型是由AUTOSAR終端用戶（汽車工程師）構建的。由他們定義名為“雨刷”的軟件組件和一系列連接其它軟件組件的接口等等。在這一層AUTOSAR系統被細分成可重用的組件和特定實例。
M2層：AUTOSAR元模型
這一層定義之後將被AUTOSAR終端用戶使用的“詞彙表”，比如，這層定義了在AUTOSAR中有名為“軟件組件”的實體和另一個名為“端口”的實體。這些實體之間的聯繫和語義都屬於整個模型的一部分。
M3：AUTOSAR模板的UML profile
M2層的模板是由M3層定義的元模型構建的。正如之前討論過的，這是UML加上一個特定的UML profile，以更好的支持模板建模工作。嚴格意義上M2層上的模板仍然是UML的實例，但同時也採用了模板profile。
M4：元對象設施（meta object facility）
為了概念上的完整性，OMG將MOF放在最後一層元層上。因為MOF被定義為是反射式的，所以不再需要進一步的元層。
3. AUTOSAR工具
“AUTOSAR創作工具”是指所有支持解釋、修改、創建用於描述系統的AUTOSAR XML描述（AUTOSAR模型的XML表示）的工具。這些模型由以下模板產生：
1. 軟件組件模板，
2. ECU資源模板，
3. AUTOSAR系統模板。
AUTOSAR創作工具包含幾個重要的方面，如下圖所示。
AUTOSAR創作工具
A 創作工具的特徵定義
“創作工具的特徵定義”建議逐步實現AUTOSAR整體概念中關於交換描述的部分，即軟件組件模板、ECU資源模板、系統模板。在第一次實現的基礎上，定義AUTOSAR模板子集的AUTOSAR創作工具。
B 創作工具的協同工作
“創作工具的協同工作”著重於那些在不同工具間交換AUTOSAR模型時可能會出現的問題。本文檔首先描述一些數據交換的基本概念，然後簡單勾勒出解決這些問題的策略。
C 行為模型的交互
“行為模型的交互”列出了AUTOSAR中行為模型的用例。並標識出與行為模型有關的部分AUTOSAR元模型。
D 圖形符號
“圖形符號”為AUTOSAR創作工具定義了AUTOSAR圖形符號。例如，文檔為圖形建模CompositionTypes提供了詳盡的圖式。這些圖形符號應作為實現AUTOSAR創作工具的指南。
4. 一致性測試
AUTOSAR一致性測試的目的是為了驗證產品是否符合AUTOSAR規範。這些產品需要在互操作性、重用/移植性、可擴展性上證明符合AUTOSAR標準。
因為AUTOSAR是一個開放標準，所以所有最終規範都是標準的一部分。
本文檔關注為證明特定產品符合AUTOSAR標準所必需的幾條相關路徑。測試過程的複雜度應儘可能的低，但具體應根據供應商和客戶之間的關係來確定最合適的測試方案。
一致性測試中的角色有：
（1） AUTOSAR（維護標準，監控AUTOSAR規範的使用），
（2） Conformance Test Agency（分為第一方CTA和第三方CTA，主要任務是提供測試包，執行測試，提供支持和證明服務），
（3） Product Supplier（開發和測試產品）。
AUTOSAR一致性測試路徑
