隨著汽車智能化日趨深入，手機與汽車不斷結合，越來越多車企的商業場景中引入了數字鑰匙方案，為消費者帶來了更加智能和安全的使用體驗。

但數字鑰匙系統建設之路并非坦途。一個完整的數字鑰匙系統涉及車廠、手機廠、芯片廠、軟件服務廠商等多個領域，即便在數字鑰匙滲透率日益高漲的當下，車企仍然面臨著眾多的選擇和挑戰。數字鑰匙個頭雖小，做起來卻并不輕松，這一點做過數字鑰匙的工程師們都能深深理解。創新應用須經千錘百煉自不必說，頻繁踩坑更是家常便飯。那么今天我們就來談一談要“提升用戶體驗，增加用戶粘性”，應該如何有效地做減法，從而優雅地避開潛在的風險，讓數字鑰匙系統的建設和部署工作能夠事半功倍地有序進行。 

在數字鑰匙系統設計之初，令廣大車企最頭疼的一個事情便是如何選擇數字鑰匙協議。回顧數字鑰匙的發展歷史，自有協議似乎是數字鑰匙建設之初的必經之路。在2020年之前幾乎所有車企應用的數字鑰匙都采用車企或方案商提供的自有協議，車企按自身需求和理解定義通信和認證協議，這樣可以保障自由度，但同時也提高了與不同手機對接的復雜度。于是以互聯互通為目的的標準數字鑰匙協議紛紛登場，像國際上赫赫有名的CCC，國內華為推動的ICCE、以及ICCOA等等。他們通過手機的原生支持，為終端用戶提供更好的使用體驗。但隨之而來的問題是，目前所有的標準協議都還處在發展過程中，數據結構、認證流程等各不相同，并且仍在不斷地迭代更新，還沒有一個協議可以覆蓋市場上所有手機。CCC和ICCE為了提供更安全的數字鑰匙運行環境，需要使用手機內置安全元件SE，而市場上內置SE的智能手機還不到50%，這意味著一多半的手機無法部署標準CCC或ICCE；而基于TEE技術的ICCOA支持的手機品牌同樣有限。為了兼容更多的手機，車企不得不在車端和云端部署對多個協議的支持，既耗費了研發資源，也增加了開發和運維的復雜度。促成數字鑰匙低成本快速落地，就要用盡量少的協議去兼容更多的手機，并保持后續更新擴展的能力。

以我們多年數字鑰匙商用部署的經驗來看，比較推薦的方式是先使用一套自有協議覆蓋絕大多數手機品牌，然后根據自身客戶群體分布，選擇主打的合作品牌手機所支持的標準協議。畢竟標準協議雖然能提供原生的優質支持，但只能覆蓋有限的機型，即便是同一種協議，比如CCC，也需要與不同的手機廠分別進行對接，所以最好是集中優勢兵力與主力合作品牌打響發布，隨后迭代優化再逐步對接其他品牌。而保留自有協議，可以在尚未與更多品牌手機對接的時候以最低成本的部署做到最大的兼容。比如通過基于軟件白盒技術的SDK為手機部署軟件安全運行環境并整合到車主APP中，用戶安裝APP即可放心使用數字鑰匙服務，無需與每一家手機廠商單獨對接。

從車企的角度，無論使用哪種協議，都請不要忘了建設的初心——提升用戶體驗，增加用戶粘性。所以無論采用哪種數字鑰匙協議，使用哪款手機，都應該為用戶提供統一的優質體驗。這需要在數字鑰匙系統的設計之初，就讓各個協議可以兼容運行，甚至互聯互通，協議A的手機也可以分享給協議B的手機，讓用戶安心自由地享受數字鑰匙帶來的便捷順暢體驗。

