CN1249045A

CN1249045A - 实现层次状态图的装置和对其有用的方法及设备

Info

Publication number: CN1249045A
Application number: CN97181804A
Authority: CN
Inventors: 弗里德里克·C·罗特巴尔
Original assignee: Emultek Ltd
Current assignee: Emultek Ltd
Priority date: 1996-12-25
Filing date: 1997-12-22
Publication date: 2000-03-29
Anticipated expiration: 2017-12-22
Also published as: EP0993639A1; HK1027182A1; JP2001507490A; CN1165857C; IL119914A; AU5408898A; EP0993639A4; US6285976B1; IL119914A0; WO1998029817A1; NO993149L; KR20000069716A; US5995739A; TW355767B; NO993149D0

Abstract

能使用户实现层次状态图的设备。此设备包括:运行来执行一系统的工况指令表的状态机具(SME)(20);运行来以计算机代码形式复制描述系统工况指令表的用户定义的层次状态图的状态图编码器(10),此编码器运行来以第一数据结构维持状态图层次结构的完整性;运行来对指令表内的多个事件中的各个别事件生成与此个别事件相关的状态图的状态之间的至少一变迁的清单的事件清单发生器,此事件清单发生器运行以第二数据结构维持此清单;和运行来激活系统以执行其指令表中的每一操作的工况实现器。

Description

实现层次状态图的装置和对其有用的方法及设备

本发明领域

本发明关于计算机代码和用于生成计算机代码的设备及方法。

本发明背景

David Harel的“状态图，通往复杂系统的直观途径”(Science ofComputer Programming，1987)中介绍有层次状态图。

此说明书中所提到的所有出版物和其中所引用的出版物的公开内容在此均被结合作为参考。

本发明概述

本发明试图提供改进的计算机代码和用于生成计算机代码的改进的设备及方法。

根据本发明一优选实施例提供实现层次状态图的设备，它包括：运行来执行一系统的工况指令表的状态机具(SME)；运行来以计算机代码形式复制描述系统的工况指令表的用户定义的层次状态图的状态图编码器，此编码器运行来以第一数据结构维持状态图的层次结构完整；运行来为指令表内多个事件中的各个别事件生成与此个别事件相关的状态图的状态间至少一变迁的清单的事件清单发生器，此事件清单发生器运行来以第二数据结构维持清单；和运行来激活系统以执行其指令表中的每个操作的工况实现器。

按照本发明一优选实施例，此系统还包括硬件和软件中至少一种。

另外按照本发明优选实施例，此第一数据结构的大小与此层次结构中的转移数成正比地线性增加。

此外，按照本发明一优选实施例，此第二数据结构的大小与至少一变迁的清单中的变迁数成正比地线性增加。

而且按照本发明一优选实施例，每一清单的至少一变迁的顺序对应于由层次状态图所定义的变迁评价顺序。

另外按照本发明的优选实施例，事件清单发生器为其生成清单的多个事件包括至少一外部输入事件。

再有按照本发明的优选实施例，事件清单发生器为其生成清单的多个事件包括至少一内部数据值变化事件，此设备还包括数据值变化事件通告器，该通告器运行来向状态机具生成各数据值变化事件的通知。

按照本发明的一优选实施例另外还提供实现层次状态图的方法，此方法包括：提供一可运行来执行一系统的工况指令表的状态机具(SME)，以计算机代码形式复制描述系统的工况指令表的用户定义的层次状态图，此复制步骤可运行来保持此状态图的层次结构完整，对此指令表内多个事件中的各个别事件生成一与此个别事件相关的状态图的状态间的至少一变迁的清单，和激活系统来执行其指令表中的每一个操作过程。

按照本发明的优选实施例另外还提供自动代码生成方法，包括：自动生成在存储器中构成维持图的层次结构的层次状态图的复制体的代码，自动生成为第一多个输入事件的每一个构成受该输入事件作用的变迁的清单的代码，自动生成为第二多个内部数据变量的每一个构成受该内部数据变量中的变化作用的变迁的清单的代码，自动生成向状态机具通知内部数据变量中的变化的代码，和自动生成评估条件和实现动作和活动的代码。

按照本发明优选实施例此方法还包括提供状态机具的步骤，该状态机具运行来根据接收的有关发生事件的通知评估受此事件作用的变迁清单以便能选择要进行的变迁，并进行这些变迁。

另外按照本发明的优选实施例还提供用于为层次状态机计算状态的方法，此方法包括：提供一运行来接收关于至少一事件的发生的状态机具，提供描述一系统的工况指令表的层次状态图，为每一事件提供与其相关的状态图的状态间的至少一变迁的清单，评估此至少一变迁清单以便能根据此至少一事件选择欲进行的变迁，和评估层次状态图来计算对应于所选变迁的状态。

附图的简要说明

由以下结合附图的详细说明将会理解本发明，其中

图1为按照本发明的优选实施例所构成的和运行的软件系统的简化方框图，此系统包括与状态机具(SME)接口的自动生成的代码；

图2为对图1的状态机具的优选操作方法的简化流程图说明；

图3为从层次状态图生成高级计算机代码的优选方法的简化流程图说明；

图4为一特定例中从层次状态图自动生成计算机代码的过程中所生成计算机屏幕的图形说明；

图5为在处理图4例的过程中所生成的计算机屏幕的图形说明，它表示构成此例的状态图的所有模式；

图6为在处理图4例的过程中所生成的计算机屏幕的图形说明，它表示图5状态图的可替换表述；和

图7为可按照本发明优选实施例运行的自动代码生成技术的简化流程图说明。

优选实施例的详细说明

现在参看图1的按照本发明一优选实施例构成和运行的软件系统的简化方框图，此系统包括与状态机具(SME)20接口的自动生成的代码10。还设置有对基础硬件(未图示)的任选接口30。

状态机具20为动态或静态地链接到自动生成的代码和接口程度库的预设目标码模块。

此状态机具实现最好仅由与其相连接的自动生成的代码所定义的软件系统的工况。即就是这样的情况，状态机具代码通常仅以目标码形式一次提供，而无需每一软件系统加以改变。

