整车功能开发

谈思实验室 2024-10-10 17:48 494浏览 0评论 0点赞

汽车照明系统的“智慧大脑”，竟然是它？》 一站式登记香港贸易发展局各个商贸展览

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

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

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、功能的大致交互框图，输入、输出和中间的决策定义。
5、功能的具体Use case（重点）设计

一个完整的UC，应当包含该：

UC的目标：该UC要实现的目标，如激活Auto Hold
UC的前置条件：如整车的电源模式，整车的配置，相关系统的无故障等
UC的触发条件：如车速为零，或者制动踏板在多少时间内踩动两次，等等
UC的主流程：也就是用户的操作及车辆的期望响应，如把大象关进冰箱分几步，第一步打开冰箱门，第二步把大象赶紧去，第三步关上冰箱门。
UC的支线流程：达到同样的目标，其他的操作步骤
UC的异常流程：设计一定的保护措施保证功能的有效性。

6、功能属性目标，如Auto Hold这块的加载响应时间，释放响应时间，可在多少角度的坡道上进行驻车等等
7、其他信息安全、功能安全的设计要求。

整车功能开发流程

功能开发的起点-整车功能清单。功能开发的核心-功能设计，功能开发的下游-系统设计、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。

功能分配

功能分配功能分配是架构设计的中间步骤，功能分配设计须具备一定的前提条件才能进行。E/E架构设计始于功能需求。

功能的逻辑架构是以功能规范为基础设计的功能模型，功能分配是将不同的功能模型映射到控制模块的过程。功能分配是架构设计中的一个关键步骤，通过功能分配，导出最终的架构设计方案，形成网络拓扑，输出最终的系统方案。

如图功能分配设计过程图（其中虚框内为功能分配过程）。功能分配的前提条件是各功能的功能规范以及逻辑模型等。