Patent Description:
FA technology using a control device such as a programmable logic controller (PLC) is widely used in various production sites. With the development of information and communication technology (ICT) in recent years, control devices in the FA field are becoming more sophisticated and highly functional.

Along with this, in the development of various programs related to FA control, for example, there is a desire to use an external control provided in the development environment of the application program compatible with the operating system (OS) of Windows (registered trademark) as user interface (UI) elements that configure an application program compatible with non-Windows OS for FA. For example, there is a desire to use an external control as UI elements that configure a human-machine interface (HMI) program for providing a UI screen for monitoring or controlling the state of a field device via a control device.

Patent Document <NUM> (<CIT>) discloses that a platform-independent source code among source codes is extended with one or more parts of the source code annotated for different platforms and/or versions.

[Patent Document <NUM>] <CIT>
Further attention is drawn to <CIT> describing adapted components to be used by a computer program under different execution contexts. The adapted components include platform independent source code which is executed regardless of the execution context in which the component is deployed. Adaption logic wraps the execution context independent component in a wrapper. The wrapper performs data marshaling between the execution context independent component and a computer program invoking the execution context independent component, or the host system on which the computer program is deployed. The execution context independent component is adapted to a new execution context dynamically the first time that the execution context independent component is invoked in the execution context. Thereafter, the execution context independent component is invoked statically without the need to readapt the component.

Patent Document <NUM> discloses the extension of the source code but does not disclose a technique for making an external control compatible with a general-purpose OS available as UI elements configuring a program compatible with a non-general-purpose OS.

The disclosure provides an environment for supporting program development that enables diversification without limiting the types of OSs compatible with configuring elements of the HMI program.

A support device according to the invention being defined by the appended claim <NUM> is a support device which supports development of a human machine interface (HMI) program to be executed by a target device of factory automation (FA). The support device includes: a receiving part which receives specification of a user interface (UI) element configuring the HMI program with a program code compatible with a first type of operation system (OS); a code generation part which generates a program code of a UI element compatible with a second type of OS from the specified UI element; and a wrapper generation part which generates a wrapper program including the generated program code compatible with the second type of OS and an instruction code which instructs to generate an execution module that includes the program code when a condition that an OS possessed by the target device is not the first type of OS is satisfied, and a program in executable code is generated from the HMI program in which the wrapper program is incorporated as a UI element with the program code compatible with the first type of OS.

According to this disclosure, it is possible to realize a program development support environment that enables parallel development of an HMI program configured by the UI element compatible with the first type of OS and an HMI program configured by the UI element compatible with the second type of OS including the OS, as configuring elements of the HMI program.

As a result, if the first type of OS is a general-purpose OS, the UI elements provided in the development environment of the application compatible with the general-purpose OS can be used for the development of the HMI program in the FA field.

In the above disclosure, the wrapper generation part further includes, in the instruction code, a code which instructs to generate an execution module of an HMI program including the UI element with the program code compatible with the first type of OS when a condition that the OS possessed by the target device is the first type of OS is satisfied.

According to this disclosure, when the HMI program is executed by the target device, when the target device has the first type of OS, the execution module of the HMI program including the UI element with the program code compatible with the first type of OS is generated, and when the target device has the second type of OS, the execution module of the HMI program including the UI element with the program code compatible with the second type of OS is generated.

In this way, the execution module compatible with the first type of OS and the execution module compatible with the second type of OS can be generated from the program code of one HMI program. Therefore, one HMI program compatible with various types of OS can be generated without preparing both a program development environment compatible with the first type of OS and a program development environment compatible with the second type of OS.

In the above disclosure, the code generation part extracts a property which matches a property of the UI element with the program code compatible with the second type of OS from a property of the UI element with the program code compatible with the first type of OS, and generates the UI element with a program code compatible with the second type of OS from a UI element with a program code including the extracted property.

According to the above disclosure, the the UI element with program code compatible with the second type of OS is generated by using the property of the UI element with the program code compatible with the first type of OS. Therefore, it is possible to generate the UI element with the program code compatible with the second type of OS without requiring new information.

In the above disclosure, the support device further includes: a part which outputs a list of selection candidates of the UI elements; and a registration part which registers the UI element with the program code compatible with the first type of OS received by the receiving part in the list, and the HMI program is edited by using a UI element selected by a user from the list.

According to the above disclosure, the user can register the UI element with the program code compatible with the first type of OS in the list of the selection candidates of the UI elements, whereby the UI element can be selected from the list, and the selected UI element can be used as a UI element configuring the HMI program.

In the above disclosure, the wrapper generation part generates the wrapper program when the program in executable code is generated.

According to the above disclosure, the wrapper program can be generated when the program in executable code of the edited HMI program is generated.

In the above disclosure, the wrapper generation part generates the wrapper program when the UI element with the program code compatible with the first type of OS is registered in the list by the registration part.

According to the above disclosure, the wrapper program can be generated when the UI element with the program code compatible with the first type of OS is registered in the list.

In the above disclosure, the code generation part generates the UI element with a program code compatible with the second type of OS from the specified UI element when a type of the OS possessed by the target device is not the first type of OS.

