Engineering tool, controller, and control system

An engineering tool includes a hardware-allocation-data storage, an allocation-condition storage, and a tool processor. Hardware allocation data is to be downloaded to a controller that executes a host operating system (OS), and represents hardware allocation to each of the host OS and a guest OS that runs on a virtual machine implemented on the host OS. The allocation-condition storage stores therein hardware allocation conditions for the host OS and the guest OS. The tool processor causes a display to display a settings screen for inputting the hardware allocation data; after determining that the input hardware allocation data satisfies the allocation conditions stored in the allocation-condition storage, saves the input hardware allocation data in the hardware-allocation-data storage; and after determining that the input hardware allocation data fails to satisfy the allocation conditions, refrains from saving the input hardware allocation data therein.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a national stage application of International Application No. PCT/JP2018/033636, filed Sep. 11, 2018, which designates the United States, and which claims the benefit of priority from Japanese Patent Application No. 2018-036820, filed Mar. 1, 2018, the entire contents of each of which are incorporated herein by reference.

FIELD

Embodiments described herein generally relate to an engineering tool, a controller, and a control system.

BACKGROUND

Server virtualization technology is known, which refers to logically partitioning a single computer to allow a plurality of operating systems (OS) to run on the computer. By applying server virtualization to a control system that controls an intended device, such as a valve in a plant, a human machine interface (HMI), an engineering tool, and a controller can be consolidated into one computer. This can bring promising effect of large cost savings in terms of equipment installation and electricity and air conditioning in a control system.

Meanwhile, A guest OS runs on a virtual machine implemented on the host OS of the computer. To apply server virtualization to the control system, the virtual machine is to be initiated by allocating the hardware to the guest OS on the basis of hardware allocation data that is set by an engineer with an engineering tool. In doing so, with occurrence of error in the setting of the hardware allocation data, however, the control system may fail to function properly.

DETAILED DESCRIPTION

According to an embodiment, in general, an engineering tool includes a hardware-allocation-data storage, an allocation-condition storage, and a tool process unit. The hardware-allocation-data storage stores therein hardware allocation data to be downloaded to a controller that executes a host operating system. The hardware allocation data represents hardware allocation to each of the host operating system and a guest operating system that runs on a virtual machine implemented on the host operating system. The allocation-condition storage stores therein hardware allocation conditions for the host operating system and the guest operating system. The tool process unit causes a display to display a settings screen for inputting the hardware allocation data; after determining that the hardware allocation data input to the settings screen satisfies the allocation conditions stored in the allocation-condition storage, saves the input hardware allocation data in the hardware-allocation-data storage; and after determining that the input hardware allocation data fails to satisfy the allocation conditions, refrains from saving the input hardware allocation data in the hardware-allocation-data storage.

An engineering tool, a controller, and a control system according to embodiments will be described below with reference to the accompanying drawings.

First Embodiment

FIG. 1is a view illustrating an exemplary functional configuration of a control system according to a first embodiment. As illustrated inFIG. 1, the control system of the present embodiment includes a controller1and a tool PC2(an exemplary engineering tool). The controller1and the tool PC2are connected to each other in a communicable manner through a network, such as a local area network (LAN). In the present embodiment, the tool PC2's transmitting a variety of information to the controller1is referred to as downloading (D/L). The tool PC2's receiving a variety of information from the controller1is referred to as uploading (U/L).

The tool PC2represents an engineering tool for use by vendors or engineers, for example, and stores therein a program organization unit (POU), later-described hardware allocation data (tool data), and other data. The POU refers to modularized programs in units of function for the purpose of executing processing in the entire control system.

The controller1receives results of a variety of detection from sensors, for example, in a plant. The controller1has downloaded thereto a POU created in the tool PC2. The controller1executes the POU on an internal task. In this manner, the controller1performs a computation based on the results of detection, and controls a target device in the plant, such as a valve, on the basis of a result of the computation.

The controller1includes logically partitioned resources (hardware) and operates a plurality of operating systems (OS) to consolidate external devices involved in controlling the target device, such as a human machine interface (HMI) of the control system and another controller. The operator of the control system uses the HMI to monitor the state of the POU remotely executed by the controller1and to perform a variety of operations, such as writing variables to the controller1and altering the POU.

