1. 介紹（Introduction）
在介紹如何修改AUTOSAR軟件之前，對所有各種元素進行概念性介紹至關重要。 在繼續使用Arctic教程之前，了解AUTOSAR軟件包含的許多實體（entities）是一個很好的開始。 因此，強烈建議在閱讀其它Arctic教程之前閱讀下面的內容。 為了介紹各種AUTOSAR實體，使用了名為InteriorLightCAN的項目。 InteriorLightCAN是一個AUTOSAR項目，旨在模擬汽車內部燈光的行為。 該項目本身可以在Arctic Core中找到，名稱為InteriorLightCAN（和InteriorLightCAN-artext）。
2. 概覽（Overview）
下圖描繪了InteriorLightCAN的應用層。 請仔細查看圖片，以下示例基於此。 在接下來的部分中，InteriorLightCAN的集群將被細分並詳細描述。
3. 用戶符號（User Symbols）
上圖描繪了軟件組件（SWC）通過端口（通過接口進行通信 - 稍后將詳細介紹）。 常用的端口有四種：
- Sender Port
- Receiver Port
- Server Port
- Client Port
發件人端口只能連接到接收器端口（創建委派連接器時除外 - 稍后會詳細介紹），並且服務器端口只能連接到客戶端端口。 無論是在發件人和接收器端口之間，還是在服務器和客戶端端口之間建立連接，連接的端口都必須通過同一接口進行通信。 接口依次實現各種數據類型，例如boolean，uint32等。遵循前面的邏輯，配置為發送布爾值的發送方端口不能連接到配置為接收uint32值的接收端口。
在上圖中，深灰色容器顯示了SWC，其端口，內部行為，Runnables及其實現的實例。 再次，稍后會有更多內容。
SWC可以看作是應該如何設計某個東西的藍圖，而實際的實例化對象則稱為原型。 在InteriorLightCAN系統中，原型用深灰色矩形表示，其名稱（下圖中的SWC原型名稱）在右下角用斜體鍵入。 SWC和原型之間的區別允許同一SWC的多個原型。 一個例子是SWC DoorSensor。 SWC DoorSensor實例化兩次，一個是leftDoorSensor，另一個是rightDoorSensor; 可能會有比本例中給出的兩個更多的實例。
4. 服務組件（Service Component）
表示原型的紅色框稱為服務組件。服務組件是從BSW編輯器生成的SWC，用於配置基本軟件（BSW）。使用服務組件，以便可以從應用層連接駐留在BSW中的服務模塊。因此，SWC EcuM，BswM和IoHwAb（如上圖所示）都是基於BSW配置生成的。目前，請將服務組件視為一種聯系各種BSW服務模塊的方法。例如，應用層中的SWC可以調用EcuM服務組件（與BSW中相應的服務模塊通信）來控制ECU的模式。類似地，BswM服務組件允許應用層訪問要發送的各種PDU組（一組消息）。此示例中的最后一個服務組件是IoHwAb，它負責處理一個名為DIO的模塊，負責數字輸入/輸出。如果沒有服務組件，我們無法在此示例中實現任何功能。 （IoHwAb SWC實際上不是一個服務組件，而是一個名為Ecu Abstraction的東西 - 這兩個具有非常相似的功能，所以現在我們將其視為服務組件。）
5. 內部照明燈（Interior Light）
Root CompositionLightCANCAN右側的深灰色容器表示手動創建的SWC（即不是由BSW編輯器生成的）。 這些SWC構成了本例中執行的大部分邏輯。 如果您查看頁面頂部的概述圖，您可以看到下面的圖片不包括ModeManager，EcuM和BswM。 這三個SWC僅負責啟動ECU，並不是本示例的重點。 下面的所有深灰色SWC原型每隔100毫秒由OS調用，並具有各種端口以相互通信。 每個SWC都有非常明確的責任，下面將詳細介紹。
6. 門傳感器（DoorSensor）
DoorSensor SWC有兩個端口，如下所示。一個客戶端端口（名稱：DoorSwitchSignal）用於觸發對IoHwAb的服務器端口的函數調用（名稱：Digital_FrontDoorLeft和Digital_FrontDoorRight）。在我們的示例中，對這些服務器端口的調用會觸發輸入DIO的讀取。由於IoHwAb，DIO和端口模塊的BSW配置，在整個堆棧中調用兩個DIO（稍后將對此進行更詳細的描述）。為了能夠在IoHwAb中觸發服務器端口，DoorSensor必須首先具有Runnable。在這種情況下，Runnable會定期觸發（具有所謂的timingEvent觸發器）。這允許在稍后配置RTE時將Runnable連接到RTE編輯器中的OsTask。
此外，DoorSensor Runnable必須有一個所謂的serverCallPoint，它通過客戶端端口的接口觸發一個功能。在這種情況下，我們必須定義我們的serverCallPoint來調用DoorSensor的客戶端端口DoorSwitchSignal，以及在DoorSwitchSignal實現的ClientServerInterface DigitalServiceRead中定義的函數Read。配置這樣的serverCallPoint將導致RTE生成可以從我們的DoorSensor Runnable的c代碼實現（其中寫入實際邏輯）調用的函數。 DoorSensor還有一個Sender Port DoorStatus。為了使RTE生成發送數據的函數，DoorSensor Runnable必須具有所謂的dataWriteAccess。作為serverCallPoint，dataWriteAccess需要一個它應該通過的端口（在這種情況下是DoorStatus端口）和一個與DoorStatus通信的接口上的參數（在這種情況下是參數狀態）。此端口只是將信息傳遞給InteriorLightManager，無論其DIO是打開還是關閉。 InteriorLightManager依次處理是否應該打開InteriorLight的所有邏輯。 DoorSensor SWC的唯一責任是讀取其DIO並將此信息傳遞給InteriorLightManager以進行進一步處理。
7. 燈執行器（LightActuator）
LightActuator SWC與DoorSensor SWC具有相似的職責，但不是通過其客戶端端口讀取（如DoorSensor所做的那樣），LightActuator負責為每個LightActuator實例寫入一個LED。 除了客戶端端口的不同之外，LightActuator還有一個接收器端口（而不是作為DoorSensor的發送器端口），用於接收來自InteriorLightManager的信息，以確定LightActuator是應該打開還是關閉其連接的LED。 擁有Receiver Port需要Runnable具有dataReadAccess（類似於上面的DoorSensors dataWriteAccess）。 LightActuator的兩個實例分別負責一個LED。 作為DoorSensor，LightActuator有一個timingEvent，因此它的唯一Runnable可以由OsTask定期觸發。 目前，關於LightActuator還有很多話要說。
8. 內部燈管理者（InteriorLightManager）
InteriorLightManager SWC負責處理InteriorLightCAN示例的邏輯。它讀取DoorStatus（通過InteriorLightManager連接到的兩個DoorSensor SWC），並將InteriorLightStatus（連接到它的兩個LightActuator）通信，從而打開或關閉LED。對於兩個Sender Ports RightLightStatus和LeftLightStatus中的每一個，必須定義dataWriteAccess。同樣，兩個Receiver Ports必須都有一個相應的dataReadAccess。
左邊是兩個端口 - 一個發送器端口和一個接收器端口 - 尚未詳細描述。這些端口並不是唯一的。它們與任何其他端口一樣是發送器端口和接收器端口。然而，這兩個端口的目的是通過CAN與模擬ECU進行通信，模擬ECU負責接收（通過CAN）狀態，無論是否打開行李箱，以及發送狀態是否有任何門或艙門是否打開。如果這三個中的任何一個被發出信號打開，則InteriorLightManager將向LightActuators和模擬后ECU發出信號，指示燈應該打開。然后由每個執行器打開燈。在LightActuator的情況下，通過打開各自的LED來轉動燈。在主干的情況下，如果通過CAN接收到0x01（通過InteriorLightManager的端口RearLightStatus），則打開燈。
9. 外部端口（External Ports）
正如上一節中簡要討論的那樣，InteriorLightManager有一個發送器端口和一個連接到根組合的外部端口的接收器端口。 這些外部端口又可以連接到BSW中的Com模塊，因此可以通過CAN（或您喜歡的任何總線）進行通信 - 這完全取決於您的BSW配置; InteriorLightCAN應用層不知道消息將使用哪個總線 發送過來）。 根組合將在本章的最后部分詳細描述。 目前，重要的是要知道我們有兩個端口 - 一個發送器端口和一個接收器端口 - 可以與Com模塊通信，因此可以與例如CAN總線通信。 標題為“CAN BUS”的灰色矩形模擬后部ECU。
10. 啟動集群（Startup Cluster）
在根組合的左上角，找到了SWC EcuM，BswM和ModeManager。如前所述，EcuM和BswM是服務組件，並通過其BSW配置控制ECU。在我們的示例中，BSW配置已設置，以便EcuM為任何外部SWC（在我們的示例中為ModeManager）提供讀取其（以及ECU的）currentMode的可能性。 EcuM的currentMode是跟蹤ECU所處模式的參數。例如，EcuM可以處於RUN，STARTUP，SHUTDOWN等狀態，具體取決於它的配置方式。在我們的例子中，ModeManager Runnable應該由一個所謂的modeSwitchEvent觸發。更具體地說，當modeSwitchEvent退出STARTUP時（因此，當ECU啟動時）。發生這種情況時，我們要求ECU應通過Client Port RunControl進入RUN狀態。 ModeManager負責的最后一件事是告訴BswM它應該請求COMM_FULL_COMMUNICATION。 BswM收到此消息並相應地觸發某些操作。在此示例中，BswM配置為執行打開兩個PduGroup（ComIPduGroupRx和ComIPduGroupTx）的操作。 Com中的所有Pdus都屬於這些組中的任何一個。所以我們所說的基本上就是：盡可能讓我們在BSW堆棧中發送Pdus。沒有這個調用，就無法與后面的（rear）ECU通信。
11. 根組成（Root Composition）
為簡化起見，將Root Composition視為所有SWC原型（不是SWC！）的容器，這些原型與根組合的外部端口之間的連接。 從下圖中可以看出，有三個服務組件原型，以及在ARText中定義的六個原型，總共九個原型。 第一步是實例化所有這九個原型。 然后，必須定義外部端口。 最后，必須進行所有內部連接。 在內部連接端口時，發送器端口連接到接收器端口（相反的情況不可用），服務器端口連接到客戶端端口（這里也不可能相反）。
12. 連接器（Connectors）
外部發件人端口連接到InteriorLightManager中的發件人端口，外部接收器端口連接到InteriorLightManager中的接收器端口。這與上述SWC之間的連接指令相矛盾。但是，內部和外部連接之間存在差異。在同一組合中的兩個SWC之間創建內部連接時，會創建一個所謂的Assembly Connector。對於裝配連接器（Assembly Connector），上述規則適用：發件人端口必須連接到接收器端口，服務器端口必須連接到客戶端端口。但是，在創建外部連接時（我們將InteriorLightManager連接到根組合的外部端口時就是這種情況），會創建所謂的委派連接器（Delegation Connectors）。顧名思義，委托連接器負責委托某些東西 - 它可以是函數調用（服務器端口到服務器端口，或客戶端端口到客戶端端口），也可以是數據（發送端口到發送端口，或者接收端口到接收端口）。在我們的示例中，InteriorLightManager的發件人端口RearLightStatus通過委派連接器連接到根組合的發件人端口LightStatus。因此，InteriorLightManager中的發件人端口將其數據委托給根組合的外部端口。同樣，Root Composition的Receiver Port DoorStatus負責將此數據委托給InteriorLightManager的Receiver Port RearDoorStatus。通過這種方式，在CAN總線上進行通信的所有其他ECU都不知道（並且不關心）根組合內部發生的事情，但只知道（並關心）它可以將DoorStatus發送到我們的應用程序，它可以收回LightStatus。
