從ISO26262看缺失的系統(tǒng)設(shè)計

從ISO26262看缺失的系統(tǒng)設(shè)計（一）功能安全與系統(tǒng)設(shè)計翻開ISO26262Ed.1（2011）與ISO26262Ed.2（2018），當(dāng)中有些許顯著不同的地方。其中一處便是發(fā)生在系統(tǒng)開發(fā)階段的要求：第一版在安全合規(guī)交付物的產(chǎn)出中，要求輸出SystemDesignSpecification（系統(tǒng)設(shè)計規(guī)格）；第二版僅只是客氣的提及SystemArchitectureDesignSpecification（系統(tǒng)架構(gòu)設(shè)計規(guī)格）。為啥會有這樣的變化？這種變化又代表何事？首先，汽車業(yè)在經(jīng)過多年的系統(tǒng)工程方法論洗禮（如A-SPICE）及功能安全導(dǎo)入經(jīng)驗之后，多半已認(rèn)識到「安全」僅只是系統(tǒng)的一個屬性，盡管這個屬性在某些系統(tǒng)開發(fā)工作中被視為是最重要的屬性（下圖為筆者在迪拜參與自動駕駛研討會時，現(xiàn)場參與嘉賓投票的自動駕駛落地最重要關(guān)鍵要素為何：明確可見，安全的地位比技術(shù)亮點本身還高許多）。lhW林ufl炒I 軸甲■jufi IEWiJnott除了這個屬性，依照系統(tǒng)功能的不同，系統(tǒng)還要能照顧到其他許多屬性。諸如，當(dāng)我們談?wù)摰氖莿恿偝上嚓P(guān)系統(tǒng)時，「可靠性」與「舒適性」也是必須要照顧到的屬性；當(dāng)目標(biāo)是儀表顯示系統(tǒng)時，「直觀易理解」則是重要的系統(tǒng)屬性。既然安全始終就只是系統(tǒng)的一個屬性，我們在實施安全標(biāo)準(zhǔn)的時候，若把完整的系統(tǒng)設(shè)計及與其相關(guān)的系統(tǒng)設(shè)計規(guī)格定義成為符合安規(guī)的必要交付物，似乎就顯得小題大做與不知所謂何事。然而，系統(tǒng)的全貌及方方面面確實會跟安全特性之間有某種程度的耦合關(guān)系：一個HMI人機接口設(shè)計的不夠人性化，不只是難用而已，可能也會因為安全報警的不清楚而影響到安全性；AEB設(shè)計的強度階梯變化很舒適，但也可能造成面對危害事件時的響應(yīng)不及而降低安全性。為了能充分考慮安全是否已在系統(tǒng)中充分達成，基于系統(tǒng)設(shè)計的一些交互資訊反饋給安全團隊開發(fā)人員仍然是必要的，為此， ISO26262Ed.2(2018)做了一個還不錯的折衷方案：它把系統(tǒng)級別的交付物限縮到僅剩SystemArchitectureDesignSpecification- 系統(tǒng)架構(gòu)設(shè)計規(guī)格依筆者之見，系統(tǒng)架構(gòu)設(shè)計規(guī)格足夠反應(yīng)出相當(dāng)程度的「安全要素」與「非安全要素」間的依賴關(guān)系，對判定系統(tǒng)安全特性的達成程度有很大幫助。然而，對于未來的標(biāo)準(zhǔn)Ed.3;Ed.4......甚至更久遠(yuǎn)的未來，關(guān)于系統(tǒng)設(shè)計的交付物是否就會凍結(jié)在SystemArchitectureDesignSpecification-系統(tǒng)架構(gòu)設(shè)計規(guī)格？筆者認(rèn)為難說，因為時至今日，我們對于「何謂系統(tǒng)」的樣貌及理解詮釋方式都還在演進中，尤其對于復(fù)雜的系統(tǒng)更是如此：自動駕駛；高度自動化機器人；先進武器系統(tǒng)；大型航空載具 ?…等等，這些東西都不比20-30年前的車身控制系統(tǒng)；電動窗控制系統(tǒng)，簡簡單單地僅需一份SystemDesignSpecification就能總結(jié)。筆者過去曾參與過戰(zhàn)斗機開發(fā)團隊的技術(shù)討論，光談?wù)撓到y(tǒng)的功能層面，就有好幾種不同的規(guī)格：功能需求規(guī)格；功能分解規(guī)格；功能集成規(guī)格……系統(tǒng)是抽象的東西，但這部分抽象的東西談不清楚，直接進展到軟硬件的實體開發(fā)，多半會有以下幾種結(jié)果：對于復(fù)雜性不高的系統(tǒng)，由軟件或硬件團隊承擔(dān)一些更重的系統(tǒng)責(zé)任，最終還是能把產(chǎn)品開發(fā)完成。對于復(fù)雜性極高的產(chǎn)品，可能產(chǎn)品只能推進到樣件階段，離量產(chǎn)還很遙遠(yuǎn)?；蛘撸瑢τ趶?fù)雜性極高的產(chǎn)品，最終還是開發(fā)到足以量產(chǎn)的程度，但付出的代價很高：不斷的設(shè)計變更；改型；重測；規(guī)模巨大的樣件測試。開發(fā)周期很長，試誤成本也很高?；蛘?，產(chǎn)品根本就開發(fā)不出來，因為無法兜出合適的解決方案。（二）實際項目的薄弱環(huán)節(jié)因為筆者多年來參與功能安全產(chǎn)品開發(fā)項目之故，并且涉及到的系統(tǒng)級產(chǎn)品種類多元，覆蓋到了從車身域，底盤域，動力域，安全域到輔助或自動駕駛域的系統(tǒng)開發(fā)，對各公司平臺環(huán)境或各不同產(chǎn)品的系統(tǒng)設(shè)計狀況有著比較深刻的觀察與體認(rèn)，在這里分享一些筆者在項目上的總結(jié)。其實一個好的功能安全項目，需要開發(fā)團隊比較扎實的系統(tǒng)經(jīng)驗與基礎(chǔ)，這包含系統(tǒng)開發(fā)流程；與對產(chǎn)品本質(zhì)上的技術(shù)性理解。然而在筆者從事推動功能安全技術(shù)的10年時間，發(fā)現(xiàn)功能安全起到的作用剛好是反向的：它推動各制造商更加重視系統(tǒng)設(shè)計；正向開發(fā)，并且以邏輯演繹加上對產(chǎn)品的科學(xué)認(rèn)識與實際驗證結(jié)果來完成產(chǎn)品的定義與開發(fā)。也因此，A-SPICE順道成為了一個潮流，雖然這個標(biāo)準(zhǔn)是源于對軟件質(zhì)量的掌控，但它背后隱藏的是系統(tǒng)開發(fā)流程的思維。汽車業(yè)的諸多制造商在多年的功能安全， A-SPICE與AUTOSAR洗禮下，對系統(tǒng)流程的觀念其實已經(jīng)相對清楚，但對真正落實系統(tǒng)設(shè)計仍然有不少的技術(shù)障礙。舉例來說，筆者發(fā)現(xiàn)在經(jīng)手的諸多開發(fā)項目中，客戶團隊都會知道要設(shè)計階層化的需求架構(gòu)，層層從整車需求分解到相對應(yīng)的軟硬件需求。這種流程性認(rèn)識大家是有的，但對應(yīng)的工程體悟卻沒那么深刻：這造成需求定義上的阻礙感與推進不順暢。功能安全因為已經(jīng)變成業(yè)界關(guān)注的熱點主題，所以在系統(tǒng)開發(fā)項目上，安全需求的制定可以找到不少參照或資源，一些比較成熟的系統(tǒng)：如BMS；EPS；MCU……安全目標(biāo)或安全需求都相對比較一致。在這樣的背景下，制造商也不必太傷腦筋去導(dǎo)出需求。但真正要完成一個產(chǎn)品開發(fā)，系統(tǒng)設(shè)計過程中需要照顧的需求種類，遠(yuǎn)不止安全需求，在第一章中說到的其他產(chǎn)品屬性，也需要有相對應(yīng)的需求去規(guī)范約束或者定義設(shè)計。舉個簡單的例子，當(dāng)某整車廠總工提出一條非常高階的需求如開發(fā)一臺好開的車。這樣的需求就好似安全領(lǐng)域的安全目標(biāo)，是一切設(shè)計的起點，但功能安全方法論會要求我們基于安全目標(biāo)去導(dǎo)出后續(xù)一切層級的safetyconcept，覆蓋軟硬件的策略。但在安全以外的產(chǎn)品屬性，一樣可以有類似的系統(tǒng)設(shè)計方式去展開它的設(shè)計。當(dāng)我們做整車規(guī)劃，承接的需求是「開發(fā)一臺好開的車」時，系統(tǒng)設(shè)計的任務(wù)就是把這樣的抽象目標(biāo)落實成為一個系統(tǒng)方案，里面包含必要的機械；裝置；軟硬件特性……等等，這樣才算是完成了恰當(dāng)?shù)南到y(tǒng)設(shè)計。但這種強正向設(shè)計，對國內(nèi)很多客戶都是非常困難的過程。因為這樣的設(shè)計過程，沒有標(biāo)準(zhǔn)答案，是一整路的自我辯證自我推翻與自我迭代，然后收斂到一個大家都滿意的設(shè)計點上。這里面有幾點迷思供大家參考：越熱愛或依賴參考設(shè)計的人/組織，越難展開正向系統(tǒng)設(shè)計2.越怕在設(shè)計上犯錯的人/組織，也越難發(fā)動正向系統(tǒng)設(shè)計（三）系統(tǒng)設(shè)計的難點與必要性正向系統(tǒng)設(shè)計的一個自我辯證過程，大概會是用類似如下的方式展開。如果要開發(fā)一臺好開的車，我們大概得對以下問題提出觀點，想法與解決方案：這車是對誰而言好開？男人；女人；老人？怎樣的車會被認(rèn)知為好開的車？越省力的車？越不需要操控技巧越直觀的車？這車需要考慮自動駕駛輔助帶來的效應(yīng)跟影響嗎？如何對好開定KPI?轉(zhuǎn)向，制動，加速與HMI又各自占比怎樣的比重?經(jīng)過一連串的邊界定義；功能定義與性能定義，可能在規(guī)格上我們會收斂出一些結(jié)論與方向，如；轉(zhuǎn)向必須要軟，不能硬；轉(zhuǎn)向程度要與車速聯(lián)動；剎車行程不能太長 etc也是透過這樣逐步細(xì)化的過程，我們會推導(dǎo)出各個階層的系統(tǒng)需求甚至是最終的系統(tǒng)級解決方案。但也由此可見，系統(tǒng)設(shè)計的復(fù)雜性肯定很高，做不好很容易顧此失彼：如剎車行程不能太長來達到更高的駕駛可控性，但也有可能容易觸發(fā)過重的剎車沖突了SOTIF的安全問題。這就需要我們在系統(tǒng)設(shè)計過程中不斷以各種視角自我辯證推翻與迭代，最終讓設(shè)計能收斂到一個特定的點上。在這樣的辯證過程中，各個崗位的專家意見就變得相對重要，如果專家水平不夠以至于給出的意見是誤導(dǎo)或扭曲的，可能會造成系統(tǒng)設(shè)計的方向偏離：原本應(yīng)該是好開的車變成了硬核（hardcore）的車，銷量于是減少一半，并且公司還難以定位與追蹤銷量不及預(yù)期的原因。另外要做好系統(tǒng)設(shè)計的另外一個關(guān)鍵點，就在于有效視角的建立，并針對這些視角提出如「安全生命周期」一般的可操作模式。畢竟，一個好的系統(tǒng)應(yīng)該是平衡的，能經(jīng)得起各個視角的檢驗，并已充分考慮了各個視角的沖突及解決方案。說個極端一點的：「成本」肯定也是檢驗系統(tǒng)設(shè)計的一個視角，但若把成本這個視角抬升成眾多視角中最高的優(yōu)先級，我們恐怕只能坐出一臺賣得動但賣不久的車。或許 30年前的國內(nèi)汽車市場最重視這個視角，但今日恐怕行不通。如何設(shè)定這些視角，并平衡這些視角，也是公司整體競爭力的展現(xiàn)。這里也可以做個總結(jié)：系統(tǒng)設(shè)計就像是在下一局棋，有好的系統(tǒng)設(shè)計手法與能力，才有棋盤與套路可言。會的套路越多，手法越靈活，產(chǎn)品相對于市場也更有競爭力。甚至，對應(yīng)到未來軟件定義汽車的快速迭代世界時，系統(tǒng)設(shè)計的功力與優(yōu)化程度更是直接決定這間車企的命運與發(fā)展。（四）在V模型以外的世界根據(jù)我們的傳統(tǒng)認(rèn)知，掌握了V模型，就掌握了系統(tǒng)設(shè)計的主要精神。多年前，曾經(jīng)有客戶詢問筆者叫筆者簡單總結(jié)下V模型的思路到底是啥？記得當(dāng)時筆者回復(fù)的是：設(shè)計要自上而下，驗證要自下至上。這樣的思路很直觀，也相當(dāng)有益于復(fù)雜性管理。但就目前筆者的觀察，大部分客戶能夠妥善地實現(xiàn)自下至上的驗證，卻無法有效實現(xiàn)自上而下的設(shè)計，原因，我們在前幾章也已經(jīng)解釋過。