FIG. 2is a view illustrating an exemplary functional configuration of the controller and the tool PC of the control system in the first embodiment. As illustrated inFIG. 2, the controller1includes hardware101, a host OS102, a host process group103, a virtual machine104, a guest OS105, a guest process group106. The hardware101represents, for example, a processor such as a central processing unit (CPU), memories such as read-only memory (ROM) and random access memory (RA), and a LAN port, a universal serial bus (USB) port, and a peripheral component interconnect (PCI) slot used in communications with external devices such as the tool PC2.

In the present embodiment, the controller1serves as a multi-core processor including a plurality of CPU cores (for example, four CPU cores) as the hardware101, to execute software on the CPU cores. Specifically, the controller1causes one of the CPU cores to execute a single OS (the host OS102) to operate a plurality of mutually isolated containers110and111. In doing so, the controller1causes different CPU cores to operate the containers110and111. In the present embodiment, the controller1causes different CPU cores to operate the container110including the host OS102and the host process group103, and the container111including the virtual machine104, the guest OS105, and the guest process group106, as illustrated inFIG. 2.

The host OS102serves as an OS for implementing an external device (the virtual machine104) to be virtualized by the controller1. The host process group103includes an application that runs on the host OS102. The virtual machine104is implemented on the host OS102. In the present embodiment, the virtual machine104represents a virtualized machine of hardware of an external device, such as an HMI or another controller. Herein, virtualization includes emulation of the hardware of the external device. The guest OS105runs on the virtual machine104and serves to operate a computer program (guest process group106, as will be described later) of the external device. The guest process group106runs by the guest OS105, and serves to execute processing involving in controlling the target device (hereinafter referred to as control processing), using the hardware101allocated to the guest OS105in accordance with later-described hardware allocation data. Herein, in the case of using the virtual machine104being a virtualized HMI, the control processing includes processing involving in monitoring the control system and remotely operating the control system to perform a process. In the case of using the virtual machine104being virtualization of another controller, the control processing includes controlling the target device, for example, by transmitting control data to the target device.

In the present embodiment, the host process group103includes a controller process unit103a. The controller process unit103ais operated by the host OS102without the guest OS105. The controller process unit103adownloads and executes a POU from the tool PC2. Also, the controller process unit103adownloads hardware allocation data from the tool PC2, to execute the control processing to the target device, using the hardware101allocated to the host OS102in accordance with the hardware allocation data. Herein, the hardware allocation data represents allocation of the hardware101to each of the host OS102and the guest OS105. Specifically, in response to power-on of the controller1, the controller process unit103avalidates the hardware allocation data, and uses the hardware101allocated to the host OS102indicated by the hardware allocation data, to control the target device. The controller process unit103asaves the downloaded hardware allocation data in a hardware-allocation-data storage101aserving as a nonvolatile storage of the hardware101, such as a hard disk drive (HDD).

In view of managing engineering data in the control system, it is preferable to manage the hardware101allocated to the guest OS105in accordance with the hardware allocation data. For this reason, in the present embodiment the host process group103includes a guest-initialization process unit103b, in addition to the controller process unit103a. Upon power-on of the controller1, the guest-initialization process unit103ballocates the hardware101to the guest OS105, referring to the hardware allocation data stored in the hardware-allocation-data storage101a, and also sets, on the host OS102, the virtual machine104being virtualization of the external device. Further, the guest-initialization process unit103binitiates the guest OS105on the virtual machine104. Thereby, the hardware101becomes allocable to the guest OS105that runs on the virtual machine104in the same or like manner as the hardware101is allocated to the host OS102. As a result, a single controller1into which external devices such as an HMI and another controller are consolidated can easily manage the allocation of the hardware101to the guest OS105in response to an update of the hardware101.

With occurrence of error in the hardware allocation data downloaded from the tool PC2, however, the controller1cannot properly allocate the hardware101to the host OS102and the guest OS105on the basis of the hardware allocation data concerned, which may undesirably affect the controller1. For example, when a larger memory capacity than the memory capacity of the hardware101is allocated to the guest OS105in accordance with the downloaded hardware allocation data, the CPU core of the controller1may not be able to execute the guest OS105, which may lead to a failure in causing the virtual machine104to function as an HMI.

