軟件質量：汽車智能化新課題

文 本刊記者 朱熙

追求“萬無一失”的汽車產業，正面臨數字化變革帶來的質量挑戰。如何造一輛不會“死機”的汽車，將成為智能汽車普及道路上的重要一關。

汽車“死機”

在1998年的計算機博覽會（COMDEX）上，微軟創始人比爾·蓋茨曾表示：“如果通用汽車像計算機行業一樣緊跟技術更新節奏，那我們都將駕駛25美元的汽車，而且每1000英里只需一加侖汽油。”之后，通用汽車給出了一篇回復表示，這輛25美元且超節油的汽車，將每天無理由失控兩次，“操控車輛轉向或倒車時，可能導致熄火并拒絕再度發動……毫無理由將你鎖在車外……必須使用通用汽車牌導航地圖，否則車輛失控次數會增加……每次通用汽車推出新車型時，車主必須重新學習駕駛方式。”

如今，“老笑話”正成為新現實。汽車“死機”正越來越多的見諸于媒體。2019年，一輛蔚來ES8在行駛過程中OTA升級時當場黑屏“死機”，不僅無法啟動，且連車窗也無法升降，影響北京長安街交通一個小時；今年1月，美國NHTSA國家公路交通安全管理局致信特斯拉，由于中控屏MCU故障，要求其召回15.8萬輛Model S和Model X。

“智能”導致的缺陷問題并不僅局限于新造車勢力。市監總局缺陷產品管理中心汽車召回管理部主任肖凌云提供的數據顯示，2013-2018年的汽車召回案例中，與汽車智能系統和功能相關的召回共有20次，涉及20.69萬輛；涉及軟件的召回次數109次，召回車輛191萬輛，呈明顯上升趨勢。

顯然在機械功能日趨完善的同時，軟件系統的功能安全作為汽車質量的另一大門檻，其重要程度正愈發凸顯。

究其原因，一方面是智能汽車中的軟件占比相比傳統汽車正在大幅提升。如可實現L2級駕駛輔助、智能座艙、語音助理、OTA等現階段功能的智能汽車實現代碼量相較傳統汽車增加了十倍左右。

另一方面，則是由于智能汽車內部功能區域不再“涇渭分明”。當前汽車的電子電氣架構正在由傳統的分布式電子控制單元（ECU）向域控制器架構逐步升級，汽車動力域、座艙域、底盤控制域、自動駕駛域等功能需求正在逐步形成。“這種轉變使得原本清晰的軟件開發邊界變的模糊，軟件的耦合性變大，軟件的復雜度也隨之大幅增加。”中國汽車工業協會（以下簡稱中汽協）秘書長助理兼技術部部長王耀表示。

如何打造車規級軟件

事實上，在智能汽車大行其道之前，汽車產業已對軟件質量高度重視。

“隨著系統技術復雜度、軟件規模、機電部件的不斷增加，由系統性失效和硬件隨機失效導致的風險也在增加。”2011年針對電子電氣系統安全相關的國際標準ISO26262發布，其開篇這樣論述道。

而且，早在2005年，由歐洲20多家主流汽車制造商共同制定的ASPICE（Automotive Software Process Improvement and Capacity Determination，汽車軟件過程改進及能力評定）就已發布，在歐洲汽車行業內被廣泛應用。近年來，隨著軟件在汽車研發中的比重不斷增加，ASPICE也被引入國內用以指導車載軟件開發流程，改善軟件質量。此外，包括車載軟件的功能安全、網絡安全都已有相關技術標準。

盡管已有相當嚴苛的流程指導和技術標準，但軟件數量和復雜程度幾何級增長的智能汽車，仍將打造“萬無一失”的車規級軟件的難度推到了新高度。

一方面，可靠性驗證的內容和手段更加復雜。中國汽車技術研究中心有限公司的專家表示：盡管汽車行業軟件開發依據統一代碼書寫標準和統一軟件架構標準并基于模型設計開發，但軟件代碼撰寫難度仍較大，無法有效及時保證其代碼質量。因此，智能汽車相比傳統汽車在可靠性驗證上不再只關注車輛動力和底盤性能，同時需要驗證車輛信息安全、功能安全、數據安全、駕乘安全和軟件升級安全等多方面的可靠性和安全性。

