Methods and apparatus for updating electronic system programs and program blocks during substantially continued system execution

[0002] This invention relates generally to control systems and more specifically to industrial control systems that use embedded programs as a part of an industrial control system.

[0003] Known electronic systems are extensively used in process control applications. These electronic systems are usually modular, that is, a central processing unit (CPU) communicates with a series of replaceable modules, sometimes called input/output (I/O) modules that are connected to the CPU in a bus arrangement. I/O modules are configured with a common interface to the electronic system. In addition, specific input/output circuitry is contained within a particular I/O module depending on the function performed (i.e. the specific input/output requirements of a particular industrial control application). In one aspect of industrial control, the CPU monitors inputs and outputs from various I/O modules.

[0004] Typical electronic systems, such as those used in industrial control applications execute a plurality of program blocks, as part of an integrated control system. A typical integrated control system contains multiple modules used to control various hardware interfaces. One problem with electronic systems of this type is that when it is necessary to update a program block, the electronic system has to be stopped, even though the program block to be updated is not executing. Stopping the electronic system also means that the process being controlled, an assembly line for example, has to be stopped.

[0005] It would therefore be desirable to provide a method where program blocks can be updated without stopping execution of other program blocks within the electronic system or the stopping of the entire electronic system.

[0006] In an exemplary embodiment of the invention, a method of implementing program updates in an electronic system is described. The method includes requesting the system to accept a program update and loading replacement programs for execution.

[0007] FIG. 1 is a schematic diagram of an electronic system;

[0008] FIG. 2 is a diagram depicting a Run Mode Store of two program blocks in an electronic system;

[0009] FIG. 3 is a diagram depicting a Run Mode Store in microcycle mode; and

[0010] FIG. 4 is a diagram depicting an alternative embodiment of a Run Mode Store in microcycle mode.

[0011] FIG. 1 is a schematic illustration of an exemplary electronic system 10 including a main module 12 and two input/output (I/O) modules 14. Although two I/O modules 14 are shown, more can be provided. Main module 12 includes a power supply 16, which supplies power for main module 12 and I/O modules 14. A backplane 18, which includes electrical pathways for communication of various control and data signals, such as those signals originating from central processing unit (CPU) 20 facilitate communication between main module 12 and I/O modules 14.

[0012] One use of system 10 is in industrial process controls. A main program, for example, is loaded onto memory (not shown) within main module 12 and executed on CPU 20. I/O modules 14 perform control functions such as monitoring and supplying of signals to external devices (not shown) in order to monitor a process or a control application. I/O modules 14 are configured to perform diverse applications and certain I/O modules 14 are configured to execute internal programs. A program block for execution in an electronic system 10 is typically written in a programming language and debugged on a development system (not shown) and then downloaded to memory (not shown) in an electronic system 10 in order to run as a part of a particular application. In most programming applications, an application program includes multiple programming blocks that are executed separately under control of a main program block.

[0013] In a system, such as system 10, program blocks are continually undergoing changes and updates. It is desired that some of these updates take place without suspending execution of all program blocks. Run Mode Store is a capability that allows a user to add, remove, or replace program blocks while electronic system 10 is in a Run mode, e.g. while the application is executing. A microcycle mode is a Run Mode Store feature in which a time allocation is set aside for execution of software routines. Time allocation for program execution is referred to as a microcycle sweep. As a microcycle sweep or time allocation comes to an end, and if any program blocks are still executing at the end of the time allotted for execution, these program blocks are suspended. As a next microcycle sweep begins, the routine restarts execution where it left off as a next slot of time or microcycle sweep is allocated.