In the present embodiment, the controller1includes an allocation-condition storage101bincluding a nonvolatile storage of the hardware101, such as an HDD. The allocation-condition storage101bstores therein allocation condition data. The allocation condition data represents individual hardware allocation conditions101for the host OS102and the guest OS105. Having the hardware allocation data downloaded from the tool PC2, the controller process unit103adetermines whether the downloaded hardware allocation data satisfies the allocation condition data stored in the allocation-condition storage101b. After determining that the downloaded hardware allocation data satisfies the allocation condition data, the controller process unit103asaves the downloaded hardware allocation data in the hardware-allocation-data storage101a. Meanwhile, after determining that the downloaded hardware allocation data fails to satisfy the allocation condition data, the controller process unit103arefrains from saving the downloaded hardware allocation data in the hardware-allocation-data storage101a. This can prevent the hardware101from being allocated to the host OS102and the guest OS105in accordance with erroneous hardware allocation data downloaded from the tool PC2and can reduce the possibility of undesirably affecting the controller1. Additionally, in response to an engineer's instruction through an operation of the tool PC2to upload hardware allocation data, the tool PC2uploads the hardware allocation data from the hardware-allocation-data storage101a.

A functional configuration of the tool PC2will be described next. As illustrated inFIG. 2, the tool PC2includes a tool process unit201, a display202, an allocation-condition storage203, and a hardware-allocation-data storage204. The hardware-allocation-data storage204stores therein hardware allocation data for each model of the controller1or for each network address (for example, an IP address) of the controller1. The allocation-condition storage203stores therein allocation-condition data for each model of the controller1or for each network address (for example, IP address) of the controller1.

The tool process unit201controls the entire tool PC2. In the present embodiment, the tool PC2is equipped with hardware including a processor such as a CPU, and memory such as ROM and RAM. The processor executes a computer program stored in the memory, thereby implementing the tool process unit201. However, the tool process unit201is not limited thereto, and may be implemented by circuitry.

Specifically, the tool process unit201causes the display202to display a settings screen for entering hardware allocation data. The tool process unit201also determines whether the hardware allocation data input to the settings screen satisfies the allocation condition data stored in the allocation-condition storage203. After determining that the hardware allocation data satisfies the allocation condition data, the tool process unit201saves the hardware allocation data in the hardware-allocation-data storage204. After determining that the hardware allocation data fails to satisfy the allocation condition data, the tool process unit201refrains from saving the hardware allocation data in the hardware-allocation-data storage204. In this manner, the hardware101can be prevented from being erroneously allocated to the host OS102and the guest OS105in accordance with the hardware allocation data to be downloaded to the controller1, which can reduce the possibility of exerting undesirable influence on the controller1.

Thereafter, in response to an engineer's, being the user of the tool PC2, selection of hardware allocation data and instruction for downloading the data, the tool process unit201downloads, to the controller1, the selected hardware allocation data from the hardware allocation data stored in the hardware-allocation-data storage204. Thereby, the engineer is able to manage, with the tool PC2, the hardware allocation to the guest OS105that runs on the virtual machine104of the controller1. After receiving an instruction for uploading hardware allocation data from the engineer being the user of the tool PC2, the tool process unit201uploads the hardware allocation data from the controller1and saves that in the hardware-allocation-data storage204.

FIG. 3is a flowchart illustrating exemplary hardware-allocation-data setting processing performed by the tool PC in the first embodiment. The tool process unit201causes the display202to display the settings screen for inputting hardware allocation data (Step S301). In the present embodiment, the tool process unit201causes the display202to display the settings screen showing default hardware allocation data. The tool process unit201then reads the allocation condition data from the allocation-condition storage203in accordance the model or the network address of the controller1instructed by the user (engineer) of the tool PC2(Step S302). The tool process unit201also reads the hardware allocation data from the hardware-allocation-data storage204in accordance with the model or the network address of the controller1instructed by the user of the tool PC2(Step S302).

Subsequently, the tool process unit201compares the hardware allocation data input onto the settings screen and the hardware allocation data read from the hardware-allocation-data storage204, to determine whether there is a change in the hardware allocation data (Step S303). In the present embodiment, upon every input of one item of hardware allocation data to the settings screen, the tool process unit201compares the hardware allocation data input to the settings screen and the read hardware allocation data, to determine whether there is a change in the hardware allocation data. However, how to compare the data and determine a change is not limited thereto. For example, after completion of input of all the items of hardware allocation data to the settings screen and receipt of an instruction for saving the hardware allocation data, the tool process unit201may compare the hardware allocation data input to the settings screen and the read hardware allocation data, to determine whether there is a change in the hardware allocation data.