According to the above disclosure, if the type of OS of the target device corresponds to the first type, the generation of the program code by the code generation part and the generation of the wrapper program by the wrapper generation part can be omitted.

A support program according to the invention being defined by the appended claim <NUM> is a support program which supports development of a human machine interface (HMI) program to be executed by a target device of factory automation (FA). The support program is configured to make a computer execute: receiving specification of a user interface (UI) element configuring the HMI program with a program code compatible with a first type of operation system (OS); generating a program code compatible with a second type of OS from the specified UI element; generating a wrapper program including the generated program code compatible with the second type of OS and an instruction code which instructs to generate an execution module that includes the program code when a condition that an OS possessed by the target device is not the first type of OS is satisfied; and generating a program in executable code from the HMI program in which the wrapper program is incorporated as a UI element with the program code compatible with the first type of OS.

According to the disclosure, it is possible to provide a program development support environment that enables diversification without limiting the types of OSs compatible with the configuring elements of the HMI program.

Embodiments of the disclosure will be described in detail with reference to the drawings. Further, in the drawings, the same or corresponding parts are denoted by the same reference numerals and descriptions thereof will not be repeated.

First, an example of a scenario where the disclosure is applied is described with reference to <FIG> is a diagram schematically showing a configuration of a system <NUM> according to an embodiment of the disclosure. A support device <NUM> according to the embodiment is a device that supports the development of an HMI program to be executed by a target device of FA, and for example, a general-purpose computer can be applied. The target device includes an industrial computer (IPC) <NUM>-<NUM> and a PLC <NUM>-<NUM> as control devices. The control device controls a device <NUM> (for example, a manufacturing device or equipment) provided in any field and serving as a control target.

The support device <NUM> edits an HMI program <NUM> and compiles the edited HMI program <NUM>. By compiling, an execution format program configured by a program code executable by the target device is generated from the HMI program <NUM>. The target device displays an HMI screen by executing the execution format HMI program <NUM> transferred from the support device <NUM>.

When the support device <NUM> receives specification of user interface (UI) elements of a program code compatible with a first type of OS from a user (the UI elements configuring the HMI program <NUM>), the support device <NUM> generates a program code of UI elements compatible with a second type of OS from the specified UI elements. The support device <NUM> generates an I/F conversion object 425B corresponding to a wrapper program including the generated program code compatible with the second type of OS and an instruction code which instructs to generate an execution module that includes the relevant program code when a condition that the OS possessed by the target device is not the first type of OS is satisfied. At the time of compiling, the support device <NUM> generates an executable format program from the HMI program <NUM> in which the above wrapper program (I/F conversion object 425B) is incorporated as UI elements of the program code compatible with the first type of OS.

In the configuration of <FIG>, when the HMI program <NUM> is transferred from the support device <NUM> to the target device and executed by the target device, by executing the wrapper program, when the target device has the first type of OS, for example, in the IPC <NUM>-<NUM>, an execution module <NUM> of the HMI program including the UI elements (for example, an external control <NUM>) of the program code compatible with the first type of OS is generated. Further, when the target device has the second type of OS, for example, in the PLC <NUM>-<NUM>, an execution module <NUM> of the HMI program including the UI elements (an alternative control <NUM> of the external control <NUM>) of the program code compatible with the second type of OS is generated.

By executing the wrapper program in this way, an execution module compatible with Windows including the external control <NUM> and an execution module compatible with a non-Windows OS including the alternative control <NUM> instead of the external control <NUM> can be generated from the source code of the same HMI program <NUM>.

In this way, in the support device <NUM>, the HMI program <NUM> compatible with the types of OS possessed by the target device can be developed without preparing both a program development environment compatible with the first type of OS and a program development environment compatible with the second type of OS.

The first type of OS described above is typically a general-purpose OS such as Windows (registered trademark), and the second type of OS is a type of OS different from the first type of OS, and typically is an OS applied to a program for FA. For example, non-Windows Linux (registered trademark), UNIX (registered trademark) and the like are included. Further, the first type of OS and the second type of OS may be different versions of the OS. For example, the first type of OS may be Windows <NUM> (registered trademark), and the second type of OS may be Windows CE (registered trademark).

Further, in the embodiment, the program (or program code) compatible with the OS indicates a program or program code having a code system that is interpretable and executable under the OS.

Hereinafter, the development environment of the HMI program provided by the support device <NUM> according to the embodiment will be described in detail as a more specific application example of the disclosure.

<FIG> is a diagram schematically showing a configuration of a system according to an embodiment of the disclosure. With reference to <FIG>, the system <NUM> of FA network-connects the industrial computer (IPC) <NUM>-<NUM> and the PLC <NUM>-<NUM> as control devices, multiple devices <NUM>, and the support device <NUM>. The control device is a kind of computer, and a user program such as a control program designed according to a manufacturing device, a manufacturing equipment or the like is executed in the control device. Such a user program is developed by the support device <NUM> as a development environment prepared separately from the control devices.

