整车功能开发

站在前人的肩膀上，从系统功能架构集成角度梳理下整车功能开发相关内容

1、整车功能开发相关文件介绍

1.1 配置表

在这里插入图片描述
上面的表格，是一种车辆特性的表达方式，其实比较传统，我们称之为配置表（Feature list），简单来说，就是具备什么样的特征，也就是我有什么，拿整车配置表来说，就是告诉用户或者内部开发人员，我有哪些东西，而且这些东西很多是我的特色，买我性价比高。传统的Feature List通常有以下几种表达类型：
1.参数类：
轮胎尺寸、轴距、电池容量、续驶里程；参数类配置说明整车、系统或零件的类型和参数；
2.零件类：
零件类配置说明整车装有哪些零件，有些零件名称本身就可以表示其具有的功能，如车顶行李架（功能为行李固定），电动助力转向管柱（功能为车辆转向）；有些零件可能会具有多种功能，一般采用零件功能+零件的方式去描述，如电动调节外后视镜（还可能有电动折叠等）、电动调节驾驶员座椅（还可能有电动加热等）、间歇时间可调前雨刮（还可能有雨量传感器自动控制等）；
3.功能类：
碰撞断高压电、位置灯未关提醒。功能类配置说明整车具有哪些功能；
4.系统类：
上坡辅助系统、自动泊车系统、无钥匙进入系统。与功能类配置类似，只是以系统2字结尾，配置表中的条目都是想表达“整车具有什么”这个核心思想。

对于10年前的汽车来说，当时电控部件的功能单一，从名字上来看就知道有哪些功能了。随着智能汽车新技术应用，功能越来越多，或者多个零部件联动一起形成新的功能如“驾驶模式”。在这种情况下，仅仅通过一个配置表来管理整车功能开发变得相形见绌，整车功能清单也就由此诞生。

1.2 功能清单

功能清单，称作Function list。如何传统的配置表（Feature list）变化到功能清单（Function list）
在这里插入图片描述
从上图描述的配置表和功能清单发现：
1，功能类的配置可以直接被功能表采用（上面表述中3，功能类），而参数类、零件类和系统类的配置是功能实现的物理基础和约束条件，上图的功能表中，冒号后面是功能实现需要的物理实体零件或能达到的参数。
2，为了体现出功能是零件的作用，功能的名称需要用能够表达整车、系统或零件所发挥的作用来进行命名，例如xxx控制等，而不能以零件或系统直接进行命名。
为什么现在的车型，甚至项目开发过程中，主流的方式，依然还是以传统的配置表（Feature list）来展示呢？
一来，在用户领域，传统车辆的用户形成的惯性和粘性，依然会以配置对比来评价车辆。而不会想到功能层级。而且大多数人更倾向于看得见，摸的着的东西作为评价标准。而非体验类的感觉。例如，一辆车动力性能，驾驶性能，并不是单纯的看配置表就能对比的出来的。——俗称堆料。
二来，在开发领域，车型配置表单（Feature list）的定义始终是各大车企，尤其是合资品牌车企产品战略部门管理的核心职责。无论调研逻辑是否成立，只要有配置表单（Feature list），那就有数据，可量化，易达成……简单的说，更加容易管控各个部门的目标，绩效，交付物。

