7、通信有限状态机（CFSMs）相关技术详解

通信有限状态机（CFSMs）相关技术详解

1. 状态图（StateCharts）基础

状态图是一种用于描述系统状态和状态转换的工具，在嵌入式系统的建模中具有重要作用。

1.1 状态类型

状态图中的状态主要分为三种：AND - 超级状态、OR - 超级状态和基本状态。AND - 超级状态是描述并发的关键机制，其每个子状态都可看作一个独立的状态机，这些状态机相互通信，形成通信有限状态机（CFSMs）。

1.2 定时器

由于嵌入式系统需要对时间进行建模，状态图提供了定时器功能。定时器用特定符号表示，当系统处于包含定时器的状态达到指定时间后，会发生超时事件，系统将离开该指定状态，并且定时器可以进行分层使用。

以答录机的 Lproc 状态为例，定时器可用于描述该状态的行为。不过，由于调用者挂断电话时的异常转换，当调用者挂断电话时，Lproc 状态会终止。而对于被调用者挂断电话的情况，Lproc 状态的设计存在不便之处：若被调用者先挂断电话，电话会一直处于“死机”（安静）状态，直到调用者也挂断电话。

1.3 边标签和 StateMate 语义

扩展有限状态机（FSM）的输出可以通过边标签来指定，边标签的一般形式为“事件 [条件]/反应”，三个部分都是可选的。反应部分描述 FSM 对状态转换的反应，如生成事件和变量赋值；条件部分用于测试变量值或系统当前状态；事件部分用于测试当前事件，事件可分为内部事件和外部事件。

以下是一些边标签的示例：
- on - key/on:=1（事件测试和变量赋值）
- [on = 1]（变量值的条件测试）
- off - key [not in Lproc]/on:=0（事件测试、状态的条件测试和变量赋值，当事件发生且条件为真时执行赋值操作）

StateMate 是状态图的商业实现，它基于步骤执行描述。每次事件或变量发生变化时，会执行相应步骤。所有变量值、生成的事件集（以及当前时间）共同定义为 StateMate 模型的状态。每个步骤包含三个阶段：
1. 第一阶段 ：评估外部变化对条件和事件的影响，包括评估依赖外部事件的函数，但不包含任何状态变化。在简单示例中，此阶段可能并非必需。
2. 第二阶段 ：计算当前步骤应进行的转换集，评估变量赋值，但新值仅赋给临时变量。
3. 第三阶段 ：状态转换生效，变量获得新值。

这种分阶段执行的方式保证了 StateMate 模型的可重复性。例如，对于相互依赖的变量赋值，如果不进行阶段划分，可能会导致两个变量被赋予相同的值，结果将依赖于赋值的执行顺序。而通过分阶段执行，如在第二阶段将新值存储在临时变量中，在第三阶段再将临时变量的值赋给用户定义的变量，就可以实现变量值的正确交换，类似于两个交叉耦合的寄存器在同一时钟控制下的操作。

2. 状态图的评估与扩展

状态图和 StateMate 隐式假设了变量更新的广播机制，因此它们适合基于共享内存的平台，但对于消息传递和分布式系统不太适用。因为在分布式系统中，很难在两个步骤之间更新所有变量。

状态图的主要应用领域是本地、控制主导的系统，其优势在于可以在任意级别嵌套层次结构，自由选择 AND - 超级状态和 OR - 超级状态，并且 StateMate 的语义有详细的定义。此外，有许多基于状态图的商业工具，如 StateMate 和 StateFlow，它们能够将状态图转换为等效的 C 或 VHDL 描述，从而实现从规格说明到硬件或软件的完整开发路径。

然而，状态图也存在一些局限性。例如，自动翻译的效率有时会成为问题，它不是面向对象的，缺乏描述复杂计算的程序结构，也无法描述硬件结构或非功能行为。不过，商业实现通常会提供一些机制来克服这些限制，如使用 C 代码表示程序结构，使用 StateMate 的模块图表示硬件结构。

UML 包含了状态图的一种变体，在 UML 1 版本中称为状态图，从 2.0 版本开始称为状态机图。但 UML 中状态机图的语义与 StateMate 不同，不包含三个模拟阶段。

3. 同步语言

3.1 动机

用状态机图描述复杂系统（SUDs）存在困难，因为它无法表达复杂的计算。而标准编程语言虽然可以表达复杂计算，但多线程执行的顺序可能不可预测，在多线程环境中，不同计算的交织方式众多，理解并发系统的所有可能行为变得困难。这种非确定性的行为会带来一些负面后果，如验证设计时的问题。对于非分布式系统，我们可以尝试避免不必要的非确定性语义。

