電子電氣架構(gòu)的正向開發(fā)流程

國外的OEM在多年的Know-how積累下，其在規(guī)劃新一代電子電氣架構(gòu)平臺時，基本完全按照正向的流程來開發(fā)，例如VW的MEB E3架構(gòu)，Volvo的SPA2等，伴隨其正向電子電氣架構(gòu)開發(fā)的需要，誕生了強(qiáng)大的工具供應(yīng)商，比如Vector的PREEvision，其囊括了電子電氣開發(fā)的整個流程，從需求分析、邏輯功能架構(gòu)、軟件架構(gòu)、硬件架構(gòu)到電氣原理設(shè)計、線束原理設(shè)計、幾何拓?fù)湓O(shè)計以及線束2D圖紙設(shè)計，同時包含通訊設(shè)計、功能安全開發(fā)、變形管理等，提供了電子電氣開發(fā)的集成平臺，需求工程師、功能工程師、軟件工程師，通信工程師、架構(gòu)工程師、電氣工程師、功能安全工程師可以在這個平臺彼此協(xié)作開發(fā)，數(shù)據(jù)無縫傳遞，每個專業(yè)的輸入可通過上游設(shè)計的輸出數(shù)據(jù)重構(gòu)生成，數(shù)據(jù)可在全流程追溯，在應(yīng)對目前電子電氣的復(fù)雜性上確實具有領(lǐng)先性。

下面以PREEvision為例來簡單介紹下電子電氣架構(gòu)的正向開發(fā)流程是什么樣的：

1、需求工程和需求管理

在電子電氣架構(gòu)開發(fā)的概念階段，我們需要明確開發(fā)的目標(biāo)及范圍，需要收集客戶對車輛的功能需求、法規(guī)需求以及其他非功能需求，在這個階段涉及兩個重要的概念：

lCustomer Feature：在高層級描述車輛的特征，通常是客戶可以感知的功能，比如自動空調(diào)，自動啟停，自動泊車、自適應(yīng)巡航等，

lRequirements:需求Requirement 是對Customer Feature的進(jìn)一步細(xì)化，包括功能需求，技術(shù)需求（工作溫度范圍等），法規(guī)需求（排放法規(guī)等）；

同時可以將Requirement和Customer Feature進(jìn)行映射關(guān)聯(lián)，從而實現(xiàn)追溯，另外Customer Feature和Requirement在向下映射過程也是有差別的，Customer Feature通常和邏輯架構(gòu)層（Logical Function Architecture）的元素(Activity Chain)進(jìn)行映射,而Requirement通常和軟件架構(gòu)層（Software Architecture）的元素以及硬件架構(gòu)層（Harware Architecture）的元素進(jìn)行映射。

2、邏輯功能架構(gòu)（Logical Function Archtecture）

邏輯功能架構(gòu)設(shè)計階段，就是根據(jù)需求階段定義的Customer Feature，為每一個Feature設(shè)計功能的實現(xiàn)邏輯，設(shè)計的Activity Chain提供了一個功能的抽象視圖，只從功能實現(xiàn)的角度劃分Sensor（Input）、Logical Function(Process)、Actuator（Output），并不關(guān)心具體的軟件實現(xiàn)、以及硬件實現(xiàn)，在該階段設(shè)計完成的邏輯組件（Logical Component）會分配到硬件架構(gòu)中的組件（ECU、傳感器、執(zhí)行器等）以及軟件架構(gòu)中組件（Application Software Component等）。

3、軟件架構(gòu)（Software Architecture）

在汽車行業(yè)嵌入式軟件開發(fā)領(lǐng)域繞不開AUTOSAR（Automotive Open System Architecture）,其定義了一套分布式的、功能驅(qū)動的汽車電子軟件開發(fā)方法和電子控制單元上的軟件架構(gòu)標(biāo)準(zhǔn)方案，AUTOSAR的核心思想“統(tǒng)一標(biāo)準(zhǔn)、分散實現(xiàn)、集成配置”，即提供統(tǒng)一、開放的軟件架構(gòu)標(biāo)準(zhǔn)和平臺，軟件構(gòu)建在不同的汽車平臺上復(fù)用，應(yīng)用軟件整合到ECU 中，建立獨立于硬件的、分層的軟件架構(gòu)，針對AUTOSAR Classic的系統(tǒng)和軟件架構(gòu)設(shè)計在PREEvision中可以分為如下步驟：

