Drive unit, drive method, and program

Abstract

A device (20), which is a drive device, is provided with a drive unit (W), a control unit (24) which acquires an application including a plurality of blocks and controls the drive unit (W) in accordance with the plurality of blocks by executing the application, a first sensor (25a), and a second sensor (25b), wherein: each of the plurality of blocks has a parameter and a termination condition; and if a second drive status detected by the second sensor (25b) satisfies a parameter change condition when a first drive status detected by the first sensor (25a) while a first block is being executed satisfies the termination condition of the first block, the control unit (24) changes the parameter of a second block to be executed after the first block, and controls the drive unit (W) in accordance with the second block having the changed parameter.

Description

Technical Field

[0001] The present disclosure relates to a drive device including an actuator and / or a heater, etc.

Background Art

[0002] Conventionally, drive devices for household appliances and housing equipment, etc. are controlled according to operating conditions (control programs) prepared in advance by their manufacturers, etc. Patent Document 1 discloses a washing machine as a drive device that can set the operating conditions of washing that a user wants to perform.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above prior art, a control program developed in advance by the manufacturer, etc. of the product which is a drive device must be stored in the product in advance, and it is difficult to realize diverse and safe drive devices.

[0005] Therefore, the present disclosure provides a drive device, etc. that is diverse and can improve safety.

Means for Solving the Problems

[0006] A drive device according to one aspect of the present disclosure includes a drive unit including at least one actuator and a heater; a control unit that acquires and executes an application including a plurality of blocks and controls the drive unit according to the plurality of blocks; a first sensor for detecting a first drive state of the drive unit; and a second sensor for detecting a second drive state of the drive unit, each of the plurality of blocks having parameters used for controlling the drive unit by the block and termination conditions for driving the drive unit by the block; and the control unit, during the execution of a first block among the plurality of blocks, if the first drive state detected by the first sensor satisfies the termination conditions of the first block, and the second drive state detected by the second sensor satisfies the parameter change conditions, changes the parameters of a second block among the plurality of blocks that is executed after the first block, and controls the drive unit according to the second block having the changed parameters.

[0007] These comprehensive or specific embodiments may be implemented as a system, method, integrated circuit, computer program, or recording medium such as a computer-readable CD-ROM, or as any combination of a system, method, integrated circuit, computer program, and recording medium. [Effects of the Invention]

[0008] A drive device according to one aspect of this disclosure can be diverse and offer improved safety. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a hardware configuration diagram of the system in Embodiment 1. [Figure 2A] Figure 2A is a hardware configuration diagram of the cloud server in Embodiment 1. [Figure 2B] Figure 2B is a hardware configuration diagram of the device in Embodiment 1. [Figure 2C] Figure 2C is a hardware configuration diagram of the terminal in Embodiment 1. [Figure 3] Figure 3 is a functional configuration diagram of the system in Embodiment 1. [Figure 4] Figure 4 shows an example of a block that defines the application in Embodiment 1. [Figure 5] Figure 5 shows multiple blocks for the washing machine in Embodiment 1. [Figure 6] Figure 6 shows multiple blocks for a microwave oven in Embodiment 1. [Figure 7] Figure 7 shows multiple blocks for the rice cooker in Embodiment 1. [Figure 8] Figure 8 is a sequence diagram of the system in Embodiment 1. [Figure 9] Figure 9 shows an example of a device database in Embodiment 1. [Figure 10] Figure 10 shows an example of an execution content declaration in Embodiment 1. [Figure 11] Figure 11 shows a flowchart of the pre-execution verification process in Embodiment 1. [Figure 12] Figure 12 shows an example of a rule database in Embodiment 1. [Figure 13] Figure 13 shows an example of block modification in Embodiment 1. [Figure 14] Figure 14 shows an example of block modification in Embodiment 1. [Figure 15A] Figure 15A is a sequence diagram of the system in Modification 1 of Embodiment 1. [Figure 15B] Figure 15B is a sequence diagram of the system in a modified example 2 of Embodiment 1. [Figure 15C] Figure 15C is a sequence diagram of the system in Modification 3 of Embodiment 1. [Figure 15D] Figure 15D is a sequence diagram of the system in Modification 4 of Embodiment 1. [Figure 15E] FIG. 15E is a sequence diagram of the system in Modification 5 of Embodiment 1. [Figure 16] FIG. 16 shows a flowchart of the pre-execution confirmation process in Embodiment 2. [Figure 17] FIG. 17 shows a flowchart of the pre-execution confirmation process in Embodiment 3. [Figure 18] FIG. 18 shows a flowchart of the pre-execution confirmation process in Embodiment 4. [Figure 19] FIG. 19 shows an example of a rule database in Embodiment 4. [Figure 20] FIG. 20 is a diagram showing a configuration example of the information processing system in Embodiment 5. [Figure 21] FIG. 21 is a diagram showing an example of information stored in each of the block database and the rule database in Embodiment 5. [Figure 22] FIG. 22 is a diagram showing an example of a general rule included in the rule database in Embodiment 5. [Figure 23] FIG. 23 is a sequence diagram of the information processing system in Embodiment 5. [Figure 24] FIG. 24 is a flowchart showing the overall processing operation of the development tool in Embodiment 5. [Figure 25] FIG. 25 is a flowchart showing an example of the automatic correction process of parameters in Embodiment 5. [Figure 26] FIG. 26 is a flowchart showing an example of the error prompt process of parameters in Embodiment 5. [Figure 27] FIG. 27 is a diagram showing an example of a sequence generation screen in Embodiment 5. [Figure 28] FIG. 28 is a diagram showing an example of the display of the block list in Embodiment 5. [Figure 29] FIG. 29 is a diagram showing an example of the display of the parameter setting area in Embodiment 5. [Figure 30A]Figure 30A shows an example of the automatic correction process for a functional block in Embodiment 5. [Figure 30B] Figure 30B shows another example of the automatic correction process for functional blocks in Embodiment 5. [Figure 31] Figure 31 shows an example of the error presentation process in Embodiment 5. [Figure 32] Figure 32 shows an example of error presentation and the presentation of multiple solutions. [Figure 33] Figure 33 is a block diagram showing an example of the apparatus in Embodiment 6. [Figure 34] Figure 34 is a flowchart showing an example of the processing operation of the device in Embodiment 6. [Figure 35] Figure 35 is a flowchart showing an example of the application execution process by the device in Embodiment 6. [Figure 36] Figure 36 shows an example of parameter changes in Embodiment 6. [Figure 37] Figure 37 shows another example of parameter modification in Embodiment 6. [Figure 38] Figure 38 shows yet another example of parameter changes in Embodiment 6. [Figure 39] Figure 39 shows yet another example of parameter changes in Embodiment 6. [Modes for carrying out the invention]

[0010] (Knowledge that forms the basis of this disclosure) The present inventors will now explain the circumstances leading to this disclosure. In household electrical appliances and the like that have actuators and / or heaters, open development environments are required in order to develop control programs that meet the diverse needs of users. In other words, there is a need for an environment that reduces the difficulty of developing control programs and allows third parties to easily participate in the development of control programs. In such an environment, for example, an apparel company could develop a control program for a washing machine to wash the clothes it sells.

[0011] Therefore, the inventors have investigated a mechanism that allows for the development of control programs while maintaining safety standards, using functional blocks that abstract the control of actuators and heaters included in the product, and that allows for the packaging of control programs consisting of combinations of multiple functional blocks and their distribution as applications. This enables the distribution of a wide variety of applications, making it possible to customize and update the product to meet the needs of a wider range of users. However, in such an environment, there is a possibility that dangerous applications (i.e., applications that cannot safely control the product) may be distributed, which would reduce the safety of the product.

[0012] For example, the programs included in household electrical appliances are embedded in devices that directly control actuators and / or heaters, and are expected to include a mix of programs developed by the manufacturer and programs developed by third parties. In this case, the manufacturer is unlikely to disclose all information about the household electrical appliances, including know-how, to third parties. For example, the parameters or timing for driving actuators and heaters are know-how related to the performance of the manufacturer's household electrical appliances. Therefore, because it could lead to a decline in competitiveness, the manufacturer is unlikely to open up its know-how to third parties so that they can freely operate the household electrical appliances.

[0013] Therefore, due to a lack of information on household electrical appliances, third parties may create applications that include control combinations or parameter ranges not anticipated by the manufacturer, i.e., applications whose safety cannot be guaranteed. Providing such applications to users is undesirable.

[0014] Furthermore, manufacturers of household electrical appliances and similar products may attempt to update users' lives by providing new control programs. However, developing a wide variety of new control programs requires a tremendous amount of effort, including parameter adjustment and hardware performance evaluation. Because household electrical appliances and similar products physically operate actuators and / or heaters, it is easy to predict that the effort required for program development, such as performance evaluation, will be greater compared to smartphone programs. However, in an era where on-demand development tailored to the individual lifestyles of each user is required, rather than mass production, it is necessary to develop a wide variety of control programs for household electrical appliances and similar products, just as it is for smartphone programs. Therefore, manufacturers must create a wide variety of applications that ensure product safety while reducing the enormous amount of effort required.

[0015] Furthermore, manufacturers may want to guarantee that household appliances and other devices will operate safely even when powered by applications provided by third parties. In this case, it is desirable to reduce the amount of work required to actually test the safety of various applications on household appliances and other devices. Household appliances and other devices are just one example of drive devices.

[0016] Therefore, this disclosure provides a drive device and the like that can be used in a wide variety of ways and with improved safety.

[0017] The embodiments will be described in detail below with reference to the drawings.

[0018] The embodiments described below are all general or specific examples. The numerical values, shapes, materials, components, arrangement and connection configurations of components, steps, and the order of steps shown in the following embodiments are examples only and are not intended to limit the scope of the claims.

[0019] Furthermore, the figures are not necessarily strictly accurate. In each figure, substantially identical components are denoted by the same reference numerals, and redundant explanations are omitted or simplified.

[0020] (Embodiment 1) [1.1 Hardware Configuration] The hardware configuration of System 1 in this embodiment will be described with reference to Figures 1 to 2C. Figure 1 is a hardware configuration diagram of System 1 in Embodiment 1. Figure 2A is a hardware configuration diagram of the cloud server 10 in Embodiment 1. Figure 2B is a hardware configuration diagram of the device 20 in Embodiment 1. Figure 2C is a hardware configuration diagram of the terminal 30 in Embodiment 1.

[0021] As shown in Figure 1, the system 1 in this embodiment comprises a cloud server 10, devices 20a to 20h used in facilities 2a to 2d, and terminals 30a to 30d. Facilities 2a to 2d are, for example, residences, but are not limited to these. Facilities 2a to 2d may be, for example, apartments, shops, offices, etc.

[0022] The cloud server 10 is a virtual server provided via a computer network (e.g., the Internet). The cloud server 10 is connected to devices 20a-20h and terminals 30a-30d via the computer network. A physical server may be used instead of the cloud server 10.

[0023] As shown in Figure 2A, the cloud server 10 virtually comprises a processor 11 and memory 12 connected to the processor 11. The processor 11 functions as a sequence manager and device manager, as described later, when instructions or software programs stored in memory 12 are executed.

[0024] Devices 20a to 20h are electrical machinery and equipment used in facilities 2a to 2d. Note that in Figure 1, devices 20c to 20h, used in facilities 2b to 2d, are not shown. In the following, devices 20a to 20h will be referred to as "device 20" unless otherwise specified.

[0025] The device 20 can be household electrical appliances (home appliances) and housing equipment, etc. Household electrical appliances (home appliances) and housing equipment, etc. are not limited to equipment used in a residence, but also include equipment used in a business. In this disclosure, household electrical appliances and housing equipment, etc. may be abbreviated as household electrical appliances, etc. Examples of household appliances include microwave ovens, rice cookers, blenders, electric ovens, electric toasters, electric kettles, hot plates, induction heating (IH) cookers, roasters, bakeries, electric pressure cookers, electric waterless cooking pots, multi-cookers, coffee makers, refrigerators, washing machines, dishwashers, vacuum cleaners, air conditioners, air purifiers, humidifiers, hair dryers, fans, and ion generators. Examples of housing equipment include electric shutters, electronic locks, and electric water heaters for bathtubs. The device 20 is not limited to these.

[0026] As shown in Figure 2B, the device 20 comprises a housing 21, an actuator 22, a heater 23, and a control unit 24. Note that the device 20 only needs to include at least one of the actuator 22 and the heater 23; it does not need to include both the actuator 22 and the heater 23.

[0027] The housing 21 houses the actuator 22, the heater 23, and the control unit 24. The housing 21 may also have an internal space for processing an object. For example, the washing tub of a washing machine, the heating chamber of a microwave oven, and the inner pot of a rice cooker are examples of internal spaces for processing an object.

[0028] The actuator 22 is a mechanical element that converts input energy into physical motion based on an electrical signal. Examples of actuators 22 include, but are not limited to, electric motors, hydraulic cylinders, and pneumatic actuators.

[0029] The heater 23 is an electric heater that converts electrical energy into thermal energy. The heater 23 heats the object by means of, for example, Joule heating, induction heating, and dielectric heating. For example, a nichrome wire, a coil, and a magnetron can be used as the heater 23.

[0030] Here, we will explain an example of why the apparatus 20 of this disclosure includes an actuator 22 and / or a heater 23. Consider a case where a manufacturer of household electrical appliances provides a third party with a development environment in which all parameters and drive combinations for driving the actuator 22 and the heater 23 can be freely controlled. In this case, the third party can create a program that controls the actuator 22 and / or heater 23 in a manner that deviates from the parameter range or drive limits of the actuator 22 and / or heater 23 that the manufacturer has assumed to be able to safely drive. In particular, driving the physically moving actuator 22 or the heater 23 that outputs thermal energy in a manner not assumed by the manufacturer presents a significant challenge in ensuring safety. Examples of driving in a manner not assumed by the manufacturer include high-speed rotation of an electric motor, which is an example of an actuator, and the supply of overcurrent to the heater 23. The inventors of this application aimed to avoid hindering the creation of an environment that can provide users with a wide variety of applications by excessively considering safety aspects. Therefore, the present disclosure focuses on the apparatus 20, specifically on the actuator 22 that moves physically, or the heater 23 that outputs thermal energy, with the aim of ensuring safety.

[0031] The control unit 24 is a controller that controls the actuator 22 and / or heater 23, and functions as a device described later. The control unit 24 is composed of, for example, an integrated circuit.

[0032] Terminals 30a to 30d are used in facilities 2a to 2d, respectively, and function as user interfaces. Note that in Figure 1, terminals 30b to 30d, which are used in facilities 2b to 2d, are not shown. In the following, terminals 30a to 30d will be referred to as terminal 30 when distinction between them is unnecessary.

[0033] Terminal 30 is connected to the cloud server 10 and the device 20 via a computer network and functions as a user interface (UI), as described later. A portable information terminal such as a smartphone or tablet computer can be used as Terminal 30. Terminal 30 may also be a terminal fixed to the wall, floor, or ceiling of facilities 2a to 2d. Furthermore, Terminal 30 may be included within the device 20. For example, Terminal 30 may be implemented as a display terminal having a built-in display in each of the devices 20a to 20h.

[0034] As shown in Figure 2C, the terminal 30 includes a display 31 and an input device 32. For example, a liquid crystal display and an organic EL display can be used as the display 31. For example, a touch panel, keyboard, mouse, and mechanical buttons can be used as the input device 32. Alternatively, a voice input device may be used as the input device 32. The display 31 and the input device 32 may be integrated as a touchscreen. Alternatively, a gesture input device may be used as the input device 32. A gesture input device, for example, includes a camera and a recognition unit. The camera captures an image including the gesture, and the recognition unit recognizes the gesture using the image.

[0035] [1.2 Functional Configuration] Next, the functional configuration of System 1 in this embodiment will be described with reference to Figure 3. Figure 3 is a functional configuration diagram of System 1 in Embodiment 1.

[0036] The cloud server 10 includes a sequence manager 100 and a device manager 200. Devices 20a to 20h each include devices 300a to 300h. Terminals 30a to 30d each include UIs 400a to 400d.

[0037] In the following, if it is not necessary to distinguish between devices 300a to 300h, it will be referred to as device 300. Similarly, if it is not necessary to distinguish between UI400a to 400d, it will be referred to as UI400.

[0038] The sequence manager 100 manages multiple applications. These applications are downloaded to the sequence manager 100 from the application distribution platform, for example, through user actions. Alternatively, applications included in the application distribution platform do not necessarily need to be downloaded to the sequence manager 100. In that case, information indicating that the applications included in the application distribution platform are associated with the sequence manager 100 may be recorded in the sequence manager 100's database. Details about the applications will be described later.

[0039] The device manager 200 has a database for managing multiple facilities 2a-2d and the devices 300 and UI 400 used in each of the facilities 2a-2d. The device manager 200 manages the devices 300 and UI 400 by recording device information and UI information associated with facilities 2a-2d in the database. The device information and UI information include, for example, control functions, drive functions, and operating status. For example, the device manager 200 can manage the operating status of device 300 and understand the operating schedule of device 300. The device manager 200 may also manage log information for device 300.

[0040] Note that such a database may be held by the sequence manager 100 instead of the device manager 200, or both the sequence manager 100 and the device manager 200 may hold it.

[0041] Device 300 has control and drive functions for the apparatus 20. Device 300 can drive the apparatus 20 according to instructions from the device manager 200.

[0042] UI400 provides information to the user and accepts input from the user.

