WO2012151886A1 - 一种标准化底层控制驱动系统 - Google Patents

一种标准化底层控制驱动系统 Download PDF

Info

Publication number
WO2012151886A1
WO2012151886A1 PCT/CN2011/081952 CN2011081952W WO2012151886A1 WO 2012151886 A1 WO2012151886 A1 WO 2012151886A1 CN 2011081952 W CN2011081952 W CN 2011081952W WO 2012151886 A1 WO2012151886 A1 WO 2012151886A1
Authority
WO
WIPO (PCT)
Prior art keywords
channel
standardized
module
read
drive system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2011/081952
Other languages
English (en)
French (fr)
Inventor
徐华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tsinghua University
Original Assignee
Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tsinghua University filed Critical Tsinghua University
Publication of WO2012151886A1 publication Critical patent/WO2012151886A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms

Definitions

  • the present invention relates to the field of computer applications and integrated circuit equipment, and more particularly to a standardized underlying control drive system. Background technique
  • the drive control system plays a pivotal role as part of the IC (Integrated Circuit) industry.
  • the drive control system of the existing integrated circuit has poor versatility and cannot meet the communication between the integrated circuit manufacturing equipment process module controller (PMC) and the transmission module controller (TMC) and common external hardware devices, thereby causing the integrated circuit
  • PMC integrated circuit manufacturing equipment process module controller
  • TMC transmission module controller
  • the various hardware devices of the manufacturing equipment are inefficient in operation and processing. Summary of the invention
  • An object of the present invention is to at least solve one of the above technical drawbacks, and in particular to provide an efficient and versatile standardized underlying control drive system for an integrated circuit manufacturing apparatus.
  • an embodiment of the first aspect of the present invention provides a standardized underlying control driving system for receiving a device operation request from a client, and controlling the hardware device according to the device operation request.
  • the standardized underlying control drive system includes: a central control module that initializes the standardized underlying control drive system and creates a TCP/IP socket of the standardized underlying control drive system to communicate with the client Communicating; an EPICS protocol communication module, the EPICS protocol communication module establishes a communication connection with the client through the TCP/IP socket, and communicates with the client by using an EPICS protocol to receive from the client a device operation request and exchange channel data with the client; a configuration module, the configuration module is configured to generate a change parameter configuration file to configure a change parameter in the standardized underlying control drive system; and a data module, where the data module is used For storing the source EPICS protocol channel data communication module; and a module device driver, the device driver of the device operation request processing module, and a data channel according to a
  • the central control module includes: an initialization unit, configured to initialize the EPICS protocol communication module, the configuration module, the data module, and the device driver module And creating a TCP/IP socket of the EPICS protocol communication module; a test unit, a test unit is configured to periodically test a state of the hardware device to update a parameter scheduling unit of a channel associated with the hardware device, where the scheduling unit is configured to schedule each task in the standardized underlying control driving system to control Each task is described independently.
  • an initialization unit configured to initialize the EPICS protocol communication module, the configuration module, the data module, and the device driver module And creating a TCP/IP socket of the EPICS protocol communication module
  • a test unit a test unit is configured to periodically test a state of the hardware device to update a parameter scheduling unit of a channel associated with the hardware device, where the scheduling unit is configured to schedule each task in the standardized underlying control driving system to control Each task is described independently.
  • the scheduling unit puts the respective tasks into a task priority queue, and executes the plurality of working threads in the thread pool according to the priority of the channel corresponding to the respective tasks. Multiple tasks of the same priority.
  • the change parameter configuration file is saved in an XML file format.
  • the change parameters in the change parameter configuration file include:
  • a configuration parameter of each channel between the EPICS protocol communication module and the client a time interval for the standardized underlying control driving system to periodically feed back a channel value to the client, and the standardized underlying control driving system timing test station a test time interval of the hardware device, an IP address of the standardized underlying control drive system end, a port of the standardized underlying control drive system listening network connection, a maximum number of threads existing in the standardized underlying control drive system, and the standardization The number of threads executing in parallel in the underlying control drive system.
  • the configuration module further generates a key class for parsing the change parameter profile.
  • the EPICS protocol communication module listens for a connection request from the client, and receives a connection request from the client. After that, a communication connection with the client is established.
  • the EPICS protocol communication module includes: a connection state machine, the connection state machine is configured to maintain a state of a connection between the EPICS protocol communication module and the client;
  • the read data state machine is configured to read and process channel data transmitted between the client and the standardized underlying control driving system in communication; a feedback state machine, wherein the feedback state machine is used in the When the client queries the standardized underlying control driving system for the channel value, the channel value is returned to the client, and when the channel value changes, the channel value change notification is sent to the client;
  • the monitoring state machine is configured to periodically send a data packet to the client to detect a connection state between the EPICS protocol communication module and the client,
  • the communication connection between the EPICS protocol communication module and the client is detected to be disconnected.
  • the channel data stored by the data module includes: a channel type, the channel type includes a continuous type, a discrete type, a string type; a channel read/write type, and the channel read/write type includes only Read type, write-only type, read-write type; parent class of channel type, the parent class of the channel type is used to encapsulate the operation of the channel; node class, the node class is logically or physically related EPICS A collection of channels, including a plurality of nodes, the plurality of nodes being a continuous channel set, a discrete channel set, or a string type channel set; a channel factory class, the channel factory class for managing and creating nodes and channels.
  • the channel includes: a continuous read-only channel, a continuous write-only channel, a continuous read-write channel, a discrete read-only channel, a discrete write-only channel, a discrete read-write channel, String read-only channel, string-type write-only channel, and string-type read-write channel.
  • each channel corresponds to a hardware device.
  • the standardized underlying control drive system includes at least one node, wherein the standardized underlying control drive system arbitrarily designates a set of EPICS channels as the nodes.
  • the channel when a channel is created, the channel is simultaneously added to the channel factory class and the EPICS channel set of the node to which the channel belongs.
  • the device driving module includes: a mapping unit, configured to map the channel and a read/write interface of the hardware device to read the hardware device/ a write operation; the read/write unit is configured to read channel data stored by the data module, change parameters of the configuration module configuration, and data of the hardware device, and write to the hardware device a timeout processing unit, the timeout processing unit is configured to process a read operation timeout for the hardware device; and a device management unit, the device management unit is configured to create and maintain the hardware device.
  • a mapping unit configured to map the channel and a read/write interface of the hardware device to read the hardware device/ a write operation
  • the read/write unit is configured to read channel data stored by the data module, change parameters of the configuration module configuration, and data of the hardware device, and write to the hardware device
  • a timeout processing unit is configured to process a read operation timeout for the hardware device
  • a device management unit the device management unit is configured to create and maintain the hardware device.
  • the timeout processing unit determines whether a read/write lock is obtained within a predetermined time, and if the read/write lock is not obtained within the predetermined time, a timeout exception is thrown, if If the read-write lock is obtained within a predetermined time, it is judged whether it times out in another thread through an asynchronous delegation mechanism, if yes, a timeout exception is thrown, and the read-write lock is released, if otherwise, the data of the hardware device is read. And release the read-write lock.
  • the device management unit divides the hardware devices into four categories, including: a random analog device, where each read operation of the hardware device in the random analog device returns a random a continuous type device, the hardware device in the continuous type device stores a double precision floating point type value, and reads/writes the double precision floating point type value; the discrete type device, the discrete type device The hardware device in the middle saves an integer value and reads/writes the integer value; the string device, the hardware device in the string device saves a string value, and the string is The type value is read/written.
  • the method further includes an exception processing module, configured to: when the normalized underlying control driving system throws an exception, look up an exception processing vector table to obtain an exception handling function of the exception, And processing the abnormality according to the exception handling function.
  • an exception processing module configured to: when the normalized underlying control driving system throws an exception, look up an exception processing vector table to obtain an exception handling function of the exception, And processing the abnormality according to the exception handling function.
  • the exception handling vector table includes an exception type and an exception handling function corresponding to each exception type.
  • the log module is further included, and the log module records information in the running process of the standardized underlying control driving system in the form of a log.
  • the standardized underlying control driving system for integrated circuit manufacturing equipment is based on the Windows XP operating system, and is implemented by Visual C#.
  • the standardized underlying control drive system includes a central control module, an EPICS protocol communication module, a configuration module, a data module, and a device driver module. Among them, central control The module can initialize and schedule the entire drive system, including creating a TCP/IP socket for the drive system to communicate with the client.
  • the EPICS protocol communication module can establish a communication connection with the client according to the created TCP/IP socket and communicate with the client using the EPICS protocol.
  • the processing of the EPICS protocol includes the management of EPICS communications and the processing of EPICS packets, providing a reliable communication link.
  • the configuration module can generate a change parameter profile to configure the change parameters in the standardized underlying control drive system.
  • these parameters can be obtained through the configuration module at runtime.
  • the configuration file can be directly modified without recompiling the entire system, thereby greatly improving the portability of the drive system.
  • the data module includes abstractions of some data structures commonly used by the drive system, including data items and channels.
  • the data module stores the channel data of the EPI CS protocol communication module, and uses object-oriented related technology to reduce the coupling between objects, thereby improving the data organization efficiency.
  • the device driver module communicates with the hardware device, processes the device operation request, and controls the hardware device according to the channel data stored by the data module and the change parameter configured by the configuration module.
  • the standardized underlying control driving system can enable the process module controller (PMC), the cluster controller (CTC), and the transmission module controller (TMC) in the integrated circuit manufacturing equipment to communicate with the external hardware device, and efficiently dispatch And processing a large number of operational requests from various control subsystems to various hardware devices of the integrated circuit manufacturing equipment.
  • PMC process module controller
  • CTC cluster controller
  • TMC transmission module controller
  • FIG. 1 is a schematic diagram of a standardized underlying control drive system in accordance with an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a standardized underlying control driving system interacting with a client and a hardware device according to an embodiment of the present invention
  • Figure 3 is a schematic structural view of a central control module
  • Figure 4 shows the event processing flow of the central control module to the GotPacketDelegate
  • Figure 5 is an inheritance relationship diagram of various tasks in the drive system
  • FIG. 6 is a schematic diagram of scheduling of a scheduling unit
  • Figure 7 is a schematic diagram of the inheritance class of the task factory class
  • FIG. 9 is a schematic diagram of a process of creating various objects in an EPICS protocol communication module
  • Figure 10 is a state transition diagram of the connected state machine
  • Figure 11 is a state transition diagram of a read data state machine
  • Figure 12 is a state transition diagram of the feedback state machine
  • Figure 13 is a state transition diagram of the monitoring state machine
  • Figure 14 is a diagram of cooperation between state machines of the EPICS protocol communication module
  • Figure 15 is an inheritance relationship diagram of the channel class
  • Figure 16 is a diagram of the relationship between the channel and the hardware device driver
  • Figure 17 shows the function call relationship inside the AbstractDevice class.
  • FIG. 18 is a schematic structural diagram of a device driving module
  • Figure 19 is a flow chart of processing when the device is read
  • Figure 20 is a schematic diagram of the UML description of the DeviceFactory
  • 21 is a schematic structural diagram of an exception processing module
  • Figure 22 is a process flow diagram of the exception handling module.
  • the standardized underlying control driving system 1000 includes a central control module 100, an EPICS protocol communication module 200, a configuration module 300, a data module 400, and a device driver module 500.
  • the central control module 100 initializes the entire drive system 1000 and creates a TCP/IP socket of the drive system 1000 to communicate with the client; the EPICS protocol communication module 200 establishes a communication connection with the client through the TCP/IP socket.
  • the configuration module 300 is configured to generate a change parameter configuration file to configure the change parameters in the drive system 1000;
  • the data module 400 For storing channel data from the EPICS protocol communication module 200;
  • the device driver module 500 is configured to process the device operation request, and control the hardware device according to the channel data stored by the data module 400 and the variation parameters configured by the configuration module 300.
  • the standardized bottom layer control driving system 1000 provided by the embodiment of the present invention can be used for controlling the integrated circuit manufacturing equipment.
  • FIG. 2 shows an interaction process between the standardized underlying control driving system 1000 and the client 3000 and the hardware device 2000 provided by the embodiment of the present invention.
  • the standardized underlying control drive system 1000 and client 300 employ the C/S type architecture shown in FIG.
  • the standardized underlying driver system 1000 is equivalent to a data server, and communicates with the client 3000 using an EPICS communication protocol.
  • the standardized underlying control drive system 1000 and the client 3000 exchange the data items (Dataltem) of the channel using the EPICS communication protocol.
  • the standardized underlying control drive system 1000 is responsible for monitoring the network and handling various large numbers of concurrent client 3000 devices.
  • the operation request controls the hardware device 2000 according to the request of the client 300, for example, various serial devices (Serial) and PCI data collection cards.
  • serial Serial
  • PCI data collection cards for example, various serial devices (Serial) and PCI data collection cards.
  • the data item (Dataltem) is the logical unit of data exchange between the client 3000 and the standardized underlying control system 1000.
  • the data item (Dataltem) is an abstract data structure that is mainly used to save the state of various control units (I/O pins) of the hardware device 2000 in the drive system 1000, and can also be used to transfer data between objects. .
  • the various control units (I/O points) of the hardware device 2000 are mapped to Dataltem, and the drive system 1000 controls various actual hardware devices 2000 by controlling Dataltem.
  • the data information of the channel is exchanged between the client 200 and the drive system 1000 via the Epics communication protocol.
  • the EPICS communication protocol is a message-based communication protocol over TCP/IP sockets that is used in the context of the driver system 1000 to exchange channel data between the client 3000 and the server side (drive system 1000 side).
  • the EPICS protocol is responsible for establishing a reliable and efficient communication connection, in which data items (Dataltem) are used to exchange information between the communicating parties.
  • the drive system 1000 is a server side, and the client 3000 requests the drive system 1000 to operate a specific channel. Establishing a communication connection between the drive system 1000 and the client 3000 includes the following steps:
  • the drive system 1000 establishes a server-side socket connection on a computer-specific port
  • the drive system 1000 listens for a connection request from the client 3000 on the above port;
  • the client 3000 sets an environment variable such as a port number
  • the client 3000 generates a client socket connection and then attempts to connect to the drive system 1000;
  • the drive system 1000 receives the connection request and the communication is established.
  • the client 3000 can communicate with the drive system 1000, and the drive system 1000 receives and processes the operation request of the client 3000.
  • the drive system 1000 communicates with the client program using the EPICS communication protocol and is responsible for handling a large number of concurrent client 3000 device operation requests.
  • the main interaction between client 3000 and drive system 1000 is as follows:
  • the client 3000 When the client 3000 needs to read a value from a channel, the client 3000 sends a P_READ type EPICS message to the drive system 1000. After receiving the message, the drive system 1000 will call the Read method associated with the channel to query the device. The status value of the specific channel, if the query is successful, the drive system 1000 returns the value of the corresponding channel to the client 3000; if it fails, an error message is returned.
  • the drive system 1000 will notify the client 3000 when the value of the channel changes.
  • the drive system 1000 periodically polls the device to detect if the channel value has changed.
  • the client 3000 When the client 3000 needs to write a value to a channel, the client 3000 sends a P_WRITE type EPICS message to the drive system 1000. After the drive system 1000 receives the message, it will call the channel. The off Write method sets the state of the device channel to the specified value.
  • the central control module 100 will be described below with reference to Figs.
  • the central control module 100 is the core of the entire drive system 1000 and is responsible for the initialization and scheduling of the entire drive system 1000.
  • the central control module 1000 When the drive system 1000 is started, the central control module 1000 first initializes the relevant objects, creates server-side sockets, and waits for the client to connect.
  • actions such as reading and writing of the channel, round robin, timing test of the hardware device, and the like are all encapsulated into tasks, which are scheduled by the central control module 100.
  • the central control module 100 includes an initialization unit 110, a test unit 120, and a scheduling unit 130.
  • the initialization unit 110 is configured to initialize the EPICS protocol communication module 200, the configuration module 300, the data module 400, and the device driver module 500, and create a TCP/IP socket of the EPICS protocol communication module 200;
  • the testing unit 120 is configured to The state of the hardware device 2000 is periodically tested to update the parameters of the channel associated with the hardware device 2000.
  • the test unit 120 tests the state of the hardware device 2000 at a predetermined test frequency;
  • the scheduling unit 130 is configured to perform various tasks in the drive system 1000. Scheduling to control individual tasks to execute independently.
  • the initialization unit 110 initializes related objects, including initializing the EPICS protocol communication module 200, the configuration module 300, the data module 400, and the device driver module 500, creating a server-side socket, waiting for the client. 3000 connection.
  • the network connection is maintained and managed by the EPICS protocol communication module 200.
  • the EPICS protocol communication module 200 manages the network connection, and creates a corresponding task according to the network status and the received data packet. Capture the corresponding action.
  • the central control module 100 receives the P_SHUTDOWN message from the client 3000, it exits the loop.
  • the message is processed as described below.
  • the state machine of the EPICS communication protocol module 200 listens to the network. After receiving the Epics packet, the EpicsReader triggers the GotPacketDelegate event of the EpicsReaderEventAdapter in the method ProcessEpicsPacketO, and processes the Epics packets in the handler of the GotPacketDelegate.
  • the EpicsReaderEventAdapter is a Fa ⁇ ade provided by EpicsReader to the registration and processing of GotPacketDelegate events.
  • the GotPacketDelegate event is processed in the central control module 100.
  • processing the GotPacketDelegate event includes the following steps:
  • Test unit 120 can allocate a separate timer thread to check the status of hardware device 2000 in a round-robin manner. In particular, the state of the hardware device 2000 needs to be tested periodically to update the value of the channel associated with the hardware device 2000 in time. For each channel, test unit 120 can allocate a separate timer thread to periodically generate a read task for the channel to read values from hardware device 2000 and set the current state of the channel associated with hardware device 2000. In one embodiment of the invention, the test frequency of hardware device 2000 is paid from the configuration file.
  • the scheduling unit 130 is the core of the entire central control module 100.
  • the driving system 1000 encapsulates the processing of the Epics data packet, the testing of the hardware device, and the reading and writing of the channel into tasks, and is scheduled by the scheduling unit 130. In this way, the execution of each task can be made relatively independent, facilitating the execution of long-term tasks, and improving the concurrency and throughput of the system.
  • the abstract parent class Task for all tasks is defined as follows:
  • Protected bool active true; ⁇ task is active ⁇ , executable
  • Public abstract void Execute (ManagedThreadPo ol tp); ⁇ is mainly used to return the task object to the system object pool after the task execution is completed.
  • Figure 5 shows the inheritance relationship of various tasks in the system. Commonly used are ReadForEpicsTask, WriteForEpicsTask, ReadTask and other tasks.
  • the core of the drive system 1000 is the task scheduling and control system.
  • the core framework is shown in Figure 6.
  • the scheduling unit 130 places each task into a task priority queue, and processes each task in parallel through a plurality of worker threads in the thread pool according to the priority.
  • tasks such as ReadTask, ReadForEpicsTask, and WriteForEpicsTask.
  • priority queues 0 and 3 are used by the drive system 1000 itself, queue 1 is used for read-only channel-related tasks, and queue 2 is used for write-only and read-write channel-related tasks. use.
  • the priority of a task is only related to the priority of the channel associated with that task.
  • ReadTask In the drive system 1000 of the embodiment of the present invention, the following three tasks are actually used: ReadTask, ReadForEpicsTask, and WriteForEpicsTask.
  • ReadTask It is mainly used to assign a ReadTask to each channel timing to read the channel value when timing the channel related hardware devices.
  • ReadForEpicsTask When the drive system 1000 (server side) receives a P_READ message, it will assign a ReadForEpicsTask task to read the channel value and then return the corresponding channel value to the client 3000.
  • the client 3000 continuously requests the service of the drive system 1000 (server side), and the server side creates a task object, executes a task, and then destroys the task object according to the request.
  • the concept of an object pool (ObjectPool) is used in the scheduling unit 130.
  • Different task objects have different structural members, so each task factory maintains a separate object pool, which can solve the negative impact of the creation and destruction of a large number of task objects on the performance of the system.
  • the object pool draws a data structure of a single-chain phenotype.
  • Two pointers to the PoolableObject object point to the header and footer of the linked list, respectively.
  • poolHead and poolTail point to the last task object in the linked list, but the header object pointed to by poolHead only serves as a flag, and the header does not store the available task objects.
  • Access to the linked list is mutually exclusive.
  • Each task is created and assigned in the engineering mode at the scheduling unit 130.
  • the inheritance relationship of the task factory class is as shown in FIG.
  • scheduling unit 130 encapsulates threads into IOCPHandle objects for ease of management and scheduling of threads.
  • ManagedlOCP implements the core of the port completion model.
  • ManagedlOCP is responsible for creating and registering thread objects (IOCPHandle), placing new task objects into appropriate priority queues, and taking the next appropriate task object for system based on the priority of the task object. Scheduling.
  • the ManagedThreadPool class refers to the Facade mode, which is used by the scheduling system.
  • the ManagedThreadPool class initializes the ManagedlOCP object, creates a pool of thread objects by definition, registers the thread object with the ManagedOCP object, and also places the new task object in the priority queue of ManangedlOCP.
  • the EPICS protocol communication module 200 will be described below with reference to Figs. 8 through 14.
  • the EPICS protocol communication module 200 establishes a communication connection with the client 3000 through the TCP/IP socket established by the central control module 100, and communicates with the client 3000 by using the EPICS protocol, and receives the device operation request from the client 3000 and Client 3000 exchanges channel data.
  • the EPICS communication protocol is a communication protocol based on TCP/IP sockets.
  • the processing of the EPICS protocol mainly includes the management of EPICS communication and the processing of EPICS packets to provide a reliable communication connection.
  • the EPICS protocol communication module 200 provides a use interface through the class EpicsAdapter.
  • EpicsAdapter Use the Singleton mode. There is only one EpicsAdapter instance in the drive system 1000 that manages the Epics connection of the system.
  • the design of the EpicsAdapter class refers to the Facade pattern.
  • the EpicsAdapter class is defined as follows:
  • IsServer When IsServer is true, it initializes a server, otherwise it initializes a client.
  • the central control module 100 uses the Init method of the EpicsAdapter to initialize the Epics connection.
  • the parameter of the Init method is True
  • the drive system 1000 is initialized to the server side, otherwise the drive system 1000 is initialized to the client.
  • the EPICS protocol communication module 200 listens for a connection request from the client 3000, and upon receiving a connection request from the client 3000, establishes a communication connection with the client 3000.
  • the EPICS protocol communication module 200 listens to the network after initialization. After the connection is established, multiple state machines of the Epics module are executed in separate threads, and multiple state machines interact to maintain the connection state and process Epics communication. As shown in Figure 8, the EpicsReader class is directly related to Epics packet processing. When the communication end receives the Epics packet, it will call EpicsReader's ProcessEpicsPacket method, in which it processes the received Epics packet and triggers the corresponding The GotPacketDelegate type of event (Event).
  • Event The GotPacketDelegate type of event
  • FIG. 9 shows the creation process of various objects in the EPICS protocol communication module 200. among them,
  • EpicsManager Encapsulates the EpicsConnection once and provides an operation interface to the outside;
  • EpicsStateMachine responsible for managing the state of the connection
  • EpicsPoller mainly responsible for processing P_POLL data packets
  • EpicsReader responsible for receiving and processing data packets of the EPICS communication terminal
  • EpicsMonitor periodically sends a packet to the communicating party to detect the current connection status
  • EpicsPacketFactory The creation factory for Epics packets.
  • P_INIT client 3000 requests the server (drive system 1000) to establish an EPICS communication connection
  • P_READ client 3000 requests the server (drive system 1000) to return the value of an EPICS channel
  • P_WRITE client 3000 requests the server (drive system 1000) to set a Setpoint of the EPICS channel
  • P_POLL Client 3000 requests the server (drive system 1000) to query the value of an EPICS channel; when the Control 10 driver receives this message, it returns the value of this channel, and when the value of the channel changes, it will send to the client.
  • a P_REFRESH message informs that the value of the requested EPICS channel has changed.
  • P_UNPOLL The client 3000 requests the server (drive system 1000) to cancel the POLL-EPICS channel;
  • P_REFRESH When the client 3000 requests the server (drive system 1000) to return an EPICS channel; and when the data entry value changes, the server sends a P_REFRESH message to the client 3000.
  • P_SHUTDOWN The client 3000 requests the server (drive system 1000) to close the established EPICS communication connection.
  • Table 1 shows the EPICS packet structure in which the drive system 1000 interacts with the client 3000.
  • the standard EPICS packet is a 32-byte array. If the channel attribute value can be stored in the 8-byte VALUE field (such as discrete-integer, continuous double-precision floating-point type), the EPICS packet has no EXTRA field, and the first field LEN of the packet is 0; If the channel attribute value cannot be stored in the 8-byte VALUE field (such as string type), the channel attribute value is stored in the EXTRA field, and the field length is specified by the first field LEN of the packet, at this time, the EPICS packet The length is greater than 32 bytes.
  • the 8-byte VALUE field such as discrete-integer, continuous double-precision floating-point type
  • LEN EXTRA field length. If 0, the packet length is 32 bytes of standard; if it is not 0, the packet length is 32+LEN bytes.
  • DTYPE Channel data type. Among them, channel data types include:
  • CONTINUOUS ( 1 ) continuous type
  • ASCII (2) string type
  • VARIANT (4) Universal type.
  • OPCODE Opcode.
  • the operation code includes:
  • E_EVENT (-6) error event
  • E_REFRESH ( -4 ) Error update
  • P_READ ( 0) read request
  • P-WRITE ( 1 ) write request
  • P_POLL (2) poll request
  • P-UNPOIX (3) unpoll request
  • P_REFRESH (6) channel attribute value update
  • P_GETIDBYNAME ( 8 ) : Get the id request by name
  • P_HEARTBEAT ( 27 ) peer surviving
  • P_EVENT (28) Event.
  • the minimum service set supported by the EPICS server corresponds to: READ, WRITE, POLL, UNPOLL, INIT, SHUTDOWN, REFRESH, and E_REFRESH.
  • NUMl Board Number (Node Number, node number);
  • NUM2 Channel Number (channel number);
  • CHID Channel ID (channel ID);
  • CHATTR Channel Attribute, including:
  • NAME ( 0 ) name
  • DT_VALUE (2) Discrete channel value
  • DT_SETPOINT ( 3 ) : Discrete channel set point
  • CT_V ALUE (4) continuous channel value
  • CT_SETPOINT ( 5 ) continuous channel set point
  • ST_SETPOINT (6) string type channel set point
  • ST_VALUE (19) string type channel value
  • PEERID Peer Entity ID (EPICS Packet Receiver ID).
  • REQUESTOR Request ID (corresponding to an EPICS request).
  • VALUE Used to store channel attribute values (non-string types, which can be stored in 8-byte fields).
  • EXTRA Stores string type channel attribute values.
  • the EPICS protocol communication module 200 includes four state machines, each of which operates in a separate thread.
  • the four state machines include the connection state machine (EpicsStateMachine), the read data state machine (EpicsReader), the feedback state machine (EpicsPoller), and the monitoring state machine (EpicsMonitor).
  • the connection state machine is used to maintain the state of the connection between the EPICS protocol communication module 200 and the client 3000, and the state is an enumeration value ConnectionStates; the read data state machine is used to read and process the client 3000 and the standardized underlying control.
  • the channel data transmitted between the driving systems 1000 in communication is in the enumerated value ReaderStates; when the client 3000 queries the standardized underlying control driving system 1000 for the channel value of the Epits channel, the feedback state machine returns the requested Epics to the client 3000.
  • the channel value of the channel and when the channel value of the Epics channel changes, send a P_REFRESH message to the client 3000 to notify that the channel value of the Epits channel has changed, the state is the enumeration value Pollers tates; the monitoring state machine is used for timing
  • the client 3000 sends a data packet to detect the connection status between the EPICS protocol communication module 200 and the client 3000, and the state is the enumeration value Monitors tates.
  • the connection state machine, the reading state machine, the feedback state machine, and the monitoring state machine all operate in separate threads.
  • Figure 10 shows the state transition process of the connection state machine (EpicsStateMachine), where the connection state machine is responsible for maintaining the state of the connection.
  • connection state machine EpicsStateMachine
  • FIG 11 shows the state transition process of the read data state machine (EpicsReader), where the read data state machine is responsible for receiving and processing the data packets of the EPICS communication terminal.
  • the EpicsReader is in the STANDBY state. In this state, EpicsReader keeps executing the DoRead() method.
  • EpicsReader calls the EpicsConnection method to read the packet from the Epics network connection and then calls ProcessEpicsPacket() to process the read packet.
  • ProcessEpicsPacket() method for the purpose of encapsulation, the P_SHUTDOWN type message needs to be processed first, and then the GotPacketDelegate event is triggered.
  • Figure 12 shows the state transition process of the feedback state machine (EpicsPoller), where the feedback state machine is responsible for the reception and processing of data packets at the EPICS communication end.
  • the feedback state machine is responsible for the reception and processing of data packets at the EPICS communication end.
  • FIG 13 shows the state transition process of the monitoring state machine (EpicsMonitor), where the monitoring state machine periodically sends a packet to the communicating party to detect the current connection condition.
  • the EpicsMonitor After the client 3000 and the drive system 1000 successfully establish a connection, the EpicsMonitor will be in the STANDBY state. In this state, the EpicsMonitor periodically sends a HeartBeat packet to the communicating party to detect the network status. When the network is disconnected, the monitoring state machine sends a HeartBeat packet to trigger an exception, and the system detects that the network connection between the EPICS protocol communication module 120 and the client 3000 has been disconnected.
  • Figure 14 shows a collaborative working diagram of the various state machines of the EPICS protocol communication module 120.
  • the configuration module 300 is responsible for the processing of the variable parameters in the drive system 1000. Specifically, the configuration module 300 is used by The parameters that are frequently changed in the drive system 1000 are placed in the change parameter profile. In one embodiment of the invention, the change parameter configuration file is saved in an XML file format.
  • the configuration module 300 is mainly configured with the following two types of parameters:
  • Descriptor List Saves a list of the various descriptors in the driver system 1000, as well as the entries contained in each list.
  • An example of a descriptor list is as follows:
  • Node Configure the node.
  • the main parameter of the node is the node number.
  • the channels below each node are divided into three categories, and the other 1 J are ContinuousChannels, DiscreteChannels, and StringChannels. In jt ⁇ three categories
  • Channel holds key information for each Channel object.
  • the channels are divided into three types of ContinuousChannels, DiscreteChannels, and StringChannels, each with different key information.
  • the discrete channel includes the channel ID, channel number, channel name, descriptor list name, minimum value, maximum value, priority, and read and write type. Examples of discrete channels are as follows:
  • Continuous channels include channel ID, channel number, channel name, unit, minimum, maximum, accuracy, priority, read and write type.
  • An example of a continuous channel is as follows:
  • the string channel includes the channel ID, channel number, channel name, maximum length, priority, and read and write type.
  • An example of a string channel is as follows: ⁇ channel>
  • PollingFrequency the time interval between the server (drive system 1000) and the upper layer (client 3000) timing feedback channel value when the channel is rotated;
  • deviceTestFrequency server (drive system 1000) timing test hardware device 2000 test interval;
  • IP IP address of the server (driver system 1000);
  • Port The server side (drive system 1000 side) listens to the port connected to the network;
  • MaxThreads The maximum number of threads present in the drive system 1000.
  • ConcurrentThreads The number of threads in the drive system 1000 that can be executed in parallel.
  • configuration module 300 can further generate a key class ConfigProvider for parsing the change parameter configuration file.
  • the key class ConfigProvider is responsible for parsing the change parameter configuration file, obtaining the configuration parameters such as the channel, and saving to
  • the key is to use the following methods or properties of the class XmlNode: SelectSingleNode(string path): Get the first node object that satisfies the path path.
  • SelectNodes(string path) Gets a list of all node objects that satisfy the path path.
  • InnerText property the text content of the node, such as for a node
  • Attributes attribute The attribute set of the node
  • the data module 400 is used to store channel data from the EPICS protocol communication module 200.
  • the data module 400 can store abstractions of some data structures commonly used in the drive system 1000, including data items Dataltem, channels. Channel, etc.
  • Data structure is the foundation of a complete system.
  • the design of data structure and data object is directly related to the overall operating efficiency of the system and the realization of control algorithms. In the design process of data structure and data object, it is necessary to use object-oriented related technology to reduce the coupling between objects and provide data organization efficiency.
  • Channel Type Identifies whether a channel is continuous, discrete, or string.
  • Channel read/write type Identifies whether a channel is read-only, write-only, or read-write.
  • Channel abstract class The parent class of all specific channel classes (discrete channel, continuous channel, string channel), common operations for encapsulating channels.
  • the channels can be divided into: continuous type, discrete type and string type.
  • the channel read and write type the channel can be divided into: read-only, write-only and read-write. Combining these two classifications, the channels are divided into the following six types: continuous read-only channel, continuous write-only channel, continuous read-write channel, discrete read-only channel, discrete write-only channel, discrete read-write channel, character Serial read-only channel, string-type write-only channel, string-type read-write channel.
  • the channel class Channel there are only three subclasses of the channel class Channel: a continuous channel ContinuousChannel, a discrete channel DiscreteChannel, and a string channel StringChannel. All three types contain a member of the ReadWriteTypes type to indicate that the object is read-only, write-only, or read-write.
  • Figure 15 is an inheritance class diagram of the channel class.
  • the channel object is a primary package of the underlying hardware I/O point.
  • Each channel corresponds to one hardware device at the bottom, that is, corresponds to one hardware control point.
  • the value of the channel is the value of the corresponding I/O point.
  • the hardware device 2000 acts as a member of the channel Channel.
  • the relationship between the channel and the hardware device 2000 is as shown in Fig. 16, wherein the channel can include a continuous channel, a discrete channel, and a string channel.
  • Figure 17 shows the function call relationship inside the AbstractDevice class, that is, the order of channel read and write operations.
  • a node is a collection of logically or physically related EPICS channels.
  • a node class consists of multiple nodes, where multiple nodes are a continuous channel set, a discrete channel set, or a string channel set. There must be at least one node per drive.
  • the server (drive system 1000) driver can arbitrarily specify a collection of EPICS channels as nodes.
  • the channel is added to both the channel factory and the set in the node to which the channel belongs, to facilitate the management of the channel.
  • Channel Factory Class Globally Unique Instance, Manage and Create Nodes and Channels: Use Singleton mode to ensure that there is only one factory instance on the entire Control IO side. This instance is responsible for driving the creation of all nodes and channels in system 1000, and has two Hashtables that hold all available nodes and channels in drive system 1000, respectively.
  • the device driving module 500 will be described below with reference to Figs. 18 to 21 .
  • the device driver module 500 and the hardware device 2000 communicate, process device operation requests, and provide device-related interfaces to the outside.
  • the common read and write operations of all types of devices provide a consistent interface. Therefore, it is necessary to package the existing drivers of different types of devices.
  • the device driver module 500 includes some device abstract classes, abstracting the actual hardware device 2000, and encapsulating the operation methods of the common hardware device 2000.
  • the device driver module 500 includes a mapping unit 510, a read/write unit 520, a timeout processing unit 530, and a device management unit 540.
  • Mapping unit 510 is used to map the read/write interface of the channel and hardware device 2000 to read/write hardware device 2000.
  • mapping unit 510 encapsulates the abstraction of actual hardware device 2000, completing a 10 point mapping of the channel and the actual hardware.
  • the read/write unit 520 is configured to read channel data stored by the data module 400, change parameters of the configuration module 300, and data of the hardware device 2000, and write data to the hardware device 2000.
  • the AbstractDevice class is the parent class of all actual devices. It provides an abstract interface to device operations inside AbstractDevice, and handles device operation timeouts.
  • the timeout processing unit 530 is configured to handle read timeouts for the hardware device 2000.
  • Figure 16 shows the flow of device read operation timeout processing.
  • the timeout for device read operations including two cases:
  • Execution S1901 The timeout processing unit 530 determines whether the read/write lock is obtained within the predetermined time. If the read/write lock is not obtained within the predetermined time, S1902 is performed; otherwise, S1905 is executed.
  • S1904 Release the read-write lock. 2
  • the read operation of the hardware device 2000 may take a long time, and a timeout occurs.
  • the actual reading and writing of the hardware device 2000 is performed in a new thread through an asynchronous delegation mechanism, and a WaitHandle handle waiting for the asynchronous delegate to be completed can be obtained, and the WaitOne() method of the handle is used to process the device operation timeout.
  • S1906 Get the WaitHandle handle waiting for the completion of the asynchronous delegate to determine whether it times out. If yes, execute S1907 and throw a timeout exception. Otherwise, execute S1908 to read the data of the hardware device 2000.
  • the InternalWriteDevice function handles the high-level Read and Write functions that encapsulate the underlying functions and handle exceptions such as timeouts for objects such as channels.
  • a subclass of AbstractDevice that is, a wrapper class for various actual hardware devices 2000, must override the InternalReadDevice method and the InternalWriteDevice method to handle the read and write of various specific devices.
  • the function call relationship inside the AbstractDevice class is shown in Figure 17.
  • the device management unit 540 is used to create and maintain the hardware device 2000.
  • the drive system 1000 includes a device factory class DeviceFactory that completes the creation and maintenance of all hardware devices in the drive system 1000.
  • Figure 20 shows the UML description of the DeviceFactory (Singleton mode).
  • the device factory class of the device management unit 540 can create the following four types of analog devices:
  • RandomSimulatedDevice Returns a random positive number for each read operation of the stochastic analog device
  • StaticContinuousDevice The hardware device in the continuous device stores a double-precision floating-point value and reads/writes the double-precision floating-point value;
  • StaticDiscreteDevice A hardware device in the discrete device holds an integer (int type) value and reads/writes the integer value;
  • String device (StaticStringDevice): A hardware device in the string device holds a string type (string type) value and reads/writes the string type value.
  • the driving system 1000 of the embodiment of the present invention further includes an exception processing module 600, configured to take over the abnormality when the driving system 1000 throws an abnormality, and look up an exception processing vector table to obtain an abnormal processing function of the abnormality, according to the The exception handler processes the exception.
  • the exception handling module 600 mainly handles some of the more important exceptions associated with the underlying data structure and the Epics protocol. When an abnormality occurs in a certain portion of the drive system 1000, the exception processing module 600 takes over the abnormality and performs related processing on the abnormality.
  • a relatively independent exception handling class AlarmServer is included in the exception handling module 600.
  • the AlarmServer class uses the Singleton mode. Only one instance of AlarmServer is allowed in the drive system 1000, so that All exceptions in the system are processed centrally.
  • the AlarmServer maintains an exception handling vector table.
  • the exception handling vector table holds each of the predefined exception classes, as well as the exception handler for each exception type.
  • the exception handling vector table is similar to the underlying interrupt vector table of the PC, and stores various types of exceptions that can be handled, as well as exception handling functions for each type of exception.
  • the AlarmServer When the AlarmServer receives an Alarm, it will query the exception handling vector table and find the corresponding processing function. The type of the processing class of the exception is obtained by looking up the exception processing vector table, and then the exception is processed, and related operations such as logging are performed.
  • the abnormal log processing includes calling the log module 700 to perform corresponding abnormal record. The log module 700 will be described in detail below.
  • the drive system 1000 throws anomalies in two main ways.
  • Figure 22 shows the processing flow for two types of anomalies.
  • AlarmServer For some of the more important exceptions related to the underlying data structure and the Epics communication protocol, AlarmServer can be used. AlarmServer looks up the exception handling vector table and finds the pre-specified exception handling class to handle the exception. In the exception handling class, you can focus on some specified processing, such as logging, sending messages to the communicating party, and so on.
  • the standardized underlying control drive system 1000 of the embodiment of the present invention further includes a log module 700 for recording information in the log system during operation of the drive system 1000.
  • the log module 700 has only one class, LoggingService. When the user needs to log, he only needs to call
  • the member function of the LoggingService is fine.
  • the design of the LoggingService class refers to the Adapter mode and the Bridge design mode.
  • the definition of LoggingService is as follows:
  • the log module 700 can provide a flexible and efficient log system to record the operation of the drive system 1000, so that when the drive system 1000 has a problem, the problem can be found in time, thereby greatly improving the maintainability of the drive system 1000, and also using the log. Module 700 performs debugging and maintenance of the program
  • Figure 23 shows the overall operating state machine model of the drive system 1000.
  • the drive system 1000 is first initialized, including creating custom channels, modifying read and write delegations of existing channels, reading configuration files, creating channels and nodes, and initializing EPICS protocol communication modules. After the initialization is complete, run the drive system 1000, including running the system framework, into the message loop. After processing is complete, drive system 1000 stops processing and performs cleanup tasks. After the cleanup is complete, restart the system and perform new processing tasks, and perform related cleanup tasks after processing is complete.
  • the overall startup and scheduling of the drive system 1000 employs a class Core.
  • the Core class is the interface for scheduling and use of the entire drive system 1000.
  • the following tasks are mainly performed:
  • the Core class also uses the Singleton mode. There is only one Core object in the drive system 1000.
  • the standardized underlying control driving system for integrated circuit manufacturing equipment is based on the Windows XP operating system and is implemented by Visual C#.
  • Standardized underlying control drive system enables process module controllers (PMCs), cluster controllers (CTCs), and transport module controllers (TMCs) in integrated circuit manufacturing equipment to communicate with external hardware devices, efficiently scheduling and processing individual control subsystems A large number of operational requests for various hardware devices of integrated circuit manufacturing equipment.
  • PMCs process module controllers
  • CTCs cluster controllers
  • TMCs transport module controllers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种标准化底层控制驱动系统 技术领域