The support device <NUM> is, for example, a general-purpose computer, and provides an environment for integrating and developing various programs of the system <NUM> and also provides a function of transferring the user program to the control devices. Hereinafter, the IPC <NUM>-<NUM> and the PLC <NUM>-<NUM> are collectively referred to as a control device <NUM>. The devices <NUM> network-connect a field device (now shown) serving as a control target. The control target may include, for example, a sensor, an actuator and the like.

A transmission line conforming to, for example, the universal serial bus (USB) is adopted between the support device <NUM> and the control device <NUM>. For the transmission line of the control device <NUM> and the devices <NUM>, for example, it is preferable to adopt a bus or network in which the arrival time of data is guaranteed conforming to the time-sensitive network (TSN) standard. For example, EtherCAT (registered trademark), which is an example of a network for machine control, may be adopted.

The user program developed in the support device <NUM> includes various programs such as a control program for the control device <NUM> to perform a control calculation for controlling the devices <NUM> and an HMI program for performing an HMI process. These user programs may include programs compatible with non-Windows such as Linux (registered trademark) and UNIX (registered trademark) or programs compatible with Windows, and the types of OSs are not limited thereto. The developed program is transferred from the support device <NUM> to the control device <NUM> and executed by the processor of the control device <NUM>.

The control calculation includes a process of processing data collected or generated by the devices <NUM> from the field device, a process (calculation process) of generating data such as an instruction to the devices <NUM>, a process (output process) of transmitting the generated output data to the target devices <NUM>, and the like.

The HMI process includes processes of collecting information such as the states of various FA devices (the control device <NUM>, the devices <NUM>, and the field device), outputting the collected information on the HMI screen, and receiving user setting (setting of instructions, values, and the like) operations for operating various devices via the HMI screen, and the like.

Further, in the system <NUM> shown in <FIG>, the support device <NUM> is provided as a separate body from the control device <NUM>, but the support device <NUM> may be provided integrally with the control device <NUM>. That is, the function of the support device <NUM> may be built in the control device <NUM>.

<FIG> is a diagram schematically showing an example of a hardware configuration of the control device <NUM> according to an embodiment of the disclosure. With reference to <FIG>, the control device <NUM> includes a processor <NUM>, such as a central processing unit (CPU) or a micro-processing unit (MPU), a chipset <NUM>, a main memory <NUM>, a flash memory <NUM>, an external network controller <NUM>, a memory card interface <NUM>, an internal bus controller <NUM>, and a field bus controller <NUM>.

The processor <NUM> reads a system program <NUM> and a user program stored in the flash memory <NUM>, expands them in the main memory <NUM>, and executes them to realize the control process or the HMI process for the control target such as the devices <NUM> or the field device.

The system program <NUM> includes an instruction code for providing basic functions of the control device <NUM> such as the data input/output process and the execution timing control. The user program includes a control program <NUM>, an HMI program <NUM>, and a library <NUM> that are designed as desired according to the control target. The control program <NUM> includes a sequence program for executing sequence control, a motion program for executing motion control, and the like. The HMI program <NUM> includes, for example, a program corresponding to each HMI screen. In the library <NUM>, unit programs such as the external control <NUM>, user interface (UI) elements configuring the HMI program, and functions configuring the control program are registered in the form of executable codes (for example, intermediate codes). The UI elements include the executable codes of a user-defined UI <NUM> defined by the user and a system-defined UI <NUM> defined by the system as shown in <FIG> (to be described later).

The chipset <NUM> realizes processes of the control device <NUM> as a whole by controlling each component.

The internal bus controller <NUM> is an interface for exchanging data between the control device <NUM> and an I/O unit <NUM> connected through an internal bus. The field bus controller <NUM> is an interface for exchanging data between the control device <NUM> and an I/O unit <NUM> connected through a field bus (not shown). The internal bus controller <NUM> and the field bus controller <NUM> obtain state values input to the corresponding I/O units <NUM> and <NUM>, respectively, and output calculation results of the processor <NUM> as instruction values from the corresponding I/O units <NUM> and <NUM>, respectively.

The external network controller <NUM> controls the exchange of data through various wired/wireless networks. The memory card interface <NUM> is configured to allow a memory card <NUM> to be attached thereto or detached therefrom, and is capable of writing data to the memory card <NUM> and reading data from the memory card <NUM>. The control device <NUM> exchanges data with the support device <NUM> via the external network controller <NUM> or the memory card interface <NUM>.

A part or all of the functions provided by the control device <NUM> executing the programs may be implemented as a dedicated hardware circuit.

Next, an example of a hardware configuration of the support device <NUM> will be described. <FIG> is a diagram schematically showing an example of a hardware configuration of the support device <NUM> according to an embodiment of the disclosure. With reference to <FIG>, the support device <NUM> may be a stationary type, or may be provided in the form of a notebook type personal computer having good portability at the manufacturing site where the control device <NUM> is disposed.

The support device <NUM> includes a CPU <NUM> which executes various programs including an OS, a read only memory (ROM) <NUM> which stores a basic input output system (BIOS) and various data, a random access memory (RAM) <NUM> which provides a work area for storing data necessary for executing the programs by the CPU <NUM>, and a hard disk (HDD) <NUM> which non-volatilely stores programs and the like executed by the CPU <NUM>.

