CN102185860A

CN102185860A - 用于集成电路制造设备的标准化底层控制驱动系统

Info

Publication number: CN102185860A
Application number: CN2011101205819A
Authority: CN
Inventors: 徐华
Original assignee: Tsinghua University
Current assignee: Tsinghua University
Priority date: 2011-05-10
Filing date: 2011-05-10
Publication date: 2011-09-14
Also published as: WO2012151886A1

Abstract

本发明公开一种用于集成电路制造设备的标准化底层控制驱动系统，包括中央控制模块，对驱动系统进行初始化并创建TCP/IP套接字；EPICS协议通信模块，通过TCP/IP套接字建立与客户端的通信连接，并采用EPICS协议与客户端进行通信，接收来自客户端的设备操作请求及与客户端交换通道数据；配置模块，用于生成变化参数配置文件以配置驱动系统中的变化参数；数据模块，用于存储来自EPICS协议通信模块的通道数据；设备驱动模块，处理设备操作请求，并根据数据模块存储的通道数据以及配置模块配置后的变化参数控制硬件设备。本发明可以高效调度和处理各个控制子系统对集成电路制造设备的各种硬件设备的大量操作请求。

Description

用于集成电路制造设备的标准化底层控制驱动系统

技术领域

本发明涉及计算机应用和集成电路装备技术领域，特别涉及一种用于集成电路制造设备的标准化底层控制驱动系统。

背景技术

随着微电子技术、信息技术、网络技术等的飞速发展，全球信息产业迅猛成长、网络经济快速兴起、知识经济初见端倪，现代国防和未来战争中的尖端技术不断崛起，人类进入了信息和网络时代。由于微电子技术的核心地位，微电子比以往任何时候都更显示出其重要的战略地位，微电子产业已经成为全球经济的重要支柱和经济、社会发展的强大推动力。

驱动控制系统作为IC(Integrated Circuit，集成电路)产业的一部分，具有举足轻重的作用。但是现有的集成电路的驱动控制系统通用性差，不能够满足集成电路制造装备工艺模块控制器(PMC)和传输模块控制器(TMC)与常见的外部硬件设备的通信，也从而导致对集成电路制造设备的各种硬件设备的操作和处理效率低。

发明内容

本发明的目的旨在至少解决上述技术缺陷之一，特别提出一种高效、通用的用于集成电路制造设备的标准化底层控制驱动系统。

为达到上述目的，本发明第一方面的实施例提出一种用于集成电路制造设备的标准化底层控制驱动系统，所述标准化底层控制驱动系统用于接收来自客户端的设备操作请求，并根据所述设备操作请求控制硬件设备，所述标准化底层控制驱动系统包括：中央控制模块，所述中央控制模块对所述驱动系统进行初始化并创建所述驱动系统的TCP/IP套接字以与客户端进行通信；EPICS协议通信模块，所述EPICS协议通信模块通过所述TCP/IP套接字建立与所述客户端的通信连接，并采用EPICS协议与所述客户端进行通信，接收来自所述客户端的设备操作请求及与所述客户端交换通道数据；配置模块，所述配置模块用于生成变化参数配置文件以配置所述驱动系统中的变化参数；数据模块，所述数据模块用于存储所述来自所述EPICS协议通信模块的通道数据；和设备驱动模块，所述设备驱动模块处理所述设备操作请求，并根据所述数据模块存储的通道数据以及所述配置模块配置后的变化参数控制硬件设备。

在本发明的一个实施例中，所述变化参数配置文件以XML文件格式保存。

在本发明的一个实施例中，所述变化参数配置文件中的变化参数包括：

所述EPICS协议通信模块和客户端之间的各个通道的配置参数、所述驱动系统向所述客户端定时反馈通道制的时间间隔、所述驱动系统定时测试所述硬件设备的测试时间间隔、所述驱动系统端的IP地址、所述驱动系统端监听网络连接的端口、所述驱动系统中存在的线程的最大数量和所述驱动系统中并行执行的线程数量。

在本发明的一个实施例中，所述配置模块进一步生成用于解析所述变化参数配置文件的关键类。

在本发明的一个实施例中，所述EPICS协议通信模块在由所述中央处理模块初始化后，监听来自所述客户端的连接请求，在接收到来自所述客户端的连接请求后，建立与所述客户端的通信连接。

在本发明的一个实施例中，所述EPICS协议通信模块包括：连接状态机，所述连接状态机用于维持所述EPICS协议通信模块与所述客户端之间的连接的状态；读数据状态机，所述读数据状态机用于读取并处理通信中传输的通道数据；轮循状态机，所述轮循状态机用于接收并处理轮循过程中传输的通道数据；和监测状态机，所述监测状态机用于定时向所述客户端发送数据包以检测所述EPICS协议通信模块和所述客户端之间的连接状态，其中，所述连接状态机、读数据状态机、轮循状态机和监测状态机均以单独的线程运行。

在本发明的一个实施例中，当所述监测状态机发送的数据包触发到一个异常时，则检测到所述EPICS协议通信模块和所述客户端之间通信连接断开。

在本发明的一个实施例中，所述数据模块存储的通道数据包括：通道类型，所述通道类型包括连续型、离散型、字符串型；通道读写类型，所述通道读写类型包括只读型、只写型、读写型；通道类型的父类，所述通道类型的父类用于封装所述的通道的操作；节点类，所述节点类为逻辑上或物理上相关的EPICS通道的集合；通道工厂类，所述通道工厂类用于管理和创建节点和通道。

在本发明的一个实施例中，通道包括：连续型只读通道、连续型只写通道、连续型读写通道、离散型只读通道、离散型只写通道、离散型读写通道、字符串型只读通道、字符串型只写通道和字符串型读写通道。

在本发明的一个实施例中，所述每个通道分别对应一个硬件设备。

在本发明的一个实施例中，所述驱动系统包括至少一个节点，其中所述驱动系统任意指定作为所述节点的EPICS通道集合。

在本发明的一个实施例中，当创建一个通道时，将所述通道同时添加到所述通道工厂类和所述通道所属的节点的EPICS通道集合中。

在本发明的一个实施例中，所述设备驱动模块包括：映射单元，所述映射单元用于对所述通道和所述硬件设备的读/写接口进行映射以对所述硬件设备进行读/写操作；读写单元，所述读写单元用于读取所述数据模块存储的通道数据、所述配置模块配置后的变化参数以及所述硬件设备的数据，并向所述硬件设备中写入数据；超时处理单元，所述超时处理单元用于处理对所述硬件设备的读操作超时；和设备管理单元，所述设备管理单元用于创建和维护所述硬件设备。

