國(guó)外的OEM在多年的Know-how積累下，其在規(guī)劃新一代電子電氣架構(gòu)平臺(tái)時(shí)，基本完全按照正向的流程來開發(fā)，例如VW的MEB E3架構(gòu)，Volvo的SPA2等，伴隨其正向電子電氣架構(gòu)開發(fā)的需要，誕生了強(qiáng)大的工具供應(yīng)商，比如Vector的PREEvision，其囊括了電子電氣開發(fā)的整個(gè)流程，從需求分析、邏輯功能架構(gòu)、軟件架構(gòu)、硬件架構(gòu)到電氣原理設(shè)計(jì)、線束原理設(shè)計(jì)、幾何拓?fù)湓O(shè)計(jì)以及線束2D圖紙?jiān)O(shè)計(jì)，同時(shí)包含通訊設(shè)計(jì)、功能安全開發(fā)、變形管理等，提供了電子電氣開發(fā)的集成平臺(tái)，需求工程師、功能工程師、軟件工程師，通信工程師、架構(gòu)工程師、電氣工程師、功能安全工程師可以在這個(gè)平臺(tái)彼此協(xié)作開發(fā)，數(shù)據(jù)無縫傳遞，每個(gè)專業(yè)的輸入可通過上游設(shè)計(jì)的輸出數(shù)據(jù)重構(gòu)生成，數(shù)據(jù)可在全流程追溯，在應(yīng)對(duì)目前電子電氣的復(fù)雜性上確實(shí)具有領(lǐng)先性。
下面以PREEvision為例來簡(jiǎn)單介紹下電子電氣架構(gòu)的正向開發(fā)流程是什么樣的：
1、需求工程和需求管理
在電子電氣架構(gòu)開發(fā)的概念階段，我們需要明確開發(fā)的目標(biāo)及范圍，需要收集客戶對(duì)車輛的功能需求、法規(guī)需求以及其他非功能需求，在這個(gè)階段涉及兩個(gè)重要的概念：
lCustomer Feature：在高層級(jí)描述車輛的特征，通常是客戶可以感知的功能，比如自動(dòng)空調(diào)，自動(dòng)啟停，自動(dòng)泊車、自適應(yīng)巡航等，
lRequirements:需求Requirement 是對(duì)Customer Feature的進(jìn)一步細(xì)化，包括功能需求，技術(shù)需求（工作溫度范圍等），法規(guī)需求（排放法規(guī)等）；
同時(shí)可以將Requirement和Customer Feature進(jìn)行映射關(guān)聯(lián)，從而實(shí)現(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ì)階段，就是根據(jù)需求階段定義的Customer Feature，為每一個(gè)Feature設(shè)計(jì)功能的實(shí)現(xiàn)邏輯，設(shè)計(jì)的Activity Chain提供了一個(gè)功能的抽象視圖，只從功能實(shí)現(xiàn)的角度劃分Sensor（Input）、Logical Function(Process)、Actuator（Output），并不關(guān)心具體的軟件實(shí)現(xiàn)、以及硬件實(shí)現(xiàn)，在該階段設(shè)計(jì)完成的邏輯組件（Logical Component）會(huì)分配到硬件架構(gòu)中的組件（ECU、傳感器、執(zhí)行器等）以及軟件架構(gòu)中組件（Application Software Component等）。
3、軟件架構(gòu)（Software Architecture）
在汽車行業(yè)嵌入式軟件開發(fā)領(lǐng)域繞不開AUTOSAR（Automotive Open System Architecture）,其定義了一套分布式的、功能驅(qū)動(dòng)的汽車電子軟件開發(fā)方法和電子控制單元上的軟件架構(gòu)標(biāo)準(zhǔn)方案，AUTOSAR的核心思想“統(tǒng)一標(biāo)準(zhǔn)、分散實(shí)現(xiàn)、集成配置”，即提供統(tǒng)一、開放的軟件架構(gòu)標(biāo)準(zhǔn)和平臺(tái)，軟件構(gòu)建在不同的汽車平臺(tái)上復(fù)用，應(yīng)用軟件整合到ECU 中，建立獨(dú)立于硬件的、分層的軟件架構(gòu)，針對(duì)AUTOSAR Classic的系統(tǒng)和軟件架構(gòu)設(shè)計(jì)在PREEvision中可以分為如下步驟：
同時(shí)，在目前SDV趨勢(shì)下，PREEvision同時(shí)支持面向服務(wù)的架構(gòu)設(shè)計(jì)（SOA）以及Adaptive AutoSAR系統(tǒng)和軟架構(gòu)設(shè)計(jì)，并提供SOA&Ethernet Explorer（Classic Platform）和Adaptive AutoSAR Explorer（Adaptive Platform）支持新的設(shè)計(jì)需求。
4、硬件架構(gòu)（Hardware Architecture）
硬件架構(gòu)的設(shè)計(jì)分為三層：硬件組件（Hardware components）和網(wǎng)絡(luò)拓?fù)洌∟etwork topology），電氣原理和線束原理，
l硬件組件（Hardware Component）架構(gòu)，設(shè)計(jì)硬件組件（例如ECU、傳感器、執(zhí)行器）之間的硬線連接，包括硬線信號(hào)（PWM、高低電平等），總線連接（CANFD/CAN/LIN等），以及電源連接和接地連接，另外也設(shè)計(jì)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è)計(jì)相關(guān)的電氣屬性，例如電源供應(yīng)、接地連接等，其可設(shè)計(jì)電源分配的保險(xiǎn)、繼電器以及接地分配電路。
l線束原理（Wiring Harness）將電氣原理數(shù)據(jù)進(jìn)行細(xì)化，將邏輯連接轉(zhuǎn)換為導(dǎo)線，同時(shí)添加導(dǎo)線之間的焊接點(diǎn)（Splice），內(nèi)部連接器（Inline），端子（Terminal），線束端連接器（Female Connector）,
5、幾何拓?fù)洌℅eometric Topology）
幾何拓?fù)鋵邮钦囯娖鞯?.5D布局視圖，其可以通過將3D CAD工具（Dassault Catia等）設(shè)計(jì)完成的3D線束通過KBL格式導(dǎo)入，展平為2D視圖，表達(dá)各電器的安裝位置，線束分段，然后將線束原理層中各組件映射到幾何拓?fù)鋵樱瑥亩M(jìn)行導(dǎo)線的路由規(guī)劃，從而為最終的架構(gòu)評(píng)估提供線束的長(zhǎng)度、重量等數(shù)據(jù)支撐。
6、線束設(shè)計(jì)（Harness Design）
將幾何拓?fù)渲型瓿蓪?dǎo)線路由的線束總成，在Wire Harness Diagram中進(jìn)行數(shù)據(jù)重構(gòu)，同時(shí)添加卡扣、膠帶以及其他固定件、防護(hù)件，可生成線束2D圖紙，指導(dǎo)線束供應(yīng)商進(jìn)行線束的工藝轉(zhuǎn)化，然后進(jìn)行線束的生產(chǎn)和制造。
7、通訊設(shè)計(jì)（Communication）
在完成軟件組件到硬件的Mapping后，可進(jìn)行信號(hào)的路由，并進(jìn)行網(wǎng)絡(luò)通訊設(shè)計(jì)，PREEvision提供了多種通信設(shè)計(jì)編輯器來應(yīng)對(duì)同步的通信類型，比如CAN Bus Editor,LIN Scheduling Editor,FlexRay Schedulling 和Ethernet Explorer。
上述基于模型的系統(tǒng)工程方法（MBSE）同時(shí)可導(dǎo)出文檔，作為供應(yīng)商開發(fā)的輸入，比如可導(dǎo)出ECU的軟件需求規(guī)范SWRS（Software Requirement Specification）用于指導(dǎo)供應(yīng)商進(jìn)行軟件設(shè)計(jì)，導(dǎo)出ARXML文件用于供應(yīng)商生成應(yīng)用層軟件框架代碼，生成DBC/LDF文件用于總線仿真及測(cè)試等。
而國(guó)內(nèi)OEM通常采用基于文檔的電子電氣架構(gòu)的開發(fā)流程，基于模型的正向開發(fā)流程通常很難真正的實(shí)施下去的，因?yàn)樵谶^去幾十年分布式架構(gòu)下形成的OEM、Tier1的產(chǎn)業(yè)供應(yīng)鏈?zhǔn)呛芄袒?，目前市面上車型搭載的ECU大部分都是由國(guó)外頭部Tier1在供應(yīng)，特別是在底盤、動(dòng)力領(lǐng)域，ESP、Ibooster、ECM這些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在這些零部件巨頭手里，國(guó)內(nèi)OEM的電子電氣架構(gòu)團(tuán)隊(duì)自己的積累太少，并不能在此領(lǐng)域提出足夠支配供應(yīng)商的需求，另外這些供應(yīng)商開發(fā)的零部件基本是平臺(tái)化的，相同的零件應(yīng)用在多家主機(jī)廠的車型上，收發(fā)信號(hào)都是定義好OEM根據(jù)需求信號(hào)進(jìn)行匹配，因此我們的架構(gòu)團(tuán)隊(duì)寫的功能規(guī)范（子系統(tǒng)功能規(guī)范），迫于無奈要根據(jù)零部件實(shí)際的功能情況去更改適配，架構(gòu)輸出規(guī)范的作用更多的是梳理目前整車已有的功能，而不是去正向設(shè)計(jì)整車的功能，但是近些年我們國(guó)內(nèi)的OEM也在一直成長(zhǎng)，并嘗試建立正向的電子電子電氣架構(gòu)開發(fā)流程：
l在需求階段進(jìn)行市場(chǎng)調(diào)研、法規(guī)標(biāo)準(zhǔn)分析、競(jìng)品分析、新技術(shù)分析、基礎(chǔ)平臺(tái)分析，定義整車架構(gòu)目標(biāo)，輸出Function List，并針對(duì)每個(gè)功能編制功能需求規(guī)范FRS（Function Requirement Spefication）,進(jìn)行功能描述，場(chǎng)景定義，功能系統(tǒng)框圖設(shè)計(jì)等；
l在功能實(shí)現(xiàn)階段，把功能需求分解并分配給子系統(tǒng)設(shè)計(jì)團(tuán)隊(duì)（功能需求+子系統(tǒng)交互圖）；
l在子系統(tǒng)設(shè)計(jì)階段，輸出子系統(tǒng)需求描述SRD（System Requirement Description）
l在零部件設(shè)計(jì)階段輸出 零部件技術(shù)規(guī)范CTS（Component Technical Spefication）
通過上述規(guī)范的輸出，國(guó)內(nèi)OEM掌握的Know-how也越來越多，并在新一代電子電氣架構(gòu)中，逐漸掌握主動(dòng)權(quán)，不管是Domain架構(gòu)還是Zonal架構(gòu)，要實(shí)現(xiàn)SOA是大家達(dá)成的共識(shí)，同時(shí)在新的面向服務(wù)的架構(gòu)中，主機(jī)廠要掌握車端、和云端可以提供的服務(wù)，并將服務(wù)開放給第三方應(yīng)用開發(fā)者，從而創(chuàng)建SOA的開發(fā)生態(tài)，因此作為主機(jī)廠的電子電氣架構(gòu)團(tuán)隊(duì)在新的SOA趨勢(shì)下，其作用顯得越來越重要，其要從整車功能需求來設(shè)計(jì)整車的服務(wù)，并將服務(wù)分配到不同的Domain，由不同Domain的應(yīng)用軟件開發(fā)團(tuán)隊(duì)來實(shí)現(xiàn)。
面向服務(wù)的架構(gòu)SOA（Service-Orientied Architecture）是一種軟件設(shè)計(jì)范式，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進(jìn)行拆分，并通過這些服務(wù)之間良好定義的接口和協(xié)議聯(lián)系起來，接口采用中立的方式進(jìn)行定義，他獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語言，
這使得構(gòu)建在各種系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。
設(shè)計(jì)范式是設(shè)計(jì)解決方案邏輯的一種方法，在構(gòu)建分布式解決方案邏輯時(shí)，設(shè)計(jì)方法通過一種稱為“關(guān)注點(diǎn)分離”的軟件工程理論實(shí)現(xiàn)，簡(jiǎn)而言之，這個(gè)理論說明，將更大的問題分解為一組較小的問題或關(guān)注點(diǎn)時(shí)，這個(gè)問題就能得到更有效的解決，這讓我們產(chǎn)生了將解決方案邏輯劃分為多個(gè)功能的想法，每個(gè)功能都旨在解決單一的關(guān)注點(diǎn)，相關(guān)功能可以分組為解決方案邏輯單元。分布式解決方案邏輯存在不同的設(shè)計(jì)范式，面向服務(wù)體現(xiàn)在：面向服務(wù)執(zhí)行關(guān)注點(diǎn)分離的方式以及如何塑造具有特定特性和支持特定目標(biāo)狀態(tài)解決方案邏輯的單個(gè)單元。從根本上說，面向服務(wù)將合適的解決方案邏輯單元整合為企業(yè)資源，其可以被設(shè)計(jì)為解決即時(shí)問題，同時(shí)對(duì)更大的問題保持不可知，這就為我們提供了不斷的機(jī)會(huì)來重新利用那些單元內(nèi)的功能并解決其他問題。
在面向服務(wù)持續(xù)應(yīng)用于軟件程序設(shè)計(jì)時(shí)，一系列戰(zhàn)略目標(biāo)和優(yōu)勢(shì)共同代表了我們所期望實(shí)現(xiàn)的目標(biāo)狀態(tài)，理解這些目標(biāo)和優(yōu)勢(shì)是非常有益的，因?yàn)樗鼈兛梢詾槲覀兲峁┻B續(xù)不斷的總體背景和理由，以維持我們長(zhǎng)期面向服務(wù)的投入。
l增加本征互操作性:即增加數(shù)據(jù)共享，軟件程序的互操作性越高，其之間的信息交換越容易；
l增強(qiáng)聯(lián)合:即服務(wù)的聯(lián)合，軟件資源和應(yīng)用程序聯(lián)合在一起，同時(shí)保持其各自的自主性和自治性；
l增加供應(yīng)商的多元化選擇：即供應(yīng)商多元化能力，指組織必須選擇“最佳品種”的供應(yīng)商產(chǎn)品和技術(shù)創(chuàng)新；
l同步提升業(yè)務(wù)與技術(shù)領(lǐng)域：即應(yīng)用程序的設(shè)計(jì)和實(shí)現(xiàn)不僅要滿足初始業(yè)務(wù)需求，也應(yīng)滿足未來隨業(yè)務(wù)性質(zhì)和方向變化時(shí)的也業(yè)務(wù)需求；
l提高投資回報(bào)率：即衡量自動(dòng)化解決方案投資回報(bào)率（ROI）是決定應(yīng)用程序或系統(tǒng)實(shí)際成本效益的關(guān)鍵因素；
l提高組織的業(yè)務(wù)敏捷性：即組織能夠?qū)ψ兓龀龇磻?yīng)的效率，以適應(yīng)行業(yè)變化并超越競(jìng)爭(zhēng)對(duì)手；
l減少研發(fā)成本：即減少浪費(fèi)和冗余，縮小規(guī)模和運(yùn)營(yíng)成本，減少與其治理和演進(jìn)相關(guān)開銷等。
面向服務(wù)架構(gòu)體系中，服務(wù)通過一個(gè)服務(wù)合約來表達(dá)他們的目標(biāo)和能力，標(biāo)準(zhǔn)化服務(wù)合作設(shè)計(jì)原則是面向服務(wù)中最基本的原則之一，其本質(zhì)上是在設(shè)計(jì)一個(gè)服務(wù)的公開技術(shù)接口，或評(píng)估作為服務(wù)正式合約的一部分而發(fā)布的內(nèi)容特性和數(shù)量時(shí)，給予特殊考慮指導(dǎo)方法。
服務(wù)合約設(shè)計(jì)時(shí)，需要重點(diǎn)考慮服務(wù)能力的表達(dá)方式、數(shù)據(jù)類型和數(shù)據(jù)模型，以及服務(wù)策略、服務(wù)端點(diǎn)的一致性、可靠性和可治理性。
(2)服務(wù)松耦合原則
耦合是指兩個(gè)事務(wù)之間的關(guān)聯(lián)和聯(lián)系，這一原則主張?jiān)诜?wù)的邊界之內(nèi)和之外創(chuàng)建特定類型的關(guān)系時(shí)，要始終強(qiáng)調(diào)減少服務(wù)合約、服務(wù)實(shí)現(xiàn)和服務(wù)消費(fèi)者之間的依賴關(guān)系（車載領(lǐng)域尤其需要關(guān)注感知、決策和執(zhí)行的耦合關(guān)系），在服務(wù)設(shè)計(jì)過程中存在各種數(shù)據(jù)類型的耦合關(guān)系，每一個(gè)都會(huì)影響合約的內(nèi)容和粒度，需要依靠原則指導(dǎo)和實(shí)際經(jīng)驗(yàn)獲得一個(gè)適當(dāng)?shù)鸟詈霞?jí)別。
(3)服務(wù)抽象原則
這個(gè)原則強(qiáng)調(diào)盡量隱藏服務(wù)的更多細(xì)節(jié)，服務(wù)需要一致地抽象關(guān)于技術(shù)、邏輯和功能的相關(guān)信息，不會(huì)展現(xiàn)給外部世界（服務(wù)邏輯開發(fā)上之外的世界），屆時(shí)，服務(wù)合約需要抽象僅僅包含服務(wù)不要對(duì)外發(fā)布公開的信息，如必要的交互需求、約束和必須的服務(wù)元數(shù)據(jù)。
(4)服務(wù)可復(fù)用性原則
服務(wù)可復(fù)用性原則強(qiáng)調(diào)在無關(guān)的功能性上下文環(huán)境中，把服務(wù)定位為企業(yè)的資源，確保服務(wù)是無關(guān)單個(gè)應(yīng)用和業(yè)務(wù)流程，具有無關(guān)功能性和通用性，可以在無關(guān)服務(wù)環(huán)境中被定義，并且可以保證它們能促進(jìn)必要的復(fù)用環(huán)境，可以被多個(gè)消費(fèi)者程序提供訪問。
(5)服務(wù)自治性原則
為了讓服務(wù)能夠持續(xù)可靠地提供服務(wù)能力，底層的方案邏輯要求對(duì)環(huán)境和資源進(jìn)行相當(dāng)程度的控制，這一原則涉及服務(wù)邏輯設(shè)計(jì)及服務(wù)實(shí)際實(shí)施環(huán)境的各類問題，合理利用可以增加服務(wù)的可靠性和行為的可預(yù)測(cè)性的設(shè)計(jì)特性，可以對(duì)其他設(shè)計(jì)原則在實(shí)際開發(fā)過程中的有效應(yīng)用提供足夠的支持。在車載領(lǐng)域，由于涉及不同安全等級(jí)和實(shí)時(shí)性要求，尤其要關(guān)注隔離級(jí)別和服務(wù)規(guī)范化，針對(duì)不同應(yīng)用領(lǐng)域一起可以達(dá)到各自適合程度的自治，對(duì)于經(jīng)常需要共享的可復(fù)用服務(wù)來說尤其重要。
(6)服務(wù)無狀態(tài)性原則
就服務(wù)而言，管理過多的狀態(tài)信息會(huì)導(dǎo)致服務(wù)可用性和伸縮性潛力的破壞，在理想情況下，服務(wù)只應(yīng)該在必要時(shí)保持狀態(tài)；
(7)服務(wù)可發(fā)現(xiàn)性原則
將服務(wù)定位為可服用資產(chǎn)時(shí)，若復(fù)用機(jī)會(huì)出現(xiàn)，服務(wù)可以被發(fā)現(xiàn)并理解。服務(wù)發(fā)現(xiàn)機(jī)制（SOME/IP-SD等）和服務(wù)自身的設(shè)計(jì)（尤其服務(wù)端點(diǎn)）都需要將服務(wù)的“交流質(zhì)量”和其自身能力考慮在內(nèi)。
(8)服務(wù)可組合性原則
面向服務(wù)的解決方案的復(fù)雜程度在持續(xù)增長(zhǎng)，位于其下的服務(wù)組合配置的復(fù)雜度也在持續(xù)增長(zhǎng)，車載領(lǐng)域也面臨同樣的問題，能夠有效組合服務(wù)能力是面向服務(wù)計(jì)算的一些基本目標(biāo)的關(guān)鍵要求，復(fù)雜的服務(wù)組合對(duì)服務(wù)設(shè)計(jì)提出了要求，服務(wù)有望作為有效的組合成員參與，無論他們是否需要立即加入組合。
在面向服務(wù)的架構(gòu)開發(fā)時(shí)，分析和設(shè)計(jì)服務(wù)架構(gòu)的過程是從客戶需求到SOA架構(gòu)產(chǎn)出的分析過程，相對(duì)于傳統(tǒng)汽車軟件開發(fā)采用的基于功能分解的面向過程分析方法，“用例驅(qū)動(dòng)的開發(fā)方法”和“面向服務(wù)架構(gòu)的設(shè)計(jì)方法”是SOA軟件架構(gòu)開發(fā)的兩個(gè)主要特點(diǎn)。
（1）需求分析
用例（Use Case）驅(qū)動(dòng)的開發(fā)方法指從用戶的角度而非開發(fā)人員的角度考慮功能需求和系統(tǒng)實(shí)現(xiàn)，重視從系統(tǒng)外部觀察對(duì)系統(tǒng)的使用，由用例驅(qū)動(dòng)的開發(fā)活動(dòng)，可建立需求和系統(tǒng)功能之間清晰的追溯關(guān)系，更好的應(yīng)對(duì)智能汽車產(chǎn)品需求的快速迭代更新。
（2）功能設(shè)計(jì)
在功能設(shè)計(jì)階段我們用產(chǎn)品能力（Product Capability）描述功能實(shí)現(xiàn)的邏輯，產(chǎn)品能力是連接功能設(shè)計(jì)和軟件設(shè)計(jì)的橋梁，在功能設(shè)計(jì)層面，借助UML動(dòng)態(tài)圖（序列圖、活動(dòng)圖、狀態(tài)機(jī)）運(yùn)用產(chǎn)品能力PC描述每個(gè)UseCase的功能實(shí)現(xiàn)鏈路；在軟件架構(gòu)設(shè)計(jì)階段，通過將產(chǎn)品能力分配到不同的軟件模塊，從而明確各軟件模塊的職責(zé)范圍，作為軟件開發(fā)的輸入，同時(shí)各軟件模塊中的服務(wù)也根據(jù)PC描述的功能范圍來設(shè)計(jì)。
（3）軟件架構(gòu)設(shè)計(jì)
軟件分層
為了更好地管理依賴關(guān)系和構(gòu)建軟件架構(gòu)，應(yīng)該使用分層軟件架構(gòu)，對(duì)于SOA的應(yīng)用軟件架構(gòu)分層可采用如下原則:
a.分離HMI和核心應(yīng)用軟件
HMI行為比核心應(yīng)用功能更容易改變，因此，將核心應(yīng)用軟件和HMI之間的分離將使設(shè)計(jì)更容易更改，特別是在開發(fā)期間的后期更改，或在HMI適應(yīng)新產(chǎn)品時(shí)，此外，開發(fā)核心應(yīng)用軟件和HMI設(shè)計(jì)需要不同的的能力技能，分開時(shí)應(yīng)該更容易處理，基本的策略是將HMI功能與其他應(yīng)用軟件（功能）的核心部分分離，為了實(shí)現(xiàn)這一點(diǎn)，MVC(Model-View-Controller)模式需要被使用，這意味著核心應(yīng)用軟件不應(yīng)該意識(shí)到任何HMI，而是HMI應(yīng)該對(duì)模型做出反應(yīng)并呈現(xiàn)給用戶，用戶輸入由Controller處理，Controller解釋用戶的意圖并操作模型。
b.分離傳感器/執(zhí)行器軟件和應(yīng)用軟件
將硬件邏輯，例如傳感器和執(zhí)行器邏輯與應(yīng)用程序邏輯分開，以便能夠在中央系統(tǒng)中分配應(yīng)用程序，同時(shí)保持傳感器/執(zhí)行器盡可能的具體，這將促進(jìn)能夠在應(yīng)用程序之間使用SOA，及時(shí)傳感器和執(zhí)行器不支持，更容易將傳感器/執(zhí)行器作為現(xiàn)有組件來采購(gòu)，從而降低價(jià)格；更容易處理中央系統(tǒng)的可變性；將戰(zhàn)略軟件與中央系統(tǒng)分開，以更好地控制，并在需要時(shí)更容易進(jìn)行內(nèi)部開發(fā)；此策略目的在于提高上層應(yīng)用軟件關(guān)鍵功能的復(fù)用性，將依賴硬件的功能與邏輯控制功能分離。
c.分離的設(shè)備抽象層
這一層包含了對(duì)設(shè)備的抽象，即設(shè)備代理（Device Proxy）和設(shè)備驅(qū)動(dòng)程序（Device Driver）,這里的模塊將在需要時(shí)，對(duì)信號(hào)到服務(wù)之間進(jìn)行轉(zhuǎn)換，并處理設(shè)備層中的可變性，這一層不應(yīng)該包含任何車輛功能，只管理設(shè)備，在這一層的Device Driver不允許直接彼此通信，必須通過DP或車輛控制層，DP和DD可以使用一些平臺(tái)服務(wù)，如日志、診斷等；
d.分離平臺(tái)服務(wù)和主應(yīng)用軟件
與所有系統(tǒng)一樣，需要一些更偏向支持的功能，這是所有模塊都可以使用的公共服務(wù)，如日志記錄，資源管理等；
e.應(yīng)用軟件分為多層
即便我們已經(jīng)將HMI 、Platform Service、Sensor/actuator和Device Abstraction與核心應(yīng)用進(jìn)行分離，針對(duì)龐大的核心應(yīng)用功能的開發(fā)，對(duì)于開發(fā)部門來講還是很復(fù)雜的，為了促進(jìn)高效的開發(fā)工作，這個(gè)核心應(yīng)用功能需要以某種方式進(jìn)行分割，根據(jù)核心應(yīng)用功能軟件特點(diǎn)，公司組織結(jié)構(gòu)等，可根據(jù)需要將核心應(yīng)用功能軟件劃分為多個(gè)層次：
-車輛應(yīng)用層：這一層包含的軟件部件，對(duì)本車應(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è)計(jì)
a.服務(wù)分層
l硬件抽象服務(wù)：基于ECUs功能和硬件外圍設(shè)備（傳感器/執(zhí)行器），定義硬件抽象服務(wù)，這些服務(wù)應(yīng)該在軟件平臺(tái)級(jí)別提供。
l平臺(tái)核心服務(wù)：所有跨應(yīng)用程序集群和域的公共服務(wù)都需要在軟件平臺(tái)級(jí)別定義和提供；
l域核心服務(wù)：在一個(gè)應(yīng)用集群中，跨不同應(yīng)用程序的公共服務(wù)應(yīng)定義為域核心服務(wù)，
l應(yīng)用程序服務(wù)：特定于系統(tǒng)的每個(gè)應(yīng)用程序或功能的服務(wù)，需要定義為應(yīng)用程序服務(wù)；
b.服務(wù)類型
根據(jù)服務(wù)提供功能的特點(diǎn)，可以分為基礎(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是對(duì)通用基礎(chǔ)軟件的擴(kuò)充，在基于不同種類的操作系統(tǒng)及基礎(chǔ)軟件平臺(tái)之上提供系統(tǒng)級(jí)服務(wù)調(diào)用及整車級(jí)功能設(shè)計(jì)視圖，其次對(duì)AutoSAR的服務(wù)管理框架進(jìn)行擴(kuò)展，向應(yīng)用層提供更多基于服務(wù)開發(fā)需要的功能，最后提供基于引擎的動(dòng)態(tài)服務(wù)配置方法，基于預(yù)設(shè)的靜態(tài)服務(wù)，通過云端對(duì)靜態(tài)服務(wù)進(jìn)行編排，實(shí)現(xiàn)更加豐富的業(yè)務(wù)功能。
l原子服務(wù)：不可拆分的服務(wù)，一般為執(zhí)行單一操作的功能，不同功能節(jié)點(diǎn)可以提供針對(duì)業(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ù)的形式提供給上層，針對(duì)不同異構(gòu)系統(tǒng)分別提供軟件包；
l整車級(jí)系統(tǒng)基礎(chǔ)服務(wù)：整車角度需要多個(gè)控制器協(xié)同實(shí)現(xiàn)的功能
l動(dòng)態(tài)服務(wù)：基于原子服務(wù)及系統(tǒng)服務(wù)提供的功能進(jìn)行組合，實(shí)現(xiàn)服務(wù)的級(jí)聯(lián)，包括動(dòng)態(tài)服務(wù)配置接口：提供給調(diào)用者實(shí)現(xiàn)動(dòng)態(tài)服務(wù)的可配置接口；動(dòng)態(tài)服務(wù)引擎，根據(jù)配置接口的輸入，執(zhí)行動(dòng)態(tài)服務(wù)的核心功能。
d.服務(wù)定義
車載SOA軟件接口是服務(wù)提供者或使用者之間數(shù)據(jù)交換的定義，它定義了向使用者公開的服務(wù)的屬性、方法和事件等，服務(wù)定義定義服務(wù)之間的依賴關(guān)系，以及服務(wù)的接口（Require Interface Provide Interface）
(5)物理架構(gòu)設(shè)計(jì)
定義整車的網(wǎng)絡(luò)拓?fù)湟约坝布軜?gòu)類型（功能域架構(gòu)、中央計(jì)算單元+區(qū)域架構(gòu)），綜合各家OEM的下一代電子電氣架構(gòu)分析，車載計(jì)算單元+自動(dòng)駕駛域控制器+智能座艙域控制器+區(qū)域控制器的架構(gòu)形態(tài)被大多數(shù)的OEM所采用。
(6)網(wǎng)絡(luò)通信設(shè)計(jì)
可在PREEvision中定義SOME/IP服務(wù)矩陣，設(shè)計(jì)Machine，SWC to Machine Mapping, Machine Deployment,Application Deployment,Servcie Instance Design,可導(dǎo)出Service Interface Description ARXML文件，該文件可以包含一個(gè)或多個(gè)服務(wù)接口的詳細(xì)信息，如Method/Event/Property以及對(duì)應(yīng)的數(shù)據(jù)類型等內(nèi)容。該文件可以將服務(wù)接口信息準(zhǔn)確的傳遞給其他工具，如DaVinci Adaptive IDE，用于生成服務(wù)接口的頭文件。
同時(shí)可導(dǎo)出Execution Manifest包含了Adaptive Application部署到目標(biāo)AUTOSAR Adaptive平臺(tái)上所需的信息，比如進(jìn)程啟動(dòng)配置，進(jìn)程與Machine的映射等內(nèi)容，導(dǎo)出Machine Manifest包含Machine部署相關(guān)的信息，比如網(wǎng)絡(luò)配置信息，計(jì)算資源等，導(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ù)再來探討。
以上簡(jiǎn)單的描述了傳統(tǒng)電子電氣架構(gòu)的開發(fā)過程，以及在新一代SOA架構(gòu)中，我們采取的以用例驅(qū)動(dòng)的，以服務(wù)設(shè)計(jì)為核心的電子電氣架構(gòu)開發(fā)流程，在新的架構(gòu)中需要探索新的適合每個(gè)OEM的開發(fā)方法，開發(fā)工具鏈以及與供應(yīng)商的合作方式（包括芯片供應(yīng)商、基礎(chǔ)軟件供應(yīng)商、零部件供應(yīng)商等），行業(yè)在變革，作為電子電氣架構(gòu)工程師的我們應(yīng)該直面困難和挫折，尋找一條清晰的發(fā)展道路。
聯(lián)系客服
