Data processing: generic control systems or specific application – Generic control system – apparatus or process – Having preparation of program
Reexamination Certificate
1998-09-29
2001-08-07
Grant, William (Department: 2121)
Data processing: generic control systems or specific application
Generic control system, apparatus or process
Having preparation of program
C700S023000, C700S108000, C712S241000
Reexamination Certificate
active
06272388
ABSTRACT:
CROSS-REFERENCE TO RELATED APPLICATIONS
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
BACKGROUND OF THE INVENTION
The present invention relates generally to a program architecture for a real time industrial control system and particularly to a program structure well suited for the development of complex, real-time operating systems for industrial controllers.
Industrial controllers are special purpose computers used for controlling industrial processes or manufacturing equipment. Under the direction of a stored program, the industrial controller examines a series of inputs reflecting the status of the controlled process and changes outputs effecting the control of the process. The inputs are most simply binary, that is “on” or “off”, however analog inputs and outputs taking on a continuous range of values are also used. The binary inputs and outputs may be represented by single bits of data; the analog inputs and outputs may be represented by multiple-bit data words.
It is desirable in industrial control that the outputs change in response to the inputs in a way so that the operation of the control program is predictable, race conditions are minimized, and the relative order of control tasks is preserved. For these reasons, industrial controllers normally employ a three step execution sequence. In the first step, inputs to the industrial controller from sensors or other devices on the controlled process are collected and stored in an input/output (I/O) table so as to create a snapshot of the inputs at a given instant in time. In the second step, a user-defined control program is executed using the inputs from the I/O table as frozen in time. The execution of the control program creates outputs which are written to the I/O table. In the final step, outputs from the I/O table are transmitted to the particular machines as control outputs to actuators and the like and the process is repeated.
Traditionally, larger industrial controllers have used dedicated circuitry for the input and output scanning steps allowing the primary processor to be dedicated to the execution of a control program. With the advent of increasingly powerful microcontrollers, however, it is possible to perform all the steps of input scanning, output scanning and execution of the control program on a single general purpose processor to create a compact, versatile control unit. Such a “processor-based” system must additionally handle numerous other tasks including the monitoring of communication channels and error conditions and responding to higher level mode control commands from the user, all the while preserving real-time control.
Following normal procedures for software development, the operating system may be divided into a number of smaller “modules” each of which may be developed independently by a separate team of individuals. Each module may be separately tested and then integrated with the others. The high degree of interaction between the modules of an industrial controller operating system and the complex interaction between the modules and hardware of the industrial controller make testing and integration of the modules particularly challenging. Each module may need to be tested alone and in various combinations with other modules. For this purpose, it is known to write “stubs”, that is dummy modules that handle calls from the modules being tested to the modules not being tested, so as to accommodate their interactions. Creating the stubs is burdensome and in many cases complicated. Poorly written stubs may introduce additional errors into the program.
In an industrial controller, it is normal for the operating system to operate in a number of modes in which different functions are activated or deactivated. For example, the industrial controller may be operated in a “program mode” where inputs are read but the control program is not executed so as to test the input lines and circuitry. A “test mode” allows the inputs to be read and the control program run, but no outputs are created, allowing testing of the control program. Finally, a “run mode” allows all three of: reading inputs, executing the control program, and writing outputs to occur. These mode changes are typically invoked by “front panel” switches (which may in fact be from a remote terminal) representing user inputs that override all other tasks of the operating system. Mode changes in the operating system may be implemented through mode flags read by “test” instructions placed in the various modules of the operating system. Embedding these “test” instructions throughout the operating system code is cumbersome and makes development and testing of the operating system difficult. A similar problem occurs when different versions of the controller are produced which have different functional requirements and thus which require different combinations of the modules.
What is needed is a program structure that allows for simplified development of modules of a real-time operating system for an industrial controller, the integration and testing of the modules, the selective activation of modules according to mode changes in the operating system or different configurations of the controller.
BRIEF SUMMARY OF THE INVENTION
The present invention provides an architecture for the development of complex real-time operating systems for industrial controllers that uses a central “call table” consisting of a list of call instructions to modules of the operating system. The calls of the call table are executed in sequence until a terminating, jump instruction is executed which returns the program execution to the first call, whereupon the process is repeated. The call table provides a single, centralized way of enabling or disabling modules of the operating system (by selectively overwriting calls with a “no operation” (NOP) instruction) and provides an intuitive and powerful framework for program development.
As modules are developed, calls to the modules may be added to the call table. In this way, the operating system may be tested with any combination of modules at any time during module development.
Other call tables may be called by the first call tables to provide similar benefits within the modules themselves thus allowing this technique to be used for programs of arbitrary complexity. Returns from the loops of nested call tables are accomplished by an overriding of the terminating jump instruction or similar technique.
Specifically then, the invention provides for an industrial control system employing a general-purpose electronic computer operating to execute standard computer instructions. An operating system executed by the electronic computer includes a sequentially executed program portion being a call table containing a plurality of call instructions to addresses of other program portions and a terminating instruction at the end of the plurality of call instructions causing an indefinite repeated execution of the call table. A plurality of periodically executed program portions are at the addresses of the call table and have instructions providing industrial control functions followed by a terminating instruction causing a return from a call.
Thus it is one object of the invention to provide a program structure allowing repeated execution of program modules for predictable real-time control.
It is yet another object of the invention to provide a framework that allows simplified testing of individual modules and their interaction with hardware on a real-time basis. Deletion or insertion of call instructions in a centralized call table allows modules to be easily added or removed without the generation of complex and error-inducing stub programs. This is particularly valuable for creating different controllers having different functional capabilities.
At least one of the periodically executed program portions may include a second call table containing a second plurality of call instructions to addresses of other program portions and a second terminating instruction at the end of the second plurality of call instructions cau
Buvel Raymond L.
Chandler Steven K.
Izzo Joseph P.
Searing Lawrence G.
Shelvik Norman S.
Bahta Kidest
Baxter Keith M.
Gerasimow Alexander M.
Grant William
Rockwell Technologies LLC
LandOfFree
Program structure and method for industrial control does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Program structure and method for industrial control, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Program structure and method for industrial control will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2482457