SOA架构下基于EA的车身控制域系统设计.docxVIP

0引言

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

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

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

（2）服务松耦合；

（3）服务的可重用性；

（4）服务自治。

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

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

1模块化层级框架搭建

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

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

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

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

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

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

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

基于上述描述，使用EA搭建出了车身控制域系统设计框