Methods and devices for managing process control system tests
The integration of test procedures with process control routines in process control systems enables automated verification, reducing test time and errors by ensuring only unverified parts are tested during designated times, enhancing productivity and product quality.
Patent Information
- Application Number
- DE102010037159
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2009-08-26
- Filing Date
- 2010-08-25
- Publication Date
- 2025-11-06
- Estimated Expiration
- 2030-08-25
AI Technical Summary
Current process control systems require manual, time-consuming verification of process control routines, which can lead to inefficiencies and potential errors due to the independence of test procedures from control routines, lack of operator training, and the need for system shutdowns.
A method and apparatus that generate a test application from a process control routine, monitor its operation, and update the test application to indicate when tests have been executed, allowing for automated verification and optimization of test time by integrating test procedures with routine operations.
Automated verification of process control routines reduces test time and minimizes errors by ensuring only unverified parts of the routine are tested during designated times, improving productivity and product quality.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
AREA OF REVELATION
[0001] The present invention relates generally to process control systems and in particular to methods and devices for managing process control system tests. GENERAL STATE OF THE ART
[0002] Process control systems, such as those used in chemical, petroleum, or other processes, typically comprise one or more process controllers and input / output (I / O) devices that communicate with at least one host or operator workstation and one or more field devices via analog, digital, or combined analog-digital buses. The field devices, which may include valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, and flow sensors), perform process control functions within the process, such as opening or closing valves and measuring process control parameters.The process controllers receive signals indicating process measurements taken by the field devices, process this information to implement a control routine, and generate control signals that are sent to the field devices via buses or other communication lines to control process operation. In this way, the process controllers can execute and coordinate control strategies or routines using the field devices via the buses and / or other communication lines that connect the field devices.
[0003] Information from field devices and controllers can be made available to one or more applications (i.e., software routines, programs, etc.) executed by the operator workstation (e.g., a processor-based system) to enable an operator to perform desired functions related to the process, such as viewing the current process status (e.g., via a graphical user interface), evaluating the process, modifying process operation (e.g., via a visual object diagram), and so on. Many process control systems can include one or more application stations. These application stations are typically implemented using a personal computer, workstation, or similar device, which communicates with the controllers, operator workstations, and other systems within the process control system via a local area network (LAN).Each application station can execute one or more strategies, routines, or applications that perform campaign management functions, maintenance management functions, virtual control functions, diagnostic functions, real-time monitoring functions, safety-related functions, configuration functions, etc., within the process control system.
[0004] Process control systems typically implement strategies, routines, or applications that require regular testing to verify that these strategies, routines, or applications function as designed or specified. For example, an application involving a sensor and an actuator can be verified by changing a sensor input to cause the application to actuate the actuator. Applying simulated sensor input values to an application and / or applying simulated values to actuators may be sufficient to verify an application and save testing time, but it may not be sufficient to verify the actual, physical operation of the sensor and / or actuator.Currently, to verify an application or process control system, an operator must manually input data to sensors and record the positions of the corresponding actuators. This manual verification process can be time-consuming, as the operator can only perform one test at a time. Furthermore, the verification process may require shutting down the application or process control system, resulting in a loss of productivity.
[0005] US 2003 / 0046613A1 discloses a method for generating a test suite for testing computer software, comprising the following steps: running an existing test suite against the computer software and outputting a test recording; inputting the test recording into a test coverage tool and outputting a test coverage results file; inputting the test coverage results file into an automatic test generator; and generating a final test suite based on the test coverage results file.
[0006] DE 603 18 795 T2 discloses a method for setting up an optimized sequence of tests for testing integrated circuits (ICs), comprising the following steps: executing a first test sequence comprising a plurality of tests to test an initial plurality of ICs and generate a statistically significant test result that exhibits one or more test failures; analyzing the one or more test failures to identify one or more tests in the first test sequence that are inefficient compared to other tests in the first test sequence; and generating a second test sequence optimized for test efficiency with respect to the first test sequence by reordering the tests without removing any tests. The execution of the first test sequence does not cease if the one or more test failures of the initial plurality of ICs occur during the execution of the first test sequence. SUMMARY
[0007] The invention is defined by the subject matter of the independent claims. Advantageous embodiments are described in the dependent claims.
[0008] Exemplary methods and devices for managing process control system tests are described. In one example, a method includes generating a test application from a process control routine, wherein the test application comprises at least one test to be executed within a specified time period. The exemplary method further includes monitoring the operation of the process control routine, determining whether the operation of the process control routine during the time period includes the execution of a portion of the process control routine that is substantially similar to the at least one test, and updating the test application by indicating that the at least one test has been executed within the time period.
[0009] An exemplary apparatus comprises a routine monitor for monitoring the operation of a process control routine and a test application comparator for determining whether the operation of the process control routine during a period of time includes the execution of a portion of the process control routine that is substantially similar to the at least one test contained within a test application, wherein the at least one test must be performed within the period of time. The exemplary apparatus further comprises a test application modifier for updating the test application by indicating that the at least one test has been performed within the period of time. In some examples, the exemplary apparatus may also include a test application generator for generating a test application from the process control routine.
[0010] Preferably, the invention also includes a machine-accessible medium with instructions stored thereon which, when executed, cause a machine to: Generating a test application from a process control routine, wherein the test application includes at least one test to be performed within a time period; Monitoring the operation of the process control routine; Determine whether the operation of the process control routine during the period includes the execution of a part of the process control routine that is substantially similar to at least one test; and Updating the test application by displaying that at least one test has been performed within the time period.
[0011] Preferably, the machine-accessible instructions, when executed, can cause the machine to: Determine whether the execution of that part of the process control routine includes a correct mitigation of a problem associated with at least one test; and Indications after determining whether the execution of the part of the process control routine includes the correct reduction indicate that at least one test must be performed within a second period, the second period occurring after the first period.
[0012] Preferably, when executed, the machine-accessible instructions can also cause the machine to determine whether the correct mitigation includes a specified process control response to correct the problem within the process control system.
[0013] Preferably, the machine-accessible instructions, when executed, can also cause the machine to: Providing at least one test with a timestamp after determining the correct reduction; and Save at least one of the correct reductions, the timestamp of at least one test, or at least one test in a test log.
[0014] Preferably, the machine-accessible instructions, when executed, can further induce the machine to generate the test application from the process control routine, by at least one of: Determine at least one test limit based on at least one parameter within the process control routine; Ordering a sequence of at least one test based on a sequence of instructions within the process control routine; or Ordering the sequence of at least one test based on a type of function within the process control routine.
[0015] Preferably, the machine-accessible instructions, when executed, can also cause the machine to: Receiving a modification of the process control routine; Modifying the test application based on the modification; and Save the modified test application as a different version of the test application.
[0016] Preferably, the machine-accessible instructions, when executed, can also cause the machine to: Creating a test plan from the test application that includes at least one test; Requesting an operator to perform at least one test included in the test plan; Receive at least some of the data associated with the test plan or the test application; Determine whether the received data corresponds to a correct reduction of at least one test; and Update the test plan to show that at least one test has been verified for the period.
[0017] Preferably, the machine-accessible instructions, when executed, can further cause the machine to: Prompting the operator to enter an identification value; Receiving the identification value; Accessing a database of staff training certificates; Determine whether a training record corresponding to the identification value includes a statement that the user is authorized to execute the test plan; and Allow the operator to execute the test plan;
[0018] Preferably, the machine-accessible instructions, when executed, can ultimately cause the machine to: Combining test plan results with test application data to create a test protocol for the first period; The test protocol should be timestamped with the time at which at least one test was performed; Determine whether at least one test has been performed within the time period for the application associated with it; and Creating a notification that at least one test has not been carried out within the time period. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a block diagram illustrating an example process control system with an example test application manager. Fig. Figure 2 is a functional diagram of the example test application manager of Fig. 1. Fig. 3 represents the process control routine and the corresponding test application of Fig. 1 dar. Fig. Section 4 presents the exemplary test application of Fig. 3 and a test description table for an example test. Fig. 5 presents a verification history of the exemplary test TEST01L in Fig. 4 dar. Fig. Section 6 provides an exemplary operator training record for the process control system and / or the process control routine of Fig. 1 dar. Fig. 7, Fig. 8, Fig. 9A and Fig. 9B are flowcharts of exemplary procedures for implementing the exemplary test application manager, an exemplary test application generator, an exemplary test application modifier, an exemplary routine monitor, an exemplary test application comparator, an exemplary test execution checker and / or an exemplary test application processor of Fig. 1 and / or 2 can be used. Fig. Figure 10 is a block diagram of an exemplary processor system that can be used to implement the exemplary procedures and devices described herein. DETAILED DESCRIPTION
[0019] It should be noted that, although exemplary methods and devices are described below, which include, among other components, software and / or firmware executed on hardware, these examples are for illustrative purposes only and should not be considered limiting. For example, it is intended that any or all of the hardware, software, and firmware components could be implemented entirely in hardware, entirely in software, or in any combination of hardware and software. Therefore, although exemplary methods and devices are described below, it should be apparent to those skilled in the art that the examples provided do not represent the only possible implementation of these methods and devices.Although the exemplary methods and devices are described, for example, in connection with process control system tests, the exemplary method and device are more generally applicable and can be used to test and / or verify any automation systems, batch processing systems, manufacturing systems, industrial control systems, instrumented safety systems, etc.
[0020] Process control system designers typically implement control strategies, routines, algorithms, and / or applications for the operation of a process control system. Process control test designers can then create test procedures to test the process control system, at least partially, based on these control strategies, algorithms, routines, and / or applications. Thus, test designers create test procedures and system designers implement control routines. Consequently, process control systems usually include systems and / or routines that are independent of one or more corresponding test procedures. This independence can lead to a modification of a process control system and / or a process control routine that cannot be reflected in a corresponding test procedure, which in turn can result in the modification not being properly verified or verifiable by the test procedure.However, process control systems generally implement routines that require regular testing to verify that the routines function as designed or specified. Therefore, there is a possibility that the unverified modification might experience a higher problem and / or error rate than other, verified or verifiable parts of the strategy, routine, and / or application.
[0021] Furthermore, since process control routines and corresponding test procedures are often independent of each other, the test procedure is generally performed by a process control operator while the process control routine is interrupted. As mentioned earlier, to verify a process control system and / or a process control routine, an operator can manually input data to some field devices within the process control system and record the outputs of other corresponding field devices within the process control system. However, this manual verification process can be time-consuming, as the operator is only able to perform one test at a time (i.e., sequentially). Additionally, the verification process may require shutting down the process control system, which may not be feasible and / or could result in a loss of productivity.
[0022] Furthermore, any process control operator may attempt to verify one or more process control routines. However, in some cases, the operator may lack the appropriate training to perform the verification. An operator without proper training may perform a test improperly and / or record the test results incorrectly, resulting in unverified routines and / or process control field devices. Over time, avoidable errors may occur in the unverified routines or field devices, leading to a deterioration in product quality, process quality, and / or process interruption for error correction.
[0023] The exemplary methods and devices described herein combine process control routines and / or the operation of process control systems with corresponding test procedures to optimize the management of tests for the routines and / or process control systems. More specifically, the exemplary methods and devices described herein can generate a test procedure (e.g., a test application) from or based on process control strategies, routines, algorithms, and / or applications. In some examples, tests within the test application can be combined with and / or added to other tests in a test database based on a test type.
[0024] The exemplary procedures and devices can then monitor the strategies, routines, algorithms, and / or applications to determine whether an event occurs that substantially resembles one or more tests within the test application. If an event occurs that substantially resembles one or more tests, the exemplary procedures and devices determine whether the event was correctly mitigated. If the event was correctly mitigated by the process control system, the exemplary procedures and devices can subsequently update the test application by indicating that the one or more tests have been verified. By automatically updating the test application, the exemplary procedures and devices optimize test time by documenting which tests do not need to be verified because they have already been effectively verified during routine or normal operation of the process control system.
[0025] The exemplary methods and devices can determine, by comparing parameters, functions, and / or field devices associated with the event with parameters, functions, and / or field devices specified within one or more tests, that an event (e.g., the execution of part of a process control routine) is substantially similar to one or more tests. For example, a process control routine may include a parameter from a sensor corresponding to an input measured by the sensor that is part of a processing function. A test application may include a test that verifies the full input range (e.g., 0.5 to 35 bar) of the sensor. The test may be divided by partitioning the sensor's input range into a test for a low range of inputs (e.g., 0.5 bar to 10 bar) to the sensor and a test for high range inputs (e.g., 10 bar to 35 bar) to the sensor.During the execution of the process control routine, the sensor may receive an input (e.g., 2 bar) that falls within the sensor's low range. When such an input is received, the exemplary methods and apparatus can compare this event with the low-range sensor test. If the exemplary methods and apparatus then determine that there was a correct mitigation of the event (e.g., an increase in the input measured by the sensor) within the process control routine based on the sensor's low range, the low-range sensor test can be updated to reflect the execution of this test. The exemplary methods and apparatus can also indicate a next verification date for the low-range sensor test, where the next verification date can be based on a time increment (e.g., six months from a date of execution) that depends on the test type.
[0026] Correct mitigation of a process control event, a process control problem, and / or the execution of part of a process control routine may include a specified response for correcting the event and / or problem. For example, the aforementioned routine, with the appropriate sensor, may include an instruction to increase a pump speed by an amount that is a function of the low-range value of the sensor input. When the sensor receives an input corresponding to the low-range value, the exemplary procedures and devices can determine whether the routine increases the pump speed by an amount that is a function of the measured input.If the exemplary procedures and devices determine that the routine has correctly increased the pump speed, the procedures and devices can indicate that the event has been correctly mitigated and record the verification of the low-range sensor test.
[0027] Furthermore, since the exemplary procedures and devices combine a test application with a corresponding process control routine, changes or modifications made to the routine can be reflected within the test application after the modification has been implemented. Additionally, the exemplary procedures and devices can monitor test applications to determine if one or more tests are specified to be verified after a particular date. If, in the examples, one or more tests within a test application need to be verified after a specific date, the exemplary procedures and devices can generate a test plan to guide an operator through the verification process. The exemplary procedures and devices can receive any process control data related to the verification process and use this data as part of a test evidence for the test plan.
[0028] Furthermore, the exemplary procedures and devices can determine that an operator is properly trained to execute a given test plan. For example, an operator might log in to a process control system to execute a test plan. The exemplary procedures and devices can use an identification value provided by the operator to cross-reference a training record database to determine whether the operator is authorized to execute the training plan (e.g., has the permission or is qualified to do so). If the operator lacks the appropriate qualifications, the exemplary procedures and devices can provide the operator with a list and / or references to training that the operator can complete before executing the test plan.Accordingly, the exemplary procedures and devices can be used in a process control environment to structure operator training and / or configure training levels based on required training classes and / or exercises. Furthermore, by logging the identity of the operator executing a test plan, the exemplary procedures and devices provide a documentation system that can be used to identify and resolve future events and / or problems based on the identity of the operator who executed the test plan.
[0029] Fig. Figure 1 is a block diagram illustrating an example process control system 100 with an example test application manager 101. The test application manager 101 relates test operations to process control routines. In the example of Fig. In this example, the test application manager 101 generates a test application 103 from a process control routine 102. The process control routine 102 includes a visual object diagram 104 that can be displayed in a workstation 105 (e.g., an application station, an operator station, etc.). The workstation 105 is communicatively connected to a process controller 106 via a local area network (LAN) 108 (e.g., an application control network (ACN)). In this example, the test application manager 101 and the process control routine 102 are implemented in the workstation 105. Alternatively or additionally, the test application manager 101 and / or the process control routine 102 can be implemented in the controller 106 to manage, test, and / or execute process control routines or applications.
[0030] The Workstation 105 can be configured to perform operations associated with one or more information technology applications, user-interactive applications, and / or communication applications. For example, the Workstation 105 can be configured to perform operations associated with process control-related applications and communication applications, enabling the Workstation 105 and the Controller 106 to communicate with other devices or systems using any desired communication media (e.g., wireless, wired, etc.) and protocols (e.g., Hypertext Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP), etc.). The Workstation 105 can also be configured to create, manage, test, and / or modify process control processes via a graphical user interface using the parameters and / or functions of the Process Control Routine 102.The Workstation 105 can be used with any suitable computing or processing system (e.g., the P10 processor system from . Fig. 10) be implemented. For example, Workstation 105 could be implemented using a personal computer with a single processor, workstations with one or more processors, etc.
[0031] The LAN 108, which connects the workstation 105 to the controller 106, can be implemented using any desired communication media and protocols. For example, the LAN 108 can be based on a wired or wireless Ethernet communication scheme. However, any other suitable communication media and protocols could be used. Furthermore, although only a single LAN is shown, more than one LAN and suitable communication hardware can be used within the workstation 105 to provide redundant communication paths between the workstation 105 and any similar workstation (not shown).
[0032] In the exemplary process control system 100 of Fig. 1. Example: Workstation 105 enables a process control operator to view, modify, and / or test process control data processed by the controller 106. The controller 106 can execute one or more process control routines generated by a systems engineer or other systems personnel using workstation 105 or any other workstation, and downloaded and instantiated on the controller 106. The controller 106 can be, for example, a DeltaV™ controller distributed by Fisher-Rosemount Systems, Inc., an Emerson Process Management company. However, any other controller can be used instead. Furthermore, only one controller in Fig. As shown in Figure 1, additional controllers of any desired type or any desired combination of types can be connected to the LAN 108.
[0033] The controller 106 can be connected via a digital data bus 114 and an input / output (I / O) device 116 to a plurality of process control devices, including field devices 110a-b and a pump 112. During the execution of a process control routine, the controller 106 can exchange information (e.g., commands, configuration information, measurement information, status information, etc.) with the field devices 110a-b and the pump 112. This information can include parameters within process control routine functions. For example, the controller 106 can be equipped with a process control routine which, when executed by the controller 106, causes the controller 106 to send commands to the field devices 110a-b and the pump 112, which cause the field devices 110a-b and the pump 112 to perform specified operations (e.g., to take a measurement, open / close a valve, activate / deactivate, etc.) and / or transmit information (e.g.,The measurement data is transmitted to the controller 106 via the digital data bus 114. The workstation 105 can then access the information via the controller 106.
[0034] In the Fig. In the illustrated example 1, the process control routine 102 on the workstation 105 is configured to define properties and configuration information for controlling and / or connecting to the pump 112. The pump 112 can be controlled via the process control routine 102, which is implemented in and / or executed by the controller 106. Furthermore, the process control routine 102 defines properties and configuration information for controlling and / or connecting to the field devices 110a-b. The field devices 110a-b can be any type of process control device(s), including sensors or measuring instruments, actuators, etc., of any type. The field devices 110a-b can also include process control equipment such as tanks, vats, mixers, boilers, heaters, etc.
[0035] In the Fig. In the illustrated example, the field devices 110a-b are fieldbus-compatible devices configured to communicate via the digital data bus 114 using the widely known Foundation™ Fieldbus protocol. According to the Foundation™ Fieldbus protocol, the digital data bus 114 is a two-way, multipoint digital communication bus configured to communicate with measurement and control devices (e.g., devices 110a-b and 112). In the illustrated example, the I / O device 116 is implemented using an I / O subsystem interface, which enables the controller 106 and devices 110a-b and 112 to communicate with other field devices that can use the fieldbus protocol or other types of communication protocols (e.g., Profibus protocol, HART protocol, etc.).For example, the I / O device 116 can include one or more gateways that translate between the fieldbus protocol and one or more other communication protocols. Additional I / O devices (similar to or identical with the I / O device 116) can be connected to the controller 106 to enable additional groups of field devices to communicate with the controller 106.
[0036] The process control routine 102 can include a set of instructions to manage and / or operate the field devices 110a-b and 112 via the I / O device 116. The process control routine 102 can include process monitoring applications, alarm management applications, process trend and history applications, batch processing and / or campaign management applications, statistical applications, streaming video applications, advanced control applications, etc. The controller 106 can include the process control routine 102 to control and / or manage a process control routine. An operator of the workstation 105 can modify and / or view the process control routine 102 and / or data associated with the process control routine 102. For example, an operator using the workstation 105 can modify or access the process control routine 102 and / or data through the visual object program 104.
[0037] The visual object diagram 104 comprises interconnected function blocks that represent and / or encompass the process control routine 102 (e.g., process control strategies, logic, algorithms, applications, etc.). Each function block can be defined to define one or more process control functions and / or applications. For example, function blocks can receive inputs from a process control system, generate outputs for the process control system, calculate parameter values based on the process control inputs and / or other parameter values, monitor inputs and / or parameters, store inputs and / or parameter values, and / or compute control operations.
[0038] The visual object diagram 104 is a graphical representation of the process control routine 102. The functionality assigned to the function blocks is implemented as part of the process control routine 102 by the workstation 105 and / or the controller 106. Therefore, when a user accesses process control data and / or modifies one or more function blocks, the workstation 105 or the controller 106 coordinates the modifications between the visual object diagram 104 and the process control routine 102. In other implementations, the workstation 105 can translate a modified visual object diagram (e.g., the visual object diagram 104) into a modified process control routine 102 and store the modified process control routine 102 in the controller 106.
[0039] The function blocks within the visual object diagram 104 can be organized in a hierarchical structure with primary function blocks that are linked to other primary and / or secondary function blocks. Each of the secondary function blocks can further be linked to function blocks of a lower level, with each of the lower-level function blocks being linked to function blocks of an even deeper level, and so on.
[0040] In general, the exemplary test application manager 101 of Fig. Test application manager 101 accesses process control routine 102 to generate test application 103 and monitors process control routine 102 for events that might correspond to a test within test application 103. Test application manager 101 can access process control routine 102 within workstation 105 or, alternatively, via LAN 108 if process control routine 102 is implemented in controller 106 and test application manager 101 is implemented in workstation 105.
[0041] After the process control routine 102 has been created, the test application manager 101 can generate the corresponding test application 103. In other examples, the test application manager 101 can generate the test application 103 in response to an instruction from a process control operator or other personnel. The exemplary test application manager 101 can generate the test application 103 by accessing the visual object diagram 104 and creating individual tests based on the organization of the function blocks, the parameters assigned to the function blocks, parameter boundaries, and / or other functions (e.g., function types) of the function blocks.
[0042] For example, the visual object diagram 104 can include a function block that receives a parameter value from the field device 110a, determines whether the parameter value exceeds, falls below, and / or otherwise deviates from a threshold (e.g., a maximum value, a minimum value, a limit, etc.), and, if the parameter value deviates from the threshold, sends an instruction to another function block to correct the deviation (e.g., a process control problem resulting from the parameter value deviating from the threshold). The parameter value can be associated with an output from the field device 110a, which measures an environmental component of the process control system 100. In this case, the sample test application manager 101 can generate a test based on the parameter's threshold within the function block.Furthermore, the Test Application Manager 101 can generate tests based on an input measurement range of the field device 110a, an output measurement range of the field device 110a, and / or the function within the function block that generates the instruction based on the output from the field device 110a. Specifically, if the specified input measurement range of the field device 110a is 0.5 bar to 35 bar, the Test Application Manager 101 can generate a test to verify that the field device 110a can accurately measure inputs from 0.5 bar to 35 bar.
[0043] The exemplary test application 103 can be a test procedure or test plan comprising a sequence of tests for verifying the operational capability of the field devices 110ab, the pump 112, the I / O device 116, and / or the controller 106 within the process control system 100. Test application 103 can also include tests to verify that functions, algorithms, processes, and / or calculations in the process control routine 102 operate within specified standards. Each test within test application 103 can include subtests that more closely reflect actual possible events and / or problems of the process control system 100. For example, a test to verify the input range of field device 110a from 0.5 bar to 35 bar can be divided into a test to verify a lower input range (e.g., 0.5 bar to 2 bar) and a test to verify a higher input range (e.g., 33 bar to 35 bar).In this way, part of the test can be verified when the field device 110a receives a relatively low input value (e.g. 1 bar), and the other part of the test can be verified separately when the field device 110a receives a relatively high input value (e.g. 34 bar).
[0044] Furthermore, the exemplary test application 103 can be stored in a database and saved as a sequence of individual tests. Each test can include data fields corresponding to a test execution time (e.g., date, month, year, hours, minutes, and / or seconds) or data fields for storing evidence of a test. Evidence of a test can include process control data used to verify the process control routine 102 and / or process control data used to verify the components (e.g., the field devices 110a-b) within the process control system 100. For example, field device 110a can measure a value of 0.6 bar, which is used by the test application manager 101 to verify a low-input range test. The value 0.6 bar can be stored as evidence of the test in a data field. Additionally, a timestamp of the measurement of the value 0.6 bar and / or an identification value (e.g.,PT101) of the field device 110a will be included in a test verification data field.
[0045] Furthermore, in examples where the process control routine 102 is modified, the exemplary test application manager 101 recognizes the modified process control routine 102 and automatically updates the application 103 accordingly. The test application manager 101 can regularly check for modifications to the process control routine 102, or alternatively, it can receive a message from the process control routine 102 or any associated components within the workstation 105 indicating that the process control routine 102 has been modified. By automatically updating the test application 103 when the process control routine 102 is modified, the exemplary test application manager 101 ensures complete effective test coverage for the routine 102.
[0046] During operation, the exemplary test application manager 101 monitors the operation of the process control routine 102 for events, problems, and / or execution of parts of the process control routine 102 that may essentially resemble tests within the test application 103. In some examples, the test application manager 101 may monitor the communication between the controller 106 and the field devices 110a-b for events and / or problems. Alternatively or additionally, the test application manager 101 may monitor the routine 102 in the controller 106 and / or the workstation 105. By monitoring the process control routine 102, the test application manager 101 can determine that the normal operation of the process control system 100 can be used to verify the execution of one or more of the tests within the test application 103.Verifying tests during the normal operation of the process control system 100 can reduce the overall or general test time by ensuring that only tests corresponding to unverified parts of the process control routine 102 are performed by an operator during the designated verification times.
[0047] The exemplary test application manager 101 can determine whether an event, problem, and / or execution of a part of the process control routine 102 is substantially similar to a test within the test application 103 by providing parameters, field devices, functions, and / or function blocks associated with an event, problem, and / or execution of a part of the process control routine 102 with cross-references to information contained in the test and possibly used to generate the test. For example, the test to verify the input area of the field device 110a may contain an identifier of the field device (e.g.,PT101) 110a, an identifier and / or a link to a parameter associated with the input of field device 110a, a location within process control routine 102 corresponding to the input of field device 110a, and / or an identifier of a function block that receives the parameter associated with the input of field device 110a. The test application manager 101 can monitor process control routine 102 for incidents when routine 102 receives data from any of these identifiers. The test application manager 101 can then determine whether the received data is within the limits of the corresponding test. For example, an input of 10 bar to field device 110a may not be sufficient to verify the low-input range test of 0.5 bar to 2 bar.
[0048] After determining that an event, problem, and / or execution of a portion of the process control routine 102 substantially resembles a test within the test application 103, the test application manager 101 can determine whether correct mitigation of the problem and / or event has occurred. Correct mitigation includes a specified solution to correct the event and / or problem. Each test can include specified conditions for correct mitigation, or alternatively, the test application manager 101 can determine correct mitigation based on whether the process control routine 102 stops indicating the occurrence or presence of the problem and / or an error flag associated with the problem is deselected or disabled.If the Test Application Manager 101 determines that a correct mitigation for a problem has occurred, it can then update the test application by indicating that the corresponding test has been performed. The indication can include evidence of the test, a timestamp of when the test was performed, the mitigation that occurred, and / or the field devices associated with the problem. The Test Application Manager 101 can also determine a new time for the next test to be performed. For example, the Test Application Manager 101 can determine that a test should be performed every six months. Therefore, if a test is performed on May 13, 2009, the Test Application Manager 101 can determine that the next test date is November 13, 2009.
[0049] The exemplary test application manager 101 can also monitor the execution of tests within the test application 103 and send instructions to an operator to perform any tests with an upcoming and / or expired execution time (e.g., tests that were not performed within a specified or predetermined time period). Alternatively, the test application manager 101 can create a test plan or test procedure for tests to be performed by an operator at specified verification times. The test application manager 101 can filter tests to be included in the test plan based on which tests have already been performed during the normal operation of the process control system 100.
[0050] The exemplary test application manager 101 of Fig. Test Application Manager 101 can manage the execution of the test plan by guiding an operator through the test sequence and / or the individual steps involved in performing a test. Additionally, Test Application Manager 101 can prompt the operator to enter test results and / or test evidence and / or record the identification assigned to the operator performing the test. Furthermore, Test Application Manager 101 can allow an operator to enter test deviations and / or manually specify test results based on tests specified for such verification. Test Application Manager 101 can also filter the test plan to show which tests are optional or mandatory. Additionally, Test Application Manager 101 can display a priority for tests to be performed in the test plan, assigning a lower priority to tests that have already been performed.Additionally, the Test Application Manager 101 can receive process control data associated with the performed tests and enter the data into the corresponding test evidence data fields. Furthermore, the Test Application Manager 101 can combine the results or test evidence from tests performed by an operator with previously performed tests to create a log of tests performed within the Test Application 103. The Test Application Manager 101 can also update each test with a new verification time (e.g., a new period for performing the test).
[0051] The exemplary Test Application Manager 101 can also manage operator privileges for executing test plans and / or procedures. For example, Test Application Manager 101 can prompt an operator to enter an identification value before deploying a test plan. Test Application Manager 101 can then access a database to determine whether the operator is authorized to perform process control tests. The database can contain a training record for the operator, which might include, for example, an operator's training level, training classes completed by the operator, authorized tests assigned to the operator, authorized process control areas for the operator, training required to reach the next training levels and / or areas, and so on.Furthermore, Test Application Manager 101 can filter the tests in the test plan based on the tests the operator is authorized to perform. Thus, Test Application Manager 101 provides a framework for combining training credentials of process control operators with access to process control test procedures.
[0052] The exemplary process control system 100 serves to illustrate a type of system in which the exemplary methods and devices described in more detail below can be advantageously used. The exemplary methods and devices described herein can also be implemented in other systems of greater or lesser complexity than the one described in this document. Fig. 1. The process control system 100 shown and / or systems can be used advantageously in connection with process control activities, automation activities, industrial activities, business management activities, communication activities, security activities, etc.
[0053] Fig. Figure 2 is a functional diagram of the exemplary test application manager 1010 from Fig. 1. The Test Application Manager 101 includes function blocks for generating test applications, monitoring process control routines, updating test applications with executed tests, managing operator test execution, and / or combining operator training with access to test plans. Although the example Test Application Manager 101 includes function blocks configured to execute processes, the Test Application Manager 101 can combine function blocks or include additional function blocks. In some examples, the Test Application Manager 101 may be associated with a single process control system (e.g., Process Control System 100), while in other examples, the Test Application Manager 101 may manage the tests of multiple process control systems.
[0054] To generate test applications from a process control routine, the exemplary test application manager includes 101 of Fig. 2. A test application generator 202. The exemplary test application generator 202 can access a process control routine via a communication path 204 to generate a test application. The communication path 204 can comprise a wired and / or wireless communication path of any type that is communicatively connected to one or more process control routines.
[0055] The exemplary Test Application Generator 202 can generate a test application from a routine after the routine has been created. In other examples, the Test Application Generator 202 can generate a test application in response to an instruction from a process control operator. The Test Application Generator 202 can generate a test application from a routine by determining test boundaries based on parameters within the routine. Furthermore, the Test Application Generator 202 can order and / or sequence the tests within the test application based on the sequence, functions, and / or types of function blocks in a visual object diagram associated with a routine, and / or by the sequence and / or types of algorithms or processes contained in the routine.
[0056] Furthermore, the Test Application Generator 202 can use functions, equations, calculations, and / or algorithms defined within function blocks to define boundaries for the corresponding tests. For example, the Test Application Generator 202 can determine boundaries for a test based on specified values within an algorithm that can trigger certain events based on those specified values. The Test Application Generator 202 can also create subtests within tests in cases where an entire test cannot be executed and / or verified due to one or more events and / or problems within a specific timeframe. These cases can be defined by process control system designers and / or specified by algorithms used by the Test Application Generator 202 to generate test applications.
[0057] Furthermore, the test application generator 202 can include identifiers within each test in the test application, which can be cross-referenced to locations within the routine. The test application manager 101 can then (via a test application comparator 206) use each test's cross-references to a location in the routine to determine whether a problem or event handled by the routine is substantially similar to one or more tests.
[0058] After a test application has been created, the test application generator 202 can save the test application in a test database 208. The test database 208 can be implemented using electronically erasable and reprogrammable read-only memory (EEPROM), random access memory (RAM), read-only memory (ROM), and / or other memory types. Furthermore, operators can access test applications from workstations (e.g., the workstation 105) via a communication path 210 that is communicatively connected to the test database 208. The communication path 210 can be a wired and / or wireless communication path of any type.
[0059] The example test database 208 can store test applications and associated information, such as test verification data, the date the tests were performed, an operator identifier, the date for the next execution or verification of a test, and so on. Furthermore, test database 208 can store different versions of a test application, with each version potentially corresponding to a different version of a routine. Additionally, each test within a test application stored in test database 208 can be organized as a test sequence. In other examples, all tests within a test application can be stored as individual tests, which are then grouped according to the corresponding test application.Furthermore, the test database 208 can store test plans and / or procedures assigned to respective test applications, which can be created to guide an operator through the execution of any unperformed tests. Additionally, the test application generator 202 can access other tests within the test database 208 and add and / or combine these other tests with tests within a test application based on a test type.
[0060] To modify test applications based on modifications to corresponding process control routines, the exemplary test application manager 101 includes Fig. 2. A test application modifier 212. The exemplary test application modifier 212 receives a notification that a process control routine has been modified, accesses a corresponding test application in the test database 208, and / or modifies the test application based on the modified process control routine. Furthermore, the test application modifier 212 can save the modified test application as a different version than the unmodified test application. The exemplary test application modifier 212 can receive a notification of a modified process control routine via a communication path 214, which can be communicatively connected to a controller and / or a workstation. The communication path 214 can be implemented via a wired and / or wireless communication path of any type.
[0061] In alternative examples, the exemplary test application modifier 212 can monitor process control routines for modifications. Upon detecting one or more modifications, the test application modifier 212 can access the corresponding test application and make the necessary changes. The test application modifier 212 can modify a test application in the same way that the test application generator 202 uses function blocks, parameters, and / or any other routine information to construct the test application.
[0062] Furthermore, if the test application modifier 212 receives an instruction and / or indication from the test application comparator 206 that a test has been performed, the test application modifier 212 can access the test within the test application in the test database 208 and update the test to indicate that the test was successful. The test application modifier 212 can update the test by storing evidence of the test, a timestamp indicating when the test was performed, an operator identification value, the next scheduled time for the test, and / or any other information in one or more associated data fields to indicate that the test was performed.
[0063] For monitoring process control applications, the exemplary test application manager includes 101 of Fig. 2. A routine monitor 216. The exemplary routine monitor 216 monitors the operation of a process control routine, which may include events, problems, and / or executions of parts of the process control routine. In some examples, the routine monitor 216 may monitor the communication between the controller 206 and the field devices 110a-b via a communication path 218. Alternatively or additionally, the routine monitor 216 may monitor one or more routines within the controller 106 and / or the workstation 105 via the communication path 218. The communication path 218 may be a wired and / or wireless communication path of any type.
[0064] The exemplary routine monitor 216 can monitor a routine specifically for events and / or problems and then forward a display of these events and / or problems to the test application comparator 206. Alternatively, the routine monitor 216 can continuously or periodically monitor one or more routines for processing activity and forward any detected processing activity to the test application comparator 206. Furthermore, the routine monitor 216 can be instructed to monitor parts of a process control routine, which may include events that are substantially similar to a test in the test application. Additionally, the routine monitor 216 can monitor a process control routine for incidents of specific functional blocks, parameters, and / or parts of the process control routine that can be identified or used within a corresponding test application.In some examples, the routine monitor 216 can monitor a process control routine while it is running. In other examples, the routine monitor 216 can check the execution history of a process control routine.
[0065] Upon detecting a problem, an event, and / or the execution of a part of a process control routine, the exemplary routine monitor 216 forwards information or data associated with the problem, event, and / or execution of a part of the process control routine to the test application comparator 206. In other examples, the routine monitor 216 can forward an instruction to the test application comparator 206 containing the information or data associated with the event, problem, and / or execution of a part of a process control routine.
[0066] To determine whether an event, problem, and / or execution of part of a process control routine substantially resembles one or more tests, the exemplary Test Application Manager 101 includes Fig. 2 the Test Application Comparator 206. The exemplary Test Application Comparator 206 can determine, by providing parameters, field devices, functions and / or function blocks associated with the event, problem and / or execution of a part of the process control routine with cross-references to information contained in one or more tests, that a problem, event and / or execution of a part of a process control routine is substantially similar to one or more tests.
[0067] For example, the test application comparator 206 can receive event-associated information from the routine monitor 216, containing a parameter defined as OUT_01 with a parameter value of 2.4. The test application comparator 206 can cross-reference the parameter OUT_01 to a test that contains the parameter OUT_01. The test application comparator 206 can then use the parameter value to determine a subtest within the test that contains the parameter value 2.4. In other examples, the test application comparator 206 can receive a function from the routine monitor 216, which may contain a cross-reference to the same function used to set the boundaries for a test.Alternatively, the test application comparator can use 206 identifiers in each test that can refer to a location in a process control routine to determine whether an event and / or problem matches a test.
[0068] After determining that an event, problem, and / or execution of a part of the process control routine is substantially similar to a test within a test application, the Test Application Comparator 206 can determine whether correct mitigation of the problem, event, and / or part of the process control routine has occurred. The Test Application Comparator 206 can determine correct mitigation for a test by accessing a data field within the test that contains a specified correct mitigation operation. Alternatively, the Test Application Comparator 206 can access a database that contains lists of correct mitigations for each type of event, problem, and / or part of a process control routine.Furthermore, the Test Application Comparator 206 can determine that proper mitigation has occurred by monitoring a routine to determine whether an error flag has been reset and / or by determining whether the event and / or problem indicator is no longer active or present. If the Test Application Comparator 206 determines that proper mitigation did not occur, it does not update the test with information indicating that proper mitigation took place.
[0069] When the test application comparator 206 determines that correct mitigation has occurred for a problem, event, and / or part of the operation of a process control routine, the test application comparator 206 can send a notification to the test application modifier 212 to update the test application by indicating that the corresponding test was successfully performed. The notification can include evidence data of the test, a timestamp of when the test was performed, any mitigation that occurred, and / or the field devices associated with the problem or event. The test application comparator 206 can also determine a new time (e.g., a period) for the test to be performed and forward this new test time to the test application modifier 212. Alternatively, the test application comparator 206 can access the test database 208 to store the notification of test performance.
[0070] The exemplary test application comparator 206 can also receive process control data from a test execution verifier 220 and determine whether the data is associated with a correct mitigation and / or verification of the test. Based on parameter identifiers, field device identifiers, and / or function identifiers that may be contained in the data, the test application comparator 206 can also determine which tests can be associated with which data. In examples where an operator can perform one or more tests, the test application comparator 206 can receive process control data associated with the performed tests, determine which tests are associated with the data, and populate data fields for test verification and / or correct mitigation with the data.
[0071] Furthermore, the Test Application Comparator 206 can periodically check test applications to determine if any tests have expired or are about to expire with an execution time. If one or more tests are detected, the Test Application Comparator 206 can generate a test plan, test procedure, and / or work instruction for an operator to perform these tests before or at the execution time. Alternatively, the Test Application Comparator 206 can periodically generate a test plan and / or test procedure for the tests that are due to be performed within a specified time period.
[0072] The exemplary Test Application Comparator 206 can create a test plan by determining which tests are to be performed. The Test Application Comparator 206 can filter the tests based on the identifier of the operator who is to perform the test. Furthermore, the Test Application Comparator 206 can receive operator-entered verification data for a test and / or deviation test data and combine this data in the respective data fields of the corresponding test. In addition, if a test results in an error, the Test Application Comparator 206 can save a record of the error for the corresponding test in the test application and / or generate an error message for process control personnel to correct the error.
[0073] The exemplary test application comparator 206 can determine that one or more tests can be performed automatically by field devices (e.g., field devices 110a-b) that include a self-test and / or self-calibration function. In these examples, the test application comparator 206 can send instructions to these field devices to perform the self-tests. The test application comparator 206 can then receive the results from the field devices via the test execution checker 220, determine whether the results indicate a test pass, and enter the test results in the respective data fields of the corresponding test.
[0074] To manage the execution of a test plan and / or a test procedure, the sample Test Application Manager includes 101 of Fig. 2. A test application processor 224. The exemplary test application processor 224 can receive the test plan from the test application comparator 206 and request an operator to perform the tests contained in the test plan. The test application processor 224 can communicate with an operator via a communication path 226, which communicates with a workstation (e.g., workstation 5 of Fig. 1) is connected. The communication path 226 can include a wired and / or wireless communication path of any type.
[0075] The Test Application Processor 224 can also prompt the operator to enter an operator-assigned identification value. Upon receiving the operator's identification value, the Test Application Processor 224 can forward this identification value to the Test Application Comparator 206 to determine whether the operator is authorized to execute part and / or all of the test plan. After receiving the identification value, the Test Application Comparator 206 can access a Training Database 228, which contains operator training records, to determine the operator's training level and / or authorizations. The Training Database 228 can contain a training record for each operator.Each training record can include, for example, an operator's training level, training classes completed by an operator, authorized tests for an operator, authorized process control areas for an operator, training required to reach the next training level and / or area, etc.
[0076] The training database 228 can be implemented using EEPROM, RAM, ROM, and / or any other memory type. Furthermore, the records in the training database 228 can be updated by authorized process control personnel via a communication path 230, which can be any type of communication path (wired or wireless) connected to a workstation.
[0077] Based on the data in the training records, the Test Application Comparator 206 can filter the tests within the test plan that the operator is authorized to perform, and / or it can withhold the test plan from the operator if the operator is not authorized to perform any tests. After determining the tests that an operator is authorized to perform, the Test Application Comparator 206 forwards the test plan to the Test Application Processor 224 to guide the operator through the tests. The test plan can include information about which tests an operator can skip, which tests the operator can perform manually, which tests the operator can simulate, which tests can have variations in performance by the operator, and / or the order in which the tests are to be performed.This information can be generated by the test application generator 202 based on the corresponding routine and / or entered for each test by a process control system test engineer via communication path 210.
[0078] After receiving the test plan, the Test Application Processor 224 can guide the operator through the tests. For some tests, the Test Application Processor 224 can instruct the operator to enter process control data to simulate a test input for testing functions in a routine and / or outputs of field devices. The Test Application Processor 224 can forward this entered process control data to the Test Comparator 206 for storage in a data field associated with the test as evidence of the test. Additionally, the Test Application Processor 224 can request that process control data be measured and / or recorded by the operator. Upon receiving this process control data, the Test Application Processor 224 can forward this entered process control data to the Test Comparator 206 for storage in a data field associated with the test as evidence of the test.For example, to test an input area of the field device 110a from . Fig. 1. The test application processor 224 prompts an operator to perform a test that involves applying a known pressure to a read element of the field device 110a. The test application processor 224 can inform the operator of the specified pressure, prompt the operator to enter a value of the pressure applied to the field device 110a, and / or prompt the operator to enter a measured pressure value reported by the field device 110a. Alternatively, the test execution verifier 220 can receive the measured pressure value from the field device 110a and forward the value to the test application comparator 206 to combine it with the pressure applied to the field device 110a as proof of the test.
[0079] The exemplary test application processor 224 can include functions that allow an operator to simulate process control inputs and / or outputs to verify the operation of function blocks within a routine. Simulated inputs can also be used to verify the operation of field devices. The test application processor 224 can send the simulated values to the field devices via the communication path through the controller 106 and / or to the routine via the workstation 105.
[0080] Furthermore, the exemplary Test Application Processor 224 can timestamp data entered by an operator to record the time a test is performed. The Test Application Processor 224 can then include the timestamp in the test evidence data, which is forwarded to the Test Application Comparator 206. Additionally, the Test Application Processor 224 can forward self-test (e.g., self-test) instructions from the Test Application Comparator 206 to the appropriate field devices. In some examples, the Test Application Processor 224 can also provide operators with a list of training or tasks that the operator must complete to be authorized to execute a test plan.
[0081] To receive process control data associated with performed tests, the exemplary test application manager includes 101 of Fig. 2. The test execution tester 220. The exemplary test execution tester 220 can process control data by monitoring a routine and / or the LAN 108 of Fig. 1. Received via a communication path 222, which can be a wired and / or wireless communication path of any type. Alternatively, a process control routine, a workstation (e.g., workstation 105), and / or the controller 106 can send process control data to the test execution monitor 220.
[0082] The exemplary Test Execution Tester 220 can monitor process control data by identifying parameters sent by field devices and / or functions executed by a routine using identifiers assigned to those parameters and / or functions. For example, the Test Execution Tester 220 can include a list of parameter identifiers to be recognized by the routine. Each time the routine receives one of the listed parameters, the Test Execution Tester 220 can use an identification value of the parameter contained in the data to recognize the data associated with that parameter. Furthermore, by monitoring the portions of the routine associated with mitigation actions, the Test Execution Tester 220 can determine whether a routine correctly mitigated a problem.
[0083] The exemplary Test Execution Verifier 220 can receive process control data associated with tests, which can be used to automatically verify sections of a process control system. Alternatively, the Test Execution Verifier 220 can receive process control data associated with tests performed by an operator via the Test Application Processor 224. After receiving the process control data, the Test Execution Verifier 220 forwards the process control data to the Test Application Comparator 206.
[0084] Although an exemplary way of implementing the Test Application Manager 101 in Fig. As illustrated in point 2, one or more interfaces, data structures, elements, processes and / or devices that are in Fig. The elements shown in Figure 2 can be combined, split, rearranged, omitted, removed, and / or otherwise implemented. For example, the exemplary test application generator 202, the exemplary test application comparator 206, the exemplary test application modifier 212, the exemplary routine monitor 216, the exemplary test application processor 224, and the exemplary test execution checker 220, which are shown in Figure 2, can be combined, split, rearranged, omitted, removed, and / or otherwise implemented. Fig. 2 are shown, separately and / or in any combination, for example using machine-accessible or readable instructions, which are implemented by one or more computing devices and / or computing platforms (e.g. the exemplary processing platform P10 from Fig. 10) can be carried out.
[0085] Furthermore, the exemplary test application generator 202, the exemplary test application comparator 206, the exemplary test application modifier 212, the exemplary routine monitor 216, the exemplary test application processor 224, the exemplary test execution checker 220 and / or, more generally, the test application manager 101 can be implemented by hardware, software, firmware and / or any combination of hardware, software and / or firmware.Furthermore, any of the exemplary test application generator 202, the exemplary test application comparator 206, the exemplary test application modifier 212, the exemplary routine monitor 216, the exemplary test application processor 224, the exemplary test execution checker 220 and / or, more generally, the test application manager 101, may be implemented by one or more circuit(s), programmable processor(s), application-specific integrated circuits (ASIC(s)), programmable logic devices (PLD(s)) and / or user-programmable logic devices (FPLD(s)), etc.
[0086] Fig. 3 represents the visual object diagram 104 of the process control routine 102 and the corresponding test application 103 of Fig. 1. For brevity, visual object diagram 104 represents function blocks 302 to 308. In other examples, however, visual object diagram 104 may include additional function blocks connected by additional links. For example, a typical process control system may include dozens of interconnected function blocks linked by connections.
[0087] The example function blocks 302 to 308 are interconnected to implement a proportional-integral derivative (PID) feedback loop with an alarm. Function block 302 can include a PID control algorithm and / or a PID control routine to calculate an output based on an input value and a feedback value. The output value corresponds to an OUT parameter, the input value corresponds to an IN parameter, and the feedback value corresponds to a BKCAL_IN parameter within function block 302. The IN parameter of function block 302 is communicatively connected to an OUT parameter of function block 306 via connection 310.
[0088] Example function block 306 can receive a process control data value from one or more field devices and convert the received data into a parameterized value for PID1 function block 302. FT-101 function block 306 then sends the value via its OUT parameter to the IN parameter of PID1 function block 302. After calculating an output value, PID1 function block 302 outputs the output value via its OUT parameter through connection 312 to a CAS_IN parameter within function block 304. Example function block 304 can use the output value to calculate a control operation and / or a calibration value based on the received output value. FT-101 function block 304 can then send this control operation via an OUT parameter through connection 316 to an IN parameter within ALARM1 function block 308.Furthermore, the FY-101 function block 304 can send the calibration value via a BKCAL_OUT parameter over a connection 314 to a BKCAL_IN parameter within the ID1 function block 302.
[0089] The corresponding test application 103 can be generated from the visual object diagram 104 and / or the corresponding process control routine 102 via the test application generator 202. Fig. 2 will be generated. The exemplary test application 103 of Fig. Figure 3 illustrates example tests that correspond to and / or can be generated from function blocks 302 to 308, and their associated parameters. For example, TEST 01 can test the limits of the OUT parameter, which is received by and / or generated from the FT-101 function block. As shown in Fig. As shown in Figure 3, TEST 01 includes a next verification time (e.g., date) of December 22, 2009, indicating that the test should have been performed by that date. If the test has not been performed by the process control routine 102 by that date, the test application manager 101 can request an operator to perform the test. In another example, TEST 04 can be generated from a function executed by the PID1 function block 302. The function to be tested can include a combination of the BKCAL_IN and IN parameters in the PID1 function block 302 to generate the OUT parameter. In yet another example, TEST 10 can be generated to test the operation of an alarm via the IN parameter to the ALARM1 function block 308. This test can determine whether the alarm is triggered by sending the appropriate value to activate the alarm via the IN parameter.In some examples, the test application manager 101 can perform the TEST 10 by simulating an event that triggers an activation of the alarm.
[0090] The sample test application 103 includes fields for a test identifier, a test name, and the next verification (e.g., execution) time. In the example of Fig. In example 3, the tests are ordered by test ID. However, in other examples, the tests may be ordered by the next verification time and / or by test name. Alternatively, the tests may be ordered by test sequence. Furthermore, in other examples, the test application may include additional fields for test verification data, operator identification of an operator who performed a test, the time a test was last performed, etc. Additionally, the date (e.g., October 30, 2009) in the "Next Verification Time" data field is italicized to indicate that the deadlines for TEST 05 and TEST 07 are approaching.
[0091] Test application 103 can be implemented as a manager and / or processor of individual tests (e.g., TEST 01 - TEST 10). For example, test application 103 can determine if any tests have an execution or verification time that is about to expire. Furthermore, test application 103 can manage the storage and / or organization of test execution data, including test proof data, for each test. In other examples, test application 103 might include a table and / or a graph listing the tests associated with it.
[0092] Although the exemplary test application 103 of Fig. 3. While test application 103 comprises ten tests (e.g., TEST 01 to TEST 10), it can include additional tests that correspond to the visual object program 104 and / or the process control routine 102. For example, test application 103 can include tests to verify the operation of field devices 110a-b and / or pump 112. Fig. 1. Furthermore, in other examples where the visual object diagram 104 includes additional function blocks, the test application 103 may include additional tests corresponding to the additional function blocks.
[0093] Fig. Section 4 presents the exemplary test application 103 and a test description table 402 for the exemplary TEST 01 of Fig. 3. The sample test description table 402 can be included in the test application 103. For example, TEST 01 can include a link to the test description table 402. The sample test description table 402 contains fields for a test identification (e.g., TEST-ID), test limits (e.g., TEST), mitigation for each test (e.g., MITIGATION), and a next verification or execution time / date (e.g., NEXT VERIFICATION DATE). Additionally, the test description table can include further data fields for a mitigation value, test evidence, and / or the corresponding location of the test within a routine.
[0094] For example, the location of a test in a routine field can include a value that specifies a location in a routine substantially similar to the test. Alternatively, the location of a test in a routine field can include parameter and / or function identification values that reference functions and / or parameters within routine 102. Additionally, test description table 402 can include fields to indicate whether a test can be performed manually by an operator, fields to indicate whether a test can be optional, fields to indicate that a test can have a deviation, and / or fields to indicate a type of detected fault associated with a test.
[0095] The exemplary test description table 402 includes subtests of TEST 01. For example, TEST 01 can determine the limit of the OUT parameter of the FT101 function block 306 of Fig. 3. Test. The limits of the OUT parameter and TEST 01 can range from 21.7 to 25.2. During operation of the process control system 100 of Fig. However, only one side of the boundary can be tested at a time. Therefore, TEST 01 is divided into TEST 01H for testing the upper boundary of the range and TEST 01L for testing the lower boundary of the range.
[0096] The TEST 01H test can be specified to run if the OUT parameter deviates from the 25.2 threshold, and the Test Application Manager 101 determines that proper mitigation has occurred. In this case, proper mitigation includes sending or generating a problem indicator (e.g., INDICATOR 02) and reducing the value of the OUT parameter to below the 25.2 threshold within 60 seconds. Similarly, the TEST 01L test can be specified to run if the OUT parameter falls below the 21.7 threshold, and the Test Application Manager 101 determines that proper mitigation has occurred. In this case, proper mitigation includes sending or generating a problem indicator (e.g., INDICATOR 04) and increasing the value of the OUT parameter to above the 21.7 threshold within 60 seconds. Furthermore, TEST 01 includes a communication test (e.g.TEST 01N), which can test the communication between the controller 106 and the corresponding field device that can generate the OUT parameter.
[0097] The NEXT VERIFICATION DATE field indicates that each subtest can be performed independently and has a different execution time. However, the execution time of the TEST 01 test in test application 103 can reflect the nearest date (e.g., December 22, 2009). In addition to test boundaries, the TEST field can include function variables, test runtimes, test conditions, and / or any other test definition characteristics. For example, the TEST field for the TEST 04 test can include a definition of PID1 FUNCTION 1 with corresponding test boundaries. The test application manager 101 can use the identifiers (e.g. FT-101 and / or OUT) to cross-reference the TEST 01 test of routine 102 to determine whether an event, problem and / or part of an operation of routine 102 is substantially similar to the tests TEST 01H, TEST 01L and / or TEST 01N.
[0098] In scenarios where an operator is to perform a test, the Test Description Table can be used by the Test Application Manager 101 to create a test plan. For example, the information in the TEST field can define the runtimes of a test plan, and the information in the MITIGATION field can define the events that an operator must observe and / or record to determine whether the problem indicated by the test is mitigated or corrected. Additionally, each subtest (e.g., TEST 01H, TEST 01L, and / or TEST 01N) can be further subdivided into subtests, which can be displayed in separate Test Description Tables.
[0099] Fig. 5 presents an exemplary verification history table 502 of the exemplary TEST 01L from Fig. 4. The exemplary verification history table 502 can be found in the test description table 402 and / or the test application 103 of Fig. 4. Verification history table 502 represents the test execution history for a single test (e.g., TEST 01L). Other tests may include corresponding verification history tables.
[0100] The sample Verification History Table 502 includes fields for the time / date the test was performed (e.g., TESTDATE), the version of the test (e.g., TESTVERSION), the test type (e.g., TESTTYPE), the time at which the correct mitigation should occur (e.g., MITIGATIONTIME), the operator who performed the test (e.g., OPERATOR), and the next verification or performance date (NEXT VERIFICATION DATE). Additionally, Verification History Table 502 may include fields for test proof data, mitigation data, and / or any other test performance data.
[0101] The TESTVERSION field indicates a test version and / or a version of test application 103. For example, a test version VER. 2.0A can fall within the test range of 21.7 to 25.2 in Fig. 4 corresponds to, while a test version VER. 1.5A may correspond to a previous test limit range of 22.4 to 28.3. The TESTTYPE field includes a list of the test type performed. For example, a MANUAL test may correspond to a test performed by an operator, a PROCESS INTERNAL test may correspond to a test performed during operation of the process control system and / or process control routine, an AUTOMATIC test may correspond to a test performed by the Test Application Manager 101 while the process control system was stopped or interrupted, and / or the SIMULATION test may correspond to a test that used simulated test values instead of process control data to perform the test. In some examples, multiple test types may be performed.
[0102] Additionally, the REDUCE TIME field includes the time at which the correct reduction should occur. The OPERATOR field represents an operator's identifier for the operator who performed the test. In an example where the test may have been performed INTERNALLY, the operator could be an operator who supervised the process control system during an event and / or problem substantially similar to the test. The NEXT VERIFICATION DATE field in Verification History Table 502 represents the scheduled next test execution time based on the corresponding date in the TEST DATE field. For example, it may be specified that TEST 01L is to be performed every six months. Therefore, a test execution date of 05 / 15 / 2008 could have a next test execution time / date of 11 / 15 / 2008. The second line of the verification history table 502 shows that a MANUAL test was performed on an expiration date of 15.11.The fourth line indicates that a PROCESSINTERN test was performed on August 14, 2009, which was before the expiration date of November 15, 2009. Since the test took place while the process control system (e.g., PROCESSINTERN) was running, no operator was required to perform the test, and the test does not need to be performed again until February 14, 2010.
[0103] Fig. 6 provides an exemplary operator training certificate 602 for the process control system 100 and / or the process control routine 102 of Fig. 1. The sample operator training record 602 can be used by the test application manager 101 to determine whether an operator is authorized to perform one or more tests in a test plan. Additionally, the operator training record 602 can be used to continue, manage, and / or coordinate operator training for process control tasks. The sample operator training record 602 includes data fields for an operator identifier (e.g., OPERATOR ID), an operator's training level (e.g., TRAINING LEVEL), a date by which the operator must complete refresher training (e.g., RECERTIFICATION DATE), process control areas that an operator may be authorized to test and operate (e.g., AUTHORIZED PROCESS CONTROL AREAS), and uncompleted training classes (e.g., UNCOMPLETE ASSIGNED TRAINING).In addition, the operator training record 602 may include other fields such as an operator's job title, an operator's department level, previously completed training, and / or any other fields that may contain operator training information.
[0104] In examples where the Test Application Manager 101 determines that at least one test should be performed by an operator to ensure that the test is completed by an expiration time or date, the Test Application Manager 101 can create a test plan, prompt an operator to enter an identification value, and determine whether the identification value corresponds to a training level and / or authorized process control areas required to perform the tests in the test plan. For example, the Test Application Manager 101 can create a test plan for the PD1 routine of Fig. 3. Create. When operator GKL01 attempts to execute the test plan, Test Application Manager 101 determines that the PID1 routine is contained within the AUTHORIZED PROCESS CONTROL AREA. Alternatively, Test Application Manager 101 may determine that a test plan corresponds to a LEVEL 4 based on the types of tests in the test plan. Therefore, based on the individual operator training records within Operator Training Record 602, operators with a LEVEL 4 training level or higher (e.g., operators GKL01, EM02, and / or MN04) can execute the test plan. Test Application Manager 101 may determine a training level for a test plan based on the complexity of tests in the test plan or the process control areas assigned to the test plan, and / or a training level may be assigned by process control personnel.
[0105] Furthermore, the Operator Training Record 602 can be used to show operators the training courses they must complete to advance to the next higher training level and / or add another authorized process control area to their record. For example, operator EM02 can advance to training level LEVEL 5 by completing training classes or procedures PDM 202, PDM 203, and MEMS 432.
[0106] Fig. 7, Fig. 8, Fig. 9A and Fig. 9B are flowcharts of exemplary procedures for implementing the exemplary test application manager 101, the exemplary test application generator 202, the exemplary test application comparator 206, the exemplary test application modifier 212, the exemplary routine monitor 216, the exemplary test application processor 224 and / or the exemplary test execution checker 220 of Fig. 1 and / or 2 can be carried out. The exemplary procedures of 7, 8, 9A and / or 9B can be carried out by a processor, a controller and / or any other suitable processing devices. For example, the exemplary procedures of Fig. 7, Fig. 8, Fig. 9A and / or 9B may be implemented in coded instructions stored on any physical, computer-readable medium, such as flash memory, CD, DVD, floppy disk, ROM, RAM, programmable ROM (PROM), electronically programmable ROM (EPROM), electronically erasable PROM (EEPROM), optical storage disk, optical storage device, magnetic storage disk, magnetic storage device, and / or any other media that can be used to transport or store program code and / or instructions in the form of procedures or data structures and that can be accessed by a processor, general-purpose or specialized computer, or other machine with a processor (e.g., the exemplary processor platform P10, which is referred to below in conjunction with Fig. (as described in section 10) can be accessed. Combinations of the aforementioned also fall within the scope of computer-readable media.
[0107] The procedures include, for example, instructions and / or data that cause a processor, a general-purpose computer, a specialized computer, or a specialized processing machine to implement one or more specific procedures. Alternatively, some or all of the exemplary procedures from Fig. 7, Fig. 8, Fig. 9A and / or 9B can be implemented using any combination(s) of ASIC(s), PLD(s), FPLD(s), discrete logic, hardware, firmware, etc.
[0108] Furthermore, some or all of the exemplary procedures can be described by Fig. 7, Fig. 8, Fig. 9A and / or 9B can instead be implemented using manual procedures or as any combination of any of the aforementioned techniques, for example, any combination(s) of firmware, software, discrete logic, and / or hardware. Furthermore, many other methods can be used to implement the exemplary operations of Fig. 7, Fig. 8, Fig. 9A and / or 9B can be used. For example, the order in which the blocks are executed can be changed, and / or one or more of the described blocks can be modified, removed, subdivided, or combined. Furthermore, any or all of the exemplary procedures from Fig. 7, Fig. 8, Fig. 9A and / or 9B can be performed sequentially and / or in parallel, for example by separate processing threads, processors, devices, discrete logic, circuits, etc.
[0109] The exemplary procedure 700 of Fig. Example 7 updates test applications based on correct mitigations of problems and / or events that may occur during the operation of a process control system. Multiple Example Procedures 700 can be executed in parallel or sequentially to update multiple test applications associated with specific routines. Furthermore, in examples where multiple routines can control a single process control system, an Example Procedure 700 can be implemented for each routine, or alternatively, a single Example Procedure 700 can be implemented for the process control system.
[0110] The exemplary procedure 700 of Fig. Procedure 7 begins by receiving a selection of a process control routine (block 702). The selection can be made by an operator, and / or it can be made after a process control routine has been created. Next, the exemplary procedure 700 generates a test application from the selected process control routine (block 704) and stores the test application in the test database 208. Fig. 2 (Block 706). The exemplary procedure 700 then monitors the selected process control routine (Block 708). In some examples, some time may elapse between the creation of the test application and the monitoring of the routine. For example, the routine might not be monitored until the process control system is commissioned or operational.
[0111] Exemplary Procedure 700 continues by determining whether a portion of the operation of the process control routine substantially resembles one or more tests in the test application (Block 710). Exemplary Procedure 700 may also determine whether an event and / or problem substantially resembles a test within the test application. If no portion of the operation of the routine substantially resembles at least one test, Exemplary Procedure 700 continues by monitoring the process control routine (Block 708). However, if a portion of the operation of the routine substantially resembles at least one test, Exemplary Procedure 700 determines whether proper mitigation of that portion of the operation of the routine has occurred (Block 712). Proper mitigation may include one or more measures implemented by the process control routine to cause the at least one test to be within specified threshold(s).Even if part of the operation of the routine is substantially similar to at least one test, Exemplary Procedure 700 may also monitor the process control routine for other parts of the routine, events and / or problems (Block 708) that may be substantially similar to other tests (not shown).
[0112] If Exemplary Procedure 700 determines that no correct reduction has occurred within the process control system and / or routine, Exemplary Procedure 700 does not update the test application (Block 716) but continues monitoring the process control routine (Block 708). However, if Exemplary Procedure 700 determines that a correct reduction has occurred within the process control system and / or routine, Exemplary Procedure 700 determines whether an operator was authorized to perform the reduction (Block 714).
[0113] In examples where the routine and / or process control system automatically performs the correct reduction without operator assistance, Exemplary Procedure 700 continues by updating the test application with information associated with the execution of the test (e.g., test verification information) (Block 718). Similarly, Exemplary Procedure updates the test application (Block 718) if an operator was authorized to perform the reduction. However, in examples where Exemplary Procedure 700 determines that an operator was not authorized to perform the reduction, Procedure 700 does not update the test application (Block 716) but continues monitoring the process control routine (Block 718).
[0114] Alternatively, in some examples where an operator was not authorized to perform the mitigation, Exemplary Procedure 700 may request an authorized operator to verify the work of the other, unauthorized operator. Exemplary Procedure 700 may determine whether an operator is authorized to perform mitigation of an event and / or problem by referring to appropriate operator training records in Training Database 228. Fig. 2 accesses.
[0115] Example Procedure 700 continues after the test application is updated by determining a new time (e.g., a period for the test to be performed) (Block 720). For example, in cases where a test is to be performed every six months, Example Procedure 700 can set the new time to a date and / or a time six months after the current date. Example Procedure 700 then saves the new time for the test (Block 722) and continues monitoring the process control routine (Block 708). Example Procedure 700 can be terminated by an operator, and / or it can terminate when the process control routine and / or the process control system is stopped.
[0116] The exemplary procedure 710 of Fig. 8 determines whether part of the operation of the process control routine of Fig. 7 is substantially similar to at least one test in the test application. Exemplary procedure 710 represents a detailed process of exemplary procedure 700 during the execution of block 710 in Fig. 7. The exemplary procedure 710 of Fig. Procedure 8 begins by receiving a notification that a parameter, algorithm, function, and / or calculation deviated from within a limit and / or triggered an error detection in the process control system during the operation of the process control routine (Block 802). In other examples, Exemplary Procedure 710 can receive a notification of any activity associated with the routine.
[0117] Exemplary Procedure 710 then accesses the test application in test database 208 (Block 804). Next, Exemplary Procedure 710 determines whether the parameter, algorithm, function, and / or computation contained within one or more tests is part of the test application (Block 806). Exemplary Procedure 710 can determine whether the parameter, algorithm, function, and / or computation is contained within one or more tests by cross-referencing identifiers associated with the parameter, algorithm, function, and / or computation to runtimes, variables, and / or boundaries within the tests. Alternatively, Exemplary Procedure 710 can determine whether one or more of the tests include a reference to a location within the routine that corresponds to the parameter, algorithm, function, and / or computation.
[0118] If Exemplary Procedure 710 is unable to determine that at least one test matches the parameter, algorithm, function, and / or computation, Exemplary Procedure 710 continues monitoring the process control routine (Block 708 of Fig. 7) However, if Exemplary Procedure 700 determines that at least one test corresponds to the parameter, algorithm, function and / or computation, Exemplary Procedure determines which of the test(s) corresponds to the parameter, algorithm, function and / or computation that deviated from within the limit or triggered the error (Block 808).
[0119] Exemplary Procedure 710 then determines whether the limit deviation and / or detected fault is within or exceeds the limit(s) of the relevant test(s) (Block 810). For example, Exemplary Procedure 710 may determine that a field device received an input of 4 bar, which deviates from within a process function limit of 5 bar. However, if the test applies to inputs from 0.5 bar to 2 bar, the parameter value of 4 bar does not deviate from the test limit, and Exemplary Procedure 710 does not update the test as passed. In another example, if the field device receives an input of 2 bar, which deviates from within a process routine function limit of 5 bar, Exemplary Procedure 710 indicates that the test is substantially similar to the event because the parameter value also deviates from the test limit of 2.5 bar.After determining that the limit or error was the same as or different from the limit(s) of the relevant test(s), Exemplary Procedure 710 continues by indicating that a portion of the operation of the process control routine is substantially similar to at least one test in the test application (Block 812). Exemplary Procedure 710 then terminates.
[0120] The exemplary procedure 900 of Fig. 9A and Fig. 9B manages the execution of tests by a process control operator. Multiple Exemplary Procedures 900 can be executed in parallel or sequentially to update multiple test applications, each assigned to a specific routine. Additionally, in examples where multiple routines can control a single process control system, an Exemplary Procedure 900 can be implemented for each routine, or alternatively, a single Exemplary Procedure 800 can be implemented for the process control system. Furthermore, Exemplary Procedure 900 can be executed for each operator performing a test within the test application.
[0121] The exemplary procedure 900 of Fig. Procedure 9A begins by receiving a selection of a process control routine (block 902). The process control routine can be selected by an operator who has tests to perform that have expired and / or have test execution times that are about to expire. Exemplary Procedure 900 then generates a test application from the selected process control routine (block 904) and determines that at least one test should be performed in the test application (block 906). Exemplary Procedure 900 can determine that at least one test should be performed by determining whether any tests have an upcoming or expired verification time and / or execution time. If Exemplary Procedure 900 determines that there are no tests to be performed by an operator, Exemplary Procedure 900 terminates.
[0122] However, if Exemplary Procedure 900 determines that at least one test must be performed by an operator, Exemplary Procedure 900 creates a test plan, a test procedure, and / or a work instruction (Block 908). Next, Exemplary Procedure 900 may prompt an operator to provide identification (Block 910). Exemplary Procedure 900 may then receive the identification associated with the operator and determine whether the operator is authorized to process and / or execute the test plan (Block 912). Exemplary Procedure 900 may determine the operator's authorization by accessing the operator's training record. If the operator is not authorized to execute the test plan, Exemplary Procedure 900 may prompt the operator to find an authorized operator to execute the test plan (Block 914) and then prompt the authorized operator for identification (Block 910).Alternatively, the exemplary procedure 900 can filter the test plan and allow the operator to perform tests within the test plan that the operator is authorized to perform.
[0123] If the operator is authorized to execute the test plan (block 912), Exemplary Procedure 900 proceeds by prompting the operator to execute the test plan (block 916). In some examples, Exemplary Procedure 900 may manage the execution of the test plan to ensure that the operator follows a defined test sequence and / or to ensure that the operator performs each test correctly. Additionally, Exemplary Procedure 900 may prompt the operator to enter test verification data.
[0124] Next, the exemplary procedure of Fig. 9B continues by receiving data from the process control system corresponding to the tests performed by the operator (Block 918). The received data may be detected during the operation of the routine, entered by the operator, and / or provided directly by field devices and / or a controller within the process control system. Exemplary Procedure 900 then determines whether the received data corresponds to a correct reduction of at least one test in the test plan (Block 920).
[0125] Exemplary Procedure 900 can determine whether the received data corresponds to a correct reduction by cross-referencing the data and / or the identifiers associated with the data to a "Correct Reduction" field assigned to each of the tests. If the data does not correspond to a correct reduction, Exemplary Procedure 900 can continue receiving data from the process control system (Block 918). Exemplary Procedure 900 can also continue receiving data from the process control system (Block 918) even if the data corresponds to a correct reduction. If the data corresponds to a correct reduction, Exemplary Procedure 900 also determines which test(s) correspond to the data and updates the test plan to indicate that the corresponding test(s) has been performed (e.g., that the portion of the process routine has been verified) (Block 922).The display can include test verification information, a time at which a test was performed, the identification value of the operator who performed the test, the results of the correct reduction, etc.
[0126] The exemplary procedure 900 of Fig. 9B continues by determining if there are any additional tests in the test plan that were not performed by the operator (Block 924). If there are additional tests, Exemplary Procedure 900 continues by receiving data from the process control system (Block 918). However, if no additional tests are to be performed, Exemplary Procedure 900 updates the test application with information associated with the test(s) performed (Block 926). Exemplary Procedure 900 may then determine a new test execution date for each test performed (Block 928). The exemplary procedure then saves the new test execution date for each test in the test application (Block 930), and Exemplary Procedure 900 terminates.
[0127] Fig. Figure 10 is a block diagram of an exemplary processor system P10 that can be used to implement the exemplary methods and devices described herein. For example, processor systems similar to or identical with the exemplary processor system P10 can be used to implement the exemplary test application manager 101, the exemplary test application generator 202, the exemplary test application comparator 206, the exemplary test application modifier 212, the exemplary test application processor 224, and / or the exemplary test execution verifier 220. Fig. 1 and / or 2 are used. Although the exemplary processor system P10 is described below as including a plurality of peripherals, interfaces, chips, memories, etc., one or more of these elements may be omitted by other exemplary processor systems used to implement one or more of the exemplary test application manager 101, the exemplary test application generator 202, the exemplary test application comparator 206, the exemplary test application modifier 212, the exemplary test application processor 224, and / or the exemplary test execution verifier 220.
[0128] As in Fig. As shown in Figure 10, the processor system P10 comprises a processor P12, which is connected to a connection bus P14. The processor P12 includes a register set or register space P16, which is located in Fig. Figure 10 is shown to be fully integrated on the chip, but alternatively, it could also be located wholly or partially outside the chip and be directly connected to the processor P12 via dedicated electrical connections and / or the connection bus P14. The processor P12 can be any suitable processor or microprocessor or any suitable processing unit. Although in Fig. If not shown, system P10 can be a multiprocessor system and therefore include one or more additional processors that are identical to or similar to processor P12 and are communicatively connected to the connection bus P14.
[0129] The P12 processor from Fig. 10 is connected to a chipset P18, which includes a memory controller P20 and a peripheral input / output (I / O) controller P22. As is generally known, a chipset typically provides I / O and memory management functions, as well as a plurality of general-purpose and / or special-purpose registers, timers, etc., which can be accessed or used by one or more processors connected to the chipset P18. The memory controller P20 performs functions that enable the processor P12 (or processors, if there are multiple processors) to access the system memory P24 and a mass storage device P25.
[0130] System memory P24 can include any desired type of volatile and / or non-volatile memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. Mass storage P25 can include mass storage of any desired type. For example, if the example processor system P10 is used to implement the test application manager 101 ( Fig. 2) If used, the mass storage device P25 can comprise a hard disk storage device, an optical storage device, a tape storage device, etc. Alternatively, if the exemplary processor system P10 is used to implement the test database 208 and / or the training database 228, the mass storage device P25 can comprise solid-state storage (e.g., flash memory, RAM, etc.), magnetic storage (e.g., a hard disk), or any other storage suitable for mass storage in the test database 208 and / or the training database 228.
[0131] The peripheral I / O controller P22 performs functions that enable the processor P12 to communicate with peripheral input / output (I / O) devices P26 and P28 and a network interface P30 via a peripheral I / O bus P32. The I / O devices P26 and P28 can be any desired type, such as a keyboard, a display (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT) display, etc.), or a navigation device (e.g., a mouse, a trackball, a capacitive touchpad, a joystick, etc.). The network interface P30 can be, for example, an Ethernet device, an asynchronous transmission mode (ATM) device, an 802.11 device, a DSL modem, a cable modem, a cellular modem, etc., enabling the processor system P10 to communicate with another processor system.
[0132] Although the memory controller P20 and the I / O controller P22 are in Fig.10 are represented as separate functional blocks within the P18 chipset; the functions performed by these blocks can be integrated into a single semiconductor circuit, or they can be implemented using two or more integrated circuits.
[0133] At least some of the aforementioned methods and / or devices are implemented by one or more software and / or firmware programs running on a computer processor. However, dedicated hardware implementations include, but are not limited to, application-specific integrated circuits, programmable logic arrays, and other hardware devices that may also be configured to implement some or all of the exemplary methods and / or devices described herein, in whole or in part. Furthermore, alternative software implementations, including but not limited to distributed processing or component / object distributed processing, parallel processing, or virtual machine processing, may be configured to implement the exemplary methods and / or systems described herein.
[0134] It should be noted that the exemplary software and / or firmware implementations described herein are stored on a physical storage medium, such as a magnetic medium (e.g., a magnetic disk or magnetic tape); a magneto-optical or optical medium, such as an optical disc; or a solid-state medium, such as a memory card, or other packaging containing one or more (non-volatile) read-only memories, random-access memories, or other rewritable (volatile) memories. Accordingly, the software and / or firmware described herein can be stored on a physical storage medium such as the storage media described above or successor models thereof.It is understood that, insofar as the foregoing specification describes exemplary components and functions with respect to certain standards and protocols, the scope of this patent is not limited to those standards and protocols. For example, all standards for internet and other packet-switched network transmission (e.g., Transmission Control Protocol (TCP) / Internet Protocol (IP), User Datagram Protocol (UDP) / IP, HyperText Markup Language (HTML), HyperText Transfer Protocol (HTTP)) represent examples of the current state of the art. These standards are regularly superseded by faster or more efficient equivalents with the same general functionality. Accordingly, replacement standards and protocols with the same functions are equivalents provided for by this patent and are included within the scope of the accompanying claims.
[0135] It should be noted that, although this patent discloses exemplary methods and devices comprising software or firmware executed on hardware, these systems serve only for illustration and should not be considered limiting. For example, it is intended that any or all of the hardware and software components could be implemented entirely in hardware, entirely in software, entirely in firmware, or in some combination of hardware, firmware, and / or software. Accordingly, although the foregoing specification described exemplary methods, systems, and machine-accessible media, these examples are not the only possible implementations of these systems, methods, and machine-accessible media. Therefore, although certain exemplary methods, systems, and machine-accessible media have been described herein, the scope of this patent is not limited to them.On the contrary, this patent covers all methods, systems and machine-accessible media that fall entirely within the scope of the attached claims, either literally or according to the equivalence doctrine.
Claims
A method for managing process control system tests for a process control system (100), comprising: - executing a process control routine (102) during normal operation of the process control system (100); - generating a test application (103) from the process control routine (102), wherein the test application (103) comprises at least one test to be performed within a period of time; - monitoring the operation of the process control routine (102) during the period of time; - determining whether the operation of the process control routine (102) during the period of time includes the execution of a part of the process control routine (102) that is substantially similar to the at least one test, by comparing the part of the process control routine with the test with respect to associated parameters, functions and / or field devices;and- updating the test application (103) by indicating that the at least one test has been performed within the time period when it is determined that the operation of the process control routine (102) includes the execution of the part of the process control routine (102) that is substantially similar to the at least one test;- determining whether the execution of the part of the process control routine (102) includes a correct mitigation of a problem associated with the at least one test, wherein the correct mitigation includes a specified process control response to correct the problem within the process control system (100); and- indicating, after determining that the execution of the part of the process control routine (102) includes the correct mitigation, that the at least one test has been verified and is to be performed again within a second time period, the second time period occurring after the first time period.; The method of claim 1, further comprising: - providing the at least one test with a timestamp after determining the correct reduction; and - storing at least one of the correct reduction, the timestamp of the at least one test or the at least one test in a test protocol. The method of claim 1, wherein generating the test application (103) from the process control routine (102) comprises at least one of: - determining at least one test boundary based on at least one parameter within the process control routine (102); - ordering a sequence of the at least one test based on a sequence of instructions within the process control routine (102); or - ordering the sequence of the at least one test based on a type of function within the process control routine (102). The method of claim 1, further comprising: - receiving a modification to the process control routine (102); - modifying the test application (103) based on the modification; and - storing the modified test application as another version of the test application (103). The method of claim 1, further comprising: - creating a test plan from the test application (103) comprising the at least one test; - prompting an operator to perform the at least one test included in the test plan; - receiving at least some of the data associated with the test plan or with the test application (103); - determining whether the received data corresponds to a correct reduction of the at least one test; and - updating the test plan to indicate that the at least one test has been verified for the period. The method of claim 5, further comprising: - prompting the operator to enter an identification value; - receiving the identification value; - accessing a database of personnel training records; - determining whether a training record corresponding to the identification value includes a statement that the user is authorized to execute the test plan; and - allowing the operator to execute the test plan. The method of claim 5, further comprising: - combining results of the test plan with the test application (103) to create a test log for the first period; - providing the test log with a timestamp indicating the time at which the at least one test was performed; - determining whether the at least one test associated with the test application was performed within the period; and - generating an indication that the at least one test was not performed within the period. Device (101) for managing process control system tests for a process control system (100), the device comprising: - a routine monitor (216) for monitoring the operation of a process control routine (102) during a period of time, wherein the process control routine (102) is executed during normal operation of the process control system (100);- a test application comparator (206) for determining whether the operation of the process control routine (102) during the period includes execution of a part of the process control routine (102) that is substantially similar to at least one test contained within a test application (103), by comparing the part of the process control routine with the test with respect to associated parameters, functions and / or field devices, wherein the at least one test is to be performed within the period, wherein the test application comparator (206) is configured to determine whether the execution of the part of the process control routine (102) includes correct mitigation of a problem associated with the at least one test, by determining whether the correct mitigation includes a specified process control response to correct the problem within the process control system;and- a test application modifier (212) for updating the test application (103) by indicating that the at least one test has been performed, in response to the determination that the at least one test has been performed within the period, wherein, after the test application comparator (206) has determined whether the execution of the part of the process control routine includes the correct reduction, the test application modifier (212) is configured to indicate that the at least one test is to be performed within a second period, the second period occurring after the first period. Device (101) according to claim 8, further comprising a test application generator (202) for generating a test application (103) from the process control routine (102). Device (101) according to claim 9, wherein the test application generator (202) generates the test application (103) from the process control routine (102) by at least one of: - determining at least one test boundary based on at least one parameter within the process control routine (102); - ordering a sequence of the at least one test based on a sequence of instructions within the process control routine (102); or - ordering the sequence of the at least one test based on a type of function within the process control routine (102). Device (101) according to claim 9, wherein the test application generator (202) is configured to create a test plan from the test application (103) which contains the at least one test. Device (101) according to claim 11, further comprising: a test application processor (204) for: - prompting an operator to perform the at least one test included in the test plan; - prompting the operator to enter an identification value; and - receiving the identification value; and - a test execution monitor (200) for receiving at least some of the data associated with the test plan or with the test application (103). Device (101) according to claim 12, wherein the test application comparator (206) is configured to: - determine whether the received data corresponds to a correct reduction of the at least one test; - access a database (208) of personnel training records; - determine whether a training record corresponding to the identification value includes a statement that the user is authorized to execute the test plan; and - allow the operator to execute the test plan; - combine results of the test plan with the test application (102) to create a test log for the first period; and - determine whether the at least one test associated with the test application (102) has been performed within the period. Device (101) according to claim 13, wherein the test application modifier (212) is configured to: - update the test plan to indicate that the at least one test has been verified for the period; and - provide the test log with a timestamp indicating the time at which the at least one test was performed. Device (101) according to claim 14, wherein the test application comparator (206) is configured to generate a display indicating that at least one test has not been performed within the time period. Device (101) according to claim 8, wherein, after the test application comparator (206) has determined whether the execution of the part of the process control routine includes the correct reduction, the test application modifier (212) is configured at least to: - provide the at least one test with a timestamp; or - store at least one of the correct reduction, the timestamp of the at least one test, or the at least one test in a test log. Device (101) according to claim 8, wherein the test application modifier (212) is configured to: - receive a modification of the process control routine; - modify the test application (103) based on the modification; and - store the modified test application as a different version of the test application.
Citation Information
Patent Citations
testing of integrated circuits
DE60318795T2
Method and system for integrating test coverage measurements with model based test generation
US20030046613A1
Empirical data based test optimization method
US20040061517A1