INFORMATION PROCESSING METHOD AND INFORMATION PROCESSING APPARATUS

An information processing method includes: selecting M blocks as M selected blocks from among N blocks for driving at least one of an actuator or a heater included in an apparatus, in accordance with an input operation performed by an operator; generating an application by setting, in accordance with an input operation performed by the operator, a parameter for driving the actuator or the heater in each of the M selected blocks; consulting a rule defining a parameter range within which the above-described driving is not permitted, and modifying the application by changing at least one of the M selected blocks, the at least one of the M selected blocks including a parameter included in the parameter range; and outputting the modified application.

FIELD

The present disclosure relates to an information processing method and the like for generating a control program for an apparatus including an actuator and/or a heater.

BACKGROUND

Conventionally, home appliances and housing equipment are controlled according to operating conditions (a control program) prepared in advance by, for example, the manufacturer. Patent literature (PTL) 1 discloses a washing machine that allows the user to set operating conditions for a washing operation that he/she wishes to perform.

CITATION LIST

Patent Literature

SUMMARY

Technical Problem

Unfortunately, with the conventional technology described above, the control program must be developed in advance by the product manufacturer and stored in the product in advance, making it difficult to generate, customize, and update a wide variety of safe control programs.

In view of this, the present disclosure provides an information processing method and the like capable of easily generating a wide variety of safe control programs.

Solution to Problem

An information processing method according to one aspect of the present disclosure is executed by a computer system, and includes: (a) selecting M blocks as M selected blocks from among N blocks for driving at least one of an actuator or a heater included in a device to be controlled, in accordance with an input operation performed by an operator, where N is an integer greater than or equal to two, and M is an integer greater than or equal to one and less than or equal to N; (b) generating an application including at least the M selected blocks by setting, in accordance with an input operation performed by the operator, a parameter for driving the actuator or the heater in each of the M selected blocks; (c) consulting a rule defining a parameter range within which the at least one of the actuator or the heater is not permitted to be driven, and modifying the application by changing at least one of the M selected blocks, the at least one of the M selected blocks including a parameter included in the parameter range; and (d) outputting the application modified.

General or specific aspects of the present disclosure may be realized as a system, method, integrated circuit, computer program, computer readable medium such as a CD-ROM, or any given combination thereof.

Advantageous Effects

The information processing method according to one aspect of the present disclosure can easily generate a wide variety of safe control programs.

DESCRIPTION OF EMBODIMENTS

Underlying Knowledge Forming the Basis of the Present Disclosure

First, the process by which the inventors arrived at the present disclosure will be described. For home appliances or other products that include an actuator and/or a heater, there is a need for an open development environment to develop control programs that meet the desires of a variety of users. Stated differently, there is a need for an environment in which the difficulty of developing control programs is reduced and third parties can easily participate in the development of control programs. In such an environment, it would be possible, for example, for an apparel company to develop a control program for a washing machine to launder the clothes it sells.

In view of this, the inventors of the present application considered the creation of an environment in which control programs can be developed while maintaining safety assurance by using function blocks that abstract the control of actuators and/or heaters included in the product, and a system in which a control program consisting of a combination of a plurality of function blocks can be packaged and distributed as an application. This enables the distribution of a wide variety of applications and allows products to be customized and updated to meet the desires of a wider range of users. Unfortunately, in such an environment, dangerous applications (i.e., applications that cannot be safely controlled by the product) may be distributed, diminishing the safety of the product.

For example, it is envisioned that programs included in home appliances or other products would be incorporated into devices for direct control of actuators and/or heaters and would include a mixture of programs developed by the manufacturer and programs developed by third parties. In such cases, the manufacturer will likely not disclose to third parties all information on the home appliances or other products, including privy knowledge. For example, the parameters or timing of driving actuators and/or heaters is privy knowledge related to the performance of home appliances or other products made by the manufacturer. Manufacturers are therefore unlikely to divulge their privy knowledge to third parties so that they can freely drive their home appliances or other products, as this could cause them to lose their competitive edge.

The third parties may therefore create an application that includes a combination of controls or parameter ranges not anticipated by the manufacturer, i.e., an application with which safety cannot be guaranteed, due to lack of information about the home appliance or other product. From the perspective of the user, it is undesirable for such applications to be provided to users.

Manufacturers of home appliances or other products may attempt to improve users' lives by providing new control programs. However, the development of a wide variety of new control programs requires a great amount of man-hours to adjust parameters or evaluate hardware performance. Since the hardware of home appliances or other products is physically driven by actuators and/or heaters, one can easily expect that programs for home appliances or other products will require more man-hours for performance evaluation, etc., than programs for smartphones. However, in an age when on-demand development, rather than mass production, is required to meet the needs of each individual user's life, there is a need to develop a wide variety of control programs for home appliances or other products, similar to programs for smartphones. Manufacturers must therefore create a wide variety of applications that ensure the safety of their products with a reduction in the great amount of man-hours.

In addition, manufacturers may wish to ensure that their home appliances or other products operate safely even when operated using applications provided by third parties. In such cases, it is desirable to reduce the amount of work required to verify safety by actually driving home appliances or other products with a wide variety of applications.

In view of the above, the present disclosure provides an information processing method and the like that can easily generate a wide variety of safe applications defined by a plurality of function blocks that drive an actuator and/or a heater.

Each of the exemplary embodiments described below shows a general or specific example. The numerical values, shapes, materials, elements, the arrangement and connection of the elements, steps, the processing order of the steps, etc., shown in the following exemplary embodiments are mere examples, and do not intend to limit the scope of claims.

The appended drawings are not necessarily precise depictions. In the drawings, elements that are essentially the same share like reference signs. Accordingly, duplicate description is omitted or simplified.

1.1 Hardware Configuration

The hardware configuration of system1according to the present embodiment will be described with reference toFIG.1throughFIG.2C.FIG.1illustrates the hardware configuration of system1according to Embodiment 1.FIG.2Aillustrates the hardware configuration of cloud server10according to Embodiment 1.FIG.2Billustrates the hardware configuration of apparatus20according to Embodiment 1.FIG.2Cillustrates the hardware configuration of terminal30according to Embodiment 1.

As illustrated inFIG.1, system1according to the present embodiment includes cloud server10, and apparatuses20athrough20hand terminals30athrough30dused in facilities2athrough2d. For example, facilities2athrough2dare, but not limited to, residences. For example, facilities2athrough2dmay be apartments, stores, offices, etc.

Cloud server10is a virtual server provided via a computer network (for example, the internet). Cloud server10is connected to apparatuses20athrough20hand terminals30athrough30dvia the computer network. A physical server may be used instead of cloud server10.

As illustrated inFIG.2A, cloud server10includes, virtually, processor11and memory12connected to processor11. Processor11functions as a sequence manager and a device manager, which will be described below, when instructions or a software program stored in memory12are executed.

Apparatuses20athrough20hare electromechanical devices used in facilities2athrough2d. Note thatFIG.1omits the illustration of apparatuses20cthrough20hused in facilities2bthrough2d. Hereinafter, when it is not necessary to distinguish between apparatuses20athrough20h, they will be referred to as apparatuses20or in the singular as apparatus20.

Home appliances and housing equipment can be used as apparatuses20. Home appliances and housing equipment are not limited to devices used in residences, and also include devices used in businesses. In the present disclosure, “home appliances and housing equipment or other products” may be shortened to “home appliances or other products”. Home appliances include, for example, microwave ovens, rice cookers, blenders, electric ovens, electric toasters, electric hot water servers, hot plates, induction heating (IH) cookers, roasters, bread makers, electric pressure cookers, electric waterless cookers, multi-cookers, coffee makers, refrigerators, washing machines, dishwashers, vacuum cleaners, air conditioners, air purifiers, humidifiers, hair dryers, electric fans, and ion generators. Housing equipment include, for example, electric shutters, electronic locks, and electric water heaters for bathtubs. However, apparatuses20are not limited to these examples.

As illustrated inFIG.2B, apparatus20includes enclosure21, actuator22, heater23, and controller24. Apparatus20need only include at least one of actuator22or heater23, and need not include both actuator22and heater23.

Enclosure21houses actuator22, heater23, and controller24. Enclosure21may include an interior space for processing a target. For example, the drum of a washing machine, the cooking compartment of a microwave oven, and the inner pot of a rice cooker correspond to the interior space for processing a target.

Actuator22is a mechanical element that converts input energy into physical motion based on electrical signals. For example, electric motors, hydraulic cylinders, and pneumatic actuators can be used as actuator22, but examples are not limited thereto.

Heater23is an electric heater that converts electrical energy into thermal energy. Heater23heats the target by, for example, Joule heating, induction heating, and/or dielectric heating. For example, nichrome wires, coils, and magnetrons can be used as heater23.

Next, one example of why apparatus20according to the present disclosure includes actuator22and/or heater23will be given. Consider a case in which a manufacturer of home appliances or other products provides a third party with a development environment that allows free control of all parameters and combinations of drives for actuator22and heater23. In such a case, the third party would be able to create a program to control actuator22and/or heater23so as to operate outside of the range of parameters anticipated by the manufacturer at which actuator22and/or heater23can be safely driven or outside the drive limits of actuator22and/or heater23. In particular, the driving of actuator22, which physically moves, or heater23, which outputs thermal energy, in a manner unanticipated by the manufacturer poses significant safety assurance issues. Examples of driving in a manner unanticipated by the manufacturer include the high-speed rotation of an electric motor, which is one example of the actuator, and the supply of excessive current to heater23. The inventors of the present application aimed to ensure that excessive safety considerations would not inhibit the creation of an environment that could provide users with a wide variety of applications. Apparatus20according to the present disclosure therefore is specific to actuators22, which physically move, or heaters23, output thermal energy, with an eye to ensuring safety.

Controller24is a controller that controls actuator22and/or heater23and functions as a device, which will be described later. Controller24is configured as, for example, an integrated circuit.

Terminals30athrough30dare used at facilities2athrough2d, respectively, and function as user interfaces. Note thatFIG.1omits the illustration of terminals30bthrough30dused in facilities2bthrough2d. Hereinafter, when it is not necessary to distinguish between terminals30athrough30d, they will be referred to as terminals30or in the singular as terminal30.

Terminals30are connected to cloud server10and apparatuses20via the computer network and function as a user interface (UI), which will be described later. Portable information terminals such as smartphones and tablet computers can be used as terminals30. Terminals30may be fixed to the wall, floor, or ceiling of facilities2athrough2d. Terminals30may be included in apparatuses20. For example, terminals30may be realized as a display terminal including a display built into apparatuses20athrough20h.

As illustrated inFIG.2C, terminal30includes display31and input device32. For example, a liquid crystal display and an organic electroluminescent display can be used as display31. For example, a touch panel, a keyboard, a mouse, and a mechanical button can be used as input device32. A voice input device may be used as input device32. Display31and input device32may be integrally implemented as a touch screen. Alternatively, a gesture input device may be used as input device32. A gesture input device includes, for example, a camera and a recognition unit. The camera captures images containing gestures, and the recognition unit recognizes the gestures using the images.

1.2 Functional Configuration

Next, the functional configuration of system1according to the present embodiment will be described with reference toFIG.3.FIG.3illustrates the functional configuration of system1according to Embodiment 1.

Hereinafter, when it is not necessary to distinguish between devices300athrough300h, they will be referred to as devices300or in the singular as device300. Similarly, when it is not necessary to distinguish between UIs400athrough400d, they will be referred to as UIs400or in the singular as UI400.

Sequence Manager100manages a plurality of applications. The plurality of applications are downloaded to sequence manager100from an application delivery platform by, for example, user interaction. Alternatively, applications included in the application delivery platform may not be downloaded to sequence manager100. In such cases, information indicating that the applications included in the application delivery platform are associated with it may be recorded in the database of sequence manager100. The applications will be described in greater detail later.

Device Manager200includes a database for managing facilities2athrough2d, as well as devices300and UIs400used at the respective facilities2athrough2d. Device Manager200manages devices300and UIs400by recording device information and UI information associated with facilities2athrough2din a database. Device information and UI information includes, for example, control functions and drive functions, as well as operating status. For example, device manager200can manage the operating statuses of devices300and keep track of the operating schedules of devices300. Device Manager200may manage log information for devices300.

Such a database may be included in sequence manager100instead of device manager200, or included in both sequence manager100and device manager200.

Device300includes control functions and drive functions for apparatus20. Device300can drive apparatus20according to instructions from device manager200.

UI400provides information to the user and accepts inputs from the user.

Next, the applications will be described. In the present embodiment, an application (hereinafter sometimes abbreviated as “app”) means a control program defined by a plurality of function blocks (hereinafter abbreviated as “blocks”) that drive actuator22and/or heater23. Each of the blocks can include a parameter for driving actuator22or heater23. More specifically, each of the blocks is an abstraction of the control of actuator22or heater23. In addition to the blocks that drive actuator22and/or heater23, the application may include blocks that do not drive actuator22and/or heater23. Examples of blocks that do not drive actuator22and/or heater23include the displaying of information using an interface included in device300, the outputting of sound using a buzzer included in device300, and the turning on or off of a lamp included in device300. The block may include a condition to start driving actuator22or heater23. For example, assume an application includes a first block and a second block. Here, when switching to the second block during the execution of the first block, when the start condition included in the second block is met, the second block is switched to from the first block. The block may also contain an end condition rather than a start condition. Here, when switching to the second block during the execution of the first block, when the end condition included in the first block is met, the second block is switched to from the first block.

FIG.4illustrates one example of a block that defines an application according to Embodiment 1. Block1000illustrated inFIG.4controls the agitation operation of a washing machine and includes parameters1001through1006. Parameter1001includes information indicating the type of agitation (for example, normal, “dancing”, or rocking). In other words, parameter1001can be said to indicate the type of function. Parameter1002includes a value indicating the drum speed. In other words, parameter1002can be said to indicate the intensity of the driving of actuator22and/or heater23. Parameter1003includes a value indicating the amount of water supplied to the drum in terms of the water level after the water has been supplied. In other words, parameter1003can be said to indicate the state after the driving of actuator22and/or heater23. Parameter1004includes a value indicating whether the circulation pump is on or off. In other words, parameter1004can be said to indicate whether to drive actuator22and/or heater23. Parameter1005includes information indicating the agitation interval in terms of stages (for example, short, medium, long). Parameter1006includes a value indicating the agitation time.

A plurality of such blocks are used to define the application. For example, a plurality of blocks such as those illustrated inFIG.5throughFIG.7are used.

FIG.5illustrates a plurality of blocks for a washing machine according to Embodiment 1.FIG.6illustrates a plurality of blocks for a microwave oven according to Embodiment 1.FIG.7illustrates a plurality of blocks for a rice cooker according to Embodiment 1. The plurality of blocks illustrated inFIG.5throughFIG.7are merely examples; blocks for a washing machine, a microwave oven, and a rice cooker are not limited to these examples. For example, the plurality of blocks may be hierarchized by abstraction level.

For example, the abstraction level may be changed between a level for manufacturers and a level for non-manufacturers. Examples of a level for non-manufacturers include a level for other manufacturers and a level for third parties.

Here, the level for manufacturers is less abstract than the level for non-manufacturers. A low level of abstraction means that the control content is close to the parameters that drive the actuator and the heater.

On the other hand, for non-manufacturers, the manufacturer provides blocks with the minimum level of abstraction that ensures privy knowledge stays privy and guarantees safety, thereby enabling non-manufacturers to develop applications. The manufacturer can provide blocks with an even higher level of abstraction to ordinary users to enable even more people to develop applications. For example, a higher level of abstraction corresponds to blocks defined in terms that can be understood by ordinary users without specialized knowledge. Terms that can be understood without specialized knowledge are those that correspond to the functionality of the home appliance or other product, for example. More specifically, if “plenty” is selected as the parameter for water amount in the “wash” block in a washing machine, in one low-abstraction layer, the water level parameter in the water supply block is increased from 60 mm to 100 mm, the rotation amount parameter in the agitate block is decreased from 120 rpm to 100 rpm, and so on. With this, rearranging blocks and changing parameters at a higher level of abstraction can be achieved with lower level of abstraction blocks. A plurality of blocks may be defined just like inFIG.5throughFIG.7for apparatuses other than washing machines, microwave ovens, and rice cookers as well. These blocks allow for free development of applications by reconfiguring and adjusting parameters while ensuring the safety and confidentiality of the driving of the actuator and the heater drive.

For example, in apparatus20according to the present embodiment, the application may include information on the plurality of blocks and information on the order in which each of the plurality of blocks is executed, and when the rule includes information indicating at least one block among the plurality of blocks cannot be executed, the rule may present, to a developer as error information, that the application cannot be developed or information on the block that cannot be executed.

Next, processes performed by system1configured as described above will be described with reference toFIG.8.FIG.8is a sequence diagram of system1according to Embodiment 1.

Sequence manager100transmits sequence manager information to device manager200. This transmission of sequence manager information is performed, for example, by instruction of the system administrator. Device manager200registers the received sequence manager information in a sequence manager database, for example. This step may be skipped if the sequence manager information is already registered in the sequence manager database.

The sequence manager information includes, for example, an identifier and/or an address of sequence manager100(for example, the uniform resource locator (URL) or internet protocol (IP) address or the like). Sequence manager information may further include any sort of information.

Device300transmits device information1101to device manager200. This transmission of device information1101is done, for example, when device300is connected to a computer network. Device Manager200registers the received device information1101in device database1100. This step may be skipped if device information1101is already registered in device database1100.

Device information1101may be sent to UI400and then registered in device manager200via UI400.

Device information1101includes an identifier and/or an address of device300. Device information1101may further include any sort of information.FIG.9illustrates one example of a device database according to Embodiment 1. A plurality of items of device information, including device information1101, are registered in device database1100inFIG.9. Each item of device information includes a device ID, an address, a type, a manufacturer name, a model number, actuator/heater, and a degradation level. Actuator/heater is information identifying actuator22and/or heater23included in device300. The degradation level is one example of degradation information that indicates whether actuator22and/or heater23included in device300has degraded or not. Here, a higher degradation level indicates more degradation. Device information1101may include information about executable blocks. Information about executable blocks may be information that specifies blocks in the database as executable or non-executable, or it may be information about executable blocks only. Whether a block is executable or not can be prepared in advance based on information such as the actuator/heater information included in device information1101.

