以图示方法来表示嵌入式系统内部各部件与环境的交互作用，是一种描述和理解嵌入式系统所常用的方法。
本文从如何制作一个简洁、明了、直观、图示的标准化注释系统入手，说明如何确定嵌入实时系统的交互作用过程，重点介绍了基于消息序列图(Message
Sequence Charts，MSCs)的注释系统的基础知识以及采用这种系统的好处。
描述实时系统的方法之一是列举其与环境的交互作用。消息序列图组是专门用于描述这一交互作用的简洁、严格和图示的直观注释。由于MSCs类似于UML，MSCs在电信行业中得到了普遍的应用，并且它在其它领域中的应用也日益广泛。
以图表形式来表示嵌入式系统内部各部件与环境的交互作用，是一种描述和理解嵌入式系统所常用的方法，这样的图表不仅在进行系统设计时很有用，而且在后期分析问题的过程中也发挥着作用。但是如何制作出一个有效的图表呢？工程师们需要的是一个简洁、明了、直观、图示意的标准化的注释系统，用以确定嵌入实时系统的交互过程。本文将介绍称为消息序列图的注释系统的基础知识以及采用这种系统的原因。
MSC是一种运算严格，表示方法简洁的图示技术。它在电信领域的应用十分普及，在实时安全和重要任务系统中的应用日益增加。序列图和在UML中的应用实例过程图都是直观的，并且语义上类似于MSC注释。
交互作用与交互作用假设
当以图形来描述一个嵌入式或实时系统时，我们要列举出系统环境与外部系统之间的交互作用，还要列举出一个过程与下一个过程之间的交互作用。要注意交互作用和交互作用假设(interaction
scenario)之间的重要区别。
一个交互作用是指发生在参与实体当中的特定的事件序列。例如，温度计(外部系统)向系统控制器发送一条消息就是一个交互作用，消息也可能是一个交互作用。具体而言，在系统描述当中，还要描述系统的内部部件(子系统)之间的交互作用。对于复杂的系统，这种交互作用发生的形式多种多样。
一个交互作用假设，从另一方面来讲，详细描述了一个交互作用组，该交互作用组形成了一个交互作用的情节，并通常表示该情节中可能出现的事件序列。例如，压力计、控制器和阀之间存在各种交互作用，那么交互作用假设可能是指在压力太高的情况下三者之间使阀开启的相互作用过程。
每一个交互作用假设常被分为需要的(“晴天”)和不需要的(“雨天”)交互作用假设。理想情况下，将要实现的系统应当符合交互过程中所有需要的条件(“晴天”)而不出现一个不需要的条件(“雨天”)。
实体和事件
在一个消息序列图当中，实体是各种处理过程或子系统，而事件则表示通过实体发送和接收各种消息的行为。其它种类的事件，如与定时器相关的事件，也同样存在。在一个交互作用假设中，你可以想象实体作为一个执行者：它是一个事件的发送者或接受者。一个事件，从另一方面来讲，是指在两个执行者之间以发送消息的形式进行的通信。
处理过程(有时称之为例程)和消息的意义取决于系统。一个处理过程不一定代表计算机程序；它可指任何一个被激活的代理。消息不一定代表一个实际的数据消息，它可指在两个实体之间的另一种信息交换形式。例如，消息有一个命名，但却没有更深一层的结构或详细资料。
除非假定消息总是以发送顺序来接收，并且无任何丢失和毁损，消息序列图与消息传输的实际机制或渠道是无关的。在消息序列图注释中发送消息是不受阻碍的，意即发送者不必等到接受者接受到消息后才发送下一个消息。
应用实例
图1简单描述了阀、控制器和压力计这三个处理过程之间交互作用的消息序列图。每一个水平线表示该线所连接的实体上发生的事件，最顶部水平线表示的事件是从时间上看发生最早的事件，底部水平线表示的事件是最迟发生的事件。用于实体的临时事件顺序叫做局部顺序(local
order)。局部顺序内的两个事件间的可视距离并非表示实际的距离。
在图1当中，阀和压力计两个实体各自将称为闭合状态(status_close)和高压状态(status_high_pressure)的消息发送到控制器。控制器然后向阀发送一个称为开启命令(cmd_open)的消息。这个消息序列图仅描写了一种交互作用假设，除此之外，尚有许多其它可能出现的情况，诸如阀在哪里开启、压力何时太低、控制器何时发出闭合阀的命令等等。
在消息序列图中，交互作用假设到底是指什么呢？看起来，消息序列图仅代表一个交互作用假设，或消息交换的一个序列。消息序列图，实际上表示几个消息序列，它们当中的每一个表示特定的行为。要明确地理解这一点，我们要确定在消息序列图的各个事件的先后顺序。
在图1中，有3个发送事件的消息和3个接受事件的消息，其命名如图2(a)所示。我们假定发送事件先于相应接受这一消息的事件，例如e1先于e2。此外，对于表示处理阀的沿垂直线分布的各个事件，e1先于e6发生。
在图2所示的优先顺序图表示各个事件的优先顺序。这个优先顺序图中的圆点代表事件，如果u先于v发生，箭头方向则从事件u指向事件v。事件v发生的前提条件是其前面的所有时间已经发生。消息序列图如果构成优良的话，其相应的优先顺序图就应该具有非循环指向(DAG)的特征；优先顺序图是连通的，意即无断点，也无回路或平行线。对任意两个圆点u和v,一定有一个从u到v或从v到u的路径。由于一个事件不可能先于它自己，一个自循环、从圆点指向其自身的箭头是不允许出现的。
根据优先顺序图，在消息序列图中的事件可被分为最小事件和最大事件两类。最小事件没有先于它发生的事件，最大事件也不可能有发生在其后的其它事件。例如，e1和e3是最小事件，e6是最大事件。如在它们之间不存在任何优先关系的话，两个事件是不可比较的。因此，事件e1和e3是不可比较的，事件e2和e3也如此。
确定了与消息序列图有关的优先顺序图，我们将消息序列图M中R的排序定义为M中各个事件中的一个序列，那么，M中每个事件在R中仅出现一次，并且对序列的任何一个事件也是如此；对于M而言，所有的先发生事件都遵循该优先顺序图。总而言之，消息序列图中，有几种可能的排序。一个消息序列图的完整意义包含其所有可能出现的排序。例如，图1中的消息序列图有如下3种可能的排序：
共区结构
图1中，控制器首先接收来自阀的状态关闭(status_close)消息，然后接收来自压力计的高压状态(status_high_pressure)消息。有时我们并不希望在这两个事件间出现这样的顺序。消息序列图注释允许通过应用一个叫做共区(coregion)的结构，从而避免对于一个处理过程而言，各个事件的某个子集出现任何特定的顺序。
共区用表示处理过程的垂直线内虚线段来表示，这些虚线段内的事件是无序的。图3对图1进行了修改，它应用一个共区使事件e2和e4变得无序，它也表明了相关的优先顺序图。现在事件e2和e4是不可比较的，两者先于e5发生。
定时器结构
许多交互作用假设要用时序约束条件来限定消息流。通过应用三种专用事件：定时器设置、定时器复位和时间结束，你会很容易地在消息序列图注释中确定特定的交互作用假设。定时器设置通过将计时标记(hourglass)符号连接到一个单实体的时基上来表示；定时器复位通过将某个X连接到时基上来表示；时间结束用一根弯线将定时器的计时标记符号连接到实体时基来表示。
每一个定时器均有其特定的名字。对于每一个定时器而言，定时器复位和时间结束事件必定先于定时器设置事件。此外，时间结束事件是最后发生的事件。在图4中，在开始等待从阀和压力计实体发出消息前，控制器要启动定时器t1。控制器同时接收到来自阀和压力计的两个消息并将定时器复位，事件e7和e8表明定时器设置和定时器复位事件。图5显示了一个简明的消息序列图，图中控制器设定定时器t1(事件e7)并且在定时器t1(事件e9)时间结束前仅接受到来自阀的状态关闭(status_close)消息。
事件发生条件
条件是一种非正式描述机制，用以显示一个或一组实体达到的某个状态或情形。条件写为一个六边形框内的文本标签，可放置于某一实体或一组实体当中。如果条件C被置于实体E当中，那么除非条件得到满足，否则E不会进入到下一个事件。也就是说，条件C是实体中下一个事件发生的先决条件。如果将条件C被放置于一组实体E1，...,Ek之中，那么所有k个实体必须达到符合条件C的局部状态。只有在那个状态达到时，任何k实体才能在其相应的局部顺序中完成进一步处理。在这样的情况下，条件C可以被认为是完成进一步处理前确保实体E1,...,Ek达到相同状态的同步作用机制。
图6显示了图1中的消息序列图(稍作重新排序)，并增加了一些条件，实体阀和压力计共享一个称为可用正确状态(correct_status_available)的条件。只有当这两个实体均达到满足该条件的某一状态时，它们才能按照其局部顺序进一步处理下去。该实体控制器必须达到某一状态，这个状态下实体控制器在接收状态信息前要满足准备接收状态(ready_to_receive_status)条件。这些条件的确切定义在此省略。
在线算子表达式
在线算子表达式(Inline operator expressions)是一种允许终端用户在消息序列图内确定补充控制流的机制，而且还可组合或合成多个消息序列图组。在线算子表达式当中，可以采用五种操作类型来确定控制流，分别是：
从图解的意义来讲，在线算子表达式用一条由虚线水平分割的矩形来描述；算子关键字(operator keyword)标准在右上角。
图7利用具有可选算子的在线表达式合并了图4和图5中的消息序列图组。矩形内的虚线分割两个交替的路径，在一次执行过程中，消息序列图仅处理其中一条路径。
补充工具
消息序列图注释为描述嵌入式系统内部的交互作用提供了更为丰富的工具。消息的收发并不限于任何特定的实体，还包括外部环境。发向外部环境的消息，箭头止于消息序列图框上；从外部环境接收消息，箭尾止于消息序列图框上。
消息可包括附加信息。例如，通过阀处理所发送的开启状态(status_open)和闭合状态(status_close)，消息可以合并成单个命名状态消息，上述两个状态的消息则以“status(open)”和“status(closed)”表示，其中的变量包含了消息值。
消息序列图的动作用矩形表示，矩形内包含了将要被执行的某项任务的文字描述。与某种“条件”类似，动作矩形被置于某一实体垂直线上。然而，与某种“条件”不同的是，一个动作是局部的；它只可相连于单个实体而不可跨越多个实体。将此动作作为特殊事件加以处理，我们可将它们包括进与消息序列图相关的优先顺序图当中。与各种“条件”类似，动作通常按非正式的描述加以处理。
消息序列图组中尚存在许多其它的工具，如消息门(gates for messages)。用户也可以一种标准化的、以事件为导向的文字句法对消息序列图加以描述，而不是以这里所给出的可视注释加以描述。
高层消息序列图
基本消息序列图注释描述了微小而特殊的基本交互作用，但复杂系统又怎样处理呢？一个复杂系统通常描述为各种子系统的分级组合，其交互作用描述为子交互作用的分级组合。
高层消息序列图(HMSC)增强了基本消息序列图注释以便描述子交互作用的组合。HMSC注释也支持自上而下的分级注释，其意义在于可在不同层的提取上确定各种交互作用，即通过基础消息序列图组描述从最高层开始到最底层的交互作用。
HMSC是一组由有方向的边相互连接起来的节点集合。每一个节点既是开始符号-，也是终止符号D，圆长方形包含某一个到另一个低层或高层消息序列图的参考，六边形包含一个条件，空心圆表示一个连接点或含有两个或更多平行的高层消息序列图组(HMSCs)的平行框。就组合的方面而言，实体不在HMSC中出现。连接点仅供方便布局之用，它们没有语义。HSMC中的各种条件具有整体性，其意义在于适用于所有实体并表示某一整体系统状态。
图8所示为控制器行为的HMSC。该行为由几个通过其它HMSC和MSC来说明的低层行为组成。通过这种方式，HMSC注释就可以自顶向下分层对行为进行分解。低层的HMSC可含有更深一层的HMSC或MSC。在此要强调的是，因HMSC是循环的，所以它不含终止符。我们已强调过：一个基本MSC总是有限的；但HMSC却不是这样，因为某个HMSC可能包含多个循环(表明是周期性的或循环的行为)。
复审和确认
项目要求的复审和确认，包含在那些应用消息序列图组确定的要求，是质理管理的重要组成部分。对于已用消息序列图确定的项目要求，还可用两种方法来复审和确认，一个是运行仿真，也称之为原型或模拟，可就特殊情形测试消息序列图组；另一个是确保消息序列图组满足特定的系统特征(原理)。
后者可采用工具自动检查HMSC，你可运用与临时逻辑有关的注释来表述特性并使用诸如模型检查和满意度来验证所给特性。此外，一些专用算法和工具可用来分析给定的HMSC，以自动检测若干意外的情况，如死锁、竞争条件和非局部选择。
购买指南
消息序列图为设计实时安全和重大任务系统的工程师提供有价值的服务。类似于在UML中的序列图和应用实例注释，消息序列图组有几点优于UML的性能。
例如，消息序列图简化了在早期设计阶段的概念化系统要求。消息序列图将系统及其外部与该系统相互作用的所有实体描述为一个黑盒子，图表仅包含了一个有关系统与其外部环境间交互作用的简洁而非正式的描述。黑盒子和其外部实体作为消息序列图组中的单个实体，意即你无需知道或明确有关系统的内部结构或行为，当然我们己知的交互作用除外。这样的高层黑盒子交互作用导向的系统要求在UML中就说明得不够充分。
消息序列图组也可用作测试过程的规范(综合测试)。由于你可以运用消息序列图仿真、正式验证或完善规范，你可在实时嵌入系统的生命周期内广泛运用消息序列图组。此外，消息序列图注释也正因其特殊的应用价值而在几个领域广泛运用。例如，在计时消息序列图组中，上部和下部时限可用每一个消息加以规定，使其更适用于协议和实时系统。此外，由一套消息序列图组还可制作各种文件。
| 
