WO2023195521A1 - Distributed processing system - Google Patents

Abstract

This distributed processing system comprises an SDI device equipped with a sensor, and a plurality of MDI devices that are capable of communicating with each other. Data measured by the SDI device is sent to one of the MDI devices. If said MDI device is capable of executing a task corresponding to said data, said MDI device carries out processing itself; if necessary, the execution may also be left to another MDI device.

Description

distributed processing system

The present invention relates to a technique for distributing tasks to multiple computing resources.

With the advancement of AI (Artificial Intelligence) and IoT (Internet of Things) related technologies, a wide variety of electronic devices are becoming intelligent and becoming networked. Many electronic devices have computational resources such as a CPU (Central Processing Unit), memory, and software in order to execute specific software.

Electronic devices sometimes entrust part of the calculation processing to the cloud. For example, in a face authentication system, an electronic device serving as a face authentication device may transmit a facial image to an external server, the server may execute face authentication processing, and return the execution result to the face authentication device.

Patent No. 6699653 JP2021-60742A

In order to handle the processing generated by various electronic devices, it is thought that the number of servers in clouds (data centers) and the computing power of electronic devices will increase in the future.

However, the computational resources of many electronic devices, including servers, are not always used. For example, the operating rate of an automobile is said to be about 4 (%), and the high-performance CPU installed in the automobile is in an idle state most of the time.

The present invention was completed based on the recognition of the above problem, and its main purpose is to provide a technology for efficiently responding to various computational needs by effectively utilizing existing computational resources. There is a particular thing.

A distributed processing system in an aspect of the present invention includes a first computing device equipped with a sensor and a plurality of second computing devices capable of communicating with each other.
The first computing device includes a sensing unit that acquires data from the outside using a sensor, a data transmitting unit that transmits the acquired data to one or more second computing devices, and one or more tasks corresponding to the acquired data. and an output unit that outputs the execution results of one or more tasks.
The second computing device includes a data receiving unit that receives data from the first computing device, a task execution unit that executes a task using the received data, and a task execution unit that executes the task together with the received data. A task requesting section that requests a task to be executed, a result receiving section that receives a task execution result from another computing device, and a result transmitting section that transmits the task execution result to the other computing device.

A distributed processing system according to another aspect of the present invention includes a first computing device equipped with a sensor, a plurality of second computing devices capable of communicating with each other, and a plurality of third computing devices capable of communicating with each other. .
The computing power of the third computing device is greater than the computing capability of the second computing device.
The first computing device transmits data acquired by the sensor to any second computing device. The second computing device identifies one or more tasks that process the received data, and determines whether the second computing device or the third computing device is the main entity for executing the task based on the identified tasks or the data to be processed. At the same time, the computer instructs the selected computing device to execute the specified task.

A distributed processing system in another aspect of the invention includes multiple types of mobile devices that can communicate with each other.
The first mobile device includes a sensor, a sensing unit that acquires data from the outside using the sensor, and a data transmission unit that transmits the acquired data to another mobile device.
The second mobile device includes a data reception unit that receives data from another mobile device, an execution determination unit that determines whether or not a task can be executed based on the data received from the other mobile device, and a data receiving unit that receives data from the other mobile device. The mobile device further includes a task execution unit that executes a task based on the mobile device, and a data transmission unit that further transmits data received from another mobile device to the other mobile device.
The execution determination section of the second mobile device instructs the task execution section to execute the task when the second mobile device satisfies the execution condition, and instructs the second mobile device to transmit data to another mobile device when the execution condition is not satisfied.

A distributed processing system according to another aspect of the present invention is a device configured as social infrastructure equipment configured to be able to communicate with each other, and includes a plurality of computing devices equipped with a processor along with both or one of a sensor and an output device. Be prepared.
The computing device has a data receiving unit that receives data from a mobile terminal or other computing device owned by a user, and a task that executes subtasks corresponding to the received data in parallel with the main task as a social infrastructure facility. an execution unit, a task requesting unit that requests another computing device to execute a subtask corresponding to the received data, a result receiving unit that receives the execution result of the subtask from the other computing device, and a carrying unit that carries the execution result of the subtask. It includes a result transmitting unit that transmits to a terminal or other computing device, and an execution determining unit that determines whether or not the subtask can be executed in the own device.
The execution determining unit instructs the task execution unit to execute the subtask when the own device satisfies the execution conditions for the subtask, and instructs the task requesting unit to request the subtask to another computing device when the execution conditions are not satisfied.

According to the present invention, it becomes easier to efficiently respond to various computational needs.

1 is a conceptual diagram of a task distribution system. FIG. 1 is a conceptual diagram of a distributed processing system. FIG. 2 is a conceptual diagram showing the relationship between requesting and executing tasks. FIG. 1 is a conceptual diagram of a distributed processing system in a first embodiment. FIG. 2 is a hardware configuration diagram of an SDI device. FIG. 2 is a functional block diagram of an SDI device. FIG. 2 is a functional block diagram of an MDI device and an LDI device. It is a data structure diagram of request condition information. It is a data structure diagram of underwriting condition information. 3 is a flowchart showing a processing process for allocating subtasks. 3 is a flowchart showing a processing process when an MDI device receives request data from another device. 3 is a flowchart showing a processing process when an LDI device receives request data from another device. It is a data structure diagram of payment information. FIG. 2 is a conceptual diagram of a distributed processing system in a second embodiment. It is a functional block diagram of a robot. FIG. 3 is a data structure diagram of service definition information. It is a flowchart showing a processing process when a robot receives request data. It is a flowchart which shows the processing process when a robot receives service instruction information. FIG. 3 is a conceptual diagram of a distributed processing system in a third embodiment. FIG. 2 is a functional block diagram of a surveillance camera. 3 is a flowchart showing a processing process when the MDI device receives request data. FIG. 2 is a schematic diagram for explaining a method of distributing subtasks from an LDI device. FIG. 7 is a schematic diagram for explaining a method of determining whether a subtask can be executed in a modified example.

FIG. 1 is a conceptual diagram of a task distribution system 201.
The server receives various processing requests from a large number of client terminals. In this embodiment, the server receives a face image (hereinafter referred to as a "verification image") and a face image to be compared with this face image (hereinafter referred to as a "reference image") from a client terminal. The client terminal compares the verification image (face image) obtained from the surveillance camera with a pre-registered reference image and determines whether the person shown in the reference image and the person shown in the verification image are the same person. Requests the server the task of determining whether or not the

The server sends a dataset including the reference image and the verification image to the task distribution device 101. The task distribution device 101 is capable of communicating with a plurality of electronic devices Em (m: natural number). Electronic devices here include cars such as EVs (Electric Vehicles), smartphones, PCs (Personal Computers), other servers, secondary batteries, etc., and processors with arithmetic functions such as CPUs or GPUs (Graphics Processing Units). , a memory with a storage function, and a device with a communication function. As described above, in this embodiment, the storage function, communication function, and calculation function are collectively referred to as "computing resources."

The electronic device in this embodiment is equipped with a "DI (Digital Intelligence) engine." The DI engine may be configured as an IC (Integrated Circuit) chip with communication and calculation functions and lightweight software, or may be configured as dedicated software executed in a processor of an electronic device.

Note that in this embodiment, a secondary battery equipped with calculation resources such as a CPU is also assumed as an electronic device that accesses the task distribution device 101, but details will be described later.

An electronic device is an existing device that performs processing for a specific purpose. For example, the EV's computational resources run software to perform the calculations necessary for the operation of the EV. The task distribution device 101 allows the electronic device to execute tasks generated in the server on behalf of the electronic device by borrowing the computational resources of such an existing electronic device.

The task distribution device 101 sends a load confirmation request to each electronic device when a task occurs in the server or periodically. The task distribution device 101 may multicast the load confirmation request. It is assumed that the electronic device in this embodiment can execute a finite number of threads. When the DI engine of the electronic device receives the load confirmation request, the DI engine of the electronic device returns the available threads of the electronic device, or in other words, the remaining calculation capacity, to the task distribution device 101. For example, the electronic device E1 can execute 10 threads simultaneously, and when 3 threads (tasks) are already running, there are 7 free threads (threads that can be allocated for new tasks). This is notified to the task distribution device 100. The electronic device E2 can execute 30 threads simultaneously, and when 17 threads are already running, it notifies the task distribution device 101 that there are 13 free threads (=30-17).

The task distribution device 101 registers the number of free threads for each electronic device that has responded to the load confirmation request as "load information." The task distribution device 101 refers to the load information and assigns a task to the electronic device with the largest number of free threads, in other words, the electronic device with the largest computational capacity by transmitting a data set including a reference image and a verification image. request.

The electronic device may maintain a spare thread in order to respond to requests for proxy execution of tasks. In this case, even in a situation where all the electronic devices are already using a large number of threads, it becomes easier to more reliably request other electronic devices to perform tasks that occur in the originating device. For example, electronic device Ex is capable of executing 12 threads, but uses only up to 10 threads for its own processing. When the electronic device Ex uses three threads, it reports to the task distribution device 101 that the number of free threads is 9 (=12-3). On the other hand, even when the electronic device Ex is using the maximum ten threads, two spare threads can be used. Therefore, even when the electronic device Ex has used up its own upper limit of 10 threads, it can still have some remaining capacity to respond to task processing requests from the task distribution device 101.

A program for determining the degree of similarity between two types of images (hereinafter referred to as a "similarity determination program") is registered in advance in the electronic device. The DI engine of the electronic device that receives the task loads a similarity determination program and causes the similarity between the reference image and the verification image to be determined. After completing the processing, the DI engine notifies the task distribution device 100 of the degree of similarity as a processing result. The task distribution device 101 returns the degree of similarity to the server, and the server returns the degree of similarity to the client terminal.

According to this embodiment, a group of existing electronic devices becomes, so to speak, an instant data center. When a task occurs in a server, the task distribution device 101 can utilize idle computing resources by selecting a task requestee from among a plurality of electronic devices.

Hereinafter, a device that requests a task, such as the server shown in FIG. 1, will be referred to as a "starting point device." The starting point device is not limited to a server. Other electronic devices such as a smartphone or a PC may serve as the starting point device. When a task occurs, the originating device requests the task distribution device 101, and the task distribution device 101 selects an electronic device from among a plurality of electronic devices to execute the task. In this embodiment, the origin device and the task distribution device 101 are described as separate devices, but even if the origin device has the function of the task distribution device 101 (hereinafter referred to as "task distribution function"), good.

Multiple types of programs corresponding to multiple types of tasks may be registered in advance in the electronic device. Each program (hereinafter referred to as a "task handler") is identified by a handle ID. The origin device may have only data that becomes a variable for the task handler. The variable here may be any data such as images, sounds, and numerical values.

For example, when it is desired to execute task A based on variable X1, the origin device passes the handle ID of task A and variable X1 to the task distribution device 101. The task distribution device 101 selects an electronic device as a request destination and passes the handle ID and variable X1. The DI engine of the requested electronic device starts the task handler HA corresponding to the task A according to the specified handle ID and sets the variable X1, thereby causing the task handler HA to execute the task A.