[0043] Here, we will describe the application. In this embodiment, the application (hereinafter sometimes abbreviated as "app") means a control program defined by a plurality of functional blocks (hereinafter abbreviated as "blocks") that drive the actuator 22 and / or heater 23. Each of the plurality of blocks may include parameters for driving the actuator 22 or heater 23. Specifically, each of the plurality of blocks is an abstraction of the control of the actuator 22 or heater 23. In addition to the plurality of blocks that drive the actuator 22 and / or heater 23, the application may also include blocks that do not drive the actuator 22 and / or heater 23. An example of a block that does not drive the actuator 22 and / or heater 23 is an information display using the interface of device 300, an audio output using the buzzer of device 300, or turning on or off a lamp of device 300. Furthermore, the block may include conditions for starting the driving of the actuator 22 or heater 23. For example, an application including the first block and the second block will be described as an example. Here, when switching to the second block during the execution of the first block, the switch occurs when the start condition included in the second block is met. Furthermore, the block may also include a termination condition instead of a start condition. When switching to the second block during the execution of the first block, the switch occurs when the termination condition included in the first block is met.

[0044] Figure 4 shows an example of a block defining the application in Embodiment 1. Block 1000 shown in Figure 4 is a block that controls the agitation operation of the washing machine and includes parameters 1001 to 1006. Parameter 1001 includes information indicating the type of agitation (e.g., normal, dancing, swaying). Parameter 1001 can also be rephrased as indicating the type of function. Parameter 1002 includes a value indicating the rotation speed of the drum. Parameter 1002 can also be rephrased as indicating the intensity of the drive of the actuator 22 and / or heater 23. Parameter 1003 includes a value indicating the amount of water supplied into the drum as the water level after water supply. Parameter 1003 can also be rephrased as indicating the state after the actuator 22 and / or heater 23 are driven. Parameter 1004 includes a value indicating the on / off state of the circulation pump. Parameter 1004 can also be rephrased as indicating whether or not to drive the actuator 22 and / or heater 23. Parameter 1005 includes information indicating the stirring interval in stages (e.g., short, medium, long). Parameter 1006 includes a value indicating the stirring time.

[0045] Multiple such blocks are used to define an application. For example, multiple blocks like those shown in Figures 5 to 7 are used.

[0046] Figure 5 shows multiple blocks for a washing machine in Embodiment 1. Figure 6 shows multiple blocks for a microwave oven in Embodiment 1. Figure 7 shows multiple blocks for a rice cooker in Embodiment 1. Note that the multiple blocks shown in Figures 5 to 7 are illustrative, and the blocks for the washing machine, microwave oven, and rice cooker are not limited to these. For example, the multiple blocks may be hierarchically structured by levels of abstraction.

[0047] For example, you might change the level of abstraction between the manufacturer-facing hierarchy and the non-manufacturer-facing hierarchy. Examples of non-manufacturer-facing hierarchies include hierarchies for other manufacturers and hierarchies for third parties.

[0048] In this case, the hierarchy for manufacturers is less abstract than the hierarchy for non-manufacturers. A lower level of abstraction means that the control is closer to the parameters that drive the actuators and heaters.

[0049] On the other hand, manufacturers can enable non-manufacturers to develop applications by providing blocks with the minimum level of abstraction necessary to guarantee know-how and safety. Manufacturers can enable more people to develop applications by providing general users with blocks with an even higher level of abstraction. An even higher level of abstraction corresponds to blocks defined in terms that general users can understand even without specialized knowledge. Terms that can be understood without specialized knowledge correspond to the functions of household electrical appliances, for example. Specifically, if "plenty" is selected as the water volume parameter in the "wash" block for a washing machine, changes will be made in one concrete layer, such as raising the water level parameter in the water supply block from 60 mm to 100 mm and lowering the rotation speed parameter in the agitation block from 120 rpm to 100 rpm. As described above, rearranging blocks and changing parameters at a higher level of abstraction can be achieved with blocks at a lower level of abstraction. In addition, multiple blocks can be defined for devices other than washing machines, microwave ovens, and rice cookers, similar to Figures 5 to 7. These blocks allow for flexible application development through reconfiguration and parameter adjustment, while ensuring safety and confidentiality regarding the operation of actuators and heaters.

[0050] Furthermore, by providing other manufacturers with blocks that have the minimum level of abstraction necessary to guarantee know-how and safety, other manufacturers can independently define and implement blocks with an even higher level of concretization to realize the provided blocks. This allows each manufacturer to guarantee their own know-how and safety while enabling third parties who only develop the applications to freely develop applications related to the operation of each manufacturer's actuators and heaters.

[0051] At this time, other manufacturers may not develop blocks with a higher level of detail that match the minimum level of abstraction required to guarantee the know-how and safety provided by the manufacturer. Instead, they may return an error and inform the app developer and user that the blocks provided by the manufacturer are unusable or operate within a limited parameter range. Specifically, if "high speed" is selected as the motor rotation parameter in the "agitation" block for a washing machine, and the manufacturer's washing machine can achieve a parameter of 150 rpm to realize "high speed," but another manufacturer's washing machine can only rotate up to 120 rpm due to the characteristics of its motor, the app developer or user may be informed of an error or that it will operate at the limit of 120 rpm.

[0052] [1.3 Processing] Next, the processing of System 1 configured as described above will be explained with reference to Figure 8. Figure 8 is a sequence diagram of System 1 in Embodiment 1.

[0053] [1.3.1 Preparation Phase F100] First, let's explain the preparation phase F100.

[0054] (Step S110) The sequence manager 100 transmits sequence manager information to the device manager 200. This transmission of sequence manager information is performed, for example, by a command from the system administrator. The device manager 200 registers the received sequence manager information in, for example, the sequence manager database. Note that if the sequence manager information is already registered in the sequence manager database, this step may be skipped.

[0055] The sequence manager information includes, for example, the identifier and / or address of sequence manager 100 (e.g., URL (Uniform Resource Locator), IP (Internet Protocol) address, etc.). Furthermore, the sequence manager information may include any other information.

[0056] (Step S112) Device 300 sends device information 1101 to device manager 200. This transmission of device information 1101 occurs, for example, when device 300 is connected to a computer network. Device manager 200 registers the received device information 1101 in device database 1100. Note that if device information 1101 is already registered in device database 1100, this step may be skipped.

[0057] Alternatively, the device information 1101 may be sent to the UI400 and then registered with the device manager 200 via the UI400.

[0058] Device information 1101 includes the identifier and / or address of device 300. Furthermore, device information 1101 may include arbitrary information. Figure 9 shows an example of a device database in Embodiment 1. The device database 1100 in Figure 9 has multiple device information entries, including device information 1101. Each device information entry includes a device ID, address, type, manufacturer name, model number, actuator / heater, and degradation level. The actuator / heater is the identification information of the actuator 22 and / or heater 23 that constitute device 300. The degradation level is an example of degradation information indicating whether the actuator 22 and / or heater 23 that constitute device 300 are degraded or not. Here, a higher value indicates greater degradation. Device information 1101 may include information on executable blocks. Information on executable blocks may be information that associates whether the blocks included in the database are executable or not, or it may be information only on executable blocks. Furthermore, whether or not a block is executable can be determined in advance based on information such as actuators / heaters included in the device information 1101.

[0059] Furthermore, device information 1101 may include information that can identify facilities 2a to 2d.

[0060] (Step S114) UI400 transmits UI information to device manager 200. This transmission of UI information is performed, for example, by user instruction. Device manager 200 registers the received UI information in a UI database, for example. Note that this step may be skipped if the UI information is already registered in the UI database.

[0061] UI information includes, for example, the identifier and / or address of UI400. Furthermore, UI information may include any other information.

[0062] Furthermore, the UI information may include information that can identify facilities 2a to 2d.

[0063] Through the above process, the sequence manager 100, device manager 200, device 300, and UI400 can be linked to each other and establish connections. This completes the preparation phase F100.

[0064] [1.3.2 Pre-application execution phase F200] Next, we will explain the pre-application execution phase F200. Prior to the pre-application execution phase F200, the application is downloaded from the application distribution platform to the sequence manager 100 according to instructions from the user via the UI400. With the application downloaded to the sequence manager 100 in this state, the following processes are performed.

[0065] (Step S210) The UI400 receives an application execution request from the user and sends the application execution request, which includes the application's identification information, to the sequence manager 100. For example, the user selects an application from among several applications downloaded to the sequence manager 100 via the UI400 and instructs the sequence manager 100 to execute the selected application.

[0066] Furthermore, the application execution request sent from UI400 to sequence manager 100 is sent together with information that can identify facilities 2a to 2d.

[0067] Furthermore, the application execution request does not necessarily have to be explicitly received from the user. For example, the application execution request may be automatically sent to the sequence manager 100 based on the detection result after detecting the user's actions or state.

[0068] (Step S212) The sequence manager 100 sends an execution declaration for the application identified by the application execution request to the device manager 200. The execution declaration includes information on multiple blocks that define the application to be executed and information that can identify facilities 2a to 2d.

[0069] Figure 10 shows an example of an execution declaration in Embodiment 1. Figure 10 shows an execution declaration 1200 for an application defined by combining multiple blocks for a washing machine as shown in Figure 5. The execution declaration 1200 includes multiple blocks 1201, information 1202 about the devices required for the execution of each block 1201, and information 1203 about the order in which each block 1201 is executed.

[0070] Note that the execution declaration 1200 does not necessarily have to include device information 1202. In that case, the device manager 200 needs to search for a device capable of executing the block in question at the facility indicated by the received facility information, based on the information from multiple blocks 1201, and then assign the device.

[0071] In Figure 10, the device information 1202 shows the model number of device 300, but is not limited to this. The device information 1202 can be any information that can indicate the conditions for device 300 that can be assigned to a block. For example, the device information 1202 may include multiple model numbers, or it may include only the type of device, intended use, location, or any combination thereof.

[0072] (Step S214) The device manager 200 assigns a device 300 associated with the device manager 200 to each block included in the execution declaration, based on information that can identify facilities 2a to 2d. For example, the device manager 200 assigns to each of the multiple blocks 1201 shown in Figure 10 a device DEV001 with model number WM-0001, which is registered in the device database 1100 in Figure 9 as connected to the facility indicated by the received facility information. Note that if the operating status of a device 300 or its connection status to the cloud is managed, the assignment of an operating device 300 may be prohibited.

[0073] Furthermore, if, for example, the multiple blocks shown in Figure 10 are not registered as connected to the facility indicated by the received facility information, that is, if the target device does not exist at the facility, the device manager 200 notifies the sequence manager 100 that the execution of the declared application is not possible.

[0074] (Step S215) The device manager 200 notifies the device 300 of the device assignment results. As a result, multiple blocks included in the application are sent to the respective assigned devices 300.

[0075] (Step S216) Device 300 verifies the block before executing it. That is, before executing the block, device 300 checks whether any problems will occur in device 300 when the block is executed. For example, device 300 checks for safety and / or efficiency issues.

[0076] Then, device 300 modifies the block based on the verification results. This corrects the block so that the problem does not occur.

[0077] This pre-execution verification process will be explained in more detail with reference to Figure 11. Figure 11 shows a flowchart of the pre-execution verification process in Embodiment 1.

[0078] (Step S2165) Device 300 retrieves rules corresponding to a block. The rules define a range of parameters (hereinafter referred to as the "unacceptable range") in which the driving of at least one of the actuators 22 and heater 23 is not permitted. For example, device 300 refers to the rule database to retrieve the parameter range corresponding to the actuator 22 or heater 23 driven by the block. The rule database may be contained in, for example, device 300, or in the sequence manager 100 or device manager 200.

[0079] Figure 12 shows an example of a rule database in Embodiment 1. Rule database 1300 in Figure 12 contains rules 1301 and 1302. Each of rules 1301 and 1302 has a parameter range that defines an unacceptable range. For example, rule 1301 has an unacceptable range greater than 1000 rpm.

[0080] Such non-acceptable ranges include, for example, the range of parameters that cause the internal space of the housing 21, the actuator 22, or the heater 23 to reach the tolerance temperature, which is predetermined. The tolerance temperature refers to the rated temperature and indicates the maximum temperature that can be allowed. Therefore, if the actuator 22 or the heater 23 is driven using parameters within the non-acceptable range, the temperature of the internal space of the housing 21, the actuator 22, or the heater 23 will reach an unacceptable temperature.

[0081] In Figure 12, rules 1301 and 1302 each have a non-acceptable range as a parameter range, but are not limited to this. For example, each of rules 1301 and 1302 may have a parameter range that defines the range of parameters within which the actuator 22 or heater 23 can be driven (hereinafter referred to as the "acceptable range"). Even in this case, each of rules 1301 and 1302 can define the range excluding the acceptable range as the non-acceptable range. This acceptable range is defined as the range within which the actuator 22 or heater 23 can be driven safely. Furthermore, the acceptable range is defined to allow for the use of a wide range of parameters for the development of a wide variety of applications.

[0082] For example, the parameters required for safe operation of the actuator 22 or heater 23 may vary depending on the environment of the device 300, such as the internal space of the housing 21, and the tolerance range may not depend solely on the performance of the actuator 22 or heater 23 itself. Therefore, in order to operate safely in any environment, the tolerance range will have a high weight given to safety considerations, reducing the scope for developing a wide variety of applications. For this reason, the rules may be associated with information such as the device 300, independently of the application. By using such rules, it is possible to achieve both safety and the development of a wide variety of applications.

[0083] The rule relates to the range in which the actuator 22 or heater 23 can be safely operated. The range in which it can be safely operated may be a range that takes into account the block's start or end conditions. Consider a first block and a second block executed after the first block as an example. A rule (tolerance range) may be set assuming that executing the first block until the start conditions of the second block are reached places a load that affects the safety of the actuator 22 or heater 23. In other words, the tolerance range depends on the performance of the actuator 22 or heater 23, the block's start or end conditions, etc.

[0084] For example, the acceptable or unacceptable range may be defined by a combination of multiple parameters. Specifically, the acceptable or unacceptable range may be a range of output values ​​of a function of multiple parameters. For example, if device 300 is a washing machine, the acceptable or unacceptable range may be a range of output values ​​of a function of a first parameter indicating the water level and a second parameter indicating the motor speed. The function can be predetermined empirically and / or experimentally. Alternatively, the acceptable or unacceptable range may be defined by a set of multiple combinations of the values ​​of multiple parameters instead of a function.

[0085] Each of rules 1301 and 1302 further includes a type, a manufacturer's name, and an actuator / heater. This allows device 300 to retrieve rules from the rule database 1300 corresponding to actuators 22 or heaters 23 driven by the block. For example, device 300 refers to the rule database 1300 in Figure 12 and retrieves rule 1301 for the dewatering block in Figure 10.

[0086] (Step S2166) Device 300 determines whether the parameter included in the block falls within an unacceptable range. If it is determined that the parameter does not fall within an unacceptable range (No in S2166), device 300 skips the subsequent step S2167 and terminates the pre-execution verification process. On the other hand, if it is determined that the parameter falls within an unacceptable range (Yes in S2166), device 300 proceeds to the next step S2167.

[0087] (Step S2167) Device 300 modifies a block and terminates the pre-execution verification process. Modifying a block means correcting the contents of the block, deleting the block, adding new blocks before or after the block, or any combination thereof.

[0088] For example, device 300 can be modified by changing the block's parameters to those that fall within the acceptable range. A specific example of such block modification will be explained with reference to Figure 13.

[0089] Figure 13 shows an example of block modification in Embodiment 1. In Figure 13, the rotation speed parameter in the dewatering block falls within the non-acceptable range, so it is changed to a parameter that falls within the acceptable range (1200 rpm → 1000 rpm).

[0090] Furthermore, for example, device 300 can also modify a block by changing its parameters to those within an acceptable range and adding a new block. A specific example of such block modification will be explained with reference to Figure 14.

[0091] Figure 14 shows an example of block modification in Embodiment 1. In Figure 14, the time parameter in the dewatering block falls within the non-acceptable range, so it is changed to a parameter that falls within the acceptable range (600s → 300s), and a stop block and another dewatering block are added after the dewatering block. For example, by modifying a block that places an unintended load on device 300 due to the washing tub being rotated at high speed for a long time during the dewatering process, the load can be reduced, a stop block can be added, and the dewatering block can be performed again, thereby providing an application that can safely execute the functions defined in the application before the modification.

[0092] For example, device 300 can also modify a block by deleting it.

[0093] While this explanation focused on modifying blocks for washing machines, the same method can be used to modify blocks for other devices.

[0094] For example, in a microwave oven, if a temperature parameter falls within an unacceptable range, it may be changed to a temperature parameter that falls within an acceptable range. Similarly, if an execution time parameter falls within an unacceptable range, it may be changed to an execution time parameter that falls within an acceptable range, and a new block may be added.

[0095] Furthermore, in the case of a rice cooker, if the bottom temperature parameter of the pot falls within the unacceptable range, it may be changed to a bottom temperature parameter that falls within the acceptable range. Also, if the duration parameter falls within the unacceptable range, it may be changed to a duration parameter that falls within the acceptable range, and a new block may be added.

[0096] (Step S217) Device 300 sends the results of the pre-execution check to Device Manager 200. If a block has been modified, the modified block may also be sent to Device Manager 200.

[0097] (Step S218) The device manager 200 returns the device assignment results to the sequence manager 100. Additionally, if blocks have been modified during pre-execution verification, the application containing the modified blocks may be sent to the sequence manager 100.

[0098] (Step S220) The sequence manager 100 receives the assignment result notification from the device manager 200 and notifies the user via the UI 400 that it is ready to run.

[0099] (Step S222) UI400 displays a list of devices on which the application will run, and also displays a graphical user interface (GUI) for receiving user input to confirm application execution. UI400 may also accept user requests to change device assignments. Furthermore, UI400 does not necessarily need to display a list of devices.

[0100] (Step S224) UI400 receives confirmation input from the user and sends an application start command to device manager 200. Device manager 200 forwards the application start command to sequence manager 100.

[0101] Steps S220, S222, and S224 provide the user with additional information before the application is executed, but they may be omitted as they could increase the user's workload.

[0102] This completes the pre-application execution phase F200.

[0103] [1.3.3 Application Execution Phase F300] Next, we will explain the application execution phase F300.

