基于EA的电子电气架构功能设计探讨

【摘 要】 在软件定义汽车时代背景下，新一代的汽车电子电气架构（以下简称E/E 架构） 不断进化。物理拓扑上，控制器ECU 数量大幅减少，集中度提高，拓扑方式从分布式到域集中式，再到中央集成大脑逐步演进；功能开发思路上，从传统的以明确各ECU 之间交互为主体任务，实现功能为主线，切换到现在的以服务定义和ECU的软件接口设计为主体，穷尽硬件平台能力为主线，覆盖面更广，功能开发深度更深。传统的基于文档的功能设计方式，已不足以满足现阶段功能开发需求。本文结合项目实践案例，基于Enterprise Architect（以下简称：EA） 工具对SOA（Service Oriented Architecture，面向服务架构） 架构功能设计方法进行应用和探索。

随着汽车行业向智能化、 数字化和电动化发展， 现存大部分汽车的E/E架构由于ECU数量众多、 线束繁琐复杂、算力低和功能耦合度高等问题， 无法实现高级别自动驾驶和快速OTA （Over The Air， 空中下载技术） 升级， 从而无法满足人们对汽车的多样化需求。主要的挑战有高级别自动驾驶所要求的实时性和安全性高， 人工智能机器学习所需要的大数据量和高带宽需求， 还有满足未来多节点连接（比如车路协同、 云代驾等） 所带来的信息安全问题[1]。为更好地解决上述汽车行业挑战， E/E架构拓扑形式在不断演进， 新的通信方式和开发方法也从工业或IT领域引入， 给汽车行业提供了丰富的技术参考。

针对E/E架构功能开发方法， 其内容和开发思路也发生了变化。本文通过对比传统架构功能开发流程和SOA架构功能开发流程， 指出传统架构功能设计环节可能存在的不足， 结合具体项目实例， 提出一种基于EA的功能设计方法， 以满足架构功能开发过程中对功能设计的需求。

1 E/E架构功能开发介绍

1.1 E/E架构功能开发流程

参考AUTOSAR标准中关于方法论的文档描述， 围绕E/E架构功能开发主线， 可以将开发流程从上到下， 从虚到实， 分为4个层级的步骤：产品层、 虚拟功能层、 系统层、子系统层。

1） 产品层：主要定义整车层级的功能需求， 属于整车产品定义的范畴， 包含整车功能对标分析、 功能清单梳理、功能配置管理等。此部分内容不在本文讨论范畴。

2） 虚拟功能层：主要定义整车层级的功能交互关系，也就是本论文涉及的内容， 一般包含功能定义和功能实现设计两个部分。

3） 系统层：主要承接虚拟功能层的输出， 对功能实现涉及的逻辑模块进行分配， 定义ECU层级的交互关系， 包括ECU之间的连接拓扑关系、 功能交互时序、 ECU接口定义、 服务定义、 通信定义等。

4） 子系统层级：聚焦具体ECU， 对承接的功能逻辑模块进一步详细设计， 定义应用层软件架构， 软件组件SWC之间的接口交互、 服务接口设计、 SWC运行设计等。

E/E架构功能开发过程层级说明如图1所示。

图1 EE架构功能开发层级说明

图1中， 产品层级的整车功能分析主要任务为结合市场情况、 竞争对手分析、 公司战略、 终端用户需求和自身产品定位等信息， 对整车项目所需要实现的功能进行对标分析， 提炼出所需要实现的功能清单和配置信息， 输出给到E/E架构进行功能实现。

对于虚拟功能层的整车功能设计环节， 承接产品层级输出的功能清单， 对清单上的每一个功能进行定义， 拆分功能用例；功能实现层面， 对某一具体功能用例， 进行功能实现设计， 包括功能逻辑模块设计、 模块交互设计、 状态机等。

而系统层级和子系统层级设计， 则是依据上述功能设计环节的输出结果， 对其中的功能逻辑模块进行具体ECU或SWC的映射， 映射关系可以是一对一或多对一；对交互接口进行进一步详细细化， 区分ECU间或ECU内部接口，定义内外部接口的类型、 协议和数据类型。这一步做完后，即可提炼出对具体ECU的功能逻辑需求和接口需求， 用以指导Tier1的开发。