The support device <NUM> further includes an input part <NUM> including a keyboard <NUM> and a mouse <NUM> which receive user operations on the support device <NUM>, and a display <NUM> for presenting information to the user. The support device <NUM> includes a communication interface <NUM> for communicating with the control device <NUM>. The input part <NUM> may be provided as a touch panel integrally configured with the display <NUM>.

The support device <NUM> includes a recording medium reading device <NUM> for reading a support program stored in a recording medium <NUM> from the recording medium <NUM>. This support program may include a program that realizes a program development environment. Each part of the support device <NUM> communicates with each other via a bus <NUM>.

<FIG> is a schematic diagram showing an example of a software configuration of the control device <NUM> according to an embodiment of the disclosure. <FIG> shows, for example, a configuration example of the IPC <NUM>-<NUM>.

With reference to <FIG>, in the control device <NUM>, a hypervisor manages the hardware resources of the control device <NUM> and allocates these hardware resources to a real-time OS <NUM> and a general-purpose OS <NUM> such as Windows <NUM> (to be described later) while mediating these hardware resources, so that the real-time OS <NUM> and the general-purpose OS <NUM> are executed independently of each other on the common hardware resources. That is, a virtual environment for executing different types of OSs is realized by using the hypervisor. A logical network is configured between the real-time OS <NUM> and the general-purpose OS <NUM> by the hypervisor.

In the real-time OS <NUM>, the control program <NUM> including the sequence program is executed. A task scheduler <NUM>, a program manager <NUM>, and an input/output (I/O) control process <NUM> cooperate in executing the control program <NUM>. The control program <NUM> is converted into an executable code in advance, and at the time of execution, the task scheduler <NUM>, the program manager <NUM>, and the I/O control process <NUM> cooperate to repeatedly obtain a signal from the control target, execute the control logic, and reflect the execution result (actuator control).

Under the general-purpose OS <NUM>, a user application <NUM> including for example the HMI program <NUM>, which is any user application, and a general-purpose application <NUM> are executed while calling various programs of the library <NUM>. The general-purpose application <NUM> is a standard application executable by the general-purpose OS <NUM>, and is capable of constructing a system with fewer person-hours with use of general-purpose processes or functions in cooperation with a user application such as the HMI program <NUM>.

The library <NUM> includes the system-defined UI <NUM>, the user-defined UI <NUM>, and the external control <NUM> in an executable format configured by an executable code.

Further, the execution module <NUM> compatible with the first type of OS (general-purpose OS) or the execution module <NUM> compatible with the second type of OS (non-general-purpose OS) may be generated under the general-purpose OS <NUM>.

<FIG> is a diagram schematically showing an example of an overall configuration of a development environment and an execution environment of a program according to an embodiment of the disclosure. With reference to <FIG>, a development environment <NUM> is provided by the support device <NUM>, and an execution environment <NUM> is provided by the control device <NUM>. In <FIG>, the development environment <NUM> and the execution environment <NUM> are provided in different devices, but they may be provided in the same device. Further, various programs and data configuring the development environment <NUM> are stored in a storage part such as the RAM <NUM> of the support device <NUM>.

With reference to <FIG>, the development environment <NUM> and the execution environment <NUM> are provided on Windows <NUM> and a dot net (. NET) framework <NUM>. The development environment <NUM> includes, for example, an HMI program language processing system <NUM>, a UI element processing system <NUM> for HMI, a UI element compiler <NUM>, and an HMI program compiler <NUM> by visual basic dot net (VB. NET) script. The execution environment <NUM> includes an assembly <NUM> configured by an executable code such as a library for executing an HMI program. In the embodiment, in the development environment, a program source code generated by an editor <NUM> (to be described later) of the HMI language processing system and the UI element processing system <NUM> for HMI is compiled by the UI element compiler <NUM> and the compiler <NUM>. By compiling, the source code becomes an executable format file configured by an executable code (intermediate code). In the execution environment for HMI, the compiled HMI program is made an execution module by using the assembly <NUM>, and the execution module is executed. The execution module is provided by linking an executable format object of the UI element to the executable format HMI program <NUM>.

<FIG> is a diagram schematically showing a specific configuration example of the development environment and the execution environment in the support device <NUM> according to an embodiment of the disclosure. With reference to <FIG>, in the support device <NUM>, a program which provides the development environment <NUM> of the HMI program <NUM> is executed under the Windows <NUM> executed under the hardware resources of a PC and also under various programs of an FA development environment <NUM> provided under the Windows <NUM>. These programs include an external control converter <NUM>, a compiler <NUM> and the editor <NUM> in the development environment <NUM>. A support program <NUM>, which is configured by a program for realizing the development environment of the HMI program <NUM>, is stored in the RAM <NUM>.

