JP5726106B2 - Embedded system controller - Google Patents

Description

  The present invention relates to an embedded system control device.

  Currently, embedded systems are used in many industrial and consumer devices. An embedded system is a generic term for computer systems that realize specific functions, and is a computer system that consists of hardware and programs that cannot be selected and replaced, and that satisfy the necessary and sufficient conditions for realizing specific functions. It can be said that there is.

  An example of the flow of software development for embedded systems is roughly as follows. (1) Creation of program configuration (2) Modularization of program and creation of detailed specifications (3) Design for each module (4) Verification of each module by prototype (5) Modification and correction for each module (6) Prototype (7) Final change / correction of entire program.

  Development of software for an embedded system is usually performed using a PC (Personal Computer) or the like, and the developed software is introduced and executed on target hardware different from the PC. The software development environment is generally an editor for describing a source program in a high-level language such as C language or an assembly language, and the source program is converted into a machine language program corresponding to the CPU (Central Processing Unit) of the target hardware. And a compiler for.

  The present applicant has proposed a graphical program development environment described in Patent Document 1 with the aim of improving program development efficiency. In this environment, a graphical programming language with a graphical representation of control content is used.

JP 2009-271768 A

Mitsubishi general-purpose sequencer C language controller unit Quick Start Guide, [online], Mitsubishi Electric Corporation, Internet <URL: http://wwwf2.mitsubishielectric.co.jp/melfansweb/document/catalog/plc/l08206/l08206a.pdf>

  As described above, many kinds of programming languages can be used in software development of embedded systems, and a situation in which they are mixed may occur. One technique for generating a program to be downloaded to a target from a number of programs written in a number of programming languages is to link them statically using a linkage editor. That is, each of a large number of programs is processed by a corresponding compiler or assembler, and all the obtained object files (intermediate files) are combined into one file (executable file).

  For example, when C language and assembly language are mixed, a general-purpose editor is used to create a C source program written in C language and an assembler source program written in assembly language. A first intermediate file is generated by processing the C source program with a C language compiler. Further, the second intermediate file is generated by processing the assembler source program by the assembler. Then, the first intermediate file and the second intermediate file are combined using the linkage editor to generate one executable file.

  However, in this case, the generated executable files are collectively and it is difficult to replace each module. Therefore, modularization of options and the like is difficult.

  Also, for example, in a development environment that mainly uses a graphical programming language as described in Patent Document 1, when trying to reuse a program that has been developed in C language, the user uses the graphical programming program. It is necessary to rewrite by language. However, such rewriting is troublesome, and mistakes can occur during the rewriting process. Therefore, even if the user holds a program written in C language or the like other than the graphical programming language as an asset, it is difficult to effectively use it.

  For example, as described in Non-Patent Document 1, it is conceivable to provide a large number of CPUs in an embedded system (multi-CPU system). However, in this case, the units that execute each language are separated, and it is difficult to adopt a configuration in which they are closely coupled. Therefore, it is difficult to realize high-speed mutual access between a plurality of languages.

  The present invention has been made in view of these problems, and an object of the present invention is to provide an execution environment in which a graphical programming language and a text programming language such as C language can be used in an embedded system software development environment. On offer.

  One embodiment of the present invention relates to a control device. This control device is a control device of an embedded system, which is generated using a programming language accompanied by a graphical representation of control contents, and has a first area in which a first program executable by the control device is arranged, and a text A second area in which a second program that is generated using a programming language in the form and is executable by the present control device is arranged; first resource information relating to resources of the first program; and second resources relating to resources of the second program And a memory including a third area in which middleware for holding information is arranged, and an arithmetic unit shared by the first program and the second program. Either the first program or the second program uses the resources of the other program. The middleware mediates access from one program to the other program's resources.

  According to this aspect, the first program and the second program can coexist in the control device.

  It should be noted that any combination of the above-described constituent elements, or those obtained by replacing the constituent elements and expressions of the present invention with each other between apparatuses, methods, systems, computer programs, recording media storing computer programs, and the like are also included in the present invention. It is effective as an embodiment of

  According to the present invention, it is possible to provide an execution environment in which a graphical programming language and a text programming language such as C language can be used together in a software development environment of an embedded system.