Device information1101may include information that can identify facilities2athrough2d.

UI400transmits UI information to device manager200. This UI information is transmitted, for example, by user instruction. Device manager200registers the received UI information in a UI database, for example. This step may be skipped if the UI information is already registered in the UI database.

UI information1101includes an identifier and/or an address of UI400, for example. The UI information may further include any sort of information.

The UI information may include information that can identify facilities2athrough2d.

Through the above processes, sequence manager100, device manager200, device300, and UI400can be associated with each other and establish a connection with each other. This completes preparation phase F100.

Next, app pre-execution phase F200will be described. Prior to app pre-execution phase F200, the application is downloaded from the application delivery platform to sequence manager100in accordance with instructions from the user received via UI400. With the application downloaded to sequence manager100, the following processes are performed.

UI400accepts an app execution request from the user and transmits the app execution request including information identifying the application to sequence manager100. For example, the user selects an application from among several applications downloaded to sequence manager100via UI400, and instructs the execution of the selected application.

The app execution request transmitted from UI400to sequence manager100is transmitted as a set with information that can identify facilities2athrough2d.

The app execution request does not have to be explicitly accepted from the user. For example, the user's behavior or state may be detected and an app execution request may be automatically transmitted to sequence manager100based on the detection results.

Sequence manager100transmits the execution content declaration of the application identified by the app execution request to device manager200. The execution content declaration includes information on the plurality of blocks that define the application to be executed and information that can identify facilities2athrough2d.

FIG.10illustrates one example of an execution content declaration according to Embodiment 1.FIG.10illustrates execution content declaration1200for the application defined by combining a plurality of blocks for the washing machine illustrated inFIG.5. Execution content declaration1200includes a plurality of blocks1201, information1202about the device required to execute each block1201, and information1203on the order in which blocks1201are to be executed.

Execution content declaration1200does not need to include information1202about the device. In such cases, device manager200needs to search for a device that can execute the relevant block at the facility indicated by the received facility information from information about the plurality of blocks1201and perform device allocation.

InFIG.10, information1202about the device indicates the model number of device300, but information1202is not limited to this example. Information1202about the device may be any information that can indicate a condition for device300that can be assigned to the block. For example, information1202about the device may include a plurality of model numbers, or may include only the type of device, intended use, device location, or any combination of these.

Device manager200allocates device300associated with device manager200to each block in the execution content declaration, based on information that can identify facilities2athrough2d. For example, device manager200allocates, to each of the plurality of blocks1201illustrated inFIG.10, device DEV001having a model number of WM-0001, which is registered in device database1100inFIG.9as being connected to the facility indicated by the received facility information. If the operational status of device300or its connection to the cloud is managed, the allocation of a device300that is in operation may be prohibited.

For example, if the plurality of blocks illustrated inFIG.10are not registered as being connected to the facility indicated by the received facility information, i.e., if the target device does not exist at this facility, device manager200notifies sequence manager100of whether the application corresponding to the execution content declaration is executable or not.

Device manager200notifies devices300of the result of the device allocation. This transmits the respective blocks included in the application to the respective allocated devices300.

Device300checks a block before it is executed. Stated differently, before executing a block, device300checks to see if any problems will arise in device300if the block is executed. For example, device300checks for safety and/or efficiency issues.

Device300then changes the block based on the result of the check. This corrects the blocks so that problems do not arise.

This pre-execution check process will be described in greater detail with reference toFIG.11.FIG.11illustrates a flowchart of the pre-execution check process according to Embodiment 1.

Device300obtains a rule corresponding to a block. The rule defines a parameter range within which at least one of actuator22or heater23is not permitted to be driven (hereafter referred to as a non-permissible range). For example, device300consults the rule database to obtain a parameter range corresponding to actuator22or heater23that the block drives. For example, the rule database may be included in device300, and may be included in sequence manager100or device manager200.

FIG.12illustrates one example of a rule database according to Embodiment 1. Rules1301and1302are registered in rule database1300inFIG.12. Each of rules1301and1302includes a parameter range that defines a non-permissible range. For example, rule1301includes a range greater than 1000 rpm as a non-permissible range.

InFIG.12, each of rules1301and1302includes a non-permissible range as a parameter range, but this example is non-limiting. For example, each of rules1301and1302may include, as the parameter range, a parameter range within which actuator22or heater23is permitted to be driven (hereafter referred to as a permissible range). Even in this case, each of rules1301and1302may define, as the non-permissible range, a range excluding the permissible range. The permissible range is defined as a range within which actuator22or heater23can be safely driven. Furthermore, the permissible range is defined such that a wide range of parameters can be used for the development of a wide variety of applications.

For example, the parameters by which actuator22or heater23can be safely driven may vary depending on the environment of device300, such as the interior space of enclosure21, and the permissible range may not depend solely on the performance of actuator22or heater23itself. Therefore, in order to ensure safe driving in any environment, the permissible range is heavily weighted in favor of safety, which reduces the freedom for development of a wide variety of applications. The rules may therefore be independent of the application and may be associated with information on, for example, device300. The use of such rules allows for both safety and the development of a wide variety of applications.

The rules relate to the range within which actuator22or heater23can be safely driven. The range within which actuator22or heater23can be safely driven may be a range that takes into account the start condition or the end condition of the block. Consider an example including a first block and a second block that is executed after the first block. A rule (a permissible range) could be set for a case in which the first block is to be executed until the start condition of the second block is reached, whereby actuator22or heater23is loaded with a load that affects safety. Stated differently, the permissible range depends on the performance of actuator22or heater23, the start condition or the end condition of the block, etc.

For example, the permissible range or the non-permissible range may be defined by a combination of a plurality of parameters. More specifically, the permissible range or the non-permissible range may be a range of output values of a plurality of parameter functions. For example, if device300is a washing machine, the permissible range or non-permissible range may be a range of output values of a function of a first parameter indicating water level and a second function indicating motor speed. The function can be predetermined empirically and/or experimentally. Instead of a function, a permissible range or non-permissible range may be defined by a collection of a plurality of combinations of parameter values.

Each of rules1301and1302further includes the type, the manufacturer name, and actuator/heater. This allows device300to obtain, from rule database1300, rules corresponding to actuator22or heater23that is driven by the block. For example, device300consults rule database1300inFIG.12, and obtains rules1301for the spin block inFIG.10.

Device300determines if the parameters included in the block are within the non-permissible range. If device300determines that the parameters are not within the non-permissible range (No in S2166), device300skips the subsequent step S2167and ends the pre-execution check process. However, if device300determines that the parameters are within the non-permissible range (Yes in S2166), device300proceeds to the next step S2167.

Device300changes the block and ends the pre-execution check process. Changing a block means changing the contents of the block, removing the block, adding a new block before or after the block, or any combination thereof.

For example, device300can change a block by changing the parameters of the block to parameters that are within the permissible range. A specific example of such a change to a block will be described with reference toFIG.13.

FIG.13illustrates one example of changing a block according to Embodiment 1. InFIG.13, since the speed parameter in the spin block is included in the non-permissible range, it is changed to a parameter that is included in the permissible range (from 1200 rpm to 1000 rpm).

For example, device300can also change a block by changing the parameters of the block to parameters that are within the permissible range and adding a new block. A specific example of such a change to a block will be described with reference toFIG.14.

FIG.14illustrates one example of changing a block according to Embodiment 1. InFIG.14, since the time parameter in the spin block is included in the non-permissible range, it is changed to a parameter included in the permissible range (from 600 s to 300 s), and a stop block and spin block are added after the spin block. For example, by changing a block that unintentionally places a load on device300by spinning the wash tank at high speed for a long time during the spin operation, the load can be reduced, a stop added, and the spin block performed again, allowing the application to safely perform the functions defined in the application before the change.

For example, device300can also change a block by removing it.

Although the changing of a block for a washing machine is described here, a block can be changed for other apparatuses in the same manner as well.

In a rice cooker, if the parameter for the temperature of the bottom of the pot is included in the non-permissible range, the parameter for the temperature of the bottom of the pot may be changed to a parameter that is included in the permissible range. If a duration parameter is in the non-permissible range, the duration parameter may be changed to a duration parameter that is in the permissible range and a new block may be added.

Device300transmits the result of the pre-execution check to device manager200. If a block has been modified, the modified block may be transmitted to device manager200.

Device manager200responds to sequence manager100with the result of the device allocation. If the block has been modified in the pre-execution check, the application including the modified block may be transmitted to sequence manager100.

Sequence manager100receives a notification of the allocation result from device manager200and notifies the user that execution preparation is complete via UI400.

UI400displays a list of devices on which the application will be executed and a graphical user interface (GUI) for accepting input from the user to confirm execution of the application. UI400may accept device allocation changes from the user. Moreover, UI400does not need to display a list of devices.

UI400receives execution confirmation input from the user and transmits an instruction to start the app to device manager200. Device manager200forwards the instruction to start the app to sequence manager100.

Steps S220, S222, and S224, which again provide information to the user before the application is executed, may be omitted because they may increase the user's workload.

This completes app pre-execution phase F200.

Sequence manager100receives the instruction to start the app and selects the initial block (the first block) from among the plurality of blocks included in the application. Sequence manager100then transmits an instruction to execute the selected first block to device manager200.

When a plurality of blocks operate consecutively, sequence manager100may send instructions to execute the plurality of blocks together to device manager200.

Device manager200transmits the instruction to execute the first block to device300allocated to the first block, based on the instruction to execute the first block received from sequence manager100.

Device manager200receives the instruction to execute the first block, and updates the schedule (scheduled time of use) for each device.

Device300receives the instruction to execute the first block, and executes the first block.

Device300transmits a notification of completion to device manager200when the execution of the first block is complete. If an error occurs during the execution of the first block, device300may send error information to device manager200. Device300may send event information to device manager200during the execution of the first block. For example, sensor output values or device operations can be used as event information, but examples are not limited thereto. Device manager200forwards the notification of completion and/or the various information received from device300to sequence manager100.

Upon receiving the notification of completion of the first block, sequence manager100updates the application progress, and selects the next block (the second block). If sequence manager100receives error information, it executes a process corresponding to the error information (for example, return to the previous block, return to the first block, wait, etc.). Information on the process corresponding to the error information, for example, may be held in advance in sequence manager100or accepted from the user via UI400. If sequence manager100receives event information, it executes a process corresponding to the event information. For example, if the event information includes the output value of the water level sensor, sequence manager100updates the water level parameter for indicating water level in the block being executed.

Sequence manager100then transmits an instruction to execute the selected second block to device manager200.

The instruction to execute the second block may be an instruction to the same device as the instruction to execute the first block (S310), or to a different device.

The instruction to execute the second block may be transmitted to device manager200in the same manner as the execution instructions for the first block—by transmitting instructions to execute a plurality of blocks together.

Subsequent processing is the same as for the first block (S312through S318), so repeated illustration in the figures and explanation in the description are omitted. The blocks included in the application are executed in sequence, and when the execution of the last block is completed, app execution phase F300ends.

Although the execution of blocks is exemplified as being instructed one by one in sequence, the execution of blocks is not limited to this example. For example, the execution of a plurality of blocks allocated with the same device may be instructed together. In such cases, it may be checked in advance whether each block satisfies the parameter range for executing its function, or a block corresponding to the change may be downloaded to the device before execution. For example, instructions to execute each of the blocks may be given to a plurality of devices.

As described above, the application including one or more blocks and the rule database provide an environment in which a wide variety of applications can be developed, and for applications freely developed in that environment, actuator22that physically moves or heater23that outputs thermal energy can be safely driven. Stated differently, the application including one or more blocks and the rule database can provide an environment in which applications can be freely developed, while at the same time providing functions to ensure safety independent of the application. As a result, for example, the development of a wide variety of applications with a high degree of freedom and the development of a rule database to ensure safety can be created in parallel, enabling the early development of a wide variety of applications.

Even after the application is provided, the rule database can be modified to make the application more secure. In addition, even if a manufacturer needs to improve a situation that was not anticipated beforehand, the rule database is defined independently from the applications, so all applications can be supported by updating the rule database, without having to change a wide variety of applications themselves.

One conceivable measure is to store a rule base for error handling by detecting the state of the application when it is executed, without modifying the application itself. However, this measure invariably means dealing with the error condition after it has occurred, allowing a situation where the home appliance is overloaded or a situation where safety cannot be guaranteed. It is therefore possible to include a rule database independent of the applications, and to guarantee safety by modifying the application content by consulting the rule data.

Apparatus20according to the present embodiment includes: at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24obtains an application defined by a plurality of blocks that drive the at least one of actuator22or heater23. Each of the blocks includes a parameter for driving actuator22or heater23. Controller24consults a first rule that defines a first parameter range in which the at least one of actuator22or heater23is not permitted to be driven, and modifies the application by changing at least one of the plurality of blocks. The at least one of the plurality of blocks includes a parameter included in the first parameter range. Controller24drives the at least one of actuator22or heater23based on the modified application.

This allows actuator22and/or heater23to be driven based on an application defined by a plurality of blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications to be developed not only by the manufacturer but also by third parties, and these applications can be easily executed on apparatus20. Furthermore, before actuator22and/or heater23is/are driven based on the application, a block including a parameter in the first parameter range that is not permitted can be changed. Thus, it is possible to inhibit actuator22and/or heater23from being driven at a non-permissible parameter. Stated differently, if an application developer mistakenly instructs the driving of actuator22and/or heater23at a non-permissible parameter, it is still possible to inhibit the execution of an application that cannot safely control apparatus20. Thus, the application developer can improve the safety of apparatus20controlled by the application, even if the application is created with an emphasis on suitability for the user rather than ensuring the safety of actuator22and/or heater23.

For example, in apparatus20according to the present embodiment, controller24may consult the first rule, and modify the application by changing a parameter included in the first parameter range to a parameter included in a range in which the at least one of actuator22or heater23is permitted to be driven.

With this, since a parameter included in the non-permissible first parameter range can be changed to a parameter included in the permissible range, for example, the application developer can lower the priority that takes into consideration the safe driving of actuator22and heater23to more freely develop the application, and furthermore, the developer of the software that is incorporated in apparatus20that controls actuator22and heater23can allow the execution of blocks without having to check the safety of each and every application every time, whereby actuator22and/or heater23can be prevented from being driven with non-permissible parameters.

For example, in apparatus20according to the present embodiment, controller24may consult the first rule, and modify the application by changing a parameter included in the first parameter range to a parameter included in a range in which the at least one of actuator22or heater23is permitted to be driven, and adding a new block to the plurality of blocks.

With this, since a parameter included in the non-permissible first parameter range can be changed to a parameter included in the permissible range, actuator22and/or heater23can be prevented from being driven with non-permissible parameters. Furthermore, since a new block can be added, it is possible to supplement a function degraded by a parameter change with a new block.

For example, in apparatus20according to the present embodiment, controller24may modify the application by removing the at least one block including a parameter included in the first parameter range.

With this, since a block including a parameter included in the non-permissible first parameter range can be removed, actuator22and/or heater23can be prevented from being driven with non-permissible parameters. For example, if actuator22and heater23are unable to execute the parameter specified by the application developer in the first place, the removal allows the device to be controlled without confusion. On the other hand, the user may be notified of the removal.

For example, in apparatus20according to the present embodiment, controller24may consult the first rule, determine, for each of a plurality of parameters included in the plurality of blocks, whether the parameter is included in the first parameter range, and when controller24determines that the parameter is included in the first parameter range, may change the block including the parameter.

This makes it possible to more reliably change a block including a parameter included in the non-permissible first parameter range.

For example, in apparatus20according to the present embodiment, the application may include information on the order in which each of the plurality of blocks is executed and information on the timing of execution of each of the plurality of blocks. The information on the timing for each of the blocks indicates, for example, the amount of time between the start of the block and the start or end of another block (for example, the block that is first in order).

This enables the application to include order and timing information, and to make decisions and execute them sequentially while checking the parameter ranges of each block.

For example, in apparatus20according to the present embodiment, the application may include information on the plurality of blocks and information on the order in which each of the plurality of blocks is executed, and when the rule includes information indicating at least one block among the plurality of blocks cannot be executed, the rule may present, to a developer as error information, that the application cannot be developed or information on the block that cannot be executed.

With this, a new block can be added, the order of blocks can be changed, or a block can be removed before the application is executed to ensure that the third block is executed after the second block. Accordingly, the application developer can lower the priority that takes into consideration the safe driving of actuator22and heater23to more freely develop the application. Furthermore, the developer of the software that is incorporated in apparatus20that controls actuator22and heater23can allow the execution of blocks without having to check the safety of each and every application every time.

For example, in apparatus20according to the present embodiment, the first parameter range may be a range of parameters that allow the at least one of actuator22or heater23to reach its maximum withstand temperature.

This makes it possible to inhibit actuator22and/or heater23from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

For example, apparatus20according to the present embodiment may include enclosure21including an interior space, and the first parameter range may be a range of parameters that allow the interior space to reach its maximum withstand temperature.

This makes it possible to inhibit the interior space of enclosure21from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

Variations of Embodiment 1

In Embodiment 1, processes performed by system1are described with reference toFIG.8, but the flow of processes is not limited to this example. In particular, regarding the pre-execution check (S216) described in detail, the timing and the main module in which the pre-execution check are performed are not limited to this example. Next, a number of variations of the sequence diagram for system1will be described in detail with reference toFIG.15AthroughFIG.15E.

FIG.15Aillustrates a sequence diagram for system1according to Variation 1 of Embodiment 1. InFIG.15A, the pre-execution check (S216) is performed by device300just before device300receives the execution instruction (S310) to execute the block (S314).

This allows the software incorporated in device300to be simply configured to perform a pre-execution check just before the execution of a block. Stated differently, steps S215and S217can be omitted. As a result, it is no longer necessary to incorporate functions and a communication API for these processes into device300, and it is therefore possible to reduce memory used by the microcontroller in device300.

The result of the pre-execution check may be notified to device manager200and/or UI400. For example, device manager200or UI400may be notified of the result of the check when a parameter change or an instruction to stop execution of a block is made as a result of the pre-execution check.

FIG.15Billustrates a sequence diagram for system1according to Variation 2 of Embodiment 1. InFIG.15B, the pre-execution check (S216) is performed by device manager200as it performs the allocation result notification (S218).

