基于电控框架模型的硬件资源管理研究

刘敏，李吉宗，张文学

（泛亚汽车技术中心有限公司，上海 201201）

引言

随着汽车电器化的发展，整车上的电控系统日益增多，系统间的关联关系也越加复杂，项目需求的不同导致开发交付物存在差异，而项目的不断增多，车型功能的个性化配置，也使得开发交付物的重复工作不断增加，潜在出错概率也进一步增加。“基于模型的系统工程（MBSE）”是汽车电子研发的发展方向[1]。不同的项目必然存在部分相同的功能和车载控制器ECU（Electronic Control Unit），从而使得这些功能和零件可以应用到不同的项目中，以减少开发工作。但如何在众多的项目和需求变更中高效地识别到这些相同点并进行沿用，同时能兼容不同项目的差异点是目前整车电控系统开发工作中的一大挑战。因此，泛亚汽车技术中心有限公司基于Vector公司的PREEvision软件自主创建了整车电控框架模型库，实现不同车型项目中电控模型的复用，进而实现基于模型的整车电子架构开发。

ECU是车载电子控制功能的载体，每个ECU承载着汽车的一部分功能和算法，因此每一个ECU控制器都必须能够提供相应的硬件资源，以确保车载软件功能的正常运行。如果ECU控制器提供的硬件资源无法达到各个软件组件执行的最低要求，那么将对车辆的功能产生影响，后果也将不堪设想。基于节约成本的原则，通常ECU会复用到多个项目中，如何对ECU的硬件资源进行高效准确的评估，是汽车行业的一大难点。

本文基于整车电控框架模型库，提出一种基于模型的ECU硬件资源管理方法，以提高整车硬件架构开发效率和质量。

1 PREEvision层级介绍

德国Vector公司的PREEvision是全球应用最为广泛的电子电气系统（E/E）架构设计工具，其支持从电子电气架构设计到产品系列开发的全过程，其主要包含需求设计、软件架构设计、硬件架构设计、电气系统和线束方案开发、拓扑结构设计等[2-4]。而且，PREEvision还具备强大的二次开发功能，提供了可以用于技术评估的算法工具，其核心的技术也是基于模型的开发，层与层之间相互渗透和映射[5]。其分层架构流程如图1所示。

图1 PREEvision分层架构[6]

2 汽车电子电气架构开发

2.1 软件架构层开发

由于需求设计层与本文阐述内容－硬件资源管理关系不大，故本文不涉及需求层设计。软件架构用于描述系统的逻辑功能关系，即系统功能的模块框架以及各模块之间的接口关系，包括两个方面的开发工作：

2.1.1 开发“功能类型”

在“功能网络”中各模块端口上的接口信息都需要事先在功能类型库中定义。功能类型库描述了所分配端口需要或提供的信息，这里的接口可近似看成技术通讯协议。在“功能网络”建模以及对整个网络信号进行路由规划过程中，接口定义一致的端口之间的兼容性可以在PREEvision反映出来，如图2所示。

图2 软件架构“功能类型”描述图

2.1.2 设计“功能网络”

“功能网络”遵从AUTOSAR标准的定义，包括逻辑传感器、功能块和逻辑执行器。这些元素（也被称为功能模块）以层次结构的方式组织并存储在组合模块中。功能模块之间通过信息交互接口进行连接。当两个功能模块的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。在功能网络里，用户可以看到各功能模块之间的逻辑关系，如图3所示。

图3 软件架构“功能网络”描述图

2.2 硬件系统架构开发

硬件系统架构通常在开发过程的各个阶段都会被用到。在早期的设计阶段，它被用于确定所有电子电器部件内部连接的最优架构方式；在设计阶段，网络图描述了系统规范中重要的电路原理。在网络图中用户可以自定义模块及连接线的显示方式，来凸显与特定属性有关联的部件，这些属性可以是电源供应、传输协议、网络电阻等。

图4 硬件系统架构

硬件层描述各部件之间的逻辑连接方式，例如总线系统（CAN、LIN、FlexRay、MOST、Ethernet、USB和WLAN）、传统连接、地线和供电连接等。部件之间的所有连接通过不同的接口来实现。可将每个具体接口配置为定义了通用属性的特定接口类型。通过网络层的描述，可以构建部件设备内部对外连接的总体关系，如图4所示。

上图中包含ECU、传感器、执行器、接地点等，同时设置连接口的类型。如图5所示，硬件接口常用的接口类型有CAN Connector Type、CAN FD Connector Type、LIN Connector Type、Ethernet Connector Type等。

图5 接口类型选择