After determining no change in the hardware allocation data (No at Step S303), the tool process unit201refrains from saving the hardware allocation data in the hardware-allocation-data storage204. After determining a change in the hardware allocation data (Yes at Step S303), the tool process unit201determines whether the hardware allocation data input to the settings screen satisfies the read allocation condition data (Step S304).

In the present embodiment, the allocation condition data contains items such as the number of CPUs for the host OS, the number of CPUs for the guest OS, the number of CPUs for the system, host OS memory, guest OS memory, total memory, built-in LAN port, built-in USB port, PCI expansion slot A, and PCI expansion slot B, as illustrated in Table 1 below.

TABLE 1Lower limitUpper limitNumber of CPUs for the host OS24Number of CPUs for the guest OS02Number of CPUs for the system24Host OS memory (GB)48Guest OS memory (GB)44Total memory (GB)88Built-in LAN port02Built-in USB port02PCI Expansion Slot A02PCI Expansion Slot B02. . .

The number of CPUs for the host OS represents the upper and lower limits of the number of the CPU cores that are allocable to the host OS102. The number of CPUs for the guest OS represents the upper and lower limits of the number of the CPU cores that are allocable to the guest OS105. The number of CPUs for the system represents the upper and lower limits of the sum of the CPU cores that are allocable to the host OS102and the guest OS105.

The host OS memory represents the upper and lower limits of memory capacity that is allocable to the host OS102. The guest OS memory represents the upper and lower limits of memory capacity that is allocable to the guest OS105. The total memory represents the upper and lower limits of the sum of memories that are allocable to the host OS102and the guest OS105.

The built-in LAN port represents to which of the host OS102or the guest OS105the built-in LAN port is allocated. The built-in USB port represents to which of the host OS102or the guest OS105the built-in USB port is allocated. The PCI expansion slot A represents to which of the host OS102or the guest OS105the PCI expansion slot A is allocated. The PCI expansion slot B represents to which of the host OS102or the guest OS105the PCI expansion slot B is allocated. Herein, the number 0 indicates that the hardware101(for example, built-in LAN port) is allocated to both the host OS102and the guest OS105. The number 1 indicates that the hardware101is allocated to the host OS102. The number 2 indicates that the hardware101is allocated to the guest OS105.

In the present embodiment, the tool process unit201identifies the allocation condition data that corresponds to the item of the hardware allocation data input to the settings screen, from the read allocation condition data. The tool process unit201then compares the hardware allocation data input to the settings screen and the identified allocation condition data, to determine whether the input hardware allocation data satisfies allocation conditions.

For example, in response to input of the number of the CPU cores to be allocated to the host OS102onto the settings screen, the tool process unit201determines whether the input number of the CPU cores satisfies the upper and lower limits of the number of CPUs for the host OS. In response to input of the number of the CPU cores to be allocated to at least one of the host OS102and the guest OS105onto the settings screen, the tool process unit201determines whether the sum of the CPU cores to be allocated to the host OS102and the guest OS105satisfies the upper and lower limits of the number of CPUs for the system.

After determining that the hardware allocation data input to the settings screen satisfies the allocation condition data (Yes at Step S304), the tool process unit201saves the input hardware allocation data in the hardware-allocation-data storage204(Step S305). The tool process unit201then downloads the hardware allocation data from the hardware-allocation-data storage204to the controller1in accordance with the user's operation of the tool PC2.

In the present embodiment, the tool process unit201downloads, to the controller1, the hardware allocation data as configured in Table 2 below. Specifically, the tool process unit201downloads items of hardware allocation data (for example, numerical values) to the controller1, as illustrated in Table 2 below.

TABLE 2Hardware allocation dataNumber of CPUs for the host OS2Number of CPUs for the guest OS0Host OS memory (GB)4Guest OS memory (GB)4Built-in LAN port0Built-in USB port2PCI Expansion slot A1PCI Expansion slot B2. . .