[0104] (Step S310) Upon receiving an application start command, the sequence manager 100 selects the first block (the first block) from among the multiple blocks included in the application. Then, the sequence manager 100 sends an execution command for the selected first block to the device manager 200.

[0105] Furthermore, if multiple blocks are to be operated sequentially, the sequence manager 100 may send the execution instructions for multiple blocks together to the device manager 200.

[0106] Based on the execution instructions for the first block received from the sequence manager 100, the device manager 200 sends the execution instructions for the first block to the device 300 assigned to the first block.

[0107] (Step S312) Upon receiving the execution instruction for the first block, Device Manager 200 updates the schedule (scheduled usage time) for each device.

[0108] (Step S314) Device 300 receives an instruction to execute the first block and executes the first block.

[0109] (Step S316) Device 300 sends a completion notification to device manager 200 when the execution of the first block is complete. If an error occurs during the execution of the first block, device 300 may also send error information to device manager 200. In addition, device 300 may send event information to device manager 200 during the execution of the first block. Event information may include, but is not limited to, sensor output values ​​or equipment operations. Device manager 200 forwards the completion notification and / or various information received from device 300 to sequence manager 100.

[0110] (Step S318) The sequence manager 100 receives a notification that the first block is complete, updates the application's progress, and selects the next block (the second block). The sequence manager 100 also executes a corresponding process (e.g., return to the previous block, return to the first block, wait, etc.) if it receives error information. Information regarding the error response process may be stored in the sequence manager 100 beforehand, or it may be received from the user via the UI 400. Furthermore, the sequence manager 100 executes a corresponding process if it receives event information. For example, if the event information includes the output value of the water level sensor, the sequence manager 100 updates the water level parameter to display the water level included in the currently executing block.

[0111] (Step S320) The sequence manager 100 sends an execution instruction for the selected second block to the device manager 200.

[0112] The execution instruction in the second block may be for the same device as the execution instruction in the first block (S310), or it may be for a different device.

[0113] Note that, similar to the execution instructions for the first block, the execution instructions for the second block may be sent to the device manager 200 as a bundle of execution instructions for multiple blocks.

[0114] The subsequent processing is the same as the processing for the first block (S312-S318), so the illustrations and explanations are omitted. The blocks included in the application are executed in order, and when the execution of the last block is completed, the application execution phase F300 ends.

[0115] Note that, while block execution is instructed one by one in this example, it is not limited to this. For example, the execution of multiple blocks assigned to the same device may be instructed together. In that case, it may be necessary to check in advance whether each block meets the parameter range for function execution, or to download the corresponding block to the device before execution. Alternatively, for example, block execution instructions may be issued to multiple devices individually.

[0116] [1.4 Effects, etc.] As described above, the application, including blocks, and the rule database provide an environment in which a wide variety of applications can be developed, and in that environment, it is possible to safely drive the physically moving actuator 22 or the heater 23 that outputs thermal energy for the application that has been freely developed. In other words, it provides an environment in which applications can be freely developed, and also provides functions to ensure safety independently of the application. As a result, for example, it becomes possible to create a wide variety of applications with a high degree of freedom and to develop a rule database to ensure safety in parallel, making it possible to develop a wide variety of applications at an early stage.

[0117] Furthermore, even after the application has been released, it is possible to modify the rule database to create an application with enhanced security. Also, even if improvements are needed in situations that the manufacturer did not anticipate, the rule database is defined independently of the application itself. By updating the rule database, it becomes possible to address all applications without changing the diverse range of applications themselves.

[0118] One possible approach is to maintain an error handling rule database by detecting the state of the application when it is executed, without modifying the application itself. However, this approach would always deal with errors after they occur, meaning it would be acceptable to allow situations that put a load on the appliance or where safety cannot be guaranteed. Therefore, by maintaining a rule database independently of the application and modifying the application's content by referring to the rule data, safety can be ensured.

[0119] The apparatus 20 in this embodiment comprises at least one actuator 22 and a heater 23, and a control unit 24 that controls at least one of the actuator 22 and the heater 23, the control unit 24 taking an application defined by a plurality of blocks that drive at least one of the actuator 22 and the heater 23, each of the plurality of blocks having parameters for driving the actuator 22 or the heater 23, and modifying the application by modifying at least one of the plurality of blocks with reference to a first rule that defines a first parameter range in which driving at least one of the actuator 22 and the heater 23 is not permitted, and at least one of the plurality of blocks having parameters included in the first parameter range and driving at least one of the actuator 22 and the heater 23 based on the modified application.

[0120] According to this, the actuator 22 and / or heater 23 can be driven based on an application defined by multiple blocks. Therefore, it becomes possible to develop applications using blocks that abstract the control of the device 20, allowing not only the manufacturer but also third parties to develop a wide variety of applications, and these applications can be easily executed on the device 20. Furthermore, before the actuator 22 and / or heater 23 are driven based on the application, it is possible to modify blocks that have parameters included in an unacceptable first parameter range. Therefore, it is possible to prevent the actuator 22 and / or heater 23 from being driven with unacceptable parameters. In other words, even if an application developer mistakenly instructs the actuator 22 and / or heater 23 to be driven with unacceptable parameters, it is possible to prevent the execution of an application that cannot safely control the device 20. Therefore, even if an application developer creates an application that prioritizes user-friendliness over ensuring the safety of the actuator 22 and / or heater 23, the safety of the device 20 controlled by the application can be improved.

[0121] For example, in the apparatus 20 of this embodiment, the control unit 24 may change the application by referring to the first rule and changing the parameters included in the first parameter range to parameters included in the range in which the driving of at least one of the actuator 22 and heater 23 is permitted.

[0122] According to this, parameters included in the unacceptable first parameter range can be changed to parameters included in the acceptable range. For example, application developers can freely develop applications with a lower priority given to considering the safe operation of the actuator 22 and heater 23. Furthermore, developers of software incorporated into the device 20 that controls the actuator 22 and heater 23 can execute blocks without checking the safety of each application every time, and prevent the actuator 22 and / or heater 23 from being driven with unacceptable parameters.

[0123] For example, in the apparatus 20 of this embodiment, the control unit 24 may change the application by referring to the first rule to change the parameters included in the first parameter range to parameters included in the range in which the driving of at least one of the actuator 22 and heater 23 is permitted, and by adding new blocks to multiple blocks.

[0124] According to this, parameters that fall within the unacceptable first parameter range can be changed to parameters that fall within the acceptable range, thereby preventing the actuator 22 and / or heater 23 from being driven with unacceptable parameters. Furthermore, new blocks can be added, making it possible to compensate for the reduced functionality caused by the parameter changes with these new blocks.

[0125] For example, in the apparatus 20 of this embodiment, the control unit 24 may modify the application by deleting blocks that have parameters included in the first parameter range.

[0126] According to this, blocks containing parameters that fall within an unacceptable first parameter range can be deleted, thereby preventing the actuator 22 and / or heater 23 from being driven by unacceptable parameters. For example, if the actuator 22 and heater 23 are incapable of executing the parameters specified by the application developer, deleting them allows the devices to be controlled without confusion. Alternatively, the user may be notified that the blocks have been deleted.

[0127] For example, in the apparatus 20 of this embodiment, the control unit 24 may refer to the first rule to determine whether each of the multiple parameters included in the multiple blocks is included in the first parameter range, and if it is determined that the parameter is included in the first parameter range, it may change the block having that parameter.

[0128] This allows for a more reliable modification of blocks that have parameters falling within an unacceptable first parameter range.

[0129] For example, in the device 20 of this embodiment, the application may include information about the order in which each of the multiple blocks is executed, and information about the timing of the execution of each of the multiple blocks. The timing information for each block indicates, for example, the time between the start timing of that block and the start or end timing of another block (for example, the first block).

[0130] According to this, the application can include information on order and timing, and can be executed sequentially while checking the parameter range of each block.

[0131] For example, in the device 20 of this embodiment, if the application includes information on multiple blocks and the order in which each block is executed, and the rule includes information that at least one block among the multiple blocks cannot be executed, the developer may be presented with error information indicating that the application cannot be developed or information on the block that cannot be executed.

[0132] According to this, it is possible to ensure that the third block is executed after the second block by adding a new block, changing the order of blocks, or deleting blocks before the application is executed. Therefore, application developers can freely develop applications with a lower priority on considering the safe operation of the actuator 22 and heater 23. Furthermore, developers of the software incorporated into the device 20 that controls the actuator 22 and heater 23 can permit the execution of blocks without having to check the safety of each application every time.

[0133] For example, in the apparatus 20 of this embodiment, the first parameter range may be the range of parameters that cause at least one of the actuator 22 and the heater 23 to reach its durability temperature.

[0134] According to this, it is possible to prevent the actuator 22 and / or heater 23 from reaching their tolerable temperature when the application is executed, thereby improving the safety of the device 20 controlled by the application.

[0135] For example, the apparatus 20 in this embodiment may include a housing 21 having an internal space, and the first parameter range may be a range of parameters that cause the internal space to reach a durable temperature.

[0136] According to this, it is possible to suppress the internal space of the enclosure 21 from reaching the tolerance temperature when the application is executed, thereby improving the safety of the device 20 controlled by the application.

[0137] (Modified version of Embodiment 1) In the above embodiment 1, the processing of system 1 was explained with reference to Figure 8, but the processing flow is not limited thereto. In particular, the timing of the pre-execution check (S216) that is explained in detail and the main module involved are not limited thereto. Therefore, several modifications of the sequence diagram of system 1 will be specifically explained with reference to Figures 15A to 15E.

[0138] Figure 15A is a sequence diagram of System 1 in Modification 1 of Embodiment 1. In Figure 15A, pre-execution confirmation (S216) is performed by device 300 immediately before device 300 receives an execution instruction (S310) and executes the block (S314).

[0139] This allows the software incorporated into device 300 to have a simple configuration in which pre-execution checks are performed immediately before execution of a block. In other words, steps S215 and S217 can be omitted. As a result, it becomes unnecessary to incorporate functions and communication APIs for performing those processes into device 300, and it becomes possible to reduce the memory usage of the microcontroller mounted on device 300.

[0140] Furthermore, the results of the pre-execution check may be notified to the device manager 200 and / or UI400. For example, if a parameter change or a block execution stop instruction is issued as a result of the pre-execution check, the check results may be notified to the device manager 200 or UI400.

[0141] Figure 15B is a sequence diagram of System 1 in Modification 2 of Embodiment 1. In Figure 15B, the pre-execution check (S216) is performed by the Device Manager 200 when the Device Manager 200 notifies the allocation result (S218).

[0142] This means that the software incorporated into device 300 does not need to include the pre-execution verification (S216) function. Therefore, the memory usage of device 300 can be reduced, leading to a reduction in the cost of device 300.

[0143] Furthermore, in the above embodiment 1, the block execution (S314) by device 300 was described as being performed by instructions from the sequence manager 100 implemented in the cloud server 10, but the form in which block execution (S314) is performed is not limited to this.

[0144] For example, the notification content from the sequence manager 100 may be stored in the memory of the device 300, and the block may be executed by direct instruction from the user through the UI of the device 20 or the UI 400 of the terminal 30. In other words, the application may be downloaded to the device, and the user may execute the application at any time.

[0145] Figure 15C is a sequence diagram of System 1 in Modification 3 of Embodiment 1. In Figure 15C, during the application execution phase F300, the sequence manager 100 notifies the device 300 of one or more blocks to be executed by the device 300 (S310C). The device 300 then saves the one or more notified blocks to memory (S311C).

[0146] Subsequently, device 300 receives instructions from the user to execute one or more saved blocks (S312C), and executes one or more blocks in order from the first block (S314).

[0147] As described above, by saving the block to device 300, device 300 can be controlled without communication between device manager 200 and device 300. This reduces the risk of device 300 stopping or experiencing delays due to unstable communication between cloud server 10 and device 20. Therefore, this modified version is more effective in environments where communication with cloud server 10 is unreliable, and / or in devices 300 where device stopping or delays during application execution are unacceptable.

[0148] In Modification Example 3, as in Embodiment 1, the pre-execution check (S216) is of significant importance, but the timing of the pre-execution check (S216) and the main module involved are not limited to those shown in Figure 15C. In other words, Modification Example 3 may be combined with Modification Example 1 or 2.

[0149] Figure 15D is a sequence diagram of System 1 in Modification 4 of Embodiment 1. Modification 4 corresponds to a combination of Modification 1 and Modification 3. In Modification 4, as shown in Figure 15D, pre-execution confirmation (S216) is performed by device 300 immediately before device 300 receives an execution instruction (S312C) and executes the block (S314).

[0150] If a block is downloaded to device 300 and the user executes it at their discretion, there is a high probability that the timing of the block download and execution will be significantly different. In other words, the block may be executed several days, months, or even years after it is downloaded to device 300. In such cases, the degradation level of device 300 may change between the time the block is downloaded and the time it is executed. Therefore, for device 300, where the execution of the block is affected by the degradation level, a pre-execution check is performed by device 300 immediately before the block is executed, enabling a pre-execution check that is appropriate to the degradation level.

[0151] Figure 15E is a sequence diagram of System 1 in Modification 5 of Embodiment 1. Modification 5 corresponds to a combination of Modification 2 and Modification 3. In Modification 5, as shown in Figure 15E, the pre-execution confirmation (S216) is performed by the device manager 200 when the device manager 200 notifies the allocation result (S218).

[0152] (Embodiment 2) Next, Embodiment 2 will be described. This embodiment differs from Embodiment 1 in that pre-execution verification is skipped if the application is already authenticated. The following description will focus on the differences from Embodiment 1.

[0153] The hardware configuration and functional configuration of System 1 in this embodiment are the same as those in Embodiment 1 described above, so they are not shown or described.

[0154] [2.1 Processing] In this embodiment, the process is the same as in Embodiment 1, except that step S216 of the pre-execution verification process is replaced by step S216A. Therefore, step S216A of the pre-execution verification process will be explained with reference to Figure 16.

[0155] Figure 16 shows a flowchart of the pre-execution verification process in Embodiment 2.

[0156] (Step S2161A) Device 300 obtains app authentication information. App authentication information includes information indicating that the application is authenticated, if so.

[0157] Application authentication is a mechanism to guarantee the quality of an application, for example, and allows verification of the application's security and / or identity (that it has not been tampered with). An example of an application with authentication information is described below. If the change history of the application's code shows that no changes were made to the parameter range, then information indicating that the application is authenticated is associated with it.

[0158] (Step S2162A) Device 300 determines whether the application is authenticated based on the acquired application information. If it is determined that the application is authenticated (Yes in S2162A), device 300 skips the following steps S2165 to S2167 and terminates the pre-execution verification process. On the other hand, if it is determined that the application is not authenticated (No in S2162A), device 300 proceeds to the next step S2165.

[0159] [2.2 Effects, etc.] As described above, the apparatus 20 in this embodiment comprises at least one actuator 22 and a heater 23, and a control unit 24 that controls at least one of the actuator 22 and the heater 23. The control unit 24 acquires an application which includes information indicating whether or not it is certified and is defined by a plurality of blocks which drive at least one of the actuator 22 and the heater 23. Each of the plurality of blocks has parameters for driving the actuator 22 or the heater 23, and if the application does not include information indicating that it is certified, the control unit 24 modifies the application by modifying at least one of the plurality of blocks, referring to a first rule which defines a first parameter range in which driving at least one of the actuator 22 and the heater 23 is not permitted. At least one of the plurality of blocks has parameters included in the first parameter range and drives at least one of the actuator 22 and the heater 23 based on the modified application.

[0160] According to this, the actuator 22 and / or heater 23 can be driven based on an application defined by multiple blocks. Therefore, it becomes possible to develop applications using blocks that abstract the control of the device 20, and a wide variety of such applications can be easily executed on the device 20. Furthermore, before the actuator 22 and / or heater 23 are driven based on the application, it is possible to modify blocks that contain parameters included in an unacceptable first parameter range. Therefore, it is possible to prevent the actuator 22 and / or heater 23 from being driven with unacceptable parameters. In other words, it is possible to prevent the execution of applications that cannot safely control the device 20, thereby improving the safety of the device 20 controlled by the application. Furthermore, if the application is not authenticated, processing involving application modification can be performed, and if the application is authenticated, the processing load can be reduced. Therefore, it is not necessary to perform parameter range determination processing for all applications, and management through authentication reduces the processing load, provides a standard for designing parameter ranges, and enables easier and safer design for application developers.

[0161] Furthermore, for example, in the device 20 of this embodiment, if the application has information indicating that it is authenticated, the application does not need to be modified without referring to the first rule.

[0162] According to this, if the application is authenticated, the process of modifying the block can be skipped, thereby reducing the processing load.

[0163] (Embodiment 3) Next, Embodiment 3 will be described. This embodiment differs from Embodiment 1 in that pre-execution verification is skipped when the application creator and the device creator are the same person. The following description will focus on the differences from Embodiment 1.

[0164] The hardware configuration and functional configuration of System 1 in this embodiment are the same as those in Embodiment 1 described above, so they are not shown or described.

[0165] [3.1 Processing] In this embodiment, the process is the same as in Embodiment 1, except that step S216 of the pre-execution verification process is replaced by step S216B. Therefore, step S216B of the pre-execution verification process will be explained with reference to Figure 17.

[0166] Figure 17 shows a flowchart of the pre-execution verification process in Embodiment 3.

[0167] (Step S2161B) Device 300 retrieves app creator information. App creator information indicates the creator of the application. The creator refers to the company, individual, or organization that created the application, and may also be called the developer or author.

[0168] (Step S2163B) Device 300 retrieves device manufacturer information. Device manufacturer information indicates the manufacturer of the device. The manufacturer refers to the company, individual, or organization that manufactured device 300 (i.e., device 20), and is sometimes referred to as the producer.

[0169] (Step S2164B) Device 300 determines whether the creator of the application and the creator of Device 300 are different. If the creator of the application is an individual and the creator of Device 300 is a company, Device 300 may determine that the creator of the application and the creator of Device 300 are the same if the company to which the application creator belongs matches the creator of Device 300. Alternatively, Device 300 may determine that the creator of the application and the creator of Device 300 are the same if the application creator is a development contractor of the creator of Device 300.