状态机具实现这种工况是依靠将输入事件和数据值的变化变换成层次状态图内的变迁，然后实现这些变迁。它这样来完成，即计算与这种变迁相关的新状态，去活化老状态的相关部分和最后激活新状态的相关部分。

以图2的流程图说明对状态机具(SME)20的优选操作方法。

SME通过根据由自动生成的代码30所提供的数据建立初始数据结构来开始操作。这些数据结构通常包括：

一对一表述层次状态图的数据结构；

使任何输入事件与由这些输入事件触发的变迁耦合到一起的数据结构；

使应用程序中的任何数据变量与由这些数据变量的值或状态的变化所触发的变迁、和与在这些数据变量改变时必须加以评估的表达式耦合到一起的数据结构；和

指向自动生成的代码中的所有逻辑和活动功能的指针。

SME进入它等待任何输入事件或数据值中的任何变化的正常操作状态。应当理解的是，输入事件可能源自于硬件例如后面参照图4更详细说明的灯，或者来自软件过程例如过程间消息。

当来自自动生成的代码的输入事件通知或数据变化通知到达时，SME20检查触发此通知的事件或数据结构是否具有与其相关的变迁或逻辑表达式的清单。如果没有，它放弃此通知并返回到其正常的操作状态。

如果此通知源具有与之相关的这样的清单，则SME检验清单中的各项以选择那些属于当前活动的状态的项。所有其它项均忽略。

然后SME重复通过此被选择的清单和校验各项。

如果一项为变迁，而且该变迁的源状态仍然为活动的，则SME这样进行变迁，即：计算与此变迁相关的新状态，去活化在新状态中将不再活动的当前状态的那些部分，而后激活新状态中的那些在当前状态原非活动的所有元素。然后此新状态成为当前状态。

如果此项为逻辑表达式而不是一变迁，SME通过调用所生成的代码中的对应功能来评估这一表达式。

一旦SME处理了清单中的所有项，它返回其正常操作模式等待下一通知。

再回头参看图1，自动生成的代码10为一系统的层次状态图描述的翻译，以及系统中的所有数据元素，它在经编译后连同SME和接口程序库一起运行来实现原始系统的运行功能。

自动生成的代码10典型地包括下列组分的某些或全部：

用于在存储器中一对一地生成包括所定义的变迁和活动的原始状态图的复制体的代码；

用于生成将输入事件源与在SME接收到这些事件的通知时要加以评估的变迁相链接的清单的代码；

用于生成将数据变量与在SME接收到改变这些数据变量的通知时要加以评估的变迁和逻辑表达式相链接的清单的代码；

每当数据变量改变时生成对SME的通知的代码；

用于评估条件和实现说明由原始状态图描述的系统的工况的动作和活动的代码，包括用于激活状态图所指定的硬件或软件元素的代码；和

在需要时将上述任一个代码传递到SME的代码。

对基础硬件的目标码接口程序库30为使状态机和自动生成的代码中的一个或二者能与这些元素所依赖运行的硬件交互作用的可选预设目标码。

这种目标码接口程序库是对系统要依赖运行的硬件专用的。

用于以状态图生成高级代码的通常技术必须生成如状态图所描述的所有可能变迁和状态的静态表述，还要生成用于激活这些不同状态的状态机的代码。一般，状态和状态机在这样生成的代码中是无法分开的。

能用于完成这一点的二个主要技术有：由嵌套转移语句构成的状态机和围绕状态变迁表建立的状态机。

在第一技术中，利用转移语句生成代码，状态图形被变换成大量通常很深的嵌套的转移语句，此时各转移语句代表可能的变迁之一。嵌套深度至少与状态图中最深层次结构的深度相同，并作为状态图中所有转移的深度、转移的宽度和可能的输入事件数量的函数非线性地增加。

转移语句是“if-else(如果-否则)”或“switch-case(转移-理由)”型式的语句。

对于简单程序这可能是足够的，但通常由于为编码嵌套转移语句需要大量的代码，这一技术产生太大的程序。

每一可能的输入事件典型地以某种标记来表述。当发生一输入事件时，设置对应标记来指明这一情况。状态机机理就是连续不断地通过所有转移语句进行循环，搜寻任何包括可能已在当前循环之前设置的标记以及由于改变值的变量而成为真的条件语句的转移。这具有无法避免的结果，即这样的代码非常缓慢，特别是因为每一循环均必须通过组成代码的深度嵌套的转移点。这使得这种类型的代码很大而对任何要求快速响应时间或适度存储器需求的应用程序来说太慢。

在第二技术中，利用状态变迁表生成代码，对每一可能的变迁和状态生成一过程或功能，连同由所生成的状态机所用的状态变迁表来为每一可能的外部输入选择哪一过程加以调用。实际上，这种状态变迁表是一其下标为“输入事件”和“当前状态”，而其值为新状态的二维阵列。

这里的状态不是层次状态而是一正常线性状态图中的状态，后者依靠“平整”原始状态图从状态图推演得到。

当一输入事件到达状态机，状态机利用它连同当前状态一起来查找下一状态。这种表的利用取得较之嵌套转移语句对输入好得多的响应时间。另一方面，仍然必须以循环通过所有条件语句以寻求任何评估为“真”者来对这样的语句进行评价。自然这仍然是很慢的。

另外，由于需要“平整”或线性化原始状态图，表的大小作为可能的输入事件数量、状态图的深度和各个转移的宽度的函数成指数地急剧增大。因此，这样所生成的程序通常大到使所生成的代码不能实用于市场产品。

相反，本发明的代码生成技术最好具有下列某些或全部特点：

它不致力于在所生成的代码中再现层次状态机，而是生成在编译和连接后由预设的优化状态机具运行的代码；

它不生成状态图中所有的可能状态和变迁的静态表述，而是生成再现原始状态图的实际层次状态结构的代码。然后此预设状态机具响应于每一个输入事件或条件中的变化来动态计算所需的新状态；

它完全由事件驱动，即使依赖于条件。每一事件源和每一个变量均具有一与之相关的逻辑清单。这一清单指向任一如果或当该事件被触发或该变量改变值时必须加以评价的语句。一般，此清单中的语句表示变迁，语句的顺序表明对这些变迁的评价的顺序。一旦输入事件到达或一变量改变值，立即辨识取决于它的变迁并加以评价；和

