JP2010244213A - Programmable controller, program execution monitoring method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a programmable controller, a program execution monitoring method and a program by which the middle lapse of program execution can be verified even when this programmable controller is configured of hardware or software whose execution channels are different with a small memory quantity in a short time. <P>SOLUTION: Execution programs 26-1 and 26-2 including instructions to call a verification code generation routine are generated from a ladder figure 24. When the execution programs 26-1 and 26-2 are executed by an execution channel, a verification code is generated, and stored in a verification code storage area 22. Those verification codes are verified, so that it is possible to verify whether the execution programs 26-1 and 26-2 have been normally executed. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a programmable controller, and more particularly to a technique for monitoring program execution of a programmable controller.

  In a programmable controller, it is checked whether a program has been executed in an expected order and whether a calculation result has been correctly calculated, and diagnosed whether the program is being executed normally.

  In particular, in a programmable controller having a redundant configuration such as multiplexing of CPUs, a technique for diagnosing whether the processing is executed in an expected order and whether the calculation result is correct is required.

  As the simplest technique for diagnosing program execution, a method of monitoring execution time by a watchdog timer is generally known. For example, Patent Literature 1 discloses a programmable controller that monitors runaway by interrupting the CPU with a watchdog timer.

  Patent Document 2 discloses a programmable controller that performs monitoring by comparing a state transition time with a reference time as monitoring without using a watchdog timer.

  In Patent Document 3, as a monitoring method that does not use the watchdog timer, a check program is described in the program, the value in the RAM is incremented and written by this check program, and the numerical value written in the RAM is normal. A method of detecting a runaway by checking whether or not is disclosed.

  As another diagnostic technique, there is known a method of performing diagnosis by storing execution passage points in a program in a trace memory and collating the contents of the trace memory.

JP-A-6-250864 JP-A-5-313711 JP-A-6-324914

However, each monitoring method described above has the following problems.
In the program execution monitoring method using the watchdog timer disclosed in Patent Document 1 or the like, it can be confirmed whether the execution from the execution of the instruction indicating the program start to the execution of the instruction indicating the program end can be completed within a specified time. However, when the programmable controller has a multiplexed configuration, it is not possible to verify whether the same program has been executed equally in a plurality of execution channels by checking the progress of the process.

In the method of Patent Document 2, it is necessary to set a reference execution time or the like in advance, and memory resources used for storing the state transition time and the reference time are required.
Furthermore, in the method of Patent Document 3, if the execution program is sequential, it can be checked. However, the application is limited to the case where the execution program is a simple sequence program, and is not suitable when the execution program dynamically changes the execution destination including branches and loops.

The methods of Patent Documents 1 to 3 are all techniques for monitoring and diagnosing in the case of a configuration having a single execution channel.
Also, the execution monitoring method by accumulating execution pass points of the execution program in the trace memory and collating the data makes it possible to collate the progress, but transfer the entire contents of the trace memory to other execution channels. Then, since the comparison is made within each execution channel, processing time is required. Further, the larger the size of the execution program, the longer the trace memory capacity and the processing time. For example, when there are 2 bytes per point, a trace memory capable of storing 1000 points requires a capacity of about 2 kilobytes.

  In addition, multiple execution channels of a programmable controller with redundancy are configured with exactly the same hardware, the same operation clock, and the same software, and the execution channels are operated in complete synchronization, and the hardware from each execution channel is configured. There is also a method in which a wear signal is monitored to make an abnormality when a difference occurs. However, in an electronic device for functional safety defined in IEC 61508, which is an international standard for functional safety, as a measure for avoiding the influence of systematic failure due to the same hardware as much as possible, hardware or software is used as a component. It is recommended to have diversity (diversity) that makes a difference in processing method. For this reason, this standard cannot be satisfied by a method of synchronizing with this configuration.

  In view of the above, the present invention provides a programmable controller capable of verifying the progress of program execution even with a small amount of memory, within a short period of time, and even if the execution channel is composed of different hardware and software. Is an issue.

  The programmable controller of the present invention is a programmable controller comprising a plurality of execution channels for executing an execution program in parallel. The plurality of execution channels are verified for verifying whether the execution program has been normally executed in the execution channel. A verification code storage unit for storing a code, and a verification code generation routine storage area for storing a verification code generation routine that is called from the execution channel and generates the verification code.

  The program execution monitoring method of the present invention is a program execution monitoring method in a programmable controller having a plurality of execution channels for executing an execution program in parallel. Call a verification code generation routine for generating a verification code for verifying whether or not it has been executed, store the verification code in a verification code storage area provided for each of the execution channels, and store the verification code storage area of each of the plurality of execution channels It is characterized by verifying whether the said execution program was normally executed by collating the verification code in this.

  The program according to the present invention is a program executed in a programmable controller having a plurality of execution channels for executing an execution program in parallel, and is called from the execution program and passed from the execution program and the verification code Is generated using a value in a verification code storage area provided for each execution channel, and a verification code for verifying whether the execution program has been executed normally is generated, and the verification code is stored in the verification code storage area And causing the programmable controller to execute.

  According to the present invention, since the verification code is calculated along with the execution of the execution program, if the execution program point and the execution order are different among the execution channels, the verification code becomes a different verification code and an error is detected by collation. Detection can be performed.

