前言

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

1 面向功能开发模式

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

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

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

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

（2）指导零件技术方案选型，将功能需求分配到零件中去，并且明确零件在功能实现过程中的作用。

考虑网络架构的约束条件，在功能策划阶段，就能判断功能实现的可行性并预估开发的成本和时间，能为功能决策提供相对可靠的依据。

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

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

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

功能、系统和控制器三者的矩阵依赖关系放在整车环境下进行定义，可以表述为：在整车制造维度上，整车由单体零件组装而来；在整车功能维度上，用户体验是由单项功能组合呈现；系统从管理维度，将功能分门别类进行组合。考虑到整车功能开发往往从特色功能的定义开始，故作表4所示定义。

1.2 系统对功能的完善

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

1.3 系统对零件的约束

零件的开发需要完整而清晰的功能需求和性能指标，这样才能有效地避免与需求反复确认。系统层在进行功能分配之前，需要了解零件的性能和处理能力，这样就能有效地避免分配下来的功能，在零件上无法实现的问题。结合系统层利用零件和零件之间的分工方式定义出来的最优接口方案，比如信号的周期和类型，就能明确地指导触发机制的选择。在系统层面进行建模仿真能有效地预估功能响应时间和动作幅度，并能给出带有数据支持的零件开发目标。

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

1.4 系统对架构的补充

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

2 功能架构模型

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

2.1 功能架构概念

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

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

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

（3）零件角色：统一和扩展功能对于零件的分工要求。

图3把功能架构的3个维度内容有机地结合起来：功能和零件的依赖关系通过交叉圆点展示出来，零件在功能架构中的作用也能通过查看三角标记而得知，比如触发条件、前提条件。针对系统层的功能实现逻辑，还能定义系统的类型，挖掘出系统层级的逻辑需求。系统的类型如表 6所示。

针对多输入系统，就需要对输入进行优先级定义，并且在逻辑上建立仲裁机制，而对于多输出系统，就需要定义各个零件的响应同步性；此外这也大大方便了功能安全的评审，不仅可以了解失效之后的功能安全状态，也能明确零件单点失效率如何影响功能的降级行为。

2.2 功能状态定义

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

2.3 功能激励条件定义

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

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

3 应用与实践

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

3.1 用户场景定义

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

3.2 搭建需求框架

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

· 尾门解锁

· 尾门升程运动

· 尾门停止

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