A decentralized event-based coordination model

Abstract

The present invention relates to the coordination of tasks in a distributed mesh of systems, such as among autonomous vehicles, multi-camera systems, IoT distributed node systems, and / or modular factories in various use cases. More specifically, the present invention relates to the coordination of events in a distributed mesh of systems based on parameters and constraints, which can be used to provide messaging arrangements that enable distributed systems to communicate and ensure tasks are completed within the distributed system and / or at one or more nodes in the distributed system. Aspects and / or embodiments seek to provide a method for coordinating machines / nodes / devices of a distributed network without a centralized system component by synchronizing devices of the distributed system without the use of absolute timestamps. Instead, a logical, event-based dependency tree is collaboratively constructed by the nodes of the distributed network to manage decisions at each node of the distributed network.

Description

[Technical Field]

[0001] The present invention relates to the coordination of tasks in a distributed mesh of systems such as between autonomous vehicles, multi-camera systems, IoT distributed node systems, and / or modular factories in a variety of use cases. More specifically, the present invention relates to the coordination of events in a distributed mesh of systems based on parameters and constraints, and can be used to provide messaging arrangements that allow distributed systems to communicate and ensure that tasks are completed within the distributed system and / or at one or more nodes within the distributed system at one or more substantially predetermined times. [Background technology]

[0002] Manual tasks are increasingly being automated by machines, and the machines used to provide this automation are being improved to be increasingly able to operate "intelligently," for example, by considering risks, such as infrastructure or human safety risks, from automated, decentralized decisions. In particular, industries such as warehousing, logistics, and automotive have already seen significant efficiency improvements, while other industries, such as mining, are only now becoming automated.

[0003] The current paradigm requires a stable, centralized network connection to centrally coordinate all autonomous devices and machines in a given operation, but this is not always possible. Specifically, when communication protocols such as LTE or 5G are used, they are typically either not fast enough or not ubiquitous in most geographic areas. The limitations of such centralized networks are obvious, including the need to set up cell infrastructure in remote locations where it does not exist. In some situations, such as underwater exploration, closed-pit mines, mountainous regions, and space, it may not even be economically possible to deploy the infrastructure. Furthermore, operating a centralized management server may introduce a single point of weakness into an otherwise distributed system.

[0004] It would therefore be desirable to provide a way to avoid the need for centralized coordination of autonomous machines in such operations, which could then avoid problems arising from poor communication links between one or more of the machines. Summary of the Invention [Problem to be solved by the invention]

[0005] However, current distributed networks are typically used only in specific use cases, such as tethered mesh networking, web architecture, and developer operations for scaling web applications. However, these known implementations of distributed networks have not yet been applied or adapted for safety-critical applications (e.g., autonomous vehicles) because the lack of a common or "global" clock makes task synchronization on the distributed network unreliable. In such distributed networks, each machine / system has its own internal clock, i.e., its own time record, but it is difficult to guarantee that all machines / systems have synchronized internal clocks. As an example, a 150 ms misalignment between internal clocks between nodes in a distributed system may mean that a node that is an autonomous vehicle may have an estimated location on a roadway that is miscalculated to be approximately 5 meters away from the node's actual location relative to another node, again, for example, another autonomous vehicle, a machine / system in the same network. As a result, even what may appear to be small time differences or synchronization errors can lead to a high probability of serious errors and / or consequences when attempting to centrally coordinate several nodes in a distributed system.

[0006] Furthermore, when sequencing is based on timestamps, little or no context information is typically exchanged between machines / systems or within a distributed sequencing process. The exchanged timestamp data can consume a significant portion of available bandwidth in some configurations, especially if addressing information is included in the timestamp data. As a result, when making decisions within a sequencing or between machines / systems, this lack of context information limits decentralized decision-making. However, increasing the amount of context information provided also exacerbates the problem of bandwidth consumption due to data exchange, which may already be limited by the amount of timestamp data exchanged. [Means for solving the problem]

[0007] Aspects and / or embodiments seek to provide a method for coordinating machines / nodes / devices of a distributed network without a centralized system component by synchronizing devices of the distributed system without the use of absolute timestamps. Instead, a logical, event-based dependency tree is collaboratively constructed by the nodes of the distributed network to manage decisions at each node of the distributed network.

[0008] Further aspects and / or embodiments seek to provide a method for coordinating tasks in a distributed system of nodes using local parameters and constraints to determine the best actor within the mesh for a particular task.

