EP4681404A1 - Procédé et dispositif de contrôle d'un réseau de communication maillé pour l'exécution de tâches relatives à des fonctions sans état - Google Patents

Procédé et dispositif de contrôle d'un réseau de communication maillé pour l'exécution de tâches relatives à des fonctions sans état

Info

Publication number
EP4681404A1
EP4681404A1 EP24715670.6A EP24715670A EP4681404A1 EP 4681404 A1 EP4681404 A1 EP 4681404A1 EP 24715670 A EP24715670 A EP 24715670A EP 4681404 A1 EP4681404 A1 EP 4681404A1
Authority
EP
European Patent Office
Prior art keywords
gateway
nodes
communication network
mesh communication
lot
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP24715670.6A
Other languages
German (de)
English (en)
Inventor
David Fernandez Blanco
Frédéric LE MOUËL
Trista LIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut National des Sciences Appliquees de Lyon
Stellantis Auto SAS
Original Assignee
Institut National des Sciences Appliquees de Lyon
Stellantis Auto SAS
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 Institut National des Sciences Appliquees de Lyon, Stellantis Auto SAS filed Critical Institut National des Sciences Appliquees de Lyon
Publication of EP4681404A1 publication Critical patent/EP4681404A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y40/00—IoT characterised by the purpose of the information processing
    • G16Y40/30—Control
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00—IoT infrastructure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30—Decision processes by autonomous network management units using voting and bidding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the present invention claims priority from French application 2302508 filed on 03/17/2023, the content of which (text, drawings and claims) is incorporated herein by reference.
  • the present invention relates to the execution of tasks relating to stateless functions at the edge of a mesh communication network comprising loT nodes.
  • the present invention relates to the control of such a mesh communication network.
  • cloud computing In order to keep devices affordable for the public and to perform tasks related to, for example, stateless functions in a resource-optimized environment, cloud computing has extended its services by adding nodes at the edge of mesh communication networks: These are commonly called Fog or Edge.
  • edge nodes support fewer computing resources than other nodes in the cloud.
  • their lower latency and network load are sufficient to meet the demands of today's applications.
  • mesh communication solves current resource demand issues, cloud computing still relies on computing resources that will need to evolve over time. The development of cloud computing is therefore economically and environmentally fragile because it may be heavily impacted by future semiconductor shortages and/or resource crises.
  • IoT Internet of Things
  • IoT nodes are generally characterized by their lack of on-board resources (computation, energy and storage), their intermittent availability and their faults. These nodes generally experience network interruptions and unexpected crashes that leave them unreachable for long periods of time. These IoT nodes can also encounter Byzantine faults due to low-end features or malicious attacks.
  • loT nodes for cloud computing, it is therefore necessary to implement a method for controlling the infrastructures of mesh communication networks to overcome the faults of the loT nodes and thus ensure the security and availability of task calculations at the edge of the cloud.
  • FIG. 1 schematically illustrates a mesh communication network 1, according to a particular and non-limiting exemplary embodiment of the present invention.
  • the mesh communication network 1 advantageously corresponds to a cellular type network, for example a mobile telephone cellular network.
  • a cellular network is composed of a set of cells, each cell corresponding to a geographic coverage area of a communication antenna (also called a base station) making it possible to establish radio communications between users (also called clients or users, each user carrying a mobile communication device) and/or between the users and the mesh communication network.
  • the size of a cell varies and is for example between 1 km and a few tens of kilometers (for example 20 or 30 km).
  • a user corresponds for example to a natural person carrying a mobile communication device of the smartphone type or a tablet.
  • a user corresponds to a vehicle carrying a computer-type communication device, for example a telematic control unit, called TCU (Telematic Control Unit), or a mobile communication device of the smartphone type embedded in the vehicle and connected to the latter via a wired connection (for example of the USB type (Universal Serial Bus)) or wireless connection (for example of the Bluetooth® or Wifi® type).
  • TCU Telematic Control Unit
  • the mesh communication network 1 implements, for example, communications according to LTE (Long-Term Evolution), LTE-Avanced (Long-Term Evolution - Advanced), C-V2X (Cellular - Vehicle to Everything) technology, which is based on 4G and soon 5G, based on LTE.
  • LTE Long-Term Evolution
  • LTE-Avanced Long-Term Evolution - Advanced
  • C-V2X Cellular - Vehicle to Everything
  • the mesh communication network 1 is intended to execute tasks relating to stateless functions. These tasks are ordered by user through requests sent via the mesh communication network 1. The user then receives responses to his requests via the mesh communication network 1.
  • the topology of the mesh communication network 1 comprises nodes called gateways to indicate that these nodes correspond to gateways (servers) of the mesh communication network 1, and loT nodes to indicate that these nodes correspond to loT devices.
  • the topology of the mesh communication network 1 has a fully connected backbone between six gateways P1 to P6 and a set of star subnets in which each gateway P1 to P6 can reach a group of loT nodes (represented by unreferenced circles).
  • the unreferenced circles in solid lines represent loT nodes that are either sleeping or awake.
  • Light gray circles represent failed loT nodes or gateways, dotted circles represent faulty loT nodes or gateways.
  • Solid lines represent viable connection links while dotted lines represent faulty connection links.
  • Gateways P1 to P6 manage a large set of loT nodes. They are considerably fewer in number than loT nodes but more resourceful and more available than loT nodes. Their availability is almost complete. However, even if it can happen much less often than for loT nodes, gateways can suffer network outages, unexpected crashes or malicious attacks. These attacks have a greater impact in the case of mesh communication network 1 because they then generally deny service to the gateway and loT devices in its subnet.
  • Such a consensus model must (i) guarantee the security of the system under both Byzantine and non-Byzantine faults which include network partitioning, delays, inability to reach a node and packet loss, (ii) maintain service availability as soon as at least one gateway and three loT nodes are available, (iii) be independent of timing to synchronize the topology and task execution and implement an asynchronous intermediate communication mechanism and (iv) be completed as soon as a majority is reached and be able to compensate for the performance loss caused by slower nodes.
  • Consensus models were born from the need to provide non-trivial solutions to achieve agreement between multiple machines in the most efficient and reliable way possible and to strengthen the fault tolerance of systems. These algorithms, through the use of multiple processes and mechanisms, guarantee a single output value between a set of possible values proposed by different machines (nodes) on a set of machines (“cluster” in English).
  • Paxos (A.Yousefpour. 2019. All one needs to know about fog computing and related edge computing paradigms: A complete survey. In J. of Syst. Architecture. Elsevier., D.Ongaro. 2014. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference) is one such consensus model. Paxos works by allowing a group of nodes to reach an agreement on a value, synchronizing these values, and making them learnable for all nodes in a group of nodes. To do this, Paxos classifies nodes into three roles (proposer, acceptor, and learner); it is possible for a node to play more than one role at the same time.
  • this model implements a two-phase process: (1) a promise phase and, once the majority of nodes have reached agreement on a value, (2) a validation phase, during which the proposer determines the final answer to a request and propagates the result to all nodes in the node group to ensure that the entire mesh communication network is synchronized.
  • Paxos has been widely criticized due to its complex applicability to real distributed systems due to system heterogeneity and cluster node constraints. Multiple proposals have attempted to improve this adaptability and reduce the complexity of Paxos. However, these proposals are still too complex for systems using loT nodes.
  • Raft L. Lamport. 2019. Time, docks, and the ordering of events in a distributed system. In Concurrency: the Works of Leslie Lamport) then emerged as an alternative to Paxos for managing logs replicated across all nodes in a node group.
  • Raft focuses on storing data replication rather than executing tasks, the way of reaching agreements on the synchronization and integrity of stored data is based on the same principles as Paxos.
  • Raft proposes three exclusive and different roles of nodes: (a) "leader”, the node is then responsible for coordinating all system management actions and requests and ensuring consistency and organization, (b) "follower”, the node then passively listens and follows the leader's orders, and (c) "candidate", the node then intervenes during a leader election process.
  • leader the node is then responsible for coordinating all system management actions and requests and ensuring consistency and organization
  • follower the node then passively listens and follows the leader's orders
  • (c) “candidate” the node then intervenes during a leader election process.
  • Raft relies on Lamport's logical clocks (L. Lamport. 2019. Time, docks, and the ordering of events in a distributed system.
  • Pirogue (A. Munir et al. 2017. IFCIoT: Integrated Fog Cloud loT: A novel architectural paradigm for the future Internet of Things. In IEEE Consumer Electronics Magazine) is presented as a variant of Raft. Pirogue focuses on the high reduction of its energy footprint while maintaining a performance similar to that of Raft.
  • the classic static voting process is replaced by a dynamic linear voting process (S. Jajodia et al. 1990. Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems.). This change replaces the classic static quorum majority with a dynamic quorum, requiring fewer nodes to obtain a majority in the event of a gateway (server) disconnection.
  • Pirogue proposes a new role of the nodes: witness, the node is then able to participate in the consensus quorum if necessary. This role is implemented by low-power devices that do not have the capacity to store all of the system's data, reducing the energy footprint of the node group.
  • loT nodes and gateways are very heterogeneous between them in terms of resources which depend not only on their hardware characteristics which can be either high-end or low-end, but also on the duty cycle and software of these nodes and gateways, since the aim sought is to use the reserve resources of the loT nodes and gateways without interrupting their original functions.
  • loT nodes are highly resource constrained. Although gateways are much less resource constrained, they nevertheless represent a small portion of the total mesh communication network nodes 1 .
  • loT devices are characterized, for the most part, by their lack of hardware resources (computing and storage) and their battery constraints, since they are generally powered by batteries.
  • Current consensus models are generally deployed on server nodes (gateways) capable of storing a full copy of the logs of the communication network nodes, which is not the case for loT nodes.
  • loT nodes have intermittent availability. Despite the high connectivity capabilities of gateways, loT nodes often experience network outages and unexpected crashes. Their availability is therefore unreliable, unpredictable, and generally intermittent. [0030] Furthermore, consensus models rely on a large number of coordination and synchronization messages transmitted over a fully connected backbone, but given the size of mesh communication network topologies comprising loT nodes, multiple backbones are present requiring messages to pass through multiple intermediate nodes before reaching their destination. Thus, reducing the number of messages is necessary to improve the performance of a consensus model.
  • loT nodes are highly mobile nodes, both physically and from a network perspective. This makes it difficult to maintain complete synchronization of log tables as required by current consensus models.
  • An object of the present invention is to solve at least one of the problems of the technological background described above.
  • An object of the present invention is a collaborative computing service platform targeting the execution of stateless functions and using loT nodes having low to medium availability of an already deployed communication network infrastructure.
  • the present invention is based on an original consensus model which can be related to the consensus models of the state of the art such as Raft or Pirogue. But the consensus model of the present invention extends these classic consensus models by adding:
  • the consensus model divides nodes into two layers based on their energy and computational capabilities: a first layer, which contains few gateways likely to be managers of the resources of the mesh communication network, and a second layer, which contains many loT nodes.
  • the loT nodes are dynamically grouped into subnets, also called computing units UC, according to their degree of availability and their computing capacities, to optimize the execution of tasks relating to user requests.
  • PCM operates on a heterogeneous set of layers.
  • a two-level mesh communication network control at the level of a gateway then resource manager which is dynamically elected and at the level of each subnet by electing a calculation orchestrator node OC for each subnet.
  • This consensus model aims to compensate for the limitations of loT nodes (i.e. high heterogeneity, limited resources, intermittent availability, high dynamics and lack of direct connection between nodes within the platform) to ensure fault tolerance, synchronization of information in the mesh communication network and coordination of task execution.
  • the present invention enables the execution of tasks by an infrastructure of a weakly connected mesh communication network by optimizing the election of a resource management gateway which reduces the total number of messages exchanged.
  • the present invention limits the energy consumption for executing tasks at the edge of the cloud because it uses the resources of IoT devices instead of traditional nodes at the edge of the cloud. [0041] The present invention centralizes the management of resources of a large number of loT nodes without significantly increasing the messages exchanged or slowing down the performance of the mesh communication network.
  • the present invention improves fault tolerance and task coordination, it helps reduce the on-board resources required by vehicles, thereby reducing the price of the on-board architectures of these vehicles.
  • the present invention provides many possibilities for the development of future resilient Vehicle-to-Anything (V2X) applications that could be commercialized.
  • V2X Vehicle-to-Anything
  • the present invention relates to a method for controlling a mesh communication network for the execution of tasks relating to stateless functions, said mesh communication network comprising nodes called gateways to indicate that these nodes correspond to gateways of the mesh communication network and nodes called loT nodes to indicate that these nodes correspond to devices connected to the internet, said method comprising the following steps:
  • each computing unit comprises loT nodes and is attached to a gateway to form a subnet of the mesh communication network;
  • each intermediate response being either obtained by the computing orchestrator node or emitted by an loT node of the computing unit to the computing orchestrator node following the execution of the task by said loT node of the computing unit;
  • the resource management gateway if the resource management gateway does not receive a final response relating to said request before a period of time has elapsed, said request is assigned to another calculation unit.
  • the method further comprises a step of verifying the presence of said request in a cache memory of the resource management gateway, and a step of sending a final response stored in the cache memory in relation to said request if said request is stored in said cache memory.
  • the content of the cache memory of the resource management gateway is synchronized with the contents of the cache memories of the other gateways of the mesh communication network.
  • the resource management gateway periodically broadcasts to the gateways of the mesh communication network a message comprising a first table formed from a union of several second tables, each second table representing an availability and characteristics of the loT nodes of a subnetwork of the mesh communication network, if a gateway receives no message during an election expiration period, said gateway triggers a new election of a resource manager gateway.
  • a new election of a resource management gateway is triggered to verify whether a current resource management gateway minimizes the number of messages exchanged in the mesh communication network for the execution of tasks.
  • a new election of a resource manager gateway is triggered as soon as a gateway of the mesh communication network is disconnected.
  • the method further comprises a step of updating a topology of the mesh communication network and broadcasting an updated topology to all the gateways of the mesh communication network.
  • the present invention relates to a device for controlling a mesh communication network for the execution of tasks relating to stateless functions, the device comprising a memory associated with a processor configured for the implementation of the steps of the method according to the first aspect of the present invention.
  • the present invention relates to a vehicle comprising a device according to the third aspect.
  • the present invention relates to a computer program which comprises instructions adapted for the execution of the steps of the method according to the first aspect of the present invention, this in particular when the computer program is executed by at least one processor.
  • Such a computer program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the present invention relates to a computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of the method according to the first aspect of the present invention.
  • the recording medium may be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM memory, a CD-ROM or a microelectronic circuit type ROM memory, or a magnetic recording means or a hard disk.
  • this recording medium may also be a transmissible medium such as an electrical or optical signal, such a signal being able to be conveyed via an electrical or optical cable, by conventional or hertzian radio or by self-directed laser beam or by other means.
  • the computer program according to the present invention may in particular be downloaded from an Internet-type network.
  • the recording medium may be an integrated circuit in which the computer program is incorporated, the integrated circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 schematically illustrates, according to a particular and non-limiting exemplary embodiment of the present invention
  • FIG. 2 illustrates a flowchart of the different steps of the method 10 for electing a resource management gateway according to a particular and non-limiting exemplary embodiment of the present invention
  • FIG. 3 illustrates an exemplary embodiment of the method 10 of FIG. 1
  • FIG. 4 illustrates a flowchart of the different steps of the method 40 for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention
  • FIG. 5 illustrates a flowchart of the different steps of the method 20 for updating the topology of the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention
  • FIG. 6 illustrates an example of broadcasting an SFTT table in the mesh communication network 1 according to a particular and non-limiting example of the present invention
  • FIG. 7 illustrates a flowchart of the different steps of the method 30 for forming the calculation units, according to a particular and non-limiting exemplary embodiment of the present invention
  • FIG. 8 schematically illustrates a device for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.
  • the present invention relates to a method 10 for controlling a mesh communication network 1 for the execution of tasks relating to stateless functions.
  • the present invention also relates to a method 20 for updating the topology of the mesh communication network 1 to orchestrate the fault-tolerant execution of tasks on often faulty or unavailable loT nodes of this mesh communication network 1.
  • the present invention also relates to a method 30 of forming computing units by grouping loT nodes.
  • each gateway of the mesh communication network 1 stores three tables up to date: a global topology table (GTT), a topology table of the nodes of the sub-network attached to the gateway (SFTT) and a task tracking table (TTT).
  • GTT global topology table
  • SFTT topology table of the nodes of the sub-network attached to the gateway
  • TTT task tracking table
  • the SFTT table represents the availability and characteristics of the loT nodes of a subnetwork of the mesh communication network 1 comprising several loT nodes. This subnetwork is attached to a gateway. The SFTT table is stored by each gateway.
  • the GTT table of a gateway is formed by the union of SFTT tables of other gateways that are known to said gateway.
  • a gtt table index ndex is associated with each GTT table. This table index is used for the synchronization of the GTT tables as will be seen later.
  • the TTT table includes the tasks to be executed and their execution status.
  • a table index ttt ndex is associated with each TTT table. This table index is used for synchronization of the TTT tables as will be seen later.
  • An loT node is either in a “follower” state or in a Calculus Orchestrator (OC) state.
  • a follower node is a passive loT node, i.e. it does not issue any requests by itself.
  • a follower node executes the task execution requests assigned to it and sends an intermediate response to an OC node of the computing unit to which this follower node belongs.
  • a computation orchestrator node called an OC node, is an loT node that is elected for each computation unit UC.
  • An OC node of a computation unit UC executes the task execution requests assigned to it and obtains an intermediate response following the execution of a task.
  • An OC node also collects intermediate responses produced by follower nodes of this computation unit UC following the execution of this task by the other follower nodes of the computation unit UC.
  • the OC node produces a final response from a voting process based on the intermediate responses it has obtained as we will see later.
  • a gateway can be either in a resource manager (RM) state, a dispatcher state, or a candidate state.
  • RM resource manager
  • An RM gateway is suitable for implementing the method 20 for controlling a mesh communication network for executing tasks relating to stateless functions.
  • an RM gateway is suitable for managing all user requests (if a user issues a request to another gateway of the mesh communication network 1, this request is redirected to the RM gateway). It is also suitable for assigning a task to be executed to follower nodes of a computing unit UC, for dynamically selecting the OC nodes and for retransmitting a final response to a user issuing a task execution request.
  • An RM gateway is also adapted to implement the method 20 for updating the topology of the mesh communication network 1 .
  • an RM gateway is adapted to manage the dynamics of the loT nodes and to broadcast a state of a topology of the mesh communication network 1 , as it is known to the RM gateway, to the other gateways of the mesh communication network 1 .
  • An RM gateway also synchronizes with each other the GTT and TTT tables stored by the gateways of the mesh communication network 1 .
  • the RM gateway is also adapted to implement a method 30 of forming the computing units UC by grouping the loT nodes.
  • the RM gateway can determine a group of loT nodes and add new loT nodes to this group without consulting other gateways, having to propagate the information concerning this addition only once the decision has been made.
  • an RM gateway is adapted to optimally choose an OC node for each computing unit UC.
  • Using a central RM gateway simplifies the management of the highly dynamic GTT, SFTT and TTT tables that are used for task execution. [0087] Although gateway failures are considerably less frequent than those of loT nodes, an RM gateway may fail or disconnect from the mesh communication network 1 , in which case a new RM gateway is elected.
  • a dispatcher responds to requests from an RM gateway.
  • time is divided into periods of variable length called eras.
  • the eras are numbered with a consecutive integer.
  • eras act as logical clocks, allowing gateways to identify the most recent information.
  • the eras and table indexes (gtt ndex and ttt ndex) are used for the synchronization of the GTT and TTT tables as will be seen in detail later.
  • a gateway in the candidate state is used to elect a new RM gateway.
  • the gateway increments its era by one, initializes its indexes of the GTT and TTT tables to 0, triggers the election process of an RM gateway and resets an election timer (election delay).
  • the nodes of the mesh communication network 1 communicate using asynchronous remote procedure calls (RPCs) via asynchronous message devices deployed on the gateways.
  • RPCs remote procedure calls
  • An asynchronous message device deployed on a gateway makes it possible to transmit a message from the gateway to the loT nodes of the subnetwork attached to this gateway.
  • the messages are then delivered at most once to the recipients in order to improve performance.
  • a message intended for an loT node is however retransmitted by a gateway in the event that an error has occurred during the connection of the loT node with the gateway. The messages are retained until they are consumed or deleted.
  • Gateways can clean up the message stacks of loT nodes to clear old, unconsumed messages that arrived at the gateway while those recipient loT nodes were unavailable.
  • Different messages are defined. Each message includes a type, identifiers of a sending node and a receiving node, an era of the information carried by this message, a table index and a useful part ("payload" in English).
  • a message can be of one of the following four types 1, 2, 3 or 4:
  • GTT table intended to be known to a recipient
  • TTT table intended to be known to a recipient.
  • the table index of a message can be equal to gtt ndex for messages of type
  • the useful part of the message depends on the message type. If type 1 then the part includes a follower duty cycle ("duty-cyle" in English). The follower duty cycle is defined in milliseconds by three values ⁇ Active, Busy, Asleep> with the addition of these three values less than 120s). If type 2 then the useful part includes a GTT table. If type 3 then the useful part includes the SFTT table. If type 4 then the useful part includes the TTT table.
  • a receiver When a receiver receives a new message of type 1, 2, 3 or 4, if the information in the received message is relevant, i.e. if the era of this message is greater than the current era of the receiver, the receiver updates its era and updates its local information.
  • the information in the received message may also be relevant if the era of this message is equal to the current era of the receiver and if the index of this message is greater than a table index of the receiver (gttjndex or ttt ndex).
  • the receiver updates its local information, i.e. it updates the table index concerned which then becomes equal to the index carried by the received message and updates the corresponding table according to the useful part of this received message.
  • an update history log is updated by adding an entry for any new information in the message that is not already present in the log and by removing entries from the log that do not match the information carried by the received message.
  • An update history log is updated by adding an entry for any new information from the message that is not already present in the log and by deleting log entries that do not match the information carried by the received message.
  • FIG. 2 illustrates a flowchart of the different steps of the method for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.
  • a step 110 computing units UC are obtained, each computing unit UC comprising loT nodes of the mesh communication network 1.
  • Each computing unit UC is attached to a gateway of the mesh communication network 1 and forms a subnetwork of the mesh communication network.
  • a gateway is elected as an RM gateway among the gateways of the mesh communication network 1, said RM gateway minimizing a number of messages exchanged in the mesh communication network for the execution of tasks.
  • an OC node is elected by the RM gateway for each computing unit UC, an OC node of a computing unit being elected from among the nodes of said computing unit based on the performance and availability of the nodes of said computing unit.
  • the RM gateway accepts a task execution request sent by a user.
  • Each request (called a “Function Execution Request” (FER) in English) contains a stateless function to be executed by loT nodes of a CPU.
  • a FER request is composed of function scripts to be executed and libraries required to execute these scripts.
  • the RM gateway assigns the request to nodes of a computing unit UC for the execution of the tasks of this request by the nodes of this computing unit UC.
  • the node OC of said computing unit UC collects at least one intermediate response, each intermediate response being either obtained by the node OC or emitted by a follower node of the computing unit to the node OC following the execution of the task by said follower node of the computing unit UC.
  • the OC node determines a final response from a majority vote based on collected intermediate responses.
  • a step 180 the OC node transmits the final response to the RM gateway.
  • a step 190 the RM gateway transmits the final response to the user.
  • a step 135 the topology of the mesh communications network 1 is updated and broadcast to all the gateways of the mesh communications network 1.
  • the task is assigned to another computing unit UC.
  • the RM gateway checks the presence of each request received by the RM gateway in its local cache memory.
  • the RM gateway sends the final stored response to the user and refreshes the cache.
  • the RM gateway adds the query to its gateway TTT table as a new entry, increments the TTT table index, and sends an asynchronous message carrying the query to the nodes of a compute unit assigned to execute the query.
  • This variant gives priority to the computing units formed by the least defective nodes at a given time.
  • the RM gateway stores the final response in the entry of its local TTT table relating to the request, sends the final response to the user and synchronizes its TTT table with that of the distributors of the mesh communication network 1.
  • FIG. 3 illustrates an example of execution of the tasks according to a particular and non-limiting example of embodiment of the present invention.
  • a user CI1 issues a request referenced f11 to a gateway RM.
  • the gateway RM checks whether f11 matches an entry in one of its cache memories.
  • f11 corresponds to a referenced request f2 stored in the referenced cache memory FIFO of the RM gateway.
  • the RM gateway then sends to the user Cl 1 the final response Rf2 stored in the cache memory FIFO in relation to f2.
  • f11 does not match an entry in the FIFO cache.
  • the RM gateway then stores the new request f11 in the cache and increments the table index TTT ttt ndex by one, which increases to 2.
  • the RM gateway also selects a computing unit UC formed, according to the example of FIG. 3, of a node OC and two follower nodes F1 and F2 and transmits f11 to the node OC and to the nodes F1 and F2.
  • the OC node executes the request f11 and obtains an intermediate response referenced a.
  • Node F1 executes request f11 and provides an intermediate response c to node OC.
  • Node F2 executes request f11 and provides an intermediate response a to node OC.
  • the OC node therefore obtains a majority of votes and considers the intermediate response a as being the final response (step 170).
  • the OC node then sends the final response a to the RM gateway (step 180) which stores it in the FIFO memory in relation to the new entry corresponding to the request f11.
  • the RM gateway then sends the final response a to the user CL1 (step 190).
  • the cache memory can follow the principle of a FIFO stack (First In First Out). In this case, when the maximum number of cache entries is reached, any new entry implies the deletion of an entry stored in the cache memory. This is illustrated in Figure 3: Recording f11 implies the deletion of an entry corresponding to a query f1 .
  • the content of the cache memory of the RM gateway is synchronized with the contents of the cache memories of the other gateways in the same way as the GTT tables, that is to say that each time a new entry is added or deleted to the cache memory of an RM gateway, the index of the cache memory is incremented by one unit and asynchronous messages are broadcast to synchronize the cache memories of the other distributors of the mesh communication network 1 with the cache memory of the RM gateway.
  • the triggering of an election of an RM gateway is based on a heartbeat mechanism defined as follows.
  • a gateway When a gateway starts, it positions itself in the distributor state and broadcasts a type 2 message informing the other gateways of the mesh communication network 1 of the contents of its GTT table (of the SFTT tables that it knows). The gateway remains in this distributor state until it receives a message indicating that an RM gateway is valid or a message indicating that it must switch to a candidate state.
  • an RM gateway periodically broadcasts a type 2 message comprising its GTT table to the gateways of the mesh communication network 1 in order to maintain its authority and to keep the tables of all the gateways synchronized.
  • this distributor assumes that no RM gateway nor election process is in progress and triggers a new election to choose a new RM gateway (step 120).
  • a new election is triggered as soon as a gateway is disconnected from the mesh communication network 1.
  • a new election is triggered to verify whether a current RM gateway minimizes the number of messages exchanged in the mesh communication network for the execution of tasks.
  • the RM gateway triggers a new election of an RM gateway (step 120) by considering itself as a distributor. If the RM gateway is no longer the candidate gateway resulting from an election, the RM gateway increases the era and determines its successor, by propagating its choice both to the new candidate gateway and to the rest of the distributors of the mesh communication network 1.
  • This succession mechanism makes it possible to accelerate the election of a new RM gateway (step 120) and to ensure over time the optimality of a current RM gateway.
  • a dispatcher receives a message from another gateway, RM or dispatcher at any time with a higher era or table index than its era (or with the same era or table index from a different RM gateway) while having already considered an active RM gateway. This case may probably be due to malicious behavior or segmentation of the mesh communication network 1 .
  • the distributor alerts the active RM gateway, which merges its GTT table with the GTT table of the other RM gateway, triggers the election process again to lead to an election of a single RM gateway.
  • an RM or candidate gateway is "obsolete"
  • this gateway is assumed to have temporarily lost the network connection.
  • This gateway synchronizes with the era and table indexes of the RM gateway and triggers a new RM gateway election (step 120), returning to the dispatcher state.
  • This same mechanism works in the opposite direction when receiving an old era number from another dispatcher.
  • an election expiration time of the RM gateway elapses without receiving any request sent by the RM gateway, a distributor increments its era by one unit and launches a new election of a new RM gateway.
  • a candidate gateway receives a message from a node claiming to be an RM gateway for the same or higher era, the candidate gateway switches to the dispatcher state.
  • the candidate gateways merge their GTT tables, increase the era and trigger a new RM gateway election (step 120).
  • the election of an RM gateway is implemented by a method 40 of deterministic election of an RM gateway based on a list of all the distributors of the mesh communication network 1 (figure 4)
  • a distributor increments its era by one unit.
  • a candidate gateway is determined among the distributors in the distributor list.
  • a most recent GTT table in the mesh communication network 1 is considered.
  • This GTT table contains a list of dispatchers, each having a list of connected nodes and their computing capabilities. This list excludes the RM gateway.
  • steps 430, 440 and 450 are executed.
  • step 430 a number of totalMessages is initialized to 0.
  • step 440 for each dispatcher disp of the list of dispatchers, a number expectMsgs of messages that are expected to be exchanged between the dispatcher DispLeadTmp and the dispatcher disp is determined by considering that the dispatcher DispLeadTmp is elected RM gateway. The total number of messages totalMsgs is then updated by: totalMsgs + expectMsgs *distance(dispLeadTmp, disp) in which distance(DispLeadTmp, disp) specifies a distance between the dispatchers DispLeadTmp and disp.
  • step 450 if the total number of messages totalMsgs is less than an optimal number of messages optimalNumberOfMsgs then the dispatcher DispLeadTmp is considered as an RM gateway and a variable optimalDispatcher is updated with the identifier of the dispatcher DispLeadTmp.
  • the optimal number of messages optimalNumberOfMsgs is also equal to the total number of messages totalMsgs.
  • the optimalDispatcher variable indicates which dispatcher was elected as the candidate gateway and the optimalNumberOfMsgs variable indicates the total number of messages relating to this dispatcher.
  • some dispatchers may not respond within a time period less than an election expiration time. Each of these dispatchers that has exceeded this election expiration time in turn performs the election process 40 and informs the candidate gateway resulting from the first election that, to its knowledge, this candidate gateway is the most optimal RM gateway for this new era. If a dispatcher of the mesh communication network 1 receives one of these messages, it attempts to reach this candidate gateway. If it succeeds then this gateway is considered to have voted for this candidate gateway to be the new RM gateway. If the dispatcher is unable to wait for this candidate gateway, it will trigger an election in the remaining dispatchers that have not already voted for this candidate gateway. Then, this dispatcher transitions to the candidate gateway state until one of three events occurs: (a) it wins the election, (b) another dispatcher wins the election or is already the RM gateway, or (c) an election period elapses without a winner.
  • majority rule ensures that only one candidate gateway can win the election for a particular era.
  • a candidate gateway may receive a message from another candidate gateway claiming to be the RM gateway. If the era of this RM gateway is at least as large as the current era of the candidate gateway, the candidate gateway recognizes it as a legitimate RM gateway and returns to the dispatcher state. However, if the era of this RM gateway is smaller than the current era, the message is rejected and the candidate gateway remains in the candidate state.
  • event c at the end of an election period, none of the candidate gateways have enough votes to win or lose the election. This can happen if there are multiple fractures in the mesh communication network 1 that do not allow the dispatchers to have an up-to-date GTT table. When this happens, each candidate gateway sends its GTT table to the rest of the candidate gateways. This merges the GTT tables and the election process is re-run, increasing the era. This time, it is confirmed that all participating dispatchers share the same GTT table, and thus the same candidate gateway. Once a candidate gateway wins the election, that gateway propagates the decision to the rest of the dispatchers.
  • FIG. 5 illustrates a flowchart of the different steps of the method 20 for updating the topology of the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.
  • the gateway to which a subnetwork is attached determines the availability of each node of this subnetwork and updates its SFTT table to indicate the availability and characteristics of each available node of the subnetwork.
  • Each gateway then tracks loT node faults flexibly since each loT node has different availability and periodicity.
  • each loT node of each subnetwork periodically emits a message to indicate that it is available. If a gateway attached to a subnetwork does not receive said message or a message relating to an execution of a task of an loT node of said subnetwork during a given period, said gateway assumes that the loT node has disconnected and purges it from its SFTT table. Similarly, if a gateway attached to a subnetwork receives a message for the first time relating to an execution of a task of an loT node of said subnetwork, said gateway assumes that the loT node is connected and adds it to its SFTT table.
  • a step 220 the SFTT tables of the gateways are broadcast to the gateways of the mesh communication network 1 so that the new topology of a subnetwork is known to all the gateways of the mesh communication network 1.
  • FIG. 6 illustrates an example of broadcasting an SFTT table in the mesh communication network 1 according to a particular and non-limiting example of the present invention.
  • the mesh communication network 1 comprises an RM gateway and four distributors D2 to D5.
  • the RM gateway includes a local GTT table formed from the union of its local SFTT table referenced SFTT1 and the SFTT tables of each of the distributors D2 to D5 referenced respectively SFTT2, SFTT3, SFTT4 and SFTT5.
  • step 221 the RM gateway periodically broadcasts a type 2 message to broadcast its GTT table to all the other distributors of the mesh communication network 1.
  • step 222 if the information in the received message is relevant, this dispatcher updates its GTT table and the information it stores based on the relevant information carried by this received message.
  • the distributor D2 thus stores its local SFTT table referenced SFTT2, the GTT table referenced GTT1 carried by the received message.
  • Each other distributor D3 to D5 does the same.
  • each distributor sends a type 3 message carrying its SFTT table to the RM gateway.
  • the RM gateway compares the SFTT table of each message received with information that it knows from the subnetwork corresponding to this SFTT table (local SFTT tables forming the local GTT table).
  • step 225 the RM gateway merges the changes into its local GTT table and increases the index of the GTT table.
  • the index increases by only one unit each period, regardless of the number of changes detected.
  • the distributors D3 and D4 each have an SFTT table modified by the appearance or disappearance of at least one loT node in their subnetwork. These modified SFTT tables are referenced SFTT3’ and SFTT4’.
  • the distributors D3 and D4 then each send a type 3 message to the RM gateway which detects a change in the SFTT tables of the distributors D3 and D4.
  • the GTT table index only increases by one unit each period, regardless of the number of changes detected.
  • the RM gateway broadcasts the new GTT table to all the distributors of the mesh communication network 1.
  • the distributors D2 to D5 are then informed of the new GTT table (GTT2) of the RM gateway during a next broadcast of the type 2 message (step 221).
  • the SFTT table has a list of a dozen nodes, and the GTT table has a list of dozens of SFTT tables for example.
  • the RM gateway compares the pair ⁇ era, table index> of the received message to that stored locally, which makes it possible to identify which is the most recent table among SFTT tables and the local GTT table. The process then continues by comparing the SFTT tables with each other once the SFTT tables contained in the received message are more recent than the local GTT table (have a higher era or the same era but a higher table index than that of the SFTT table of the GTT table).
  • FIG. 7 illustrates a flowchart of the different steps of the method 30 for forming the calculation units by grouping loT nodes, according to a particular and non-limiting exemplary embodiment of the present invention
  • each UC computing unit is highly dependent on the timeliness of receiving at least half of the votes from the UC nodes so that the OC node can determine a final response to a query.
  • the computational unit formation method attempts to minimize the gap between the availability periods of the nodes.
  • the RM gateway classifies the loT nodes according to their degree of availability and their computing capacities: an loT node is said to be efficient when its degree of availability and its computing capacities are high and said to be non-efficient otherwise.
  • the computation unit formation method also examines the current computation unit distribution to assign nodes to a computation unit so as to minimize changes in this distribution.
  • a number of calculation units N is calculated as a function of a number of nodes M per calculation unit.
  • N is equal to 5.
  • This embodiment is advantageous because it makes it possible to obtain optimal calculation performances according to tests carried out by the inventor.
  • each computing unit UC is formed by grouping N loT nodes of the mesh communication network 1, at least one of said nodes being efficient and at least one of said nodes being non-efficient.
  • the N fastest nodes are for example distributed among the computing units UC.
  • each calculation unit comprises an OC node.
  • a computing unit comprises 5 nodes
  • one of the nodes of a computing unit is considered to be a computing orchestrator node
  • two other nodes are high-performance nodes
  • two other nodes are non-performance nodes.
  • each computing unit UC forms a subnetwork of the mesh communication network 1 which is attached to a gateway of the mesh communication network 1.
  • the gateway stores a table SFTT representing the availability and the characteristics of the loT nodes of the subnetwork.
  • the loT nodes of this computing unit UC are informed of their attachment to this computing unit UC.
  • This method of forming computing units makes it possible to increase the number of computing periods and to homogenize the capacities of the infrastructure of the mesh communication network 1 while seeking to maintain a previous distribution of nodes.
  • This computational unit formation method may consume significant resources and add overhead to the mesh communication network control method 1 .
  • this computational unit formation process cannot be executed every time an loT node disconnection occurs without greatly penalizing the performance of the mesh communication network control method 1 .
  • the method of forming a calculation unit only occurs if one of the following conditions is verified:
  • a compute unit does not contain an OC node or a high-performance loT node
  • the RM gateway monitors the loT nodes to ensure that these rules are respected.
  • the RM gateway gives priority to the execution of tasks towards the UC computing units with all their quorum of active efficient nodes.
  • the RM gateway informs the OC node of a computing unit UC each time a change occurs in this computing unit UC concerning the number of nodes of this computing unit.
  • the RM gateway when a disconnection of an OC node from a computing unit UC occurs, the RM gateway must choose another OC node for this computing unit UC among the nodes of this computing unit UC so that this computing unit UC is operational until the computing unit formation process is executed again.
  • each computing unit can tolerate one node disconnection outside the quorum of performing nodes and up to three disconnections if two of them are non-performing nodes.
  • an loT node of a computing unit UC receives a message carrying a request to execute tasks, this loT node executes these tasks and returns its result to the OC node of this computing unit UC.
  • the OC node which knows the state of the computing unit UC, then checks whether it is able to obtain a majority vote.
  • the voting method used by the OC node is a variant of the voting process known as DLV [S. Jajodia et al. 1990. Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems]. DLV dynamically sets a vote majority threshold based on the number of connected nodes, which improves the flexibility and performance of the voting process. In case of a tie, the OC node favors its intermediate response over a FER or, if its intermediate response is not among the tied intermediate responses, the first intermediate response that reaches the tied quantity is retained as the final response.
  • DLV Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems.
  • DLV dynamically sets a vote majority threshold based on the number of connected nodes, which improves the flexibility and performance of the voting process. In case of a tie, the OC node favors its intermediate response over a FER or, if its intermediate response is not among the tied intermediate responses, the first intermediate response that reaches the tied quantity
  • Using the DLV-based voting process requires at least n + 2 servers per CPU to be able to tolerate n failures instead of the 2n + 1 required by Raft. This property allows CPUs to operate with fewer members with an acceptable level of fault tolerance, which is critical in a faulty and highly dynamic environment.
  • FIG. 8 schematically illustrates a device for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.
  • the device 23 is for example configured for the implementation of at least one of the steps of at least one method 10, 20, 30 or 40.
  • the elements of the device 23, individually or in combination, can be integrated into a single integrated circuit, into several integrated circuits, and/or into discrete components.
  • the device 23 can be produced in the form of electronic circuits or software (or computer) modules or even a combination of electronic circuits and software modules.
  • the device 23 is coupled in communication with other similar devices or systems, for example the computers 20, 21 and/or 22 and/or with communication devices, for example a TCU (from the English “Telematic Control Unit” or in French “Telematic Control Unit”), for example via a communication bus or through dedicated input/output ports.
  • a TCU from the English “Telematic Control Unit” or in French “Telematic Control Unit”
  • the device 23 comprises one (or more) processor(s) 230 configured to execute instructions for carrying out at least part of the steps of at least one method 10, 20, 30 or 40 and/or for executing the instructions of the software(s). embedded in the device 23.
  • the processor 230 may include integrated memory, an input/output interface, and various circuits known to those skilled in the art.
  • the device 23 further comprises or is in association with at least one memory 231 corresponding for example to a volatile and/or non-volatile memory and/or comprises a memory storage device which may comprise volatile and/or non-volatile memory, such as EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic or optical disk.
  • the computer code of the embedded software(s) comprising the instructions to be loaded and executed by the processor is for example stored in the memory 231.
  • the device 23 comprises a block 232 of interface elements for communicating with external devices, for example a remote computing device.
  • the interface elements of the block 232 comprise one or more of the following interfaces:
  • RF radio frequency interface for example of the Bluetooth® or Wi-Fi® type, LTE (Long-Term Evolution), LTE-Advanced;
  • USB interface from the English “Universal Serial Bus” or “Universal Serial Bus” in French);
  • HDMI interface from the English “High Definition Multimedia Interface” or “High Definition Multimedia Interface” in French);
  • the device 23 comprises a communication interface 233 which makes it possible to establish communication with other devices, such as the on-board computers 20, 21 and/or 22 of the vehicle via a communication channel 234.
  • the communication interface 233 corresponds for example to a transmitter configured to transmit and receive information and/or data via the communication channel 234.
  • the communication interface 233 corresponds for example to a wired network of the CAN type (from the English “Controller Area Network” or in French “Controller Area Network”), CAN FD (from the English “Controller Area Network Flexible Data-Rate” or in French “Flexible Data Rate Controller Network”), FlexRay (standardized by the ISO 17458 standard) or Ethernet (standardized by the ISO/IEC 802-3 standard).
  • the present invention is not limited to the exemplary embodiments described above but extends to a method of controlling a mesh communication network for the execution of tasks relating to stateless functions which would include secondary steps without thereby departing from the scope of the present invention. The same would apply to a device configured for the implementation of such a method.
  • the present invention also relates to a vehicle, for example an automobile or more generally an autonomous vehicle with a land motor, comprising the device of figure 8.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé et un dispositif de contrôle d'un réseau de communication maillé pour l'exécution de tâches relatives à des fonctions sans état, ledit réseau de communication maillé comprenant des nœuds appelés passerelle et des nœuds loT. Le procédé regroupe (110) les nœuds loT en unités de calcul, élit (120) une passerelle gestionnaire de ressources qui élit (130) un nœud orchestrateur de calcul par unité de calcul. Le procédé calcule (170) une réponse à une requête par un vote à la majorité basé sur des réponses intermédiaires collectées (160) par les nœuds loT d'une unité de calcul. La réponse finale est alors transmise (180) par le nœud orchestrateur de calcul à la passerelle gestionnaire des ressources qui la transmet (190) à un utilisateur émetteur de la requête.