[0170] If the creator of the application and the creator of device 300 are the same (No in S2164B), device 300 skips the subsequent steps S2165 to S2167 and terminates the pre-execution verification process. On the other hand, if the creator of the application and the creator of device 300 are different (Yes in S2164B), device 300 proceeds to the next step S2165.

[0171] [3.2 Effects, etc.] As described above, the apparatus 20 in this embodiment includes a control unit 24 that controls at least one of the actuator 22 and the heater 23, the control unit 24 acquires an application which includes information indicating the manufacturer and is defined by a plurality of blocks which drive at least one of the actuator 22 and the heater 23, each of the plurality of blocks has parameters for driving the actuator 22 or the heater 23, the control unit 24 acquires information indicating the manufacturer of the apparatus 20, and if the manufacturer of the application and the manufacturer of the apparatus 20 are different, the control unit 24 modifies the application by modifying at least one of the plurality of blocks which includes parameters which include parameters which include parameters which include parameters which include parameters which include the actuator 22 and the heater 23, and drives at least one of the actuator 22 and the heater 23 based on the modified application.

[0172] According to this, actuators and / or heaters can be driven based on applications defined by multiple blocks. Therefore, it becomes possible to develop applications using blocks that abstract the control of the device 20, and a wide variety of such applications can be easily executed on the device 20. Furthermore, before the actuators 22 and / or heaters 23 are driven based on the application, blocks containing parameters that fall within an unacceptable first parameter range can be modified. Therefore, it is possible to prevent the actuators 22 and / or heaters 23 from being driven with unacceptable parameters. In other words, it is possible to prevent the execution of applications that cannot safely control the device 20, thereby improving the safety of the device 20 controlled by the application. In addition, if the creator of the application and the manufacturer of the device 20 are different, processing involving changes to the application can be performed, and if the creator of the application and the manufacturer of the device 20 are the same, the processing load can be reduced.

[0173] (Embodiment 4) Next, Embodiment 4 will be described. This embodiment differs from Embodiment 1 in that pre-execution checks are performed using rules corresponding to the degradation level of the device. The following description will focus on the differences from Embodiment 1.

[0174] The hardware configuration and functional configuration of System 1 in this embodiment are the same as those in Embodiment 1 described above, so they are not shown or described.

[0175] [4.1 Processing] In this embodiment, the process is the same as in Embodiment 1, except that step S216 of the pre-execution verification process is replaced by step S216C. Therefore, step S216C of the pre-execution verification process will be explained with reference to Figure 18.

[0176] Figure 18 shows a flowchart of the pre-execution verification process in Embodiment 4.

[0177] (Step S2163C) Device 300 acquires device degradation information. The device degradation information indicates the degradation level of the actuator 22 and / or heater 23 included in the apparatus 20. The method for detecting the degradation level is not particularly limited and may be detected by a sensor, for example.

[0178] (Step S2165C) Device 300 retrieves rules corresponding to the degradation level. For example, device 300 refers to a rule database to obtain a parameter range corresponding to the degradation level of the actuator 22 or heater 23 driven by the block.

[0179] Figure 19 shows an example of a rule database in Embodiment 4. Rule database 1300C in Figure 19 contains rules 1301C to 1304C. Each of rules 1301C to 1304C has a parameter range that defines an unacceptable range. For example, rule 1301C has an unacceptable range greater than 1000 rpm for motor MM0001 with degradation level 0. For example, rule 1302C has an unacceptable range greater than 800 rpm for motor MM0001 with degradation level 1. In other words, rule 1302C has a wider unacceptable range and a narrower acceptable range than rule 1301C.

[0180] Each of rules 1301C to 1304C further includes a type, manufacturer name, actuator / heater, and degradation level. This allows device 300 to retrieve a rule from the rule database 1300 corresponding to the degradation level of the actuator 22 or heater 23 driven by the block. For example, if the degradation level of motor MM0001 driven by the dewatering block in Figure 10 is 0, device 300 retrieves rule 1301C for the dewatering block by referring to the rule database 1300C in Figure 19.

[0181] The factors that determine the degradation level include, for example, the number of uses, usage time, or number of days of use from the start of operation to the present for the actuator 22 and / or heater 23 included in device 300. These factors are assumed to increase in roughly proportional proportion to user usage. Therefore, the rules are determined such that the degradation level increases as the value corresponding to each factor increases.

[0182] Furthermore, the items that determine the degradation level are, for example, the sum of the temperatures of the heater 23, or the degree of reproducibility of the input and output of the actuator 22 and / or the heater 23. The sum of the temperatures of the heater 23 is the sum of the temperatures when the heater 23 is driven. For example, the average temperature, intermediate temperature, or maximum temperature of the heater 23 during block execution can be used. The temperature of the heater 23 may also be the ratio of the execution temperature to the limit temperature of the heater 23, or the difference between the execution temperature and the limit temperature of the heater 23.

[0183] The degree of reproducibility of the input and output of the actuator 22 and / or heater 23 is determined by referring to the relationship between the input value for driving the actuator 22 and / or heater 23 and the output of the actuator 22 and / or heater 23. The ratio of the actual output value for a given input to the output value defined in the relationship is used.

[0184] [4.2 Effects, etc.] As described above, the apparatus 20 in this embodiment comprises at least one actuator 22 and a heater 23, and a control unit 24 that controls at least one of the actuator 22 and the heater 23, wherein the control unit 24 acquires an application defined by a plurality of blocks that drive at least one of the actuator 22 and the heater 23, each of the plurality of blocks having parameters for driving the actuator 22 or the heater 23, acquires degradation information indicating whether at least one of the actuator 22 and the heater 23 is degraded, and if the degradation information indicates that at least one of the actuator 22 and the heater 23 is not degraded, a first rule that defines a first parameter range in which driving at least one of the actuator 22 and the heater 23 is not permitted. The application is modified by modifying at least one first block included in multiple blocks, where at least one first block has parameters included in a first parameter range, and if degradation information indicates that at least one of the actuators 22 and heaters 23 is degraded, driving at least one of the actuators 22 and heaters 23 is not permitted, by referring to a second rule that defines a second parameter range different from the first parameter range, where at least one second block included in multiple blocks has parameters included in the second parameter range, and drives at least one of the actuators 22 and heaters 23 based on the modified application.

[0185] According to this, the actuator 22 and / or heater 23 can be driven based on an application defined by multiple blocks. Therefore, it becomes possible to develop applications using blocks that abstract the control of the device 20, and a wide variety of such applications can be easily executed on the device 20. Furthermore, before the actuator 22 and / or heater 23 are driven based on the application, it is possible to change blocks that contain parameters included in an unacceptable first parameter range. Therefore, it is possible to prevent the actuator 22 and / or heater 23 from being driven with unacceptable parameters. In other words, it is possible to prevent the execution of applications that cannot safely control the device 20, thereby improving the safety of the device 20 controlled by the application. Furthermore, different parameter ranges can be used depending on the degradation information of the device 20, and by using blocks, it is possible to execute drive instructions to the actuator 22 and / or heater 23 from the application side while considering the performance of the device as it ages, thereby further improving the safety of the device 20 controlled by the application.

[0186] (Embodiment 5) In embodiments 1 to 4 described above, blocks included in an application that has already been distributed are modified before the application is executed. In this embodiment, the timing of the modification of the blocks included in the application is before the application is distributed, that is, during the development or production stage of the application, and in this respect, this embodiment differs from embodiments 1 to 4. The following describes this embodiment in detail, focusing on the differences from embodiments 1 to 4. Note that this embodiment may be the same as embodiments 1 to 4 except for the timing of the block modification. Also, for each component in this embodiment that is the same as in embodiments 1 to 4, the same reference numerals are used, and detailed descriptions are omitted.

[0187] [5.1 Structure] Figure 20 shows an example of the configuration of an information processing system used for application development.

[0188] The information processing system 2000 comprises a block database 41, a rule database 42, a development tool 50, multiple devices 20 and multiple terminals 30, an application provision server 60, and a sequence manager 100. For example, these components provided in the information processing system 2000 are connected via a communication network such as the Internet.

[0189] The block database 41, also called a block DB, is a recording medium that stores a list of blocks, including multiple functional blocks. These functional blocks are also called blocks, as in Embodiments 1 to 4. The rule database 42, also called a rule DB, is a recording medium that stores multiple rules. The rule database 42 may be the same as, for example, the rule database 1300 shown in Figure 12. These recording media can be hard disks, RAM (Random Access Memory), ROM (Read Only Memory), or semiconductor memory. Such recording media may be volatile or non-volatile.

[0190] The development tool 50 is a computer system comprising, for example, a processor 51, memory 52, a display 53, and an input unit 54. The processor 51 executes the processes described below by, for example, executing instructions or software programs stored in memory 52, and displays characters or images on the display 53. The display 53 is, for example, a liquid crystal display, a plasma display, or an organic EL (Electro-Luminescence) display, but is not limited to these. The input unit 54 is configured as, for example, a keyboard, a touch sensor, a touchpad, or a mouse. Such a development tool 50 is used, for example, by an application developer to generate a sequence or application containing multiple functional blocks. In this embodiment, the development tool 50 is an example of an information processing device.

[0191] The application provision server 60 retrieves and stores applications generated by the development tool 50 from the development tool 50 via the communication network. Then, in response to instructions from the UI 400 on the terminal 30, the application provision server 60 downloads the stored applications to the sequence manager 100.

[0192] Figure 21 shows examples of the information stored in the block database 41 and the rule database 42, respectively.

[0193] As shown in Figure 21(a), the block database 41 stores a list of functional blocks for each of the multiple types of devices 20, as the block lists described above. For example, block lists 41a to 41e are stored. Block list 41a includes functional blocks FB11 to FB14 for driving an oven range. Block list 41b includes functional blocks FB21 to FB24 for driving a multi-cooker. These functional blocks may be the same as or similar to the blocks in embodiments 1 to 4 described above.

[0194] As shown in Figure 21(b), the rule database 42 stores a set of rules for each of the multiple types of devices 20, each consisting of at least one rule applicable to that type of device 20. For example, rule sets 42a to 42e are stored. Rule set 42a includes rules R100 and R11 to R13 that apply to oven ranges. Rule set 42b includes rules R200 and R21 to R23 that apply to multi-cookers. Rule set 42d includes rules R400 and R41 to R43 that apply to washing machines. These rules may be the same as or similar to the rules in embodiments 1 to 4 described above.

[0195] Here, each of the oven range rules R11 to R13 is a specific rule applicable to a specific model of oven range manufactured by a specific manufacturer. Similarly, each of the multi-cooker rules R21 to R23 is a specific rule applicable to a specific model of multi-cooker manufactured by a specific manufacturer. Similarly, each of the washing machine rules R41 to R43 is a specific rule applicable to a specific model of washing machine manufactured by a specific manufacturer. Specifically, each of the specific rules R41 to R43 may be, for example, rule 1301 or 1302 shown in Figure 12.

[0196] On the other hand, Rule R100 for microwave ovens is a general rule for microwave ovens that can be applied to various types of microwave ovens, for example. Similarly, Rule R200 for multi-cookers is a general rule for multi-cookers that can be applied to various types of multi-cookers, for example.

[0197] Figure 22 shows an example of a general-purpose rule included in the rule database 42.

[0198] The washing machine rule group 42d stored in the rule database 42 includes, for example, the general-purpose rule R400 shown in Figure 22(a). This general-purpose rule R400 indicates a parameter range (500 rpm, +∞) applicable to each of several types of washing machines. These several types of washing machines include washing machines provided by multiple manufacturers. Furthermore, if each manufacturer provides multiple models of washing machines, these several types of washing machines include those multiple models. In other words, the parameter range shown in the general-purpose rule R400 is applicable to any washing machine, regardless of the manufacturer or model. Note that, as in Embodiments 1 to 4, the parameter range defines an unacceptable range. For example, the general-purpose rule R400 indicates a range greater than 500 rpm as an unacceptable range. Also, as in Embodiments 1 to 4, the unacceptable range may be, for example, the range of parameters that cause the internal space of the housing 21, the actuator 22, or the heater 23 to reach the durable temperature.

[0199] Furthermore, the general rule R400 for the washing machine may indicate parameter ranges applicable to washing machines from multiple manufacturers, as shown in Figure 22(b). For example, the general rule R400 may indicate parameter ranges (800 rpm, +∞) applicable to multiple models of washing machines provided by manufacturer "Company A", and parameter ranges (600 rpm, +∞) applicable to multiple models of washing machines provided by manufacturer "Company B", and so on.

[0200] [5.2 Processing] Figure 23 is a sequence diagram of the information processing system 2000.

[0201] (Step S11) First, the development tool 50 installs one or more functional blocks. Specifically, the development tool 50 obtains one or more functional blocks by downloading them from the block database 41. For example, the development tool 50 may obtain the block list 41a for the microwave oven, or it may obtain only some of the functional blocks from that block list 41a. Then, the development tool 50 makes the obtained one or more functional blocks available for sequence generation.

[0202] Here, each functional block stored in the block database 41 may have device information corresponding to that functional block attached to it. This device information indicates, for example, the manufacturer, type, model, or part number of the device 20 that is driven according to the functional block corresponding to that device information. Therefore, the development tool 50 may download one or more functional blocks based on that device information. For example, the development tool 50 may download one or more functional blocks to drive each device 20 provided by the same manufacturer, or it may download one or more functional blocks to drive each device 20 used for heating food.

[0203] (Step S12) Next, the development tool 50 generates a sequence. Specifically, the development tool 50 generates a sequence using one or more downloaded functional blocks in response to an input operation to the input unit 54 by the operator. The operator may be the developer of the application which is the sequence. In this embodiment, in step S12, the development tool 50 refers to the above-described rule and modifies the application based on that rule.

[0204] (Step S13) Next, the development tool 50 uploads the generated sequence. Specifically, in response to the user's input operation to the input unit 54, the development tool 50 generates transmission information based on the content of the sequence for sending the generated sequence to the application provision server 60, and sends this transmission information to the application provision server 60. This transmission information may be, for example, JSON (JavaScript Object Notation). As a result, the sequence is sent to the application provision server 60 and stored there as an application.

[0205] (Step S14) Next, the user of terminal 30 accesses the application distribution server 60 by operating the UI 400 on terminal 30 and views a list of applications stored on the application distribution server 60. Then, in response to the user's operation, the UI 400 selects an application from the list and requests the application distribution server 60 to download that application.

[0206] (Step S15) When the application server 60 receives a download request from the UI400, it downloads the selected application to the sequence manager 100 associated with that user.

[0207] Figure 24 is a flowchart showing the overall processing operation of the development tool 50. Specifically, the flowchart shown in Figure 24 illustrates the detailed processing operation of steps S11 and S12 in the sequence shown in Figure 23.

[0208] (Step S21) The development tool 50 first installs several functional blocks to drive a device 20, such as a washing machine.

[0209] (Step S22) Next, the development tool 50 performs the function block placement process in response to the operator's input operation to the input unit 54. That is, the development tool 50 displays the multiple function blocks installed in step S21 on the display 53, and in response to the operator's input operation to the input unit 54, it selects one function block from the displayed multiple function blocks. Then, in response to the operator's input operation to the input unit 54, the development tool 50 places that function block in the selection block area on the sequence generation screen on the display 53. The sequence generation screen will be described later with reference to Figure 27. In other words, the operator drags and drops one of the multiple function blocks into its selection block area.

[0210] (Step S23) Next, the development tool 50 performs parameter setting processing for the function block placed in step S22 in response to the operator's input operation to the input unit 54. That is, the development tool 50 displays a reception image in the parameter setting area of ​​the sequence generation screen described above to receive the contents of the parameters used for that function block. Then, in response to the operator's input operation to the input unit 54, the development tool 50 receives the contents of those parameters and displays the contents of those parameters in the parameter setting area. As a result, the parameters are set for that function block.

[0211] (Step S24) Next, the development tool 50 refers to the rules applied to the device 20, such as a washing machine, and determines whether the parameters set in step S23 are outside the parameter range indicated in the rules, i.e., outside the non-acceptable range.

[0212] (Step S25) If the development tool 50 determines in step S24 that the parameter is not outside the acceptable range (No. in step S24), it performs parameter setting support processing. In this parameter setting support processing, the development tool 50 performs either error presentation processing, which presents an error to the operator, or automatic parameter correction processing. In automatic parameter correction processing, the development tool 50 modifies the function block by changing a parameter outside the acceptable range to a parameter within the acceptable range. In error presentation processing, the development tool 50 displays a message on the display 53 as an error, for example, indicating that the parameter set in the previous step S23 is outside the acceptable range, and prompts the operator to change the parameter. After the processing in step S25 is completed, the development tool 50 repeats the processing from step S23.

[0213] Furthermore, if the process in step S23 is performed after the automatic parameter correction process in step S25, in step S23, the development tool 50 displays the parameters after they have been changed by the automatic correction process in the parameter setting area. On the other hand, if the process in step S23 is performed after the error notification process in step S25, in step S23, the development tool 50 again accepts the contents of the parameters in response to the input operation to the input unit 54 by the operator, as described above. As a result, the parameters for that function block are changed. In other words, the function block is changed.

[0214] (Step S26) If the development tool 50 determines in step S24 that the parameter is outside the acceptable range (Yes in step S24), it further determines whether the connection of the function block placed in step S22 is permitted. For example, in step S22, a function block is placed immediately before or after an existing block, which is another function block already placed in the selected block area. As a result, the function block is placed connected to the existing block. In other words, the function block is placed so that the processing of the device 20 by the function block and the processing of the device 20 by the existing block are executed consecutively. In this case, the development tool 50 determines whether the connection between the function block and the existing block is permitted by referring to the connection rules applied to the device 20, such as a washing machine.