In addition, when the result of the execution program is used as a parameter for the verification code generation routine, it is possible to check the identity of the operation result in addition to the execution order.
Furthermore, since the verification code is calculated within the subroutine, there is no dependency on the hardware and software processing method of the execution channel.
Also, the memory size required for the verification code is small, and the time required for verification is short.

It is a figure showing the whole programmable controller system composition in this embodiment. It is a figure which shows the example of a ladder diagram. It is a figure which shows the example of the execution program run with the conventional programmable controller. It is a figure which shows the 1st example of the execution program produced | generated by the execution program production | generation part of this embodiment. It is a figure which shows the 2nd example of the execution program produced | generated by the execution program production | generation part of this embodiment. It is a flowchart which shows the operation | movement process at the time of the execution control part of this embodiment executing an execution program. It is a figure which shows the 1st operation example of a verification code generation routine. It is a figure which shows the 2nd operation example of a verification code generation routine.

  In the programmable controller of the present embodiment, when a program (for example, a ladder diagram) created by a user in the language for the programmable controller in the program generation device is converted into an execution program executed by the controller, the execution program is normally executed in each execution channel. Insert code that calls a routine that generates the verification code used to verify whether

  In each execution channel of the controller that executes this execution program, the verification code is recorded in its own memory when the corresponding program is executed. Then, each execution channel compares the recorded verification codes with each other when the operation by the execution program is completed, and continues the process only when both match, and performs the functional safety error process when both do not match.

  As a result, an error check for functional safety of the programmable controller can be realized by a simple process of comparing the verification codes, and only a few bytes are required for storing the verification codes.

Next, the detail of the programmable controller system of this embodiment is demonstrated.
FIG. 1 is a diagram showing an overall configuration of a programmable controller system in the present embodiment.