In car parking lots, many car computing resources are idle. Therefore, by bringing the starting point device and the task distribution device 101 into the parking lot, it is possible to efficiently process a large number of tasks using the computational resources of many cars. Therefore, parking lots can become large-scale data centers.

In the future, it is thought that the number of secondary batteries equipped with computing resources such as CPUs will increase. For example, a BMS (Battery Management System) measures the cell voltage, temperature, etc. of a secondary battery, and controls the voltage and current when charging the secondary battery. Based on the processing results of the BMS, the secondary battery may be required to have more advanced functions such as measuring or estimating the degree of deterioration of the secondary battery and diagnosing abnormalities. Alternatively, a secondary battery may be installed as standard in electronic devices that function as edge AI. In this way, if secondary batteries become intelligent by being equipped with advanced computational resources, the secondary batteries themselves can also be requested for tasks.

The task distribution device 101 may periodically transmit load confirmation requests to nearby electronic devices and update load information that associates electronic devices with their load information. More specifically, the task distribution device 101 registers and updates the electronic device ID, address, confirmation time, communication time required from confirmation to response, and number of free threads as load information.

When selecting a task request destination, the task distribution device 101 may consider not only the load situation but also the communication time. The communication time here is the time from when the task distribution device 101 sends a load confirmation request until it receives a response from the electronic device. For example, the evaluation value of each electronic device is calculated based on an arbitrary evaluation function that monotonically increases for both variable V1, which is set to increase as the communication time becomes shorter, and variable V2, which indicates the number of free threads. do. The task distribution device 101 may select the electronic device with the largest evaluation value thus calculated as the task request destination.

The task distribution device 101 may exclude from request destinations electronic devices that have not responded to the load confirmation request or whose communication time has exceeded a predetermined time. When a request destination is not found, the task distribution device 101 itself may execute the task.

The task distribution device 101 is an electronic device connected to the task distribution device 101 by wire, or an electronic device capable of short-range wireless communication with the task distribution device 101, such as Wi-Fi, Li-Fi, or Bluetooth (registered trademark). You may request tasks on a priority basis.

When requesting multiple tasks, the task distribution device 101 may concentrate the requests on a small number of electronic devices. For example, when the number of free threads in the electronic device E3 is 5 and the number of free threads in the electronic device E4 is 3, and the number of tasks to be requested is three, the task distribution device 101 transfers the three tasks to the electronic device E3, which has a larger remaining calculation capacity. You may request them all at once. By making requests all at once, the administrative burden on the electronic devices of the task distribution device 101 can be reduced.

Alternatively, the task distribution device 101 may decide the request recipients so that the multiple tasks are distributed to as many electronic devices as possible.

According to the task distribution system 201, idle computational resources of existing electronic devices can be efficiently utilized.

The task distribution device 101 may determine the load on the electronic device based on information other than the number of free threads. For example, the task distribution device 101 may register CPU utilization rate, memory occupancy rate, CPU temperature, etc. as load information.

The task distribution device 101 uses an evaluation function that has many variables, such as the high performance of the CPU of the electronic device, the number of free threads, the low CPU utilization rate, the low memory occupancy rate, and the low temperature of the CPU. Based on this, the electronic device to which the task is requested may be selected.

The starting point device or the task distribution device 101 may include a task handler (program). For example, suppose that a need arises in the originating device to process task A based on variable X1. At this time, the origin device transmits the variable X1 and the task handler HA (program) corresponding to task A to the task distribution device 101. The task distribution device 101 transmits the task handler HA and the variable X1 to the requested electronic device. The DI engine of the electronic device may execute the task A based on the variable X1 using the task handler HA received from the task distribution device 101.

The DI engine of the electronic device may delete the task handler HA and variable X1 received from the task distribution device 101 from the memory after executing task A. Alternatively, the task handler HA may be left in memory until a predetermined period of time has elapsed after task A is completed, in preparation for the possibility that task A will be re-requested with another variable in the near future.

The task distribution device 101 may request a task to an electronic device, and the requested electronic device may further request a task to another electronic device. As an example, it is assumed that the task distribution device 101 is connected to the electronic device E5 by short-range wireless communication, but is not connected to the electronic device E6. On the other hand, it is assumed that the electronic device E5 is connected to the electronic device E6 by wire.

Assume that the task distribution device 101 requests five tasks to the electronic device E5. At this time, the electronic device E5 transmits load confirmation information to the electronic device E6 to check whether there is sufficient remaining capacity in the computing resources of the electronic device E6. When the electronic device E6 has calculation capacity, the electronic device E5 requests the electronic device E6 to perform all or part of the five requested tasks. Electronic device E6 returns the task execution result to electronic device E5. The electronic device E5 sends back to the task distribution device 101 the results of the tasks executed by itself and the results of the tasks received from the electronic device E6.

When the electronic device is a secondary battery or is equipped with a secondary battery, the task distribution device 101 may exclude electronic devices with a low SOC (State of Charge) from the request destinations. This is because an electronic device with a low SOC, that is, a low charging rate of a secondary battery, may not be able to secure sufficient power to execute a task.

The task distribution device 101 may preferentially select electronic devices to which it has previously requested tasks. Further, request conditions regarding the task request destination may be set. For example, possible request conditions include that the electronic device is owned by user A and that the CPU clock rate is equal to or higher than a predetermined threshold.

The task distribution device 101 may additionally request another electronic device to execute the same task when a predetermined period of time or more has elapsed since requesting execution of the task. In this case, the request may be canceled for the electronic device that made the request earlier.

The task distribution device 101 may preferentially request tasks to electronic devices that do not move, such as fixed servers and desktop PCs, rather than mobile electronic devices such as smartphones and EVs. Further, task requests to important devices such as ambulances and medical devices may be given low priority.

The task distribution device 101 may preferentially select electronic devices that are charged and powered by clean energy. According to such a control method, the task distribution system 201 also contributes to suppressing carbon dioxide emissions.

The DI engine of the electronic device may be set with acceptance conditions for accepting the execution of the task. For example, acceptance conditions may be such as accepting only requests from a specific originating device, or accepting requests only when there are 10 or more free threads.

Compensation may be generated by requesting a task. For example, suppose that when user A's PC1 becomes the starting device and a task is requested to user B's PC2, a fee of M (yen) is incurred. If the number of times PC1 requests a task to PC2 per month is K (times), user A is charged M×K (yen) by user B. On the other hand, when user B has also requested a task to user A, the difference between the amounts billed by both parties may be settled. The task distribution device 101 may include such a payment function.

In particular, when the electronic device is a secondary battery, by connecting the secondary batteries, optimization of the entire task distribution system 201 including the secondary battery is realized.

In the following, a mechanism for distributing tasks by requesting tasks from one computing device to another computing device will be explained in more detail.

FIG. 2 is a conceptual diagram of the distributed processing system 100.
The distributed processing system 100 is composed of three layers: SDI (Small Digital Intelligence), MDI (Middle Digital Intelligence), and LDI (Large Digital Intelligence). Although the distributed processing system 100 may have a two-layer configuration of SDI and MDI, the following explanation will be based on a three-layer configuration.

The SDI is the originating device mentioned above. An SDI is a device that provides a user interface function and/or a sensor function, thereby providing a point of contact with the user or the environment. A task, that is, a work to be processed, occurs in this SDI. Various tasks can be considered, such as image recognition, voice recognition, data search, and translation. Hereinafter, a device that functions as an SDI will also be referred to as an "SDI device." The SDI device is equipped with a DI engine. Specifically, the SDI device (first computing device) is assumed to be a smartphone, a wearable terminal such as a smart watch, a sensor, or the like. Note that the sensor here also includes a camera that captures an image.

MDI is a collection of multiple computational resources. The device constituting the MDI (hereinafter also referred to as "MDI device") may be any computational resource that has a communication function and a calculation function, such as a smartphone, a car, a surveillance camera, or a laptop PC. The MDI device (second computing device) is also equipped with a DI engine.

LDI is also a collection of multiple computational resources. The device constituting the LDI (hereinafter also referred to as "LDI device") may be any device that has a communication function and a calculation function. The LDI device (third computing device) is a device with higher computing power than the MDI. The LDI device is also equipped with a DI engine. "Computing capacity" here may be an index indicating the processing capacity per unit time of a processor such as MIPS (Million Instructions Per Second) or FLOPS (FLOating-point Operations Per Second), It may be defined as the number of cores or the number of threads that can be executed simultaneously.

The DI engine in this embodiment is assumed to be resident software executed on each computing device. The DI engine has its own process and secures a memory space of a predetermined size (hereinafter referred to as "DI space"). The DI engine (DI process) generates threads as needed, and uses the DI space to execute tasks requested by the SDI device. Processes other than the DI engine cannot access the DI space. Further, the DI engine also does not access memory spaces other than the DI space. Therefore, although a computing device equipped with a DI engine provides some computational resources such as a processor to the DI engine, it does not interfere with the processing of the DI engine, and the DI engine does not interfere with the original processing. Nor.

The DI engine may be configured as a lightweight program that is executed on the OS (Operating System) of each computing device. Alternatively, the DI engine may be configured as firmware of the computing device rather than relying on the OS.

When MDI devices and LDI devices (hereinafter collectively referred to as ``MDI devices, etc.'' or ``computing devices'') are requested to perform a task by an SDI device, they perform the device's original task (hereinafter referred to as ``main task''). ), the requested task (hereinafter referred to as a "subtask") is executed in parallel by the DI engine. Hereinafter, when we simply refer to a task, we mean a subtask.

When a subtask to be executed occurs, the SDI device requests the MDI device to execute the subtask. The subtask is completed when one of the MDI devices executes the subtask and returns the execution result to the SDI device. Further, some subtasks may be executed in LDI instead of MDI. In this case, one of the LDI devices executes the subtask and returns the execution result to the SDI device. MDI and LDI provide, so to speak, a function as SaaS (Software as a Service) or PaaS (Platform as a Service) to SDI.

There are subtasks that should be executed in MDI and others that should be executed in LDI. The type of subtask determines whether it should be executed in MDI or LDI. Subtasks with a relatively large processing load, such as processing to recognize similarity between images, may be executed by LDI, and subtasks, which have a relatively small load, such as processing to extract a predetermined region from an image, may be executed by MDI. . It is set in advance whether each subtask is for MDI or LDI. As mentioned above, a "program that executes a subtask (work)" is called a "task handler." In the following, "execution of a subtask" means "execution of a task handler corresponding to a subtask."

The SDI, MDI, and LDI are all connected to the payment device 102. When a subtask requested by the SDI device is executed by any computing device, a settlement unit (not shown) included in the settlement device 102 sends the SDI device to the user (executor) of the computing device that executed the subtask. Payment of remuneration from the user (requester) is executed (described later). Note that in the distributed processing system 100, the payment device 102 is not an essential component.

