WO2016207989A1 - 分散システム - Google Patents

分散システム Download PDF

Info

Publication number
WO2016207989A1
WO2016207989A1 PCT/JP2015/068119 JP2015068119W WO2016207989A1 WO 2016207989 A1 WO2016207989 A1 WO 2016207989A1 JP 2015068119 W JP2015068119 W JP 2015068119W WO 2016207989 A1 WO2016207989 A1 WO 2016207989A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
distributed system
module
data
nodes
Prior art date
Application number
PCT/JP2015/068119
Other languages
English (en)
French (fr)
Inventor
納谷　英光
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to CN201580080771.9A priority Critical patent/CN107615247A/zh
Priority to PCT/JP2015/068119 priority patent/WO2016207989A1/ja
Priority to JP2017524327A priority patent/JPWO2016207989A1/ja
Publication of WO2016207989A1 publication Critical patent/WO2016207989A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present invention relates to a distributed system that connects a plurality of sensors, a plurality of computers, and a plurality of computer environments via a network, communicates data and programs, and executes programs.
  • Patent Document 1 There is a distributed application such as Patent Document 1 in which a plurality of programs are separately executed by a plurality of computers connected via a network and each program is linked to operate like one application.
  • the program is statically arranged on the basis of the superiority or inferiority of local communication so that the priority of the distributed application is appropriately performed when a plurality of the distributed applications operate.
  • the present invention provides support for selecting the location of the program. As shown in the example of paragraph 0022 of Patent Document 1, the invention corresponds to a static computer environment that is closed like a factory production facility.
  • Patent Document 2 there is a distributed application of Patent Document 2 in which one application is executed by one master computer and an internal program is assigned to a plurality of slave computers connected via a network.
  • an internal program is assigned to a slave computer having a low load to distribute the load, and an invention for obtaining a final calculation result on the master computer It is. It is an implementation method of load balancing in a server / client type computer system.
  • M2M Machine to Machine
  • IoT Internet of Things
  • MQTT http://mqtt.org/
  • a predetermined static and fixed network topology information indicating the network topology and the attributes of each line constituting the network.
  • the location is presented based on the information. Therefore, when a network device or a computer is changed, a distributed application is changed, or a new distributed application is added, it is necessary to redo the arrangement.
  • the communication bandwidth which is one of the network specification information, is different from the ideal value in design and the bandwidth in actual operation in terms of continuity and bandwidth. There is a problem that it becomes difficult to maintain priority.
  • Patent Document 2 is a master / slave server / client type computing system having a centralized configuration, and as shown in FIG. 1, a small closed computer in which a plurality of computers can be directly connected to the same communication medium.
  • the environment is assumed. Therefore, in a large-scale open environment such as M2M and IoT configured with a protocol such as Non-Patent Document 1 that interconnects the sensor and the cloud via the Internet as described above, a large number of client computers and a huge amount There is a problem that it is difficult to construct a configuration in which a quantity of sensors and controllers are managed by a master computer. That is, in the M2M and IoT interconnection environment, a P2P (Peer to Peer) configuration is required instead of the server / client type.
  • P2P Peer to Peer
  • An object of the present invention is to provide a distributed system capable of efficient processing as a whole system by dynamically determining a node for executing an execution module in a distributed system having a plurality of nodes connected by a network. It is.
  • a property related to an execution condition is assigned to an execution module executed on the node, and the execution is performed according to the property and an internal state of the distributed system.
  • a node for executing the module is determined.
  • efficient processing can be performed as a whole system by dynamically determining a node for executing an execution module.
  • a plurality of program modules constituting the program are used as nodes.
  • a method of dynamically distributing a program module by assigning properties as execution conditions of the module to the program module, measuring a network state and a computer state, and a program module based on the result and property of the measurement unit
  • the present invention relates to a dynamic distribution method having determination means for determining a node for executing the program and means for moving the program module between nodes. Note that the processing progress of the program module, the data accumulation status, and the arrangement status may be stored, and the program module may be arranged according to the storage status. Further, it is possible to extract the rate-determining step according to the storage status and present the optimum property.
  • FIG. 1 A schematic diagram of a distributed system in the first embodiment is shown in FIG.
  • a device 11 such as a sensor, a controller 12, a gateway 13, a router 14, a final domain 15 such as a cloud having a plurality of computers including a server, and components connected to these networks are collectively referred to as a node 30.
  • each node is hierarchically arranged from the device 11 which is a lower node to the final domain 15 which is an upper node.
  • a plurality of nodes such as switches installed to connect a plurality of nodes are omitted in FIG.
  • the communication path 21 that connects the sensor device 11 and the controller 12 has wiring for exchanging physical data such as voltage, SPI, I2C for exchanging physical data as digital data, a high-speed wired network, or a low-speed low-speed network. It is common to use wireless communication with power consumption or wireless communication with high speed and high power consumption.
  • the communication path 22 connecting the controller 12 and the gateway 13 is generally a high-speed wired network, Wi-Fi, as with the communication path 21.
  • High-speed wired networks are also common in the LAN 23 that connects the gateway 13 and the router 14 and the WAN 14 that connects the router 14 and the final domain 15.
  • the types and configurations of the nodes connected to the distributed system in this embodiment are only examples and are not limited to this.
  • the final domain is often configured by gateways such as routers and firewalls.
  • the communication media of the communication path can be broadly classified into wired and wireless, and either may be adopted. Note that there are mobile phone terrestrial communication networks that can always be connected to radio, and satellite communication networks that cannot be connected depending on the time of day, but in this embodiment, such communication media differences are concealed. Is also effective.
  • FIG. 2 shows an example of the internal structure of the node 30 in this embodiment. Since the node 30 can correspond to any of the nodes 11, 12, 13, 14, and 15 shown in FIG. 1, the reference numeral is different from the reference numerals 11 to 15 that can specify a specific node. 30 is used.
  • a property related to the execution condition is given to the execution module executed by the node 30, and the node that executes the execution module is determined according to the property 80 and the internal state of the distributed system.
  • the internal state of the distributed system include the processing state of the nodes 30 constituting the distributed system and the communication state between the nodes 30.
  • the processing status of the node 30 is specifically the processing capability (or processing load) or storage capability (that is, storage capacity) of the node 30, and the communication status is the size of communication capability or communication band. It is.
  • Such an internal state can change over time, and therefore, in this distributed system, a node executing an execution module can change over time.
  • the distributed system has a plurality of hierarchies, but the hierarchies constituting the distributed system may change with time.
  • An example of the temporal change of the hierarchy is described with reference to FIG. 1. “From the state in which the device 11, the controller 12, the gateway 13, the router 14, and the final domain 15 are sequentially configured from the initial lower layer to the upper layer, The controller 12 and the final domain 15 communicate directly without going through intermediate nodes such as the router 14 and the router 14 ”.
  • the execution environment 40 is an environment in which the module 50 operates.
  • the module 50 is a processing unit that processes and generates the data 60 based on one or more devices 11.
  • the module 50 is a module that executes processing, and therefore can be referred to as an execution module.
  • the moving means 71 is means for moving the module 50 and the data 60 to another node 30.
  • the measuring unit 72 is a unit that measures a state related to the node 30.
  • the determination unit 73 is a unit that determines whether or not the module 50 should be moved based on the state obtained by the measurement unit 72 and the data recorded in the property 80.
  • the property 80 includes a processing performance 81 necessary for the execution of the module 50, a delay time 82 allowed for the execution time of the module 50, and a communication band 83 required for communication of the data 60 related to the execution of the module 50.
  • the capacity 84 of the storage area necessary for storing the data 60 related to the execution of the module 50 is recorded.
  • a general environment of the execution environment 40 includes an operating system (OS).
  • OS operating system
  • the OS has hardware dependency and OS-specific elements, so there is a case where the OS is not compatible. If the OS is uniquely determined when constructing the distributed system, the system configuration becomes inflexible.
  • an interpreter and a virtual machine (VM) operating on the OS.
  • the movement of the module 50 between the nodes 30 can be realized by transferring an executable file and a static / dynamic library in the above-described OS.
  • the data format of the module 50 is determined and can be realized by transferring the data. For example, an intermediate format is defined in a kind of programming language environment popular in interpreters.
  • the serialized data format of the module is defined and can be realized by transferring the data.
  • a popular VM interpreter enables data transfer between nodes by means of serialization.
  • the VM execution environment the VM execution environment set is managed as a file, and the execution environment can be directly executed on another node.
  • the processing performance 81, the delay time 82, the communication band 83, and the storage capacity 84 are presented as the property 80 as an example.
  • the property is determined according to the request related to the module 50 and the operation status. This is not the case.
  • execution start timing of the determination unit 73 may be executed by periodic execution by the scheduler or by an event managed by the execution environment 40.
  • an interrupt process installed in a general OS may be used.
  • FIG. 3 shows a configuration example of a distributed system including a plurality of nodes.
  • a series of processes for obtaining sensor data, pre-processing the data to generate intermediate data, and post-processing the intermediate data to obtain resultant data is performed.
  • the measurement module 51 measures the data of the sensor device 11 and generates sensor data 61.
  • the preprocessing module 52 preprocesses the sensor data 61 to generate intermediate data 62.
  • the post-processing module 33 based on the intermediate data 62 from the pre-processing module 32, the post-processing module 53 post-processes the intermediate data 62 and generates result data 63.
  • the sensor node 31 corresponds to the device 11 in FIG. 1
  • the post-processing module 33 corresponds to any one of the nodes 30 in the final domain 15 in FIG. 1
  • the pre-processing module corresponds to the property 80.
  • This node 30 is processed.
  • the processing nodes are two nodes, a preprocessing node and a postprocessing node, but this is not restrictive.
  • the number of modules 50 and the processing content depend on the requirements and operational status of the entire system.
  • FIG. 4 shows an outline up to the system configuration distributed to a plurality of nodes shown in the third embodiment.
  • FIG. 4 (a) corresponds to a system configuration in which the data of the end sensor in IoT is aggregated into the end cloud system and subjected to large-scale processing.
  • This configuration is a configuration that only connects the majority of sensors and the cloud system, and is easy to construct.
  • the sensor node 91 includes one or more sensor devices 11, and the measurement module 51 operates on the execution environment 40 and acquires a large amount of sensor data 61 from the sensor device 11.
  • the application node 92 includes a pre-processing module 52 that processes the sensor data 61 and generates aggregated intermediate data 62, and a post-processing module that processes the intermediate data 62 and generates result data 63. Both the sensor node 91 and the application node 92 have a moving unit 61, a measuring unit 72, and a determining unit 73.
  • the determination unit 73 determines that the communication load is reduced by the intermediate data 62 having a smaller capacity than the sensor data 61, for example, according to the property 80 associated with each of the modules 52 and 53, As shown in FIG. 4B, the preprocessing module 52 is transferred to the node 93 by the moving means 71 so that it can be executed by another node 93, and the processing is executed in the execution environment 40 of the node 93.
  • FIG. 5 shows a flowchart relating to the movement of the program module 50 shown in FIG.
  • the measuring means 72 of the application node 92 searches for a communication partner via the networks 21, 22, 23, and 24, and acquires a list of nodes 30 that pass through the network (S10).
  • the measuring means 72 of the application node 92 measures the status of the own node 30 according to the item recorded in the property 80 (S20). Further, the measuring means 72 acquires the other node status of the node list (S30). Based on the property 80 assigned to each of the modules 52 and 53, the judging means 73 of the application node 92 selects an appropriate node 30 among its own node and other nodes (S40).
  • the preprocessing module 52 determines that the intermediate data 62 should be generated by the selection node 93. If the selected node is its own node, the process is continued (S42). If the selected node is another node, the communication partner of the intermediate data 62 of the preprocessing module 52 is set as the own node and transferred to the selected node 93 (S50).
  • the selection node 93 receives the module 52 (S52).
  • the transfer destination node 30 is requested to start the transferred preprocessing module 52 (S60).
  • the selection node 93 receives the activation request and activates the preprocessing module 52 (S62).
  • the application node 92 notifies the currently communicating sensor node 91 of the change to the transfer destination node 93 (S70). .
  • the sensor node 91 changes the communication destination from the application node 92 to the transfer destination node 93 (S72).
  • the connection synchronization of the sensor node 91, the transfer node 93, and the application node 92 is completed (S80).
  • ⁇ Sensor cloud (program to sensor)> 4 and 5 show an example in which the program exists in the cloud, but the following FIGS. 6 and 7 show examples in which the program exists in the sensor.
  • FIG. 6 shows an example of program / module movement status in an environment where the computer resources and the network communication bandwidth are insufficient.
  • FIG. 6A corresponds to a monitoring node 95 that constitutes a large-scale monitoring center that remotely monitors information of a large number of sensors installed at remote locations in IoT.
  • This configuration is a configuration that only connects the majority of sensors and the cloud system, and is easy to construct.
  • the sensor node 94 includes at least one sensor device 11, and includes a measurement module 51, a preprocessing module 52, and a postprocessing module 53 so that the node can generate the result data 63.
  • the measurement module 51 acquires a large amount of sensor data 61 from the sensor device 11 by operating.
  • the preprocessing module 52 processes the sensor data 61 to generate intermediate data 62.
  • the post-processing module 53 generates result data 63.
  • the result data 63 is transferred to the monitoring node 95 via the networks 21, 22, 23 and 24.
  • Both the sensor node 91 and the application node 92 have a moving unit 61, a measuring unit 72, and a determining unit 73.
  • the determination unit 73 determines that the sensor node is suitable only for the execution of the measurement module 51 according to the property 80 attached to each of the modules 52 and 53, as shown in FIG.
  • the processing module 52 and the post-processing module 53 are transferred to other nodes and executed in the execution environment 40.
  • the transfer node 93 is not suitable for the property 80, the post-processing module 53 is further transferred to the monitoring module 95 and executed.
  • a sensor node with insufficient computer resources is installed as a measurement target and is connected to a node that receives processing results via a network with insufficient communication bandwidth
  • the sensor nodes can be connected to the network only by connecting them to the network.
  • modules are dynamically arranged at appropriate nodes, so that sufficient processing performance can be obtained for the entire system.
  • FIG. 7 shows a flowchart relating to the movement of the program module 50 in the sixth embodiment.
  • the measuring unit 72 of the sensor node 94 searches for a communication partner via the networks 21, 22, 23, and 24, and acquires a list of nodes 30 that pass through the network (S110).
  • the measuring means 72 of the sensor node 94 measures the status of the own node 30 according to the item recorded in the property 80 (S120).
  • the measuring means 72 acquires other node statuses in the node list (S130).
  • the determination means 73 of the sensor node 92 selects an appropriate node 30 among the own node and other nodes based on the property 80 assigned to each module 52, 53 (S140).
  • the preprocessing module 52 and the postprocessing module 53 determine that the selection node 96 should generate the intermediate data 62. If the selected node is its own node, the process is continued (S142). If the selected node is another node, the communication partner of the preprocessing module 52 is set as the own node and transferred to the selected node 93 (S150). The selection node 93 receives the modules 52 and 53 (S152). The transfer destination node 30 is requested to start the transferred pre-processing module 52 and post-processing module 53 (S160).
  • the selection node 96 receives the activation request and activates the pre-processing module 52 and the post-processing module 53 (S162).
  • the sensor node 94 notifies the monitoring node 95 that is currently communicating to the change to the transfer destination node 96 (S170).
  • the monitoring node 95 changes the communication destination from the sensor node 94 to the transfer destination node 96 (S172).
  • connection synchronization of the sensor node 94, the selection node 96, and the monitoring node node 95 is completed (S180).
  • a change has occurred in the selection node 96 by newly executing the pre-processing module 52 and the post-processing module 53 in the execution environment 40.
  • the measuring means 72 of the selected node 96 searches for communication partners via the networks 21, 22, 23, and 24, and acquires a list of nodes 30 that pass through the network (S190).
  • the measuring means 72 of the selected node 96 measures the status of the own node 30 according to the item recorded in the property 80 (S200). Further, the measuring means 72 acquires the other node status of the node list (S210).
  • the determination means 73 of the selection node 96 selects an appropriate node 30 among its own node and other nodes based on the property 80 assigned to each module 52, 53 (S220). In this embodiment, it is assumed that the post-processing module 53 determines that the monitoring node 95 should generate the result data 63. If the selected node is its own node, the process is continued (S222). If the selected node is another node, the communication partner of the post-processing module 53 is set as its own node and transferred to the selected node 95 (S230).
  • the monitoring node 95 receives the post-processing module 53 (S232).
  • the monitoring node 95 is requested to start the transferred post-processing module 53 (S240).
  • the monitoring node 95 receives the activation request and activates the post-processing module 53 (S242).
  • the selection node 96 notifies the monitoring node 95 that is currently communicating with the change to the monitoring node 95 (S250).
  • the monitoring node 95 changes the communication destination from the sensor node 94 to the transfer destination node 96 (S252).
  • the connection synchronization of the sensor node 94, the selection node 96, and the monitoring node 95 is completed (S18).
  • the module 50 is transferred to the appropriate node 30 dynamically by transferring the module 40 according to the determination means 73 via the networks 21, 22, 23, and 24. can do. That is, according to this embodiment, in an environment in which a plurality of sensors and a plurality of computers are connected to a network, a plurality of program modules constituting the program are dynamically calculated according to the network communication status and the computer status. It is possible to provide an environment that can be moved between and executed. Also, by using the dynamic distribution method, program modules are dynamically executed according to network path changes, load fluctuations, and computer conditions. Therefore, it is not necessary to statically configure the network configuration such as network priority and master / slave, and it can be used effectively even in the environment where it is difficult to determine the network priority and the computer resources change sequentially like the Internet. It becomes possible.
  • the execution state of the system changes greatly, there are two stages: a stage in which the status of a measurement target is learned based on sensor data and a stage in which the measurement target is constantly diagnosed based on the learning result. It is an example of the system which has.
  • the controller 96 installed in the measurement target is connected to the sensor device 11 and acquires the sensor data 111 by the measurement module 51.
  • the feature extraction module 101 extracts feature data 62 from the sensor data 111.
  • the learning module 102 generates learning data 112 based on the feature data 62.
  • the diagnostic module 103 makes a determination of normality / abnormality, generates abnormal data 113 in the case of abnormality, and causes an abnormality in the center 97 installed in the final domain 15. Data 113 is notified.
  • the processing of the learning module 102 is large, and it is difficult for the controller 96 to process and store a huge amount of sensor data 111.
  • the property 80 has to be set so that it is difficult to execute it by the controller 96.
  • the feature extraction module 101 is executed by the relay node 98 installed between the center 97 and the feature data 62 is generated from the sensor data 111.
  • the learning module 102 Based on the feature data 62 generated at the relay node 98, the learning module 102 generates learning data 112 at the center 97.
  • the controller 96 performs diagnosis processing on the sensor data 111 by the diagnosis module 103 based on the learning data 112, determines normality / abnormality, and if abnormal, abnormal data 113 is generated, and abnormal data is notified to the center 97 via the networks 21, 22, 23, and 24.
  • Example 3 shows an example in which the entire system configuration is easily changed by changing the property.
  • the present embodiment is an example applied to a controller 300 of an automatic driving of a car or a safety control system.
  • FIG. 9A shows the sensor 16, the actuator 17, and the controller 300 that are mounted on, for example, an automobile.
  • the sensor 16 includes a sensor corresponding to various dimensions such as a one-dimensional distance sensor, a two-dimensional camera, a three-dimensional stereo camera, and a laser range finder.
  • the dimension processing module 201 generates feature data 212 based on the multidimensional data 211 obtained from these sensors.
  • the feature data 212 includes distance data and object detection results.
  • the recognition module 202 generates recognition data 213 based on the feature data 212.
  • the control module 203 Based on the recognition data 213, the control module 203 generates control data 214 that is a target value for operating the actuator 17.
  • the actuator 17 includes a brake actuator for braking, a steer actuator for steering, an accelerator actuator for acceleration / deceleration, and the like.
  • This configuration is a schematic configuration of ADAS which is the current auto cruise control and safety equipment. In this configuration, since the sensor device 11 and the processing module 50 are mounted on each vehicle body, it tends to be costly, and there is a possibility that cooperation between vehicles is difficult to achieve.
  • the generation of the feature data 201 is performed on the vehicle, and the generation of the recognition data 213 and the generation of the control data 214 are performed.
  • the multidimensional data 221 from the sensor 16 is transferred via the networks 21, 22, 23, and 24.
  • the data is transmitted to the road system 320, and the dimension processing module 201, the recognition module 202, and the control module 203 can be implemented on the road system 320 side.
  • the control system 300 As described above, by installing the control system 300 in all automobiles as shown in FIG. 9A, a driver-centered autonomous system can be constructed. However, the control system 300 is expensive because high performance is required, and it is difficult to manage an enormous amount of the control system 300 in cooperation with each other.
  • the recognition module 202 and the control module 203 can be executed by an external node, so that the cost can be reduced by reducing the processing capacity of the control system 300. Become.
  • the recognition module 202 and the control module 203 that are less dependent on hardware in the control system 300 outside the vehicle (for example, on the ground), the scalability of the recognition module 202 and the control module 203 is ensured and the modules are linked.
  • the ground systems 310 and 320 may be installed, for example, on the side of a road where road-to-vehicle communication is possible, or may be the final domain 15 installed at a long distance if communication delay is acceptable. Absent.
  • the recognition module 202 and the control module 203 are executed in the facility on the ground side, it is possible to change the recognition module 202 with improved accuracy, or change to the control module 203 that can execute accurate control. .
  • FIG. 9C only the sensor 17 and the actuator 16 are mounted on the car, and the multidimensional data 211 measured by the sensor 16 is grounded via the networks 21, 22, 23, and 24.
  • the system 320 enables a shift to an automatic driving system that manages recognition and control in a centralized manner.
  • the execution environment is exemplified by software such as OS and VM environment, but may be hardware, and the hardware execution environment is a re-configurable device.
  • PLD and FPGA can be considered.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本発明の目的は、ネットワークで接続された複数のノードを有する分散システムにおいて、実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能な分散システムを提供することである。 本発明は、ネットワークで接続された複数のノードを有する分散システムにおいて、前記ノードで実行される実行モジュールに実行条件に関するプロパティが付与され、前記プロパティと、前記分散システムの内部状態に応じて前記実行モジュールを実行するノードが決定されることを特徴とする。