It is a schematic diagram which shows the flow from the development of the program introduced into the control apparatus of the embedded system which concerns on embodiment to mounting. It is a schematic diagram which shows the control part system structure of the automatic guided vehicle to which the technical idea which concerns on this Embodiment was applied. It is a schematic diagram which shows the control part system structure of the automatic guided vehicle to which the technical idea which concerns on this Embodiment is not applied. It is a schematic diagram which shows the software structure of the injection molding machine to which the technical idea which concerns on this Embodiment was applied. It is a schematic diagram which shows the software structure of the injection molding machine to which the technical idea which concerns on this Embodiment is not applied. It is a schematic diagram which shows the execution form at the time of product operation.

  Hereinafter, the same or equivalent components, members, and processes shown in the drawings are denoted by the same reference numerals, and repeated description is appropriately omitted.

  The embedded system control apparatus according to the embodiment includes a mutual program between an execution program generated using a graphical programming language and an execution program generated using a text programming language such as C language. Middleware that provides access to other resources (for example, variables and functions) is introduced. This middleware manages the resource information of both execution programs by implementing the memory allocation of each execution program.

  As a result, on the development environment side, the source program described in each programming language can be converted into an executable file and downloaded to the control device as it is. As a result, there is no need to rewrite the source program written in the C language in the graphical programming language, so that the user can enjoy the benefits of improving the efficiency of program development by using the graphical programming language, and the existing program. Assets can be used more effectively.

  FIG. 1 is a schematic diagram showing a flow from development to implementation of a program installed in the control device 100 of the embedded system according to the embodiment. This flow is realized by the development environment 2 on the host PC and the execution environment 4 on the target.

The development environment 2 includes a graphical editor 6, a graphical compiler 10, a first C compiler 14, a C editor 18, and a second C compiler 22.
The graphical editor 6 is an editor that uses a graphical programming language with a graphical representation of control contents. The user uses the graphical editor 6 to generate a graphical source program 8 in which desired control contents are described. At this time, the user may include a reference to the resource of the second C source program 20 in the graphical source program 8. The graphical compiler 10 converts the graphical source program 8 into a first C source program 12 written in C language. The processing related to the graphical editor 6, the graphical source program 8, and the graphical compiler 10 may be realized based on, for example, the technique described in Patent Document 1.

  The first C compiler 14 is a known C language compiler, and converts the first C source program 12 into a graphical execution file 16 that is an object file in a format executable by the control device 100. The graphical compiler 10 and the first C compiler 14 cooperate to incorporate graphical resource information regarding the resources of the graphical executable file 16 into the graphical executable file 16.

The C editor 18 is a known text editor. The user uses the C editor 18 to generate the second C source program 20 in which desired control contents are described in C language.
The second C compiler 22 is a known C language compiler, and converts the second C source program 20 into a C execution file 24 that is an object file in a format executable by the control device 100. The second C compiler 22 incorporates symbol information (for example, a symbol table) regarding the symbols of the C execution file 24 into the C execution file 24.

  The execution environment 4 includes the control device 100 of the embedded system according to the embodiment. The control device 100 includes a memory 102, a CPU 104, an input / output interface 106, and a control device bus 108 that connects them to each other within the control device 100.

  The memory 102 includes a first area in which the graphic execution program 110 corresponding to the graphic execution file 16 is arranged, a second area in which the C execution program 114 corresponding to the C execution file 24 is arranged, and the graphic execution program A third area in which middleware 112 holding 110 graphical resource information and C execution program 114 symbol information is arranged.