另外，對于系統(tǒng)設(shè)計的手法，不是僅有V模型一種，還有一些其他的可能性在筆者近期的項目中，發(fā)現(xiàn)越是到復(fù)雜系統(tǒng)的領(lǐng)域（如自動駕駛），系統(tǒng)設(shè)計就越發(fā)重要；但也更加難以百分之一百的自上至下完成開發(fā)。Requ^ements ValidationTestDesign ?-IntegrationTestIrnpipmentation*?UnitTest系統(tǒng)設(shè)計在復(fù)雜系統(tǒng)中之所以重要的原因，主要在于復(fù)雜系統(tǒng)需要能夠清楚描述情境；用例；系統(tǒng)運行環(huán)境；支撐系統(tǒng)在環(huán)境下運作的必要功能；性能……這些都要能夠談清楚，不然堆疊出來的軟硬件僅是無意義的浪費。舉例來說，人也是個系統(tǒng)，我們的硬件就是身體的各式器官；我們的軟件就是我們的思維能力經(jīng)驗知識等等讓我們能發(fā)揮功能的必要智能。我們?nèi)祟愡@樣的一個系統(tǒng)，也必須應(yīng)付處理許多復(fù)雜的情境與用例，但與一般復(fù)雜系統(tǒng)的差別在于，我們?nèi)祟愂且粋€自適應(yīng)系統(tǒng)：我們的軟件與硬件都可