在本发明的一个实施例中，所述超时处理单元判断在预定时间内是否获得读写锁，如果在所述预定时间内未获得所述读写锁，则抛出超时异常；如果在所述预定时间内获得所述读写锁，则通过异步委托机制在另一个线程里执行，包括判断是否超时，如果超时则抛出超时异常，释放所述读写锁，否则读取所述硬件设备的数据，释放所述读写锁。

在本发明的一个实施例中，设备管理单元将所述硬件设备分为四类，包括：随机模拟类设备，对所述随机模拟类设备中的硬件设备的每次读操作均分别返回一个随机的正数；连续型类设备，在所述连续型设备中的硬件设备保存一个双精度浮点型数值，并对所述双精度浮点型数值进行读/写；离散型设备，在所述离散型设备中的硬件设备保存一个整型数值，并对所述整型数值进行读/写；字符串型设备，在所述字符串型设备中的硬件设备保存一个字符串型数值，并对所述字符串型数值进行读/写。

在本发明的一个实施例中，所述中央控制模块包括：初始化单元，所述初始化单元用于对所述EPICS协议通信模块、配置模块、数据模块和设备驱动模块进行初始化，并创建所述EPICS协议通信模块的TCP/IP套接字；测试单元，所述测试单元用于以预定的测试频率测试所述硬件设备的状态以更新与所述硬件设备相关的通道的参数；和调度单元，所述调度单元用于对所述驱动系统中的各个任务进行调度以控制所述各个任务独立执行。

在本发明的一个实施例中，所述调度单元将所述各个任务放入任务优先级队列，并根据优先级通过线程池中的多个工作线程，并行执行所述各个任务。

在本发明的一个实施例中，进一步包括异常处理模块，用于在所述驱动系统抛出异常时，接管所述异常，并查找异常处理向量表以获得所述异常的异常处理函数，根据所述异常处理函数对所述异常进行处理。

在本发明的一个实施例中，所述异常处理向量表包括异常类型以及每种异常类型对应的异常处理函数。

在本发明的一个实施例中，进一步包括日志模块，所述日志模块以日志的形式记录所述驱动系统运行过程中的信息。

本发明实施例提供的用于集成电路制造设备的标准化底层控制驱动系统基于Windows xp操作系统，采用Visual C#实现。该标准化底层控制驱动系统包括中央控制模块、EPICS协议通信模块、配置模块、数据模块和设备驱动模块。其中，中央控制模块可以对整个驱动系统进行初始化和调度，包括创建驱动系统的TCP/IP套接字以与客户端进行通信。

EPICS协议通信模块可以根据创建的TCP/IP套接字建立与所述客户端的通信连接，并采用EPICS协议与所述客户端进行通信。对EPICS协议的处理包括EPICS通信的管理和EPICS数据包的处理，提供可靠的通信连接。

配置模块可以生成变化参数配置文件以配置所述驱动系统中的变化参数。当驱动系统需要这些参数时，可以在运行时通过配置模块获取这些参数。当系统中这些参数经常变化时，可以直接修改配置文件，而不用重新编译整个系统，从而大大提高了驱动系统的可移植性。

数据模块包括驱动系统常用的一些数据结构的抽象，包括数据项和通道等。数据模块存储EPI CS协议通信模块的通道数据，采用面向对象的相关技术，减小对象间的耦合性，从而提高数据的组织效率。

设备驱动模块和硬件设备进行通信，处理设备操作请求，根据数据模块存储的通道数据以及配置模块配置后的变化参数控制硬件设备。

本发明实施例提供的用于集成电路制造设备的标准化底层控制驱动系统可以使得集成电路制造设备中的工艺模块控制器(PMC)、集群控制器(CTC)和传输模块控制器(TMC)和外部硬件设备进行通信，高效调度和处理各个控制子系统对集成电路制造设备的各种硬件设备的大量操作请求。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本发明实施例的用于集成电路制造设备的标准化底层控制驱动系统的示意图；

图2为根据本发明实施例的用于集成电路制造设备的标准化底层控制驱动系统与客户端及硬件设备交互的示意图；

图3为中央控制模块的结构示意图；

图4为中央控制模块对GotPacketDelegate的事件处理流程；

图5为驱动系统中各种任务的继承关系图；

图6为调度单元的调度示意图；

图7为任务工厂类的继承类示意图；

图8为EPICS协议通信模块的通信示意图；

图9为EPICS协议通信模块中各种对象的创建过程示意图；

图10为连接状态机的状态转换图；

图11为读数据状态机的状态转换图；

图12为轮循状态机的状态转换图；

图13为监测状态机的状态转换图；

图14为EPICS协议通信模块的各个状态机之间的协作图；

图15为通道类的继承关系图；

图16为通道与硬件设备驱动的关系图；

图17为AbstractDevice类内部的函数调用关系；

图18为设备驱动模块的结构示意图；

图19为设备读操作时处理的流程图；

图20为DeviceFactory的UML描述示意图；

图21为异常处理模块的结构示意图；

图22为异常处理模块的处理流程图；和

图23为根据本发明实施例的驱动系统整体运行状态机模型。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

如图1所示，本发明实施例提供的用于集成电路制造设备的标准化底层控制驱动系统1000，包括中央控制模块100、EPICS协议通信模块200、配置模块300、数据模块400和设备驱动模块500。其中，中央控制模块100对整个驱动系统1000进行初始化并创建驱动系统1000的TCP/IP套接字以与客户端进行通信；EPICS协议通信模块200通过TCP/IP套接字建立与客户端的通信连接，并采用EPICS协议与客户端进行通信，接收来自客户端的设备操作请求及与客户端交换通道数据；配置模块300用于生成变化参数配置文件以配置驱动系统1000中的变化参数；数据模块400用于存储来自EPICS协议通信模块200的通道数据；设备驱动模块500用于处理设备操作请求，并根据数据模块400存储的通道数据以及配置模块300配置后的变化参数控制硬件设备。

图2示出了本发明实施例提供的标准化底层控制驱动系统1000与客户端3000和硬件设备2000的交互过程。在集成电路制造装备的控制系统中，存在大量需要被控制的硬件设备2000(例如串口设备和数据采集卡)。标准化底层控制驱动系统1000和客户端300采用图2所示的C/S型体系结构。如图2所示，标准化底层驱动系统1000相当于数据服务器，采用EPICS通信协议与客户端3000进行通信。标准化底层控制驱动系统1000与客户端3000采用EPICS通信协议交换通道的数据项(DataItem)。标准化底层控制驱动系统1000负责监听网络，处理各种大量的并发的客户端3000的设备操作请求，根据客户端300的请求控制硬件设备2000，例如各种串口设备(Serial)和PCI数据采集卡。采用上述C/S型体系结构，可以弥合各种不同设备的不同操作方式，由驱动系统1000向外提供硬件设备200的统一的控制接口。

