JP2012059078A - Plc system and development support device therefor - Google Patents

Abstract

A development support apparatus can automatically perform a substantially optimal load distribution for a plurality of arithmetic processing units.
A compiler 11 compiles an arbitrary application to generate an execution object code. Accordingly, the POU size calculation function unit 13 obtains the size of the execution object code of each POU, and the call information generation function unit 14 generates “POU call information”. The optimum load distribution function unit 15 distributes the execution object code to the plurality of CPUs 2a and 2b based on the execution object code size and the “POU call information”.
[Selection] Figure 1

Description

  The present invention relates to a development support apparatus for a programmable controller.

  In recent years, in embedded systems using microcontrollers and LSIs, the improvement in execution speed due to an increase in hardware clock frequency is approaching the limit. The multi-core method that increases the execution speed of is now being used. At that time, the user may be required to adjust the load applied to each CPU in order to efficiently use a system including a plurality of arithmetic processing units (CPUs).

  However, in PLCs that often require sequential processing and often require real-time performance, load adjustment requires processing know-how that depends on the system configuration, including input / output devices, and is difficult. As the system scale increases, the adjustment man-hours are also increasing. Regarding the automatic load distribution method devised to reduce the man-hours, there are the following Patent Documents 1 and 2 as prior art documents.

  Patent Document 1: A method of load distribution when the system is operating (dynamic). When the system is in operation, each PLC calculates its own load, and at least part of its processing is requested to another PLC in accordance with the calculated load, thereby realizing automatic load distribution.

  Patent Document 2: A method of distributing the load when the system is not operating (static). It specializes in SFC, one of the international standardized languages of PLC (IEC61131-3), and realizes an automatic allocation method that uses these features.

JP-A-9-91011 JP-A-7-28390

  In recent years, applications of programmable controllers have become more complex and larger in capacity, and it is difficult to determine the distribution even if the load is distributed to a plurality of CPUs to improve processing efficiency. In addition, when load is distributed by trial and error, it takes a lot of time, which is a burden on the user.

  In addition, when load is distributed by trial and error, it takes a lot of time, which is a burden on the user, which not only increases the difficulty of developing an application program, but also reduces the development efficiency.

  Also, in recent years, PLC applications are designed to be structured in functional units using multiple languages such as IEC61131-3, rather than simply structured programs written in processing units in a conventional ladder language or the like. As a result, it has become difficult for the user to grasp the overall flow of processing. In the case of structured design, the same functional unit, function, and the like are often called from different programs, and the program creator has developed a number of developments.

  In such a situation, even if the system has a plurality of CPU resources, it is difficult for the application program creator to distribute the load by himself, resulting in the total system processing performance due to the imbalance of processing load. Decrease and increase of system startup man-hours can be considered.

  An object of the present invention is to have a plurality of arithmetic processing units, and in a PLC system that distributes a load related to arbitrary application execution to a plurality of arithmetic processing units, a development support apparatus can automatically perform almost optimal load distribution, Accordingly, it is to provide a PLC system capable of improving the system development efficiency of the user and reducing man-hours at the time of starting the system, a development support apparatus thereof, and the like.

  The PLC system of the present invention is a PLC system that first includes a development support apparatus and a plurality of arithmetic processing units, and distributes a load related to execution of an arbitrary application to the plurality of arithmetic processing units. The development support apparatus determines a total number of sizes of the execution object code related to a processing unit for each of a plurality of processing units constituting the application and a compiling unit that generates an execution object code by compiling the application. Total execution object code size calculation means, and means for allocating the processing of the application to the plurality of arithmetic processing units in each processing unit, each of the processing units calculated by the total execution object code size calculation means Based on the total execution object code size of And a load distribution unit for arithmetic processing unit of the respective load number to distribute the processing of the application so as to be substantially equal to each processing unit.

  Based on the size of the execution object code after compilation, the distribution of the execution object code to a plurality of arithmetic processing units is determined, so that appropriate load distribution can be performed and it does not matter what the pre-compile PLC language is. Become.

  Secondly, the PLC system of the present invention includes a development support apparatus and a plurality of arithmetic processing units, and loads the plurality of loads related to execution of an arbitrary application including a plurality of programs and various POUs called from the programs. The development support apparatus determines a size of the execution object code of each of the POUs, and a compiling unit that generates an execution object code by compiling the application. POU size calculation means, call information generation means for obtaining call information of the POU at the time of compilation, a program constituting the application based on the size of the execution object code of each POU and the call information of the POU Each time the program A total execution object code size calculating means for calculating the total number of execution object code sizes according to the size of the execution object code of each POU and the number of executions, and a means for allocating each program to the plurality of arithmetic processing units. Then, based on the total number of execution object code sizes of each of the programs calculated by the total execution object code size calculation means, each program is processed by each calculation process so that the load on the plurality of calculation processing units is substantially equal. Load distribution means for allocating to each section.

  In the case of structured design, the same functional unit, function, etc. are often called from different programs, and it is difficult for humans to perform load distribution. However, in the PLC system, the execution object code for each POU is high. Based on the size and the POU call information, appropriate load distribution can be automatically performed.

  According to the PLC system of the present invention, its development support device, and the like, the development support device can automatically perform almost optimal load distribution, thereby improving the system development efficiency of the user and starting up the system. Man-hours can be reduced. This has a particularly remarkable effect in the case of a structured design such as IEC61131-3. Moreover, since the execution object code size is used, it can be applied regardless of the PLC language.

