在软件定义汽车的时代，功能体验日新月异，采用面向信号的架构开发模式不能满足用户对于功能快速交付的期待，正初步地被面向服务架构所取代。本文讨论了面向功能开发流程中的核心元素，以及功能、系统和零件之间的关系，提出了在系统层建立以功能架构为基础的建模方法。同时结合吉利汽车的开发实践经验，提出功能导向开发模式的组织分工，建议由系统工程师来主抓功能架构在系统层建模并推动落地。最后展望了功能架构在面向服务架构和敏捷开发流程中的重要作用。

前言

随着电动化、共享化、智能化和网联化时代的到来，用户的需求与日俱增，丰富的应用场景和个性的驾乘体验驱动着整车电子和软件进行快速地迭代和创新。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所示为自动尾门开启功能的依赖关系，为了简单起见，仅仅把部分零件整理出来。

脚踢传感器

尾门锁

尾门升降电机

铰链

电动尾门控制器

车辆防盗系统

最后，将功能按行排序，零件按列排序，画成矩阵图，并且在矩阵上将功能和零件的关联点用圆圈标识出来。此外还可整理出一张表格，用于定义依赖关系的信号。

3.3 使用依赖矩阵

在整个开发过程中，使用依赖矩阵进行了信号矩阵的校核，没有功能需要的信号就会被标识出来，根据是否有功能预留作为判断依据，来讨论并决定是否需要删除。除了上述提到的系统层需求抽取之后，根据依赖矩阵，可以快速进行功能成熟度的评估和软件问题的原因分析。

3.4 组织和人员分工

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

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

（2） 互联网产品经理也是从软件开发成长起来的，所以和工程师进行需求交流比较顺畅。

而系统工程师来牵头开发工作，就能利用他们的系统思维和严谨工作方式来协助擅长创意和体验的功能开发工程师来完善需求，有效地实现功能落地。

在开发人员比较充足的情况下，也推荐单独定义功能架构师角色，如图6所示，这样系统工程师可以更加专注于系统层中零件的技术方案，而功能架构师则关注系统的外部功能或者行为表现。

4 结论与展望

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

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

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

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

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