FIG. 3 is a conceptual diagram showing the relationship between requesting and executing tasks.
Assume that a subtask to process data D1 occurs in the SDI device (S01). At this time, the SDI device transmits "request data" including SDIID=S01 that identifies the SDI device, data to be processed (D1), a task handler corresponding to the subtask, and request conditions to the MDI device (M01). M01 here is an MDI ID that identifies an MDI device. The request condition is information indicating the performance required of the subtask execution entity, and the details will be described later. Note that the LDI device is identified by the LDI ID.

The MDI device (M01) receives the request data and determines whether the subtask can be executed by itself. A specific determination method will be described later. In FIG. 3, the MDI device (M01) has determined that it cannot accept the subtask. At this time, the MDI device (M01) adds MDIID=M01 to the request data and transmits it to the MDI device (M02).

In FIG. 3, the MDI device (M02) also determines that it cannot accept the subtask. The MDI device (M02) adds MDIID=M2 to the request data and transmits it to the MDI device (M03). If the MDI device (M03) is able to execute the subtask, it executes the subtask targeting the data (D1), and returns the execution result to the requesting MDI device (M02). The MDI device (M02) sends the execution result to the MDI device (M01), and the MDI device (M01) sends the execution result to the SDI device (S01). The SDI device (S01) outputs the execution result as an image or the like. Hereinafter, such a request method will be referred to as a "transfer search method."

As another example, the MDI device (M01) that has received the request data from the SDI device (S01) may check with the nearby MDI device (M02) and MDI device (M04) whether or not the subtask can be executed. If the MDI device (M02) is unable to execute the subtask and the MDI device (M04) is able to execute the subtask, the MDI device (M01) sends the request data to the MDI device (M04), and the MDI device (M04) Run subtasks. The execution results of the subtasks are sent to the SDI device (S01) in the same manner as in the transfer search method. Hereinafter, such a request method will be referred to as a "confirmation request method."

Although the transfer search method and the confirmation request method may be used together, this embodiment will be described assuming the transfer search method. Note that, not only in MDI but also in LDI, the execution entity of a subtask is determined by a transfer search method.

A task handler, which is a program for executing subtasks, may be included in the request data. Alternatively, a task handler may be registered in advance in the MDI device or LDI device, and the requesting side may transmit a handler ID that specifies the subtask. For example, when the SDI device (S01) sends request data including handler ID=H1, the MDI device (M03) reads the task handler (H1) corresponding to handler ID=H1 from the built-in memory, and May execute subtasks. In this embodiment, description will be given assuming that the task handler itself is included in the request data instead of transmitting the handler ID.

The distributed processing system 100 will be described below in first to third embodiments.
In the first embodiment, a method will be described in which when a subtask occurs in an SDI device configured as a wearable terminal, it is processed by MDI and LDI.
In the second embodiment, a method will be described in which an MDI is configured by a plurality of robots (mobile devices) in a shopping mall, and a service is provided by these robots working together.
In the third embodiment, a method will be described in which social infrastructure equipment such as surveillance cameras configures an MDI to provide various calculation services to users.
In this specification, when the first embodiment to the third embodiment are not distinguished from each other, or when they are collectively referred to, they are referred to as "this embodiment".

[First embodiment]
FIG. 4 is a conceptual diagram of the distributed processing system 100 in the first embodiment.
The SDI device in the first embodiment is a computing device (first computing device) including a sensing function and a communication function, such as a scale 104, a smart watch 106, and smart glasses 108. These SDI devices communicate with a relay terminal 110 such as a smartphone. The relay terminal 110 is a type of MDI device, but the relay terminal 110 in the first embodiment does not execute the subtask requested by the SDI device itself, but directly requests the subtask to another MDI device, etc. explain. In other words, the relay terminal 110 functions as a contact point between the MDI and the like and the SDI.

The SDI device includes various data such as the weight measured by the scale 104, the pulse rate and number of steps measured by the smart watch 106, and the captured image obtained by the smart glasses 108, as well as a task handler (subtask) for processing the data. (program data indicating processing contents) is included in the request data and transmitted to the relay terminal 110. As described above, it is determined whether each subtask is executed using LDI or MDI.

The relay terminal 110 transmits request data including a task handler to the MDI or LDI depending on the type of subtask. Data (including images) sensed by the SDI device 120 is processed by MDI and LDI.

For example, the smart glasses 108 may transmit the captured image to the relay terminal 110 and request the relay terminal 110 to perform a subtask of determining a building that appears in the captured image. In this case, relay terminal 110 requests a computing device such as an MDI device to execute a subtask. The MDI device or the like identifies a building included in the captured image by executing a subtask, and transmits explanatory information regarding the building to the smart glasses 108 . The smart glasses 108 display an image to which explanatory information about the building is added to the user.

In the case of the smart watch 106, a subtask for determining the user's health condition may be executed based on the detected number of steps and pulse rate. In the case of the weight scale 104, a subtask may be executed to determine whether the user is lacking in exercise based on measured weight and data on past weight changes, and to provide various advice. In this way, by utilizing the computing power of an MDI device or the like, it becomes possible to provide a variety of services in an SDI device.

The LDI device (third computing device) in the first embodiment may be a large-sized, fixedly installed secondary battery installed in a home, an office building, a factory, or the like. As mentioned above, the LDI device is also equipped with a DI engine. If a large number of LDI devices are assembled as an ESS (Energy Storage System), the LDI can function as an instant data center and process many subtasks in parallel.

Although the configuration of the LDI device is not limited to secondary batteries, there are advantages to using secondary batteries as the LDI device. First, as renewable energy is promoted in the future, it is thought that large secondary batteries will have an increased presence in order to level out the power supply. It is also envisioned that a processor will be installed in the secondary battery for advanced control of charging and discharging. For example, a secondary battery equipped with a DI engine is assumed. However, since the main task (charging and discharging control) of the secondary battery does not require a large processing load, there is a possibility that the secondary battery's computational resources will be freed up. Furthermore, since it is mounted on a secondary battery, the power supply to the DI engine is likely to be stable. Therefore, the DI engine equipped with a secondary battery can stably provide computing power.

For the above reasons, secondary batteries that have sufficient computing power, are likely to be deployed in large quantities, and have a stable power supply may become suitable computing resources as LDI devices. For similar reasons, it is also envisaged that a household fuel cell system, so-called "Ene-Farm", may be used as an LDI device. Needless to say, the LDI device is not limited to a secondary battery or an ENE-FARM, but may be configured as a general PC (Personal Computer) or a server.

FIG. 5 is a hardware configuration diagram of the SDI device 120.
The SDI device 120 includes a storage 312 as a nonvolatile memory that stores computer programs, a volatile memory 304 that expands programs and data, and a built-in register (not shown), an arithmetic unit, an instruction decoder, etc. (not shown), and a memory. It includes a processor 300 (CPU) that reads a program from 304 and executes it. Processor 300 is connected to a first bus 302 that is relatively high speed. A memory 304 and a NIC (Network Interface Card) are connected to the first bus 302 . In addition to this, other devices such as a GPU may be connected to the first bus 302.

The first bus 302 is connected to a relatively low speed second bus 310 via a bridge 308. The second bus 310 is connected to a storage 312 as well as an output device 316 such as a monitor or a speaker. Furthermore, an input device 314 such as a mouse and a keyboard, and a peripheral device 318 such as a printer may be connected to the second bus 310.
The hardware configurations of the MDI device and the LDI device are basically the same.
Note that the method of connecting the first bus 302 and the second bus 310 shown in FIG. 5 is an example, and those skilled in the art will understand that other connection methods or a configuration including other buses may be used. By the way.

FIG. 6 is a functional block diagram of the SDI device 120.
Each component of the SDI device 120 includes hardware including arithmetic units such as a CPU and various co-processors, storage devices such as memory and storage, wired or wireless communication lines connecting them, and storage devices. It is realized by software that is stored and supplies processing instructions to the arithmetic unit. A computer program may be composed of a device driver, an operating system, various application programs located in an upper layer thereof, and a library that provides common functions to these programs.
Each block described below indicates a functional unit block rather than a hardware unit configuration. The same applies to FIGS. 7, 15, and 20.

The SDI device 120 includes a user interface processing section 122, a sensing section 124, a communication section 128, a data processing section 126, and a data storage section 130.
The user interface processing unit 122 accepts operations from the user via an input device such as a touch panel, and is also responsible for processing related to the user interface, such as image display and audio output. The sensing unit 124 acquires measurement values from various sensors such as a camera, radar, and gyro sensor. The communication unit 128 is in charge of communication processing with the relay terminal 110 and the like. The data storage unit 130 stores various data. The data processing unit 126 performs various processing based on data input from the user interface processing unit 122, data measured by the sensing unit 124, data received by the communication unit 128, and data stored in the data storage unit 130. Execute. The data processing unit 126 also functions as an interface for the communication unit 128, sensing unit 124, user interface processing unit 122, and data storage unit 130.

User interface processing section 122 includes an input section 132 and an output section 134.
The input unit 132 receives various inputs from the user. The output unit 134 outputs various information to the user.

Communication section 128 includes a transmitting section 136 and a receiving section 138.
The transmitter 136 transmits various data to an external device. The receiving unit 138 receives various data from an external device.

The transmitting unit 136 includes a data transmitting unit 140 that transmits request data including data measured by the sensing unit 124 to the relay terminal 110. As described above, the request data includes the task handler (program body) and SDIID in addition to the measured data. The receiving unit 138 includes a result receiving unit 142 that receives subtask execution results using MDI or the like.

FIG. 7 is a functional block diagram of the MDI device 150 and the LDI device 160.
As described above, the relay terminal 110 that receives request data from the SDI device 120 is also a type of MDI device 150.

(MDI device 150)
MDI device 150 (relay terminal 110) includes a data processing section 170, a communication section 172, and a data storage section 174.
The communication unit 172 is in charge of communication processing with the SDI device 120, payment device 102, other MDI devices 150, LDI device 160, and the like. The data storage unit 174 stores various information. The data processing unit 170 executes various processes based on the data acquired by the communication unit 172 and the data stored in the data storage unit 174. The data processing section 170 also functions as an interface for the communication section 172 and the data storage section 174.

Communication section 172 includes a transmitting section 182 and a receiving section 184.
The transmitter 182 transmits various data to an external device. The receiving unit 184 receives various data from an external device.

The transmitting unit 182 includes a data transmitting unit 186 that transmits request data to another MDI device 150 or LDI device 160, and a result transmitting unit 188 that transmits the execution result of the subtask. The receiving unit 184 includes a data receiving unit 190 that receives request data from other devices, and a result receiving unit 192 that receives subtask execution results.

The data processing unit 170 includes an execution determination unit 176, a task requesting unit 178, and a task execution unit 180.
When the execution determination unit 176 receives request data from another device, it determines whether the subtask can be executed (accepted) by the own device. Details of the determination method will be described later. When the task requesting unit 178 does not execute a subtask on its own device, it requests another device to execute the subtask. At this time, the task requesting unit 178 determines whether to request the MDI or LDI depending on the type of subtask. The task execution unit 180 executes various tasks. The task execution unit 180 includes a main task execution unit 194 that executes a main task as an original function of the MDI device 150, and a subtask execution unit 196 that executes a subtask based on request data. As described above, the functions of the subtask execution unit 196 are realized by the DI engine installed in the MDI device 150. The main task and subtasks can be executed in parallel as separate processes or threads.