所生成代码的大小在转移数量和转移间的变迁数量方面是线性的。此大小与转移的宽度和可能输入事件的数量无关。

本发明的代码生成技术和本发明的代码结构具有下列某些或全部优点：

最后所生成的代码连同预设状态机具很小，而所需存储器可以与由程序员手工开发的等同代码相当；

虽然所生成代码对输入事件的响应时间与通常的自动生成的代码同样令人满意，对变量中的变化的响应时间则优于自动生成的代码，而事实上类似于对输入事件的响应时间；和

保证所生成代码反映它由之推演的状态图，而不是它的变换版本。结果，所生成代码即如原始状态图所描述那样运行操作。另外，由于状态图形式体系本身的清晰性，与等同的手工开发代码相比较，所生成代码更有可能按所需的运行操作。

实例：

图3说明将一用于生成这里所表示和说明的代码的系统结合进Rapid S/W工具(Emnltek Ltd，Misgav 20179，Isreal提供的商品)。

现在说明图3的步骤。

建立接口程序库：接口程序库由自动生成的代码用来与系统要被开发来运行的硬件交互作用。例如，此程序库代码可被用来从操作系统请求存储器分配，或者，如果此硬件控制一装置例如一个灯，此程序库可含有例如通过访问此硬件上特定的地址来接通或断开此灯的代码。此程序库可以任何适当的语言编写而最好在Rapid开发之前作预测试。

将组分映射到仿真目标：在Rapid中，通过在屏幕上汇编仿真硬件和/或软件组分和从由目标仿真提供的功能建立逻辑表达式来建立应用程序。这些被提供的功能激励目标仿真的运行性能。例如在一Lamp(灯)目标的情况下，功能“Switch On(接通)”将使得屏幕上被仿真的灯改变到“On”色彩。为了使逻辑表达式能与实际组分交互作用，设置所提供功能与接口程序库间的映射。这一映射可被硬编码成被仿真的目标码。另一方面也可采用外部的逐句映射文件。

打开一新的Rapid应用程序：这是建立Rapid应用程序中的第一步，提供要在其上建立此应用程序的“清除状态”。

建立系统的仿真：这一仿真的建立是依靠从Layout Editor(格式编辑程序)中的工具盘中拖曳目标并将它们按要求布置于被仿真的装置的图形表述上。各目标可按图形定制，和在某种程度上按功能定制。

Rapid状态图：Rapid应用程序中的逻辑由状态图描述。Rapid中的状态图由称之为“modes(模式)”的单元建立。模式为系统的功能性状态，而任何模式均可被分层次地嵌套在任何其他模式中。因此，模式描述一层次结构树。模式具有二种“风格”：排他的和并存的。对于排他模式，在任一给定时间仅能有一个“兄弟”为活动状态，而对于并存模式所有“兄弟”必定同时活动。当一特定模式为活动的时，这就意味着它的所有先辈均为活动的。如果此模式的子辈为排他式，这也意味着其子辈至少一个为活动的，而如果此模式的子辈为并存模式，这就意味着所有子辈为活动的。状态图中的状态为所有当前活动的模式的清单。一模式可具有活动和变迁的多个清单。活动描述系统在一特定状态时做什么。活动可以是进入活动，退出活动或模式活动。进入活动是在包含它们的模式成为激活的时所进行的活动。退出活动是在包含它们的模式成为不活动的时所进行的活动。模式活动是在模式成为活动时进行和只要模式仍然为活动的、每当描述它们的数据变量改变值时即自动重新被评价的活动。变迁定义系统如何由一状态演变到另一状态。变迁典型地具有一目的模式。变迁还必须有一输入事件清单，或条件表达式或两者。变迁还可能具有动作清单。如果接收到由一变迁所保持的输入事件之一的通告，和该变迁属于一当前活动的模式，以及条件表达式如果任一个评价为真，则属于此变迁的模式被去激活(连同其子辈和任何相关的先辈)和此变迁的目的模式被激活(连同其子辈等)。在原先模式的去激活与目的模式的激活之间进行变迁中的任何动作。

建立状态图：典型地利用二种Rapid中的工具来建立仿真：Mode TreeEditor(模式树编辑程序)和Logic Editor(逻辑编辑程序)。模式树编辑程序使用户能借助选择新模式的父代、指定新模式的类型、和给新模式命名来定义和增加模式到模式的层次结构树。在这一过程期间，可利用逻辑编辑程序来增加和编辑变迁和活动。在各逻辑表达式被加到状态图时就被编译成用于被用来运行系统仿真的虚拟机的字节代码。

运行仿真：在此开发过程期间的任何时间，在开发中的系统仿真均可理想地运行。这使得能递增地开发系统和验证系统工况是如所期望的。

生成代码：一旦开发者满意此系统，Rapid即自动为具有上述特性的系统生成C++代码。应理解，除C++外的编程语言也可用于此自动生成的代码。

编译所生成的代码：可对自动生成的代码进行编译来产生目标码。

与状态机和接口程序库连接：由编译此自动生成的代码所产生的目标码然后被与SME目标码和接口程序库连接来为目标系统产生可执行代码。

这种可执行代码可被装载到目标系统并运行。

示例应用程序

以下是Rapid中的一示例应用程序和为其自动生成的代码。

图4为表明目标格式的Layout Editor(格式编辑程序)中的应用程序的一屏幕俘获。

如可看到的，此应用程序包含有5个灯和5个按钮：目标RAPID应用程序：TRANSITN 12/12/96 16：09：08目标数据报告参数：域：子树顺序：层次结构内容：活动的目标，非图形目标，目标参数，目标性能1.目标：transitn

父代：无类型：根目标

参数：

位置(pxl)：’0@0’ 大小(pxl)：’393@403’ 动态：’false’

拖放：’false’2.目标：灯H

父代：transitn 类型：圆灯参数：中心(pxl)：’300@139’ 半径(pxl)：’15@15’ 动态：’false’拖放：’false’性能：2.1.名称：闪烁周期类型：数据

参数：

值：5003.目标：灯G父代：transitn 类型：圆灯参数：中心(pxl)：’243@139’ 半径(pxl)：’15@15’ 动态：’false’拖放：’false’性能：3.1.名称：闪烁周期类型：数据