[0009] Further aspects and / or embodiments may involve a node in a decentralized network risking one or more other nodes in the network (e.g., Cyber-Physical Systems It seeks to provide a decentralized safety resolution to ensure that no one starts to undertake any action or new sequence of events that could expose them to the risk of physical damage in the context of a network, or more generally, the (logical) risk of a deadlock scenario.

[0010] Further aspects and / or embodiments contemplate providing complex messaging arrangements or protocols for nodes in a distributed system to communicate to ensure tasks are completed efficiently.

[0011] According to a first aspect, there is provided a method of event-based synchronization of states for a distributed system of nodes, wherein each node calculates its own event sequence, the method of calculating the event sequence at each node of the distributed system comprising the steps of establishing communication between a plurality of adjacent nodes, each of the adjacent nodes determining a plurality of interdependent events between nodes of the plurality of adjacent nodes, and each node communicating its state information to its adjacent nodes such that each node can determine the state of one or more of the nodes of the plurality of adjacent nodes, wherein each node is operable to react to one of more states of the nodes of the plurality of adjacent nodes.

[0012] The use of event-based synchronization can enable coordination of nodes / machines / systems in a distributed system by removing the dependency of such systems on time-based clocks and / or without the nodes / machines / systems having to go through a central dictator or server to manage tasks or events. More specifically, using this approach, when components of a distributed network are communicating with each other, they cannot rely on absolute time-based clocks to synchronize their communications.

[0013] In this way, the nodes of the network do not need to be centrally connected, thus providing the flexibility to deploy a distributed system anywhere, regardless of network availability.

[0014] Optionally, event-based synchronization involves coordinating events of multiple neighboring nodes to automatically adapt to state changes in the event sequence of any neighboring node.

[0015] By doing so, each node can independently assess whether changes in the state of neighboring nodes will affect its own sequence or state, and if so, how the changed state may affect its own sequence. Once determined, each node can also change its own sequence of events to ensure that the task is completed, and preferably completed safely.

[0016] Optionally, the step of establishing communication between the plurality of adjacent nodes further includes sending a confirmation communication request to the plurality of adjacent nodes, and receiving one or more responses to the confirmation communication request from one or more adjacent nodes indicating their presence.

[0017] Before making any decisions or changes to the sequence of any nodes, it is important to know which nodes in the system are close enough to connect or will cause a disruption. This is sometimes called the discovery step.

[0018] Optionally, the step of establishing communication between a plurality of neighboring nodes further comprises creating a real-time map of the plurality of neighboring nodes.

[0019] In some examples, knowing the proximity of surrounding nodes or devices in a distributed system may provide a visual representation of the network in a particular area and may be useful when considering deploying additional nodes to the system and / or planning to efficiently manage system resources.

[0020] Optionally, a node can detect external nodes that are physically nearby but not part of the distributed network or neighborhood and update its own event sequence (or update one or more external nodes) by observing the behavior of such nodes, such that a node, such as an autonomous vehicle, can respond to hybrid situations involving non-autonomous vehicles. Optionally, the external nodes are within the geographic proximity of a node in the distributed network.

[0021] Optionally, determining the plurality of interdependent events comprises creating an event dependency tree for each of the plurality of adjacent nodes. Optionally, the event dependency tree is created using logical time.

[0022] Using logical time reduces the risk of unpredictable transmission time delays that occur in traditional systems: event-based logic is used, whereas traditional time-based measurements can be used internally within a node but not within / between the rest of the system.

[0023] Optionally, the logical time is calculated based on the event sequences of each of the multiple neighboring nodes.

[0024] In some examples, the logical time is determined after considering the sequence of events that must occur to safely complete a particular task. Alternatively, the logical time may be determined relative to a position within the sequence of events.

[0025] Optionally, the step of each node communicating the state information of the node to a neighboring node comprises sending a state change query to the neighboring node, Optionally, upon receiving the state change query, the neighboring node determines whether the state change query complies with the event sequence of the neighboring node.

[0026] Each node can calculate whether a state change from a nearby node could complicate or interrupt the node's own state or sequence, and whether it could stop the node from properly, and optionally safely, completing its original task.

[0027] Optionally, the step of each node communicating the node's state information to adjacent nodes further includes locally processing the state information received from the adjacent nodes to determine new event sequences for the node itself and for the adjacent nodes to accommodate the state change request, and optionally sending a request to the adjacent nodes to execute the new event sequences.

[0028] This may also reduce the processing power required by traditional centralized components, as processing steps may be distributed among nodes or components in the distributed system.

[0029] Optionally, the new event sequence is determined based on a variable sample rate.

[0030] For example, this may be based on the vehicle moving at a particular speed for a particular amount of time. If this changes and conditions are determined to be no longer safe, the method can adapt by updating / creating the event sequence with a new event sequence or by stopping updates entirely.

[0031] Optionally, each node is operable to react to one of more conditions depending on local parameters, optionally including any one or any combination of user-defined parameters and / or pre-defined parameters.

[0032] The local parameters may be several characteristics, such as proximity, speed, location, or specific requirements, depending on the node. The local parameters may be used to create a ranking system that determines which nodes are capable of completing tasks that enter the network or new requests from nodes within the network. This data is often gathered in determining neighboring nodes and can also improve upon traditional task allocation because the data is no longer predictive and / or centrally arbitrated, but is based on local conditions of the network's components.

[0033] Optionally, each node is operable to react to one of more states depending on constraints, optionally the constraints include any one or any combination of conditional constraints, dependent constraints, exclusive constraints, precedence constraints, and / or coincidence constraints, and optionally the conditional constraints include determining when a Boolean condition is satisfied.

[0034] A precedence constraint requires that an event occur after a particular event, while a coincidence constraint requires that events occur at the same time.

[0035] A dependency constraint may relate to a situation where one event depends on another. As an example, and for the automotive industry in particular, if an "engine start" event has not occurred, then a request to increase the vehicle's speed cannot occur. Similarly, an exclusion constraint may relate to ensuring that if one event is occurring, then another event cannot occur. Again, continuing with the automotive example, requests to turn left and right cannot occur at the same time.

[0036] Optionally, the method operates without a timestamp system.

[0037] In particular, when the method is implemented globally across or throughout a distributed system, the method does not rely on traditional time-based measurements of, for example, absolute timestamps.

[0038] Optionally, the transmission and reception of data is handled over the same and / or separate communication channels, which optionally include any one or any combination of wireless or wired connections.

[0039] Optionally, the sequence of events includes one or more tasks performed by each node of the distributed network.

[0040] Optionally, each of the nodes is operable to evaluate state changes of each of its neighboring nodes and determine a sequence of events that avoids a risk. Optionally, the risk includes any one or combination of physical or logical risks.

[0041] Optionally, the step of determining a state of one or more associated nodes of a plurality of neighboring nodes comprises determining a steady state of each of a plurality of neighing nodes.

[0042] According to a second aspect, there is provided a transmitter node operable to perform any one or any combination of the steps of the method described above.

[0043] According to a third aspect, there is provided a receiver node operable to perform any one or any combination of the steps of the method set out above.

[0044] According to a fourth aspect, there is provided a system including a transmitter node according to the second aspect and a receiver node according to the third aspect. Each node in the distributed system can act as a transmitter and / or receiver of data in the distributed system. Thus, each node can also perform its own computations and process data.

[0045] According to a fifth aspect, there is provided a system comprising means for performing any one or any combination of the steps of the methods described above.

[0046] According to a sixth aspect, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform any one or any combination of the steps of the methods set out above.

[0047] Embodiments will now be described, by way of example only, and with reference to the accompanying drawings bearing like reference numerals, in which: [Brief explanation of the drawings]

[0048] [Figure 1] 1 illustrates one embodiment in a discovery phase in which three autonomous vehicles determine in a distributed manner how to allow one of the vehicles to merge with another autonomous vehicle in a lane. [Figure 2] 1 illustrates one embodiment during the intent stage, where three autonomous vehicles determine in a distributed manner how to allow one of the vehicles to merge with another autonomous vehicle in a lane. [Figure 3] 1 illustrates an embodiment in the execution stage, where three autonomous vehicles determine in a distributed manner how to allow one of the vehicles to merge with another autonomous vehicle in a lane. [Figure 4] Shows the performed task of one vehicle merging with another autonomous vehicle in its lane. [Figure 5] 1 illustrates one embodiment in a discovery phase, where four autonomous robots determine in a distributed manner how to access intersections between corridors and avoid deadlocks. [Figure 6] 1 illustrates one embodiment during the intent stage, where four autonomous robots determine in a distributed manner how to access intersections between corridors and avoid deadlocks. [Figure 7] 1 illustrates one embodiment in the intent stage, where four autonomous robots communicate intents to each other and identify a critical section consisting of locations CS1, CS2, CS3, and CS4. [Figure 8] 1 shows an embodiment in the running stage, with two of the robots moving into an intersection without causing a deadlock. DETAILED DESCRIPTION OF THE INVENTION

[0049] In the paper "Timed-pNets: a communication behavioral semantic model for distributed systems," published in Frontiers of Computer Science in February 2015 (Front.Comput.Sci., 2015, 9(1):87-110; DOI 10.1007 / s11704-014-4096-4), which is incorporated herein by reference, a mathematical approach was proposed for building semantic models of communication behavior in heterogeneous distributed systems, including synchronous and asynchronous communication. The paper provides a mathematical description of how to build event-based clock dependencies.

[0050] Based on the mathematical foundations set out in this paper, the following example describes one embodiment of the present invention across a distributed network.

[0051] In a distributed network, several connected nodes (e.g., a, b, c...) can communicate with each other via direct and / or indirect channels. Any known wired and / or wireless form of communication can be used to enable communication between nodes within the same distributed network. In some embodiments, nodes within close proximity or nodes that affect the task sequence of one or more other nodes in the distributed network may be considered to be within a neighborhood of (neighboring) nodes. In some embodiments, neighboring nodes may be dynamically determined and / or considered to be a subset of the nodes in the distributed network. As an example, all autonomous robots in a warehouse may be considered to be a distributed network (each robot is a node of the network), but a group or smaller subset of these robots may be considered to be a neighborhood of the nodes of the distributed network. In some embodiments, each node of the distributed network is operable to determine its own neighborhood of nodes rather than a global determination of each node's neighboring nodes in the distributed network. For example, if two nodes "node a" and "node b" of a distributed network are near each other, they are likely to be neighbors in each other's neighborhood, but each node may have different nodes in their respective neighborhoods (e.g., neighbors of "node a": nodes b, e, l, r, c, and neighbors of "node b": nodes a, t, n, f). In some embodiments, a node's neighborhood may include nodes from more than one distributed network.

[0052] In exemplary embodiments, a node's current state is typically monitored and based on a previously defined consensus. When a state is changing according to the consensus of the system or distributed network, this is generally referred to as a steady state. In some embodiments, a steady state is a condition that exists when all nodes in a neighborhood reach a consensus (agreement on which nodes should perform which tasks / actions and when they should perform them). As an example, if a new node enters or interferes with the neighborhood and begins a new "intent phase," the entire neighborhood is no longer in a steady state condition. In some embodiments, a state change corresponds to an action (e.g., "MOVING_FORWARD," "TURNING_LEFT," etc.) performed by a node. Thus, a node is considered to be operating in a steady state when nodes within the node's neighborhood are performing various action sequences and changing their state in an expected manner based on a predefined consensus. In some embodiments, the actions performed by each node in the network may be context-dependent, as these actions are based on the capabilities and / or functions of the particular node. For example, if a node is connected to a component in a robotic warehouse, the node may perform an action called "LIFT_SHELF," but this type of action would not be relevant in the context of an autonomous vehicle.

[0053] Throughout the network, each node periodically sends heartbeats to its neighbors, allowing each respective node to monitor the state of each of its neighbors. In some embodiments, a node's state corresponds to a set of internal parameters of the node, such as speed, direction, location, proximity, etc. In some embodiments, the heartbeats may allow for the construction of a real-time map of surrounding nodes. In some embodiments, heartbeat messages are continuously sent by each node throughout all stages of the process, and in this way, allow each node to determine whether all conditions for a state change (e.g., starting the execution of a new task / action) have been met. As an example, a heartbeat message may include a node identifier and a set of parameters related to a particular application. As an example, some Cyber-Physical Systems In the context of , these parameters may include the current position, the last known position, and the rotation of the physical node across the three-dimensional axes.

[0054] When one or more nodes need to complete a new action or action / event sequence (that will ultimately change the steady state of their neighbors), they send an intent communication to their neighbors giving details about the intended action or action / event sequence. The intent communication may include an arbitrary set of parameters and constraints. In some embodiments, a node does not necessarily know that it will affect the steady state of its neighbors, but as soon as the node enters its intent phase, a new consensus is needed to determine whether its neighbors can perform a particular action or action / event sequence, and thus the neighborhood is no longer in steady state.

[0055] Upon receiving this payload information from the originating node (or nodes), the neighboring nodes evaluate the impact of the change on their own state and the state of their neighboring nodes. In some embodiments, the intent communication (payload information) in the Intent Phase includes a description of the action or action / event sequence the node needs to take. This description is then used by the node's neighboring nodes (the recipients of the Intent communication) to determine whether the action or action / event sequence can be performed and the impact on the node's own and neighboring states. In an exemplary embodiment, in the Intent Phase, nodes may exchange messages to reach a consensus. If, based on the evaluation by the neighboring nodes, it is deemed safe to proceed with the intent communication (e.g., there are no deadlocks, race conditions, unsafe conditions, etc.), the neighboring nodes transmit a positive consensus back to the intent originating node and, optionally, to other neighboring nodes. However, if the intent and its impact on the neighboring node (or nodes) are deemed unsafe, the "Intent" message is rejected. In some embodiments, some nodes may consider an intent safe to execute, and some nodes may consider an intent unsafe to execute. Affirmative consensus is required whenever a node that is part of the distributed network, a neighbor, or a node close enough to influence the distributed network wishes to enter a new state (i.e., perform a new action). This is because entering a new state can potentially affect the event sequence maintained within each of the neighboring nodes. In some embodiments, the action sequence of one or more nodes may depend on the action sequence of another neighboring node, so a positive consensus must be confirmed before changing the state of the node's neighboring nodes.

[0056] As an example of a safety assessment performed by a node, the node can determine the possibility of a deadlock scenario. A deadlock can occur when there is a circular dependency between exclusive resource acquisitions performed by two or more concurrent threads or nodes. Typically, two or more concurrent threads of execution or nodes are required for a deadlock to occur. A deadlock occurs when these concurrent threads attempt to gain exclusive access to some resource. Exclusive access to a resource is often required for the correctness of concurrent programs to prevent multiple threads or nodes from interfering with each other, but it is the exclusivity requirement that can lead to deadlock. For a deadlock to actually occur, there is usually a circular dependency: a ring of threads or nodes, each of which has obtained access to some exclusive resource but desires access to another resource. Due to the circularity, each thread ultimately waits for the thread itself to release its resource in order to proceed. Common deadlock scenarios include four vehicles at a two-way road intersection or the well-known "dining philosophers problem."

[0057] Another evaluation that nodes may perform is known as a race condition or race hazard. A race condition is when the output of a system or network depends on the timing or sequence of uncontrollable events. This is very prevalent in multithreaded and distributed environments. A race condition can occur when two (or more) nodes sharing the same memory space want to update a variable sum after completing their independent events substantially simultaneously. As an example, when two threads or nodes want to complete a task, both nodes first read the initial variable sum. As the two nodes perform their tasks, they perform operations on the initial variable sum based on the results of their tasks and then attempt to update the initial variable sum with their respective updated sums. However, because the variable sum is shared between two nodes, only the value of the node that last sends its updated variable sum is saved in the shared memory. This is because it overwrites any previous sums, including updated variable sums from other nodes. Therefore, in a race condition, the output cannot be guaranteed because it depends on which thread or node finishes its task and last sends its updated sum.

[0058] The evaluation performed by the node may also help determine which node or actor in the network is best suited to perform a task or sequence of events. This may be determined based on efficiency and / or safety. For example, in a robotic warehouse, several robots (represented as nodes in a distributed network) may perform a task, such as transporting an object from one location to another, by a certain deadline (e.g., within a time frame of 5 minutes, 10 minutes, etc.). When evaluating options, the node may select the first node to advance the node's state transition (i.e., execution of a set of actions / event sequences) based on its proximity to the node's deadline. Alternatively, if a neighborhood faces a risk of congestion in the warehouse, the node may select the node in the state that most frequently appears in the dependency lists of other nodes (i.e., blocks the greatest number of nodes) to advance. Furthermore, in this way, processing information is distributed within the network and not performed on a central system component (such as a server or centralized software or hardware controller, e.g., a central master node in a mesh network).

[0059] Once the originating node receives responses from neighboring nodes, action is taken by the node determined to be involved in the first action or event in the sequence, provided there is no precedence dependency on that node for another action(s) (e.g., the action may be taken independently or in parallel with one or more other actions at one or more other nodes). If there is a precedence dependency that could jeopardize the new action, event, or sequence, the original intent is aborted and the sequence is abandoned. In some embodiments, the sequence may be abandoned or aborted based on a consensus message from one or more nodes denying consent to the state transition in response to the initial intent message.

[0060] If and when a node enters the Executing state based on intent messages and new actions / events, the Executing node monitors the state of the node to ensure that the actions or event sequence are performed in the correct sequence and as agreed upon to maintain the integrity and safety of the system. When a node completes its event in the sequence, it reports the completion and the node's current state to neighboring nodes, which triggers the next event in the sequence, if available. Once all participating nodes have completed the Executing stage, the system re-enters the Steady State.

[0061] In some instances, a new high-priority Intent message may be inserted into the network to execute an action or sequence of events before a previously issued Intent, based on any arbitrary parameters defined by the system / network. In other instances, each time a new Intent message is sent to the system, the safety of the new event is considered before any action is safely executed, and the new Intent is executed only if it is safe to do so.

[0062] 1-4, exemplary embodiments are now described regarding the use of this approach in autonomous vehicles, providing a method for coordinating tasks within a distributed network / mesh based on parameters and constraints, which provides complex messaging arrangements that allow machines within the distributed network to communicate among themselves to ensure tasks are completed effectively.

[0063] 1-4, the exemplary embodiment illustrates a situation involving three autonomous motor vehicles C1, C2, and C3 traveling along a divided highway (i.e., a road with two lanes with traffic traveling in the same direction). The first motor vehicle C1 is traveling along the first lane and intends to merge into another lane of the road. The second motor vehicle C2 is traveling along the second lane (where the first motor vehicle C1 intends to merge). The third motor vehicle C3 is traveling along the second lane behind the second motor vehicle C2.

[0064] Referring to FIG. 1 , a first vehicle C1 is in a “discovery” phase, attempting to establish connections with any neighboring vehicles. In some embodiments, an event-based dependency tree is collaboratively constructed by nodes in a distributed network. In some embodiments, a node's proximity may be determined by nodes within a particular area or based on interdependencies (e.g., related nodes) to perform one or more action sequences. In this example, the related vehicles are a second vehicle C2 and a third vehicle C3. The first vehicle C1 does this by issuing a “heartbeat” command 130 to any nearby vehicles over a common communication channel, and in this example, receives responses from the second vehicle C2 and the third vehicle C3 over the same communication channel. Preferably, connections are established to obtain the current state of the other vehicles before making any decisions at any node.

[0065] 2 , a first vehicle C1 enters the “intent” phase and sends a request 240 via a communication channel to a second vehicle C2 and a third vehicle C3 to be inserted into a lane between the second vehicle C2 and the third vehicle C3 on a road 220. The second vehicle C2 and the third vehicle C3 then in turn communicate the request from the first vehicle C1 to their neighbors, respectively, to ensure that each of the second vehicle C2 and the third vehicle C3 can safely complete the required task. If the second vehicle C2 and the third vehicle C3 (as well as any neighbors of the second vehicle C2 and the third vehicle C3) agree that the task is deemed safe (positive consensus), the execution phase can begin.

[0066] 3 , a first vehicle C1 enters the “execute” phase and requests the current state (e.g., speed, direction, location, etc.) of a second vehicle C2 and a third vehicle C3 via a communication channel. The first vehicle C1 then uses the obtained state of the second vehicle C2 and the third vehicle C3 to calculate a determination of the correct course of action that needs to be safely completed for the required task(s). In this example, the first vehicle C1 determines that the second vehicle C2 must accelerate 5 miles per hour (mph) for 30 seconds and the third vehicle C3 must decelerate 5 mph for 30 seconds to create a safe entry point between the second vehicle C2 and the third vehicle C3 at a distance three times the length of the first vehicle C1 for the first vehicle C1 to move into the second lane 320 of the road between the second vehicle C2 and the third vehicle C3. The first vehicle C1 then communicates these determined requests for acceleration by the second vehicle C2 and deceleration by the third vehicle C3 via a communication channel. The second vehicle C2 and the third vehicle C3 then receive these requests and check with any of their respective neighboring vehicles to ensure that the requests maintain safety. Once all checks have been performed with any neighboring vehicles and the second vehicle C2 and the third vehicle C3, the second vehicle C2 and the third vehicle C3 approve the execution phase, and the distributed task is performed by each of the participating actors C1, C2, and C3 until the calculated ideal (relative) position is achieved by the respective vehicles C1, C2, and C3. During execution, each node C1, C2, C3 samples its own state and that of any neighboring nodes C1, C2, C3 at a variable sample rate and can be triggered by any inflection (e.g., one of the cars C1, C2, C3 suddenly brakes, or one of the cars C1, C2, C3 suddenly turns, when the steady state of the system is broken).

[0067] As depicted in Figure 4, once a task is completed, the three-phase cycle is continuously repeated. In other words, once a task is completed, the system / network enters a new steady state in which heartbeats from each node are continuously sent to neighboring nodes in the system / network. If there is a change in the steady state or a new intent is propagated, the full cycle is restarted. Optionally, at the end of every cycle, the safety of the completed task may be determined.

[0068] Referring now to Figures 5-8, another embodiment will now be described regarding the use of this approach in a robotic warehouse.

[0069] 5-8, an example embodiment illustrates a situation involving four autonomous robots R1, R2, R3, and R4 (i.e., nodes) traveling along different corridors in a warehouse. In this example, each robot is traveling toward the intersection of the four corridors without knowledge of the other robots' direction, intended destination, or action sequence.

[0070] Referring to FIG. 5, as each robot R1, R2, R3, and R4 approaches an intersection, it is in a "discovery" phase and attempts to establish a connection with any neighboring robots. In this example, the associated robots are R1, R2, R3, and R4. Each robot does this by issuing "heartbeat" commands 510a, 510b, 510c, and 510d to any nearby robots over a common communication channel. For example, as mentioned above, the heartbeat commands / communications may include the node's state. In this example, each robot receives responses from each of the other robots over the same communication channel.

[0071] Next, referring to Figure 6, each robot enters an "intent" stage, sending a request 610 (indicating an intended action or sequence of actions) to a neighboring robot. As an example, Figure 6 also shows an X / Y Cartesian coordinate system that a robot can use to express its intent or location. Robot R1 moves at distance d (until it reaches the warehouse wall 620). r11 We declare that we want to move along the X axis in the positive direction (i.e., "MOVE_EAST") by a distance d (to the warehouse wall 621). r12 We declare that we want to move along the Y axis in the negative direction by a distance d (i.e., "MOVE_SOUTH"), and then move along the Y axis in the negative direction by a distance d (until wall 622 is no longer an obstacle in the north direction). r13 Just declare that you want to "MOVE_EAST" and then add the distance d r14 Robot R1 declares that it wants to move along the Y-axis in the positive direction by 100 m (i.e., "MOVE_NORTH"). Similarly, robot R2 declares that it wants to "MOVE_SOUTH" to wall 621, then "MOVE_EAST" until wall 621 is no longer an obstacle in the south direction, and finally "MOVE_SOUTH". Robot R3 declares that it wants to move along the X-axis in the negative direction (i.e., "MOVE_WEST") until it reaches wall 623, then "MOVE_NORTH" until it reaches wall 624, and finally "MOVE_WEST". Robot R4 declares that it wants to "MOVE_NORTH" until it reaches wall 624, then "MOVE_EAST" until it reaches wall 620, and finally "MOVE_NORTH".

[0072] Referring to FIG. 7, here the robot is calculating a common list of events and all dependencies (e.g., all interdependent events between all nodes). For example, each robot knows where each robot intends to move R1’, R2’, R3’, R4’. Further, FIG. 7 shows four locations of intersections CS1, CS2, CS3, CS4 that represent critical sections of intersections or paths. This is an area where synchronization is essential to avoid deadlocks. Considering the initial coordinates of the robots, robot R1 determines that it needs to be at an X coordinate less than the X coordinate of CS4 (i.e., R3.x < CS4.x) and at a Y coordinate less than the Y coordinate of R1 (i.e., R3.y < R1.y) so that robot R3 can perform its event sequence. R2 also determines that R3.x < CS4.x needs to apply so that it can perform its event sequence. R3 determines that R1.x > CS1.x needs to apply so that it can perform its event sequence. Finally, R4 determines that R2.y < CS2.y needs to apply so that it can perform its event sequence. As described above, the nodes can reach a consensus regarding the ordering of events based on which node blocks the largest number of adjacent nodes. In this case, since both R1 and R2 depend on R3, they agree that R3 should move to the location of CS3, which is the closest location that satisfies both constraints of R3.x < CS4.x and R3.y < R1.y. After R3 enters the “execution” phase and moves to CS3, R1 requests permission to move to CS2. However, R2 may deny the request because it is using a criterion aimed at minimizing the number of nodes inside the critical section at the same time, and R1 needs to enter the critical section so that R3 can exit the critical section, and R2 provides consent for R1 to move to CS2.

[0073] Referring to FIG. 8, the robots / nodes are now in the "execute" phase, with both R3 and R1 moving inside the critical section. At this point, the neighbors attempt to minimize the number of concurrently accessed nodes across the critical section, so R1 and R3 re-enter the "intent" phase, and each time R1 and R3 ask their neighbors whether R1 and R3 can proceed with the next state transition, both R2 and R4 provide consent. Once both R1 and R3 exit the critical section, R2 and R4 perform the remaining intent / execute cycles according to the previously defined constraints. As discussed above, a high-priority intent system can also be implemented. For example, in some embodiments, high-priority intent messages may be used by ambulances, police vehicles, fire engines, etc., which may be given more importance compared to civilian vehicles for performing a sequence of events or tasks. In other words, a new action by a first responder or emergency vehicle will preempt an action or event requested by another civilian vehicle.

[0074] In an embodiment, logical time is calculated in an event-based sequence. Generally, each event has two instant actions: a start action and an end action. For example, braking a car can be modeled as an "start braking" action and an "end braking" action, and the condition required to trigger the "end braking" action may be when the car's speed drops to zero.

[0075] For example, for other events that have wait events, a local clock (traditional time-based measurement) can be used to determine the duration of the event. However, the use of a local time-based clock does not determine or affect the constraints of logical clocks in different devices within the distributed system or across the distributed system as a whole. In contrast to using absolute time-based scheduling, which can be difficult to synchronize and can be spoofed, the present embodiment uses event-based scheduling.

[0076] Other applications of the invention may include multiple coordinated cameras / multi-camera setups, IoT devices, or modular factories.

[0077] As an example, in multi-camera setups for film and television, instead of relying on timestamp information from each camera to synchronize video frames and / or audio data during editing, digital output triggers created by the cameras can be translated into intents or events, such as audio profile variations, color profile changes, scene composition changes, scene brightness, etc.

[0078] These events can then be used to create logical sequences that can be used to synchronize multiple camera timelines and, in some cases, even to automatically determine offsets before feeding the data to editing software.

[0079] Similarly, factories are evolving towards the concept of a modular factory. Typically, traditional factories are very efficient at a fixed output and may occasionally reduce production when there are no changes to the process. However, these traditional factories cannot handle sudden increases in demand (e.g., to accommodate commercial holidays such as Mother's Day) or limited runs of products that deviate from the factory's prescribed process.

[0080] Modular factories offer a solution to this problem by allowing factories to build modular setups that can be scaled on demand and new steps or components can be introduced as needed.

[0081] The embodiments disclosed herein can also be used in modular factories, allowing them to function very easily and in a true plug-and-play paradigm. Handover and takeover intent can be defined in the system and programmed into each factory hardware unit. Thus, when new units or components are introduced into a process, they can establish sequence-driven connections to their neighbors and immediately function together without risk of error.

[0082] In the embodiments and aspects described herein, the communication hardware used to provide communication between machines / systems / vehicles may be DSRC (dedicated short-range communications) modules, which may offer the advantage of full-duplex communication and less likelihood of interference or lack of bandwidth due to congestion on the communication channel because the frequencies on which these modules typically operate are typically protected by government regulations from other communication protocols, such as consumer wireless networks. Optionally, any wired and / or wireless communication medium may be used to transfer data within the distributed network. In some embodiments, nodes may include one or more sensors to determine one or more nodes within a particular vicinity. In some embodiments, these additional or external nodes may be considered external actors that do not depend on or affect the sequence of any node or the vicinity of a node within the distributed network. In some embodiments, nodes may include sensors or transmitters to propagate one or more sequences of actions or states to other nodes (and their neighbors) in the distributed network, or to external actors (external nodes) within close proximity (e.g., geographic proximity).

[0083] Any system features as described herein may also be provided as method features, and vice versa. As used herein, means-plus-function features may alternatively be expressed in terms of their corresponding structures.

[0084] Any feature in one aspect may be applied to other aspects in any suitable combination. In particular, method aspects may be applied to system aspects, and vice versa. Furthermore, any, some, and / or all features in one aspect may be applied to any, some, and / or all features in any other aspect in any suitable combination.

[0085] It should also be understood that specific combinations of the various features described and defined in any embodiment may be implemented and / or provided and / or used independently.

Claims

1. A method for event-based synchronization of states of a distributed system of nodes, wherein each mobile physical node computes its own event sequence, said method computing said event sequence at each node of said distributed system comprising: establishing communication with a plurality of neighboring nodes; each node determining a plurality of interdependent events between associated nodes of the plurality of neighboring nodes and agreements on the interdependent events, each of the interdependent events being related to node movement; each node communicating its state information to its neighboring nodes so that the neighboring nodes can monitor the state of one or more of the nodes among the plurality of neighboring nodes during execution of the event; each node is operable to react to one or more conditions of an associated node of said plurality of neighboring nodes; The method, wherein the step of each of the nodes communicating its state information to the neighboring nodes includes sending a state change query to the neighboring nodes.

2. 2. The method of claim 1, wherein the event-based synchronization includes coordinating events of the plurality of neighboring nodes to automatically adapt to changes in the state of any neighboring node during the event sequence of the neighboring node.

3. said step of establishing communication with said plurality of neighboring nodes further comprising: transmitting a communication request to the plurality of neighboring nodes; and receiving, from one or more neighboring nodes, one or more responses to the communication request from the one or more neighboring nodes indicating their presence as neighboring nodes.

4. The method of claim 1 , wherein the step of establishing communication with a plurality of neighboring nodes further comprises creating a real-time map of the plurality of neighboring nodes.

5. 5. The method of claim 1, wherein each node of the distributed system or a plurality of neighboring nodes may detect one or more associated external nodes, and the external nodes update their own and / or the one or more associated external nodes' event sequences by observing the behavior of the one or more associated external nodes without being part of the node's distributed system or a plurality of neighboring nodes.

6. The method of claim 5 , wherein the associated external nodes are within a geographical vicinity of the node.

7. The method of claim 1 , wherein determining a plurality of interdependent events comprises creating an event dependency tree for each of the plurality of adjacent nodes.

8. The method of claim 7 , wherein the event dependency tree is created using logical time.

9. The method of claim 8 , wherein the logical time is calculated based on the event sequence for each of the plurality of neighboring nodes.

10. The method of claim 1 , wherein upon receiving the state change query, the neighboring node determines whether the state change query conforms to the neighboring node's event sequence.

11. 11. The method of claim 10, wherein the step of each of the nodes communicating its state information to the neighboring nodes further comprises locally processing state information received from neighboring nodes to determine new event sequences for each of the neighboring nodes and for its own and neighboring nodes to accommodate the state change query.

12. The method of claim 11 , further comprising sending a request to a neighboring node to execute the new event sequence.

13. 13. A method according to any preceding claim, wherein each node is operable to react to said one or more conditions in dependence on local parameters.

14. The method of claim 13 , wherein the local parameters include any one or more of position, velocity, direction, and proximity.

15. The method of claim 1 , wherein the method operates without a timestamp system.

16. The method of claim 1 , wherein the sequence of events includes one or more tasks performed by each node of the distributed system.

17. 17. A method according to any preceding claim, wherein each node is operable to assess the state changes of each of said neighbouring nodes and determine a sequence of events to avoid risk.

18. 20. The method of claim 17, wherein the risks include any one or combination of physical or logical risks.

19. 19. The method of any one of claims 1 to 18, wherein the distributed system of nodes lacks a centralized system component, optionally comprising any or any combination of a central server, a master node, or a centralized control component.

20. 20. The method of claim 1, wherein the distributed system is a cyber-physical system.

21. 21. The method of claim 1, wherein the neighboring nodes of each node can be different.

22. 22. The method of claim 21, wherein establishing communication includes each node dynamically determining its neighboring nodes.

23. A system comprising means for carrying out the method according to any one of claims 1 to 22.

24. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method of any one of claims 1 to 22.

Images