同時，在目前SDV趨勢下，PREEvision同時支持面向服務(wù)的架構(gòu)設(shè)計（SOA）以及Adaptive AutoSAR系統(tǒng)和軟架構(gòu)設(shè)計，并提供SOA&Ethernet Explorer（Classic Platform）和Adaptive AutoSAR Explorer（Adaptive Platform）支持新的設(shè)計需求。

4、硬件架構(gòu)（Hardware Architecture）

硬件架構(gòu)的設(shè)計分為三層：硬件組件（Hardware components）和網(wǎng)絡(luò)拓?fù)洌∟etwork topology），電氣原理和線束原理，

l硬件組件（Hardware Component）架構(gòu)，設(shè)計硬件組件（例如ECU、傳感器、執(zhí)行器）之間的硬線連接，包括硬線信號（PWM、高低電平等），總線連接（CANFD/CAN/LIN等），以及電源連接和接地連接，另外也設(shè)計ECU內(nèi)部的細(xì)節(jié)，比如MCU、SBC、RAM等；

l網(wǎng)絡(luò)拓?fù)洌∟etwork Topology）

l電氣原理（Electric Circuit）,電氣原理層將硬件架構(gòu)層的數(shù)據(jù)進(jìn)行重構(gòu)，重新定義硬件組件之間的連接，并關(guān)注與線束設(shè)計相關(guān)的電氣屬性，例如電源供應(yīng)、接地連接等，其可設(shè)計電源分配的保險、繼電器以及接地分配電路。

l線束原理（Wiring Harness）將電氣原理數(shù)據(jù)進(jìn)行細(xì)化，將邏輯連接轉(zhuǎn)換為導(dǎo)線，同時添加導(dǎo)線之間的焊接點（Splice），內(nèi)部連接器（Inline），端子（Terminal），線束端連接器（Female Connector）,

5、幾何拓?fù)洌℅eometric Topology）

幾何拓?fù)鋵邮钦囯娖鞯?.5D布局視圖，其可以通過將3D CAD工具（Dassault Catia等）設(shè)計完成的3D線束通過KBL格式導(dǎo)入，展平為2D視圖，表達(dá)各電器的安裝位置，線束分段，然后將線束原理層中各組件映射到幾何拓?fù)鋵樱瑥亩M(jìn)行導(dǎo)線的路由規(guī)劃，從而為最終的架構(gòu)評估提供線束的長度、重量等數(shù)據(jù)支撐。

6、線束設(shè)計（Harness Design）

將幾何拓?fù)渲型瓿蓪?dǎo)線路由的線束總成，在Wire Harness Diagram中進(jìn)行數(shù)據(jù)重構(gòu)，同時添加卡扣、膠帶以及其他固定件、防護(hù)件，可生成線束2D圖紙，指導(dǎo)線束供應(yīng)商進(jìn)行線束的工藝轉(zhuǎn)化，然后進(jìn)行線束的生產(chǎn)和制造。

7、通訊設(shè)計（Communication）

在完成軟件組件到硬件的Mapping后，可進(jìn)行信號的路由，并進(jìn)行網(wǎng)絡(luò)通訊設(shè)計，PREEvision提供了多種通信設(shè)計編輯器來應(yīng)對同步的通信類型，比如CAN Bus Editor,LIN Scheduling Editor,FlexRay Schedulling 和Ethernet Explorer。

上述基于模型的系統(tǒng)工程方法（MBSE）同時可導(dǎo)出文檔，作為供應(yīng)商開發(fā)的輸入，比如可導(dǎo)出ECU的軟件需求規(guī)范SWRS（Software Requirement Specification）用于指導(dǎo)供應(yīng)商進(jìn)行軟件設(shè)計，導(dǎo)出ARXML文件用于供應(yīng)商生成應(yīng)用層軟件框架代碼，生成DBC/LDF文件用于總線仿真及測試等。

國內(nèi)OEM的電子電氣架構(gòu)開發(fā)過程

