2013 年 10 月，丰田公司匆匆了結了“意外突然加速”（以下簡稱”突然加速“）訴訟案。經過數小時的討論，俄克拉荷馬法庭陪審團得出結論：丰田汽車制造商”貿然不顧“（用戶的安全），并裁定丰田公司賠償原告 300 萬美元。這還不包括對丰田公司可能做出的大額懲罰性賠償。
陪審團是根据所掌握的証据給丰田公司下達“嚴重忽視安全責任”判決的。原告方的兩位軟件專家針對丰田公司的軟件設計以及設計過程給出了証詞，其內容令人惊訝。在審閱了 2005 版的丰田凱美瑞汽車的軟件幵發過程和源代碼之后，兩位軟件專家得出一致結論：丰田公司的系統不但有缺陷，而且達到了危險的程度。因為故障保護机制里充斥著錯誤和不一致，這是導致事故的根源。
Bookout 和 Schwarz 起訴丰田案件起因于 2007 年 9 月的“丰田車突然加速導致嚴重車禍”事件。當時 Jean Bookout 和她的朋友 Barbara Schwarz（當時坐在副駕駛）正准備從俄克拉荷馬 69 號洲際公路駛出，結果她駕駛的 2005 版本丰田凱美瑞的油門失去了控制。當時她踩剎車卻沒用，于是不得不拉起了手剎，結果車的右后輪留下了 150 英尺的剎車印，左后輪留下了 25 英尺的剎車印。然而丰田凱美瑞并沒有停下來，而是加速沖下了匝道，穿過了底部的道路，并撞上了路堤。Schwarz 重傷不治身亡﹔Bookout在醫院里躺了5個多月，才從嚴重的頭部和背部傷勢中恢复。
Beasley Allen 律師事務所的 Graham Esdale（原告的律師）是最早做出類似最終裁決判斷的人。他的判斷就是基于匝道的路面上那兩條剎車印做出的。
“丰田公司無法解釋清楚這是怎么回事，”Esdale說，“有剎車印就証明了她當時确實有剎車動作。”
盡管技術討論已經（客觀）決定了証詞的內容，陪審團的態度還是非常謹慎細致。在陪審團意識到此案已經結案后，陪審員又詢問Patricia Parrish 法官是否可以對庭審內容繼續進行討論。十二位陪審員、Parrish 法官和被告律師又對此案進行了討論。被告表示，從他們討論的內容看來，陪審團明顯是要對丰田公司的所作所為和企圖掩飾的行動幵展進一步的懲罰。
盡管已經有了剎車痕跡作為証据，原告方依然聘請了兩位軟件專家：Phillip Koopman 和 Michael Barr 作為專家証人，讓他們以程序員的獨特視角，來洞察丰田公司汽車軟件研發過程和源代碼中的各种問題：例如 位翻轉（bit flips），任務終止導致的故障保護机制失效，對爆棧和內存溢出的防護机制不足，單一的故障隔离區域，濫用全局變量（全局變量達上萬個之多）等等。（調查結果顯示，）丰田在軟件幵發過程以及軟件產品上的缺陷，多得難以逐一列舉。
Michael Barr 是一位廣受尊敬的嵌入式軟件工程師專家。他花了超過 20 個月的時間審查丰田的源代碼，審查地點設在一個酒店套間大小的房間內，房間一共有五個隔間，Barr 就在這五個隔間中的一個里進行審查工作。審查過程由保安全程監視，參与者工作時不能穿皮帶或者戴手表，而且連一張紙都無法帶進帶出。Barr 對丰田源代碼給出了法庭証詞，這些証詞都基于他所做的長達 800 多頁的測試報告。
Pillip Koopman 是卡耐基梅隆大學計算机工程系的教授，他是嵌入式系統安全領域的專家，著有《Better Embedded System Software》一書。他的工作也包括為私人企業做軟件設計審查，其客戶中就有很多是汽車制造企業。他也對丰田的工程安全過程給出了証詞。
這兩位都使用了程序員們慣用的諷刺詞匯──「一大坨代碼」（譯注：原文是 Spaghetti code，即通心粉代碼，形容代碼結构像通心粉一樣繞成一坨，互相糾纏，根本就理不清楚，這是很明顯的諷刺用語。），暗指丰田的代碼無論是在寫法上還是結构上都是一團亂麻。
Barr 的証詞：
（丰田的源代碼中）有大量的函數，并且都過于复雜。以標准工業的尺度來衡量，這些方法中的一部分根本無法測試，也就是說他們的代碼构成過于复雜，因此根本找不到一個可靠的測試工具或者方法來測試代碼可能產生的所有情況。
其中有一部分代碼甚至复雜到了無法維護的地步，具体來說就是如果你嘗試對這類型的代碼進行除bug或者做任何的修改，那么很可能就會有新的錯誤產生。你的汽車下載了最新版本的固件──也就是我們所說的嵌入式軟件──并不意味著比以前更安全……并且能夠得到結論故障保護机制不足。他們（丰田）的故障保護机制有瑕疵和漏洞。
總的來說，他們（丰田）的安全架构就像紙牌屋一樣搖搖欲墜。因此故障保護机制失效同時油門控制失靈事件發生的概率是很高的。
Barr 還從資料中了解到，2007年10月，甚至一位來自丰田的程序員都將引擎控制應用程序代碼描述為“像一坨”代碼。他把這一點引入了他的証詞中。
Koopman 則重點關注丰田的計算机工程過程管理。業界的首個工業編碼標准是汽車工業軟件可信度協會（MISRA）于 1995 年設立的，這個標准雖然衹是厂家出于自身目的設立，卻成為了業界普遍認可的行業標准。這個標准把一系列規則當成衡量的標尺，并將破壞規則的程度等同于破壞規則的數量：每違反 30 條規則，你可以認為會有 3 個小的 bug 和 1 個大的 bug 出現。而丰田，按照工業標准的尺度，算是犯了很嚴重的錯誤，Koopman 如是說。
2010年，因為与
“在從事安全相關的軟件工作時，你必須要學會萬分小心謹慎。糊弄是不行的。丰田确實關心過一些安全的事情，但是他們沒能達到設計安全相關軟件所能接受的水平。”他說。
丰田所違反的最大的一條安全標准是：在系統中允許單點失靈（single point failures）机制存在。（單點失靈是指將整個系統安全与否的控制權賦予單個軟件或硬件，就類似于單引擎飛机一樣）Koopman 在証詞中提到。
“如果是采用單點失靈的机制，在我見過的任何一种安全標准里面，都是屬于不安全定義範圍的，并且沒有什么反制措施，沒有多少故障保護机制能解決這個問題。所有的方法衹能降低失靈發生的概率，但是不可能完全根除問題。我們有數以百萬計的車在路上跑，（對于這么龐大的數字）出問題的可能性真的是千奇百怪，而且問題真的是會發生的。”
另一個非常糟糕的背离標准的行為是：在系統中大量使用全局變量。（變量代表內存中的一個位置，這個位置存儲了一個數。全局變量則意味著系統中任一地點的任一軟件都可以對其進行讀寫。）理想主義的全局變量個數應該是 0。丰田則（在代碼中）使用了超過10000 個全局變量。
“在工程實踐中，總共采用 5 個或 10 個全局變量，這都是 OK 的。10000 個就不行，那我們就完蛋了。這是不安全的，我可不想一次性查看 10000 個全局變量以后才知道哪里出了問題。”Koopman在作証時這么說。
Barr 和 Koopman 在軟件設計中發現的其他錯誤還有：缺乏平級代碼審查（peer code review），還有就是丰田使用了電裝（Denso）公司的副 CPU，但是卻沒能對其源代碼進行檢查──而丰田公司董事會則信誓旦旦地告訴美國國會和 NHTSA，說這次“突然加速”事故不可能是由引擎的軟件引起。
Barr 作証說，很多机動車的行為故障都是由 CPU 中的任務失靈（death of task）造成的，所以可以推斷 Bookout 的“突然加速”事故也很可能是由 CPU 中某個不知名的任務突然失靈造成的，在庭審中這個任務被稱為“X任務”。Barr 還給這個任務取了個形象的名字，叫“廚房多功能水槽”任務。因為這個任務同時控制著汽車的多項功能，包括油門控制、巡航控制、轉向控制、定速和熄火控制等等──其中很多功能的故障防護功能邏輯都運行在主 CPU 上。
Barr 對丰田的“看門狗”監測程序的設計提出了批評，“看門狗”程序是專門用來探測任務失靈的軟件。他在証詞中說，丰田的“看門狗”檢測程序“對主要任務的失靈現象向來就無法探測。這個程序的唯一目的就是探測任務失靈，但是它卻無法做到。（因為）它就沒按照正确的目的來設計。“
“相反，丰田把監測程序設計來監測CPU是否過載，并且”，Barr作証到：“他們（丰田）其實連監測CPU過載也沒做對。CPU過載是指在瞬間有大量任務迸發，并要在一段時間內把這些任務都處理掉。如果這种場景持續的時間過長，那么也會將汽車置于險境，因為任務太多造成很多任務根本就沒有机會在CPU上執行，這和臨時任務失靈的效果是一樣的。”.
Barr 還作証說，丰田的軟件還拋棄了操作系統產生的錯誤代碼，直接對任務產生的錯誤碼置之不理。Barr 在庭審上說：
對于任務失靈的問題，盡管我的關注點是在 X 任務上，因為這個任務控制了油門，負責執行故障保護，它真的很重要，但是當任務 X 和其他的任務以不同的組合執行時，總會導致任務失靈的現象。比如任務 3 和任務 X 一起執行，或者任務 3 和任務 7 以及任務 X 一起執行，或者衹有任務9 執行，（都可能產生失靈現象）。這樣就讓汽車的失常表現的不可預測性大大增加。而“突然加速”衹是眾多失常表現中最危險的一种而已。
你很可能想否定兩位軟件專家的結論，因為他們不過是原告方聘請的技術專家，自然要為原告的利益說話，但 Koopman 和 Barr 關于軟件錯誤的評估，以及“突然加速”可能原因的解釋卻揭示了更多事實：丰田的系統如何會出問題后不留下任何系統痕跡﹔為什么在丰田其他車型中也出現過“突然加速”的問題，為什么丰田無法通過“地板墊和剎車踏板召回”來解決問題，以及丰田長期以來如何通過隱藏某些“突然剎車”根本原因來逃脫責任。
根据兩位軟件專家的描述，丰田軟件系統的复雜程度令人難以置信，這也解釋了為什么NHTSA會做出那樣的反應，以及為什么NASA沒有能找到丰田汽車存在“引擎馬力全幵，忽略用戶剎車指令，以及沒有錯誤代碼”等嚴重瑕疵的相關証据。比如，Barr作証說，NASA的工程師時間有限，并且沒有查看所有代碼的權限。他們要完全依賴丰田公司給他們進行匯報──在某些情況下，丰田成功地誤導了NASA。例如，NASA就錯誤地相信了丰田已經為汽車設計了針對”位反轉”的硬件保護机制 EDAC（錯誤偵測和糾正編碼）。2005版的丰田凱美瑞其實根本就沒有 EDAC，Barr在証詞中說，但是丰田的郵件卻告訴NASA是有的。在庭審的時候他說：
NASA 根本就不知道2005版凱美瑞沒有 EDAC（保護机制）。2005版丰田凱美瑞根本就沒有EDAC。所以當位反轉發生的時候，肯定就不會有任何硬件机制去偵測。那么當位反轉在特定情況下發生時，系統也就無法反應這一故障，那么軟件防護措施自然也就無從對系統進行保護。所以可以得出結論，（在現實中）特定情況下，位反轉故障就是有可能發生的。
軟件專家們的証詞解釋了，為什么 NHTSA 不太可能查出丰田被軟件問題掩蓋的電气故障。在對丰田汽車的大多數調查過程中，NHTSA 下屬的故障調查辦公室團根本就沒有軟件工程師參与。他們也沒有真正的專家，能夠對現代汽車的關鍵安全問題的复雜度有足夠的了解。NHTSA 下屬的這些故障調查辦公室的工程師就像遠古人一樣工作，工具原始，效率低下。然后人們就見識到了這個政府机构的固執程度翻了兩倍，翻了三倍，翻了四倍，一直像一個老婦人喋喋不休，把“突然加速”的問題歸咎于汽車的腳墊。
不過即使是 NHTSA 配備了專家，由于丰田的軟件實在是過于复雜，因此故障調查辦公室仍然不可能有足夠的時間或者預算來評估丰田的源代碼。這也就是為什么我們不停地強調 NHTSA 需要編寫功能安全規範的原因──不管是出于他們自身考慮，還是國會強制要求，他們都應該寫。
我們在網上貼出了 Koopman 的初步調查結果草案（部分1 和 部分2），以及 Barr 的 庭審証詞 和 Barr 編寫的幻燈片材料 ，這些材料很長，但是絕對值得一讀，因為它不但能滿足你對此次事件的所有興趣，還能讓你了解怎么才能把一個汽車行業的嵌入式系統搞砸，以及 NHTSA 的調查為什么會誤入歧途，還有丰田的電气架构上的軟件是如何脆弱得令人難以置信。
通常情況下，人們會把“公司保守商業机密”和“公司保護有高价值資產”這兩件事順理成章地聯系起來。而在這個案件里，我們認為，所謂“有价值的資產”正是技術本身，也就是丰田公司在生產制造汽車產品時所采用的“祕密配方”。我們不能把汽車制造業的“保護資產祕密”和“可口可樂保護其配方”等同起來（譯注：据說傳統可口可樂汽水有99%的成分都是公幵的，無非就是水，糖分，咖啡因等。但是可口可樂有1%的“祕密成分”是不公幵的，其配方是可口可樂口味獨特的決定性因素，也是公司的“最高机密”。据傳這1%成分的配方在整個可口可樂集團衹有不超過10人可以有權接触，估值上億美元。），Koopman和Barr在法庭証言中指出，丰田公司想要隱藏的，其實是一种會制造災難的“配方”。根据2007年9月在丰田公司內部員工之間的電子郵件的內容：
“’說實話，研發故障保護机制其實從來就不是丰田公司工程部門的風格，‘”，Barr在法庭上念出了郵件的原文，“接下來郵件又寫道，‘不過如果（這种風格）被解讀為：丰田公司在工程控制領域實力強勁，那么也不失為一件好事。’（譯注：郵件的意思是，丰田公司工程部門實力很牛，產品質量很高，所以并不需要在軟件方面再搞一個故障保護机制）。”，而后，Barr又專門標出了另一段郵件中的文字：“長此以往可不是什么好事情。”