(A), (b) is a system configuration example (part 1) and (part 2) of the PLC system of this example. It is a process flowchart figure of a development assistance apparatus. (A), (b) is a figure which shows an example of "POU call information." (A) is an example of an execution object code size, and (b) is a diagram showing an example of the total execution object code size in a list. It is an example of the load distribution result to a plurality of CPUs. (A), (b) is a figure for demonstrating the step number of an object code. It is a hardware structural example of a development assistance apparatus.

Embodiments of the present invention will be described below with reference to the drawings.
FIGS. 1A and 1B are system configuration examples (part 1) and (part 2) of a PLC (programmable controller) system of this example.

  Each of the PLC systems shown in FIGS. 1A and 1B includes a plurality of arithmetic processing units (CPUs) and a development support apparatus 10. However, in FIG. 1A, each is composed of a plurality of arithmetic modules each having an arithmetic processing unit (CPU), and FIG. 1B has a plurality of arithmetic processing units (CPU) in one arithmetic module. It has a configuration. In any case, the PLC system has a plurality of arithmetic processing units, and when executing an arbitrary application program, in order to improve the processing efficiency by distributing the load to the plurality of arithmetic processing units (CPU), It is assumed that the load is distributed to a plurality of CPUs.

The PLC system (development support apparatus) of this example does not dynamically perform load distribution during operation as described in Patent Document 1, but performs load distribution statically before operation.
In the PLC system of FIG. 1A, the development support apparatus 10 (10A) and a plurality of PLC modules 2 (calculation modules) are connected to the network 1 and can communicate with each other via the network 1. Since each PLC module 2 has one CPU 2a and CPU 2b, a plurality of arithmetic processing units (CPUs) are provided.

  On the other hand, in the PLC system of FIG. 1B, the development support apparatus 10 (10B) and one PLC module 4 are connected to the network 1 and can communicate with each other via the network 1. Since the PLC module 4 includes a plurality of CPUs 4a and 4b, a plurality of arithmetic processing units (CPUs) are provided.

Each PLC module (2 or 4) is connected to the I / O module 3.
The development support apparatus 10 (10A, 10B) of FIGS. 1A and 1B causes a user or the like to create an arbitrary application program, compiles the generated application program code, generates an execution object code, and then via the network 1 The execution object code is transferred to the PLC module 2 or 4. This transfer process is performed according to a system definition registered in advance, but this will not be described in particular.

  The development support apparatuses 10 (10A, 10B) in FIGS. 1A and 1B have some differences regarding the processing related to the transfer, but the functions related to this method are substantially the same, and therefore the same reference numerals are used. In the following description, no particular distinction is made.

1A and 1B includes a compiler 11, a linker 12, a POU size calculation function unit 13, a call information generation function unit 14, and an optimum load distribution function unit 15.
The compiler 11 and the linker 12 are general functions provided in a conventional development support apparatus, and are not specifically described here. Although not particularly shown or described, a general function provided in the conventional development support apparatus may further have a function of causing the user to create an arbitrary application. The development support apparatus 10 of this example further includes the POU size calculation function unit 13, the call information generation function unit 14, and the optimum load distribution function unit 15.

  After an arbitrary application program is created by the user, this application is converted into an execution object code by the compiler 11 or the like. The size of the execution object code is considered to be almost equal to the number of code steps in the RISC type CPU. Thus, in this method, the execution time of the program in the CPU is estimated based on the size of the execution object code, and the load is calculated.

  The call information generation function unit 14 generates “POU call information (correlation tree)” when the compiler 11 compiles the application program and stores it in a memory or the like. Since the function of the call information generation function unit 14 is an existing technology, an example of “POU call information (correlation tree)” is shown in FIGS. .