3.2 同步语言的特点

同步语言将有限状态机和编程语言融合为一个模型，它可以表达复杂的计算，但其底层执行模型是有限自动机，描述的是并发运行的自动机。通过“当自动机并行组合时，乘积的转换由所有自动机的‘同时’转换组成”这一关键特性，实现了确定性的行为。这意味着我们可以假设存在一个全局时钟，在每个时钟周期内，考虑所有输入，计算新的输出和状态，然后进行转换。

3.3 同步语言示例

• Esterel ：是一种反应式语言，当接收到输入事件时，Esterel 模型会产生输出事件作为反应。它是同步语言，所有反应都假设在零时间内完成，只需在离散时刻分析行为。它具有并行运算符 ||，通信基于广播机制，且通信是即时的（在同一时钟周期内）。
• Lustre ：看起来更像数据流语言，与 Esterel 使用不同的语法技术来表示 CFSMs。
• SCADE ：是一种商业图形语言，结合了 Esterel、Lustre 和 Quartz 的元素，其 SCADE 套件用于许多安全关键的软件组件。

由于 StateMate 具有三个模拟阶段，它具备同步语言的关键属性，如果冲突得到解决，它也是确定性的。

4. 消息传递：以 SDL 为例

4.1 SDL 语言特点

状态图不适合对分布式通信有限状态机进行建模，对于分布式系统，消息传递是更好的通信范式。SDL（规格说明和描述语言）就是一个采用异步消息传递的通信有限状态机的例子。

SDL 专为分布式应用而设计，起源于 20 世纪 70 年代，20 世纪 80 年代就有了形式语义，并由国际电信联盟（ITU）进行了标准化。它提供了文本和图形两种格式，满足不同用户的需求。

SDL 的基本元素是进程，进程表示建模为扩展有限状态机的组件。SDL 进程可以对数据进行操作，变量可以在进程本地声明，其类型可以是预定义的，也可以在 SDL 描述中自行定义，并且支持抽象数据类型（ADTs）。此外，SDL 还包含编程语言元素，如过程，过程调用也可以用图形表示。从 SDL - 1992 版本开始引入了面向对象的特性，并在 SDL - 2000 版本中得到了扩展。

4.2 进程间通信

SDL 描述通常由一组相互交互的进程（FSMs）组成，进程之间通过异步消息传递进行通信，概念上通过与进程关联的先进先出（FIFO）队列实现。每个进程有一个输入队列，发送给特定进程的信号会被放入相应的 FIFO 队列中。

进程从 FIFO 队列中取出下一个可用条目，检查其是否与当前状态描述的输入匹配。如果匹配，则发生相应的状态转换并生成输出；如果不匹配，则忽略该条目（除非使用了 SAVE 机制）。FIFO 队列在语义描述中被认为是无限长的，但在实际系统中必须是有限长的，因此在从规格说明推导实现时，需要证明 FIFO 队列长度的安全上限。

4.3 信号接收指示方式

有三种方式可以指示信号的接收方：
1. 通过进程标识符 ：在图形输出符号中使用接收进程的标识符。
2. 显式指定 ：指明通道名称。
3. 隐式指定 ：如果信号名称暗示了通道名称，则使用该通道。

4.4 层次结构

SDL 中的进程不能嵌套，但可以分层分组为块，最高层次的块称为系统。如果将环境也建模为块，系统边界将没有通道。进程交互图是块图的特殊情况，位于层次描述中叶子节点的上一层。

4.5 定时器

SDL 包含定时器，可在进程本地声明。使用 SET 原语设置定时器，该原语有两个参数：绝对时间和定时器名称。当定时器超时后，会在输入队列中存储一个信号，该信号通常会导致 FSM 发生特定的转换，但可能会被输入队列中的其他条目延迟处理。因此，SDL 的定时器概念适用于电信中常见的软定时约束，不适用于硬定时约束。可以使用 expirytime 内置函数来避免 now 函数的一些限制。使用 RESET 原语可以重置定时器，在执行 SET 原语的开始会隐式执行 RESET 操作。

例如，在一个状态转换图中，从状态 D 到 E 的转换过程中，定时器 Z 被设置为当前时间 now 加上 T；从 E 到 A 的转换有 T 个时间单位的超时。如果在信号 f 到达之前这些时间单位已经过去，将在不生成输出信号 v 的情况下转换到状态 A。但由于输入队列中其他条目的可能延迟，很难实现严格的周期为 T 的处理。

通信有限状态机（CFSMs）相关技术详解

5. 技术对比与总结

