应用层软件开发的一些总结

0 前言

做了几年的应用层软件开发，觉得非常有意思。一方面可能是做软件开发工作还是比较纯粹，另一方面可能是做应用层软件可以在上车调试，尤其想起做驾驶策略和降档控制那会，经常需要各种节奏踩油门踩刹车，非常狂暴，非常刺激！本文想通过几件往事来大致总结下应用层软件开发的一些内容。

1 HIL 台架物理模型的搭建

我的职业生涯是从 HIL 物理模型的搭建开始的，虽然那时我还不知道什么是 HIL，但是那会刚出学校出来，仿真还是很在行的。当科长直接让我仿真 DCT 电液控制系统，记得刚接到任务的时候，什么是 DCT，什么电液控制系统，通通都没有概念，但也不慌，可能自己偏学术思维一点，不会就找书找论文，一步一步地看一遍。哦，原来 DCT 是指双离合器自动变速器，电液控制系统关键在电磁阀，把电磁阀模型研究一通，搭建了 AMESim 模型，也跑得溜溜的，看来还是适合做这个工作。

接着科长又让搭建整车动力总成的传动系统模型，意在为了联合 AMESim 模型和传动系统 Simulink 模型后续仿真变速箱控制策略铺垫，依葫芦画瓢，继续泡在论文里一阵子，对着论文把模型给搭建好了，也联合起来了，这下子联合模型终于跑起来了。虽然很顺利，但是也很纠结零部件模型（离合器，传动系）的细化程度。后面回头再看，这确实很难确定细化的程度，因为这就是为应用层软件开发整一个 HIL 台架的 plant，没有对应用层有一定的了解嘛！

源于: Model-Based Design Methods for the Developmentof Transmission Control Systems

现在回想到 HIL 台架物理模型搭建的经历，确实让自己对整车动力总成理论有了系统性掌握，但至于细化到何种程度仍然是迷糊的，因为不清楚应用层软件要做到何种程度。非常有意思的一段工作经历，现在来看最受益的一点就是：要了解一个主题或事物，知道如何去寻找资料，构建该主题或事物的基本认识。

2 从 0 开发应用层软件

从一个预研项目开始，当时只有用不完的箱子和执行器总成和一群从高校毕业的小白鼠，不想现在可以高薪聘请专业人士，一个不够再加几个都行。当时基本上是从 0 开始开发变速箱控制。不知者无畏，我们从 0 开始剖析大量变速箱零件与控制的专业论文和相关专利，从 0 开始大量逆向对标竞品车的控制策略与算法，从 0 开始整个变速箱控制的底层代码和应用层模型，从 0 开始实验室和测试车上标定和测试。这么多从 0 开始，竟然在短短一年多时间把车子基本上跑起来了。

想起那时除了上面的那些工作，自己还用 CAD 设计过一个简易台架，简直是无所不能！从机械，到电子，再到软件；从台架，到测试，再到标定；从文档，到流程，再到项目管理，全方面萌芽！现在回想起来，正是经历过过往的从 0 开始的经历，让人有种无所畏惧的心理，光过脚就不拍没鞋穿。当然这些多从 0 开始，肯定会留下很多待解的难题，所以这也激励着自己在日后身在成熟的软件开发项目时，会带着一种探知未知的好奇，去了解方方面面，然后会很受启发，原来是这样做的，还可以这样做啊。

也许就是这样：每个人都有自己的路，有的人一开始就在成熟的平台，平台教你怎么做；有的人却不是这样，得自己去想怎么做；虽然看似不同，但是每条路都走得通，只要你坚持向上，也许这就是殊路同归吧！在这个圈子，事总是就这些，当然这里不谈选择比努力更重要，因为你都在路上了。

感触很深，影响也很深，不过还是回归到应用层软件这个主题吧！当时我的核心工作是应用层软件开发。

首先来说说个人对整个应用层软件架构（变速箱控制）的理解：变速箱的主要功能是要实现起步，换挡，动力中断，通过同步器和离合器运动来实现。

这时。我们需要一套执行器系统来控制同步器和离合器运动，可以是电动的，也可以是液压的。不管是哪种都需要得到具体的控制命令才执行，那控制命令要怎么给？一个要挂什么档，另一个要控制哪个离合器到哪个位置，来自于需处理的驾驶工况，可能是要起步，也可能是要换挡。怎么知道是要起步还是换挡，根据传感器监测的轴转速，离合器位置或者驾驶员的请求。在此进行抽象一下：

• 需要有输入的模块，处理来自整车其他 ECU 的信息，和传感器采过来的数据；

• 需要有识别驾驶工况的模块，来决定一个合理的档位，来满足司机的加速和速度需求；

• 需要有给执行器发号施令的模块，来决定执行器怎么去运动，才能保证司机开得很爽很舒服