数据项(DataItem)是客户端3000与标准化底层控制系统1000之间数据交换的逻辑单位。数据项(DataItem)是一种抽象的数据结构，在驱动系统1000中主要用来保存硬件设备2000的各种控制单元(I/O管脚)的状态，也可以用来在对象之间传递数据。硬件设备2000的各种控制单元(I/O points)被映射为DataItem，驱动系统1000通过控制DataItem来控制各种实际的硬件设备2000。客户端200和驱动系统1000之间通过Epics通信协议来交换通道的数据信息。

EPICS通信协议为一个基于消息的位于TCP/IP套接字之上的通信协议，在驱动系统1000的上下文中用来在客户端3000和服务器端(驱动系统1000端)之间交换通道数据。EPICS协议负责建立一种可靠地、高效的通信连接，以数据项(DataItem)为单位在通信双方之间进行信息交换。

驱动系统1000为服务器端，客户端3000向驱动系统1000请求操作特定的通道。驱动系统1000和客户端3000之间建立通信连接包括如下步骤：

1)驱动系统1000在计算机特定的端口建立一个服务器端套接字连接；

2)驱动系统1000在上述端口监听来自客户端3000的连接请求；

3)运行客户端3000；

4)客户端3000设置端口号等环境变量；

5)客户端3000生成一个客户端套接字连接，然后尝试连接驱动系统1000；

6)驱动系统1000接收连接请求，通信建立。

在连接建立之后，客户端3000可以与驱动系统1000进行通讯，驱动系统1000接收并且处理客户端3000的操作请求。

驱动系统1000采用EPICS通信协议来和客户端程序进行通信，负责处理各种大量的并发的客户端3000的设备操作请求。客户端3000和驱动系统1000之间的主要交互如下：

当客户端3000需要从一个通道读取值时，客户端3000会向驱动系统1000发送一个P READ型的EPICS消息，驱动系统1000在接收到消息之后，将调用和这个通道相关联的Read方法查询设备的特定通道的状态值，如果查询成功，则驱动系统1000向客户端3000返回相应的通道的数值；如果失败，则返回一个错误消息。

如果客户端3000绑定到驱动系统1000的一个通道，则当通道的数值改变时，驱动系统1000将通知客户端3000。驱动系统1000会定时查询设备，来检测通道数值是否改变。

当客户端3000需要向一个通道写数值时，客户端3000会向驱动系统1000发送一个P WRITE型EPICS消息。驱动系统1000接收到该消息之后，将调用和这个通道相关的Write方法把设备通道的状态设置为指定的值。

下面参考图3至图7描述中央控制模块100。中央控制模块100是整个驱动系统1000的核心，负责对整个驱动系统1000的初始化和调度。在驱动系统1000启动时，首先由中央控制模块1000初始化相关的对象，创建服务器端套接字，等待客户端的连接。在驱动系统1000中，对通道的读写、轮循、对硬件设备的定时测试等动作都被封装成任务，由中央控制模块100进行调度。

如图3所示，中央控制模块100包括初始化单元110、测试单元120和调度单元130。其中，初始化单元110用于对EPICS协议通信模块200、配置模块300、数据模块400和设备驱动模块500进行初始化，并创建EPICS协议通信模块200的TCP/IP套接字；测试单元120用于以预定的测试频率测试硬件设备2000的状态以更新与硬件设备2000相关的通道的参数；调度单元130用于对驱动系统1000中的各个任务进行调度以控制各个任务独立执行。

当驱动系统1000启动时，初始化单元110对相关的对象进行初始化，包括对EPICS协议通信模块200、配置模块300、数据模块400和设备驱动模块500进行初始化，创建服务器端套接字，等待客户端3000的连接。由EPICS协议通信模块200维护和管理网络连接，当客户端3000和驱动系统1000之间的连接建立之后，EPICS协议通信模块200管理网络连接，根据网络状态和接收到的数据包创建相应的任务，采取对应的动作。当中央控制模块100接收到来自客户端3000的P SHUTDOWN消息时，退出循环。

在中央控制模块100的循环中，对消息进行下述过程的处理。

由EPICS通信协议模块200的状态机监听网络，EpicsReader接收到Epics数据包以后，在方法ProcessEpicsPacket()中触发EpicsReaderEventAdapter的GotPacketDelegate事件，在GotPacketDelegate的处理函数中处理这些Epics数据包。其中EpicsReaderEventAdapter是EpicsReader向外提供的一个Facade，用于对GotPacketDelegate事件的注册和处理。在中央控制模块100中对GotPacketDelegate事件进行处理。

如图4所示，对GotPacketDelegate事件进行处理包括如下步骤：

S401：触发GotPacketDelegate事件；

S402：判断消息类型；

当消息类型为P_READ类型时，创建ReadForEpicsTask型的任务；

当消息类型为P_WRITE类型时，创建WriteForEpicsTask型的任务；

当消息类型为P_POLL类型时，注册Poller；

当消息类型为P_UNPOL类型时，取消注册Poller。

为了封装的需要，系统中P SHUTDOWN类型的消息已经在类EpicsReader的ProcessEpicsPacket()方法中进行了处理，所以图4中未示出P_SHUTDOWN类型的消息。

测试单元120可以分配单独的定时器线程以轮循地检查硬件设备2000的状态。具体而言，硬件设备2000的状态需要定时进行测试，以便及时更新与硬件设备2000相关的通道的值。针对每个通道，测试单元120可以分配单独的定时器线程，从而定时产生通道的读任务，以便从硬件设备2000读取值并且设置与硬件设备2000相关的通道的当前状态。在本发明的一个实施例中，硬件设备2000的测试频率从配置文件中获得。

调度单元130为整个中央控制模块100的核心。驱动系统1000对Epics数据包的处理、对硬件设备的测试、通道的读写等操作均封装成任务，由调度单元130进行调度。采用这种方式，可以使得各个任务的执行相对独立，便于长时间任务的执行，有利于提高系统的并发性和吞吐量。每个任务的设计，参考了Command模式。所有任务的抽象父类Task定义如下：

protected object id；//任务ID

protected bool active＝true；//任务是活动的，可执行

public Task(){}//构造函数

//参考Command模式，任务执行的核心内容

public abstract void Execute(ManagedThreadPool tp)；//主要用于在任务执行完成之后，将任务对象归还到系统对象池中

