基于EnterpriseArchitect工具的电子电气架构MBSE设计流程

原创汽车电子与软件 2025-02-06 08:36 256浏览 0评论 0点赞

多物理场仿真在半导体制程中的应用 汽车用卸负载电阻低价方案

本文约4,400字，建议收藏阅读

作者 | 窦明佳

出品 | 汽车电子与软件

#01

概述

1.1 Harmony SE介绍

Harmony SE是系统工程在软件行业的最佳实践，它支持模型驱动开发的流程，在模型驱动开发中，模型是开发流程的核心成果，与分析和设计共存，每一个开发阶段由特定类型的模型支持，Harmony SE包括各个阶段的开发模型包括：

1) 需求模型

通过收集涉众需求，并将需求条目化、模型化，从而与下游的涉及建立关联；

2) 系统用例模型

把涉众需求以用例的方式组织在一起，但这些模型是不可执行的模型；

3) 系统功能分析

把功能需求解释成与系统功能（操纵）一致性的描述，每一个用例被解析成可执行的模型；

4) 架构分析模型

设计综合阶段的架构分析模型目的与权衡分析模型相关，如通过参数分析，针对所确定的操作实施方式，详细阐述系统架构概念；

5) 系统架构模型

系统架构模型是对前阶段的架构分析阶段所形成的系统架构，进行系统操作分配，系统架构模型的正确性和完整性是由模型执行来验证的，一旦模型被验证，架构设计则进入性能和安全性需求分析，该分析包括失效模式和影响分析（FMEA）。

模型驱动开发流程的必要元素是模型/需求存储库，它包含开发系统的知识配置信息，如需求文档、需求跟踪性信息，设计文档，测试定义。

1.2 汽车行业MBSE电子电气架构设计

参考Harmony SE在软件工程行业的最佳实践，在汽车行业电子电气架构设计过程中我们也可以采用基于模型的系统工程（MBSE）方法开展设计工作，逐步由基于文档的需求设计，需求传递、需求交互转变为基于模型，MBSE相对于基于文档的重要优势是其可以通过模型展现系统的不同视角，包括需求视角（Requirement View）、功能视角（Function View）、逻辑视角（Logical View）以及物理视角（Physical View/Tech View），这些视角提供了车辆电子电气架构的不同展现形式，同时这些视角不同元素之间的可追溯性能够让我们应对复杂系统的设计，并能够全面的进行变更影响分析，从而保证了设计的准确性、一致性并符合相关的标准和规范的要求，如ISO26262、ASPICE。

而Sparx System 公司的Enterprise Architect是一款通用的UML、SysML建模工具，其可以根据各行业的需求灵活定制自己的设计流程，可基于UML、SysML扩展模型元素类型及图形类型，以适应每个OEM自己定制化的电子电气架构设计流程。虽然其相对于汽车行业电子电气架构设计的专业工具（如PREEvision、SysWeaver）在某些方面存在些许不足，但是在功能易用性、成本、对UML/SysML支持程度等方面综合评估后其还是具有优势的，本文将基于Enterprise Architect 工具介绍一种电子电气架构设计的流程，并遵循MBSE方法构建整车电子电气架构的R-F-L-P视角。

#02

EA工具MDG Technology

在介绍基于EA工具电子电气架构的设计流程之前，我们先介绍下EA工具的MDG Technology，并介绍如何根据自己的EEA设计流程定制MDG Technoogy. Sparx Systems Enterprise Architect扩展可通过“Specialize”菜单“Technologies”中的“Manage Technology”进行查看，如下图所示EA工具本身已提供各行各业根据不同业务需求定制的MDG Technology，包括汽车行业的AUTOSAR设计工具LiberLieber AUTOSAR Engineeer，但是完全适用与电子电气架构设计的MDG Technology还需要自己定制。

2.1 创建视图

右键点击“Model”，选择”Model Builder”页面，在All Perspectives选择MDG Technology Builder-Basic Template，其目的是允许模型库管理员创建MDG Technology，包括扩展Element（Stereotype）Profile、Diagram Profile、Toolbox Profiles。

在模型栏介可以看到“Profile”、“Diagram Profile”、“Toolbox Profile”三个文件夹，其中“Profile”用来扩展元模型，“Diagram Profile”用来扩展视图类型，“Toolbox Profile”用来扩展工具栏。

2.2 扩展元模型

