汽车电子软件行业的从业人员，对MISRA都不陌生，这个组织制定的编码规范MISRA C被整个工业界广泛使用。作为汽车行业软件可靠性协会这样的组织，对于汽车行业软件开发中最为流行的MBD软件开发模式，自然也想有自己的贡献。所以，早在2009年，MISRA就发布过一份SL/SF建模指南，个人认为，这份规范的质量并不高，也许这也是为什么这份建模规范并没有像MISRA C那样被大面积推广的原因。最近从客户那里得知，MISRA的SL/SF建模指南发布第二版了，那我们就一起来看看这份规范到底如何？文档中提到，为了帮助SL/SF用户建立高质量的模型，高质量有如下要求：功能正确、可读、可靠、可维护、可无缝用于代码生成、所有工程师遵守统一风格。没错，貌似没有考虑模型的可验证性（Verifiable），不过还好，在后面每条规则的目标中，有可测性（Testability）的考量。文档中的规则按照优先级分为Advisory和Required两类。好，下面开始逐条解读这份文档中的规则（Rules）。
MISRA AC SLSF 001: Usage of Simulink and Stateflow
A. Simulink is recommended for mathematical operations, signal flow and feedback algorithms. Stateflow is recommended for combinatorial logic, schedulers and finite state machines.目标：Maintainability，Usability，Testability，Efficiency【点评】这条规则也是很多初学者比较关心的问题，同样一个算法，Simulink可以实现，Stateflow也可以实现，到底如何选择？规则告诉我们，Simulink推荐用于数学运算、信号流、反馈算法；Stateflow推荐用户组合逻辑、调度器、有限状态机。这条规则基本上是大家的共识，稍微有点经验的工程师在设计软件的时候也基本上这么操作。写到这里，想起发生在10多年的一个小故事。Xx公司给日本的OEM做车身控制器产品，应用层软件使用是MBD方法开发，日本客户有自己的建模规范，其中有一条规则就是：如果Stateflow Chart里只有两个状态，那么不允许使用Stateflow，要改成Simulink实现。这家公司把模型交付给客户评审之后，因为上述规则，被要求把只有两个状态的Stateflow Chart改成了Simulink模块实现，有意思的是，当他们把改好的模型再次提交给客户，客户看完之后让他们又改回了Stateflow Chart。我猜，这家日本OEM的建模规范不是那些逻辑密集型算法开发者制定的，也就是说，规范制定者很可能是Simulink重度用户，而对Stateflow不够熟悉。MISRA AC SLSF 056: Simulink within Stateflow charts and flow chartsA．Simulink functions shall not be used in Stateflow charts or flow charts.目标：Usability，Maintainability，Efficiency 【点评】这条规则的理由是Stateflow里嵌入Simulink会增加Stateflow算法的复杂性。非常同意这种说法，实践中，我也基本上不在Stateflow Chart里使用Simulink function，但是，我有例外，如果Stateflow算法中会涉及到现成的Simulink模块就可实现的算法，比如，最常见的查表函数，相比于自行设计查表算法，或者通过调用外部function call 子系统的方式调用查表模块，直接在Stateflow里通过Simulink function调用查表模块岂不是更为方便？
好吧，今天先写这两条，后续会不定期持续更新。也许有人会问，为什么不解读MAB？很简单，MAB太长了，先从MISRA写，如果大家喜欢这个系列，写完MISRA就再写MAB。
![]()