(LDI device 160)
LDI device 160 includes a communication section 198, a data processing section 200, and a data storage section 202.
The communication unit 198 is in charge of communication processing with the SDI device 120, MDI device 150, other LDI devices 160, payment device 102, and the like. The data storage unit 202 stores various information. The data processing unit 200 executes various processes based on the data acquired by the communication unit 198 and the data stored in the data storage unit 202. The data processing section 200 also functions as an interface for the communication section 198 and the data storage section 202.

Communication section 198 includes a transmitting section 204 and a receiving section 206.
The transmitter 204 transmits various data to an external device. The receiving unit 206 receives various data from an external device.

The transmitting unit 204 includes a data transmitting unit 208 that transmits request data to other LDI devices 160, and a result transmitting unit 210 that transmits the execution results of subtasks. The receiving unit 206 includes a data receiving unit 212 that receives request data from another device, and a result receiving unit 214 that receives the execution results of subtasks.

The data processing unit 200 includes an execution determination unit 216, a task requesting unit 224, and a task execution unit 218.
When the execution determination unit 216 receives request data from another device, it determines whether the subtask can be executed by the own device. The determination method is the same as that for MDI, but the details will be described later. When the task requesting unit 224 does not execute a subtask on its own device, it requests another device to execute the subtask. The task execution unit 218 executes various tasks. The task execution unit 218 includes a main task execution unit 220 that executes a main task as an original function of the LDI device 160, and a subtask execution unit 222 that executes a subtask based on request data. As described above, the functions of the subtask execution unit 222 are realized by the DI engine installed in the LDI device 160.

FIG. 8 is a data structure diagram of the request condition information 230.
Request condition information 230 is stored in data storage section 130 of SDI device 120. Request condition information 230 is information that defines request conditions for each subtask. Subtasks are identified by task IDs. The subtask with task ID=T01 (hereinafter referred to as "subtask (T01)") is a task for MDI ("M" in the figure indicates that it is for MDI).

The request conditions for the subtask (T01) are "domestic" and "20 GB or more of free memory." For example, when the location of the SDI device 120 (request source) is "Japan", execution of the subtask (T01) is not permitted unless the MDI device 150 is located in Japan (domestic) and has free memory of 20 GB or more. By limiting the subtask execution entity to the "domestic" MDI device 150, the distribution range of data generated from the SDI device 120 can be restricted. Furthermore, by setting a condition regarding the specifications of the main subtask execution entity, such as "20 GB or more of free memory," it is possible to select an MDI device 150 with sufficient spare capacity.

The subtask (T02) is a task for LDI ("L" in the figure indicates that it is for LDI). The request conditions for the subtask (T02) are that the OS is “OS-A (OS name)”, that it is operated by a public organization, and that the LDI device 160 is a multi-core device. LDI devices 160 operated by public organizations are considered to be more reliable and have relatively higher security than private LDI devices 160. By limiting the OS that executes subtasks to, for example, an OS that has been proven to have sufficient security, information leakage can be easily prevented. Similarly, the security of information can be increased by limiting the operator of the LDI device 160 to public institutions.

The subtask (T03) is a task for MDI. The request conditions for the subtask (T03) are “at home” and “power consumption <K”. "K" here is a threshold value indicating "power consumption per unit time when a predetermined task is continuously executed." Therefore, the MDI device 150 that can execute the subtask (T03) is limited to an MDI device 150 that is installed in the same household as the SDI device 120 and has low power consumption according to specifications. Power consumption may be defined as specification information as power consumption expected when a predetermined task is executed. By adding request conditions regarding power consumption, it is possible to actively utilize MDI devices and the like that consume less power, in other words, do not place a burden on the environment. In addition, the request condition may include that the device is an MDI device or the like that is operated using renewable energy.

By setting request conditions, the user of the SDI device 120 can select who will execute the subtask from various viewpoints, such as limiting the range of data distribution and consideration for environmental protection. As described above, the request conditions are included as part of the request data. The request data includes request conditions, data to be processed, a task handler, SDIID (request source ID), and the like.

As request conditions, arbitrary conditions regarding processing load, specification information, power supply status, communication status, etc. can be set. The same applies to the underwriting conditions described below. The term "processing load" as used herein means the current burden on the computing device that is the main body of task execution. For example, CPU usage rate, memory occupancy rate, number of threads used, etc. can be considered. "Specification information" means the specifications of the computing device that is the main body for task execution. For example, the generation of the CPU, the number of clocks, the number of cores, the size of the installed memory, the type and generation of the installed OS, the power consumption per unit processing, etc. are applicable. The “power supply state” means the stability of the power supply to the computing device that is the main subject of task execution. For example, whether it is being charged or not, the size of the SOC, etc. "Communication state" means the state of communication between a computing device that is a request source and a computing device that is a request destination. For example, the presence or absence of a wired connection, the availability of short-range wireless communication, the communication speed, the stability of communication, etc. By proactively selecting a computing device with good communication status, power consumption associated with communication can be suppressed.

FIG. 9 is a data structure diagram of the underwriting condition information 240.
The underwriting condition information 240 shown in FIG. 9 is stored in the data storage unit 174 of the MDI device 150 (M01). The acceptance condition information 240 is information that defines the conditions for the MDI device 150 (M01) to accept a subtask (hereinafter referred to as "acceptance conditions"), in other words, the criteria for determining whether the subtask can be executed. Other MDI devices 150 and LDI devices 160 also have their own underwriting requirements.

The MDI device 150 (M01) executes a subtask when the subtask request condition is satisfied and the acceptance condition of the device itself is satisfied. The conditions for underwriting the MDI device 150 (M01) are that "the CPU usage rate is 50 (%) or less" and that "power is being supplied". That is, the MDI device 150 (M01) does not accept subtasks when the main task is busy or when power is not being supplied. The task requesting unit 178 of the MDI device 150 (M01) transfers the request data to another MDI device 150 when the subtask cannot be executed.
Note that even if the request data is for the MDI device 150, the MDI device 150 may transmit the request data to the LDI device 160 instead of the other MDI device 150 when the own device cannot accept the subtask.

Setting of underwriting conditions is optional. For example, in the multi-core MDI device 150, there is a core (processor) in an idle state, the SOC (State of Charge) is 80 (%) or more, and the number of threads used in the main task is 5 or less. The CPU temperature is below 50 degrees, the memory usage rate is below 60(%), etc. The MDI device 150 only needs to accept subtasks when its own computing resources have surplus capacity. By setting acceptance conditions, it is possible to control so that the performance of the main task, which is the original work of the MDI device 150, does not deteriorate due to the execution of subtasks. The MDI device 150 only needs to take on subtasks when the load of the main task is light, or in other words, only when there is computational surplus.

Underwriting conditions may include conditions regarding remuneration. Although the details will be described later, when the MDI device 150 (M33) executes a subtask of the SDI device 120 (S12), the user of the SDI device 120 (S12: request source) sends a message to the user of the MDI device 150 (M33: request destination). Rewards will be paid. The request conditions may include a reward amount for executing the subtask. Similarly, the underwriting conditions may include a condition that the remuneration amount is a predetermined amount or more.

In the following, request conditions and acceptance conditions will be collectively referred to as "execution conditions." There may be subtasks for which request conditions are not set, and there may be MDI devices 150 for which acceptance conditions are not set. Underwriting conditions can also be set in the LDI device 160.

FIG. 10 is a flowchart showing the processing process for allocating subtasks.
When relay terminal 110 receives request data from SDI device 120, relay terminal 110 executes the process shown in FIG. 10. As described above, the relay terminal 110 in the first embodiment does not execute subtasks by itself.

The task requesting unit 178 of the relay terminal 110 refers to the request conditions included in the request data and determines whether the subtask is for MDI or LDI (S10). When the data is for MDI (Y in S10), the task requesting unit 178 selects the MDI device 150 to which the request data will be transmitted (S12). The task requesting unit 178 may select a destination from the plurality of MDI devices 150 using any method. For example, the task requesting unit 178 may preferentially select the MDI device 150 that is connected to the relay terminal 110 by wire. Alternatively, the task requesting unit 178 may select the MDI device 150 capable of short-range wireless communication with the relay terminal 110 as the destination, or select the MDI device 150 that has been selected as the destination in the past as the destination again. You can choose one at random. As the short-range wireless communication referred to here, Bluetooth (registered trademark), NFC (Near field communication), IrDA (Infrared Data Association), etc. are assumed.

The task requesting unit 178 of the relay terminal 110 instructs the data transmitting unit 186 to transmit the request data to the selected MDI device 150 (S14). In other words, the task requesting unit 178 requests the selected MDI device 150 to execute the subtask. The task requesting unit 178 includes the MDIID of the relay terminal 110 in the request data. The data transmitter 186 may encrypt the request data during transmission.

When the subtask is for LDI (N in S10), the task requesting unit 178 selects the LDI device 160 to which the request data will be transmitted (S16). The method for selecting the LDI device 160 is the same as the method for selecting the MDI device 150. The task requesting unit 178 of the relay terminal 110 instructs the data transmitting unit 186 to transmit the request data (S18).

For example, assume that the smart glasses 108 request the relay terminal 110 to perform a subtask (for MDI) of identifying a building appearing in the captured image from the captured image. At this time, the relay terminal 110 receives the request data including the task handler corresponding to this subtask, and transfers the request data to one of the MDI devices 150. After the data transmitter 186 transmits the request data to the MDI device 150 or the like, the result receiver 192 receives a confirmation signal from the request destination. When the task requesting unit 178 cannot receive a confirmation signal even after a certain period of time has passed after transmitting the request data, in other words, when it cannot confirm the reception of the request data, the task requesting unit 178 sends a new MDI device 150 or the like to another MDI device 150 or the like. Select as the destination.

FIG. 11 is a flowchart showing a processing process when the MDI device 150 receives request data from another device.
The data receiving unit 190 of the MDI device 150 receives request data from the relay terminal 110 or another MDI device 150. When the request data is encrypted, the data receiving unit 190 decrypts the request data. The execution determination unit 176 of the MDI device 150 determines whether or not to undertake the execution of the subtask specified in the request data based on the execution conditions (request conditions and acceptance conditions) (S20). If the task can be accepted (Y in S20), the subtask execution unit 196 executes the subtask according to the data included in the request data and the task handler (S22). The result transmitting unit 188 transmits the execution result of the subtask to the requesting computing device (S24).

As explained in relation to FIG. 3, the execution results of the subtasks are returned to the original SDI device 120 following the transmission route of the request data. The data transmitter 186 transmits the MDIID of its own device and the SDIID included in the request data to the payment device 102 and requests payment (S26). At this time, the payment unit (not shown) of the payment device 102 performs payment of the remuneration amount associated with the execution of the subtask.

When the MDI device 150 does not accept the subtask (N in S20), the task requesting unit 178 selects another MDI device 150 (S28). The task requesting unit 178 instructs the data transmitting unit 186 to transmit the request data (S30). As a result, the subtask is requested to another MDI device 150.