The CPU 104 is shared by the graphical execution program 110, the C execution program 114, and the middleware 112, and performs a processing operation based on each of them. The CPU 104 performs predetermined processing according to the flow of instructions included in each of the graphical execution program 110, the C execution program 114, and the middleware 112.
The input / output interface 106 controls data input / output between the control device 100 and a device external to the control device 100.

  Hereinafter, the function of the middleware 112 for each of (1) when the graphical execution program 110 uses the resource of the C execution program 114 and (2) when the C execution program 114 uses the resource of the graphical execution program 110 Will be explained.

  (1) When the graphical execution program 110 uses the resource of the C execution program 114, the middleware 112 mediates access to the resource of the C execution program 114 from the graphical execution program 110.

  When the C execution file 24 is downloaded to the control device 100, the middleware 112 places the C execution program 114 corresponding to the C execution file 24 in the second area of the memory 102. At this time, the middleware 112 acquires symbol information of the C execution file 24 incorporated in the C execution file 24.

  When the graphical execution file 16 is downloaded to the control device 100, the middleware 112 places the graphical execution program 110 corresponding to the graphical execution file 16 in the first area of the memory 102. At this time, the middleware 112 replaces the access to the resource of the C execution program 114 in the graphical execution program 110 with the corresponding symbol information. That is, when the graphical execution program 110 includes access to the resource of the C execution program 114, the middleware 112 extracts symbol information corresponding to the resource from the acquired symbol information. The middleware 112 replaces the access to the resource of the C execution program 114 included in the graphical execution program 110 with the extracted symbol information.

  Thus, the middleware 112 mediates access to the resources of the C execution program 114 from the graphic execution program 110 at the stage of downloading the graphic execution file 16. When the graphical execution program 110 is executed in the control device 100, the graphical execution program 110 directly accesses the resources of the C execution program 114 without depending on the middleware 112.

  (2) When the C execution program 114 uses the resource of the graphic execution program 110, the middleware 112 mediates access to the resource of the graphic execution program 110 from the C execution program 114.

  When the graphical execution file 16 is downloaded to the control device 100, the middleware 112 places the graphical execution program 110 corresponding to the graphical execution file 16 in the first area of the memory 102. At this time, the middleware 112 acquires graphic resource information of the graphic execution file 16 incorporated in the graphic execution file 16.

  The middleware 112 includes an application programming interface (hereinafter referred to as API) related to the acquired graphical resource information. The API enables access to the resources of the graphic execution program 110 from programs other than the graphic execution program 110 based on the acquired graphic resource information.

  When the C execution file 24 is downloaded to the control device 100, the middleware 112 places the C execution program 114 corresponding to the C execution file 24 in the second area of the memory 102. When the C execution program 114 is executed in the control device 100, the C execution program 114 accesses the resources of the graphical execution program 110 through the API.

  According to the control device 100 according to the present embodiment, the graphic execution program 110 developed by the graphic programming language and the C execution program 114 developed by the C language can be operated in the same execution environment 4. Information can be shared between the execution programs 110 and 114. In addition, execution units can be called between the execution programs 110 and 114.

  Further, during the transition from a development environment based on the C language to a more efficient development environment based on a graphical programming language, both languages are often mixed in the development environment. Therefore, when the control device 100 according to the present embodiment is used, the program can be smoothly developed even in such a development environment.

  Further, in the control device 100 according to the present embodiment, the graphic execution program 110 and the C execution program 114 share the CPU 104, thereby realizing tight coupling. Therefore, compared to the case of coarse coupling in which each uses a different CPU, it is not necessary to switch the CPU and memory when accessing the resource of the other program from one program, so that a higher speed operation is possible. It becomes possible.

(Application to automated guided vehicle)
FIG. 2 is a schematic diagram showing a control unit system configuration of the automatic guided vehicle to which the technical idea according to the present embodiment is applied. The first controller 202 and the second controller 204 are connected to the system bus 206. The first controller 202 is installed with a sequence control program 208 generated using C language, a transfer servo control program 210 generated using a graphical programming language, and middleware 214. ing.

The sequence control program 208 and the transfer system servo control program 210 use the same CPU (not shown) in the first controller 202. The middleware 214 controls mutual access of resources between the sequence control program 208 and the transfer servo control program 210. Thereby, the sequence control program 208 and the transfer servo control program 210 can coexist in the same first controller 202.
A traveling system servo control program 212 generated using a graphical programming language is installed in the second controller 204.

  FIG. 3 is a schematic diagram showing a control unit system configuration of the automatic guided vehicle to which the technical idea according to the present embodiment is not applied. The first controller 302, the second controller 304, and the third controller 306 are connected to the system bus 308. A transfer servo control program 310 generated using a graphical programming language is installed in the first controller 302. A traveling system servo control program 314 generated using a graphical programming language is installed in the second controller 304. A sequence control program 312 generated using C language is installed in the third controller 306.

  Since the middleware as shown in FIG. 2 does not exist in the configuration shown in FIG. 3, the transfer servo control program 310 and the sequence control program 312 cannot be operated on the same controller, and separate controllers are used. Will be installed on. Alternatively, the sequence control program 312 needs to be rewritten using a graphical programming language.

  As described above, when the technical idea according to the present embodiment is applied, programs having different languages can be operated on the same controller, so that the number of necessary controllers can be reduced. As a result, the cost of the automatic guided vehicle can be reduced. In addition, it is not necessary to prepare a new controller when introducing other proven programs generated using the C language.