The programmable controller system 1 in FIG. 1 has a configuration in which a program generation device 20 is connected to a controller 10 via a transfer cable 30.
The controller 10 includes a calculation unit 11 having two execution channels 16-1 and 16-2 for executing an execution program, and an activation for an operator to instruct activation / stopping of the execution channels 16-1 and 16-2. / Stop switch 12, input unit 13 for receiving external input from an external device connected to programmable controller system 1, start / stop command is received from program generator 20, and execution channel 16-1 and It has a start / stop command receiving unit 14 for notifying 16-2 of start / stop, and an output unit 15 for outputting the execution result of the execution program to the outside.

  Of these, the execution channels 16-1 and 16-2 are independent in hardware, and are realized by hardware such as a microcomputer, a memory, and a logic IC, and firmware.

  Each of the execution channels 16-1 and 16-2 includes execution control units 17-1 and 17-2 that execute execution programs and memories 18-1 and 18-2 that store the execution programs. Each memory 18 (18-1, 18-2) implements an execution program storage area 19 (19-1, 19-2) for storing an execution program, and a verification code generation routine and verification described later in software. Verification code generation routine storage area 21 (21-1 and 21-2) for storing firmware for performing verification, and verification code storage area 22 (22-1 and 22-2) for storing verification codes . The execution control unit 17 executes the firmware in the verification code generation routine storage area 21 to compare two verification codes generated by the execution channels 16-1 and 16-2. , 23-2) is realized.

  The program generation device 20 is used by a user to input a program. For example, the program can be input using a ladder diagram 24 shown in FIG. Hereinafter, an example using the ladder diagram 24 will be described. However, the language in which the user inputs the program is not limited, and other languages (standards) shown in IEC 61131-3 of the International Electrotechnical Conference (IEC) ( SFC, FBD, ST, IL) may be used.

  The program generation device 20 generates the execution programs 26 that can be interpreted and executed by the controller 10 from the input user program by the number of execution channels 16 provided on the controller 10 side (two in the case of FIG. 1). That is, in the case of FIG. 1, execution programs 26-1 and 26-2 are generated.

  In FIG. 1, each execution channel 16-1, 16-2 has a configuration including verification code generation routine storage areas 21-1, 21-2, but each execution channel 16-1, 16-2 is one. Two verification code generation routine storage areas 21 may be shared.

  The program generation apparatus 20 is connected to the controller 10 via a transfer cable 30, and the execution program 26 is transferred to the memory 18 of each execution channel 16 in the controller 10 via the transfer cable 30.

  The program generation device 20 includes an execution program generation unit 25 that generates execution programs 26-1 and 26-2 executed by the execution channels 16-1 and 16-2 of the controller 10 from a ladder diagram 24 created by the user, and a controller. It has a start / stop command generator 27 for instructing start / stop to 10 execution channels 16-1 and 16-2.

  The execution program generation unit 25-1 generates execution programs 26-1 and 26-2 corresponding to the execution channels 16-1 and 16-2 from the ladder diagram 24. The execution programs 26-1 and 26-2 are functionally the same but different code programs in order to provide diversity. Further, when the execution program generation unit 25 generates the execution programs 26-1 and 26-2 from the ladder diagram 24, an instruction for calling a verification code generation routine for generating a verification code in the execution programs 26-1 and 26-2. insert. The instruction for calling the verification code generation routine is inserted at a position where it is executed in either execution channel 16-1 or 16-2. Various insertion methods can be considered, for example, in ladder diagram 24. Insert each function such as a relay.

FIG. 2 shows an example of the ladder diagram 24.
When the execution program generation unit 25 converts the ladder diagram 24 as shown in FIG. 2 into the execution programs 26-1 and 26-2, each of the points 31-1 to 31-6 corresponding to elements such as contacts and coils. Insert an instruction to call the verification code generation routine. Note that it is not necessary to insert an instruction for calling the verification code generation routine in all of the points 31-1 to 31-6, and may be inserted at regular intervals in consideration of the entire amount of the program and the number of steps. The point 31 may be inserted mechanically according to a predefined rule, or may be inserted by the user based on an empirical rule or a processing time of an execution program.

  3 is a diagram showing an example of an execution program executed by the conventional programmable controller generated from the ladder diagram 24 of FIG. 2, and FIG. 4 is an execution program generation unit 25 of the present embodiment from the ladder diagram 24 of FIG. It is a figure which shows the example of the execution program 26 produced | generated.

Comparing FIG. 3 and FIG. 4, in the execution program of FIG. 4, instructions 41-1 to 41-3 for calling (calling) verification code generation routines are inserted at three locations.
“CRCGEN” in the instruction 41 for calling the verification code generation routine of FIG. 4 indicates the name of the verification code generation routine to be called, and the following “X′0000” to “X′0002” call the verification code generation routine. “X ′” is a unique value in the execution program and indicates, for example, a hexadecimal number. Here, if the value is 4 digits, the range is from 0000 to FFFF.

  In the example of FIG. 4, each verification code generation routine uses a unique value as a parameter to generate a verification code using this unique value. As a result, the collating units 23-1 and 23-2 collate the verification codes of the execution channels 16-1 and 16-2, so that the execution order of the execution programs can be verified.

  Further, the execution program 26 of FIG. 4 does not include a verification code generation routine and calls the verification code generation routine in the verification code generation routine storage area 21 in the controller 10. The execution program 26 can be realized with only several bytes to several tens of bytes. Therefore, since the instruction 41 for calling the verification code generation routine can be entered at a necessary place of the execution program 26, the execution order of the execution program 26 can be verified even if there are complicated branches and conditional expressions in the execution program. I can do it. The verification code storage area 22 required for this purpose also occupies only about 2 bytes of memory resources.

  Furthermore, since the verification code is generated by a verification code generation routine stored in the controller 10, there is no dependency on the hardware of the execution channel 16 or the software processing method.