[0215] (Step S27) If the development tool 50 determines in step S26 that the connection is not permitted (No. in step S26), it performs connection support processing. In this connection support processing, the development tool 50 performs error presentation processing to present an error to the operator, or performs automatic connection correction processing. The development tool 50 then repeats the processing from step S22.

[0216] If the process in step S22 is performed after the automatic connection correction process in step S27, then in step S22, the development tool 50 displays two or more function blocks that have been reconnected by the automatic correction process in the selected block area. On the other hand, if the process in step S22 is performed after the error presentation process in step S27, then in step S22, the development tool 50 rearranges the function blocks again in response to the input operation to the input unit 54 by the operator, as described above. Furthermore, if the process from step S27 to step S22 is repeated, the development tool 50 may skip the processes from step S22 to steps S23 to S25 because the parameters of the function blocks have already been set within the acceptable range.

[0217] (Step S28) If the development tool 50 determines in step S26 that a connection is permitted (Yes in step S26), it further determines whether the sequence generation is complete in response to the operator's input operation to the input unit 54. If the development tool 50 determines that the sequence generation is not complete (No in step S28), it repeats the process from step S22. In this case, the development tool 50 selects a new block from the multiple blocks installed in step S21 in response to the operator's input operation to the input unit 54 and places it in the selected block area described above.

[0218] (Step S29) If the development tool 50 determines that the generation of the sequence is complete in step S28 (Yes in step S28), it further determines whether the flow of the entire generated sequence is permitted. For example, if the second functional block is placed before or after the first functional block in the sequence, while the combination rule applied to the device 20, such as a washing machine, does not permit the combination of the first and second functional blocks, the development tool 50 determines that the flow of the entire generated sequence is not permitted. Alternatively, if the combination rule applied to the device 20, such as a washing machine, requires that the second functional block be placed before or after the first functional block, the development tool 50 determines that the flow of the entire generated sequence is permitted.

[0219] (Step S30) If the development tool 50 determines in step S29 that the overall flow of the sequence is not permitted (No. in step S29), it performs placement support processing. In this placement support processing, the development tool 50 performs either error presentation processing to present an error to the operator, or automatic correction processing of the placement of the functional blocks. Then, the development tool 50 repeats the processing from step S22.

[0220] Furthermore, if the process in step S22 is performed after the automatic placement correction process in step S30, the development tool 50 displays two or more function blocks that have been rearranged by the automatic correction process in the selected block area in step S22. Also, if the processes from step S30 to step S22 are repeated, the development tool 50 may skip the processes in steps S23 to S25 after step S22 because the parameters of the function blocks have already been set within the acceptable range. In addition, the development tool 50 may skip the processes in steps S26 and S27 because the connection of the function blocks has already been permitted. Furthermore, the development tool 50 may also skip the process in step S28.

[0221] Figure 25 is a flowchart showing an example of an automatic parameter correction process.

[0222] In the example shown in Figure 24, each time a functional block is selected and placed, a determination and automatic correction process are performed on the parameters of that functional block. However, the present disclosure is not limited to this example, and the development tool 50 may perform each process according to the flowchart shown in Figure 25.

[0223] (Step S41) The development tool 50 selects M function blocks (M being an integer between 1 and N) from N function blocks (N being an integer of 2 or more) for driving a device 20, such as a washing machine, in response to an input operation by the operator to the input unit 54. In other words, the development tool 50 selects each of the M function blocks as selected blocks from N function blocks for driving at least one of the actuators 22 and heaters 23 provided in the device 20, which is the controlled device, in response to an input operation by the operator to the input unit 54.

[0224] (Step S42) Next, the development tool 50 generates a sequence, or application, by setting parameters for each of the M selected functional blocks. In other words, the development tool 50 generates an application containing at least M selected blocks by setting parameters for each of the M selected blocks to drive the actuator 22 or heater 23, in accordance with the operator's input operation to the input unit 54.

[0225] (Step S43) Next, the development tool 50 refers to the rules applicable to the washing machine, if each of the M functional blocks is a block for driving the washing machine. For example, if the application generated in step S42 is applicable to multiple types of washing machines, the development tool 50 refers to the general rule R400. Also, if the application generated in step S42 is applicable to a predetermined type of washing machine, the development tool 50 refers to the rule from the dedicated rules R41 to R43 that is associated with that type of washing machine. In other words, the development tool 50 determines whether the application generated in step S42 is an application dedicated to the controlled device or a general-purpose application applicable to that controlled device and other devices. Then, the development tool 50 refers to the rule candidate from among several rule candidates that define parameter ranges in which the driving of at least one of the actuator 22 and heater 23 is not permitted, according to the determination result of the application, as the rule described above.

[0226] (Step S44) The development tool 50 then determines whether the parameters of each of the M functional blocks set in step S42 fall within the non-acceptable range indicated by the rules described above.

[0227] (Step S45) Here, if the development tool 50 determines that the parameter falls within an unacceptable range (Yes in step S44), it modifies the functional block having that parameter. In other words, the development tool 50 modifies the application by modifying at least one of the M selection blocks by referring to a rule that defines a parameter range in which the driving of at least one of the actuator 22 and heater 23 is not permitted, where at least one of the M selection blocks has a parameter that falls within that parameter range.

[0228] (Step S46) Then, development tool 50 outputs the modified application.

[0229] Figure 26 is a flowchart showing an example of parameter error notification processing.

[0230] In the example shown in Figure 24, each time a functional block is selected and placed, a check is performed on the parameters of that functional block and error reporting is carried out. However, the present disclosure is not limited to this example, and the development tool 50 may perform each process according to the flowchart shown in Figure 26.

[0231] (Steps S41-S44) The development tool 50 executes the processes in steps S41 to S44, similar to the example shown in Figure 25.

[0232] (Step S51) If the development tool 50 determines in step S44 that a parameter falls within an unacceptable range (Yes in step S44), it displays an error on the display 53 without automatically modifying the function block containing that parameter. This presents the error to the operator. In other words, in the processing of steps S43, S44, and S51, the development tool 50 presents the error by referring to a rule. Specifically, the development tool 50 refers to a rule that defines a parameter range in which the driving of at least one of the actuator 22 and heater 23 is not permitted, and presents an error to the operator if at least one of the M selection blocks has a parameter that falls within the aforementioned parameter range.

[0233] Furthermore, the development tool 50 may present an error and show the operator multiple solutions, prompting the operator to choose one. In this case, the development tool 50 may show the operator the differences in output performance for each of the multiple solutions. In addition, the development tool 50 may present at least two or more solutions from among solutions involving parameter changes, solutions involving deleting selected blocks, and solutions involving adding blocks.

[0234] (Step S52) Upon seeing the error, the operator modifies the parameter set in step S42 by performing an input operation to the input section 54 of the development tool 50. If multiple solutions are presented to the operator as options, the operator selects a solution from these options by performing an input operation. As a result, the development tool 50 modifies the functional block. In other words, the development tool 50 modifies the application by changing at least one of the M selection blocks in response to the input operation by the operator who received the error. The development tool 50 then repeatedly executes the process from step S43.

[0235] (Step S46) When the development tool 50 determines in step S44 that the parameter is not included in the unacceptable range (No in step S44), it outputs the application. At this time, if the application has been changed in step S52, the changed application is output. On the other hand, if the application has not been changed in step S52, the application generated in step S42 is output.

[0236] Here, when the process of step S51 is repeated, the development tool 50 may change the error presentation form according to the number of repetitions. For example, when the number of error presentations is K times (K is an integer of 2 or more), the development tool 50 presents the operator with the parameters not included in the above parameter range. That is, when the number of error presentations is K times or more, the development tool 50 displays, on the display 53, the parameters not included in the parameter range, that is, the parameters not included in the unacceptable range, as candidates for the parameters set in the functional block. As a result, the operator who is an application developer who sees the candidate can easily change the parameters set in step S42 to the candidate by performing an input operation on the input unit 54 of the development tool 50.

[0237] Alternatively, when the number of error presentations is K times or more, the development tool 50 may present the operator with the range of the parameters not included in the above parameter range. That is, when the number of error presentations is K times or more, the development tool 50 displays the allowable range of the parameters on the display 53. As a result, the operator who is an application developer who sees the allowable range can easily change the parameters set in step S42 to the parameters within the allowable range by performing an input operation on the input unit 54 of the development tool 50.

[0238] [5.3 Display Example] FIG. 27 is a diagram showing an example of a sequence generation screen.

[0239] The development tool 50 displays the above-described sequence generation screen on the display 53. The sequence generation screen includes a parameter setting area D1, a block list area D2, a target device area D3, and a selected block area D4.

[0240] In the parameter setting area D1, a reception image for receiving the content of the parameters used for the function block is displayed.

[0241] In the block list area D2, the block lists of each of the plurality of types of devices 20 are displayed. These block lists include the function blocks downloaded from the block database 41 and installed in the development tool 50.

[0242] In the target device area D3, the type name of the device 20 selected from the plurality of types of devices 20 is displayed.

[0243] In the selected block area D4, the function block selected from the block list displayed in the block list area D2 is arranged and displayed. The function block is displayed, for example, as an icon.

[0244] For example, the operator determines the type name of the device 20 to which the application is applied by performing an input operation on the input unit 54 of the development tool 50. The development tool 50 displays the determined type name in the target device area D3. For example, the determined type name "rice cooker" is displayed. Next, the operator selects a function block to drive the device 20 with the determined type name "rice cooker" from the block list displayed in the block list area D2 by performing an input operation. Then, the operator places the selected function block, i.e., the selected block, in the selection block area D4 by performing an input operation. The selection and placement of this function block may be done by drag and drop. One or more function blocks placed in this selection block area D4 may be executed in the order in which they are placed. In other words, the application includes information on the order in which each of the M selected blocks placed in the selection block area D4 is executed, and information on the timing in which each of the M selected blocks is executed.

[0245] When a functional block is placed in the selection block area D4, the development tool 50 displays the input images of the parameters used for that functional block in the parameter setting area D1.

[0246] Figure 28 shows an example of how the block list is displayed.

[0247] The operator selects the type name of the device 20 to which the application to be generated will be applied from among the type names of multiple devices 20 displayed in the block list area D2 shown in Figure 27 by performing an input operation on the input unit 54. The development tool 50 displays the block list corresponding to the selected type name of device 20, for example, as shown in Figures 28(a) and (b). For example, as shown in Figure 28(a), when an oven range is selected, the development tool 50 displays the block list for that oven range. For example, this block list includes function blocks that realize the functions of baking, microwave heating, oven, grill, steaming, preheating, and superheated steam. Also, as shown in Figure 28(b), when a multi-cooker is selected, the development tool 50 displays the block list for that multi-cooker. For example, this block list includes function blocks that realize the functions of preheating, keeping warm, stir-frying, pressure cooking, boiling, steaming, simmering, mixing, and simmering.

[0248] The operator selects a function block from the displayed block list by performing an input operation to the input unit 54, and places the selected function block in the selection block area D4 shown in Figure 27. In other words, the development tool 50 performs the process of step S22 shown in Figure 24, that is, the function block placement process, in response to such an input operation.

[0249] Figure 29 shows an example of the display of the parameter setting area D1.

[0250] The development tool 50 displays, for example, as shown in Figures 29(a) and (b), a reception image for receiving the contents of the parameters included in the function block of the oven range device 20 in the parameter setting area D1. The oven range can be fitted with a function block that realizes the oven function and a function block that realizes the microwave heating function.

[0251] For example, the reception image of the parameter setting area D1 shown in Figure 29(a) is an image for receiving the contents of multiple parameters included in the oven's function block. For example, the oven's function block includes the oven's set temperature, duration, steam on / off, and two-stage cooking on / off as parameters. The operator looks at the reception image and performs an input operation to the input unit 54, inputting the numerical values ​​of the set temperature and duration as the contents of the set temperature parameter and the duration parameter, respectively. Furthermore, the operator inputs either on or off for steam and either on or off for two-stage cooking as the contents of the steam parameter and the two-stage cooking parameter, respectively. The development tool 50 sets each parameter used in the oven's function block by receiving the contents of each input parameter.

[0252] Similarly, the reception image of the parameter setting area D1 shown in Figure 29(b) is an image for receiving the contents of multiple parameters included in the microwave heating function block. For example, the microwave heating function block includes a power output setting and a duration as parameters. The operator looks at the reception image and performs an input operation to the input unit 54, thereby inputting the numerical values ​​of the power output setting and duration as the contents of the power output parameter and the duration parameter, respectively. The development tool 50 sets each parameter used in the microwave heating function block by receiving the contents of each input parameter.

[0253] In this way, the development tool 50 performs the parameter setting process shown in step S23 of Figure 24 in response to the operator's input.

[0254] Furthermore, once each parameter included in the functional block is set, the development tool 50 determines whether or not that parameter is outside the acceptable range by referring to the rules of the device 20 corresponding to that functional block, as shown in step S24 of Figure 24.

[0255] Figure 30A shows an example of an automatic correction process for a functional block.

[0256] For example, as shown in Figure 30A(a), the operator inputs numerical values ​​for the set temperature and duration included in the oven's function block by performing input operations on the input unit 54. Furthermore, the operator inputs either on or off for steam and either on or off for two-stage cooking by performing input operations on the input unit 54. This sets each parameter used in the oven's function block.

[0257] Once each parameter is set in this way, the development tool 50 performs an automatic correction process for that functional block. First, the development tool 50 refers to the oven range rules corresponding to that functional block. For example, the development tool 50 identifies the oven range rule group 42a from the rule database 42 shown in Figure 21(b), and refers to one of the rules included in that rule group 42a. That rule may be a general-purpose rule R100, a dedicated rule R11, or the like.

[0258] The development tool 50 then determines that the input parameter, the set temperature value, for example, 350°C, falls within the parameter range specified in the rules, i.e., within the unacceptable range, and modifies that parameter value. For example, if the parameter range exceeds 300°C, the development tool 50 modifies the set temperature value from 350°C to 300°C, as shown in Figure 30A(b). In this case, the development tool 50 may also modify the duration parameter to increase the duration in order to lower the set temperature. Such parameter modifications change the oven's functional block, that is, the application containing that functional block is modified. This ensures the safety of the oven range.

[0259] As described above, in the present embodiment, the development tool 50 refers to the rules to determine whether each of the plurality of parameters included in the M selection blocks is within the parameter range. When it is determined that the parameter is within the parameter range, the selection block having the parameter is changed. That is, the development tool 50 refers to the rules and changes the parameter within the parameter range to a parameter within the range in which at least one of the actuator 22 and the heater 23 is allowed to be driven, thereby changing the application.

[0260] FIG. 30B is a diagram showing another example of the automatic correction process of the function block.

[0261] In addition, in the automatic correction process of the function block, the development tool 50 may not only correct the parameters but also add a new function block. For example, as shown in (a) of FIG. 30B, the operator inputs the numerical values of the set temperature and the duration included in the function block of the oven by performing an input operation on the input unit 54. Thereby, each parameter used in the function block of the oven is set.

[0262] The development tool 50 then modifies the numerical value of the input parameter, the duration, if it determines that the duration falls within the parameter range specified in the rule. In the example in Figure 30B(a), the duration is 120 minutes. In other words, if the development tool 50 determines that 120 minutes falls within the unacceptable range, it modifies the 120 minutes. Specifically, if the parameter range exceeds 60 minutes, the development tool 50 modifies the duration from 120 minutes to 60 minutes, as shown in Figure 30B(b). At this time, the development tool 50 adds, for example, the stop function block shown in Figure 30B(c) and the oven function block shown in Figure 30B(d) to shorten the duration. The added stop function block stops the operation of the oven range for 10 minutes. The added oven function block compensates for the oven duration that is no longer performed due to the reduction in the duration from 120 minutes to 60 minutes, as described above. In other words, in this example, the added oven function block includes parameters for a set temperature of "300°C" and a duration of "60 minutes." This ensures the safety of the oven.

[0263] Thus, in this embodiment, the development tool 50 may modify the application by referring to the rules and changing the parameters included in the parameter range to parameters included in the range in which the driving of at least one of the actuator 22 and heater 23 is permitted, and by adding new blocks to the M selection blocks.

[0264] Furthermore, similar to embodiments 1 to 4 described above, the development tool 50 may delete the oven function block containing the parameter if the parameter has been set, as shown in Figures 30A(a) and 30B(a). In other words, the development tool 50 modifies the application by deleting the selection block containing the parameter included in the parameter range. This also ensures the safety of the oven range.

[0265] Figure 31 shows an example of error notification processing.

[0266] For example, as shown in Figure 31(a), the operator inputs numerical values ​​for the set temperature and duration included in the oven's function block by performing input operations on the input unit 54. This sets each parameter used in the oven's function block.

[0267] Here, the development tool 50 first refers to the oven range rule corresponding to that function block. Then, if the development tool 50 determines that the input parameter, the set temperature value, falls within the parameter range indicated in the rule, it performs an error presentation process. In the example in Figure 31, the set temperature value is 350°C. In other words, if the development tool 50 determines that 350°C falls within the unacceptable range, it performs an error presentation process. Specifically, as shown in Figure 31(a), the development tool 50 displays an error message E1 in the parameter setting area D1, for example. This error message E1 indicates that the temperature is too high. Such error presentation processing is performed, for example, in step S51 in Figure 26.

[0268] Furthermore, if the development tool 50 determines that the input parameter, the set temperature, falls within an unacceptable range, it may display an error message E2 in the parameter setting area D1, for example, as shown in Figure 31(b). This error message E2 contains a candidate for the set temperature, such as 300°C. Such error presentation processing may be performed, for example, in step S51 in Figure 26, when the error is repeatedly presented K times or more, as described above.

[0269] Furthermore, if the development tool 50 determines that the input parameter, the set temperature, falls within an unacceptable range, it may display an error message E3 in the parameter setting area D1, for example, as shown in Figure 31(c). This error message E3 indicates the settable range for the set temperature, for example, 100 to 300°C. This settable range is the acceptable range for parameters such as the set temperature. Such error presentation processing may be performed, for example, in step S51 in Figure 26, when the error is repeatedly presented K times or more, as described above.