本发明涉及计算机应用和集成电路装备技术领域， 特别涉及一种标准化底层控制 驱动系统。 背景技术
随着微电子技术、 信息技术、 网络技术等的飞速发展， 全球信息产业迅猛成长、 网络经济快速兴起、 知识经济初见端倪， 现代国防和未来战争中的尖端技术不断崛起， 人类进入了信息和网络时代。 由于^：电子技术的核心地位， ^：电子比以往任何时候都 更显示出其重要的战略地位， 微电子产业已经成为全球经济的重要支柱和经济、 社会 发展的强大推动力。
驱动控制系统作为 IC ( Integrated Circuit, 集成电路） 产业的一部分， 具有举足轻 重的作用。 但是现有的集成电路的驱动控制系统通用性差， 不能够满足集成电路制造 装备工艺模块控制器 （ PMC ) 和传输模块控制器 （ TMC ) 与常见的外部硬件设备的通 信， 也从而导致对集成电路制造设备的各种硬件设备的操作和处理效率低。 发明内容
本发明的目的旨在至少解决上述技术缺陷之一， 特别提出一种高效、 通用的用于 集成电路制造设备的标准化底层控制驱动系统。
为达到上述目的， 本发明第一方面的实施例提出一种标准化底层控制驱动系统， 所述标准化底层控制驱动系统用于接收来自客户端的设备操作请求， 并根据所述设备 操作请求控制硬件设备的动作， 所述标准化底层控制驱动系统包括： 中央控制模块， 所述中央控制模块对所述标准化底层控制驱动系统进行初始化并创建所述标准化底层 控制驱动系统的 TCP / IP 套接字以与客户端进行通信； EPICS 协议通信模块， 所述 EPICS协议通信模块通过所述 TCP / IP套接字建立与所述客户端的通信连接， 并釆用 EPICS 协议与所述客户端进行通信以接收来自所述客户端的设备操作请求及与所述客 户端交换通道数据； 配置模块， 所述配置模块用于生成变化参数配置文件以配置所述 标准化底层控制驱动系统中的变化参数； 数据模块， 所述数据模块用于存储所述来自 所述 EPICS协议通信模块的通道数据； 和设备驱动模块， 所述设备驱动模块处理所述 设备操作请求， 并根据所述数据模块存储的通道数据以及所述配置模块配置的变化参 数控制所述硬件设备。
在本发明的一个实施例中， 所述中央控制模块包括： 初始化单元， 所述初始化单 元用于对所述 EPICS协议通信模块、 所述配置模块、 所述数据模块和所述设备驱动模 块进行初始化， 并创建所述 EPICS协议通信模块的 TCP / IP套接字； 测试单元， 所述 测试单元用于定时测试所述硬件设备的状态以更新与所述硬件设备相关的通道的参数 调度单元， 所述调度单元用于对所述标准化底层控制驱动系统中的各个任务进行调度 以控制所述各个任务独立执行。
在本发明的一个实施例中， 所述调度单元将所述各个任务放入任务优先级队列， 并根据所述各个任务对应的通道的优先级通过线程池中的多个工作线程， 并行执行属 于同一优先级的多个任务。
在本发明的一个实施例中， 所述变化参数配置文件以 XML文件格式保存。
在本发明的一个实施例中， 所述变化参数配置文件中的变化参数包括：
所述 EPICS协议通信模块和所述客户端之间的各个通道的配置参数、 所述标准化 底层控制驱动系统向所述客户端定时反馈通道值的时间间隔、 所述标准化底层控制驱 动系统定时测试所述硬件设备的测试时间间隔、 所述标准化底层控制驱动系统端的 IP 地址、 所述标准化底层控制驱动系统监听网络连接的端口、 所述标准化底层控制驱动 系统中存在的线程的最大数量和所述标准化底层控制驱动系统中并行执行的线程数 量。
在本发明的一个实施例中， 所述配置模块进一步生成用于解析所述变化参数配置 文件的关键类。
在本发明的一个实施例中， 在所述中央处理模块初始化所述标准化底层控制驱动 系统后， 所述 EPICS协议通信模块监听来自所述客户端的连接请求， 在接收到来自所 述客户端的连接请求后， 建立与所述客户端的通信连接。
在本发明的一个实施例中， 所述 EPICS协议通信模块包括： 连接状态机， 所述连 接状态机用于维持所述 EPICS协议通信模块与所述客户端之间的连接的状态； 读数据 状态机， 所述读数据状态机用于读取并处理所述客户端与所述标准化底层控制驱动系 统之间在通信中传输的通道数据； 反馈状态机， 所述反馈状态机用于在所述客户端向 所述标准化底层控制驱动系统查询通道值时， 向所述客户端返回请求的所述通道值， 并在所述通道值变化时， 向所述客户端发送通道值变化通知； 监测状态机， 所述监测 状态机用于定时向所述客户端发送数据包以检测所述 EPICS协议通信模块和所述客户 端之间的连接状态，
在本发明的一个实施例中， 当所述监测状态机发送的数据包触发到异常时， 则检 测到所述 EPICS协议通信模块和所述客户端之间通信连接断开。
在本发明的一个实施例中， 所述数据模块存储的通道数据包括： 通道类型， 所述 通道类型包括连续型、 离散型、 字符串型； 通道读写类型， 所述通道读写类型包括只 读型、 只写型、 读写型； 通道类型的父类， 所述通道类型的父类用于封装所述的通道 的操作； 节点类， 所述节点类为逻辑上或物理上相关的 EPICS通道的集合， 包括多个 节点， 所述多个节点是连续型通道集合、 离散型通道集合或字符串型通道集合； 通道 工厂类， 所述通道工厂类用于管理和创建节点和通道。 在本发明的一个实施例中， 所述通道包括： 连续型只读通道、 连续型只写通道、 连续型读写通道、 离散型只读通道、 离散型只写通道、 离散型读写通道、 字符串型只 读通道、 字符串型只写通道和字符串型读写通道。
在本发明的一个实施例中， 每个通道对应于一个硬件设备。
在本发明的一个实施例中， 所述标准化底层控制驱动系统包括至少一个节点， 其 中所述标准化底层控制驱动系统任意指定作为所述节点的 EPICS通道集合。
在本发明的一个实施例中， 当创建一个通道时， 将所述通道同时添加到所述通道 工厂类和所述通道所属的节点的 EPICS通道集合中。
在本发明的一个实施例中， 所述设备驱动模块包括： 映射单元， 所述映射单元用 于对所述通道和所述硬件设备的读 /写接口进行映射以对所述硬件设备进行读 /写操作； 读写单元， 所述读写单元用于读取所述数据模块存储的通道数据、 所述配置模块配置 的变化参数以及所述硬件设备的数据， 并向所述硬件设备中写入数据； 超时处理单元， 所述超时处理单元用于处理对所述硬件设备的读操作超时； 和设备管理单元， 所述设 备管理单元用于创建和维护所述硬件设备。
在本发明的一个实施例中， 所述超时处理单元判断在预定时间内是否获得读写锁， 如果在所述预定时间内未获得所述读写锁， 则抛出超时异常， 如果在所述预定时间内 获得所述读写锁， 则通过异步委托机制在另一个线程里判断是否超时， 如果是则抛出 超时异常， 并释放所述读写锁， 如果否则读取所述硬件设备的数据， 并释放所述读写 锁。
在本发明的一个实施例中， 设备管理单元将所述硬件设备分为四类， 包括： 随机 模拟类设备， 所述随机模拟类设备中的硬件设备的每次读操作均分别返回一个随机的 正数； 连续型类设备， 所述连续型设备中的硬件设备保存一个双精度浮点型数值， 并 对所述双精度浮点型数值进行读 /写； 离散型设备， 所述离散型设备中的硬件设备保存 一个整型数值， 并对所述整型数值进行读 /写； 字符串型设备， 所述字符串型设备中的 硬件设备保存一个字符串型数值， 并对所述字符串型数值进行读 /写。
在本发明的一个实施例中， 进一步包括异常处理模块， 所述异常处理模块用于在 所述标准化底层控制驱动系统抛出异常时， 查找异常处理向量表以获得所述异常的异 常处理函数， 并根据所述异常处理函数对所述异常进行处理。
在本发明的一个实施例中， 所述异常处理向量表包括异常类型以及每种异常类型 对应的异常处理函数。
在本发明的一个实施例中， 进一步包括日志模块， 所述日志模块以日志的形式记 录所述标准化底层控制驱动系统运行过程中的信息。
本发明实施例提供的用于集成电路制造设备的标准化底层控制驱动系统基于 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 配置的变化参数控制硬件设备。 本发明实施例提供的标准 化底层控制驱动系统 1000可以用于对集成电路制造设备的控制。
图 2示出了本发明实施例提供的标准化底层控制驱动系统 1000与客户端 3000和 硬件设备 2000的交互过程。 在集成电路制造装备的控制系统中， 存在大量需要被控制 的硬件设备 2000 (例如串口设备和数据釆集卡）。 标准化底层控制驱动系统 1000和客 户端 300釆用图 2所示的 C/S型体系结构。 如图 2所示， 标准化底层驱动系统 1000相 当于数据服务器， 釆用 EPICS通信协议与客户端 3000进行通信。 标准化底层控制驱动 系统 1000与客户端 3000釆用 EPICS通信协议交换通道的数据项 （Dataltem ) 。 标准 化底层控制驱动系统 1000 负责监听网络， 处理各种大量的并发的客户端 3000的设备 操作请求， 根据客户端 300的请求控制硬件设备 2000, 例如各种串口设备（ Serial )和 PCI数据釆集卡。 釆用上述 C/S型体系结构， 可以弥合各种不同设备的不同操作方式， 由驱动系统 1000向外提供硬件设备 200的统一的控制接口。
数据项（ Dataltem )是客户端 3000与标准化底层控制系统 1000之间数据交换的逻 辑单位。 数据项 （Dataltem )是一种抽象的数据结构， 在驱动系统 1000中主要用来保 存硬件设备 2000的各种控制单元 （I/O 管脚） 的状态， 也可以用来在对象之间传递数 据。 硬件设备 2000的各种控制单元 （I/O points )被映射为 Dataltem, 驱动系统 1000 通过控制 Dataltem来控制各种实际的硬件设备 2000。 客户端 200和驱动系统 1000之 间通过 Epics通信协议来交换通道的数据信息。
EPICS通信协议为一个基于消息的位于 TCP/IP套接字之上的通信协议， 在驱动系 统 1000的上下文中用来在客户端 3000和服务器端（驱动系统 1000端）之间交换通道 数据。 EPICS协议负责建立一种可靠地、 高效的通信连接， 以数据项 （Dataltem )为单 位在通信双方之间进行信息交换。
驱动系统 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 相关的通道的参数， 换言之， 测试单元 120以预定的测试频率测试硬件设备 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数据包 以后,在方法 ProcessEpicsPacketO中触发 EpicsReaderEventAdapter的 GotPacketDelegate 事件， 在 GotPacketDelegate 的处理函数中处理这些 Epics 数据包。 其中 EpicsReaderEventAdapter 是 EpicsReader 向 夕卜提供的一个 Fa§ade , 用 于对 GotPacketDelegate事件的注册和处理。 在中央控制模块 100中对 GotPacketDelegate事 件进行处理。
如图 4所示， 对 GotPacketDelegate事件进行处理包括如下步骤：
S401 : 触发 GotPacketDelegate事件；
S402: 判断消息类型；
当消息类型为 P_READ类型时， 创建 ReadForEpicsTask型的任务；
当消息类型为 P_WRITE类型时， 创建 WriteForEpicsTask型的任务；
当消息类型为 P_POLL类型时， 注册 Poller;
当消息类型为 PJJNPOL类型时， 取消注册 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 (ManagedThreadPo ol 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对象。
ManagedlOCP实现了端口完成模型的核心， ManagedlOCP负责创建和注册线程对 象 (IOCPHandle) ,将新的任务对象放到合适的优先级队列中，并且根据任务对象的优先 级取出下一个合适的任务对象供系统调度。
ManagedThreadPool 类参考 Facade 模式， 是调度系统对外提供的使用接口。
ManagedThreadPool类初始化 ManagedlOCP对象， 根据定义创建一个线程对象池， 将 线程对象注册到 ManagedlOCP对象中， 同时也将新的任务对象放到 ManangedlOCP的 优先级队列中。
下面参考图 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类的定义如下：
public class EpicsAdapter private EpicsReaderEventAdapter
readerEventAdapter=EpicsReaderEventAdapter.getInstance();
private EpicsEventAdapter eventAdapter = EpicsEventAdapter.getInstance(); private EpicsManager epicsManager;
public ManualResetEvent manualEvent = new ManualResetEvent(f alse)； private int portNumber = 5001 ;
private string hostname = "127.0.0.1 ";
private static EpicsAdapter instance=new EpicsAdapter();
〃初始化连接，当 IsServer为 true时初始化的是一个服务器端，否则初始化的 是一个客户端
public void Init(bool IsServer); public void InitEpicsServer(); 〃初始化并且启动服务器端
public void InitEpicsClient(); 〃初始化并且启动客户端
public void DisConnect(); 〃断开连接
void NotifyOtherSideToShutDo wn()；〃通知通信的另一端关闭连接 public void Shutdown(); 〃关闭连接,清理资源
}
}
中央控制模块 100釆用 EpicsAdapter的 Init方法来初始化 Epics连接， 当 Init方法 的参数为 True时， 驱动系统 1000被初始化为服务器端， 否则驱动系统 1000被初始化 为客户端。
在中央处理模块 100初始化后， EPICS协议通信模块 200监听来自客户端 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 10驱动接收到这个消息后立即返回这个通道的值， 并且当该通道的值发生 变化时， 将向客户端发送一个 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
LEN DTYPE OPCODE NUM1 NUM2 CHID CHATT PEE ID
0 4 6 8 12 16 18 20
REQUESTOR VALUE EXTRA
22 24 32
如表 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—UNPOIX (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。
NUMl: 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_V ALUE (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; 读数据状态机用于读取并处理客户端 3000与标准化底层控制驱动系 统 1000之间在通信中传输的通道数据， 状态为枚举值 ReaderStates; 在客户端 3000向 标准化底层控制驱动系统 1000查询 Epics通道的通道值时， 反馈状态机向客户端 3000 返回请求的 Epics通道的通道值， 并在该 Epics通道的通道值变化时， 向客户端 3000 发送 P_REFRESH 消息来通知该 Epics 通道的通道值已经发生变化， 状态为枚举值 Pollers tates; 监测状态机用于定时向客户端 3000发送数据包以检测 EPICS协议通信模 块 200和客户端 3000之间的连接状态， 态为枚举值 Monitors tates。 连接状态机、 读数 据状态机、 反馈状态机和监测状态机均以单独的线程运行。
图 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 中各种描述符列表， 以及每种列表所包含的 条目。 描述符列表示例如下：
〃描述符列表， 名称为 "OpenStatus" ，该类描述符可以有两种取值： Open和 Close <Descriptors Name="OpenStatus">
<Descriptor>
<StringValue>Open</StringValue>
<IntValue> 1 </IntValue>
</Descriptor>
<Descriptor>
<StringValue>Close</StringValue>
<IntValue>2</IntValue>
</Descriptor>
</Descriptors>
1.2)节点： 对节点进行配置， 节点的主要参数是节点号， 每个节点下面的通道被分 为三类， 分另1 J为 ContinuousChannels、 DiscreteChannels、 和 StringChannels。 在 jt匕三类
Xml节点下的为具体的通道。 节点示例如下：
<node Node Numbers" 1 ">
<ContinuousChannels>
<channel>
...
</channel>
</ContinuousChannels>
<DiscreteChannels>
<channel>
...
</channel>
</D i s creteCh ann el s〉
<StringChannels>
<channel> </channel>
</StringChannels>
</node>
1.3 ) 通道： 通道保存有每个 Channel 对象的关键信息。 通道分为三类 ContinuousChannels、 DiscreteChannels、 和 StringChannels , 每类的关键信息都不同。
1.3.1)离散型通道 DiscreteChannel:
离散型通道包括通道的 ID、 通道号、 通道名、 描述符列表名、 最小值、 最大值、 优先级、 读写类型。 离散型通道示例如下：
<channel>
<ID>2003</ID>
<ChannelNumber>3</ChannelNumber>
<ChannelName>channel8</ChannelName>
<DescriptorsName>OpenStatus</DescriptorsName>
<Min>l</Min>
<Max>10</Max>
<Privilege>3</Privilege>
<Type>Write</Type>
</channel>
1.3.2)连续型通道 ContinuousChannel:
连续型通道包括通道的 ID、 通道号、 通道名、 单位、 最小值、 最大值、 精确度、 优先级、 读写类型。 连续型通道示例如下：
<channel>
<ID>2001</ID>
<ChannelNumber> 1 </ChannelNumber>
<ChannelName>channel6</ChannelName>
<Units>0.1</Units>
<Min>1.0</Min>
<Max>10.0</Max>
<Accuracy>0.1</Accuracy>
<Privilege>3</Privilege>
<Type>Write</Type>
</channel>
1.3.3)字符串型通道 StringChannel:
字符串型通道包括通道的 ID、 通道号、 通道名、 最大长度、 优先级、 读写类型。 字符串型通道示例如下： <channel>
<ID>2005</ID>
<ChannelNumber>5</ChannelNumber>
<ChannelName>channel 10</ChannelName>
<MaxLength>20</MaxLength>
<Privilege>3</Privilege>
<Type>Write</Type>
</channel>
b ) 其他可配置的易变参数包括：
l)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就是 "channellO"
Attributes属性： 该节点的属性集合，
如对于节点 Descriptors Name="OpenStatus"> , "Name"就是该节点的一个属性。 当驱动系统 1000需要上述参数时， 可以在运行时通过配置模块 3000获取这些参 数。 当驱动系统 1000中上述参数经常变化时， 可以直接修改变化参数配置文件， 而不 用重新编译整个驱动系统 1000 , 这样大大提供了驱动系统 1000的可移植性。
数据模块 400用于存储来自 EPICS协议通信模块 200的通道数据。 数据模块 400 可以存储驱动系统 1000 中常用的一些数据结构的抽象， 包括数据项 Dataltem、 通道 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通道集合。
public class DeviceNode 〃节点 private int nodeNum; 〃节点号 private int channellndex; 〃通道索引号， 用于创建通道
private Hashtable channels; 〃该节点的所有通道
}
每当创建一个新的通道时， 就会把通道同时添加到通道工厂和该通道所属的节点 中的集合里， 以方便对通道的管理可操作。
( 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的抽象， 完 成通道和实际硬件的 10 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 进行实际的读写是通过异步委托机制在一个新的线程
Beginlnvoke ( ) 里完成；
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的定义如下：
public static class LoggingService //创建日志记录对象
static readonly ILog log = LogManager.GetLogger(typeof(LoggingService));
〃使用配置文件初始化 log4net的日志模块
static LoggingService()
XmlConfigurator. Configure AndWatch(new
Filelnfo(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile));
〃参考 Adapter模式和 Bridge模式,把调用转加给 log4net的日志对象 public static void Debug(object message) log.Debug(message);
}
}
日志模块 700 可以提供一个灵活高效的日志系统来记录驱动系统 1000 的运行情 况， 以便当驱动系统 1000出现问题时可以及时发现问题所在， 从而大大提高驱动系统 1000的可维护性， 并且也可以使用日志模块 700进行程序的调试和维护
图 23示出了驱动系统 1000整体运行状态机模型。 如图中所示， 首先进行初始化 驱动系统 1000 , 包括创建自定义通道、 修改已有通道的读写委托、 读取配置文件、 创 建通道和节点、 初始化 EPICS协议通信模块等任务。 在初始化完成后， 运行驱动系统 1000 , 包括运行系统框架， 进入消息循环。 在处理完成后， 驱动系统 1000停止处理并 执行清理任务。 在清理完成后， 重新启动系统并执行新的处理任务， 在处理完成后进 行相关的清理任务。
在本发明的一个实施例中， 驱动系统 1000的整体启动和调度釆用类 Core。
Core类是整个驱动系统 1000调度和使用的接口。 在 Core类中， 主要执行下述任 务：
a)初始化各个任务对象的工厂， 以在处理 Epics数据包时创建相应的任务 b)初始化通道工厂， 以在需要的时候创建通道和节点
c)初始 4匕 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所述的标准化底层控制驱动系统， 其中， 所述中央控制模块包括： 初始化单元， 所述初始化单元用于对所述 EPICS协议通信模块、 所述配置模块、 所述数据模块和所述设备驱动模块进行初始化， 并创建所述 EPICS 协议通信模块的 TCP / IP套接字；
测试单元， 所述测试单元用于定时测试所述硬件设备的状态以更新与所述硬件设 备相关的通道的参数； 和
调度单元， 所述调度单元用于对所述标准化底层控制驱动系统中的各个任务进行 调度以控制所述各个任务独立执行。
3、 如权利要求 1所述的标准化底层控制驱动系统， 其中， 所述调度单元将所述各 个任务放入任务优先级队列， 并根据所述各个任务对应的通道的优先级通过线程池中 的多个工作线程， 并行执行属于同一优先级的多个任务。
4、 如权利要求 2所述的标准化底层控制驱动系统， 其中， 所述变化参数配置文件 以 XML文件格式保存。
5、 如权利要求 4所述的标准化底层控制驱动系统， 其中， 所述变化参数配置文件 中的变化参数包括：
所述 EPICS协议通信模块和所述客户端之间的各个通道的配置参数、 所述标准化 底层控制驱动系统向所述客户端定时反馈通道值的时间间隔、 所述标准化底层控制驱 动系统定时测试所述硬件设备的测试时间间隔、 所述标准化底层控制驱动系统的 IP地 址、 所述标准化底层控制驱动系统端监听网络连接的端口、 所述标准化底层控制驱动 系统中存在的线程的最大数量和所述标准化底层控制驱动系统中并行执行的线程数 量。
6、 如权利要求 1所述的标准化底层控制驱动系统， 其中， 所述配置模块进一步生 成用于解析所述变化参数配置文件的关键类。
7、 如权利要求 1所述的标准化底层控制驱动系统， 其中， 在所述中央处理模块初 始化所述标准化底层控制驱动系统后， 所述 EPICS协议通信模块监听来自所述客户端 的连接请求， 在接收到来自所述客户端的连接请求后， 建立与所述客户端的通信连接。
8、 如权利要求 7所述的标准化底层控制驱动系统， 其中， 所述 EPICS协议通信模 块包括：
连接状态机， 所述连接状态机用于维持所述 EPICS协议通信模块与所述客户端之 间的连接的状态；
读数据状态机， 所述读数据状态机用于读取并处理所述客户端与所述标准化底层 控制驱动系统之间在通信中传输的通道数据；
反馈状态机， 所述反馈状态机用于在所述客户端向所述标准化底层控制驱动系统 查询通道值时， 向所述客户端返回请求的所述通道值， 并在所述通道值变化时， 向所 述客户端发送通道值变化通知； 和
监测状态机，所述监测状态机用于定时向所述客户端发送数据包以检测所述 EPICS 协议通信模块和所述客户端之间的连接状态，
其中， 所述连接状态机、 读数据状态机、 反馈状态机和监测状态机均以单独的线 程运行。
9、 如权利要求 7所述的标准化底层控制驱动系统， 其中， 当所述监测状态机发送 的数据包触发到异常时， 则检测到所述 EPICS协议通信模块和所述客户端之间通信连 接断开。
10、 如权利要求 1 所述的标准化底层控制驱动系统， 其中， 所述数据模块存储的 通道数据包括：
通道类型， 所述通道类型包括连续型、 离散型、 字符串型；
通道读写类型， 所述通道读写类型包括只读型、 只写型、 读写型；
通道类型的父类， 所述通道类型的父类用于封装所述的通道的操作；
节点类， 所述节点类为逻辑上或物理上相关的 EPICS通道的集合， 包括多个节点， 所述多个节点是连续型通道集合、 离散型通道集合或字符串型通道集合； 和
通道工厂类， 所述通道工厂类用于管理和创建节点和通道。
11、 如权利要求 10所述的标准化底层控制驱动系统， 其中， 所述通道包括： 连续型只读通道、 连续型只写通道、 连续型读写通道、 离散型只读通道、 离散型 只写通道、 离散型读写通道、 字符串型只读通道、 字符串型只写通道和字符串型读写 通道。
12、 如权利要求 10所述的标准化底层控制驱动系统， 其中， 每个通道对应于一个 硬件设备。
13、 如权利要求 10所述的标准化底层控制驱动系统， 其中， 所述标准化底层控制 驱动系统包括至少一个节点， 其中所述标准化底层控制驱动系统任意指定作为所述节 点的 EPICS通道集合。
14、 如权利要求 13所述的标准化底层控制驱动系统， 其中， 当创建一个通道时， 将所述通道同时添加到所述通道工厂类和所述通道所属的节点的 EPICS通道集合中。
15、 如权利要求 1 所述的标准化底层控制驱动系统， 其中， 所述设备驱动模块包 括：
映射单元， 所述映射单元用于对所述通道和所述硬件设备的读 /写接口进行映射以 对所述硬件设备进行读 /写操作；
读写单元， 所述读写单元用于读取所述数据模块存储的通道数据、 所述配置模块 配置的变化参数以及所述硬件设备的数据， 并向所述硬件设备中写入数据；
超时处理单元， 所述超时处理单元用于处理对所述硬件设备的读操作超时； 和 设备管理单元， 所述设备管理单元用于创建和维护所述硬件设备。
16、 如权利要求 15所述的标准化底层控制驱动系统，
其中， 所述超时处理单元判断在预定时间内是否获得读写锁，
如果在所述预定时间内未获得所述读写锁， 则抛出超时异常，
如果在所述预定时间内获得所述读写锁， 则通过异步委托机制在另一个线程里 判断是否超时， 如果是则抛出超时异常并释放所述读写锁， 如果否则读取所述硬 件设备的数据并释放所述读写锁。
17、 如权利要求 15所述的标准化底层控制驱动系统， 其中， 所述设备管理单元将 所述硬件设备分为四类， 包括：
随机模拟类设备， 所述随机模拟类设备中的硬件设备的每次读操作均返回一个随 机的正数；
连续型类设备， 所述连续型设备中的硬件设备保存一个双精度浮点型数值， 并对 所述双精度浮点型数值进行读 /写；
离散型设备， 所述离散型设备中的硬件设备保存一个整型数值， 并对所述整型数 值进行读 /写；
字符串型设备， 所述字符串型设备中的硬件设备保存一个字符串型数值， 并对所 述字符串型数值进行读 /写。
18、 如权利要求 16所述的标准化底层控制驱动系统， 其中， 进一步包括异常处理 模块， 所述异常处理模块用于在所述标准化底层控制驱动系统抛出异常时， 查找异常 处理向量表以获得所述异常的异常处理函数， 并根据所述异常处理函数对所述异常进 行处理。
19、 如权利要求 18所述的标准化底层控制驱动系统， 其中， 所述异常处理向量表 包括异常类型以及每种异常类型对应的异常处理函数。
20、 如权利要求 1所述的标准化底层控制驱动系统， 其中， 进一步包括日志模块， 所述日志模块以日志的形式记录所述标准化底层控制驱动系统运行过程中的信息。
PCT/CN2011/081952 2011-05-10 2011-11-08 一种标准化底层控制驱动系统 Ceased WO2012151886A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2011101205819A CN102185860A (zh) 2011-05-10 2011-05-10 用于集成电路制造设备的标准化底层控制驱动系统
CN201110120581.9 2011-05-10