Description

DESCRIPTION
Titre : Procédé et dispositif de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état
Domaine technique
[0001] La présente invention revendique la priorité de la demande française 2302508 déposée le 17.03.2023 dont le contenu (texte, dessins et revendications) est ici incorporé par référence. La présente invention concerne l’exécution de tâches relatives à des fonctions sans état en périphérie d’un réseau de communication maillé comprenant des nœuds loT. En particulier, la présente invention concerne le contrôle d’un tel réseau de communication maillé.
Arrière-plan technologique
[0002] Avec les nouvelles formes d'objets connectés, smartphones et ordinateurs, les applications mises en œuvre sur ces objets connectés ont progressivement accru leur demande de connectivité et de puissance de calcul. Cette augmentation des besoins en ressources des applications s'est accompagnée d'une augmentation constante des caractéristiques embarquées, de la consommation d'énergie et du prix des appareils.
[0003] Dans le but de maintenir les appareils abordables pour le public et d’exécuter des tâches relatives, par exemple, à des fonctions sans état dans un environnement optimal en termes de ressources, le « cloud computing» (« calcul dans le nuage », en français) a étendu ses services en ajoutant des nœuds à la périphérie des réseaux de communication maillés : Ceux-ci sont communément appelés Fog (en anglais, « brouillard » en français) ou Edge (en anglais, « bordure » en français).
[0004] Dans le « cloud computing», les nœuds périphériques supportent moins de ressources de calcul que les autres nœuds du « cloud ». Leur latence et leur charge réseau inférieures sont toutefois suffisantes pour répondre aux demandes des applications actuelles. Même si l'ajout de ressources en périphérie des réseaux de communication maillés résout les problèmes de demande de ressources actuelles, le « cloud computing» repose toujours sur des ressources informatiques qui devront évoluer dans le temps. Le développement du « cloud computing» est par conséquent fragile économiquement et écologiquement car il peut être fortement impacté par de futures pénuries en semi-conducteurs et/ou par des crises de ressources.
[0005] Pour améliorer les capacités de la couche périphérique du « cloud » sans déployer des quantités massives de ressources informatiques supplémentaires, il est nécessaire de tirer profit des ressources qui sont déjà déployées.
[0006] Les appareils loT (de l’anglais « Internet of Things », en français « l’Internet des objets ») sont une source majeure de ressources informatiques sous-utilisée. Leur nombre augmente de manière exponentielle permettant ainsi de suivre l’évolution des besoins du « cloud computing». Les nœuds loT sont généralement caractérisés par leur manque de ressources embarquées (calcul, énergie et stockage), leur disponibilité intermittente et leurs défauts. Ces nœuds subissent généralement des interruptions de réseau et des plantages inattendus qui les laissent injoignables pendant de longues périodes. Ces nœuds loT peuvent également rencontrer des fautes byzantines en raison de caractéristiques bas de gamme ou d'attaques malveillantes.
[0007] Pour utiliser des nœuds loT pour le « cloud computing», il est donc nécessaire de mettre en œuvre un procédé de contrôle des infrastructures des réseaux de communication maillés pour dépasser les défauts des nœuds loT et ainsi assurer la sécurité et la disponibilité des calculs de tâches à la périphérie du « cloud ».
[0008] [Fig. 1] illustre schématiquement d’un réseau de communication maillé 1 , selon un exemple de réalisation particulier et non limitatif de la présente invention.
[0009] Le réseau de communication maillé 1 correspond avantageusement à un réseau de type cellulaire, par exemple un réseau cellulaire de téléphonie mobile. Un tel réseau cellulaire est composé d’un ensemble de cellules, chaque cellule correspondant à une zone de couverture géographique d’une antenne de communication (aussi appelée station de base) permettant d’établir des communications radio entre utilisateurs (aussi appelés clients ou usagers, chaque utilisateur étant porteur d’un dispositif de communication mobile) et/ou entre les utilisateurs et le réseau de communication maillé 1 . La taille d’une cellule varie et est par exemple comprise entre 1 km et quelques dizaines de kilomètres (par exemple 20 ou 30 kms).
[0010] Un utilisateur correspond par exemple à une personne physique portant un dispositif de communication mobile de type téléphone intelligent (de l’anglais « smartphone ») ou une tablette. Selon une variante, un utilisateur correspond à un véhicule embarquant un dispositif de communication de type calculateur, par exemple une unité de contrôle télématique, dite TCU (de l’anglais « Telematic Control Unit »), ou un dispositif de communication mobile de type téléphone intelligent embarqué dans le véhicule et connecté à ce dernier via une liaison filaire (par exemple de type USB (de l’anglais « Universal Serial Bus » ou en français « Bus série universel »)) ou sans fil (par exemple de type Bluetooth® ou Wifi®).
[0011] Le réseau de communication maillé 1 met en œuvre par exemple des communications selon la technologie LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Avanced (de l’anglais « Long-Term Evolution - Advanced » ou en français « Evolution à long terme avancée »), C-V2X (de l’anglais « Cellular - Vehicle to Everything » ou en français « Cellulaire - Véhicule vers tout ») qui s’appuie sur la 4G et bientôt la 5G, basées sur LTE.
[0012] Le réseau de communication maillé 1 est destiné à exécuter des tâches relatives à des fonctions sans état. Ces tâches sont ordonnées par utilisateur au travers de requêtes émises via le réseau de communication maillé 1 . L’utilisateur reçoit alors des réponses à ses requêtes via le réseau de communication maillé 1.
[0013] La topologie du réseau de communication maillé 1 comprend des nœuds appelés passerelle pour indiquer que ces nœuds correspondent à des passerelles (serveurs) du réseau de communication maillé 1 , et des nœuds loT pour indiquer que ces nœuds correspondent à des appareils loT.
[0014] Selon l’exemple de la figure 1 , la topologie du réseau de communication maillé 1 a une dorsale entièrement connectée entre six passerelles P1 à P6 et un ensemble de sous- réseaux en étoile dans lesquels chaque passerelle P1 à P6 peut atteindre un groupe de nœuds loT (représentés par des cercles non référencés). Les cercles non référencés en traits pleins représentent des nœuds loT qui sont soient en sommeil soient éveillés. Les cercles gris clair représentent des nœuds loT ou des passerelles en panne, Les cercles en pointillé représentent des nœuds loT ou des passerelles en défaut. Les traits pleins représentent des liens de connexion viables tandis que les traits en pointillé représentent des liens de connexions en défaut.
[0015] Les passerelles P1 à P6 gèrent un grand ensemble de nœuds loT. Elles sont considérablement moins nombreuses que les nœuds loT mais plus ingénieuses et plus disponibles que les nœuds loT. Leur disponibilité est presque complète. Cependant, même si cela peut se produire beaucoup moins souvent que pour les nœuds loT, les passerelles peuvent subir des coupures de réseau, des plantages inattendus ou des attaques malveillantes. Ces attaques ont un impact plus important dans le cas du réseau de communication maillé 1 car elles refusent alors généralement le service de la passerelle et des appareils loT dans son sous-réseau.
[0016] Ainsi, il est impératif de prévoir un procédé de contrôle du réseau de communication maillé 1 qui gère les défauts des nœuds loT et des passerelles de manière à assurer une continuité de l’exécution des tâches relatives à des fonctions sans état dans le « cloud ».
[0017] La définition d’un tel procédé passe par la définition d’un modèle consensuel pour contrôler le réseau de communication maillé 1 .
[0018] Un tel modèle consensuel doit (i) garantir la sécurité du système dans les deux défauts byzantins et non byzantins qui incluent le partitionnement du réseau, les retards, l'impossibilité de joindre un nœud et la perte de paquets, (ii) maintenir la disponibilité du service dès qu’au moins une passerelle et trois nœuds loT sont disponibles, (iii) ne pas dépendre du moment pour synchroniser la topologie et l'exécution des tâches et mettre en œuvre un mécanisme communication intermédiaire asynchrone et (iv) être complété dès qu'une majorité est atteinte et pouvoir compenser la perte de performances causée par des nœuds plus lents.
[0019] Les modèles de consensus (algorithmes de consensus) sont nés de la nécessité d'apporter des solutions non triviales pour parvenir à un accord entre plusieurs machines de la manière la plus efficace et la plus fiable possible et renforcer la tolérance aux pannes des systèmes. Ces algorithmes, grâce à l'utilisation de plusieurs processus et mécanismes, garantissent une valeur de sortie unique entre un ensemble de valeurs possibles proposées par différentes machines (nœuds) sur un ensemble de machines (« cluster » en anglais).
[0020] Paxos (A.Yousefpour. 2019. All one needs to know about fog computing and related edge computing paradigms: A complete survey. In J. of Syst. Architecture. Elsevier., D.Ongaro. 2014. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference) est l’un de ces modèles de consensus. Paxos fonctionne en permettant à un groupe de nœuds de parvenir à un accord sur une valeur, en synchronisant ces valeurs et en les rendant apprenables pour tous les nœuds d’un groupe de nœuds. Pour ce faire, Paxos classe les nœuds en trois rôles (proposeur, accepteur et apprenant) ; il est possible qu'un nœud joue plus d'un rôle en même temps. Pour simplifier le comptage des votes et éviter la désynchronisation entre les nœuds lors de la réponse à différentes requêtes simultanées, ce modèle met en œuvre un processus en deux phases : (1 ) une phase de promesse et, une fois que la majorité des nœuds sont parvenus à un accord sur une valeur, (2) une phase de validation, au cours de laquelle le proposant détermine la réponse finale à une requête et propage le résultat à tous les nœuds du groupe de nœuds pour s'assurer que tout le réseau de communication maillé est synchronisé.
[0021] Paxos a été largement critiqué en raison de son applicabilité complexe aux systèmes distribués réels en raison de l'hétérogénéité du système et des contraintes de nœud de groupe. De multiples propositions ont tenté d'améliorer cette adaptabilité et de réduire la complexité de Paxos. Cependant, ce propositions sont encore trop complexes pour les systèmes utilisant des nœuds loT.
[0022] Ayant pour objectifs d'atteindre des niveaux de performances élevées et de faciliter la compréhension et la mise en œuvre du modèle de consensus, ainsi que l'adaptabilité aux systèmes distribués réels, Raft (L. Lamport. 2019. Time, docks, and the ordering of events in a distributed system. In Concurrency: the Works of Leslie Lamport) est alors apparu comme une alternative à Paxos pour la gestion de journaux (« log » en anglais) répliqués à travers tous les nœuds d’un groupe de nœuds. Même si Raft se concentre sur le stockage de réplication de données plutôt que sur l'exécution de tâches, la manière de parvenir à des accords sur la synchronisation et l'intégrité des données stockées repose sur les mêmes principes que Paxos. [0023] Pour simplifier la répartition des tâches (c'est-à-dire la coordination du système ou la maintenance de la topologie du réseau de communication maillé), Raft propose trois rôles exclusifs et différents des nœuds : (a) « meneur » (« leader » en anglais), le nœud est alors chargé de coordonner toutes les actions et demandes de gestion du système et de garantir la cohérence et l'organisation, (b) « suiveur » (« follower » en anglais), le nœud écoute alors passivement et suit les ordres du meneur, et (c) « candidat » (« candidate » en anglais), le nœud intervient alors pendant un processus d'élection du meneur. En plus de cette centralisation du pouvoir par le meneur, et du moyen de résoudre les incohérences dans la synchronisation des tables de journaux (« log » en anglais), Raft se base sur des horloges logiques de Lamport (L. Lamport. 2019. Time, docks, and the ordering of events in a distributed system. In Concurrency: the Works of Leslie Lamport.) en ajoutant un nombre de comptage (appelé « terme » (« term » en anglais) dans Raft) qui permet la détection des informations obsolètes et la restauration de la table de journaux (« log » en anglais) des nœuds. Cependant, malgré les simplifications et optimisations apportées par Raft, la complexité et le coût du processus de vote sur lequel repose ce modèle rend difficile son applicabilité aux réseaux de communication maillé comprenant des nœuds loT qui sont hautement mobiles et défaillants.
[0024] Pirogue (A.Munir et al. 2017. IFCIoT: Integrated Fog Cloud loT: A novel architectural paradigm for the future Internet of Things. In IEEE Consumer Electronics Magazine) se présente comme une variante de Raft. Pirogue se concentre sur la réduction élevée de son empreinte énergétique tout en conservant une performance similaire à celle de Raft. Dans Pirogue, le processus de vote statique classique est remplacé par un processus de vote linéaire dynamique (S. Jajodia et al. 1990. Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems.). Ce changement remplace la majorité de quorum statique classique par un quorum dynamique, nécessitant moins de nœuds pour obtenir une majorité en cas de déconnexion d’une passerelle (serveur). Pirogue propose un nouveau rôle des nœuds : témoin (« witness » en anglais), le nœud est alors capable de participer au quorum de consensus en cas de besoin. Ce rôle est mis en œuvre par des appareils à faible consommation n'ayant pas la capacité de stocker l'ensemble des données du système, ce qui réduit l'empreinte énergétique du groupe de nœuds.
[0025] Ces optimisations permettent à Pirogue d'atteindre des performances, une disponibilité et une tolérance aux pannes proches de celles d'un groupe à cinq nœuds modélisés par Raft avec des configurations à faible empreinte énergétique telles que des groupes à quatre nœuds ou trois nœuds et un témoin.
[0026] Les modèles de consensus actuels ne peuvent pas fonctionner sur des topologies de réseau de communication maillé 1 comprenant des nœuds loT hétérogènes du type de celles décrites en relation avec la figure 1 compte tenu de la forte hétérogénéité, des ressources restreintes des nœuds loT, de la disponibilité intermittente des nœuds loT, de la dynamique élevée des nœuds loT et du manque de connexion directe entre les nœuds loT au sein du réseau de communication maillé 1 .
[0027] En effet, les nœuds loT et les passerelles sont très hétérogènes entre eux en termes de ressources qui dépendent non seulement de leurs caractéristiques matérielles qui peuvent être soit haut de gamme, soit bas de gamme, mais aussi du rapport cyclique et logiciel de ces nœuds et passerelles, puisque le but recherché est d’utiliser les ressources de réserve des nœuds loT et des passerelles sans interrompre leurs fonctions d'origine.
[0028] Par ailleurs, les nœuds loT sont fortement restreints en ressources. Même si les passerelles sont beaucoup moins restreintes en ressources, elles représentent néanmoins une petite partie de l'ensemble des nœuds du réseau de communication maillé 1 . D'autre part, les appareils loT se caractérisent, pour la plupart d'entre eux, par leur manque de ressources matérielles (de calcul et de stockage) et leurs contraintes de batterie, puisqu'ils sont généralement alimentés par des batteries. Les modèles de consensus actuels sont généralement déployés sur des nœuds de serveur (passerelles) capables de stocker une copie complète des journaux (« log » en anglais) des nœuds du réseau de communication, ce qui n'est pas le cas pour les nœuds loT.
[0029] De plus, les nœuds loT ont une disponibilité intermittente. Malgré les capacités de connectivité élevées des passerelles, les nœuds loT subissent souvent des coupures de réseau et des plantages inattendus. Leur disponibilité est donc peu fiable, imprévisible et généralement intermittente. [0030] De plus, les modèles de consensus reposent sur un grand nombre de messages de coordination et de synchronisation transmis sur une dorsale entièrement connectée, mais compte tenu de la taille des topologies de réseau de communication maillé comprenant des nœuds loT, plusieurs dorsales sont présentes nécessitant que les messages passent par plusieurs nœuds intermédiaires avant d’atteindre leur destination. Ainsi, la réduction du nombre de messages est nécessaire pour améliorer les performances d’un modèle de consensus.
[0031] De plus, les nœuds loT sont des nœuds hautement mobiles, à la fois physiquement et d'un point de vue réseau. Cela complique le maintien d’une synchronisation complète des tables de journaux (« log » en anglais) comme cela est requis par les modèles de consensus actuels.
[0032] Il est donc nécessaire de définir un modèle de consensus qui puisse être déployé sur une réseau de communication maillé 1 comprenant des passerelles et des nœuds loT qui répondent aux différentes limitations des modèles de consensus actuels exposées ci-dessus.
[0033] Résumé de la présente invention
[0034] Un objet de la présente invention est de résoudre au moins l’un des problèmes de l’arrière-plan technologique décrit précédemment.
[0035] Un objet de la présente invention est une plate-forme de service informatique collaborative ciblant l'exécution de fonctions sans état et utilisant des nœuds loT ayant une disponibilité faible à moyenne d’une infrastructure d’un réseau de communication déjà déployée.
[0036] La présente invention repose sur un modèle de consensus original qui peut s'apparenter aux modèles de consensus de l’état de la technique tels que Raft ou Pirogue. Mais le modèle de consensus de la présente invention étend ces modèles de consensus classiques en ajoutant :
(i) des rôles et une classification des nœuds : Le modèle de consensus divise les nœuds en deux couches en fonction de leurs capacités énergétiques et de calcul : une première couche, qui contient peu les passerelles susceptibles d’être gestionnaire des ressources du réseau de communication maillé, et une deuxième couche, qui contient de nombreux nœuds loT. De plus, les nœuds loT sont regroupés dynamiquement en sous-réseau, encore appelé unité de calcul UC, en fonction de leur degré de disponibilité et des leurs capacités de calcul, pour optimiser l’exécution des tâches relatives à des requêtes utilisateur. Ainsi, PCM opère sur un ensemble hétérogène de couches.
(ii) un contrôle du réseau de communication maillé à deux niveaux : au niveau d’une passerelle alors gestionnaire des ressources qui est élue dynamiquement et au niveau de chaque sous-réseau en élisant un nœud orchestrateur de calcul OC pour chaque sous-réseau.
(iii) des possibilité de mise à jour dynamique des sous-réseaux et de l’élection de nœud OC pour répondre à un environnement loT mobile hautement dynamique qui entraîne la modification de chacun des sous-réseaux.
[0037] Ce modèle de consensus a pour objectif de compenser les limitations des nœuds loT (c'est-à-dire une forte hétérogénéité, des ressources restreintes, une disponibilité intermittente, une forte dynamique et un manque de connexion directe entre les nœuds au sein de la plateforme) pour garantir la tolérance aux pannes, la synchronisation des informations dans le réseau de communication maillé et la coordination de l’exécution des tâches.
[0038] La présente invention permet l’exécution de tâches par une infrastructure d’un réseau de communication maillé faiblement connecté en optimisant l'élection d’une passerelle gestionnaire des ressources qui réduit le nombre total de messages échangés.
[0039] Le contrôle à deux niveaux et le regroupement des nœuds de leur degré de disponibilité et de leur capacité de calcul permettent de compenser leurs erreurs et d'améliorer les performances globales de l’exécution de tâches par le réseau de communication maillé.
[0040] La présente invention limite la consommation énergétique pour l’exécution de tâches en périphérie du « cloud » car elle utilise les ressources d’appareils loT au lieu des nœuds classiques en périphérie du « cloud ». [0041] La présente invention centralise la gestion des ressources d’un nombre important de nœuds loT sans pour autant augmenter considérablement les messages échangés ni ralentir les performances du réseau de communication maillé.
[0042] Etant donné que la présente invention améliore la tolérance aux pannes et la coordination des tâches, elle participe à réduire les ressources embarquées nécessaires aux véhicules, réduisant ainsi le prix du architectures embarquées de ces véhicules.
[0043] La présente invention offre de nombreuses possibilités pour le développement de futures applications résilientes Vehicle-to-Anything (V2X) qui pourraient être commercialisées.
[0044] Selon un premier aspect, la présente invention concerne un procédé de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état, ledit réseau de communication maillé comprenant des nœuds appelés passerelle pour indiquer que ces nœuds correspondent à des passerelles du réseau de communication maillé et des nœuds appelés nœuds loT pour indiquer que ces nœuds correspondent à des appareils connectés à internet, ledit procédé comprenant les étapes suivantes :
- obtention d’unités de calcul à partir des nœuds loT, chaque unité de calcul comprend des nœuds loT et est rattachée à une passerelle pour former un sous-réseau du réseau de communication maillé ;
- élection d’une passerelle gestionnaire de ressources parmi les passerelles du réseau de communication maillé, ladite passerelle gestionnaire de ressources minimisant un nombre de messages échangés dans le réseau de communication maillé pour l’exécution de tâches ;
- élection, par la passerelle gestionnaire de ressources, d’un nœud orchestrateur de calcul pour chaque unité de calcul, un nœud orchestrateur de calcul d’une unité de calcul étant élu parmi les nœuds de ladite unité de calcul en fonction de performances et de disponibilité des nœuds de ladite unité de calcul ;
- acceptation, par la passerelle gestionnaire de ressources, d’une requête d’exécution de tâches émise par un utilisateur ;
- assignation, par la passerelle gestionnaire de ressources, de ladite requête à des nœuds loT d’une unité de calcul pour l’exécution de tâches de ladite requête par les nœuds loT de ladite unité de calcul ;
- collecte, par un nœud orchestrateur de calcul de ladite unité de calcul, d’au moins une réponse intermédiaire à ladite requête, chaque réponse intermédiaire étant soit obtenue par le nœud orchestrateur de calcul soit émise par un nœud loT de l’unité de calcul à destination du nœud orchestrateur de calcul suite à l’exécution de la tâche par ledit nœud loT de l’unité de calcul ;
- obtention, par le nœud orchestrateur de calcul, d’une réponse finale à partir d’un vote à la majorité basé sur les réponses intermédiaires collectées ;
- transmission de la réponse finale par le nœud orchestrateur de calcul à destination de la passerelle gestionnaire de ressources ; et
- transmission de la réponse finale par la passerelle gestionnaire de ressources à destination de l’utilisateur.
[0045] Selon un exemple de réalisation particulier et non limitatif, si la passerelle gestionnaire de ressources ne reçoit pas de réponse finale relative à ladite requête avant qu’un délai se soit écoulé, ladite requête est assignée à une autre unité de calcul.
[0046] Selon un exemple de réalisation particulier et non limitatif, le procédé comporte en outre une étape de vérification d’une présence de ladite requête dans une mémoire cache de la passerelle gestionnaire des ressources, et une étape d’envoi d’une réponse finale mémorisée dans la mémoire cache en relation avec ladite requête si ladite requête est mémorisée dans ladite mémoire cache.
[0047] Selon un exemple de réalisation particulier et non limitatif, le contenu de la mémoire cache de la passerelle gestionnaire des ressources est synchronisé avec les contenus des mémoires cache des autres passerelles du réseau de communication maillé.
[0048] Selon un exemple de réalisation particulier et non limitatif, la passerelle gestionnaire des ressources diffuse périodiquement aux passerelles du réseau de communication maillé un message comprenant une première table formée d’une union de plusieurs deuxièmes tables, chaque deuxième table représentant une disponibilité et des caractéristiques des nœuds loT d’un sous-réseau du réseau de communication maillé, si une passerelle ne reçoit aucun message pendant un délai d'expiration d’élection, ladite passerelle déclenche une nouvelle élection d’une passerelle gestionnaire de ressources.
[0049] Selon un exemple de réalisation particulier et non limitatif, une nouvelle élection d’une passerelle gestionnaire de ressources est déclenchée pour vérifier si une passerelle gestionnaire des ressources actuelle minimise le nombre de messages échangés dans le réseau de communication maillé pour l’exécution de tâches.
[0050] Selon un exemple de réalisation particulier et non limitatif, une nouvelle élection d’une passerelle gestionnaire de ressources est déclenchée dès qu’une passerelle du réseau de communication maillé est déconnectée.
[0051] Selon un exemple de réalisation particulier et non limitatif, le procédé comporte en outre une étape de mise à jour d’une topologie du réseau de communication maillé et de diffusion d’une topologie mise à jour à toutes les passerelles du réseau de communication maillé.
[0052] Selon un deuxième aspect, la présente invention concerne un dispositif de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention.
[0053] Selon un troisième aspect, la présente invention concerne un véhicule comprenant un dispositif selon le me aspect.
[0054] Selon un quatrième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur.
[0055] Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. [0056] Selon un cinquième aspect, la présente invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de la présente invention.
[0057] D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur.
[0058] D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet.
[0059] Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des figures
[0060] D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 8 annexées, sur lesquelles :
[0061] [Fig. 1] illustre schématiquement, selon un exemple de réalisation particulier et non limitatif de la présente invention ;
[0062] [Fig. 2] illustre un organigramme des différentes étapes du procédé 10 d’élection d’une passerelle gestionnaire de ressources selon un exemple de réalisation particulier et non limitatif de la présente invention ;
[0063] [Fig. 3] illustre un exemple de réalisation du procédé 10 de la figure 1 ; [0064] [Fig. 4] illustre un organigramme des différentes étapes du procédé 40 de contrôle du réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état, selon un exemple de réalisation particulier et non limitatif de la présente invention ;
[0065] [Fig. 5] illustre un organigramme des différentes étapes du procédé 20 de mise à jour de la topologie du réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état, selon un exemple de réalisation particulier et non limitatif de la présente invention ;
[0066] [Fig. 6] illustre un exemple de diffusion d’une table SFTT dans le réseau de communication maillé 1 selon un exemple particulier et non limitatif de la présente invention ;
[0067] [Fig. 7] illustre un organigramme des différentes étapes du procédé 30 de formation des unités de calcul, selon un exemple de réalisation particulier et non limitatif de la présente invention ;
[0068] [Fig. 8] illustre schématiquement un dispositif de contrôle du réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état, selon un exemple de réalisation particulier et non limitatif de la présente invention.
[0069] Description des exemples de réalisation
[0070] Des procédés et dispositifs vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 8. Des mêmes éléments sont identifiés avec des mêmes signes de référence tout au long de la description qui va suivre.
[0071] La présente invention concerne un procédé 10 de contrôle d’un réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état.
[0072] La présente invention concerne également un procédé 20 de mise à jour de la topologie du réseau de communication maillé 1 pour orchestrer l'exécution tolérante aux pannes des tâches sur des nœuds loT souvent défectueux ou indisponibles de ce réseau de communication maillé 1. [0073] La présente invention concerne également un procédé 30 de formation d’unités de calcul par regroupement de nœuds loT.
[0074] Selon la présente invention, chaque passerelle du réseau de communication maillé 1 mémorise à jour trois tables : une table de topologie globale (GTT de l’anglais « Global Topology Table), une table de topologie des nœuds du sous-réseau rattaché à la passerelle (SFTT de l’anglais « Sub-network Follower Topology ») et une table de suivi des tâches (TTT de l’anglais Task Tracking Table).
[0075] La table SFTT représente la disponibilité et les caractéristiques des nœuds loT d’un sous-réseau du réseau de communication maillé 1 comprenant plusieurs nœuds loT. Ce sous-réseau est rattaché à une passerelle. La table SFTT est mémorisée par chaque passerelle.
[0076] La table GTT d’une passerelle est formée par l’union de tables SFTT de d’autres passerelles qui sont connues de ladite passerelle. Un index de table gtt ndex est associé à chaque table GTT. Cet index de table est utilisé pour la synchronisation des tables GTT comme on le verra par la suite.
[0077] La table TTT comprend les tâches à exécuter et leur état d’exécution. Un index de table ttt ndex est associé à chaque table TTT. Cet index de table est utilisé pour la synchronisation des tables TTT comme on le verra par la suite.
[0078] Un nœud loT est soit dans un état « suiveur » (« follower » en anglais) soit dans un état orchestrateur de calcul (OC, « Calculus Orchestrator » en anglais).
[0079] Un nœud suiveur est un nœud loT passif c’est-à-dire qu’il n'émet aucune demande par lui-même. Un nœud suiveur exécute les demandes d’exécution de tâches qui lui sont assignées et envoie une réponse intermédiaire à un nœud OC de l’unité de calcul à laquelle appartient ce nœud suiveur.
[0080] Un nœud orchestrateur de calcul, dit nœud OC, est un nœud loT qui est élu pour chaque unité de calcul UC. Un nœud OC d’une unité de calcul UC exécute les demandes d’exécution de tâches qui lui sont assignées et obtient une réponse intermédiaire suite à l’exécution d’une tâche. Un nœud OC collecte également des réponses intermédiaires produites par des nœuds suiveurs de cette unité de calcul UC suite à l’exécution de cette tâche par les autres nœuds suiveurs de l’unité de calcul UC. Le nœud OC produit une réponse finale à partir d’un procédé de vote basé sur les réponses intermédiaires qu’il a obtenues comme on le verra par la suite.
[0081] Une passerelle peut être soit dans un état de gestionnaire de ressources (RM de l’anglais « Ressources Manager »), soit dans une état « répartiteur » (en anglais « dispatcher »), soit dans une état candidat (en anglais « Candidate »).
[0082] Une passerelle RM est adaptée pour la mise en œuvre du procédé 20 de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état. En particulier, une passerelle RM est adaptée pour gérer toutes les demandes des utilisateurs (si un utilisateur émet une requête vers une autre passerelle du réseau de communication maillé 1 , cette requête est redirigée vers la passerelle RM). Elle est également adaptée pour assigner une tâche à exécuter à des nœuds suiveurs d’une unité de calcul UC, pour sélectionner dynamiquement les nœuds OC et pour retransmettre une réponse finale à un utilisateur émetteur d’une demande d’exécution de tâche.
[0083] Une passerelle RM est également adaptée pour mettre en œuvre le procédé 20 de mise à jour de la topologie du réseau de communication maillé 1 . En particulier, une passerelle RM est adaptée pour gérer la dynamique des nœuds loT et de diffuser un état d’une topologie du réseau de communication maillé 1 , tel qu’il est connu de la passerelle RM, à destination des autres passerelles du réseau de communication maillé 1 . Une passerelle RM synchronise également entre elles les tables GTT et TTT mémorisées par les passerelles du réseau de communication maillé 1 .
[0084] La passerelle RM est également adaptée pour mettre en œuvre un procédé 30 de formation des unités de calcul UC par regroupement des nœuds loT.
[0085] Par exemple, la passerelle RM peut déterminer un groupe de nœuds loT et ajouter de nouveaux nœuds loT à ce groupe sans consulter d'autres passerelles, n'ayant à propager les informations concernant cet ajout qu'une fois la décision prise. En particulier, une passerelle RM est adaptée pour choisir de manière optimale un nœud OC pour chaque unité de calcul UC.
[0086] L’utilisation d’une passerelle RM centrale simplifie la gestion des table GTT, SFTT et TTT hautement dynamiques qui sont utilisées pour l’exécution des tâches. [0087] Même si des pannes des passerelles sont considérablement moins fréquentes que celles des nœuds loT, une passerelle RM peut échouer ou se déconnecter du réseau de communication maillé 1 , auquel cas une nouvelle passerelle RM est élue.
[0088] Un répartiteur répond aux requêtes d’une passerelle RM.
[0089] Selon la présente invention, le temps est divisé en périodes de longueur variable appelées ères. Les ères sont numérotées avec un nombre entier consécutif.
[0090] Les différents répartiteurs peuvent observer des transitions entre des ères à des moments différents, et ils peuvent ne pas toujours être conscients qu'une ou plusieurs élections se sont produites alors qu'ils étaient hors réseau. Ainsi, les ères agissent comme des horloges logiques, permettant aux passerelles d'identifier les informations les plus récentes.
[0091] Les ères et les index de table (gtt ndex et ttt ndex) sont utilisés pour la synchronisation des tables GTT et TTT comme on le verra en détails par la suite.
[0092] Une passerelle dans l’état candidat, en bref passerelle candidat, est utilisée pour élire une nouvelle passerelle RM. Lors de la conversion d’une passerelle en passerelle candidat, la passerelle incrémente son ère d’une unité, initialise à 0 ses index des tables GTT et TTT, déclenche le procédé d'élection d’une passerelle RM et réinitialise un chronomètre des élections (délai d’élection).
[0093] Compte tenu de la disponibilité et de la dynamique intermittentes des nœuds loT, les nœuds du réseau de communication maillé 1 communiquent à l'aide d'appels de procédure à distance asynchrones (RPC de l’anglais Remote Procedure Call) via des dispositifs de messages asynchrones déployés sur les passerelles. Un dispositif de messages asynchrones déployé sur une passerelle permet de transmettre un message de la passerelle vers les nœuds loT du sous-réseau rattaché à cette passerelle. Les messages sont alors livrés au maximum une fois aux destinataires afin d'améliorer les performances. Un message à destination d’un nœud loT est toutefois réémis par une passerelle dans le cas où une erreur s’est produite lors de la connexion du nœud loT avec la passerelle. Les messages sont conservés jusqu'à ce qu'ils soient consommés ou effacés. Les passerelles peuvent nettoyer les piles de messages des nœuds loT pour effacer les messages anciens non consommés qui sont arrivés sur la passerelle alors que ces nœuds loT destinataires n'étaient pas disponibles. [0094] Différents messages sont définis. Chaque message comprend un type, des identifiants d’un nœud émetteur et d’un nœud récepteur, une ère de l’information portée par ce message, un index de table et une partie utile (« payload » en anglais).
[0095] Selon un exemple de réalisation particulier et non limitatif, un message peut être de l’un des quatre types 1 , 2 3 ou 4 suivants :
[0096] configuration d’un nœud loT suiveur destinée à être connue par un répartiteur ;
[0097] table GTT destinée à être connue d’un destinataire ;
[0098] table SFTT destinée à être connue d’un destinataire ; et
[0099] table TTT destinée à être connue d’un destinataire.
[0100] L’index de table d’un message peut être est égal à gtt ndex pour les messages de type
1 à 3 et tttjndex pour les messages de type 4.
[0101] La partie utile du message dépend du type de message. Si type 1 alors la partie comprend un cycle de service suiveur (« duty-cyle » en anglais). Le cycle de service suiveur est défini en millisecondes par trois valeurs <Actif, Occupé, Endormi> avec l'addition de ces trois valeurs inférieure à 120s). Si type 2 alors la partie utile comprend une table GTT. Si type 3 alors la partie utile comprend la table SFTT. Si type 4 alors la partie utile comprend la table TTT.
[0102] Lors de la réception par un récepteur d'un nouveau message de type 1 , 2, 3 ou 4, si les informations du message reçu sont pertinentes, c’est-à-dire si l'ère de ce message est supérieure à l’ère actuelle du récepteur, le récepteur actualise son ère et met à jour ses informations locales. Les informations du message reçu peuvent aussi être pertinentes si l’ère de ce message est égale à l’ère actuelle du récepteur et si l’index de ce message est supérieur à un index de table du récepteur (gttjndex ou ttt ndex). Dans ce cas, le récepteur met à jour ses informations locales c’est-à-dire qu’il actualise l’index de table concerné qui devient alors égal à l’index porté par le message reçu et met à jour la table correspondante en fonction de la partie utile de ce message reçu. Si les informations du message reçu sont pertinentes, un journal d’historique des mises à jour est mis à jour en ajoutant une entrée pour toute nouvelle information du message qui ne serait pas déjà présente dans le journal et en supprimant les entrées du journal qui ne correspondraient pas aux informations portées par le message reçu. Un journal d’historique des mises à jour est mis à jour en ajoutant une entrée pour toute nouvelle information du message qui ne serait pas déjà présente dans le journal et en supprimant les entrées du journal qui ne correspondraient pas aux informations portées par le message reçu.
[0103] Si une entrée existante du journal est en conflit avec une nouvelle entrée, l'entrée existante et tout ce qui le suit sont supprimés.
[0104] Si les informations du message reçues sont obsolètes, c’est-à-dire si l’ère de ce message est inférieure à l’ère actuelle du récepteur ou si l’ère de ce message est égale à l’ère actuelle du récepteur et si l’index de ce message est inférieur à un index de table du récepteur alors le message est ignoré et le récepteur émet sa table GTT (message de type 2) et sa table TTT (message de type 4) à l’émetteur du message reçu.
[0105] [Fig. 2] illustre un organigramme des différentes étapes du procédé de contrôle du réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état, selon un exemple de réalisation particulier et non limitatif de la présente invention.
[0106] Dans une étape 110, des unités de calcul UC sont obtenues, chaque unité de calcul UC comprenant des nœuds loT du réseau de communication maillé 1 . Chaque unité de calcul UC est rattachée à une passerelle du réseau de communication maillé 1 et forme un sous-réseau du réseau de communication maillé.
[0107] Dans une étape 120, une passerelle est élue passerelle RM parmi les passerelles du réseau de communication maillé 1 , ladite passerelle RM minimisant un nombre de messages échangés dans le réseau de communication maillé pour l’exécution de tâches.
[0108] Dans une étape 130, un nœud OC est élu par la passerelle RM pour chaque unité de calcul UC, un nœud OC d’une unité de calcul étant élu parmi les nœuds de ladite unité de calcul en fonction de performances et de disponibilité des nœuds de ladite unité de calcul.
[0109] Dans une étape 140, la passerelle RM accepte une requête d’exécution de tâches émise par un utilisateur.
[0110] Chaque requête (appelée « Function Execution Request » (FER) en anglais, « Requête d’Exécution de Fonction » en français) contient une fonction sans état à exécuter par les nœuds loT d’une unité de calcul UC. Une requête FER est composée de scripts de fonction à exécuter et de bibliothèques nécessaires à l’exécution de ces scripts.
[0111] Dans une étape 150, la passerelle RM assigne la requête à des nœuds d’une unité de calcul UC pour l’exécution des tâches de cette requête par les nœuds de cette unité de calcul UC.
[0112] Dans une étape 160, le nœud OC de ladite unité de calcul UC collecte au moins une réponse intermédiaire, chaque réponse intermédiaire étant soit obtenue par le nœud OC soit émise par un nœud suiveur de l’unité de calcul à destination du nœud OC suite à l’exécution de la tâche par ledit nœud suiveur de l’unité de calcul UC.
[0113] Dans une étape 170, le nœud OC détermine une réponse finale à partir d’un vote à la majorité basé sur des réponses intermédiaires collectées.
[0114] Dans une étape 180, le nœud OC transmet la réponse finale à destination de la passerelle RM.
[0115] Dans une étape 190, la passerelle RM transmet la réponse finale à destination de l’utilisateur.
[0116] Selon une variante du procédé, dans une étape 135, la topologie du réseau de communications maillé 1 est mise à jour et diffusée à toutes les passerelles du réseau de communication maillé 1 .
[0117] Selon une variante, si la passerelle RM ne reçoit pas de réponse finale relative à une requête avant qu’un délai se soit écoulé, la tâche est assignée à une autre unité de calcul UC.
[0118] Selon une variante, dans une étape 145, la passerelle RM vérifie la présence de chaque requête reçue par la passerelle RM dans sa mémoire cache locale.
[0119] Si la requête a déjà été demandée et correspond à l'une des requêtes stockées dans une mémoire cache, dans une étape 146, la passerelle RM envoie la réponse finale mémorisée à l’utilisateur et rafraîchit la mémoire cache.
[0120] Si aucune entrée de la mémoire cache ne correspond à la requête, la passerelle RM ajoute la requête dans sa table TTT de la passerelle en tant que nouvelle entrée, incrémente l'index de table TTT et émet un message asynchrone porteur de la requête à destination des nœuds d’une unité de calcul assignée à l’exécution de la requête. [0121] Cette variante donne la priorité aux unités de calcul formées des nœuds les moins défectueux à un moment donné.
[0122] Lorsque le nœud OC de l’unité de calcul UC sélectionnée répond la réponse finale relative à une requête, la passerelle RM mémorise la réponse finale dans l'entrée de sa table TTT locale relative à la requête, envoie la réponse finale à l’utilisateur et synchronise sa table TTT avec celle des répartiteurs du réseau de communication maillé 1 .
[0123] [Fig. 3] illustre un exemple d’exécution des tâches selon un exemple de réalisation particulier et non limitatif de la présente invention.
[0124] Selon l’exemple de la figure 3, un utilisateur CI1 émet une requête référencée f11 à une passerelle RM. La passerelle RM vérifie si f11 correspond à une entrée de l’une de ses mémoire cache.
[0125] Supposons que f11 correspond à une requête référencée f2 mémorisée dans la mémoire cache référencée FIFO de la passerelle RM. La passerelle RM envoie alors à l’utilisateur Cl 1 la réponse finale Rf2 mémorisée dans la mémoire cache FIFO en relation avec f2. L’ère et l’index de table TTT de la passerelle RM restent inchangés. Sur la figure 3, l’ère est égale à 1 (e=1 ) et l’index de la table TTT est égal à 1 (ttt_index=1 ).
[0126] Supposons maintenant que f11 ne corresponde pas à une entrée de la mémoire cache FIFO. La passerelle RM enregistre alors la nouvelle requête f11 dans la mémoire cache et incrémente de une unité l’index de table TTT ttt ndex qui passe à 2.
[0127] La passerelle RM sélectionne également une unité de calcul UC formée, selon l’exemple de la figure 3, d’un nœud OC et de deux nœuds suiveurs F1 et F2 et émet f11 au nœud OC et aux nœuds F1 et F2.
[0128] Le nœud OC exécute la requête f11 et obtient une réponse intermédiaire référencée a.
[0129] Le nœud F1 exécute la requête f11 et fournit une réponse intermédiaire c au nœud OC.
[0130] Le nœud F2 exécute la requête f11 et fournit une réponse intermédiaire a au nœud OC.
[0131] Le nœud OC obtient donc une majorité de vote et considère la réponse intermédiaire a comme étant la réponse finale (étape 170). Le nœud OC émet alors la réponse finale a à la passerelle RM (étape 180) qui la mémorise dans la mémoire FIFO en relation avec la nouvelle entrée correspondante à la requête f11 . La passerelle RM émet alors la réponse finale a à destination de l’utilisateur CL1 (étape 190).
[0132] On peut noter que la mémoire cache peut suivre le principe d’une pile FIFO (First In First Out » en anglais, premier entré premier sorti en français). Dans ce cas, lorsque le nombre maximal d’entrées de la mémoire cache est atteint, toute nouvelle entrée implique la suppression d’une entrée mémorisée dans la mémoire cache. C’est ce qui est illustrée sur la figure 3 : L’enregistrement de f11 implique la suppression d’une entrée correspondante à une requête f1 .
[0133] Selon un exemple de réalisation particulier et non limitatif, le contenu de la mémoire cache de la passerelle RM est synchronisée avec les contenus des mémoires cache des autres passerelles au même titre que les tables GTT c’est-à-dire que chaque fois qu’une nouvelle entrée est ajoutée ou supprimée à la mémoire cache d’une passerelle RM, l’index de la mémoire cache est incrémenté d’une unité et des messages asynchrones sont diffusés pour synchroniser les mémoires cache des autres répartiteurs du réseau de communication maillé 1 avec la mémoire cache de la passerelle RM.
[0134] Selon un exemple de réalisation particulier et non limitatif, le déclenchement d’une élection d’une passerelle RM (étape 120) est basé sur un mécanisme de pulsation (« heartbeat » en anglais) défini comme suit.
[0135] Lorsqu'une passerelle démarre, elle se positionne dans l’état de répartiteur et diffuse un message de type 2 informant les autres passerelles du réseau de communication maillé 1 du contenu de sa table GTT (des tables SFTT qu’elle connaît). La passerelle reste dans cet état répartiteur tant qu'elle ne reçoit pas un message lui indiquant qu’une passerelle RM est valide ou un message lui indiquant qu’elle doit basculer dans un état candidat.
[0136] Selon un exemple de réalisation particulier et non limitatif, une passerelle RM diffuse périodiquement un message de type 2 comprenant sa table GTT aux passerelles du réseau de communication maillé 1 afin de maintenir son autorité et de garder les tables de toutes les passerelles synchronisées. Cependant, si un répartiteur ne reçoit aucun message pendant un délai dit d'expiration d’élection, ce répartiteur suppose qu'aucune passerelle RM ni processus d'élection n'est en cours et déclenche une nouvelle élection pour choisir une nouvelle passerelle RM (étape 120).
[0137] Selon un mode de réalisation particulier et non limitatif, une nouvelle élection est déclenchée dès la déconnexion d’une passerelle du réseau de communication maillé 1 .
[0138] Selon un exemple de réalisation particulier et non limitatif, une nouvelle élection est déclenchée pour vérifier si une passerelle RM actuelle minimise le nombre de messages échangés dans le réseau de communication maillé pour l’exécution de tâches. Dans ce cas, la passerelle RM déclenche une nouvelle élection d’une passerelle RM (étape 120) en se considérant comme répartiteur. Si la passerelle RM n’est plus la passerelle candidate issue d’une élection, la passerelle RM augmente l'ère et détermine son successeur, en propageant son choix à la fois à la nouvelle passerelle candidate et au reste des répartiteurs du réseau de communication maillé 1 . Ce mécanisme de succession permet d'accélérer l’élection d’une nouvelle passerelle RM (étape 120) et de s’assurer au fil du temps de l’optimalité d’une passerelle RM courante.
[0139] Il peut aussi se produite le cas où un répartiteur reçoive un message d'une autre passerelle, RM ou répartiteur à tout moment avec une ère ou un index de table plus élevé que son ère (ou avec la même ère ou index de table provenant d'une passerelle RM différente) tout en ayant déjà considéré une passerelle RM active . Ce cas peut probablement être dû à un comportement malveillant ou à une segmentation du réseau de communication maillé 1 .
[0140] Dans ce cas, selon un mode de réalisation particulier et non limitatif, le répartiteur alerte la passerelle RM active, qui fusionne sa table GTT avec la table GTT de l'autre passerelle RM, déclenche à nouveau le processus d’élection pour amener à une élection d’une unique passerelle RM.
[0141] Selon un exemple de réalisation particulier et non limitatif, si une passerelle RM ou candidate est "obsolète", cette passerelle est supposée avoir temporairement perdu la connexion réseau. Cette passerelle se synchronise avec l’ère et les indexes de table de la passerelle RM et déclenche une nouvelle élection de passerelle RM (étape 120), revenant à l'état de répartiteur. Ce même mécanisme fonctionne dans le sens inverse lors de la réception d'un numéro d'ère ancienne d'un autre répartiteur. [0142] Selon un exemple de réalisation particulier et non limitatif, si un délai d'expiration d’élection de la passerelle RM s'écoule sans recevoir aucune requête émise par la passerelle RM, un répartiteur incrémente de une unité son ère et lance une nouvelle élection d’une nouvelle passerelle RM.
[0143] Si une passerelle candidate reçoit un message d'un nœud prétendant être une passerelle RM pour la même ère ou une ère supérieure, la passerelle candidate bascule à l'état de répartiteur.
[0144] Selon un exemple de réalisation particulier et non limitatif, si le délai d’élection s'écoule sans majorité de répartiteurs, les passerelles candidates fusionnent leurs tables GTT, augmente l'ère et déclenche une nouvelle élection de passerelle RM (étape 120).
[0145] Selon un exemple de réalisation particulier et non limitatif, l’élection d’une passerelle RM est mis en œuvre par un procédé 40 d’élection déterministe d’une passerelle RM basé sur une liste de tous les répartiteurs du réseau de communication maillé 1 (figure 4)
[0146] Dans une étape 410, un répartiteur incrémente son ère de une unité.
[0147] Dans une étape 420, une passerelle candidate est déterminée parmi les répartiteurs de la liste de répartiteurs.
[0148] Pour cela, par exemple, une table GTT la plus récente dans le réseau de communication maillé 1 est considérée. Cette table GTT contient une liste de répartiteurs, chacun ayant une liste de nœuds connectés et leurs capacités de calcul. Cette liste exclut la passerelle RM.
[0149] Initialement, deux variables optimalDispatcher et optimalNumberOfMsgs sont initialisées à la valeur NULL.
[0150] Pour chaque répartiteur dispLeadTmp de la liste de répartiteurs, des étapes 430, 440 et 450 sont exécutées.
[0151] Dans l’étape 430, un nombre de message totalMessages est initialisé à 0.
[0152] Dans l’étape 440, pour chaque répartiteur disp de la liste de répartiteurs, un nombre expectMsgs de messages qu'il est prévu d'échanger entre le répartiteur DispLeadTmp et le répartiteur disp est déterminé en considérant que le répartiteur DispLeadTmp est élu passerelle RM. Le nombre total de messages totalMsgs est alors mis à jour par : totalMsgs + expectMsgs *distance(dispLeadTmp, disp) dans laquelle distance(DispLeadTmp, disp) indique une distance entre les répartiteurs DispLeadTmp et disp.
[0153] Dans l’étape 450, si le nombre total de messages totalMsgs est inférieur à un nombre optimal de message optimalNumberOfMsgs alors le répartiteur DispLeadTmp est considéré comme une passerelle RM et une variable optimalDispatcher est mise à jour avec l’identifiant du répartiteur DispLeadTmp. Le nombre optimal de messages optimalNumberOfMsgs est aussi égal au nombre total de messages totalMsgs.
[0154] Lorsque chaque répartiteur DispLeadTmp de la liste GTT a été considéré, la variable optimalDispatcher indique quel est le répartiteur qui a été élu passerelle candidate et la variable optimalNumberOfMsgs indique le nombre total de messages relatif à ce répartiteur.
[0155] Lors de l’exécution de ce processus d’élection 40, certains répartiteurs peuvent ne pas répondre dans un délai inférieur à un délai d’expiration d’élection. Chacun de ces répartiteurs qui a dépassé ce délai d'expiration d'élection exécute à son tour le processus d’élection 40 et informe la passerelle candidate issue de la première élection que, à sa connaissance, cette passerelle candidate est la passerelle RM la plus optimale pour cette nouvelle ère. Si un répartiteur du réseau de communication maillé 1 reçoit l'un de ces messages, il tente d'atteindre cette passerelle candidate. Si il y arrive alors cette passerelle est considérée comme ayant voté pour que cette passerelle candidate soit la nouvelle passerelle RM. Si le répartiteur n'est pas en mesure d’attendre cette passerelle candidate, il déclenchera une élection dans le reste des répartiteurs qui n'ont pas déjà voté pour cette passerelle candidate. Ensuite, ce répartiteur passe à l'état de passerelle candidate jusqu'à ce que l'une des trois évènements suivants se produise : (a) il remporte l'élection, (b) un autre répartiteur remporte l'élection ou est déjà la passerelle RM ou (c) une période d’élection s’écoule sans vainqueur.
[0156] Dans l’évènement a) se produit, une passerelle candidate ne remporte une élection que si la majorité des répartiteurs disponibles dans le réseau de communication maillé 1 votent qu'il s'agit de la passerelle RM la plus optimale. Chaque répartiteur vote pour exactement une passerelle candidate à chaque élection, qui, compte tenu du comportement déterministe du processus d’élection, doit toujours être le même si ces répartiteurs sont synchronisés sur tout le réseau de communication maillé 1 ; cela ne conduit jamais à un vote par division. Cependant, pour garantir l'exactitude du processus, la règle de la majorité garantit qu'une seule passerelle candidate peut remporter l'élection pour une ère particulière.
[0157] Dans l’évènement b), en attendant les votes, une passerelle candidate peut recevoir un message d'une autre passerelle candidate prétendant être la passerelle RM. Si l'ère de cette passerelle RM est au moins aussi grande que l'ère actuelle de la passerelle candidate, la passerelle candidate le reconnaît comme une passerelle RM légitime et revient à l'état répartiteur. Cependant, si l'ère de cette passerelle RM est inférieur à l’ère actuelle, le message est rejeté et la passerelle candidate reste dans l'état candidat.
[0158] Dans l’évènement c), à la fin d’une période d’élection, aucune des passerelles candidates n'a suffisamment de voix pour gagner ou perdre l'élection. Cela peut se produire s'il y a plusieurs fractures du réseau de communication maillé 1 ne permettant pas aux répartiteurs d'avoir une table GTT à jour. Lorsque cela se produit, chaque passerelle candidate envoie sa table GTT au reste des passerelles candidates. Cela fusionne les tables GTT et le processus d’élection est réexécuter, augmentant ainsi l'ère. Cette fois, il est confirmé que tous les répartiteurs participants partagent la même table GTT, et donc la même passerelle candidate. Une fois qu'une passerelle candidate remporte l'élection, cette passerelle propage la décision au reste des répartiteurs.
[0159] Selon un exemple de réalisation particulier et non limitatif, étant donné que l’élection d’une passerelle RM est calculée selon un procédé déterministe, les votes par division sont inhabituels. Cependant, si cela se produit, les nœuds divisés fusionnent leurs tables GTT et relancent une nouvelle élection d’une passerelle RM.
[0160] [Fig. 5] illustre un organigramme des différentes étapes du procédé 20 de mise à jour de la topologie du réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état, selon un exemple de réalisation particulier et non limitatif de la présente invention.
[0161] Dans une étape 210, la passerelle à laquelle est attaché un sous-réseau détermine la disponibilité de chaque nœud de ce sous-réseau et met à jour sa table SFTT pour indiquer les disponibilités et caractéristiques de chaque nœud disponible du sous- réseau. Tl
[0162] Il est avantageux de déléguer le maintien de la disponibilité des nœuds d’un sous- réseau à la passerelle à laquelle est rattaché ce sous-réseau car la congestion du réseau de communication maillé 1 et le nombre global de messages échangés sur ce réseau sont réduits.
[0163] Chaque passerelle suit alors les défauts des nœuds loT de manière flexible puisque chaque nœud loT a une disponibilité et une périodicité différentes.
[0164] Selon un mode de réalisation particulier et non limitatif, chaque nœud loT de chaque sous-réseau émet périodiquement un message pour indiquer qu’il est disponible. Si une passerelle rattachée à un sous-réseau ne reçoit pas ledit message ou un message en relation avec une exécution d’une tâche d'un nœud loT dudit sous-réseau pendant une période donnée, ladite passerelle suppose que le nœud loT s'est déconnecté et le purge de sa table SFTT. De même, si une passerelle rattachée à un sous-réseau reçoit un message pour la première fois en relation avec une exécution d’une tâche d'un nœud loT dudit sous-réseau, ladite passerelle suppose que le nœud loT est connecté et l’ajoute à sa table SFTT.
[0165] Dans une étape 220, les tables SFTT des passerelles sont diffusées aux passerelles du réseau de communication maillé 1 pour que la nouvelle topologie d’un sous-réseau soit connue de l’ensemble des passerelles du réseau de communication maillé 1 .
[0166] [Fig. 6] illustre un exemple de diffusion d’une table SFTT dans le réseau de communication maillé 1 selon un exemple particulier et non limitatif de la présente invention.
[0167] Supposons dans cet exemple, que le réseau de communication maillé 1 comprenne une passerelle RM et quatre répartiteurs D2 à D5.
[0168] Supposons également que la passerelle RM comprenne une table local GTT formée de l’union de sa table SFTT locale référencée SFTT1 et des tables SFTT de chacun des répartiteurs D2 à D5 référencées respectivement SFTT2, SFTT3, SFTT4 et SFTT5. L’ère courante de la passerelle RM est égale à 1 (e=1 ) et l’index de table GTT est égal à 1 (i=1 ).
[0169] Dans étape 221 , la passerelle RM diffuse périodiquement un message de type 2 pour diffuser sa table GTT à l’ensemble des autres répartiteurs du réseau de communication maillé 1 . [0170] Une fois ce message reçu par un répartiteur, dans étape 222, si les informations du message reçu sont pertinentes, ce répartiteur met à jour sa table GTT et les informations qu’ils mémorisent en fonction des informations pertinentes portées par ce message reçu.
[0171] Par exemple, ce répartiteur met à jour l’ère (e=1 ) et l’index de table GTT (i=1 ) ainsi que sa table GTT en fonction de la table GTT portée par le message de type 2.
[0172] Selon l’exemple de la figure 6, le répartiteur D2 stocke ainsi sa table SFTT locale référencée SFTT2, la table GTT référencée GTT1 portée par le message reçu. Chaque autre répartiteur D3 à D5 en fait de même.
[0173] Dans une étape 223, chaque répartiteur émet un message de type 3 porteur de sa table SFTT à destination de la passerelle RM.
[0174] Dans une étape 224, la passerelle RM compare la table SFTT de chaque message reçu avec des informations qu’elle connaît du sous-réseau correspondant à cette table SFTT (tables SFTT locales formant la table GTT locale).
[0175] Si la passerelle RM ne trouve aucun changement (cas 1 sur la figure 6), la passerelle RM ignore le contenu des messages reçus.
[0176] Si la passerelle RM trouve un changement, dans étape 225, la passerelle RM fusionne les changements dans sa table GTT locale et augmente l’index de la table GTT. L'index n'augmente que d'une unité à chaque période, quel que soit le nombre de changements détectés.
[0177] Selon l’exemple de la figure 6, les répartiteurs D3 et D4 ont chacun une table SFTT modifiée par l’apparition ou la disparition d’au moins un nœud loT de leur sous-réseau. Ces tables SFTT modifiées sont référencées SFTT3’ et SFTT4’. Les répartiteurs D3 et D4 émettent alors chacun un message de type 3 à destination de la passerelle RM qui détecte un changement des tables SFTT des répartiteurs D3 et D4. La passerelle RM fusionne alors les changements dans sa table GTT locale (maintenant référencée GTT2) et augmente l’index de la table GTT (i=2) (cas 2 sur la figure 6). L’ère de la passerelle RM reste égale à 1 (e=1 ). L'index de table GTT n'augmente que d'une unité à chaque période, quel que soit le nombre de changements détectés.
[0178] Dans une étape 226, la passerelle RM diffuse la nouvelle table GTT à l’ensemble des répartiteurs du réseau de communication maillé 1 . [0179] Selon l’exemple de la figure 6, les répartiteurs D2 à D5 sont alors informés de la nouvelle table GTT (GTT2) de la passerelle RM lors d’une prochaine diffusion du message de type 2 (étape 221 ).
[0180] Puisque ce processus repose sur la comparaison de tables SFTT, il est avantageux de garder la comparaison aussi légère que possible. Cependant, les tailles de ces tables sont différentes. La table SFTT a une liste d'une douzaine de nœuds, et la table GTT a une liste de dizaines de tables SFTT par exemple.
[0181 ] Selon une variante du processus de mise à jour de la topologie du réseau de communication maillé 1 , la passerelle RM compare le couple <ère, index de table > du message reçu à celui stocké localement, ce qui permet d'identifier quelle est la table la plus récente parmi des tables SFTT et la table GTT locale. Le processus se poursuit ensuite par la comparaison des tables SFTT entre elles une fois que les tables SFTT contenue dans le message reçu est plus récent que la table GTT locale (a une ère plus élevée ou une même ère mais un index de table plus élevé que celui de la table SFTT de la table GTT).
[0182] [Fig. 7] illustre un organigramme des différentes étapes du procédé 30 de formation des unités de calcul par regroupement de nœuds loT, selon un exemple de réalisation particulier et non limitatif de la présente invention ;
[0183] La performance de chaque unité de calcul UC dépend fortement de la rapidité de la réception d'au moins la moitié des votes des nœuds de l’unité de calcul UC afin que le nœud OC puisse déterminer une réponse finale à une requête.
[0184] En conséquence, le procédé de formation d’unité de calcul (étape 110) tente de minimiser l'écart entre les périodes de disponibilité des nœuds.
[0185] Dans une étape 310, la passerelle RM classe les nœuds loT en fonction de leur degré de disponibilité et de leurs capacités de calcul : un nœud loT est dit performant lorsque son degré de disponibilité et ses capacités de calcul sont élevées et dit non performant dans le cas contraire.
[0186] De plus, compte tenu des capacités limitées des appareils loT, et afin de perdre le moins de périodes de calcul possible, le procédé de formation d’unité de calcul examine également la distribution des unités de calcul courante pour assigner les nœuds à une unité de calcul de manière à minimiser les changements de cette distribution. [0187] Dans une étape 320, un nombre d’unité de calcul N est calculée en fonction d’un nombre de nœuds M par unité de calcul.
[0188] Selon un mode de réalisation particulier et non limitatif, N est égal à 5.
[0189] Ce mode de réalisation est avantageux car il permet d’obtenir des performances de calcul optimales selon des tests réalisés par l’inventeur.
[0190] Dans une étape 330, chaque unité de calcul UC est formée par regroupement de N nœuds loT du réseau de communication maillé 1 , au moins un desdits nœuds étant performant et au moins un desdits nœuds étant non performant.
[0191] Selon un mode de réalisation particulier et non limitatif, les N nœuds les plus rapides sont par exemple distribués parmi les unités de calcul UC.
[0192] Selon un mode de réalisation particulier et non limitatif, chaque unité de calcul comprend un nœud OC.
[0193] Selon un mode de réalisation particulier et non limitatif, lorsque une unité de calcul comprend 5 nœuds, l’un des nœuds d’une unité de calcul est considéré comme étant un nœud orchestrateur de calcul, deux autres nœuds sont des nœuds performants et deux autres nœuds sont des nœuds non performants.
[0194] Dans une étape 340, chaque unité de calcul UC forme un sous-réseau du réseau de communication maillé 1 qui est rattaché à une passerelle du réseau de communication maillé 1. La passerelle mémorise une table SFTT représentant la disponibilité et les caractéristiques des nœuds loT du sous-réseau. Les nœuds loT de cette unité de calcul UC sont informés de leur rattachement à cette unité de calcul UC.
[0195] Ce procédé de formation d’unités de calcul permet d’augmenter le nombre de périodes de calcul et d’homogénéiser les capacités de l'infrastructure du réseau de communication maillé 1 tout en cherchant maintenir une distribution antérieure des nœuds.
[0196] Ce procédé de formation d’unité de calcul peut consommer des ressources de manière importante et ajouter une surcharge au procédé de contrôle du réseau de communication maillé 1 . Ainsi, si les nœuds loT ont une forte intermittence de leur disponibilité, ce processus de formation d’unité de calcul ne peut être exécuté à chaque fois qu'une déconnexion de nœud loT se produit sans pénaliser fortement les performances du procédé de contrôle du réseau de communication maillé 1 . [0197] Selon un exemple de réalisation particulier et non limitatif, le procédé de formation d’unité de calcul, ne se produit que si l’une des conditions suivantes est vérifiée :
(a) une unité de calcul ne contient pas de nœud OC ou de nœud loT performant ;
(b) le nombre de nœuds loT du réseau de communication maillé 1 est inférieur à 3. N
(c) (c) lorsqu’une période prédéterminée est écoulée pour réoptimiser la distribution des nœuds loT.
[0198] La passerelle RM contrôle les nœuds loT pour s'assurer que ces règles sont respectées.
[0199] Selon une variante, pour garder l'infrastructure aussi performante que possible, en palliant les pertes de nœuds, la passerelle RM donne la priorité à l’exécution des tâches vers les unités de calcul UC avec tout leur quorum de nœuds performants actifs.
[0200] Selon une variante, la passerelle RM informe le nœud OC d’une unité de calcul UC chaque fois qu'un changement se produit dans cette unité de calcul UC concernant le nombre de nœuds de cette unité de calcul.
[0201] Cette variante optimise les performances du processus de contrôle du réseau de communication maillé 1.
[0202] Selon une variante, lorsqu'une déconnexion d’un nœud OC d’une unité de calcul UC se produit, la passerelle RM doit choisir un autre nœud OC pour cette unité de calcul UC parmi les nœuds de cette unité de calcul UC pour que cette unité de calcul UC soit opérationnelle jusqu'à ce que le processus de formation d’unité de calcul soit à nouveau exécuté.
[0203] De cette façon, chaque unité de calcul peut tolérer une déconnexion de nœud hors du quorum des nœuds performants et jusqu'à trois déconnexions si deux d'entre elles sont des nœuds non performants.
[0204] Une fois qu'un nœud loT d'une unité de calcul UC reçoit un message porteur d’une requête d’exécution de tâches, ce nœud loT exécute ces tâches et renvoie son résultat au nœud OC de cette unité de calcul UC. Le nœud OC, qui connaît l'état de l’unité de calcul UC, vérifie alors s'il est en mesure d'obtenir un vote majoritaire.
[0205] Selon un exemple de réalisation particulier et non limitatif, le procédé de vote utilisé par le nœud OC est une variante du processus de vote connu sous le nom de DLV [S. Jajodia et al. 1990. Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems]. DLV définit dynamiquement un seuil de majorité de votes en fonction du nombre de nœuds connectés, ce qui permet d'améliorer la flexibilité et les performances du processus de vote. En cas d'égalité, le nœud OC privilégie sa réponse intermédiaire à une FER ou, si sa réponse intermédiaire ne fait pas partie des réponses intermédiaires ex aequo, la première réponse intermédiaire qui atteint la quantité ex aequo est retenue en tant que réponse finale. L’utilisation du processus de vote basé sur DLV nécessite au moins n + 2 serveurs par unité de calcul UC pour pouvoir tolérer n pannes au lieu des 2n + 1 requis par Raft. Cette propriété permet aux unités de calcul UC de fonctionner avec moins de membres avec un niveau acceptable de tolérance aux pannes, ce qui est critique dans un environnement défaillant et hautement dynamique.
[0206] [Fig. 8] illustre schématiquement un dispositif de contrôle du réseau de communication maillé 1 pour l’exécution de tâches relatives à des fonctions sans état, selon un exemple de réalisation particulier et non limitatif de la présente invention.
[0207] Le dispositif 23 est par exemple configuré pour la mise en œuvre d’au moins une des étapes d’au moins un procédé 10, 20, 30 ou 40. Les éléments du dispositif 23, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 23 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels.
[0208] Selon différents modes de réalisation particuliers, le dispositif 23 est couplé en communication avec d’autres dispositifs ou systèmes similaires, par exemple les calculateurs 20, 21 et/ou 22 et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés.
[0209] Le dispositif 23 comprend un (ou plusieurs) processeur(s) 230 configurés pour exécuter des instructions pour la réalisation d’au moins une partie des étapes d’au moins un procédé 10, 20, 30 ou 40 et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 23. Le processeur 230 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 23 comprend en outre ou est en association avec au moins une mémoire 231 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique.
[0210] Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la mémoire 231 .
[0211] Selon un mode de réalisation particulier et non limitatif, le dispositif 23 comprend un bloc 232 d’éléments d’interface pour communiquer avec des dispositifs externes, par exemple un dispositif de calcul distant. Les éléments d’interface du bloc 232 comprennent une ou plusieurs des interfaces suivantes :
(i) interface radiofréquence RF, par exemple de type Bluetooth® ou Wi-Fi®, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE- Advanced (ou en français LTE-avancé) ;
(ii) interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
(iii) interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ;
(iv) interface LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »).
[0212] Selon un autre mode de réalisation particulier, le dispositif 23 comprend une interface de communication 233 qui permet d’établir une communication avec d’autres dispositifs, tels que les calculateurs 20, 21 et/ou 22 embarqués du véhicule via un canal de communication 234. L’interface de communication 233 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 234. L’interface de communication 233 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458) ou Ethernet (standardisé par la norme ISO/IEC 802-3).
[0213] Bien entendu, la présente invention ne se limite pas aux exemples de réalisation décrits ci-avant mais s’étend à un procédé de de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé.
[0214] La présente invention concerne également un véhicule, par exemple automobile ou plus généralement un véhicule autonome à moteur terrestre, comprenant le dispositif de la figure 8.

