基于Enterprise Architect工具的電子電氣架構(gòu)MBSE設計流程

一、概

述1.1HarmonySE介紹HarmonySE是系統(tǒng)工程在軟件行業(yè)的最佳實踐，它支持模型驅(qū)動開發(fā)的流程，在模型驅(qū)動開發(fā)中，模型是開發(fā)流程的核心成果，與分析和設計共存，每一個開發(fā)階段由特定類型的模型支持，HarmonySE包括各個階段的開發(fā)模型包括：1)需求模型通過收集涉眾需求，并將需求條目化、模型化，從而與下游的涉及建立關聯(lián)；2)系統(tǒng)用例模型把涉眾需求以用例的方式組織在一起，但這些模型是不可執(zhí)行的模型；3)系統(tǒng)功能分析把功能需求解釋成與系統(tǒng)功能（操縱）一致性的描述，每一個用例被解析成可執(zhí)行的模型；4)架構(gòu)分析模型設計綜合階段的架構(gòu)分析模型目的與權衡分析模型相關，如通過參數(shù)分析，針對所確定的操作實施方式，詳細闡述系統(tǒng)架構(gòu)概念；5)系統(tǒng)架構(gòu)模型系統(tǒng)架構(gòu)模型是對前階段的架構(gòu)分析階段所形成的系統(tǒng)架構(gòu)，進行系統(tǒng)操作分配，系統(tǒng)架構(gòu)模型的正確性和完整性是由模型執(zhí)行來驗證的，一旦模型被驗證，架構(gòu)設計則進入性能和安全性需求分析，該分析包括失效模式和影響分析（FMEA）。模型驅(qū)動開發(fā)流程的必要元素是模型/需求存儲庫，它包含開發(fā)系統(tǒng)的知識配置信息，如需求文檔、需求跟蹤性信息，設計文檔，測試定義。1.2汽車行業(yè)MBSE電子電氣架構(gòu)設計參考HarmonySE在軟件工程行業(yè)的最佳實踐，在汽車行業(yè)電子電氣架構(gòu)設計過程中我們也可以采用基于模型的系統(tǒng)工程（MBSE）方法開展設計工作，逐步由基于文檔的需求設計，需求傳遞、需求交互轉(zhuǎn)變?yōu)榛谀Ｐ?，MBSE相對于基于文檔的重要優(yōu)勢是其可以通過模型展現(xiàn)系統(tǒng)的不同視角，包括需求視角（RequirementView）、功能視角（FunctionView）、邏輯視角（LogicalView）以及物理視角（PhysicalView/TechView），這些視角提供了車輛電子電氣架構(gòu)的不同展現(xiàn)形式，同時這些視角不同元素之間的可追溯性能夠讓我們應對復雜系統(tǒng)的設計，并能夠全面的進行變更影響分析，從而保證了設計的準確性、一致性并符合相關的標準和規(guī)范的要求，如ISO26262、ASPICE。而SparxSystem公司的EnterpriseArchitect是一款通用的UML、SysML建模工具，其可以根據(jù)各行業(yè)的需求靈活定制自己的設計流程，可基于UML、SysML擴展模型元素類型及圖形類型，以適應每個OEM自己定制化的電子電氣架構(gòu)設計流程。雖然其相對于汽車行業(yè)電子電氣架構(gòu)設計的專業(yè)工具（如PREEvision、SysWeaver）在某些方面存在些許不足，但是在功能易用性、成本、對UML/SysML支持程度等方面綜合評估后其還是具有優(yōu)勢的，本文將基于EnterpriseArchitect工具介紹一種電子電氣架構(gòu)設計的流程，并遵循MBSE方法構(gòu)建整車電子電氣架構(gòu)的R-F-L-P視角。二、EA工具MDGTechnology在介紹基于EA工具電子電氣架構(gòu)的設計流程之前，我們先介紹下EA工具的MDGTechnology，并介紹如何根據(jù)自己的EEA設計流程定制MDGTechnoogy.SparxSystemsEnterpriseArchitect擴展可通過“Specialize”菜單“Technologies”中的“ManageTechnology”進行查看，如下圖所示EA工具本身已提供各行各業(yè)根據(jù)不同業(yè)務需求定制的MDGTechnology，包括汽車行業(yè)的AUTOSAR設計工具LiberLieberAUTOSAREngineeer，但是完全適用與電子電氣架構(gòu)設計的MDGTechnology還需要自己定制。

2.1創(chuàng)建視圖右鍵點擊“Model”，選擇”ModelBuilder”頁面，在AllPerspectives選擇MDGTechnologyBuilder-BasicTemplate，其目的是允許模型庫管理員創(chuàng)建MDGTechnology，包括擴展Element（Stereotype）Profile、DiagramProfile、ToolboxProfiles。在模型欄介可以看到“Profile”、“DiagramProfile”、“ToolboxProfile”三個文件夾，其中“Profile”用來擴展元模型，“DiagramProfile”用來擴展視圖類型，“ToolboxProfile”用來擴展工具欄。