public abstract void Done()；

图5示出了系统中各种任务的继承关系。其中常用的有ReadForEpicsTask、WriteForEpicsTask、ReadTask等任务。

驱动系统1000的核心是任务调度和控制系统，其核心框架如图6所示。

在驱动系统1000中，对通道的读写、轮循(polling)以及对硬件设备的定时测试等均被封装成任务。如图6所示，调度单元130将各个任务放入任务优先级队列中，并根据优先级通过线程池中的多个工作线程，并行处理各个任务。其中，任务例如为ReadTask、ReadForEpicsTask和WriteForEpicsTask。

在驱动系统1000中共有4个优先级队列，其中优先级队列0和3供驱动系统1000自身使用，队列1供只读通道相关的任务使用，队列2供只写和读写型通道相关的任务使用。任务的优先级只与该任务相关的通道的优先级有关。

在本发明实施例的驱动系统1000中，实际使用如下三种任务：ReadTask、ReadForEpicsTask和WriteForEpicsTask。

下面分别对上述三种任务进行说明。

ReadTask：主要用于在定时测试通道相关的硬件设备时，为每个通道定时分配一个ReadTask以读取通道的值。

ReadForEpicsTask：当驱动系统1000(服务器端)接收到一个P_READ消息时，将分配一个ReadForEpicsTask任务，以读取通道值，然后向客户端3000返回相应的通道值。

WriteForEpicsTask：当驱动系统1000(服务器端)接收到一个P_WRITE消息时，将分配一个WriteForEpicsTask任务，以向通道写入指定值。

对于一个长时间执行的C/S型系统，客户端3000不断请求驱动系统1000(服务器端)的服务，服务器端根据请求创建任务对象、执行任务、然后销毁任务对象。调度单元130中采用了对象池(ObjectPool)的概念。不同的任务对象的结构成员不同，因此每种任务工厂分别维护一个对象池，从而可以解决大量任务对象的创建和销毁对系统的性能造成负面影响。

对象池(ObjectPool)采取一种单链表型的数据结构，两个指向PoolableObject对象的指针(poolHead和poolTail)分别指向链表的表头和表尾。为了对链表操作的方便，poolTail指向链表中最后一个任务对象，但是poolHead所指向的表头对象只是起标志作用，该表头不存储可用的任务对象。对链表的访问是互斥进行的。当需要从对象池取得一个任务对象时，如果对象池为空，而且可以创建对象，则调用任务工厂创建一个对象并返回。如果对象池非空，则取出链表中poolHead的下一个对象，初始化并且返回该对象。当任务执行完成之后，任务工厂会把该任务对象添加到链表尾。

在调度单元130采用工程模式创建和分配每种任务。在驱动系统1000中，任务工厂类的继承关系如图7所示。

在本发明的一个实施例中，调度单元130为了便于管理和调度线程，将线程封装成IOCPHandle对象。

ManagedIOCP实现了端口完成模型的核心，ManagedIOCP负责创建和注册线程对象(IOCPHandle)，将新的任务对象放到合适的优先级队列中，并且根据任务对象的优先级取出下一个合适的任务对象供系统调度。

ManagedThreadPool类参考Facade模式，是调度系统对外提供的使用接口。ManagedThreadPool类初始化ManagedIOCP对象，根据定义创建一个线程对象池，将线程对象注册到ManagedIOCP对象中，同时也将新的任务对象放到ManangedIOCP的优先级队列中。

下面参考图8至图14描述EPICS协议通信模块200。

EPICS协议通信模块200通过中央控制模块100建立的TCP/IP套接字建立与客户端3000的通信连接，并采用EPICS协议与客户端3000进行通信，接收来自客户端3000的设备操作请求及与客户端3000交换通道数据。EPICS通信协议是一个基于TCP/IP套接字之上的通信协议。EPICS协议的处理主要包括EPICS通信的管理和EPICS数据包的处理，从而提供可靠的通信连接。

EPICS协议通信模块200通过类EpicsAdapter向外提供使用接口。EpicsAdapter采用Singleton模式。在驱动系统1000中只有一个EpicsAdapter实例管理系统的Epics连接。EpicsAdapter类的设计参考了Facade模式，EpicsAdapter类的定义如下：

中央控制模块100采用EpicsAdapter的Init方法来初始化Epics连接，当Init方法的参数为True时，驱动系统1000被初始化为服务器端，否则驱动系统1000被初始化为客户端。

EPICS协议通信模块200在由中央处理模块100初始化后，监听来自客户端3000的连接请求，在接收到来自客户端3000的连接请求后，建立与客户端3000的通信连接。

具体而言，EPICS协议通信模块200在初始化之后，监听网络。在连接建立之后，Epics模块的多个状态机分别在单独的线程中执行，多个状态机之间相互作用，共同维护连接状态和处理Epics通信。如图8所示，与Epics数据包处理直接相关的就是EpicsReader类，当通信端接收到Epics数据包之后，将调用EpicsReader的ProcessEpicsPacket方法，在这个方法中处理接收到的Epics数据包，并且触发相应的GotPacketDelegate类型的事件(Event)。

图9示出了EPICS协议通信模块200中各种对象的创建过程。其中，

EpicsManager：对EpicsConnection进行一次封装，向外提供操作接口；

EpicsConnection：负责EPICS连接的建立和管理；

EpicsStateMachine：负责管理连接的状态；

EpicsPoller：主要负责处理P POLL数据包；

EpicsReader：负责该EPICS通信端的数据包的接收和处理；

EpicsMonitor：定时向通信的对方发送数据包，以检测当前连接状况；

EpicsPacketFactory：Epics数据包的创建工厂。

Epics消息类型包括：

P_INIT：客户端3000请求服务器(驱动系统1000)建立EPICS通信连接；

P_READ：客户端3000请求服务器(驱动系统1000)返回一个EPICS通道的值；

P_WRITE：客户端3000请求服务器(驱动系统1000)设置一个EPICS通道的setpoint；

P_POLL：客户端3000请求服务器(驱动系统1000)查询一个EPICS通道的值；当Control IO驱动接收到这个消息后立即返回这个通道的值，并且当该通道的值发生变化时，将向客户端发送一个P REFRESH消息通知所请求的EPICS通道的值已经发生变化。

P_UNPOLL：客户端3000请求服务器(驱动系统1000)取消POLL一个EPICS通道；

P_REFRESH：当客户端3000请求服务器(驱动系统1000)返回一个EPICS通道；且当数据条目值变化时，服务器向客户端3000发送一个P_REFRESH消息。

P_SHUTDOWN：客户端3000请求服务器(驱动系统1000)关闭建立的EPICS通信连接。