Description

分散システム
この発明は、複数のセンサと複数の計算機及び複数の計算機環境とをネットワークを介して接続し、データ及びプログラムの通信を行い、プログラムを実行する分散システムに関する。
　複数のプログラムを、ネットワークで接続された複数の計算機で別々に実行し、各プログラムを連携させることで一つのアプリケーションのように動作する特許文献１のような分散アプリケーションがある。特許文献１の分散アプリケーションでは、ローカルな通信の優劣度を基にプログラムを静的に配置することで、該分散アプリケーションが複数動作する場合に、分散アプリケーションの優先度が適正に行われることを目的に、該プログラムの配置場所の選択支援を行う発明である。特許文献１の段落００２２の例で示しているように、工場生産設備のように閉じた静的な計算機環境に対応した発明である。
　また、一つのアプリケーションを一つのマスター計算機で実行し、内部プログラムをネットワークで接続された複数のスレーブ計算機に割り当てて動作するような特許文献２の分散アプリケーションがある。特許文献２の分散アプリケーションでは、マスター計算機において分散アプリケーションを実行するときに、内部プログラムを負荷の少ないスレーブ計算機に担当させることで負荷分散を図り、マスター計算機で最終的な計算結果を得るための発明である。サーバ・クライアント型の計算機システムでの、負荷分散の一実装方式である。
　なお、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）と呼ばれるセンサ及び計算機をインターネット経由で相互接続を実施する環境では、ＭＱＴＴ（http://mqtt.org/）を一例とするプロトコルが使用されており、センサとクラウドとを接続する形態が一般的となっている。
特開２００９－２８２６５２号公報 特開平０６－３４８６６６号公報
　特許文献１の発明では、段落００１４に示されているように、ネットワークのトポロジ-およびネットワークを構成する各回線の属性が示されたネットワーク仕様情報、という事前に決定された静的で且つ固定の情報を基に配置場所を提示するものである。よって、ネットワーク機器や計算機の変更、分散アプリケーションに変更および新たな分散アプリケーションが追加になった場合には、配置をやり直す必要が生じる。また、ネットワーク仕様情報の一つである通信帯域は設計上の理想値と実運用での帯域は定常度および帯域幅が異なるため、ネットワークの経路変更や負荷変動によって、特許文献１が目的とする優先度の維持が困難になる問題点がある。
　特許文献２の発明では、中央集権構成となるマスター、スレーブのサーバ・クライアント型計算システムであり、図１に示すように、同一の通信媒体に複数の計算機が直接接続できる小規模の閉じた計算機環境を前提としている。そのために、上述のようなセンサとクラウドをインターネットで相互接続する非特許文献１のようなプロトコルで構成されるＭ２Ｍ、ＩｏＴのような大規模な開かれた環境では、多数のクライアント計算機や膨大な量のセンサ・コントローラをマスター計算機で管理する構成を構築することは困難であるという問題がある。つまり、Ｍ２Ｍ、ＩｏＴの相互接続環境では、サーバ・クライアント型ではなくＰ２Ｐ（Ｐｅｅｒ　ｔｏ　Ｐｅｅr）構成が必要となる。
　本発明の目的は、ネットワークで接続された複数のノードを有する分散システムにおいて、実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能な分散システムを提供することである。
　本発明は、ネットワークで接続された複数のノードを有する分散システムにおいて、前記ノードで実行される実行モジュールに実行条件に関するプロパティが付与され、前記プロパティと、前記分散システムの内部状態に応じて前記実行モジュールを実行するノードが決定されることを特徴とする。
　本発明によれば、ネットワークで接続された複数のノードを有する分散システムにおいて、実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能なとなる。
本発明の分散システムの概略図 本発明におけるプログラム・モジュール及びプロパティの構成図 本発明における複数ノードで構成される分散システムの例 計算機リソースは十分であるが、ネットワーク通信帯域が不十分な環境における、プログラム・モジュールの移動の例 図４におけるプログラム・モジュール移動のフローチャート 計算機リソース及びネットワーク通信帯域が不十分な環境における、プログラム・モジュールの移動の例 図６におけるプログラム・モジュール移動のフローチャート 本発明におけるデータ生成の有無によって、プログラム・モジュールの移動の例 本発明における自動制御モジュールが車上、地上を行き来する図
　以下、本発明の実施形態に係る分散システムの実施例を示す。
　本実施例に係る分散システムは、ネットワークに接続される構成単位（ノード）である複数のセンサ及び複数の計算機がネットワークに接続された計算機環境において、プログラムを構成する複数のプログラム・モジュールをノードに動的に分散させる方法であって、プログラム・モジュールに該モジュールの実行条件となるプロパティを付与し、ネットワークの状態及び計算機の状態を計測する手段と、該計測手段の結果とプロパティによりプログラム・モジュールを実行するノードを決定する判断手段と、該プログラム・モジュールがノード間で移動する手段と、を有する動的分散方法に関するものである。なお、プログラム・モジュールの処理経過、データの蓄積状況、配置状況を記憶し、該記憶状況に応じて、該プログラム・モジュールを配置してもよい。また、該記憶状況に応じて律速段階を抽出して、最適なプロパティを提示してもよい。
　＜概略構成＞
実施例１における分散システムの概略図を図１に示す。センサ等のデバイス１１、コントローラ１２、ゲートウェイ１３、ルータ１４、サーバをはじめとする複数の計算機を有するクラウド等の最終ドメイン１５、これらネットワークに接続される構成物を総称してノード３０と呼ぶ。この分散システムでは、下位のノードであるデバイス１１から上位のノードである最終ドメイン１５に至るまで、各ノードが階層的に配置されている。なお、複数のノードを接続するために複数設置されるスイッチのようなノードは図１では省略している。
　センサデバイス１１とコントローラ１２を繋ぐ通信路２１、コントローラ１２とゲートウェイ１３を接続する通信路２２、ローカルエリアネットワークＬＡＮ２３と、外部ネットワークとの接続を担うルータ１４、インターネットを代表とするワイドエリアネットワークＷＡＮ２４、とがある。これらを総称してネットワーク２０と呼ぶ。センサデバイス１１とコントローラ１２を繋ぐ通信路２１には、電圧等の物理的データをやりとりするためにワイヤリング、物理データをデジタルデータとしてやりとりするためのＳＰＩ、Ｉ２Ｃ、さらに高速な有線ネットワーク、もしくは低速低消費電力の無線通信もしくは高速大消費電力の無線通信を利用するが一般的である。コントローラ１２とゲートウェイ１３を接続する通信路２２には、通信路２１と同様に高速有線ネットワーク、Ｗｉ－Ｆｉが一般的である。ゲートウェイ１３とルータ１４を結ぶＬＡＮ２３、ルータ１４と最終ドメイン１５を結ぶＷＡＮ１４にも高速有線ネットワークが一般的である。
　本実施例における分散システムに接続されているノードの種類及び構成は一実施例であってこの限りではない。例えば最終ドメイン内も、ルータやファイアウォールを始めとするゲートウェアによって構成されている場合が多い。また、通信路の通信メディアとしては大きく分けて有線、無線があるがどちらを採用しても構わない。なお、無線には常時接続可能が携帯電話の地上通信網や、時間帯によっては接続が不可能となる衛星通信網があるが、本実施例ではこのような通信メディアの差異を隠蔽するのにも有効である。
　＜ノードとプロパティ＞
　図２では、本実施例におけるノード３０の内部構造の一例を示す。なお、ノード３０は、図１に示した各ノード１１、１２、１３、１４、１５のいずれかもが該当し得るものであるため、具体的なノードを特定し得る符号１１～１５とは異なる符号３０を用いている。
　本実施例の分散システムでは、ノード３０で実行される実行モジュールに実行条件に関するプロパティが付与され、この実行モジュールを実行するノードは、プロパティ８０と、分散システムの内部状態に応じて決定される。ここで、分散システムの内部状態としては、分散システムを構成するノード３０の処理状態や、各ノード３０間の通信状態が挙げられる。また、ノード３０の処理状態とは、具体的には、ノード３０の処理能力（又は処理負荷）や記憶能力（即ち、記憶容量）であり、通信状態とは、通信能力や通信帯域の大きさである。このような内部状態は、時間的に変化し得るものであり、従って、この分散システムでは、実行モジュールを実行するノードが時間的に変化し得る。また、上述のように、分散システムは複数の階層を有するものであるが、分散システムを構成する階層が時間的に変化する場合もある。階層の時間的変化とは、図１を用いて一例を説明すると、「当初下層から上層にかけて順にデバイス１１、コントローラ１２、ゲートウェイ１３、ルータ１４、最終ドメイン１５で構成されていた状態から、ゲートウェイ１３やルータ１４といった中間のノードを経由しないでコントローラ１２と最終ドメイン１５とが直接通信する」といったように、階層構造が変化することである。
　実行環境４０は、モジュール５０が動作する環境である。モジュール５０は一つ以上のデバイス１１を基にデータ６０を処理・生成をする処理単位である。なお、モジュール５０は、処理を実行するモジュールであることから、実行モジュールと称することができる。移動手段７１はモジュール５０及びデータ６０を他のノード３０に移動する手段である。計測手段７２はノード３０に係る状態を計測する手段である。判断手段７３は、計測手段７２で得られた状態とプロパティ８０に記録されたデータを基に、モジュール５０を移動すべきか否かを判断する手段である。具体的には、プロパティ８０には、モジュール５０の実行に必要な処理性能８１、モジュール５０の実行時間に許容される遅延時間８２、モジュール５０の実行に係るデータ６０の通信に必要な通信帯域８３、同様にモジュール５０の実行に係るデータ６０の記憶に必要な記憶領域の容量８４等が記録されている。
　実行環境４０の一般的な環境には、オペレーティング・システム（ＯＳ）がある。ただしＯＳには、ハードウェア依存性やＯＳ固有要素があるために、ＯＳ間で互換性が無い場合がある。分散システムを構築する際にＯＳを一意に決定しまうとシステム構成に柔軟性がなくなる。そこで、ＯＳ依存性を解消するために、ＯＳ上で動作するインタープリタや仮想マシン（ＶＭ）がある。ノード３０の間でのモジュール５０の移動は、前述のＯＳであれば、実行形式のファイル、静的・動的ライブラリを転送することで実現できる。インタープリタの場合には、モジュール５０のデータ形式が定められており、該データを転送することで実現できる。例えば、インタープリタで普及しているプログラミング言語環境の一種では中間形式が定められている。ＶＭの場合にも同様に、モジュールのシリアライズデータ形式が定められており、該データを転送することで実現できる。例えば普及しているＶＭ型インタープリタでは、シリアライズという手段によって、ノード間でのデータ転送を可能としている。ＶＭ実行環境では、ＶＭ実行環境一式をファイルとして管理しており、該実行環境をそのまま別のノードで実行させることを可能としている。本実施例では、プロパティ８０に処理性能８１、遅延時間８２、通信帯域８３、記憶容量８４を例として提示したが、該プロパティは、モジュール５０に係る要求や運用状況に応じて決定するものであり、この限りではない。
　なお、判断手段７３の実行開始タイミングは、スケジューラによる定期的実行、若しくは実行環境４０で管理するイベントによって実行しても良い。例えば一般的なＯＳに搭載されている割込み処理でも構わない。
　＜ノード分散＞
図３は、複数ノードで構成される分散システムの構成例を示す。この構成例では、センサのデータを取得して、該データに前処理を施して中間データを生成し、該中間データを後処理して結果となるデータを得る一連の処理が行われる。センサノード３１では、計測モジュール５１がセンサデバイス１１のデータを計測し、センサデータ６１を生成する。
　前処理ノード３２では、センサノード３１からのセンサデータ６１を基に、前処理モジュール５２がセンサデータ６１を前処理して中間データ６２を生成する。後処理ノード３３では、前処理モジュール３２からの中間データ６２を基に、後処理モジュール５３が中間データ６２を後処理して結果データ６３を生成する構成例である。この構成例では、センサノード３１が図１のデバイス１１に対応し、後処理モジュール３３が図１の最終ドメイン１５内のいずれかのノード３０に対応し、前処理モジュールがプロパティ８０に応じて何れかのノード３０にて処理される構成となる。本実施例では、処理ノードを前処理ノードと後処理ノードの２ノードとしているがこの限りではない。モジュール５０の個数や処理内容は、システム全体に対する要求や運用状況によって左右されるものである。
　＜センサークラウド（クラウドにプログラム）＞
図４では、実施例３で示した複数ノードに分散されるシステム構成に至るまでの概略を示す。この例では、計算機リソースは十分である最終ドメイン１５と、ネットワーク２１、２２、２３、２４の通信帯域が不十分である環境でセンサノード９１と接続する場合の、プログラム・モジュールの移動状況の一例である。
　図４（ａ）は、ＩｏＴにおける、末端のセンサのデータを終端のクラウドシステムに集約して大規模な処理を施すシステム構成に相当する。この構成は、大多数のセンサとクラウドシステムを接続するだけの構成であり、構築が容易である。
　センサノード９１は、一つ以上のセンサデバイス１１を有し、計測モジュール５１は実行環境４０上で動作してセンサデバイス１１から多量のセンサデータ６１を取得する。アプリケーションノード９２は、該センサデータ６１を処理して集約された中間データ６２を生成する前処理モジュール５２、該中間データ６２を処理して結果データ６３を生成する後処理モジュールを有する。なお、センサノード９１、アプリケーションノード９２はともに、移動手段６１、計測手段７２、判断手段７３を有する。
　この構成において、該センサ群とクラウドシステムを繋ぐネットワークの通信帯域が十分でない場合センサのデータの取得が困難となる。その場合、判断手段７３が各モジュール５２，５３に付随するプロパティ８０に応じて、前処理モジュール５２が、例えばセンサデータ６１よりも容量の少ない中間データ６２で通信負荷が軽減されると判断し、図４（ｂ）に示すように、別のノード９３で実行できるように移動手段７１により、前処理モジュール５２を該ノード９３に転送し、該ノード９３の実行環境４０にて処理を実行する。
　上記で説明したように、計算機リソースが十分にあるクラウドやサーバと、複数のセンサを接続する、Ｍ２ＭやＩｏＴの分散システムを、通信帯域が不十分なネットワークを経由して構成する場合に、従来であれば通信がボトルネックとなって十分な処理性能が得られない場合でも、上述した処理を行えば、クラウドやサーバと複数のセンサを結ぶネットワーク上のノードを有効活用できるとともに、ノード間を結ぶネットワーク帯域及びノードの性能に応じて、動的に適切なノードにモジュールが配置されることによってシステム全体として十分な処理性能が得られる。
　図５は、図４で示したプログラム・モジュール５０の移動に係るフローチャートを示す。アプリケーションノード９２の計測手段７２は、ネットワーク２１、２２、２３、２４を経由して通信相手先を探索して該ネットワーク上で経由するノード３０の一覧を取得する（Ｓ１０）。
　アプリケーションノード９２の計測手段７２はプロパティ８０に記録された項目に応じて自ノード３０の状況を計測する（Ｓ２０）。さらに計測手段７２はノード一覧の他ノード状況を取得する（Ｓ３０）。アプリケーションノード９２の判断手段７３は各モジュール５２，５３に付与されたプロパティ８０を基に、自ノード及び他ノードで適当なノード３０を選択する（Ｓ４０）。
　例えば、前処理モジュール５２が選択ノード９３で中間データ６２を生成するのが良いと判断したとする。選択ノードが自ノードの場合には、処理を継続する（Ｓ４２）。選択ノードが他ノードの場合には、選択したノード９３に前処理モジュール５２の中間データ６２の通信相手を自ノードと設定して転送する（Ｓ５０）。
　選択ノード９３は、該モジュール５２を受信する（Ｓ５２）。転送先ノード３０に、転送した前処理モジュール５２の起動を依頼する（Ｓ６０）。選択ノード９３は、起動の依頼を受領して前処理モジュール５２を起動する（Ｓ６２）アプリケーションノード９２は、現在通信しているセンサノード９１に、転送先ノード９３への変更を通知する（Ｓ７０）。
　センサノード９１は通信先をアプリケーションノード９２から転送先ノード９３に変更する（Ｓ７２）。以上により、センサノード９１、転送ノード９３、アプリケーションノード９２の接続同期が完了する（Ｓ８０）。このように、プロパティ８０に応じて、モジュール３０を実行するのに適切なノード３０を動的に選択することにより、Ｍ２Ｍ、ＩｏＴのような大規模で且つ運用状態が流動的な分散システムにおいてもシステムが効率的に運用することが可能となる。
　＜センサークラウド（センサにプログラム）＞
図４及び図５の例では、クラウドにプログラムが存在する例を示したが、次の図６、７では、センサにプログラムが存在する例を示す。
　図６では、計算機リソース及びネットワークの通信帯域が不十分である環境における、プログラム・モジュールの移動状況の一例を示す。この例では、莫大な個数のセンサノード９４を、ネットワーク２１、２２、２３、２４を経由して、最終ドメイン１５に設置された監視ノード９５を接続する場合の、プログラム・モジュールの移動状況の一例である。図６（ａ）は、ＩｏＴにおける、遠隔地に多数設置したセンサの情報をリモート監視する大規模監視センターを構成する監視ノード９５に相当する。この構成は、大多数のセンサとクラウドシステムを接続するだけの構成であり、構築が容易である。
　センサノード９４は、少なくとも一つ以上のセンサデバイス１１を有し、該ノードで結果データ６３を生成できるように、計測モジュール５１、前処理モジュール５２、後処理モジュール５３を有し、実行環境４０で動作させることで、計測モジュール５１は、センサデバイス１１から多量のセンサデータ６１を取得する。前処理モジュール５２は、該センサデータ６１を処理して中間データ６２を生成する。後処理モジュール５３は、結果データ６３を生成する。結果データ６３はネットワーク２１、２２、２３、２４を経由して監視ノード９５に転送される。なお、センサノード９１、アプリケーションノード９２はともに、移動手段６１、計測手段７２、判断手段７３を有する。
　この構成において、センサの低価格化を狙ってノード３０の演算処理能力及び通信能力を最低限まで絞ったものであった場合、高度な処理を実行できずに遅延が発生するおそれがある。その場合、判断手段７３が各モジュール５２、５３に付随するプロパティ８０に応じて、例えば、計測モジュール５１の実行にしかセンサノードが適さないと判断すると、図６（ｂ）に示すように、前処理モジュール５２と後処理モジュール５３を他のノードに転送し、実行環境４０にて実行する。本実施例では、転送ノード９３でもプロパティ８０に適さない場合に、更に後処理モジュール５３を監視モジュール９５に転送して実行する構成となっている。
　上記で説明したように、計算機リソースが不十分なセンサノードを計測対象に設置し、且つ通信帯域が不十分なネットワークを経由して処理結果を受信するノードに接続する場合において、従来であればセンサノードの貧弱な処理性能及び不十分な通信がボトルネックとなって、分散システムとして成立しない場合であっても、上述した処理を行えば、センサノードをネットワークに接続するだけで、ノード間を結ぶネットワーク帯域及びノードの性能に応じて、動的に適切なノードにモジュールが配置されることによってシステム全体として十分な処理性能が得られる。
　図７では、実施例６でのプログラム・モジュール５０の移動に係るフローチャートを示す。センサノード９４の計測手段７２は、ネットワーク２１、２２、２３、２４を経由して通信相手先を探索して該ネットワーク上で経由するノード３０の一覧を取得する（Ｓ１１０）。センサノード９４の計測手段７２はプロパティ８０に記録された項目に応じて自ノード３０の状況を計測する（Ｓ１２０）。
　さらに計測手段７２はノード一覧の他ノード状況を取得する（Ｓ１３０）。センサノード９２の判断手段７３は各モジュール５２，５３に付与されたプロパティ８０を基に、自ノード及び他ノードで適当なノード３０を選択する（Ｓ１４０）。
　例えば、前処理モジュール５２と後処理モジュール５３が選択ノード９６で中間データ６２を生成するのが良いと判断したとする。選択ノードが自ノードの場合には、処理を継続する（Ｓ１４２）。選択ノードが他ノードの場合には、選択したノード９３に前処理モジュール５２の通信相手を自ノードと設定して転送する（Ｓ１５０）。選択ノード９３は、該モジュール５２、５３を受信する（Ｓ１５２）。転送先ノード３０に、転送した前処理モジュール５２及び後処理モジュール５３の起動を依頼する（Ｓ１６０）。
　選択ノード９６は、起動の依頼を受領して前処理モジュール５２及び後処理モジュール５３を起動する（Ｓ１６２）。センサノード９４は、現在通信している監視ノード９５に、転送先ノード９６への変更を通知する（Ｓ１７０）。監視ノード９５は通信先をセンサノード９４から転送先ノード９６に変更する（Ｓ１７２）。
　以上により、センサノード９４、選択ノード９６、監視ノードノード９５の接続同期が完了する（Ｓ１８０）。ここで、選択ノード９６において、新たに前処理モジュール５２、後処理モジュール５３を実行環境４０で実行することにより変化が生じたものとする。
　選択ノード９６の計測手段７２は、ネットワーク２１、２２、２３、２４を経由して通信相手先を探索して該ネットワーク上で経由するノード３０の一覧を取得する（Ｓ１９０）。選択ノード９６の計測手段７２はプロパティ８０に記録された項目に応じて自ノード３０の状況を計測する（Ｓ２００）。さらに計測手段７２はノード一覧の他ノード状況を取得する（Ｓ２１０）。選択ノード９６の判断手段７３は各モジュール５２，５３に付与されたプロパティ８０を基に、自ノード及び他ノードで適当なノード３０を選択する（Ｓ２２０）。本実施例では、後処理モジュール５３が監視ノード９５で結果データ６３を生成するのが良いと判断したとする。選択ノードが自ノードの場合には、処理を継続する（Ｓ２２２）。選択ノードが他ノードの場合には、選択したノード９５に後処理モジュール５３の通信相手を自ノードと設定して転送する（Ｓ２３０）。
　監視ノード９５は、後処理モジュール５３を受信する（Ｓ２３２）。監視ノード９５に、転送した後処理モジュール５３の起動を依頼する（Ｓ２４０）。監視ノード９５は、起動の依頼を受領して後処理モジュール５３を起動する（Ｓ２４２）。選択ノード９６は、現在通信している監視ノード９５に、監視ノード９５への変更を通知する（Ｓ２５０）。監視ノード９５は通信先をセンサノード９４から転送先ノード９６に変更する（Ｓ２５２）。以上により、センサノード９４、選択ノード９６、監視ノード９５の接続同期が完了する（Ｓ１８）。
　上記で説明したように、モジュール５０を、ネットワーク２１、２２、２３、２４を経由して、判断手段７３に従ってモジュール４０を転送することによって、適切なノード３０に動的にモジュール４０を配置・実行することができる。即ち、本実施例によれば、複数のセンサ及び複数の計算機がネットワークに接続された環境で、ネットワークの通信状況及び計算機の状況に応じて、プログラムを構成する複数プログラム・モジュールが動的に計算機間を移動、実行できる環境を提供することができる。また、動的分散方式を用いることで、ネットワーク経路変更や負荷変動および計算機状況に応じて動的にプログラム・モジュールが実行される。よって、ネットワーク優先度やマスター・スレーブのような計算機の構成を静的に構成する必要がなく、インターネットのようにネットワーク優先度の決定が困難で且つ計算機資源が逐次変化する環境でも有効に活用することが可能となる。
　実施例２は、システムの実行状態が大きく変化する例として、センサのデータを基に計測対象の状況を学習する段階と、該学習結果を基に計測対象を常時診断する段階の大きく二つの段階を有するシステムの例である。
　図８（ａ）に示す初期段階では、計測対象に設置するコントローラ９６は、センサデバイス１１と接続し、計測モジュール５１により、センサデータ１１１を取得する。特徴抽出モジュール１０１は、該センサデータ１１１から、特徴データ６２を抽出する。学習モジュール１０２は、特徴データ６２を基に、学習データ１１２を生成する。該学習データ１１２とセンサデータ１１を基に、診断モジュール１０３は正常／異常の判断を下し、異常の場合には異常データ１１３を生成して、最終ドメイン１５に設置されているセンター９７に異常データ１１３を通知する。
　初期段階では、学習データ１１２は存在せず、且つ学習モジュール１０２の処理は大きく、膨大な量のセンサデータ１１１を処理・記憶することは、コントローラ９６で実行することは困難である。実際、コントローラ９６の仕様上、コントローラ９６で実行することが困難となるようにプロパティ８０を設定せざるを得ない。
　そこで図８（ｂ）に示すように、センター９７との間に設置された中継ノード９８で、特徴抽出モジュール１０１を実行し、センサデータ１１１から特徴データ６２を生成する。中継ノード９８で生成された特徴データ６２を基に、センター９７では、学習モジュール１０２が、学習データ１１２を生成する。
　図９（ｃ）に示すように、コントローラ９６は、学習データ１１２を基にセンサデータ１１１を診断モジュール１０３で診断処理を実施し、正常／異常の判断を下し、異常の場合には異常データ１１３を生成して、ネットワーク２１、２２、２３、２４を経由してセンター９７に異常データを通知する。
　上記で説明したように、学習データ１１２の生成状況により適切なノードで処理を実行させることが可能となる。
　実施例３は、プロパティの変更により、システム全体の構成を容易に変更する例を示す。本実施例は、自動車の自動運転や安全制御システムのコントローラ３００に適用した例である。
　図９（ａ）は、例えば自動車に搭載されるセンサ１６と、アクチュエータ１７と、コントローラ３００を示す。センサ１６は、一次元の距離センサや二次元のカメラ、三次元のステレオカメラやレーザー・レンジ・ファインダ等の様々な次元に対応したセンサによって構成されている。コントローラ３００では、これらのセンサから得られる多次元データ２１１を基に、次元処理モジュール２０１は、特徴データ２１２を生成する。特徴データ２１２には、距離データや物体検知の結果等がある。認識モジュール２０２は、特徴データ２１２を基に、認識データ２１３を生成する。認識データ２１３を基に制御モジュール２０３はアクチュエータ１７を操作するための目標値となる制御データ２１４を生成する。制御の目標にもよるが、アクチュエータ１７には、制動のためのブレーキ・アクチュエータ、操舵のためのステア・アクチュエータ、加減速のためのアクセル・アクチュエータ、等がある。この構成が、現在のオートクルーズコントロールや、安全装備であるＡＤＡＳの概略構成である。この構成では、個々の車体に、センサデバイス１１と処理モジュール５０が搭載されるため、コストがかかりがちであり、また、車車間での連携が取りにくいおそれがある。
　図９（ｂ）の例では、認識モジュール２０２と制御モジュール２０３に係るプロパティを操作することにより、特徴データ２０１の生成までを車上で実施し、認識データ２１３の生成や、制御データ２１４の生成は、路上システム３１０、３２０で実施する構成にしている。
　さらに、図９（ｃ）の例では、車上に搭載されるのはセンサ１６とアクチュエータ１７だけとなり、センサ１６からの多次元データ２２１を、ネットワーク２１、２２、２３、２４を経由して、路上システム３２０に送信し、路上システム３２０側で、次元処理モジュール２０１、認識モジュール２０２、制御モジュール２０３を実施する形態にすることが可能となる。
　上記で説明したように、図９（ａ）のように制御システム３００を全ての自動車に搭載することで、運転者主体の自律的なシステムが構築できる。ただし、制御システム３００は高性能が要求されるために高価になるとともに、莫大な量の制御システム３００を連携して管理することが困難である。一方、図９（ｂ）に示す構成を採用すれば、認識モジュール２０２や制御モジュール２０３を外部のノードで実行させることができるので、制御システム３００の処理能力を削減することでコスト削減が可能となる。また、制御システム３００でハードウェア依存の少ない認識モジュール２０２や制御モジュール２０３を、車の外部（例えば地上）に設置することで、認識モジュール２０２や制御モジュール２０３のスケーラビリティを確保するとともに各モジュールの連携もソフト的に容易となる。この場合、地上システム３１０、３２０は、例えば路車間通信が可能となる道路脇に設置されても良いし、通信遅延が許容できるのであれば遠距離に設置される最終ドメイン１５であっても構わない。地上側の設備において認識モジュール２０２や制御モジュール２０３を実行する構成にすることにより、精度を向上させた認識モジュール２０２の変更や、精度良い制御を実行できる制御モジュール２０３に変更することが可能となる。図９（ｃ）の構成では、車に搭載されるのは、センサ１７とアクチュエータ１６だけとなり、センサ１６で計測された多次元データ２１１を、ネットワーク２１，２２，２３，２４を経由して地上システム３２０で、集中的に認識、制御を管理する自動運転システムへの移行が可能となる。
　なお、本発明は、上記各実施形態の構成に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
　例えば、上記では、実行環境として、ＯＳやＶＭ環境といったソフトウェアによるものを例示したが、ハードウェアによるものであってもよく、ハードウェアの実行環境としては、再構成可能（re-configurable）なデバイスとして、ＰＬＤやＦＰＧＡが考えられる。
１１…デバイス、１２…コントローラ、１３…ゲートウェイ、１４…ルータ、１５…最終ドメイン、２１…通信路、２２…通信路、２３…ＬＡＮ、２４…ＷＡＮ、３０…ノード、４０…実行環境、５０…モジュール、６０…データ、７１…移動手段、７２…計測手段、７３…判別手段、８０…プロパティ

