功能架构在吉利浩瀚平台中的应用和实践

前言

随着电动化、共享化、智能化和网联化时代的到来，用户的需求与日俱增，丰富的应用场景和个性的驾乘体验驱动着整车电子和软件进行快速地迭代和创新。2010年生产的一台豪华轿车具备800个整车功能，而在2007年这个数量只有270个。随着整车算力的提升，信息安全、功能安全要求也在提高，代码量还会快速提升。当前豪华车辆代码已经能达到2~3亿行 ，软件在进行快速迭代的同时，也增加其在整车价值链中的比重，根据Apostu等的预测，软件创造的价值在2030年将达到整车的30%。在当今存量市场竞争的背景下，各整车厂都在积极地推出架构平台，比如：大众汽车的MEB，丰田汽车TGNA和吉利汽车的SEA架构，依托架构进行造车，用于控制成本，提高竞争力。电子电气架构作为整车功能的基础平台，其可扩展性将决定各整车厂在未来软件定义汽车赛道上的竞争力。如何在电子电气架构上快速进行功能的开发和扩展，是业界共同的挑战。

1 面向功能开发模式

现代汽车电子电气架构通过各类总线至少可以连接150个控制器，并且能部署300万多项功能。要整体管理这样规模的系统，仅通过网络架构和系统架构来梳理是无法掌握功能之间的依赖关系。网络架构从通信的维度定义各个控制器之间的信号矩阵，而系统架构从零件分工的维度明确它们之间的接口关系，其核心都是管理零件与零件之间的依赖关系。这就需要立足于功能，重构其在电子电气架构上的开发逻辑。

面向功能开发模式强调从用户使用场景出发，全面分析用户需求，定义功能特征，最终通过零件来实现，执行功能实现的零件包括控制器、传感器、执行器、开关和显示器等。功能需求在创建时颗粒度大小不一，通过层层传递后，需求内容也会随着关注重点的不同而被误解，最后导致功能策划和功能实现效果不一致。为了弥补功能需求理解差异，需要引入系统层来捋清功能和零件的映射关系，如图1所示，起到承上启下的作用。业内对系统层的定义比较抽象和宽泛，在实际工作中不具备可操作性，反而额外增加了需求开发和维护的沟通开销。

功能层的需求捕获来自于用户的使用场景，目的在于明确功能价值，控制器层的需求输出给供应商（内部或者外部供应商）开展开发工作，目的在于选择技术方案。因此，系统层的需求工程目的就是将功能和零件统一关联起来，主要起到以下两方面的作用：

（1）引导功能场景进行具体形象化，体验方式进行精细化，并提炼成技术需求语言；

1.1 功能、系统和零件的矩阵关系

为了更好地理解面向功能开发的流程，首先需要梳理清楚功能、系统和零件的关系。 这3个术语的定义都整理在表 1~表 3中，同时增加了中文的翻译。

解读完术语定义并结合吉利汽车在开发中的工作实践，本文建议采用矩阵方式来重新定义三者关系，在工作组织关系上则沿用分层结构来建立上下游关系。控制器是整车比较特殊的零件，考虑到软件基本上都集成在控制器中，因此在 图 2 中使用控制器来代替零件。

1.2 系统对功能的完善

特色功能往往通过创新手段 （ 比如： 头脑风暴，设计思维）或者对标而捕获，并形成 一个概念或者愿景表述，通过功能层的需求抽取 ，逐步地形成使用场景。 在系统层上，面向功能场景进行建模，使用用例图、状态机、时序图等方法进行分析，就能将功能点扩展为功能族，进而形成完整的功能清单。 这份功能清单又作为新一轮的输入进行市场调研，然后确定每项功能的价值和优先级。 经过多轮迭代和优化，整车功能定义就能层次清晰，场景目标明确，并能全局把控用户的目标期待，功能需求的提取是一个系统工程 。

1.3 系统对零件的约束

考虑到当前功能安全和信息安全的要求，系统失效模式的分析工作，可以框定零件FMEA的工作重点，并能指导零件的异常处理机制部署。

1.4 系统对架构的补充

网络架构的开发模式要求架构团队输出网络拓扑图、通信矩阵和诊断数据，但是对于功能的开发仅仅停留在信号层面。表5所示为架构的定义，通过系统层的需求定义，建立功能和零件的依赖矩阵，这样不仅能有效地协同各个零件同步开发进程，快速高质量地交付，同时也能有效地把控功能的变更，主动进行功能重构，迅速地适应需求的变化。系统层需求的建模分析结果，从数据也能支持架构拓扑结构、电源模式管理和网络休眠唤醒机制等基础性功能优化的决策。

2 功能架构模型

功能驱动带来软件复杂度的提升，严重地拖延了整车厂的创新和新功能交付，这就需要研究功能开发的关键路径并找到优化方向。 结合吉利汽车的实践经验，使用功能架构 模型进行系统层建模 ，由此有效地管理依 赖关系，进而提高研发效率。