1.2 功能设计流程需求分析

由上述分析可知， 虚拟功能层所包含的功能设计位于产品分析和系统层设计之间， 是从整车层级过渡到ECU级的重要环节， 是功能实现过程中从虚到实的关键映射步骤，其需求一般包括以下内容。

1） 需要高效全面地转化需求。产品分析重在需求开发， 是以用户为中心， 服务于用户体验， 借用非工程化的语言描述其功能需求；系统设计重在工程实现， 考虑有限的成本和周期， 用工程化的方式导出Tier1的相应需求， 这就要求处于中间环节的功能设计过程具备简洁高效地将用户语言转化为工程语言的能力， 同时保证产品需求的实现完整性和可追溯性。

2） 功能设计广度和深度要求高。传统的E/E架构功能开发过程中， 功能设计到系统层即结束， 考虑不同ECU之间的交互设计即可；SOA理念下的E/E架构功能开发过程包括功能设计、 服务设计、 模块设计、 通信设计等[2]步骤， 功能设计需满足后续服务设计和模块设计的不同需求， 由于已经深入到子系统层级， 需要考虑的设计广度和深度大大提高。

3） 功能设计尽量做到可以复用。SOA理念的核心思想是追求解耦和复用， 以便达到快速应对需求变化， 快速迭代产品的目的。这种思想或理念理应贯穿整个架构开发流程。目前在基于SOA的E/E架构开发过程中， 系统层级和子系统层级的设计已经引入了面向服务的设计思想， 将每个服务设计为具体业务逻辑的封装， 具有明确定义的接口，并可被独立地实现[3]， 每个服务都是独立的单元， 具备自洽和重用的特性；功能设计环节亦是需要考虑， 利用已有的成熟功能设计， 快速迭代， 快速转化日益变化的产品需求，进而提高整个开发流程的效率。

2 传统E/E架构功能开发流程分析

传统E/E架构功能开发以已有的固定的功能清单作为输入， 基于ECU控制器， 以功能实现为主线， 最终输出相应的DBC/LIN文件和具体的ECU开发需求给到Tier1供应商， 用以指导Tier1供应商开发。其大致流程可见图2。

图2 传统E/E架构功能开发流程示意

由图2可以看出， 传统E/E架构功能开发流程主要涉及虚拟功能层和系统层的设计， 输入为固有的功能清单， 结合具体的功能， 对功能进行定义和实现设计， 考虑故障处理、 功能安全和HMI需求等， 最终输出针对每个ECU的开发需求和接口文件 （如DBC/LIN文件）。以上过程， 大多借用Excel和Word等工具来描述和传递过程中产生的需求， 包括不限于功能需求规范、 系统规范和ECU开发需求等文件。

而随着基于SOA的理念引入， 传统功能开发流程已不足以满足SOA追求的灵活性、 可拓展性和可复用性， 主要表现在以下几方面。

1） 深度和广度不够。深度方面， 传统功能开发流程仅定义到系统层级， 明确ECU与ECU之间的交互接口和要求即可， 不满足需要深入到子系统层级的要求；广度方面，仅对现阶段定义的功能输入进行了功能设计， 未考虑未来产品迭代中可能出现的场景和需求。

2） 灵活性不够， 可复用性差。上述功能开发流程中，一般采用多级文档的形式来拆解功能， 不同级别文档或同级别文档之间存在耦合关系。往往一个功能点的更新会同时带来多份文档的维护， 并且不同级别文档的更新责任归属于不同部门或组织， 这样就极大地增加了应对需求变化时的维护成本和沟通成本， 进而影响快速迭代效率。另外，横向来说， 这些文档主要根据当前项目、 当前功能清单和当前ECU拓扑形式进行功能设计， 针对性较强， 无法做到跨项目跨平台使用， 可复用性较差。

3 基于EA的SOA架构功能设计

不同于传统E/E架构功能开发， SOA架构功能开发的目的是穷尽硬件能力， 尽可能暴露更多服务， 同时降低软件耦合度。本文结合项目实践， 提出一种面向SOA架构的功能开发流程， 见图3。