表1示出了驱动系统1000与客户端3000交互的EPICS数据包结构。

表1

如表1所示，标准的EPICS数据包是一个32字节的数组。如果通道属性值可以存放在8字节的VALUE字段中(如离散--整型、连续--双精度浮点型)，则EPICS数据包无EXTRA字段，此时数据包的第一个字段LEN为0；如果通道属性值无法存放在8字节的VALUE字段中(如字符串型)，则将通道属性值存放在EXTRA字段中，字段长度由数据包的第一个字段LEN指定，此时EPICS数据包长度大于32字节。

对EPICS数据包各字段的意义说明如下：

LEN：EXTRA字段长度。如果为0，则数据包长度为标准的32字节；如果非0，则数据包长度为32+LEN字节。

DTYPE：通道数据类型。其中，通道数据类型包括：

DISCRETE(0)：离散型；

CONTINUOUS(1)：连续型；

ASCII(2)：字符串型；

ALIST(3)：字符串列表型；

VARIANT(4)：通用型。

OPCODE：操作码。其中，操作码包括：

E_EVENT(-6)：错误事件；

E_REFRESH(-4)：错误更新；

P_READ(0)：read请求；

P_WRITE(1)：write请求；

P_POLL(2)：poll请求；

P_UNPOLL(3)：unpoll请求；

P_INIT(4)：初始化epics连接；

P_SHUTDOWN(5)：关闭epics连接；

P_REFRESH(6)：通道属性值更新；

P_GETIDBYNAME(8)：通过name获取id请求；

P_MESSAGE(11)：消息；

P_HEARTBEAT(27)：peer存活；

P_EVENT(28)：事件。

EPICS服务器支持的最小服务集对应：READ、WRITE、POLL、UNPOLL、INIT、SHUTDOWN、REFRESH及E_REFRESH。

NUM1：Board Number(Node Number，节点号)；

NUM2：Channel Number(通道号)；

CHID：Channel ID(通道ID)；

CHATTR：Channel Attribute(通道属性)，包括：

NAME(0)：名称；

UNITS(1)：单位；

DT_VALUE(2)：离散型通道值；

DT_SETPOINT(3)：离散型通道设置点；

CT_VALUE(4)：连续型通道值；

CT_SETPOINT(5)：连续型通道设置点；

ST_SETPOINT(6)：字串型通道设置点；

ST_VALUE(19)：字串型通道值；

DESCRIPTOR(21)：描述字串；

ACCURACY(22)：精度；

MIN(23)：最小值；

MAX(24)：最大值。

PEERID：对等实体ID(EPICS数据包接收方ID)。

REQUESTOR：Request ID(请求ID，和一个EPICS请求相对应)。

VALUE：用于存放通道属性值(非字串类型，可存放在8字节字段中)。

EXTRA：存储字串型通道属性值。

EPICS协议通信模块200包括四个状态机，每个状态机都以一个单独的线程进行。四个状态机包括连接状态机(EpicsStateMachine)、读数据状态机(EpicsReader)、轮循状态机(EpicsPoller)和监测状态机(EpicsMonitor)。其中，连接状态机用于维持所述EPICS协议通信模块200与客户端3000之间的连接的状态，状态为枚举值ConnectionStates；读数据状态机用于读取并处理通信中传输的通道数据，状态为枚举值ReaderStates；轮循状态机用于接收并处理轮循过程中传输的通道数据，状态为枚举值PollerStates；监测状态机用于定时向客户端3000发送数据包以检测EPICS协议通信模块200和客户端3000之间的连接状态，态为枚举值MonitorStates。连接状态机、读数据状态机、轮循状态机和监测状态机均以单独的线程运行。

图10示出了连接状态机(EpicsStateMachine)的状态转换过程，其中连接状态机负责维持连接的状态。

图11示出了读数据状态机(EpicsReader)的状态转换过程，其中读数据状态机负责该EPICS通信端的数据包的接收和处理。在连接建立以后，EpicsReader处于STANDBY状态。在这个状态中，EpicsReader不停地执行DoRead()方法。在DoRead()方法中，EpicsReader调用EpicsConnection的方法从Epics网络连接中读取数据包，然后调用ProcessEpicsPacket()处理读到的数据包。在ProcessEpicsPacket()方法中，为了封装的需要，首先需要对P_SHUTDOWN类型的消息进行处理，然后触发GotPacketDelegate事件。

图12示出了轮循状态机(EpicsPoller)的状态转换过程，其中轮循状态机负责EPICS通信端的数据包的接收和处理。

图13示出了监测状态机(EpicsMonitor)的状态转换过程，其中监测状态机定时向通信的对方发送数据包，以检测当前连接状况。在客户端3000和驱动系统1000成功建立连接之后，EpicsMonitor将处于STANDBY状态，在这个状态，EpicsMonitor定时向通信的对方发送HeartBeat型数据包，以检测网络状态。当网络断开时，监测状态机发送HeartBeat型数据包将触发一个异常，系统就会检测到EPICS协议通信模块120和客户端3000之间的网络连接已经断开。

图14示出了EPICS协议通信模块120的各个状态机的协作工作图。

配置模块300负责驱动系统1000中易变参数的处理。具体而言，配置模块300用于将驱动系统1000中经常变化的参数放置到变化参数配置文件中。在本发明的一个实施例中，变化参数配置文件以XML文件格式保存。

配置模块300主要配置如下两类参数：

a)EPICS协议通信模块200和客户端3000之间的各个通道的配置参数：包括描述符列表、节点、各种通道等条目

1.1)描述符列表：保存驱动系统1000中各种描述符列表，以及每种列表所包含的条目。描述符列表示例如下：

1.2)节点：对节点进行配置，节点的主要参数是节点号，每个节点下面的通道被分为三类，分别为ContinuousChannels、DiscreteChannels、和StringChannels。在此三类Xml节点下的为具体的通道。节点示例如下：

1.3)通道：通道保存有每个Channel对象的关键信息。通道分为三类ContinuousChannels、DiscreteChannels、和StringChannels，每类的关键信息都不同。

1.3.1)离散型通道DiscreteChannel：

离散型通道包括通道的ID、通道号、通道名、描述符列表名、最小值、最大值、优先级、读写类型。离散型通道示例如下：

1.3.2)连续型通道ContinuousChannel：

连续型通道包括通道的ID、通道号、通道名、单位、最小值、最大值、精确度、优先级、读写类型。连续型通道示例如下：

1.3.3)字符串型通道StringChannel：

字符串型通道包括通道的ID、通道号、通道名、最大长度、优先级、读写类型。字符串型通道示例如下：