• 需要有执行器自身精确控制的模块，输出给执行器，保证命令能贯彻执行到位。

这样根据系统地分析，抽象了一个应用层软件架构的主干。当然架构这博大精深，不是这样纸上谈兵，自行去细细实践再实践。

没有放之四海皆准的好与坏的标准。对于衡量软件架构好坏的 AAA 原则：

> 可考核（Accountable）：好的软件架构让每个团队都有自己负责的业务目标；

> 可自主（Autonomous）：好的软件架构让每个团队都一定的自主性可以独立往前跑，而不总是被其他团队阻塞；

> 可复用（Amortized）：好的软件架构鼓励对未来投资，使得基础设施的成本可被摊销。

然后是 MBD（基于模型设计 V 流程开发）。因为 MBD 是图形化建模，像搭积木一样，另外可以通过仿真看现象，所以上手不难。再加上参考资料很多，Mathworks 每年都举办研讨会，对 Simulink 和 Stateflow 的基本使用没啥问题，也能满足日常工作需求。但工具难在深入掌握，因为平时工作需要用到的高阶技巧很少，而且大多数人一般也不懂工具背后的机理。

印象很深刻的是 Mathworks 免费研讨会还提供免费的五星级酒店自助餐，快乐摸鱼一天，另外在其官网的研讨会录像把 V 流程的模型开发测试介绍清晰明了。

说完了应用层架构和工具，再来说说模块开发。当时通过论文了解基本原理，再结合实车测试数据来辅助模块开发，通过这种方法，最终起步，升档和降档过程都勉强能行，虽然顿挫，异响，刚开始心里还是蛮激动的。回过头再看，其实与量产还有质的差距，一方面是对应用场景工况的理解，另一方面是菜鸟没有工程应用经验。这样探索了一段时间的模块开发后，发现好像自己在围城里原地转圈，有很多问题但没有解决的头绪，也没有人可问。

源于：模型开发在 DCT 控制软件中的运用

从 0 开始，人力和技术支持都不够，确实有点不可思议，怎么都要有几个极具天赋的天才来做才行，反正我最终放弃了。不过这段经历还是很有意思的，有过快速成长的过程，掌握了变速箱控制的应用层 MBD 开发的 V 流程方法，当时换工作必备技能；积累了从模型到实车调试的经验；当然也有过很多迷茫无助的时候，不知道如何有效地改善顿挫异响，不知道如何准确抗饱和 PI 控制，也不知道如何设计自学习策略；所以为了解开这些谜底，离开是最好的选择，去寻找美丽新世界吧。

源于：https://zhuanlan.zhihu.com/p/25248541

往事 3 -- 新世界

话说运气也不错，确实来到一个新世界，成熟的平台，开放整个变速箱控制的代码和模型，具有成熟而完善的工具链和项目管理（流程和数据），以及绝对大神的专家支持。遗留的历史问题都可以一一得到答案，下面讲讲个人认为应用层软件的最核心点：

3.1 实际工况的处理，这里降档所涉及的工况来说明。

正常降档两种类型：动力降档和无动力降档。每种都分为几个阶段，包括预挂挡，充油，转矩相，惯性相，降档结束。

在降档控制过程中，工况可能是随时变化的，比如司机前一刻急踩油门超车，那么会动力降档，但是突然司机发现超车有危险，下一刻立马改变注意，急松油门了。这就意味着应用层软件就需要实时准确地识别出各种各样的驾驶工况，同时随着驾驶工况的变化，当前正在进行的操作可能得取消，立马切换到下一工况控制，这里就会涉及到如何去切换、过渡。控制不好就会出现顿挫，抖动，令人很不舒服；控制好那就人车合一，车随心动的感觉。我曾经细细研究了一番：一方面是这些驾驶工况怎么去识别；另一方面是当前处于的阶段应该切换到哪个阶段去，以及如何做切换的精密控制。突然有一种菜鸟入门，体会到了应用层软件的博大精深，敬畏之心更重几分；当然很乐在其中，也很想上车去琢磨个遍（可惜项目结束没车给玩了）。

曾经的琢磨手记

总的来说，应用层软件开发者，绝对不是常年待在办公室，而是常年开着车实践，去体会工况的变化，去体会切换的流畅，也去体会标定的影响。当然理论其实也很重要，但是理论一旦掌握，实践才是王道。

3.2 常用的技术

应用层软件中经常会涉及到信号的切换，也就是从一个信号过渡到另一个信号，常用的技术就是：  , 随着时间的累加，  值逐渐增加，直到 1。

还有就是 PI 控制，注意没有 D，目前为止，在变速箱控制没有看到除了 PI 控制的更先进控制算法，但是感受到了使用 PI 控制的千变万化，首先是 PI 控制的类型，区别在于是否带前馈控制。