Claims

REVENDICATIONS
1 . Procédé de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état, ledit réseau de communication maillé comprenant des nœuds appelés passerelle pour indiquer que ces nœuds correspondent à des passerelles du réseau de communication maillé et des nœuds appelés nœuds loT pour indiquer que ces nœuds correspondent à des appareils connectés à internet, chaque passerelle du réseau de communication maillé mémorise à jour trois tables, une table de topologie globale, GTT, une table de topologie des nœuds du sous-réseau rattaché à la passerelle, SFTT, et une table de suivi des tâches, TTT, ledit procédé comprenant les étapes suivantes :
- obtention (110) d’unités de calcul à partir des nœuds loT, chaque unité de calcul comprend des nœuds loT et est rattachée à une passerelle pour former un sous-réseau du réseau de communication maillé ;
- élection (120) d’une passerelle gestionnaire de ressources (RM) parmi les passerelles du réseau de communication maillé, ladite passerelle gestionnaire de ressources (RM) minimisant un nombre de messages échangés dans le réseau de communication maillé pour l’exécution de tâches ;
- élection (130), par la passerelle gestionnaire de ressources (RM), d’un nœud orchestrateur de calcul pour chaque unité de calcul, un nœud orchestrateur de calcul d’une unité de calcul étant élu parmi les nœuds de ladite unité de calcul en fonction de performances et de disponibilité des nœuds de ladite unité de calcul ;
- acceptation (140), par la passerelle gestionnaire de ressources (RM), d’une requête d’exécution de tâches émise par un utilisateur ;
- assignation (150), par la passerelle gestionnaire de ressources (RM), de ladite requête à des nœuds loT d’une unité de calcul pour l’exécution de tâches de ladite requête par les nœuds loT de ladite unité de calcul ;
- collecte (160), par un nœud orchestrateur de calcul (OC) de ladite unité de calcul, d’au moins une réponse intermédiaire à ladite requête, chaque réponse intermédiaire étant soit obtenue par le nœud orchestrateur de calcul soit émise par un nœud loT de l’unité de calcul à destination du nœud orchestrateur de calcul (OC) suite à l’exécution de la tâche par ledit nœud loT de l’unité de calcul ;
- obtention (170), par le nœud orchestrateur de calcul, d’une réponse finale à partir d’un vote à la majorité basé sur les réponses intermédiaires collectées ;
- transmission (180) de la réponse finale par le nœud orchestrateur de calcul (OC) à destination de la passerelle gestionnaire de ressources (RM); et
- transmission (190) de la réponse finale par la passerelle gestionnaire de ressources (RM) à destination de l’utilisateur.
2. Procédé selon la revendication 1 , dans lequel si la passerelle gestionnaire de ressources (RM) ne reçoit pas de réponse finale relative à ladite requête avant qu’un délai se soit écoulé, ladite requête est assignée à une autre unité de calcul.
3. Procédé selon l’une des revendications précédentes, qui comporte en outre une étape (145) de vérification d’une présence de ladite requête dans une mémoire cache de la passerelle gestionnaire des ressources, et une étape (146) d’envoi d’une réponse finale mémorisée dans la mémoire cache en relation avec ladite requête si ladite requête est mémorisée dans ladite mémoire cache.
4. Procédé selon la revendication 3, dans laquelle le contenu de la mémoire cache de la passerelle gestionnaire des ressources est synchronisé avec les contenus des mémoires cache des autres passerelles du réseau de communication maillé.
5. Procédé selon l’une des revendications précédentes, dans lequel la passerelle gestionnaire des ressources diffuse périodiquement aux passerelles du réseau de communication maillé un message comprenant une première table (GTT) formée d’une union de plusieurs deuxièmes tables (SFTT), chaque deuxième table représentant une disponibilité et des caractéristiques des nœuds loT d’un sous-réseau du réseau de communication maillé, si une passerelle ne reçoit aucun message pendant un délai d'expiration d’élection, ladite passerelle déclenche une nouvelle élection (120) d’une passerelle gestionnaire de ressources (RM).
6. Procédé selon l’une des revendications précédentes, dans lequel une nouvelle élection (120) d’une passerelle gestionnaire de ressources (RM) est déclenchée pour vérifier si une passerelle gestionnaire des ressources actuelle minimise le nombre de messages échangés dans le réseau de communication maillé pour l’exécution de tâches.
7. Procédé selon l’une des revendications précédentes, dans lequel une nouvelle élection (120) d’une passerelle gestionnaire de ressources (RM) est déclenchée dès qu’une passerelle du réseau de communication maillé est déconnectée.
8. Procédé selon la revendication 1 , qui comporte en outre une étape (135) de mise à jour d’une topologie du réseau de communication maillé et de diffusion d’une topologie mise à jour à toutes les passerelles du réseau de communication maillé.
9. Dispositif de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état comportant ledit réseau de communication maillé comprenant lesdites passerelles et lesdits nœuds loT, lesdits unités de calcul, une passerelle gestionnaire de ressources (RM), un nœud orchestrateur de calcul pour chaque unité de calcul, une mémoire associée à au moins un processeur configuré pour la mise en œuvre des étapes du procédé selon l’une des revendications 1 à 8.
10. Véhicule comprenant un dispositif de la revendication 9.
EP24715670.6A 2023-03-17 2024-03-08 Procédé et dispositif de contrôle d'un réseau de communication maillé pour l'exécution de tâches relatives à des fonctions sans état Pending EP4681404A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2302508A FR3146775B1 (fr) 2023-03-17 2023-03-17 Procédé et dispositif de contrôle d’un réseau de communication maillé pour l’exécution de tâches relatives à des fonctions sans état
PCT/FR2024/050290 WO2024194550A1 (fr) 2023-03-17 2024-03-08 Procédé et dispositif de contrôle d'un réseau de communication maillé pour l'exécution de tâches relatives à des fonctions sans état