With this, the software incorporated in device300does not need to include the function for performing the pre-execution check (S216). Thus, the use of memory included in device300can be reduced, leading to a cost reduction of device300.

In Embodiment 1, regarding the block execution (S314) by device300, the flow of processes performed by instructions from sequence manager100implemented in cloud server10is described, but the aspect in which the block execution (S314) is performed is also not limited to this example.

For example, the content of the notification from sequence manager100may be stored in memory in device300, and the block may be executed by direct instruction from the user through the UI included in apparatus20or UI400included in terminal30. Stated differently, the application may be downloaded to the device and the user may execute the application at any time.

FIG.15Cillustrates a sequence diagram for system1according to Variation 3 of Embodiment 1. InFIG.15C, in app execution phase F300, sequence manager100notifies device300of one or more blocks to be executed on device300(S310C). Device300then stores the notified one or more blocks in memory (S311C).

Device300then accepts instructions from the user to execute the stored one or more blocks (S312C) and executes the one or more blocks in order starting with the first block (S314).

As described above, by storing the one or more blocks in device300, device300can be controlled without communication between device manager200and device300, thus reducing the risk of device300outage or delay due to unstable communication between cloud server10and apparatus20. Therefore, this variation is more effective in environments where communication with cloud server10is unreliable and/or in device300where device outages or delays during application execution are not tolerated.

In Variation 3, as in Embodiment 1, the pre-execution check (S216) is also important, but the timing and the main module in which the pre-execution check (S216) is performed are not limited toFIG.15C. In other words, Variation 3 may be combined with Variation 1 or 2.

FIG.15Dillustrates a sequence diagram for system1according to Variation 4 of Embodiment 1. Variation 4 corresponds to a combination of Variation 1 and Variation 3. In Variation 4, as illustrated inFIG.15D, the pre-execution check (S216) is performed by device300just after device300receives the execution instruction (S312C) and just before device300executes the block (S314).

If a block is downloaded to device300and the user executes the block at any given time, the possibility of a significant discrepancy between when the block is downloaded and when it is executed increases. Stated differently, the block may be executed, for example, days, months, or years after the block is downloaded to device300. In such cases, the degradation level, etc., of device300may change between the time the block is downloaded and the time the block is executed. Therefore, in device300—the degradation level of which affects the execution of a block—a pre-execution check is performed by device300just before the block is executed, which allows for pre-execution check that is dependent on degradation level

FIG.15Eillustrates a sequence diagram for system1according to Variation 5 of Embodiment 1. Variation 5 corresponds to a combination of Variation 2 and Variation 3. In Variation 5, as illustrated inFIG.15E, the pre-execution check (S216) is performed by device manager200as it performs the allocation result notification (S218).

Next, Embodiment 2 will be described. The present embodiment differs from Embodiment 1 primarily in that the pre-execution check is skipped when the application is authenticated. Hereinafter, the present embodiment will be described with a focus on the points of difference from Embodiment 1.

The hardware and functional configurations of system1according to the present embodiment are the same as in Embodiment 1. Accordingly, repeated illustration in the figures and explanation in the description are omitted.

In the present embodiment, the processes are the same as in Embodiment 1 except that step S216of the pre-execution check in Embodiment 1 is replaced with step S216A. Step S216A of the pre-execution check process will therefore be described with reference toFIG.16.

FIG.16illustrates a flowchart of the pre-execution check process according to Embodiment 2.

Device300obtains app authentication information. If the application has been authenticated, the app authentication information includes information indicating that the application has been authenticated.

Application authentication is a mechanism for guaranteeing the quality of an application, for example, by enabling confirmation of the application's security and/or identity (i.e., that it has not been tampered with). Next, one example of an application granted with authentication information will be given. If the change history of the application's code indicates that no changes were made to parameter ranges, information indicating that the application has been authenticated is associated with the application.

Device300determines whether the application is authenticated or not based on the retrieved app information. Here, if the application is determined to be authenticated (Yes in S2162A), device300skips the subsequent steps S2165to S2167and terminates the pre-execution check process. If, however, it is determined that the application is not authenticated (No in S2162A), device300proceeds to the next step S2165.

As described above, apparatus20according to the present embodiment includes: at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24obtains an application that is defined by a plurality of blocks that drive the at least one of actuator22or heater23and includes information indicating whether the application has been authenticated. Each of the plurality of blocks includes a parameter for driving actuator22or heater23. When the application does not include information indicating that the application has been authenticated, controller24consults a first rule that defines a first parameter range within which the at least one of actuator22or heater23is not permitted to be driven, and modifies the application by changing at least one of the plurality of blocks. The at least one of the plurality of blocks includes a parameter included in the first parameter range. Controller24drives the at least one of actuator22or heater23based on the modified application.

This allows actuator22and/or heater23to be driven based on an application defined by a plurality of blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications developed in this manner to be easily executed on apparatus20. Furthermore, before actuator22and/or heater23is/are driven based on the application, a block including a parameter in the first parameter range that is not permitted can be changed. Thus, it is possible to inhibit actuator22and/or heater23from being driven at a non-permissible parameter. Stated differently, it possible to inhibit the execution of an application that cannot control apparatus20safely, which makes it possible to improve the safety of apparatus20controlled by the application. Furthermore, when the application is not authenticated, processes that involve application modifications can be performed, which reduces the processing load when the application is authenticated. It is therefore not necessary to perform the determination process for the parameter range for all applications, and management through authentication reduces the processing load and facilitates design standards for the parameter range, making it easier and safer for application developers to design.

For example, in apparatus20according to the present embodiment, when the application includes information indicating that the application has been authenticated, controller24may not consult the first rule and may not modify the application.

This allows the process for changing the blocks to be skipped if the application has already been authenticated, thus reducing the processing load.

Next, Embodiment 3 will be described. The present embodiment differs from Embodiment 1 above primarily in that the pre-execution check is skipped when the creator of the application and the producer of the apparatus are the same. Hereinafter, the present embodiment will be described with a focus on the points of difference from Embodiment 1.

The hardware and functional configurations of system1according to the present embodiment are the same as in Embodiment 1. Accordingly, repeated illustration in the figures and explanation in the description are omitted.

In the present embodiment, the processes are the same as in Embodiment 1 except that step S216of the pre-execution check in Embodiment 1 above is replaced with step S216B. Step S216B of the pre-execution check process will therefore be described with reference toFIG.17.

FIG.17illustrates a flowchart of the pre-execution check process according to Embodiment 3.

Device300obtains app creator information. The app creator information indicates the creator of the application. Here, “creator” means, for example, the company, individual, or organization that created the application, and may also be referred to as “developer” or “author”.

Device300obtains device manufacturer information. The device manufacturer information indicates the producer of the device. Here, “producer” means, for example, the company, individual, or organization that produced device300(i.e., apparatus20), and may also be referred to as “manufacturer”.

Device300determines whether the creator of the application is different from the producer of device300. If the creator of the application is an individual and the producer of device300is a company, device300may determine that the creator of the application and the producer of device300are the same if the company to which the creator of the application belongs and the producer of device300match. Device300may also determine that the creator of the application and the producer of device300are the same if the creator of the application is a development contractor contracted by the producer of device300.

Here, if the creator of the application and the producer of device300are the same (No in S2164B), device300skips the subsequent steps S2165to S2167and ends the pre-execution check process. If, however, the creator of the application and the producer of device300are different (Yes in S2164B), device300proceeds to the next step S2165.

As described above, apparatus20according to the present embodiment includes controller24that controls at least one of actuator22or heater23. Controller24obtains an application that is defined by a plurality of blocks that drive the at least one of actuator22or heater23and includes information indicating a creator of the application. Each of the plurality of blocks includes a parameter for driving actuator22or heater23. Controller24obtains the information indicating the producer of apparatus20, and when the creator of the application and the producer of apparatus20are different, controller24consults a first rule that defines a first parameter range within which the at least one of actuator22or heater23is not permitted to be driven, and modifies the application by changing at least one of the plurality of blocks. The at least one of the plurality of blocks includes a parameter included in the first parameter range. Controller24drives the at least one of actuator22or heater23based on the modified application.

This allows the actuator and/or the heater to be driven based on an application defined by a plurality of blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications developed in this manner to be easily executed on apparatus20. Furthermore, before actuator22and/or heater23is/are driven based on the application, a block including a parameter in the first parameter range that is not permitted can be changed. Thus, it is possible to inhibit actuator22and/or heater23from being driven at a non-permissible parameter. Stated differently, it possible to inhibit the execution of an application that cannot control apparatus20safely, which makes it possible to improve the safety of apparatus20controlled by the application. Furthermore, when the creator of the application and the manufacturer of apparatus20are different, processes that involve application modifications can be performed, which reduces the processing load when the creator of the application and the manufacturer of apparatus20are the same.

Next, Embodiment 4 will be described. The present embodiment differs from Embodiment 1 primarily in that pre-execution check is performed using a rule corresponding to the degradation level of the apparatus. Hereinafter, the present embodiment will be described with a focus on the points of difference from Embodiment 1.

The hardware and functional configurations of system1according to the present embodiment are the same as in Embodiment 1. Accordingly, repeated illustration in the figures and explanation in the description are omitted.

In the present embodiment, the processes are the same as in Embodiment 1 except that step S216of the pre-execution check in Embodiment 1 above is replaced with step S216C. Step S216C of the pre-execution check process will therefore be described with reference toFIG.18.

FIG.18illustrates a flowchart of the pre-execution check process according to Embodiment 4.

Device300obtains device degradation information. The device degradation information indicates the degradation level of actuator22and/or heater23included in apparatus20. The method of detecting the degradation level is not limited, and can be detected using a sensor, for example.

Device300obtains a rule corresponding to the degradation level. For example, device300consults the rule database to obtain a parameter range corresponding to the degradation level of actuator22or heater23that the block drives.

FIG.19illustrates one example of a rule database according to Embodiment 4. Rules1301C through1304C are registered in rule database1300C inFIG.19. Each of rules1301C through1304C includes a parameter range that defines a non-permissible range. For example, rule1301C includes, as a non-permissible range, a range greater than 1000 rpm for motor MM0001having a degradation level of 0. For example, rule1302C includes, as a non-permissible range, a range greater than 800 rpm for motor MM0001having a degradation level of 1. Stated differently, rule1302C has a wider non-permissible range and a narrower permissible range than rule1301C.

Each of rules1301C through1304C further includes the type, the manufacturer name, actuator/heater, and the degradation level. This allows device300to obtain, from rule database1300, rules corresponding to the degradation level of actuator22or heater23that is driven by the block. For example, if motor MM0001driven by the spin block inFIG.10has a degradation level of 0, device300consults rule database1300C inFIG.19to obtain rule1301C for the spin block.

An item that determines the degradation level is, for example, the number of times actuator22and/or heater23included in device300has been used, the hours of use, or the number of days used from the start of operation to the present. These items are assumed to increase in an approximately proportional relationship to use by a user. Thus, the rule is defined so that the degradation level increases with each increase in the value corresponding to the item.

Another item that determines the degradation level is, for example, an added value of the temperature of heater23or the degree of reproducibility of the input and output of actuator22and/or heater23. The added value of the temperature of heater23is the added value of the temperature when heater23is driven. For example, the average, intermediate, or maximum temperature of heater23during execution of the block is used. The temperature of heater23may be the ratio of the execution temperature to the limit temperature of heater23, or the difference of the execution temperature to the limit temperature of heater23.

The degree of reproducibility of the input and output of actuator22and/or heater23is calculated with reference to the relationship between the input value to drive actuator22and/or heater23and the output of actuator22and/or heater23. The ratio of the actual output value for a given input to the output value specified by the relationship is used.

As described above, apparatus20according to the present embodiment includes at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24obtains an application defined by a plurality of blocks that drive the at least one of actuator22or heater23. Each of the plurality of blocks includes a parameter for driving the at least one of actuator22or heater23. Controller24obtains degradation information indicating whether the at least one of actuator22or heater23has degraded. When the degradation information indicates that the at least one of actuator22or heater23has not degraded, controller24consults a first rule that defines a first parameter range within which the at least one of actuator22or heater23is not permitted to be driven, and modifies the application by changing at least one first block included in the plurality of blocks. The at least one first block includes a parameter included in the first parameter range. When the degradation information indicates that the at least one of actuator22or heater23has degraded, controller24consults a second rule that defines a second parameter range within which the at least one of actuator22or heater23is not permitted to be driven, and modifies the application by changing at least one second block included in the plurality of blocks. The second parameter range is different from the first parameter range. The at least one second block includes a parameter included in the second parameter range. Controller24drives the at least one of actuator22or heater23based on the modified application.

This allows actuator22and/or heater23to be driven based on an application defined by a plurality of blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications developed in this manner to be easily executed on apparatus20. Furthermore, before actuator22and/or heater23is/are driven based on the application, a block including a parameter in the first parameter range that is not permitted can be changed. Thus, it is possible to inhibit actuator22and/or heater23from being driven at a non-permissible parameter. Stated differently, it possible to inhibit the execution of an application that cannot control apparatus20safely, which makes it possible to improve the safety of apparatus20controlled by the application. Furthermore, different parameter ranges dependent on the degradation information of apparatus20can be used, and the block can be used to execute drive instructions from the application side to actuator22and/or heater23while taking into account the performance of the device as it degrades over time, and apparatus20controlled by the application can therefore be made more secure.

In Embodiments 1 through 4, a block included in an application that has already been delivered is changed before the application is executed. In the present embodiment, a block included in the application is changed before the application is delivered, i.e., in the development or production stage of the application. In this respect to timing, the present embodiment differs from Embodiments 1 through 4. Hereinafter, the present embodiment will be described in detail with a focus on the points of difference from Embodiments 1 through 4. Excluding the timing of the changing of a block, the present embodiment may be the same as Embodiments 1 through 4. Elements in the present embodiment that are the same as those in Embodiments 1 through 4 are given the same reference signs as in Embodiments 1 through 4, and repeated detailed description thereof will be omitted.

FIG.20illustrates a configuration example of an information processing system used in the development of an application.

Information processing system2000includes block database41, rule database42, development tool50, a plurality of apparatuses20and a plurality of terminals30, app provision server60, and sequence manager100. For example, these components included in information processing system2000are connected via a communication network such as the internet.

Block database41, also referred to as a “block DB”, is a recording medium that stores block lists of a plurality of function blocks. These function blocks are also referred to as “blocks”, just as in Embodiments 1 through 4. Rule database42, also referred to as a “rule DB”, is a recording medium that stores a plurality of rules. Rule database42may be the same as rule database1300illustrated inFIG.12, for example. These recording media can be hard disks, random access memory (RAM), read only memory (ROM), or semiconductor memory. The recording media may be volatile or non-volatile.

Development tool50is, for example, a computer system including processor51, memory52, display53, and input unit54. Processor51executes each of the processes described below by executing instructions or a software program stored in memory52, for example, and displays text or images on display53. Display53is, for example, but not limited to, a liquid crystal display, a plasma display, or an electroluminescent (EL) display. Input unit54is configured as, for example, a keyboard, a touch sensor, a touch pad, or a mouse. Such development tool50is used, for example, by a developer of the application to generate a sequence or application including a plurality of function blocks. Note that in the present embodiment, development tool50is one example of the information processing apparatus.

App provision server60obtains and holds applications generated by development tool50, from that development tool50via a communication network. App provision server60then downloads the applications it holds to sequence manager100in accordance with an instruction from UI400included in terminal30.

FIG.21illustrates one example of the information stored in each of block database41and rule database42.

As illustrated in (a) inFIG.21, block database41stores, for each of a plurality of types of apparatuses20, a list of function blocks for driving that type of apparatus20, as the above-described block list. For example, block lists41athrough41eare stored. Block list41aincludes function blocks FB11through FB14, etc., for driving a convection microwave oven. Block list41bincludes function blocks FB21through FB24, etc., for driving a multicooker. These function blocks may be identical or similar to the blocks in Embodiments 1 through 4.

As illustrated in (b) inFIG.21, rule database42stores, for each type of apparatus20, a rule group consisting of at least one rule applicable to that type of apparatus20. For example, rule groups42athrough42eare stored. Rule group42aincludes rules R100and R11through R13, which apply to convection microwave ovens. Rule group42bincludes rules R200and R21through R23, which apply to multicookers. Rule group42dincludes rules R400and R41through R43, which apply to washing machines. These rules may be identical or similar to the rules in Embodiments 1 through 4.

Here, each of the convection microwave oven rules R11through R13is a dedicated rule that applies, for example, to a given model of convection microwave oven manufactured by a given manufacturer. Similarly, each of the multicooker rules R21through R23is a dedicated rule that applies, for example, to a given model of multicooker manufactured by a given manufacturer. Similarly, each of the washing machine rules R41through R43is a dedicated rule that applies to a given model of washing machine manufactured by a given manufacturer. More specifically, each of dedicated rules R41through R43may be, for example, rule1301or1302illustrated inFIG.12.

On the other hand, convection microwave oven rule R100is a generic rule for convection microwave ovens, applicable to each of a plurality of types of convection microwave ovens, for example. Similarly, multicooker rule R200is a generic rule for multicookers, applicable to each of a plurality of types of multicookers, for example.

FIG.22illustrates examples of a generic rule included in rule database42.

Rule group42dfor washing machines stored in rule database42includes, for example, generic rule R400shown in (a) ofFIG.22. This generic rule R400indicates a parameter range (500 rpm, +∞) applicable to each of a plurality of types of washing machines. The plurality of types of washing machines include washing machines from a plurality of manufacturers. If each manufacturer offers more than one model of washing machine, the plurality of types of washing machines include those plurality of models of washing machines. Stated differently, the parameter range, i.e., rule indicated in generic rule R400applies to any washing machine, regardless of manufacturer and model. The parameter range defines a non-permissible range, just like in Embodiments 1 through 4. For example, generic rule R400indicates a range greater than 500 rpm as a non-permissible range. Just as in Embodiments 1 through 4, the non-permissible range may be a range of parameters that allow, for example, the interior space of enclosure21, allows actuator22, or allows heater23to reach its maximum withstand temperature.