图3 SOA架构功能开发流程示意

对比图2和图3可知， SOA架构功能开发思路和目标发生了重大变化， 不再是以实现具体功能为主要目标， 而是构建面向服务的软硬件平台， 通过当前已有的功能实现分析和硬件能力分析， 提取出该平台所能暴露出的最大能力，同时应用层软件尽量解耦， 固化SWC之间的接口， 再结合SOME/IP的通信方式， 可以实现功能的快速迭代和升级。

对于虚拟功能层所包含的功能设计环节， 其实际内容也发生了较大改变。功能定义部分， 从用户体验角度， 将功能拆分为一个个独立的功能用例 （Use Case， 以下简称UC）， 对每个UC进行属性分析， 定义其前置条件、 后置条件、 基本事件流、 可选事件流、 异常事件流等， 同时加上功能安全需求、 非功能需求、 HMI需求等内容。功能实现设计部分， 不再基于ECU进行实现分析， 而是定义实现某UC所需要的功能实体， 设计功能实体之间的交互时序关系， 同时结合活动图和状态机， 对功能的实现过程进一步验证， 以保证此环节输出的功能实体的必要性和整体性。这里的功能实体定义为一个虚拟的需求描述， 一般结构形式为过程 对象， 如提供车速， 是衔接功能与服务的重要概念。其创建原则一般包括高内聚， 低耦合， 具备完整单一责任。

下文结合项目实例对上述功能设计环节进行具体说明。

3.1 功能定义环节

本环节的主要任务是将用户需求转化为工程需求， 同时考虑功能安全、 性能要求等， 输出该功能所包含的UC集合， 一方面输入到功能UC库进行汇总， 以便后续新功能的定义进行复用；另一方面输入到下一环节， 进行后续的功能实现设计。

功能定义主要采用EA工具里的Use Case Diagram来进行功能UC的设计， EA是一款基于UML （Unified Modeling Language， 统一建模语言） 的可视化模型与设计工具， 提供了对软件系统的设计和构建、 业务流程建模和基于领域建模的支持。功能UC主要定义以下属性。

1） 描述：对本UC进行简单描述。

2） 前置条件：激活该UC所必须满足的前提条件。

3） 后置条件：描述UC执行后功能的状态。

4） 场景：是对UC激活期间一系列事件流的描述， 主要包含3种：①基本事件流——描述UC正常激活时的事件流；②可选事件流——描述与基本事件流不同的步骤， 但同样实现UC目标的事件流；③异常事件流——描述未能实现UC目标的异常事件流。图4为Use Case场景描述中不同事件流示意说明。

图4 Use Case场景描述中不同事件流示意说明

5） 需求描述：描述该UC涉及的需求， 包括功能安全需求、 非功能需求、 HMI需求等。

下面以FCW （Forward CollisionWarning， 前碰撞报警）功能为例， 说明功能定义的过程。

3.1.1 拆分UC

拆分UC是基于功能的使用场景分析， 将功能拆分为若干个用户可感知的、 独立的UC。按照此原则， 可将FCW功能拆分为以下7 个UC，如图5所示。

图5 FCW功能的UseCaseDiagram

3.1.2 定义UC

针对拆解的每个UC进行上文提到的属性定义， 包括描述、 前置条件、 后置条件、 场景和需求描述。下面以UC-02-006-07 activate FCW function 为例进行展示，图6中展示的是场景定义中涉及事件流的定义界面， 可以定义基本事件流、 可 选 事 件 流 （如有）、 异 常 事 件 流。另外， 在Requirements选项框中定义需求描述， 在Constraints选项框中定义前置条件和后置条件。

图6 UC属性定义界面示意

3.2 功能实现设计环节

上述功能定义环节结束后， 可以得到针对某个具体功能的UC集合。功能实现设计环节则承接每个UC， 对其实现环节所需要的功能实体进行分析。该过程一般分为以下3个步骤。