FIG. 5 is a diagram illustrating a second example of the execution program generated by the execution program generation unit 25 of the present embodiment.
In the execution program of FIG. 5, in the instruction 42 for calling the verification code generation routine, the name “CRCGEN2” of the verification code generation routine to be called is followed by the arguments “X′0000” to “X′0002” indicating the position. Thus, arguments “X'0000”, “Y00”, and “Y01” of values used for generating the verification code are given. The value used for generating the verification code, which is the second parameter, is a calculation result obtained by executing the execution program. “Y00” and “Y01” indicate values of arbitrary variables in the execution program.

  In the second example of FIG. 5, in addition to the information indicating the position in the execution program, the calculation result is also sent to the verification code generation routine as a parameter. By verifying the verification code generated by the verification code generation routine based on these, not only the execution order of the execution program 26 but also the consistency of the operation results can be diagnosed.

  When the execution program 26 shown in FIG. 4 or 5 is executed on the execution channel 16, the verification code generation routine is called to generate a verification code, which is stored in the verification code storage area 22 of the memory 18. When the execution of the execution program 26 is completed, the collation units 23-1 and 23-2 of the execution channels 16-1 and 16-2 receive the value of the verification code storage area 22 in the memory 18 of the own execution channel 16, and The value of the verification code storage area 22 in the memory 18 of the other execution channel 16 is collated. And as a result of this collation, the controller 10 continues the process only when the two match each other, and performs the functional safety error process when both do not match.

  In the verification code generation routine, the verification code is generated using the parameter value. The verification code generation algorithm may be a checksum (simple sum), CRC (Cyclic redundancy checksum), hash value (Hash value), or the like. However, it is not particularly limited, and an appropriate algorithm may be selected and used according to the diagnostic accuracy for which the programmable controller is required.

  In FIGS. 4 and 5 described above, the execution programs 26-1 and 26-2 are executed by the execution control units 17-1 and 17-2 of the execution channels 16-1 and 16-2. At this time, the two execution channels 16-1 and 16-2 operate in synchronization, “input” for fetching external input from the input unit 13, “calculation” for executing the execution program 26, and two execution channels 16-1. And the results of “collation”, “calculation”, and “collation” for confirming that the values in the verification code storage areas 22-1 and 22-2 between 16-2 match are output from the output unit 15 to the outside. Each phase of “output” is processed as one scan cycle. The scanning is repeated while the two verification codes match in “collation”.

  When the execution program 26 is executed, the verification code is generated every time the verification code generation routine is called, and the value of the verification code storage area 22 in the memory 18 is updated. When execution of the execution program 26 is completed, in each of the execution channels 16-1 and 16-2, the collation units 23-1 and 23-2 collate the values in the two verification code storage areas 22-1 and 22-2. And confirm that they match. As a result of this collation, if the two verification codes match, the controller 10 outputs a calculation result. If the two verification codes do not match, the controller 10 outputs an error and does not output the calculation result.

  Note that the collation by the collation unit 23-1 and the collation unit 23-2 has an aspect of satisfying functional safety by duplicating the collation processing itself. This is because the execution channel 16-1 and the execution channel 16-2 have different hardware configurations (to ensure diversity), so that the execution channel 16-1 and the execution channel 16-2 have a hardware problem. This avoids the possibility of “mismatching at the same time”.