2.3 软件层和硬件层的关系模型化

软件层和硬件层之间通过映射和路由进行关联。软件层可以映射到硬件层上，代表逻辑功能通过软件或硬件的实现方式，当软件层各模块之间的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。硬件层可以映射到拓扑层上，将ECU的模型与在整车的实际安装位置关联起来，整车总线束长度可以在拓扑层得出。

信号路由是根据映射关系按照某些规则自动建立软件层的数据元素（Data Element）与通信层的信号（Signal）之间的映射关系。软件层路由的目的是将软件层的信号流映射到硬件层中的连接线上。硬件层线束路由的目的是将硬件层中的连接线映射到拓扑层中的线槽中。

图6 模型元素的关联关系

模型元素层级之间通过映射（Mapping）和信号路由（Routing）进行互相关联，如图6所示。功能需求和功能Feature是整车电子电气开发的起点，需求层可以映射到其他层级，进行需求跟踪，代表客户特性通过软件、硬件等的实现方式如需求特性根据功能划分映射到功能框架模型，同时和系统方案相关的需求特性也可以和硬件相关的系统方案进行关联。而软件层功能模型可以根据架构需求映射到不同的Topo硬件ECU上，代表逻辑功能通过软件或硬件的实现方式。当软件层各模块之间的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。信号路由是根据映射关系按照规则自动建立软件层的数据元素（Data Element）与通信层的信号（Signal）之间的映射关系，并创建通信层元素，经后续集成发布相关数据库。

通过这种模型层与层之间的关联从而实现模型元素所有层级之间的关联关系，形成一个完整的电控模型，而工程师只需要勾选对应的功能特征就可以在一定的规则下抽取出该功能特征对应的所有模型元素，实现了电子电气架构的分层式及统一化开发。

3 硬件资源管理开发方法

根据上述软硬件模型的创建方法，软件组件已经与硬件层的ECU建立了映射关系。因此，基于整车电控系统的变体管理实现基于系统方案的硬件资源管理方案。

根据前文所述，在框架模型的建设中，每一个软件组件都将会映射一个明确的ECU硬件（如图7的BCM），每一个软件组件都必须由ECU中的相对应的可执行文件来实现执行。因此，每一个软件组件都将消耗一定的ECU硬件资源（例如ECU的RAM、ROM、CPU等资源），并且对于同一个ECU控制器，可能有一个或多个软件组件与之建立映射关系，因此每一个ECU控制器都必须提供相应的硬件资源，如果ECU控制器提供的硬件资源无法达到各个软件组件执行的最低要求，那么将对车辆的功能产生影响，后果将不堪设想。如果ECU控制器提供的硬件资源对于与之Mapping的软件组件的执行绰绰有余，那么势必造成ECU控制器硬件资源的严重浪费，增加了整车的研发成本和制造成本。因此，本文提出接口与硬件资源管理解决方案。基于整车电控系统变体抽取系统方案后，可以针对每一个具体的ECU，导出其需要配置的最低硬件资源管理报告，如图7所示。

图7 硬件资源管理方案

对于不同整车电子架构方案，同一个ECU可以映射不同的功能组件，所以工程要求的硬件资源也不一样，因此通过映射到ECU的功能组件及接口清单即可计算出ECU的硬件资源，如表1所示。

表1 ECU 资源表

在表1中，Resource列表示硬件资源类型，Result列表示基于框架模型库计算出来的硬件资源值，Actual列表示上汽通用汽车某实际整车项目中的ECU硬件资源。

依托整车电控系统的变体管理解决方案，工程师不仅可以方便地抽取系统方案，并且可以针对抽取的不同系统方案进行各种纬度的分析和对比，帮助工程师选择出最优系统解决方案。针对抽取的各个不同的系统方案，对每一个系统方案中的每一个ECU硬件资源的最低要求进行分析和汇总，然后对比不同的系统方案对ECU控制器硬件资源的需求差异。由此可以帮助工程师从车辆性能与整车研发成本和制造成本等不同纬度来对抽取的不同系统方案进行分析和对比，并选择出最优的电控系统方案。

4 总结

本文重点研究了基于PREEvision的电控模型框架库，并基于电控框架模型库开发了硬件资源管理方法。其中，介绍了PREEvision的各个层级（即框架模型库的层级），并基于PREEvision，实现了软件架构模型开发、硬件架构模型开发 及各层级之间的映射关系模型化，阐述了电控领域变体管理思想，并基于此研究了硬件的有效管理，实现每一个系统方案中的每一个ECU硬件资源最低要求的分析，可有效提高整车开发中硬件工程师的开发效率。