FIG. 3A is an image diagram for easy understanding of “POU call information”, and the actual data storage format is shown in FIG.
Here, in this example, a structured design of functional units such as IEC61131-3 is taken as an example. As described above, in the case of structured design, the same functional unit, function, etc. are often called from different programs.

  Here, the POU is a minimum unit of a program defined in IEC 61131-3, and is a general term for a program (PG), a function (FCT), and a function block (FB). In this example, the application program is composed of a plurality of programs (PG). In the example shown in FIGS. 3A and 3B, the five programs PG1, PG2, PG3, PG4, and PG5 are included. Shall be.

  Normally, as shown in FIGS. 3A and 3B, each program (PG) has a structure for calling one or more functions (FCT) or / and one or more function blocks (FB). . Further, the function block (FB) called from the program (PG) may call another function block (FB) or / and one or more functions (FCT).

  In any case, in this example, application processing is executed with each program (PG) of PG1, PG2, PG3, PG4, and PG5 as one "processing unit" (one grouped process). It is difficult to further divide such “processing units” and distribute / execute them to a plurality of CPUs. Therefore, when an application composed of a plurality of “processing units” such as PG1 to PG5 is executed by a plurality of CPUs, it is necessary to distribute them to the CPUs for each “processing unit” (for example, as shown in FIG. 5 later). Distributed as in the example). In this example, each program (PG) of PG1 to PG5 is a “processing unit”, but the present invention is not limited to this example.

  The “processing unit” may be broadly defined, for example, by dividing the application into a plurality of arbitrary groups as described later, and each group may be defined as a “processing unit”. As in the above examples of PG1 to PG5, those divided into groups so that it is difficult to divide further (cannot be executed normally on the CPU side) may be called “processing units”.

When each program (PG) calls various POUs such as a function (FCT) and a function block (FB), processing of the program (PG) is executed.
FIG. 3B shows a data storage example of “POU call information” only for the program PG1 as an example of the programs PG1 to PG5 shown in FIG.

  Accordingly, if the program PG1 is described in detail with reference to FIG. 3B as an example, the program PG1 sequentially calls the function FCT1, the function FCT1, the function FCT2, the function block FB1, and the function block FB1. Note that the same function / function block may be called a plurality of times as the function FCT1 is called twice consecutively for the first time.

  As shown in FIG. 3B, the POU called from the program (PG) is defined as a POU of level 1. A POU called from a POU at Tier 1 is defined as a POU at Tier 2. A POU called from a Tier 2 POU is defined as a Tier 3 POU.

  Since the program (PG) is never called, “called POU” means a POU excluding PG, and thus means FB or FCT. In other words, this means that all the POUs in the respective layers 1 to 3 are FB or FCT.

  As shown in FIG. 3B, among the POUs in the hierarchy 1, the function blocks FB1 and FB2 further call the POU. The POU to be called will be defined as the POU of level 2. That is, the function block FB1 in the hierarchy 1 calls the functions FCT1 and FCT2 in the hierarchy 2, and the function block FB2 in the hierarchy 1 calls the functions FCT1 and the function block FB3 in the hierarchy 2.

The called function block FB3 (hierarchy 2) calls the functions FCT1 and FCT2 and the function block FB4 (both hierarchies 3).
In the above example, for example, the function FCT1 is called five times in total, and the function FCT1 is executed every time it is called. Therefore, if the execution time of the function FCT1 is t1, the function related to the program PG1 The total execution time of FCT1 is “5 × t1”.

  Here, the execution time t1 of the function FCT1 may be considered to be determined by the size of the execution object code of the function FCT1 (as described above, substantially equal to the number of code steps). For example, assuming that the time required for execution of processing per step is t2, if the number of steps of FCT1 is '3' as will be described later, then t1 = 3 × t2.

  Thus, since it is considered that the correlation between the execution object code size (number of steps) and the execution time can be described by a simple calculation formula, the execution object code size (number of code steps) is calculated. The execution time for each “processing unit” of the application program created by the user (for example, for each program (PG)) can be estimated. The magnitude of the load on each CPU can be estimated as processing time (execution time of all assigned PGs).

  The POU size calculation function unit 13 calculates and stores the size (≈code step number) of the execution object code of each POU (PG / FB / FCT) of the application. In the case of the application example shown in FIG. 3A, as shown in FIG. 4A, the size of each program PG1 to PG5, the size of each function block FB1, FB2, FB3, FB4, the function FCT1, The sizes of FCT2 and FCT3 are obtained.

