AP Autosar
Architecture
overview
AP autosar在SOC 中的位置，起到的作用。下面圖可以看出，AP autosar封裝了作業系統的接口，封裝了功能安全，資訊安全的接口讓應用層軟體可以脫離作業系統進行獨立開發，使用ap autosar定義好的統一接口。完成了應用層和作業系統之間的解耦，提供了統一通訊接口，使得app與app之間實作了解耦。極大的減少了牽一發動全身的影響，增大了各地同步開發的可能性。（圖來自ap 官網）
Execution Management - runtime
execution management 是AP autosar foundation裡的一個功能簇。由上圖可以看出，execution management 是在系統boot之後啟動的然後對程式程序管理.（圖來自ap 官網）
- Execution management 控制如何啟動應用層執行個體程式，程序的建立與配置
- State Management 控制着合适 去start 或者 stop 應用層執行個體程式，比如相應狀态改變請求
- 資源管理，CPU 記憶體占用，時間管理等 接口函數
在建立執行管理時最重要的四個點
- 需要執行的executable是什麼，換句話就是要管控什麼可執行檔案
- UID 和 GID （Linux 系統中，每個使用者的 ID 細分為 2 種，分别是使用者 ID（User ID，簡稱 UID）群組 ID（Group ID，簡稱 GID），這與檔案有擁有者和擁有群組兩種屬性相對應）
- 部署在哪個machine上，上文說到應用層之間互相解耦，也就是說 從上層架構層面 可以将不同的app部署到不同的ECU 上，這裡要定義一下app想部署在哪個machine上。
-
執行狀态，定義這個可執行程式 在 哪個狀态下去執行。比如在machine上定義了startup 和 shutdown兩個狀态，你可以把這個程式放到startup階段。這樣在linux啟動的時候會先去激活execution management，然後執行管理會根據使用者定義的狀态去執行使用者的部署規則。也就是manifest檔案中定義的。這點也是ap autosar 和 cp autosar 很大不同的點，本文隻簡單說一下大概。後面對每個子產品進行詳細說明。
//在狀态在start的時候建立了一個叫alwaysHello_process的程序
ExMConfig::start(ILoaderRegistrar& reg)
{
InstanceIf* alwaysHello_process = reg.getNewInstance();
...;
}
State Management - runtime
State Management通過ara::com提供了一組“Trigger”和“Notifier”字段。SM本質上監聽“觸發器”，并在内部執行特定于實作的狀态機處理，如果有“通知”字段，則提供效果。State Management還通過其他fc提供的标準接口與它們進行互動。使用該機制可以達到以下效果:——FunctionGroups可以要求設定一個專門的狀态——(部分)網絡可以請求deactive /active 這台機器可以要求關機或重新開機,其他自适應(平台)的應用程式可以影響他們的行為——項目可以執行特定操作。（圖來自ap 官網）
其中一些功能是至關重要的。是以，對觸發器字段的通路必須由Integrator通過身份和通路管理适當地保護，以免意外地更改狀态管理的内部狀态(以及由此産生的依賴效果)。
State Management的内部狀态通過其提供的“Notifier”字段傳播到系統。對這些字段的讀通路不那麼重要，是以每個Adaptive (Platform)應用程式都可以注冊到它們的事件，以便在狀态管理的内部狀态發生變化時得到通知。是以，當狀态管理的狀态發生變化時，每個自适應(平台)應用程式都可以(在需要時)執行一個操作。
Log and trace - runtime
log and trace是個比較實用卻又尴尬的子產品。實用在于可以實時記錄，形成log檔案，後期檢視對比。尴尬在于作汽車軟體的都知道，在運作過程中有些東西需要線上标定。目前這個東西時不足以支援線上标定。雖然支援TCP/IP 但是和傳統的汽車軟體工程師的标定手段相比還是極其的不友好。下面列一下log的一些level, 可以和linux 核心列印level同步對比。（圖來自ap 官網）
ap autosar log等級
| Level | Notes |
| ----------- | ------------------------------------------------------------ |
| Fatal | Fatal incorrect behavior; the application is unable to continue |
| Error | Incorrect application behavior and functionality adversely affected. The application results should not be used. |
| Warn | Indicates a failure to achieve fully correct application behavior. The application results are not to be considered trustworth. |
| Information | High-level informational messages aimed at assisting the understanding of program flow |
| Debug | Detailed information intended for the use of programmers/developers |
| Verbose | Highly loquacious; all error messages reported. |
| Off | No messages |
linux 核心 printk 列印等級，數字越低等級越高
#defineKERN_EMERG"<0>"
#defineKERN_ALERT"<1>"
#defineKERN_CRIT"<2>"
#defineKERN_ERR"<3>"
#defineKERN_WARNING"<4>"
#defineKERN_NOTICE"<5>"
#defineKERN_INFO"<6>"
#defineKERN_DEBUG"<7>"
目前log子產品對log檔案的大小沒有特定限制，這是好事但也需要工程師在運用過程中注意記憶體消耗不要太大，需要代碼實作自動清空或者設定大小。
Core
autosar 官方文檔 對C++14 使用過程中進行了一些限制，其中有一條就是針對異常機制。（圖來自ap 官網）
exception handling --> Dunamic exeption specification
function - try - blocks 這兩條都是禁止使用的。為什麼提到這個呢，因為我對CORE 的了解（可能存在偏差）是一種傳回機制。
Core提供了自适應應用程式的AUTOSAR運作時的初始化和反初始化以及程序終止的功能。AUTOSAR為AUTOSAR API選擇了一種無異常的方法，因為它被認為從API傳回錯誤而不是使用異常更有效，并且能夠更好地推理程式的控制流。Result類型支援無異常API，同時維護一種自然的程式設計風格，在這種風格下，API可以以正常方式傳回結果，同時支援錯誤傳回值。這點了解的不是很深，它不是一個庫，也不是一個程序，是一種傳回的狀态。
Operating system interface
一句話總結，運用POSIX 接口。
這裡提一下通訊方式。哪些被限制了，哪些是可以的。（圖來自ap 官網）
兩個AA (adaptative application)之間是不被允許直接進行IPC (internal process communication)的。兩個AA 之間想通訊 需要 經過 ara::com 子產品進行通訊。 AA 隻可以用過POSIX51 的 API 與 基礎軟體Foundation進行通訊。AA如果需要ap 裡面services 可以直接與FC 通過 ara::com 進行通訊。附加一張一次研讨會供應商的圖。
但是這一切隻是規定，或者叫規範。本身是都可以通訊的。。。（手動狗頭）
就比如ap autosar 實作的過程，自身的function clusster 是可以通過IPC, IPC 進行通信的。
這裡讓我想到MISAR 對C 實用過程的要求，盡量不使用#pragma，文檔，comment，都到位的情況下 也是可以的。
規則 3.4（強制）： 所有#pragma 指令的使用應該文檔化并給出良好解釋。