序章：基於V模型的電子電氣系統開發
概要
本部分內容主要是簡單介紹一下基於V模型開發流程的電子電氣系統開發。
引言
可能有人會問，這個專欄不是解讀ISO 26262功能安全標準的么，為什麼在第一章就開始跑題。
我們可以先把上面的這個問題放一放，來看一下ISO 26262中每章的Introduction部分都要提到的這部分內容：
我把其中重點的內容翻譯一下：
1. ISO 26262改編自IEC 61508系列標準，主要強調了對道路車輛電子或（和）電氣系統的需求；
2. 隨著科技複雜度、軟體內容和機電一體化的不斷提升，系統失效與隨機硬體失效的發生概率也隨之增加，而這些失效便是在功能安全的考慮範疇之內。
看到這裡，我想大家可能會形成一種模糊的認知，就是功能安全，或許和電子電氣系統有著某些聯繫，而具體是什麼聯繫呢，我們接著往下看：
上面是ISO 26262-1:2018中對功能安全的定義：
功能安全是為了消除由於電子電氣系統故障所導致的不合理的風險。
好了，現在我們都知道了，功能安全及其標準的存在，都服務於電子電氣系統。那麼，什麼又是電子電器系統呢？
電子電氣系統
在ISO 26262-1：2018中給出了這樣的解釋：
翻譯過來就是：
電氣或電子元素，包括可編程電子元素所組成的系統便是電子電氣系統。
而對於系統這個概念：
標準里的解釋為：至少包含一個感測器、控制器和執行器的一系列元件的組成。
那麼把這兩個結合起來就是：
由電子或電氣元素組成的，至少包含一套完整的控制元件的元素集合。
而對於汽車而言，整個汽車本身就是一個非常複雜的電子電氣系統，其中包含了大量的感測器、控制器以及執行器。而這套電子電氣系統的主要目的，則是為了實現各種功能，如加速減速（驅動相關）、音樂播放（娛樂相關）、自動泊車（智能駕駛相關）。
實際上，隨著人們對汽車舒適度，娛樂性以及智能性等需求的不斷增加，還有排放等法規標準的不斷嚴苛，汽車電子電氣系統也越發複雜。如果沒有一個完善合理的流程來支持電子電氣系統的開發，則很難保證系統開發的順利進行。
基於V模型的電子電氣系統開發流程
為了方便理解，我們來一次真正的「實戰演習」。
由於你在平日的工作中，工作十分努力，工作能力與經驗都十分出色，現在公司上層正式提拔任命你為新的項目總監，任務是針對目前市場中的空缺，用三年時間開發出一款全新的車型。
那麼，首先要做的事情，就是要找到這一部分空缺的市場。經過調研團隊一個多月的市場調研，發現目前市場上的確缺少一款：適合城市內短距離代步的、精緻、環保而且智能的純電微型車，主要面向年輕的城市白領，價格區間5-10萬左右。
現在大的方向已經確定了，接下來需要進一步明確車輛的各種屬性，例如：
1. 因為主要面向城區通行，續航能力不需要太高，結合成本考慮，續航在200-250km，百公里加速6s即可；
2. 因為主要面向城市白領人群，由於他們對精緻生活的追求，車內環境包括影音等方面的素質要相對高一些，例如採用高端品牌的音箱等；
3. 整車配備L3水平的智能駕駛；
…
上面所說的內容，基本上可以認為是一個簡易的屬性開發，例如提到的續航、加速和智能駕駛等級都可理解為整車屬性的一部分，屬性基本上是V模型開發的最上層部分。
現在我們假定屬性開發已經完成，屬性開發工程師把整車屬性需求劃分為不同的功能並交給了對應的功能開發工程師來進行進一步的開發。
隨之我們也轉變一下角色，變成一名功能開發工程師。
需要強調的是，我們這裡所指的功能，是面向消費者的整車層面的功能，而不是一個小的功能模塊（邏輯模塊）。例如大家熟悉的自適應巡航功能、自動泊車功能，都是整車層面的功能。
而作為一名功能開發工程師，其主要的任務便是：
1. 定義功能（WHAT）；
2. 設計功能實現（HOW）。
假設我們現在要開發一個自動雨刷的功能，那麼首先，我們就要定義這個功能是什麼（WHAT）:
1. 功能的目的是什麼（為了駕駛的便捷性）；
2. 功能的使用場景是哪些（陰雨天氣）；
3. 功能是怎麼樣作用的（自動檢測雨天並開啟對應等級雨刷）；
…
當我們完成了對功能的定義之後，就要考慮，怎麼去在整車上實現這個功能（HOW）:
1. 需要誰提供什麼樣的輸入信息（雨天檢測）；
2. 需要誰執行什麼樣的邏輯（面對不同的雨天，應自動開啟什麼樣的雨刷等級）；
3. 需要誰提供什麼樣的輸出信息（雨刷控制命令）；
…
上面提到的部分，便是一個簡易的功能開發介紹，一句話總結就是：
根據屬性的要求，完善並設計功能的定義與實現並將對應需求分配給不同的系統開發人員。
接下來我們就到了系統層級，這一層級相對抽象，因為從這一層級開始，我們就看不到整車層級的屬性和功能了，有的只是從功能開發人員那裡接來的各種功能需求。
這就好比某個人去五金店裡買了一個水龍頭和一些管路，作為五金店老闆，你是不可能根據顧客的水龍頭和管路訂單就推測出顧客的家裡是幾室幾廳，什麼樣的裝修風格等信息的。
我們可以把上面例子中的顧客，想像為功能開發工程師，顧客自己要決定整屋的風格（功能定義）以及裝修整屋所需要的所有材料（功能實現），並把所需內容（功能需求）按不同類別分採購。
而例子中的五金店老闆，便可視為一個系統工程師，主要任務便是滿足顧客對五金方面的原料採購需求（功能需求）。
除了五金之外，我們要裝修一套房屋，可能還需要去木材店、燈具店、電器店等店鋪採購以滿足裝修需求，而這些店鋪也可以理解其他為不同的系統。
為了方便理解，我再來舉個例子。在醫院中，我們有不同的科室，如神經、消化、呼吸等，根據不同的病情癥狀，我們需要去正確的科室才能把病看好。
相似地，我們也可以把一個汽車的所有模塊與組成，按照某種架構定義，劃分為不同的系統，如影音娛樂系統、驅動系統、排放系統、安全系統等。
根據上面的例子，我們可以把系統理解為：
一個虛擬的、具有較強專業性的一系列邏輯模塊的集合。
而其中的邏輯模塊，主要是這個系統所接收的各種功能需求的優化與整合。
這裡需要強調一點的是，這裡所謂的系統，與電子電氣系統中的系統，是兩個不一樣的概念，也處於不一樣的層級。
電子電氣系統中的系統，是一套或幾套控制單元的集合。當某個電子電氣系統較為複雜時，我們需要一套成熟可靠的開發流程來支持開發，V模型流程就是其中的一種，而碰巧的是在V模型開發流程中，我們也引入了一個系統的概念，但這個系統的主要目的是：
承接對應的功能需求，對功能需求進行優化與整合，最終以軟體需求的形式傳遞給對應的軟體開發人員。
在軟體開發這一層級，其最終的目的就是：
把對應的系統設計需求，轉化為某種軟體語言。
由於我對軟體開發也沒有過多的了解，在這裡就不展開了。
至此為止，我們V模型的左半邊就介紹完畢了：
現在我們再來從整體上看一下V流程的左半邊：
從屬性開發開始，按照 屬性-->功能-->系統-->軟體 的順序進行開發，環環相扣，層層遞進。
其中，屬性與功能開發都相對上層，可以理解為偏向整車層級的開發；而到了系統開發，則就進入了一個相對下層而專業的領域；至於軟體開發則更像是一種從文字語言到計算機語言的轉換。
當我們完成了從屬性到軟體的開發工作後，隨之而來要面臨的問題便是：
我們如何才能知道我們的軟體是否與系統需求一致？所有的功能需求是否可以被系統設計所覆蓋？整車功能是否可以實現？整車的屬性目標是否已經達到？
為了解決上面所面臨的問題，在V流程中，引入了V字的右半邊：測試驗證。
從上圖我們可以看到，每個階段的開發之後，都要有對應的測試驗證環節，來確認各個層級的設計是否已經被實現。
同樣由於篇幅與個人經驗方面的原因，這一部分就不再做展開，大家只需要明確一點：
測試驗證是電子電氣系統開發、優化、迭代過程中不可缺少的環節。
結尾
至此為止，基於V模型的電子電氣系統開發流程的簡單介紹就結束了，如果有什麼問題或者我說的不對的地方，歡迎大家留言給我。
另外，我這裡還有兩個問題，希望大家可以思考一下：
1. 為什麼我在介紹ISO 26262 之前要先介紹V模型的電子電氣開發流程？
2. 基於V模型的電子電氣開發流程，與ISO 26262中功能安全的開發流程之間，到底有著什麼樣的聯繫？
希望大家可以結合下面給出的兩個流程，對上面的問題展開思考。
推薦閱讀：