Patent Application
20050060396
1. Field of Invention
The present invention primarily relates to a device diagnosis system for systematically controlling and executing the diagnosis of field devices located at different positions in a plant.
2. Description of the Prior Art
Symbol 4 denotes an intra-plant network, which is connected to higher-order FCS 3 and to which field devices to be controlled are connected so that the field devices communicate with FCS 3 and prescribed control is performed. Symbols 5A, 5B and 5C denote field devices from different vendors, where 5A indicates company A's valve, 5B indicates company B's valve and 5C indicates company C's valve.
In such a system configuration as described above, the environment in which valves SA, 5B and 5C are diagnosed differs from vendor to vendor. Specifically, 6A is a PC running company A's diagnostic software, which communicates with valve 5A through intra-plant network 4. 6B is a PC running company B's diagnostic software, which communicates with valve 5B through higher-order network 2, FCS 3 and intra-plant network 4. 6C is a PC running company C's diagnostic software, which communicates with valve 5C by means of communication by direct device access.
There are many types of diagnostic software, including an application that diagnoses devices themselves such as in the case of valves; an application that diagnoses clogging in the pressure lead pipe of a pressure transmitter; an application that constantly equalizes databases between different systems; an application that simultaneously monitors the statuses of two or more devices to watch for failures in the control loop; and an application that constantly monitors databases and, if it discovers a specific event, notifies the user accordingly.
Should any valve which is a field device fail, damage that would be inflicted on a plant would be enormous. It is therefore necessary to predict failure before it actually occurs and perform preventive maintenance. Thus, predictive diagnosis is performed according to the total operating time, the difference between the indicated stroke and actual stroke, and hysteresis.
Conventionally, software for executing these diagnoses has been provided on a vendor-by-vendor basis. In addition, as explained with reference to
Consequently, the user must not only separately verify diagnostic software programs that are running on two or more PCs but also use different methods of verification. Another drawback is that methods of notification when a failure is actually predicted/detected differ from each other. It has therefore been extremely cumbersome to systematically control these software programs.
The present invention has been developed to address these issues and one objective of the invention is to provide an environment whereby it is possible to systematically control and execute diagnosis for a variety of devices located at different positions in a plant.
Another objective of the present invention is to apply a client-server system configuration and provide an environment whereby it is possible to have access to information on device diagnosis being performed from PCs other than the PC that is actually performing the device diagnosis.
Preferred embodiments are described in detail below by referring to the accompanying drawings.
Symbol 7 denotes a database server, for which data necessary for diagnosing valves is constantly acquired and read from valves 5A. 5B and 5C using the functions of an external tool (not shown in the figure) and saved in the area of “data to be diagnosed.” Alternatively, equipment maintenance personnel or other persons save such data items by manually inputting them.
Symbol 8 denotes a client PC that is a component of a diagnosis execution unit comprising diagnostic software from different vendors. This client PC gains access to “data to be diagnosed” stored in the database server to execute diagnosis under the same environment.
Symbol 9 denotes an external network, such as the Internet, to which host system 1 is connected. Symbol 10 is another client PC connected to this network. The user can have access to the statuses of all diagnostic software running within the same system from any client PC. It is also possible to distribute the execution environments of two or more pieces of diagnostic software to two or more client PCs.
At the client PC functioning as a diagnosis execution unit, a common interface is provided for diagnostic software programs and actions to be taken in case of failure prediction/detection are standardized. Thus, it is possible to send e-mail notifications and issue work requests/instructions to an equipment control system or the like.
The block indicated by 13 and enclosed by a dashed line is a diagnosis execution unit comprising one or more than one client PC (PC1, PC2, . . . , PCn). Each client PC is provided with the functions of diagnostic scheduler 14 comprising one or more than one diagnostic program and a common interface.
This diagnostic scheduler function is a process executed as a Windows “service”. Within this process, each diagnostic software program runs as a thread. Specifically, the diagnostic scheduler provides the following common interface functions and operating environment to diagnostic software.
By using this common interface, it is possible for the diagnostic programs to run under a common environment without the need for newly creating diagnostic programs. Making this interface available makes it extremely easy for the user to arbitrarily select diagnostic software and configure a diagnostic system.
In addition, this scheduler function itself has no GUI functions and is controlled from a “diagnostic navigator” or “diagnostic tool” which is discussed later. For the purpose of load distribution this function is designed so that two or more units thereof can run concurrently within the same system.
The block indicated by 15 and enclosed with a dashed line is a human-machine interface and has functions provided by diagnostic navigator 16, as well as those provided by diagnostic tool 17 which is started from this diagnostic navigator. Diagnostic navigators NV1, NV2, . . . , NVn are created according to multiple client PCs (PC1, PC2, . . . , PCn).
Diagnostic navigator 16 is a Windows application for controlling diagnostic scheduler 14 and has the following functions:
Diagnostic navigator 16 monitors diagnostic software.
Diagnostic tool 17 executes Windows applications started from diagnostic navigator 16 and provides screens necessary for diagnosis. In addition, diagnostic tool 17 comprises diagnosis control unit 17a for displaying setup screens specific to each diagnostic software, and common control unit 17b for displaying screens common to all diagnostic software.
Common control unit 17b displays screens common to all diagnostic software, wherein the unit provides a screen for setting items related to the scheduling of diagnostic software and for setting actions to be taken if the diagnostic software detects any failures.
This screen indicates the names of five client PCs the names of diagnostic software to be executed, the names of devices under diagnosis, and their operating statuses. Diagnostic software can be selected to start or stop it.
According to the present invention all items of diagnostic data are incorporated in the database server for centralized management. Consequently, it is possible for diagnostic software to run on any computer and anywhere in the world by way of the external network, just as it runs on client PC 10 illustrated in
Since the system of the present invention has a client-server configuration, any client PC that is going to execute device diagnosis can access information on any device diagnosis being currently executed, from any location where the client PC has access to the server. Thus, access to the information can also be made from any PC other than the PC that is actually executing the device diagnosis.
Diagnostic software targeted for use in the present invention is of the type that performs the task of analyzing information (data to be diagnosed) that is stored in a database and of storing these analysis results in the database (diagnostic work area). Devices under diagnosis are not necessarily limited to such hardware components as field devices. Rather, the present invention may be applied to general applications where data needs to be constantly monitored.
In the embodiment illustrated in
In the embodiment illustrated in
As is evident from the description heretofore provided, according to the present invention, it is possible to easily realize an environment in which the diagnosis of a variety of devices located in different positions in a plant can be controlled and executed systematically.
In addition, by applying a client-server configuration, any client PC that is going to execute device diagnosis can be located in a desired place where the PC has access to the server. Thus, access can be made to information on the device diagnosis being currently executed, from any PC other than the PC that is actually executing the device diagnosis.
