国内主机厂车身控制器功能开发通常使用文字来描述系统设计，各个功能之间的依赖关系不清晰，功能复用率不高。随着功能需求数量的增多，为提高各个功能的复用率，行业内提出面向服务的汽车架构（SOA）解决方案。挖掘SOA 架构设计方法论，总结岚图汽车SOA 平台车身控制域中氛围灯子系统设计开发实践经验，阐述使用企业构架（EA）软件完成汽车车身控制域系统设计，交付开发需求文档以及系统功能规范的方法，以达到提升设计效率，改善设计质量的目的。

0 引言

在国内主流整车企业完成车身控制系统或其相关子系统的设计工作时，通常采用Micro soft Visio 软件完成流程图的绘制并开展设计工作，使用Microsoft Word 进行人工编写功能规范或者子系统规范的文字说明，使用Auto CAD 工具辅助完成系统框图的设计。随着“域”概念的引入，相较于早期的汽车车身控制器产品功能的开发，车身域控制器不仅新的功能层出不穷[1]，而且功能与功能之间还存在交叉复用的情况。例如2010 年生产的一台豪华轿车具备800 个整车功能[2]，而在2007年整车功能只有270个[3]。例如中控屏控制车窗、语音控制车窗2个功能需求中，执行端（控制器驱动玻璃升降电机的部分）处理逻辑是一样的，这部分的逻辑就可以在不同车窗控制方式中复用。随着各个功能之间交叉复用的情况增多，在进行系统设计时，使用文字进行描述和辅助一些插图的方式，越来越难以梳理功能的链路以及功能之间的交互关系。

在当下软件定义汽车的时代[4]，汽车生产厂商依托架构方案进行造车，以控制成本，提高产品竞争力[5]，加快软件产品的迭代。例如大众汽车集团的电动车模块化平台（Modular Electrification Toolkit，MEB）构架，丰田汽车新全球架构平台（Toyota New Global Architecture，TGNA）和吉利汽车的浩瀚智能体验（Sustainable Experience Architecture，SEA）架构，都是当前国际上先进的面向服务化的汽车架构（Service-Oriented Architecture，SOA）。这些汽车构架具有粗粒度、松耦合的特征，服务之间通过定义简单、精确的接口进行通讯，其设计的基本原则主要有：

（1）标准化的服务契约；

（2）服务松耦合；

（3）服务的可重用性；

（4）服务自治[6]。

由此可以看出，在设计、输出车身控制系统或子系统对应的功能规范时，在新的架构方案下，系统设计人员还需要对服务接口进行标准化定义。

在新架构下，汽车车身域系统开发人员利用企业构架（Enterprise Architect，EA）软件完成车身域[7]的子系统设计、完成功能规范的编写和开发交付物，同时根据EA提供的应用程序接口（Application Program Interface，API）进行拓展功能开发的研究。EA是一款企业架构软件[8]，覆盖了系统开发的整个周期，除了开发类模型之外，还包括事务进程分析、使用案例需求、动态模型、组件和布局、系统管理、非功能需求、用户界面设计、测试和维护。EA使用者还可以利用EA中的基础元素，封装出一套满足使用需求的元素插件，所以选择使用EA进行车身控制域子系统的设计与开发研究，具有很高的灵活度和契合度。

1 模块化层级框架搭建

利用EA开展SOA架构下车身控制域子系统的设计工作，首先需使用EA 搭建子系统框架。为了避免相关的元素依赖关系不清晰，框架的搭建通常有2种方案。

（1）方案1 以某一车型平台为单位搭建服务器。服务器内使用唯一编号对功能进行标识，新增的功能需求按新的顺序进行编号，固化的功能需求不再改变编号，把此车型平台上所有功能需求汇集在一个服务器上，当开发不同车型时，根据功能需求进行拆分重组，完成车身域子系统的功能设计，输出功能规范和开发交付物。

（2）方案2 以项目为单位搭建服务器。每个服务器单独开发维护，此方案更适合有相同功能的不同车型，按不同用例需求进行定制开发。EA 架构开发环境的搭建可根据公司战略需求进行工程方案选择。

在工程内部需要对文档进行分层搭建，软件层级的划分是SOA架构中松耦合的实现方式，所以在搭建文档时，不仅要横向考虑开发流程的先后顺序，还需要纵向考虑软件的分层实现[9]。

使用EA 搭建模块化层级的框架，首先需建立功能需求文档，这是开展车身控制域子系统设计的基础，主要用于存放设计中的功能描述和功能用例流程图。在功能需求文档的子文档中，需要对功能进行模块化的划分，车身控制域就属于其中一个模块，整车的其他控制系统均可根据功能类别划分成不同的模块，功能需求文档建立后，将此文档派发给系统工程师进行处理和维护。