On the other hand, when such a restriction is not provided, for example, the collation unit 23 may be configured as a single unit or provided outside the execution channel 16.
Moreover, the collation part 23 should just have the acquisition control of the value in verification code storage area 22-1 and 22-2, and the output control function of the collation result, even if it is a hardware structure. Firmware (program) for realizing in software may be used. For example, the collation unit 23 may be stored in the memory 18 as a collation routine accessible from the execution control unit 17.

Next, the processing flow of the execution control units 17-1 and 17-2 of the execution channels 16-1 and 16-2 will be described.
FIG. 6 is a flowchart showing an operation process when the execution control unit 17 executes the execution program 26. In the example of FIG. 6, a case where a CRCGEN routine of FIG. 7 described later is used as the verification code generation routine is shown as an example.

  Note that the processing of FIG. 6 is processed in synchronization in the two execution channels 16-1 and 16-2. Further, in the programmable controller system 1 of this embodiment, there are behaviors corresponding to various events such as start, stop, and failure, but the processing flow of FIG. 6 describes only the part related to the verification code of this embodiment, and others. Is omitted.

In the flow of FIG. 6, first, the execution channel 16 is initialized as step S1.
In this initialization process, the controller 10 prepares the execution environment of the execution program 26, and enters the scan cycle when the initialization process is completed.

  In the scan cycle, the execution control unit 17 first performs external input capture as step S2. In this external input capture, external input data is captured from the input unit 13 to the execution control unit 17.

Next, in step S3, the execution control unit 17 initializes the value in the verification code storage area 22 in which the verification code is stored.
When the initialization is completed, the execution control unit 17 reads the execution program 26 from the execution program storage area 19 as step S4. In step S5, the execution program 26 read in step S4 is executed. In the execution process of the execution program 26, the execution control unit 17 advances instruction execution according to the program code of the execution program 26.

  When an instruction for calling a verification code generation routine such as a CAL CRCGEN, X′xxxx instruction or the like is executed during the execution process of the execution program 26 in step S5, the process is processed by the verification code generation routine in the verification code generation routine storage area 21. Transfer.

  In the verification code generation routine, in step S6, a verification code is generated using the parameter value X'xxxx and the like, stored in the verification code storage area 22, and the process returns to step S5.

This verification code generation routine is called every time an instruction for calling the verification code generation routine is executed, and the verification code in the verification code storage area 22 is updated.
Details of this verification code generation routine will be described later.

  When the execution of the execution program 26 in step S5 is completed, the execution control unit 17 notifies the verification code in the verification code storage area 22 to another execution channel 16 in step S7. In this example, the execution channel 16-1 notifies the execution channel 16-2, and the execution channel 16-2 notifies the execution channel 16-1 of its own verification code.

  When receiving the verification code from the other execution channel 16 (step S8), the execution control unit 17 performs comparison and verification with the verification code of the own channel by the verification unit 23 as step S9.

  As a result of verification of the verification code in step S9, if they do not match (NO in step S10), it indicates that the program execution order is different between the execution channel 16-1 and the execution channel 16-2. Anomaly processing such as anomaly notification is performed and the process is terminated. The controller 10 does not execute the program thereafter. The execution result of the execution program 26 is not output.

  On the other hand, if the result of verification code verification in step S8 is the same (step S10, YES), it indicates that the program execution order is the same in the two channels 16, and is normal. Output the calculation result. This output data is output to the outside via the output unit 15.

After outputting the calculation result, the execution control unit 17 determines whether or not the execution program 26 is to be continued in step S13.
In the program controller 1, when the user operates the program generation device 20, the start / stop command generation unit 27 issues a start / stop command to the controller 10, and execution / stop of the execution program 26 by the execution channel 16 is performed. Can be done.

  In step S13, when the stop command is not input from the program generation device 20, and when stop is not instructed by the start / stop switch 12, the execution control unit 17 continues the execution of the execution program 26 ( In step S13, YES), the process moves to step S2 to return to the head of the scan loop, and the operations of input, calculation, collation, and output are repeated again.

  Thereafter, the scan loop is repeated until a verification code mismatch is detected or a stop is instructed by the user. When a stop instruction is received from the user (step S13, NO), execution of the execution program is terminated.

