CN102169436B - General control kernel system used for integrated circuit manufacturing equipment - Google Patents

Abstract

The invention discloses a general control kernel system for integrated circuit manufacturing equipment, comprising: a configuration module, used for instantiating objects and registering the instantiated objects into the name space when the kernel system starts, Create an initial name space tree structure, and initialize objects in the initial name space tree structure; a control module, configured to control the high-level control unit to call and execute the service of the low-level control unit according to the initial name space tree structure created by the configuration module, wherein The level of the control object is the physical layer, the functional layer and the operation layer in order from low to high, and the control object also includes a maintenance layer at the same level as the operation layer; a monitoring module for monitoring the condition of the kernel system And when the conditions are met, the corresponding actions are executed independently. The invention provides a powerful application programming interface supporting software interlocking, data logging, and communication functions, and realizes component development and software reuse through flexible configuration strategies.

Description

General Control Core System for Integrated Circuit Manufacturing Equipment

technical field

The invention relates to the fields of computer application technology and integrated circuit equipment technology, in particular to a general control core system for integrated circuit manufacturing equipment.

Background technique

With the rapid development of microelectronics technology, information technology, network technology, etc., the rapid growth of the global information industry, the rapid rise of the network economy, the beginning of knowledge economy, and the continuous rise of cutting-edge technologies in modern national defense and future wars, human beings have entered the information and Internet Age. Due to the core position of microelectronics technology, microelectronics has shown its important strategic position more than ever before, and the microelectronics industry has become an important pillar of the global economy and a powerful driving force for economic and social development.

As a part of the IC (Integrated Circuit, integrated circuit) industry, the kernel system is used to develop real-time device control applications and plays a pivotal role. However, the commonality of the core system of the existing integrated circuit is poor, so that the developer's efficiency in developing device control application programs is low, and the performance of the developed application programs is poor in robustness.

Contents of the invention

The purpose of the present invention is to at least solve one of the above-mentioned technical defects, and in particular propose a general control core system for integrated circuit manufacturing equipment with high efficiency, general purpose and flexible configuration.

In order to achieve the above object, an embodiment of the present invention proposes a general control kernel system for integrated circuit manufacturing equipment, including: a configuration module, which is used to instantiate an object and The instantiated object is registered in the namespace, an initial namespace tree structure is created, and the objects in the initial namespace tree structure are initialized, wherein the object maps the behavior of the hardware device; the control module, the The control module is used to control the high-level control unit to call and execute the service of the low-level control unit according to the initial name space tree structure created by the configuration module. The control object also includes a maintenance layer at the same level as the operation layer; and a monitoring module, which is used to monitor the conditions of the kernel system and independently execute corresponding actions when the conditions are met.

In one embodiment of the present invention, the configuration module includes: a configuration file parser, which analyzes the configuration file, and instantiates the object according to the information of the configuration file; a registration unit, the registration unit It is used to register the instantiated object to the name space, and create an initial name space tree structure, the initial name space tree structure is a collection of multiple names; an initialization unit, the initialization unit follows the priority search algorithm variable described initial name space tree structure, and initialize the registered objects according to the information in the configuration file.

In an embodiment of the present invention, the registration unit is also used to create an alias, wherein the one object corresponds to one or more aliases.

In one embodiment of the present invention, the object is accessed in one of the following two ways: 1) accessing the object corresponding to the name by referring to the name in the namespace tree structure; 2) accessing the object corresponding to the alias by referring to the alias Object.

In one embodiment of the present invention, the control module includes: a physical layer control unit, the physical layer control unit reads the data items of the bottom device in the hardware device, and provides services to the bottom device; function A layer control unit, the function layer control unit provides the service of the function layer by invoking the service of the physical layer control unit; an operation layer control unit, the operation layer control unit provides the service by invoking the service of the function layer control unit a service at the operation layer; and a maintenance layer control unit that performs fault location and repair of the physical layer control unit and the functional layer control unit, wherein the maintenance layer control unit invokes the physical layer control unit The unit and function layers control the services of the unit.

In one embodiment of the present invention, the physical layer control unit further includes an EPICS protocol communication part, and the EPICS protocol communication part uses the EPICS protocol to communicate with the hardware device to exchange data items, including reading the state values of underlying devices and send setpoints to said hardware devices.

In one embodiment of the present invention, the data items are divided into discrete type, continuous type and string type according to the type of data carried; the data items are divided into read-only type and read/write type according to the type of read/write operation .

In one embodiment of the present invention, the value of the data item is checked using an interlock, the interlock comprising: a setpoint interlock for controlling the data item of the hardware device being read or written to the hardware device The data items of are only allowed to be modified when the set conditions are satisfied.

In one embodiment of the present invention, the set point interlock includes: read and write data items, the read and write data items are data items read from the hardware device or data items written from the hardware device ; and a checksum, the checksum is used to determine whether the modification of the read-write data item is allowed; an alarm is used to throw a blocking alarm when the modification of the read-write data item is rejected.

In one embodiment of the present invention, the alert provides three recovery actions: abort, retry and continue execution.

In one embodiment of the present invention, the set point interlock further includes a trigger and a qualifier, the trigger is used to set the conditions for modifying the read-write data item, and the qualifier is used to judge whether the calibration needs to be verified. The condition of the verifier.

In one embodiment of the present invention, the monitoring module monitors the security state of the kernel system through a value interlock, and corrects when an unsafe condition of the kernel system is triggered, wherein the value interlock includes : trigger, the trigger sets the unsafe condition of the kernel system; a behavior list, the behavior list is an action after triggering the unsafe condition, wherein when the behavior list includes multiple actions, the Multiple actions are executed one by one.

In an embodiment of the present invention, the value interlock further includes: an alarm, and the alarm is used to provide a non-blocking alarm.

In one embodiment of the present invention, the high-level control unit calling and executing the service of the low-level control unit includes the following steps: the high-level control unit sends a server lock request or a service lock request to the low-level control unit to obtain a server lock or Service lock, initialize the parameters of the requested service, and send a running lock request to the low-level control unit to obtain the running lock; after the high-level control unit obtains the running lock, call and execute the low-level lock corresponding to the running lock The service of the control unit, and release the running lock after the service is completed; the high-level control unit releases the server lock or service lock, wherein the server lock request is used to request to obtain the server lock, and the high-level The control unit uses the server lock to call a service to the low-level control unit, and locks the low-level control unit; the service lock request is used to request to obtain the service lock, and the high-level control unit uses the service lock to send the service to the low-level control unit. The low-level control unit invokes the specified service and locks the call to the specified service; the running lock request is used to request to obtain the running lock, and the high-level control unit uses the running lock to execute the specified service and locks Execution of the specified service.

In one embodiment of the present invention, when the low-level control unit receives the server lock request or service lock request from the high-level control unit, if there is no active server lock, service lock or running lock, Then the low-level control unit grants the high-level control unit a server lock; if there is currently no active server lock or service lock or running lock, or the current service lock and the service lock requested by the service lock perform the same service, then The low-level control unit grants the high-level control unit a service lock.

In one embodiment of the present invention, when the service requested by the high-level control unit is not currently executed, and meets any of the following conditions, the low-level control unit grants the high-level control unit a running lock: 1) There is no active server 2) there is only one active service lock for the currently requested service; 3) there is only one server lock owned by the high-level control unit.

In one embodiment of the present invention, the low-level control unit places server lock requests, service lock requests, or run lock requests that are not granted server locks, service locks, or run locks in the lock request waiting queue in the order of arrival .

In one embodiment of the present invention, the low-level control unit checks the lock request waiting queue after the high-level control unit releases the running lock, and if the current high-level control unit holds the server lock, the low-level control unit Execute the service corresponding to the next running lock request of the current high-level control unit; if the service lock is currently held, the low-level control unit executes the service corresponding to the next running lock request of the service corresponding to the service lock; if there is no active server lock, service lock or running lock, and the next request is a server lock request, grant the server lock to the server lock request, and execute the service corresponding to the running lock request of the high-level control unit that owns the server lock; if there is no Active server lock, service lock or running lock, and the next request is a service lock request, then grant the service lock to the service lock request, and execute all high-level control units to request the corresponding services for the running lock; if there is no active A server lock, a service lock or a running lock, and the next request is a running lock request, then the low-level control unit executes the service corresponding to the running lock request.

In one embodiment of the present invention, an alarm module is further included, configured to issue an alarm when an abnormality occurs in the kernel system.

In one embodiment of the present invention, the alarm module sends a blocking alarm and a non-blocking alarm, and the alarm module will block the thread where the sending object is located after throwing the blocking alarm until the blocking alarm is cleared; After the alarm module throws the non-blocking alarm, the thread where the sending object is located continues to run.

In one embodiment of the present invention, it further includes a log module, which is used to record information during the operation of the kernel system in the form of a log, wherein the log module includes: a data log unit, and the data log unit is used for recording data and events of the kernel system in a first predetermined period; and a system log unit, configured to record call information and trace information of the kernel system in a second predetermined period.

In one embodiment of the present invention, the logging form adopted by the data logging unit includes: time-based logging, the time-based logging is triggered by one or more conditional triggers; periodic logging, the Periodic logging is triggered by an interval trigger.