Generic rule R400for washing machines may also indicate a parameter order that applies to each washing machine from a plurality of manufacturers, as illustrated in (b) ofFIG.22. For example, generic rule R400indicates a parameter range (800 rpm, +∞) applicable to the plurality of models of washing machines provided by the manufacturer “company A”, a parameter range (600 rpm, +≅) applicable to the plurality of models of washing machines provided by the manufacturer “company B”, and so on.

FIG.23is a sequence diagram of information processing system2000.

First, development tool50installs one or more function blocks. More specifically, development tool50downloads and obtains one or more function blocks from block database41. For example, development tool50may retrieve block list41afor the convection microwave oven, or only some function blocks from block list41a. Development tool50then makes the obtained one or more function blocks available for sequence generation.

Here, each function block stored in block database41may be appended with device information corresponding to that function block. This device information indicates the manufacturer, type, model, or model number of, for example, apparatuses20driven according to the function block corresponding to that device information. Accordingly, development tool50may download one or more function blocks based on the device information. For example, development tool50may download one or more function blocks to drive each of apparatuses20provided by the same manufacturer, and may download one or more function blocks to drive each of apparatuses20used for warming food.

Next, development tool50generates the sequence. More specifically, development tool50generates a sequence using one or more downloaded function blocks in accordance with an input operation performed on input unit54by the operator. The operator may be a developer of the application defined by the sequence. In the present embodiment, in this step S12, development tool50consults a rule described above and modifies the application based on the rule.

Next, development tool50uploads the generated sequence. More specifically, development tool50generates transmission information for transmitting the generated sequence to app provision server60in accordance with an input operation performed on input unit54by the operator, based on the content of that sequence, and transmits the generated transmission information to app provision server60. The transmission information may be, for example, a JavaScript Object Notation (JSON) object. This transmits the sequence to app provision server60, where it is stored as an application on app provision server60.

Next, the user of terminal30accesses app provision server60by operating UI400of that terminal30and browses the list of applications stored in app provision server60. UI400then selects an application from the list in accordance with the user operation, and requests app provision server60to download that application.

When app provision server60receives a download request from UI400, it downloads the selected application to sequence manager100associated with that user.

FIG.24is a flowchart illustrating the overall processing operations of development tool50. More specifically, the flowchart inFIG.24illustrates the processing operations of steps S11and S12in the sequence inFIG.23in greater detail.

Development tool50first installs a plurality of function blocks to drive apparatus20, such as a washing machine.

Next, development tool50performs a process of arranging a function block in accordance with an input operation performed on input unit54by the operator. Stated differently, development tool50displays on display53the plurality of function blocks installed in step S21, and selects one function block from the displayed plurality of function blocks in accordance with an input operation performed on input unit54by the operator. Development tool50then arranges the function block in the selected block area in the sequence generation screen on display53in accordance with the input operation performed on input unit54by the operator. The sequence generation screen will be described below with reference toFIG.27. Simply stated, the operator drags and drops one of the plurality of function blocks into the selected block area.

Next, development tool50performs a process of setting a parameter of the function block arranged in step S22in accordance with an input operation performed on input unit54by the operator. Stated differently, development tool50displays, in the parameter setting area of the sequence generation screen described above, a reception image for accepting the parameter content to be used for that function block. Development tool50then accepts the parameter content in accordance with an input operation performed on input unit54by the operator, and displays the parameter content in the parameter setting area. This sets a parameter for that function block.

Next, development tool50consults a rule applicable to apparatus20, such as a washing machine, and determines whether the parameter set in step S23is outside the parameter range indicated in that rule, i.e., outside the non-permissible range.

If development tool50determines in step S24that the parameter is not outside the non-permissible range (No in step S24), it performs a parameter setting support process. In this parameter setting support process, development tool50performs an error presentation process to present an error to the operator or performs an automatic parameter correction process. In the automatic parameter correction process, development tool50changes a function block by changing the parameter in a non-permissible range to a parameter in a permissible range. In the error presentation process, development tool50, for example, displays, on display53as an error, a message indicating that the parameter set in the previous step S23is within the non-permissible range, and prompts the operator to change that parameter. Then, after the process of step S25is performed, development tool50repeats the processes from step S23.

If the processing of step S23is performed after automatic parameter correction processing is performed in step S25, in step S23, development tool50displays the parameter after it has been changed by the automatic parameter correction process in the parameter setting area. On the other hand, if the processing of step S23is performed after error presentation processing is performed in step S25, in step S23, development tool50again accepts the parameter content in accordance with an input operation performed on input unit54by the operator, as described above. This changes a parameter for that function block. In other words, this changes the function block.

If development tool50determines in step S24that the parameter is outside the non-permissible range (Yes in step S24), it further determines whether the connection of the function block arranged in step S22is permitted. For example, in step S22, a function block is arranged immediately before or immediately after an existing block, which is another function block already arranged in the selected block area. As a result, a function blocks is arranged connected to an existing block. Stated differently, the function block is arranged so that the process performed by apparatus20according to the function block and the process performed apparatus20according to the existing block are executed consecutively. In this case, development tool50determines whether the connection between that function block and that existing block is permitted by consulting a connection rule applicable to apparatus20, such as a washing machine.

If development tool50determines that the connection is not permitted in step S26(No in step S26), it performs a connection support process. In this connection support process, development tool50performs an error presentation process to present an error to the operator or perform an automatic connection correction process. Then, development tool50repeats the processes from step S22.

If the processing of step S22is performed after automatic connection correction processing is performed in step S27, in step S22, development tool50displays the two or more function blocks that have been reconnected by the automatic connection correction processing in the selected block area. On the other hand, if the processing of step S22is performed after error presentation processing is performed in step S27, in step S22, development tool50again rearranges the function blocks in accordance with an input operation performed on input unit54by the operator, as described above. If the process of step S22is repeated from step S27, development tool50may skip the processes of steps S23through S25after step S22because the parameters of the function block have already been set within the permissible range.

When development tool50determines that the connection is permitted in step S26(Yes in step S26), it further determines whether or not the generation of the sequence has completed in accordance with an input operation performed on input unit54by the operator. Here, if development tool50determines that the generation of the sequence has not completed (No in step S28), processing from step S22is repeated. At this time, development tool50selects a new block from the plurality of blocks installed in step S21in accordance with an input operation performed on input unit54by the operator, and arranges it in the selected block area described above.

When development tool50determines that the generation of the sequence has completed in step S28(Yes in step S28), it further determines whether the flow of the entire generated sequence is permitted. For example, assume the second function block is arranged before or after the first function block in the sequence, but a combination rule applicable to apparatus20, such as a washing machine, does not permit the combination of the first and second function blocks. In such a case, development tool50determines that the flow of the entire generated sequence is not permitted. Alternatively, assume a combination rule applicable to apparatus20, such as a washing machine, requires that the second function block be arranged before or after that first function block. In such a case, development tool50determines that the flow of the entire generated sequence is permitted.

If development tool50determines that the flow of the entire sequence is not permitted in step S29(No in step S29), it performs an arrangement support process. In this arrangement support process, development tool50performs an error presentation process to present an error to the operator or perform an automatic function block arrangement correction process. Then, development tool50repeats the processes from step S22.

If the processing of step S22is performed after automatic connection arrangement processing is performed in step S30, in step S22, development tool50displays the two or more function blocks that have been rearranged by the automatic arrangement correction processing in the selected block area. If the process of step S22is repeated from step S30, development tool50may skip the processes of steps S23through S25after step S22because the parameters of the function block have already been set within the permissible range. Development tool50may skip also steps S26and S27because the connection of the function block is already permitted. Development tool50may additionally skip step S28.

FIG.25is a flowchart illustrating one example of an automatic parameter correction process.

In the example illustrated inFIG.24, each time a single function block is selected and arranged, a decision is made and an automatic correction process is performed on the parameters of that function block. However, the present disclosure is not limited to this example; development tool50may perform each process according to the flowchart illustrated inFIG.25.

Development tool50selects, from among N (N is an integer greater than or equal to 2) function blocks for driving apparatus20, such as a washing machine, M (M is an integer greater than or equal to one and less than or equal to N) function blocks, in accordance with an input operation performed on input unit54by the operator. Stated differently, development tool50selects each of the M function blocks as a selected block from among the N function blocks for driving at least one of actuator22or heater23included in apparatus20, which is the device to be controlled, in accordance with an input operation performed on input unit54by the operator.

Next, development tool50generates the sequence, i.e., application by setting parameters for each of the M selected function blocks. Stated differently, development tool50generates an application including at least the M selected blocks, by setting parameters for driving actuator22or heater23in each of the M selected blocks in accordance with an input operation performed on input unit54by the operator.

Next, if each of the M function blocks is a block for driving a washing machine, development tool50refers to a rule that applies to a washing machine. For example, development tool50refers to generic rule R400if the application generated in step S42applies to a plurality of types of washing machines. If the application generated in step S42is applicable to a given model of washing machine, development tool50consults a rule associated with that model of washing machine among dedicated rules R41through R43. Stated differently, development tool50determines whether the application generated in step S42is an application dedicated to the device to be controlled or a general-purpose application applicable to the device to be controlled and devices other than the device to be controlled. Development tool50then, as the above-described rule, consults a rule candidate that corresponds to the determination result of the application, from among a plurality of rule candidates that each define a parameter range within which at least one of actuator22or heater23is not permitted to be driven.

Next, for each parameter included in the M function blocks set in step S42, development tool50determines whether the parameter is included in the non-permissible range indicated in the rule.

Here, if development tool50determines that the parameter is within the non-permissible range (Yes in step S44), it changes the function block including that parameter. Stated differently, development tool50modifies the application by changing at least one of the M selected blocks by consulting a rule that defines a parameter range within which at least one of actuator22or heater23is not permitted to be driven. Here, the at least one of the M selected blocks includes a parameter included in this parameter range.

Development tool50then outputs the modified application.

FIG.26is a flowchart illustrating one example of a parameter error presentation process.

In the example illustrated inFIG.24, each time a single function block is selected and arranged, a decision is made and an error presentation process is performed on the parameters of that function block. However, the present disclosure is not limited to this example; development tool50may perform each process according to the flowchart illustrated inFIG.26.

Development tool50performs steps S41through S44, just like in the example illustrated inFIG.25.

If development tool50determines in step S44that a parameter is within the non-permissible range (Yes in step S44), it displays an error on display53without automatically changing the function block including that parameter. This presents an error to the operator. Stated differently, in steps S43, S44, and S51, development tool50presents errors by consulting a rule. More specifically, development tool50consults a rule defining a parameter range within which at least one of actuator22or heater23is not permitted to be driven, and if at least one of the M selected blocks includes a parameter that is included in this parameter range, an error is presented to the operator.

In addition to presenting the error, development tool50may also present a plurality of solutions to the operator and prompt the operator to select a solution. In such cases, development tool50may present to the operator the differences in output performance for each of the plurality of solutions. In such cases, development tool50may also present at least two or more of the following solutions: a solution of changing the parameter, a solution of removing the selected block, and a solution including adding a block.

The operator who sees the error changes the parameter set in step S42by performing an input operation on input unit54of development tool50. When each of the plurality of solutions is presented to the operator as a choice, the operator selects any of the solutions from among those choices by performing an input operation. As a result, development tool50changes the function block. Stated differently, development tool50modifies the application by changing at least one of the M selected blocks in accordance with an input operation performed by the operator presented with the error. Then, development tool50repeats the processes from step S43.

If development tool50determines in step S44that the parameter is not within the non-permissible range (No in step S44), the application is output. At this time, if the application has been modified in step S52, the modified application is output. If, however, the application has not been modified in step S52, the application generated in step S42is output.

Here, if the process of step S51is repeated, development tool50may change how the error is presented according to the number of times step S51has been repeated. For example, if development tool50presents an error K or more times (K is an integer greater than or equal to 2), it may present a parameter not included in the above-described parameter range to the operator. Stated differently, if the number of times an error has been presented is K or more, development tool50displays on display53a parameter that is not included in the parameter range, i.e., a parameter not included in the non-permissible range, as a parameter candidate to be set in the function block. This presents the candidate to the operator, who is a developer of the application, for example. As a result, the operator, who is a developer of the application who has seen the candidate can easily change the parameter set in step S42to the candidate by performing an input operation on input unit54of development tool50.

Alternatively, if the number of times the error has been presented is K or more, development tool50may present a range of parameters to the operator that are not included in the above-described parameter range. Stated differently, if the number of times the error has been presented is K or more, development tool50displays a permissible range for the parameter on display53. With this, the operator, who is a developer of the application who has seen the permissible range can easily change the parameter set in step S42to a parameter within the permissible range by performing an input operation on input unit54of development tool50.

5.3 Display Example

FIG.27illustrates one example of a sequence generation screen.

Development tool50displays the sequence generation screen described above on display53. The sequence generation screen includes parameter setting area D1, block list area D2, target apparatus area D3, and selected block area D4.

Parameter setting area D1displays a reception image for accepting the parameter content to be used for a function block.

Block list area D2displays a block list for each of a plurality of types of apparatuses20. These block lists include function blocks that have been downloaded from block database41and installed in development tool50.

Target apparatus area D3displays the name of the type of apparatus20selected from the plurality of types of apparatuses20.

Function blocks selected from the block lists displayed in block list area D2are arranged and displayed in selected block area D4. The function blocks are displayed as icons, for example.

For example, the operator determines the name of the type of apparatus20to which the application is applicable by performing an input operation on input unit54of development tool50. Development tool50displays the determined name of the type of apparatus20in target apparatus area D3. For example, “rice cooker” is displayed as the determined name of the type of apparatus20. The operator then selects a function block for driving apparatus20corresponding to the determined type named “rice cooker” from the block list displayed in block list area D2by performing an input operation. The operator then arranges the selected function block, i.e., the selected block, in selected block area D4by performing an input operation. The selection and arrangement of this function block may be done by dragging and dropping the function block. The one or more function blocks arranged in selected block area D4may be executed in the order in which they are arranged. For example, the function blocks are executed in sequence from left to right inFIG.27. Stated differently, the application includes information on the order in which each of the M selected blocks arranged in selected block area D4is to be executed and information on the timing at which each of the M selected blocks is to be executed.

When a function block is arranged in selected block area D4, development tool50displays a reception image of the parameters to be used for that function block in parameter setting area D1.

FIG.28illustrates examples of how a block list is displayed.

The operator selects the name of the type of apparatus20to which the application to be generated is applicable from among the names of the types of apparatuses20displayed in block list area D2illustrated inFIG.27, by performing an input operation on input unit54. Development tool50displays a block list corresponding to the selected type of name of apparatus20, as shown, for example, in (a) and (b) inFIG.28. For example, as illustrated in (a) inFIG.28, when a convection microwave oven is selected, development tool50displays a block list for the convection microwave oven. For example, the block list includes function blocks that perform the respective functions of baking, microwave heating, oven, grilling, steaming, preheating, and super-heated steam. As illustrated in (b) inFIG.28, when a multicooker is selected, development tool50displays a block list for the multicooker. For example, the block list includes function blocks for preheating, keeping warm, frying, pressure cooking, cooking, steaming, stewing, mixing, and boiling, respectively.

The operator selects a function block from the block list displayed in this manner by performing an input operation on input unit54, and arranges the selected function block in selected block area D4illustrated inFIG.27. Stated differently, development tool50performs the process of step S22illustrated inFIG.24, i.e., the process of arranging the function block, in accordance with such an input operation.

FIG.29illustrates examples of how parameter setting area D1is displayed.

As illustrated in, for example, (a) and (b) inFIG.29, development tool50displays, in parameter setting area D1, a reception image for accepting the parameter content to be included in a function block for a convection microwave oven, which is apparatus20. A function block that performs an oven function and a function block that performs a microwave heating function can be applied to the convection microwave oven.

For example, the reception image for parameter setting area D1illustrated in (a) inFIG.29is an image for accepting content of a plurality of parameters included in the “oven” function block. For example, the “oven” function block includes a set temperature for the oven, a duration, steam on/off, and two-stage cooking on/off as parameters. The operator sees the reception image and inputs numerical values for the set temperature and the duration as parameter content for the set temperature and the duration, by performing input operations on input unit54. In addition, the operator inputs either on or off for the steam and either on or off for the two-stage cooking as parameter content for the steam and the two-stage cooking parameter. Development tool50sets each parameter to be used for the “oven” function block by accepting the content of each input parameter.

Similarly, the reception image for parameter setting area D1illustrated in (b) inFIG.29is an image for accepting content of a plurality of parameters included in the “microwave heating” function block. For example, the “microwave heating” function block includes a set power output and a duration as parameters. The operator sees the reception image and inputs numerical values for the set output and the duration as parameter content for the set output and the duration, by performing an input operation on input unit54. Development tool50sets each parameter to be used for the “microwave heating” function block by accepting the content of each input parameter.

In this way, development tool50performs the parameter setting process in step S23illustrated inFIG.24in accordance with an input operation performed by the operator.

When each parameter in the function block has been set in this manner, development tool50determines whether each parameter is outside the non-permissible range by consulting a rule for apparatus20corresponding to that function block, as in step S24ofFIG.24.

FIG.30Aillustrates one example of the automatic function block correction process.

For example, as illustrated in (a) inFIG.30A, the operator inputs numerical values for the set temperature and the duration in an “oven” function block by performing input operations on input unit54. In addition, the operator inputs either on or off for the steam and either on or off for the two-stage cooking by performing input operations on input unit54. This sets each parameter used for the “oven” function block.

Once each parameter is set in this manner, development tool50performs an automatic correction process for the function block. First, development tool50refers to a rule for a convection microwave oven that corresponds to that function block. For example, development tool50identifies rule group42afor convection microwave ovens in rule database42illustrated in (b) inFIG.21, and consults any one rule in rule group42a. That rule may be generic rule R100, dedicated rule R11, etc.

If development tool50determines that the input parameter, i.e., the numerical value of the set temperature, for example, 350° C., is within the parameter range indicated in the rule, i.e., that the numerical value is within the non-permissible range, development tool50will correct the numerical value of the parameter. For example, if the parameter range is above 300° C., development tool50will correct the set temperature numerical value from 350° C. to 300° C., as illustrated in (b) inFIG.30A. Here, development tool50may correct the duration parameter so as to lengthen the duration in order to lower the set temperature. These parameter corrections change the “oven” function block. Stated differently, these parameter corrections modify the application including that function block. This ensures the safety of the convection microwave oven.

