1樓：Silmar
C確實是乙個非常重要卻又很難驗證的乙個值，我寫了一篇文章：
躲在鋼琴裡的貓：自動駕駛中駕駛員轉向可控性的研究
介紹了轉向可控性方面的相關試驗，同樣，對於其他方面的可控性，也需要一系列的試驗等去分析論證，這樣才能從乙個比較嚴謹的角度去定義C。
2樓：NutshellKing
強答一下。開眼界了，工業界的標準真的很全面。以前只聽過ASIL，自己在學校做Prototyp開發時沒要求搞這個，只做簡單的魯棒性Robustheit，基本上都是拍腦袋定的場景然，後換算成激勵輸入的。
簡單看了一下，其實ISO26262中定義輸入的流程定的很清楚了
也就是推導過程是危險/風險分析->安全目標->功能安全要求->技術安全要求->軟體安全要求。所以一切起點是危險/風險分析。而其關鍵應該是型別的全面和基於統計的覆蓋率取捨。
我想這應該是主機廠的核心機密了。如果自己公司沒積累，可以去找專門做事故調研的大學中汽研保險公司獲取事故資料，這裡給同濟的王鴻雁和朱西產老師打廣告。
以上隨便說說，我沒有功能安全經驗，不構成建議。
3樓：Ted Zhang
好專業的問題！
這個問題沒有做過功能安全故障注入實驗的同學確實很難回答，在HARA分析的Work Breakdown Structure中對於流程的簡要定義為（每家廠商都會有獨特的Know How流程，這裡只能給出概要）：
Operation situation analysis to define exposure parameter
Define vehicle level HAZOP guide words
Create the guideline of severity and exposure acc. operation situation
Create simulation acc. operation situation to evaluate the severity and controllability
Create risk management datasheet
最關鍵的且技術含量最高的就是步驟三，在ASIL確定中要考慮的第三個方面是可控性，這是最主觀的引數。可控性（C類）代表避免傷害的能力水平。在自動駕駛系統中通常可控性的需求來自於底盤的表現，通過對於底盤的直接故障注入來估算自動駕駛系統故障的C類。
以LKA為例，該方法基於對車輛的電動助力轉向（EPS）的故障注入測試。
Workflow Chart for FI
基於該方法進行了可控性測試。該測試涉及3名專家司機。故障噴射包括在中心車道上沿直線方向行駛期間方向盤上的意外扭矩。
對車速的不同值重複測試，轉向扭矩值和三個壓擺率注入的故障。在測試期間收集了以下客觀資料：橫擺率，橫向加速度等指標。
在每次實驗結束，Cooper-Harper會被提交給司機，以收集可控性的主題等級。主觀分析確認不同轉向指標對於操控性的影響。主觀引數和客觀引數之間的匹配提供了C1可控性的量化指示。
Cooper-Harper
可能只有真正去過試驗場呆過幾個月的同學才會有血淚的經驗吧...
如何設計乙個好的Model與Controller（MVC）？
騰飛 我的看法是別太硬套MVC吧！還有設計模式，那些只是培養你軟體架構，解藕的這些常用方法，把那些融入但你的思維當時方式中就行。記得一些最基本的原則，解藕，解藕，解藕 對於MVC,實際上就是把顯示和資料處理分離，顯示和使用者互動分離。view只負責現實，根據資料來顯示內容。什麼時候需要重新整理，由c...
如何量化設計？
王小翼 1.建立設計標準工期 就是做乙個設計專案需要花費多少工作時間 2.制訂產出物標準 根據行業或以往工作內容，提煉出不同級別的標準3.結合設計師個人效率和專案進度情況，填寫timesheet Milo 量化設計是一件非常痛苦的事情，曾經被老大些逼著研究制訂過，截至目前仍在不斷探索中。有一些小小的...
如何有效避免量化過程中的過度優化問題？
量化小兵 這個世界是平衡的，沒有任何乙個事物是完美的，在所有的方面都是表現最好的。所以我們會面對很多 不可能三角 的抉擇，而無法做到魚和熊掌兼得。不要陷入不斷優化的陷阱之中，引數優化適可為止。 ayime 瀉藥，這個問題還是簡單的，想避免過度優化，是足夠多的樣本，能覆蓋所有可能發生事件的樣本。世界上...