[0270] By presenting such an error, the application developer, or operator, can easily readjust the parameters from an unacceptable range to an acceptable range. Therefore, the safety of the microwave oven can be ensured.

[0271] In the examples above, error messages E1 to E3 are displayed, but the format in which these errors are presented is not limited to these examples; any format is acceptable. For example, errors may be presented audibly.

[0272] Figure 32 shows an example of error presentation and the presentation of multiple solutions.

[0273] In the example in Figure 32(a), the set temperature is 300°C and the duration is 120 minutes. The development tool 50 refers to the rules regarding the upper limit of the duration when the set temperature is 300°C, and if it determines that 120 minutes is within the unacceptable range, it suggests a solution to correct that 120 minutes. In other words, the development tool 50 presents the error message E1 shown in Figure 32(a), and the solutions and effects shown in Figures 32(b) and (c). Specifically, for example, as shown in Figure 32(b), the development tool 50 presents solution 1, which corrects the duration from 120 minutes to 60 minutes, adds a block that stops the oven operation for 10 minutes, and adds a block to compensate for the duration of the oven that will no longer be performed. The development tool 50 also refers to the rules indicating the upper limit of the set temperature for a duration of 120 minutes, and if it determines that 300°C is within the unacceptable range, it suggests a solution to correct that 300°C. Specifically, as shown in Figure 32(c), for example, the development tool 50 suggests solution 2, which involves lowering the set temperature value to 200°C.

[0274] By presenting multiple solutions simultaneously with the error message, the effort required for the user to change parameters can be reduced.

[0275] Furthermore, when the development tool 50 presents multiple solutions, it may also present the impact each solution has on the application. Alternatively, when the development tool 50 presents multiple solutions, it may present the impact on the food being heated by the oven. For example, as shown in Figure 32(b), when solution 1 is presented, the development tool 50 presents impact 1. As described above, solution 1 is a solution that modifies the duration value from 120 minutes to 60 minutes, adds a block that stops the oven range operation for 10 minutes, and adds a block to compensate for the duration of the oven that will no longer be operated. When such a solution 1 is presented, the development tool 50 notifies the user of the event that the amount of heat delivered to the food is the same, but the total oven time (i.e., baking time) is extended, as described above, as impact 1. Also, as shown in Figure 32(c), when solution 2 is presented, which lowers the set temperature value to 200°C, the development tool 50 notifies the user of the possibility that the amount of heat delivered to the food will decrease, thereby changing the shape and texture of the food, as described above, as impact 2. Furthermore, the development tool 50 may present a method for deleting the functional block shown in Figure 32(a), i.e., a selection block having parameters included in the non-acceptable range, and the impact of such deletion, which results in the food not being oven-cooked.

[0276] In other words, in this embodiment, the development tool 50 presents multiple solutions to an error and modifies the application by changing at least one of the M selection blocks described above, in response to the input operation by the operator who has received the error and the multiple solutions. Specifically, the multiple solutions include at least two of the following: a solution to change a parameter included in the parameter range, a solution to add a new block to the M selection blocks, and a solution to delete a selection block having a parameter included in the parameter range. Furthermore, the development tool 50 presents the effect on the object acted upon by the operation of the actuator 22 or heater 23, or the effect on the application, when each of the multiple solutions is performed. In the example in Figure 32, the object acted upon by the operation of the actuator 22 or heater 23 is the food heated by the heater 23. Also, the information regarding the error, solutions, and effects may be shown in correspondence with the parameter range in the rule.

[0277] By presenting multiple solutions along with their respective impacts on the application, users can intuitively select a solution that aligns with their intentions in creating the application.

[0278] It should be noted that while solutions involving only parameter changes or deleting selected blocks are likely to have some impact on application performance, solutions involving additions of blocks can relatively minimize the impact on application performance, although they may affect application execution time. In other words, the impact on the application will differ depending on the type of solution. On the other hand, it is expected that users will have various priorities depending on the situation, such as wanting to minimize the impact on application performance or wanting to change application execution time.

[0279] In other words, to provide operators with appropriate solutions in diverse situations, when presenting multiple solutions, it is best to present at least two solutions from among those involving parameter changes, deletion of selected blocks, and addition of blocks. For example, as shown in the example in Figure 32, it is best to present both a solution involving only parameter changes and a solution involving changes that include adding blocks. This allows operators to select an option that fulfills their intent in creating the application when choosing a solution.

[0280] [5.4 Effects, etc.] As described above, this embodiment provides an environment in which a wide variety of safe applications can be developed using an application including blocks and a rule database. Therefore, it enables the safe operation of a physically moving actuator 22 or a heater 23 that outputs thermal energy for an application freely developed in that environment. As a result, for example, it becomes possible to create a wide variety of applications with a high degree of freedom and a rule database to ensure safety in parallel, enabling the early development of a wide variety of safe applications.

[0281] Furthermore, by combining this embodiment with any of the embodiments 1 to 4, it becomes possible to modify the application to ensure greater security even after the application has been provided, by changing the rule database. Also, even if improvements become necessary in situations not anticipated by the manufacturer in advance, it is possible to support all applications by updating the rule database, which is defined independently of the applications themselves, without having to change the diverse range of applications.

[0282] Specifically, the information processing method in this embodiment is an information processing method executed by a computer system such as the development tool 50. In this information processing method, (a) from N blocks (N is an integer of 2 or more) for driving at least one of the actuator 22 and heater 23 provided in the device 20 which is the controlled device, each of M blocks (M is an integer of 1 or more and less than or equal to N) is selected as a selected block in response to an input operation by the operator; (b) parameters for driving the actuator 22 or heater 23 are set in each of the M selected blocks in response to an input operation by the operator, thereby generating an application that includes at least the M selected blocks; (c) the application is modified by modifying at least one of the M selected blocks by referring to a rule that defines a parameter range in which driving at least one of the actuator 22 and heater 23 is not permitted, so that at least one of the M selected blocks has parameters that fall within that parameter range; and (d) the modified application is output.

[0283] According to this, the actuator 22 and / or heater 23 can be driven based on an application defined by M blocks. Therefore, it becomes possible to develop applications using blocks that abstract the control of the device 20, allowing not only the manufacturer but also third parties to develop a wide variety of applications, and these applications can be easily executed on the device 20. Furthermore, during this development, blocks containing parameters that fall within an unacceptable parameter range can be automatically modified. Therefore, it is possible to prevent the actuator 22 and / or heater 23 from being driven with unacceptable parameters. In other words, even if an operator, who is an application developer, mistakenly sets unacceptable parameters for the actuator 22 and / or heater 23, it is possible to prevent the creation of an application that cannot safely control the device 20. Therefore, even if an application developer creates or generates an application that prioritizes suitability for the user of the actuator 22 and / or heater 23, the safety of the device 20 controlled by that application can be guaranteed and its safety can be improved.

[0284] Furthermore, in (c) above, the application may be modified by referring to the rule and changing the parameters included in that parameter range to parameters included in the range in which the driving of at least one of the actuator 22 and heater 23 is permitted.

[0285] According to this, parameters that fall within an unacceptable parameter range can be automatically changed to parameters that fall within an acceptable range. Therefore, for example, an operator who is the developer of an application can relatively freely create an application in which the actuator 22 and heater 23 are safely driven without having to be aware of the acceptable range of those parameters.

[0286] Furthermore, in (c) above, the application may be modified by referring to the rule and changing the parameters included in the parameter range to parameters included in the range in which at least one of the actuator 22 and heater 23 is allowed to be driven, and by adding new blocks to the M selection blocks.

[0287] According to this, parameters that fall within the unacceptable parameter range can be changed to parameters that fall within the acceptable range, thereby preventing the actuator 22 and / or heater 23 from being driven with unacceptable parameters. Furthermore, new blocks can be added, making it possible to compensate for the reduced functionality caused by the parameter changes with these new blocks.

[0288] Furthermore, in (c) above, the application may be modified by deleting the selection block that has parameters included in that parameter range.

[0289] According to this, blocks containing parameters that fall within an unacceptable parameter range can be deleted, thereby preventing the actuator 22 and / or heater 23 from being driven with unacceptable parameters. For example, if the actuator 22 and heater 23 are incapable of executing the parameters set by the application developer, deleting them allows the controlled devices to be controlled without confusion. Alternatively, the operator may be notified that the blocks have been deleted.

[0290] Furthermore, (c) above may refer to the rule to determine whether each of the multiple parameters included in the M selection blocks is included in the parameter range, and if it is determined that the parameter is included in the parameter range, the selection block containing that parameter may be changed.

[0291] This allows for a more reliable modification of blocks that contain parameters within an unacceptable parameter range.

[0292] The application may also include information about the order in which each of the M selection blocks is executed, and information about the timing of the execution of each of the M selection blocks. The timing information for each selection block may, for example, indicate the time between the start timing of that selection block and the start or end timing of another selection block (e.g., the first selection block).

[0293] According to this, the application can include information on order and timing, and can execute sequentially while checking the parameter range of each selected block.

[0294] Furthermore, the parameter range is the range of parameters that cause at least one of the actuator 22 and the heater 23 to reach its durability temperature.

[0295] According to this, it is possible to prevent the actuator 22 and / or heater 23 from reaching their tolerable temperature when the application is executed, thereby improving the safety of the device 20 controlled by the application.

[0296] Furthermore, the device 20, which is the controlled device, includes a housing 21 having an internal space, and the parameter range may be the range of parameters that cause the internal space to reach a durable temperature.

[0297] According to this, it is possible to suppress the internal space of the enclosure 21 from reaching the tolerance temperature when the application is executed, thereby improving the safety of the device 20 controlled by the application.

[0298] Furthermore, in (c) above, it may be determined whether the generated application is an application dedicated to the controlled device or a general-purpose application applicable to the controlled device and other devices, and a rule candidate corresponding to the determination result for that application may be referenced as a rule from among a plurality of rule candidates that define parameter ranges in which the driving of at least one of the actuator 22 and heater 23 is not permitted.

[0299] This allows for an increase in application variations, such as dedicated applications and general-purpose applications. Furthermore, since rules appropriate to each variation are referenced, each variation can be appropriately modified for that specific application.

[0300] Furthermore, the information processing method in this embodiment is an information processing method executed by a computer system such as the development tool 50, and may present errors. In other words, the information processing method (a) selects M blocks (M is an integer of 1 or more and less than or equal to N) from N blocks (N is an integer of 2 or more) for driving at least one of the actuator 22 and heater 23 provided in the device 20, which is the controlled device, as selected blocks in response to an input operation by the operator; (b) generates an application including at least the M selected blocks by setting parameters for driving the actuator 22 or heater 23 in each of the M selected blocks in response to an input operation by the operator; (c) refers to a rule that defines a parameter range in which driving at least one of the actuator 22 and heater 23 is not permitted, and if at least one of the M selected blocks has a parameter included in the parameter range, presents an error to the operator; (d) modifies the application by changing at least one of the M selected blocks in response to an input operation by the operator who has received the error; and (e) outputs the modified application.

[0301] According to this, if the operator, who is the application developer, mistakenly sets unacceptable parameters for the actuator 22 and / or heater 23, an error will be presented, thus preventing the creation of applications that cannot safely control the device 20. In other words, it can achieve the same effect as when the application is automatically modified as described above.

[0302] Furthermore, the information processing method in this embodiment is an information processing method executed by a computer system such as the development tool 50, and may present an error and simultaneously present multiple solutions.

[0303] This reduces the effort required for operators to change parameters after encountering an error message.

[0304] Furthermore, the information processing method in this embodiment is an information processing method executed by a computer system such as the development tool 50, and may present a method for dealing with errors, as well as simultaneously present the impact on the application of implementing that method.

[0305] According to this, when an operator chooses a solution, they can make an intuitive choice that aligns with the intent behind creating the application.

[0306] Furthermore, the information processing method in this embodiment is an information processing method executed by a computer system such as the development tool 50, and when presenting a method for dealing with an error, it is preferable to present at least two or more methods from among methods that involve changing parameters, methods that involve deleting selected blocks, and methods that include adding blocks.

[0307] According to this, when an operator chooses a solution, they can select an option that fulfills the intent behind creating the application.

[0308] Furthermore, in this information processing method, after (d) above, (c) and (d) above are repeatedly executed, and if the number of times an error is presented is K or more (where K is an integer of 2 or more), parameters not included in the parameter range may be presented to the operator.

[0309] According to this approach, if errors are repeatedly presented, parameters not included in the parameter range can be presented to the operator as suitable parameter candidates. As a result, the operator can easily change parameters included in the parameter range to parameters not included in the parameter range, making it easier to create secure applications.

[0310] Furthermore, in this information processing method, after (d) above, (c) and (d) above may be repeatedly executed, and (f) if the number of times an error is presented is K or more (where K is an integer of 2 or more), the operator may be presented with a range of parameters that are not included in the parameter range.

[0311] According to this approach, if an error is repeatedly presented, the operator will be presented with a parameter range that is not included in the current parameter range. As a result, the operator can easily change a parameter included in the parameter range to one that is not included, making it easier to create a secure application.

[0312] (Embodiment 6) In embodiments 1 to 4 described above, the parameters of blocks included in an application that has already been distributed are changed before the application is executed. In embodiment 5, the parameters of blocks included in an application are changed before the application is distributed, that is, during the development or production stage of the application. On the other hand, in this embodiment, the parameters of blocks included in an application are changed while the application that has already been distributed is being executed. The blocks mentioned above are functional blocks. The following describes this embodiment in detail, focusing on the differences from embodiments 1 to 5 described above. Among the components in this embodiment, components that are the same as those in embodiments 1 to 5 are denoted by the same reference numerals as in embodiments 1 to 5, and detailed descriptions are omitted.

[0313] [6.1 Structure] Figure 33 is a block diagram showing an example of the apparatus 20 in Embodiment 6.

[0314] The device 20 in this embodiment is an example of a drive device and comprises a control unit 24, a drive unit W, a first sensor 25a, a second sensor 25b, and a memory 26.

[0315] The drive unit W includes an actuator 22 and a heater 23. In the example shown in Figure 33, the drive unit W includes both the actuator 22 and the heater 23, but it is sufficient to include at least one of them.

[0316] The control unit 24 acquires an application containing multiple functional blocks and stores the acquired application in the memory 26. For example, as in Embodiments 1 to 4, the control unit 24 acquires an application from the sequence manager 100 or the device manager 200. Furthermore, the control unit 24 controls the drive unit W according to its multiple functional blocks by executing the application. In this embodiment, each of the multiple functional blocks has parameters used for controlling the drive unit W by the functional block and termination conditions for driving the drive unit W by the functional block. These functional blocks are the same as those in Embodiments 1 to 5.

[0317] The memory 26 is, for example, a recording medium for storing applications, and specifically, is RAM (Random Access Memory), ROM (Read Only Memory), or semiconductor memory. Such memory 26 may be volatile or non-volatile.

[0318] The first sensor 25a detects the first driving status of the drive unit W. For example, the first sensor 25a is a timer. In other words, when the drive unit W is performing a drive according to the first of its multiple functional blocks, the first sensor 25a detects the duration of the drive of the drive unit W according to that first functional block as the first driving status.

[0319] The second sensor 25b detects a second driving condition of the drive unit W. For example, the second sensor 25b detects the temperature, rotational speed, or number of spills caused by the driving of the drive unit W as the second driving condition.

[0320] In this embodiment, the control unit 24 modifies the parameters included in a function block when predetermined conditions are met during the execution of the application, and controls the drive unit W according to the function block containing the modified parameters. The predetermined conditions are met when, during the execution of the first function block among a plurality of function blocks, the first drive status detected by the first sensor 25a satisfies the termination condition of the first function block, and the second drive status detected by the second sensor 25b satisfies the parameter modification condition. In such a case, the control unit 24 modifies the parameters of the second function block, which is executed after the first function block among the plurality of function blocks. The control unit 24 then controls the drive unit W according to the second function block having the modified parameters. The parameters of the second function block are the time during which the drive of the drive unit W continues according to the second function block, or the temperature or heat generated by the drive of the drive unit W.

[0321] Thus, in this embodiment, when the drive unit W is finished driving according to the first functional block, if the second driving state satisfies the parameter change condition, the parameters of the second functional block following the first functional block are changed. Therefore, in the second driving state of the drive unit W, if driving the drive unit W with the parameters of the second functional block could cause danger, those parameters can be automatically changed. Since this second driving state varies considerably depending on how the user uses the device 20, it can be difficult to set parameters in advance that do not cause danger during application development. However, in this embodiment, the second driving state is detected during application execution, and the parameters are changed according to that second driving state, so the occurrence of danger can be appropriately suppressed. As a result, even when acquiring a wide variety of applications and controlling the drive unit W according to those applications, the safety of the device 20 controlled by those applications can be guaranteed and its safety can be improved.

[0322] [6.2 Processing] Figure 34 is a flowchart showing an example of the processing operation of the device 20 in this embodiment.

[0323] (Step S61) First, the control unit 24 of the device 20 acquires the application.

[0324] (Step S62) Next, the control unit 24 of the device 20 performs application execution processing. That is, the control unit 24 executes each functional block included in the acquired application.

[0325] Figure 35 is a flowchart showing an example of the application execution process by the device 20 in this embodiment.

[0326] (Step S62a) First, the control unit 24 controls the drive unit W according to the function block by executing the function block included in the application. In other words, the drive unit W is driven.

[0327] (Step S62b) Next, the control unit 24 acquires the first drive status detected by the first sensor 25a and determines whether the first drive status satisfies the termination condition of the functional block being executed in step S62. If the control unit 24 determines that the first drive status does not satisfy the termination condition (No. in step S62b), it continues the processing in step S62a.