有些控制需要用到带前馈调节的 PI 控制，不带的话效果差别很大，在变速箱控制带前馈的 PI 控制非常多。

其次是 P 值和 I 值的调节，通常都采用标定的方法，也就是说需要根据某些物理量的变化来确定具体的 P 值和 I 值，比如转速，温度，压力等物理量。这样通过标定，不断地优化调节 P 值和 I 值，就可以一步一步地逼近最佳的控制效果。

源于：https://ww2.mathworks.cn/company/newsletters/articles/optimizing-performance-and-fuel-economy-of-a-dual-clutch-transmission-powertrain-with-model-based-design.html

通过上述仅仅标定 PI 参数其实还是不够的，实际应用还需要做很多的限幅和抗饱和处理。比如可能需要对 P 值或 I 值或两者调节后的输出值做限幅处理，可能需要对 I 值做抗饱和处理。印象中见到过需要根据不同的工况去进行 I 值抗饱和，处理地非常精细。

3.3 scaling

因为 scaling 总是有点让人迷糊，就是你以为你懂了，但是下一次碰到的时候，你又要理顺一遍才行。对 scaling 印象深刻的原因是曾经碰到了一个 scaling 设置不对导致精度不准情况，有过深入分析并解决了。我的理解 scaling 出现是因为让软件没有浮点运算，用 scaling 将浮点运算转化为整型运算，有时会出现精度损失而达到控制效果。打个比方：一个浮点数 0.25，在 scaling 为 0.25 的情况下，转化之后物理值仍为 0.25，这时精度没有损失；而 scaling 为 0.1 的情况下，转化之后物理值就为 0.2 了，这时就损失了 0.05。假如这个浮点数去乘以 1000N 的力，那就意味着 scaling=0.1 时，损失了 0.05x1000=50N 的力，这时有可能会导致控制效果不好了，那么就应该重新选择合适的 scaling。

3.4 模型到代码

由于应用层软件通常都是基于模型自动生成代码，所以多数工程师会更多关注模型而非代码。这样通常会忽视几个问题：一个是可能忽视工具链是怎么回事？就是指模型自动生成代码的逻辑或配置，或者说生成代码再编译成可执行文件格式过程，或者说自动生成供标定使用的 A2L 文件等。在成熟的项目平台，通常只需要点击按钮或敲几个命令就实现了，用着习惯就习以为常了，自然就不会去深入思考了，思维惰性嘛！但是了解工具链的背后知识，有时能让你快速地找到产生 error 的原因，不管是代码生成过程还是集成编译过程。

另一个是数据管理。在模型里，需要定义各种变量类型，有常量，有宏定义，有局部变量，全局变量，也有标定常量，标定表。通根据要求的定义选择正确的变量类型就好，但是我一直很好奇，为啥那谁就是标定量，而为啥那谁就是非标定量，后来才明白：

#pragma section farrom "xxx_cal"#pragma for_constant_data_use_memory far#pragma align 4#pragma data_core_association share#endif
// 此处开始标定量的定义.........// 此处结束标定量的定义
#pragma section farrom restore#endif

原来通过上述语法，相当于把圈住这些标定量，放在了 xxx_cal 部分，而这个 xxx_cal 其实在 linker control file 映射着 MCU 的内存部分。总的逻辑来说是这样：先确定好 MCU 的内存分配，哪些部分放代码，比如 0X8000 0000- 0X801F FFFF 放代码，哪些部分放标定，比如 0X8000 0000- 0X803F FFFF 放标定，这样依次还在 linker control file 定义好；然后应用层软件和底层软件就会采用上述代码 #pragma 来规定代码放哪里，标定放哪里。

总的来说，应用层软件的学问非常博大精深，有句话说的好：纸上得来终觉浅，觉知此事要躬行。应用层软件来源于应用场景，环境，工况，这要躬行！应用层软件不仅要实现应用功能，也保证使用性能，精细活，这更要躬行！应用层软件本质是软件，软件知识越丰富越好！

总结

通过上述个人经历的几件往事，希望能大致讲明白了应用层软件是怎么回事。简单来说，就是在理解产品的应用场景、工况的基础上，掌握产品方面的专业知识，熟练运用通用的控制技术，以及对标定有一定的了解，那么就基本把握了应用层软件的核心内容；继而在车或者 HIL 台架进一步去测试验证所设计的应用层软件，并不断优化，以满足功能和性能的要求。

当然再能对开发工具掌握得更牢靠，对 MCU 有更深入的理解，那能更进一步。

总之，每个人都有自己的路，不管是选择了应用层软件开发还是底层软件开始，只要你在这条路坚持着，不管你选的路是广博还是精深，都可以的。

文章来源：上汽零束 SOA 开发者论坛

原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7504