Thus, in the programmable controller system 1 of this embodiment, an execution program is executed and a functional safety error is detected using a verification code.
In the above example, the CRCGEN routine of FIG. 7 is used as the verification code generation routine, but a CRCGEN2 routine of FIG. 8 to be described later may be used. When this CRCGEN2 routine is used, a value indicating the position in the execution program 26 and a calculation result by the execution program are also given as parameter values, so that not only the execution order of the execution program 26 but also the consistency of the calculation results can be diagnosed.

  In addition, the controller of the above example is premised on a configuration including two execution channels 16, but the programmable controller system 1 of the present embodiment is also assumed to include three or more execution channels 16. When three or more execution channels 16 are provided, the functional safety is verified as normal only when all the verification codes generated in all the execution channels 16 match, and even if one of the values is different. Perform error handling.

Next, details of the verification code calculation routine will be described.
FIG. 7 is a diagram showing an operation example of the CRCGEN verification code generation routine called by the execution program 26 of FIG. The routine shown in the figure is called with one parameter having a length of 2 bytes, for example. Further, as an example of the verification code generation algorithm, a case where a CRC 16 having a large use record in digital data communication is used is shown as an example.

  In this embodiment, the verification code generation algorithm is not particularly limited, but it is generally known that a CRC called a cyclic redundancy code has more certainty of data error detection than a checksum that takes a simple sum. In this example, the CRC 16 is used to generate a verification code.

  When the CRCGEN routine of FIG. 7 is called, first, in step S21, the input parameter value given by the routine call instruction from the execution program 26 is set to the input parameter 1 of the CRC calculation algorithm.

In step S22, the current verification code is read from the verification code storage area 22, and this value is set as the input parameter 2 of the CRC calculation algorithm.
In step S23, a verification code updated by the CRC16 calculation algorithm is generated. In this CRC16 calculation algorithm, a new CRC code is generated by reflecting the 2-byte value of the input parameter 1 in the input parameter 2 in the order of the lower byte and the upper byte.

  Finally, as step S24, the CRC code generated in step S23 is stored in the verification code storage area 22 as an updated verification code, and then the process is returned to the execution program 26.

  When the two execution channels 16-1 and 16-2 always proceeded with processing faithfully to the program codes of the execution programs 26-1 and 26-2, the input parameter values always have the same value. Since the routine 7 is called, the verification code values of the two execution channels 16-1 and 16-2 match. However, for example, when a difference occurs in the execution order of the execution program due to an erroneous branch execution in a branch instruction, a jump destination miss, a code generation failure, or the like, a different verification code is calculated, and the collating unit 23 A mismatch is detected by verification of the verification code after the execution program 26 ends.

Therefore, the execution order of the execution program 26 can be verified by verifying the verification code.
FIG. 8 is a diagram showing an operation example of a CRCGEN2 verification code generation routine called by the execution program 26 of FIG. The routine shown in the figure is called with two 2-byte input parameters.

  When the routine of FIG. 8 is called, first, in step S31, the first parameter value given by the routine call instruction from the execution program 26 is set to the input parameter 1 of the CRC calculation algorithm.

Next, in step S32, the current verification code is read from the verification code storage area 22, and this is set in the input parameter 2 of the CRC calculation algorithm.
In step S33, a verification code updated by the CRC16 calculation algorithm is generated. In this CRC16 calculation algorithm, a new CRC code is generated by reflecting the 2-byte value of the input parameter 1 in the input parameter 2 in the order of the lower byte and the upper byte.

In step S34, the second parameter value given by the routine call instruction from the execution program 26 is set to the input parameter 1 of the CRC calculation algorithm.
In step S35, the CRC code obtained in step S33 is set in the input parameter 2 of the CRC calculation algorithm.