The external control converter <NUM> converts the external control <NUM>, which is provided as a UI element for constructing a program compatible with Windows, into a code for making it executable under a non-Windows OS. The compiler <NUM> includes the compiler <NUM> and the compiler <NUM> of the UI elements of <FIG>. The editor <NUM> receives a user operation and edits (creates) the HMI program <NUM> according to the received operation content. Further, an environment for developing the control program <NUM> is also provided under the FA development environment <NUM>. The external control <NUM>, the HMI program <NUM>, and the control program <NUM> are also stored in the RAM <NUM>.

The control program <NUM> includes a program and various libraries conforming to IEC, which is a programming standard for PLC. The HMI program <NUM> includes a user-defined UI or a system-defined UI as UI elements configuring the HMI program <NUM>. Further, the user can select the external control <NUM> as a UI element configuring the HMI program <NUM> at the time of editing.

When the compiler <NUM> is started under the FA development environment <NUM>, the HMI program <NUM> is compiled, whereby an executable code is generated from the source code of the HMI program <NUM>. The HMI program <NUM> in executable code is transferred to the control device <NUM>.

In the execution environment of the control device <NUM>, a Runtime <NUM> launched under the Windows <NUM> supports the execution of the HMI program <NUM> in executable code. The Runtime <NUM> generates an execution module compatible with the Windows <NUM> from the HMI program <NUM> in executable code. By interpreting and executing the code of the execution module of the HMI program <NUM>, the Windows <NUM> performs an HMI process such as presenting an HMI screen including various UI elements.

Further, the executable code of the compiled control program <NUM> is interpreted and executed by the real-time OS <NUM>, and the control process is executed.

In the control device <NUM>, data can be exchanged between the HMI program <NUM> which executes the HMI process and the control program <NUM> which executes the control process via their OSs and a logical network (see <FIG>). As a result, for example, in the execution environment, a state (such as outputs of a sensor) of the field device, which is a control target, obtained by the control process can be presented by a display mode (for example, display color) of the UI elements of the HMI screen. Further, the data input by operating the UI elements of the HMI screen can be used as data for changing the state of the field device, which is a control target, by the control process.

<FIG> is a diagram schematically showing an example of a module configuration for a conversion process of an external control according to an embodiment of the disclosure. With reference to <FIG>, the development environment <NUM> includes a compilation execution part <NUM> which starts the compiler <NUM>, an OS type storage part <NUM>, and an external control converter <NUM> according to a compilation instruction 421A received from the user operation via the input part <NUM>. The compiler <NUM> includes an HMI compiler <NUM> which compiles the HMI program <NUM> configured by UI elements, and a WinApp compiler <NUM> which compiles the external control <NUM>.

The OS type storage part <NUM> obtains an OS type 424A of the control device <NUM> and holds (stores) it in a memory such as the RAM <NUM>. The OS type storage part <NUM> obtains the OS type 424A from the content of the user operation via the input part <NUM> or by receiving it from the control device <NUM>. In order to obtain the OS type 424A, the support device <NUM> communicates with the control device <NUM> conforming to a communication protocol such as the hypertext transfer protocol (HTTP).

When the external control converter <NUM> receives an import instruction <NUM> of the external control <NUM> according to the user operation via the input part <NUM>, the external control converter <NUM> accesses the external control <NUM> stored in the RAM <NUM>, generates an interface (I/F) conversion source code 425A from the code of the external control <NUM> and stores it in the RAM <NUM>. The I/F conversion source code 425A includes a code in which the source code of the I/F part of the external control <NUM> compatible with Windows is made compatible with the UI element of non-Windows. Details of the operation of each part of <FIG> will be described later in the description of <FIG>.

<FIG> is a diagram schematically showing an outline of a toolbox management process according to an embodiment of the disclosure. <FIG> is a diagram schematically showing an example of a display screen at the time of editing the HMI program according to an embodiment of the disclosure. <FIG> is a diagram illustrating a part of the internal code of the HMI program <NUM> according to an embodiment of the disclosure.

In the embodiment, when the editor <NUM> edits the HMI program <NUM>, for example, an editor screen shown in <FIG> is displayed on the display <NUM>. In the embodiment, the HMI program <NUM> includes a page-by-page program corresponding to the HMI screen. The HMI program <NUM> is configured by multiple pages, and a page <NUM> of the HMI program and a toolbox <NUM> are displayed on the editor screen. The data in the toolbox <NUM> is stored in, for example, the RAM <NUM>, and is read from the RAM <NUM> by the editor <NUM> and displayed when the HMI program is edited.

With reference to <FIG>, the toolbox <NUM> corresponds to a part for outputting a list of selection candidates of the UI elements by being displayed on the display <NUM>. Specifically, this list includes a list of identifiers, such as names of the UI elements, which can be used to edit the HMI program <NUM>. The UI elements that are registrable in the toolbox <NUM> may include a user-defined UI or a system-defined UI for the HMI of FA and the external control <NUM>. The UI elements may include GUI elements such as a button and a lamp.