另一方面，這是場時間金錢與可靠性之間的博弈。王耀指出：遵循ASPICE等相關流程和技術標準，可有效保證汽車軟件的可靠性，“但未來隨著汽車軟件代碼劇增，如果未來所有的汽車軟件開發完全遵循上述的開發流程，汽車的研發周期以及研發成本將倍增。目前IT領域比較流行的敏捷開發模式雖然可以實現快速交付，但這種模式如何有效保證汽車系統級軟件的質量，迭代頻次一旦過高是否同樣會帶來軟件開發成本過高等問題仍需要行業進行思考。”

誰來“造”汽車軟件？

保證智能汽車的軟件質量，不僅受制于量大、復雜、要求高的自身特性，同時還因開發者的邊界愈發模糊而變得更加困難。

傳統汽車開發流程中，主機廠只需要定義零部件信號接口，由零部件供應商根據定義提供軟硬件一體的解決方案，主機廠更多的工作是做系統集成，無需關心零部件中的軟件是如何實現功能的。

而智能汽車則打破了這一線性的合作模式。在引入域控制器甚至中央計算平臺之后，各部件功能高度融合，“軟硬分離”成為汽車行業共識。與此同時軟件產品也已被進一步細分為軟件工具鏈、基礎軟件、軟件中間件、應用軟件等產品。

由此，行業開發分工進一步明確，產業鏈上各方都開始“重新學習”。王耀表示，此前站在供應鏈核心位置的硬件Tier1需要具備一定的軟件開發能力，如提供外設驅動及編譯工具、底層操作系統等；曾處于第三甚至第四級供應商位置的“外行人”IT領域軟件供應商，則需進一步了解智能汽車，具備更深與更廣的軟件開發能力；而主機廠除開始將硬件和軟件產品分開，進行獨立招標外，還需要擁有強大的系統架構、硬件架構、軟件架構和通信架構的能力，并對總體集成負責。

但在產品端“軟硬分離”的同時，行業端的“軟硬融合”則成為了新的挑戰。2020年底率先在汽車行業爆發的“芯片荒”中，“芯片不懂汽車、汽車不懂芯片”便成為困擾雙方協同破除芯片緊張壓力的阻礙之一。

“目前汽車行業內還沒有形成應用于量產自動駕駛汽車產品的汽車軟件架構及相關接口定義。同時，自動駕駛汽車的軟件開發過程融合了IT領域軟件開發技術和汽車領域軟件開發技術，大量的跨域協同工作也增加了軟件的開發難度。” 王耀表示。

如何監管軟件質量？

“相較于傳統汽車，智能汽車在車輛穩定性、一致性方面均需要滿足更高的要求。”王耀表示：在車輛穩定性方面，智能汽車的自動駕駛系統從設計之初便增加了功能安全與預期功能安全的要求，通過核心器件冗余備份和提升性能邊界等手段來保證更高的系統穩定性。

一致性方面，車輛測試與認證要求在相同測試場景下智能汽車完成的駕駛動作與行駛軌跡須保持高度一致，這對于智能汽車的攝像頭、激光雷達、毫米波雷達、電控單元以及線控執行機構等電器元件的軟硬件質量一致性提出了很高的要求。同時，智能汽車在生產，制造時要面對更加復雜、嚴格的出廠質量檢驗要求。

但僅憑行業自律顯然不夠。近年來，隨著智能化成為汽車產業轉型方向的共識，相關國際組織和國家也正緊鑼密鼓的制定相應的標準和監管方向。

“第三方監管一定要站在公平公正第三方的立場上，服務于國家、企業和消費者，為行業進行監督。”中汽中心的專家向記者表示：首先，要引導企業強化自身的軟件安全意識與安全保障能力，迅速建立OTA升級管理體系，并具備覆蓋全流程的升級實施能力、信息安全保障能力、軟件質量管控能力、升級測試驗證能力、升級過程信息記錄存儲能力、風險防控和應急響應能力等；然后，針對汽車軟件的功能不同進行分類，如哪些是影響車輛駕駛的安全性，哪些是提升車輛舒適性等。不同的功能分類，其風險定位以及監管力度以及手段也是不一樣的。此外，在確保規范后，應對企業的開發流程和使用過程進行一定的監督，評估、驗證企業內部的相關文件以及記錄，確保其可供調取和檢查。

對于創新技術下誕生的新生事物，容錯與監管同等重要。這一道理對于攸關產業未來命運，也關乎普通消費者生命安全的智能汽車尤為重要。如何兼得創新與安全，將是產業、行業與政府共同面臨的課題。