其次是建立其他需求文档。比如功能安全需求文档、系统性能需求文档，这部分内容可以派发给功能安全工程师和系统工程师进行搭建和维护。由功能安全工程师根据功能安全目标，指导软件开发；系统工程师根据性能需求，提出可量化、可实现的性能指标，比如系统的资源占用情况、响应时间要求。

最后，建立逻辑实现文档。逻辑实现文档包括纵向软件分层，每个域模块的层级分类会有不同，车身控制域从软件控制层、协调层、信号转换层、传感器与执行层以及物理层进行划分，此项可以先由系统工程师设计出相应的外部通信接口，再由软件开发人员根据开发需求定义内部接口。

基于上述描述，使用EA 搭建出了车身控制域系统设计框架，如图1所示。

图1 车身控制域系统设计框架

2 车身控制域子系统设计

在EA中按照以下流程开展车身控制域子系统的设计工作，系统的功能逻辑思路就能非常清晰地呈现出来，进行功能设计时就不会造成逻辑混乱和接口依赖不清晰、不明确的问题，客观上保证了设计开发的质量。

2.1 功能需求文档内容设计

功能需求文档的内容包括功能描述和功能用例流程。

2.1.1 分解功能需求完成功能描述

在获得车身控制域的系统功能需求后，应对其进行分解。把一项功能拆解成多条功能用例，在EA 中用案例（Use Case）元素进行表示，考虑支持实现这些功能用例的需求，每一条功能用例的前置条件、触发条件、执行方法或步骤，在执行动作过程中，有其他异常情况发生时所期望的执行结果，以及信息冲突的仲裁情况。这些设计中的信息均可用文字描述的形式放入Use Case 属性的不同条目下，以完成功能需求分解和定义。

2.1.2 绘制功能用例流程图

在此阶段，首先应根据整车的电子电器架构了解系统中各个单元的分布情况。以物理单元为基础，软件组件为载体，抽象出软件组件的产品能力（Product Capability，PC）。

在每一条功能用例流程图中拽入功能实现所需要的PC，并在其“特征”选项卡的“操作”（Operation）中建立具体的关联方法，此时就可绘制功能流程的传递过程，在此基础上加入功能定义中的判断条件，可完成功能用例流程图设计。

功能用例流程图的主要作用是梳理功能逻辑，分配功能任务。通过功能用例流程图，系统设计人员可以明确系统的依赖关系以及系统的逻辑、时序和步骤，各软件组件也能明确自身需要完成的工作内容。状态机和活动图在EA中均有对应的元素可以直接使用，相比于流程图更加方便。

2.2 逻辑实现文档内容设计与衔接

逻辑实现文档的设计分为纵向设计和横向设计。纵向设计是把一个系统功能从需求到最终实现的流程设计，横向设计则是把每个系统的纵向设计内容进行组合设计。在搭建模块化层级框架时，需要根据实际分层情况把纵向设计内容进行分类管理。下文重点阐述利用EA完成纵向设计内容。

2.2.1 建立软件组件并继承产品能力

前文主要描述的是功能层面的设计，下文的设计属于软件设计范畴。根据PC需求能力进行分类组合，建立EA 中的软件组件（Software Component,SWC）[10]，该组件可通过EA 中的关系图，对PC 操作进行继承，防止设计人员在需求编制时出现漏项。

2.2.2 打包并部署软件组件

每个SWC 都需要部署在系统芯片（System on Chip，SOC）里，部署时可把一类或一个系统的SWC一起打包部署。在部署之前，应先根据整车电气架构图，建立所有的ECU元素，再通过部署图实现SWC与ECU的部署关系。

2.2.3 设计软件组件接口

在SOA 的架构中，主要原则是定义标准化的接口。车身控制域系统的设计，不仅有基于单一（Single）信号的接收与发送，还有基于以太服务的消费接口[11]。利用EA对基础元素的封装能力，把EA的基础接口封装出不同类型的接口。以SOC为基础单元，根据架构的层级关系，每个层级之间建立的标准接口为内部接口，与其他SOC 之间的交互称为外部接口；若以SWC 为基础单元，其外部接口和需求接口，分别代表着SWC能提供的服务和消费依赖；每个外部接口元素可以在“操作”（Operation）选项卡里添加具体的接口名称，并将添加的外部接口名称提供给其他SWC进行消费；需求接口则是其余SWC 的外部接口，不能自行建立，需依赖方的SWC 建立外部接口，通过消费依赖方的外部接口建立关系。