参数：

值：5004.目标：灯A父代：transitn 类型：圆灯参数：中心(pxl)：’72@140’ 半径(pxl)：’15@15’ 动态：’false’

拖放：’false’性能：4.1.名称：闪烁周期类型：数据

参数：

值：5005.目标：灯E父代：transitn 类型：圆灯参数：中心(pxl)：’129@139’ 半径(pxl)：’15@15’ 动态：’false’拖放：’false’性能：5.1.名称：闪烁周期类型：数据

参数：

值：5006.目标：灯F父代：transitn 类型：圆灯参数：中心(pxl)：’186@139’ 半径(pxl)：’15@15’ 动态：’false’拖放：’false’性能：6.1.名称：闪烁周期类型：数据

参数：

值：5007.目标：B to A父代：transitn 类型：平按钮参数：位置:’(pxl)：’57@199’ 大小(pxl)：’40@40’ 动态：’false’拖放：’false’ 瞬时：’true’ 自动重复：’false’自动重复周期：5008.目标：Default父代：transitn 类型：平按钮参数：

位置(pxl)：’131@199’ 大小(pxl)：’40@40’ 动态：’false’

拖放：’false’ 瞬时：’true’ 自动重复：’false’

自动重复周期：5009.目标：History父代：transitn 类型：平按钮参数：

位置(pxl)：’206@199’ 大小(pxl)：’40@40’ 动态：’false’

拖放：’false’ 瞬时：’true’ 自动重复：’false’

自动重复周期：50010.目标：DeepHistory父代：transitn 类型：平按钮参数：

位置(pxl)：’276@199’ 大小(pxl)：’40@40’ 动态：’false’

拖放：’false’ 瞬时：’true’ 自动重复：’false’

自动重复周期：50011.目标：History父代：transitn 类型：标签参数：

位置(pxl)：’198@244’ 大小(pxl)：’58@15’ 动态：’false’

拖放：’false’ 文本：’History’ 方向：’Horizontal’

字体：’Fixedsys’ 行宽：112.目标：Next父代：transitn 类型：平按钮参数：位置(pxl)：’167@282’ 大小(pxl)：’40@40’ 动态：’false’拖放：’false’ 瞬时：’true’ 自动重复：’false’自动重复周期：500

图5为表明构成这一示例应用程序的状态图的所有模式的Mode TreeEditor(模式树编辑程序)的屏幕俘获。

在图6中所示Logic Chart(逻辑图)工具的屏幕俘获中可看到此状态图的另一替换视图。图6表示各模式为矩形和各变迁为弧形。可清楚看出状态的层次结构性质。

现在参看图7，可按照本发明优选实施例运行的自动代码生成技术的简化流程图说明。所得代码可结合一能进行下列功能的状态机具应用，其中包括：

a、在接收到发生输入事件的通报后，SME访问对该输入事件所形成的清单和评价该清单上的各个变迁以便根据当前状态来确定要进行哪些变迁；和

b、在接收到内部数据变量发生变化的通报后，SME访问对该内部数据变量所形成的清单和评价该清单上的各个变迁以便根据当前状态确定要进行哪些变迁。

为进行一变迁，SME通过转到变迁的目的地查找并激活所有先辈而计算与此变迁相关的新状态。在适宜时例如按预先定义的缺省值还查找和激活所有的子辈。将当前状态的那些在新状态中不再为活动的部分去激活。新状态中的那些在当前状态中原本非活动的元素被激活。然后此新状态成为当前状态被存入SME中。

另一方面，也可不设置上述清单中的一个或两者。例如，系统可周期地轮询内部事件而不是由其驱动。或者还可以，系统可周期地轮询外部事件而不是由其驱动。状态图中的逻辑RAPID应用程序：TRANSITN 12/12/96 16：07：32模式数据报告参数：域：子树顺序：层次结构包括：用户功能，活动，变迁，触发，动作用户功能1.模式：transitn

父代：无类型：根

注释：2.模式：A

父代：transitn 类型：排他

进入活动：

a.灯A接通

退出活动：

a.灯A断开

变迁：

a.目的地：B 项目类型：Default

a1.触发：Default in &

b.目的地：B 项目类型：History

b1.触发：History in &

c.目的地：B 项目类型：Deep History

c1.触发：DeepHistory in &3.模式：B父代：transitn 类型：排他变迁：

a.目的地：A 项目类型：Default

a1.触发：B to A in &4.模式：C父代：B 类型：排他5.模式：E父代：C 类型：排他进入活动：

a.灯E接通退出活动：

a.灯E断开

变迁：

a.目的地：F 项目类型：Default

a1.触发：Next in &6.模式：F

父代：C 类型：排他

进入活动：

a.灯F接通

退出活动：

a.灯F断开

变迁：

a.目的地：G 项目类型：Default

a1.触发：Next in &7.模式：D父代：B 类型：排他8.模式：G父代：D 类型：排他进入活动：

a.灯G接通退出活动：

a.灯G断开变迁：

a.目的地：H 项目类型：Default

a1.触发：Next in &9.模式：H父代：D 类型：排他进入活动：

a.灯H接通退出活动：

a.灯H断开变迁：

a.目的地：E 项目类型：Default

a1.触发：Next in &生成的代码

  Header File

  #ifndef_include_transitn

  #define_include_transitn

  #include＂applic.h＂

  #include＂task.h＂
				
				<dp n="d20"/>
#include ＂object.h＂
#include ＂mode.h＂
class Application；
class myApplication；
typedef bool(myApplication∷*MyApplicationMethod)()；
#define cNumberDependencies   8
#define cNumberDependencyIndices 6
#define cNumberChildren     18
#define cNumberObjects      20
#define cNumberTriggers     5
#define cNumberTransitions  8
#define cNumberModes        9
#define cNumberActivities   10
class myApplication：public Application
{
private：
∥Objects
enum objectID
{
cOB_RootObject＝0，
∥PushButtons
cOB_Default，∥1
cOB_History，∥2
cOB_DeepHistory，∥3
cOB_BToA，∥4
cOB_Next，∥5
∥Lamps
				