[0328] (Step S62c) Next, if the control unit 24 determines that the first drive status satisfies the termination condition (Yes in step S62b), it determines whether the function block after the function block executed in step S62 is included in the application. If the control unit 24 determines that the subsequent function block is not included in the application (No in step S62c), it terminates the application execution process.

[0329] (Step S62d) Next, if the control unit 24 determines that a later functional block is included (Yes in step S62c), it acquires the second drive status detected by the second sensor 25b. Then, the control unit 24 determines whether the second drive status satisfies the parameter change condition. If the control unit 24 determines that the second drive status does not satisfy the parameter change condition (No in step S62d), it executes the process in step S62f.

[0330] (Step S62e) Next, when the control unit 24 determines that the second drive status satisfies the parameter change condition (Yes in step S62d), it changes the parameters included in the subsequent functional block described above.

[0331] (Step S62f) Then, if the function block following the function block executed in step S62a is the subsequent function block described above, and after the processing in step S62e has been performed, the control unit 24 executes the subsequent function block containing the changed parameters. Also, if the control unit 24 determines in step S62d that the second drive status does not satisfy the parameter change condition (No. in step S62d), it executes the next function block. Here, if the function block following the function block executed in step S62a is the subsequent function block described above, the control unit 24 executes the subsequent function block containing the unchanged parameters.

[0332] Thus, in this embodiment, the function block containing the parameter to be changed does not have to be the function block immediately following the function block in which the termination condition was determined, as long as it is a function block after the function block in which the termination condition was determined. In other words, the function block in which the termination condition was determined is the function block executed in step S62a, which is the first function block described above. The function block containing the parameter to be changed is the second function block described above, and does not have to be the function block immediately following the first function block, as long as it is a function block after the first function block.

[0333] [6.3 Specific Examples] Figure 36 shows an example of parameter changes in this embodiment. In the example in Figure 36, the device 20 is a clothes dryer, but it may be a washing machine or other device as long as it has the function of a clothes dryer.

[0334] The application includes, for example, a drying function block FB61, a blowing function block FB62, and a door lock function block FB63, as shown in Figure 36. The control unit 24 causes the drive unit W to perform drying, then blowing, and then turning off the door lock by executing the function blocks FB61, FB62, and FB63 in that order.

[0335] Here, when the control unit 24 starts executing the function block FB61, the first sensor 25a, which is a timer, for example, detects the drying duration of the clothes drying by the drive unit W according to the function block FB61 as the first driving status. The second sensor 25b detects the internal temperature of the device 20 as the second driving status. In the example of Figure 36, the termination condition is that the drying duration reaches the scheduled completion time of the clothes drying by the drive unit W according to the function block FB61. For example, the scheduled completion time of drying is 1 hour. The parameter change condition is that the internal temperature is above a threshold. The threshold is, for example, 70°C.

[0336] When predetermined conditions are met after the start of execution of function block FB61, the control unit 24 extends the time of air blowing by the drive unit W according to function block FB62 as a parameter of function block FB62. In other words, during the execution of function block FB61, the control unit 24 determines whether the drying duration detected by the first sensor 25a satisfies the termination conditions of function block FB61. Specifically, the control unit 24 determines whether the drying duration has reached the scheduled completion time for drying clothes by the drive unit W according to function block FB61. Then, when the control unit 24 determines that the drying duration satisfies the termination conditions, that is, that the drying duration has reached the scheduled completion time, it determines whether the internal temperature of the device 20 detected by the second sensor 25b at that time satisfies the parameter change conditions. Specifically, the control unit 24 determines whether the internal temperature is 70°C or higher. Then, when the control unit 24 determines that the internal temperature satisfies the parameter change conditions, that is, that the internal temperature is 70°C or higher, it changes the parameters of function block FB62. In other words, the control unit 24 modifies the parameters of function block FB62, which is executed after function block FB61, among the multiple function blocks included in the application. In the example in Figure 36, these parameters are the air blowing time. For example, the control unit 24 modifies these parameters by extending the air blowing time from 5 minutes to 10 minutes. The control unit 24 then controls the drive unit W according to function block FB62, which has the extended air blowing time.

[0337] Thus, in this embodiment, if the internal temperature exceeds a threshold and the drive unit W is activated for the airflow time of the functional block FB62 (e.g., 5 minutes), potentially creating a dangerous situation, the airflow time can be automatically extended from 5 minutes to 10 minutes. The internal temperature of the device 20 varies considerably depending on the amount of clothing placed inside the device 20, making it difficult to pre-set a safe airflow time during application development. However, in this embodiment, the internal temperature is detected during application execution, and the airflow time is extended accordingly, thereby appropriately suppressing the occurrence of dangerous situations. In other words, the internal temperature can be sufficiently reduced by airflow. Note that the parameter to be changed may be the airflow intensity, not the airflow time. In this case, the control unit 24 changes the parameter by increasing the airflow intensity. This also allows the internal temperature to be sufficiently reduced by airflow.

[0338] Figure 37 shows another example of parameter modification in Embodiment 6. In this example of Figure 37, the device 20 is a washing machine.

[0339] The application includes, for example, a stirring function block FB71, a standby function block FB72, and a water supply function block FB73, as shown in Figure 37. The control unit 24 causes the drive unit W to perform stirring, then standby, and then water supply by executing the function blocks FB71, FB72, and FB73 in that order.

[0340] Here, when the control unit 24 starts executing the function block FB71, the first sensor 25a, which is a timer, for example, detects the duration of agitation by the drive unit W according to the function block FB71 as the first drive status. The second sensor 25b detects the rotational speed of agitation as the second drive status. The rotational speed of agitation is, for example, the rotational speed of the washing tub or drum. In the example of Figure 37, the termination condition is that the duration of agitation reaches the scheduled completion time of agitation by the drive unit W according to the function block FB71. For example, the scheduled completion time of agitation is 24 seconds. The parameter change condition is that the rotational speed is above a threshold. The threshold is, for example, 3 rpm.

[0341] When predetermined conditions are met after the start of execution of function block FB71, the control unit 24 extends the waiting time by the drive unit W according to function block FB72 as a parameter of function block FB72. In other words, during the execution of function block FB71, the control unit 24 determines whether the stirring duration detected by the first sensor 25a satisfies the termination conditions of function block FB71. Specifically, the control unit 24 determines whether the stirring duration has reached the scheduled completion time for stirring by the drive unit W according to function block FB71. Then, when the control unit 24 determines that the stirring duration satisfies the termination conditions, i.e., that the stirring duration has reached the scheduled completion time, it determines whether the stirring rotation speed detected by the second sensor 25b at that time satisfies the parameter change conditions. Specifically, the control unit 24 determines whether the stirring rotation speed is 3 rpm or higher. Then, when the control unit 24 determines that the stirring rotation speed satisfies the parameter change conditions, i.e., that the stirring rotation speed is 3 rpm or higher, it changes the parameters of function block FB72. In other words, the control unit 24 modifies the parameters of function block FB72, which is executed after function block FB71, among the multiple function blocks included in the application. In the example in Figure 37, this parameter is the waiting time. For example, the control unit 24 modifies this parameter by extending the waiting time from 1 minute to 3 minutes. Then, the control unit 24 controls the drive unit W according to function block FB72, which has the extended waiting time.

[0342] Thus, in this embodiment, if a hazard could arise if the drive unit W were to operate during the standby time (e.g., 1 minute) of the functional block FB72 at a rotational speed above a threshold, the standby time can be automatically extended from 1 minute to 3 minutes. When the agitation of the functional block FB71 is completed, the washing machine drum may still be rotating due to inertia. Since the rotational speed varies depending on the amount of clothing placed inside the device 20, it can be difficult to pre-set a standby time that does not pose a hazard during application development. However, in this embodiment, if a rotational speed above a threshold is detected even though the agitation of the functional block FB71 has finished, the standby time is extended according to that rotational speed, thereby appropriately suppressing the occurrence of a hazard. In other words, the inertial rotational speed can be sufficiently reduced by the standby time.

[0343] Figure 38 shows yet another example of parameter modification in Embodiment 6. In this example of Figure 38, the device 20 is a rice cooker.

[0344] The application includes, for example, a pre-cooking function block FB81, a final cooking function block FB82, and a boiling function block FB83, as shown in Figure 38. The control unit 24 executes these function blocks in the order of FB81, FB82, and FB83, causing the drive unit W to perform pre-cooking, then final cooking, and then boiling. Pre-cooking is a soaking process in which the rice absorbs water, final cooking is a process in which the rice is heated rapidly to a boiling point over high heat, and boiling is a process in which the rice is kept boiling at an optimal heat level.

[0345] Here, when the control unit 24 starts executing the function block FB81, the first sensor 25a, which is a timer, for example, detects the duration of pre-cooking performed by the drive unit W according to the function block FB81 as the first drive status. The second sensor 25b detects the number of boil-overs as the second drive status. For example, the second sensor 25b has a boil-over sensor that detects boil-overs and a counter that counts the number of boil-overs detected by the boil-over sensor. The boil-over sensor has, for example, a PTC thermistor, and detects the boil-over by the temperature drop caused by contact of boil-over bubbles, etc., with the PTC thermistor. In the example in Figure 38, the termination condition is that the duration of pre-cooking reaches the scheduled completion time of pre-cooking performed by the drive unit W according to the function block FB81. For example, the scheduled completion time of pre-cooking is 30 minutes. The parameter change condition is that the number of boil-overs during pre-cooking is greater than or equal to a threshold. The threshold is, for example, 1 time.

[0346] When predetermined conditions are met after the start of execution of function block FB81, the control unit 24 reduces the heating power of the drive unit W for cooking according to function block FB82 as a parameter of function block FB82. In other words, during the execution of function block FB81, the control unit 24 determines whether the pre-cooking duration detected by the first sensor 25a satisfies the termination conditions of function block FB81. Specifically, the control unit 24 determines whether the pre-cooking duration has reached the scheduled completion time for pre-cooking by the drive unit W according to function block FB81. Then, when the control unit 24 determines that the pre-cooking duration satisfies the termination conditions, that is, that the pre-cooking duration has reached the scheduled completion time, it determines whether the number of boil-overs detected by the second sensor 25b at that time satisfies the parameter change conditions. Specifically, the control unit 24 determines whether the number of boil-overs is one or more. Then, when the control unit 24 determines that the number of boil-overs satisfies the parameter change condition, that is, that the number of boil-overs is one or more, it changes the parameter of the function block FB82. In other words, the control unit 24 changes the parameter of the function block FB82, which is executed after the function block FB81, among the multiple function blocks included in the application. In the example in Figure 38, that parameter is the cooking heat. For example, the control unit 24 changes this parameter by lowering the cooking heat from 10 to 6. Then, the control unit 24 controls the drive unit W according to the function block FB82 which has the reduced heat. The heat used as a parameter is represented by an integer from 0 to 10, for example, with larger numbers indicating stronger heat.

[0347] Thus, in this embodiment, if the number of boil-overs exceeds a threshold and driving the drive unit W with the heating power of the functional block FB82 (for example, 10) could create a dangerous situation, the heating power can be automatically reduced from 10 to 6. The number of boil-overs varies considerably depending on the amount of rice and water placed inside the device 20, as well as their temperatures. Therefore, it can be difficult to pre-set a heating power that does not create a dangerous situation during application development. However, in this embodiment, if a number of boil-overs exceeding a threshold is detected, the heating power is reduced according to that number of boil-overs, thereby appropriately suppressing the occurrence of dangerous situations.

[0348] Furthermore, if predetermined conditions are met after the start of execution of function block FB82, the control unit 24 may reduce the boiling heat of the drive unit W according to function block FB83 as a parameter of function block FB83. In other words, during the execution of function block FB82, the control unit 24 determines whether the cooking duration detected by the first sensor 25a satisfies the termination conditions of function block FB82. Specifically, the control unit 24 determines whether the cooking duration has reached the scheduled completion time of cooking by the drive unit W according to function block FB82. Then, if the control unit 24 determines that the cooking duration satisfies the termination conditions, that is, that the cooking duration has reached the scheduled completion time, it determines whether the number of boil-overs detected by the second sensor 25b at that time satisfies the parameter change conditions. Specifically, the control unit 24 determines whether the number of boil-overs during cooking is one or more. Then, when the control unit 24 determines that the number of boil-overs satisfies the parameter change condition, that is, that the number of boil-overs is one or more, it changes the parameter of the function block FB83. In other words, the control unit 24 changes the parameter of the function block FB83, which is executed after the function block FB82, among the multiple function blocks included in the application. In the example in Figure 38, that parameter is the boiling heat level. For example, the control unit 24 changes this parameter by lowering the boiling heat level from 8 to 5. Then, the control unit 24 controls the drive unit W according to the function block FB83 which has the lowered heat level.

[0349] Therefore, the parameters of the heating element can be automatically changed between functional block FB82 and functional block FB83, just as they can be changed between functional block FB81 and functional block FB82, thereby appropriately suppressing the occurrence of hazards.

[0350] Figure 39 shows yet another example of parameter changes in Embodiment 6. In this example of Figure 39, the device 20 is an oven, but it may be a microwave oven or other device as long as it has the function of an oven.

[0351] The application includes, for example, a grilling function block FB91 and another grilling function block FB92, as shown in Figure 39. The control unit 24 causes the drive unit W to perform grilling in a first mode and then in a second mode by executing the function blocks FB91 and FB92 in that order. The first mode and the second mode may be the same or different. Grilling is the process of grilling food placed inside the device 20 using a heater.

[0352] Here, when the control unit 24 starts executing the function block FB91, the first sensor 25a, which is a timer, for example, detects the duration of the baking process performed by the drive unit W according to the function block FB91 as the first drive status. The second sensor 25b detects the internal temperature of the device 20 as the second drive status. The internal temperature is the internal temperature of the device 20. In the example of Figure 39, the termination condition is that the baking duration reaches the scheduled completion time of the baking process performed by the drive unit W according to the function block FB91. For example, the scheduled completion time of the baking process is 40 minutes. The scheduled completion time is also called the execution time. The parameter change condition is that the difference between the scheduled temperature rise caused by the baking process of the food by the drive unit W according to the function block FB92 and the limit temperature of the device 20 is less than or equal to the internal temperature. For example, the scheduled temperature rise is 60°C and the limit temperature is 250°C. The difference between the scheduled temperature rise and the limit temperature mentioned above is also called the differential temperature.

[0353] When predetermined conditions are met after the start of execution of the functional block FB91, the control unit 24 shortens the time (i.e., execution time) of the baking process by the drive unit W according to the functional block FB92 as a parameter of the functional block FB92. In other words, during the execution of the functional block FB91, the control unit 24 determines whether the baking duration detected by the first sensor 25a satisfies the termination conditions of the functional block FB91. Specifically, the control unit 24 determines whether the baking duration has reached the scheduled completion time of the baking process by the drive unit W according to the functional block FB91. Then, when the control unit 24 determines that the baking duration satisfies the termination conditions, i.e., that the baking duration has reached the scheduled completion time, it determines whether the internal temperature detected by the second sensor 25b at that time satisfies the parameter change conditions. Specifically, the control unit 24 determines whether the internal temperature is equal to or greater than the difference temperature. Then, when the control unit 24 determines that the internal temperature satisfies the parameter change conditions, i.e., that the internal temperature is equal to or greater than the difference temperature, it changes the parameters of the functional block FB92. In other words, the control unit 24 modifies the parameters of function block FB92, which is executed after function block FB91, among the multiple function blocks included in the application. In the example in Figure 39, these parameters are the scheduled completion time (i.e., execution time) of the baking process. For example, the control unit 24 modifies these parameters by reducing the execution time from 40 minutes to 20 minutes. The control unit 24 then controls the drive unit W according to function block FB92, which has the shortened execution time.

[0354] Thus, in this embodiment, if the internal temperature of the oven is above the differential temperature and the drive unit W is driven for the baking time of the functional block FB92 (for example, 40 minutes), a dangerous situation may arise, the baking time can be automatically shortened from 40 minutes to 20 minutes. Since the internal temperature varies considerably depending on the food or environment placed inside the device 20, it can be difficult to pre-set a baking time that will not cause danger during application development. Furthermore, if the internal temperature is above the differential temperature at the end of the baking process of the functional block FB91, the internal temperature of the functional block FB92 may reach above the limit temperature during its baking process. However, in this embodiment, the internal temperature is detected during application execution, and the baking time of the functional block FB92 is shortened according to that internal temperature, thereby appropriately suppressing the occurrence of danger.

[0355] [6.4 Effects, etc.] As described above, the device 20, which is a drive device in this embodiment, comprises a drive unit W including at least one actuator 22 and a heater 23, a control unit 24 that acquires an application including a plurality of functional blocks and executes the application to control the drive unit W according to the plurality of functional blocks, a first sensor 25a that detects a first drive status of the drive unit W, and a second sensor 25b that detects a second drive status of the drive unit W. Each of the plurality of functional blocks has parameters used for controlling the drive unit W by the functional block and termination conditions for driving the drive unit W by the functional block. When the first drive status detected by the first sensor 25a is executed during the execution of the first functional block among the plurality of functional blocks and the second drive status detected by the second sensor 25b is satisfied with the parameter change conditions, the control unit 24 changes the parameters of the second functional block which is executed after the first functional block among the plurality of functional blocks, and controls the drive unit W according to the second functional block which has the changed parameters.

[0356] According to this, the drive unit W can be controlled based on applications defined by multiple functional blocks. Therefore, it becomes possible to develop applications using blocks that abstract the control of the device 20, allowing not only the manufacturer but also third parties to develop a wide variety of applications, and these applications can be easily executed on the device 20.