In one embodiment of the present invention, the system log unit records the modification of the data item, the information of the interlock, the information of the alarm and the information of clearing the alarm.

The general control kernel system for integrated circuit manufacturing equipment provided by the embodiment of the present invention is based on Windows XP operating system, adopts JAVA to realize, has the following advantages:

1) Through the parallelism and resource interlocking of the management system, a unified interface is provided for different types of I/O in the application program, and a time-saving framework for error handling and error recovery, which solves the time-consuming and easy problems in the development of control application programs. wrong question.

2) Provide a powerful application programming interface that supports software interlocking, data logging, and communication functions. Specifically, the interlock API (Application Programming Interface, Application Programming Interface) of the general control kernel system of the embodiment of the present invention ensures the safety of personnel and equipment. Recipe API can store and retrieve process parameters. The data log API can quickly obtain the process parameter information at runtime.

3) Realize component development and software reuse through flexible configuration strategies. The common control kernel system configuration policy in the embodiment of the present invention can facilitate code reuse within the same application program and among different application programs. Also, the common control kernel system configuration file allows software developers to configure the properties of the components, although the above properties will be different in different applications, but without recompilation.

4) Provide necessary tools to support rapid development and debugging of applications. The general control kernel system of the embodiment of the present invention provides two powerful functions of application program debugging and performance tracking, including system log service and console interface, wherein the system log service includes generating system operation records, and the console interface includes View and modify the state of the common control kernel system environment while the application is running.

The general control kernel system of the embodiment of the present invention can enable developers to quickly develop robust control application programs, realize component development and software reuse through flexible configuration strategies, and can also provide necessary tools to support rapid development and debugging of application programs.

Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

Description of drawings

The above and/or additional aspects and advantages of the present invention will become apparent and easy to understand from the following description of the embodiments in conjunction with the accompanying drawings, wherein:

1 is a schematic structural diagram of a general control kernel system for integrated circuit manufacturing equipment according to an embodiment of the present invention;

Fig. 2 is a schematic structural diagram of a configuration module;

Figure 3 is a schematic diagram of a namespace;

Figure 4 is a namespace UML class diagram;

Fig. 5 is the structural representation of control module;

Fig. 6 is a schematic diagram of a data item (DataItem);

Fig. 7 is a schematic diagram of calling service of the control module;

Fig. 8 is a schematic diagram of a control module calling chain;

Figure 9 is a schematic diagram of the alarm process of the alarm module; and

FIG. 10 is a schematic structural diagram of a log module.

Detailed ways

Embodiments of the present invention are described in detail below, examples of which are shown in the drawings, wherein the same or similar reference numerals designate the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary only for explaining the present invention and should not be construed as limiting the present invention.

As shown in FIG. 1 , a general control kernel system 1000 for integrated circuit manufacturing equipment provided by an embodiment of the present invention includes a configuration module 100 , a control module 200 and a monitoring module 300 . Wherein, the configuration module 100 is used for instantiating objects and registering the instantiated objects into the namespace when the kernel system starts, creating an initial namespace tree structure, and configuring the objects in the initial namespace tree structure Initialize, wherein the object maps the behavior of the hardware device; the control module 200 is used to control the call of the high-level control unit and execute the service of the low-level control unit according to the initial name space tree structure created by the configuration module, wherein the level of the control object From low to high, they are physical layer, functional layer and operation layer, and the control object also includes a maintenance layer at the same level as the operation layer; the monitoring module 300 is used to monitor the conditions of the kernel system and when the conditions are met perform the corresponding actions independently.

As shown in FIG. 2 , the configuration module 100 includes a configuration file parser 110 , a registration unit 120 and an initialization unit 130 . Wherein, the configuration file parser 110 is used to analyze the configuration file, and instantiate the object according to the information of the configuration file; the registration unit 120 is used to register the instantiated object into the namespace, and create an initial namespace tree structure, wherein the initial The name space tree structure is a collection of multiple names; the initialization unit 130 is used to variable the initial name space tree structure according to the priority search algorithm, and initialize the registered objects according to the information of the configuration file.

The configuration process of the configuration module 100 occurs during the startup process of the application program, and is responsible for instantiating and initializing objects. Most objects in an application should be instantiated at application startup, not at runtime. The structure of the namespace is determined by the configuration file information and the code in the build() method of the configurable (implementing the Configurable interface) object. The namespace structure does not necessarily reflect the functional relationship between objects, or the relationship between physical, functional, and operational layers, nor does it necessarily reflect the ownership relationship between two objects.

Objects that can be instantiated and initialized through the configuration module 100 must implement the Configurable interface, and the interface information is as follows:

public abstract void build()

public abstract void init()

public abstract void verifyInit()

public abstract void startRunTime()

Among them, the build() interface method is used to instantiate other objects that need to be created; the init() interface method is used to initialize the object, and the typical operation is to create the link relationship between objects and change the object state; the verifyInit() interface method is used to verify property to make sure everything is set up correctly, so that the object can safely execute the job and avoid runtime errors; the startRunTime() method is used to start the runtime, including setting the object to a runtime state, such as allowing some threads to start running, or connecting to an external device.

The configuration process of the configuration module 100 includes the following five stages:

The first stage: the configuration file parser 110 analyzes the configuration file, the registration unit 120 instantiates the object according to the configuration file information, and registers the object into the namespace, and creates an initial namespace tree structure;

The second stage: the initialization unit 130 traverses the initial namespace tree structure created in the first stage from top to bottom and from left to right according to the depth-first search algorithm, initializes the registration object according to the configuration file initialization information parsed in the first stage, and passes Call the build() method of the configurable object associated with the registration node to create the entire namespace tree structure;

The third stage: the initialization unit 130 traverses the namespace tree structure according to the depth-first search algorithm, and calls the init() method of the registered object in the namespace tree to complete the initialization of the object;

The fourth stage: the initialization unit 130 traverses the name space tree structure according to the depth-first search algorithm, and calls the verifyInit() method of the registered object in the name space tree to complete the initialization verification work of the object;

The fifth stage: the initialization unit 130 traverses the name space tree structure according to the depth-first search algorithm, and calls the startRunTime() method of the object registered in the name space tree to perform preparatory work before running the object or set the object to the running state.

Wherein, the first stage of the configuration process is completed by the configuration file parser 110, and the second to fourth stages are completed by the ReferenceBroker, that is, the registration unit 120 and the initialization unit 130 are completed by the ReferenceBroker. In other words, the configuration process of the configuration module 100 includes initializing the registration object of the initial namespace tree structure generated by Parse parsing, and calling build(), init(), verifyInit() and startRunTime() of the Configurable interface in sequence to complete. The common control kernel system configuration function facilitates the development of component-based applications.

ReferenceBroker is a singleton object responsible for registering objects into the namespace and maintaining the mapping between object references and names. ReferenceBroker mainly provides three functions:

1) Register object: establish the mapping relationship between object and name;

2) Create an alias: establish a mapping relationship between an alias and a namespace tree node;

3) Reference the registered object.

A namespace is a tree structure of nodes, most of which are associated with objects. A namespace is a registry of objects in which objects are related to each other by their names, providing a common address space. By using the ReferenceBroker to register an object to create a namespace, and to register a named object in the namespace, any object in the kernel system 1000 can refer to any named object in the namespace by name. Registration specifies the name of the object and the location of the registered object relative to other objects in the tree. All objects in the kernel system 1000 can query the ReferenceBroker for a reference to any object registered in the namespace.

In one embodiment of the invention, objects are accessed in one of two ways:

1) Access the object corresponding to the name by referring to the name in the namespace tree structure;

2) Access the object corresponding to the alias by referring to the alias.

Regarding accessing objects corresponding to names by referring to names in the namespace tree structure, most nodes in the initial namespace tree are associated with named objects, which can be identified in two ways:

Fully qualified name: from the root node of the namespace tree to the current object. Each fully qualified name within a namespace is unique. As shown in Figure 3, the fully qualified name of objectG is "/objectA/objectF/objectG".

Relative names: There is always a starting point, which is called the reference object. In other words, when using a relative name to register an object or refer to an object, a starting point must be clearly provided, and this starting point is a reference object. From the reference object to the current object. For example, if objectP is the reference object, the relative name of objectG is "../../objectA/objectF/objectG".

The name of the named object referenced by the node is a partial name, for example, the partial name of objectG is "objectG". Section names are not unique.

Regarding accessing the object corresponding to the alias by referring to the alias, the concept of the alias is explained first. Aliases can be created through registry unit 120, providing another path to access an original object (as well as other objects) in the namespace. An object can correspond to one or more aliases. When an alias is established, an "alias node" is inserted into the namespace. As shown in Figure 3, aliasOfObjectF is an alias node, which points to the objectF node, so the objectF object has two paths to access: the first path: "/objectA/objectF"; the second path: "/aliasOfObjectF". objectJ also has two paths to access: the first path: "/objectA/objectF/objectJ"; the second path: "/aliasOfObjectF/objectJ".

Various types of nodes of the namespace tree will be described below with reference to FIG. 4 .

A namespace is a tree-like data structure that includes three types of nodes:

General node: There is no association between general nodes and objects;

Registration node: the registration node establishes an association relationship with the object;