而國內(nèi)OEM通常采用基于文檔的電子電氣架構(gòu)的開發(fā)流程，基于模型的正向開發(fā)流程通常很難真正的實施下去的，因為在過去幾十年分布式架構(gòu)下形成的OEM、Tier1的產(chǎn)業(yè)供應(yīng)鏈?zhǔn)呛芄袒模壳笆忻嫔宪囆痛钶d的ECU大部分都是由國外頭部Tier1在供應(yīng)，特別是在底盤、動力領(lǐng)域，ESP、Ibooster、ECM這些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在這些零部件巨頭手里，國內(nèi)OEM的電子電氣架構(gòu)團(tuán)隊自己的積累太少，并不能在此領(lǐng)域提出足夠支配供應(yīng)商的需求，另外這些供應(yīng)商開發(fā)的零部件基本是平臺化的，相同的零件應(yīng)用在多家主機(jī)廠的車型上，收發(fā)信號都是定義好OEM根據(jù)需求信號進(jìn)行匹配，因此我們的架構(gòu)團(tuán)隊寫的功能規(guī)范（子系統(tǒng)功能規(guī)范），迫于無奈要根據(jù)零部件實際的功能情況去更改適配，架構(gòu)輸出規(guī)范的作用更多的是梳理目前整車已有的功能，而不是去正向設(shè)計整車的功能，但是近些年我們國內(nèi)的OEM也在一直成長，并嘗試建立正向的電子電子電氣架構(gòu)開發(fā)流程：

l在需求階段進(jìn)行市場調(diào)研、法規(guī)標(biāo)準(zhǔn)分析、競品分析、新技術(shù)分析、基礎(chǔ)平臺分析，定義整車架構(gòu)目標(biāo)，輸出Function List，并針對每個功能編制功能需求規(guī)范FRS（Function Requirement Spefication）,進(jìn)行功能描述，場景定義，功能系統(tǒng)框圖設(shè)計等；

l在功能實現(xiàn)階段，把功能需求分解并分配給子系統(tǒng)設(shè)計團(tuán)隊（功能需求+子系統(tǒng)交互圖）；

l在子系統(tǒng)設(shè)計階段，輸出子系統(tǒng)需求描述SRD（System Requirement Description）

l在零部件設(shè)計階段輸出 零部件技術(shù)規(guī)范CTS（Component Technical Spefication）

通過上述規(guī)范的輸出，國內(nèi)OEM掌握的Know-how也越來越多，并在新一代電子電氣架構(gòu)中，逐漸掌握主動權(quán)，不管是Domain架構(gòu)還是Zonal架構(gòu)，要實現(xiàn)SOA是大家達(dá)成的共識，同時在新的面向服務(wù)的架構(gòu)中，主機(jī)廠要掌握車端、和云端可以提供的服務(wù)，并將服務(wù)開放給第三方應(yīng)用開發(fā)者，從而創(chuàng)建SOA的開發(fā)生態(tài)，因此作為主機(jī)廠的電子電氣架構(gòu)團(tuán)隊在新的SOA趨勢下，其作用顯得越來越重要，其要從整車功能需求來設(shè)計整車的服務(wù)，并將服務(wù)分配到不同的Domain，由不同Domain的應(yīng)用軟件開發(fā)團(tuán)隊來實現(xiàn)。

面向服務(wù)的電子電氣架構(gòu)開發(fā)方法

面向服務(wù)的架構(gòu)SOA（Service-Orientied Architecture）是一種軟件設(shè)計范式，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進(jìn)行拆分，并通過這些服務(wù)之間良好定義的接口和協(xié)議聯(lián)系起來，接口采用中立的方式進(jìn)行定義，他獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言，

這使得構(gòu)建在各種系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。