1） UC实现过程分析。此步骤主要针对每个独立的UC，进行粗略的实现过程分析。包括时间维度的工作流程、 仲裁环节和可能并发存在的行为描述， 并确定上述过程中涉及的信息。该步骤主要采用EA中的活动图来实现， 活动图是一种基于UML语言的动态行为图， 主要包括活动、 动作、仲裁节点、 分支与合并等元素。上述UC：UC-02-006-07 activateFCWfunction的活动图如图7所示。

图7 UC：activate FCW function活动图示意

2） UC实现时序设计。此步骤主要是对上述实现过程的详细展开， 将其中涉及到的信息、 流程和动作进行细化。首先明确该UC的触发或启动条件， 进而按照活动图定义的粗略时序， 分析实现每一步过程需要的功能实体， 创建新的或从功能实体库中选择已有的功能实体；其次， 根据实现过程， 定义功能实体之间的交互接口内容；最后根据时间顺序， 将整个过程表述完整， 同时考虑使用组合片段来定义特殊条件和并列过程。

该步骤主要采用EA中的时序图来实现， 时序图是一种基于UML语言的动态交互图， 它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作关系， 主要包含对象、 生命线、 消息、 组合片段等元素。本项目中， 对象即功能实体， 生命线即功能实体的参与时间线， 消息主要用到了同步消息和异步消息两种， 组合片段则采用Opt（选项）、 Alt （抉择） 和Par （并行） 来处理UC中可能存在的不同情况， 其中Opt表示一个可能发生或可能不发生的选项过程， Alt则类似于If-Else语句， 定义多个备选过程， Par表示并行发生过程。

图8为UC：activate FCW function所对应的时序图， 图中定义了7个功能实体， 定义了FCW功能激活时的实体间的信息交互关系， 采用Alt组合片段定义可能存在的两级激活报警。

图8 UC：activate FCW function时序图示意

3） 功能状态机设计。状态机是针对复杂功能存在多个稳定状态， 定义每个状态的进入动作、 执行动作和退出动作， 定义状态跳转条件和优先级明确各状态之间的切换关系， 达到说明该功能随着不同条件的变化改变状态的目的。本项目主要采用EA中的状态机图来定义FCW功能的状态机切换， 由于状态机在传统E/E架构功能开发中已得到广泛使用， 这里不做过多展开。

3.3 小结

通过以上4种形式的图形建模， 可以完成FCW功能从功能定义到功能实现的详细设计。将功能拆解为一个个独立的UC， 对每个UC进行独立的活动图和时序图设计， 导出实现该UC需要的功能实体和接口需求， 同时辅助以功能状态机， 对设计过程进行校验。一般来说， 一个功能对应多个UC和最多一个状态机图， 而一个UC对应一个时序图和一个活动图 （可选）。

4 总结

本文介绍了E/E架构功能开发流程， 提出SOA架构开发中功能设计环节的需求。通过对传统E/E架构功能开发中的功能设计环节分析， 指出存在的不足：不能满足开发的深度和广度， 同时灵活性和复用性差。基于项目经验提出一种基于EA的功能设计方法， 通过4个形式的图形建模， 深入到子系统层级， 为后续服务设计提供设计依据；同时设计2个库：UC库和功能实体库， 为之后的新功能设计提供复用基础。另外， 从使用工具角度来说， EA建模工具具备良好的可视化界面， 支持各类插件的二次开发和模型的Word形式导出， 结合后续环节的Word转Excel工具和Excel生成ARXML工具， 可以打通E/E架构开发全流程工具链。

参考文献：

[1] Philipp Obergfell，Stefan Kugele，Eric Sax. Model-Based Resource Analysis and Synthesis of Service-Oriented AutomotiveSoftware Architectures [C]//IEEE/ACM 22nd International Conference on Model Driven EngineeringLanguages and Systems（MODELS）2019.

[2] 华一丁，龚进峰，戎辉，等. 基于模型的智能汽车电子电气架构发展综述[J]. 汽车零部件，2019（2）：63-66.

[3] 刘佳熙，施思明，徐振敏，等. 面向服务架构汽车软件开发方法和实践[J]. 中国集成电路，2021，1（16）：83-84.

END