基于有限状态机的控工系统软件设计.docVIP

基于有限状态机的工控系统软件设计 (1) ? 通过分析工控系统的特性，提出采用状态机的思想进行工控软件设计。详细论述了高速状态机的错步问题以及控制层中状态机的状态划分问题。结合具体的应用实例，给出了基于状态机的实现方法。实验表明，采用状态机的设计方法有助于准确描述受控对象的行为，软件的健壮性和可靠性得到显著提高。 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?不同分发结构对错误消息的处理示意图 　　我们可以看到由于模式二采用全局状态机标定当前软件所处的状态，消息首先会到达相应的状态处理程序，然后才进行分发。此时分发语句可以根据当前的状态屏蔽不应该被调用