設(shè)計范式是設(shè)計解決方案邏輯的一種方法，在構(gòu)建分布式解決方案邏輯時，設(shè)計方法通過一種稱為“關(guān)注點分離”的軟件工程理論實現(xiàn)，簡而言之，這個理論說明，將更大的問題分解為一組較小的問題或關(guān)注點時，這個問題就能得到更有效的解決，這讓我們產(chǎn)生了將解決方案邏輯劃分為多個功能的想法，每個功能都旨在解決單一的關(guān)注點，相關(guān)功能可以分組為解決方案邏輯單元。分布式解決方案邏輯存在不同的設(shè)計范式，面向服務(wù)體現(xiàn)在：面向服務(wù)執(zhí)行關(guān)注點分離的方式以及如何塑造具有特定特性和支持特定目標(biāo)狀態(tài)解決方案邏輯的單個單元。從根本上說，面向服務(wù)將合適的解決方案邏輯單元整合為企業(yè)資源，其可以被設(shè)計為解決即時問題，同時對更大的問題保持不可知，這就為我們提供了不斷的機(jī)會來重新利用那些單元內(nèi)的功能并解決其他問題。

在面向服務(wù)持續(xù)應(yīng)用于軟件程序設(shè)計時，一系列戰(zhàn)略目標(biāo)和優(yōu)勢共同代表了我們所期望實現(xiàn)的目標(biāo)狀態(tài)，理解這些目標(biāo)和優(yōu)勢是非常有益的，因為它們可以為我們提供連續(xù)不斷的總體背景和理由，以維持我們長期面向服務(wù)的投入。

l增加本征互操作性:即增加數(shù)據(jù)共享，軟件程序的互操作性越高，其之間的信息交換越容易；

l增強(qiáng)聯(lián)合:即服務(wù)的聯(lián)合，軟件資源和應(yīng)用程序聯(lián)合在一起，同時保持其各自的自主性和自治性；

l增加供應(yīng)商的多元化選擇：即供應(yīng)商多元化能力，指組織必須選擇“最佳品種”的供應(yīng)商產(chǎn)品和技術(shù)創(chuàng)新；

l同步提升業(yè)務(wù)與技術(shù)領(lǐng)域：即應(yīng)用程序的設(shè)計和實現(xiàn)不僅要滿足初始業(yè)務(wù)需求，也應(yīng)滿足未來隨業(yè)務(wù)性質(zhì)和方向變化時的也業(yè)務(wù)需求；

l提高投資回報率：即衡量自動化解決方案投資回報率（ROI）是決定應(yīng)用程序或系統(tǒng)實際成本效益的關(guān)鍵因素；

l提高組織的業(yè)務(wù)敏捷性：即組織能夠?qū)ψ兓龀龇磻?yīng)的效率，以適應(yīng)行業(yè)變化并超越競爭對手；

l減少研發(fā)成本：即減少浪費和冗余，縮小規(guī)模和運營成本，減少與其治理和演進(jìn)相關(guān)開銷等。

1、面向服務(wù)的設(shè)計原則

(1)標(biāo)準(zhǔn)化服務(wù)合約原則

面向服務(wù)架構(gòu)體系中，服務(wù)通過一個服務(wù)合約來表達(dá)他們的目標(biāo)和能力，標(biāo)準(zhǔn)化服務(wù)合作設(shè)計原則是面向服務(wù)中最基本的原則之一，其本質(zhì)上是在設(shè)計一個服務(wù)的公開技術(shù)接口，或評估作為服務(wù)正式合約的一部分而發(fā)布的內(nèi)容特性和數(shù)量時，給予特殊考慮指導(dǎo)方法。

服務(wù)合約設(shè)計時，需要重點考慮服務(wù)能力的表達(dá)方式、數(shù)據(jù)類型和數(shù)據(jù)模型，以及服務(wù)策略、服務(wù)端點的一致性、可靠性和可治理性。

(2)服務(wù)松耦合原則

耦合是指兩個事務(wù)之間的關(guān)聯(lián)和聯(lián)系，這一原則主張在服務(wù)的邊界之內(nèi)和之外創(chuàng)建特定類型的關(guān)系時，要始終強(qiáng)調(diào)減少服務(wù)合約、服務(wù)實現(xiàn)和服務(wù)消費者之間的依賴關(guān)系（車載領(lǐng)域尤其需要關(guān)注感知、決策和執(zhí)行的耦合關(guān)系），在服務(wù)設(shè)計過程中存在各種數(shù)據(jù)類型的耦合關(guān)系，每一個都會影響合約的內(nèi)容和粒度，需要依靠原則指導(dǎo)和實際經(jīng)驗獲得一個適當(dāng)?shù)鸟詈霞墑e。

