WO2018184699A1 - Contrôleur et protocole d'accord de système de commande en temps réel - Google Patents

Contrôleur et protocole d'accord de système de commande en temps réel Download PDF

Info

Publication number
WO2018184699A1
WO2018184699A1 PCT/EP2017/058421 EP2017058421W WO2018184699A1 WO 2018184699 A1 WO2018184699 A1 WO 2018184699A1 EP 2017058421 W EP2017058421 W EP 2017058421W WO 2018184699 A1 WO2018184699 A1 WO 2018184699A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
measurements
digest
digests
label
Prior art date
Application number
PCT/EP2017/058421
Other languages
English (en)
Inventor
Wajeb SAAB
Maaz MASHOOD MOHIUDDIN
Simon BLIUDZE
Jean-Yves Le Boudec
Original Assignee
Ecole Polytechnique Federale De Lausanne (Epfl)
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 Ecole Polytechnique Federale De Lausanne (Epfl) filed Critical Ecole Polytechnique Federale De Lausanne (Epfl)
Priority to PCT/EP2017/058421 priority Critical patent/WO2018184699A1/fr
Publication of WO2018184699A1 publication Critical patent/WO2018184699A1/fr

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B9/00—Safety arrangements
    • G05B9/02—Safety arrangements electric
    • G05B9/03—Safety arrangements electric with multiple-channel loop, i.e. redundant control systems
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0421—Multiprocessor system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/22—Pc multi processor system
    • G05B2219/2213—Local processor uses data from own local store and data from other stations
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24186—Redundant processors are synchronised
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24189—Redundant processors monitor same point, common parameters