Publications (1)

Publication Number Publication Date
WO2012151886A1 true WO2012151886A1 (zh) 2012-11-15

Family

ID=44571930

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/081952 Ceased WO2012151886A1 (zh) 2011-05-10 2011-11-08 一种标准化底层控制驱动系统

Country Status (2)

Country Link
CN (1) CN102185860A (zh)
WO (1) WO2012151886A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121704398A (zh) * 2026-02-13 2026-03-20 中国科学院长春光学精密机械与物理研究所 基于动态配置的异构设备协同控制方法、系统及介质

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102185860A (zh) * 2011-05-10 2011-09-14 清华大学 用于集成电路制造设备的标准化底层控制驱动系统
CN102662362B (zh) * 2012-04-17 2014-01-08 清华大学 一种集成电路制造装备通用控制系统
CN103176417B (zh) * 2013-02-04 2016-02-24 华中科技大学 一种兼容epics的可编程自动化控制方法及装置
CN105099896A (zh) * 2015-09-18 2015-11-25 上海上讯信息技术股份有限公司 邮件传输方法及用于邮件传输的设备
CN105677464A (zh) * 2015-12-31 2016-06-15 江苏小牛电动科技有限公司 一种基于电动车中控系统的任务调度系统和方法
US10791195B2 (en) * 2016-06-27 2020-09-29 Miaobo Chen Common device interface framework for IoT/smart device application
EP3432236A1 (en) * 2017-07-18 2019-01-23 Siemens Aktiengesellschaft Method and system for automatic maintenance of a machine
CN108196993A (zh) * 2017-12-28 2018-06-22 努比亚技术有限公司 Usb接口测试方法、终端及计算机可读存储介质
CN111897732B (zh) * 2020-08-04 2021-11-12 北京师范大学 一种嵌入式疲劳检测平台及疲劳检测方法
CN113765935B (zh) * 2021-09-17 2023-09-12 展讯通信（深圳）有限公司 通信方法及装置、可读存储介质、应用处理器、终端
CN114185315B (zh) * 2021-11-23 2026-02-10 芯庆科技(上海)有限责任公司 一种自动化设备信号检测和控制的自动生成方法
CN115174442B (zh) * 2022-06-24 2024-04-05 硕橙（厦门）科技有限公司 一种多模态进程数据传输方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101848152A (zh) * 2010-05-07 2010-09-29 华为终端有限公司 终端设备控制用户设备的通信方法、设备及系统
CN101895544A (zh) * 2010-07-15 2010-11-24 深圳市普联技术有限公司 通信设备的多用户控制方法、多用户控制系统和服务器
US20110004790A1 (en) * 2007-12-21 2011-01-06 Albert Rossmann Asynchrony Debugging Using Web Services Interface
CN102185860A (zh) * 2011-05-10 2011-09-14 清华大学 用于集成电路制造设备的标准化底层控制驱动系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100531197C (zh) * 2004-11-30 2009-08-19 广东省电信有限公司科学技术研究院 用于移动通信服务开通的网络配置接口的实现方法
CN101110865B (zh) * 2006-07-19 2011-05-11 中兴通讯股份有限公司 一种实现多通道语音调度的系统和方法
CN101114984A (zh) * 2006-07-27 2008-01-30 中兴通讯股份有限公司 一种多线程网络负载控制方法
CN101562622B (zh) * 2009-06-05 2012-09-26 杭州华三通信技术有限公司 一种执行用户请求的方法及其对应的服务器
CN101727352A (zh) * 2009-12-15 2010-06-09 四川长虹电器股份有限公司 一种定时器的实现方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110004790A1 (en) * 2007-12-21 2011-01-06 Albert Rossmann Asynchrony Debugging Using Web Services Interface
CN101848152A (zh) * 2010-05-07 2010-09-29 华为终端有限公司 终端设备控制用户设备的通信方法、设备及系统
CN101895544A (zh) * 2010-07-15 2010-11-24 深圳市普联技术有限公司 通信设备的多用户控制方法、多用户控制系统和服务器
CN102185860A (zh) * 2011-05-10 2011-09-14 清华大学 用于集成电路制造设备的标准化底层控制驱动系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SHEN GUOBAO ET AL.: "PC/104 based EPICS Device Controller.", NUCLEAR ELECTRONICS & DETECTION TECHNOLOGY., vol. 23, no. IS.2, March 2003 (2003-03-01), pages 151 - 154 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121704398A (zh) * 2026-02-13 2026-03-20 中国科学院长春光学精密机械与物理研究所 基于动态配置的异构设备协同控制方法、系统及介质

