畢業實習總結報告
這既是畢業實習要求的總結報告，也是我對AutoSAR的一點理解，更是個人對未來生活的一點思考。我不希望把這份報告草草水過，而是希望把現在的感受記錄下來，給以後的自己看一看，好記性不如記下來。涉及到工作細節和隱私的部分不在此展示了。
“時間像一頭野驢呀，跑起來就不停。”——前言
自今年三月底拿到實習錄用通知後，當時的我總有一種不真實的感覺，畢竟接下來的數個月將是與學校生活完全不同、又沒有其他同學能夠借鑑的經驗的一種生活。四月還有三門專業必修課在讀，其中還有一門跨級修讀、令人身心俱疲的畢業綜合實踐，自己真的有能力能平衡好學業和實習嗎？從▇▇▇▇校區到虹橋的國家會展中心，自己能堅持每天通勤往返將近兩個半小時嗎？這是我的第一份實習，對自己的能力是否能匹配實習工作也有些擔憂。相比於嵌入式領域這片汪洋大海，我簡歷上的專案不過是幾點浮在表面的浪花。會不會被發現自己很“水”，不能符合專案的需要？現在看來，這些煩惱大多沒有真實存在，適應在▇▇▇▇▇▇▇▇的實習工作比我想象中快很多，每天忙忙碌碌，一轉眼就來到了實習的第六個月。在實習即將結束之際，我透過本篇實習總結報告的形式，記錄自己實習階段感受與思考。
技術升級驅動，市場普及加速。
▇▇▇▇▇▇▇▇（本節主要介紹實習單位與產品領域）
“在標準上合作，在實現上競爭。”——我對AutoSAR的一點理解
什麼是 AutoSAR
AutoSAR（AUTomotive Open Systems ARchitecture）是汽車開放系統架構，它定義了一套支援分散式的、功能驅動的汽車電子軟體開發方法和電子控制單元上的軟體架構標準化方案，以便應用於不同的汽車平臺，提高軟體複用，降低開發成本。這是標準描述，但卻很難理解。如果毫無瞭解地查資料，感覺這又是一套工具、一套架構解決方案、一種作業系統、一種開發方法論、一套標準、一個組織等等。所以，不妨首先來看它的出現是想解決什麼問題。
汽車電子系統的複雜性不斷增長，軟體程式碼量急速上升，開發、測試和維護的成本顯著提高，不同元件和系統之間的相容性和整合問題變得更加複雜。如果存在統一的標準，各家廠商圍繞這個標準開發產品，就能減少大量開發成本。
從汽車的生命週期上講，整車生命週期往往長於ECU的生命週期。在一款成熟的車型上，整車平臺可以沿用相當長的時間，想一下銷量排行榜上的那些熟面孔，例如大眾捷達、桑塔納，日產軒逸等。但單獨的ECU的更新速度快，可能僅僅兩三年就有更好用、更便宜的ECU可供替換，可以根據需要進行升級，且較少影響整車設計。當然，這裡也涉及到一個汽車零部件選型的重要因素，即廠家的供貨穩定性和支援時間。曾經看到過一篇文章，一些公司在產品器件選型時，選擇了部分在價格上有優勢的國產MCU，但在產品SOP後，這款MCU突然停產或不再受支援，這對已SOP的產品打擊很大，可能需要不得不變更設計或者緊急在市場上高價購買存貨。而在這方面，ST等成熟公司會一般更有保障些。
既然講到硬體的更換，就可以擴充到嵌入式系統那五花八門的硬體平臺了。嵌入式不同於普通的PC軟體，它的軟體和硬體耦合性特別高，尤其是在實時性要求高和資源受限的情況下。而不同的硬體平臺就可能導致在硬體更換後，軟體部分要花大量時間移植和修改，這又導致開發成本的增加。汽車電子能不能像純軟體一樣，不關心底層硬體的變化，而實現一套統一的軟體系統？另外，一旦硬體能夠實現自由更換，對零部件的依賴也可以降低許多。從採購方講，“歷史包袱”可以輕鬆許多；從供應方講，能夠允許更多新廠家願意參與競爭，而不是望著巨頭止步不前。
軟體的模組化、可靠性愈發重要。 以CAN通訊為例，CAN通訊本身已經是規定完善的標準，如果各家自己實現，不僅需要投入人力開發，還可能因為自己開發有缺陷，導致可靠性不足。UDS服務等等亦是如此，比起每家廠商都去自己實現，行業更希望像Python的庫一樣，有各種符合所有標準，透過多類測試檢驗後的高可靠的模組，需要時拿來即用，“開袋即食”。把模組配置成所需的樣子，而非是去一遍遍地造輪子。
AutoSAR願景：Cooperate on standards, and compete on implementation.（在標準上合作，在實現上競爭）。就是希望各家廠商把成本投入到產品的應用和功能上，實現所謂的“軟體定義汽車”。
AutoSAR 組織與標準
那麼，這樣一介紹，首先可以引出AutoSAR組織，這個組織由OEM、Tire1、軟體服務商等在這個星球算是相當懂車的一批組織作為成員。這個聯盟負責研發滿足上述需求的AutoSAR架構標準，所有標準都是免費的。
AutoSAR 工具鏈
但是，免費的往往也是很貴的。上面提到，AutoSAR 架構標準是免費的，也就是這個組織只定義了這樣一套標準和方法論，而沒有任何實現的程式碼。這怎麼和之前講的模組化、可靠性不大一樣，不是不造輪子嗎？軟體服務商此時登場了，他們負責投入開發成本，聯合 MCU 等硬體提供商，來實現符合AutoSAR 標準的工具鏈，再賣給 OEM、Tire1 們。當我第一次認識到這點時，我的第一直覺是“不愧是老牌資本主義國家，在這等我呢😠！”
國際上的AutoSAR的御三家是 Vector 、ETAS 、EB，是影響很深的德國公司。一方面，晶片廠商為了讓他們的晶片賣得出去，需要花錢請這類公司適配他們的晶片（對，在和上海知從科技的一次聊天時我才明白，是晶片廠花錢採購），像 Vector 因其市場佔有多，幾乎有所有晶片的適配（每換一套平臺也是要重新購買 License 的）。另一方面，OEM 和 Tire1 等由需要花錢買他們的工具鏈（甚至是按照每個模組談採購），用這套工具鏈基礎上開發。部分OEM已經有了合作多年的廠家，也要求其採購的 Tire1 使用其定製的工具鏈開發。對於需要這套工具鏈的公司來說，更換供應商需要開發人員花時間去適應。對於開發工具鏈的公司來說，怎麼拿到晶片廠的支援和賣得出去也很麻煩。國內這塊，普華、經緯恆潤、東軟這些比較領先，但是沒有接觸過。從使用體驗上講，Vector Davinci 的使用體驗我覺得比ETAS要強很多，一方面，報錯的指向比較清晰，也能夠很快修復；ETAS 就不那麼好用，有時候甚至會報工具內部的一些錯誤（Java），Debug 困難。另外一個對比點是程式碼生成時間，在 Vector 工具裡面生成 BSW+RTE 僅需要 2Min 的活，ETAS 需要數十分鐘才能完成，而能夠加快這個速度的方法是換臺更好的裝置，有點無語。
既然AutoSAR工具這麼貴，那能不能乾脆不用 AutoSAR 架構？前面提到，AutoSAR 只是行業內自行組織編寫的一套標準，而不是強制性的規定。特斯拉就選擇放棄使用 AutoSAR 框架，使用自研的軟硬體架構連線各個元件。使用 AutoSAR 同樣受 ISO-26262 標準等安全標準影響很大。如果廠商有實力有自信能夠把車做安全，透過各種安全認證，用什麼都無所謂。
AutoSAR 架構與開發方法論
終於可以介紹到AutoSAR的詳細架構了，架構又分為CP和AP兩種平臺，這裡主要介紹的是比較熟悉的CP。
CP架構的軟體架構自底向上有三層，分別為BSW、RTE、ASW。每一層只能呼叫下一層的介面，併為其上一層提供介面，保證其獨立性。
基礎軟體層 BSW
基礎軟體層（Basic Software Layer，BSW）可分為四層，即服務層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstraction Layer，MCAL）和複雜驅動（Complex Drivers）
-
服務層（Services Layer）提供系統服務（作業系統）、儲存器服務以及通訊服務三大部分。除了作業系統外，服務層的軟體模組都是與ECU平臺無關的，這些服務提供介面給上層的ASW層和BSW內部其他服務使用。此外，服務層可以由故障診斷事件管理器（Dem）和故障診斷通訊管理器（Dcm）實現診斷服務，分別負責對錯誤事件進行記錄和診斷資訊的傳輸（診斷通訊棧）。
-
ECU抽象層（ECU Abstraction Layer）包括板載裝置抽象（Onboard Devices Abstraction）、儲存器硬體抽象（Memory Hardware Abstraction）、通訊硬體抽象（Communication Hardware Abstraction）和I/O硬體抽象（Input/Output Hardware Abstraction）。該層提供訪問外設的API（無論外設在微控制器的內部還是外部，以及如何與MCU連線）。MCU無關但和整個ECU平臺相關。在模組上，給服務層提供介面，便於服務層操作。
-
微控制器抽象層（Microcontroller Abstraction Layer，MCAL）是實現不同硬體介面統一化的特殊層。MCAL直接操作MCU，提供介面給ECU抽象層。透過MCAL可將硬體封裝起來，避免上層軟體直接對微控制器的暫存器進行操作，我個人認為和HAL庫可能差不多，作為驅動層。
-
複雜驅動層（Complex Drivers, CDD），對複雜感測器和執行器進行操作的模組涉及嚴格的時序問題，難以抽象，沒有被標準化。在我從事的工作範圍內，CDD層的內容不少，一般都是由其他同事負責處理這塊內容，並暴露介面給ASW層，遇到問題除錯起來難度也很大。
執行時環境 RTE
執行時環境（Runtime Environment，RTE）作為ASW層與BSW層互動的橋樑，為軟硬體分離提供了可能。RTE可以實現軟體元件間、基礎軟體間以及軟體元件與基礎軟體之間的通訊。RTE是透過工具配置元件等生成的程式碼。生成RTE後，再由各個元件把自己的實現與RTE生成後的程式碼合併起來。各個元件原則上講不應該出現直接呼叫原始介面或者直接訪問變數的情況，而是透過RTE的方式套個外殼。套這個外殼並不是沒有意義的，一方面提高了系統訪問的安全性，這個外殼包括了其他資訊；另一個方面是透過RTE能實現多種方式的訪問，這個在下面會有提到。
應用軟體層 ASW
應用軟體層（ASW），這層做的就是和業務強相關的部分了。在講軟體元件的時候，主要是要理解軟體元件的內部組成和元件與元件的連線。從這塊的介紹，也會逐步過渡到AutoSAR的開發過程上，那就先從這塊講起。
一個SWC Component內，一定會涉及到資料的處理，所以需要明確所需要使用的資料型別。
應用資料型別（Application Data Type，ADT）是在軟體元件設計階段抽象出來的資料型別，用於表徵實際物理世界的量，是提供給應用層使用的，僅僅是功能定義，並不生成實際程式碼。需要配置Compu Method，也就是資料從內部到物理含義的轉換。Data Constraiint則是約束條件。比如電壓、溫度這類資料型別，就可以定義成一種ADT，ADT是在VFB設計這個層面上使用的。
實現資料型別（Implementation Data Type，IDT）是程式碼級別的資料型別，是對應用資料型別的具體實現；它需要引用基礎資料型別（Base Type），並且還可以配置一些計算方法（Compute Method）與限制條件（Data Constaint）。IDT就比較容易理解，因為他是以基礎資料型別上為基礎的（有點繞口），基礎資料型別就是uint16、sint8這些真正反映在程式碼裡的變數。
在AUTOSAR中，對於ADT沒有強制要求使用，使用者可以直接使用IDT。若使用了ADT，則必須進行資料型別對映（Data Type Mapping），每個ADT進行具體實現。
規定資料型別後，就要考慮資料在元件之間的通訊了。這時候引出Interface，Interface在我的理解是更像一座預製的橋，配置Interface就是相當於規定這座橋上只允許透過什麼型別的車。Interface又分為三大類
- AUTOSAR Interface 多用於Application、Abstraction於Complex Driver上；
- Standardized AUTOSAR Interface 多用於BSW中的Service上；
- Standardized Interface 是AutoSAR定義的BSW中的模組直接互動用的介面。
其中，最常見的又有這幾種Interface: - 傳送者-接收者介面（Sender-Receiver Interface，S/R）。S/R介面是一組資料型別的集合，連線的兩個元件透過類似全域性變數的方式傳遞資料。S/R介面可以1:n（1個模組傳送，多個模組接收）或者n:1（多個模組傳送，1個模組接收）。
- 客戶端-伺服器介面（Client-Server Interface，C/S）。C/S介面是一組函式原型集合，定義了IN(輸入引數)，OUT（輸出引數，傳入的是地址）等函式的引數以及返回值，相當於呼叫其他元件的函式。
- 模式轉換介面（Mode Switch Interface）。和模式管理強相關，這個只接觸過一次。
- 非易失性資料介面（Non-volatile Data Interface）。為了實現非易失性資料資料通訊，用於和非易失性資料元件通訊用的介面，沒用過。
- 引數介面（Parameter Interface）。引數通訊，這個也沒用過。
- 觸發介面（Trigger Interface）。Trigger Interface定義了一組在軟體元件之間通訊的觸發器，使用Trigger Interface進行外部觸發源事件通訊。這個也沒有用過。
Interface在此時也屬於VFB設計的一部分，沒有實體程式碼。
Port是每個SWC元件的埠，也可以說是Interface這座橋的兩端。只有一座橋跨越兩岸的時候才有意義，所以Port和Interface是分不開的。作為一座橋，首先要確定的是通訊方向，也就是Port的三種通訊方向。P-Port代表提供方（Provide)，R-Port代表需求方（Require），PR-Port代表進出均可。然後就對應到每種Interface上，Interface決定了埠的屬性。例如，Sender/Server相當於是P-Ports，Receiver/Client相當於R-Ports。
由於元件之間已經規定了型別一致的Interface和Ports，只要將P/R-Ports連線再生成程式碼，就可以看到實質性的函式，加入使用者程式碼即可。
元件間的部分實現後，下面要介紹的是元件內部的實現。軟體元件的內部行為（Internal Behaviour，IB）下包括：
- 執行實體（Runnable Entity，RE）。執行實體是一段可執行的程式碼，也就是實際需要執行的函式。
- 執行實體的RTE事件（RTE Event）。RE是靜態的，它需要一個能讓其執行起來的條件，這個條件被稱之為Event。每個執行實體都需要有一個Event，能引發這個執行實體的執行。Event又分為以下數類：
- 週期性（Periodic）事件，即Timing Event；
- 資料接收事件（Data-received Event）；
- 客戶端呼叫伺服器事件（Server-call Event）。
- 執行實體與所屬軟體元件的埠訪問（Port Access）。C/S Interface有同步和非同步之分，S/R Interface可能需要配置緩衝區等等，這裡就不再多說。
- 執行實體間變數（Inter Runnable Variable，IRV）。就是RE和RE之間互動的變數，這個也是第一次看到，我理解就是元件內部的一些全域性變數吧，但是這種全域性變數，應該是要透過介面函式提供對外讀寫的方式，不知道AutoSAR裡面是怎麼處理的。
在元件內部定義好和元件與元件之間的關係透過VFB設計描述好的，這個時候不需要考慮跨ECU的互動關係。這些設計都會儲存在對應的Arxml檔案內。Arxml是用來描述配置的一種標記語言。再提取（有的叫萃取，很神奇的翻譯）各個ECU相關描述將SWC對映到各個ECU上，再將子系統獨立出來，之後就可以開發單個ECU的SWC、BSW，將生成的程式碼整合。生成RTE前必須要進行ECU的萃取。萃取後，將每個Event對映到OS上不同型別的Task，即可在OS排程時，執行相應的程式碼操作。生成RTE和檢查編譯透過後，就可以下載程式到MCU上看執行是否正常了，這又是一個極為漫長的故事。上面所述的過程，也是我經歷的一部分AutoSAR開發過程，也是AutoSAR開發方法論的一部分。
整個學習下來，很多內容不是立刻就開悟的。作為實習生，在這塊工作時，剛開始只會接觸很小的一部分操作，這部分操作已經有組內很詳細的文件介紹了操作流程，只需要照例完成就行。但就是這樣一點點接觸不同的各部分的操作，再加上自己查閱資料，才能有恍然大悟的機會。我在第一次感覺有點理解這套開發過程時，當天把各個部分的操作都點進去看過一遍，用從底到頂的方法知道為什麼需要這樣配置後，再順著下來配置了幾次，有種心曠神怡的感覺。當然，這裡介紹的也只是我個人的理解，總會有不足和缺陷的。
“工欲善其事，必先利其器。”——開發環境
開發環境如同廚師的廚房，一個穩定、正常和專案組匹配的開發環境能保證自己在接下來的工作中，不會遇到因為某個設定不一致而導致耽誤工作的情況。我所在的開發小組有比較完善的文件供配置，建議一定要按照文件的步驟配置，如果有不同或者沒有提到的地方，應該是多問而不是想當然。我自己安裝完某個IDE後，就發現沒法除錯專案所使用的晶片，這當然是自己的問題，還得返工重灌（這種重灌又可能引發沒刪乾淨等等新問題，很討厭）。所以，在開發環境全部配置好後也要檢驗測試，確定是否能正常編譯和除錯。
“Code and Documents are all you need.” ——專案程式碼和文件
拿到倉庫許可權後，就可以把程式碼拉到本地仔細瀏覽了。專案程式碼和文件真的是最好的老師。首先就是專案的程式碼結構，各個模組在專案的什麼位置，都可以很清晰地瞭解到。第二個是透過Commit記錄，檢視當前的主分支、開發分支，提交規範等等資訊，確定自己在什麼分支基礎開發，又合入什麼分支。題外話是透過Commit也能看到大家真實的工作時間😄。在我的工作中，每筆程式碼合入都需要Code Review，記得剛開始的提交的Merge Request，因為不符合組內要求的開發規範和細節，待整改的Comment多的嚇人，來來回回跑好多次改。但有效的Code Review確實能學習到很多。有空的時候我也會檢視其他同事的MR，能學習到很多更好的組織程式碼的方法。
“在小小的程式碼裡面挖大大的Bug” ——自測與Debug
自測檢驗兩個方面的問題，第一個是檢查本次合入的功能是否符合預期需求，第二個是檢查這個功能是否對其他原有功能造成影響，其實第二個的意義更大一些，因為耽誤的是更多人的進度。這點我深有體悟，舉個例子，有次程式碼合入在經過自測後一切正常，合入後卻發現在一批新板上會自動復位，導致無法執行。雖然最終發現是時序衝突和硬體變更原因，但是這樣的情況也需要儘快修復。Debug一般有兩個原因，一種是自己正常開發過程中的，另一種是由其他組提出的缺陷等，分配到自己需要檢視原因和解決的。後一種更要緊些，首先就需要確定問題產生的條件，版本、現象、是否可以穩定復現等等都很重要，有穩定復現的一般好解決，不能穩定復現的，則可能需要回退版本、壓力測試等情況一點點對比，這點就很複雜了，很吃經驗，也很頭大。
“溝通的價值，取決於聽者的需要。” ——溝通與協作
在學校的時候，大多是我自己獨立地做專案，合作專案的大部分實施細節也是我完成，很少遇到需要溝通的情況。而在實際的開發工作中，一個需求或者是問題整改往往需要涉及到多個模組、多個部門的協調，這是一個系統工程。開發過程中，可能有的時候寫程式碼並不多，但是協調各個環節很費工夫。我的經驗有兩點：找對人和把話說全很重要，別人可能並不清楚你描述的問題的背景；按照正規的流程去溝通和上升，部門應當是一個整體，需要注意自己傳送的資訊是否應當讓接收者知道。
“別把整個大的變成整坨大的” ——從最小可用出發與不要憋大招
有的時候自己做事有點完美主義，總是在腦海裡面有了一個想做的東西后，就給他填上各種功能。然後興致沖沖地開始寫程式碼，但是寫著寫著就覺得“啊，這麼寫太醜了”，就這樣來回糾結半天，實際想做的核心功能進展卻很少。這樣並不對，因為這不是隻能做一次的藝術品。所以在完成的時候，就是要優先從可用性出發，哪怕它很醜，沒有介面，用的是命令列，程式碼可讀性一塌糊塗，效能也不好，只有完全按照方法用才有正確的輸出，不然連錯誤處理也沒有。但這就已經是很好的起點，在這個起點上，能夠有無限的可能性和最佳化方向。而最佳化是需要投入人力的。
不要憋大招，就是指一定在工作中積極反饋進度，不能埋頭蠻幹，要讓相關人知道你的工作進展和可能的風險，而不是到最後說自己沒有完成，這樣反而會給更多人帶來麻煩。有些工作是可以商量調整的，不合理的需求完全可以提出自己的意見。
“縱觀世界風雲，這邊風景獨好” ——外界環境
進入新的環境，有太多可以熟悉的了。從通勤角度考慮，比如坐地鐵從哪個門下車可以走路最少，公交大概幾點鐘會有一班到站等等，這些都可以把通勤上的不確定減少很多，我喜歡減少生活中的不確定性，但是謀事在人，成事在天，當然很多事情也沒法預見到。到工作地點，交集比較多的同事坐在哪裡，會議室都分佈在哪，各個樓層大概是哪些部門，包括公司的架構都可以一起熟悉起來。HRBP、財務、行政、裝置、OA、公司內部的一些政策和福利等等都是需要了解的內容，雖然一時半會沒有需要，但是比需要用到時，找不到合適的聯絡人要好。
“殘酷的現實已直逼我心理防線了”——個人心態
既然已經決定要直接走向社會了，那麼心態和思維也要儘快轉為“社會”的形態。首先就是對於壓力的處置，很多時候面對版本交付節點，總感覺有無形的壓力，再來一個臨時更改的點需要加班改，更是壓力山大。但既然壓力客觀存在，就要分析和解決。進入職場多年的同事教我們在這個時候，更是要分析事情的根因和優先順序，堅決克服浮在表面這種現象，一件一件總能完成下去，少想多做。再就是身心健康，不能讓不合理的壓力摧毀自己的身體。大學四年，如果說學到什麼，最深刻的就是身體永遠是最前面的1。宇宙很大，生命更大，工作之餘一定要有自己的生活，哪怕是下班後洗個澡。努力工作，快樂生活，保持自信，別害怕尷尬，工作中做個鈍角。
實習的感受是相當複雜的。在剛開始的兩個月裡面，在學校裡面還有課要上，又要兼顧學業，有的時候一邊上課一邊還得回飛書的訊息。等到後面單位搬遷和放暑假後，情況好了很多，感覺好像也不是那麼累了，但這還是吃住都在學校，幾乎沒有生活壓力。等到後面這層保護去掉，生活的挑戰就會露出它本來的面目。
我不知道自己有沒有做好準備，去承受這種壓力，但至少也曾體驗過這半年的酸甜苦辣。第一次實習，就能把自己的工作轉化為一個即將生產▇▇▇▇的產品，不久的將來，我也能指著某款▇▇▇▇說這是我曾經做過的，這種成就感比學校裡面的任何榮譽都要強烈，也是我選擇嵌入式方向的最初動力。我深知自己要學的還有太多太多，離“半瓶水”都還遠著。感謝遇到的各位同事同學對我的幫助，也感謝家人朋友的理解和支援，當然也感謝自己能夠堅持下來。今年高校畢業生超過1200萬人，在上大參加招聘會時又體會到自己和大家的渺小與普通。早點認識清楚現實，走好自己的路，把選擇做正確，這也足夠了，時代往哪發展，下一個風口又在哪，不是這個年紀的我們能夠想明白的。人好比盆中鮮花，生活就是一團亂麻，房子修的再好那是個臨時住所，小盒才是我們所有人永遠的家:)