2.2擴展元模型打開“Profile”文件夾，在工具欄“ProfileHelpers”中選擇“AddStereotype”在視圖中單擊，然后在添加的stereotype上右鍵點擊選擇“EditwithProfileHelper，可定義Stereotype屬性，包括名稱、擴展類型、MetaType、TaggedValues等；在擴展類型中選擇ElementExtension點擊AddMetacalss，若選擇Class，則表明是基于UML中的Class進行擴展。在TaggedValues頁面右鍵可以選擇“AddSpecializedTaggedValue”并選擇“Enumeration”，可以為擴展元素添加枚舉類型的屬性。最后選擇“Profile”文件夾。點擊“Specialize”工具欄中的“Publish-Tech”，并選擇“PublishPackageasUMLProfile”，將該Profile以XML格式保存在制定文件中，用于后面生成MDGTechnology。2.3擴展工具箱打開“ToolProfile”頁面，在工具箱中選擇“AddToolboxPage”在頁面中單擊后出現(xiàn)對話框，可以填寫工具箱的名稱，備注，按鍵圖形、并可選擇AddStereotype，選擇2.2中擴展的元模型，這樣就擴展好了工具欄的中的模型，同理在AddToolboxPage選擇AddBulit-intype中的Connector可以擴展UML中元素的連接類型。最后選擇“toolboxprofile”視圖頁面。點擊“Specialize”工具欄中的“Publish-Tech”，并選擇“PublishDiagramasUMLProfile”，將該Profile以XML格式保存在制定文件中，用于后面生成MDGTechnology。2.4擴展視圖打開“DiagramProfile”在工具欄中選擇“AddDiagramExtension”,在彈出的對話框中可以定義擴展圖形的名稱、擴展類型、描述等，在擴展類型中可以選擇是基于UML中那些圖形進行擴展，例如可基于ActivityDiagram、SequenceDiagram定義功能設計的序列圖活動圖，可基于ClassDiagram、ComponentDiagram擴展子系統(tǒng)邏輯架構(gòu)圖，可基于DeploymentDiagram定義功能分配圖或部署圖等；最后選擇“DiagramProfile”選擇“PublishDiagramasUMLProfile”并將擴展的視圖以XML格式保存到相同的文件夾。有了上述2.1到2.4我們獲得了擴展元模型的profile，擴展視圖的Profile以及擴張工具箱的Profile三個XML文件，然后點擊Specialize-Publish-Tech-MDGtechnology-GenerateMDGTechnolog，可以將上述三個Profile文件生成為MDGtechnology并應用，最后點擊“Specialize”菜單“Technologies”中的"Manage-Tech"。在對話框中點擊"Advanced"，添加存儲MDG文件的文件夾即可。在文件框中能夠找到保存的MDG技術并勾選激活即可使用。三、基于EA工具的電子電氣架構(gòu)設計流程電子電氣架構(gòu)的正向設計流程早已被大家所熟知，其基本遵循“關注點分離”的原則，將利益相關方的需求（StakeholderRequirement）通過基于模型的系統(tǒng)工程MBSE方法進行逐步分解，并轉(zhuǎn)化為具體技術領域的技術方案，并保證上下游的追溯，F(xiàn)uncitonOwner、SystemOwner、ECUOwner分別關注不同層級的設計工作，但是彼此又相互關聯(lián)，同時都為了達成最初的利益相關方需求。其大致可以劃分為以下設計活動：1)利益相關方需求收集：包括企劃商品定義書，Benchmark，HighLevelFunctionSafetyRequirement，標準法規(guī)分析等，其中關鍵就是功能選型FDA，并整理確定功能開發(fā)的目標-FeatureList；2)功能定義：根據(jù)FeatureList輸入分域、分Feature