Claims (10)

  1. 　ネットワークで接続された複数のノードを有する分散システムにおいて、
    　前記ノードで実行される実行モジュールに実行条件に関するプロパティが付与され、
    　前記プロパティと、前記分散システムの内部状態に応じて前記実行モジュールを実行するノードが決定されることを特徴とする分散システム。
  2. 　請求項１の分散システムにおいて、
    　前記内部状態は、前記ノードの処理状態であることを特徴とする分散システム。
  3. 　請求項１の分散システムにおいて、
    　前記内部状態は、前記各ノード間の通信状態であることを特徴とする分散システム。
  4. 　請求項１の分散システムにおいて、
    　前記内部状態の時間的変化に応じて、前記実行モジュールが実行されるノードが決定されることを特徴とする分散システム。
  5. 　請求項１の分散システムにおいて、
    　前記分散システムは、複数の階層を有し、
    　前記分散システムを構成する階層の時間的変化に応じて、前記実行モジュールが実行されるノードが決定されることを特徴とする分散システム。
  6. 　請求項１の分散システムにおいて、
    　前記プロパティは、前記ノードの処理能力、記憶能力、処理の遅延状態、通信帯域の少なくとも一つであることを特徴とする分散システム。
  7. 　請求項１の分散システムにおいて、
    　前記各ノードによる前記実行モジュールの処理経過、及び、データの蓄積状態の少なくとも一方に応じて、前記実行モジュールが実行されるノードを決定することを特徴とする分散システム。
  8. 　請求項１の分散システムにおいて、
    　前記プロパティが変更可能に構成され、
    　前記プロパティが変更されることにより、実行モジュールを実行するノードが変更されることを特徴とする分散システム。
  9. 　請求項１の分散システムにおいて、
    　前記実行モジュールの実行主体に決定されたノードが、前記実行モジュールと互換性のある実行モジュールを備える場合に、前記プロパティを基にどちらの実行モジュールを実行するかが決定されることを特徴とする分散システム。
  10. 　請求項１の分散システムにおいて、
    　前記実行モジュールの移動とともに、該モジュールの入れ替えを行うことを特徴とする分散システム。
