曾经为了经历汽车功能软件开发的闭环，放弃了不错的软件开发机会而去了主机厂做功能开发，即FO（Function Owner），虽然所做的时间不长，但是收获颇多，写下来记着，也在此分享给有需要的人。

1 什么是功能开发

功能开发是FO的职责，主要内容如下描述：

为了更好地理解功能开发是什么，需要从整理功能开发过程说起，整车功能开发通常从市场分析开始，然后制定出满足市场需要的VTS，进而用SSTS描述抽象的逻辑关系，再由CTS说明实现方案，最后由零部件供应商具体落地实现。它们之间的关系如下示意：

VTS（vehicle technical specification），即整车技术规范，主要描述车辆与使用者的交互关系以及性能目标。

SSTS（sub system technical specification），即子系统技术规范，描述应用场景分析、信号交互和功能控制逻辑等。

CTS（component technical specification），即零部件技术规范，描述零部件供应商所需提供的控制器设计原理，包含控制芯片要求、电气原理图、控制功能逻辑、通讯诊断和休眠唤醒等内容。

其中，SSTS主要以子系统为中心，由多个控制器共同实现，而CTS主要以控制器为中心。CTS通常由零部件供应商提供或确认，其内容必须满足各SSTS中的需求内容。

所谓功能开发主要围绕着SSTS的内容进行，即应用场景分析，功能控制逻辑和通讯等内容，下面就以纯电动车动力总成系统的充电功能为例展开详细介绍。

2 怎么做功能开发

充电功能除了大家所熟知的交流充电（慢充）、直流充电（快充），交流放电（V2L），还包括预约充电，交流/直流桩供电以及V2V等功能。这里就借助交流充电来解释功能开发。

2.1 应用场景分析

用户的感知通常是插上交流枪，然后就开始充电了，在车的大屏或者手机端就可以看到当前的电量，充电剩余时间，充电电流和充电电压等信息。

source: Current Trends in EV Charging Infrastructure; Opportunities and Challenges

假如正在充电中，用户可能不想充了，那么可以在手机APP端或车的大屏点击相应的按钮来停止充电，甚至可能可以长按充电口盖或充电桩APP端的按钮来停止。

以上这些用户所能看到的信息和进行的操作，就属于功能开发的范畴，在SSTS中定义了用户可以看到哪些交流充电信息，允许用户能够进行哪些操作来影响交流充电功能，这就是功能开发的应用场景分析主要内容之一。

另外，应用场景分析还需要综合起来考虑用户行为，使得用户操作之后产生的现象符合预期，即各种行为交叠的时候，其交互逻辑不会产生冲突。比如正在交流充电过程中，用户通过手机APP端停止充电，但是又通过车的大屏再次启动充电，那么相应的现场应该是先停止充电，而后又进入充电。

除此之外，应用场景分析还需要结合一些典型的功能场景（比如交流充电，有使用公用充电桩充电，也有使用自己的专属的充电桩充电）来全面考虑，总之，从充电桩，手机APP端，车的大屏端以及充电口盖等因素综合分析之后，对产品功能有了全面的理解和清晰的定义，再来制定相应的功能控制策略。

2.2 功能控制逻辑

要制定好功能的控制策略或逻辑，必须要掌握一些基础知识，比如针对交流充电功能：

需要了解交流充电的基本过程，比如先通过CC电阻值识别充电枪的连接状态，再通过CP了解交流充电的进行状态等，具体可参考GB-18487。

需要了解整车电子电器架构，交流充电会涉及到哪几个控制器，比如动力总成系统的BMS，VCU和OBC等，其他总成系统的HMI和TBOX等；另外也需要知道各控制器分别承担哪些工作；比如OBC需要识别充电枪的连接状态，需要控制继电器以决定是否进行交流充电；BMS需要控制主正主负继电器上高压，也需要根据电池状态请求是否充电等。

需要了解整车网络拓扑，以决定信号交互怎样定义。

需要了解各个控制器的故障等级所对应的产品工作状态，比如BMS的1级别故障意味着BMS将断高压，停止工作。

source: EV charging configuration at AC level 1 and 2 setup

在上述的基础上，接下来就是制定功能的控制逻辑，即定义各个控制器的信息交互时序和逻辑，比如针对典型的交流充电功能，其控制时序如下图示意：

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

2.3 功能开发的关键点

关于功能开发的关键点，一方面得从SSTS说起，因为功能开发的最终交付物就是SSTS，SSTS明确规定了各个控制器需要做什么。既然规定了各个控制器需要做什么，那么前提是他们得知道为什么要这么做，所以第一个关键点：

首先就是需要与各个控制器的相关人员深入沟通，让他们知道你想做什么，然后基于他们的现状，你怎么做才是最好的方案，通过几个轮回的沟通与对齐，最终与各个控制器思想统一，理解在同一水平，再去落实到纸面的SSTS上。

source：Communication is the solvent of all the problems and is the foundation of personal development.

当确认好了实现的方案，接着第二个关键点：亲自去测试验证，杜绝眼高手低，停留在纸面SSTS上，尤其新手入门，测试是快速入门的必经途径。一方面针对功能需求定义好测试用例，另一方面可以通过台架或者实车自己去实践测试。基于测试结果分析在产品功能维度是否存在缺陷，以及在控制逻辑是否存在缺陷。

最后一个关键点：问题分析与解决，碰到问题是宝贵的财富，去分析问题本身就是最快速地了解整个功能，最迅速提炼出最主要的逻辑；以及找到问题点之后，如何协调来解决问题是很有“意思”也很有挑战的事情。

source: Planning for a Successful Document Collection

总而言之，沟通和实践是功能开发的两把强大的利器。除此之外，有想法也是至关重要的一点，就如为什么预约充电最开始是特拉斯做出来的，而不是其他OEM呢？做功能开发不能仅仅跟随，最好是自己能够玩出点花样。

就我做功能开发时，当我听说我们经常碰到两个问题：

问题1：控制策略的缺陷前期未识别出来，后期发现后需要时间来修改，导致交付压力问题特别大。

问题2：功能测试因为某个控制器无法如约交付，导致功能测试受阻，从而也影响交付。

基于我软件开发的背景，找到一个虚拟控制器系统的技术方案，不仅可以来助力解决这两个问题，而且还能构建整个动力总成系统的功能仿真与开发平台，以此支持纯虚拟和虚实结合的玩法。我觉得这也是功能开发的关键点，决定能否将功能开发的技术性提升几个维度。

参考：虚拟控制器（virtual ECU）到底有什么价值？

3 小结

以上就是个人对于功能开发的一点认识，写到此处，突然发现原来老板这么有技术野心，后面谈了几家，再也没碰到有此想法的。FO应该不仅仅要把功能开发做成一项高质量交付的工作，还要把功能开发做成一个技术含量高的活，好像以前在比亚迪有此类似的感觉。

本来我布局功能开发要干两个闭环：一个是功能开发与通讯和诊断；另一个是功能开发的仿真与测试。

以上有些内容已经介绍过了，链接如下：

一文了解汽车故障诊断的几个层级 (qq.com)

一篇易懂的整车网络管理指南 (qq.com)

虚拟控制器（virtual ECU）到底有什么价值？

另外，通讯可以参考CAN通讯系列文章。

所以我觉得如果做功能开发，先建立了一个宏观的技术概念与布局，然后再不断地实践每一项，同时也在不断磨练自己的沟通组织协调等软实力，应该会有一个不错的职业发展机会。