Then, using the input parameter 1 and the input parameter 2, as step S36, a CRC code is obtained by a CRC16 calculation algorithm similar to step S33.
Finally, in step S37, the CRC code generated in step S36 is stored in the verification code storage area 22 as a verification code, and the post-processing is returned to the execution program 26.

  As described above, in the verification code generation routine of FIG. 8, the verification code is generated using the parameter indicating the unique value in the execution program 26 and the parameter of the calculation result by the execution program. Therefore, by using the verification code generation routine of FIG. 8, not only the difference in the program execution order but also the difference in the calculation result can be detected.

  Although the CRC code is used as the verification code in the verification code generation routines of FIGS. 7 and 8, the present embodiment is not limited to this, and other than the above checksum, for example, a CRC code Although the size is larger than the above, it is possible to use a hash algorithm that has been widely used in message authentication codes (MAC) in digital data communication such as MD and SHA. In the case of this hash code, it is generally known that there is more certainty of error detection than the CRC code, and if it is desired to monitor program execution more strictly, a hash algorithm may be employed.

  In the above example, one or two parameter values are passed to the verification code generation routine. However, three or more parameter values are passed to the verification code generation routine, and the verification code generation routine uses these to pass the verification code. You may make it produce | generate.

  Thus, a programmable controller having a desired program execution monitoring accuracy can be realized by selecting a verification code generation algorithm based on required strictness and implementing a verification code calculation routine of the controller.

Even in the case of an execution channel composed of different hardware and software, verification of the progress of program execution can be performed in a short time with a small amount of memory.
Furthermore, the present invention can be applied without being influenced by the complexity of the execution program, and the program execution order and the result can be checked in the redundant execution channel.

DESCRIPTION OF SYMBOLS 1 Programmable controller system 10 (Programmable) controller 11 Operation part 12 Startup stop switch 13 Input part 14 Startup command receiving part 15 Output part 16 Execution channel 17 Execution control part 18 Memory 19 Execution program storage area 20 Program generation apparatus 21 Verification code generation routine Storage area 22 Verification code storage area 23 Verification unit 24 Ladder diagram 25 Execution program generation unit 26 Execution program 27 Start / stop command generation unit 30 Transfer cable

Claims (10)

In a programmable controller comprising a plurality of execution channels for executing an execution program in parallel,
The plurality of execution channels include a verification code storage unit that stores a verification code for verifying whether the execution program has been normally executed in the execution channel;
When the execution of the execution program is completed, a verification unit for verifying verification codes in the verification code storage area of the plurality of execution channels;
With
A verification code generation routine storage area that stores a verification code generation routine that is called from the execution channel and generates the verification code;
A programmable controller comprising:   The execution program is determined to have been executed normally when all verification codes in the verification code storage areas of the plurality of execution channels match as a result of the verification by the verification unit. Programmable controller.   The programmable controller according to claim 2, wherein the verification unit performs error processing when there is a code that does not match the verification code in the verification code storage area of the plurality of execution channels.   4. The execution program according to claim 1, wherein when the verification code generation routine is called, the execution program delivers a first parameter that takes a unique value in the execution program to the verification code generation routine. Programmable controller described in 1.   5. The programmable controller according to claim 4, wherein when the execution program calls the verification code generation routine, the execution parameter is also transferred to the verification code generation routine by a second parameter that is an execution result of the execution program.   The programmable controller according to claim 4, wherein the verification code generation routine generates the verification code using the parameter.   The verification code generation routine generates the verification code using any one of a checksum algorithm, a CRC code algorithm, and a hash code algorithm using the one or more parameter values. The programmable controller according to claim 6.   The program generation part which produces | generates the said execution program including the code | cord | chord which calls the said several verification code production | generation routine from the program created in the language for the said programmable controller by the user is further provided. The programmable controller as described in any one. In a program execution monitoring method in a programmable controller having a plurality of execution channels for executing an execution program in parallel,
A verification code generation routine for generating a verification code for verifying whether or not the execution program has been normally executed is called from the plurality of execution programs executed in parallel, and the verification code is provided for each execution channel. Store it in the code storage area,
A program execution monitoring method comprising: verifying whether or not the execution program has been executed normally by collating verification codes in the verification code storage area of each of the plurality of execution channels. A program executed in a programmable controller having a plurality of execution channels for executing execution programs in parallel,
Verifies whether the execution program has been executed normally using the parameter value called from the execution program and passed from the execution program and the value in the verification code storage area provided for each execution channel. Generate verification code to
A program for causing the programmable controller to store the verification code in the verification code storage area.

Images