Meanwhile, after determining that the input hardware allocation data to the settings screen fails to satisfy the allocation condition data (No at Step S304), the tool process unit201refrains from saving, in the hardware-allocation-data storage204, the hardware allocation data input to the settings screen. Furthermore, the tool process unit201causes the display202to present an error display representing that the input hardware allocation data fails to satisfy the allocation condition data (Step S306).

FIG. 4is a view illustrating an exemplary settings screen displayed on the tool PC in the first embodiment. The tool process unit201causes the display202to display a settings screen G showing controller information401, a hardware-allocation-data setting field402, a download button403, and an upload button404, as illustrated inFIG. 4. In the present embodiment, the tool process unit201causes the display202to display the settings screen G for each controller1, following an instruction from the user (engineer) of the tool PC2.

The controller information401serves to allow the controller1, serving to change hardware allocation data, to be identifiable, and is exemplified by the model of the controller1. The download button403serves to give an instruction for downloading the hardware allocation data input to the settings screen G to the controller1. The upload button404serves to give an instruction for uploading the hardware allocation data from the controller1.

The hardware-allocation-data setting field402serves as an interface for entering hardware allocation data. Specifically, the hardware-allocation-data setting field402displays items of the hardware allocation data (for example, the number of CPUs for host OS, the number of CPUs for guest OS, host OS memory, guest OS memory, built-in LAN port, built-in USB port, PCI expansion slot A, and PCI expansion slot B) and the corresponding hardware allocation data. The hardware-allocation-data setting field402displays hardware allocation data (for example, numerical values) input with an operation element of the tool PC2, and hardware allocation data selected from a pull-down menu displayed on the hardware-allocation-data setting field402. The pull-down menu in the hardware-allocation-data setting field402displays only selectable candidates for hardware allocation data (that is, the hardware allocation data satisfying the allocation condition data). At the time of initial display of the settings screen G (that is, with no hardware allocation data input to the hardware-allocation-data setting field402), the hardware-allocation-data setting field402displays previous values or stored values of the hardware allocation data. Herein, the previous values refer to previously input hardware allocation data. The stored values refer to the hardware allocation data stored in the hardware-allocation-data storage204(in other words, the hardware allocation data previously saved in the hardware-allocation-data storage204).

In the present embodiment, among the items of the hardware allocation data in the hardware-allocation-data setting field402, the hardware allocation data regarding the built-in LAN port, the built-in USB port, the PCI expansion slot A, and the PCI expansion slot B is input only from the pull-down menu. In the items of the built-in LAN port, the built-in USB port, the PCI expansion slot A, and the PCI expansion slot B, the pull-down menu displays conversion information. The conversion information represents information converted from selectable hardware allocation data candidates to be recognizable to the user of the tool PC2.

For example, selectable candidates for hardware allocation data for the built-in LAN port may be integers from zero to two. In this case, zero is converted and displayed as “shared between host and guest”, one is converted and displayed as “dedicated to host” and two is converted and displayed as “dedicated to guest”.

In the present embodiment, the user of the tool PC2selects hardware allocation data from the pull-down menus displayed in the hardware-allocation-data setting field402. However, the present embodiment is not limited thereto. The user of the tool PC2may freely enter any hardware allocation data in the hardware-allocation-data setting field402.

Every time one item of the hardware allocation data is input to the hardware-allocation-data setting field402, the tool process unit201determines whether the input hardware allocation data satisfies the allocation condition data stored in the allocation-condition storage203. After determining that the input hardware allocation data fails to satisfy the allocation condition data, the tool process unit201does not reflect the input hardware allocation data in the hardware-allocation-data setting field402and displays previous values or stored values of hardware allocation data in the hardware-allocation-data setting field402. After determining that the input hardware allocation data satisfies the allocation condition data, the tool process unit201displays the input hardware allocation data in the hardware-allocation-data setting field402.

In the present embodiment, upon every input of one item of the hardware allocation data, the tool process unit201determines whether the input hardware allocation data satisfies the allocation condition data. However, the present embodiment is not limited thereto. The tool process unit201may determine whether the input hardware allocation data satisfies the allocation conditions after all of the items of the hardware allocation data are input, or upon receiving an instruction for storing the hardware allocation data in the hardware-allocation-data storage204.