As described above, MDI request data sent from the SDI device 120 is sent to the MDI device 150 via the relay terminal 110. The MDI device 150 executes the subtask if it can accept it, and if it cannot, transfers the request data to another MDI device 150. Request data continues to be transferred until an MDI device 150 that can accept the subtask is found.

As described above, whether or not the subtask can be accepted is determined based on whether the own device satisfies the request conditions and also satisfies the acceptance conditions. Furthermore, since the MDI ID of the transmission source is added to the request data, the destination MDI device 150 can always know the transmission source of the request data. The MDI device 150 that executed the subtask returns the execution result to the transmission source, and finally, the SDI device 120 obtains the execution result of the subtask. The output unit 134 of the SDI device 120 outputs images or audio based on the execution results.

FIG. 12 is a flowchart showing a processing process when the LDI device 160 receives request data from another device.
The data receiving unit 212 of the LDI device 160 receives request data from other devices such as the relay terminal 110. When the request data is encrypted, the data receiving unit 212 decrypts the request data. The execution determination unit 216 of the LDI device 160 determines whether to undertake execution of the subtask specified in the request data based on the execution conditions (S32).

When the LDI device 160 accepts the subtask (Y in S32), the subtask execution unit 222 executes the subtask according to the request data (S34). The result transmitting unit 210 transmits the execution result of the subtask to the requesting computing device (S36). The execution result follows the request route and is returned to the original SDI device 120. The data transmitter 208 transmits the LDIID of its own device and the SDIID included in the request data to the payment device 102, and requests payment (S38). At this time, the payment unit (not shown) of the payment device 102 performs payment of the remuneration amount associated with the execution of the subtask.
Note that the transmission route for the execution result may be determined by following the request route in the reverse direction, or by the LDI device 160 that is the execution entity calculating the shortest route to the SDI device 120 that is the request source. good.

When not accepting the subtask (N at S32), the task requesting unit 224 selects another LDI device 160 (S40). The task requesting unit 224 instructs the data transmitting unit 208 to transmit the request data (S42).

The LDI device 160 also executes the subtask if it can accept it, and if not, transfers the request data to another LDI device 160. Request data continues to be transferred until an LDI device 160 that can accept the subtask is found.

FIG. 13 is a data structure diagram of the payment information 250.
Payment information 250 shown in FIG. 13 is stored in payment device 102. Each time a subtask is executed, the MDI device 150 or the like that executed the subtask transmits a payment request to the payment device 102. A user is identified by a user ID. According to the payment information 250 in FIG. 13, the user identified as user ID=P01 owns the SDI device 120 (S01) and the SDI device 120 (S02). The payment request includes the task ID, the requester's user ID, the SDI ID of the requester's SDI device 120, the executor's user ID, and the MDIID or LDIID of the executor's computing device.

The SDI device 120 (S01:P01) generates a subtask (T01), and the MDI device 150 (M01) owned by the user (P05) executes this subtask (T01). The amount of remuneration associated with the execution of the subtask (T01) is Y1 (yen). When the data transmitter 186 of the MDI device 150 (M01:P05) executes the subtask (T01), it notifies the payment device 102 of a payment request including SDIID=S01, MDIID=M01, and task ID=T01, and sends the payment request to the payment device 102. The payment unit 102 registers the notification content in the payment information 250. The payment unit periodically executes, for example, once a month, a remittance process from the user of the SDI device 120 to the holder of the MDI device 150 that is the subject of task execution. Regarding the task (T01), a remittance process of Y1 (yen) from the user (P01) to the user (P05) is executed.

According to the payment information 250, the subtask (T04) generated by the SDI device 120 (S02) of the user (P01) is executed by the LDI device 160 (L01:P11). The remuneration amount at this time is Y2 (yen). Therefore, the user (P01) also pays a reward to the user (P11) who is the owner of the LDI device 160 (L01).

Note that each time request data is transferred from MDI device 150 to MDI device 150, from LDI device 160 to LDI device 160, or from MDI device 150 to LDI device 160, the destination computing device indicates the transfer content. The information may be sent to payment device 102. In the payment information 250, the payment device 102 may register not only the requestor and executor of the task but also the transferor. Further, the payment device 102 may pay a reward not only to the task executor but also to the task transferer (relayman). The information indicating the transfer content here includes the task ID, the requester's user ID, the SDI ID of the requesting SDI device 120, the transferer's user ID, and the MDIID or LDIID of the transferred computing device.

<Summary>
In the first embodiment, subtasks generated by the SDI device 120 are executed by MDI or LDI. Therefore, even if the SDI device 120 does not have advanced processing capabilities, it can provide a variety of services by utilizing other computational resources such as MDI. Furthermore, by setting acceptance conditions, the MDI device 150 and the like can execute subtasks only when there is surplus computing power. Therefore, the MDI device 150 and the like can execute subtasks requested by the SDI device 120 only when the processing load of the main task is not heavy, while executing the main task that is its original role. With such a control method, various computational resources included in the distributed processing system 100 can be effectively utilized without degrading the original performance of the MDI device 150 and the like.

The user of the SDI device 120 can freely set request conditions in consideration of various aspects such as data destination, security, and environmental protection. For example, a user who prefers to utilize renewable energy may set request conditions such that a computing device powered by renewable energy is the primary task execution entity.

Among the subtasks, those with a large processing load or those for which a slow response is acceptable may be processed by LDI. Since the LDI device 160 in the first embodiment is a secondary battery equipped with a DI engine, the main task load is lighter compared to the MDI device 150. Therefore, the LDI device 160 can more efficiently execute subtasks that have a larger processing load than the MDI device 150. On the other hand, the MDI device 150 is a device that exists close to the SDI device 120, such as a smartphone or a car. Therefore, compared to the LDI device 160, the MDI device 150 has more opportunities to receive request data from the nearby SDI device 120.

The payment device 102 executes payment from the subtask requester to the executor. Owners of MDI devices 150, etc. can earn revenue by taking on subtasks. The owner of the SDI device 120 can freely set request conditions for the MDI device 150 or the like to which he or she wishes to request a subtask. For example, in a situation where an MDI device 150 with sufficient computing power is likely to be preferred, it is economically rational to introduce a high-quality MDI device 150 even if it is expensive. Alternatively, if an MDI device 150 with low power consumption is preferred, the MDI device 150 with low power consumption is likely to be introduced even if it is expensive. The preferences of the subtask requester will influence the decision to install the MDI device 150 and LDI device 160.

Based on the payment information 250, the payment device 102 transmits to the SDI device 120 a statement indicating which MDI device 150 etc. executed the subtask (hereinafter referred to as "execution statement"). You may. The execution specification may include, for example, background information indicating the location, function, specifications, etc. of the MDI device 150 or the like that is the subject of task execution. By referring to the execution specification, the user of the SDI device 120 can track who executed a subtask, making it easier to request a subtask to another computing device with confidence. By setting the request conditions, the user may limit the execution range of the subtask regionally, such as within the home or within the same town.

<Modified example of the first embodiment>
In the first embodiment, it has been described that the relay terminal 110 determines whether the subtask is for MDI or LDI. The present invention is not limited to this, and the SDI device 120 may determine whether the subtask is for MDI or LDI.

In the first embodiment, the relay terminal 110 is described as requesting the MDI device 150 or LDI device 160 to perform the subtask without executing the subtask. As a modification, the relay terminal 110 may execute the subtask itself when the execution condition is satisfied by the relay terminal 110 itself.

As an example of the processing method of the distributed processing system 100, a subtask of determining whether a missing person is shown in the image captured by the smart glasses 108 can be considered. In this case, the smart glasses 108 may send the captured image to the MDI device 150 or the like, and the MDI device 150 or the like may assist in finding the missing person by comparing the captured image with the face image of the missing person. According to such a control method, the user of the smart glasses 108 can cooperate in searching for a missing person.

[Second embodiment]
FIG. 14 is a conceptual diagram of the distributed processing system 100 in the second embodiment.
In the second embodiment, SDI and MDI are not particularly distinguished and will be collectively referred to as MDI. In the second embodiment, a plurality of robots 262 that operate autonomously in a shopping mall function as the "MDI device 150." In FIG. 14, a drone 252, a guide robot 254, a cleaning robot 256, a security robot 258, and a transport robot 260 are shown as robots 262. Among these, it is assumed that the transport robot 260 is being charged. These robots 262 are also connected to LDI.

The drone 252 flies around the shopping mall and periodically takes images. The guide robot 254 is in charge of customer service and provides guide information to visitors as necessary. The cleaning robot 256 travels within the shopping mall and automatically cleans the floor surface. When the security robot 258 detects a person acting suspiciously, it issues a warning to this person. The transport robot 260 automatically transports cargo. Both robots 262 are equipped with DI engines.

Each robot 262 is a mobile device equipped with a communication function. Furthermore, in the second embodiment, the unique functions that each robot 262 can provide are referred to as "services." For example, the cleaning robot 256 can provide a service called "floor cleaning," and the security robot 258 can provide a service called "warning."

As an example, assume that the drone 252 images an indoor space at a certain point P1. At this time, the drone 252 transmits request data including the captured image and position information P1 to the nearby guide robot 254. This request data specifies a subtask for detecting whether "dirt" appears in the captured image. It is assumed that the execution condition of the subtask in the second embodiment is "charging".
In this case, it is desirable that one or more robots 262 among the plurality of robots 262 included in the distributed processing system 100 are always charging. If a charging robot 262 is present, this robot 262 can eventually take on the subtask.

Since the guide robot 254 is not charging, it transfers the request data to a nearby cleaning robot 256. Since the cleaning robot 256 is also not charging, the request data is transferred to the nearby security robot 258. Since the security robot 258 is also not charging, the request data is transferred to the nearby transport robot 260. Since the transport robot 260 is being charged, it executes the subtask.

It is assumed that the transportation robot 260 executes a subtask and discovers "dirt on the floor" in the captured image. The transportation robot 260 determines that "floor cleaning" at the point P1 is necessary as a result of executing the subtask. At this time, the transportation robot 260 transmits service instruction information requesting a floor cleaning service at the point P1 to the nearby security robot 258. Since the security robot 258 cannot provide floor cleaning service, it transmits service instruction information to a nearby cleaning robot 256. The cleaning robot 256 can provide floor cleaning services. The cleaning robot 256 moves to the point P1 specified by the service instruction information and performs floor cleaning.

In the distributed processing system 100 of the second embodiment, the plurality of robots 262 cooperate in this way to recognize various events that occur in the shopping mall and provide corresponding services. In the second embodiment as well, not only the robot 262 (MDI device 150) but also the LDI device 160 may execute subtasks. For example, the transport robot 260 that is being charged may transmit subtask request data to the LDI device 160 when its own device does not have sufficient computing power. The LDI device 160 in the second embodiment may also be a fixedly installed computing device equipped with a DI engine, such as a large secondary battery.