(3)服務(wù)抽象原則

這個原則強(qiáng)調(diào)盡量隱藏服務(wù)的更多細(xì)節(jié)，服務(wù)需要一致地抽象關(guān)于技術(shù)、邏輯和功能的相關(guān)信息，不會展現(xiàn)給外部世界（服務(wù)邏輯開發(fā)上之外的世界），屆時，服務(wù)合約需要抽象僅僅包含服務(wù)不要對外發(fā)布公開的信息，如必要的交互需求、約束和必須的服務(wù)元數(shù)據(jù)。

(4)服務(wù)可復(fù)用性原則

服務(wù)可復(fù)用性原則強(qiáng)調(diào)在無關(guān)的功能性上下文環(huán)境中，把服務(wù)定位為企業(yè)的資源，確保服務(wù)是無關(guān)單個應(yīng)用和業(yè)務(wù)流程，具有無關(guān)功能性和通用性，可以在無關(guān)服務(wù)環(huán)境中被定義，并且可以保證它們能促進(jìn)必要的復(fù)用環(huán)境，可以被多個消費者程序提供訪問。

(5)服務(wù)自治性原則

為了讓服務(wù)能夠持續(xù)可靠地提供服務(wù)能力，底層的方案邏輯要求對環(huán)境和資源進(jìn)行相當(dāng)程度的控制，這一原則涉及服務(wù)邏輯設(shè)計及服務(wù)實際實施環(huán)境的各類問題，合理利用可以增加服務(wù)的可靠性和行為的可預(yù)測性的設(shè)計特性，可以對其他設(shè)計原則在實際開發(fā)過程中的有效應(yīng)用提供足夠的支持。在車載領(lǐng)域，由于涉及不同安全等級和實時性要求，尤其要關(guān)注隔離級別和服務(wù)規(guī)范化，針對不同應(yīng)用領(lǐng)域一起可以達(dá)到各自適合程度的自治，對于經(jīng)常需要共享的可復(fù)用服務(wù)來說尤其重要。

(6)服務(wù)無狀態(tài)性原則

就服務(wù)而言，管理過多的狀態(tài)信息會導(dǎo)致服務(wù)可用性和伸縮性潛力的破壞，在理想情況下，服務(wù)只應(yīng)該在必要時保持狀態(tài)；

(7)服務(wù)可發(fā)現(xiàn)性原則

將服務(wù)定位為可服用資產(chǎn)時，若復(fù)用機(jī)會出現(xiàn)，服務(wù)可以被發(fā)現(xiàn)并理解。服務(wù)發(fā)現(xiàn)機(jī)制（SOME/IP-SD等）和服務(wù)自身的設(shè)計（尤其服務(wù)端點）都需要將服務(wù)的“交流質(zhì)量”和其自身能力考慮在內(nèi)。

(8)服務(wù)可組合性原則

面向服務(wù)的解決方案的復(fù)雜程度在持續(xù)增長，位于其下的服務(wù)組合配置的復(fù)雜度也在持續(xù)增長，車載領(lǐng)域也面臨同樣的問題，能夠有效組合服務(wù)能力是面向服務(wù)計算的一些基本目標(biāo)的關(guān)鍵要求，復(fù)雜的服務(wù)組合對服務(wù)設(shè)計提出了要求，服務(wù)有望作為有效的組合成員參與，無論他們是否需要立即加入組合。

2、面向服務(wù)的設(shè)計方法

在面向服務(wù)的架構(gòu)開發(fā)時，分析和設(shè)計服務(wù)架構(gòu)的過程是從客戶需求到SOA架構(gòu)產(chǎn)出的分析過程，相對于傳統(tǒng)汽車軟件開發(fā)采用的基于功能分解的面向過程分析方法，“用例驅(qū)動的開發(fā)方法”和“面向服務(wù)架構(gòu)的設(shè)計方法”是SOA軟件架構(gòu)開發(fā)的兩個主要特點。

（1）需求分析

用例（Use Case）驅(qū)動的開發(fā)方法指從用戶的角度而非開發(fā)人員的角度考慮功能需求和系統(tǒng)實現(xiàn)，重視從系統(tǒng)外部觀察對系統(tǒng)的使用，由用例驅(qū)動的開發(fā)活動，可建立需求和系統(tǒng)功能之間清晰的追溯關(guān)系，更好的應(yīng)對智能汽車產(chǎn)品需求的快速迭代更新。