Thus, in the present embodiment, development tool50consults a rule to determine whether each of the plurality of parameters in the M selected blocks is included in the parameter range, and if a parameter is determined to be included in the parameter range, the selected block including the parameter is changed. Stated differently, development tool50modifies the application by consulting a rule and changing parameters included in the parameter range to parameters included in a range in which at least one of actuator22or heater23is permitted to be driven.

FIG.30Billustrates another example of the automatic function block correction process.

In the automatic function block correction process, development tool50may add a new function block as well as correct parameters. For example, as illustrated in (a) inFIG.30B, the operator inputs numerical values for the set temperature and the duration in an “oven” function block by performing input operations on input unit54. This sets each parameter used for the “oven” function block.

Thus, in the present embodiment, development tool50may modify the application by consulting a rule and changing a parameter included in the parameter range to a parameter included in a range in which at least one of actuators22and heater23is permitted to be driven and adding a new block to the M selected blocks.

Just like in Embodiments 1 through 4 above, development tool50may remove an “oven” function block that includes the parameter when the parameter is set, as in (a) inFIG.30Aand (a) inFIG.30B. Stated differently, development tool50modifies the application by removing a selected block that includes a parameter included in the parameter range. This also ensures the safety of the convection microwave oven.

FIG.31illustrates one example of an error presentation process.

For example, as illustrated in (a) inFIG.31, the operator inputs numerical values for the set temperature and the duration in an “oven” function block by performing input operations on input unit54. This sets each parameter used for the “oven” function block.

Here, development tool50first consults a rule for a convection microwave oven that corresponds to that function block. If development tool50determines that the input numerical value of the set temperature parameter is within the parameter range indicated in the rule, it performs an error presentation process. In the example inFIG.31, the numerical value of the set temperature parameter is 350° C. Stated differently, if development tool50determines that 350° C. is included in the non-permissible range, it performs the error presentation process. More specifically, development tool50displays error message E1in parameter setting area D1, for example, as illustrated in (a) inFIG.31. Here, error message E1states that the temperature is too high. Such an error presentation process is performed, for example, in step S51inFIG.26.

If development tool50determines that the input parameter, i.e., the numerical value of the set temperature is included in the non-permissible range, development tool50may, for example, display error message E2in parameter setting area D1, as illustrated in (b) inFIG.31. Here, error message E2includes a candidate for the set temperature, for example, 300° C. Such an error presentation process may be performed in, for example, step S51inFIG.26when the error has been repeatedly presented K or more times, as described above.

If development tool50determines that the input parameter, i.e., the numerical value of the set temperature is included in the non-permissible range, development tool50may, for example, display error message E3in parameter setting area D1, as illustrated in (c) inFIG.31. Here, error message E3includes a settable range for the set temperature, for example, 100° C. to 300° C. This settable range is a permissible range for a parameter such as the set temperature. Such an error presentation process may be performed in, for example, step S51inFIG.26when the error has been repeatedly presented K or more times, as described above.

The presentation of such an error allows the operator, who is a developer of the application, to easily re-set a parameter in the non-permissible range to a parameter in the permissible range. This ensures the safety of the convection microwave oven.

In the above examples, error messages E1through E3are displayed, but how the errors are presented are not limited to these examples; the error message may be presented in any manner. For example, the error may be presented audibly.

FIG.32illustrates one example of the presentation of an error and the presentation of a plurality of solutions.

In the example in (a) inFIG.32, the set temperature is 300° C. and the numerical value of the duration parameter is 120 minutes. Development tool50consults a rule regarding the upper limit for the duration at a set temperature of 300° C., and if development tool50determines that 120 minutes is included in the non-permissible range, development tool50presents a solution for correcting the value of 120 minutes. Stated differently, development tool50presents error E1illustrated in (a) inFIG.32, and the solutions and effects illustrated in (b) and (c) inFIG.32. More specifically, for example, as illustrated in (b) inFIG.32, development tool50presents solution1, which changes the numerical value of the duration parameter from 120 minutes to 60 minutes and adds a block to stop operation of the convection microwave oven for 10 minutes and a block to compensate for the oven duration time that will no longer be implemented. Development tool50consults a rule indicating the upper limit for the set temperature at 120 minutes duration, and if development tool50determines that 300° C. is included in the non-permissible range, development tool50presents a solution to correct the value of 300° C. More specifically, for example, as illustrated in (c) inFIG.32, development tool50presents solution2, which reduces the numerical value of the set temperature parameter to 200° C.

Thus, by presenting a plurality of solutions simultaneously with the presentation of the error, it is possible to reduce the amount of time it takes the operator to change a parameter.

When presenting a plurality of solutions, development tool50may present the effect of the solution on the application. Alternatively, when presenting a plurality of solutions, development tool50may present the effect of the solution on the food heated by the oven. For example, as illustrated in (b) inFIG.32, if solution1is presented, development tool50presents effect1. As noted above, solution1is a solution that changes the numerical value of the duration parameter from 120 minutes to 60 minutes and adds a block to stop operation of the convection microwave oven for 10 minutes and a block to compensate for the oven duration time that will no longer be implemented. If such a solution1is presented, development tool50notifies the operator that the amount of heat given to the food will remain the same but the total oven time (i.e., the baking time) will increase, as effect1described above. If solution2of lowering the numerical value of the set temperature parameter to 200° C. is presented as illustrated in (c) inFIG.32, development tool50notifies the operator that the amount of heat given to the food will decrease, which may change the shape and texture of the food, as effect2described above. Development tool50may present the function block illustrated in (a) inFIG.32, i.e., may present a solution of removing the selected block including a parameter included in the non-permissible range and an effect indicating an event not implemented by the oven on the food as a result of the removal of the selected block.

Stated differently, in the present embodiment, development tool50presents a plurality of solutions for handling the error, and modifies the application by changing at least one of the M selected blocks described above in accordance with an input operation performed by the operator presented with the error and the plurality of solutions. More specifically, the plurality of solutions include at least two of the following: a solution of changing a parameter included in the parameter range, a solution of adding a new block to the M selected blocks, and a solution of removing a selected block including a parameter included in the parameter range. Development tool50further presents, for each of the plurality of solutions, the effect of the solution, when performed, on the object acted upon by the driving of actuator22or heater23, or the effect of the solution, when performed, on the application. Note that the object acted upon by the driving of actuator22or heater23is, in the example ofFIG.32, the food to be heated by heater23. Information on the error, solutions, and effects may be shown in association with the parameter range defined in the rule.

In this way, by presenting a plurality of solutions and the effects thereof on the application at the same time, the operator can intuitively select a solution in accordance with their intention of creating the application.

Note a solution of only changing a parameter or a solution of removing the selected block is likely to have no small effect on application performance, whereas a solution of a change that includes adding a block will have a relatively small effect on application performance. In this way, the effect on the application, such as the effect on application run time, is expected to vary depending on the type of solution. However, when the operator wants to minimize the effect on application performance or wants to change the application run time, it is anticipated that the operator will have various priorities that change depending on the situation.

Stated differently, in order to present solutions that are appropriate from the perspective of the operator, even in diverse situations, when presenting a plurality of solutions, it is beneficial to present at least two or more of the following: a solution of changing a parameter, a solution of removing a selected block, and a solution including adding a block. For example, as illustrated in the example inFIG.32, it is beneficial to present both of a solution of only changing a parameter and a solution of a change that includes adding a block. With this, when the operator selects a solution, the operator can select an option that satisfies their intention of creating the application.

As described above, the present embodiment can provide an environment in which a wide variety of safe applications can be developed, by using an application including blocks, and a rule database. Thus, for applications freely developed in that environment, actuator22, which physically moves, or heater23, which outputs thermal energy, can be safely driven. As a result, for example, the development of a wide variety of applications with a high degree of freedom and the development of a rule database to ensure safety can be created in parallel, enabling the early development of a wide variety of safe applications.

If the present embodiment and any one of Embodiments 1 through 4 are combined, even after the application is provided, the rule database can be modified to make the application more secure. In addition, even if a manufacturer needs to improve a situation that was not anticipated beforehand, the rule database is defined independently from the applications, so all applications can be supported by updating the rule database, without having to change a wide variety of applications themselves.

More specifically, the information processing method according to the present embodiment is an information processing method executed by a computer system such as development tool50. The information processing method includes: (a) selecting M blocks as M selected blocks from among N blocks for driving at least one of actuator22or heater23included in apparatus20, which is a device to be controlled, in accordance with an input operation performed by an operator, where N is an integer greater than or equal to two, and M is an integer greater than or equal to one and less than or equal to N; (b) generating an application including at least the M selected blocks by setting, in accordance with an input operation performed by the operator, a parameter for driving actuator22or heater23in each of the M selected blocks; (c) consulting a rule defining a parameter range within which the at least one of actuator22or heater23is not permitted to be driven, and modifying the application by changing at least one of the M selected blocks, the at least one of the M selected blocks including a parameter included in the parameter range; and (d) outputting the modified application.

This allows actuator22and/or heater23to be driven based on an application defined by M blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications to be developed not only by the manufacturer but also by third parties, and these applications can be easily executed on apparatus20. Furthermore, during development, a block including a parameter included in a non-permissible parameter range can be automatically changed. Thus, it is possible to inhibit actuator22and/or heater23from being driven at a non-permissible parameter. Stated differently, even if the operator, i.e., a developer of the application mistakenly sets a non-permissible parameter for actuator22and/or heater23, it is possible to inhibit generation of an application that cannot safely control apparatus20. Thus, the application developer can ensure and improve the safety of apparatus20controlled by the application, even if the application is created or generated with an emphasis on suitability for the user of actuator22and/or heater23.

In (c), the rule may be consulted, and the application may be modified by changing a parameter included in the parameter range to a parameter included in a range within which the at least one of actuator22or heater23is permitted to be driven.

In (c), the rule may be consulted, and the application may be modified by changing a parameter included in the parameter range to a parameter included in a range within which the at least one of actuator22or heater23is permitted to be driven, and adding a new block to the M selected blocks.

With this, since a parameter included in the non-permissible parameter range can be changed to a parameter included in the permissible range, actuator22and/or heater23can be prevented from being driven with non-permissible parameters. Furthermore, since a new block can be added, it is possible to supplement a function degraded by a parameter change with a new block.

In (c), the application may be modified by removing the at least one of the M selected blocks including a parameter included in the parameter range.

With this, since a block including a parameter included in the non-permissible parameter range can be removed, actuator22and/or heater23can be prevented from being driven with non-permissible parameters. For example, if actuator22and heater23are unable to execute the parameter set by the application developer in the first place, the removal allows the device to be controlled without confusion. On the other hand, the operator may be notified of the removal.

Step (c) may include: consulting the rule and determining, for each of a plurality of parameters included in the M selected blocks, whether the parameter is included in the parameter range; and when the parameter is determined to be included in the parameter range, changing a selected block including the parameter.

With this, a block including a parameter included in the non-permissible parameter range can be more reliably changed.

The application may include information on an order in which each of the M selected blocks is executed and information on timing of execution of each of the M selected blocks. The information on the timing for each of the selected blocks indicates, for example, the amount of time between the start of the selected block and the start or end of another selected block (for example, the selected block that is first in order).

This enables the application to include order and timing information, and to make decisions and execute them sequentially while checking the parameter ranges of each selected block.

The parameter range may be a range of parameters that allow the at least one of actuator22or heater23to reach a maximum withstand temperature.

This makes it possible to inhibit actuator22and/or heater23from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

Apparatus20, which is the device to be controlled, may include enclosure21including an interior space, and the parameter range may be a range of parameters that allow the interior space to reach a maximum withstand temperature.

This makes it possible to inhibit the interior space of enclosure21from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

Step (c) may include: determining whether the application generated is an application dedicated to the device to be controlled or a general-purpose application applicable to the device to be controlled and a device other than the device to be controlled; and consulting, as the rule, a rule candidate that corresponds to a result of the determining of the application, from among a plurality of rule candidates that each define a parameter range within which the at least one of actuator22or heater23is not permitted to be driven.

This allows for more variation in applications, such as dedicated and general-purpose applications. Furthermore, since rules appropriate for those variations are consulted, in each of those variations, the application can be modified appropriately.

The information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and may present a an error. The information processing method includes: (a) selecting M blocks as M selected blocks from among N blocks for driving at least one of actuator22or heater23included in apparatus20, which is a device to be controlled, in accordance with an input operation performed by an operator, where N is an integer greater than or equal to two, and M is an integer greater than or equal to one and less than or equal to N; (b) generating an application including at least the M selected blocks by setting, in accordance with an input operation performed by the operator, a parameter for driving actuator22or heater23in each of the M selected blocks; (c) consulting a rule defining a parameter range within which the at least one of actuator22or heater23is not permitted to be driven, and when at least one of the M selected blocks includes a parameter included in the parameter range, presenting an error to the operator; (d) modifying the application by changing the at least one of the M selected blocks in accordance with an input operation performed by the operator presented with the error; and (e) outputting the modified application.

With this, even if the operator, i.e., a developer of the application mistakenly sets a non-permissible parameter for actuator22and/or heater23, since an error is presented, it is possible to inhibit generation of an application that cannot safely control apparatus20. Stated differently, the same advantageous effect can be achieved as when the application is automatically changed as described above.

The information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and may present a plurality of solutions at the same time as presenting the error.

This reduces the time and effort required for the operator who has seen the presentation of the error to change the parameter.

The information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and may present a solution for handling the error and simultaneously present an effect that implementing the solution has on the application.

This allows the operator to intuitively select a solution in accordance with their intention of creating the application.

The information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and when presenting a solution for handling the error, may present at least two of the following solutions: a solution of changing a parameter, a solution of removing a selected block, and a solution including adding a block.

With this, when the operator selects a solution, the operator can select an option that satisfies their intention of creating the application.

In the information processing method, after (d), execution of (c) and (d) may be repeated. The information processing method may further include (f) presenting a parameter not included in the parameter range to the operator when the error has been presented K or more times, where K is an integer greater than or equal to two.

With this, when the error is presented repeatedly, a parameter not included in the parameter range can be presented to the operator as a candidate for an appropriate parameter. As a result, the operator can easily generate a safe application by easily changing the parameter included in the parameter range to a parameter not included in the parameter range.

In the information processing method, after (d), execution of (c) and (d) may be repeated. The information processing method may further include (f) presenting a range of parameters not included in the parameter range to the operator when the error has been presented K or more times, where K is an integer greater than or equal to two.

With this, when the error is presented repeatedly, a range of parameters not included in the parameter range is presented to the operator. As a result, the operator can easily generate a safe application by easily changing the parameter included in the parameter range to a parameter not included in the parameter range.

In Embodiments 1 through 4, a block (i.e., a parameter, etc.) in the application is changed. In the present embodiment, the application is modified by changing the order, combination, etc., of the blocks in the application. Stated differently, the mode of change in the present embodiment differs from the mode of change in Embodiments 1 through 4. Hereinafter, the present embodiment will be described in detail with a focus on the points of difference from Embodiments 1 through 4. Excluding the mode of change, the present embodiment may be the same as Embodiments 1 through 4. Elements in the present embodiment that are the same as those in Embodiments 1 through 4 are given the same reference signs as in Embodiments 1 through 4, and repeated detailed description thereof will be omitted.

The hardware configuration, functional configuration, and basic processing of system1according to the present embodiment are the same as the configuration and processing illustrated inFIG.1throughFIG.10in Embodiment 1.

This pre-execution check process according to the present embodiment will be described in greater detail with reference toFIG.33.FIG.33illustrates a flowchart of the pre-execution check process according to Embodiment 6. Note that the pre-execution check process is the processing of step S216illustrated inFIG.8.

Device300obtains a rule corresponding to the application. Here, the rule states that when one block among two or more given blocks is executed, at least one of the remaining blocks among the two or more given blocks is prohibited from not being executed. For example, device300consults the rule database to obtain the combination of the two or more given blocks. For example, the rule database may be included in device300, and may be included in sequence manager100or device manager200.

For example, a rule that prohibits the first block from not being executed before the second block is executed can be used. More specifically, a rule that prohibits the first block from not being executed in a period from the start of the application to before the second block is executed can be used. For example, a block for establishing an executable environment for the second block can be used as such a first block. More specifically, a drain block can be used as the first block to achieve a water-prohibited environment before the second block (for example, a spin block) is executed.

For example, a rule that prohibits a third block from not being executed after the second block is executed can also be used. More specifically, a rule that prohibits the third block from not being executed in a period from after the second block is executed to the end of the application can be used. For example, a block for restoring the environment changed by the execution of the second block to the environment before the execution of the second block can be used as such a third block. More specifically, an airflow block can be used as the third block to return the temperature increased by the execution of the second block (for example, a dry block) to the temperature before the execution of the second block.

FIG.34illustrates one example of a rule database according to Embodiment 6. Rules1301and1302are registered in rule database1300inFIG.34. Each of rules1301and1302includes information on the combination of the two or more given blocks. For example, rule1301indicates that the drain block is prohibited from not being executed before the spin block is executed. For example, rule1302indicates that the airflow block is prohibited from not being executed after the dry block.

For example, a combination of blocks for preventing the interior space of enclosure21, preventing actuator22, or preventing heater23from reaching its maximum withstand temperature is predetermined as such a combination of the two or more given blocks. A maximum withstand temperature refers to the rated temperature and indicates the maximum tolerable temperature. Therefore, if actuator22or heater23is driven with the combination of the two or more given blocks, the temperature of the interior space of enclosure21, the temperature of actuator22, or the temperature of heater23will not reach an unacceptable temperature. Stated differently, the rule ensures that two or more given blocks are executed in combination to prevent the interior space of enclosure21, prevent actuator22, or prevent heater23from reaching its maximum withstand temperature.

InFIG.34, each of rules1301and1302indicates a combination of two blocks, but the rules are not limited to this example. For example, a rule may indicate a range of parameters for at least one of the two blocks in addition to the combination of the two blocks. Furthermore, the rules are defined such that a wide range of blocks can be used for the development of a wide variety of applications.