[0357] Furthermore, when the drive unit W is finished driving according to the first functional block, if the second driving state satisfies the parameter change condition, the parameters of the second functional block following the first functional block are changed. Then, the drive unit W is controlled according to the second functional block having the changed parameters. This allows the parameters to be automatically changed if, in the second driving state of the drive unit W, driving the drive unit W with the parameters of the second functional block could cause danger. Since this second driving state varies considerably depending on how the user uses the device 20, it can be difficult to set parameters that do not cause danger in advance during application development. However, in this embodiment, the second driving state is detected during application execution, and the parameters are changed according to that second driving state, so the occurrence of danger can be appropriately suppressed. As a result, even when acquiring a wide variety of applications and controlling the drive unit W according to those applications, the safety of the device 20 controlled by those applications can be guaranteed and its safety can be improved.

[0358] Furthermore, in this embodiment, the first drive status detected by the first sensor 25a is the drive duration spent driving the drive unit W according to the first functional block.

[0359] According to this, by comparing the duration of the drive with the scheduled completion time of the first functional block, it is possible to appropriately determine whether the first drive state satisfies the termination condition, that is, whether the drive of the drive unit W according to the first functional block has ended.

[0360] In this embodiment, the second drive status detected by the second sensor 25b is the temperature, rotational speed, or number of times spillage occurs due to the drive of the drive unit W.

[0361] According to this, it is possible to appropriately determine whether or not to change the parameters of the second functional block based on the second driving condition related to the safety of the device 20.

[0362] Furthermore, in this embodiment, the parameter of the second functional block is the duration for which the drive unit W is driven, or the temperature or heat generated by the drive unit W.

[0363] According to this, safety-related parameters of the device 20 can be changed, and safety can be appropriately improved.

[0364] Furthermore, in this embodiment, for example, the device 20 is a clothes dryer. In this case, the first sensor 25a detects the drying duration of the clothes being dried by the drive unit W according to the first functional block as the first driving status, and the second sensor 25b detects the internal temperature of the device 20 as the second driving status. The termination condition is that the drying duration reaches the scheduled completion time for drying clothes by the drive unit W, and the parameter change condition is that the internal temperature is above a threshold. In such cases, the control unit 24 extends the time of air blowing by the drive unit W according to the second functional block as a parameter when changing the parameter.

[0365] According to this, if the internal temperature exceeds a threshold and the drive unit W is driven for the same duration as the second functional block's airflow time, a hazard could arise, the airflow time can be automatically extended. The internal temperature of the device 20 varies considerably depending on the amount of clothing placed inside, making it difficult to pre-set a safe airflow time during application development. However, in this embodiment, the internal temperature is detected during application execution, and the airflow time is extended accordingly, thereby appropriately suppressing the occurrence of hazards. As a result, even when acquiring a wide variety of applications and controlling the drive unit W according to those applications, the safety of the device 20 controlled by those applications can be ensured and its safety improved.

[0366] Furthermore, in this embodiment, for example, the device 20 is a washing machine. In this case, the first sensor 25a detects the duration of agitation by the drive unit W according to the first functional block as the first drive status, and the second sensor 25b detects the rotational speed of the agitation as the second drive status. The termination condition is that the agitation duration reaches the scheduled completion time of agitation by the drive unit W, and the parameter change condition is that the rotational speed is above a threshold. In such cases, when changing parameters, the control unit 24 extends the waiting time by the drive unit W according to the second functional block as a parameter.

[0367] According to this, if the drive unit W were to operate during the standby time of the second functional block at a rotation speed above a threshold, a hazard could arise, and the standby time can be automatically extended. When the agitation of the first functional block is completed, the washing machine drum may still be rotating due to inertia. Since the rotation speed varies considerably depending on the amount of clothing placed inside the device 20, it can be difficult to pre-set a standby time that does not pose a hazard during application development. However, in this embodiment, if a rotation speed above a threshold is detected even though the agitation of the first functional block has been completed, the standby time is extended according to that rotation speed, thereby appropriately suppressing the occurrence of hazards. As a result, even when acquiring a wide variety of applications and controlling the drive unit W according to those applications, the safety of the device 20 controlled by those applications can be guaranteed and its safety can be improved.

[0368] Furthermore, in this embodiment, for example, the device 20 is a rice cooker. In this case, the first sensor 25a detects the duration of pre-cooking performed by the drive unit W according to the first functional block as the first drive status, and the second sensor 25b detects the number of times the device 20 boils over as the second drive status. The termination condition is that the duration of pre-cooking reaches the scheduled completion time of pre-cooking by the drive unit W, and the parameter change condition is that the number of boil-overs is greater than or equal to a threshold. In such cases, the control unit 24, in changing the parameters, lowers the heating power of the cooking by the drive unit W according to the second functional block as a parameter.

[0369] According to this, if the number of boil-overs exceeds a threshold, and driving the drive unit W with the cooking heat of the second functional block could create a dangerous situation, the heat can be automatically reduced. The number of boil-overs varies considerably depending on the amount of rice and water placed inside the device 20, as well as their temperatures. Therefore, it can be difficult to pre-set a heat level that does not create a dangerous situation during application development. However, in this embodiment, if a boil-over exceeding a threshold is detected, the heat is reduced according to the number of boil-overs, thereby appropriately suppressing the occurrence of dangerous situations. As a result, even when acquiring a wide variety of applications and controlling the drive unit W according to those applications, the safety of the device 20 controlled by those applications can be ensured, and its safety can be improved.

[0370] In this embodiment, for example, the device 20 is an oven. In this case, the first sensor 25a detects the duration of the baking process of the food by the drive unit W according to the first functional block as the first driving status, and the second sensor 25b detects the internal temperature of the device 20 as the second driving status. The termination condition is that the baking duration reaches the scheduled completion time of the baking process by the drive unit W, and the parameter change condition is that the difference between the scheduled temperature rise caused by the baking process of the food by the drive unit W according to the second functional block and the limit temperature of the device 20 is less than or equal to the internal temperature. In such a case, the control unit 24 shortens the time of the baking process of the food by the drive unit W according to the second functional block as a parameter when changing the parameter.

[0371] According to this, if the internal temperature exceeds a threshold and the drive unit W is driven for the baking time of the second functional block, a hazard could arise, the baking time can be automatically shortened. The internal temperature of the device 20 varies considerably depending on the food or environment placed inside the device 20, making it difficult to pre-set a baking time that does not pose a hazard during application development. However, in this embodiment, the internal temperature is detected during application execution, and the baking time is shortened accordingly, thereby appropriately suppressing the occurrence of hazards. As a result, even when acquiring a wide variety of applications and controlling the drive unit W according to those applications, the safety of the device 20 controlled by those applications can be ensured and its safety improved.

[0372] In this embodiment, the first sensor 25a is a timer, but it may be a sensor other than a timer. For example, if the device 20 is an oven, the first sensor 25a may be a temperature sensor that detects the internal temperature as the first driving condition. In this case, the internal temperature detected by the first sensor 25a satisfies the termination condition of the first functional block when the internal temperature reaches the target temperature. At this time, the control unit 24 determines whether the second driving condition detected by the second sensor 25b satisfies the parameter change condition. Similarly, the first sensor 25a may detect the rotational speed of stirring as the first driving condition.

[0373] Furthermore, in this embodiment, if the device 20 is a washing machine, the second sensor 25b may detect weight balance as a second driving condition. In other words, the second sensor 25b may detect uneven distribution of clothes placed in the washing machine. In this case, the control unit 24 may change the parameters of the subsequent functional blocks according to the uneven distribution of the clothes.

[0374] Furthermore, the parameter change conditions in this embodiment may also be used in the rules of embodiments 1 to 5. In other words, the rule specifies that if the second drive status detected by the second sensor 25b satisfies the parameter change conditions, then it is necessary to change the parameters of the second functional block. The control unit 24 changes the parameters according to that rule.

[0375] Furthermore, the parameter change conditions in this embodiment may include a function or table for deriving the changed parameter from the parameter before the change. For example, the function may be a mathematical formula that derives 110% or 90% of the numerical value of the parameter before the change as the changed parameter.

[0376] (Other embodiments) Although a system relating to one or more embodiments of this disclosure has been described above based on embodiments, this disclosure is not limited to these embodiments. Without departing from the spirit of this disclosure, various modifications to these embodiments that a person skilled in the art could conceive of, or forms constructed by combining components from different embodiments, may also be included within the scope of one or more embodiments of this disclosure.

[0377] Furthermore, in each of the above embodiments, the sequence manager 100 and the device manager 200 were included in the cloud server 10, but are not limited to this. The sequence manager 100 and / or the device manager 200 may be included in the device 20. Also, the UI 400 was included in the terminal 30, but may be included in the device 20.

[0378] Furthermore, in each of the above embodiments, the application may be modified based on the degradation information. For example, device 300 may refer to parameter conversion information, which associates a plurality of degradation levels with a plurality of parameter conversion methods, to obtain a conversion method corresponding to a degradation level, and use the obtained conversion method to convert the parameters included in the block. The conversion method may be defined, for example, by the converted value, or by a coefficient applied to the value before conversion.

[0379] Furthermore, in each of the above embodiments, the block was modified if the parameter was within an unacceptable range during pre-execution verification, and the block was then executed; however, this is not the only way. For example, if the parameter is within an unacceptable range and the state of device 300 is different from what was expected, the block may not be executed, and the device manager 200 and / or sequence manager 100 may be notified of execution abort (error). [Industrial applicability]

[0380] It can be used in home appliances that can execute applications defined by multiple functional blocks, and in devices that generate such applications. [Explanation of symbols]

[0381] 1 System 2a, 2b, 2c, 2d facilities 10 Cloud Servers 11 processors 12, 26, 52 memory 20, 20a, 20b, 20c, 20d, 20e, 20f, 20g, 20h equipment 21 cabinets 22 Actuators 23 Heater 24 Control Unit 25a First sensor 25b Second sensor Terminals 30, 30a, 30b, 30c, 30d 31 displays 32 Input Devices 41 Block Databases 42, 1300, 1300C Rule Database 50 Development Tools 51 processors 53 displays 54 Input section 60 application delivery servers 100 Sequence Manager 200 Device Manager 300, 300a, 300b, 300c, 300d, 300e, 300f, 300g, 300h devices 400, 400a, 400b, 400c, 400d UI 1000, 1201 blocks Parameters 1001, 1002, 1003, 1004, 1005, 1006 1100 Device Database 1101 Device Information 1200 Declaration of Execution Content 1202 Device Information 1203 Order Information 1301, 1301C, 1302, 1302C, 1303C, 1304C Rules 2000 Information Processing Systems D1 Parameter setting area D2 Block List Area D3 Target device area D4 Selected block area E1-E3 Error Messages F100 Preparation Phase F200 App Execution Pre-Phase F300 Application Execution Phase FB61-63, FB71-73, FB81-83, FB91-92 Functional Blocks Rules specific to R11-R13, R21-R23, R31-R33, and R41-R43. R100, R200, R300, R400 General Rules W drive unit

Claims

1. A drive unit including at least one actuator and a heater, A control unit that obtains an application containing multiple blocks and executes the application, thereby controlling the drive unit according to the multiple blocks, A first sensor for detecting the first driving status of the drive unit, A drive device comprising a second sensor for detecting the second driving status of the drive unit, Each of the aforementioned plurality of blocks has parameters used for controlling the drive unit by the block, and conditions for terminating the drive of the drive unit by the block. The control unit, If, during the execution of the first block among the plurality of blocks, the first drive status detected by the first sensor satisfies the termination condition of the first block, and the second drive status detected by the second sensor satisfies the parameter change condition, Of the plurality of blocks, the parameters of the second block, which is executed after the first block and has different control or parameters from the first block, are changed. The drive unit is controlled according to the second block having the modified parameters, The parameter change conditions are related to the situation in which, when the second block is executed in the second driving state, the safety of the drive unit is affected. The parameter of the second block is the duration for which the drive unit continues to drive the drive device in accordance with the second block, or the temperature or heat generated by the drive unit's operation. Drive unit.

2. The first drive status detected by the first sensor is the drive duration of the drive unit according to the first block. The drive device according to claim 1.

3. The second drive condition detected by the second sensor is the temperature, rotation speed, or number of spills caused by the drive unit. The drive device according to claim 1 or 2.

4. A drive unit including at least one actuator and a heater, A control unit that obtains an application containing multiple blocks and executes the application, thereby controlling the drive unit according to the multiple blocks, A first sensor for detecting the first driving status of the drive unit, A drive device comprising a second sensor for detecting the second driving status of the drive unit, Each of the aforementioned plurality of blocks has parameters used for controlling the drive unit by the block, and conditions for terminating the drive of the drive unit by the block. The control unit, If, during the execution of the first block among the plurality of blocks, the first drive status detected by the first sensor satisfies the termination condition of the first block, and the second drive status detected by the second sensor satisfies the parameter change condition, Of the aforementioned plurality of blocks, the parameters of the second block which is executed after the first block are changed, The drive unit is controlled according to the second block having the modified parameters, The aforementioned drive device is a clothes dryer, The first sensor detects the drying time taken for the clothes to dry by the drive unit according to the first block as the first drive status, The second sensor detects the internal temperature of the drive unit as the second driving condition, The termination condition is that the drying duration reaches the scheduled completion time for drying the clothes by the drive unit. The parameter change condition is that the internal temperature is above a threshold. The control unit, In the modification of the aforementioned parameter, the time of airflow by the drive unit according to the second block is extended as the parameter. Drive unit.

5. A drive unit including at least one actuator and a heater, A control unit that obtains an application containing multiple blocks and executes the application, thereby controlling the drive unit according to the multiple blocks, A first sensor for detecting the first driving status of the drive unit, A drive device comprising a second sensor for detecting the second driving status of the drive unit, Each of the aforementioned plurality of blocks is used to control the drive unit by that block. The block comprises parameters and conditions for ending the drive of the drive unit. The control unit, If, during the execution of the first block among the plurality of blocks, the first drive status detected by the first sensor satisfies the termination condition of the first block, and the second drive status detected by the second sensor satisfies the parameter change condition, Of the aforementioned plurality of blocks, the parameters of the second block which is executed after the first block are changed, The drive unit is controlled according to the second block having the modified parameters, The aforementioned drive device is a rice cooker, The first sensor detects the duration of pre-heating performed by the drive unit according to the first block as the first drive status, The second sensor detects the number of times spillage occurs from the drive unit as the second drive status. The termination condition is that the pre-heating duration reaches the scheduled completion time of the pre-heating by the drive unit. The parameter change condition is that the number of times the boil-over occurs is equal to or greater than a threshold. The control unit, In the aforementioned parameter change, the heating power of the drive unit according to the second block is reduced as the parameter. Drive unit.

6. A drive unit including at least one actuator and a heater, A control unit that obtains an application containing multiple blocks and executes the application, thereby controlling the drive unit according to the multiple blocks, A first sensor for detecting the first driving status of the drive unit, A drive device comprising a second sensor for detecting the second driving status of the drive unit, Each of the aforementioned plurality of blocks has parameters used for controlling the drive unit by the block, and conditions for terminating the drive of the drive unit by the block. The control unit, If, during the execution of the first block among the plurality of blocks, the first drive status detected by the first sensor satisfies the termination condition of the first block, and the second drive status detected by the second sensor satisfies the parameter change condition, Of the aforementioned plurality of blocks, the parameters of the second block which is executed after the first block are changed, The drive unit is controlled according to the second block having the modified parameters, The aforementioned drive device, oven, The first sensor detects the duration of the grilling process of the food by the drive unit according to the first block as the first drive status, The second sensor detects the internal temperature of the drive unit as the second driving condition, The termination condition is that the burning duration reaches the scheduled completion time of the burning process by the drive unit. The parameter change condition is that the difference between the expected temperature rise caused by the grilling process of the food by the drive unit according to the second block and the limit temperature of the drive unit is less than or equal to the internal temperature. The control unit, The change in the aforementioned parameter shortens the time for the food to be grilled by the drive unit according to the second block, as the parameter. Drive unit.

7. A method for driving a drive device performed by a computer, The drive device is A drive unit including at least one actuator and a heater, A first sensor for detecting the first driving status of the drive unit, The drive unit is further equipped with a second sensor for detecting the second driving status of the drive unit, The aforementioned drive method is Get an application that contains multiple blocks, By executing the aforementioned application, the drive unit is controlled according to the plurality of blocks, Each of the aforementioned plurality of blocks has parameters used for controlling the drive unit by the block, and conditions for terminating the drive of the drive unit by the block. During the execution of the aforementioned application, If, during the execution of the first block among the plurality of blocks, the first drive status detected by the first sensor satisfies the termination condition of the first block, and the second drive status detected by the second sensor satisfies the parameter change condition, Of the plurality of blocks, the parameters of the second block, which is executed after the first block and has different control or parameters from the first block, are changed. The drive unit is controlled according to the second block having the modified parameters, The parameter change conditions are related to the situation in which, when the second block is executed in the second driving state, the safety of the drive unit is affected. The parameter of the second block is the duration for which the drive unit continues to drive the drive device in accordance with the second block, or the temperature or heat generated by the drive unit's operation. Driving method.

8. A program for a drive unit, The drive device is A drive unit including at least one actuator and a heater, A first sensor for detecting the first driving status of the drive unit, A second sensor for detecting the second driving status of the drive unit, Equipped with a computer, The aforementioned program, Get an application that contains multiple blocks, By executing the aforementioned application, the computer is made to control the drive unit according to the plurality of blocks, Each of the aforementioned plurality of blocks has parameters used for controlling the drive unit by the block, and conditions for terminating the drive of the drive unit by the block. During the execution of the aforementioned application, If, during the execution of the first block among the plurality of blocks, the first drive status detected by the first sensor satisfies the termination condition of the first block, and the second drive status detected by the second sensor satisfies the parameter change condition, Of the plurality of blocks, the parameters of the second block, which is executed after the first block and has different control or parameters from the first block, are changed. The drive unit is controlled according to the second block having the modified parameters. death, The parameter change conditions are related to the situation in which, when the second block is executed in the second driving state, the safety of the drive unit is affected. The parameter of the second block is the duration for which the drive unit continues to drive the drive device in accordance with the second block, or the temperature or heat generated by the drive unit's operation. program.

Images