（2）功能設(shè)計

在功能設(shè)計階段我們用產(chǎn)品能力（Product Capability）描述功能實現(xiàn)的邏輯，產(chǎn)品能力是連接功能設(shè)計和軟件設(shè)計的橋梁，在功能設(shè)計層面，借助UML動態(tài)圖（序列圖、活動圖、狀態(tài)機(jī)）運用產(chǎn)品能力PC描述每個UseCase的功能實現(xiàn)鏈路；在軟件架構(gòu)設(shè)計階段，通過將產(chǎn)品能力分配到不同的軟件模塊，從而明確各軟件模塊的職責(zé)范圍，作為軟件開發(fā)的輸入，同時各軟件模塊中的服務(wù)也根據(jù)PC描述的功能范圍來設(shè)計。

（3）軟件架構(gòu)設(shè)計

軟件分層

為了更好地管理依賴關(guān)系和構(gòu)建軟件架構(gòu)，應(yīng)該使用分層軟件架構(gòu)，對于SOA的應(yīng)用軟件架構(gòu)分層可采用如下原則:

a.分離HMI和核心應(yīng)用軟件

HMI行為比核心應(yīng)用功能更容易改變，因此，將核心應(yīng)用軟件和HMI之間的分離將使設(shè)計更容易更改，特別是在開發(fā)期間的后期更改，或在HMI適應(yīng)新產(chǎn)品時，此外，開發(fā)核心應(yīng)用軟件和HMI設(shè)計需要不同的的能力技能，分開時應(yīng)該更容易處理，基本的策略是將HMI功能與其他應(yīng)用軟件（功能）的核心部分分離，為了實現(xiàn)這一點，MVC(Model-View-Controller)模式需要被使用，這意味著核心應(yīng)用軟件不應(yīng)該意識到任何HMI，而是HMI應(yīng)該對模型做出反應(yīng)并呈現(xiàn)給用戶，用戶輸入由Controller處理，Controller解釋用戶的意圖并操作模型。

b.分離傳感器/執(zhí)行器軟件和應(yīng)用軟件

將硬件邏輯，例如傳感器和執(zhí)行器邏輯與應(yīng)用程序邏輯分開，以便能夠在中央系統(tǒng)中分配應(yīng)用程序，同時保持傳感器/執(zhí)行器盡可能的具體，這將促進(jìn)能夠在應(yīng)用程序之間使用SOA，及時傳感器和執(zhí)行器不支持，更容易將傳感器/執(zhí)行器作為現(xiàn)有組件來采購，從而降低價格；更容易處理中央系統(tǒng)的可變性；將戰(zhàn)略軟件與中央系統(tǒng)分開，以更好地控制，并在需要時更容易進(jìn)行內(nèi)部開發(fā)；此策略目的在于提高上層應(yīng)用軟件關(guān)鍵功能的復(fù)用性，將依賴硬件的功能與邏輯控制功能分離。

c.分離的設(shè)備抽象層

這一層包含了對設(shè)備的抽象，即設(shè)備代理（Device Proxy）和設(shè)備驅(qū)動程序（Device Driver）,這里的模塊將在需要時，對信號到服務(wù)之間進(jìn)行轉(zhuǎn)換，并處理設(shè)備層中的可變性，這一層不應(yīng)該包含任何車輛功能，只管理設(shè)備，在這一層的Device Driver不允許直接彼此通信，必須通過DP或車輛控制層，DP和DD可以使用一些平臺服務(wù)，如日志、診斷等；

d.分離平臺服務(wù)和主應(yīng)用軟件

與所有系統(tǒng)一樣，需要一些更偏向支持的功能，這是所有模塊都可以使用的公共服務(wù)，如日志記錄，資源管理等；

e.應(yīng)用軟件分為多層