Also Published As

Publication number Publication date
CN102185860A (zh) 2011-09-14

Similar Documents

Publication Publication Date Title
WO2012151886A1 (zh) 一种标准化底层控制驱动系统
US8751644B2 (en) Modular monitor service for smart item monitoring
US8296413B2 (en) Device registration in a hierarchical monitor service
CN101207550B (zh) 负载均衡系统及多种业务实现负载均衡的方法
KR100253930B1 (ko) 고성능 사용자 레벨 네트워크 프로토콜 서버 시스템에 대한 동적 실행 유닛 관리
Grimm et al. Programming for pervasive computing environments
CN110716748A (zh) 业务处理方法、装置、计算机可读介质及电子设备
US6601195B1 (en) Switch adapter testing
US20050038808A1 (en) System and method for utilizing a modular operating system (OS) resident agent allowing an out-of-band server management
US20120042327A1 (en) Method and System for Event-Based Remote Procedure Call Implementation in a Distributed Computing System
IL135269A (en) Testing of many computer networks - focal points by injecting errors
CN101719852B (zh) 一种中间件性能的监控方法和设备
IL135270A (en) On-line switch diagnostics
CN113259404B (zh) 基于tcp/ip协议的工业通信中间件及其使用方法
Welling et al. An architecture for exporting environment awareness to mobile computing applications
CN112230987A (zh) 一种分布式模块化插件框架实现系统及方法
CN110209383A (zh) 面向泛制造与边缘计算的泛在对象交互接口方法
CN110119269B (zh) 控制任务对象的方法、装置、服务器及存储介质
CN119629015A (zh) 一种物理交换机信息的获取方法、计算设备及物理交换机
Migliardi et al. Heterogeneous distributed virtual machines in the Harness metacomputing framework
Brugali et al. Service component architectures in robotics: The sca-orocos integration
WO2000060455A2 (en) Systems, methods and computer program products for event and action management in data processing systems using event handler intermediaries
Shi CoAP infrastructure for IoT
CN113965561B (zh) 一种基于异步事件驱动的机载文件传输系统
e Silva et al. A pattern language for adaptive distributed systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11865097

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC OF 080414

122 Ep: pct application non-entry in european phase

Ref document number: 11865097

Country of ref document: EP

Kind code of ref document: A1