|
小編有個習(xí)慣，做一件事之前必須要深刻理解這件事的全部過程和關(guān)鍵輸出。對于汽車工程師而言，開發(fā)經(jīng)驗可以慢慢積累，但是我們做事情的思路是否清晰很大程度上影響我們的工作質(zhì)量。 我還記得16年剛?cè)肼殨r，還是一個職場小白，領(lǐng)導(dǎo)交給我一個關(guān)于故障響應(yīng)策略開發(fā)的任務(wù)。那時候?qū)τ贔ault reaction strategy的理解是，跟乘客安全有關(guān)系，屬于系統(tǒng)量產(chǎn)必須的部分。但是這部分工作跟功能安全有什么關(guān)系，真是不知道。也是在第二年參加部門組織的培訓(xùn)時，才開始知道ISO26262, 功能安全這些東東。 Fault reaction strategy屬于功能安全的技術(shù)安全概念的一部分，也會涉及到一部分的功能安全技術(shù)需求分配。如果功能安全活動足夠完整，從技術(shù)安全需求文檔里可以整理出來Fault reaction strategy了。哎喲臥槽，想想那會還挺NB, 都不知道功能安全是個啥，都開始獨立寫技術(shù)安全概念文檔了 像俺們這種做乘用車變速器的小作坊團隊 萬能的淘寶，一百塊錢，就能買到一些靠譜的學(xué)習(xí)資料，主要有分析模板更加不錯，真是看的我頭暈眼花 但是這么野路子，你怎么知道你理解的是對的，你寫的文檔是經(jīng)得起推敲的呢？講煽情的故事沒人愿意聽，還是要看功能安全活動是否有高質(zhì)量的輸出，是否產(chǎn)生了真正有競爭力的產(chǎn)品。前同事、球友、同學(xué)，但凡有點功能安全經(jīng)驗的大多被我電話、微信“騷擾”了個遍。功能安全上，我還是個小白工程師，從本期開始，會有一系列的學(xué)習(xí)文章陸續(xù)釋放出來，非?？释掷m(xù)改進，持續(xù)進步。 本期用一個案例來講講功能安全的故事，如果有大牛閱讀到，非常歡迎批評和指導(dǎo)。 功能安全應(yīng)用范圍 功能安全的分析對象針對汽車電子產(chǎn)品，包括軟件和硬件部分，機械件是不在分析范圍內(nèi)的。功能安全活動的大部分的工作輸出體現(xiàn)在軟件和硬件電路的設(shè)計開發(fā)中。 功能安全標(biāo)準(zhǔn)-ISO26262 功能安全的開發(fā)必須要符合標(biāo)準(zhǔn)的，新版的ISO26262總共有9章，涉及到產(chǎn)品的全生命周期。但是對于開發(fā)人員而言，第三章~第六章是開發(fā)的核心。 舉個例子，在第二章的功能安全管理中，對于功能安全活動的確認(rèn)機制，提了如下的要求。我們可以看出，對于ASIL D等級產(chǎn)品而言，功能安全的評估對團隊成員有特殊的要求。這種要求其實蠻主觀的，你很難去證明你確實是這么干的，但是可以感覺出ISO26262的制定者們確實在努力用很多手段和方法去提高產(chǎn)品開發(fā)的質(zhì)量。 Case study: Torque safety concept design 第一步：對象定義(Item definition) 對象定義主要干兩件事:Structure diagram以及Function list. 假定我們分析的對象純電動電驅(qū)系統(tǒng)(我們分析的是純電動車驅(qū)動系統(tǒng)，不是子部件系統(tǒng))。 Structure diagram簡圖如下： Function list(功能列表) 純電動電驅(qū)系統(tǒng)的功能列表的編寫，顆粒度把握是一個重點。在功能安全層面，我們在描述Function list時，關(guān)注在整車層面，而不是子系統(tǒng)層面。比如要寫VCU functional requirement，可以寫上百條，舉下面幾個例子，從FR01到FR04是非常細節(jié)的功能描述。
控制策略開發(fā)工程師拿到需求FR01,可以直接開發(fā)VCU功能邏輯，如下圖所示。
但是功能安全活動時，需求列表里的東西就不需要寫那么細。我們能寫到的程度，如下表所示：
第二步：危害分析和風(fēng)險評估(HARA) HARA主要的工作包括： 1.確定功能失效，也即是:function-->malfunction 2.危害分析，也就是:malfunction-->Hazard 3.確定Hazard event 4.進行Risk anlysis, 確定ASIL等級 5.制定功能安全目標(biāo)(Safety goal) 6.確定功能安全需求(Functional safety requirements) 1. Function-->Malfunction 功能描述是一段整車層面的定性描述，功能失效并不是一個非0即1的過程，在做HARA分析時，首先要列出功能所有可能的失效形式。
比如某功能需求：產(chǎn)生并傳輸驅(qū)動扭矩到輪端驅(qū)動車輛，可能的失效模式列舉如下：
2. Malfunction-->Hazard 還是上面的例子，我們基于功能不同失效形式，確定整車層面產(chǎn)生的危害，需要特別注意的是這里的Hazard我們關(guān)注在Vehicle level。
3. 確定Hazard event Hazard event的確定順序是：
我們繼續(xù)上面的例子，確定Hazard event
4. Risk analysis,確定ASIL等級 危害和對應(yīng)的運行場景，構(gòu)成了危害事件，接下來要對危害事件的嚴(yán)重度(S), 場景暴露率(E)和交通參與者的控制能力(C)進行評分，得到每個危害事件的ASIL等級。 在分析嚴(yán)重度(S)，危害產(chǎn)生的后果針對對象是交通參與者，也就是行人、駕駛員或者乘客，而非零部件的損壞。S值的計算，來源于ISO26262的法規(guī)，如下表所示。
其中AIS等級來源于汽車事故醫(yī)學(xué)高級協(xié)會(Association for the Advancement of Automotive Medicine)。AIS分為7個等級：
在分析場景暴露率(E)的時候，也是對著ISO26262標(biāo)準(zhǔn)來的，但是這里作了不同額區(qū)分：使用基于“持續(xù)時間”和基于“頻率”的暴露率分級。也就是說在計算E值時，要參考2個不同的表格。但是但是，我是實在分不清什么時候參考表B.2,什么時候參考表B.3，知道的同學(xué)可以私信我 表B.2 基于運行場景持續(xù)時間的暴露概率分解
表B.3 基于運行場景頻率的暴露率分級 在分析可控性(C)的時候, 參考表B.4計算C值
在確定了S,E,C三個參數(shù)的值后，會計算危害時間的ASIL等級，ASIL等級計算方法比較簡單： S+E+C<7, QM level S+E+C=7, ASIL A level S+E+C=8, ASIL B level S+E+C=9, ASIL C level S+E+C=10, ASIL D level 4. 制定功能安全目標(biāo)(Safety goal) Safety goal怎么確定，Safety state是什么樣子的，也是非常重要的步驟。不同ASIL等級的Safety goal會有對應(yīng)的功能安全需求，舉個簡單的例子：做過電控的人都聽說過監(jiān)控(Monitoring)。ISO2626里面對監(jiān)控的邏輯也是有不同的要求，低ASIL等級可能只需要做Range check, 更高ASIL等級的監(jiān)控還要實現(xiàn)合理性校驗等邏輯。具體實現(xiàn)方法可以參考ISO2626第5章附錄D。功能安全Monitoring的邏輯，我們后面會寫專題深入分析，也期待自己可以理解到位。
Safety goal后面還有功能安全需求，技術(shù)安全需求以及軟硬件分配的技術(shù)安全需求文檔。每個文檔都比較難寫，需要對車輛運動、功能軟件、硬件電路非常熟悉才可以，剛買了《單片機原理》和《模擬電路》等參考書，靠你們了 本期篇幅有點長，我們下期繼續(xù)... |
|
|