即便我們已經(jīng)將HMI 、Platform Service、Sensor/actuator和Device Abstraction與核心應(yīng)用進(jìn)行分離，針對龐大的核心應(yīng)用功能的開發(fā)，對于開發(fā)部門來講還是很復(fù)雜的，為了促進(jìn)高效的開發(fā)工作，這個核心應(yīng)用功能需要以某種方式進(jìn)行分割，根據(jù)核心應(yīng)用功能軟件特點，公司組織結(jié)構(gòu)等，可根據(jù)需要將核心應(yīng)用功能軟件劃分為多個層次：

-車輛應(yīng)用層：這一層包含的軟件部件，對本車應(yīng)用負(fù)有總體責(zé)任，例如如何使用各種能源策略的定義，他們更像是應(yīng)用程序類型的SWC，使用其他層中的服務(wù)，而不向其他層提供服務(wù)接口；

-車輛協(xié)調(diào)層：這一層包含協(xié)調(diào)特定范圍內(nèi)（Domain內(nèi)）功能的軟件部件，例如協(xié)調(diào)不同類型的電氣能量的使用；

-車輛控制層：這一層包含控制功能范圍更有限的軟件部件，例如門窗控制，門鎖控制等，除分層外，核心應(yīng)用功能，或部分的核心應(yīng)用功能也可以根據(jù)開發(fā)組織進(jìn)行分離，例如：Connectivity，Energy,Motion，Control,Safety,Body和Infotainment，不同的企業(yè)可以采用不同的定義方案。

(4)服務(wù)設(shè)計

a.服務(wù)分層

l硬件抽象服務(wù)：基于ECUs功能和硬件外圍設(shè)備（傳感器/執(zhí)行器），定義硬件抽象服務(wù)，這些服務(wù)應(yīng)該在軟件平臺級別提供。

l平臺核心服務(wù)：所有跨應(yīng)用程序集群和域的公共服務(wù)都需要在軟件平臺級別定義和提供；

l域核心服務(wù)：在一個應(yīng)用集群中，跨不同應(yīng)用程序的公共服務(wù)應(yīng)定義為域核心服務(wù)，

l應(yīng)用程序服務(wù)：特定于系統(tǒng)的每個應(yīng)用程序或功能的服務(wù)，需要定義為應(yīng)用程序服務(wù)；

b.服務(wù)類型

根據(jù)服務(wù)提供功能的特點，可以分為基礎(chǔ)型服務(wù)與功能型服務(wù)，

l基礎(chǔ)型服務(wù)：提供與業(yè)務(wù)無關(guān)的通用系統(tǒng)服務(wù)能力，包括操作系統(tǒng)、基礎(chǔ)軟件、通用中間件提供的功能；

l功能型服務(wù)，提供具體業(yè)務(wù)功能相關(guān)的服務(wù)，包括與域控相關(guān)的專用中間件、應(yīng)用層提供的功能。

c.服務(wù)框架

Service Framework是對通用基礎(chǔ)軟件的擴(kuò)充，在基于不同種類的操作系統(tǒng)及基礎(chǔ)軟件平臺之上提供系統(tǒng)級服務(wù)調(diào)用及整車級功能設(shè)計視圖，其次對AutoSAR的服務(wù)管理框架進(jìn)行擴(kuò)展，向應(yīng)用層提供更多基于服務(wù)開發(fā)需要的功能，最后提供基于引擎的動態(tài)服務(wù)配置方法，基于預(yù)設(shè)的靜態(tài)服務(wù)，通過云端對靜態(tài)服務(wù)進(jìn)行編排，實現(xiàn)更加豐富的業(yè)務(wù)功能。

l原子服務(wù)：不可拆分的服務(wù)，一般為執(zhí)行單一操作的功能，不同功能節(jié)點可以提供針對業(yè)務(wù)的原子服務(wù)；

lSOA+：基于AutoSAR的服務(wù)框架擴(kuò)展，向應(yīng)用層提供更多基于服務(wù)開發(fā)需要的功能，其中包括服務(wù)轉(zhuǎn)換、服務(wù)調(diào)試、服務(wù)同步、服務(wù)權(quán)限管理和基于Andorid的SOA協(xié)議棧；

l系統(tǒng)基礎(chǔ)服務(wù)：系統(tǒng)可以提供的基礎(chǔ)服務(wù)，體現(xiàn)該系統(tǒng)可以提供的能力，需要依賴通用基礎(chǔ)軟件提供的功能，可以通過API或服務(wù)的形式提供給上層，針對不同異構(gòu)系統(tǒng)分別提供軟件包；