When editing the page <NUM>, the user operates the input part <NUM> to select a UI element from the toolbox <NUM>, moves the selected UI element to a desired position on the page <NUM> by a dragging operation, and performs a dropping operation. The editor <NUM> receives the dragging/dropping operation and edits (creates) the page <NUM> so that the selected UI element is incorporated into the HMI program of the page <NUM>. The user can switch to display another page <NUM> and edit it in the same manner by a switching operation on the page <NUM> of the display <NUM>. In this way, the user can edit the HMI program <NUM> by performing an operation of arranging the UI elements on the page <NUM> without inputting a program code.

For example, when the external control <NUM> is selected as a UI element configuring the page <NUM>, the code for calling the external control <NUM> after the I/F conversion is added to the source code of the page <NUM>. For example, as shown in <FIG>, the editor <NUM> adds a call code of the external control <NUM> using the name of "converted_SampleControl" in which converted_ is added to the name of the external control <NUM>.

Next, a configuration for registering the external control <NUM> in the toolbox <NUM> used in the above-mentioned editing process will be described.

With reference to <FIG>, the development environment <NUM> includes an external control file selection part <NUM>, the external control converter <NUM> including a wrapper generation part <NUM>, and a toolbox management part <NUM>. The user operates the input part <NUM> to select the function of importing the external control <NUM> from a function menu <NUM>. The external control file selection part <NUM> searches for the executable code file ("SampleControl. dll") of the external control <NUM> selected from the RAM <NUM> based on the external control import instruction <NUM> according to the corresponding selection operation of the user.

The external control converter <NUM> outputs to the toolbox management part <NUM> a registration request of "SampleControl" (which is the file name of the external control <NUM>) to the toolbox <NUM>. The toolbox management part <NUM> corresponds to a registration part for registering a UI element of the program code compatible with Windows, that is, the external control <NUM>, which is received from the user operation via the input part <NUM> in a list of UI element candidates of the toolbox <NUM>. In this case, the toolbox management part <NUM> registers the name "SampleControl" of the external control <NUM> in the toolbox <NUM>. As a result, the external control <NUM> selected by the user can be registered in the list of the toolbox <NUM> as a candidate of the UI elements that can be used for editing the HMI program <NUM>.

<FIG> is a diagram schematically showing an example of a process for generating an I/F conversion source code according to an embodiment of the disclosure. <FIG> is a diagram schematically showing an example of an I/F conversion object according to an embodiment of the disclosure.

The external control converter <NUM> executes an I/F conversion source code generation process. Specifically, the external control converter <NUM> generates the I/F conversion source code 425A from the code of the file "SampleControl. dll" of the external control <NUM> registered in the toolbox <NUM>. Further, the external control converter <NUM> compiles the I/F conversion source code 425A to generate the I/F conversion object 425B. The I/F conversion object 425B has an instruction code (script or the like) for calling the file "SampleControl. dll" of the external control <NUM>.

First, with reference to <FIG>, the external control converter <NUM> reads the code of the file "SampleControl. dll" of the external control <NUM>, analyzes the read code, and extracts an interface (I/F) 425C from the code based on the analysis result. Further, the external control converter <NUM> compares the I/F 425C with a required I/F 425D. This "I/F" is an attribute possessed by the external control <NUM> or the UI element, and may include, for example, a display attribute (color, size, and the like) or a communication attribute for exchanging data with other UI elements, other programs, and the like. The required I/F 425D indicates an I/F including properties required as the UI element of the HMI of FA. More typically, it indicates an I/F including properties of a UI element represented by a program code compatible with a non-Windows OS. Further, data of the required I/F 425D is held (stored) in the RAM <NUM> or the like.

Based on the result of the I/F comparison, the external control converter <NUM> extracts the properties (type and number of the attributes) that match the properties included in the required I/F 425D from the properties of the extracted I/F 425C. The external control converter <NUM> uses the extracted (matching) properties to generate a source code <NUM> for presenting the external control <NUM> as a UI element for the HMI of FA, i.e., as a UI element compatible with a non-Windows OS. The I/F conversion source code 425A includes a name 425E of the called external control <NUM> and the converted (generated) source code <NUM>.

The wrapper generation part <NUM> of the external control converter <NUM> generates, for example, the I/F conversion object 425B of <FIG> by compiling the I/F conversion source code 425A. The I/F conversion object 425B of <FIG> has the form of a wrapper program. That is, the I/F conversion object 425B includes a source code <NUM> which is interpretable and executable by Windows, the source code <NUM> which is interpretable and executable by a non-Windows OS, and a wrapper part <NUM>.

The source code <NUM> includes a name of the external control <NUM> to be called and a code instructing the Runtime <NUM> under the Windows <NUM> to call and execute the external control <NUM>.

The source code <NUM> includes a code instructing the Runtime under the non-Windows OS to generate an object module of a UI element compatible with the non-Windows OS from the source code <NUM>.

The I/F conversion object 425B is not a file configured by an executable code dynamically linked to the execution module of the HML program such as "SampleControl. dll" of the external control <NUM>, but may be said to be an intermediate code which is converted into an object module configured by an executable code by executing the source code <NUM>.