FIG. 15 is a functional block diagram of the robot 262.
The robot 262 includes a user interface processing section 326, a sensing section 264, a communication section 266, a driving section 268, a data processing section 270, and a data storage section 272.
The user interface processing unit 326 accepts operations from the user via an input device such as a touch panel, and is also responsible for processing related to the user interface, such as image display and audio output. The sensing unit 264 acquires measurement values from various sensors such as a camera, radar, and gyro sensor. The communication unit 266 is in charge of communication processing with other robots 262 or the LDI device 160. The drive unit 268 controls various drive mechanisms of the robot 262, such as propellers, wheels, and robot hands. The data storage section 272 stores various data. The data processing unit 270 performs various processing based on data input from the user interface processing unit 326, data measured by the sensing unit 264, data received by the communication unit 266, and data stored in the data storage unit 272. Execute. The data processing section 270 also functions as an interface for the communication section 266, sensing section 264, user interface processing section 326, and data storage section 272.

User interface processing section 326 includes an input section 274 and an output section 276.
The input unit 274 accepts various inputs from the user. The output unit 276 outputs various information to the user.

Communication section 266 includes a transmitting section 278 and a receiving section 280.
The transmitter 278 transmits various data to an external device. The receiving unit 280 receives various data from an external device.

The transmitting unit 278 includes a data transmitting unit 282 that transmits request data including data measured by the sensing unit 264 to other devices, and a result transmitting unit 284 that transmits the execution results of the subtask. In addition to measured data, the request data in the second embodiment includes robot IDs that identify task handlers and robots. The receiving unit 280 includes a data receiving unit 286 that receives request data and the like, and a result receiving unit 288 that receives the execution results of subtasks.

The data processing unit 270 includes an execution determination unit 290, a task execution unit 292, a service provision unit 294, a service identification unit 296, a service determination unit 298, a task request unit 321, and a service request unit 320.
When the execution determination unit 290 receives request data from another robot (mobile device), it determines whether the robot itself can accept the subtask. In the second embodiment, the execution determination unit 290 determines that the subtask can be accepted if the own device is charging. The determination method may be the same as in the first embodiment.

When the task requesting unit 321 does not execute a subtask on its own device, it requests a subtask from another mobile device. The task execution unit 292 executes various tasks. The task execution unit 292 includes a main task execution unit 322 that executes a main task, and a subtask execution unit 324 that executes a subtask. The main task of the robot 262 is an operation for executing a service specific to the robot 262. In the second embodiment as well, the functions of the subtask execution unit 324 are realized by the DI engine installed in the robot 262.

The service providing unit 294 provides a service specific to the robot 262 by controlling the driving unit 268 according to the execution result of the main task or subtask. The service identification unit 296 determines the service to be executed based on the result of the subtask execution by the subtask execution unit 324. The service determination unit 298 determines whether or not the own device is capable of executing the specified service. The service requesting unit 320 requests services from other robots 262. More specifically, the service requesting unit 320 generates service instruction information based on the execution results of the subtasks, and instructs the result transmitting unit 284 to transmit the service instruction information to the other robots 262.

FIG. 16 is a data structure diagram of the service definition information 330.
The service definition information 330 shown in FIG. 16 is stored in the data storage unit 272 of the cleaning robot 256 with robot ID=R01. Service definition information 330 is information that defines services that can be provided by robot 262.

Each service is identified by a service ID. The cleaning robot 256 (R01) can provide the service "movement" identified by service ID=V01 and the service "floor cleaning" identified by service ID=V02. The drone 252 can provide the services of "flight" and "photography". The guide robot 254 can provide services such as "guidance," "movement," and "calling out." The security robot 258 can provide services such as "movement", "warning", and "imaging". The transportation robot 260 can provide services such as "movement" and "transportation." In this way, each robot 262 has its own service definition information 330.

As described above, a subtask is generated in response to sensing by one of the robots 262. As a result of the execution of the subtask, a service such as "floor cleaning" is required. At this time, the cleaning robot 256 that can provide the service "floor cleaning" is responsible.

Note that the above is just an example, and the services that each robot 262 (MDI device 150) can provide are not limited to this. In addition, various other services can be considered, such as a robot 262 that provides games to children, a robot 262 that can display animations, a robot 262 that gives haircuts, and a robot 262 that reports to outside agencies such as the police.

FIG. 17 is a flowchart showing a processing process when the robot 262 receives request data.
When the request data is received from another robot 262, the execution determination unit 290 determines whether the subtask can be accepted (S44). If the subtask can be accepted (Y in S44), the subtask execution unit 324 executes the subtask (S46). The service identifying unit 296 identifies the service to be executed based on the processing results of the subtasks (S48). If any service is required (Y in S48), the service requesting unit 320 causes the data transmitting unit 282 to transmit service instruction information including the service ID (S50). The data transmitter 282 transmits the designated service instruction information to the other robots 262. If the service does not need to be executed (N at S48), the process at S50 is skipped.
Note that if the service can be executed by the own device, the service providing unit 294 provides the service at step S50.

If the subtask cannot be accepted (N at S44), the task requesting unit 321 selects another robot 262 (S52). The task requesting unit 321 instructs the data transmitting unit 282 to transmit request data to the selected robot 262 (S54). Similar to the first embodiment, request data is transferred between robots 262 until one of the robots 262 is able to take on the subtask. LDI device 160, rather than robot 262, may perform the subtasks.

The robot 262 may periodically learn what kind of robots 262 are around by using known means such as a beacon. More specifically, the robot 262 periodically transmits a beacon (search signal) to its surroundings, and upon receiving the beacon, the robot 262 informs the sender of the services that it can provide along with its own robot ID. Reply with your ID. In S50, when requesting the specified service from another robot 262, the robot 262 may select a robot 262 that can provide the necessary service from among the robots 262 existing in the vicinity and transmit the service instruction information. .

FIG. 18 is a flowchart showing a processing process when the robot 262 receives service instruction information.
The service determination unit 298 determines whether the service specified in the service instruction information can be provided (S58). If it is possible to provide the specified service (Y in S58), the service providing unit 294 provides the specified service (S60). Depending on the subtask, multiple services may be required. For example, it may be necessary to provide a service such as erecting a no-trespassing sign on-site after cleaning the floor.

If there remains a service that cannot be provided by the robot itself (Y at S62), the task requesting unit 321 requests the service from another robot 262 (S64). If there are no remaining services that cannot be provided by the device itself (N at S62), the process at S64 is skipped.

When the service cannot be provided, the service requesting unit 320 selects another robot 262 (S66) and requests the robot 262 to provide the service (S64).

<Summary>
In the distributed processing system 100 according to the second embodiment, the plurality of robots 262 share sensing, execution of subtasks, and provision of services, so that processing can be distributed as a whole. According to such a configuration, the processing load per robot 262 can be reduced. In the case of the distributed processing system 100 shown in FIG. 14, the drone 252 only needs to have a circular flight and regular imaging function. The subtask of determining whether "floor cleaning" is necessary is executed by the charging robot 260. Further, the service "floor cleaning" is instructed from the transportation robot 260 to the cleaning robot 256 via the security robot 258. The cleaning robot 256 may move to a location specified by the service instruction information and clean the floor.

The drone 252 can monitor the entire floor of the shopping mall from above. Therefore, more efficient monitoring is possible than with the cleaning robot 256 that travels on the ground. By coordinating multiple robots 262, various services can be provided efficiently.

<Modified example of second embodiment>
The robot 262 equipped with an odor sensor may request analysis of odor information, and the other robots 262 may determine whether or not the odor is abnormal. In the case of a strange odor, a robot 262 with a guiding function may guide the passengers to evacuate. In addition, when a lost child is detected, a service may be provided that calls out to the child, takes a picture of the child, and makes an announcement in the venue including the characteristics of the child.

[Third embodiment]
FIG. 19 is a conceptual diagram of a distributed processing system 100 in the third embodiment.
The MDI device 150 in the third embodiment is configured as social infrastructure equipment. Social infrastructure equipment is equipment installed to play social and industrial roles such as transportation, safety, security, observation, and information provision. The MDI device 150 serving as social infrastructure equipment includes a surveillance camera, a human sensor, a camera that measures the flow of people, a digital signage, an environmental sensor, an AED (Automated External Defibrillator), a traffic light, a wireless base station, a rain gauge, a snow gauge, and a wind direction. Possible devices include meters, solar cells in solar power plants, street lights, smart poles, and barometers. The MDI device 150 in the third embodiment is also equipped with a DI engine.

In the MDI device 150, the main task is the device's work as a social infrastructure facility, and the work for the SDI device 120 is a subtask. The DI engine installed in the MDI device 150 executes subtasks in parallel with the main task. In the third embodiment as well, not only the MDI device 150 but also the LDI device 160 may execute the subtask. For example, when the MDI device 150 configured as an environmental sensor is requested to perform a subtask, and this MDI device 150 does not have sufficient calculation capacity, the MDI device 150 may request the LDI device 160 to perform the subtask. .

As the SDI device 120 in the third embodiment, a portable mobile terminal such as a smartphone is assumed. As long as the SDI device 120 is within an area where MDI devices 150 are installed at various locations, the SDI device 120 can request subtasks to the MDI at any time. The SDI device 120 selects the nearest MDI device 150 and requests the subtask. In this case, the MDI device 150 that has acquired the subtask from the SDI device 120 may function as the task distribution device 101, or the SDI device 120 itself may function as the task distribution device 101.

FIG. 20 is a functional block diagram of the surveillance camera 151.
The surveillance camera 151 is an example of the MDI device 150 in the third embodiment. The surveillance camera 151 includes a sensing section 342, a communication section 344, a data processing section 346, and a data storage section 348 configured as a camera.
The sensing unit 342 acquires a captured image using a camera. The communication unit 344 is in charge of communication processing with other MDI devices 150 or LDI devices 160. The data storage unit 348 stores various data. The data processing unit 346 executes various processes based on the captured image acquired by the sensing unit 342, data received by the communication unit 344, and data stored in the data storage unit 348. The data processing section 346 also functions as an interface for the communication section 344, sensing section 342, and data storage section 348.

Communication section 344 includes a transmitting section 350 and a receiving section 352.
The transmitter 350 transmits various data to an external device. The receiving unit 352 receives various data from an external device.

The transmitting unit 350 includes a data transmitting unit 354 that transmits request data received from other computing devices such as the SDI device 120 to other devices, and a result transmitting unit 356 that transmits the execution results of subtasks. The receiving unit 352 includes a data receiving unit 358 that receives request data and the like, and a result receiving unit 360 that receives the execution results of subtasks.

The data processing unit 346 includes an execution determination unit 368, a task execution unit 362, and a task request unit 370.
When the execution determination unit 368 receives request data from another computing device such as the SDI device 120, it determines whether the own device can accept the subtask. The determination method may be the same as in the first embodiment. When the task requesting unit 370 does not execute a subtask on its own device, it requests another computing device to execute the subtask. The task execution unit 362 executes various tasks. The task execution unit 362 includes a main task execution unit 364 that executes a main task and a subtask execution unit 366 that executes a subtask. The main task of the surveillance camera 151 is "obtaining captured images." In the third embodiment as well, the functions of the subtask execution unit 366 are realized by the DI engine installed in the surveillance camera 151.
The same is basically true for MDI devices 150 other than the surveillance camera 151.