FIG. 5is a view illustrating an exemplary error display on the tool PC in the first embodiment. If the input hardware allocation data fails to satisfy the allocation condition data, the tool process unit201displays an error display EG on the display202as illustrated inFIG. 5. The error display EG includes, among the input items of the hardware allocation data, a name501of the item of the hardware allocation data not satisfying the allocation condition data (for example, anomaly in the number of CPUs for the host OS), and allocation condition data502of the item concerned.

FIG. 6is a flowchart illustrating exemplary processing for downloading the hardware allocation data to the controller in the first embodiment. The controller process unit103aof the controller1receives downloaded hardware allocation data from the tool PC2(Step S601). The controller process unit103aalso reads allocation condition data from the allocation-condition storage101b(Step S602).

Subsequently, the controller process unit103adetermines whether the downloaded hardware allocation data from the tool PC2satisfies the read allocation condition data (Step S603). After determining that the downloaded hardware allocation data satisfies the allocation condition data (Yes at Step S603), the controller process unit103asaves the downloaded hardware allocation data in the hardware-allocation-data storage101a(Step S604).

After determining that the downloaded hardware allocation data fails to satisfy the allocation condition data (No at Step S603), the controller process unit103arefrains from saving the downloaded hardware allocation data in the hardware-allocation-data storage101a. Further, the controller process unit103atransmits an error response to the tool PC2. The error response serves to notify the user of the fact that the downloaded hardware allocation data is invalid (Step S605). In the present embodiment, when the downloaded hardware allocation data fails to satisfy the allocation condition data, the controller process unit103atransmits an error response to the tool PC2. However, the controller process unit103amay not transmit an error response to the tool PC2.

Thus, the control system according to the first embodiment can prevent the hardware101from being allocated to the host OS102and the guest OS105in accordance with erroneous hardware allocation data. This can lower the possibility of exerting undesirable influence on the controller1.

Second Embodiment

A second embodiment describes an example of displaying on the tool PC the settings screen showing the hardware allocation data uploaded from the controller. In the following, a description of the same or like configurations as those of the first embodiment will be omitted.

FIG. 7is a view illustrating an exemplary settings screen displayed on the tool PC in the second embodiment. In the present embodiment, the tool process unit201causes the display202to display the settings screen presenting the hardware allocation data uploaded from the controller1. Specifically, the tool process unit201causes the display202to display the settings screen G including an uploaded hardware-allocation-data field701, in addition to the controller information401, the hardware-allocation-data setting field402, the download button403, and the upload button404, as illustrated inFIG. 7. The uploaded hardware-allocation-data field701displays each item of uploaded hardware allocation data from the controller1.

Thus, the control system of the second embodiment allows the user to input the hardware allocation data to the hardware-allocation-data setting field402while checking the uploaded hardware allocation data from the controller1. This can make it easier for the user to change allocation of the hardware101to the host OS102and the guest OS105. The hardware allocation data while displayed in the uploaded hardware-allocation-data field701is defined to be non-editable.

As described above, according to the first and second embodiments, it is possible to prevent the hardware101from being allocated to the host OS102and the guest OS105in accordance with erroneous hardware allocation data, which can lower the possibility of exerting undesirable influence on the controller1.

A computer program to be executed by the controller1of the embodiments is incorporated in advance into ROM, for example. The computer program to be executed by the controller1of the embodiments may be recorded and provided in an installable or executable file format on a computer-readable recording medium, such as a CD-ROM, a flexible disk (FD), a CD-R, or a digital versatile disc (DVD).

Furthermore, the computer program to be executed by the controller1of the embodiments may be stored on a computer connected to a network, such as the Internet, and provided by being downloaded via the network. The computer program to be executed by the controller1of the embodiments may also be provided or distributed via a network, such as the Internet.

The computer program to be executed by the controller1of the embodiments has a module configuration including the respective elements (the host OS102, the host process group103, the virtual machine104, the guest OS105, and the guest process group106). The CPU serves as actual hardware to read and execute the computer program from the ROM, thereby loading the respective elements onto the main memory and generating the host OS102, the host process group103, the virtual machine104, the guest OS105, and the guest process group106on the main memory.

While certain embodiments of the present invention have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. These novel embodiments may be embodied in a variety of other forms, and various omissions, substitutions, and changes may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover these embodiments or modifications thereof as would fall within the scope and spirit of the inventions.