Alias node: Alias nodes point to other nodes in the tree for easy access through aliases.

As shown in Figure 4, NamedObject is an important class in the general control kernel system library, and most classes in the system library are derived from NamedObject. NamedObject inherits from the OssObject class and implements the Configurable and MsgLogger interfaces. NamedObject is a named object, one of its important characteristics is that it can be registered in the namespace, and can be referenced by name after the namespace is established, and its derived classes conveniently inherit the system logging function.

The implementation of the namespace tree structure is composed of three types of nodes: UnNamedNode, AliasNode and ReferenceNode. Among them, UnNamedNode can be registered under the ReferenceNode node of the associated (referenced) named object NamedObject, and associated with a configurable object. Among them, NamedObject can implement the Configurable interface.

Both AliasNode and ReferenceNode are NamespaceNode. Among them, AliasNode is used as an alias node and has no child nodes. AliasNode points to a ReferenNode in the namespace.

The ReferenceNode node is the main node in the namespace, it can be associated with a named object NamedObject, or not associated with any object (equivalent to a general node at this time). ReferenceBroker is responsible for managing and maintaining the entire namespace tree structure, and returns the object associated with the corresponding node according to the name at runtime.

The control module 200 and the monitoring module 300 are the main functional modules of the general kernel system 1000, which inherit from the public classes ControlObject and ControlMonitor. These classes have built-in functionality that makes the control logic easier to implement and maintain. A typical application of ControlObject is to represent a well-defined device control domain. Each ControlObject provides an associated service set to complete the control operations in the corresponding domain. For example, a control object that represents a valve might have two services, open and close, which are the two operations that an actual valve device has. ControlObject has built-in features to solve difficult control problems, such as error recovery and multithreading.

The control module and the monitoring module will be described respectively below in conjunction with specific embodiments.

The control module 200 adopts a hierarchical organization, which is a physical layer, a functional layer, and an operation layer/maintenance layer in sequence from low to high. Correspondingly, as shown in FIG. 5 , the control module 200 includes a physical layer control unit 210 , a function layer control unit 220 , an operation layer control unit 230 and a maintenance layer control unit 240 . Wherein, the physical layer control unit 210 is used to read the data items of the bottom device in the hardware device 2000, and provide services to the bottom device; the function layer control unit 220 provides the service of the function layer by calling the service of the physical layer control unit 210; The operation layer control unit 230 provides the service of the operation layer by calling the service of the function layer control unit 220; the maintenance layer control unit 240 performs fault location and repair to the physical layer control unit 210 and the function layer control unit 220, wherein the maintenance layer control The unit 240 may invoke services of the physical layer control unit 210 and the functional layer control unit 220 . The high-level control unit can invoke the methods and services of the same-level or low-level control units, thereby establishing a call chain of the control module 200 .

The service calling process in the control module 200 will be described below in combination with specific embodiments.

As shown in FIG. 5 , the physical layer control unit 210 is located at the lowest layer, and maps low-level devices in the hardware device 2000 , such as simple devices in the hardware device 2000 . The physical layer control unit 210 includes an EPICS protocol communication part 211, which is used to communicate with the hardware device 2000 using the EPICS protocol to exchange data items (DataItem), including reading the status value of the bottom device in the hardware device 2000, and sending the data to the hardware device 2000 Send the associated setpoint. For example a valve control object class that might reference a read/write DataItem representing a solenoid that opens or closes a valve, and a read-only DataItem representing a contact sensor that represents the valve's open or closed state. Since the operation of the above-mentioned DataItems cannot be simplified, the valve object belongs to the bottom layer.

The data item (DataItem) provides a mechanism for exchanging data between the kernel system 1000 and the external hardware device 2000 and between various modules in the kernel system 1000 . Wherein, the data exchange with the external hardware device 2000 is realized by providing an abstract interface to the I/O device driver. Data exchange between modules in the kernel system 1000 is realized by storing internal data that needs to be globally visible in the whole kernel system 1000 . The DataItems of the physical device are associated with the physical device through EPICS I/O.

In one embodiment of the present invention, the data item (DataItem) can be divided into discrete type (int), continuous type (double), string type (string), and general type (any java object ).

DataItem can be divided into read-only type and read/write type according to different read/write (I/O) operation types. As shown in Figure 6, a read-only DataItem is associated with a data source, and only this data source can update its value. This data source can be an I/O object or a non-I/O object. Read-only data items (DataItem) can be read and applied for.

The read-write DataItem is associated with a target, and the settings for the read-write DataItem will be transferred to the corresponding physical device I/O point. The read-write DataItem can also be used for non-I/O purposes, and only represents a variable that can be read and written. Read and write DataItem can be read, written, applied for, and vetoed.

In one embodiment of the present invention, a DataItem with a data source includes three important characteristics: access mode, polling and validity.

1) Access mode: read from DataItem or its data source

Local: get the value from the local DataItem;

Remote: read the remote physical device through its data source, and then return the value. Since remote access takes longer than local access, you need to wait when waiting for the device to return a value;

Smart: use local access if polling, otherwise use remote access.

2) Polling: Whether the DataItem is continuously updated by its data source. Polling is automatically implemented in the following cases: has subscribers, has attachers or is used in a DataSpec that is being used by a CollectionSpec using synchronous mode.

3) Validity: Whether there is a match between the DataItem and its data source

invalid: the data has never been read, and the data source is offline;

not_init: the data has not been read, and the data source is online;

stale: the data may not be fresh, but the data source is online;

offline: the data may not be fresh, but the data source is offline;

good: The data is fresh, where the data value of a DataItem with an internal data source or without a data source is always good.

Data item (DataItem) related interfaces include: Subscriber interface, Vetoer interface, TimeListener interface.

Subscriber interface: void updateFromItem(DataItem, NewValue, Valid). The method of the Subscriber interface is to call DataItem.subscribe(Subscriber) to register on the DataItem. When the value of the DataItem changes, it will automatically call the Subscriber interface method updateFromItem to perform the corresponding action.

Vetoer interface: void checkVeto(DataItem, ProposedValue). The method of the Vetoer interface is to call DataItem.subscribeVetoer(Vetoer) to register on the DataItem. When the value of the DataItem is set, the interface method checkVeto of Vetoer will be called to verify whether the proposed value is accepted or rejected.

TimeListener interface: updateFromTimer() method. The method of the TimeListener interface is to call Timer.subscribeTimerListener (TimeListener) to register on the Timer, and after the timer expires, call the interface method subscribeTimerListener of TimeListener to perform corresponding actions.

Data item (DataItem) includes required attributes and optional attributes. Among them, the required properties constitute the state of the object.

Required attributes: value, timestamp, validity;

Optional attributes: data source, target, typeInfo, peer, simulator.

In order to provide a layer of security that overrides DataItem value changes, a setpoint interlock is implemented at kernel system 1000 time. The setpoint interlock is based on DataItem, applied to DataItems, and performs corresponding actions when the value of DataItems changes. The setpoint interlock is preventive. A setpoint interlock can only check the value of a DataItem, not the state of an object. Specifically, the set point interlock controls that the data item of the hardware device 2000 read or written into the data item of the hardware device 2000 is allowed to be modified only when the set condition is satisfied.

A setpoint interlock consists of a read-write data item (DataItem), one or more checksums, and an alarm. In addition, the setpoint interlock can further include a trigger and a qualifier. Among them, triggers and qualifiers are optional conditions. The setpoint interlock can be expressed by the following formula:

SetpointInterlock＝R-W DataItem+Trigger+Qualifier+{Checkers}+Blocking Alarm.

The setpoint interlock will veto a proposed modification to a DataItem when the trigger condition is true, the qualifier condition is true, and at least one validator is false, otherwise the proposed modification will be allowed.

Read-write DataItem: The read-write data item (DataItem) is a data item read from the hardware device 2000 or a data item written from the hardware device 2000 . The setpoint interlock is associated with a specific DataItem specified in the trigger condition or directly in the setpoint interlock;

Trigger: Triggers are used to set conditions for modifying read and write data items. The trigger is the first condition to check. This condition is a complex condition, generally a condition involving the proposed modification of the DataItem. If a read-write DataItem is not explicitly specified, the DataItem associated with the setpoint interlock is the first read-write DataItem from the left in the trigger complex condition. (back root traversal)

Qualifier: The qualifier is used to determine whether the verification character needs to be verified. The condition to validate the validator is a complex condition. Subsequent conditions need to be checked only if this particular condition is met. The qualifier works based on the current value of the DataItem, even if the qualifier contains the same DataItem as the trigger. A trigger checks the proposed value of a DataItem (the current value has not been modified), while a qualifier checks the current value of the same DataItem. The purpose of qualifiers is to simplify a complex trigger condition.

Verifier: The verifier is used to determine whether the modification of the read-write data item is allowed. Description of validators that determine whether a proposed setting value is allowed or not. The Verifier interface currently only requires one implementation. A requirement is based on a condition, which can be a simple condition or a complex condition. The proposed setting value is only allowed if the corresponding condition is true. If the requirements cannot meet the requirements, you can customize the special inspection requirements by implementing the verifier interface. Validators can also work based on the current value of the DataItem. A setpoint interlock must include at least one verifier.