When executed, the wrapper part <NUM> includes a code which causes the Runtime of the control device <NUM> to determine the OS type and instructs switching of whether to generate an execution module by the source code <NUM> based on the determined OS type. More specifically, when this code is executed, when the condition that the OS type is Windows is satisfied, an execution module of the HMI program <NUM> including the external control <NUM> provided by the OS (Windows <NUM>) of the control device <NUM> is generated. On the other hand, when the condition that the determined OS type is non-Windows is satisfied, the source code <NUM> is executed. As a result, an execution module of the HMI program <NUM> including the executable code of the source code <NUM> is generated in order to realize a control (UI element) that replaces the external control <NUM>.

By executing the wrapper part <NUM> in this way, an execution module compatible with Windows including the external control <NUM> and an execution module compatible with a non-Windows OS including an alternative external control instead of the external control <NUM> can be generated from the source code of the same HMI program <NUM>.

In the embodiment, the time when the external control converter <NUM> generates the I/F conversion object 425B is not particularly limited. For example, the external control converter <NUM> generates the I/F conversion object 425B (wrapper program) when the executable format program is generated from the HMI program <NUM> by the compiler <NUM>.

In this way, the I/F conversion object 425B can be generated in one time. That is, when the HMI program <NUM> is edited, there is a background that the UI elements configuring the HMI program <NUM> are frequently changed by trial and error. With such a background taken into consideration, if the I/F conversion object 425B is generated at the time of editing, the generation will be repeated relatively frequently. On the other hand, if the I/F conversion object 425B is generated when the HMI program <NUM> is compiled, the generation of the I / F conversion object 425B can be completed in one time at the time of compilation as described above.

Further, at another time, the external control converter <NUM> can also generate the I/F conversion object 425B when the external control <NUM> is registered in the toolbox <NUM> by the toolbox management part <NUM>. In this case, since it is not necessary to generate the I/F conversion object 425B when compiling the HMI program <NUM>, the time required for compiling can be shortened.

<FIG> is a flowchart schematically showing an example of a process of importing the external control <NUM> into the development environment <NUM> according to an embodiment of the disclosure. A process of importing the external control <NUM> as a UI element that is usable in the development environment <NUM> will be described with reference to <FIG> according to the flowchart of <FIG>.

With reference to <FIG>, when the external control converter <NUM> receives the external control import instruction <NUM> from the user operation via the input part <NUM> (Step S1), the external control converter <NUM> obtains the OS type of the target device stored by the OS type storage part <NUM> (Step S3), and determines whether the OS type indicates Windows (Step S5). When the external control converter <NUM> determines that the OS type indicates non-Windows (NO in Step S5), the external control converter <NUM> ends a series of processes.

On the other hand, when the external control converter <NUM> determines that the OS type indicates Windows (YES in Step S5), the external control converter <NUM> generates the I/F conversion source code 425A according to the procedure of <FIG>, and the external control converter <NUM> stores the generated I/F conversion source code 425A in the RAM <NUM> according to the procedure of <FIG> (Step S7).

The external control converter <NUM> compiles the I/F conversion source code 425A and obtains the I/F conversion object 425B from the I/F conversion source code 425A (Step S9).

The external control converter <NUM> requests the toolbox management part <NUM> to register the I/F conversion object 425B (Step S11). Upon receiving the registration request, the toolbox management part <NUM> extracts the name of the external control <NUM> from the I/F conversion object 425B (Step S13), and adds (registers) the name of the extracted external control <NUM> to the data of the toolbox <NUM> of the RAM <NUM> (Step S15). After that, the process ends. Further, the name of the external control <NUM> registered in the toolbox <NUM> is associated with the corresponding I/F conversion object 425B of the RAM <NUM>.

<FIG> is a flowchart showing an example of a process of editing and compiling according to an embodiment of the disclosure. Editing the HMI program by the editor <NUM> and compiling the HMI program in the development environment <NUM> will be described with reference to the flowchart of <FIG>. At the time of editing, the HMI program <NUM> and the toolbox <NUM> are displayed on the display <NUM> as shown in <FIG>.

With reference to <FIG>, the editor <NUM> receives via the input part <NUM> a dragging/dropping operation for incorporating an external control with a name selected by the user from the toolbox <NUM> into the HMI program as a UI element (Step S21).

The editor <NUM> reflects the object name of the I/F conversion object 425B of the RAM <NUM> associated with the external control selected by the user in the project data of the HMI program <NUM> as the call destination object name according to the received user operation content (Step S23). As a result, it is possible to incorporate the external control into the HMI program <NUM> as a UI element configuring the program.

When the development environment <NUM> receives the compilation instruction 421A of the HMI program from the user via the input part <NUM> (Step S25), the development environment <NUM> starts the compilation execution part <NUM>.

The compilation execution part <NUM> starts the WinApp compiler <NUM> and the HMI compiler <NUM> in order to compile the project data of the HMI program <NUM>. The WinApp compiler <NUM> scans the HMI program, compiles the I/F conversion source code of the external control <NUM> among the UI elements configuring the HMI program, and the HMI compiler <NUM> compiles the source code of the HMI program <NUM> (Step S27).