功能清单的结构
当前的整车功能清单会区分为主功能和子功能，对于主功能和子功能的区分。
主功能
场景来看，完成一个用户的主场景动作，如用户完成座椅调节，满足自己的乘坐需求；
部件来看，基于一个较为完整的部件系统，如座椅这个完整的系统；
子功能
场景来看：完成用户的一个细分场景需求，如座椅的前后调节；
部件来看，至少基于一个主要零部件及上下游的关联零部件，如座椅的前后调节电机、开关、显示屏等。
Use case
一个子功能的实现，有输入、判断、输出等几个步骤，输入可以是软开关、硬开关等，执行中会有防玩，功能失效等情况，这些都是形成use cases的主要考量项，如上述座椅的调节，前后调节，可以用软开关、可以用硬开关，可以语音，执行过程中，用户打断调节、调节电机堵转等，这些都会形成一个子功能下的不同use case。
子功能的最小单位必须是必须是一个完整的给用户服务的场景，一个单独的执行动作，或者一个交互显示内容，只是一个子功能下的case内容，不能设定为一个子功能。
通过主功能、子功能、UC的三层分级后，需要达到主功能清单基本保不变，子功能清单也基本保持不变，UC可以按照项目的新需求便捷调整。既主功能清单基本可以覆盖所有车型而不做改变，子功能可以覆盖同平台车型不做改变，UC可以覆盖一款车型及其衍生车型不做改变。
随着整车功能数量的增多，SOA（面向服务的软件架构）兴起，从功能需求可以直接连接到产品原子化服务能力，更多场景模式的出现，功能清单的结构也会逐渐重构。
功能清单和整车其他清单的关系
销售配置表，工程配置表，功能清单，BOM清单，功能增长表等，这些名称都是整车开发中常用的一些清单
在这里插入图片描述
通过上面这几个清单，基本上就能把整车开发串起来了，这些清单，本质上都是管理工具。
功能设计
功能设计一般分为2个阶段，
第一阶段：从无到有，此阶段是在开发当前整车产品不具备的功能，此阶段基本不符合当前国内整车开发情景，因此很快进入第二阶段
第二阶段：优化设计，在这个阶段，核心是竞品对标，针对竞品功能对标，有以下几个个关键点：
1、说明书，获得对标车辆的说明书，并对要对标对功能的使用说明和注意事项等详细的阅读；
2、对标场景设计，详细设计对标场景，设计详细的体验Case,基本上可以寻找功能体验细节。
3、对标车辆选择，当前建议，新势力的如特斯拉、蔚来，传统豪华品牌如奔驰、宝马，以及大众等车。你会发现针对这些场景，不同品牌的会有很多不错的考虑。如奔驰是通过踩两脚制动激活Auto Hold，特斯拉是大力出奇迹。另外奔驰可以通过再次踩制动释放Auto Hold，看似反人类的设计却在下坡堵车的场景下给你最安心的操作。如果不知道这个设计，没关系，特斯拉非常人性的在坡道上会提醒你“可以通过踩制动释放Auto Hold。“
4、人员选择，新手、老手、男士、女士、不同年龄段等，每个人的经历和关注度都不一样，发现的点基本也不一样。

1.3 功能设计文档

在功能定义文档中，一定要把以下几个事情定义清楚。
1、功能的简明描述
2、功能设计的法规需求
3、功能已有的专利检索
4、功能的大致交互框图，输入、输出和中间的决策定义。
D-NICE：整车功能开发系列–一个完整的功能设计应该包含哪些要素
5、功能的具体Use case（重点）设计
一个完整的UC，应当包含该：
UC的目标：该UC要实现的目标，如激活Auto Hold
UC的前置条件：如整车的电源模式，整车的配置，相关系统的无故障等
UC的触发条件：如车速为零，或者制动踏板在多少时间内踩动两次，等等
UC的主流程：也就是用户的操作及车辆的期望响应，如把大象关进冰箱分几步，第一步打开冰箱门，第二步把大象赶紧去，第三步关上冰箱门。
UC的支线流程：达到同样的目标，其他的操作步骤
UC的异常流程：设计一定的保护措施保证功能的有效性。
6、功能属性目标，如Auto Hold这块的加载响应时间，释放响应时间，可在多少角度的坡道上进行驻车等等
7、其他信息安全、功能安全的设计要求。

2 整车功能开发流程

功能开发的起点-整车功能清单。功能开发的核心-功能设计，功能开发的下游-系统设计、ECU设计、软件开发以及整个功能开发过程的管理-功能增长表。
在这里插入图片描述
功能负责人（FO ,function Owner）根据整车功能清单，用SSTS描述抽象的逻辑关系，再由CTS说明实现方案，最后由零部件供应商具体落地实现。它们之间的关系如下示意：

VTS（vehicle technical specification），即整车技术规范，主要描述车辆与使用者的交互关系以及性能目标。
SSTS（sub system technical specification），即子系统技术规范，描述应用场景分析、信号交互和功能控制逻辑等。
CTS（component technical specification），即零部件技术规范，描述零部件供应商所需提供的控制器设计原理，包含控制芯片要求、电气原理图、控制功能逻辑、通讯诊断和休眠唤醒等内容。
其中，SSTS主要以子系统为中心，由多个控制器共同实现，而CTS主要以控制器为中心。CTS通常由零部件供应商提供或确认，其内容必须满足各SSTS中的需求内容。
所谓功能开发主要围绕着SSTS的内容进行，即应用场景分析，功能控制逻辑和通讯等内容，下面就以纯电动车动力总成系统的充电功能为例展开详细介绍
充电功能除了大家所熟知的交流充电（慢充）、直流充电（快充），交流放电（V2L），还包括预约充电，交流/直流桩供电以及V2V等功能。这里就借助交流充电来解释功能开发
a. 功能应用场景分析
用户的感知通常是插上交流枪，然后就开始充电了，在车的大屏或者手机端就可以看到当前的电量，充电剩余时间，充电电流和充电电压等信息。
在这里插入图片描述

