《漫谈ECU开发》1：应用层软件开发往事.docVIP

《漫谈ECU开发》1：应用层软件开发往事 往事1 --HIL Plant 记得刚工作那会老板二话不说，直接让仿真DCT电液控制系统来入门，那时倒也合适干那活，本身偏学术思维，把电磁阀模型研究一通，AMESim模型跑得溜溜的。接着又让搭建整车传动系统模型，说是为了联合AMESim模型和整车传动系统Simulink模型后续仿真变速箱控制策略铺垫，泡在论文里，联合模型终于跑起来了，但是会很纠结零部件模型（离合器，传动系）的细化程度。后面回头再看，这其实就是为应用层软件开发整一个HIL台架的plant。 源于: Model-Based Design Methods for the Developmentof Transmission Control Systems 为了这个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流程的模型开发测试介绍清晰明了。 说完了应用层架构和工具，再来说说模块开发。当时通过论文了解基本原理，再结合实车测试数据来辅助模块开发，通过这种方法，最终起步，升档和降档过程都勉强能行，虽然顿挫，异响，刚开始心里还是蛮激动的。回过头再看，其实与量产还有质的差距，