《漫谈ECU开发》1：应用层软件开发往事
引言
之前做了四五年的应用层软件开发，但后面转型了。目前觉得做应用层还是最有意思的，一方面是做软件开发比较纯粹，另一方面是做应用层可以上车调试标定，记得做驾驶策略和降档控制的时候，油门刹车各种踩，非常刺激！本文想通过回忆一些往事来大致介绍做应用层软件开发会涉及的方方面面。
注：本文不展开探讨非常具体的技术细节。
往事1 --HIL Plant
记得刚工作那会老板二话不说，直接让仿真DCT电液控制系统来入门，那时倒也合适干那活，本身偏学术思维，把电磁阀模型研究一通，AMESim模型跑得溜溜的。接着又让搭建整车传动系统模型，说是为了联合AMESim模型和整车传动系统Simulink模型后续仿真变速箱控制策略铺垫，泡在论文里，联合模型终于跑起来了，但是会很纠结零部件模型（离合器，传动系）的细化程度。后面回头再看，这其实就是为应用层软件开发整一个HIL台架的plant。
为了这个Plant，当时测试中心竟然提供了台架资源来支持标定离合器特性曲线，变速箱设计部门提供了变速箱Adam模型来支持换挡控制策略的精细仿真；量产项目提供了大量的样车供实车测试。现在回想，多么强力的支持！回归到HIL台架的plant搭建经历，确实对整车动力总成理论有了系统性掌握，但至于细化到何种程度仍然是迷糊的，因为不清楚应用层软件要做到何种程度。
非常有意思的一段工作经历，现在来看最受益的一点就是：要了解一个主题或事物，知道如何去寻找资料，构建该主题或事物的基本认识。
往事2 --从0开始
当时是预研项目，没有高薪聘请专业人士，几乎是从0开干变速箱控制。不知者无畏，我们3只小白鼠，从0开始剖析大量变速箱零件与控制的论文和专利，从0开始大量逆向测试竞品车的控制策略，从0开始整个变速箱控制的底层代码和应用层模型，从0开始实验室和测试车上标定和测试。短短一年多时间，竟然车还跑起来了。
突然想起咱还用CAD设计了个简易台架，简直无所不能！从机械，到电子，再到软件；从台架，到测试，再到标定；从文档，到流程，再到项目管理，全方面萌芽！正是经历过过往的从0开始的经历，留下了非常多待解的难题，在日后身在成熟的软件开发项目，会带着一种探知未知的好奇，去了解方方面面，会很受启发，原来可以这样来做。
我想可能是这样：每个人都有自己的路，有的你一开始就在成熟的平台，有的你却不是这样，但是每条路都走得通，只要你坚持向上，也许这就是殊路同归吧！在这个圈子，事总是那么些，当然这里不谈选择比努力更重要，因为你都在路上了。
回归到主题，当时我核心工作是应用层开发。首先来说说个人对整个应用层软件架构（变速箱控制）的理解：变速箱的主要功能是要实现起步，换挡，动力中断，通过同步器和离合器运动来实现。
这时我们就需要一套执行器系统来控制同步器和离合器运动，可以是电动的，也可以是液压的。不管是哪种都需要得到具体的控制命令才执行，那控制命令要怎么给？一个要挂什么档，另一个要控制哪个离合器到哪个位置，来自于需处理的驾驶工况，可能是要起步，也可能是要换挡。怎么知道是要起步还是换挡，根据传感器监测的轴转速，离合器位置或者驾驶员的请求。在此进行抽象一下：
需要有输入的模块，处理来自整车其他ECU的信息，和传感器采过来的数据； 需要有识别驾驶工况的模块，来决定一个合理的档位，来满足司机的加速和速度需求； 需要有给执行器发号施令的模块，来决定执行器怎么去运动，才能保证司机开得很爽很舒服 需要有执行器自身精确控制的模块，输出给执行器，保证命令能贯彻执行到位。
这样根据系统地分析，抽象了一个应用层软件架构的主干。当然架构这博大精深，不是这样纸上谈兵，自行去细细实践再实践。
没有放之四海皆准的好与坏的标准。对于衡量软件架构好坏的AAA原则：
> 可考核（Accountable）：好的软件架构让每个团队都有自己负责的业务目标；
> 可自主（Autonomous）：好的软件架构让每个团队都一定的自主性可以独立往前跑，而不总是被其他团队阻塞；
> 可复用（Amortized）：好的软件架构鼓励对未来投资，使得基础设施的成本可被摊销。
然后是MBD（基于模型设计V流程开发）。因为MBD是图形化建模，像搭积木一样，另外可以通过仿真看现象，所以上手不难。再加上参考资料很多，Mathworks每年都举办研讨会，对Simulink和Stateflow的基本使用没啥问题，也能满足日常工作需求。但工具难在深入掌握，因为平时工作需要用到的高阶技巧很少，而且大多数人一般也不懂工具背后的机理。
印象很深刻的是Mathworks免费研讨会还提供免费的五星级酒店自助餐，快乐摸鱼一天，另外在其官网的研讨会录像把V流程的模型开发测试介绍清晰明了。
说完了应用层架构和工具，再来说说模块开发。当时通过论文了解基本原理，再结合实车测试数据来辅助模块开发，通过这种方法，最终起步，升档和降档过程都勉强能行，虽然顿挫，异响，刚开始心里还是蛮激动的。回过头再看，其实与量产还有质的差距，一方面是对应用场景工况的理解，另一方面是菜鸟没有工程应用经验。这样探索了一段时间的模块开发后，发现好像自己在围城里原地转圈，有很多问题但没有解决的头绪，也没有人可问。
从0开始，人力和技术支持都不够，确实有点不可思议，怎么都要有几个极具天赋的天才来做才行，反正我最终放弃了。不过这段经历还是很有意思的，有过快速成长的过程，掌握了变速箱控制的应用层MBD开发的V流程方法，当时换工作必备技能；积累了从模型到实车调试的经验；当然也有过很多迷茫无助的时候，不知道如何有效地改善顿挫异响，不知道如何准确抗饱和PI控制，也不知道如何设计自学习策略；所以为了解开这些谜底，离开是最好的选择，去寻找美丽新世界吧。
往事3 -- 新世界
话说运气也不错，确实来到一个新世界，成熟的平台，开放整个变速箱控制的代码和模型，具有成熟而完善的工具链和项目管理（流程和数据），以及绝对大神的专家支持。遗留的历史问题都可以一一得到答案，下面讲讲个人认为应用层软件的最核心点：
3.1 实际工况的处理，这里降档所涉及的工况来说明。
正常降档两种类型：动力降档和无动力降档。每种都分为几个阶段，包括预挂挡，充油，转矩相，惯性相，降档结束。
在降档控制过程中，工况可能是随时变化的，比如司机前一刻急踩油门超车，那么会动力降档，但是突然司机发现超车有危险，下一刻立马改变注意，急松油门了。这就意味着应用层软件就需要实时准确地识别出各种各样的驾驶工况，同时随着驾驶工况的变化，当前正在进行的操作可能得取消，立马切换到下一工况控制，这里就会涉及到如何去切换、过渡。控制不好就会出现顿挫，抖动，令人很不舒服；控制好那就人车合一，车随心动的感觉。我曾经细细研究了一番：一方面是这些驾驶工况怎么去识别；另一方面是当前处于的阶段应该切换到哪个阶段去，以及如何做切换的精密控制。突然有一种菜鸟入门，体会到了应用层软件的博大精深，敬畏之心更重几分；当然很乐在其中，也很想上车去琢磨个遍（可惜项目结束没车给玩了）。
总的来说，应用层软件开发者，绝对不是常年待在办公室，而是常年开着车实践，去体会工况的变化，去体会切换的流畅，也去体会标定的影响。当然理论其实也很重要，但是理论一旦掌握，实践才是王道。
3.2 常用的技术
应用层软件中经常会涉及到信号的切换，也就是从一个信号过渡到另一个信号，常用的技术就是：
随着时间的累加， k 值逐渐增加，直到1。
还有就是PI控制，注意没有D，目前为止，在变速箱控制没有看到除了PI控制的更先进控制算法，但是感受到了使用PI控制的千变万化，首先是PI控制的类型，区别在于是否带前馈控制。
有些控制需要用到带前馈调节的PI控制，不带的话效果差别很大，在变速箱控制带前馈的PI控制非常多。
其次是P值和I值的调节，通常都采用标定的方法，也就是说需要根据某些物理量的变化来确定具体的P值和I值，比如转速，温度，压力等物理量。这样通过标定，不断地优化调节P值和I值，就可以一步一步地逼近最佳的控制效果。
通过上述仅仅标定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有更深入的理解，那能更进一步。
总之，每个人都有自己的路，不管是选择了应用层软件开发还是底层软件开始，只要你在这条路坚持着，不管你选的路是广博还是精深，都可以的。