Definitions

  • the present invention relates to a controller for a real-time control system (RTCS) for generating setpoints.
  • RTCS real-time control system
  • the invention also relates to an agreement protocol or a method for generating setpoints for actuators in an RTCS.
  • the present invention also relates to a controller system and to an RTCS.
  • RTCSs are computing systems, which control an operation of a process or system in real time.
  • the RTCSs typically use controllers for generating setpoints for actuators, which control the operation of another system or process, such as an electrical grid or a manufacturing process.
  • the controllers receive labelled (time- stamped or logically sequenced) measurements from sensors for generating the setpoints.
  • the controllers use the measurements to compute and issue setpoints to the actuators to complete the control cycle.
  • the measurements and setpoints are sent over non-ideal networks, and might thus experience delays and/or losses.
  • RTCSs tolerate delay and crash faults by replicating the controller. Each controller replica computes and sends the setpoints to the actuators over a network, which may drop or delay messages.
  • the actuators may receive an inconsistent set of setpoints.
  • Such inconsistency is avoided either by having a single primary replica compute and issue setpoints (in passive replication) or by a consensus or agreement algorithm, which selects one sending replica (in active replication).
  • passive replication schemes may have multiple primaries operating simultaneously, causing inconsistency, especially in the presence of intermittent delay faults.
  • impossibility of bounded- latency consensus causes also the known active replication solutions to have poor real-time performance.
  • Passive replication is commonly used in RTCSs because it avoids agreement by having one primary compute and issue setpoints. If the primary is detected as faulty, the standbys elect a new primary by consensus. However, in non- synchronous settings, failure detection is imperfect. Consequently, the standbys could incorrectly detect the primary as faulty and elect a new primary, while the original primary is not notified (eg due to a lost notification), resulting in two primaries, leading to potential inconsistencies. However, these inconsistencies are rare under a crash- only fault model. Most passive-replication research considers the crash-only fault model, under which passive replication improves availability at a negligible cost of inconsistency. For RTCSs, however, a stronger fault model, which includes delay faults, is relevant. The intermittent nature of delay faults causes more false positives by failure detectors, hence more inconsistencies.
  • active replication schemes generally guarantee consistency by using consensus, for deciding the setpoint(s) to be sent or the sender of the setpoint.
  • Consensus consists of four properties: agreement, termination, validity, and integrity. Validity and integrity address issues that arise due to Byzantine faults, and are not under consideration in the present invention. These properties are trivial to guarantee under the fault model considered in the present invention (which does not include arbitrary Byzantine faults).
  • the agreement and termination are impossible to guarantee together within a bounded delay in a non-synchronous setting. Since RTCSs require a low bounded latency, this results in low availability.
  • a method of generating one or more setpoints for one or more actuators of a real-time control system as recited in claim 1 .
  • setpoints are generated by a controller based on digests received from other controllers.
  • a digest is a message that contains a list of measurement indices and a controller state label present at a controller.
  • the present invention bases the computation of setpoints on digests. The most appropriate digest can be chosen for setpoint computations and the same digest can then be used by all the controllers. Therefore, the controller votes on and chooses an appropriate digest (to guarantee consistency), which in turn means that it is choosing a set of measurements to use for the subsequent setpoint computation. In this manner guaranteed consistency, increased availability, bounded latency-overhead can be achieved.
  • a controller for a real-time control system as recited in claim 13.
  • a controller system for a real-time control system as recited in claim 14.
  • the proposed real-time control system is consistent and has bounded latency-overhead.
  • Figure 1 is a block diagram schematically illustrating an RTCS according to an example of the present invention
  • Figure 2 is a flow chart summarising a method of generating setpoints by a controller of the RTCS of Figure 1 according to an example of the present invention
  • Figure 3 is a flow chart summarising a method of collecting measurements and states according to an example of the present invention.
  • Figure 4 is a flow chart summarising a method of voting according to an example of the present invention. DETAILED DESCRIPTION OF AN EMBODIMENT OF THE INVENTION
  • the RTCS 1 comprises m sensors 3, which are arranged to sense or detect events or changes in the operation of a unit, system or process 5 to be controlled by taking measurements from the controlled process 5.
  • the sensors 3 may all measure the same or different properties of the controlled process 5.
  • the sensors 3 are further arranged to send the measurements over a first communication network 7 to a set of controllers 9, also known as replicas.
  • the number of controllers 9 in the RTCS 1 may be between 2 and 10, or more specifically between 2 and 5 or 2 and 4 or 2 and 3.
  • all the controllers 9 in the set are substantially identical, ie they are configured to operate in the same manner when dealing with the same input.
  • the sensors 3 are arranged to mark or label each measurement with a logical sequence r, referred to as a label or measurement label r.
  • the measurement labels are global and are shared by all the sensors 3 in the RTCS 1. Such numbering can be obtained for instance by time-synchronisation or through logical clocks or by any other suitable means.
  • the controllers 9 are arranged to compute and issue setpoints or control parameters or commands. In the example below, h setpoints will be generated.
  • the controllers 9 are also arranged to send the generated setpoints over a second communication network 1 1 to actuators 13. In this example there are h actuators 13.
  • each controller 9 is arranged to generate one setpoint per actuator 13. As there are h actuators 13, this means that each of the controllers is arranged to generate h setpoints, which may or may not be all different. However, the controllers 9 need not issue setpoints/commands for all actuators or could issue several setpoints/commands for some or all of them.
  • the teachings of the present invention apply as long as all the controllers behave substantially identically.
  • the measurements and setpoints are sent over the networks 7, 1 1 , which are not ideal. This may thus lead to delayed or lost messages (ie the measurements or setpoints). In case of no loss, the propagation delay is bounded by 5 n .
  • the message handling or processing time of non-faulty controllers 9 is negligible with respect to ⁇ 5 n .
  • This network model is called probabilistic synchronous.
  • the RTCS 1 according to the present invention is expected to hold three properties as explained below.
  • the state used by the controllers 9 for computing the setpoints can be known exactly. This property is satisfied by a wide range of controllers including controllers using Kalman filters where the state is the gain matrix, or more
  • controllers 9 are not perfect, ie they may comprise commercial-off- the-shelf (COTS) components, they are susceptible to faults.
  • COTS commercial-off- the-shelf
  • the present invention considers delay faults. Any controller 9 is marked delay faulty between two consecutive issuings of setpoints if its delay in issuing the previous setpoint is greater than a pre-defined value.
  • a crash fault is a special case of delay fault with the controller's delay being infinite. The intermittent nature of delay faults makes real-time agreement more challenging.
  • controllers 9 are expected to satisfy the following property. Property 2.
  • the controllers 9 can compute correct setpoints in the presence of intermittent measurements.
  • Controllers of RTCSs that exhibit this property can compute and issue setpoints despite intermittent faults, either in the network (losses of measurements) or in the controller (delay faults).
  • an RTCS that does not exhibit Property 2 will eventually permanently fail to compute and issue setpoints, even in the absence of crash faults. This is because a controller that fails to compute setpoints for a label r cannot compute setpoints for all labels greater than r.
  • a controller might compute setpoints for label k ⁇ r - 1 , be delay faulty for some time and then compute setpoints for label r, by using a controller state corresponding to label k, without the knowledge of the intermediate states. It is to be noted that the resulting setpoints would be correct, but might be sub-optimal when compared to those computed using the state corresponding to label r - 1 (ie more recent state).
  • Actuators are able to handle duplicate setpoints, ie at least two setpoints (which are advantageously identical).
  • RTCSs that use absolute, rather than differential, setpoints.
  • An example of absolute setpoints is an electrical grid controller instructing a battery agent that is injecting for instance 8kW to 'set the injected power to 10kW, rather than to 'increase the injected power by 2kW.
  • Receiving at least two identical setpoints has the same effect as receiving a single setpoint.
  • Property 3 can also be achieved by deduplication using additional labels for the setpoints.
  • the proposed method of generating setpoints is next explained in more detail with reference to the flow charts of Figures 2 to 4. It is to be noted that the method described in the flow charts of Figures 2 to 4 may be carried in parallel by all the controllers 9 of a set of controllers.
  • step 21 the following parameters are set to zero: r, r, Z and H, where r is the highest label of measurements received by the controller at a given time instant, r is the highest label of measurements used by the controller for computation of a setpoint at a given time instant, also referred to as a controller state label, Z is a vector of measurements with label r, and H is a controller state after computing setpoints with label r.
  • r can also be understood to be a tag of the controller state H.
  • the controller 9 receives the measurements from the sensors 3. Prior to that, the sensors 3 have previously taken measurements of the process 5.
  • step 25 the controller 9 generates or updates the vector of measurements, Z, corresponding to label r.
  • step 27 it is determined whether or not r is larger than r. In other words, it is determined whether or not the received measurement(s) has (have) a higher label than any previously received measurement used for computation. If the response is no, then the process continues in step 23. If the response to the question in step 27 is in the affirmative, in step 29, a collection function is called.
  • steps 23, 25 and 27 are repeated continuously allowing measurements to be received and aggregated in the vector Z.
  • the vector Z is formed, and, when new measurements with label greater than r are received, r is overwritten and simultaneously also all the entries in the vector. This may be carried out in parallel with step 29.
  • different measurements from the sensors 3 may be received at slightly different time instants due to non-optimal operation (in terms of delay) of the first communication network 7 and/or the sensors 3.
  • the vector Z may comprise only one measurement entry and the other entries would be zero before new measurements are received for this label.
  • time-alignment function in phasor data concentrators upon receiving time-stamped measurements from phasor measurement units (PMUs).
  • PMUs phasor measurement units
  • the time-alignment function in phasor data concentrators takes care of aggregating a set of measurements with a given label/timestamp that are received at slightly different time instants.
  • this function would provide the controller with all the measurements from PMUs that it received within a small time duration (typically the jitter in the network).
  • the collector 9 forms a vector S, which in this example comprises a set of identities (IDs) of the sensors 3 from which it has received measurements with label r. Also in step 31 , the controller 9 sends a query to all the other controllers 9 asking for the missing measurements (entries of S). In this example, the query includes the label r to indicate to which label the missing measurements are requested. In step 33, the collector 9 informs the other controllers 9 about its r. In other words, the controller 9 sends an advertisement containing its state label r " to the other controllers 9. As mentioned before, r " is the label of the measurements involved in the setpoint computation leading up to that state, also referred to as the state label.
  • step 35 a timer is started.
  • a timer of 2 ⁇ 5 n is started.
  • step 37 it is determined whether or not the time measured by the timer has elapsed. In the affirmative, the process continues in step 39. In this step the controller 9 returns its set of
  • step 41 it is determined whether or not the controller 9 has received a query asking for measurements the other controllers 9 have not received. If a query has been received, then in step 43 it is determined whether or not the received query contains the label r. If the received query contains the label r, then in step 45 the controller 9 sends a response to all the other controllers 9 with answers to the query. The label r is included in the response. In other words, for each query received, the controller 9 sends a response containing the queried measurements it has. It is however possible that the controller 9 does not have all the answers to the query. In that case, only the answers that the controller 9 has are sent. After step 45, the process continues in step 47.
  • step 47 it is determined whether or not the controller 9 has received a response to the query it sent in step 31 . If a response has been received, then in step 49, it is determined whether or not the response contains the label r. In the affirmative, in step 51 , the controller 9 updates its set of measurements (vector Z) to include the measurements received in the response. From step 51 the process continues in step 53. In step 53, it is determined whether or not the controller 9 has received an advertisement. In the affirmative the process continues in step 55, where it is determined whether or not the received advertisement contains a state label I (I is a variable) that is smaller than r .
  • I is a variable
  • step 57 the controller 9 sends an update to all the other controllers 9.
  • the update comprises the current state of the controller 9 and its state label r so that the other controllers 9 can synchronise their state accordingly.
  • step 59 it is determined whether or not the controller 9 has received an update message from any other controller 9. If an update has been received, then in step 61 it is determined whether or not the received update comprises a state label I which is larger than r " , ie whether or not I > r " .
  • step 63 the controller 9 updates the current state of the controller 9 to the received state and the current state label to I as received in the update. From step 63 the process continues in step 37 to determine whether or not the timer has ended. If in steps 59 or 61 the response is negative, then the process also continues in step 37. It is to be noted at least some of the above message exchanges include the label r to ensure that stale (not most recent) measurements, caused by delay-faulty controllers 9 sending queries or responses, are ignored.
  • the operations carried out in in the flow chart of Figure 3 are comprised in a measurement and state collection phase, collectively referred to as a collection phase or simply collection. In this example, the measurement and state collection phases are run substantially simultaneously.
  • the collection phase lasts for at most 2 ⁇ 5 n at each collector 9 (the time required for queries and responses to be delivered), resulting in a bounded latency of 2 ⁇ 5 n for the collection phase.
  • the collection phase comprises the controllers 9 exchanging measurements and state.
  • the collection, designed with delay faults in mind, is in this example terminated after 2 ⁇ 5 n .
  • non-delay-faulty controllers can proceed with a next step (a voting phase) without waiting for delay-faulty ones.
  • the collection phase ends with each controller 9, in step 64 ( Figure 2), generating and sending its digest (a measurement summary) to all the other controllers 9.
  • the digest with a label I consists of (1 ) an indicator set S of measurements (IDs of the sensors from which it has received measurements) with label I (in this case the label I is a label of the digest) that this controller 9 has, and (2) the state label r at this controller 9.
  • the process continues in step 65 ( Figure 2), where the controller 9 calls a voting function as outlined in the flow chart of Figure 4.
  • the controllers 9 comprise a software unit, referred to as a voter, enabling the controllers 9 to vote on the digests as explained below.
  • the present invention uses a total order among digests. Consequently, a function, referred to as a max, returns the largest digest, based on the total order.
  • a function referred to as a max
  • For each label, there exists a largest possible digest (full_digest) that does not contain any missing measurements and that has r 1-1 .
  • the lexicographic ordering of the digest string gives the total order, with "24.1 1 1 1 " being the full_digest.
  • the present invention may also use a so-called composite voter that, in cases of no single majority, selects the output of one of the controllers 9 based on a predetermined order.
  • the proposed solution uses an ordering based on the number of measurements, a scheme more suited to RTCSs.
  • the proposed solution may use plurality voting (someone received more votes than the others), instead of majority voting (someone received more than 50% of the votes), as it has higher availability.
  • each controller 9 maintains a list or vector v of digests received with label r from the other controllers 9, with at most one entry in the vector v per controller. From the vector v, the controllers 9 attempt to vote and choose a digest, such that all the controllers 9 choosing a digest with label r, choose the same digest. Each voter also maintains two other lists, namely S mc and S sec and three integers, namely f mc , f sec and f 0 , that are updated when a new digest is received and stored in the vector v. As the same digest can be received from several controllers 9, the number of occurrences of each unique digest in the vector v is counted.
  • step 67 the controller 9 initialises the vector of digests v, ie the entries of vector v are set to zero.
  • step 69 a timer is started. In this example, a timer of 3 ⁇ 5 n is started.
  • step 71 it is determined whether or not the time counted by the timer has expired. In the affirmative, the process continues in step 73, where the process returns unsuccessfully to the calling function. On the other hand, if in step 73 it is determined that the time has not yet expired, then in step 75, it is determined whether or not a digest has been received. If no digest has been received, then the process continues in step 71 . If a digest has been received, then in step 77, it is determined whether or not the received digest contains the label r. If the received digest does not contain the label r, then the process continues in step 71 . If on the other the received digest contains the label r, then in step 79 the received digest is added to the vector v.
  • step 81 it is determined whether or not a digest has been received from all the controllers 9. If all the digests have been received, then in step 83, the digest from the vector v is selected such that the selected digest has the majority. If more than one exists in a majority set, the largest digest is chosen.
  • step 83 The number of empty cells in the vector v is zero (case of step 83). In this case, the voter has to choose one of the digests that is most common. If there is only one, it is chosen, otherwise, it chooses the largest among them. 2) There is only one most common digest, and it will remain so no matter what the controllers 9 that have yet to send digests send. It is chosen (as the obvious majority). This is the case of step 85.
  • any second most common digest can be at most as frequent as the most common one. In this case, if the most common digest is larger than all the second most common digests, the voter chooses it. This is the case of step 87. 4)
  • the full_digest is the only most common one and no other digest can become more common. Since it is the largest by definition, it is chosen. This is the case of step 89.
  • item 4 enables a two-controller RTCS to be available when one of its controllers is faulty, if the other controller receives all the measurements and is up-to-date on the state (full_digest).
  • the voter returns unsuccessfully after 3 ⁇ 5 n , which is enough time to allow the non-faulty controllers to send their digests.
  • the voting phase assumes an upper bound on the number of controllers 9 (faulty or non-faulty). This can be achieved either by statically configuring the number of controllers every time a new controller is added or removed, or by using a group membership algorithm.
  • the introduction of a new controller can wait until the termination of the group membership algorithm. During this time, the RTCS 1 continues to provide consistency but with reduced availability due to a conservative count of the number of controllers.
  • step 91 Figure 2
  • step 93 the controller computes the setpoints by using the measurements identified by the measurements IDs in the selected (voted) digest and the controller state.
  • the computation of setpoints X corresponding to label r depends on the measurements of the label r (Z), state (H), and correction factor (r - r).
  • the controller can begin computing setpoints. The computations are performed in a strictly increasing order in r. Also, each computation results in a new controller state. It is to be noted that all the controllers 9 select the same digest to form the basis for the computation of the setpoints.
  • step 95 the controller 9 sends the setpoints to the actuators 13.
  • Algorithms 1 to 5 explained below. Algorithm 1 gives an overview of the whole method. Some of the steps of Algorithm 1 are explained later in more detail with reference to Algorithms 2 to 4.
  • Algorithm 1 1 : r ⁇ - 0; // r is the highest label of measurements received;
  • H H ⁇ - 0; // H is a controller state after computing setpoints with label r ⁇
  • Thread 2 Compute and issue setpoints.
  • Algorithm 2 gives an overview of the collection and voting phases.
  • the subscript “coll” refers to collection and gives a corresponding parameter value after the collection.
  • Algorithm 2 collect_and_vote(Z, H, r, r )
  • Algorithm 3 gives a detailed overview of the measurement collection phase.
  • Q refers to indices of Z received in a query, while P is a vector of measurements received in a response.
  • Algorithm 4 gives a detailed overview of the state collection phase.
  • H' refers to the state received in an update message.
  • Algorithm 4 collect_missing_state(H, r)
  • Algorithm 5 gives a detailed overview of the voting phase.
  • One aspect of the invention can be summarised as follows. It is proposed a method of agreeing on measurements before computing one or more setpoints for one or more actuators 13 of a real-time control system 1 .
  • the method comprises:
  • a first controller 9 receiving a first set of measurements from sensors 3, the measurements being individually labelled with a sequence number, referred to hereinafter as a measurement label;
  • the first controller 9 receiving a second set of measurements from a second controller 9, the received measurements of the second set of measurements being individually labelled with the same measurement label as the measurement label of the measurements of the first set of measurements;
  • the first controller 9 generating a first digest from at least the first and second sets of measurements, the first digest comprising a first data set for determining measurements the first controller has received, and a first controller state label;
  • the first controller 9 receiving at least a second digest from at least the second controller 9, the second digest comprising a second data set for determining measurements the second controller has received, and a second controller state label;
  • the first controller 9 selecting one digest from a set of digests comprising the first and second digests for generating one or more setpoints.
  • the first and second measurement sets may be different.
  • the first controller 9 then generates the one or more setpoints by using at least the
  • the first and second data sets may comprise indices of the measurements and/or the (entire) measurements the first and second controllers 9 have received, respectively.
  • the measurement set used for the computation may be a subset of the whole measurement set comprising measurements from all the sensors. Furthermore, in the above explanations it was assumed that the measurements are not corrupted.
  • the proposed solution stems from the observation that performing agreement on the input allows for an optimisation that increases the probability of a successful agreement. This optimisation was referred to as the collection phase, and involves the controllers exchanging measurements and state so as to minimise the missing information in each controller.
  • the proposed solution provides higher availability than existing solutions, and the availability improvement is up to 10x with two controllers. While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive, the invention being not limited to the disclosed embodiment.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé de génération de points de consigne d'actionneurs (13) d'un système de commande en temps réel. Le procédé consiste, au moyen d'un premier contrôleur (9), à : a) recevoir un premier ensemble de mesures de capteurs (3), les mesures étant étiquetées individuellement avec un numéro de séquence, désigné ci-après comme étiquette de mesure; b) recevoir un second ensemble de mesures d'un second contrôleur (9), les mesures reçues du second ensemble de mesures étant étiquetées individuellement avec les mêmes étiquettes de mesure que les étiquettes de mesure des mesures du premier ensemble de mesures; c) générer un premier condensé à partir des premier et second ensembles de mesures, le premier condensé comprenant une indication des capteurs (3) dont les mesures ont été reçues par le premier contrôleur, et une première étiquette d'état de contrôleur; d) recevoir au moins un second condensé dudit second contrôleur (9), le second condensé comprenant une indication des capteurs (3) dont les mesures ont été reçues par le second contrôleur, et une seconde étiquette d'état de contrôleur; e) sélectionner un condensé dans un ensemble de condensés comprenant les premier et second condensés pour générer des points de consigne; et f) générer les points de consigne à l'aide des mesures et d'un état de contrôleur indiqué par le condensé sélectionné.
PCT/EP2017/058421 2017-04-07 2017-04-07 Contrôleur et protocole d'accord de système de commande en temps réel WO2018184699A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/058421 WO2018184699A1 (fr) 2017-04-07 2017-04-07 Contrôleur et protocole d'accord de système de commande en temps réel

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/058421 WO2018184699A1 (fr) 2017-04-07 2017-04-07 Contrôleur et protocole d'accord de système de commande en temps réel

Publications (1)

Publication Number Publication Date
WO2018184699A1 true WO2018184699A1 (fr) 2018-10-11

Family

ID=58638832

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/058421 WO2018184699A1 (fr) 2017-04-07 2017-04-07 Contrôleur et protocole d'accord de système de commande en temps réel

Country Status (1)

Country Link
WO (1) WO2018184699A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0601150A1 (fr) * 1992-06-20 1994-06-15 Bosch Gmbh Robert Dispositif de commande de vehicules a moteur.
DE10113917A1 (de) * 2001-03-21 2002-09-26 Bosch Gmbh Robert Verfahren und Vorrichtung zur Überwachung von Steuereinheiten
US20070198106A1 (en) * 2006-02-23 2007-08-23 Rockwell Automation Technologies, Inc. Optimizing availability and safety by reconfiguring and auto-adjusting redundancy
WO2016016135A1 (fr) * 2014-07-30 2016-02-04 Siemens Aktiengesellschaft Procédé et système permettant d'attribuer une autorisation de commande à un ordinateur
US20160202684A1 (en) * 2013-09-10 2016-07-14 Schneider Electric Industries Sas Automation system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0601150A1 (fr) * 1992-06-20 1994-06-15 Bosch Gmbh Robert Dispositif de commande de vehicules a moteur.
DE10113917A1 (de) * 2001-03-21 2002-09-26 Bosch Gmbh Robert Verfahren und Vorrichtung zur Überwachung von Steuereinheiten
US20070198106A1 (en) * 2006-02-23 2007-08-23 Rockwell Automation Technologies, Inc. Optimizing availability and safety by reconfiguring and auto-adjusting redundancy
US20160202684A1 (en) * 2013-09-10 2016-07-14 Schneider Electric Industries Sas Automation system
WO2016016135A1 (fr) * 2014-07-30 2016-02-04 Siemens Aktiengesellschaft Procédé et système permettant d'attribuer une autorisation de commande à un ordinateur

Similar Documents

Publication Publication Date Title
Sarin et al. Discarding obsolete information in a replicated database system
CN110047014B (zh) 一种基于负荷曲线和历史电量的用户电量数据修复方法
CN110320791A (zh) 一种用电信息采集系统时钟管理方法及装置
Melliar-Smith et al. Broadcast protocols for distributed systems
Holloway et al. Time templates for discrete event fault monitoring in manufacturing systems
US20060190243A1 (en) Method and apparatus for data management
CN103346904A (zh) 一种容错的OpenFlow 多控制器系统及其控制方法
CN104978842B (zh) 一种低压集中器时钟自我修复的方法
CN114050904B (zh) 一种基于两层级领导节点分片结构的共识系统及方法
US11831746B2 (en) Time consistency synchronization method for distributed simulation
Saab et al. Quarts: Quick agreement for real-time control systems
CN110430103A (zh) 一种报文监测方法
CN114513510A (zh) 一种面向许可链的分布式跨链事务中继系统及其通信方法
WO2022238345A1 (fr) Synchronisation de données dans des réseaux informatiques périphériques
CN110535955A (zh) 一种基于多链的配用电数据共享系统与方法
WO2018184699A1 (fr) Contrôleur et protocole d'accord de système de commande en temps réel
CN116260826A (zh) 一种供应链溯源中拜占庭容错共识方法及系统
CN110071778B (zh) 一种对时方法、装置、设备及介质
CN105141687B (zh) 一种生产消息的方法
CN107589736A (zh) 电池管理系统主从控板数据同步方法
van Rooij et al. echidna: Continuous data validation in advanced metering infrastructures
WO2023179056A1 (fr) Procédé et appareil de traitement de consensus d'un réseau à chaîne de blocs, dispositif, support de stockage et produit programme
CN114362871B (zh) 一种电能表群组自维护时钟的方法
An et al. Research on Byzantine Fault Tolerant algorithm based on Node Weights
CN111428277B (zh) 区块链数据的校验方法、装置及系统

Legal Events

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

Ref document number: 17719818

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17719818

Country of ref document: EP

Kind code of ref document: A1