The POU size calculation function unit 13 itself is an existing function provided in a general compiler, and will not be described in more detail.
Here, FIG. 2 shows a process flowchart of the development support apparatus 10.

  The development support apparatus 10 first executes the execution object code generation process at any time after an arbitrary application program is generated (step S11). When generating the execution object code, as described above, the POU size calculation function unit 13 obtains and stores the size (≈code step number) of each execution object code for each POU (PG / FB / FCT), and generates call information. The functional unit 14 generates and stores “POU call information (correlation tree)”. The function for generating the “POU call information (correlation tree)” is also an existing function provided in a general compiler, and will not be described in further detail.

  In this way, the processing of step S11 (execution object code generation by compilation, generation / storage of execution object code size, and generation / storage of “POU call information (correlation tree)”) is executed by a general compiler. Think of it as an existing process.

The characteristic function of this method is in the processing of the next step S12 and step S13. The optimum load distribution function unit 15 executes the processes of steps S12 and S13.
First, in step S12, for each program (PG), the total execution object code size (total execution object code size) of the PG is obtained by the following equation (1).

  The “number of calls” in the above equation (1) may be replaced with “the number of executions”, for example. This is because the total execution object code size according to the above equation (1) includes the size of the program (PG) itself, but the program (PG) itself is not called as described above.

  For example, the total execution time of the function FCT1 related to the program PG1 has already been described as “5 × t1”. In the above equation (1), the size of the execution object code of the function FCT1 (≈the number of code steps) is used instead of t1. You can think of it as being used. The size of the execution object code (≈code step number) of each POU is obtained and stored by the POU size calculation function unit 13 (FIG. 4A), and this can be referred to.

  In the example shown in FIG. 3B, the POU called for the program PG1 is the function blocks FB1, FB2, and FB3, and the functions FCT1, FCT2, and FCT4. Times, FB2 once, FB3 once, FCT1 five times, FCT2 three times, FCT4 one time, and the number of executions (one time) of the program PG1 itself is added.

  Here, it is assumed that “<POU>; represents the object code size of POU”. That is, the size of the execution object code (≈ number of code steps) of each POU is expressed as, for example, <PG1> for PG1, <FB1> for FB1, and <FCT1> for FCT1. If the size of the execution object code (≈code step number) of each POU (PG / FB / FCT) is as shown in FIG. 4A, the total of the program PG1 according to the above equation (1) is assumed. The execution object code size (total number of execution object code sizes) is calculated as follows.

