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

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

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