l整車級系統(tǒng)基礎(chǔ)服務(wù)：整車角度需要多個控制器協(xié)同實現(xiàn)的功能

l動態(tài)服務(wù)：基于原子服務(wù)及系統(tǒng)服務(wù)提供的功能進(jìn)行組合，實現(xiàn)服務(wù)的級聯(lián)，包括動態(tài)服務(wù)配置接口：提供給調(diào)用者實現(xiàn)動態(tài)服務(wù)的可配置接口；動態(tài)服務(wù)引擎，根據(jù)配置接口的輸入，執(zhí)行動態(tài)服務(wù)的核心功能。

d.服務(wù)定義

車載SOA軟件接口是服務(wù)提供者或使用者之間數(shù)據(jù)交換的定義，它定義了向使用者公開的服務(wù)的屬性、方法和事件等，服務(wù)定義定義服務(wù)之間的依賴關(guān)系，以及服務(wù)的接口（Require Interface Provide Interface）

(5)物理架構(gòu)設(shè)計

定義整車的網(wǎng)絡(luò)拓?fù)湟约坝布軜?gòu)類型（功能域架構(gòu)、中央計算單元+區(qū)域架構(gòu)），綜合各家OEM的下一代電子電氣架構(gòu)分析，車載計算單元+自動駕駛域控制器+智能座艙域控制器+區(qū)域控制器的架構(gòu)形態(tài)被大多數(shù)的OEM所采用。

(6)網(wǎng)絡(luò)通信設(shè)計

可在PREEvision中定義SOME/IP服務(wù)矩陣，設(shè)計Machine，SWC to Machine Mapping, Machine Deployment,Application Deployment,Servcie Instance Design,可導(dǎo)出Service Interface Description ARXML文件，該文件可以包含一個或多個服務(wù)接口的詳細(xì)信息，如Method/Event/Property以及對應(yīng)的數(shù)據(jù)類型等內(nèi)容。該文件可以將服務(wù)接口信息準(zhǔn)確的傳遞給其他工具，如DaVinci Adaptive IDE，用于生成服務(wù)接口的頭文件。

同時可導(dǎo)出Execution Manifest包含了Adaptive Application部署到目標(biāo)AUTOSAR Adaptive平臺上所需的信息，比如進(jìn)程啟動配置，進(jìn)程與Machine的映射等內(nèi)容，導(dǎo)出Machine Manifest包含Machine部署相關(guān)的信息，比如網(wǎng)絡(luò)配置信息，計算資源等，導(dǎo)出Service Instance Manifest包含基于服務(wù)的通信相關(guān)信息，如應(yīng)用層及相應(yīng)的傳輸層、網(wǎng)絡(luò)層通信參數(shù)信息。

(7)應(yīng)用層軟件開發(fā)

將PREEvision導(dǎo)出的SWC Description ARXML文件導(dǎo)入MatLab Simunlink 創(chuàng)建模型框架，配置服務(wù)發(fā)現(xiàn)機(jī)制，確認(rèn)AutoSAR屬性，生成代碼。

接下來需要利用基礎(chǔ)軟件供應(yīng)商提供的開發(fā)工具（例如DaVinCi Adaptive tool Suite）和AP中間件（例如MICROSAR）進(jìn)行集成、配置，詳細(xì)的過程我們后續(xù)再來探討。

以上簡單的描述了傳統(tǒng)電子電氣架構(gòu)的開發(fā)過程，以及在新一代SOA架構(gòu)中，我們采取的以用例驅(qū)動的，以服務(wù)設(shè)計為核心的電子電氣架構(gòu)開發(fā)流程，在新的架構(gòu)中需要探索新的適合每個OEM的開發(fā)方法，開發(fā)工具鏈以及與供應(yīng)商的合作方式（包括芯片供應(yīng)商、基礎(chǔ)軟件供應(yīng)商、零部件供應(yīng)商等），行業(yè)在變革，作為電子電氣架構(gòu)工程師的我們應(yīng)該直面困難和挫折，尋找一條清晰的發(fā)展道路。

審核編輯：郭婷