其背景是：在實際的商業化產品中，CAN驅動層也包含一些複雜的策略，如各種異常的處理，以及性能優化模塊，模塊本身還會有可配置性和可移植性的要求，畢竟CAN驅動也是軟體平臺的一部分。
在傳統的OSEK/VDX架構下，CAN驅動以上還有交互層、傳輸層、診斷一些層、網絡管理、標定、信號/報文/協議網關等上層基礎軟體模塊，幾乎每一個都有相應的國標標準來對應，是一個相當專業且門檻不低的行業子領域。
除了知名汽車零配件公司自己招募一些團隊做CAN開發以外，一般採用委託第三方公司。
其目的是：降低研發成本，省去大批工程師高額的開發周期和管理費用，目前國際知名的第三方供應商有Vector、EB、Mentor Graphics，國內有速銳得。
對於車載ECU來說，一級零部件供應商研發可以分為系統、硬體、電子、軟體、機械結構等，CAN總線涉及最多是溝通的工作，主要是CAN總線的邏輯、信號需求、通信矩陣釋放、樣件提交、測試結果反饋等等。通信矩陣不能釋放的開發項目，看是否通過速銳得適配完成數據的採集與交互。
其中原因是：國內汽車電子行業，對CAN總線相關協議有深刻理解和開發經驗的工程師數量不斷，相對於項目整體的開發規模，只佔很小一部分。數百萬的汽車電子軟體工程師，用過CAN總線的十之六七，但知道CAN相關各個模塊設計的，恐怕也是萬裡挑一。簡單的、複雜的、主從的、多主的各式各樣，優缺點、選擇依據、調研和分析、實驗與現場實踐及洞悉，都是考驗CAN技術開發的多種條件。
其需求是：DBC數據的創建，是基於各ECU系統的機能需求，如果ABS系統有個輪速信息要發給ECU，是以什麼樣的周期、什麼樣的精度，那麼我們就需要把把需求轉化成總線報文。網絡拓撲設計，基於整車線束分布，對總線節點之間的距離、節點數、總線負載等有限制，整車CAN通訊策略，對整車總線節點上都有統一的策略。網絡管理設計，處於有的節點在IGOFF後，有通信需求，為降低功耗，又制定了不同的網絡管理策略，還有將UDS協議（14229）轉為J1939或者ISO15765等等需求。
其工具是：
硬體：帶有CAN模塊晶片的開發板，CAN BOX、CAN H 與 CAN L之間的120歐姆接口，零散線束、USB、螺絲刀、裝飾面板拆卸工具等等
軟體：CAN OE 或者周立功、豪氣霸主可用vehicle spy。
其方法是：以周立功為例，這個大家用的多。
打開CANTEST通用測試軟體，選擇USBCAN-2E-U接口，選定總線波特率，一般為500K，點擊確認並啟動，啟動CAN接口卡。
點擊文件中的DBC解析按鈕，選擇對應的DBC文件開始大海撈針的採集數據。
其難度是：有的數據是加了算法的，針對數據的CAN ID一個一個做記錄，變量數據通常的都比較簡單，算法數據上才是真正考驗能力的時候。速銳得在做豐田氫能源車整車控制策略的時候，1000多組CAN ID裡面甄選了142個必要數據，其中有86個數據都帶「複雜」算法還參雜了其他CAN ID變量的邏輯。
隨著汽車電子技術的發展，汽車上所用的控制單元不斷增多，CAN總線技術的應用範圍廣泛，在工業控制測試、汽車電子維護維修、協議適配與解碼，數據單元的控制與訪問。