浅谈Simulink/StateFlow建模

   

浅谈Simulink/StateFlow建模

       在汽车、工业控制、航空航天等行业，系统与软件开发中，基于模型的设计（Model based Design，简称MBD）逐步在替代传统的手工代码开发方式，在MBD领域，Matlab/Simulink做为通用化的建模与代码生成工具及其相关配套的工具链通过多年的积累，已经在国内外以上行业中被应用到产品的开发中。

      在笔者所处的行业，因为对象的强非线性、多变量耦合性、时变特性以及被控对象和控制器的复杂性，在算法、容错处理以及控制逻辑多方面都有着较高和较复杂的要求，并且以上几方面经常是耦合在一块儿。基于以上考虑，不管是对被控对象仍是控制器，建模是一件很是必要的事情。而Simulink是无疑是首选！

       Simulink是从学生时代就接触的一种通用化建模工具，这一工具一样也陪伴着走上工做岗位。工做的前两年，因岗位关系，精力更多的投入到了控制算法的设计与验证上，相关算法最终也能够用MBD方式生成代码，同时也积累了必定的实际应用经验，当前负责的业务通过积累，有了相对的突破。但，随着接触更多更复杂的项目，总感受有点缺憾，毕竟，我的对其余容错处理及控制业务逻辑的关注却相对较少，必定程度上形成了本身视野偏窄，岗位更多的定位在仿真验证上，这种外部限制也让本身“鞭长莫及”，有些对自我提升有帮助的工做因不是本身负责，没法作到全身性的学习与工做结合，对整个控制对象的控制过程的理解天然会有所欠缺。好在后来上层对当前工做职责的界限也有了从新的认知，有幸能在新项目中全面贯彻应用层都进行建模的要求，并且，代码的需求则直接源自更上层的需求以及模型，中远期必然是走MBD的方式。

一旦负责了整个应用层的建模，则必须将以上提到的容错处理、算法以及逻辑上进行通盘考虑。其实，这时候做为建模人员，最重要的就是根据需求结合实现进行架构设计，这里的架构设计，从我当前的认知来讲，就是基于对工做场景的识别来进行功能的解耦与划分，场景又能够分为大场景与小场景，大场景一般采用状态机（StateFlow）来定义，小场景则既能够参考大场景来进行独立设计成模块也能够和功能模块进行耦合，视具体状况和我的经验而定，功能解耦则主要体如今不一样功能最终须要用同一具体控制机构（被控对象与控制器之间还存在执行机构）来实现，这时候既要划分不一样的功能，又要有最终具体控制机构的综合，在功能模块中实现功能，在具体控制机构模块中实现综合，这里的综合更多的体如今优先级的断定与最终输出量的抉择上，以上的经验也是通过不少项目的实践和妥协得来的，未必说得上通用最优，但能够说是针对复杂对象进行控制建模的较好的方法，是一种不错的架构设计实践。

    通过几个月项目“锤炼”，多番需求的迭代与评审，多轮建模设计，在某个瞬间忽然就开窍了，感受一会儿提升了需求的把控能力，不管是大方向仍是具体细节，任何一个需求的更改，都能在脑子里快速进行需求的分解并创建初步的Simulink模型，即将需求具体化，而所谓的建模，其实就是编码实现，由于模块化的建模即对应相应的函数代码。

    值得注意的是，Simulink模型一般都是基于数据流的，任何输入必须对应相应的输出，不管输出是中间量仍是最终量都有其对应的物理含义，即使这种含义是人为赋予的；这与C代码在常规上仍是区别的，在C语言中，某个全局变量可能随时会根据不一样的状态进行变化，这样容易致使某个变量在多个功能中赋值，这种处处赋值的危害是显而易见的，除非实现约定好其中的某几个，不然无约束必将致使混乱。在Simulink建模中同时被说起的还有StateFlow这一功能，StateFlow能够创建状态机也能够进行流程设计，甚至能够调用Simulink模块，调用很是灵活，但灵活带来的也是复杂性，事实上StateFlow更接近于手工代码，为了实现某个相对复杂的逻辑采用StateFlow来实现，既有状态又有代码，这种形式实际上就是把C代码进行一种函数封装，但显然不具有通用性，与Simulink混用，用的很差很容易打断数据流，让人产生混乱，所以，从我的角度，通常不推荐大量使用StateFlow。建议在如下几种场景下使用：

1、对于大量使用的基准模块，若用StateFlow实现更简单；

2、对于大的场景定义，推荐使用，同时不推荐把具体功能放在状态机里边实现；

3、对于综合模块，推荐使用。

    对于状态中经常使用的功能，则经过产生标识（进入与推出条件完备）与输出，由Simulink实现，来给综合模块进行抉择。

    限于工做性质，只能啰啰嗦嗦这么多，估计也就本身听懂了，毕竟以上经验之谈有行业的局限性，未必适合其余的，权当是前阵子工做的一个小结吧。