b)其他可配置的易变参数包括：

1)PollingFrequency：轮循通道时，服务器(驱动系统1000)向上层(客户端3000)定时反馈通道值的时间间隔；

2)deviceTestFrequency：服务器(驱动系统1000)定时测试硬件设备2000的测试时间间隔；

3)IP：服务器端(驱动系统1000端)的IP地址；

4)Port：服务器端(驱动系统1000端)监听网络连接的端口；

5)MaxThreads：驱动系统1000中存在的线程的最大数量；

6)ConcurrentThreads：驱动系统1000中可以并行执行的线程数量。

在本发明的一个实施例中，配置模块300可以进一步生成用于解析变化参数配置文件的关键类ConfigProvider。

关键类ConfigProvider负责解析变化参数配置文件，取得通道等配置参数，保存到ConfigProvider的成员对象中。为了对配置文件解析的一致性，驱动系统1000中只能有一个ConfigProvider对象，ConfigProvider采用Singleton模式。在ConfigProvider的Init方法中对XML文件进行解析，

在对XML配置文件进行解析中，关键是使用类XmlNode的如下几个方法或属性：

SelectSingleNode(string path)：获得满足路径path的第一个节点对象。

SelectNodes(string path)：获得满足路径path的所有节点对象组成的列表。

InnerText属性：该节点的文本内容，如对于节点

<ChannelName>channel 10</ChannelName>，其InnerText就是”channel 10”

Attributes属性：该节点的属性集合，

如对于节点<Descriptors Name＝″OpenStatus″>，”Name”就是该节点的一个属性。

当驱动系统1000需要上述参数时，可以在运行时通过配置模块3000获取这些参数。当驱动系统1000中上述参数经常变化时，可以直接修改变化参数配置文件，而不用重新编译整个驱动系统1000，这样大大提供了驱动系统1000的可移植性。

数据模块400用于存储来自EPICS协议通信模块200的通道数据。数据模块400可以存储驱动系统1000中常用的一些数据结构的抽象，包括数据项DataItem、通道Channel等。数据结构是一个完善的系统的基础，数据结构、数据对象设计的好坏直接关系到系统整体的运行效率和控制算法的实现。在数据结构、数据对象的设计过程中，要采用面向对象的相关技术，减小对象间的耦合性，提供数据的组织效率。

下面列出了几个主要类所包含的一些最基本的数据成员：

(1)通道类型：标识一个通道是连续的、离散的或是字符串型的。

CONTINUOUS＝0，//连续型

DISCRETE＝1，//离散型

STRING＝2，//字符串型

(2)通道读写类型：标识一个通道是只读的、只写的或是读写的。

Read＝0，//只读型

Write＝1，//只写型

ReadWrite＝2，//读写型

(3)通道抽象类：所有具体的通道类(离散型通道、连续型通道、字符串型通道)的父类，用于封装通道的常见操作。

由上述(1)(2)可知，根据通道相关的数据类型，通道可以分为：连续型，离散型和字符串型。根据通道的读写类型，通道可以分为：只读型，只写型和读写型。综合这两种分类，通道分为如下六种：连续型只读通道、连续型只写通道、连续型读写通道、离散型只读通道、离散型只写通道、离散型读写通道、字符串型只读通道、字符串型只写通道、字符串型读写通道。

在本发明实施例的驱动系统1000中，通道类Channel的子类只有三种：连续型通道ContinuousChannel、离散型通道DiscreteChannel和字符串型通道StringChannel。这三种类型都包含一个ReadWriteTypes型的成员，以表示该对象是只读型、只写型或是读写型通道。图15为通道类的继承类图。

在本发明实施例的驱动系统1000中，通道对象是底层硬件I/O point的一次封装。每个通道分别对应底层的一个硬件设备，即对应一个硬件控制点。通道的值即为对应的I/O point的值。硬件设备2000作为通道Channel的一个成员。通道和硬件设备2000的关系如图16所示，其中，通道可以包括连续型通道、离散型通道和字符串型通道。图17示出了AbstractDevice类内部的函数调用关系，即通道读写操作的顺序。

(4)节点类：节点是指逻辑上或是物理上相关的EPICS通道的集合。每个驱动至少要有一个节点。服务器(驱动系统1000)驱动可以任意指定作为节点的EPICS通道集合。

每当创建一个新的通道时，就会把通道同时添加到通道工厂和该通道所属的节点中的集合里，以方便对通道的管理可操作。

(5)通道工厂类：全局唯一实例，管理和创建节点与通道：采用Singleton模式，以确保整个Control IO端只有一个工厂实例。这个实例负责驱动系统1000中所有节点和通道的创建，并且有两个Hashtable，分别保存驱动系统1000中所有可用的节点和通道。

下面参考图18至图21描述设备驱动模块500。设备驱动模块500和硬件设备2000进行通信，处理设备操作请求，向外提供设备相关接口。在标准化通用接口软件包中，对于各类设备具有共性的读写操作均提供一致的接口，因此需要对不同类型设备已有的驱动程序进行相应的封装。设备驱动模块500中包含一些设备抽象类，对实际的硬件设备2000进行抽象，封装了对常用硬件设备2000的操作方法。

如图18所示，设备驱动模块500包括映射单元510、读写单元520、超时处理单元530和设备管理单元540。

映射单元510用于对通道和硬件设备2000的读/写接口进行映射以对硬件设备2000进行读/写操作。具体而言，映射单元510封装对实际硬件设备2000的抽象，完成通道和实际硬件的IO point的映射。

读写单元520用于读取数据模块400存储的通道数据、配置模块300配置后的变化参数以及硬件设备2000的数据，并向硬件设备2000中写入数据。读写单元520对硬件设备200的读写操作的原则：可以有多个客户同时对硬件设备2000进行读操作，但每个时刻只能有一个客户对硬件设备2000进行写操作。这种原则是由读者/写者模型来保证。AbstractDevice类是所有实际设备的父类，在AbstractDevice内部提供了对设备操作的抽象接口，同时对设备操作超时等情况进行了处理。

超时处理单元530用于处理对硬件设备2000的读操作超时。图16示出了设备读操作超时处理的流程。设备读操作的超时，包括两种情况：

1)在对硬件设备2000的实际读操作之前，如果有其他客户对硬件设备2000进行写操作，则此时该客户需要等待，出现超时。

这种超时通过读者/写者锁的AcquireReaderLock方法处理。

执行S1901：超时处理单元530判断在预定时间内是否获得读写锁，如果在所述预定时间内未获得所述读写锁，则执行S1902；否则执行S1905。