(Application to injection molding machines)
FIG. 4 is a schematic diagram showing a software configuration of an injection molding machine to which the technical idea according to the present embodiment is applied. This software configuration includes an OS (Operating System) 402, middleware 404, a common control program 406, an option A program 408, an option B program 410, and an option C program 412. The middleware 404 operates on the OS 402. The common control program 406, option A program 408, option B program 410, and option C program 412 all operate on the middleware 404. The common control program 406 is generated using the C language, and the option A program 408, the option B program 410, and the option C program 412 are all generated using the graphical programming language.

  For example, when the option C program 412 is replaced with the software configuration shown in FIG. 4, the option C program 412 is deleted, and the option C ′ program 414 generated using the graphical programming language is newly added. Just install it. For example, when an option is added to the software configuration shown in FIG. 4, an option D program 416 generated using a graphical programming language may be newly installed.

  FIG. 5 is a schematic diagram showing a software configuration of an injection molding machine to which the technical idea according to the present embodiment is not applied. This software configuration includes an OS 502, a common control program 504, an option A program 506, an option B program 508, and an option C program 510. The common control program 504 operates on the OS 502. The option A program 506, option B program 508, and option C program 510 all operate on the common control program 504. The common control program 504, option A program 506, option B program 508, and option C program 510 are all generated using the C language. It is difficult to add a new option program generated using a graphical programming language to the software configuration shown in FIG.

  In the software configuration of the injection molding machine to which the technical idea according to the present embodiment is applied, the optional part can be programmed more easily due to the presence of the middleware 404 that allows the graphical programming language and the C language to coexist. It can be created with a simple graphical programming language. Thereby, for example, the optional part can be disclosed while hiding the algorithm of the common control program. In addition, it becomes easier to add or change optional parts by frontline service persons such as overseas. Thereby, it is possible to provide a service closer to the customer.

  The control device 100 of the embedded system according to the embodiment has been described above. This embodiment is an exemplification, and it is understood by those skilled in the art that various modifications can be made to each component and combination of processes, and such modifications are within the scope of the present invention.

  Graphical programming languages are relatively suitable for machine control programs. On the other hand, communication software between computers has many assets of a conventional language such as C language. Therefore, the technical idea according to the embodiment can be preferably applied to an application that connects a mechanical device to a network.

In the embodiment, the execution form at the time of program development has been described with reference to FIG. 1, but the present invention is not limited to this.
FIG. 6 is a schematic diagram showing an execution form during product operation. The control device 100 further includes a secondary storage device 120. The secondary storage device 120 may be a disk device such as a hard disk drive or a flash disk. The secondary storage device 120 is connected to the control device bus 108. The secondary storage device 120 includes a graphical execution file 16 and a C execution file 24. There is no host PC during product operation, and the graphic execution program 110 and the C execution program 114 are arranged in the memory 102 from the graphic execution file 16 and the C execution file 24 stored in the secondary storage device 120, respectively. Note that the location of the object file only changes, and the processing flow is the same as that of the embodiment.

  2 development environment, 4 execution environment, 6 graphical editor, 8 graphical source program, 10 graphical compiler, 12 1st C source program, 14 1st C compiler, 16 graphical execution file, 18 C editor, 20 2nd C source program , 22 2C compiler, 24 C execution file, 100 controller, 102 memory, 104 CPU, 106 I / O interface, 110 graphical execution program, 112 middleware, 114 C execution program.

Claims (6)

A controller for an embedded system,
A first region in which a first program that is generated using a programming language accompanied by a graphical representation of control content and that can be executed by the control device is arranged;
A second area in which a second program generated using a text programming language and executable by the controller is arranged;
A third area in which middleware that holds first resource information related to resources of the first program and second resource information related to resources of the second program is arranged;
An arithmetic unit shared by the first program and the second program,
Either the first program or the second program uses the resources of the other program,
The middleware mediates access from one program to the other program's resources ,
The first program is a plurality of servo control program, the second program control device, wherein a sequence control program der Rukoto. The second resource information is symbol information related to symbols of the second program,
The first program uses the resources of the second program,
2. The control device according to claim 1, wherein the middleware replaces access to the resource of the second program with corresponding symbol information when the first program is arranged in the first area.   The control apparatus according to claim 2, wherein the middleware acquires symbol information when the second program is arranged in the second area. The first resource information is incorporated into the first program when the first program is converted into a format executable by the control device,
The second program uses the resources of the first program,
The middleware includes an application programming interface associated with the first resource information,
4. The control apparatus according to claim 1, wherein the second program accesses the resource of the first program through an application programming interface.   The control apparatus according to claim 4, wherein the middleware acquires the first resource information when the first program is arranged in the first area. The middleware mediates access from one program to the resource of the other program at the stage of downloading the first program and the second program to the control device. The control device described in 1.

Images