在接口中，如果是Single 类型（汽车CAN、CANFD通信协议数据类型）接口，会描绘出信号的收发情况和数据值。如果是以太服务类型的消费接口，则根据设计需要定义服务接口所传的参数信息。数据类型与程序开发高级语言中的数据类型相似，有结构体、枚举、数组和价值（Value）数据类型，如在结构体数据类型中添加成员，可以选择特征（Feature）[12]里的属性（Attribute）以区别接口使用的操作内容。

2.2.4 绘制信号流程图

当有了服务接口和信号接口后，为了更清晰的表达出数据的流向链路，可以绘制信号流程图。信号流程图应与功能用例流程图对应，是以每个SWC 为单元，接口消费关系为链路的示意图，能更详细表达出数据在软件组件之间的流转关系，对后期系统问题故障诊断起到非常有用的帮助。

2.3 其它需求文档建立与关联

在进行一些涉及行车安全的系统设计时，如雨刮系统、大灯系统[13]，功能安全专业会对某些场景提出需求，通过ASIL等级进行约束和规范，这些特殊的需求可以使用需求（Requirement）元素进行描述，并在图中与Use Case进行关联，形成对Use Case约束和要求。还有某些响应时效、性能需求，在与Use Case关联后把这些特殊的需求横向分类到功能安全需求、系统性能需求文档中。这样不仅把这些特殊需求进行了归类管理，还清晰地表示出了哪个Use Case承接了需求。

3 基于EA的功能拓展

在完成EA 的系统设计和接口设计[14]后，可以通过共享服务器的方式，为有需求的使用人员开辟账号查看或编辑内容。但在实际开发过程中，为了追求更好的设计质量，不同的系统大多是分配给不同的软件供应商完成，为了项目全盘设计内容的安全性、保密性，往往是单独提供供应商承接的开发内容部分，所以设计的产出只保留在系统或者服务器中是远远不够的，还需要把系统中设计的内容导出来使用。

EA具有强大的拓展功能，不仅在发布（Publish）中可以进行设计导出和导入，还提供相应的API接口，可以供第三方开发人员访问数据库。因此，在系统设计人员完成相应设计后，可依托第三方提供的工具，把设计数据按需求格式进行导出，供开发者使用。

系统开发过程中常用到的开发文档就是功能规范。功能规范的导出通常有2种方法：一种方法是在EA“资源”（Resource）选项卡中创建元素的引用方法，再创建一份具有统一模板的文件（Document），把设计中用到的元素拖入模板文档中，在LINK 时选择引用方法。此时拖入的元素则会按照设计方法导入功能对应的需求内容、前置条件、触发条件、执行方法或步骤，形成文档后进行导出保存。此方法的好处在于文档是一个动态链接的状态，如果元素中有更新，刷新文档后，对应的内容也会更新，保证了设计与文档同步。另一种方法则是利用第三方的脚本进行导出，此方法的缺点是若文档有更新，则需要重新导出，无法像在线设计一样同步更新。

另外用到的开发文档是在AUTOSAR[15]标准下，采用可扩展标记语言（Automotive Open System Architecture Extensible Markup Language，ARXML）来传递具有层次结构的接口数据。主要就是导出EA里的SWC及其接口部分信息、消费的依赖关系内容。因为第三方工具可以通过API 直接访问数据库，导出的数据比使用系统工具更快，通常利用第三方工具导出，然后利用MATLAB生成ARXML文档。

基于EA 提供的API，可以直接进行数据库访问，具有强大的拓展功能，可以满足设计内容的输出需求。

4 设计方法实践

在岚图汽车SOA平台项目上利用EA进行了系统设计实践，本文以车身控制域氛围灯子系统为设计实例，阐述利用EA完成系统设计工作。

需要说明的是图2～图6所涉及的内容仅作为示例展示，相对于实际开发做了处理，实际开发时接口命名规则应满足集成编译环境所需的命名规则。

图2 部分氛围灯功能需求用例设计

岚图汽车公司将氛围灯系统规划在车身控制域的功能中，但部署在座舱域的SOC中，利用EA完成氛围灯系统设计，就打破了传统产品责任方法，车身控制域系统工程师可以在其他人负责的ECU 上进行系统设计，这也体现了SOA松耦合的优点。

4.1 氛围灯功能设计

在EA 中对氛围灯功能进行拆分，氛围灯首先具有中控屏与语音打开和关闭的Use Case。往下层级拆分，有通过中控屏与语音选择的静态、动态氛围灯控制的Use Case。再往下一个层级，静态氛围灯具有中控屏与语音调节颜色、亮度的Use Case，动态氛围灯具有音乐律动模式与随驾驶模式两种选择的Use Case，其中音乐律动模式下面又拆分有3 种色域（冷色、暖色、中色）的选择Use Case，让音乐律动的值在色域中进行律动。