				<dp n="d21"/>
cOB_LampA，   ∥6
cOB_LampE，   ∥7
cOB_LampF，   ∥8
cOB_LampG，   ∥9
cOB_LampH，   ∥10
∥Modes
cOB_RootMode，∥11
cOB_ModeA，   ∥12
cOB_ModeB，   ∥13
cOB_ModeC，   ∥14
cOB_ModeD，   ∥15
cOB_ModeE，   ∥16
cOB_ModeF，   ∥17
cOB_ModeG，   ∥18
cOB_ModeH，   ∥19
}；
enum modeID
{
cMO_RootMode＝0，
cMO_ModeA，∥1
cMO_ModeB，∥2
cMO_ModeC，∥3
cMO_ModeD，∥4
cMO_ModeE，∥5
cMO_ModeF，∥6
cMO_ModeG，∥7
cMO_ModeH，∥8
}；
enum ActivityIndices
				
				<dp n="d22"/>
{

cAC_ModeA_entry，

cAC_ModeA_exit，

cAC_ModeE_entry，

cAC_ModeE_exit，

cAC_ModeF_entry，

cAC_ModeF_exit，

cAC_ModeG_entry，

cAC_ModeG_exit，

cAC_ModeH_entry，

cAC_ModeH_exit，

}；

enum ConcreteIndices

{
cConcrete1＝0，

cConcrete2，

cConcrete3，

cConcrete4，

cConcrete5，

cConcrete6，

cConcrete7，

cConcrete8，

cConcrete9，
cConcrete10，

}；
public ：
void init(RapidTask*t)；
				
				<dp n="d23"/>
∥Objects：
RootObject    rootObject；
PushButton    pbDefault；
PushButton    pbHistory；
PushButton    pbDeepHistory；
PushButton    pbNext；
PushButton    pbBToA；
RapidLamp     LampA；
RapidLamp     LampE；
RapidLamp     LampF；
RapidLamp     LampG；
RapidLamp     LampH；
∥Modes：
RootMode      rootMode；
XMode         ModeA；
XMode         ModeB；
XMode         ModeC；
XMode         ModeD；
XMode         ModeE；
XMode         ModeF；
XMode         ModeG；
XMode         ModeH；
∥Logic Methods：
bool       ModeA_entry()；
bool       ModeA_exit()；
bool       ModeE_entry()；
bool       ModeE_exit()；
bool       ModeF_entry()；
bool       ModeF_exit()；
				
				<dp n="d24"/>
bool       ModeG_entry()；
bool       ModeG_exit()；
bool       ModeH_entry()；
bool       ModeH_exit()；
∥Dynamic State Machine Data：
RapidObject    *FrameTable[cNumberObjects]；
ModeP       buffer1[cNumberModes]；
ModeP       buffer2[cNumberModes]；
ModeP       buffer3[cNumberModes]；
unsigned char_ModeFlags[3*cNumberModes][1]；
∥Static State Machine Data：
∥Each object has a list of dependency records，sorted
∥by property and event，and referencing pairs of
∥(modes，activity/condition，index)，or a transition index
static DependencyRecord dependencies[cNumberDependencies]；
∥For each object/property pair，there is a dependency index record
∥that includes the first &amp; last dependency record pertaining to the
∥object/property pair.
static DependencyIndexRecord dependencyIndicies[cNumberDependencyIndices]；
∥Each transition has an index and an associated record that includes
∥the indices of the source and destination，type，condition，and action
static TransitionRecord transitionRecords[cNumberTransitions]；
∥Each transition has an index and an associated record that includes
∥the indices of the source and destination，type，condition，and action
				
				<dp n="d25"/>
    static TriggerRecord triggerRecords[cNumberTriggers]；

    ∥Activity methods are indexed through the following array

    ∥subroutine methods are NOT indexed here.

    static MyApplicationMethod activityRecords[cNumberActivities]；

    ∥Each mode record includes entry and exit activities，if any，

    ∥and the start index and length of the mode activities. Can the mode activities

    ∥be merged？Also，the number of transitions，to facilitate flag allocation.

    static ModeRecord modeRecords[cNumberModes]；

    ∥Each object record includes

    static ObjectRecord objectRecords[cNumberObjects]；

    ∥Array to hold all of the children for the objects

    static int childrenArray[cNumberChildren]；
  ∥General Data on this APplication
  static ApplicationRecord applicationRecord；
}；
class myTask：public RapidTask
  {
  public：
  myTask()；
  ～myTask()
    {
    removeContext(&amp;_mainApp)；
    }；
private：
				
				<dp n="d26"/>
    myApplication_mainApp；
  }；
#endif
Body File
/*
Rapid Application：
Objects：
   Transitn
   |--＞BToA(Square Pushbutton)
   |--＞Default(Square Pushbutton)
   |--＞History(Square Pushbutton)
   |--＞DeepHistory(Square Pushbutton)
   |--＞Next(Square Pushbutton)
   |--＞LampA(Round Lamp)
   |--＞LampE(Round Lamp)
   |--＞LampF(Round Lamp)
   |--＞LampG(Round Lamp)
   |--＞LampH(Round Lamp)
Modes：
   Transitn
   |--＞A(D)
   |
   |---B

       |--＞C(D)

      |    |--＞E(D)

      | |

      |     |---F

     |
				
				<dp n="d27"/>
 |---D

    |--＞G(D)
  |
  |---H

逻辑1.模式：Transitn

父代：无类型：根

注释：2.模式：A

父代：Transitn 类型：排他

进入活动：

a.灯A接通

退出活动：

a.灯A断开

变迁：

a.目的地：B 项目类型：Default

a1.触发：Default in &

b.目的地：B 项目类型：History

b1.触发：History in &

c.目的地：B 项目类型：Deep History

a.目的地：A 项目类型：Default

a1.触发：B to A in &4.模式：C父代：B 类型：排他5.模式：D父代：B 类型：排他6.模式：E父代：C 类型：排他进入活动：

a.灯E接通退出活动：

a.灯E断开变迁：

a.目的地：F 项目类型：Default

a1.触发：Next in &6.模式：F

父代：C 类型：排他

进入活动：

a.灯F接通

退出活动：

a.灯F断开

变迁：

a.目的地：G 项目类型：Default

a1.触发：Next in &6.模式：G父代：D 类型：排他进入活动：

a.灯G接通退出活动：

a.灯G断开变迁：

a.目的地：H 项目类型：Default

a1.触发：Next in &6.模式：H父代：D 类型：排他进入活动：

a.灯H接通退出活动：

a.灯H断开变迁：

a.目的地：E 项目类型：Default

a1.触发：Next in &生成的代码

*/
#include ＂transitn.h＂
#include ＂emtrace.h＂
#include ＂ekernel.h＂
/*
struct DependencyRecord
{
DependencyClass dependencyClass；∥event，condition，mode activity
int mode；             ∥Frame Table index
int eventID；          ∥eventID，if any
int index；            ∥Index of transition or mode Activity
}；
*/
DependencyRecord myApplication∷dependencies[cNumberDependencies]＝
{
{cEvent，       cOB_ModeA，cPushButtonIn，0}，∥0 A-＞B on Default in
{cEvent，       cOB_ModeA，cPushButtonIn，1}，∥1 A-＞B on History in
{cEvent，       cOB_ModeA，cPushButtonIn，2}，∥2 A-＞B on DeepHistory in
{cEvent，       cOB_ModeB，cPushButtonIn，0}，∥3 B-＞A on BToA in
{cEvent，       cOB_ModeE，cPushButtonIn，0}，∥4 E-＞F on Next in
{cEvent，       cOB_ModeF，cPushButtonIn，0}，∥5 F-＞G on Next in
{cEvent，       cOB_ModeG，cPushButtonIn，0}，∥6 G-＞H on Next in
{cEvent，       cOB_ModeH，cPushButtonIn，0}，∥7 H-＞E on Next in
}；
/*
				
				<dp n="d32"/>
struct DependencyIndexRecord{

     PropertyEntry_propertyId；

     int flags＝0；

     unsigned int_firsElement；
}
*/
DependencyIndexRecord myApplication∷dependencyIndicies[cNumberDependencyIndices]＝
{
   {cSelf，0，0}，         ∥pbDefault self
   {cSelf，0，1}，         ∥pbHistory self
   {cSelf，0，2}，         ∥pbDeepHistor self
   {cSelf，0，3}，         ∥pbBToA self
   {cSelf，0，4}，         ∥pbNext self
   {cNone，O，cNumberDependencies}  ∥Sentinel for last index record
}；
∥children listed grouped by common parent
int myApplication∷childrenArray[cNumberChildren]＝
{
   cOB_Default，   ∥0
   cOB_History，   ∥1
   cOB_DeepHistory， ∥2
   cOB_BToA，          ∥3
   cOB_Next，    ∥4
   ∥Lamps
   cOB_LampA，    ∥5
   cOB_LampE，    ∥6
   cOB_LampF，    ∥7
   cOB_LampG，    ∥8
   cOB_LampH，    ∥9
				
				<dp n="d33"/>
    ∥Modes

    cOB_ModeA，    ∥10

    cOB_ModeB，    ∥11

    cOB_ModeC，    ∥12

    cOB_ModeD，    ∥13

    cOB_ModeE，    ∥14

    cOB_ModeF，    ∥15

    cOB_ModeG，    ∥16

    cOB_ModeH     ∥17

  }；
/*
struct ObjectRecord
  {
  ObjectIdentifier name；
  int parent；
  int id；∥Id within type...e，g，modes are numbered l-n，concretes are numbered l-m
  int numChildren；
  int firstChild；
  int firstDependentIndex；
  int numDependentIndex；
  }；
*/
ObjectRecord myApplication∷objectRecords[cNumberObjects]＝
  {

                                     cNone，   10，       0，            0，

    0}，

                     cOB_RootObject，       cConcrete1，      0，        cNone，

    0，              1}，
				
				<dp n="d34"/>
               cOB_RootObject，    cConcrete2，         0，        cNone，
1，       1}，

                                         cConcrete3，         0，        cNone，
2，       1}，

                   cOB_RootObject，    cConcrete5，         0，        cNone，
3，       1}，

    cOB_RootObject，           cConcrete4，           0，        cNone，         4，
4}，

                                       cConcrete6，         0，        cNone，
0，       0}，

                                       cConcrete7，         0，        cNone，
0，       0}，

                                       cConcrete8，         0，        cNone，
0，       0}，

                                       cConcrete9，         0，        cNone，
0，       0}，

                                       cConcrete10，        0，        cNone，
0，       0}，

                                       cMO_RootMode，       7，        11，      0，
0}，

                                       cMO_ModeA，          0，        cNone，
0，       0}，

                                       cMO_ModeB，          6，        10，      0，
0}，

                                       cMO_ModeC，  2，          14，         0，
0}，

                                       cMO_ModeD，  2，          16，         0，
0}，

                                       cMO_ModeE，  0，          cNone，         0，