For example, the rules by which actuator22or heater23can be safely driven may vary depending on the environment of device300, such as the interior space of enclosure21, and the rules may not depend solely on the performance of actuator22or heater23itself. Therefore, in order to ensure safe driving in any environment, the rules are heavily weighted in favor of safety, which reduces the freedom for development of a wide variety of applications. The rules may therefore be independent of the application and may be associated with information on, for example, device300. The use of such rules allows for both safety and the development of a wide variety of applications.

The rules relate to the range within which actuator22or heater23can be safely driven. The range within which actuator22or heater23can be safely driven may be a range that takes into account the start condition or the end condition of the block. Consider an example including a first block and a second block that is executed after the first block. A rule could be set for a case in which the first block is to be executed until the start condition of the second block is reached, whereby actuator22or heater23is loaded with a load that affects safety. Stated differently, the rules depend on the performance of actuator22or heater23, the start condition or the end condition of the block, etc.

Each of rules1301and1302further includes the type and the manufacturer name. This allows device300to obtain, from rule database1300, rules corresponding to actuator22or heater23that is driven by the block. For example, device300consults rule database1300inFIG.34, and obtains rules1301and1302for WM-0001.

Device300determines whether a rule applies to the plurality of blocks in the application.

For example, if the rule prohibits the first block from not being executed before the second block is executed, when the application includes the second block and does not include the first block before the second block, device300determines that the rule applies to the plurality of blocks in the application. Specifically, when the application includes the second block and does not include the first block, device300determines that the rule applies to the plurality of blocks in the application. When the application includes the second block and includes the first block only after the second block, device300determines that the rule applies to the plurality of blocks in the application. However, when the application includes the second block and includes the first block before the second block, device300determines that the rule does not apply to the plurality of blocks in the application. When the application does not include either the first or the second block, device300determines that the rule does not apply to the plurality of blocks in the application. When the application includes the first block and does not include the second block, device300determines that the rule does not apply to the plurality of blocks in the application.

For example, if the rule prohibits the third block from not being executed after the second block is executed, when the application includes the second block and does not include the third block after the second block, device300determines that the rule applies to the plurality of blocks in the application. Specifically, when the application includes the second block and does not include the third block, device300determines that the rule applies to the plurality of blocks in the application. When the application includes the second block and includes the third block only before the second block, device300determines that the rule applies to the plurality of blocks in the application. However, when the application includes the second block and includes the third block after the second block, device300determines that the rule does not apply to the plurality of blocks in the application. When the application does not include either the second or the third block, device300determines that the rule does not apply to the plurality of blocks in the application. When the application includes the third block and does not include the second block, device300determines that the rule does not apply to the plurality of blocks in the application.

If device300determines that the rule does not apply to the plurality of blocks (No in S2166), device300skips the subsequent step S2167and ends the pre-execution check process. However, if device300determines that the rule does apply to the plurality of blocks (Yes in S2166), device300proceeds to the next step S2167.

Device300modifies the application and ends the pre-execution check process. Modifying the application means (i) adding a new block to the plurality of blocks, (ii) changing an order of the plurality of blocks, (iii) removing any of the plurality of blocks, or (iv) any combination thereof. How the application is modified may be defined in a rule.

Specific examples of such modification of the application will be described with reference toFIG.35andFIG.36.

FIG.35illustrates one example of modifying the application according to Embodiment 6. InFIG.35, a drain block (the first block) is added before the spin block (the second block). This allows water to be drained from the washing machine before the spin block is executed, ensuring safe driving of actuator22during the spin operation.

FIG.36illustrates one example of modifying the application according to Embodiment 6. InFIG.36, an airflow block (the third block) is added after the dry block (the second block). This allows the temperature of the washing machine to be lowered by airflow after the temperature of the washing machine has been increased by drying, thereby inhibiting users from getting burned by the washing machine and improving the safety of the washing machine.

Although the modification of an application for a washing machine is described here, an application for other apparatuses can be modified in the same manner as well.

For example, if an application for a rice cooker includes a steam block (the second block) that utilizes the steam function and does not include a steam warming block (the first block) before the steam block, then 10 minutes before the steam block is executed, a steam warming block may be added before the corresponding block. This allows the steam heater to be warmed up before the execution of the steam block, which makes it possible to smoothly emit steam when the steam block is executed.

For example, if an application for a microwave oven includes a steam block (the second block) and does not include a steam warming block (the first block) before the steam block, then 10 minutes before the steam block is executed, a steam warming block may be added before the corresponding block. This allows the steam heater to be warmed up before the execution of the steam block, which makes it possible to smoothly emit steam when the steam block is executed. If the application for a microwave oven includes an oven block (the second block) and does not include an airflow block (the third block) after the oven block, an airflow block may be added after the oven block. This allows the inside of the oven, which has become very hot due to the execution of the oven block, to be cooled by the execution of the airflow block, thereby speeding up the execution of the next block.

After the application is changed, system1according to the present embodiment performs step S217and subsequent processes illustrated inFIG.8, just as in Embodiment 1.

As described above, the application including one or more blocks and the rule database provide an environment in which a wide variety of applications can be developed, and for applications freely developed in that environment, actuator22that physically moves or heater23that outputs thermal energy can be safely driven. Stated differently, the application including one or more blocks and the rule database can provide an environment in which applications can be freely developed, while at the same time providing functions to ensure safety independent of the application. As a result, for example, the development of a wide variety of applications with a high degree of freedom and the development of a rule database to ensure safety can be created in parallel, enabling the early development of a wide variety of applications.

Even after the application is provided, the rule database can be modified to make the application more secure. In addition, even if a manufacturer needs to improve a situation that was not anticipated beforehand, the rule database is defined independently from the applications, so all applications can be supported by updating the rule database, without having to change a wide variety of applications themselves.

One conceivable measure is to store a rule database for error handling by detecting the state of the application when it is executed, without modifying the application itself. However, this measure invariably means dealing with the error condition after it has occurred, allowing a situation where the home appliance is overloaded or a situation where safety cannot be guaranteed. It is therefore possible to include a rule database independent of the applications, and to guarantee safety by modifying the application content by consulting the rule data.

Apparatus20according to the present embodiment includes at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24: obtains an application defined by a plurality of blocks that drive at least one of actuator22or heater23; consults a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed, and modifies the application when the rule applies to the plurality of blocks included in the application; and drives at least one of actuator22or heater23based on the modified application.

This allows actuator22and/or heater23to be driven based on an application defined by a plurality of blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications to be developed not only by the manufacturer but also by third parties, and these applications can be easily executed on apparatus20. Furthermore, when a rule that specifies when one block included in two or more given blocks is executed, at least one of remaining blocks included in the two or more given blocks is prohibited from not being executed applies to the application, the application can be modified before actuator22and/or heater23is driven based on the application. Thus, it can be ensured that one of the two or more given blocks is executed in combination with at least one of the remaining of the two or more given blocks. Stated differently, if an application developer mistakenly instructs the independent execution of a block not allowed to be independently executed, it is still possible to inhibit the execution of an application that cannot safely control apparatus20. Thus, the application developer can improve the safety of apparatus20controlled by the application, even if the application is created with an emphasis on suitability for the user rather than ensuring the safety of actuator22and/or heater23.

For example, in apparatus20according to the present embodiment, controller24may modify the application by (a) adding a new block to the plurality of blocks, (b) changing the order of the plurality of blocks, or (c) removing any block included in the plurality of blocks.

More specifically, for example, in apparatus20according to the present embodiment, when the application includes information on the order in which each of the plurality of blocks is executed, the two or more given blocks include a first block and a second block, and a rule prohibits the first block from not being executed before the second block is executed, controller24may modify the application by adding the first block before the second block when the application includes the second block and does not include the first block before the second block.

For example, in apparatus20according to the present embodiment, when the application includes information on the order in which each of the plurality of blocks is executed, the two or more given blocks include a first block and a second block, and a rule prohibits the first block from not being executed before the second block is executed, controller24may modify the application by changing the order of the first block to achieve an order in which the first block comes before the second block in order when the application includes the first block and the second block and does not include the first block before the second block.

For example, in apparatus20according to the present embodiment, when the application includes information on the order in which each of the plurality of blocks is executed, the two or more given blocks include a first block and a second block, and a rule prohibits the first block from not being executed before the second block is executed, controller24may modify the application by removing the second block when the application includes the second block and does not include the first block before the second block.

With these, it is possible to ensure that the first block is executed before the second block by adding a new block, changing the order of the blocks, or removing a block before the application is executed. Accordingly, the application developer can lower the priority that takes into consideration the safe driving of actuator22and heater23to more freely develop the application. Furthermore, the developer of the software that is incorporated in apparatus20that controls actuator22and heater23can allow the execution of blocks without having to check the safety of each and every application every time.

For example, in apparatus20according to the present embodiment, when the application includes information on the order in which each of the plurality of blocks is executed, the two or more given blocks include a second block and a third block, and a rule prohibits the third block from not being executed after the second block is executed, controller24may modify the application by adding the third block after the second block when the application includes the second block and does not include the third block after the second block.

For example, in apparatus20according to the present embodiment, when the application includes information on the order in which each of the plurality of blocks is executed, the two or more given blocks include a second block and a third block, and a rule prohibits the third block from not being executed after the second block is executed, controller24may modify the application by changing the order of the third block to achieve an order in which the third block comes after the second block in order when the application includes the second block and the third block and does not include the third block after the second block.

For example, in apparatus20according to the present embodiment, when the application includes information on the order in which each of the plurality of blocks is executed, the two or more given blocks include a second block and a third block, and a rule prohibits the third block from not being executed after the second block is executed, controller24may modify the application by removing the second block when the application includes the second block and does not include the third block after the second block.

With these, it is possible to ensure that the third block is executed after the second block by adding a new block, changing the order of the blocks, or removing a block before the application is executed. Accordingly, the application developer can lower the priority that takes into consideration the safe driving of actuator22and heater23to more freely develop the application. Furthermore, the developer of the software that is incorporated in apparatus20that controls actuator22and heater23can allow the execution of blocks without having to check the safety of each and every application every time.

For example, in apparatus20according to the present embodiment, the rule may be for ensuring that two or more given blocks are executed in combination to prevent the at least one of actuator22or heater23from reaching its maximum withstand temperature.

This makes it possible to inhibit actuator22and/or heater23from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

For example, apparatus20according to the present embodiment may further include enclosure21including an interior space, and the first rule may be for ensuring that two or more given blocks are executed in combination to prevent the interior space from reaching its maximum withstand temperature.

This makes it possible to inhibit the interior space of enclosure21from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

Next, Embodiment 7 will be described. The present embodiment differs from Embodiment 6 primarily in that the pre-execution check is skipped when the application is authenticated. Hereinafter, the present embodiment will be described with a focus on the points of difference from Embodiment 6.

The hardware and functional configurations of system1according to the present embodiment are the same as in Embodiment 6. Accordingly, repeated illustration in the figures and explanation in the description are omitted.

In the present embodiment, the processes are the same as in Embodiment 6 except that step S216of the pre-execution check in Embodiment 6 is replaced with step S216A. Step S216A of the pre-execution check process will therefore be described with reference toFIG.37.

FIG.37illustrates a flowchart of the pre-execution check process according to Embodiment 7.

Device300obtains app authentication information. If the application has been authenticated, the app authentication information includes information indicating that the application has been authenticated.

Application authentication is a mechanism for guaranteeing the quality of an application, for example, by enabling confirmation of the application's security and/or identity (i.e., that it has not been tampered with). Next, one example of an application granted with authentication information will be given. If the change history of the application's code indicates that no changes were made to parameter ranges, information indicating that the application has been authenticated is associated with the application.

Device300determines whether the application is authenticated or not based on the retrieved app information. Here, if the application is determined to be authenticated (Yes in S2162A), device300skips the subsequent steps S2165to S2167and terminates the pre-execution check process. If, however, it is determined that the application is not authenticated (No in S2162A), device300proceeds to the next step S2165.

As described above, apparatus20according to the present embodiment includes: at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24obtains an application that is defined by a plurality of blocks that drive the at least one of actuator22or heater23and includes information indicating whether the application has been authenticated. When the application does not include information indicating that the application has been authenticated, controller24consults a rule indicating that two or more given blocks are to be executed in combination, and when the rule applies to the plurality of blocks included in the application, modifies the application and drives the at least one of actuator22or heater23based on the modified application.

This achieves the same advantageous effects as Embodiment 6. Furthermore, when the application is not authenticated, processes that involve application modifications can be performed, which reduces the processing load when the application is authenticated. It is therefore not necessary to perform the determination process for the combination of the blocks for all applications, and management through authentication reduces the processing load and facilitates design standards for the combination of blocks, making it easier and safer for application developers to design.

For example, in apparatus20according to the present embodiment, when the application includes information indicating that the application has been authenticated, controller24may not consult the first rule and may not modify the application.

This allows the process for changing the blocks to be skipped if the application has already been authenticated, thus reducing the processing load.

Next, Embodiment 8 will be described. The present embodiment differs from Embodiment 6 above primarily in that the pre-execution check is skipped when the creator of the application and the producer of the apparatus are the same. Hereinafter, the present embodiment will be described with a focus on the points of difference from Embodiment 6.

The hardware and functional configurations of system1according to the present embodiment are the same as in Embodiment 6. Accordingly, repeated illustration in the figures and explanation in the description are omitted.

In the present embodiment, the processes are the same as in Embodiment 6 except that step S216of the pre-execution check in Embodiment 6 above is replaced with step S216B. Step S216B of the pre-execution check process will therefore be described with reference toFIG.38.

FIG.38illustrates a flowchart of the pre-execution check process according to Embodiment 8.

Device300obtains app creator information. The app creator information indicates the creator of the application. Here, “creator” means, for example, the company, individual, or organization that created the application, and may also be referred to as “developer” or “author”.

Device300obtains device manufacturer information. The device manufacturer information indicates the producer of the device. Here, “producer” means, for example, the company, individual, or organization that produced device300(i.e., apparatus20), and may also be referred to as “manufacturer”.

Device300determines whether the creator of the application is different from the producer of device300. If the creator of the application is an individual and the producer of device300is a company, device300may determine that the creator of the application and the producer of device300are the same if the company to which the creator of the application belongs and the producer of device300match. Device300may also determine that the creator of the application and the producer of device300are the same if the creator of the application is a development contractor contracted by the producer of device300.

Here, if the creator of the application and the producer of device300are the same (No in S2164B), device300skips the subsequent steps S2165to S2167and ends the pre-execution check process. If, however, the creator of the application and the producer of device300are different (Yes in S2164B), device300proceeds to the next step S2165.

As described above, apparatus20according to the present embodiment includes at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24obtains an application that is defined by a plurality of blocks that drive the at least one of actuator22or heater23and includes information indicating a creator of the application, obtains information indicating a producer of apparatus20, and when the creator of the application and the producer of apparatus20are different, consults a rule indicating that two or more given blocks are to be executed in combination, and when the rule does not apply to a plurality of blocks included in the application, modifies the application, and drives the at least one of actuator22or heater23based on the modified application.

This achieves the same advantageous effects as Embodiment 6. Furthermore, when the creator of the application and the manufacturer of apparatus20are different, processes that involve application modifications can be performed, which reduces the processing load when the creator of the application and the manufacturer of apparatus20are the same.

Next, Embodiment 9 will be described. The present embodiment differs from Embodiment 6 primarily in that pre-execution check is performed using a rule corresponding to the degradation level of the apparatus. Hereinafter, the present embodiment will be described with a focus on the points of difference from Embodiment 6.

The hardware and functional configurations of system1according to the present embodiment are the same as in Embodiment 6. Accordingly, repeated illustration in the figures and explanation in the description are omitted.

In the present embodiment, the processes are the same as in Embodiment 6 except that step S216of the pre-execution check in Embodiment 6 above is replaced with step S216C. Step S216C of the pre-execution check process will therefore be described with reference toFIG.39.

FIG.39illustrates a flowchart of the pre-execution check process according to Embodiment 9.

Device300obtains device degradation information. The device degradation information indicates the degradation level of actuator22and/or heater23included in apparatus20. The method of detecting the degradation level is not limited, and can be detected using a sensor, for example.

Device300obtains a rule corresponding to the degradation level. For example, device300consults the rule database to obtain a rule corresponding to the degradation level of actuator22or heater23that the block drives.

An item that determines the degradation level is, for example, the number of times actuator22and/or heater23included in device300has been used, the hours of use, or the number of days used from the start of operation to the present. These items are assumed to increase in an approximately proportional relationship to use by a user. Thus, the rule is defined so that the degradation level increases with each increase in the value corresponding to the item.

Another item that determines the degradation level is, for example, an added value of the temperature of heater23or the degree of reproducibility of the input and output of actuator22and/or heater23. The added value of the temperature of heater23is the added value of the temperature when heater23is driven. For example, the average, intermediate, or maximum temperature of heater23during execution of the block is used. The temperature of heater23may be the ratio of the execution temperature to the limit temperature of heater23, or the difference of the execution temperature to the limit temperature of heater23.

The degree of reproducibility of the input and output of actuator22and/or heater23is calculated with reference to the relationship between the input value to drive actuator22and/or heater23and the output of actuator22and/or heater23. The ratio of the actual output value for a given input to the output value specified by the relationship is used.

As described above, apparatus20according to the present embodiment includes at least one of actuator22or heater23, and controller24that controls the at least one of actuator22or heater23. Controller24obtains an application defined by a plurality of blocks that drive the at least one of actuator22or heater23, obtains degradation information indicating whether the at least one of actuator22or heater23has degraded, consults a rule that corresponds to the degradation information and indicates that two or more given blocks are to be executed in combination, and when the rule applies to the plurality of blocks included in the application, modifies the application and drives the at least one of actuator22or heater23based on the modified application.

This achieves the same advantageous effects as Embodiment 6. Furthermore, a rule corresponding to the degradation information of apparatus20can be used, and the block can be used to execute drive instructions from the application side to actuator22and/or heater23while taking into account the performance of the device as it degrades over time, and apparatus20controlled by the application can therefore be made more secure.

In Embodiments 6 through 9, a block included in an application that has already been delivered is changed before the application is executed. In the present embodiment, the application is modified is before the application is delivered, i.e., in the development or production stage of the application. In this respect to timing, the present embodiment differs from Embodiments 6 through 9. Hereinafter, the present embodiment will be described in detail with a focus on the points of difference from Embodiments 6 through 9. Excluding the timing of the modification of the application, the present embodiment may be the same as Embodiments 6 through 9. Elements in the present embodiment that are the same as those in Embodiments 6 through 9 are given the same reference signs as in Embodiments 6 through 9, and repeated detailed description thereof will be omitted.