为了更清晰地了解上述各种技术的特点，我们可以通过一个表格进行对比：
| 技术名称 | 适用场景 | 通信机制 | 确定性 | 表达能力 | 局限性 |
| — | — | — | — | — | — |
| 状态图（StateCharts） | 本地、控制主导系统 | 广播机制（共享内存） | 需解决冲突才确定 | 可嵌套层次结构，但难表达复杂计算 | 不适合分布式系统，自动翻译效率低，非面向对象 |
| 同步语言（如 Esterel、Lustre、SCADE） | 复杂计算且需确定性的系统 | 广播机制（同步） | 具备确定性 | 可表达复杂计算 | 对硬件结构和非功能行为描述能力弱 |
| SDL | 分布式系统 | 异步消息传递（FIFO 队列） | 受 FIFO 队列影响 | 可操作数据，有面向对象特性 | 定时器适用于软定时约束，FIFO 队列长度需证明上限 |

从这个表格中可以看出，不同的技术在适用场景、通信机制、确定性和表达能力等方面各有优劣。在实际应用中，需要根据具体的需求来选择合适的技术。

6. 实际应用中的考虑因素

在实际应用上述技术进行系统建模和开发时，还需要考虑以下几个方面：
1. 性能需求 ：如果系统对性能要求较高，需要评估技术的执行效率。例如，状态图的自动翻译效率可能会影响系统性能，而同步语言的确定性可以避免不确定执行顺序带来的性能问题。
2. 系统架构 ：根据系统的架构特点选择合适的通信机制。对于分布式系统，SDL 的异步消息传递更合适；而对于基于共享内存的系统，状态图和同步语言的广播机制更能发挥优势。
3. 开发团队技能 ：开发团队的技能水平也是一个重要因素。如果团队熟悉面向对象编程，SDL 的面向对象特性可能更容易被接受；如果团队擅长处理同步系统，同步语言可能是更好的选择。
4. 时间约束 ：如果系统有严格的时间约束，需要考虑技术对时间的处理能力。例如，SDL 的定时器适用于软定时约束，对于硬定时约束可能需要额外的处理。

7. 未来发展趋势

随着科技的不断发展，这些技术也在不断演进。以下是一些可能的未来发展趋势：
1. 融合发展 ：不同技术之间可能会相互融合，取长补短。例如，状态图可能会引入更多同步语言的特性，以提高其表达复杂计算的能力；SDL 可能会借鉴同步语言的确定性机制，提高系统的可靠性。
2. 对分布式系统的优化 ：随着分布式系统的广泛应用，各种技术可能会针对分布式系统进行优化。例如，状态图和同步语言可能会改进其通信机制，以更好地适应分布式环境；SDL 可能会进一步优化 FIFO 队列的管理，提高系统的性能。
3. 与新兴技术的结合 ：这些技术可能会与人工智能、物联网等新兴技术相结合，创造出更智能、更高效的系统。例如，在物联网系统中，状态图可以用于描述设备的状态变化，同步语言可以用于处理复杂的数据分析。

8. 总结

本文详细介绍了通信有限状态机（CFSMs）相关的几种技术，包括状态图（StateCharts）、同步语言和 SDL。状态图适用于本地、控制主导的系统，具有可嵌套层次结构的优势，但在分布式系统和复杂计算表达方面存在不足；同步语言将有限状态机和编程语言融合，实现了确定性的行为，适合表达复杂计算，但对硬件结构和非功能行为描述能力较弱；SDL 专为分布式系统设计，采用异步消息传递机制，具备操作数据和面向对象的特性，但定时器适用于软定时约束，FIFO 队列长度需要证明上限。

在实际应用中，需要根据系统的性能需求、架构特点、开发团队技能和时间约束等因素选择合适的技术。同时，随着科技的发展，这些技术也将不断演进，未来可能会出现融合发展、对分布式系统优化以及与新兴技术结合等趋势。通过对这些技术的深入了解和合理应用，可以更好地进行系统建模和开发，提高系统的可靠性和效率。

以下是一个 mermaid 格式的流程图，展示了在选择技术时的决策过程：

graph LR
    A[系统类型] --> B{是否为分布式系统}
    B -- 是 --> C[考虑 SDL]
    B -- 否 --> D{是否需要复杂计算}
    D -- 是 --> E[考虑同步语言]
    D -- 否 --> F[考虑状态图]
    C --> G[评估性能和时间约束]
    E --> G
    F --> G
    G --> H[根据团队技能和其他因素确定最终技术]

这个流程图清晰地展示了在选择技术时，首先根据系统类型判断是否为分布式系统，然后根据是否需要复杂计算进一步筛选，最后综合考虑性能、时间约束和团队技能等因素确定最终的技术。