打开“Profile”文件夹，在工具栏“Profile Helpers”中选择“Add Stereotype”在视图中单击，然后在添加的stereotype上右键点击选择“Edit with Profile Helper，可定义Stereotype属性，包括名称、扩展类型、MetaType、Tagged Values等；在扩展类型中选择Element Extension点击Add Metacalss，若选择Class，则表明是基于 UML中的Class进行扩展。在Tagged Values页面右键可以选择“Add Specialized Tagged Value”并选择“Enumeration”，可以为扩展元素添加枚举类型的属性。

最后选择“Profile”文件夹。点击“Specialize”工具栏中的“Publish-Tech”，并选择“Publish Package as UML Profile”，将该Profile以XML格式保存在制定文件中，用于后面生成MDG Technology。

2.3 扩展工具箱

打开“ToolProfile”页面，在工具箱中选择“Add Toolbox Page”在页面中单击后出现对话框，可以填写工具箱的名称，备注，按键图形、并可选择Add Stereotype，选择2.2中扩展的元模型，这样就扩展好了工具栏的中的模型，同理在Add Toolbox Page选择Add Bulit-in type中的Connector可以扩展UML中元素的连接类型。最后选择“toolbox profile”视图页面。点击“Specialize”工具栏中的“Publish-Tech”，并选择“Publish Diagram as UML Profile”，将该Profile以XML格式保存在制定文件中，用于后面生成MDG Technology。

2.4 扩展视图

打开“Diagram Profile”在工具栏中选择“Add Diagram Extension”,在弹出的对话框中可以定义扩展图形的名称、扩展类型、描述等，在扩展类型中可以选择是基于UML中那些图形进行扩展，例如可基于Activity Diagram、Sequence Diagram定义功能设计的序列图活动图，可基于Class Diagram、Component Diagram扩展子系统逻辑架构图，可基于Deployment Diagram定义功能分配图或部署图等；最后选择“Diagram Profile”选择“Publish Diagram as UML Profile”并将扩展的视图以XML格式保存到相同的文件夹。

有了上述2.1到2.4我们获得了扩展元模型的profile，扩展视图的Profile以及扩张工具箱的Profile三个XML文件，然后点击Specialize-Publish-Tech-MDG technology-Generate MDG Technolog，可以将上述三个Profile文件生成为MDG technology并应用，最后点击“Specialize”菜单“Technologies”中的"Manage-Tech"。在对话框中点击"Advanced"，添加存储MDG文件的文件夹即可。在文件框中能够找到保存的MDG技术并勾选激活即可使用。

#03

基于EA工具的电子电气架构设计流程

电子电气架构的正向设计流程早已被大家所熟知，其基本遵循“关注点分离”的原则，将利益相关方的需求（Stakeholder Requirement）通过基于模型的系统工程MBSE方法进行逐步分解，并转化为具体技术领域的技术方案，并保证上下游的追溯，Funciton Owner、System Owner、 ECU Owner分别关注不同层级的设计工作，但是彼此又相互关联，同时都为了达成最初的利益相关方需求。其大致可以划分为以下设计活动：

1) 利益相关方需求收集：

包括企划商品定义书，Benchmark，High Level Function Safety Requirement，标准法规分析等，其中关键就是功能选型FDA，并整理确定功能开发的目标-Feature List；

2) 功能定义：

根据Feature List输入分域、分Feature Module确定对应的Function Owner，Feature Owner使用用例图等分析用户功能使用场景，明确利益相关方对Feature的需求，包括功能需求、性能需求等，从而形成整车级需求模型FDR；

3) 功能设计：

在功能设计阶段Function Owner根据上一步功能场景分析及整车级需求与子系统打合确定功能的实现方案，在这一步不同主机厂根据自身的情况存在差异，大致可分为以下几种方式：

a) 基于子系统接口的功能设计：即把子系统当作黑盒，只分析子系统之间应该有那些外部接口交互从而实现功能，对于主机厂有完善的架构设计流程及明确的System Owner职责的OEM，可以采用该方法，Function Owner只关注抽象层级的功能实现，不关注具体的技术实现方案，由SO承接FO分配的功能需求设计具体的子系统实现方案；

b) 面向服务的功能设计：此时通常把子系统划分为Module，Module代表了整车软件架构中的不同服务组，同时Module按照服务分层解耦的原则进行分层设计，每个Module提供不同的能力（Vehcile Capability）,功能设计基于VC进行设计，并表达服务之间C/S、P/S的交互方式，该方法通常适用于中央集中式架构，并采用面向服务的设计方法；

c) 面向ECU的功能设计：此时在功能设计时以ECU之间的信号交互表达功能的实现方案，此方法直接一步到底，虽然说减少了架构设计的工作量，同时与下游ECU实现端交互更直接，对功能实现各ECU的职责更明确，但是该方案通常适用于自下而上的架构设计，针对具体车型的设计可以采用该方案，但是无法保证功能架构与具体实现方案的解耦及复用。