Total execution object code size of program PG1 = <PG1> × 1 + <FB1> × 1 + <FB2> × 1 + <FB3> × 1 + <FB4> × 1 + <FCT1> × 5 + <FCT2> × 3
= 10 × 1 + 6 × 1 + 7 × 1 + 8 × 1 + 3 × 5 + 1 × 3 + 6 × 1
= 55
Similarly, for each of the other programs PG2, PG3, PG4, and PG5, the “POU call information” shown in FIG. 3A and the size of the execution object code of each POU shown in FIG. When the total execution object code size is calculated by the above equation (1), the result is as shown in FIG.

  When the optimum load distribution function unit 15 obtains the information shown in FIG. 4B (the total number of execution object code sizes for each program (PG) constituting the application program), a plurality of CPUs are based on the total size information. The programs (PG1 to PG5) are assigned so that the processing load is substantially equal to the program (step S13). An example of the assignment result is shown in FIG.

  In the example shown in FIG. 5, programs PG1 and PG5 are assigned to CPU1, and programs PG2, PG3, and PG4 are assigned to CPU2. Since the total execution object code size of each program PG1 to PG5 is as shown in FIG. 4B, the total execution object code size assigned to the CPU 1 is 55 + 7 = 62, and the execution object code size assigned to the CPU 2 is the total. 25 + 18 + 16 = 59, so that the processing load on the CPU 1 and the processing load on the CPU 2 are almost the same (substantially equal). That is, it can be considered that almost optimal load distribution has been performed.

  Then, according to the assignment result of each program (PG1 to PG5) to each CPU determined in step S13, memory allocation of each program (PG1 to PG5) is performed (step S14). For example, in the example of FIG. 5, the programs PG1 and PG5 are transmitted to the CPU 1 and stored in the memory thereof, and the programs PG2, PG3 and PG4 are transmitted to the CPU 2 and stored in the memory and the like. Note that the process of step S14 may also be executed by the optimum load distribution function unit 15, and the process of step S14 may be performed by other function units (not shown). (Not described) may be executed.

  Note that the CPU 1 and the CPU 2 may be considered to correspond to the CPU 2a and the CPU 2b in the example illustrated in FIG. Alternatively, the CPU 1 and the CPU 2 may be considered to correspond to the CPU 4a and the CPU 4b in the example illustrated in FIG.

  If the execution order of the programs (PG1 to PG5) is determined, for example, information indicating the PG execution order on the development support apparatus 10 side (referred to as an execution order table; not shown). For example, this execution order table may be stored in the memory of the CPU 1 and the memory of the CPU 2 in the process of step S14. Thereby, for example, the CPU 1 may execute PG5 first and then execute PG1 later.

  The method of assigning each program to a plurality of CPUs based on the total execution object code size for each program (PG) may be various methods. An example will be described below, but the method is not limited to these examples. Absent.

That is, for example,
(1) A method of sequentially assigning to each CPU in order from a program (PG) having a large load (size).

  For example, in the example shown in FIG. 4B, when programs (PG) having a large load (size) are sequentially allocated, the programs (PG) are sequentially allocated in the order of PG1, PG2, PG3, PG4, and PG5. Become.

  Here, for example, as an example, PGs are first assigned to each CPU in order from the largest load (size), and then the next PG (remaining) is assigned to the CPU with the smallest total amount of current load (size). A method of allocating PG) having the largest size among them is conceivable.

  According to this method, in the example shown in FIG. 4B, PG1 is initially assigned to CPU1 and PG2 is assigned to CPU2. Thereafter, PG3 is assigned to CPU2, and subsequent PG4 is also assigned to CPU2 (because the total load allocation amount at that time is CPU1> CPU2). Finally, PG5 is assigned to CPU1 (since the total amount of load assigned at that time is CPU1 (= 55) <CPU2 (= 25 + 18 + 16 = 59)).

By such an allocation process, the result shown in FIG. 5 is obtained.
In this manner, for example, as shown in FIG. 5, each program (PG) constituting the application program is distributed to a plurality of CPUs so that the processing load of the CPU 1 and the processing load of the CPU 2 are almost the same (substantially equal). Can be assigned.

(2) A method of obtaining an average value (average load distribution value) of the total assigned load and assigning each program (PG) until the average value is exceeded for each CPU.
For example, first, an average value of the total load allocated to each CPU is calculated. This obtains the total sum of the total execution object code sizes of all the programs PG1 to PG5. In the example of FIG. 4B, the sum = 55 + 25 + 18 + 16 + 7 = 121.

  By dividing this total by the number of CPUs, the average value of the total load allocated to each CPU is calculated. If the assignment is made to the two CPUs CPU1 and CPU2 as in the example of FIG. 5, the average value = 121 ÷ 2 = 60.5.

  For example, first, a program (PG) is assigned to the CPU 1 until the average value (= 60.5) is exceeded. As an example, each program (PG) is randomly assigned. However, the present invention is not limited to this example, and may be described below, for example.

  That is, a program (PG) having a large load (size) is assigned sequentially. However, unlike the above (1), allocation is concentrated to one CPU until the average value is exceeded. Furthermore, the program (PG) assigned when the average value is exceeded is not completed when the average value is exceeded, and the program (PG) assigned when the average value is exceeded is replaced with another program (PG) that has not yet been assigned. Decide on something close.

  That is, when PG1 is first assigned to CPU1, and then PG2 is assigned, the total size exceeds 55 + 25 = 80, and thus exceeds the average value (= 60.5). Here, when other programs PG3, PG4, and PG5 that have not yet been assigned are sequentially assigned instead of PG2, the total size in the case of PG3 = 55 + 18 = 73, the total size in the case of PG4 = 55 + 16 = 71, and the case of PG5 The total size = 55 + 7 = 62, and since the case of PG5 is closest to the average value, PG1 and PG5 are assigned to the CPU1.