S1902：抛出超时异常；

S1903：返回False；

S1904：释放读写锁。

2)在对硬件设备2000进行实际操作时，硬件设备2000的读操作可能要花费很长时间，出现超时。对硬件设备2000进行实际的读写是通过异步委托机制在一个新的线程里完成的，可以取得等待异步委托完成的WaitHandle句柄，使用该句柄的WaitOne()方法处理设备操作超时。

S1905：对硬件设备2000进行实际的读写是通过异步委托机制在一个新的线程BeginInvoke()里完成；

S1906：取得等待异步委托完成的WaitHandle句柄，判断是否超时，如果超时则执行S1907，抛出超时异常，否则执行S1908，读取硬件设备2000的数据。

S1909：返回True，执行S1904，释放读写锁。

AbstractDevice类中对底层设备的实际读写操作是由InternalReadDevice函数和InternalWriteDevice函数处理的，而高层的Read和Write函数封装了底层的这两个函数并且对超时等异常情况进行处理以供通道等对象调用。AbstractDevice的子类，即对各种实际的硬件设备2000的封装类，必须重写InternalReadDevice方法和InternalWriteDevice方法以处理各种具体设备的读写情况。AbstractDevice类内部的函数调用关系如图17所示。

设备管理单元540用于创建和维护硬件设备2000。驱动系统1000中包括一个设备工厂类DeviceFactory，完成对驱动系统1000中所有硬件设备的创建和维护。图20示出了DeviceFactory的UML描述(Singleton模式)。

设备管理单元540的设备工厂类可以创建如下四类模拟设备：

随机模拟类设备(RandomSimulatedDevice)：对所述随机模拟类设备的每次读操作均分别返回一个随机的正数；

连续型设备(StaticContinuousDevice)：在所述连续型设备中的硬件设备保存一个双精度浮点型数值，并对所述双精度浮点型数值进行读/写；

离散型设备(StaticDiscreteDevice)：在所述离散型设备中的硬件设备保存一个整型(int型)数值，并对所述整型数值进行读/写；

字符串型设备(StaticStringDevice)：在所述字符串型设备中的硬件设备保存一个字符串型(string型)数值，并对所述字符串型数值进行读/写。

为了提高驱动系统1000的可靠性和鲁棒性，需要对各种异常进行处理。本发明实施例的驱动系统1000进一步包括异常处理模块600，用于在驱动系统1000抛出异常时，接管所述异常，并查找异常处理向量表以获得所述异常的异常处理函数，根据所述异常处理函数对所述异常进行处理。其中，异常处理模块600主要处理与底层数据结构以及与Epics协议相关的一些比较重要的异常。当驱动系统1000的某个部分出现异常时，由异常处理模块600接管这个异常，并对该异常进行相关的处理。

在异常处理模块600中包括一个相对独立的异常处理类AlarmServer。AlarmServer类采用Singleton模式。在驱动系统1000中只允许存在一个AlarmServer实例，以便对系统中的所有异常进行集中处理。AlarmServer维护一张异常处理向量表。异常处理向量表保存了每种预定义的异常类，以及每种异常类型对应的异常处理函数。

如图21所示，当系统抛出特定的异常时，可以使用这个AlarmServer接管异常，AlarmServer查找异常处理向量表。异常处理向量表类似PC底层的中断向量表，保存了各种可以处理的异常类型，以及每种异常类型对应的异常处理函数。当AlarmServer接收到一个Alarm时，将查询异常处理向量表，找到对应的处理函数。通过查找异常处理向量表获得这种异常的处理类的类型，进而对异常进行处理，并且进行日志记录等相关操作。其中，异常日志处理包括调用日志模块700，进行相应的异常记录。日志模块700将在下文中进行详细说明。

在本发明的一个实施例中，驱动系统1000抛出异常主要有两种方式。图22示出了对两种异常的处理流程。

1)对于一般的异常可以使用throw new Exception(Message)方式。采用这种方式抛出的异常在驱动系统100中显示地用try{}catch语句捕获。

2)对于与底层数据结构以及与Epics通信协议相关的一些比较重要的异常，可以使用AlarmServer处理，AlarmServer会查找异常处理向量表，找出预先指定的异常处理类来处理该种异常。在异常处理类里可以集中进行一些指定的处理，如日志记录，向通信对方发送消息等等。

本发明实施例的标准化底层控制驱动系统1000进一步包括日志模块700，用于以日志的形式记录驱动系统1000运行过程中的信息。

日志模块700只有一个类LoggingService，用户需要进行日志记录时，只需要调用LoggingService的成员函数就可以了。LoggingService类的设计参考了Adapter模式和Bridge设计模式。LoggingService的定义如下：

日志模块700可以提供一个灵活高效的日志系统来记录驱动系统1000的运行情况，以便当驱动系统1000出现问题时可以及时发现问题所在，从而大大提高驱动系统1000的可维护性，并且也可以使用日志模块700进行程序的调试和维护

图23示出了驱动系统1000整体运行状态机模型。如图中所示，首先进行初始化驱动系统1000，包括创建自定义通道、修改已有通道的读写委托、读取配置文件、创建通道和节点、初始化EPICS协议通信模块等任务。在初始化完成后，运行驱动系统1000，包括运行系统框架，进入消息循环。在处理完成后，驱动系统1000停止处理并执行清理任务。在清理完成后，重新启动系统并执行新的处理任务，在处理完成后进行相关的清理任务。

在本发明的一个实施例中，驱动系统1000的整体启动和调度采用类Core。

Core类是整个驱动系统1000调度和使用的接口。在Core类中，主要执行下述任务：

a)初始化各个任务对象的工厂，以在处理Epics数据包时创建相应的任务

b)初始化通道工厂，以在需要的时候创建通道和节点

c)初始化EpicsAdapter，以便使用Epics协议进行通信

d)初始化ConfigProvider，以便系统使用配置文件

e)初始化设备工厂，以创建各种设备

f)对Epics数据包进行处理

Core类也采用了Singleton模式，驱动系统1000中只有一个Core型对象。

本发明实施例提供的用于集成电路制造设备的标准化底层控制驱动系统基于Windows xp操作系统，采用Visual C#实现。标准化底层控制驱动系统可以使得集成电路制造设备中的工艺模块控制器(PMC)、集群控制器(CTC)和传输模块控制器(TMC)和外部硬件设备进行通信，高效调度和处理各个控制子系统对集成电路制造设备的各种硬件设备的大量操作请求。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同限定。

Claims

1.一种用于集成电路制造设备的标准化底层控制驱动系统，所述标准化底层控制驱动系统用于接收来自客户端的设备操作请求，并根据所述设备操作请求控制硬件设备，所述标准化底层控制驱动系统包括：