By compiling the HMI program <NUM> in this way, an executable code is generated from the source code of the HMI program <NUM>. At the time of compiling, the compiler scans the HMI program <NUM>, and when it detects a call instruction for the external control, it extracts the name of the external control from the call instruction. The compiler searches the RAM <NUM> for the I/F conversion object 425B associated with the name of the extracted external control, and generates the executable code of the HMI program <NUM> including the searched I/F conversion object 425B.

The development environment <NUM> transfers the HMI program configured by the executable code obtained by compilation (Step S29). This transfer includes concepts such as transfer (download) via a transmission path to the control device <NUM>, which is a target device, or storage in a storage part such as the RAM <NUM> or the recording medium <NUM>.

<FIG> is a flowchart showing an example of a process of an external control at the time of executing an HMI program according to an embodiment of the disclosure.

With reference to <FIG>, in the control device <NUM>, the Runtime <NUM> activates and executes the HMI program <NUM> in executable code (Step S31).

When the call instruction of the external control is executed while the HMI program <NUM> is being executed, the Runtime <NUM> activates the wrapper part <NUM> in the wrapper program of the external control (Step S33). When the wrapper part <NUM> is activated, the Runtime <NUM> executes subsequent processes of Steps S35, S37, S39 and S41 while interpreting the instruction code of the wrapper part <NUM>. As a result, an execution module configured by the executable code of the HMI program <NUM> is generated.

Specifically, the Runtime <NUM> obtains the OS type which executes the Runtime <NUM> (Step S35). For example, the OS type can be obtained by reading from a predetermined storage area.

The Runtime <NUM> determines whether the obtained OS type is Windows (Step S37). When the Runtime <NUM> determines that the OS type is Windows (YES in Step S37), it generates the execution module <NUM> for presenting the UI element by the external control <NUM> without calling the I/F conversion source code <NUM> of the wrapper program (Step S39).

On the other hand, when the Runtime <NUM> determines that the OS type is non-Windows (NO in Step S37), it interprets and executes the I/F conversion source code <NUM> (Step S41). In this way, the Runtime <NUM> generates the execution module <NUM> for presenting a UI element according to the I/F conversion source code <NUM> (Step S39).

According to the process of <FIG>, by executing the HMI program <NUM>, the execution module <NUM> compatible with Windows including the external control <NUM> and the execution module <NUM> compatible with a non-Windows OS which is generated with the I/F conversion source code <NUM> replacing the external control <NUM> can be generated from the source code of the same HMI program <NUM>.

A support program for executing various processes under the development environment <NUM> including the processes of each flowchart shown in the embodiment is stored in the storage part (the ROM <NUM>, the RAM <NUM>, the HDD <NUM>, the recording medium <NUM>, and the like) of the support device <NUM>. By reading the support program from the storage part and executing it, the CPU <NUM> can realize various processes in the development environment <NUM> described in the embodiment.

Such a support program is recorded on a computer-readable recording medium such as a flexible disk, a compact disk-read only memory (CD-ROM), a ROM, a RAM and the recording medium <NUM> attached to the support device <NUM>, and it can also be provided as a program product. Alternatively, the program can be provided by being recorded on a recording medium such as the HDD <NUM> built in the support device <NUM>. Further, the program can also be provided by being downloaded from a network (not shown) via the communication interface <NUM>.

Claim 1:
A support device (<NUM>) which supports development of a human machine interface, HMI, program (<NUM>) to be executed by a target device (<NUM>) of factory automation, FA, the support device comprising:
a receiving part (<NUM>) which receives specification of at least one user interface, UI, element configuring the HMI program (<NUM>) with a program code compatible with a first type of operation system, OS;
a storage part (<NUM>) storing an external control (<NUM>) provided as an UI element of the at least one UI element compatible with the first type of OS;
a code generation part (<NUM>) which generates I/F conversion source code (425A) from code of the external control (<NUM>) by extracting properties from the code of the external control (<NUM>) that match properties required as an UI element compatible with a second type of OS, the I/F conversion source code (425A) includes a name (425E) of the called external control (<NUM>) and a converted program code (<NUM>) of a UI element compatible with the second type of OS, the converted program code (<NUM>) of the UI element compatible with the second type of OS is a source code for presenting the external control (<NUM>) as the UI element compatible with the second type of OS; and
a wrapper generation part (<NUM>) which compiles the I/F conversion source code (425A) to generate a wrapper program (425B) comprising a source code (<NUM>) interpretable and executable by the first type of OS, the converted program code (<NUM>) compatible with the second type of OS and an instruction code (<NUM>), the source code (<NUM>) comprising the name of the called external control (<NUM>) and code to call and execute the external control (<NUM>), the instruction code (<NUM>) includes when executed, a code causing the target device (<NUM>) to determine an OS type and instructing to execute the converted program code (<NUM>)to generate an execution module (<NUM>) for presenting the UI element according to the converted program code (<NUM>) compatible with the second type of OS instead of the external control (<NUM>) when a condition that an OS possessed by the target device (<NUM>) is not the first type of OS is satisfied,
wherein the wrapper program (425B) is incorporated into the HMI program (<NUM>), and a program in executable code is generated from the HMI program as a UI element with the program code compatible with the first type of OS.