Alarm: The alarm is used to throw a blocking alarm when the modification of the read-write data item is vetoed. If the proposed setting value is overruled, a blocking alert will be thrown. A setpoint interlock must include a blocked alarm. If no specified alarm is displayed using the Set Alarm method, the Setpoint Interlock will create its own alarm. The alarm can provide three recovery actions: abandon (Abort), retry (Retry) and continue execution (Continue). If a null parameter is passed using the setalarm method, it means that no alarm will be associated with the setpoint interlock, so that an exception will be thrown if the proposed value is overruled.

The concepts of conditions and events involved in the present invention will be described below.

A condition is an object involving comparisons of DataItems and constants. The value of the condition can be classified as true, false or unknown. Among them, unknown is the value when the condition is associated with one or more DataItem offline. A condition object is created in the general control kernel system 1000, and the condition can be accessed anywhere in the kernel system 1000 through the condition name. In other words, instead of rewriting the logical judgment statement every time it is needed, the same logical judgment can be reused by referencing a condition object.

Conditions can be simple or complex. Simple conditions are for example comparing two DataItems, or comparing a DataItem with a constant. The two compared elements must be of compatible types to be comparable. A complex condition is, for example, linking two conditions through a binary logic operator (AND, OR), so as to form a condition tree, and each node in the condition tree can be judged.

Each condition includes left and/or right terms, operators, that is, each condition includes two or three elements. Table 1 shows the structure of the conditions.

Table 1

As can be seen from Table 1, conditional operators include:

1) Comparison operators: ">", ">=", "<", "<=", "==", "!=";

2) Logical operators: "AND", "OR", "NOT";

3) Other operators: "CHANGES", "TIMER", "FOR".

Conditions are mainly used in the following three situations:

1) waitFor method, wherein the waitFor method is a method in the basic control class;

2) Events, create events through conditions, and the conditions used to create events are called event sources;

3) Use conditions to provide decision information, and determine the execution code type according to its value.

Events are created from conditions (event sources), once created an event exists but is inactive until the first condition in the condition tree fires true. When the last (outermost) condition trigger is true, that is, when the entire condition tree is judged, the event occurs. When an event occurs, notify its registrants with itself as a parameter.

Table 2 shows the corresponding table of conditions and events of the general control kernel system 1000 in the embodiment of the present invention.

Table 2

As shown in Table 2, if an event is based on the OR connection of multiple conditions, it is necessary to know which condition triggers the entire condition to be true when the event occurs. The information provided by the condition list is the value status of each condition when the event occurs. The condition list is a vector containing references and values for the different conditions when the event occurs.

Complex conditions joined by binary logical operators form a condition tree. The conditional tree includes leaf nodes and branch nodes. Each node in the condition tree represents a condition, which can be used for judgment. The condition tree is composed of condition nodes represented by various concrete subclasses derived from the basic condition abstract class. Among them, the leaf node represents a simple condition, which can be a change condition (representing a DataItem "CHANGES" condition) and a derived class of an abstract leaf condition (Equal, NotEqualCondition, Greater, GreaterEqual, Less, LessEqual).

Branch nodes represent compound conditions, including Not, condition change conditions, and derived classes of the abstract class Branch Condition connected by binary logical operators. Among them, Not represents the compound condition connected by the unary logical operator NOT, and the condition change condition represents the condition "CHANGES". Derived classes of the abstract class BranchCondition joined by binary logical operators include And and Or.

Events are created from (event source) conditions, corresponding to a condition tree, which also creates an event tree. The corresponding event tree also has leaf nodes and branch nodes. The event tree is composed of event nodes represented by various concrete subclasses derived from the control event abstract class. Among them, leaf nodes can be change events (corresponding to change conditions) and leaf events (corresponding to leaf conditions); branch nodes can be condition change events (corresponding to condition change conditions), no events (corresponding to no conditions) , a time event (representing the condition "FOR" cycle condition, corresponding to a time condition) and a logic event (corresponding to a branch condition).

The condition tree is a static concept, while the event tree is a dynamic concept. The definition of the abstract class control event contains 3 member variables: Condition containerCondition, BaseCondition topOfConditionTree and EventSubscriber eventSubscriber. Among them, Condition containerCondition represents the condition encapsulation with the basic condition node in the corresponding condition tree. BaseCondition topOfConditionTree represents the root node of the condition tree. EventSubscriber eventSubscriber represents the event applicant registered with it, which is actually the parent node of the event node in the event tree when it is implemented: each non-root node in the condition tree has one and only one parent node; to the condition tree The object registered by the root node implements the EventSubscriber interface, so that it can be notified in time when the entire condition value is triggered to be true.

The dynamism of the event tree is realized through the Subscriber mode: the branch nodes in the event tree register with their child nodes by implementing the EventSubscriber interface (condition change event, no event, logic event) or the TimerListener interface (time event). When the point condition value changes, it will be notified and the corresponding action will be executed. The leaf node in the event tree is associated with the DataItem. By implementing the UntypedSubscriber interface (change event) or the DiscreteSubscriber, ContinuousSubscriber and TextSubscriber (leaf event) interfaces, and registering with the associated DataItem, it will be notified when the value of the associated DataItem changes, and execute the corresponding action.

Therefore, the event tree is a bottom-up notification mechanism: DataItem → leaf node → branch node (parent node) → root node, so as to complete the timely judgment of the condition value of the entire event tree. When the condition value trigger of the outermost root node of the event tree is true, the event occurs, and the corresponding action is executed by calling the updateFromEvent interface method of the EventSubscriber interface implemented by its registrant.

Event locks are used when creating event trees, judging event values, and notifying registrants. During the event tree creation process, the entire event tree is recursively created from the root node, and all nodes in the event tree share the same event lock to ensure that the update of event values of different nodes is effectively synchronized and controlled, without An inconsistency occurred.

The functional layer control unit 220 is invoked by the operation layer control unit 230 by invoking the service of the physical layer. The functional layer control unit 220 provides a complete service. For example, a functional layer vacuum evaporation object might call a physical layer valve object and a physical layer pump object to provide operations to evacuate the chamber. The functional layer control unit 220 is usually a manager. For example, one functional layer isolation valve object can control the actions of multiple isolation valves in the physical layer.

The operation layer control unit 230 is located at the highest layer. In the general control core system 1000 of the embodiment of the present invention, the operator can use any client of the general control core system 1000 . Therefore, the operator of a common control kernel system 1000 can be an operator, can also equip a cluster with supervisory software (such as CTC), and can also be any software entity that interacts with the operation layer of the common control kernel system application program. The operation layer control unit 230 can call the service of the function layer through the function layer control unit 220 , but cannot bypass the function layer control unit 220 and directly call the service of the physical layer control unit 210 .

The maintenance layer control unit 240 is located at the highest layer. The maintenance layer is another layer other than the operation layer that interacts with the outside world through a user interface. The maintenance level control unit 240 provides maintenance engineers (non-operators) with a view for performing low-level fault location and repair. The maintenance layer control unit 240 can directly call the physical layer control unit 210 and the function layer control unit 220 .

The interaction between the control units of each layer adopts the method of client/server, in which the control unit that provides the service is the server, and the control unit that invokes the service is called the client. In an embodiment of the present invention, one control unit can be both a server and a client. For example: the operation layer control unit 230 is both a server and a client.

Specifically, the operation layer control unit 230 can invoke the services of the lower layer control units, and at the same time be invoked by an operator (such as a CTC). The functional layer control unit 220 is usually both a server and a client. The function layer control unit 220 can invoke the services of the lower layer control units, and at the same time be invoked by the higher layer control units. The physical layer control unit 210 is usually only a server, and the high-level control unit will call its service, but the physical layer control unit 210 will not call the service itself, but simply call the setValue() method of the associated DataItems to set the I/O of the physical device point. When a control unit (client) requests the services of another control unit (server), the request will be queued until another control object is free. The client will block until the requested service starts executing, and the server will block until the requested service finishes executing.

All lock (including unlock) methods are part of the control object class and are called by the client on the server. The lock of a control object can include the following situations:

1) No lock;

2) A run lock;

3) A server lock;

4) A service lock;

5) A server lock and a running lock;

5) Multiple service locks (for the same service) and one run lock.

Wherein, the server lock request is used to request to obtain a server lock, and the high-level control unit uses the server lock to call a service to the low-level control unit, and locks the low-level control unit. The service lock request is used to request to obtain a service lock, and the high-level control unit uses the service lock to call a specified service to the low-level control unit, and locks the call to the specified service. The running lock request is used to request to obtain a running lock, and the high-level control unit uses the running lock to execute the specified service and lock the execution of the specified service.

To create a control object, it needs to be derived from the control object or the derived class of the existing control object. A service for creating a control object needs to be a public inner class of the control object and derived from the control service.

As shown in Figure 7, the public inner class as the control object needs to implement the abstract method defined in the control service: public void execute() throws BaseException to customize specific service logic. But the execute() method of a service cannot call other services of the same control object, so a deadlock will occur because a control object only allows one service to execute at a time.

The high-level control unit calls and executes the service of the low-level control unit including the following steps:

1) Preparation stage:

1.1) Processing lock request: When the high-level control unit requests to execute a service, it usually first applies for a server lock or service lock.

When the low-level control unit receives the server lock request or service lock request from the high-level control unit, if there is no active server lock, service lock or running lock, the low-level control unit grants the server lock to all high-level control units.

If there is currently no active server lock, service lock or running lock, or the current service lock performs the same service as the service lock requested by the service lock, then the low-level control unit grants the high-level control unit a service lock.

If the lock request is not granted immediately, it is placed at the end of the lock request waiting queue. The low-level control unit places server lock requests, service lock requests or run lock requests that are not granted server locks, service locks or run locks in the lock request waiting queue in the order of arrival. All lock requests have the same priority in the wait queue. If multiple clients try to acquire a lock at the same time, only one lock request will be granted, while other lock requests will be queued for grant. Use the unlock method to remove all locks. If a server or client aborts, all locks are automatically released. The request and grant of the lock need to use a certain data structure, and consider the consistency of the data structure, that is, to realize the synchronization of multiple threads accessing the same data structure.

1.2) Instantiation and invocation: the client instantiates and invokes the service. A new control service inner class instance is created and initialized with the required parameters for the requested service.

1.3) Check availability: the requested service is immediately permitted (i.e., a running lock is applied for), and if the requested service is not currently being executed (i.e., no service is currently being executed), and any of the following conditions is met, the low-level control unit A run lock is granted to the higher level control unit.

A) No active server locks, service locks or run locks;

B) There is only one active service lock for the currently requested service;

C) There is only one server lock owned by the high-level control unit, in other words, there is only one active server lock, and it is owned by the current client.

If the running lock request is not granted immediately, it is placed at the end of the lock request waiting queue.

2) Executing the service

2.1) Calling: When the control unit is ready to run the service, the client automatically obtains the running lock of the server. To execute a service, the server calls the execute() method of the requested service. The execute() method may call other methods or other services, thus establishing a call chain. When another service is invoked, the current service is considered to be running in "parent mode", so the (running) lock of the parent service is still held until all dependent methods and services complete. The calling service does not pass control to the service it called, but holds that control itself, so that the run lock will be held until the service completes.

When a control service invokes a service in a control unit, the two entities are considered to be part of the same invocation chain. Several control units can be linked in a call chain. Higher control units in the call chain typically block because they wait for lower control units in the call chain to complete their services. The call chain is only valid as long as one object holds a lock on another object, once the service call is complete and all locks are released, the server is no longer in the call chain.

2.2) Alerting and aborting: During execution, a service may encounter a condition which causes it to throw an alert. Alarm recovery may require service re-execution. This service is thrown out in the form of RetryException, which is intercepted by the control object system, and the system then continues to call the execute() method of this control service to re-execute the code that caused the alarm to be thrown. The recovery option may also require the service to be terminated midway. This mechanism is similar to retry. An AbortException will be intercepted by the control object system and cause the object to terminate the service.

2.3) Completion: The service execution is completed, and the running lock is released.

2.4) Release the server lock or service lock: the high-level control unit will release the server lock or service lock.

As shown in FIG. 8 , a control object calls other control objects in a call mode or a start mode to form a control service service invocation chain. In Figure 8, the control object CO_A invokes the control service of CO_B in call mode, the control service of CO_B calls the control services of CO_C and CO_D in the start mode, and the control service of CO_C calls the control service of CO_F. The control object CO_E also requests the control service of CO_B by means of a call (it may be the same as that requested by the control object CO_A, or it may be different). Since at most one active run lock is granted, the control object can only execute one service request at a time. Therefore, CO_E's running lock request to CO_B is placed in the waitingLockRequests queue of the lockManager data member of CO_B to wait for grant.

If an object in the call chain is requested to abort or catches an exception while executing the service, this object will abort all its associated control objects in the form of server and client. For example, initiating abort on any object in Figure 8 (eg, CO_D) will eventually abort all control objects in the diagram. The abort process includes:

S1: CO_D removes all lock requests granted by it, completes the abort, and passes the abort request up the call chain to its client CO_B;

S2: CO_B then sends the abort request to the server CO_C and the server CO_F of CO_C in turn along a call chain branch;

S3: CO_F completes the suspension first, and CO_C completes the suspension next;

The control returns to CO_B, CO_B completes the suspension, and passes the suspension request to its client along the two call chain branches, that is, CO_A and CO_E, and accordingly CO_A and CO_E also complete the suspension one after another;

S4: The abort process ends, but the control object is not destroyed.

Whenever a service execution is completed, after the high-level control unit releases the running lock, the low-level control unit (server) will check the lock request waiting queue to determine which service to execute next. Checking the lock request waiting queue includes traversing each lock request in the lock request waiting queue.

1) The current client (high-level control unit) still holds the server lock, and the server (low-level control unit) will execute the next service request (running lock request) of the client with the server lock.

2) Currently holding a service lock, the server (lower layer control unit) will execute the next service request (running lock request) for this service.

3) There is currently no active lock, that is, there is no active server lock or service lock. The running lock is automatically applied for and released before and after the service is executed, and the next request is a server lock, then the server lock request is granted a server lock. The server (low-level control unit) then executes the next service request (run lock) of the client (high-level control unit) that owns the server lock.

4) There is currently no active lock, and the next request is a service lock, then grant the service lock to the service lock request. The server (lower level control unit) then executes any client (higher level control unit) execution request for this service (run lock).

5) There is currently no active server lock, service lock or running lock, and the next service request is a running lock request, and the server (lower control unit) executes the service corresponding to the running lock request.

The services provided by the control module 200 are implemented in the form of internal class control services. The high-level control unit receives the command, and then calls the low-level control unit to execute the command. The physical layer control unit 210 at the lowest layer sets or reads the value of DataItems to perform device I/O. The control module 200 has the following important characteristics:

1) Allow the control units to execute services concurrently without interfering with each other without establishing independent threads for execution, which is achieved by setting locks on the control units;

2) Including a powerful method -waitFor, waitFor is used to suspend the execution of the service until a certain condition is met;

3) Robust handling of exceptions and aborts, since the current control unit can obtain relationships between itself and other control units, which are clients or servers of the current control unit.

Control service is an important built-in feature of the control unit, which is suitable for the interaction between two control units (the client requests the service, and the server executes the service), providing a built-in security layer, including:

1) Race condition: Only one service can execute at a time on the server. When a service is running, the server where the service is located is locked. The control object queues all service requests and decides when and in what order to execute the queued requests.

2) Thread synchronization: The service implements multi-threading, but does not use the Java thread synchronization mechanism. The synchronization mechanism applies the idea of "critical section". In the "critical section", only one thread can execute in the critical section at a time. The service application has the same concept as the synchronization mechanism.

3) Exception handling: The service automatically handles exceptions, such as abort and retry.

The monitoring module (ControlMonitor) 300 is used to monitor the conditions of the kernel system 1000 and independently execute corresponding actions when the conditions are met. The ControlMonitor object and other modules of the kernel system 1000 perform operations concurrently. The monitoring module 300 detects a set of conditions and performs corresponding actions when certain conditions are met. For example, the monitoring module 300 performs the task of maintaining a cavity pressure when a specific process is executed, and the control object is only run when the specific process is executed. One use of ControlMonitor is as a background simulator, monitoring continuous data items being set to a value within a specific range, and then having sensor data items simulate the desired response.

The monitoring module 300 contains a runtime flag that is automatically created when the monitoring module 300 object is instantiated. The running flag is a DataItem, which is used to indicate the status of the monitoring module 300, that is, whether it is currently running.

A monitoring module 300 is started by calling the startRunning() method. When the startRunning() method is called, the kernel system 1000 sets the running flag to on, and calls the execute() method. The monitoring function must be executed by overloading the execute() method. execute() includes a waitFor() method that waits for a specific condition to occur. When the condition occurs, execute() performs the specified action, and then generally returns to the waitFor() method, thus forming a loop. Therefore, the running monitoring module 300 may perform waitFor() or specific actions.

By calling the stopRunning() method to stop a monitoring module 300, the kernel system 1000 sets the running flag to off. If the monitoring module 300 is waiting, the waitFor() method exits, and execute() is started. If the monitoring module 300 is performing an action, the action will continue. Setting the running flag to off will not automatically stop the monitoring module 300 , and a judgment on the running flag needs to be added to the loop condition.

The monitoring module 300 can be a client of a control unit in the control module 200, which means that its execute() method can call a service of a control unit. However, the monitoring module 300 itself does not provide services and will not become a server. Therefore, the monitoring module 300 is always at the top of the call chain.

The monitoring module 300 can be aborted by calling the startAbort() or haltMonitor() methods. When the monitoring module 300 is required to abort, it ensures that all control objects in the call chain that are executing services under it have completed the abort, and then the control transfers to the abort code defined by the application. The monitoring module 300 then stops executing unless it is ordered to continue executing after an abort. haltMonitor() halts execution of the monitor module 300, blocking the caller until the halt successfully completes.

The monitoring module 300 is more flexible than Interlock. Interlock can only set one DataItem, while the monitoring module 300 can implement multiple actions by overloading the execute() method.

The service of the control unit is available remotely when the following conditions are met:

1) Integrate the general control core system 1000 with ClusterLink CTC or GFX;

2) Write your own Java or C++ client to communicate with the general control kernel system 1000. The client can be a maintenance or operation interface, a CTC in the factory, a data collection system, and the like.

The remote interface of the common control kernel system 1000 allows control object services to be invoked remotely by an independent program. When a service is called in this way, it is called a remote call. The remote program can run on the same computer as the common control kernel system 1000, or can run on different computers in the same network. At this time, predetermined rules need to be followed to make the service of a control object remotely accessible.

In an embodiment of the present invention, the monitoring module 300 can monitor the safety state of the kernel system 1000 through value interlocking, and correct when an unsafe condition of the kernel system 1000 is triggered. Value interlocks are corrective. The value interlock detects whether the DataItem reaches a specific value, and automatically executes a series of related operations. For example, a value interlock can be used to detect an unsafe condition in equipment and perform a series of actions to restore the equipment to a safe state when the unsafe condition occurs.

A value interlock includes a trigger and a list of actions. In addition, a value interlock can also include a non-blocking alarm. Among them, non-blocking alarm is an optional condition. The value interlock can be expressed as: ValueInterlock＝Trigger+{Action}+Unblocking Alarm.

Trigger: A trigger sets an unsafe condition of the kernel system 1000 and is used to describe an unsafe state. When the value interlock falls into the trigger condition, it means that the kernel system 1000 is in an unsafe state. A trigger condition can be a simple condition, or a complex condition.

Behavior list: the behavior list is an action after an unsafe condition is triggered, and when the behavior list includes multiple actions, the multiple actions can be executed one by one. Specifically, the action list is an object with an execute method. When the trigger condition is true, the value interlock will automatically call the execute interface method of the behavior. The current behavior interface has three implementation classes, namely Assignment, Addition and Ensure, which modify a read-write DataItem. If the above three behavior implementation classes cannot meet the requirements, you can customize the special action requirements by implementing the behavior interface. The DataItem modified in the behavior can be a DataItem in the trigger condition, or a completely different DataItem. If a value interlock has multiple actions, all actions will be executed one after the other.

Alarm: The alarm is a non-blocking alarm. If there is said non-blocking alarm, it is thrown in the Ensure action.

The general control kernel system 1000 further includes an alarm module 400 for sending an alarm when the kernel system 1000 is abnormal. The alarm module 400 can notify an operator or other entity (such as a remote host) of the occurrence of an abnormality, while providing optional recovery actions for clearing the alarm.

The alarm types issued by the alarm module 400 include blocking alarms and non-blocking alarms. Wherein, the alarm module 400 will block the thread where the sending object is located after throwing the blocking alarm until the blocking alarm is cleared. Blocking alarms are cleared as part of an alarm recovery action. After the alarm module 400 throws a non-blocking alarm, the thread where the sending object is located does not need to be blocked but continues to run. Non-blocking alarms are used to warn the operator of a possible error, or to alert the operator that an action is in progress.

As shown in Figure 9, the alarm module 400 includes the following attributes: an integer alarm identifier, a message (message), a description (description), a severity level (severity), an optional automatic recovery option (autorecovery), And one or more recovery options (recovery). Wherein, the message (message) is a brief description of the alarm module 400, and the description (description) is a detailed description of the alarm module 400. Each automatic recovery option or recovery option includes four attributes: a recovery message, an access group, a recovery type, and an optional recovery action.

Alarm ID: Indicates the alarm ID, maps the alarm to a digital ID, and may be required by the remote interface.

Message (message): Used for logging or displaying to the operator, divided into two types: static and dynamic.

1) Static: the alarm message will not change;

2) Dynamic: the alarm message contains information that depends on the runtime environment, which is realized by inserting a marker (Marker: "<MarkerName>") into the alarm message string. When sending an alarm, "<MarkerName>" in the alarm message will be replaced by the current marker value. Mapping can be achieved in two ways: <MarkerName, ObjectName, AttrName> and <MarkerName, MarkerValue>.

Severity: Each alarm is assigned an integer severity level, which can be used to filter alarms by the alarm client, or display different colors in different colors on the GUI (Graphical User Interface, Graphical User Interface) alarm page. Severity level alarms.

Autorecovery: Autorecovery is an optional attribute used for automatic recovery. If the auto-reply attribute is not empty, when the alarm module 400 throws an alarm, it will automatically perform a recovery action to clear the alarm. When an alarm is cleared, no operator-selected actions will be performed. When using the automatic recovery option to establish a system recovery, special attention needs to be paid to including the automatic recovery option and a range of recovery options from which the operator can choose. The automatic recovery option has the following two advantages: First, no user intervention is required after the alarm is thrown: for example, when the alarm has only one system recovery option, or only one user-defined recovery option; second, when performing other actions further, the system needs to be in A safe state: Usually the automatic recovery option is when the user defines the recovery option.

Recovery: A set of alarm recovery options, which is a list of one or more recovery objects. A recovery object contains four attributes: recovery message, access group, recovery type, and recovery action.

recovery message: recovery option message displayed to the operator;

Access group: access group may be used on CTC side: different operators are assigned different access groups, and can only operate alarm recovery options with this access group attribute;

Recovery type: Alarm recovery type includes system type and user-defined type. The system types include abandoning ABORT, retrying RETRY, continuing CONTINUE and clearing CLEAR. The user-defined type is SER_ONLY. For each system recovery type, it includes the system built-in function to execute the recovery action corresponding to the recovery type;

Recovery action (recovery action): Accept an object that implements the interface RecoveryAction interface as a recovery action.

For system restore types, restore actions are optional. The combination of recovery action and system recovery type can put the kernel system 1000 in a safe state before executing the recovery action built into the kernel system 1000.

For user restore type, restore action is required. A complete alarm recovery function needs to be defined to clear the alarm through the system recovery options (only ABORT, RETRY, CONTINUE).

The alarm module 400 has the following advantages:

1) Whenever the kernel system 1000 cannot resolve an error situation, the alarm module 400 is used to notify the operator and allow the operator to decide how to handle it;

2) When a certain state occurs, there is no need to stop the execution of the current service, but the operator needs to know about this state.

The alarm module 400 includes a sending unit, which is used to send an alarm when a specific situation occurs. The alarm module 400 further includes a monitoring unit, which notifies the monitoring unit when the status of the alarm or the status of a recovery action changes. For example: when the alarm module 400 sends or clears an alarm, and starts or finishes executing a recovery action, it notifies the monitoring unit.

When the alarm module 400 sends an alarm, the sending object will be blocked (if the alarm is a blocking alarm), and the system calls the updateAlarmState() callback function of the client registered to the alarm. A typical client of the alarm module 400 is the monitoring module 300. When the alarm module 400 sends a certain number of alarms or sends a certain type of alarm, the monitoring module 300 will perform specific actions. The executor of the alarm recovery action, that is, the alarm module can be either a remote client or a local client.

The general control core system 1000 provided by the embodiment of the present invention further includes a log module, configured to record information during the operation of the general control core system 1000 in the form of a log. The log module defines the information contained in the log file, which is used to filter the system log information. The logging module can be modified at runtime, thereby changing the amount and level of logging information that will be logged.

As shown in FIG. 10 , the log module 500 includes a data log unit 510 and a system log unit 520 .

The data log unit 510 is configured to record data and events of the kernel system 1000 at a first predetermined period. Data logging is a mechanism of the general control kernel system 1000 that allows data and events to be logged and recorded into files, thereby providing useful debugging and performance tracking information to application developers. The data log unit 510 records data into a log file every predetermined time or when a certain event occurs. The recorded data includes the time and/or event that occurred, and the value of a particular data item at that time. Some data log sessions can be executed concurrently to collect different data according to different specifications.

The data log unit 510 collects data and writes it into a log file. Information such as what data is collected and when it was collected is included in a session. Each session includes a collection description that includes a data description that includes references to DataItems. Multiple sessions can be opened for logging at the same time.

The terms involved in the data log unit 510 are explained below.

DataSpec: A list of DataItems, indicating the data recorded together, specifying what to log. For example, a DataSpec could specify to record the values of the following DataItems: Pressure, Wafer Sensor, Temperature, Open Sensor, and Valve1.

CollectionSpec: A list of DataSpecs, indicating that the list of DataSpecs will be recorded into a file based on the same trigger, specifying when to log. These triggers that define what triggers data logging are time interval (record data at a specific time, called time trigger) and condition (record data when a condition is met, called event trigger). For example, a CollectionSpec specifies to record the DataItems specified in DataSpecA at intervals of 10s.

Session: A set of CollectionSpec, which means that a set of CollectionSpec is recorded simultaneously and recorded to the same destination, such as a file). In normal operation, multiple Sessions can be open at the same time, recording data to different files. Session allows application personnel to record data according to different purposes. For example, one session is used for application development, for debugging purposes. Another session is used to log data during application deployment for tracking data purposes. The two sessions can use some of the same CollectionSpecs, while other CollectionSpecs are specific for different purposes. Application personnel can create a session to collect drawing data, another session to collect archive data, and a third session to collect debug data.

DataLogDestination: Indicates destination information, which is managed by StorageManager. Currently the only DataLogDestination and StorageManager classes are the DataLogFile and TextStorageManager classes.