FIG. 21 is a flowchart showing a processing process when the MDI device 150 receives request data in the third embodiment.
The data receiving unit 358 of the MDI device 150 receives request data from the SDI device 120 or another MDI device 150. When request data is received from the SDI device 120 (Y in S70), the task request unit 370 determines whether the subtask indicated by the request data is for MDI or LDI (S72). When the request data is received from the MDI device 150 instead of the SDI device 120 (Y in S70), the process in S72 is skipped because it has been determined as an MDI subtask.

When a subtask for MDI is requested (Y in S72), the execution determination unit 368 determines whether the own device can accept the subtask (S74). If the task can be accepted (Y in S74), the subtask execution unit 366 executes the subtask (S76). The result transmitting unit 356 transmits the execution result of the subtask to the requesting computing device (S78).

If the task cannot be accepted (N at S74), the task requesting unit 370 selects another MDI device 150 to which the subtask is requested (S80). The task requesting unit 370 instructs the data transmitting unit 354 to transmit the request data (S82).

When a subtask for LDI is requested (N at S72), the task requesting unit 370 selects the LDI device 160 to which the request is made (S84). The task requesting unit 370 requests the subtask to another LDI device 160 by instructing the data transmitting unit 354 to transmit request data (S86).
The processing process when the LDI device 160 receives request data from another computing device is basically the same as the flowchart described in connection with FIG. 12.

Although payment processing is not performed in the third embodiment, payment processing may be performed in the same manner as in the first embodiment.

<Summary>
With the development of IoT (Internet of Things) related technologies, it is expected that more social infrastructure equipment will be equipped with processing and communication functions in the future. By installing a DI engine in social infrastructure equipment, it becomes possible to make it function as an MDI device 150.

Many social infrastructure facilities (MDI devices 150) have time periods (idle time periods) when the processing load of the main task, which is the original work, is not so heavy. By utilizing the idle time slots of a large number of MDI devices 150, it is possible to provide various services to the SDI devices 120, as in the first embodiment.

By having the social infrastructure equipment (MDI device 150) undertake subtasks, the processing capacity of the SDI device 120 can be reduced. This also contributes to lower prices, lower power consumption, and smaller and lighter SDI devices 120 such as smartphones and wearable terminals. Since the social infrastructure equipment (MDI device 150) provides calculation functions as a public service to various SDI devices 120, many users can enjoy advanced services with a simple SDI device 120.

For example, it is conceivable to transmit the results of image processing by a smart pole (MDI device 150) to a car (SDI device 120). Alternatively, an on-vehicle camera (SDI device 120) of the vehicle may transmit a captured image to a smart pole (MDI device 150), and the smart pole may notify the vehicle of the presence or absence of danger based on the captured image. In addition to in-vehicle cameras, collaboration with processing based on cameras and sensors installed in social infrastructure equipment such as smart poles is expected to enable highly automated driving using social infrastructure equipment.

As an example, a smart pole may take an image of a moving car and determine whether this car is driving dangerously in cooperation with other MDI devices 150. When it is determined that the vehicle is dangerous, the MDI device 150 located near the vehicle transmits an emergency stop command to the vehicle. When a DI engine installed in a vehicle receives an emergency stop command, it may perform the task of bringing the vehicle to a safe stop on the roadside. According to such a control method, it is possible to force a car that is driving dangerously to a safe stop.

<Other variations>
FIG. 22 is a schematic diagram for explaining a method for distributing subtasks from the LDI device 160.
The LDI device 160 may include a "data division section." The data dividing unit divides the data to be processed into a plurality of pieces. For example, assume that the LDI device 160 (L01) shown in FIG. 22 receives request data including data (D) and a task handler for a subtask (T1) from the SDI device 120 or the MDI device 150.

The data dividing unit of the LDI device 160 (L01) divides data (D) into four parts: data (D1), data (D2), data (D3), and data (D4). The LDI device 160 (L01) transmits request data including a task handler (T1) and data (D1) to the LDI device 160 (L02). The LDI device 160 (L02) returns the processing result of the data (D1) to the LDI device 160 (L01).

Similarly, the LDI device 160 (L01) transmits request data including the task handler (T1) and data (D2) to the LDI device 160 (L02). Data (D3) and data (D4) are transmitted to LDI device 160 (L03) and LDI device 160 (L04), respectively. The LDI device 160 (L01) summarizes the processing results of data (D1) to data (D4) received from the four LDI devices 160, and sends the requesting MDI device 150 or SDI device 120 to process the data (D). Submit your results.

In this way, by dividing the large size data (D) and having the plurality of LDI devices 160 process it in parallel, the processing of the data (D) can be sped up.

For example, assume that data (D) is a moving image, and a subtask is to determine whether a specific person X is shown in this moving image. In such a case, the LDI device 160 (L01) may divide the moving image into multiple parts and have the multiple LDI devices 160 process subtasks in a distributed manner.

As another example, it is assumed that the LDI device 160 is a large secondary battery equipped with a DI engine installed in each household in an apartment complex. The entrance management device (SDI device 120) at the entrance of the apartment complex acquires a captured image of a person wishing to enter in front of the entrance, and transmits the captured image to the LDI device 160 (L01). The LDI device 160 (L01) transmits this captured image to the LDI device 160 provided in each home. The LDI device 160 (L02) of a certain household compares a captured image of a person who wishes to enter the facility with a captured image of a family member, and determines whether or not the person who desires to enter the facility is a member of his or her family. The LDI devices 160 in other homes also perform similar determination processing.

The LDI device 160 (L01) instructs the admission management device to unlock the facility if the person wishing to enter the facility is a member of any household. According to such a control method, residents of an apartment complex can enter the apartment complex simply by showing their faces to the entrance control device. On the other hand, those who wish to enter the facility who are not registered in any of the LDI devices 160 are prohibited from entering the facility. Furthermore, since it is a distributed processing method using a plurality of LDI devices 160, it is possible to speed up face authentication processing.

The LDI device 160 may include a “task decomposition unit” and a “task distribution unit”. Rather than dividing the data, the LDI device 160 may divide the subtask into lower-level subtasks. For example, it may be desirable to analyze a captured image of a person entering a store from multiple perspectives, such as estimating gender, estimating age, and whether the person is an existing customer or a new customer. In such a case, the task distribution unit of the LDI device 160 (L01) divides the subtask of determining the person entering the store into "lower subtask T1 for estimating gender," "lower subtask T2 for estimating age," and "lower subtask T2 for estimating age." It is broken down into a lower subtask T3 for determining whether the customer is a new customer. The task distribution unit may allocate these three types of subtasks to the three LDI devices 160 to process multiple types of lower level subtasks in parallel.

In addition, when encrypting an image, the image may be divided into multiple parts and each part may be encrypted. In this case, a plurality of LDI devices 160 may be responsible for encrypting each part. The same applies to decoding. Note that, although the explanation in FIG. 22 is based on LDI, the same applies to MDI.

FIG. 23 is a schematic diagram for explaining a method of determining whether a subtask can be executed in a modified example.
In this embodiment, the MDI device 150 or the like that is the request source transmits request data including request conditions to the MDI device 150 or the like that is the request destination, and the MDI device 150 or the like that receives the request data determines whether or not to accept the subtask. It was explained that it is determined. As a modified example, the MDI device 150 or the like that is the request source may determine the destination of the request data after confirming the specification information or acceptance conditions from the request destination candidates in advance.

For example, the MDI device 150 (M01) first notifies the request condition C1 to the MDI device 150 (M02), the MDI device 150 (M03), and the MDI device 150 (M04). It is assumed that the MDI device 150 (M02) determines that the subtask cannot be accepted in view of the request conditions and the acceptance conditions, and notifies the MDI device 150 (M01) of the inability. On the other hand, it is assumed that the MDI device 150 (M03) and the MDI device 150 (M04) respond that they can accept the subtask.

Assume that the requesting MDI device 150 (M01) selects the MDI device 150 (M03) as the request destination from the MDI devices 150 (M03) and MDI device 150 (M04) that can accept the request. As described above, the MDI device 150 (M01) may select a request destination based on the communication state. The MDI device 150 (M01) formally transmits the request data (data and task handler) to the MDI device 150 (M03) selected as the request destination, and the MDI device 150 (M03) executes the subtask.

The MDI device 150 may collect specification information, etc. of other MDI devices 150 by periodically communicating with each other. The MDI device 150 may determine the subtask request destination based on specification information collected in advance. Alternatively, all MDI devices 150 may periodically transmit specification information and the like to a predetermined server. When requesting a subtask, the MDI device 150 may obtain specification information of each MDI device 150 from the server, and then determine the destination to which the subtask is requested. In FIG. 23, the description has been made with reference to MDI, but the same applies to LDI.

In the present embodiment, the subtask has been described as being set in advance for either MDI or LDI. In addition, it may be determined whether a subtask should be executed using MDI or LDI, depending on the type or size of data to be processed. For example, the SDI device 120 or the like may transmit request data to the LDI when processing a moving image, and transmit request data to the MDI when processing a still image. The LDI may be in charge of image or audio processing, and the MDI may be in charge of text information processing. The SDI device 120 or the like may request the LDI to perform a subtask that targets data of a predetermined size or more, and may request the MDI to perform a subtask that targets data that is less than a predetermined size.

When defining subtasks, an expected load value indicating the amount of processing load expected for each subtask may be set. The SDI device 120 or the like may transmit request data to the LDI if the assumed load value is greater than or equal to a predetermined threshold, and may transmit request data to the MDI if the assumed load value is less than the predetermined threshold.

When defining a subtask, a request response value indicating the communication speed and processing speed required for each subtask may be set. The SDI device 120 and the like selects MDI for subtasks whose request response value is greater than or equal to a predetermined value, that is, requires a high-speed response, and selects LDI for subtasks whose request response value is less than a predetermined value, that is, a subtask that does not mind a slow response. You may also choose.

Depending on the type of subtask, it may be determined whether MDI or LDI is in charge of processing. For example, subtasks related to search are defined in LDI, subtasks related to translation are defined in LDI, subtasks related to calculation are defined in MDI, and categories such as "search," "translation," and "calculation" are defined when designing subtasks. May be set. The SDI device 120 and the like determine whether to process using MDI or LDI based on the subtask category.

If a predetermined number or more of MDI devices 150, for example, three or more MDI devices 150, refuse to accept the subtask, the LDI device 160 may accept this subtask. Specifically, the "number of transfers" is included in the request data. The MDI device 150 receives the request data and adds the "number of transfers" included in the request data when the device itself does not execute the subtask. The MDI device 150 that has received the request data may check the number of transfers and, when the number of transfers exceeds a predetermined threshold, transmit the request data to the LDI device 160.