Publications (1)

Publication Number Publication Date
EP4681404A1 true EP4681404A1 (fr) 2026-01-21

Family

ID=86657390

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24715670.6A Pending EP4681404A1 (fr) 2023-03-17 2024-03-08 Procédé et dispositif de contrôle d'un réseau de communication maillé pour l'exécution de tâches relatives à des fonctions sans état

Country Status (3)

Country Link
EP (1) EP4681404A1 (fr)
FR (1) FR3146775B1 (fr)
WO (1) WO2024194550A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2508066C2 (de) 1975-02-25 1983-01-27 Agfa-Gevaert Ag, 5090 Leverkusen Dosiergerät für pulverförmiges Gut
US20220358118A1 (en) * 2021-05-10 2022-11-10 International Business Machines Corporation Data synchronization in edge computing networks

Also Published As

Publication number Publication date
FR3146775A1 (fr) 2024-09-20
FR3146775B1 (fr) 2025-02-07
WO2024194550A1 (fr) 2024-09-26

Similar Documents

Publication Publication Date Title
EP2353256A1 (fr) Determination et gestion de reseaux virtuels
EP2454850A1 (fr) Procede et systeme pour la gestion performante et automatisee de reseaux virtuels.
EP3675435A1 (fr) Procédé de routage dynamique dans un réseau d&#39;objets connectés
EP2502384B1 (fr) Procede et systeme pour distribuer du contenu avec des garanties de delais de livraison dans les reseaux radio hybrides
WO2008025925A1 (fr) Procede de routage de donnees dans un reseau comprenant des noeuds organises en groupements
CN114448997A (zh) 一种基于pbft的装备质量信息管理节点共识方法
Chen et al. Omen: Overlay mending for topic-based publish/subscribe systems under churn
EP3732565B1 (fr) Reseau informatique d&#39;infrastructures de ressources de calcul et procede d&#39;affectation de ces ressources a des applications client
EP4681404A1 (fr) Procédé et dispositif de contrôle d&#39;un réseau de communication maillé pour l&#39;exécution de tâches relatives à des fonctions sans état
FR3146774A1 (fr) Procédé et dispositif de mise à jour d’une topologie d’un réseau de communication maillé pour une exécution de tâches relatives à des fonctions sans état
FR3146773A1 (fr) Procédé et dispositif de formation d’unités de calcul à partir de nœuds IoT d’un réseau de communication maillé pour une exécution de tâches relatives à des fonctions sans état
Meiklejohn et al. Loquat: A framework for large-scale actor communication on edge networks
Shen et al. Virtual net: a decentralized architecture for interaction in mobile virtual worlds
EP2746977B1 (fr) Procédé de génération d&#39;une version d&#39;un modele de supervision d&#39;un système d&#39;information
EP3563233B1 (fr) Réseau informatique d&#39;infrastructures de ressources de calcul et procédé d&#39;affectation de ces ressources a des applications client
Vieira et al. Seamless paxos coordinators
EP3080706B1 (fr) Procédé de sauvegarde de données stockées sur un terminal
US20240275620A1 (en) Blockchain resource management system and method of use
FR2866185A1 (fr) Procede de constitution d&#39;une liste reduite de cellules voisines et dispositif pour la mise en oeuvre du procede.
WO2024052475A1 (fr) Procede d&#39;orchestration d&#39;applications logicielles dans un systeme de telecommunication, programme d&#39;ordinateur et dispositif d&#39;orchestration associes
FR3150022A1 (fr) Système de clonage multi-clusters
Farkaš et al. Modular Communication Service Managed by Microservices
WO2025073502A1 (fr) Module, procédé et programme utilisant une contrainte d&#39;affinité de données pour un déploiement de service
Ayari et al. GMTC: A generalized commit approach for hybrid mobile environments
Tamhane et al. Middleware for decentralised fault tolerant service execution using replication in pervasive systems

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250912

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR