遵循模型驱动设计策略的系统化数控机床核心设计方法研究

遵循模型驱动设计策略的系统化数控机床核心设计方法研究,遵循,模型,驱动,设计,策略,系统化,数控机床,核心,方法,研究 遵循模型驱动设计策略的系统化数控机床核心设计方法研究 刘亚东，郭新贵，李伟，山崎和夫 加州大学机械与航空工程系 关键字 数控核心，模型驱动设计，状态图，数据流图 摘要 为了克服传统的硬件预定设计的缺点，我们提出了一种模型驱动设计（MDD）的方法来设计CNC核心。按照这种方法，选择状态图来模拟数控核心的行为，并应用数据流图（DFD）来模拟数控核心内部与NC程序相关的数据处理。然后，对基于Statechart的CNC核心模型进行仿真，以检查其正确性。在最后的实施阶段，提出了一种新颖的数控核心结构，其中实施软件分为两部分：设计规范相关数据和处理引擎，这极大地简化了系统调试和重新设计。与规范相关的数据是由成熟的状态图模型生成的，它可以在未来可能的变化中进行更新。处理引擎只需设计一次，将来也会保持不变。最后，一个原型系统已经被开发出来，并证明了所提方法的可行性。 简介 数控系统已在工业界广泛使用多年。但即使在今天，它们仍然是作为专有的、供应商特定的解决方案提供的，不能满足机床制造商所要求的功能更新、定制和降低成本的需求。这些解决方案的主要局限性被总结为以下几点。 首先，很难加强专有的数控系统。通常情况下，要想更快地生产出更好的零件，往往意味着要为数控系统配备额外的设备，以提高其感知和补偿工艺参数的能力，如力、扭矩、振动或热。在专有系统中，大多数情况下，增加传感器和使用这些传感器的软件只能由原始制造商来完成，而且往往要付出很大代价。 其次，机床用户不能轻易访问CNC内部的数据。不管是否需要修改控制器的功能，用户都认为，只要把工艺数据从机床上拿下来，就是一个很大的进步。 第三，使用专有数控系统的成本也很高。不同的控制器有不同的操作界面和程序格式。因此，受过培训的人在操作机器时使用一种类型的控制器，往往不能操作安装了不同控制器的类似机器。在有几十种控制器类型的大型车间里，机械师不能轻易地从一台机器移到另一台机器上，这是一个严重的制约效率和灵活性的因素。 最后，维护专用数控系统的成本也很高。例如，台式电脑的硬盘、内存和CPU的升级是现成的，而且价格低廉。而另一方面，对于数控系统来说，这些部件往往更加昂贵，有时甚至完全不可用，仅仅是因为原始供应商停止生产。 为了克服这些限制，许多机床制造商开始开发自己的数控系统。然而，他们中的大多数并不成功，因为数控系统是非常复杂的，没有一个数控系统制造商愿意公开他们的技术诀窍。虽然有几个国家的研究项目被提出来进行开放式结构的CNC设计，如OSACA（欧洲）、OMAC（美国）和OSEC（日本），但它们大多是针对CNC的模块化和模块间的接口标准化，关于CNC内部结构的信息并不多。 本文阐明了数控系统的逻辑结构。数控系统分为几个部分：人机界面（HMI）、数控核心、运动控制器（MC）和PLC。基于这样的模块划分，预计可以很容易地设计一个数控系统，并整合机床制造商的专有功能，而不依赖于特定的数控系统供应商。本文主要关注第二部分。数控核心。 模型驱动的设计方法 为了进行数控设计，图1显示了一种传统的方法，在这种方法中，设计者往往在规格分析之后立即选择硬件/软件平台，然后进行系统设计。然后，主要的设计活动将集中在基于预先确定的平台的软件编程上。最后阶段是测试和调试。这样的方法有很多缺点。 图1 传统系统设计流程 首先，这是一种典型的逐案处理的方法。最终的设计结果往往强烈依赖于设计者的经验。最终的设计结果是否反映了原意，取决于设计者对文本格式的原始规范的理解。文本说明趋向于模糊和不完整。此外，随着现代机床的功能变得越来越复杂，设计者更难弄清规范的正确性。因此，可能会有更多引入错误的可能性。这些错误在建立原型系统之前是很难发现的。 第二，系统设计必须局限于特定的硬件，因为硬件在一开始就已经确定。一般来说，一个项目会持续一到两年，硬件的发展非常快，两年后会有很大的变化，然而，那时的系统设计者不能轻易应用，因为整个设计是基于两年前的硬件。因此，系统设计者不能自由地思考他们的设计。设计结果将不再是最佳的。如果系统设计者试图应用这种新的硬件技术，整个系统的开发就必须从头开始。 最后，在一个控制系统中，数据和数据处理通常在软件代码中。要找出代码的哪一部分与规范的相应部分有关并不容易。如果在规范中需要进行一些修改，设计人员需要翻阅整个代码来找到相应的部分。即使是一个小的修改，也可能导致大量的bug，因为修改的部分与代码的其他部分不一致，这使得系统的调试更加困难和费时。从某种意义上说，对于一个新的设计，即使它与现有的设计有相当相似的规格；大多数设计者更愿意从头开始，而不是修改现有的代码。 图2 模型驱动的设计流程 本文提出了一个模型驱动设计（MDD）的方法来加强数控系统的核心设计，如图2所示。通过这种方法，设计人员首先分析规范，并使用一些计算机辅助控制系统设计（CACSD）工具建立一个可执行的系统模型。然后，这个模型将被模拟，以确保它的行为与预期相同。最后，系统的实现将被构建成两部分：与规范相关的数据和一个过程引擎。与规范相关的数据将直接转换为从一个成熟的模型和对应的个人规范。过程引擎是为了解释与规范相关的数据。使用这个方案，系统调试和重新设计变得更加容易。例如，当规范被修改或给出一个新的版本时，只有规范相关的数据需要重新生成。处理引擎将始终保持不变。将MDD方法应用于数控核心设计的关键问题是：如何对数控核心进行建模，如何验证模型，以及如何从经过验证的模型中实现。 Cnc核心逻辑模型 数控系统概述 数控系统由几个部分组成，每个部分都有特定的功能。人机界面有两个部分：机器控制面板和数控面板。操作员的要求，如工作模式切换、功能选择和手动机器控制，都是通过机器控制面板提出的。NC面板就像PC的显示器，显示CNC/机床的工作状态，允许用户编辑NC程序和参数。数控核心负责管理任务和数控程序处理。它处理伺服控制和主轴旋转，以确保刀具和工件之间的相对运动能够准确啮合。PLC负责处理机床的访问控制，包括来自CNC核心的PLC命令，换刀顺序逻辑，报警等。 功能分析 为了建立一个数控系统核心的模型，其主要功能模块在图3中得到澄清。它从人机界面读取两种输入：操作员的请求和通过其通用API的NC程序。经过处理后，CNC核心将其运行状态输出到人机界面，并通过实时接口向MC和PLC发出两种命令。这两种命令是MC和PLC的命令。同时，轴的反馈运动位置和PLC响应将被送入CNC核心进行进一步处理。 图3：数控核心的功能模块。 数控核心是这样工作的，每次当操作者的要求到来时，其中一个最重要的模块，数控核心逻辑会根据具体的操作要求和当前的系统状态，确定此刻应该激活哪个功能模块。然后，相应的控制功能将在被激活的模块中执行。例如，如果操作人员希望通过选择某个按钮在自动操作模式下开始加工，自动控制主管模块将被触发，开始处理NC程序并将结果发送到另两个模块。运动控制处理器和逻辑控制处理器。这两个模块将负责运动插值和顺序逻辑准备，并与外部MC和PLC密切沟通。 凸轮轴芯建模 为了对数控核心进行建模，需要澄清两种数据。它们是与操作者要求有关的数据和与NC程序有关的数据。明确前者是为了建立数控核心的行为模型，以动态地观察其行为。澄清后者是为了建立数控核心的DFD，以描述数控程序如何通过相应的功能模块进行处理。 行为模型化 状态机建模 数控核心是一个典型的离散事件系统（反应式系统），其特点是：系统分为有限状态，在特定的外部刺激下，经常从一个状态转移到另一个状态[1]。该行为这样的系统完全取决于一段时间内异步事件（操作员的请求）的发生。例如，当系统工作在自动模式（状态）和紧急停止按钮被按下（事件）时，系统将从自动模式退出并进入紧急停止模式。 状态机是反应式系统建模的经典方法。使用状态机方法，系统设计的考虑改变为：将系统划分为可能的状态。然后，在传入的事件中寻找其在各状态之间的可能转换，并确定在状态中发生的或有转换的具体行动。 有限状态机（FSM）是最流行的状态机方法之一。但当系统变得复杂时，它往往是无法管理的。因此，一种对FSM的改进，即状态图被引入。Statechart是由Davis Harel在1987年发明的[2]。这种方法统一了状态机的符号并引入了三个新的特征。 · 它支持层次结构，因此扁平状态机可以用层次结构的方式来表示。 · 它支持并行性；在状态图模型中可以表示两个并行状态。 · 它能够表示历史，这使它有可能根据历史指定一个过渡的目标状态。 状态图符号 图4显示了Statechart模型的符号。如图所示，有几个图形组件：状态、过渡，还有几个非图形组件：事件、条件和行动。 一个显示为圆角矩形的状态描述了一个反应式系统的模式。一个系统可以被分解成许多具有层次结构的状态。一个事件的发生会导致状态的动态变化。在图4中，第一层是StateA，它有两个子状态。状态A1和状态A2。状态A1有三个排他性（OR）的子状态。状态A1a、状态A1b和状态A1c，这意味着在一个时刻只有一个状态可以活动。状态A2有两个平行（AND）子状态。StateA2a和StateA2b，这意味着两个状态可以同时激活。 图4：状态图模型符号。 过渡是一条连接一个状态和另一个状态的曲线。源点是过渡开始的地方，终点是过渡结束的地方。一个过渡标签与一条过渡曲线一起描述了系统从一个状态到另一个状态的情况。一个过渡标签被表示为事件[条件]。 {condition action}/{transition action}。事件是导致过渡发生的刺激物。条件是确定过渡是否可以发生的保障。条件动作是当条件得到满足时要调用的函数。过渡动作是过渡发生时要调用的函数。 有几个基于状态图符号的状态图建模软件，如Matlab的Stateflow、WindRiver的BestState、IAR的VisualState等。 数控核心的状态图模型 图5给出了用Matlab的Stateflow建立的数控核心的状态图模型。该系统是以分层方式组织的。第一层有三个状态。关闭、ESTOP和开启状态。ON状态有两个平行的子状态。Core_Logic和Parallel_Tasks状态。Core_Logic状态有三个独占的子状态。启动、正常运行和测试运行。Normal_Operation是最重要的状态之一，可以是分解为更详细的工作模式相关的子状态，如自动、手动、编辑等。平行任务（Parallel_Tasks）有三个平行子状态。Task_MLC、Task_MCP 和 Task_LCP 分别描述 CNC 核心内 MC/PLC 命令分配、运动控制处理和逻辑控制处理的行为。 状态图模型模拟 在建立了一个数控核心的Statechart模型后。应用MDD方法的第二个问题是如何验证这个模型以确保它是理想的模型。这就是模型检查，它包含两个步骤：验证和确认。 验证消除了由于对规范的误解而导致的状态图模型的逻辑缺陷。这些缺陷包括冲突的转换、不可达的转换等等。这个过程相对简单，大多数状态图建模软件都可以完成。 验证检查Statechart模型的行为是否与规范要求的一样，甚至它在验证后的逻辑上是否正确。有两种方法来进行这种检查。一种是理论分析，另一种是模拟。理论分析是一种基于Statechart模型的详尽状态空间探索的形式化方法[3,4]。这个领域正在进行大量的研究；但实际应用仍有很长的路要走。仿真方法是一种更实用的方法，因此在现实中被广泛使用。使用这种方法，通常要建立一个模拟环境。通过使用一组准备好的场景，一系列的虚拟事件被送入Statechart模型，以驱动Statechart模型的执行。通过比较模型与准备好的场景的反应，不准确或不正确的设计结果可以很容易地被发现。 使用Simulink的CNC核心。用Matlab的GUI设计器建立的人机界面被用来准备事件、条件和其他数据，这些数据被发送到Statechart模型中。在Stateflow环境中，Statechart模型的反应可以根据规范的期望进行评估。如果发现任何设计错误，Statechart模型可以被修改并再次模拟，直到证明它是正确的。 数据流图 与NC程序处理有关的数据是另一个重要的数据，为了建立一个CNC核心模型，需要澄清。图7是CNC核心的DFD，它表明了从程序区加载NC程序，经过NCPP和NCPP Buf，由MCP&LCP协调器分配到LCP/MCP和PLC/MC Cache的路径。详细流程如下。 1) 一个NC程序从程序区加载。它首先由NCPP处理，生成相应的典型加工函数（CMF）。CMF是直接的结果，由NIST定义。其目的是提供一套原始函数，以涵盖机床可以提供的所有可能的功能。 2) 每个CMF将一条MC/PLC命令填入NCPP缓冲区。每条MC/PLC命令是一条原始指令，对应一个机器动作。例如，MC6000设置进给率，PLC3003打开主轴，等等。 3） NCPP缓冲区中的每个项目都是一个结构，包括块号、序列号、命令的完成类型和命令（操作符和操作数）。 4) 一个MCP&LCP协调器（MLC）被用来将这些MC/PLC命令分配给相应的处理器。MC命令被发送到MCP，PLC命令被发送到LCP。每条命令都是在前一条命令执行成功后分配的。 5) 然后，LCP中的PLC命令通过CNC-PLC共享存储器直接发送到PLC，以触发指定的机器逻辑控制。 6) MCP中的MC命令是按其功能处理的，主要是插值。插值后的位置被存储在MC缓存中，由外部MC定期读取，用于伺服控制。 7) LCP和MCP在执行每条命令时都会给MLC以完成响应。图8显示了MC/PLC的命令是如何在每条命令执行后由MLC按顺序分配给MCP/LCP的。 系统实施 按照MDD方法，实施的软件代码有望在最后阶段直接从经过验证的系统模型中生成。对于基于状态图的行为模型，可以这样做，但对于数控系统核心模型的DFD，则不能。因此，在本文中，实施软件的框架首先从数控系统核心的状态图模型生成[5,6]。然后将数控核心模型的DFD作为Statechart模型的大部分动作来实现。此外，整个实施软件由两部分组成：一个通用处理引擎和规范相关数据。与规范相关的数据由一个生成器从StateChart模型中转换而来，而处理引擎则被构建为一个引用这些数据的不变程序。通过分离引擎和规范相关的数据，实现的复杂性并没有简单地消失；相反，大部分的复杂性都由处理引擎来处理。当将来有修改过的或新的规范时，只有规范相关的数据需要重新生成以进行新的系统设计。 规格相关数据 StateChart模型中包含的信息可以用两种数据结构表示。StateChart拓扑结构和过渡。 拓扑结构数据结构 图9展示了一个简单的StateChart例子及其相应的树状结构，反映了其拓扑结构所定义的层次性和一致性。状态和树的节点之间的对应关系是一对一的关系。在树中，每个状态都有它的标识符，它是该状态的一个数字ID。同时，每个状态都有它的直系子孙、兄弟姐妹和祖先。例如，状态B的直系后裔、兄弟姐妹和直系祖先分别是状态BA、状态C和状态A。根据这个树状结构，数据结构的定义，描述了StateChart模型的拓扑结构，在图9的模型下面给出。它为每个状态存储了以下信息：它的标识符（state），它的直接后代（descendant），它的下一个兄弟姐妹（sibling），它的直接祖先（anjestor），状态信息（status）和两个要调用的函数指针。 每当进入（Entry）或退出（Exit）相应的状态时。状态信息表明相应状态中定义的历史条件是否存在，并告诉人们该状态是一个并发状态还是一个层次状态。 过渡期数据结构 同样地，过渡的数据结构定义了一个过渡的所有信息，如图10所示。它有两个标识符，分别指定为每个过渡的起始状态（from）和目标状态（to），一个触发事件标识符（event），一个指向函数的指针，该函数返回一个表示过渡是否可以发生的布尔值（guard），一个指向函数的指针表示与过渡有关的行动（action）。 处理引擎 基于定义的状态图模型的数据结构：拓扑结构和过渡，处理引擎也被设计出来。图11给出了它的流程图，它解释了描述CNC核心的StateChart模型的拓扑结构和过渡的数据结构。当一个事件发生时，有四个步骤依次完成一个过渡。 1）该事件被发送到引擎。引擎查找过渡数据结构，找出所有可能由事件触发的过渡。然后检查拓扑数据结构中每个状态的状态，以确定当前的活动状态，只有活动状态才是被触发的过渡的起源状态。一旦过渡的起源状态和活动状态相匹配，过渡就被确定了。 2）一旦过渡被确定，原初状态就被确定。然而，如果原初状态是一个分层的或并发的超级状态，那么从原初状态可到达的活动原子状态首先需要被引擎识别为原初状态。然后，引擎也可以停用从活动的原子状态到最近的共同祖先的路径上的所有状态（不包括后者），以及这个路径上的所有并发组件。在停用的过程中，引擎会调用退出动作函数。 3) 引擎执行与过渡有关的行动。 4) 从最近的共同祖先到目标状态的路径上的所有状态以及并发的组件都被激活。一旦到达目的状态，引擎就会搜索历史条件，直到最后到达一个原子状态。在激活的过程中，引擎会调用入口动作函数。 一旦处理引擎的软件代码和规范的相关数据被编译，就可以得到一个实现[7]。 结论 为了进行数控核心的设计，本文提出了一种MDD方法，以简化和规范其设计流程。按照这种方法，首先使用状态图符号建立数控系统核心的可执行模型。通过使用仿真，对这个Statechart模型进行验证和确认，以确保该模型在逻辑上是正确的，并且与规范的预期行为一致。同时，建立一个DFD来描述数控核心内的NC程序相关数据处理。在最后的实施阶段，经过验证的数控系统核心的状态图模型被转换为规范的相关数据，这些数据将被集成到一个不变的处理引擎中。之前建立的。有了这种结构，每当规范发生变化时，要找到软件代码进行调试就容易多了。基于这个解决方案，DFD被实现并嵌入到具体的功能代码中。已经建立了一个原型系统来证明所提出的方法的可行性。未来的工作将包括建立一个更现实的状态图模型，并研究将DFD模型有效地嵌入到实现中的方法。 参考文献 C. G. Cassandras and S. L. Lafortune, (1999), Introduction to Discrete Event Systems, Kluwer Academic Publishers. David Harel, (1987), “StateCharts: A Visual Formalism for Complex Systems”, Science of Computer Programming, No.8, pp.231-274. E. M. Clarke and W. Heinle, (2000), “Modular translation of Statecharts to SMV”, Technical Report, Carnegie-Mellon University School of Computer Science. Diego Latella, et al., (1999), “Automatic verification of a behavioural subset of UML statechart diagrams using the SPIN model- checker”, Formal Aspects of Computing, Vol. 11(6), pp.637–664. B.P. Douglass, (1998), Real Time UML – Developing efficient objects for embedded systems, Massachusetts, Addison- Wesley. E. Gamma, R. Helm, R. Johnson and J. Vlissides, (1995), Design patterns: elements of reusable object-oriented software, Massachusetts: Addison Wesley. M. Samek, P.Montgomery, (2000), “State- oriented programming”, Embedded Systems Programming, Vol.8, 22-43.