The task requesting unit 178 of the MDI device 150 may use the "number of transfers" of the request data as the "priority." The task requesting unit 178 may preferentially treat request data with a larger number of transfers (priority). For example, if the task requesting unit 178 receives and buffers the request data (C1: the number of transfers is 5 times) and the request data (C2: the number of transfers is 2 times) at the same time, Transfer processing may be performed for the larger request data (C1) first. According to such a control method, it is possible to prevent subtasks corresponding to some requested data from being significantly delayed.
The same applies not only to MDI tasks but also to LDI tasks.

Even if the SDI device 120 is a subtask for MDI, if there is an LDI device 160 connected by wire or capable of short-range wireless communication, the SDI device 120 or the like may transmit request data to the LDI device 160. . The same applies to subtasks for LDI. In this way, the LDI or MDI may be selected as the subtask execution entity depending on not only the type of subtask, the type and size of data, but also the communication state.

As described above, the LDI device 160 is a computing device with greater computing power than the MDI device 150. The computing power here may be defined based on the size of the built-in memory, the amount of processing per unit time of one processor, the number of cores installed, etc. Alternatively, LDI device 160 may be a permanently installed computing device, and MDI device 150 may be a portable, portable, or movable computing device. LDI device 160 may also be a mobile computing device. For example, a car may be used as the LDI device 160. Similarly, MDI device 150 may be a permanently installed computing device. For example, a large secondary battery or ENE-FARM may be used as the MDI device 150.

The MDI device 150 may include multiple communication means. For example, it is assumed that the MDI device 150 (M01) and the MDI device 150 (M02) are equipped with three types of communication means: NFC, Wi-SUN (Wireless Smart Utility Network), and Bluetooth (registered trademark). When transmitting request data to the MDI device 150 (M02), the task requesting unit 178 of the MDI device 150 (M01) uses one of three types of communication means depending on the size or type of data to be processed. You may choose to do so.

The MDI device 150 (M01) transmits the request data via Bluetooth (registered trademark) when the data size is greater than or equal to a predetermined size, and transmits the request data via Wi-SUN when the data size is less than the predetermined size. You may do so. Although Wi-SUN has slow communication speed, it is characterized by low power consumption and long communication distance. When the MDI device 150 (M01) transmits small data such as character data, or when requesting a subtask for which a slow response speed is acceptable, the distance between the MDI device 150 (M01) and the MDI device 150 (M02) is long. Sometimes Wi-SUN may be selected.

The same applies to the LDI device 160. That is, when transmitting request data from the SDI device 120 to the MDI device 150, from the SDI device 120 to the LDI device 160, from the MDI device 150 to the MDI device 150, and from the LDI device 160 to the LDI device 160, multiple communication means can be used. In some cases, the communication means may be selected depending on the size or type of data. Further, the transmission source computing device may specify available communication means as a request condition. Similarly, the destination computing device may also specify available communication means as a condition of acceptance.

The DI engine may delete the request data from the built-in memory. For example, after receiving request data and executing a subtask, the DI engine deletes the request data from internal memory. Furthermore, when the DI engine receives request data and transfers the request data to another DI engine (such as the MDI device 150), the request data may also be deleted from the built-in memory.

As the MDI device 150, a vehicle equipped with a DI engine can be considered. Alternatively, various computing devices installed in the coworking space may provide computing power to users (SDI devices 120) as MDI devices 150 or LDI devices 160. According to such a control method, users can rent not only communication functions and electricity but also computing functions in a coworking space.

When the MDI device 150 etc. receives the request data, it may hold the request data without transferring it until the acceptance conditions are met. The MDI device 150 or the like may execute the subtask if the acceptance condition is satisfied before a predetermined time limit elapses, and transmit the request data to another MDI device 150 or the like when the time limit elapses.

Various task handlers such as image comparison, translation, and image search may be registered in advance as a library in the DI engine. A task handler is identified by a handler ID. In this case, the request data only needs to include a handler ID that specifies the task handler instead of the task handler (program). The DI engine may execute the subtask by reading a task handler registered in advance based on the handler ID specified in the request data.

Claims (20)

1. a first computing device equipped with a sensor;
   a plurality of second computing devices capable of communicating with each other;
   The first computing device includes:
   a sensing unit that acquires data from the outside using a sensor;
   a data transmitter that transmits the acquired data to one or more second computing devices;
   a result receiving unit that receives execution results of one or more tasks corresponding to the acquired data;
   an output unit that outputs the execution results of the one or more tasks,
   The second computing device includes:
   a data receiving unit that receives data from the first computing device;
   a task execution unit that executes a task using the received data;
   a task requesting unit that requests another computing device to execute the task along with the received data;
   a result receiving unit that receives task execution results from another computing device;
   A distributed processing system including: a result transmitter that transmits task execution results to other computing devices.
2. further comprising a plurality of third computing devices capable of communicating with each other,
   The third computing device includes:
   a data receiving unit that receives data from another computing device and a request to execute a task that processes the data;
   a task execution unit that executes the requested task based on the received data;
   a result transmitting unit that transmits the execution result of the task to another computing device,
   2. The task requesting unit of the second computing device selects either the second computing device or the third computing device as an execution entity of the task based on the task or the data to be processed. distributed processing system.
3. The distributed processing system according to claim 2, wherein the third computing device is equipped with a processor and configured as a fixedly installed secondary battery.
4. The third computing device includes:
   a task decomposition unit that decomposes the task requested by the second computing device into a plurality of subordinate tasks;
   a task distribution unit that distributes and allocates the plurality of lower-level tasks to a plurality of third computing devices;
   3. The distributed processing system according to claim 2, further comprising: a result receiving unit that receives an execution result of the lower task from a third computing device to which the lower task is assigned.
5. The task requesting unit of the second computing device includes:
   The distributed processing system according to claim 1, wherein when the own device does not satisfy the task execution condition, another second computing device is selected as the task execution entity.
6. The task requesting unit of the second computing device includes:
   The distributed processing system according to claim 5, wherein when the processing load of the own device does not satisfy the execution condition, another second computing device is selected as the task execution entity.
7. The task requesting unit of the second computing device includes:
   The distributed processing system according to claim 5, wherein when the power supply state of the own device does not satisfy the execution condition, another second computing device is selected as the task execution entity.
8. The task requesting unit of the second computing device includes:
   The distributed processing system according to claim 5, wherein when the specification information of the own device does not satisfy the execution condition, another second computing device is selected as the task execution entity.
9. The task requesting unit of the second computing device includes:
   9. The distributed processing system according to claim 8, wherein when the power consumption per unit calculation amount in the specification information of the own device does not satisfy the execution condition, another second computing device is selected as the task execution entity.
10. The task requesting unit of the second computing device includes:
    A claim for specifying in advance a second computing device capable of accepting a task among a plurality of second computing devices other than the own device, and requesting any of the one or more identified second computing devices to execute the task. The distributed processing system according to item 1.
11. The task requesting unit of the second computing device includes:
    2. The distributed processing system according to claim 1, wherein when requesting a task to another second computing device, the second computing device to be the main entity for executing the task is selected based on the communication state with the second computing device.
12. The task requesting unit of the second computing device includes:
    When requesting a task to another second computing device, one of the plurality of communication means provided in the second computing device to which the request is made is selected based on the data to be processed, and the selected one is The distributed processing system according to claim 1, wherein a task is requested via a communication means.
13. The second computing device includes:
    a data division unit that divides the received data into a plurality of data units;
    The distributed processing system according to claim 1, further comprising: a data transmitter that assigns a plurality of tasks for processing each of the plurality of data units to a plurality of second computing devices.
14. further comprising a payment device;
    The task requesting unit of the second computing device includes:
    requesting another computing device to execute the task, along with requester information that identifies the first computing device that is the source of the task;
    When the task execution unit of the second computing device executes the task, the task execution unit notifies the payment device of the execution of the task together with the information of the requester;
    The payment device is
    The distributed processing according to claim 1, further comprising a payment unit that instructs payment of a task execution fee from a user of the first computing device that is a task requester to a user of a second computing device that is a task requester. system.
15. a first computing device equipped with a sensor;
    a plurality of second computing devices capable of communicating with each other;
    a plurality of third computing devices capable of communicating with each other;
    The calculation capacity of the third calculation device is greater than the calculation capacity of the second calculation device,
    The first computing device transmits the data acquired by the sensor to any second computing device,
    The second computing device specifies one or more tasks that process the received data, and based on the identified tasks or data to be processed, the second computing device or the third computing device is configured to execute the task. A distributed processing system that selects one of the devices and instructs the selected computing device to execute the specified task.
16. includes multiple types of mobile devices that can communicate with each other,
    The first moving device is
    sensor and
    a sensing unit that acquires data from the outside using the sensor;
    a data transmitter that transmits the acquired data to another mobile device,
    The second moving device is
    a data receiving unit that receives data from another mobile device;
    an execution determination unit that determines whether a task can be executed based on data received from another mobile device;
    a task execution unit that executes a task based on data received from another mobile device;
    further comprising a data transmitter that transmits data received from another mobile device to the other mobile device,
    The execution determining unit of the second mobile device instructs the task execution unit to execute the task when the own device satisfies the execution condition, and instructs the task execution unit to transmit data to another mobile device when the execution condition is not satisfied. A distributed processing system.
17. further comprising a fixed computing device that is fixedly installed;
    The execution determination unit of the second mobile device further determines whether the mobile device or the fixed computing device is the execution entity of the task based on the task based on data received from another mobile device or the data to be processed. Select
    17. The data transmitting unit of the second mobile device transmits data received from another mobile device to the fixed computing device when the fixed computing device is selected as a task execution entity. Distributed processing system.
18. The second mobile device is a device capable of providing a specific service,
    The second moving device includes:
    A service provision department that provides services;
    a service identification unit that identifies a service corresponding to the execution result of the task;
    a service determination unit that determines whether the identified service can be provided by the own device;
    a service requesting unit that requests another mobile device to execute the identified service;
    The service determining unit instructs the service providing unit to provide the identified service if the identified service is a service that can be provided by the own device, and determines whether the identified service is provided by the own device. 17. The distributed processing system according to claim 16, wherein if the service is impossible, the service requesting unit is instructed to request the service to another mobile device.
19. Social infrastructure equipment configured to be able to communicate with each other, comprising a plurality of computing devices equipped with a processor along with both or one of a sensor and an output device,
    The computing device includes:
    a data receiving unit that receives data from a mobile terminal or other computing device owned by a user;
    a task execution unit that executes a subtask corresponding to the received data in parallel with the main task as social infrastructure equipment;
    a task requesting unit that requests another computing device to execute a subtask corresponding to the received data;
    a result receiving unit that receives the execution results of the subtask from another computing device;
    a result transmitting unit that transmits the execution result of the subtask to the mobile terminal or other computing device;
    an execution determination unit that determines whether the subtask can be executed in the own device;
    The execution determination unit instructs the task execution unit to execute the subtask when the own device satisfies the subtask execution condition, and instructs the task requesting unit to request the subtask to another computing device when the execution condition is not satisfied. A distributed processing system that provides instructions.
20. Some of the plurality of computing devices are surveillance cameras,
    The task execution unit of the computing device configured as the surveillance camera,
    20. The distributed processing system according to claim 19, wherein the subtask is executed in parallel with executing the monitoring function as the main task.

Images