0}，
				
				<dp n="d35"/>
                                      cMO_ModeF，  0，        cNone，        0，

    0}，

                                            cMO_ModeG，  0，        cNone，        0，

    0}，

                                            cMO_ModeH，  0，        cNone，        0，

    0}
}；
ApplicationRecord myApplication∷applicationRecord＝
{
cNumberModes，
cNumberActivities
}；
/*
struct TriggerRecord
{
int objectID；
int propertyID；
int eventID；
}；
*/
∥NOTE：Could get sophisticated，and reuse trigger records...
TriggerRecord myApplication∷triggerRecords[cNumberTriggers]＝
{
{cOB_Default，cSelf，cPushButtonIn}，  ∥0
{cOB_History，cSelf，cPushButtonIn}，  ∥1
{cOB_DeepHistory，cSelf，cPushButtonIn}，∥2
{cOB_BToA，cSelf，cPushButtonIn}，      ∥3
{cOB_Next，cSelf，cPushButtonIn}，     ∥4
				
				<dp n="d36"/>
}；
/*
struct TransitionRecord
{
int triggerStart；  ∥index of first trigger record
int triggerLength；  ∥number of trigger records
int sourceMode；     ∥object index of source mode
int destinationMode；∥object index of destination mode
int condition；    ∥index of condition method
int action；     ∥index of action method
unsigned int type：3；
unsigned int IsConditionOnly：1；
unsigned int toAncestor：1；
unsigned int toDescendant：1；
unsigned int sourceEqualsDestination：1；
}；
*/
TransitionRecord myApplication∷transitionRecords[cNumberTransitions]＝
{
{0，1，cOB_ModeA，cOB_ModeB，cNone，cNone，cDefaultTransition，    false，false，false，
false}，∥A-＞B #1
{1，1，cOB_ModeA，cOB_ModeB，cNone，cNone，cHistoryTransition，    false，false，false，
false}，∥A-＞B #2
{2，1，cOB_ModeA，cOB_ModeB，cNone，cNone，cDeepHistoryTransition，false，false，false，
false}，∥A-＞B #3
{3，1，cOB_ModeB，cOB_ModeA，cNone，cNone，cDefaultTransition，    false，false，false，
false}，∥B-＞A #1
{4，1，cOB_ModeE，cOB_ModeF，cNone，cNone，cDefaultTransition，    false，false，false，
false}，∥E-＞F #1
				
				<dp n="d37"/>
{4，1，cOB_ModeF，cOB_ModeG，cNone，cNone，cDefaultTransition，   false，false，false，
false}，∥F-＞G #1
{4，1，cOB_ModeG，cOB_ModeH，cNone，cNone，cDefaultTransition，   false，false，false，
false}，∥G-＞H #1
{4，1，cOB_ModeH，cOB_ModeE，cNone，cNone，cDefaultTransition，   false，false，false，
false}，∥H-＞E #1
}；
/*
struct ModeRecord
{
ObjectIdentifier name；
int defaultChildID；    ∥ObjectID of default child，cNone if none

                  ∥For parents of AndModes，first child
int entry；
int exit；
int modeActivityStart；
int numModeActivities；  ∥N/A，condition index，activity index
int transitionStart；∥First transition record pertaining to this mode
int numTransitions；    ∥Number of transitions
}；
*/
ModeRecord myApplication∷modeRecords[cNumberModes]＝

        ∥def child entry           exit           modeStart numMode  transSart

    numTrans
{＂RootMode＂，cOB_ModeA，cNone，        cNone，   cNone，  0，  cNone， 0}，

                                                                 0，   0，

    3}，
{＂ModeB＂，cOB_ModeC，cNone，           cNone，   cNone，  0，  3，  1}，
{＂ModeC＂，cOB_ModeE，cNone，           cNone，   cNone，  0.   cNone， 0}，
				
				<dp n="d38"/>
{＂ModeD＂，cOB_ModeG，cNone，     cNone，       cNone，      0，      cNone，0}，

                   cAC_ModeE_entry，cAC_ModeE_exit，cNone，               0，  4，

       1}，

                                cAC_ModeF_entry，cAC_ModeF_exit，cNone，  0，  5，

       1}，

                                cAC_ModeG_entry，cAC_ModeG_exit，cNone，  0，  6，

       1}，

                                cAC_ModeH_entry，cAC_ModeH_exit，cNone，  0，  7，
       1}
}；
MyApplicationMethod myApplication∷activityRecords[cNumberActivities]＝
{
&amp;myApplication∷ModeA_entry，
&amp;myApplication∷ModeA_exit，
&amp;myApplication∷ModeE_entry，
&amp;myApplication∷ModeE_exit，
&amp;myApplication∷ModeF_entry，
&amp;myApplication∷ModeF_exit，
&amp;myApplication∷ModeG_entry，
&amp;myApplication∷ModeG_exit，
&amp;myApplication∷ModeH_entry，
&amp;myApplication∷ModeH_exit，
}；
bool myApplication∷ModeA_entry()
{
LampA.turn_on()；∥LampA on
return false；
}
				
				<dp n="d39"/>