中央控制模块，所述中央控制模块对所述驱动系统进行初始化并创建所述驱动系统的TCP/IP套接字以与客户端进行通信；

EPICS协议通信模块，所述EPICS协议通信模块通过所述TCP/IP套接字建立与所述客户端的通信连接，并采用EPICS协议与所述客户端进行通信，接收来自所述客户端的设备操作请求及与所述客户端交换通道数据；

配置模块，所述配置模块用于生成变化参数配置文件以配置所述驱动系统中的变化参数；

数据模块，所述数据模块用于存储所述来自所述EPICS协议通信模块的通道数据；和

设备驱动模块，所述设备驱动模块处理所述设备操作请求，并根据所述数据模块存储的通道数据以及所述配置模块配置后的变化参数控制硬件设备。

2.如权利要求1所述的标准化底层控制驱动系统，其中，所述变化参数配置文件以XML文件格式保存。

3.如权利要求2所述的标准化底层控制驱动系统，其中，所述变化参数配置文件中的变化参数包括：

4.如权利要求1所述的标准化底层控制驱动系统，其中，所述配置模块进一步生成用于解析所述变化参数配置文件的关键类。

5.如权利要求1所述的标准化底层控制驱动系统，其中，所述EPICS协议通信模块在由所述中央处理模块初始化后，监听来自所述客户端的连接请求，在接收到来自所述客户端的连接请求后，建立与所述客户端的通信连接。

6.如权利要求5所述的标准化底层控制驱动系统，其中，所述EPICS协议通信模块包括：

连接状态机，所述连接状态机用于维持所述EPICS协议通信模块与所述客户端之间的连接的状态；

读数据状态机，所述读数据状态机用于读取并处理通信中传输的通道数据；

轮循状态机，所述轮循状态机用于接收并处理轮循过程中传输的通道数据；和

监测状态机，所述监测状态机用于定时向所述客户端发送数据包以检测所述EPICS协议通信模块和所述客户端之间的连接状态，

其中，所述连接状态机、读数据状态机、轮循状态机和监测状态机均以单独的线程运行。

7.如权利要求6所述的标准化底层控制驱动系统，其中，当所述监测状态机发送的数据包触发到一个异常时，则检测到所述EPICS协议通信模块和所述客户端之间通信连接断开。

8.如权利要求1所述的标准化底层控制驱动系统，其中，所述数据模块存储的通道数据包括：

通道类型，所述通道类型包括连续型、离散型、字符串型；

通道读写类型，所述通道读写类型包括只读型、只写型、读写型；

通道类型的父类，所述通道类型的父类用于封装所述的通道的操作；

节点类，所述节点类为逻辑上或物理上相关的EPICS通道的集合；

通道工厂类，所述通道工厂类用于管理和创建节点和通道。

9.如权利要求8所述的标准化底层控制驱动系统，其中，通道包括：

连续型只读通道、连续型只写通道、连续型读写通道、离散型只读通道、离散型只写通道、离散型读写通道、字符串型只读通道、字符串型只写通道和字符串型读写通道。

10.如权利要求8所述的标准化底层控制驱动系统，其中，所述每个通道分别对应一个硬件设备。

11.如权利要求8所述的标准化底层控制驱动系统，其中，所述驱动系统包括至少一个节点，其中所述驱动系统任意指定作为所述节点的EPICS通道集合。

12.如权利要求11所述的标准化底层控制驱动系统，其中，当创建一个通道时，将所述通道同时添加到所述通道工厂类和所述通道所属的节点的EPICS通道集合中。

13.如权利要求1所述的标准化底层控制驱动系统，其中，所述设备驱动模块包括：

映射单元，所述映射单元用于对所述通道和所述硬件设备的读/写接口进行映射以对所述硬件设备进行读/写操作；

读写单元，所述读写单元用于读取所述数据模块存储的通道数据、所述配置模块配置后的变化参数以及所述硬件设备的数据，并向所述硬件设备中写入数据；

超时处理单元，所述超时处理单元用于处理对所述硬件设备的读操作超时；和

设备管理单元，所述设备管理单元用于创建和维护所述硬件设备。

14.如权利要求13所述的标准化底层控制驱动系统，其中，所述超时处理单元判断在预定时间内是否获得读写锁，如果在所述预定时间内未获得所述读写锁，则抛出超时异常；如果在所述预定时间内获得所述读写锁，则通过异步委托机制在另一个线程里执行，包括判断是否超时，如果超时则抛出超时异常，释放所述读写锁，否则读取所述硬件设备的数据，释放所述读写锁。

15.如权利要求13所述的标准化底层控制驱动系统，其中设备管理单元将所述硬件设备分为四类，包括：

随机模拟类设备，对所述随机模拟类设备中的硬件设备的每次读操作均分别返回一个随机的正数；

连续型类设备，在所述连续型设备中的硬件设备保存一个双精度浮点型数值，并对所述双精度浮点型数值进行读/写；

离散型设备，在所述离散型设备中的硬件设备保存一个整型数值，并对所述整型数值进行读/写；

字符串型设备，在所述字符串型设备中的硬件设备保存一个字符串型数值，并对所述字符串型数值进行读/写。

16.如权利要求1所述的标准化底层控制驱动系统，其中，所述中央控制模块包括：

初始化单元，所述初始化单元用于对所述EPICS协议通信模块、配置模块、数据模块和设备驱动模块进行初始化，并创建所述EPICS协议通信模块的TCP/IP套接字；

测试单元，所述测试单元用于以预定的测试频率测试所述硬件设备的状态以更新与所述硬件设备相关的通道的参数；和

调度单元，所述调度单元用于对所述驱动系统中的各个任务进行调度以控制所述各个任务独立执行。

17.如权利要求16所述的标准化底层控制驱动系统，其中，所述调度单元将所述各个任务放入任务优先级队列，并根据优先级通过线程池中的多个工作线程，并行执行所述各个任务。

18.如权利要求1所述的标准化底层控制驱动系统，其中，进一步包括异常处理模块，用于在所述驱动系统抛出异常时，接管所述异常，并查找异常处理向量表以获得所述异常的异常处理函数，根据所述异常处理函数对所述异常进行处理。

19.如权利要求18所述的标准化底层控制驱动系统，其中，所述异常处理向量表包括异常类型以及每种异常类型对应的异常处理函数。

20.如权利要求1所述的标准化底层控制驱动系统，其中，进一步包括日志模块，所述日志模块以日志的形式记录所述驱动系统运行过程中的信息。