(3) A method defined as a combinatorial optimization problem and solved using an optimization method (empirical method, metaheuristic, etc.).
This optimization method itself is an existing general method, and is not particularly described here. However, according to this method, when the load size varies or the number of loads becomes enormous, Even in such a case, the optimum load distribution can be obtained.

  Further, the program (PG) may be assigned to a plurality of CPUs by combining the above three methods (1), (2), and (3). For example, in the example of FIG. 4B, first, PG1 having the largest size is assigned to CPU1 by the method (1), and PG2 having the second largest size is assigned to CPU2. Thereafter, by combining one or more of the remaining PG3, PG4, and PG5 with PG1 or PG2 as appropriate, various combinations are created and the total size of the created combinations (for example, the total size is 55 + 18 for the combination of PG1 and PG3) = 73). Then, a combination in which the difference between the total size and the average load distribution value (= 60.5) is minimized is obtained.

  In addition, in the load distribution when the number of loads becomes enormous, the influence of one load on the entire load is reduced. Therefore, it is also effective to perform the methods (1) and (2) independently. it is conceivable that.

  In this example, “POU call information” is used, but it is not necessary to know “which POU called which POU”. As described above, each program (PG) is related to the PG. It is only necessary to know the number of times each POU is executed. In this example, “POU call information” generated by the call information generation function unit 14 which is an existing function is used, but the present invention is not limited to such an example. In any case, the information does not necessarily need to be “POU call information”, and may be any information as long as the number of executions of each POU is known.

  IEC-61131-3 has a concept of centrally managing a process execution unit that executes one application as a resource. If the target to which the application load is distributed corresponds to a plurality of CPU modules 2 as shown in FIG. 1A, the execution object code size is calculated as described above, assuming that it is a single execution processing unit. Thereafter, load distribution is performed by a method of assigning execution objects to the CPU modules 2.

  This is also possible when the load is distributed to an arithmetic device having, for example, a multi-core microprocessor or a coprocessor such as the CPU module 4 in FIG. 1B. However, a plurality of CPUs 4a and 4b in one CPU module 4 in FIG. 1B are assumed to be microprocessors or arithmetic LSIs having the same performance for executing the same execution code, and the user application to be compiled is It is assumed that the execution results of each function are not mutually referenced.

  A specific example of the number of steps of the object code will be described with reference to FIG. In FIG. 6, FIG. 6 (a) shows a programming screen and shows an arbitrary program component (here, an ADD function). By compiling this program part, an execution object code (portion surrounded by a dotted line) shown in FIG. 6B is generated. As shown in the figure, the number of steps of this execution object code is '9' (9th line; 9th step).

Further, the development support apparatus 10 of this example can be realized by a general-purpose computer device such as a personal computer in terms of hardware.
FIG. 7 is a diagram illustrating a specific example of the hardware configuration of the development support apparatus, which may be considered as the configuration of a general-purpose computer such as a personal computer.

  In FIG. 7, the computer 30 includes a CPU 31, a memory 32, an input unit 33, an output unit 34, a storage unit 35, a recording medium drive unit 36, and a network connection unit 37, which are connected to a bus 38. It has become.

The CPU 31 is a central processing unit that controls the entire computer 30.
The memory 32 is a memory such as a RAM that temporarily stores a program or data stored in the storage unit 35 (or the portable recording medium 39) when executing arbitrary processing. The CPU 31 executes the various processes described above using the program / data read into the memory 32.

The output unit 34 is, for example, a display, and the input unit 33 is, for example, a keyboard, a mouse, or the like.
The network connection unit 37 is a communication module that is connected to, for example, the network 1 and performs communication (command / data transmission / reception, etc.) with other information processing apparatuses (CPU modules 2, 4 and the like).

  The storage unit 35 is, for example, a hard disk or the like, and stores application programs for causing the CPU 31 to realize the various processing functions of the development support apparatus 10 described above. That is, an application program for realizing the processing functions of the various processing function units of the compiler 11, the linker 12, the POU size calculation function unit 13, the call information generation function unit 14, and the optimum load distribution function unit 15 by the CPU 31 is stored. ing.

