MVC技术在光刻机人机工程中的应用研究

2014-09-26赵秋锦许武军黄栋梁杨志勇

电子设计工程 2014年1期

赵秋锦，许武军，黄栋梁，杨志勇

（1.东华大学信息科学与技术学院，上海 201620; 2.上海微电子装备有限公司上海 201203）

随着科学技术的不断发展，光刻机技术也在逐步提高，对光刻机人机交互界面的要求也逐步提高，如何设计出操作快捷、响应事实、运行稳定的人机交互界面是光刻机人机工程应用研究的重点和难点。不同于其他商业软件或个人计算机上普遍使用的GUI应用程序，光刻机软件系统是一个分布式的设备软件控制系统，分布在多个硬件平台上，并且采用了分层控制的形式。

本文介绍了MVC技术和Observer、Command两种设计模式的基础理论，提出了一种基于这两种设计模式构建的MVC框架方法，并详细叙述了它结合ADAE平台和光刻机系统状态管理模型实现的人机交互界面的框架设计方案。

1 光刻机图形化界面的特征

1.1 众多应用的操作入口

光刻机图形化界面是光刻机软件系统应用的操作入口。作为光刻机设备与终端用户(End-user)最主要的人机接口，光刻机图形化界面能够接受用户输入的参数、指令，并将其分发给软件系统应用模块，从而执行设备各类应用功能。

光刻机设备本身体系复杂，应用功能又种类繁多，图形化界面必须精心设计，做到将应用功能分门别类以供选择，对每一个应用功能，用户能快速、准确输入参数，并提供一套一致的操作模式，有效确保终端用户能顺利使用设备。

1.2 大延时的底层应用

光刻机图形化界面作为软件系统的最顶层，通过逐层调用系统软件模块，完成用户期望的应用功能。那些需要使用设备硬件的应用功能，如物料操作、生产批处理等，在应用功能执行过程中，由于设备硬件本身执行动作需要时间消耗，因而从应用功能发起执行到执行完成返回结果，具有较大的延时（相对软件执行速度而言）。此外，在应用功能执行过程中，由于硬件设备本身的可靠性有一定限度，因而可能出现设备局部发生故障而导致软件无法响应的情况。

因此，光刻机图形化界面的另一个重要特征就是，操作常常涉及大延时的底层调用，甚至由于底层硬件故障而导致底层软件无法响应。图形化界面设计时必须予以关注，避免出现界面冻结甚至崩溃，而需为用户提供友善的提示，同时提高健壮性。

2 MVC模型及其关键技术

MVC设计模式是典型的基于Agent的用户界面模型，其主要优点是分离了界面显示和事件处理，可以提高界面显示与事件处理之间接插灵活性，以及界面的可移植性和可复用性。对于界面设计可变性的需求，MVC把交互系统的组成分解成模型、视图、控制器3种部件。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新[1]。这实际上是一种模型的变化-传播机制。这种变化-传播机制体现在各个相互依赖部件之间的注册关系上。模型数据和状态的变化会激发这种变化-传播机制，它是模型、视图和控制器之间联系的纽带[2]。在初始化时，通过与变化-传播机制的注册关系建立起所有视图与模型间的关联。视图与控制器之间保持着一对一的关系，每个视图创建一个相应的控制器，视图提供给控制器处理显示的操作。

2.1 进程间通讯机制

模型在逻辑结构上可以划分为两个任务进程：数据显示进程和逻辑处理进程。数据显示进程包含模型的视图和逻辑控制器部分，逻辑处理进程包含模型的数据模型部分。基于两个任务进程的划分主要考虑以下因素：首先，模型逻辑和功能的计算需要耗费大量时间，这个过程可能会导致视图无法及时响应，且异常情况下无法实现取消以及恢复功能；其次，界面功能比较复杂，需要划分成多个子模型，存在多个视图或控制器需要和同一个数据模型交互。如果在同一进程内部，较难实现管理（如：数据同步等）。