協議兼容性之外，數字鑰匙系統還需要靈活的更新能力，以便于持續地穩定優化系統、迭代擴展應用，因此在數字鑰匙系統架構的設計上需要采用業務系統與底層能力解耦的方式。這里的底層能力指的是可以為數字鑰匙系統提供基于不同數字鑰匙協議的基礎能力，包括協議的解析、指令的生成、數字鑰匙處理邏輯、以及相關組件的生命周期管理。手機端SDK和車端SE，這一部分可以由專業的數字鑰匙系統提供商來負責，關鍵要提供這些能力的調用接口API；而車企在基礎能力之上去構建自己的數字鑰匙業務，去組織、修改以實現業務場景不斷完善、迭代、和擴展。這種上層應用業務的重新組合以及迭代并不需要對當前的底層數字鑰匙能力去進行改動。換句話說，不需要頻繁的需求變更，只需通過輕量級的底層能力接口調用，去更新完善自己的業務。以數字鑰匙遷移為例，用戶在A手機上開通了一把數字鑰匙后，又切換到了B手機，那么通常可以有幾種處理方式：1）將這把數字鑰匙開通到B手機上，同時刪除A手機的鑰匙；2）開通B手機上的鑰匙，同時保留A手機上的鑰匙；抑或是3）刪除A手機上鑰匙，同時也刪除所有A手機分享出去過的鑰匙等等。在這些需求下，只要使用了底層能力與業務應用解耦的方式，車企完全可以根據自己當前的需求選擇不同的場景服務模式，而無需再下需求變更給供應商去修改整個數字鑰匙系統，免去了需求、報價、交付、驗收等等一系列操作，可以極大縮減系統的迭代周期。

現在數字鑰匙協議以及系統服務的架構已經做好了選擇和設計，我們就可以進行開發和測試，并為部署上線做好準備了。但在開發和聯調測試過程中，不可避免的會遇到各種各樣的問題，因為數字鑰匙系統的節點實在太多了。比如我們要開發和測試一個后臺數據生成并下載到車端SE的功能，就要面對一條復雜且漫長的路徑，首先APP或TSP發起請求，數字鑰匙系統服務后臺計算出業務指令發送到TSP，再到車端的T box，經過車內CAN總線或Ethernet下載到數字鑰匙控制器ECU，經過Agent軟件處理再通過SPI接口發送到SE。這條路徑上，每一個節點都有可能有漏洞或者是缺陷，而任何一個bug都可能導致整個鏈路的阻塞。那么比較合理的開發和驗證方式，是將這些鏈路分級，抽絲剝繭般逐層逐級驗證盡量少的引入變量，最后再進行系統級別的全鏈路聯調。我們可以用樣本數據對本地鏈路進行功能驗證和壓力測試，之后進行樣本數據的在線測試，通過以后再采用真實的測試數據。這樣在一層一層地保障各個模塊組建工作正確的前提下，才能確保整個鏈路的暢通以及用例的順利執行。反過來當出現問題以后也可以去快速定位，省去逐個節點爭論扯皮的時間。當然設計驗證各個組件之間鏈路的樣本數據并不簡單，這需要大量的經驗去生成合理的數據以及測驗方法。車企可以尋找質量可靠的合作伙伴，對類似的復雜場景去進行驗證性測試設計。

好啦，現在看一看，我們選取了合適的數字鑰匙協議并且為之設計了靈活的系統框架，還需要的就是方便靈活的測試環境，這樣在后面的聯調過程中，無論出現了什么樣的難題，我們都可以進行快速的定位分析。這里我們也建議從開發開始，一直到功能上線，始終保持著一套臺架測試環境，在這個測試環境上面能夠有足夠的日志，可以對各個階段出現的問題進行復現和定位，并方便地驗證我們的改善方案。

當然，整個數字鑰匙系統服務，涉及到車端、云端、手機端等各個節點的建設，主機廠很難在短時間內去深入研究和熟悉如此眾多的組件和因素，并做出最合理有效的選擇。所以說與有經驗的系統服務商合作，是一條事半功倍的便捷之路。

伙伴·捷德

捷德集團作為一家有著171年發展史的百年老店，始終致力于為廣大客戶提供可信的連接和安全方案。從2017年開始，捷德中國已為多家車企及合作伙伴提供了數字鑰匙服務方案，覆蓋車端、云端、手機端等多個功能和安全組件，并商用20余件數字鑰匙項目，擁有豐富的經驗和可靠的產品，可以為車企的數字鑰匙系統建設提供寶貴的建議和端到端產品與服務。

返回第一電動網首頁 >