假如正在充电中，用户可能不想充了，那么可以在手机APP端或车的大屏点击相应的按钮来停止充电，甚至可能可以长按充电口盖或充电桩APP端的按钮来停止。以上这些用户所能看到的信息和进行的操作，就属于功能开发的范畴，在SSTS中定义了用户可以看到哪些交流充电信息，允许用户能够进行哪些操作来影响交流充电功能，这就是功能开发的应用场景分析主要内容之一。
另外，应用场景分析还需要综合起来考虑用户行为，使得用户操作之后产生的现象符合预期，即各种行为交叠的时候，其交互逻辑不会产生冲突。比如正在交流充电过程中，用户通过手机APP端停止充电，但是又通过车的大屏再次启动充电，那么相应的现场应该是先停止充电，而后又进入充电。
除此之外，应用场景分析还需要结合一些典型的功能场景（比如交流充电，有使用公用充电桩充电，也有使用自己的专属的充电桩充电）来全面考虑，总之，从充电桩，手机APP端，车的大屏端以及充电口盖等因素综合分析之后，对产品功能有了全面的理解和清晰的定义，再来制定相应的功能控制策略。
b. 功能控制逻辑
要制定好功能的控制策略或逻辑，必须要掌握一些基础知识，比如针对交流充电功能：
需要了解交流充电的基本过程，比如先通过CC电阻值识别充电枪的连接状态，再通过CP了解交流充电的进行状态等，具体可参考GB-18487。
需要了解整车电子电器架构，交流充电会涉及到哪几个控制器，比如动力总成系统的BMS，VCU和OBC等，其他总成系统的HMI和TBOX等；另外也需要知道各控制器分别承担哪些工作；比如OBC需要识别充电枪的连接状态，需要控制继电器以决定是否进行交流充电；BMS需要控制主正主负继电器上高压，也需要根据电池状态请求是否充电等。
需要了解整车网络拓扑，以决定信号交互怎样定义。
需要了解各个控制器的故障等级所对应的产品工作状态，比如BMS的1级别故障意味着BMS将断高压，停止工作。
在这里插入图片描述
在上述的基础上，接下来就是制定功能的控制逻辑，即定义各个控制器的信息交互时序和逻辑，比如针对典型的交流充电功能，其控制时序如下图示意：

既需要考虑正常情况下的功能控制（进入，保持和退出），也需要考虑故障情况下的功能控制（退出和后处理措施）。同时也需要定义HMI相关的内容，比如交流充电过程中，手机APP端和车的大屏显示什么内容，充电口的指示灯是否根据电量显示不同的颜色，以更好地体现充电的实时状态，以及是否需要有一些语音提示。除此之外，定义好用来进行该功能的信号交互的通讯矩阵，以此形成较完善的功能开发规范，即SSTS。

3 功能分配
功能分配功能分配是架构设计的中间步骤，功能分配设计须具备一定的前提条件才能进行。E/E架构设计始于功能需求。
功能的逻辑架构是以功能规范为基础设计的功能模型，功能分配是将不同的功能模型映射到控制模块的过程。功能分配是架构设计中的一个关键步骤，通过功能分配，导出最终的架构设计方案，形成网络拓扑，输出最终的系统方案。
如图功能分配设计过程图（其中虚框内为功能分配过程）。功能分配的前提条件是各功能的功能规范以及逻辑模型等。
在这里插入图片描述
功能分配主要考虑因素
功能分配主要考虑的因素，但分配后的结果对整车而言如何进行评价是关键。好的E/E架构设计即能节约成本又能具有良好的扩展性以满足现在用户的个性化需求。对功能分配的评价主要是4个大的方向：
（1）成本：包括ECU的成本、网络通讯的成本、线束布置带来的成本；
（2）性能：包括网络的负载及响应时间、功能端到端的时延、CPU的响应速度；
（3）可扩展性：包括CPU的计算能力、网络的带宽余量、车型从低配到高配的功能可覆盖性；
（4）功能安全：包括满足ISO 26262的安全等级要求。
通过工具来进行各方案的功能分配方案及评价，也要结合不同级别的车型以及产量的大小，达到成本与性能的最优化。
功能分配通常有System Weaver,PREEvison等架构开发工具来实现。通过将来功能模型，到不同映射提现不同的功能分配结果，并对不同的方案进行时序分析、负载分析、成本分析、可扩展性和功能安全分析，以确保设计之初的方案合理性。