近日，伊利諾伊大學香檳分校的一個研究團隊新開發了一種針對自動駕駛的故障評估技術，他們首先對百度Apollo 3.0和英偉達專有自動駕駛系統DriveAV進行了一次軟件故障評估。
結果顯示，這隻團隊在4小時發現了561個關鍵安全故障，其中，百度Apollo 3.0和英偉達具體故障佔比並未說明。
針對這一事件，百度在第一時間發表聲明稱，“非常重視測試發現的模塊異常，將持續優化，Apollo自動駕駛系統的運行依賴於軟硬件各模塊的協同工作，從而完成自動駕駛的安全運行。在新型FI測試中，同樣依託多模塊的軟硬件協同機制，從而避免風險的實際發生。”
從百度回應中可以看出，單純的軟件故障並不能使自動駕駛汽車發生一系統安全事故。
除了百度回應外，單從這一事件本身在車端可行性而言，其實，存在很多討論的地方。
通過論文可以了解到，該研究將Apollo的代碼放到一個服務器上的虛擬容器（Docker）上進行測試，導致注入故障後無法解決。
這裡我們需要知道一個前提條件就是，故障注入是針對系統的，而百度真實的系統是軟硬件一體，Apollo代碼運行於符合車規和功能安全的硬件上，即便注入故障也不會出現問題。
與此同時，在實際駕駛過程中，Apollo冗餘系統一旦發現車速異常，就不會執行深踩油門的動作，也就不會產生類似追尾的風險。
另外，論文中人為修改自動駕駛的控制輸出，造成猛踩油門，而這情況在真實的安全硬件上不會發生。
按照我們實際的開車經驗，大部分情況下，即便車往前竄了一下，也不至於撞到前面的車。
在這篇論文中可以找到一個極端的CASE，即本車以安全的車距在跟隨前面的車，在車速被改、向前加速一下的同時，假如恰好有一輛車從旁邊車道併線過來，安全車距就會突然變短，這時候才會撞車。
不過，這樣的事故，全責在變道車。
對此，百度相關人員也給予了同樣的解釋，“因為真實的硬件上，這部分代碼跑在ASIL-D級安全的MCU上，這種安全MCU裡面有兩個處理器，試行同樣的運算，相關校驗，它把一個處理器的內存改掉，讓它計算錯誤，這就會和另一個處理器的值不一樣，立刻就發現了，根本不會輸出。”
自動駕駛相關安全領域專家也對此事件做出點評，他們認為，“故障注入”研究方法是在一些位置植入故障，如果場景導致事故，則該植入場景算作研究中的一個‘Fault’。”
也就是說，如果測試中將剎車破壞，從而導致事故，則剎車失靈是一個“Fault”。
其實，今年7月，美國伊利諾伊大學香檳分校研究人員發表題為《ML-based Fault Injection for Autonomous Vehicles: A Case for Bayesian Fault Injection》的論文，根據相關表述，研究人員對百度Apollo、英偉達進行了兩種FI測試。
其中，在傳統故障注入（FI）下，Apollo代碼和參數沒有出現任何問題，表現穩健。
在這起自動駕駛故障評估事件中，我們看到美國伊利諾伊大學香檳分校研究人員是想通過故障評估的方法來驗證自動駕駛系統的安全性，但由於評測有過多的人為修改以及模擬測試結果導致其公眾誤讀。
誠然，評測機構的權益與企業的權益都應該得到尊重，而辨別其中的責任，我們更需要從實際出發，理性的看待自動駕駛汽車出現的問題。
以下為百度Apollo完整回應：
我們關注到近期伊利諾伊大學香檳分校研究人員對Apollo開放平台的關注和使用，我們正與對方取得聯繫，了解更多信息。
根據論文表述，研究人員對Apollo進行兩種FI測試，在傳統故障注入（FI）下，Apollo代碼和參數沒有出現任何問題，表現穩健。感謝該校研究人員對Apollo平台的認可。而新型的FI是使用故意更改代碼和參數的方式，引發嚴重錯誤或警告性錯誤，可幫助自動駕駛更好地發現安全風險。
Apollo自動駕駛系統的運行依賴於軟硬件各模塊協同工作，從而完成自動駕駛安全運行。對該分校在新型FI測試中出現的模塊故障，我們有多模塊軟硬件協同機制，來避免風險實際發生。在新型FI測試中，會人為地把代碼裡面輸出的點踩油門控制信號修改成深踩油門。而在實際過程中，Apollo冗餘系統一旦發現車速異常，就不會執行深踩油門動作，也就不會產生類似追尾風險。
但即便多模塊協同、軟硬件冗餘能避免安全風險產生，我們也還是非常重視FI發現的模塊異常，並持續優化。
就開源平台本身而言，我們高興地看到平台給大家的研髮帶來了便利和可能性。通過開源代碼，我們一起去發現問題，解決問題。通常在一項技術高速發展期，如Apollo開源系統，在全球開發者幫助下，會比封閉系統都更安全，這也是我們開源的目的與意義所在。
Apollo每天都在持續迭代，向更安全、更可靠、更完備上進步。Apollo也希望集大家力量，共同推進人類夢想進步。