The CPU 31 implements the various processes described above by reading and executing various programs stored in the storage unit 35.
The various information shown in FIG. 3B, FIG. 4A, and FIG. 4B is stored in the storage unit 35, the memory 32, and the like.

  Various programs / data stored in the storage unit 35 may be stored in the portable recording medium 39. In this case, the program / data stored in the portable recording medium 39 is read by the recording medium driving unit 36. The portable recording medium 39 is, for example, an FD (flexible disk) 39a, a CD-ROM 39b, a DVD, a magneto-optical disk, or the like.

  Alternatively, the program / data may be downloaded from another device via a network connected by the network connection unit 37. Or you may further download what was memorize | stored in the external other apparatus via the internet.

  In addition, the present invention can be configured not only as a portable storage medium recording a program for realizing the various processes of the present invention on a computer, but also as the program itself.

  The above description is an example, and the present invention is not limited to this example. The application created by the user may be a program using a ladder diagram, for example. This is because this method uses a compiled program (execution object code; machine language), so it does not matter what PLC language the user uses. Then, by using the size (number of steps) of the execution object code, it is possible to accurately estimate the load, thereby realizing almost optimal load distribution.

  If the functions of the development support apparatus 10 of the present example are schematically described regardless of the PLC language, it can be said that the development support apparatus 10 of the present example includes the following various functional units, although not particularly illustrated.

  First, a compile function unit (not shown) that generates an execution object code by compiling an arbitrary application program to be operated by a plurality of operation processing units (CPUs) is provided.

  Further, for example, the application program is divided into a plurality of groups (here, particularly, the above “processing unit” as an example). This is determined and set by a developer, for example.

  The development support apparatus 10 further includes a total execution object code size calculation function unit (not shown) that calculates the total number of execution object code sizes related to the “processing unit” for each of the plurality of “processing units”. . Furthermore, it is a functional unit that distributes the processing of the application program to a plurality of arithmetic processing units (CPUs) in each “processing unit”, and the total number of execution object codes for each “processing unit” (total number of steps, etc.) ), A load distribution function unit (not shown) that distributes the processing of the application program to each arithmetic processing unit so that the loads of the plurality of arithmetic processing units are substantially equal.

Thus, it can be said that the development support apparatus 10 of the present example is roughly provided with the various functional units (not shown).
Since the prior art described in Patent Document 1 is a dynamic load distribution method performed at the time of system operation, when the initial load distribution is inappropriate, the load on the CPU is biased when the system is started. There is a possibility that the punctuality required in the PLC system may be impaired. In this regard, this method, which is a static load distribution method, can perform highly reliable operation from the time of system startup.

  The prior art described in Patent Document 2 is a static load distribution method performed when the system is not operating, and is similar to this method in this respect. However, Patent Document 2 uses the feature of SFC. However, it cannot be applied to other languages, and there arises a big problem that it cannot cope with a ladder language, which is a language most frequently used in the field of PLC.

  On the other hand, in this method, execution object code (machine language, etc.) generated by compiling a program written in some PLC language is used regardless of the PLC language used by a programmer such as SFC or ladder language. Since load distribution is performed using any of them, the present invention can be applied regardless of the PLC language. In other words, this technique is more versatile than the conventional technique described in Patent Document 2.

  As described above, according to this method, in a PLC system having a plurality of CPUs, applications can be executed with an optimal load distribution from the time of starting the system, and the present invention can be applied without depending on the PLC language. Benefits.

  According to the PLC system to which the present method is applied, it is possible to automatically (almost from the initial stage of operation) load distribution to a plurality of CPUs. System development time can be shortened. In addition, almost optimal load distribution can be automatically performed at the time of compilation, so that stable operation can be performed without depending on the know-how of the user, and the reliability of the system can be improved.

  In addition, as already mentioned, the PLC application is not a program with a simple structure described in a processing unit in a conventional ladder language or the like, but a structured design of a functional unit using multiple languages such as IEC61131-3. As a result, it has become difficult for the user to grasp the overall flow of processing. In the case of structured design, the same functional unit, function, and the like are often called from different programs, and the program creator has developed a number of developments.

  In such a situation, it is difficult for an application program creator or the like to distribute loads to multiple CPUs on their own, resulting in a decrease in total system processing performance due to processing load imbalance, and system startup. The increase in man-hours when raising can be considered. On the other hand, this method can solve such a problem because it can automatically perform almost optimal load distribution even for such a high degree of difficulty.

  Note that “the number of man-hours at the time of starting the system” means a user's trouble of allocating an application to a plurality of arithmetic processing units (CPU and the like). This method can reduce the man-hours required to start up such a system.