d) 基于子系统逻辑组件的功能设计：此方法在功能设计时基于子系统的逻辑组件(Logical Component)进行功能实现方案设计，同步分析Logical Component的需求，在完全抽象的逻辑架构和具体的实现方案之间取得折中，该方法对于主机厂架构设计团队规模较小，Function Owner同步要承担System Owner角色的主机厂相对比较适用。

4) 子系统设计：

若采用上述第d基于子系统逻辑组件的功能设计方法，则子系统设计主要是合理设计子系统的逻辑组件（LC），子系统的逻辑组件应在整个架构平台中保持稳定，并根据功能需求进行适当的新增、更新工作，子系统的逻辑组件需要清晰的定义，包括LC名称、LC的描述、LC可提供的操作（Operation），从而使Function Owner在进行功能设计时可以不用费力就找到需要的LC，同时在子系统设计阶段需要设计子系统逻辑框图，包括Sensor、Actuator、Process对应的逻辑组件以及之间的信号交互。

5) ECU设计：

对于功能架构开发，通常是由EE Architect、Function Owner、System Owner进行打合后遵循功能分配的相关原则将逻辑组件分配到对应的ECU，形成ECU的功能需求规范CTS。

在进行上述架构设计过程遵循基于模型的系统工程MBSE方法，从而通过模型展现整个电子电气架构的不同视角，包括需求视角（Requirement View）、功能视角（Function View）、逻辑视角（Logical View）以及物理视角（Physical View）。

3.1 需求视角

虽然说MBSE注重通过模型来表达系统的设计方案，但是需求还是需要通过文字描述来传递，但是需求需要被条目化，转化为模型中的元素，可以与上下游建立追溯及连接。对于电子电气架构设计需求视角是最重要的，因为功能架构的设计过程就是分析需求及设计需求的工程，电子电气架构的需求视角如上所述，包括利益相关方需求、整车级需求、系统级需求、逻辑部件级需求、ECU级需求，通过上述第2部分的MDG Technology可以扩展元素的类型，并在EA工具中创建不同层级的需求，推荐使用EA –Specification Manager进行需求的创建及编辑，首先其类似与Word文档的视图，适应了传统架构设计人员采用Word编写需求的习惯，另外其可以基于需求模型导出文档（Word/PDF/HTML/CSV）适应下游专业对文档需求的接受程度。

3.2 功能视角

上述功能定义和功能设计的过程便是功能视角的呈现，首先通过用例图进行功能场景分析分析整车级的需求，并将用例与整车级需求关联，通过EA工具建立需求之间的追溯关系有多种方式，可以根据自己的习惯选择，重要的是建立Link关系，比如建立用例与整车级需求的关联，可以在UC右键点击选择Add-Construction Digaram选择Requirement Diagram，并将UC与Vehicel Requirement以Create Link的方式拖进需求图，建立UC和Vehicle Requirement的Realization关系即可。

功能设计通常采用序列图基于子系统逻辑组件设计功能的实现方案，同步分析功能对逻辑组件的需求，并创建逻辑组件需求与LC的追溯关系；功能设计过程通常涉及FO与SO的握手过程，从而保证功能设计与现有实现一致。

3.3 逻辑视角

逻辑视角建议在逻辑子系统中创建，类似创建我们所熟知的子系统框图，但是该子系统框图是以逻辑组件之间的交互来表达子系统逻辑组件之间的接口，例如悬架控制中传感器、执行器、逻辑处理单元之间的信号交互，从而展现了子系统的逻辑架构。

3.4 物理视角

物理视角又叫技术部件视角，通常以网络拓扑中具体的ECU视角描述ECU所承担的逻辑组件功能及对应的需求，在EA中物理视角的图形通常包括逻辑组件部署图、网络拓扑图等，以表达部署在ECU的逻辑组件，逻辑组件部署图呈现了ECU的功能分配，向上可以追溯ECU的功能需求，以及对应实现的功能。

#04

总结

本文介绍了基于模型系统工程的最佳实践Harmony SE，并介绍了Enterprise Architect工具MDG Technology，以此为基础介绍了汽车行业电子电气架构的流程，以及如何基于Enterprise Architect工具通过基于模型系统工程方法设计电子电气架构的R-F-L-P视角，上述方法需要在项目实践中不断完善及补充，但是基本涵盖了功能架构设计的所有业务流程，借此机会分享出来，并希望和基于EA工具开展电子电气架构设计感兴趣的同行一起交流。

添加微信，加入作者交流群