[0014] FIG. 2 is a program execution diagram 30 depicting a Run Mode Store embodiment, in electronic system 10 (shown in FIG. 1), using two program blocks. In diagram 30, program one 32 and program two 34 are executing when update request 36 occurs. As shown in diagram 30, program two 34 may execute multiple times while program one 32 is executing once. To update electronic system 10 with a different version of either program one 32 or program two 34, or both, electronic system 10 has to be at a predefined point in time where all programs have completed execution or are between executions. When neither program one 32 nor program two 34 are executing or are between executions, electronic system 10 allows an update of one or both programs. As depicted in FIG. 2, new program one 38 and new program two 40 begin execution after both programs are updated 42. Since all programs are updated at one time, programs that interact with each other, such as those programs which share data, are not affected. If electronic system 10 determines there is no point in time where none of the program blocks are executing, the Run Mode Store request is rejected.

[0015] Referring to FIG. 3, another embodiment of a Run Mode Store diagram 50, is shown. Diagram 50 depicts a Run Mode Store in microcycle mode. In the embodiment depicted in FIG. 3, a Run Mode Store is allowed only when the programs that are to be updated as a result of the Run Mode Store request are between executions. Within electronic system 10, an operating system maintains a list of currently executing programs. When electronic system 10 receives a request to perform a Run Mode Store, the operating system first determines if any of the programs to be updated in the Run Mode Store are currently executing.

[0016] To illustrate, in diagram 50, program one 52, program two 54, and program three 56 begin execution 58 at a first point in time. As shown in diagram 50, program two 54 and program three 56 may execute multiple times while program one 52 is executing a single time. After system 10 determines that an updated version of program two 54 and program three 56 is desired, a Run Mode Store update request 60 is received by CPU 20. The operating system then determines if any of the programs marked for update in Run Mode Store request 60 are currently executing. A Run Mode Store in microcycle mode, allows program two 54 and program three 56 to be swapped 62 with updated program two 64 and updated program three 66 without program one 52 having finished execution. If no programs involved in Run Mode Store request 60 are currently executing, the operating system will process request 60 immediately, otherwise request 60 is postponed until all programs involved in request 60 have finished, and are between, execution cycles. As each program completes its execution cycle, the operating system determines how many, if any, of the programs slated for updating are still executing. When the operating system determines that a Run Mode Store may proceed, the operating system swaps 62 the programs to be updated. The time allocation technique of microcycle mode does not require predefined points in time where no program blocks are executing. Updated program two 64 and updated program three 66 begin execution before one cycle of program one 52 has been completed. After the Run Mode Store is completed, the operating system resumes execution of the programs. As depicted in FIG. 3, more Run Mode Store requests are successful than in the embodiment described in FIG. 2, as only those programs involved in the Run Mode Store are between executions to allow updating.

[0017] An alternative Run Mode Store program execution diagram 70 in microcycle mode is depicted in FIG. 4. In this embodiment, each individual program can be added, deleted or swapped as it completes execution, even while other programs are executing. For each program being replaced or deleted, the operating system determines if that program is currently executing. If the program being swapped or deleted is not executing, that program is immediately replaced, added, or deleted. Those programs that are currently executing, are flagged for processing later, when those individual programs complete their execution.

[0018] In diagram 70, program one 72, program two 74, and program three 76 begin execution 78 at a first point in time. Also shown in diagram 70 is that program two 74 and program three 76 may execute multiple times while program one 72 is executing a single time. After system 10 determines that an updated version of program two 74 and program three 76 are needed, a Run Mode Store update request 80 is received by CPU 20 (shown in FIG. 1) and the operating system determines if program two 74 is currently executing. A Run Mode Store in microcycle mode, allows program two 74 to be updated 82 with updated program two 84 as soon as program two 74 has completed its current execution. Also as depicted in FIG. 4, as soon as program three 76 has finished execution, program three 76 is updated 86 with updated program three 88 which then begins execution. After a Run Mode Store update is complete for a program block, the operating system resumes execution of that program block.

[0019] The above embodiments provide system users and programmers flexibility for programmatic updates of a system, even while the system is running. This feature allows updates to be implemented without shutting down the system for installation of program updates.

[0020] While the invention has been described in terms of various specific embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit scope of the claims.