DataLogFile: A subclass of the abstract class DataLogDestination. A DataLogFile object receives data and writes the data to a permanent text file.

TextStorageManager: A subclass of the abstract class StorageManager. The abstract class StorageManager is used for text-based storage management and defines the directory structure of all log files.

In order to record data logs, the data log unit 510 must define a Session and link it to a destination. For example, a data log file (text file), and call the Session.open method to open (activate) the Session. When the Session is open, nothing is recorded into the destination until a trigger in a CollectionSpec occurs. A trigger can be a condition, or a time interval. When a trigger occurs, information about the trigger and all DataItems associated with this CollectionSpec are logged to the destination.

The data logging rules of the data logging unit 510 are:

DataItems: A DataItem can be used in multiple DataSpecs, regardless of whether the DataSpec is locked or not.

DataSpecs: A DataSpec can be used in multiple CollectionSpecs, regardless of whether the CollectionSpec is activated or not. In other words, a DataSpec can be locked by multiple Sessions at the same time.

CollectionSpecs: A CollectionSpec cannot be used in multiple Sessions. In other words, a CollectionSpec cannot be active in multiple Sessions at the same time.

DataLogFiles: Generally a DataLogFile is the only attribute of a Session. DataLogFiles are not intended to be shared among multiple Sessions. A DataLogFile cannot be connected to multiple open Sessions.

The data logging unit 510 may adopt the following two logging forms: time-based logging and periodic logging. Among them, event-based logging (Event-based logging) is triggered by specifying one or more conditional triggers. Periodic logging needs to specify a time interval trigger to trigger.

(1) Create a DataSpec: Use the DataSpec.addToData() method to add DataItems.

(2) Create CollectionSpec: it has the following attributes:

(2.1) One or more DataSpec objects: use the CollectionSpec.addToDataSpecs() method to add DataSpec objects.

(2.2) 1 or more triggers: The condition of the trigger is added using the addToTriggers() method. Interval triggers use the setInterval() method.

(2.3) Data collection method:

Synchronous mode: CollectionSpec attaches it to the DataItem it contains to ensure that all the data it collects is good. The reading of the DataItem value is always placed in the thread where the trigger is located. Synchronous mode is recommended for using an interval trigger with a short interval, or a condition trigger that occurs frequently.

Asynchronous mode: CollectionSpec uses intelligent mode to collect data to ensure that the collected data is always good. Reading of DataItem values is always done in a separate thread to avoid blocking the trigger's thread. Asynchronous mode is recommended for an infrequently occurring interval trigger.

Default mode: which mode to use is determined by the kernel system 1000 . Synchronous mode is used when the interval is less than or equal to 10 seconds, and asynchronous mode is used when the interval is greater than 10 seconds or there is no interval trigger. In the kernel system 1000, the data log unit 510 recommends using a default mode.

(3) Create DataLogFile: The name of the data file is automatically created by the DataLogFile object, and the naming template of the DataLogFile object needs to be used. There are two forms of named templates:

(3.1) System built-in template: root/<mmmdd>/<name><number>.<extension>,

Such as dlog/May21/dlog2.txt. Whenever a Session is opened, a new data file is created using the current date and the next sequence number. If it is the first data file of the day, number is 1.

root: specified by TextStorageManager.setRootDlogDirectory().

mmmdd: indicates the month and day, provided by the system, and the month is indicated by its English name.

name: specified by DataLogFile.setNameTemplate().

number: The serial number provided by the system.

extension: Optional, if an extension is specified when using the setNameTemplate() method.

(3.2) User-defined template: If the template provided by the kernel system 1000 is not suitable, the template can be customized. The custom template needs to create the LogFile in the core package and set the corresponding properties, and pass it as a constructor parameter when instantiating a DataLogFile object.

(4) Create a session:

(4.1) One or more CollectionSpecs: Added using the addToSpecs() method.

(4.2) A DataLogDestination object, and a reference to the StorageManager object to determine the file name and path of the data log file. If the data log directory of StorageManager is not set, the default directory is "current directory/dlog/"

(5) Enabling the data logging function: in the kernel system 1000, multiple Sessions may be open at the same time.

To open a session using the Session.open method, the following conditions must be met:

(5.1) The CollectionSpecs contained in the Session cannot be active, that is, they cannot be used;

(5.2) The associated DataLogDestination cannot be used already, that is, no other opened Session can be connected to this destination;

When a Session is opened, the Session is considered open ("open"), the CollectionSpecs contained in the Session are considered active ("active"), and the DataSpecs contained in the CollectionSpecs are considered locked ("locked")

When a conditional trigger occurs, the following data is written into the data log file: the record of the triggered condition and the time when the condition was triggered; the values of all DataItems in all DataSpecs contained in the corresponding CollectionSpec, and the DataItems involved in the triggering condition are not record unless it is contained in a DataSpec.

When the time interval is up (when the time interval trigger is triggered), the following data is written to the data log file: the time when the data was collected and the values of all DataItems in all DataSpecs contained in the corresponding CollectionSpec.

(6) Close the data logging function: use the Session.close method to close a session.

(7) Modify data log settings:

(7.1) If a DataSpec is locked, DataItems cannot be added to or removed from the DataSpec.

(7.2) If a CollectionSpec is active, DataSpecs cannot be added to or removed from this CollectionSpec. However, the time interval and data collection mode can be modified, and triggers can be added or removed.

(7.3) If a Session is already open, CollectionSpecs cannot be added or deleted, or the destination changed.

The system log unit 520 is configured to record call information and trace information of the kernel system 1000 at a second predetermined period. Syslog is a mechanism for general control kernel system 1000 that allows automatic generation of useful log information for debugging and performance tracking within a certain scope. These information mainly include information about ControlObject service invocation and completion, and related information when the value of a data item changes, when an interlock falls, when an alarm is issued or cleared. Developers can also insert self-defined log information into the system log unit 520, so as to record into log files during runtime.

The system log unit 520 allows users to obtain trace information already established in the general control kernel system 1000 , and can also additionally include and capture trace messages in the general control kernel system 1000 . When the syslog unit 520 executes, the captured messages are written to a destination (log file or common control kernel system console). The syslog unit 520 can provide a record of enabling or disabling certain types of logging information based on logging settings. These settings apply to each log destination and can be set at configuration time or modified at runtime.

Syslog unit 520 may be used in the development and post-development (use or production) phases of specific requirements control applications. During the development phase, syslog is a useful application debugging tool. During the post-runtime (after the application configuration process ends), system log messages are generally written to files instead of the console. The data collected by these log files will be used for diagnosis, debugging, and problem location and resolution. It is necessary to properly set the verbosity of different themes (for the default group) so as not to seriously affect system performance. Three stages can be considered: the general development stage, the development stage when configuration problems occur (because configuration is an important function of the application), and the production stage.

When kernel system 1000 starts up, all destinations set in the common control kernel system configuration file will be automatically activated for system logging. Also, two default files and an optional default log file are created and activated, and the console is set as an active destination.

The terms involved in the system log unit 520 are described below.

Archive protocol: The log file naming rules include attributes appendToExisting, template, sizeLimit, history, and defaultWildCard. The log file naming rules specify the file names of open files and how to open the next file after closing one file.

Wild cards: used for directory names and file names, except '%s' or '%S', which can only be used in the template file name part.

If the current file log has existing files log2 and log3, after closing the current file and opening a new file, the new file will be log, and the other files will be renamed log2, log3 and log4 in turn. If history is set to 4 at this time, the oldest log file log4 will be deleted. If the syslog unit 520 template is "logging/%y/%m/%d" and today is 2005-5-5, the first file opened is "logging/05/05/05".

Automatic disk writing attribute autoFlush: The automatic disk writing attribute autoFlush has nothing to do with the archive protocol, but it indicates whether the log information is written to the destination instead of temporarily stored in the memory buffer. If this property is set to true, the trace information will be written to the object file as soon as it is generated, instead of being written to the memory buffer.

Message filtering mechanism: Each message has a Topic, Verbosity and an associated Object. The message filtering mechanism uses the concepts of Topic, Verbosity and Group to filter trace information. The filtering mechanism can be represented by a matrix, where rows represent topics, columns represent groups, and matrix elements represent verbosities. When a trace message is generated, the column is first located, then the row (Topic), and finally the corresponding matrix element is located. The trace message is logged if it is within the severity level required to be logged, otherwise it is discarded.

The general control kernel system for integrated circuit manufacturing equipment provided by the embodiment of the present invention is based on Windows XP operating system, adopts JAVA to realize, has the following advantages:

1) Through the parallelism and resource interlocking of the management system, a unified interface is provided for different types of I/O in the application program, and a time-saving framework for error handling and error recovery, which solves the time-consuming and easy problems in the development of control application programs. wrong question.

2) Provide a powerful application programming interface that supports software interlocking, data logging, and communication functions. Specifically, the interlock API (Application Programming Interface, Application Programming Interface) of the general control kernel system of the embodiment of the present invention ensures the safety of personnel and equipment. Recipe API can store and retrieve process parameters. The data log API can quickly obtain the process parameter information at runtime.