2.1 功能架构概念

功能架构是在系统层对于功能进行关系建模，根据前期开发的经验，在实际开发工作中主要关注以下3个维度工作：

（1） 功能结构： 功能细化并描述功能对于系统的行为要求；

（2） 映射关系： 描写功能和零件通过接口定义的依赖关系；

2.2 功能状态定义

利用功能架构模型进行系统层建模，就需要统一定义功能的状态，如表7所示。 统一建模语言，能方便开发团队进行技术交流和讨论。 本文只标准化功能状态，但不约束功能行为，也就是说单体功能可以根据场景的需求对于功能状态进行不同行为规范，比如灯光功能的Off指的是关灯，而玻璃升降器的Off指的是停止运动。 利用功能架构进行系统建模时，只关注功能的状态迁移条件，而具体的控制行 为或者算法实现方式，比如采用PID控制还是模糊控制，可由功能执行的主要零件工程师进行选择。 这样分工，在概念设计阶段能高效地定义系统行为，不用陷入太多技术细节讨论，同时也能激活零件开发工程师的创造力，只要达成开发目标，就可以各自自由进行算法和程序的设计。

2.3 功能激励条件定义

通过外部或者内部的事件可以改变功能的状态，这些事件可以按照表8来进行分类，考虑到供应链全球化趋势，需求规范编写时，也添加了英文名。

图4表示功能状态和条件关系，针对每个功能，如果有多个事件或者状态组合成为一个条件，就需要把它们的组合关系也表示出来，比如逻辑“与”和逻辑“或”的关系。

3 应用与实践

在吉利浩瀚架构上进行了实践，在此选择脚踢开尾门的功能作为案例进行说明。此功能允许车主利用脚来非接触式地开启后备箱。

3.1 用户场景定义

在用户场景阶段，仅仅关注在什么情况下（When），解决了什么问题（What），但是对于问题怎么解决（How）不进行讨论。

根据市场部的调研以及功能开发工程师的对标，脚踢开启尾门功能按照卡诺模型的分类是属于期望型功能，功能能给用户带来正向的使用价值，帮助客户解决了不方便用手开启尾门的场景，这种场景在超市购物、搬家和运输过程中发生的概率也比较高。当然这个功能依赖于电动尾门开启和无钥匙进入功能，并且一般部署在SUV车型之上。

3.2 搭建需求框架

首先，对于功能进行结构拆解，由于尾门开启是一个动作执行过程，可以根据动作的类型对于功能继续细分，比如：

· 尾门解锁

· 尾门升程运动

· 尾门停止

其次，罗列尾门模块中的零件清单，这个清单不仅仅包含控制器、开关、传感器、电机等机电零件，甚至也可以将关联的机械零件如铰链也放在清单中。 在尾门的升程运动过程中，电机负责提供动力，而铰链的摩檫力和尾门自身的重力为阻力，在后期的标定过程中，铰链和尾门的工艺一致性影响尾门开启的响应时间。 图5所示为自动尾门开启功能的依赖关系，为了简单起见，仅仅把部分零件整理出来。

3.4 组织和人员分工

在需求开发过程中，本文建议可以在系统工程师配合架构团队，对于各域的功能架构进行统一开发管理。观察到有些整车厂学习互联网行业的经验，由功能开发工程师主导功能开发、系统设计和零件开发，但效果不是太好，分析其原因有以下两点：

（1） 互联网产品不需要考虑硬件，更不用说机电系统的限制，只要把软件逻辑实现就行；

4 结论与展望

功能架构展示了需求工程的一种全新视角，利用功能的生命周期进行需求的系统化整理，通过电子尾门功能的案例和吉利汽车浩瀚架构的开发实践，完整地提出了整套功能架构方法论在工程实践中的资源和需求组织原则，具备对行业进行架构开发的实际指导作用。

在当前软件定义汽车的背景下，电子电气系统的开发发生了深刻的变化。

首先，SOA面向服务架构正在兴起，如图7所示，通过功能架构建模，将功能颗粒度细化，可以快速地封装成为原子化的服务，而依赖关系可以作为服务订阅和发布机制的原则基础。

其次，敏捷开发流程相对于传统的迭代开发流程更加有效 ，整车项目开发要求在短时间内进行功能交付 ，细 化的功能需求将有利于更具有效地进行两周的冲刺计划。 图8 所示为一种敏捷模块 释放计划，利用依赖矩阵可以有的放矢地进行释放节奏把控，按照功能计划更加高效和灵活地实施开发计划。

再次，结合电子电气架构向中央化计算平台的演进，以及软件自研和SOA架构的推广，将会使得软件的复用变得简单 。 功能架构将软件模块和功能关联，可以将产品规划和软件开发都集中到统一平台上，如 图9 所示。