在Use Case 设计时，有许多需求不能通过Use Case 表述出来，比如氛围灯的初始化状态、颜色的色谱、亮度等级分配和仲裁关系，以及一些非功能性需求，无法直接放入Use Case 中，可以使用Requirement元素进行描述，并与Use Case建立需求关系，见图2中的需求关系。

功能定义的详细描述，需要在Use Case 元素的“性能”（Property）选项卡中的“约束”（Constraint）栏目添加用例前置条件，在“场景”（Scenario）栏目中填写具体的方案，包括触发方式、基本执行方式、异常执行方式和备选执行方式。

根据架构拓扑情况，梳理出关联单元，在EA中建立相应的ECU单元元素，开展功能分配工作。功能的分配同样可以应用Requirement 元素进行描述，根据功能描述提炼每个ECU 单元能给氛围灯系统贡献的能力PC，然后建立氛围灯系统内的PC，而关联方的PC 需要和关联方讨论后，由对方承接并建立相应的PC。PC 建立完整后就可以针对每个Use Case 绘制相应的流程图，见图3。

图3 部分氛围灯功能用例流程

4.2 氛围灯接口模块设计

根据PC能力进行整合与分配，建立对应的SWC，氛围灯系统主要分音乐律动算法部分SWC、逻辑控制部分SWC、灯头驱动SWC 以及中间件信号路由能力。建立SWC后需对其进行部署，其中音乐律动算法的SWC 部署在安卓系统内部，这样可以直接获得到PCM源码音频数据，利用算法提取到用于控制氛围灯的音频、振幅等音乐特征；逻辑控制部分的SWC（图4）针对氛围灯的控制逻辑进行处理，并把处理结果转换成信号进行输出；灯头SWC则根据信号协议内容驱动氛围灯点亮。

图4 氛围灯逻辑控制部分SWC

每个SWC之间根据通信方式建立通信接口，比如算法部分SWC 与逻辑控制的SWC 采用信息中心（Message Center）的方式通信，建立服务接口及数据类型。逻辑控制SWC到灯头SWC是先采用以太网的方式与网关通信，再由网关采用串行通信总线（Local Interconnect Network，LIN）方式通过路由传给灯头，按照同样的方式建立服务接口、数据类型与信号。按照SOA架构方案，氛围灯应暴露出服务能力给其他系统使用，所以逻辑控制部分SWC还需承接在以太网提供服务的接口工作。标准化的接口建立以后，需要使用图表元素进行消费关系的建立，同时也可以进行氛围灯信号流程图的绘制，见图5。

图5 部分信号流程

4.3 氛围灯系统框图搭建与文档输出

氛围灯设计完成后，搭建系统框图时只需要在图表元素中拖入关联的ECU，在ECU 中放入软件的SWC，这样SWC 的依赖关系就自动建立，很轻松地完成了系统框图的绘制（图6）。利用第三方脚本插件，可以对元素中的信息进行选择性导出生成Word 文档，利用此脚本可以按照模板生成氛围灯的功能规范。如果软件开发方需要ARXML 作为软件开发输入[15]文档时，可以把EA 中氛围灯接口模块设计的内容导出生成Word 文档，利用文档转换脚本把Word 文档转换成Excel 表格，再使用MATLAB 工具生成ARXML 文档[16]。

图6 氛围灯系统

5 结论

利用EA 开展车身域系统设计工作，通过图表的方式能很好地理清系统设计人员的逻辑思路，梳理数据流向，完成需要的系统设计输出物和交付物，比如系统框图、系统流程图、系统规范以及标准化的接口。EA 还具有解耦性，设计工作不与特定的硬件信息耦合，适用于一种系统方案匹配多种产品方案。

目前SOA架构已在国内汽车行业逐渐流行，传统手写功能规范的方式在车身域场景化的开发中效率低下，需要一些信息化的工具辅助完成系统设计工作，经实践EA 符合目前汽车行业车身域系统设计需求。

应用EA 开展系统设计，有利于设计协同性和信息查询的便利性。应用EA 进行设计的人员，可以分模块化同步开展工作，相互之间不干扰，有依赖需求时通过图表元素建立关系，各个系统的设计人员之间从图表元素中获得对方的需求，进行协同设计。在设计中及设计完成后，有信息需要查询和确认时，利用关键字符可以在EA 中检索出元素的所有依赖关系，方便查询。

EA 不仅适用于企业架构设计，EA 也可以成一款汽车车身控制域系统设计的辅助软件，提升设计效率，改善设计质量。