-
-
手机阅读
基于有限状态机的工控系统软件设计 |
| 摘 要：通过分析工控系统的特性，提出采用状态机的思想进行工控软件设计。详细论述了高速状态机的错步问题以及控制层中状态机的状态划分问题。结合具体的应用实例，给出了基于状态机的实现方法。实验表明，采用状态机的设计方法有助于准确描述受控对象的行为，软件的健壮性和可靠性得到显著提高。 关键词：有限状态机 工控软件 控制环 状态划分 1. 引言 1.1 工控软件的一般问题 工控软件设计可分为基于控制环和基于实时操作系统两大类。控制环是把各个功能模块连接成首尾相接的环状结构。其特点为任何一个功能模块都不能出现死循环，甚至循环次数太多的循环语句都应避免出现。以保证能够在实时意义上尽可能快地遍历各功能模块，从而满足实时多任务的需求。在各功能模块中一般用状态机来描述模块所处的状态。而实时操作系统则可以通过一套底层机制根据优先级和各任务状态调度各功能模块。此时各功能模块就以“任务”作为表现形式。但是在每个任务内部仍然为一个独立的控制环结构，仍然需要用状态机描述。本文将结合工程实践论述状态机在工控中的应用，给出通用模型和注意要点。 1.2 有限状态机 有限状态机是一种重要的思想方法。从数学的角度看，它实际是一个五元组M = （I, O, S, δ, λ），其中I，O分别表示输入输出，S为状态向量，δ为次态方程（δ: S×I ->S）， 表示输出方程（λ: S×I -> O）。有限状态机从结构体系上有层级状态机，并发状态机等。层级状态机类似于软件中的子程序调度：更高层的一个状态对应于较低层的一个状态机。这个高层的状态处于底层状态机的某个状态中。这个低层状态称为子状态。与子程序调用受到系统堆栈深度制约不一样，层级状态机可以由开发者根据控制对象的层次性运动规律任意指定深度。与子程序的目的一样，层级状态机也是为了提高控制软件的模块化程度，降低状态分析的复杂度。并发状态机偏重于描述状态机的调度。状态机本身不能实现什么并发功能，并发的实现是通过软件调度的。如果把状态机理解成一个任务，那么就能理解并发的实现。在控制环中，一个“任务”就是一个功能模块，我们只需要把多个状态机串联在环中，也就是实现了多输入多输出的并发控制。此时，多个状态机在空间上是并存的，然而却是分时调用的，调用的周期等同于控制环扫描一周的时间。不过如果CPU运算速度足够快，这个周期将会足够的快，达到“实时”的程度，从而这多个状态机也就实现了“并发”运行。同理，在多任务操作系统中，“并发”的实现就更容易理解了，除了在单个任务内存在控制环的并发控制外，在任务之间也同样存在多状态机的并发运行。当然，从CPU的角度而言，只要是单核的，也就从来不存在真正的“并发”，它在任何一个特定的时间点都只能处理某个特定状态机。不过多任务操作系统却提供了一套底层机制来调度原来仅靠控制环来调度的任务。 2.有限状态机在前后台信息交互中的作用 工控系统一般都具有人机对话界面。其通常的操作模式为用户进入某个页面，选取某项操作并执行。人机对话界面通常被设定为一个独立模块。该模块软件结构为一个消息控制环。用户在硬件接口的操作会通过接口的驱动程序封装成消息加入到专属界面模块的消息队列中。消息控制环循环扫描该队列，如有新消息则提取并解释然后封装成新消息发往后台执行。前后台软件的接口模块负责分发界面消息到各个执行模块。消息应包括目标模块的编码，命令编码以及命令参数。前后台接口模块的软件结构多采用以下两种模式。  图1 两种消息分发结构 模式一的输出结构根据消息数据的目标模块编码直接分发消息到各模块中。模式二则是根据当前系统所处的状态再分发消息到各模块中。也就是说模式二在模式一的基础上增加了一个系统级的状态机。下面我们看看两种不同的输出结构会带来何种影响。 工控软件设计者通常会碰到两种情况。一是在研发阶段，界面任务与控制任务联调时，双方均有可能出错。对于界面任务而言，有可能自身原因误发消息;而对控制任务，也有可能输出时序出错。此时需要在联调中快速定位故障，缩短研发周期。二是在产品运行中由于恶劣工况的影响，导致缓冲区数据发生异常。比如消息头的模块编码发生位翻转，则会直接导致控制任务接收到错误的界面消息。对于模式一，如果界面消息出错则会出现全局的混乱。比如模块1收到消息后开始输出一个控制时序，期间界面层又发来一个错误的消息，使其分发到模块2，于是模块2马上开始输出时序。这个不希望输出的时序在工控中有可能会导致灾难。而在联调时出现这种现象，则无法立刻判断到底是模块1还是界面层出的问题。但如果采用模式二则可以屏蔽这种混乱。如下图  图2 不同分发结构对错误消息的处理示意图 我们可以看到由于模式二采用全局状态机标定当前软件所处的状态，消息首先会到达相应的状态处理程序，然后才进行分发。此时分发语句可以根据当前的状态屏蔽不应该被调用的模块。即使消息出现错误，也会过滤掉，等待正确消息的到来。而且可进一步优化为当收到错误消息可以通知界面层。可见在控制软件前后台的接口层增加一个标记后台状态的全局状态机有助于增强软件的健壮性。 3.状态机的错步问题 工控软件本质上是根据一定的逻辑条件给出有序的输出。根据输出的次序可以划分不同的状态。逻辑条件在嵌入式领域中就是用户的输入和传感器的状态。正是这些条件决定了状态的跃迁。在这里我们探讨的是根据传感器输入而建立的状态机。很明显，它的运行速度比前述系统级状态机高很多。这种状态机分布在软件的控制层中，正是它们使得受控对象能够有序精确高速的运行。对于这样高速运转的状态机，如果考虑不周全，会使其产生失步或者跳步，即高速状态机中的错步现象。由于控制层的状态机的跃迁条件来源于传感器信号，如果不能完全跟踪到传感器信号的变化，则跃迁条件将被遗漏，导致状态机不能跃迁到新的状态。这就会导致失步。有两种情况会导致传感器信号的检测遗漏：一是采样频率不够高，漏掉了一些保持时间较短的信号。这可以通过硬件上提高采样频率得到解决。二是状态机设计的缺陷，详见以下例子。  图3 出现失步的状态机 由图3可以看出，状态1根据传感器a信号跃迁到状态2，状态2根据传感器b信号跃迁到状态3。如果b信号在a信号前发出了一个完整的脉冲，由于根据状态图在状态1时并不需要检测b信号，因此当跃迁到状态2以后，状态机就出现失步了。解决这个问题需要预先分析好a，b信号的关系。如果是b信号一定出现在a信号前，那不妨把状态1和2的条件判断对调，如果两个信号是并发关系的，那就要合并状态机1，2，把a，b信号作为跃迁到3的综合条件。因此解决失步问题的要点在于仔细考察受控对象处于此状态时所可能出现的传感器信号变化及其变化关系。 在处理“输入-输出对”时要注意防止状态机跳步。“输入-输出对”是嵌入式领域中经常遇到的控制模式，类似于应答机制。控制层给出一个输出，使得传感器信号产生变化并反馈，过一段时间后，控制对象运动完成，传感器信号恢复初态，此时控制层可以撤消原输出并给出相关处理。设计者会有意无意的把注意力放在“什么时候撤消输出”，因此设计出如图4（a）所示的有潜在问题的状态机。  图4 出现跳步的状态图 可是控制对象在收到控制层输出的驱动产生运动，传感器感知运动并给出信号变化是需要时间的。根据图4（a）的状态机，很可能跳过传感器信号变化的状态，而直接到达“撤消输出”的状态。结果导致控制层的输出仅仅是一瞬而过甚至是无法输出，这就是跳步。为解决跳步问题，就需要设计者仔细分析所有的“输入-输出对”，把状态细分。如图4（b）所示，增加一个等待对象运动的新状态，确保上一状态的输出驱使对象真正运动以后才判断对象运动停止。然而在细分状态的同时也要注意防止失步。状态分得越细，越要注意分析此状态中所有可能出现的信号变化。 4.状态机在工控软件中的状态划分问题 把一个状态机看作是一个动作模块，并把这些模块串联起来，就可以实现这几个动作的并发输出。如果是基于操作系统的，状态机还可以放在不同的任务中，也可以实现并发输出。每个状态机设定一个空闲状态，当不需要其运转时让其进入该状态。同一个控制环的状态机之间的通信可以用标志位或者状态变量，不同任务的状态机可以通过一个全局的结构体交互信息，实现同步。 状态机的调度并不困难，关键在于如何根据受控对象的运动规律来划分状态机动作模块。在实际应用中，“周期性”是解决问题的关键。从复杂的运动时序中归纳出带有“往复运动”性质的输出，连同与其同步的其他输入输出归入一个状态机中。这样每个具有“往复运动”性质的运动模态都建立一个状态机。同时，可以运用上文介绍的方法实现这几个运动模态的并发和同步控制。 下面通过某型进油系统来说明如何划分状态机。某型进油系统分左右两路。每路由一油链，摆臂，拨动滑板组成。油链上装载多个装油模块。摆臂把模块提升到滑板，并由滑板推进到燃烧舱中，然后油链步进一次。全过程双路交替供油。供油分为低速供油和高速供油。时序如下图，黑色横线代表动作持续时间。  图5供油系统低速供油时序图  图6 供油系统高速供油时序图 先分析低速供油的情况。可以看出油槽下降-油门关-油槽上升-油门开-滑板（左或右）这几个动作是交替出现，在滑板动作完成以后，油槽又开始新一轮的动作。由于这种周期性，可以把这几个动作归入状态机A中。而油链动作是由滑板动作触发的，当滑板运动到一定位置时候油链会启动，油链的运动会持续到下一次同侧运动开始后。如果把油链运动也归入状态机A中，就打破了A的周期性，从而增加了A的状态确定复杂化。另外从运动的本质上来说，油链运动被状态机A中的滑板运动所激发，因而把油链运动定义在另一个状态机B更为合理。B是在A运动到某个状态时所触发的，触发后，B和A就是并发运行的状态机。 高速供油与低速时序的区别在于在左路状态机A的周期没有完成的情况下，右路的状态机A已经开始了。但是尽管如此，对于单路而言，油槽下降-油门关-油槽上升-油门开-滑板（左或右）仍然呈现周期性。所以应该为左右两路各建立一个状态机A，也就是A1和A2。A1和A2的状态机代码是一样的，当判断油槽重新上升后马上触发相对一侧的状态机。同理对于油链运动，也应该建立B1和B2状态机。在多任务系统中，左右两路可以分别建立一个任务。把Ax和Bx归入其中一个任务中。 综上所述，根据周期划分受控对象的运动，并建立相应的状态机，就可以描述各种复杂并行的时序输出。 5.结论 本文结合嵌入式工控软件设计的工程实践，分析了状态机思想在软件设计中的应用。给出了状态机在嵌入式软件中前后台信息交互的通用模型;分析了高速状态机容易出现的错步问题;最后结合某型供油系统，给出了划分状态机的周期性准则，该准则对于分析受控对象运动具有一定的参考价值。 |