1 Network 2 PLC module 2a, 2b CPU
3 I / O module 4 PLC module 4a, 4b CPU
DESCRIPTION OF SYMBOLS 10 Development support apparatus 11 Compiler 12 Linker 13 POU size calculation function part 14 Call information generation function part 15 Optimal load distribution function part 30 Computer 31 CPU
32 memory 33 input unit 34 output unit 35 storage unit 36 recording medium drive unit 37 network connection unit 38 bus 39 portable recording medium 39a FD (flexible disk)
39b CD-ROM

Claims (5)

A PLC system having a development support apparatus and a plurality of arithmetic processing units, and distributing and executing a load related to execution of an arbitrary application among the plurality of arithmetic processing units,
The development support apparatus includes:
Compiling means for generating executable object code by compiling the application;
For each of a plurality of processing units constituting the application, a total execution object code size calculating means for obtaining a total number of the sizes of the execution object codes related to the processing units;
Means for allocating the processing of the application to the plurality of arithmetic processing units in each processing unit, based on a total number of execution object code sizes of each processing unit calculated by the total execution object code size calculation means; Load distribution means for allocating the processing of the application to the arithmetic processing units so that the loads of the arithmetic processing units are substantially equal;
A PLC system characterized by comprising: A PLC system having a development support apparatus and a plurality of arithmetic processing units, and distributing and executing a load related to execution of an arbitrary application composed of a plurality of programs and various POUs called from the programs in the plurality of arithmetic processing units Because
The development support apparatus includes:
Compiling means for generating executable object code by compiling the application;
POU size calculation means for determining the size of the execution object code for each of the POUs;
Call information generating means for obtaining call information of the POU at the time of compilation;
Based on the size of the execution object code of each POU and the call information of the POU, for each program constituting the application, the size of the execution object code and the number of executions of each POU related to the program are determined. Total execution object code size calculating means for calculating the total number of execution object code sizes;
Means for allocating each program to the plurality of arithmetic processing units, based on a total number of execution object code sizes of the programs calculated by the total execution object code size calculating unit; Load distribution means for distributing the programs to the arithmetic processing units so that the load is substantially equal;
A PLC system characterized by comprising:   3. The development support apparatus according to claim 1, wherein the size of the execution object code is the number of steps of the execution object code. A development support apparatus in a PLC system having a development support apparatus and a plurality of arithmetic processing units, and distributing and executing a load related to execution of an arbitrary application among the plurality of arithmetic processing units,
Compiling means for generating executable object code by compiling the application;
For each of a plurality of processing units constituting the application, a total execution object code size calculating means for obtaining a total number of the sizes of the execution object codes related to the processing units;
Means for allocating the processing of the application to the plurality of arithmetic processing units in each processing unit, based on a total number of execution object code sizes of each processing unit calculated by the total execution object code size calculation means; Load distribution means for allocating the processing of the application to the arithmetic processing units so that the loads of the arithmetic processing units are substantially equal;
A development support apparatus in a PLC system, characterized by comprising: The PLC system includes a development support apparatus and a plurality of arithmetic processing units, and distributes a load related to execution of an arbitrary application including a plurality of programs and various POUs called from the programs to the plurality of arithmetic processing units. A development support device,
Compiling means for generating executable object code by compiling the application;
POU size calculation means for determining the size of the execution object code for each of the POUs;
Call information generating means for obtaining call information of the POU at the time of compilation;
Based on the size of the execution object code of each of the POUs and the call information of the POU, for each program constituting the application, execution according to the execution object code size and the number of executions of each POU related to the program Total execution object code size calculating means for calculating the total object code size;
Means for allocating each program to the plurality of arithmetic processing units, based on a total number of execution object code sizes of the programs calculated by the total execution object code size calculating unit; Load distribution means for distributing the programs to the arithmetic processing units so that the load is substantially equal;
A development support apparatus in a PLC system, characterized by comprising: