引言：從本章節開始我們聚焦到具體的ECU測試上來（以車載TBOX為例），因為相比車輛其他電子零部件，車機系統和Tbox涉及的功能模塊和上層應用多一點。當然我們在文檔中可能不僅僅只描述Tbox相關的內容。
01
Tbox簡介
Tbox(Telematics Box)是汽車座艙系統中的一個ECU，物理外觀上是一個方正的盒子，通常會有線束接口、HSD接口、通訊和導航天線接口等。軟件上Tbox一般會基于Linux操作系統如Ubuntu、CentOS等，配合上層軟件進行深度定制。而車機系統目前一般選擇Android進行深度定制。
Tbox的作用是作為車輛的網絡出口，將獨立的車輛網絡環境跟互聯網進行連接，促進了現在車聯網的形成。綜合起來看，Tbox是帶通訊功能的盒子，內含SIM卡，一般是物聯網SIM卡，與這個盒子配套硬件還有GPS天線，4G天線等。
當前已經有主機廠和大的零部件供應商在研究一體式的車機系統，將傳統的車機和Tbox合二為一，從而取消獨立的Tbox物理設備。
02
Tbox的通訊
Tbox通常掛載在診斷Can上，且診斷CAN一般只有Tbox一個電子控制零部件。
Tbox通常內部有MCU和MPU兩個控制單元，相互之間的通訊一般基于UART協議。
Tbox的外部系統通訊一般有以下幾個部分：
（1）基于4G或5G通訊模組的上網通訊以及衛星導航定位，這部分都是集成移動通信供應商標準模組，主機廠或Tbox零部件供應商自定義程度較低。
（2）Tbox與主機廠TSP（運營商服務平臺）云端平臺間通訊，通常使用主機廠自定義的通訊協議。
（3）新能源車基于國標GB/T 32960規范要求的直連和轉發通訊。
（4）Tbox跟車內其他零部件間的CAN或車載以太網通訊。
（5）Tbox跟車機娛樂系統間的HSD（高速數據）連接，基于IP網絡socket通訊。
（6）Tbox跟其他設備間的專用通訊，需要看項目具體設計，如跟SRS（安全氣囊）硬線連接通訊等。
03
Tbox的功能劃分
從上個章節我們可以看出Tbox本身有多個跟其他系統的交互模塊，這些模塊基本都會對應不同的上層應用，此外還有Tbox維持本身正常工作的功能設計模塊等等，總體情況下Tbox可以有以下大體劃分：UDS診斷功能、電源管理功能、注冊激活功能、車況上報功能、報警上報功能、安防報警功能、大數據上報、遠程控制、娛樂主機功能、Bcall功能、電子圍欄、藍牙功能、無線通信功能、導航定位功能、新能源國標上報、泊車測試、FOTA功能等等。
對于這么多功能模塊的測試設計，我們可以依據的文檔還是比較多的，直接關注和應用的文檔大體上有：TBox產品功能技術規范（不同主機廠的命名可能不一樣）、Tbox項目的診斷規范、Tbox與TSP后臺通訊技術規范、Tbox功能信號表（不同主機廠的命名可能不一樣）、Tbox與娛樂主機USB通訊技術規范、整車FOTA功能技術規范、自動泊車功能技術規范等等。
主機廠各個技術規范的編制過程關系大體如下圖所示：
04
Tbox測試
汽車零部件包括Tbox在內，從設計研發到整車商用發售這個過程中，大體會經歷以下幾個測試階段：零部件單元測試、子系統集成測試、整車系統測試、功能專項測試，其中功能專項測試一般與前面的常規測試并行，基于子系統的成熟度，最早在集成測試階段開始，最晚在整車系統測試階段開始執行。
4.1 零部件單元測試
Tbox的單元測試一般從A樣正式交付后開始進行，到釋放C樣給OTS造車開閥結束，主要對設備的基本功能進行模塊測試。單元測試階段各個零部件均處于研發階段，子系統零部件之間的接口和功能測試受到條件限制，測試重點通常著眼于對零部件自身功能實現的保證。
在單元測試階段Tbox功能和接口測試會占用單元測試的很大部分時間，特別是電源管理和網絡診斷兩部分。直接關系產線電檢測試的成功與否，影響EP造車和OTS造車質檢反饋。
單元測試階段通常是在測試臺架上進行，單元測試階段Tbox的測試內容大體有：
· 白盒測試 在研發質量體系對代碼的編碼規范有約束要求的情形下，通常在從項目開始就要進行代碼的靜態規則檢測，在項目功能安全設計作等級要求時，通常還會對代碼進行結構覆蓋度測試，即動態代碼測試。常用的工具通常有：Helix QAC、SmartRocket TestGrid、LDRA TestBed等。
· 功能測試 在本階段發布的版本質量要求上，零部件所有重要功能都必須實現，允許存在故障，但不能是致命級別導致設備無法使用的故障。Tbox在單元測試階段的功能測試通常可以和接口測試一起執行，這樣可以有效減少重復的測試工作，像是診斷、車況和報價信號等的正確性測試之類。對于功能比較獨立的測試類似注冊激活、電源管理、通訊模塊AT測試之類在測試過程中都存著循環迭代的過程，建議在做測試計劃時通過功能測試+回歸測試的方式提高效率，在所有故障和功能在回歸測試中都驗證良好的情況下，再執行全功能覆蓋遍歷的功能測試。
· 接口測試 零部件的模塊間接口和零部件對外的設備接口測試在單元測試階段完成，通常這個接口測試比較簡單，Tbox在進行內外部接口測試時通常會通過tester模擬發送各種信號，測試人員驗證Tbox收到各種信號的反饋是否正確，這里的接口指的是本文前面提到的所有通訊接口。
4.2 子系統集成測試
Tbox的子系統集成測試一般從OTS造車交付開始進行，到釋放版本給PPV造車開閥結束。此階段零部件硬件開發基本凍結，集成測試階段的目標是確保子系統中各零部件工作正常，各功能在所有零部件間的實現可靠、正常。盡可能發現和解決問題，為PPV（G4）開閥造車做好充分準備。
在子系統集成測試階段已有實車可以提供測試，相對于子系統的用車需求部門數，實車數量是較少的，所以這個階段子系統硬件在環的臺架測試工作量通常還是大于實車工作量的，一般情況下都是硬件臺架驗證完成確認問題修復后，才會到實車進行大規模驗證。
這個階段的零部件測試已經不再聚焦零部件內部了，而是把重點放在子系統內部的各個零部件間接口和功能的驗證，所以在子系統內其他配合零部件狀態良好的情況下，功能專項測試就此開始，如遠程控車、自動泊車、整車FOTA、新能源車的國標考試內部驗證等等。
在集成測試的過程中，無論是專項測試，還是實車或臺架測試，所依據的技術基礎都是子系統內不同零部件間的各個通訊協議，實際項目中特別需要注意的是Tbox和其他零部件在細分上不是一個研發項目組控制，這種情況在不同零部件間普遍存在，就會容易導致一個問題，零部件之間的通訊協議是不停迭代的，而零部件的軟件研發版本也是基于協議在迭代，這樣就會出現不同零部件釋放的用于子系統集成測試的軟件版本，依據的通訊協議版本不一致。所以子系統集成測試，或者專項功能測試時版本的基線特別要注意，這也是我要強調的在實際項目中Tbox聯調時遇到的項目管理問題要比產品本身的技術問題多，因為整車系統中所有零部件的上網功能都是通過Tbox來完成的，對接的配合件比較多。
相對于實車環境的復雜和存在的大量干擾因素，臺架測試環境相對比較干凈，Tbox的臺架測試拓撲圖如下：
4.3 整車系統測試
Tbox的整車系統測試一般從PPV造車交付開始進行，到出版本給PP造車開閥結束。正常情況下在這個階段Tbox以及其他零部件狀態都比較好（項目管理把控弱，質量失控的除外），所有零部件的重大問題都已完成修復，在此階段的工作就是通過大量的實車測試，發現異常場景下的問題，以及一些功能優化調整。
需要特別注意的是在這個階段最好做到所有已知問題修復清零，一些主機廠質量管理和考核體系中，PP閥點后車輛路試組發現的問題會歸屬于工程問題，不再是簡單研發故障，對于考核績效會有影響（質量績效管理不是這樣的當我沒說）。
整車系統測試的重點在于大量的實車測試，對于Tbox來說重點在于實車特殊測試場景的設計，如隧道、高架、山地、地下、高樓間等等，注意導航信號的準確性，2G、3G、4G、5G不同網絡間的信號切換等等。
需要特別注意的是在這個階段最好做到所有已知問題修復清零，一些主機廠質量管理和考核體系中，PP閥點后車輛路試組發現的問題會歸屬于工程問題，不再是簡單研發故障，對于考核績效會有影響（質量績效管理不是這樣的當我沒說）。
整車系統測試的重點在于大量的實車測試，對于Tbox來說重點在于實車特殊測試場景的設計，如隧道、高架、山地、地下、高樓間等等，注意導航信號的準確性，2G、3G、4G、5G不同網絡間的信號切換等等。
05
總結
對于Tbox的測試我們從整體上按照常規做法在各階段完成對應的測試工作，就可以保證產品在各階段的應有質量。
目前整車新功能新技術的發展很快，新能源車很多概念炒作的比較火熱，但是實際在量產車型上，各主機廠的設計一般相對沒有采取激進的方式，新的零部件和功能的設計都是建立在可靠性的基礎之上。Tbox也同樣如此，對于主機廠而言，Tbox的技術已經相當成熟，新車型的Tbox一般都是進行項目的適配性開發，我們測試所要關注的重點通常都在項目子系統其他功能配合零部件的聯調進度上，Tbox本身測試設計和執行難度不大，所以測試工作不能僅僅關注測試本身，測試項目管理相關的事情同樣非常重要。
揭秘理想的整車電子電氣架構
國內主機整車EEA架構匯總
如何一步一步成為一個技術領域專家
談談Bootloader自更新
談談對兩家AUTOSAR工具看法
奧迪首款800V車型技術總覽
汽車軟件需求是如何變成用戶功能？
電子電氣架構設計需要考慮哪些方面？
汽車E/E架構的網絡安全分析
電子電氣架構設計需要考慮哪些方面？
分享不易，懇請點個【??】和【在看】