PCT/JP2015/068119 2015-06-24 2015-06-24 分散システム WO2016207989A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201580080771.9A CN107615247A (zh) 2015-06-24 2015-06-24 分布式系统
PCT/JP2015/068119 WO2016207989A1 (ja) 2015-06-24 2015-06-24 分散システム
JP2017524327A JPWO2016207989A1 (ja) 2015-06-24 2015-06-24 分散システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/068119 WO2016207989A1 (ja) 2015-06-24 2015-06-24 分散システム

Publications (1)

Publication Number Publication Date
WO2016207989A1 true WO2016207989A1 (ja) 2016-12-29

Family

ID=57584908

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/068119 WO2016207989A1 (ja) 2015-06-24 2015-06-24 分散システム

Country Status (3)

Country Link
JP (1) JPWO2016207989A1 (ja)
CN (1) CN107615247A (ja)
WO (1) WO2016207989A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020030725A (ja) * 2018-08-24 2020-02-27 株式会社日立製作所 設備分析支援装置、設備分析支援方法、及び設備分析システム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002175405A (ja) * 2000-12-07 2002-06-21 Nippon Telegr & Teleph Corp <Ntt> 適応型ネットワークサービス提供方法及びその記録媒体
JP2008077281A (ja) * 2006-09-20 2008-04-03 Nec Corp スーパースケジューラ、処理依頼方法、およびスーパースケジューラプログラム
WO2012023190A1 (ja) * 2010-08-18 2012-02-23 富士通株式会社 通信端末装置、着信処理プログラム、および着信処理方法
JP2013047950A (ja) * 2011-08-19 2013-03-07 Canon Inc アプリケーションが決定したスケジューリングによる効率的なキャッシュの再利用
WO2014208661A1 (ja) * 2013-06-27 2014-12-31 日本電気株式会社 仮想マシン配置設計装置及び方法とシステム並びにプログラム
JP2015503146A (ja) * 2011-11-11 2015-01-29 アルカテル−ルーセント 大規模メディア・クラウドのための分散型マッピング機能

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10334057A (ja) * 1997-06-04 1998-12-18 Nippon Telegr & Teleph Corp <Ntt> 分散システム環境におけるバッチジョブの動的負荷分散処理方法およびそのシステム
CN104580456B (zh) * 2014-12-31 2017-12-29 深圳市兰丁科技有限公司 一种用于分布式系统的动态消息分发方法及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002175405A (ja) * 2000-12-07 2002-06-21 Nippon Telegr & Teleph Corp <Ntt> 適応型ネットワークサービス提供方法及びその記録媒体
JP2008077281A (ja) * 2006-09-20 2008-04-03 Nec Corp スーパースケジューラ、処理依頼方法、およびスーパースケジューラプログラム
WO2012023190A1 (ja) * 2010-08-18 2012-02-23 富士通株式会社 通信端末装置、着信処理プログラム、および着信処理方法
JP2013047950A (ja) * 2011-08-19 2013-03-07 Canon Inc アプリケーションが決定したスケジューリングによる効率的なキャッシュの再利用
JP2015503146A (ja) * 2011-11-11 2015-01-29 アルカテル−ルーセント 大規模メディア・クラウドのための分散型マッピング機能
WO2014208661A1 (ja) * 2013-06-27 2014-12-31 日本電気株式会社 仮想マシン配置設計装置及び方法とシステム並びにプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020030725A (ja) * 2018-08-24 2020-02-27 株式会社日立製作所 設備分析支援装置、設備分析支援方法、及び設備分析システム
JP7077181B2 (ja) 2018-08-24 2022-05-30 株式会社日立製作所 設備分析支援装置、設備分析支援方法、及び設備分析システム