Module確定對應的FunctionOwner，F(xiàn)eatureOwner使用用例圖等分析用戶功能使用場景，明確利益相關方對Feature的需求，包括功能需求、性能需求等，從而形成整車級需求模型FDR；3)功能設計：在功能設計階段FunctionOwner根據(jù)上一步功能場景分析及整車級需求與子系統(tǒng)打合確定功能的實現(xiàn)方案，在這一步不同主機廠根據(jù)自身的情況存在差異，大致可分為以下幾種方式：a)基于子系統(tǒng)接口的功能設計：即把子系統(tǒng)當作黑盒，只分析子系統(tǒng)之間應該有那些外部接口交互從而實現(xiàn)功能，對于主機廠有完善的架構(gòu)設計流程及明確的SystemOwner職責的OEM，可以采用該方法，F(xiàn)unctionOwner只關注抽象層級的功能實現(xiàn)，不關注具體的技術實現(xiàn)方案，由SO承接FO分配的功能需求設計具體的子系統(tǒng)實現(xiàn)方案；b)面向服務的功能設計：此時通常把子系統(tǒng)劃分為Module，Module代表了整車軟件架構(gòu)中的不同服務組，同時Module按照服務分層解耦的原則進行分層設計，每個Module提供不同的能力（VehcileCapability）,功能設計基于VC進行設計，并表達服務之間C/S、P/S的交互方式，該方法通常適用于中央集中式架構(gòu)，并采用面向服務的設計方法；c)面向ECU的功能設計：此時在功能設計時以ECU之間的信號交互表達功能的實現(xiàn)方案，此方法直接一步到底，雖然說減少了架構(gòu)設計的工作量，同時與下游ECU實現(xiàn)端交互更直接，對功能實現(xiàn)各ECU的職責更明確，但是該方案通常適用于自下而上的架構(gòu)設計，針對具體車型的設計可以采用該方案，但是無法保證功能架構(gòu)與具體實現(xiàn)方案的解耦及復用。d)基于子系統(tǒng)邏輯組件的功能設計：此方法在功能設計時基于子系統(tǒng)的邏輯組件(LogicalComponent)進行功能實現(xiàn)方案設計，同步分析LogicalComponent的需求，在完全抽象的邏輯架構(gòu)和具體的實現(xiàn)方案之間取得折中，該方法對于主機廠架構(gòu)設計團隊規(guī)模較小，F(xiàn)unctionOwner同步要承擔SystemOwner角色的主機廠相對比較適用。4)子系統(tǒng)設計：若采用上述第d基于子系統(tǒng)邏輯組件的功能設計方法，則子系統(tǒng)設計主要是合理設計子系統(tǒng)的邏輯組件（LC），子系統(tǒng)的邏輯組件應在整個架構(gòu)平臺中保持穩(wěn)定，并根據(jù)功能需求進行適當?shù)男略?、更新工作，子系統(tǒng)的邏輯組件需要清晰的定義，包括LC名稱、LC的描述、LC可提供的操作（Operation），從而使FunctionOwner在進行功能設計時可以不用費力就找到需要的LC，同時在子系統(tǒng)設計階段需要設計子系統(tǒng)邏輯框圖，包括Sensor、Actuator、Process對應的邏輯組件以及之間的信號交互。

5)ECU設計：對于功能架構(gòu)開發(fā)，通常是由EEArchitect、FunctionOwner、SystemOwner進行打合后遵循功能分配的相關原則將邏輯組件分配到對應的ECU，形成ECU的功能需求規(guī)范CTS。在進行上述架構(gòu)設計過程遵循基于模型的系統(tǒng)工程MBSE方法，從而通過模型展現(xiàn)整個電子電氣架構(gòu)的不同視角，包括需求視角（RequirementView）、功能視角（FunctionView）、邏輯視角（LogicalView）以及物理視角（PhysicalView）。

3.1需求視角雖然說MBSE注重通過模型來表達系統(tǒng)的設計方案，但是需求還是需要通過文字描述來傳遞，但是需求需要被條目化，轉(zhuǎn)化為模型中的元素，可以與上下游建立追溯及連接。對于電子電氣架構(gòu)設計需求視角是最重要的，因為功能架構(gòu)的設計過程就是分析需求及設計需求的工程，電子電氣架構(gòu)的需求視角如上所述，包括利益相關方需求、整車級需求、系統(tǒng)級需求、邏輯部件級需求、ECU級需求，通過上述第2部分的MDGTechnology可以擴展元素的類型，并在EA工具中創(chuàng)建不同層級的需求，推薦使用EA–SpecificationManager進行需求的創(chuàng)建及編輯，首先其類似與Word文檔的視圖，適應了傳統(tǒng)架構(gòu)設計人員采用Word編寫需求的習慣，另外其可以基于需求模型導出文檔（Word/PDF/HTML/CSV）適應下游專業(yè)對文檔需求的接受程度。

3.2功能視角上述功能定義和功能設計的過程便是功能視角的呈現(xiàn)，首先通過用例圖進行功能場景分析分析整車級的需求，并將用例與整車級需求關聯(lián)，通過EA工具建立需求之間的追溯關系有多種方式，可以根據(jù)自己的習慣選擇，重要的是建立Link關系，比如建立用例與整車級需求的關聯(lián)，可以在UC右鍵點擊選擇Add-ConstructionDigaram選擇RequirementDiagram，并將UC與VehicelRequirement以CreateLink的方式拖進需求圖，建立UC和VehicleReq