The basic configuration of the hardware, block database, and rule database of information processing system2000according to the present embodiment is the same as the basic configuration illustrated inFIG.20andFIG.21in Embodiment 5.

FIG.40illustrates examples of a generic rule included in rule database42according to the present embodiment.

Rule group42dfor washing machines stored in rule database42includes, for example, generic rule R400shown in (a) ofFIG.40. This generic rule R400is applicable to each of a plurality of types of washing machines, and is a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed. Stated differently, the rule indicates a requirement for a combination of two or more given blocks, just as in Embodiments 6 through 9. Hereafter, a combination of two or more given blocks is also referred to simply as a “combination”, and a requirement for that combination is also referred to as a “combination rule”. Generic rule R400may indicate a plurality of combination rules. For example, generic rule R400indicates a first combination rule and a second combination rule. The first combination rule is a requirement for a “drain” function block, which is the first block, and a “spin” function block, which is the second block. In other words, the first combination rule indicates that the drain block is prohibited from not being executed before the spin block is executed. The second combination rule is a requirement for a “dry” function block, which is the second block, and an “airflow” function block, which is the third block. In other words, the second combination rule indicates that the airflow block is prohibited from not being executed after the dry block.

The drain block is a function block that causes the washing machine to perform a drain operation as a function, and the spin block is a function block that causes the washing machine to perform a spin operation as a function. Similarly, the dry block is a function block that causes the washing machine to perform a drying operation as a function, and the airflow block is a function block that causes the washing machine to perform an airflow operation as a function block.

The plurality of types of washing machines to which generic rule R400applies include washing machines from a plurality of manufacturers. If each manufacturer offers more than one model of washing machine, the plurality of types of washing machines include those plurality of models of washing machines. Stated differently, the combination indicated in generic rule R400applies to any washing machine, regardless of manufacturer and model.

Generic rule R400for washing machines may also indicate a combination rule that applies to each washing machine from a plurality of manufacturers, as illustrated in (b) ofFIG.40. For example, generic rule R400indicates the combination rule applicable to the plurality of models of washing machines provided by the manufacturer “company A”, the combination rule applicable to the plurality of models of washing machines provided by the manufacturer “company B”, and so on.

Thus, just as in Embodiment 6 through 9, the rule according to the present embodiment is a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed. The two or more given blocks include a first block and a second block, and the rule prohibits the first block from not being executed before the second block is executed. In other words, the rule prohibits the first block from not being executed in a period from a start of the application to before the second block is executed. Such a first block is a block for establishing an executable environment for the second block, just as in Embodiments 6 though 9.

Alternatively, the two or more given blocks include a second block and a third block, and the rule prohibits the third block from not being executed after the second block is executed. In other words, the rule prohibits the third block from not being executed in a period from after the second block is executed to the end of the application. For example, the third block is a block for restoring the environment changed by the execution of the second block to the environment before the execution of the second block, just as in Embodiments 6 through 9.

Note that just as in Embodiments 6 through 9, the rule according to the present embodiment may be a rule for ensuring that two or more given blocks are executed in combination in order to prevent, for example, the interior space of enclosure21, prevent actuator22, or prevent heater23from reaching its maximum withstand temperature.

The sequence of information processing system200and the overall processing operation of development tool50according to the present embodiment are the same as the sequence and processing operation illustrated inFIG.23andFIG.24in Embodiment 5.

Development tool50consults a rule applicable to apparatus20, such as a washing machine, and determines whether rule applies to the sequence generated in step S28, i.e., the plurality of function blocks included in the application. If the rule applies to the plurality of function blocks, development tool50determines that the entire flow of the sequence generated in step S28is not permitted. However, if the rule does not apply to the plurality of function blocks, development tool50determines that the entire flow of the sequence generated in step S28is permitted. The rule consulted in step S29is the generic rule or dedicated rule described above that applies to apparatus20, or more specifically, the combination rule included in the rule. The method of determining whether the rule applies or not is the same as in Embodiments 6 through 9.

FIG.41is a flowchart illustrating an example of the automatic arrangement correction process in step S30inFIG.24.

Development tool50selects, from among N (N is an integer greater than or equal to 2) function blocks for driving apparatus20, such as a washing machine, M (M is an integer greater than or equal to 2 and less than or equal to N) function blocks, in accordance with an input operation performed on input unit54by the operator. Stated differently, development tool50selects each of the M function blocks as a selected block from among the N function blocks for driving at least one of actuator22or heater23included in apparatus20, which is the device to be controlled, in accordance with an input operation performed on input unit54by the operator.

Next, development tool50generates the sequence, i.e., the application by arranging the M selected function blocks in order in the selected block area described above. Stated differently, development tool50sets the order in which each of the at least M selected blocks is executed in accordance with an input operation performed on input unit54by the operator, thereby generating an application that includes at least the M selected blocks. Each of the M selected blocks in this application may include a parameter for driving at least one of actuator22or heater23.

Next, if each of the M function blocks is a block for driving a washing machine, development tool50refers to a rule that applies to a washing machine. For example, development tool50refers to generic rule R400if the application generated in step S42applies to a plurality of types of washing machines. If the application generated in step S42is applicable to a given model of washing machine, development tool50consults a rule associated with that model of washing machine among dedicated rules R41through R43. Stated differently, development tool50determines whether the application generated in step S42is an application dedicated to the device to be controlled or a general-purpose application applicable to the device to be controlled and devices other than the device to be controlled. Development tool50then, as the above-described rule, consults a rule candidate that corresponds to the determination result of the application, from among a plurality of rule candidates that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed.

Next, development tool50determines whether the above-described rule applies to the M function blocks set in step S42. Stated differently, development tool50determines whether the combination rule included in that rule applies to the M function blocks included in the application.

Here, if development tool50determines that the rule applies to the M function blocks (Yes in step S44), development tool50modifies the application. Stated differently, development tool50consults a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed, and if the rule applies to the M selected blocks included in the application, modifies the application. More specifically, development tool50modifies the application by (1) adding a new blocks to the M selected blocks, (2) changing the order of the M selected blocks, or (3) removing any of the M selected blocks. How the application is modified may be defined in a rule.

Development tool50then outputs the modified application.

FIG.42is a flowchart illustrating one example of the arrangement error presentation process in step S30ofFIG.24.

Development tool50performs steps S41through S44, just like in the example illustrated inFIG.41.

If development tool50determines that the rule applies to the M function blocks in step S44(Yes in step S44), development tool50displays an error on display53without automatically modifying the application. This presents an error to the operator. Stated differently, in steps S43, S44, and S51, development tool50presents errors by consulting a rule. More specifically, development tool50consults a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed, and if the rule applies to the M selected blocks included in the application, presents an error to the operator.

In addition to presenting the error, development tool50may also present a plurality of solutions to the operator and prompt the operator to select a solution. In such cases, development tool50may present to the operator the differences in output performance for each of the plurality of solutions. In such cases, development tool50may also present at least two or more of the following solutions: a first solution of adding a new function block, a second solution of changing the order of the M selected blocks, and a third solution of removing any function block. This presents the solutions to the operator, who is a developer of the application, for example. As a result, the operator, who is a developer of the application who has seen those solutions can easily modify the application generated in step S42, based on those solutions, by performing an input operation on input unit54of development tool50.

The operator who sees the error modifies the application generated in step S42by performing an input operation on input unit54of development tool50. When each of the plurality of solutions is presented to the operator as a choice, the operator selects any of the solutions from among those choices by performing an input operation. As a result, development tool50modifies the application. Stated differently, development tool50modifies the application in accordance with an input operation performed by the operator presented with the error. Then, development tool50repeats the processes from step S43.

If development tool50determines in step S44that the rule does not apply to the M function blocks (No in step S44), the application is output. At this time, if the application has been modified in step S52, the modified application is output. If, however, the application has not been modified in step S52, the application generated in step S42is output.

When the process of step S51is repeated, development tool50may present a solution for handling the error based on the number of times step S51has been repeated. For example, if development tool50presents an error K or more times (K is an integer greater than or equal to 2), it may present a plurality of solutions for handling the error. Stated differently, if the number of times the error has been presented is K or more, development tool50presents at least two solutions to the operator from among the first, second, and third solutions described above.

FIG.43Aillustrates one example of the process of arranging a function block and the automatic function block correction process.

Development tool50displays the function blocks dragged and dropped from the block list and arranged in selected block area D4as icons, for example, as illustrated in (a) inFIG.43A. More specifically, development tool50arranges M function blocks including the “spin” function block FB42in selected block region D4, in accordance with an input operation performed on input unit54by the operator. In this way, development tool50performs the process of arranging a function block in step S22illustrated inFIG.24in accordance with an input operation performed by the operator.

Once the application is generated as a result of the process of arranging a function block, development tool50determines whether the flow of the entire application is permitted, as in step S29inFIG.24. Stated differently, development tool50uses a rule to make a decision regarding the M function blocks arranged in selected block area D4. Development tool50then performs the automatic arrangement correction process.

More specifically, development tool50first consults a washing machine rule corresponding to the M function blocks. For example, development tool50identifies rule group42dfor washing machines in rule database42illustrated in (b) inFIG.21, and consults any one rule in that rule group42d. That rule may be generic rule R400, dedicated rule R41, etc. For example, the rule includes a combination rule that prohibits the “drain” function block FB41, which is the first block, from not being executed before the “spin” function block FB42, which is the second block, is executed.

If development tool50determines that the rule applies to the M arranged function blocks, development tool50modifies the application. For example, development tool50modifies the application for the washing machine by adding the “drain” function block FB41before function block FB42, as illustrated in (b) inFIG.43A.

Thus, in the present embodiment, when the application includes a second block and does not include a first block before the second block, development tool50modifies the application by adding a first block before the second block. This change results in the rule no longer applying to the M function blocks.

When the process of arranging a function block results in the “drain” function block FB41, which is the first block, being arranged after the “spin” function block FB42, which is the second block, development tool50may move the “drain” function block FB41up in order. Stated differently, when the application includes a first block and a second block and does not include the first block before the second block, development tool50modifies the application by changing the order of the first block to achieve an order in which the first block comes before the second block in order. This change also results in the rule no longer applying to the M function blocks.

Development tool50may remove the “spin” function block FB42, which is the second block. Stated differently, when the application includes a second block and does not include a first block before the second block, development tool50modifies the application by removing the second block. This change also results in the rule no longer applying to the M function blocks.

FIG.43Billustrates another example of the process of arranging a function block and the automatic function block correction process.

Development tool50displays the function blocks dragged and dropped from the block list and arranged in selected block area D4as icons, for example, as illustrated in (a) inFIG.43B. More specifically, development tool50arranges M function blocks including the “dry” function block FB44in selected block region D4, in accordance with an input operation performed on input unit54by the operator. In this way, development tool50performs the process of arranging a function block in step S22illustrated inFIG.24in accordance with an input operation performed by the operator.

Once the application is generated as a result of the process of arranging a function block, development tool50determines whether the flow of the entire application is permitted, as in step S29inFIG.24. Stated differently, development tool50uses a rule to make a decision regarding the M function blocks arranged in selected block area D4. Development tool50then performs the automatic arrangement correction process.

More specifically, development tool50first consults a washing machine rule corresponding to the M function blocks. For example, development tool50identifies rule group42dfor washing machines in rule database42illustrated in (b) inFIG.21, and consults any one rule in that rule group42d. That rule may be generic rule R400, dedicated rule R41, etc. For example, the rule includes a combination rule that prohibits the “airflow” function block FB45, which is the third block, from not being executed before the “dry” function block FB44, which is the second block, is executed.

If development tool50determines that the rule applies to the M arranged function blocks, development tool50modifies the application. For example, development tool50modifies the application for the washing machine by adding the “airflow” function block FB45after function block FB44, as illustrated in (b) inFIG.43B.

Thus, in the present embodiment, when the application includes a second block and does not include a third block after the second block, development tool50modifies the application by adding a third block after the second block. This change results in the rule no longer applying to the M function blocks.

When the process of arranging a function block results in the “airflow” function block FB45, which is the third block, being arranged before the “dry” function block FB44, which is the second block, development tool50may move the “airflow” function block FB45down in order. Stated differently, when the application includes a second block and a third block and does not include the third block after the second block, development tool50modifies the application by changing the order of the third block to achieve an order in which the third block comes after the second block in order. This change also results in the rule no longer applying to the M function blocks.

Development tool50may remove the “dry” function block FB44, which is the second block. Stated differently, when the application includes a second block and does not include a third block after the second block, development tool50modifies the application by removing the second block. This change also results in the rule no longer applying to the M function blocks.

As inFIG.43AandFIG.43B, in the present embodiment, the automatic arrangement correction process is performed. Therefore, if an operator, i.e., a developer of the application mistakenly arranges M function blocks in a manner that consequently corresponds to a rule, those M function blocks will be automatically rearranged so that they do not correspond to a rule. This can ensure safe operation of the washing machine.

FIG.44illustrates one example of an arrangement error presentation process.

Similar to the example inFIG.43A, development tool50arranges the M function blocks which include the “spin” function block FB42in selected block area D4, as illustrated inFIG.44. When the application is generated as a result of this arrangement, development tool50determines whether the flow of the entire application is permitted, as in step S29inFIG.24. Stated differently, development tool50uses a rule to make a decision regarding the M function blocks arranged in selected block area D4. For example, the rule includes a combination rule that prohibits the “drain” function block FB41, which is the first block, from not being executed before the “spin” function block FB42, which is the second block, is executed.

If development tool50determines that the rule applies to the M function blocks, development tool50performs an error presentation process. More specifically, development tool50displays error message E1as an error, as illustrated inFIG.44. This error message E1states that a function block that corresponds to the “spin” function block FB42has not been arranged before in order. Stated differently, this error message E1notifies that the M function blocks correspond to a rule that prohibits the “drain” function block FB41, which is the first block, from not being executed before the “spin” function block FB42, which is the second block, is executed. Such an error presentation process is performed, for example, in step S51inFIG.42.

In this way, in the present embodiment, development tool50consults a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed, and if the rule applies to the M selected blocks included in the application, presents an error to the operator. Development tool50modifies the application by changing the order in which each of the M selected blocks is executed in accordance with an input operation performed by the operator presented with the error.

By presenting such an error, the operator, who is a developer of the application, can easily rearrange the M function blocks to which the rule applies to an arrangement to which the rule does not apply. This can ensure safe operation of the washing machine.

In the error presentation process, development tool50may further display solutions C1and C2for handling the error indicated by error message E1. This solution C1states that the error can be resolved by adding a “drain” function block before the “spin” function block. Stated differently, solution C1is the first solution described above of adding a new block to the M selected blocks. Development tool50may further display the effect of implementing solution C1along with the display of solution C1. For example, development tool50may display, as an effect, that although the processing time for the entire washing process will increase, the spin operation will be performed properly.

Solution C2states that the error can be resolved by removing the “spin” function block. Stated differently, solution C2is the third solution of removing any on the M selected blocks. Development tool50may further display the effect of implementing solution C2along with the display of solution C2. For example, development tool50may display, as an effect, that although the spin operation cannot be performed, the safety of the washing machine can be ensured.

FIG.45illustrates another example of a connection error presentation process.

Similar to the example inFIG.43B, development tool50arranges the M function blocks which include the “dry” function block FB44in selected block area D4, as illustrated inFIG.45. When the application is generated as a result of this arrangement, development tool50determines whether the flow of the entire application is permitted, as in step S29inFIG.24. Stated differently, development tool50uses a rule to make a decision regarding the M function blocks arranged in selected block area D4. For example, the rule includes a combination rule that prohibits the “airflow” function block FB45, which is the third block, from not being executed before the “dry” function block FB44, which is the second block, is executed.

If development tool50determines that the rule applies to the M function blocks, development tool50performs an error presentation process. More specifically, development tool50displays error message E2as an error, as illustrated inFIG.45. This error message E2states that a function block that corresponds to the “dry” function block FB44has not been arranged after in order. Stated differently, this error message E2notifies that the M function blocks correspond to a rule that prohibits the “airflow” function block FB45, which is the third block, from not being executed after the “dry” function block FB44, which is the second block, is executed. Such an error presentation process is performed, for example, in step S51inFIG.42.

By presenting such an error, the operator, who is a developer of the application, can easily rearrange the M function blocks to which the rule applies to an arrangement to which the rule does not apply. This can ensure safe operation of the washing machine.

In the error presentation process, development tool50may further display solutions C3through C5for handling the error indicated by error message E2. This solution C3states that the error can be resolved by adding an “airflow” function block after the “dry” function block. Stated differently, solution C3is the first solution described above of adding a new block to the M selected blocks. Development tool50may further display the effect of implementing solution C3along with the display of solution C3. For example, development tool50may display, as an effect, that although the processing time for the entire washing process will increase, the safety of the washing machine can be ensured.

Solution C4states that the error can be resolved by moving the “airflow” function block arranged before the “dry” function block to a position after the “dry” function block. Stated differently, solution C4is the second solution described above of adding a new block to the M selected blocks. Development tool50may further display the effect of implementing solution C4along with the display of solution C4. For example, development tool50may display, as an effect, that the safety of the washing machine can be ensured.

Solution C5states that the error can be resolved by removing the “dry” function block. Stated differently, solution C5is the third solution of removing any on the M selected blocks. Development tool50may further display the effect of implementing solution C5along with the display of solution C5. For example, development tool50may display, as an effect, that although the drying operation cannot be performed, the safety of the washing machine can be ensured.

Thus, in the present embodiment, development tool50presents a plurality of solutions to handle errors. Development tool50modifies the application in accordance with an input operation performed by the operator presented with the error and the plurality of solutions.

For example, the plurality of solutions include at least two of the first, second, and third solutions described above. In the present embodiment, development tool50further presents, for each of the plurality of solutions, the effect of the solution, when performed, on the object acted upon by the driving of actuator22or heater23, or the effect of the solution, when performed, on the application.