Also Published As

Publication number Publication date
JPWO2016207989A1 (ja) 2018-02-22
CN107615247A (zh) 2018-01-19

Similar Documents

Publication Publication Date Title
Chaâri et al. Cyber-physical systems clouds: A survey
Cheng et al. FogFlow: Easy programming of IoT services over cloud and edges for smart cities
Wen et al. Fog orchestration for internet of things services
Kristiani et al. The implementation of a cloud-edge computing architecture using OpenStack and Kubernetes for air quality monitoring application
WO2018160267A2 (en) Cloud based robotic control systems and methods
MX2015000882A (es) Sistema de administracion de computacion especifica de vehiculos para computacion en la nube.
CA3212124A1 (en) Distributed computing in a process control environment
US11314694B2 (en) Facilitating access to data in distributed storage system
US10713026B2 (en) Heterogeneous distributed runtime code that shares IOT resources
US20230132992A1 (en) Infrastructure-delegated orchestration backup using networked processing units
Popentiu-Vladicescu et al. Software reliability in the fog computing
da Silva Barbosa et al. A platform for cloudification of network and applications in the Internet of Vehicles
Yamaoka et al. Dracena: A real-time iot service platform based on flexible composition of data streams
US20210024088A1 (en) Robust autonomous drive design
Al-Jaroodi et al. CoTWare: a cloud of things middleware
Mohamed et al. Towards service-oriented middleware for fog and cloud integrated cyber physical systems
JP2024510746A (ja) 車両のためのサービス指向データアーキテクチャ
WO2016207989A1 (ja) 分散システム
US20170171036A1 (en) Distributed network management system and method for a vehicle
Budakoti et al. IoT gateway middleware for SDN managed IoT
US11782699B1 (en) Systems and methods for non-interruptive update
Rodrigues et al. Using SOA in critical-embedded systems
Alena et al. Wireless space plug-and-play architecture (SPA-Z)
JP5809743B2 (ja) 分散システムにおける異種システムデータ提供方法
Furusawa et al. Service mesh controller for cooperative load balancing among neighboring edge servers

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15896311

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017524327

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15896311

Country of ref document: EP

Kind code of ref document: A1