界面进程间通讯包括界面进程与各功能模型进程之间，以及功能模型进程之间的通讯方式。界面进程之间通讯使用ADAE平台提供的CN通讯方式和GF共享内存通讯方式。如界面初始化时订阅处理模型状态或者信息事件，一旦处理模型变化则主动通知界面，然后界面根据需要向处理模型获取状态或数据信息。而事件请求接口则一般由用户通过界面发起，由处理模型分类处理，模型结合ADAE平台机制完全实现了变化-传播机制。

2.2 事件传播机制

MVC模型中控制器是视图和模型之间交互的关键，因此必须协调好各类事件，保证事件能够及时准确的传送。一旦事件通道出现异常可能导致界面无法响应，或者底层模型执行错误的指令[3]。控制器事件管理需要由3部分协调完成：

1）Command：视图和模型事件封装为命令，事件触发就是一个命令发起，命令分3种：订阅事件命令（Subscribe Command）、异步事件命令（Asynchronous Command）以及同步事件命令（Synchron-ous Command）；

2）Controller：管理视图发起的Command，并控制抛出给Observer；

3）Observer：执行视图发起的命令，监听命令执行变化（数据和状态）并通知视图。

控制器事件管理模型中所有命令（继承于Abstract Command）由视图创建和发起，并提交给Controller管理。而Observer只负责监听Command执行变化并通知视图。命令通常封装了模型接口，命令变化都通过CN通讯返回。因此Observer需要使用ADAE平台的CN事件循环机制来监听所有命令执行变化。

2.3 状态管理机制

光刻机界面应用功能繁多，界面框架由多个功能模块组合而成，每个功能模块都是一个或多个独立的MVC模型，模型之间可以嵌套组合。而系统状态管理机制负责实现各模型之间状态同步和控制。状态管理指界面根据当前登录系统用户操作权限以及光刻机系统业务流程关系，来管理各功能项的使能状态。

状态管理采用分层管理的模式，即一个总的状态管理器和多个子状态管理器。状态管理器定制当前登录用户权限表，并通知各子状态管理器权限表变更状态；同时定义各种状态迁移事件，并维护状态迁移事件对子状态管理器的影响关系。子状态管理器维护内部功能项的状态，并触发状态迁移事件，通过状态管理器通知相关联的子状态管理器[5]。一般每个功能模型都拥有子状态管理器，管理本功能模型内的受影响功能项。状态管理模型是总的状态管理器，维护用户权限表、状态迁移事件影响关系、以及记录当前触发的事件。

3 MVC界面架构设计

光刻机图形化界面是光刻机应用程序与用户之间的接口与桥梁，用户从界面输入参数，选择并发出指令，界面需要将用户的请求传递给系统内部应用层或其他层的处理进程，由这些处理进程来实际执行用户的请求，执行完毕界面还需向用户反馈处理结果。

界面模型使用的是UI设计中通用的MVC设计模式，基于以上3点关键技术的解决并借助与ADAE平台基础，基本可以实现MVC界面框架。图1是扫描光刻机整机软件界面基于MVC界面架构设计的模型方案。

图1 扫描光刻机整机软件界面Fig. 1 The machine interface of scanning lithography machine

模型中每个功能模块是一个独立的MVC模型，总的界面也是一个MVC模型，模型之间相互嵌套形成总的界面框架模型，各模块之间相互独立。界面模块是指实现界面功能的基本单位，具有独立完成业务功能的能力。实现的MVC架构模型当前存在有以下两方面的问题需要解决：如果视图刷新数据量或频率过大会存在效率问题，还有可能会导致界面短时间僵死；模型假设ADAE平台可靠且稳定的，如果出现订阅失败等问题时如何建立保护措施。

界面数据刷新如果数据量和频率过大，可能导致界面出现阻塞状况，因此在设计时应该合理划分订阅数据项，使刷新频率高和刷新频率低的数据项划分开，避免没有必要的刷新。如果被订阅方任务进程未启动时，会导致订阅失败。因此，在启动任务进程时，应尽量考虑被订阅方任务进程先启动。如果订阅失败，应该设置默认保护，以免误操作。