By presenting such solutions and the effects of the solutions, the operator, who is a developer of the application, can more easily rearrange the M function blocks to which the rule applies to an arrangement to which the rule does not apply. This can ensure safe operation of the washing machine.

Error messages E1and E2and solutions C1through C5may be displayed in any area of the sequence generation screen. Moreover, error messages E1and E2and solutions C1through C5may be shown respectively in association with a combination rule. In the above example, error messages E1and E2and solutions C1through C5are displayed, but how they are presented is not limited to these examples; error messages E1and E2and solutions C1through C3may be presented in any manner. For example, the error or other information may be presented audibly.

If development tool50presents an error K or more times (K is an integer greater than or equal to 2), it may present a plurality of solutions to the operator for handling the error. Stated differently, if the process of step S51illustrated inFIG.42is repeated, development tool50may change how the error is presented according to the number of times step S51has been repeated. More specifically, if the number of times an error is presented is less than K times, development tool50presents the error and does not present a solution, and if the number of times the error is presented is K or more, a solution is also displayed with the error.

FIG.46illustrates another presentation example of a solution.

In the example above, the solution is presented as a message, but development tool50may present the solution in other ways, as illustrated inFIG.46. For example, development tool50presents the solution in such a way that the function block that should be added to avoid the error can be easily selected from the block list. Stated differently, if development tool50determines that the first block is not arranged before the second block indicated in the combination rule, it displays a block list, as illustrated inFIG.47. In this block list, only the function block that is the first block to be arranged before that second block is displayed in a different manner than the other function blocks in that block list. More specifically, in the block list for the washing machine, only the “drain” function block that should be added before the “spin” function block is shown brightly, while the other function blocks are shaded. This makes it easier for the operator, i.e., a developer of the application to select the “drain” function block and add it to selected block area D4, enhancing the operability of modifying the application.

FIG.47illustrates yet another presentation example of a solution.

In the example above, the solution is presented only via a message, but development tool50may present the solution using an object such as an arrow, as illustrated inFIG.47. For example, if development tool50determines that a rule applies to function blocks FB34and FB37, development tool50will present the second solution of reversing the order of those function blocks in the form of a message and arrows. This makes it easier for the operator, i.e., a developer of the application to avoid an error by reversing the order of the function blocks, enhancing the operability of modifying the application.

As described above, the present embodiment can provide an environment in which a wide variety of safe applications can be developed, by using an application including blocks, and a rule database. Thus, for applications freely developed in that environment, actuator22, which physically moves, or heater23, which outputs thermal energy, can be safely driven. As a result, for example, the development of a wide variety of applications with a high degree of freedom and the development of a rule database to ensure safety can be created in parallel, enabling the early development of a wide variety of safe applications.

If the present embodiment and any one of Embodiments 6 through 9 are combined, even after the application is provided, the rule database can be modified to make the application more secure. In addition, even if a manufacturer needs to improve a situation that was not anticipated beforehand, the rule database is defined independently from the applications, so all applications can be supported by updating the rule database, without having to change a wide variety of applications themselves.

More specifically, the information processing method according to the present embodiment is an information processing method executed by a computer system such as development tool50. The information processing method includes: (a) selecting M blocks as M selected blocks from among N blocks for driving at least one of actuator22or heater23included in apparatus20, which is a device to be controlled, in accordance with an input operation performed by an operator, where N is an integer greater than or equal to two, and M is an integer greater than or equal to one and less than or equal to N; (b) generating an application including at least the M selected blocks by setting the order in which each of the at least M selected blocks is executed in accordance with an input operation performed by an operator; (c) consulting a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed, and when the rule applies to the M selected blocks included in the application, modifying the application; and (d) outputting the modified application.

This allows actuator22and/or heater23to be driven based on an application defined by M blocks. It is therefore is possible to develop applications using blocks that abstract the control of apparatus20, allowing a wide variety of applications to be developed not only by the manufacturer but also by third parties, and these applications can be easily executed on apparatus20. Furthermore, during development, an application including M selected blocks that apply to the rule described above is automatically modified. As a result, the application can be automatically modified to an application including M selected blocks that do apply to the rule. Thus, it can be ensured that one of the two or more given blocks is executed in combination with at least one of the remaining blocks. Stated differently, if the operator, i.e., a developer of the application mistakenly generates an application in which a block that is not permitted to be executed alone is executed alone, it is possible to inhibit the generation of such an application that cannot safely control apparatus20. Thus, the application developer can ensure and improve the safety of apparatus20controlled by the application, even if the application is created or generated with an emphasis on suitability for the user of actuator22and/or heater23.

In (c), the application may be modified by (1) adding a new block to the M selected blocks, (2) changing the order of the M selected blocks, or (3) removing any block included in the M selected blocks.

More specifically, the two or more given blocks include a first block and a second block, and the rule prohibits the first block from not being executed before the second block is executed. In (c), when the application includes a second block and does not include a first block before the second block, the application may be modified by adding a first block before the second block.

In (c), when the application includes a first block and a second block and does not include the first block before the second block, the application may be modified by changing the order of the first block to achieve an order in which the first block comes before the second block in order.

In (c), when the application includes a second block and does not include a first block before the second block, the application may be modified by removing the second block.

With these, during development of the application, it is possible to ensure that the first block is executed before the second block by adding a new block, changing the order of the blocks, or removing a block. Accordingly, a developer of the application or a developer of the software that is incorporated in apparatus20that controls actuator22and heater23can ensure the safety of apparatus20without having to check the safety of each and every application every time.

More specifically, the rule may prohibit the first block from not being executed in a period from a start of the application to before the second block is executed. Furthermore, the first block may be for establishing an executable environment for the second block.

The two or more given blocks may include a second block and a third block, and the rule may prohibit the third block from not being executed after the second block is executed. In such cases, in (c), when the application includes a second block and does not include a third block before the second block, the application may be modified by adding a third block before the second block.

In (c), when the application includes a second block and a third block and does not include the third block after the second block, the application may be modified by changing the order of the third block to achieve an order in which the third block comes after the second block in order.

In (c), when the application includes a second block and does not include a third block after the second block, the application may be modified by removing the second block.

With these, during development of the application, it is possible to ensure that the third block is executed after the second block by adding a new block, changing the order of the blocks, or removing a block. Accordingly, a developer of the application or a developer of the software that is incorporated in apparatus20that controls actuator22and heater23can ensure the safety of apparatus20without having to check the safety of each and every application every time.

More specifically, the rule may prohibit the third block from not being executed in a period from after the second block is executed to the end of the application. The third block may be for restoring an environment changed by execution of the second block to an environment before the execution of the second block.

For example, the rule may be for ensuring that the two or more given blocks are executed in combination to prevent the at least one of actuator22or heater23from reaching its maximum withstand temperature.

This makes it possible to inhibit actuator22and/or heater23from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

Apparatus20, which is the device to be controlled, may include enclosure21including an interior space, and the rule may be for ensuring that the two or more given blocks are executed in combination to prevent the interior space from reaching its maximum withstand temperature.

This makes it possible to inhibit the interior space of enclosure21from reaching its maximum withstand temperature when the application is executed, which makes it possible to improve the safety of apparatus20controlled by the application.

Step (c) may include: determining whether the application generated is an application dedicated to the device to be controlled or a general-purpose application applicable to the device to be controlled and a device other than the device to be controlled; and consulting, as the rule, a rule candidate that corresponds to the result of the determining of the application, from among a plurality of rule candidates that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed.

This allows for more variation in applications, such as dedicated and general-purpose applications. Furthermore, since rules appropriate for those variations are consulted, in each of those variations, the application can be modified appropriately.

The information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and may present a an error. The information processing method includes: (a) selecting M blocks as M selected blocks from among N blocks for driving at least one of actuator22or heater23included in apparatus20, which is a device to be controlled, in accordance with an input operation performed by an operator, where N is an integer greater than or equal to two, and M is an integer greater than or equal to two and less than or equal to N; (b) generating an application including at least the M selected blocks by setting the order in which each of the at least M selected blocks is executed in accordance with an input operation performed by an operator; (c) consulting a rule that when one block included in two or more given blocks is executed, prohibits at least one of remaining blocks included in the two or more given blocks from not being executed, and when the rule applies to the M selected blocks included in the application, presenting an error to the operator; (d) modifying the application in accordance with an input operation performed by the operator presented with the error; and (e) outputs the modified application.

With this, if the operator, i.e., a developer of the application mistakenly generates an application in which a block that is not permitted to be executed alone is executed alone, since an error is presented, it is possible to inhibit the generation of such an application that cannot safely control apparatus20. Stated differently, the same advantageous effect can be achieved as when the application is automatically changed as described above.

Step (c) may further include presenting a plurality of solutions for handling the error, and in (d), the application may be modified by changing the order in which each of the M selected blocks is executed, in accordance with an input operation performed by the operator presented with the error and the plurality of solutions. Stated differently, the information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and may present a plurality of solutions at the same time as presenting the error.

This reduces the time and effort required for the operator who has seen the presentation of the error to modify the application.

The plurality of solutions may include at least two of the following: a first solution of adding a new block to the M selected blocks, a second solution of changing the order of the M selected blocks, and a third solution of removing any block included in the M selected blocks.

This allows the operator to modify the application while appropriately avoiding errors, according to any one of a plurality of solutions. In addition, when the operator selects a solution, the operator can select an option (i.e., a solution) that satisfies their intention of creating the application.

Step (c) may further include presenting, for each of the plurality of solutions, the effect of the solution, when performed, on the object acted upon by the driving of actuator22or heater23, or the effect of the solution, when performed, on the application. Stated differently, the information processing method according to the present embodiment may be an information processing method executed by a computer system such as development tool50, and may present a solution for handling the error and simultaneously present an effect that implementing the solution has on the application.

This allows the operator to intuitively select a solution in accordance with their intention of creating the application.

In the information processing method, after (d), execution of (c) and (d) may be repeated, and the plurality of solutions for handling the error may be presented to the operator when the error has been presented K or more times, where K is an integer greater than or equal to two.

With this, since a plurality of solutions are presented if an error is repeatedly presented, the operator can easily change the order in which each of the M selected blocks is executed according to the solutions, making it easier to generate a safe application.

Variations of Embodiment 10

Whether or not the hardware of apparatus20is safely operated by the application depends on the environmental conditions of that hardware. Therefore, the rules for the application should be tailored to the most severe environmental conditions. Therefore, under certain environmental conditions, the hardware may not be able to operate at its full potential.

Therefore, when the app creator and the device manufacturer are one in the same, development tool50according to the present variation carries out development and creation of applications to be used for apparatus20manufactured by the app creator, without using rules. The reason for this is that the app creator understands the environmental conditions for the safe operation of apparatus20manufactured by the app creator. Note that the app creator is a person, organization, or company that develops or creates the application, also referred to as the application developer. The device manufacturer is a person, organization, or company that makes or manufactures devices such as apparatus20, also referred to as the producer or manufacturer of apparatus20.

Stated differently, when the app creator and the device manufacturer are different, development tool50according to the present variation develops applications using rules, and when the app creator and the device manufacturer are one in the same, development tool50according to the present variation develops applications without using rules.

More specifically, in Embodiment 10, the application is modified according to a rule during the development or production phase of the application, as described above. In the present variation, when the app creator and the device manufacturer are one in the same, the modification of the application is skipped at this stage, as in Embodiment 8.

FIG.48is a flowchart illustrating the processing operations of development tool50according to the present variation.

First, development tool50generates the application by performing the process for arranging a function block and the parameter setting process. Stated differently, development tool50generates an application that includes one or more function blocks for driving at least one of the actuator or the heater included in apparatus20, which is the device to be controlled. For example, in step S51, development tool50performs step S21through23illustrated inFIG.24.

Development tool50then executes steps S2161B, S2163B, S2164B, S2165, S2166, and S2167, just as in Embodiment 8. More specifically, development tool50performs the following operations.

Development tool50identifies the creator of the application (i.e., the app creator) by obtaining app creator information.

Development tool50identifies the manufacturer of apparatus20(i.e., device manufacturer), which is the device to be controlled, by obtaining device manufacturer information.

Development tool50determines whether the app creator and the device manufacturer are different. Stated differently, development tool50determines whether the creator of the application and the manufacturer of the device to be controlled described above are the same.

If the app creator and the device manufacturer are not the same (Yes in step S2164B), development tool50obtains a rule related to one or more blocks included in the application.

Development tool50determines whether the rule applies to one or more function blocks included in the application.

If development tool50determines that the rule applies to the one or more function blocks (Yes in step S2166), development tool50modifies the application according to the rule.

If the app creator and the device manufacturer are the same (No in step S2164B), development tool50performs an appending process of appending information to the application. In the appending process, development tool50appends first append information and at least one of second append information or third append information to the application. First append information is information indicating that a rule has not been applied to the application. Second append information is information indicating when the application was generated. For example, the second append information indicates the date the application was generated. This date is hereinafter also referred to as the “app creation date”. The third append information is manufacturer identification information for identifying the manufacturer when the app creator and the device manufacturer are one in the same.

After the process of step S2167, development tool50outputs the modified application. In contrast, after the process of step S52, development tool50outputs the application after the appending process has been performed thereon. Stated differently, if the app creator and the device manufacturer are the same (No in step S2164B), development tool50outputs the application appended with the information, without applying the rule to the application.

Thus, the information processing method according to the present variation is an information processing method executed by a computer system such as development tool50. The information processing method includes: generating an application including one or more blocks for driving at least one of an actuator or a heater included in a device to be controlled; identifying a creator of the application; identifying a manufacturer of the device to be controlled; determining whether the creator of the application and the manufacturer of the device to be controlled match; and (a) when the creator of the application and the manufacturer of the device to be controlled do not match, obtaining a rule related to one or more blocks included in the application, modifying the application according to the rule, and outputting the modified application; and (b) when the creator of the application and the manufacturer of the device to be controlled do match, outputting the application without applying the rule to the application.

Accordingly, in the present variation, when the app creator and the device manufacturer are different, the application is modified by applying a rule to the application, and as such, the same advantageous effects as in Embodiment 10 can be achieved. When the app creator and the device manufacturer are the same, just as in Embodiment 8, the application of the rule and the modification of the application are omitted, so processing load can be reduced. Furthermore, in this case, since the hardware of apparatus20, which is the device to be controlled, operates according to an application to which a rule has not been applied, the functions of the hardware can be effectively utilized.

In the information processing method according to the present variation, step (b) further includes an appending process of appending, to the application, first append information and at least one of second append information or third append information. In the output of the application, the application after the appending process has been performed thereon is output. The first append information is information indicating that a rule has not been applied to the application, and the second append information is information indicating when the application was generated. The third append information is information for identifying the manufacturer when the creator of the application and the manufacturer of the device are one in the same.

Accordingly, in the present variation, if no rule is applied to the application, device300of apparatus20, which is the device to be controlled, obtains the application appended with information.

For example, if an application is appended with first append information and second append information, device300can determine whether or not to apply a rule to that application because the first append information is appended to the application. More specifically, device300can properly determine whether to apply a rule based on the second append information appended to the application. For example, device300may identify an update date of the rule and determine that the rule is not applicable to the application if the update date is before the app creation date indicated by the second append information. As a result, device300can omit applying the rule and modifying the application. Stated differently, just like development tool50, device300can also reduce the processing load.

On the other hand, if the update date is later than the app creation date, device300can determine to apply the updated rule to the application. Stated differently, if the generated application is old, it may be difficult to ensure the safety of apparatus20if apparatus20is operated by the old application. However, in such cases, the second append information will cause the rule to be applied to that old application and the application will be modified. This can ensure safe operation of apparatus20.

For example, if the first append information and the third append information are appended to an application, device300can determine whether or not to apply the rule to that application because the first append information is appended to the application. More specifically, device300can properly determine whether to apply a rule based on the third append information appended to the application. For example, device300determines whether the manufacturer of apparatus20including device300matches the manufacturer identified by the manufacturer identification information, which is the third append information. If device300determines that the manufacturers match, device300can then determine to not apply a rule to the application. As a result, device300can omit applying the rule and modifying the application. Stated differently, just like development tool50, device300can also reduce the processing load.

In contrast, if device300determines that the manufacturers do not match, device300can then determine to apply a rule to the application. For example, the generated application may be used not only for apparatus20, i.e., the device to be controlled, which is manufactured by the app creator, but also for apparatuses20manufactured by other device manufacturers. It can be difficult to ensure the safety of apparatus20manufactured by another device manufacturer when it is operated by that application. However, in such cases, the third append information will cause the rule to be applied to that application and the application will be modified. This can ensure safe operation of apparatus20manufactured by another device manufacturer.

Note that in the example above, device300applies a rule and modifies the application based on the information appended to the application. However, as in Embodiments 6 through 9, instead of device300, device manager200or the like may apply a rule based on information appended to the application and modify the application.

Other Embodiments

Hereinbefore, a system according to one or more aspects of the present disclosure has been described based on exemplary embodiments, but the present disclosure is not limited to the above exemplary embodiments. Those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within one or more aspects of the present disclosure.

In the above exemplary embodiments, sequence manager100and device manager200are described as, but not limited to, being included in cloud server10. Sequence manager100and/or device manager200may be included in apparatus20. Similarly, although UI400is described as being included in terminal30, UI400may be included in apparatus20.

In the above exemplary embodiments, the application may be modified based on the degradation information. For example, device300may consult parameter conversion information that associates a plurality of degradation levels with a plurality of parameter conversion methods, obtain the conversion method corresponding to the degradation level, and convert a parameter included in the block using the obtained conversion method. The conversion method may be defined, for example, by the value after conversion or by the coefficients applied to the value before conversion.

In Embodiments 1 through 4, a block is changed in the pre-execution check when an included parameter is in a non-permissible range, and thereafter the block is executed, but this example is non-limiting. For example, if a parameter is in the non-permissible range, when the state of device300is different than expected, the block may not be executed and device manager200and/or sequence manager100may be notified of the aborted execution (error).

In Embodiments 6 through 10, the application is described as, but not limited to, being modified in the pre-execution check and then executed. For example, when the state of device300is different than expected, the application may not be modified and device manager200and/or sequence manager100may be notified of the aborted execution (error).

INDUSTRIAL APPLICABILITY

The present disclosure can be used in home appliances or other products that can execute an application defined by a plurality of function blocks, and in apparatuses or the like that can generate the application.