bool myApplication∷ModeA_exit()
{
LampA.turn_off()；∥LampA off
return false；
}
bool myApplication∷ModeE_entry()
{
LampE.turn_on()；∥LampA on
return false；
}
bool myApplication∷ModeE_exit()
{
LampE.turn_off()；∥LampA off
return false；
}
bool myApplication∷ModeF_entry()
{
LampF.turn_on()；∥LampA on
return false；
}
bool myApplication∷ModeF_exit()
{
LampF.turn_off()；∥LampA off
return false；
}
bool myApplication∷ModeG_entry()
				
				<dp n="d40"/>
{
LampG.turn_on()；∥LampA on
return false；
}
bool myApplication∷ModeG_exit()
{
LampG.turn_off()；∥LampA off
return false；
}
bool myApplication∷ModeH_entry()
LampH.turn_on()；∥LampA on
return false；
}
bool myApplication∷ModeH_exit()
{
LampH.turn_off()；∥LampA off
return false；
}
void myApplication∷init(RapidTask*t)
{
setTask(t)；
Application∷dependencies＝dependencies；
Application∷dependencyIndicies＝dependencyIndicies；
Application∷transitionRecords＝transitionRecords；
Application∷triggerRecords＝triggerRecords；
Application∷activityRecords＝(ApplicationMethod*)activityRecords；
				
				<dp n="d41"/>
Application∷objectRecords＝objectRecords；
Application∷modeRecords＝modeRecords；
Application∷objects＝FrameTable；
Application∷applicationRecord＝&amp;applicationRecord；
Application∷children＝childrenArray；
rootObject.init(cOB_RootObject，this)；
pbDefault.init(cOB_Default，this)；
pbHistory.init(cOB_History，this)；
pbDeepHistory.init(cOB_DeepHistory，this)；
pbBToA.init(cOB_BToA，this)；
pbNext.init(cOB_Next，this)；
LampA.init(cOB_LampA，this)；
LampE.init(cOB_LampE，this)；
LampF.init(cOB_LampF，this)；
LampG.init(cOB_LampG，this)；
LampH.init(cOB_LampH，this)；
rootMode.init(cOB_RootMode，this，

       _ModeFlags[(3*cMO_RootMode)]，

       _ModeFlags[(3*cMO_RootMode)+1]，

       _ModeFlags[(3*cMO_RootMode)+2])；
ModeA.init(cOB_ModeA，this，

       _ModeFlags[(3*cMO_ModeA)]，

       _ModeFlags[(3*cMO_ModeA)+1]，

       _ModeFlags[(3*cMO_ModeA)+2])；
ModeB.init(cOB_ModeB，this，

       _ModeFlags[(3*cMO_ModeB)]，

       _ModeFlags[(3*cMO_ModeB)+1]，

       _ModeFlags[(3*cMO_ModeB)+2])；
				
				<dp n="d42"/>
ModeC.init(cOB_ModeC，this，
        _ModeFlags[(3*cMO_ModeC)]，

        _ModeFlags[(3*cMO_ModeC)+1]，

        _ModeFlags[(3*cMO_ModeC)+2])；
ModeD.init(cOB_ModeD，this，

        _ModeFlags[(3*cMO_ModeD)]，

        _ModeFlags[(3*cMO_ModeD)+1]，

        _ModeFlags[(3*cMO_ModeD)+2])；
ModeE.init(cOB_ModeE，this，

        _ModeFlags[(3*cMO_ModeE)]，

        _ModeFlags[(3*cMO_ModeE)+1]，

        _ModeFlags[(3*cMO_ModeE)+2])；
ModeF.init(cOB_ModeF，this，

        _ModeFlags[(3*cMO_ModeF)]，

        _ModeFlags[(3*cMO_ModeF)+1]，

        _ModeFlags[(3*cMO_ModeF)+2])；
ModeG.init(cOB_ModeG，this，

       _ModeFlags[(3*cMO_ModeG)]，

       _ModeFlags[(3*cMO_ModeG)+1]，

       _ModeFlags[(3*cMO_ModeG)+2])；
ModeH.init(cOB_ModeH，this，

       _ModeFlags[(3*cMO_ModeH)]，

       _ModeFlags[(3*cMO_ModeH)+1]，

       _ModeFlags[(3*cMO_ModeH)+2])；
rootMode.initActiveChild()；
ModeA.initActiveChild()；
ModeB.initActiveChild()；
ModeC.initActiveChild()；
ModeD.initActiveChild()；
ModeE.initActiveChild()；
				
				<dp n="d43"/>
    ModeF.initActiveChild()；
    ModeG.initActiveChild()；

    ModeH.initActiveChild()；

    _currentState.init(buffer1，cNumberModes)；
    _nextState.init(buffer2，cNumberModes)；

    _tempState.init(buffer3，cNumberModes)；

    Application∷rootMode＝&amp;rootMode；

    Application∷rootObject＝&amp;rootObject；

    }
  myTask∷myTask()
  {
  _mainApp.init(this)；
  setMainApplication(&amp;_mainApp)；
  setupKernelTask(this)；    
  }；
  ∥declare one task
  myTask GlobalTask；

应理解，本发明的软件组分如果希望的活可以ROM(只读存储器)形式实现。总的说软件组分如果希望可利用通常技术以硬件来实现。

应理解，为清楚起见，在分开的实施例的上下文中所描述的本发明的各种特点也可合在一单个实施例中组合地提供。相反，为概略起见在单个实施例上下文中所描述的本发明的各种特点也可分开地或在任何适当的子组合中达到。

熟悉本技术领域的人士将会理解本发明并不局限于以上所具体表示和说明的一切。而是本发明的范畴仅由所列权利要求加以规定。

Claims

1、实现层次状态图的设备，包括：

状态机具(SME)，运行来执行一系统的工况指令表；

状态图编码器，运行来以计算机代码形式复制描述所述系统的工况指令表的用户定义的层次状态图，所述编码器运行来以第一数据结构保持所述状态图的层次结构的完整性；

事件清单发生器，运行来为指令表内的多个事件中的各个别事件生成与所述个别事件相关的所述状态图的状态间的至少一变迁的清单，所述事件清单发生器运行来以第二数据结构保持所述清单；和

工况实现器，运行来激活所述系统以执行其指令表中的每一操作过程。

2、按照权利要求1的设备，其特征是所述系统包括至少硬件和软件之一。

3、按权利要求1的设备，其特征是所述第一数据结构的大小与所述层次结构中的转移数成正比地线性增大。

4、按照权利要求1的设备，其特征是所述第二数据结构的大小与所述至少一变迁的清单中的变迁数据正比地线性增大。

5、按照权利要求1的设备，其特征是每一所述清单的所述至少一变迁的顺序对应于由所述层次状态图所定义的对所述变迁的评价顺序。

6、按照权利要求1的设备，其特征是所述事件清单发生器对之生成清单的所述多个事件包括至少一外部输入事件。

7、按照权利要求1的设备，其特征是所述事件清单发生器对之生成清单的所述多个事件包括至少一内部数据值变化事件，此设备还包括有运行来对状态机具生成各数据值变化事件的通知的数据值变化事件通告器。

8、实现层次状态图的方法，此方法包括：

设立运行来执行一系统的工况指令表的状态机具(SME)；

以计算机代码形式复制描述所述系统的工况指令表的用户定义的层次状态图，所述复制步骤运行以保持所述状态图的层次结构的完整性；

为此指令表内的多个事件中的各个别事件生成所述状态图的与所述个别事件相关的状态间的至少一变迁的清单；和

激活所述系统来执行其指令表中的每一操作过程。

9、自动代码生成方法，包括：

自动生成在存储器中构成保持所述图的层次结构的层次状态图的复制体的代码；

自动生成为第一多个输入事件中的每一个构成受该输入事件影响的变迁的清单的代码；

自动生成为第二多个内部数据变量的每一个构成受该内部数据变量中的变化影响的变迁的清单的代码；

自动生成向状态机具通报内部数据变量中的变化的代码；和

自动生成评价条件和实现动作和活动的代码。

10、按照权利要求9的方法，包括如下步骤：提供一运行来在接收到关于发生一事件的通报时评价受所述事件影响的变迁清单以便选择要进行的变迁并进行所述变迁的状态机具。

11、用于计算层次状态机的状态的方法，此方法包括：

提供运行来接收关于至少一事件的发生的通报的状态机具；

提供描述一系统的工况指令表的层次状态图；

提供对每一所述事件的所述状态图的状态间与之相关的至少一变迁的清单；

评价所述至少一变迁的清单以便响应于所述至少一事件选择要进行的变迁；和

评价所述层次状态图来计算对应于所述被选择变迁的状态。