3) Realize component development and software reuse through flexible configuration strategies. The common control kernel system configuration policy in the embodiment of the present invention can facilitate code reuse within the same application program and among different application programs. Also, the common control kernel system configuration file allows software developers to configure the properties of the components, although the above properties will be different in different applications, but without recompilation.

4) Provide necessary tools to support rapid development and debugging of applications. The general control kernel system of the embodiment of the present invention provides two powerful functions of application program debugging and performance tracking, including system log service and console interface, wherein the system log service includes generating system operation records, and the console interface includes View and modify the state of the common control kernel system environment while the application is running.

The general control kernel system of the embodiment of the present invention can enable developers to quickly develop robust control application programs, realize component development and software reuse through flexible configuration strategies, and can also provide necessary tools to support rapid development and debugging of application programs.

In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structure, material or characteristic is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

Although the embodiments of the present invention have been shown and described, those skilled in the art can understand that various changes, modifications and substitutions can be made to these embodiments without departing from the principle and spirit of the present invention. and modifications, the scope of the invention is defined by the appended claims and their equivalents.

Claims (19)

1. for a general controls kernel system for integrated circuit manufacturing equipment, comprising:

Configuration module, described configuration module is for when described kernel system starts, by object-instantiated and by the object registration after instantiation in name space, create initial name space tree construction, object in described initial name space tree construction is carried out to initialization, wherein, the behavior of described object map hardware device, wherein, described configuration module comprises: configuration file parsing module, registering unit and initialization unit, wherein, described configuration file parsing module analysis configuration file, according to object described in the information instances of described configuration file; Described registering unit for by the object registration of instantiation to name space, create initial name space tree construction, the set that described initial name space tree construction is a plurality of titles; Described initialization unit travels through described initial name space tree construction according to first search algorithm, and according to the information of described configuration file, the object after registering is carried out to initialization;

Control module, described control module controls for the initial name space tree construction creating according to configuration module the service that high-rise control module called and carried out low layer control module, wherein the grade of control object is followed successively by Physical layer from low to high, functional layer and operation layer, and described control object also comprises and described other maintenance level of operation layer ad eundem, wherein, described control module comprises: Physical layer control module, functional layer control module, operation layer control module and maintenance level control module, wherein, described Physical layer control module reads the data item of the underlying device in hardware device, and provide service to described underlying device, the service of described functional layer control module by calling described Physical layer control module is to provide the service of functional layer, the service of described operation layer control module by calling described functional layer control module is to provide the service of operation layer, carry out localization of fault and the repairing to described Physical layer control module and functional layer control module with described maintenance level control module, wherein, described maintenance level control module calls the service of described Physical layer control module and functional layer control module, with

Monitoring module, described monitoring module is for monitoring the condition of described kernel system and carry out independently corresponding action when condition meeting;

Alarm module, abnormal for occurring in described kernel system, send warning;

Log pattern, for record the information of described kernel system operational process with the form of daily record, wherein, described log pattern comprises: data logging unit and system journal unit, wherein, described data logging unit is for recording data and the event of described kernel system with the first predetermined period; With described system journal unit for record recalls information and the trace information of described kernel system with the second predetermined period.

2. general controls kernel system as claimed in claim 1, wherein, described registering unit is also for Making Alias, the corresponding one or more another names of a wherein said object.

3. general controls kernel system as claimed in claim 2, wherein, by one of following two kinds of modes access object:

1) title in name space tree construction is accessed object corresponding to described title by reference;

2) described by reference another name is accessed the object that described another name is corresponding.

4. general controls kernel system as claimed in claim 1, wherein, described Physical layer control module further comprises EPICS protocol communication parts, described EPICS protocol communication parts utilize EPICS agreement and hardware device to communicate with swap data item, comprise the state value that reads the underlying device in described hardware device, and send set-point to described hardware device.

5. general controls kernel system as claimed in claim 4, wherein, described data item is divided into discrete type, continuous type and character string type according to the type of carrying data;

Described data item is divided into read-only and read/write according to read/write operation type.

6. general controls kernel system as claimed in claim 5, wherein, utilize interlocking to check the value of described data item, interlocking comprises: set-point interlocking, only allows to revise imposing a condition while meeting for the data item of the described hardware device controlling the data item of the described hardware device reading or write.

7. general controls kernel system as claimed in claim 6, wherein, the interlocking of described set-point comprises:

The item that reads and writes data, described in the read and write data data item that hardware device reads described in Xiang Weicong or the data item writing from described hardware device; With

Check character, the modification of described check character for reading and writing data described in judging whether to allow;

Report to the police, described warning is used for when the modification of the item that reads and writes data described in rejection, and the block type of dishing out is reported to the police.

8. general controls kernel system as claimed in claim 7, wherein, described warning provides three to recover action: abandon, retry and continuation carry out.

9. general controls kernel system as claimed in claim 7, wherein, set-point interlocking also comprises and trigger is set and qualifier is set,

Described trigger is for arranging the condition reading and writing data described in modification, and described qualifier is for judging whether to verify the condition of described check character.

10. general controls kernel system as claimed in claim 1, wherein, described monitoring module is monitored the safe condition of described kernel system by value interlocking, and corrects when the unsafe condition of described kernel system triggers, and wherein said value interlocking comprises:

Trigger module, described trigger module arranges the unsafe condition of described kernel system;

Behavior list, described behavior list is for triggering the action after described unsafe condition, and wherein, when described behavior list comprises a plurality of action, described a plurality of actions are carried out one by one.

11. general controls kernel systems as claimed in claim 10, wherein, described value interlocking also comprises:

Report to the police, described warning is used for providing unblock formula to report to the police.

12. general controls kernel systems as claimed in claim 4, wherein, the service that described high-rise control module called and carried out low layer control module comprises the steps:

Described high-rise control module is locked or service lock to obtain server to the lock request of described low layer control module transmission server or service lock request, parameter to the service of request is carried out initialization, to described low layer control module, sends the request of operation lock to obtain operation lock;

Described high-rise control module, after obtaining described operation lock, calls and carries out the service that corresponding low layer control module is locked in described operation, and after service completes, discharges described operation lock;

Described high-rise control module discharges described server lock or service lock,

Wherein, the request of described server lock is used for asking to obtain described server lock, and described high-rise control module utilizes described server lock to call service to described low layer control module, and locks described low layer control module;

Described service lock request is used for asking to obtain described service lock, and described high-rise control module utilizes described service lock to call specified services to described low layer control module, and locking calling described specified services;

The request of described operation lock is used for asking to obtain described operation lock, and described high-rise control module utilizes described operation lock to carry out described specified services, and locks the execution of described specified services.

13. general controls kernel systems as claimed in claim 12, wherein, described low layer control module when receiving from the server lock request of described high-rise control module or service lock request,

If when current not active described server lock or service lock or operation lock, described low layer control module is authorized described high-rise control module server lock;

If current not active described server lock or service lock or operation lock, or the service that current service lock is carried out with the service lock of described service lock request is identical, and described low layer control module is authorized described high-rise control module service lock.

14. general controls kernel systems as claimed in claim 12, wherein, the service of described high-rise control module request is current not to be carried out, and while meeting following any condition, described low layer control module is authorized described high-rise control module operation lock,

1) there is no active server lock, service lock or operation lock;

2) only there is the active service lock of a service for current request;

3) the server lock that only has a described high-rise control module to have.

15. general controls kernel systems as claimed in claim 12, wherein, described low layer control module is placed on according to the sequencing arriving the request of server lock, service lock request or the request of operation lock that are not awarded server lock, service lock or operation lock in lock request waiting list.

16. general controls kernel systems as claimed in claim 15, wherein, described low layer control module discharges after described operation lock at described high-rise control module, checks described lock request waiting list,

If current high-rise control module keeps server lock, described low layer control module is carried out the service corresponding to next one operation lock request of current high-rise control module;

If current, keeping service lock, described low layer control module is carried out the service corresponding to next one operation lock request of service corresponding to described service lock;

If current, there is no active server lock, service lock or operation lock, and next request is the request of server lock, to this server lock request grant service device lock, and the operation lock of carrying out the high-rise control module that has this server lock is asked corresponding service;

If current, there is no active server lock, service lock or operation lock, and next request as service lock request, to this service lock request grant service lock, and carry out all high-rise control modules for service corresponding to this operation lock request;

If current, there is no active server lock, service lock or operation lock, and next request is the request of operation lock, described low layer control module is carried out service corresponding to described operation lock request.

17. general controls kernel systems as claimed in claim 1, wherein, described alarm module sends block type warning and unblock formula is reported to the police,

Described alarm module, after the described block type of dishing out is reported to the police, will block and send object place thread until remove described block type warning;

Described alarm module, after the described unblock formula of dishing out is reported to the police, sends object place thread and continues operation.

18. general controls kernel systems as claimed in claim 1, wherein, the log recording form that described data logging unit adopts comprises:

Time-based log recording, described time-based log recording triggers by one or more condition triggers;

Cycle log recording, described cycle log recording triggers by a time interval trigger.

19. general controls kernel systems as claimed in claim 1, wherein, the modification of data item described in described system journal unit record is, the information that the information of interlocking, described warning are sent and the information of removing described warning.

Images