WO2018115694A1 - Plateforme et dispositif de gestion d'éléments physiques d'un système - Google Patents

Plateforme et dispositif de gestion d'éléments physiques d'un système Download PDF

Info

Publication number
WO2018115694A1
WO2018115694A1 PCT/FR2017/053667 FR2017053667W WO2018115694A1 WO 2018115694 A1 WO2018115694 A1 WO 2018115694A1 FR 2017053667 W FR2017053667 W FR 2017053667W WO 2018115694 A1 WO2018115694 A1 WO 2018115694A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
state
physical element
physical
request
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.)
Ceased
Application number
PCT/FR2017/053667
Other languages
English (en)
Inventor
Gilles Privat
Laurent LEMKE
Didier DONSEZ
Florence MARININCHI
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 Polytechnique de Grenoble
Orange SA
Universite Grenoble Alpes
Original Assignee
Institut Polytechnique de Grenoble
Orange SA
Universite Grenoble Alpes
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 Polytechnique de Grenoble, Orange SA, Universite Grenoble Alpes filed Critical Institut Polytechnique de Grenoble
Publication of WO2018115694A1 publication Critical patent/WO2018115694A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Definitions

  • a cyber-physical system is a system in which computer entities collaborate for the supervision and control of a system composed of physical elements, through a computer network. It may be directly controllable physical elements, provided with actuators for this purpose and if necessary equipped with sensors, such as for example a retractable stud, a street lamp, a traffic light, etc., as physical elements that can not be controlled directly, but can be controlled indirectly via other controllable entities, such as a road segment (which can be controlled for example by means of retractable studs or lights), etc.
  • the invention relates more particularly to the control by a software application of one or more controllable physical elements by means of an actuator.
  • platforms to simplify and “horizontalize” the design of cyber-physical systems and to pool the use of data exchanged in these systems, in other words observation data collected from the elements. physical (pooling of data collected by the sensors fitted to the physical elements).
  • These platforms serve as intermediaries between the physical elements on the one hand, and the applications controlling these physical elements on the other hand.
  • Such platforms are notably proposed in the field of the Internet of Things, such as the Xively TM platform, a description of which is given in particular on the website https://www.xively.com or the platform Predix TM which a description is available on the website https://www.ge.com/digital/predix.
  • a conflict appears as soon as a request for change of state issued by an APP2 application is accepted by a physical element (in the above example, by the retractable pad) during the lapse of time necessary for this physical element to execute a state change previously required by a APP1 application distinct from the APP2 application.
  • the consequence of such a conflict is the overwriting of the state change being executed (and required by the APP1 application in the example above) by the last change of state request received by the physical element (and issued by APP2 application).
  • the existence of such a conflict risk means that applications never have the guarantee that their change of state requests will have the desired effect on the physical element, even if these requests have been accepted by this last.
  • the invention remedies this disadvantage by proposing a management platform of a system comprising at least one physical element that can be controlled (ie controlled) by at least one application and whose state can be modified by means of a actuator, said management platform comprising:
  • a modeling module configured to represent each physical element of the system by means of a controllable entity reflecting a current state of the physical element, this controllable entity being able to take a finite number of states and being associated with a control lock unique of a change of state of the physical element;
  • a management module configured to guarantee that the unique control lock associated with each controllable entity is allocated at a given instant to at most one application or to at most one representative of an application controlling the physical element represented by this entity controllable and likely to require a change of state of this physical element;
  • a control module configured to trigger a change of state of at least one physical element of the system required by an application controlling said at least one element or by a representative of an application controlling said at least one physical element only if the unique control lock associated with each controllable entity representing a said physical element whose status change is required is assigned to that application or to that representative an application.
  • the invention also relates to a management method of a system comprising at least one physical element that can be controlled by at least one application and whose state can be modified by means of an actuator, said management method being intended to be implemented by a system management platform and comprising:
  • the invention proposes to manage the risks of conflict likely to appear between several applications seeking to control one (or more) same physical element (s) at the same time by means of a locking mechanism the physical element to guarantee the mutual exclusion of applications.
  • This locking mechanism is implemented by a management platform that acts as an intermediary between the physical elements of the system and the applications that can control these physical elements.
  • the locking mechanism proposed by the invention is based on the one hand, on the modeling of physical elements provided with actuators by controllable entities reflecting the current state of these physical elements and can take a finite number of states modeling the possible states of the physical elements, and on the other hand, by predicting for each of these controllable entities a single lock to control a change of state of the physical element that they represent.
  • the controllable entities are for example described using discrete finite state machines, well known per se. This makes it possible to have a generic modeling of the physical elements.
  • the unique lock associated with each controllable entity (and therefore with each physical element) is advantageously binary according to the invention, in other words, at each instant:
  • an application (or a representative of such an application) must first obtain the lock associated with the controllable entity representing this physical element.
  • This lock being unique and specific to each physical element, it avoids any appearance of conflict between the state change commands issued by competing applications. In this way, the state changes required by the applications and accepted by the physical elements can be completed.
  • a first example of application of the invention is in smart buildings.
  • the invention makes it possible, for example, to manage the control of motorized shutters in such a building shared between a security application and a power management application. Regardless of the priorities that can be established between these two applications, it is necessary to ensure in such a context that the state of the components presented to them by the platform is coherent and that there is no conflict as presented previously. .
  • the invention can also be applied to the concept of smart cities, for example to manage a case in which devices for closing a street (eg barriers, retractable pads and / or lights) can be controlled concurrently by several applications. , such as a traffic management application and an access control application.
  • a traffic management application e.g barriers, retractable pads and / or lights
  • an access control application e.g., a traffic management application and an access control application.
  • the invention advantageously makes it possible to avoid such a situation.
  • the locking mechanism proposed by the invention can be implemented in various ways.
  • the management module is configured to:
  • Such a token is for example a unique identifier that uniquely identifies the application or the representative of an application to which the lock has been assigned. It can therefore be used as proof of lock possession by the application or application representative.
  • the token is preferentially provided to the application itself, which then inserts it into its requests for change of state. the physical element as evidence of possession of the control lock of that physical element.
  • the invention makes it possible to respect the principles of a REST architecture (for REpresentational State Transfer), commonly used for distributed systems and in particular for scalable distributed systems (or "scalable" in English).
  • This architecture of the client-server type recommends that each request from a client (here the application) to a server (here the platform) must contain all the information necessary to allow the server to understand the request without having to depend on a context preserved on the server (constraint called "stateless” or stateless in English).
  • the application by providing the application with the token to prove that it holds the lock associated with a physical element, it is ensured that it is the application that stores this token, and that the management platform does not need to keep this token.
  • the token is generated by the management module for a predetermined period of validity.
  • This embodiment has a preferred application when the application requires the change of state of a single physical element. This ensures that the application only holds the lock of this physical element for a certain period of time, after which it is released automatically. This automatic expiration of the lock after a predetermined period of validity avoids applications that monopolize the physical elements too long.
  • This predetermined validity period is preferably set greater than or equal to a time required for the physical element represented by the controllable entity to execute its longest state change. It is counted from the moment the lock is assigned to the application. In other words, according to this assumption, the duration of validity depends on the physical element whose lock controls the change of state. In this way, an application holding the lock is ensured to perform at least one change of state, moreover the change of state that requires the most time to the physical element. In addition, it can order more state changes if the validity period has not expired.
  • the management platform further comprises a processing module configured for receiving a request from an application and requesting a change in states of a plurality of physical elements. of the system, instantiating a coordination module representing said application, and wherein said instantiated coordination module is configured to:
  • a coordination module is dynamically instantiated by the management platform when the application requires the change of state of several physical elements.
  • This coordination module acts as a representative of the application to the different controllable entities representing the physical elements which a change of state is required by the application.
  • the coordination of the multiple controllable entities as proposed by the invention in this embodiment allows the application to be able to perform a global and atomic operation (via the sending of a single request) leading to the change of state of several separate physical elements that are not necessarily physically related to each other.
  • the coordination module is configured to release the control locks that are assigned to it when all the state changes of said physical elements required by said application are completed.
  • the coordination module thus ensures the atomicity of the coordination by ensuring that the locks associated with the different controllable entities are not released until the end of the coordination, that is to say, if necessary, the change of state of all the physical elements targeted by the application.
  • This embodiment also makes it possible to avoid that a physical element remains locked indefinitely after the end of the coordination implemented by the coordination module.
  • each controllable entity is searchable by an application to know the current state of the physical element that it represents that the control lock associated with this controllable entity is or is not assigned to this application.
  • the locking mechanism proposed by the invention is applied only for the state changes of the physical elements. It does not preclude the consultation by competing applications of these physical elements in order to know their current states.
  • the invention relies not only on an intermediate management platform between the applications and the physical elements, but also on controllable entities reflecting the current states of the physical elements of the system, as well as in some embodiments of the software applications themselves that are likely to control these physical elements and a coordination module instantiated where appropriate by the management platform.
  • the invention also aims, according to a second aspect, a controllable entity reflecting a current state of a physical element that can be controlled by at least one application and whose state can be modified by means of an actuator, said entity controllable being associated with a single control lock of a state change of the physical element, and comprising:
  • a first verification module activated on receipt of a request for obtaining the control lock from an application or a representative of an application, said first verification module being configured to check whether the lock of control is already assigned;
  • a processing module of the obtaining request configured for:
  • a second verification module activated on receipt of a request for a change of state of the physical element coming from an application or a representative of an application, said second verification module being configured to checking whether said request includes proof of possession of the control lock;
  • the invention also relates to a method of treatment, intended to be implemented by a controllable entity reflecting a current state of a physical element that can be controlled by at least one application and whose state can be modified at the same time.
  • a controllable entity reflecting a current state of a physical element that can be controlled by at least one application and whose state can be modified at the same time.
  • this controllable entity being associated with a single control lock of a change of state of the physical element, the processing method comprising:
  • a verification step triggered upon receipt of a request to obtain the control lock from an application or an application representative, and during which the controllable entity checks whether the lock of control is already assigned;
  • a step of processing the request for obtaining the lock comprising:
  • a verification step triggered upon receipt of a request for a change in state of the physical element from an application or an application representative, during which the controllable entity verifies whether said change of state request includes proof of possession of the control lock;
  • controllable entity's processing module is further configured to generate a token when the control lock is assigned to said application or the representative of an application and to transmit said token as proof of possession. from the control lock to said application or representative of an application.
  • the invention also aims at a software application, capable of controlling at least one physical element of a system comprising a plurality of physical elements, a state of said physical element being able to be modified by means of an actuator, said software application comprising:
  • a first sending module configured to send to a controllable entity reflecting a current state of said physical element, this controllable entity being able to take a finite number of states and being associated with a single control lock of a change of state the physical element, a request to obtain said control lock;
  • a reception module activated if said control lock is allocated to said software application, and able to receive a proof of detention of said control lock;
  • a second sending module configured to send to said controllable entity a request for a change of state of the physical element, said request comprising said proof of holding of the control lock.
  • the invention also provides a method for controlling at least one physical element of a system comprising a plurality of physical elements, a state of said physical element that can be modified by means of an actuator, said control method being intended to be implemented by a software application and comprising: A step of sending to a controllable entity reflecting a current state of said physical element, this controllable entity being able to take a finite number of states and being associated with a single control lock of a state change of the element physical, a request to obtain said control lock;
  • a reception step triggered if said control lock is assigned to said software application, comprising receiving a proof of detention of said control lock
  • the invention also provides a device comprising a software application according to the invention.
  • this device may be a user terminal such as for example a mobile phone or a smartphone, a tablet, a computer or a laptop, or a device in a network such as for example, a server or a service gateway (eg an ADSL home gateway also more commonly known as "ADSL box", a home automation gateway, a building automation gateway, etc.).
  • a user terminal such as for example a mobile phone or a smartphone, a tablet, a computer or a laptop
  • a device in a network such as for example, a server or a service gateway (eg an ADSL home gateway also more commonly known as "ADSL box", a home automation gateway, a building automation gateway, etc.).
  • the invention provides a coordination module instantiated by a management platform of a system comprising physical elements whose state can be modified by means of an actuator, said coordination module being instantiated upon reception by said platform for a request to change states of a plurality of physical system elements from an application, each physical element being represented at the management platform by a controllable entity reflecting a current state of that physical element and capable of taking a finite number of states, said controllable entity being associated with a single control lock of a state change of the physical element it is modeling, said coordination module comprising:
  • a first sending unit configured to send to each controllable entity representing a physical element of said plurality of physical elements a request to obtain the control lock associated with this controllable entity
  • a second sending unit activated if all the control locks associated with the controllable entities representing said plurality of physical elements are allocated to the coordination module, and configured to send to each controllable entity a change of state request request; the physical element it represents in accordance with the state required in the request from said application, said physical state change request including a proof of holding the control lock associated with the controllable entity;
  • the invention also relates to a coordination method intended to be implemented by a coordination module instantiated by a management platform of a system comprising physical elements whose state can be modified by means of an actuator.
  • the coordination method comprises:
  • a second sending step triggered if all the control locks associated with the controllable entities representing said plurality of physical elements are allocated to the coordination module, said second sending step comprising sending to each controllable entity a a state change request of the physical element that it represents according to the state required in the request from said application, said state physical state change request including a proof of possession of the control lock associated with the controllable entity;
  • controllable entity the processing method, the software application, the control method, the coordination module and the coordination method benefit from the same advantages described above as the management platform and the management method.
  • the various steps of the management method, the processing method, the control method and / or the coordination method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a computer, this program comprising instructions adapted to the implementation of the steps of a method of management, a method of treatment, a method of control or a method of coordination as described above.
  • This program can 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 form desirable shape.
  • the invention also relates to a computer readable information or recording medium, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, or an EEPROM or FlashRAM microelectronic circuit, or a magnetic recording means, for example a hard disk, or a FlashRAM recording means (SSD, SD card, etc.).
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information or recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also aims at a cyber-physical system comprising:
  • a physical system comprising a plurality of physical elements
  • a plurality of applications capable of controlling said physical elements capable of controlling said physical elements; and a system management platform comprising said plurality of physical elements according to the invention.
  • FIG. 1 shows, schematically, a cyber-physical system according to the invention and comprising a management platform according to the invention
  • FIG. 2 represents an example of a hardware architecture of the management platform of FIG. 1;
  • FIG. 3 represents an exemplary configuration of the cyber-physical system of FIG. 1 in a first embodiment
  • FIG. 4 represents the main steps of a management method, a processing method and a control method as implemented by the management platform, by the applications and by the controllable entities. the cyber-physical system of Figure 1 when in the configuration shown in Figure 3;
  • FIG. 5 represents an exemplary configuration of the cyber-physical system of FIG. 1 in a second embodiment
  • FIG. 6 represents the main steps of a management method, and a coordination method as implemented by the management platform and by a coordinator of the cyber-physical system of FIG. it is in the configuration shown in Figure 5.
  • FIG. 1 represents, in its environment, a cyber-physical system 1 according to the invention, in a particular embodiment.
  • the cyber-physical system 1 comprises:
  • a physical system 2 comprising a plurality of physical elements PI, P2,..., PN, N denoting any integer greater than 1;
  • a management platform 3 of the system 2 according to the invention is a management platform 3 of the system 2 according to the invention.
  • all or some of the physical elements ⁇ ,,,,, ⁇ are provided with actuators only and are not equipped with sensors.
  • the physical elements ⁇ ,.,., ⁇ can interact with each other, and organized according to different hierarchical levels.
  • the physical system 2 can also include physical elements which can not be controlled directly via actuators, but via the controllable physical elements ⁇ ,,,,, ⁇ .
  • a non-directly controllable element is for example a road segment, on which it can act indirectly through traffic lights or controllable barriers directly by means of actuators.
  • no limitation is attached to the nature of the APP1, APP2, ..., APPK software applications (eg security applications, traffic thinning, access control, etc.). They depend of course on the nature of the physical elements ⁇ ,.,., ⁇ , and the context of implementation of the invention.
  • a terminal such as for example a user terminal such as a tablet, a smartphone, a computer, or be housed in a network equipment, such as a server or a service gateway for example, or be co-hosted on the management platform 3 itself.
  • a network equipment such as a server or a service gateway for example, or be co-hosted on the management platform 3 itself.
  • the management platform 3 here acts as an intermediary between the applications ⁇ ,.,., ⁇ on the one hand and the physical elements P1, P2, ..., PN on the other hand.
  • the management platform 3 pools sensor data and accesses to actuators C1 / A1, ..., CN / AN. It communicates with each other for example via one or more telecommunications networks, known per se. No limitation is attached to the nature of these networks. But it is assumed here that the communication delays (latencies) between the platform, the applications, and the actuators are controlled.
  • the management platform 3 has the hardware architecture of a computer, as illustrated in FIG. 2.
  • These communication means 8 are known per se and depend on the interfaces existing between the management platform 3, the sensors / actuators and the applications.
  • the read-only memory 6 of the management platform 3 constitutes a recording medium in accordance with the invention, readable by the processor 4 and on which is recorded here a computer program PROG according to the invention.
  • the computer program PROG defines functional modules (and software here), configured to implement the steps of the management method according to the invention. These functional modules rely on and / or control the hardware elements 4-8 of the management platform mentioned above. They include in particular here, as illustrated in FIG.
  • a modeling module 3A configured to represent each physical element Pn of the physical system 2 by means of a controllable entity, denoted ECn.
  • This controllable entity is an executable model that can take a finite number of states (according to a discrete time operation) and constituting an abstraction of the physical element Pn that it represents: it reflects a current state of the physical element Pn as well as the possible transitions between all the states of the physical element Pn. For example, for a traffic light, the corresponding controllable entity represents the state of the light (red, green, or orange), and the possible transitions between each state of the light (green to orange, orange to red, red to green).
  • Each entity controllable ECn is described for example here by means of a PLC, such as a Mealy automaton known per se and not described in detail here;
  • the aforementioned functional modules can be distributed over one or more servers and are not necessarily located on a single hardware device.
  • This lock is for example here a binary software variable maintained by the controllable entity ECn, and whose value depends on the state of allocation of the lock: thus, the lock takes a first value (eg 1) if it is at the instant considered (current instant) attributed to an application, and a second value (eg 0) distinct from the first value, if it is not assigned to any application.
  • each controllable entity ECn comprises various software modules, namely:
  • a first verification module 9A activated on receipt of a request to obtain the control lock Ven from an application or an application representative, this first verification module 9A being configured to check whether the control lock Ven is already assigned;
  • a processing module 9B of the request for obtaining the lock configured for:
  • a second verification module 9C activated on receipt of a request for a change of state of the physical element Pn originating from an application or a representative of a application, this second verification module 9C being configured to check whether the change of state request includes a proof of possession of the control lock Ven; and a 9D execution module of the state change required if the change of state request includes such proof of holding the control lock Ven.
  • control ie control
  • This first embodiment illustrates how the invention makes it possible to avoid any risk of conflict in the control of the PI physical element between two competing applications.
  • co-ordinated control i.e. control
  • co-ordinated control i.e. control of a plurality of physical elements of the physical system 2.
  • the first embodiment of the invention is contemplated.
  • Figure 3 illustrates an exemplary configuration of the cyber-physical system 1 in the first embodiment.
  • APP1 and APP2 capable of controlling (controlling) a physical element PI provided with a sensor C1 and an actuator A1.
  • PI is for example a retractable pad that can take two states. distinct, namely a high state and a low state, APP1 a security application and APP2 an access control application.
  • the APP1 and APP2 applications are in accordance with the invention.
  • These are computer programs readable by the processors of the devices on which they are installed, in accordance with the invention.
  • Each of these computer programs defines functional modules (and software here), configured to implement the steps of the control method according to the invention.
  • These functional modules include here, as illustrated in FIG. 3, a first sending module 10A, a receiving module 10B and a second sending module 10C the configuration of which is detailed further below, with reference to FIG. and the different steps of the control method implemented by APP1 and APP2 applications.
  • FIG. 4 illustrates the main steps of a management method, a processing method and a control method as implemented, respectively, in the first embodiment, by the platform 3, controllable entity EC1 representing the physical element PI and the APP1 and APP2 applications.
  • the controllable entity EC1 reflects the current state of the physical element PI, and can take a finite number of states, namely, in the example of the retractable stud mentioned previously, a high state and a low state.
  • the controllable entity also describes the possible transactions between these states and the events at the origin of these transitions. It is also associated with a single lock Vel control of a change of state of the physical element Pl. Because of its uniqueness, this lock can be assigned at any given time to a single application .
  • the application APP1 wishes to obtain a change of state of the physical element PI (for example if it is in a high initial INIT state, it goes into a low TARG target state).
  • the application APP1 must obtain the control lock Vel associated with the controllable entity EC1 representing the physical element P1.
  • the application APP1 sends, via its first sending module 10A, and through the management platform 3, a request for obtaining REQ-OBT (Vel) of the control lock Vel of the controllable entity EC1 representing the physical element PI (step E10).
  • REQ-OBT REQ-OBT
  • controllable entity EC1 On receipt of this request for obtaining REQ-OBT (Vel), the controllable entity EC1, via its first verification module 9A, checks the allocation status of the control lock Vel (step E20).
  • controllable entity EC1 determines that the control lock Vel has already been assigned (assignment status to the value 1 with the conventions described above), it rejects, via its processing module 9B, the request for obtaining APPl application. This rejection is notified via platform 3 to the application APP1.
  • the application APP1 sees its request for obtaining rejected, it is his responsibility here to re-request the control lock of the physical element P1, for example after the expiry of a predetermined period of time, which may depend on constraints of the application (control needed immediately or can be postponed later).
  • control lock Vel is in an unassigned state (that is, at the value 0 according to the conventions adopted here).
  • the controllable entity EC1 then assigns, via its processing module 9B, the control lock Vel to the application APP1 (step E30).
  • the control lock Vel allocated to the application APP1 is managed via a token, or token in English, that is to say a unique identifier. More precisely, when the controllable entity EC1 assigns the control lock Vel to the application APP1, it generates a TOK1 token for the application APP1.
  • This token here has a predetermined validity period, preferentially set so as to be greater than or equal to a time necessary for the physical element PI to perform its longest change of state.
  • the TOK1 token is created by the controllable entity EC1 when the lock Vel is assigned to the application APP1 and is destroyed when its validity period has expired.
  • Destroying the TOK1 token causes the Vel lock to be released automatically, that is, the Velkey returns to an unassigned state (ie 0).
  • the token TOK1 is stored in the controllable entity EC1 in association with the state of the lock Vel (note that its only storage may be sufficient to reflect the state of allocation of the lock). It allows the controllable entity EC1 to identify an application holding the lock Vel. It is therefore in itself a proof of possession of the control lock within the meaning of the invention.
  • Token TOK1 is then provided by the control entity via platform 3 to the application
  • the application APP1 Upon receipt of this TOK1 token via its receiving module 10B, the application APP1 stores the TOK1 token (step E50).
  • a change of state request REQ-CHG (TARG, TOK1) of the physical element PI (step E60).
  • the controllable entity EC1 checks, via its second verification module 9C, whether the application APP1 originating the request REQ-CHG holds the control lock Vel (step E70). More particularly here, the controllable entity EC1 checks whether the request REQ-CHG contains the token TOK1.
  • the controllable entity EC1 rejects the request for change of state of the application APP1, indicating that it must provide a valid token. The controllable entity EC1 does not send any command to the physical element P1, which therefore remains in the same state.
  • the controllable entity EC1 reflects the new current low state of the physical element PI (step E100). It notifies the APPl application of the success of the change of state (step E110).
  • the application APP1 can ask the controllable entity EC1 for further state changes of the physical element P1. It should be noted that the preferential choice previously proposed for this period of validity ensures that the APP1 application can control at least one state change of the physical element P1. This first embodiment thus prevents any risk of conflict between two competing applications wishing to control the same physical element. Indeed, if following the allocation step of the lock Vel APPl application APP2 sends a change of state request of the physical element PI to the controllable entity EC1, this request will be seen rejected because it does not contain the TOK1 token.
  • the Vel control lock (and the token for managing it at the application level) being unique, two applications APP1 and APP2 can not simultaneously hold this lock and therefore can not simultaneously control the same physical element.
  • the APP1 and APP2 applications remain free to interrogate the controllable entity EC1 in order to know the current state of the physical element PI that they hold or not the control lock. Vel. They can be informed in the response which is made to them of this current state of the physical element PI, of the state of allocation of the lock Vel.
  • each application controls a single physical element.
  • each application is able to control in a global and coordinated manner several physical elements of the physical system 2.
  • FIG. 5 illustrates an exemplary configuration of the cyber-physical system 1 in the second embodiment.
  • APP1 and APP2 capable of controlling (controlling) the physical elements ⁇ ,,, ⁇ of the physical system 2.
  • Each physical element Pn is provided with a sensor Cn and an actuator An.
  • the elements Pn are, for example, traffic lights, and the APP1 and APP2 applications of the traffic control and fluidification applications of the latter.
  • the platform 3 allows the application that requires it (for example the APP1 application) to make a global change of state request for several physical elements of the system 2 (it is assumed here that the set of physical elements ⁇ ,.,. ⁇ are concerned). It manages in a coordinated way the changes required by the application for each of the physical elements, on behalf of the application, by dynamically instantiating via a 3D processing module the global application request provided for this purpose.
  • COORD software coordination module (or coordinator). This coordinator acts as an application representative to controllable entities EC1, ..., ECN respectively representing the physical elements ⁇ ,.,., ⁇ to obtain the state change control locks of these elements.
  • FIG. 6 illustrates the main steps of a management method and a coordination method as implemented respectively in this second embodiment by the platform 3 and by the 3D coordination module instantiated by platform 3 to process the request of APPl application.
  • the application APP1 wishes to obtain a change of state of the plurality of physical elements ⁇ ,.,., ⁇ .
  • the application APP1 sends to the management platform 3, a change of state request REQ-CHG physical elements ⁇ ,.,., ⁇ (step F10).
  • the position of the pairs in the REQ-CHG query is irrelevant. This request therefore requires the execution of a finite sequence of state changes, a single change of state being associated with a controllable entity.
  • the 3D processing module of the platform 3 Upon receipt of the REQ-CHG request, the 3D processing module of the platform 3 dynamically instantiates a coordination module or coordinator COORD, according to the invention and as described above (step F20).
  • a so-called enrollment phase begins. More specifically, the COORD coordinator sends during this phase, to each controllable entity ECn identified in the change request REQ-CHG, an interrogation request Rn and here arms a timer tn for a predetermined period of time (step F40). This period is chosen, typically by the operator of the management platform 3, as a function of the network latency that may exist between the coordinator and the controllable controllable entities.
  • Each request Rn queries the controllable entity ECn to which it is sent to find out whether the physical element Pn it represents is able to reach the target state TARGn given its current state.
  • This interrogation request aims on the one hand to know if the required change of state of the physical element Pn to the state TARGn is possible (materially speaking), but also to obtain the control lock Ven of the entity controllable ECn. It is therefore a request to obtain the lock Ven in the sense of the invention.
  • the coordinator COORD If no response is received from a controllable entity ECn at the end of the predetermined period, the coordinator COORD considers here that the response of the controllable entity ECn is negative.
  • each controllable entity ECn Upon receipt of the request Rn, each controllable entity ECn checks, via its first verification module 9A, on the one hand whether the physical element Pn can reach the state TARGn (from the current state of the physical element Pn and possible transitions / allowed between states), and secondly, what is the state of allocation of the latch Ven associated with it (step F50).
  • controllable entity ECn determines that the physical element Pn can not reach the target state TARGn or that the control lock Ven is already allocated (allocation status to the value 1 with the conventions described previously), it sends through its processing module 9B, a negative response to the COORD coordinator.
  • control lock Ven determines that the control lock Ven is not assigned (assignment status to 0 with the conventions described above), it allocates, via its processing module 9B, the lock Ven at coordinator and sends a positive response to the COORD coordinator.
  • the identifier CID of the coordinator COORD is also stored by the controllable entity ECn in association with the lock Ven, meaning that the lock Ven is assigned to the coordinator COORD. In other words, the identifier CID thus becomes a proof of holding the lock Ven by the coordinator COORD.
  • a controllable entity ECn responds positively to the coordinator's query Rn, this means that the physical element Pn can reach the state TARGn required by the application APP1 and that the lock Ven is allocated to the coordinator COORD. .
  • each of the controllable entities ECn, n 1,..., N responds positively to the coordinator (step F60). This closes the enrollment phase. This terminates successfully when all the ECn entities have responded positively to the coordinator, that is, when the COORD coordinator has obtained the control lock Ven from each of the controllable entities ECn (step F70).
  • the enrollment phase fails as soon as at least one controllable entity ECn responds negatively to the COORD coordinator.
  • the coordinator COORD then notifies the application APP1.
  • the controllable entity ECn checks, via its second verification module 9C, whether the COORD coordinator at the origin of the request holds the control lock Ven of change of state of the physical element Pn (step F90). More particularly here, the controllable entity ECn checks whether the request R'n contains the identifier CID associated with the lock Ven.
  • the controllable entity ECn rejects the execution request R'n and sends a negative response to the coordinator COORD indicating that it must provide a valid token. The controllable entity ECn then sends no command to the physical element Pn. It remains in the same INIT state as its current state.
  • each request R'n issued by the coordinator COORD contains the identifier CID, in other words a proof of the holding of the control lock Ven by the coordinator COORD (representative of the application APP1 in the sense of the 'invention). It follows an execution by the controllable entity ECn of the change of state required by the coordinator of the physical element Pn to the state TARGn. More specifically, the controllable entity ECn sends for this purpose a command to the actuator An of the physical element Pn so that it moves from its current state INITn in the state TARGn specified by the APP1 application (step F100 ).
  • the change of state is taken into account by the actuator An, so that the physical element Pn enters the state TARGn (step Fl 10).
  • the controllable entity ECn transits to the state TARGn so as to reflect the new current state of the physical element Pn (step F120).
  • Each controllable entity ECn notifies the COORD coordinator of the success of the change of state if necessary (step F130).
  • the execution phase ends successfully once all controllable entities ECn have notified the COORD coordinator of the success of the change of state of the corresponding physical element Pn.
  • the COORD coordinator sends the APP1 application status of the state change required by it (step F140).
  • the COORD coordinator via a release unit provided for this purpose, releases the control locks Ven associated with each of the controllable entities ECn (step F150). For this purpose, it sends to each of the controllable entities ECn a request for disenrollment resulting in releasing the control locks maintained by the controllable entities ECn (in other words to pass these control locks in an unassigned state).
  • This second embodiment like the first embodiment, thus prevents any risk of conflict between two competing applications wishing to control the same physical element. Indeed, if following the step of assigning the locks Vel, Ve2,..., VeN to the coordinator COORD instantiated to represent the application APP1, the application APP2 sends a request for a change of state of the physical elements ⁇ ,.,., ⁇ at platform 3, this request will be rejected because the control locks are already assigned to the COORD coordinator on behalf of the APPl application. Since these locks are unique, two APP1 and APP2 applications (or a representative of these applications) can not hold them simultaneously and therefore can not simultaneously control the same set of physical elements.
  • control module 3B and the control module 3C are distributed over the controllable entities ECn representing the physical elements Pn and on the coordinator COORD.
  • This second embodiment using a coordinator although it has been described in a context where several physical elements are controlled by the same application, can also be used in a context where an application wishes to control only a physical element.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Train Traffic Observation, Control, And Security (AREA)
  • Stored Programmes (AREA)
  • Lock And Its Accessories (AREA)

Abstract

La plate forme selon l'invention permet de gérer un système comprenant au moins un élément physique (P1,...,PN) susceptible d'être contrôlé par au moins une application (APP1,...,APPK), et comprend : ¾ un module de modélisation (3A), représentant chaque élément physique au moyen d'une entité contrôlable (ECn) reflétant un état courant de l'élément, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique; ¾ un module de gestion (3B), garantissant que le verrou de contrôle (Ven) associé à chaque entité contrôlable est attribué à un instant donné à au plus une application ou à au plus un représentant d'une application susceptible de requérir un changement d'état de l'élément physique; et ¾ un module de contrôle (3C), déclenchant un changement d'état d'au moins un élément physique du système requis par une application ou par un représentant d'une application uniquement si le verrou de contrôle associé à chaque entité contrôlable représentant un dit élément physique dont un changement d'état est requis est attribué à cette application ou à ce représentant d'une application.

Description

Plateforme et dispositif de gestion d'éléments physiques d'un système
Arrière-plan de rinvention
L'invention se rapporte au domaine général des systèmes cyber-physiques. De façon connue, un système cyber-physique est un système dans lequel des entités informatiques collaborent pour la supervision et le contrôle d'un système composé d'éléments physiques, au travers d'un réseau informatique. Il peut s'agir d'éléments physiques contrôlables directement, pourvus d'actionneurs à cette fin et le cas échéant équipés de capteurs, tels que par exemple un plot rétractable, un lampadaire d'éclairage public, un feu de circulation, etc., comme d'éléments physiques non contrôlables directement, mais contrôlables indirectement via d'autres entités contrôlables, tels qu'un segment de route (qui peut être par exemple contrôlé par le biais de plots rétractables ou de feux), etc.
L'invention concerne plus particulièrement la commande par une application logicielle d'un ou plusieurs éléments physiques contrôlables au moyen d'un actionneur.
On assiste aujourd'hui à un développement considérable des applications des systèmes cyber-physiques. Ces applications sont présentes par exemple dans les villes intelligentes par exemple pour le contrôle de l'éclairage public ou du trafic routier, le guidage des automobilistes pour trouver une place de parking, etc. La plupart de ces applications sont actuellement conçues et intégrées de manière verticale, dédiée et fermée : elles n'utilisent que les données de leurs propres capteurs et ne les partagent pas, mais les gardent pour une utilisation dédiée.
On constate toutefois une évolution vers l'utilisation de plateformes permettant de simplifier et d' « horizontaliser » la conception des systèmes cyber-physiques et de mutualiser l'utilisation des données échangées dans ces systèmes, autrement dit des données d'observation remontées des éléments physiques (mise en commun des données collectées par les capteurs équipant les éléments physiques). Ces plateformes servent d'intermédiaires entre d'une part les éléments physiques, et d'autre part, les applications commandant ces éléments physiques. De telles plateformes sont notamment proposées dans le domaine de l'Internet des Objets, comme par exemple la plateforme Xively™, dont une description est donnée notamment sur le site web https://www.xively.com ou la plateforme Predix™ dont une description est disponible sur le site web https://www.ge.com/digital/predix.
La contrepartie de la possibilité offerte par ces plateformes d'avoir une commande partagée d'éléments physiques par plusieurs applications est le risque de conflits pouvant naître lorsque différentes applications cherchent à contrôler un (ou plusieurs) même(s) élément(s) physique(s) en même temps. A titre illustratif, considérons par exemple le cas d'un plot rétractable qui reçoit deux requêtes de changement d'état RI et R2 émises respectivement par deux applications concurrentes APPl et APP2. On suppose ici que la requête RI demande au plot rétractable de s'abaisser, et a été reçue et acceptée avant l'arrivée de la requête R2, celle-ci demandant au plot rétractable de se relever. Le plot rétractable demande un certain laps de temps avant d'atteindre l'état cible qu'on lui demande. Ainsi, un conflit apparaît lorsque le plot reçoit la requête R2 alors même qu'il n'a pas encore terminé d'exécuter la requête RI et atteint son état bas. L'application APPl voit alors sa requête de changement d'état interrompue avant même d'avoir été exécutée et s'en trouve lésée.
En d'autres mots, un conflit apparaît dès lors qu'une requête de changement d'état émise par une application APP2 est acceptée par un élément physique (dans l'exemple ci-dessus, par le plot rétractable) pendant le laps de temps nécessaire à cet élément physique pour exécuter un changement d'état requis préalablement par une application APPl distincte de l'application APP2. La conséquence d'un tel conflit est l'écrasement du changement d'état en cours d'exécution (et requis par l'application APPl dans l'exemple ci-dessus) par la dernière requête de changement d'état reçue par l'élément physique (et émise par l'application APP2). L'existence d'un risque de conflit de ce type entraîne que les applications n'ont jamais la garantie que leurs requêtes de changement d'état auront l'effet escompté sur l'élément physique, quand bien même ces requêtes ont été acceptées par ce dernier.
Or, les plateformes de l'état actuel de la technique ne proposent aucune solution pour gérer un tel risque de conflit.
Objet et résumé de l'invention
L'invention remédie notamment à cet inconvénient en proposant une plateforme de gestion d'un système comprenant au moins un élément physique susceptible d'être contrôlé (i.e. commandé) par au moins une application et dont un état peut être modifié au moyen d'un actionneur, ladite plateforme de gestion comprenant :
— un module de modélisation, configuré pour représenter chaque élément physique du système au moyen d'une entité contrôlable reflétant un état courant de l'élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique ;
— un module de gestion, configuré pour garantir que le verrou de contrôle unique associé à chaque entité contrôlable est attribué à un instant donné à au plus une application ou à au plus un représentant d'une application contrôlant l'élément physique représenté par cette entité contrôlable et susceptible de requérir un changement d'état de cet élément physique ; et
— un module de contrôle, configuré pour déclencher un changement d'état d'au moins un élément physique du système requis par une application contrôlant ledit au moins un élément physique ou par un représentant d'une application contrôlant ledit au moins un élément physique uniquement si le verrou de contrôle unique associé à chaque entité contrôlable représentant un dit élément physique dont un changement d'état est requis est attribué à cette application ou à ce représentant d'une application.
Corrélativement, l'invention vise également un procédé de gestion d'un système comprenant au moins un élément physique susceptible d'être contrôlé par au moins une application et dont un état peut être modifié au moyen d'un actionneur, ledit procédé de gestion étant destiné à être mis en œuvre par une plateforme de gestion du système et comprenant :
— une étape de modélisation de chaque élément physique du système au moyen d'une entité contrôlable reflétant un état courant de l'élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique ;
— sur réception d'une requête d'obtention d'un verrou associé à une dite entité contrôlable, provenant d'une application ou d'un représentant d'une application :
· une étape de vérification d'un état d'attribution dudit verrou ;
• si ledit verrou est déjà attribué, une étape de rejet de la requête d'obtention ;
• sinon, une étape d'attribution du verrou à ladite application ou audit représentant de ladite application ;
— sur réception d'une requête de changement d'état d'au moins un élément physique du système requis par une application ou par un représentant d'une application, une étape d'exécution dudit changement d'état requis uniquement si le verrou de contrôle associé à chaque entité contrôlable représentant un dit élément physique dont un changement d'état est requis est attribué à cette application ou à ce représentant d'une application.
Ainsi, l'invention propose de gérer les risques de conflit susceptibles d'apparaître entre plusieurs applications cherchant à contrôler un (ou plusieurs) même(s) élément(s) physique(s) en même temps au moyen d'un mécanisme de verrouillage de l'élément physique permettant de garantir l'exclusion mutuelle des applications. Ce mécanisme de verrouillage est mis en œuvre par une plateforme de gestion qui joue le rôle d'intermédiaire entre les éléments physiques du système et les applications susceptibles de contrôler ces éléments physiques.
Le mécanisme de verrouillage proposé par l'invention s'appuie d'une part, sur la modélisation des éléments physiques pourvus d'actionneurs par des entités dites contrôlables reflétant l'état courant de ces éléments physiques et pouvant prendre un nombre fini d'états modélisant les états possibles des éléments physiques, et d'autre part, par la prévision pour chacune de ces entités contrôlables d'un seul et unique verrou permettant de contrôler un changement d'état de l'élément physique qu'elles représentent. Les entités contrôlables sont par exemple décrites à l'aide d'automates discrets à états finis, bien connus en soi. Ceci permet d'avoir une modélisation générique des éléments physiques. Le verrou unique associé à chaque entité contrôlable (et donc à chaque élément physique) est avantageusement binaire conformément à l'invention, autrement dit, à chaque instant :
— soit il est déjà attribué à une application (ou à un représentant d'une application) souhaitant modifier l'état d'un élément physique, auquel cas une autre application présentant une requête de changement d'état simultanément se voit rejeter sa requête, et ne peut donc demander un changement d'état de l'élément physique ;
— soit il est non attribué, auquel cas une application en faisant la requête se voit attribuer le verrou de sorte qu'elle peut ensuite demander librement un changement d'état de l'élément physique sans être en concurrence avec une autre application.
En d'autres mots, pour changer l'état d'un élément physique, une application (ou un représentant d'une telle application) doit au préalable obtenir le verrou associé à l'entité contrôlable représentant cet élément physique. Ce verrou étant unique et propre à chaque élément physique, on évite ainsi toute apparition de conflit entre les commandes de changement d'état émises par des applications concurrentes. De cette sorte, les changements d'état requis par les applications et acceptés par les éléments physiques peuvent être menés à terme.
On note que l'invention s'applique aussi bien dans un contexte où une application requiert le changement d'état d'un seul élément physique que dans un contexte où cette application requiert le changement d'état de plusieurs éléments physiques. Dans ce dernier cas de figure, le changement d'état des différents éléments physiques visés par la requête de l'application ne sera déclenché que si les verrous de tous les éléments physiques sont attribués à l'application (ou à un représentant de celle-ci).
De nombreux cas d'usage de l'invention peuvent être envisagés.
Ainsi, un premier exemple d'application de l'invention se situe dans les bâtiments intelligents. L'invention permet par exemple de gérer le contrôle de volets motorisés dans un tel bâtiment partagé entre une application de sécurité et une application de gestion d'énergie. Indépendamment des priorités qui peuvent être établies entre ces deux applications, il faut s'assurer dans un tel contexte que l'état des volets qui leur est présenté par la plateforme est cohérent et qu'il n'existe pas de conflit tel que présenté précédemment.
L'invention peut également s'appliquer au concept de villes intelligentes, par exemple pour gérer un cas de figure dans lequel des dispositifs permettant de fermer une rue (ex. barrières, plots rétractables et/ou feux) peuvent être commandés concurremment par plusieurs applications, comme notamment une application de gestion du trafic et une application de contrôle d'accès. Dans ce cas de figure, il est nécessaire de s'assurer que l'état de la rue présenté par la plateforme aux applications est cohérent et qu'une application ne tente pas d'ouvrir la rue alors qu'une autre a commencé à la fermer ce qui pourrait laisser la rue dans un état intermédiaire incohérent. L'invention permet avantageusement d'éviter une telle situation. Le mécanisme de verrouillage proposé par l'invention peut être implémenté de diverses façons. Ainsi, par exemple, dans un mode particulier de réalisation, le module de gestion est configuré pour :
— générer un jeton lorsque le verrou de contrôle associé à une entité contrôlable est attribué à une application ou à un représentant d'une application ; et
— fournir à cette application ou à ce représentant le jeton généré, ce jeton étant destiné à être présenté audit module de contrôle par ladite application ou ledit représentant pour déclencher un changement d'état de l'élément physique représenté par ladite entité contrôlable.
Un tel jeton est par exemple un identifiant unique qui permet d'identifier de manière univoque l'application ou le représentant d'une application à laquelle ou auquel a été attribué le verrou. Il peut être utilisé par conséquent comme preuve de détention du verrou par l'application ou le représentant de l'application.
On note que dans le cas où l'application requiert le changement d'état d'un seul élément physique, le jeton est fourni préférentiel lement à l'application elle-même qui l'insère ensuite dans ses requêtes de changement d'état de l'élément physique comme preuve de détention du verrou de contrôle de cet élément physique. De cette sorte, l'invention permet de respecter les principes d'une architecture REST (pour REpresentational State Transfer), couramment utilisée pour les systèmes distribués et notamment pour les systèmes distribués évolutifs (ou « scalable » en anglais). Cette architecture de type client-serveur préconise notamment que chaque requête d'un client (ici l'application) vers un serveur (ici la plateforme) doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête sans avoir à dépendre d'un contexte conservé sur le serveur (contrainte dite « sans état » ou stateless en anglais). En l'espèce ici, en fournissant à l'application le jeton lui permettant d'apporter la preuve qu'elle détient le verrou associé à un élément physique, on s'assure que c'est l'application qui stocke ce jeton, et que la plateforme de gestion n'a pas besoin de conserver ce jeton.
Dans un mode particulier de réalisation, le jeton est généré par le module de gestion pour une durée de validité prédéterminée.
Ce mode de réalisation a une application privilégiée lorsque l'application requiert le changement d'état d'un seul élément physique. On s'assure de cette sorte que l'application ne détienne le verrou de cet élément physique que pendant un certain laps de temps, après quoi il est relâché automatiquement. Cette expiration automatique du verrou au bout d'une durée de validité prédéterminée permet d'éviter que les applications ne monopolisent trop longtemps les éléments physiques.
Cette durée de validité prédéterminée est préférentiellement fixée supérieure ou égale à une durée nécessaire pour que l'élément physique représenté par l'entité contrôlable exécute son changement d'état le plus long. Elle est décomptée à partir du moment où le verrou est attribuée à l'application. Autrement dit, selon cette hypothèse, la durée de validité dépend de l'élément physique dont le verrou contrôle le changement d'état. De cette sorte, une application détentrice du verrou est assurée d'effectuer au moins un changement d'état, qui plus est le changement d'état qui requiert le plus de temps à l'élément physique. De plus, elle peut commander davantage de changements d'état si la durée de validité n'a pas expiré.
Dans un mode particulier de réalisation, la plateforme de gestion selon l'invention comprend en outre un module de traitement configuré pour, sur réception d'une requête provenant d'une application et requérant un changement des états d'une pluralité d'éléments physiques du système, instancier un module de coordination représentant ladite application, et dans laquelle ledit module de coordination instancié est configuré pour :
— requérir auprès de ladite pluralité d'entités contrôlables représentant ladite pluralité d'éléments physiques, les verrous de contrôle associés à ces entités contrôlables ;
— si tous les verrous de contrôle associés aux entités contrôlables représentant ladite pluralité d'éléments physiques sont attribués audit module de coordination, déclencher les changements d'état requis par ladite application desdits éléments physiques.
Dans ce mode de réalisation, un module de coordination est instancié dynamiquement par la plateforme de gestion dès lors que l'application requiert le changement d'état de plusieurs éléments physiques. Ce module de coordination agit comme un représentant de l'application auprès des différentes entités contrôlables représentant les éléments physiques dont un changement d'état est requis par l'application.
La coordination des multiples entités contrôlables telle que proposée par l'invention dans ce mode de réalisation permet à l'application de pouvoir effectuer une opération globale et atomique (via l'envoi d'une seule requête) conduisant au changement d'état de plusieurs éléments physiques distincts qui ne sont pas nécessairement reliés physiquement entre eux.
En outre, il convient de noter qu'une telle coordination permet de favoriser la réutilisation (i.e. le partage) des éléments physiques par les applications, celles-ci pouvant notamment aisément les utiliser grâce à l'invention en les détournant de leur but principal. Considérons par exemple à titre illustratif une application de fluidification du trafic routier. Grâce à l'invention, cette application peut requérir via une opération globale et atomique le changement d'état de deux feux de travaux disposés sur un segment de route en travaux. Le but principal de ces deux feux de travaux est d'alterner le passage des voitures sur le segment de route en travaux. Grâce à l'invention, ils peuvent également être utilisés par l'application de fluidification du trafic routier dans un but opportuniste de réguler le trafic sur l'axe routier.
Dans un mode de réalisation de l'invention, le module de coordination est configuré pour libérer les verrous de contrôle qui lui sont attribués lorsque tous les changements d'état desdits éléments physiques requis par ladite application sont terminés.
Le module de coordination assure ainsi l'atomicité de la coordination en veillant à ce que les verrous associés aux différentes entités contrôlables ne soient relâchés qu'à l'issue de la coordination, c'est-à-dire le cas échéant, du changement d'état de tous les éléments physiques visés par l'application. Ce mode de réalisation permet en outre d'éviter qu'un élément physique reste verrouillé indéfiniment après la fin de la coordination mise en œuvre par le module de coordination.
Dans un mode particulier de réalisation de l'invention, chaque entité contrôlable est interrogeable par une application pour connaître l'état courant de l'élément physique qu'elle représente que le verrou de contrôle associé à cette entité contrôlable soit attribué ou non à cette application.
Autrement dit, le mécanisme de verrouillage proposé par l'invention n'est appliqué que pour les changements d'état des éléments physiques. Il n'empêche pas la consultation par des applications concurrentes de ces éléments physiques en vue de connaître leurs états courants.
Il apparaît au vu de ce qui précède que l'invention s'appuie non seulement sur une plateforme de gestion intermédiaire entre les applications et les éléments physiques, mais également sur des entités contrôlables reflétant les états courants des éléments physiques du système, ainsi que dans certains modes de réalisation sur les applications logicielles elles-mêmes qui sont susceptibles de commander ces éléments physiques et sur un module de coordination instancié le cas échéant par la plateforme de gestion.
Ainsi, l'invention vise également selon un deuxième aspect, une entité contrôlable reflétant un état courant d'un élément physique susceptible d'être contrôlé par au moins une application et dont un état peut être modifié au moyen d'un actionneur, ladite entité contrôlable étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, et comprenant :
— un premier module de vérification, activé sur réception d'une requête d'obtention du verrou de contrôle en provenance d'une application ou d'un représentant d'une application, ledit premier module de vérification étant configuré pour vérifier si le verrou de contrôle est déjà attribué ;
— un module de traitement de la requête d'obtention configuré pour :
o rejeter la requête d'obtention si le verrou de contrôle est déjà attribué ; et
o attribuer le verrou de contrôle à ladite application ou audit représentant d'une application sinon ; et
— un second module de vérification, activé sur réception d'une requête d'un changement d'état de l'élément physique en provenance d'une application ou d'une représentant d'une application, ledit second module de vérification étant configuré pour vérifier si ladite requête comprend une preuve de détention du verrou de contrôle ; et
— un module d'exécution du changement d'état requis si ladite requête comprend une preuve de détention du verrou de contrôle.
Corrélativement, l'invention vise également un procédé de traitement, destiné à être mis en œuvre par une entité contrôlable reflétant un état courant d'un élément physique susceptible d'être contrôlé par au moins une application et dont un état peut être modifié au moyen d'un actionneur, cette entité contrôlable étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, le procédé de traitement comprenant :
— une étape de vérification, déclenchée sur réception d'une requête d'obtention du verrou de contrôle en provenance d'une application ou d'un représentant d'une application, et au cours de laquelle l'entité contrôlable vérifie si le verrou de contrôle est déjà attribué ;
— une étape de traitement de la requête d'obtention du verrou comprenant :
o un rejet de la requête d'obtention du verrou si le verrou de contrôle est déjà attribué ; et
o une attribution du verrou de contrôle à ladite application ou audit représentant d'une application sinon ;
— une étape de vérification, déclenchée sur réception d'une requête d'un changement d'état de l'élément physique en provenance d'une application ou d'une représentant d'une application, et au cours de laquelle l'entité contrôlable vérifie si ladite requête de changement d'état comprend une preuve de détention du verrou de contrôle ; et
— une étape d'exécution du changement d'état requis si ladite requête de changement d'état comprend une dite preuve de détention du verrou de contrôle.
Dans un mode particulier de réalisation, le module de traitement de l'entité contrôlable est en outre configuré pour générer un jeton lorsque le verrou de contrôle est attribué à ladite application ou au représentant d'une application et pour transmettre ledit jeton comme preuve de détention du verrou de contrôle à ladite application ou audit représentant d'une application.
Selon un troisième aspect, l'invention vise également une application logicielle, susceptible de contrôler au moins un élément physique d'un système comprenant une pluralité d'éléments physiques, un état dudit élément physique pouvant être modifié au moyen d'un actionneur, ladite application logicielle comprenant :
— un premier module d'envoi, configuré pour envoyer à une entité contrôlable reflétant un état courant dudit élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, une requête d'obtention dudit verrou de contrôle ;
— un module de réception, activé si ledit verrou de contrôle est attribué à ladite application logicielle, et apte à recevoir une preuve de détention dudit verrou de contrôle ; et
— un second module d'envoi, configuré pour envoyer à ladite entité contrôlable une requête de changement d'état de l'élément physique, ladite requête comprenant ladite preuve de détention du verrou de contrôle.
Corrélativement, l'invention vise aussi un procédé de contrôle d'au moins un élément physique d'un système comprenant une pluralité d'éléments physiques, un état dudit élément physique pouvant être modifié au moyen d'un actionneur, ledit procédé de contrôle étant destiné à être mis en œuvre par une application logicielle et comprenant : — une étape d'envoi, à une entité contrôlable reflétant un état courant dudit élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, d'une requête d'obtention dudit verrou de contrôle ;
— une étape de réception, déclenchée si ledit verrou de contrôle est attribué à ladite application logicielle, comprenant la réception d'une preuve de détention dudit verrou de contrôle ; et
— une étape d'envoi à ladite entité contrôlable d'une requête de changement d'état de l'élément physique, cette requête comprenant ladite preuve de détention du verrou de contrôle.
Selon un quatrième aspect, l'invention vise également un dispositif comprenant une application logicielle selon l'invention.
Aucune limitation n'est attachée à la nature de ce dispositif. Il peut s'agir d'un terminal d'utilisateur tel que par exemple un téléphone portable ou un téléphone intelligent (« smartphone » en anglais), une tablette électronique, un ordinateur fixe ou portable, ou un dispositif dans un réseau tel que par exemple un serveur ou une passerelle de service (ex. une passerelle domestique ADSL aussi plus communément appelée « box ADSL», une passerelle domotique, une passerelle immotique, etc.).
Selon un cinquième aspect, l'invention vise un module de coordination instancié par une plateforme de gestion d'un système comprenant des éléments physiques dont un état peut être modifié au moyen d'un actionneur, ledit module de coordination étant instancié sur réception par ladite plateforme d'une requête de changement des états d'une pluralité d'éléments physiques du système provenant d'une application, chaque élément physique étant représenté au niveau de la plateforme de gestion par une entité contrôlable reflétant un état courant de cet élément physique et pouvant prendre un nombre fini d'états, ladite entité contrôlable étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique qu'elle modélise, ledit module de coordination comprenant :
— une première unité d'envoi, configurée pour envoyer à chaque entité contrôlable représentant un élément physique de ladite pluralité d'éléments physiques une requête d'obtention du verrou de contrôle associée à cette entité contrôlable ;
— une deuxième unité d'envoi, activée si tous les verrous de contrôle associés aux entités contrôlables représentant ladite pluralité d'éléments physiques sont attribués au module de coordination, et configurée pour envoyer à chaque entité contrôlable une requête de changement d'état de l'élément physique qu'elle représente conformément à l'état requis dans la requête provenant de ladite application, ladite requête de changement d'état de l'élément physique comprenant une preuve de détention du verrou de contrôle associé à l'entité contrôlable ; et
— une unité de libération des verrous de contrôle attribués au module de coordination activé lorsque tous les changements d'état de ladite pluralité d'éléments physiques requis par ladite application sont terminés ou à l'issue d'une période de temps prédéterminée. Corrélativement, l'invention concerne également un procédé de coordination destiné à être mis en œuvre par un module de coordination instancié par une plateforme de gestion d'un système comprenant des éléments physiques dont un état peut être modifié au moyen d'un actionneur, ce module de coordination étant instancié sur réception par ladite plateforme d'une requête de changement des états d'une pluralité d'éléments physiques du système provenant d'une application, chaque élément physique étant représenté au niveau de la plateforme de gestion par une entité contrôlable reflétant un état courant de cet élément physique et pouvant prendre un nombre fini d'états, cette entité contrôlable étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique qu'elle modélise. Conformément à l'invention, le procédé de coordination comprend :
— une première étape d'envoi, à chaque entité contrôlable représentant un élément physique de ladite pluralité d'éléments physiques, une requête d'obtention du verrou de contrôle associée à cette entité contrôlable ;
— une deuxième étape d'envoi, déclenchée si tous les verrous de contrôle associés aux entités contrôlables représentant ladite pluralité d'éléments physiques sont attribués au module de coordination, ladite deuxième étape d'envoi comprenant l'envoi à chaque entité contrôlable d'une requête de changement d'état de l'élément physique qu'elle représente conformément à l'état requis dans la requête provenant de ladite application, ladite requête de changement d'état de l'élément physique comprenant une preuve de détention du verrou de contrôle associé à l'entité contrôlable ; et
— une étape de libération des verrous de contrôle attribués au module de coordination déclenchée lorsque tous les changements d'état de ladite pluralité d'éléments physiques requis par ladite application sont terminés ou à l'issue d'une période prédéterminée.
L'entité contrôlable, le procédé de traitement, l'application logicielle, le procédé de contrôle, le module de coordination et le procédé de coordination bénéficient des mêmes avantages décrits précédemment que la plateforme de gestion et le procédé de gestion.
Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion, du procédé de traitement, du procédé de contrôle et/ou du procédé de coordination sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de de gestion, d'un procédé de traitement, d'un procédé de contrôle ou d'un procédé de coordination tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus.
Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, ou une EEPROM ou FlashRAM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore un moyen d'enregistrement FlashRAM (SSD, carte SD, etc.).
D'autre part, le support d'informations ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise également selon un autre aspect encore un système cyber-physique comprenant :
— un système physique comprenant une pluralité d'éléments physiques ;
— une pluralité d'applications susceptibles de contrôler lesdits éléments physiques ; et — une plateforme de gestion du système comprenant ladite pluralité d'éléments physiques conforme à l'invention.
On peut également envisager, dans d'autres modes de réalisation, que la plateforme de gestion, l'entité contrôlable, l'application logicielle, le module de coordination, le système cyber- physique, le procédé de gestion, le procédé de traitement, le procédé de contrôle, et le procédé de coordination selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— la figure 1 représente, de façon schématique, un système cyber-physique conforme à l'invention et comprenant une plateforme de gestion selon l'invention ;
— la figure 2 représente un exemple d'architecture matérielle de la plateforme de gestion de la figure 1 ;
— la figure 3 représente un exemple de configuration du système cyber-physique de la figure 1 dans un premier mode de réalisation ; — la figure 4 représente les principales étapes d'un procédé de gestion, d'un procédé de traitement et d'un procédé de contrôle telles qu'elles sont mises en œuvre par la plateforme de gestion, par les applications et par les entités contrôlables du système cyber-physique de la figure 1 lorsqu'il se trouve dans la configuration illustrée à la figure 3 ;
— la figure 5 représente un exemple de configuration du système cyber-physique de la figure 1 dans un deuxième mode de réalisation ; et
— la figure 6 représente les principales étapes d'un procédé de gestion, et d'un procédé de coordination telles qu'elles sont mises en œuvre par la plateforme de gestion et par un coordinateur du système cyber-physique de la figure 1 lorsqu'il se trouve dans la configuration illustrée à la figure 5.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système cyber-physique 1 conforme à l'invention, dans un mode particulier de réalisation.
Le système cyber-physique 1 comprend :
— un système physique 2 comportant une pluralité d'éléments physiques PI, P2,..., PN, N désignant un entier quelconque supérieur à 1 ;
— une pluralité d'applications logicielles APP1, APP2,..., APPK, K désignant un entier quelconque supérieur à 1, ces applications étant susceptibles de superviser et de contrôler (c'est-à-dire de commander) tout ou partie des éléments physiques PI, P2...,PN ; et
— une plateforme de gestion 3 du système 2 conforme à l'invention.
Aucune limitation n'est attachée à la nature des éléments physiques PI, P2,..., PN du système 2. Il peut s'agir par exemple de plots rétractables, de feux de trafic, de barrières, de volets électriques, etc. On suppose toutefois ici que ces éléments sont pourvus de capteurs et d'actionneurs Cl/Al, C2/A2,..., CN/AN, les actionneurs permettant de modifier un état des éléments physiques PI, P2,...,PN correspondant, sous le contrôle des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΚ.
En variante, tout ou partie des éléments physiques ΡΙ,.,.,ΡΝ ne sont pourvus que d'actionneurs et ne sont pas équipés de capteurs.
On note que les éléments physiques ΡΙ,.,.,ΡΝ peuvent être en interaction les uns avec les autres, et organisés selon différents niveaux hiérarchiques. Par ailleurs, le système physique 2 peut comporter également des éléments physiques non contrôlables directement par le biais d'actionneurs, mais par l'intermédiaire des éléments physiques contrôlables ΡΙ,.,.,ΡΝ. Un tel élément non contrôlable directement est par exemple un segment de route, sur lequel on peut agir indirectement par le biais de feux tricolores ou de barrières contrôlables directement au moyen d'actionneurs. De même, aucune limitation n'est attachée à la nature des applications logicielles APP1, APP2,..., APPK (ex. applications de sécurité, de fluidification du trafic, de contrôle d'accès, etc.). Elles dépendent bien entendu de la nature des éléments physiques ΡΙ,.,.,ΡΝ, et du contexte de mise en œuvre de l'invention. Ces applications logicielles peuvent être localisées dans tout type de dispositifs comme dans un terminal, tel que par exemple un terminal d'utilisateur comme une tablette électronique, un téléphone intelligent, un ordinateur, ou être hébergées dans un équipement d'un réseau, tel qu'un serveur ou une passerelle de service par exemple, ou encore être co-hébergées sur la plateforme de gestion 3 elle-même.
La plateforme de gestion 3 joue ici un rôle d'intermédiaire entre les applications ΑΡΡΙ,.,.,ΑΡΡΚ d'une part et les éléments physiques P1,P2,...,PN d'autre part. La plateforme de gestion 3 mutualise les données des capteurs et les accès aux actionneurs C1/A1,...,CN/AN. Elle communique avec les uns et les autres par exemple via un ou plusieurs réseaux de télécommunications, connu(s) en soi. Aucune limitation n'est attachée à la nature de ces réseaux. Mais on suppose ici que les délais de communication (latences) entre la plateforme, les applications, et les actionneurs sont maîtrisés.
Dans le mode de réalisation décrit ici, la plateforme de gestion 3 a l'architecture matérielle d'un ordinateur, telle qu'illustrée à la figure 2.
Elle comprend notamment un processeur 4, une mémoire vive 5, une mémoire morte 6, une mémoire flash non volatile 7 ainsi que des moyens de communication 8 lui permettant de communiquer notamment d'une part avec les capteurs/actionneurs Cn/An des éléments physiques Pn, n=l,...,N, et d'autre part avec les applications ΑΡΡΙ,.,.,ΑΡΡΝ. Ces moyens de communication 8 sont connus en soi et dépendent des interfaces existant entre la plateforme de gestion 3, les capteurs/actionneurs et les applications.
La mémoire morte 6 de la plateforme de gestion 3 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 4 et sur lequel est enregistré ici un programme d'ordinateur PROG conforme à l'invention.
Le programme d'ordinateur PROG définit des modules fonctionnels (et logiciels ici), configurés pour mettre en œuvre les étapes du procédé de gestion selon l'invention. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 4-8 de la plateforme de gestion cités précédemment. Ils comprennent notamment ici, comme illustré sur la figure 1 :
— un module de modélisation 3A, configuré pour représenter chaque élément physique Pn du système physique 2 au moyen d'une entité contrôlable, notée ECn. Cette entité contrôlable est un modèle exécutable pouvant prendre un nombre fini d'états (selon un fonctionnement à temps discret) et constituant une abstraction de l'élément physique Pn qu'elle représente : elle reflète un état courant de l'élément physique Pn ainsi que les transitions possibles entre tous les états de l'élément physique Pn. Par exemple pour un feu tricolore, l'entité contrôlable correspondante représente l'état du feu (rouge, vert, ou orange), et les transitions possibles entre chaque état du feu (vert vers orange, orange vers rouge, rouge vers vert). Chaque entité contrôlable ECn est décrite par exemple ici au moyen d'un automate, tel qu'un automate de Mealy connu en soi et non décrit en détail ici ;
— un module de gestion 3B, configuré pour garantir que le verrou de contrôle unique Ven associé à chaque entité contrôlable ECn, n=l,...,N est attribué à un instant donné à au plus une application APPk, k=l,...,K ou à au plus un représentant d'une application APPk contrôlant l'élément physique Pn représenté par cette entité contrôlable et susceptible de requérir un changement d'état de cet élément physique ; et
— un module de contrôle 3C, configuré pour déclencher un changement d'état d'au moins un élément physique Pn du système physique 2 requis par une application APPk, k=l,..,K uniquement si le verrou de contrôle unique Ven associé à chacune des entités contrôlables représentant ce ou ces éléments physiques pour lesquels un changement d'état est requis est attribué à cette application ou à un représentant de cette application.
Les fonctions de ces différents modules sont décrites plus en détail ultérieurement. On note que, suivant l'architecture d'implémentation retenue pour la plateforme de gestion 3, les modules fonctionnels précités peuvent être répartis sur un ou plusieurs serveurs et ne se trouvent pas nécessairement localisés sur un unique dispositif matériel.
Conformément à l'invention, chaque entité contrôlable ECn représentant un élément physique Pn du système physique 2, n= l,...,N est associée à un seul et unique verrou de contrôle Ven de changement d'état de l'élément physique Pn. Ce verrou est par exemple ici une variable logicielle binaire maintenue par l'entité contrôlable ECn, et dont la valeur dépend de l'état d'attribution du verrou : ainsi, le verrou prend une première valeur (ex. 1) si il est à l'instant considéré (instant dit courant) attribué à une application, et une seconde valeur (ex. 0) distincte de la première valeur, s'il n'est attribué à aucune application. Conformément à l'invention, l'attribution par l'entité logicielle ECn du verrou Ven à une application ou à un représentant d'une application permet à celle-ci ou à celui-ci de requérir (et de voir exécuter) un changement d'état de l'élément physique Pn. Une application ne disposant pas de ce verrou se voit refuser sa requête de changement d'état. Ainsi, pour assurer une telle gestion du verrou Ven qui lui est associé, chaque entité contrôlable ECn comprend divers modules logiciels, à savoir :
— un premier module de vérification 9A, activé sur réception d'une requête d'obtention du verrou de contrôle Ven en provenance d'une application ou d'un représentant d'une application, ce premier module de vérification 9A étant configuré pour vérifier si le verrou de contrôle Ven est déjà attribué ;
— un module de traitement 9B de la requête d'obtention du verrou configuré pour :
o rejeter la requête d'obtention si le verrou de contrôle Ven est déjà attribué ; et o attribuer le verrou de contrôle Ven à l'application ou au représentant de l'application sinon ;
— un second module de vérification 9C, activé sur réception d'une requête d'un changement d'état de l'élément physique Pn en provenance d'une application ou d'une représentant d'une application, ce second module de vérification 9C étant configuré pour vérifier si la requête de changement d'état comprend une preuve de détention du verrou de contrôle Ven ; et — un module d'exécution 9D du changement d'état requis si la requête de changement d'état comprend une telle preuve de détention du verrou de contrôle Ven.
Les fonctions de ces différents modules ainsi que celles des modules de la plateforme de gestion 3 sont décrites plus en détail maintenant, en référence à deux modes de réalisation distincts de l'invention.
Dans le premier mode de réalisation de l'invention, on envisage le contrôle (i.e. la commande) d'un élément physique unique parmi les éléments physiques du système physique 2. Ce premier mode de réalisation illustre comment l'invention permet d'éviter tout risque de conflit dans le contrôle de l'élément physique PI entre deux applications concurrentes.
Dans le second mode de réalisation de l'invention, on envisage le contrôle (i.e. la commande) coordonné de plusieurs éléments physiques du système physique 2. Premier mode de réalisation de l'invention
La figure 3 illustre un exemple de configuration du système cyber-physique 1 dans le premier mode de réalisation. On considère dans cet exemple deux applications logicielles concurrentes APP1 et APP2 susceptibles de contrôler (commander) un élément physique PI pourvu d'un capteur Cl et d'un actionneur Al. A titre illustratif, PI est par exemple un plot rétractable pouvant prendre deux états distincts, à savoir un état haut et un état bas, APP1 une application de sécurité et APP2 une application de contrôle d'accès.
Dans le premier mode de réalisation décrit ici, les applications APP1 et APP2 sont conformes à l'invention. Il s'agit de programmes d'ordinateurs lisibles par les processeurs des dispositifs sur lesquels elles sont installées, conformes à l'invention. Chacun de ces programmes d'ordinateur définit des modules fonctionnels (et logiciels ici), configurés pour mettre en œuvre les étapes du procédé de contrôle selon l'invention. Ces modules fonctionnels comprennent notamment ici, comme illustré sur la figure 3 un premier module d'envoi 10A, un module de réception 10B et un second module d'envoi 10C dont la configuration est détaillée davantage ci- après, en référence à la figure 4 et aux différentes étapes du procédé de contrôle mises en œuvre par les applications APP1 et APP2.
La figure 4 illustre les principales étapes d'un procédé de gestion, d'un procédé de traitement et d'un procédé de contrôle telles qu'elles sont mises en œuvre respectivement, dans le premier mode de réalisation, par la plateforme 3, l'entité contrôlable EC1 représentant l'élément physique PI et les applications APP1 et APP2.
On suppose que lors d'une étape préalable de configuration de la plateforme 3, une modélisation de l'élément physique PI au moyen d'une entité contrôlable EC1 telle que décrite précédemment a été réalisée. L'entité contrôlable EC1 reflète l'état courant de l'élément physique PI, et peut prendre un nombre fini d'états, à savoir, dans l'exemple du plot rétractable mentionné précédemment, un état haut et un état bas. L'entité contrôlable décrit également les transactions possibles entre ces états et les événements à l'origine de ces transitions. Elle est par ailleurs associée à un seul et unique verrou Vel de contrôle d'un changement d'état de l'élément physique Pl. Du fait de son unicité, ce verrou ne peut être attribué à un instant donné qu'à une unique application.
On suppose ici que l'application APPl souhaite obtenir un changement d'état de l'élément physique PI (par exemple si celui-ci est à dans un état initial INIT haut, qu'il passe dans un état cible TARG bas). A cet effet, conformément à l'invention, l'application APPl doit obtenir le verrou de contrôle Vel associé à l'entité contrôlable ECl représentant l'élément physique Pl .
Pour ce faire, l'application APPl envoie, via son premier module d'envoi 10A, et par l'intermédiaire de la plateforme 3 de gestion, une requête d'obtention REQ-OBT(Vel) du verrou de contrôle Vel de l'entité contrôlable ECl représentant l'élément physique PI (étape E10).
Sur réception de cette requête d'obtention REQ-OBT(Vel), l'entité contrôlable ECl, via son premier module de vérification 9A, vérifie l'état d'attribution du verrou de contrôle Vel (étape E20).
Si l'entité contrôlable ECl détermine que le verrou de contrôle Vel est déjà attribué (état d'attribution à la valeur 1 avec les conventions décrites précédemment), elle rejette par l'intermédiaire de son module de traitement 9B la requête d'obtention de l'application APPl . Ce rejet est notifié via la plateforme 3 à l'application APPl . Lorsque l'application APPl voit sa requête d'obtention rejetée, il est ici de son ressort de redemander ultérieurement le verrou de contrôle de l'élément physique PI, par exemple après l'expiration d'une période de temps prédéterminée, qui peut dépendre des contraintes de l'application (contrôle nécessaire immédiatement ou pouvant être reporté ultérieurement).
On suppose ici que le verrou de contrôle Vel est dans un état non attribué (autrement dit à la valeur 0 selon les conventions adoptées ici). L'entité contrôlable ECl attribue alors, par l'intermédiaire de son module de traitement 9B, le verrou de contrôle Vel à l'application APPl (étape E30).
Dans le premier mode de réalisation décrit ici, le verrou de contrôle Vel attribué à l'application APPl est géré via un jeton, ou token en anglais, c'est-à-dire un identifiant unique. Plus précisément, lorsque l'entité contrôlable ECl attribue le verrou de contrôle Vel à l'application APPl, elle génère un jeton TOKl pour l'application APPl. Ce jeton a ici une durée de validité prédéterminée, fixée préférentiellement de sorte à être supérieure ou égale à une durée nécessaire pour que l'élément physique PI exécute son changement d'état le plus long. Ainsi, le jeton TOKl est créé par l'entité contrôlable ECl lorsque le verrou Vel est attribué à l'application APPl et est détruit lorsque sa durée de validité est expirée. La destruction du jeton TOKl entraîne le relâchement automatique du verrou Vel, autrement dit, le verrou Vel repasse dans un état non attribué (i.e. à la valeur 0). Le jeton TOK1 est stocké dans l'entité contrôlable ECl en association avec l'état du verrou Vel (on note que son seul stockage peut suffire à refléter l'état d'attribution du verrou). Il permet à l'entité contrôlable ECl d'identifier une application détentrice du verrou Vel. Il s'agit donc en soi d'une preuve de détention du verrou de contrôle au sens de l'invention.
Le jeton TOK1 est alors fourni par l'entité de contrôle via la plateforme 3 à l'application
APPl en réponse à sa requête d'obtention (étape E40).
Sur réception de ce jeton TOK1 via son module de réception 10B, l'application APPl stocke le jeton TOK1 (étape E50).
Puis elle envoie à l'entité contrôlable ECl, via son second module d'envoi 10C et par l'intermédiaire de la plateforme 3, une requête de changement d'état REQ-CHG(TARG,TOKl) de l'élément physique PI (étape E60). Cette requête comprend l'état cible TARG(=bas dans l'exemple considéré ici) que l'application APPl souhaite que l'élément physique PI prenne, ainsi que le jeton TOK1 comme preuve de détention par l'application APPl du verrou de contrôle Vel.
Sur réception de la requête de changement d'état REQ-CHG, l'entité contrôlable ECl vérifie, via son second module de vérification 9C, si l'application APPl à l'origine de la requête REQ-CHG détient le verrou de contrôle Vel (étape E70). Plus particulièrement ici, l'entité contrôlable ECl vérifie si la requête REQ-CHG contient le jeton TOK1.
Si la requête REQ-CHG ne contient pas le jeton TOK1, l'entité contrôlable ECl rejette la requête de changement d'état de l'application APPl, en lui indiquant qu'elle doit fournir un jeton valide. L'entité contrôlable ECl n'envoie aucune commande à l'élément physique Pl. Celui-ci reste donc dans le même état.
Dans l'exemple illustré ici, la requête REQ-CHG contient le jeton TOK1, autrement dit une preuve de la détention du verrou de contrôle Vel par l'application APPl. Il s'ensuit une exécution par l'entité contrôlable ECl du changement d'état requis par l'application APPl de l'élément physique. Plus spécifiquement, l'entité contrôlable ECl envoie une commande à l'actionneur Al de l'élément physique PI pour que celui-ci passe de son état initial INIT=haut dans l'état TARG=bas spécifié dans la requête REQ-CHG (étape E80).
Le changement d'état est pris en compte par l'actionneur AC1, de sorte que l'élément physique PI passe dans l'état TARG=bas (étape E90). Une fois ce changement d'état effectif (et remonté par exemple par le capteur Cl ou à la fin d'un délai prédéfini), l'entité contrôlable ECl reflète le nouvel état bas courant de l'élément physique PI (étape E100). Elle notifie l'application APPl du succès du changement d'état (étape E110).
Tant que la durée de validité du jeton TOK1 n'a pas expiré, l'application APPl peut demander à l'entité contrôlable ECl d'autres changements d'état de l'élément physique Pl. On note que le choix préférentiel proposé précédemment pour cette durée de validité assure à l'application APPl de pouvoir commander au moins un changement d'état de l'élément physique Pl. Ce premier mode de réalisation empêche donc tout risque de conflit entre deux applications concurrentes souhaitant commander un même élément physique. En effet, si suite à l'étape d'attribution du verrou Vel à l'application APPl, l'application APP2 envoie une requête de changement d'état de l'élément physique PI à l'entité contrôlable EC1, cette requête se verra rejetée car elle ne contient pas le jeton TOK1. Le verrou de contrôle Vel (et le jeton permettant de le gérer au niveau de l'application) étant unique, deux applications APPl et APP2 ne peuvent détenir simultanément ce verrou et donc ne peuvent commander simultanément un même élément physique. On note toutefois que dans le premier mode de réalisation décrit ici, les applications APPl et APP2 restent libres d'interroger l'entité contrôlable EC1 pour connaître l'état courant de l'élément physique PI qu'elles détiennent ou non le verrou de contrôle Vel. Elles peuvent être informées dans la réponse qui leur est faite de cet état courant de l'élément physique PI, de l'état d'attribution du verrou Vel.
On note par ailleurs que dans ce premier mode de réalisation, le module de gestion 3B et le module de contrôle 3C sont intégrés dans l'entité contrôlable EC1 représentant l'élément physique Pl. Autrement dit, chaque entité contrôlable représentant un élément physique Pn, n=l,...,N du système physique 2 comprend son propre module de gestion 3B et son propre module de contrôle 3C.
Dans le premier mode de réalisation qui vient d'être décrit, chaque application contrôle un unique élément physique. Nous allons maintenant envisager un deuxième mode de réalisation dans lequel chaque application est susceptible de contrôler de manière globale et coordonnée plusieurs éléments physiques du système physique 2.
Deuxième mode de réalisation
La figure 5 illustre un exemple de configuration du système cyber-physique 1 dans le deuxième mode de réalisation. On considère dans cet exemple deux applications logicielles concurrentes APPl et APP2 susceptibles de contrôler (commander) les éléments physiques ΡΙ,.,.ΡΝ du système physique 2. Chaque élément physique Pn est pourvu d'un capteur Cn et d'un actionneur An. A titre illustratif, les éléments Pn sont par exemple des feux de circulation, et les applications APPl et APP2 des applications de contrôle du trafic routier et de fluidification de ce dernier.
Dans le deuxième mode de réalisation décrit ici, la plateforme 3 permet à l'application qui le requiert (par exemple l'application APPl), d'effectuer une requête globale de changement d'état pour plusieurs éléments physiques du système 2 (on suppose ici que l'ensemble des éléments physiques ΡΙ,.,.ΡΝ sont concernés). Elle gère de façon coordonnée les changements requis par l'application pour chacun des éléments physiques, pour le compte de l'application, en instanciant dynamiquement, via un module de traitement 3D de la requête globale de l'application prévu à cet effet, un module de coordination logiciel COORD (ou coordinateur). Ce coordinateur agit comme un représentant de l'application auprès des entités contrôlables EC1,..., ECN représentant respectivement les éléments physiques ΡΙ,.,.,ΡΝ pour obtenir les verrous de contrôle de changement d'état de ces éléments. Et conformément à l'invention, ce n'est qu'à l'unique condition d'avoir obtenu ces verrous pour tous les éléments physiques concernés par la requête de changement d'état de l'application, que les changements d'état des différents éléments physiques sont déclenchés par le coordinateur. Nous allons maintenant décrire plus précisément ce mode de fonctionnement de la plateforme 3 en référence à la figure 6.
La figure 6 illustre les principales étapes d'un procédé de gestion et d'un procédé de coordination telles qu'elles sont mises en œuvre respectivement, dans ce deuxième mode de réalisation, par la plateforme 3 et par le module de coordination 3D instancié par la plateforme 3 pour traiter la requête de l'application APPl.
On suppose, comme dans le premier mode de réalisation, que lors d'une étape préalable de configuration de la plateforme 3, une modélisation de chaque élément physique Pn, n=l,...,N du système physique 2, au moyen d'une entité contrôlable ECn telle que décrite précédemment a été réalisée. L'entité contrôlable ECn, n=l,...,N reflète l'état courant de l'élément physique Pn, et peut prendre un nombre fini d'états. L'entité contrôlable décrit également les transactions possibles entre ces états et les événements à l'origine de ces transitions. Elle est par ailleurs associée à un seul et unique verrou Ven de contrôle d'un changement d'état de l'élément physique Pn. Du fait de son unicité, ce verrou ne peut être attribué à un instant donné qu'à une unique application.
On suppose ici que l'application APPl souhaite obtenir un changement d'état de la pluralité d'éléments physiques ΡΙ,.,.,ΡΝ. Chacun de ces éléments physiques Pn, n=l,...,N se trouve dans un état courant INITn. L'application APPl vise pour chacun de ces éléments physiques un état cible TARGn, n=l,...,N. A cet effet, conformément à l'invention, l'application APPl doit obtenir le verrou de contrôle Ven associé à l'entité contrôlable ECn représentant chaque élément physique Pn, n=l,...,N.
Pour ce faire, dans le deuxième mode de réalisation décrit ici, l'application APPl envoie à la plateforme 3 de gestion, une requête de changement d'état REQ-CHG des éléments physiques ΡΙ,.,.,ΡΝ (étape F10). Cette requête est transmise au module de traitement 3D de la plateforme 3. Elle comprend ici N couples (ECn,TARGn), n= l,...,N, chaque couple associant l'entité contrôlable ECn représentant l'élément physique Pn à l'état cible souhaité pour cet élément physique Pn. La position des couples dans la requête REQ-CHG est sans importance. Cette requête demande donc l'exécution d'une séquence finie de changements d'état, un seul changement d'état étant associé à une entité contrôlable.
Sur réception de la requête REQ-CHG, le module de traitement 3D de la plateforme 3 instancié dynamiquement un module de coordination ou coordinateur COORD, conforme à l'invention et tel que décrit précédemment (étape F20). Le coordinateur COORD génère alors un identifiant unique CID, destiné à être utilisé dans chacune des requêtes qu'il va envoyer aux entités contrôlables ECn, n= l,...,N comme décrit ci-après (étape F30).
Suite à la génération de cet identifiant CID, une phase dite d'enrôlement débute. Plus précisément, le coordinateur COORD envoie durant cette phase, à chaque entité contrôlable ECn identifiée dans la requête de changement REQ-CHG, une requête d'interrogation Rn et arme ici un temporisateur tn pour une période de temps prédéterminée (étape F40). Cette période est choisie, typiquement par l'opérateur de la plateforme de gestion 3, en fonction de la latence réseau qui peut exister entre le coordinateur et les entités contrôlables coordonnées.
Chaque requête Rn interroge l'entité contrôlable ECn à laquelle elle est envoyée pour savoir si l'élément physique Pn qu'elle représente est en mesure d'atteindre l'état cible TARGn compte tenu de son état courant. Cette requête d'interrogation vise d'une part à savoir si le changement d'état requis de l'élément physique Pn vers l'état TARGn est possible (matériellement parlant), mais également à obtenir le verrou de contrôle Ven de l'entité contrôlable ECn. Il s'agit donc d'une requête d'obtention du verrou Ven au sens de l'invention.
Si aucune réponse n'est reçue d'une entité contrôlable ECn à l'issue de la période prédéterminée, le coordinateur COORD considère ici que la réponse de l'entité contrôlable ECn est négative.
Sur réception de la requête Rn, chaque entité contrôlable ECn vérifie, via son premier module de vérification 9A, d'une part si l'élément physique Pn peut atteindre l'état TARGn (à partir de l'état courant de l'élément physique Pn et des transitions possibles/autorisées entre les états), et d'autre part, quel est l'état d'attribution du verrou Ven qui lui est associé (étape F50).
Si l'entité contrôlable ECn détermine que l'élément physique Pn ne peut pas atteindre l'état cible TARGn ou que le verrou de contrôle Ven est déjà attribué (état d'attribution à la valeur 1 avec les conventions décrites précédemment), elle envoie, par le biais de son module de traitement 9B, une réponse négative au coordinateur COORD.
Au contraire, si elle détermine que le verrou de contrôle Ven n'est pas attribué (état d'attribution à la valeur 0 avec les conventions décrites précédemment), elle attribue, par le biais de son module de traitement 9B, le verrou Ven au coordinateur et envoie une réponse positive au coordinateur COORD. L'identifiant CID du coordinateur COORD est par ailleurs stocké par l'entité contrôlable ECn en association avec le verrou Ven, signifiant que le verrou Ven est attribué au coordinateur COORD. Autrement dit, l'identifiant CID devient ainsi une preuve de détention du verrou Ven par le coordinateur COORD.
Si une entité contrôlable ECn répond de façon positive à la requête d'interrogation Rn du coordinateur, cela signifie donc que l'élément physique Pn peut atteindre l'état TARGn requis par l'application APP1 et que le verrou Ven est attribué au coordinateur COORD.
On suppose ici que chacune des entités contrôlables ECn, n= l,...,N répond positivement au coordinateur (étape F60). Ceci clôture la phase d'enrôlement. Celle-ci se termine avec succès lorsque toutes les entités ECn ont répondu positivement au coordinateur, autrement dit, lorsque le coordinateur COORD a obtenu le verrou de contrôle Ven de chacune des entités contrôlables ECn (étape F70).
Au contraire, la phase d'enrôlement échoue dès lors qu'au moins une entité contrôlable ECn répond négativement au coordinateur COORD. Le coordinateur COORD le notifie alors à l'application APP1.
Après le succès de la phase d'enrôlement, le coordinateur COORD débute une phase d'exécution du changement d'état global requis par l'application APP1. Il envoie à cet effet, via une deuxième unité d'envoi, une requête R'n d'exécution du changement d'état à chaque entité contrôlable ECn, n=l,...,N et arme un temporisateur t'n pour une période de temps prédéterminée (étape F80). Cette période est choisie, typiquement par l'opérateur de la plateforme de gestion 3, en fonction de la latence réseau qui peut exister entre le coordinateur et les entités contrôlables coordonnées. Chaque requête R'n contient l'identifiant CID du coordinateur.
Si l'un des temporisateurs t'n expire avant d'avoir confirmation que le changement d'état de l'élément physique Pn correspondant a bien été exécuté, la phase d'exécution échoue.
Sur réception de la requête d'exécution R'n de changement d'état, l'entité contrôlable ECn vérifie, via son second module de vérification 9C, si le coordinateur COORD à l'origine de la requête détient le verrou Ven de contrôle de changement d'état de l'élément physique Pn (étape F90). Plus particulièrement ici, l'entité contrôlable ECn vérifie si la requête R'n contient l'identifiant CID associé au verrou Ven.
Si la requête R'n ne contient pas l'identifiant CID, l'entité contrôlable ECn rejette la requête d'exécution R'n et envoie une réponse négative au coordinateur COORD en lui indiquant qu'elle doit fournir un jeton valide. L'entité contrôlable ECn n'envoie alors aucune commande à l'élément physique Pn. Celui-ci reste donc dans le même état INITn que son état courant.
Dans l'exemple illustré ici, chaque requête R'n émise par le coordinateur COORD contient l'identifiant CID, autrement dit une preuve de la détention du verrou de contrôle Ven par le coordinateur COORD (représentant de l'application APP1 au sens de l'invention). Il s'ensuit une exécution par l'entité contrôlable ECn du changement d'état requis par le coordinateur de l'élément physique Pn vers l'état TARGn. Plus spécifiquement, l'entité contrôlable ECn envoie à cet effet une commande à l'actionneur An de l'élément physique Pn pour que celui-ci passe de son état courant INITn dans l'état TARGn spécifié par l'application APP1 (étape F100).
Le changement d'état est pris en compte par l'actionneur An, de sorte que l'élément physique Pn passe dans l'état TARGn (étape Fl 10). Une fois ce changement d'état effectif (et remonté par exemple par le capteur Cn), l'entité contrôlable ECn transite vers l'état TARGn de sorte à refléter le nouvel état courant de l'élément physique Pn (étape F120). Chaque entité contrôlable ECn notifie le coordinateur COORD du succès du changement d'état le cas échéant (étape F130). La phase d'exécution s'achève avec succès dès lors que toutes les entités contrôlables ECn ont notifié le coordinateur COORD du succès du changement d'état de l'élément physique Pn correspondant.
Que la phase d'exécution ait été achevée avec succès ou non, le coordinateur COORD envoie à l'application APPl un statut du changement d'état requis par celle-ci (étape F140).
Une fois ce statut envoyé, le coordinateur COORD, via une unité de libération prévue à cet effet, libère les verrous de contrôle Ven associés à chacune des entités contrôlables ECn (étape F150). A cet effet, il envoie à chacune des entités contrôlables ECn une requête de désenrôlement ayant pour conséquence de relâcher les verrous de contrôle maintenus par les entités contrôlables ECn (autrement dit de faire passer ces verrous de contrôle dans un état non attribué).
Ceci clôture le procédé de coordination mis en œuvre par le coordinateur COORD. Ce deuxième mode de réalisation, tout comme le premier mode de réalisation, empêche donc tout risque de conflit entre deux applications concurrentes souhaitant commander un même élément physique. En effet, si suite à l'étape d'attribution des verrous Vel, Ve2,...,VeN au coordinateur COORD instancié pour représenter l'application APPl, l'application APP2 envoie une requête de changement d'état des éléments physiques ΡΙ,.,.,ΡΝ à la plateforme 3, cette requête se verra rejetée car les verrous de contrôle sont déjà attribués au coordinateur COORD pour le compte de l'application APPl. Ces verrous étant uniques, deux applications APPl et APP2 (ou un représentant de ces applications) ne peuvent les détenir simultanément et donc ne peuvent commander simultanément un même ensemble d'éléments physiques. On note toutefois que comme dans le premier mode de réalisation décrit ici, les applications APPl et APP2 restent libres d'interroger les entités contrôlables ECn, n=l,..,N pour connaître l'état courant des éléments physiques Pn qu'elles représentent, qu'elles (ou tout du moins que les coordinateurs œuvrant pour le compte de ces applications) détiennent ou non les verrous de contrôle Ven.
On note par ailleurs que dans ce deuxième mode de réalisation, le module de gestion
3B et le module de contrôle 3C sont répartis sur les entités contrôlables ECn représentant les éléments physiques Pn et sur le coordinateur COORD.
Ce deuxième mode de réalisation faisant appel à un coordinateur, bien qu'ayant été décrit dans un contexte où plusieurs éléments physiques sont contrôlés par une même application, peut également être utilisé dans un contexte où une application ne souhaite contrôler qu'un élément physique.
En outre, on peut envisager un mode de réalisation dans lequel les fonctions du module de coordination sont implémentées par chaque application elle-même.

Claims

REVENDICATIONS
1. Plateforme de gestion (3) d'un système (2) comprenant au moins un élément physique (P1,...,PN) susceptible d'être contrôlé par au moins une application (ΑΡΡΙ,.,.,ΑΡΡΚ) et dont un état peut être modifié au moyen d'un actionneur, ladite plateforme de gestion comprenant :
— un module de modélisation (3A), configuré pour représenter chaque élément physique (Pn) du système au moyen d'une entité contrôlable (ECn) reflétant un état courant de l'élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique ;
— un module de gestion (3B), configuré pour garantir que le verrou de contrôle (Ven) unique associé à chaque entité contrôlable est attribué à un instant donné à au plus une application ou à au plus un représentant d'une application contrôlant l'élément physique représenté par cette entité contrôlable et susceptible de requérir un changement d'état de cet élément physique ; et
— un module de contrôle (3C), configuré pour déclencher un changement d'état d'au moins un élément physique du système requis par une application contrôlant ledit au moins un élément physique ou par un représentant d'une application contrôlant ledit au moins un élément physique uniquement si le verrou de contrôle unique associé à chaque entité contrôlable représentant un dit élément physique dont un changement d'état est requis est attribué à cette application ou à ce représentant d'une application.
2. Plateforme selon la revendication 1 dans laquelle ledit module de gestion est configuré pour :
— générer un jeton (TOK1) lorsque le verrou de contrôle (Vel) associé à une entité contrôlable (EC1) est attribué à une application ou à un représentant d'une application ; et
— fournir à cette application ou à ce représentant le jeton généré, ce jeton étant destiné à être présenté audit module de contrôle par ladite application ou ledit représentant pour déclencher un changement d'état de l'élément physique représenté par ladite entité contrôlable.
3. Plateforme selon la revendication 2 dans laquelle le jeton est généré par le module de gestion pour une durée de validité prédéterminée.
4. Plateforme de gestion selon la revendication 3 dans laquelle la durée de validité prédéterminée du jeton généré est fixée supérieure ou égale à une durée nécessaire pour que l'élément physique représenté par ladite entité contrôlable exécute son changement d'état le plus long.
5. Plateforme de gestion selon la revendication 2 comprenant en outre un module de traitement (3D) configuré pour, sur réception d'une requête provenant d'une application et requérant un changement des états d'une pluralité d'éléments physiques du système, instancier un module de coordination (COORD) représentant ladite application, et dans laquelle ledit module de coordination instancié est configuré pour :
— requérir auprès de ladite pluralité d'entités contrôlables représentant ladite pluralité d'éléments physiques, les verrous de contrôle associés à ces entités contrôlables ;
— si tous les verrous de contrôle associés aux entités contrôlables représentant ladite pluralité d'éléments physiques sont attribués audit module de coordination, déclencher les changements d'état requis par ladite application desdits éléments physiques.
6. Plateforme de gestion selon la revendication 5 dans laquelle ledit module de coordination (COORD) est configuré pour libérer les verrous de contrôle qui lui sont attribués lorsque tous les changements d'état desdits éléments physiques requis par ladite application sont terminés.
7. Plateforme de gestion selon l'une quelconque des revendications 1 à 6 dans laquelle chaque entité contrôlable est interrogeable par une application pour connaître l'état courant de l'élément physique qu'elle représente que le verrou de contrôle associé à cette entité contrôlable soit attribué ou non à cette application.
8. Entité contrôlable (EC1,...,ECN) reflétant un état courant d'un élément physique (ΡΙ,.,.,ΡΝ) susceptible d'être contrôlé par au moins une application et dont un état peut être modifié au moyen d'un actionneur, ladite entité contrôlable étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, et comprenant :
— un premier module de vérification (9A), activé sur réception d'une requête d'obtention du verrou de contrôle en provenance d'une application ou d'un représentant d'une application, ledit premier module de vérification étant configuré pour vérifier si le verrou de contrôle est déjà attribué ;
— un module de traitement (9B) de la requête d'obtention configuré pour :
o rejeter la requête d'obtention si le verrou de contrôle est déjà attribué ; et
o attribuer le verrou de contrôle à ladite application ou audit représentant d'une application sinon ; et
— un second module de vérification (9C), activé sur réception d'une requête d'un changement d'état de l'élément physique en provenance d'une application ou d'une représentant d'une application, ledit second module de vérification étant configuré pour vérifier si ladite requête comprend une preuve de détention du verrou de contrôle ; et — un module d'exécution (9D) du changement d'état requis si ladite requête comprend une preuve de détention du verrou de contrôle.
9. Entité selon la revendication 8 dans laquelle le module de traitement est en outre configuré pour générer un jeton lorsque le verrou de contrôle est attribué à ladite application ou au représentant d'une application et pour transmettre ledit jeton comme preuve de détention du verrou de contrôle à ladite application ou audit représentant d'une application.
10. Application logicielle (APP1,APP2), susceptible de contrôler au moins un élément physique (PI) d'un système (2) comprenant une pluralité d'éléments physiques, un état dudit au moins un élément physique pouvant être modifié au moyen d'un actionneur, ladite application logicielle comprenant :
— un premier module d'envoi (10A), configuré pour envoyer à chaque entité contrôlable reflétant un état courant dudit au moins un élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, une requête d'obtention dudit verrou de contrôle ;
— un module de réception (10B), activé si ledit verrou de contrôle est attribué à ladite application logicielle, et apte à recevoir une preuve de détention dudit verrou de contrôle ; et
— un second module d'envoi (10C), configuré pour envoyer à chaque entité contrôlable une requête de changement d'état de l'élément physique, ladite requête comprenant ladite preuve de détention du verrou de contrôle.
11. Dispositif comprenant une application logicielle selon la revendication 10.
12. Module de coordination (COORD) instancié par une plateforme de gestion d'un système comprenant des éléments physiques dont un état peut être modifié au moyen d'un actionneur, ledit module de coordination étant instancié sur réception par ladite plateforme d'une requête de changement des états d'une pluralité d'éléments physiques du système provenant d'une application, chaque élément physique étant représenté au niveau de la plateforme de gestion par une entité contrôlable reflétant un état courant de cet élément physique et pouvant prendre un nombre fini d'états, ladite entité contrôlable étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique qu'elle modélise, ledit module de coordination comprenant :
— une première unité d'envoi, configurée pour envoyer à chaque entité contrôlable représentant un élément physique de ladite pluralité d'éléments physiques une requête d'obtention du verrou de contrôle associée à cette entité contrôlable ;
— une deuxième unité d'envoi, activée si tous les verrous de contrôle associés aux entités contrôlables représentant ladite pluralité d'éléments physiques sont attribués au module de coordination, et configurée pour envoyer à chaque entité contrôlable une requête de changement d'état de l'élément physique qu'elle représente conformément à l'état requis dans la requête provenant de ladite application, ladite requête de changement d'état de l'élément physique comprenant une preuve de détention du verrou de contrôle associé à l'entité contrôlable ; et
— une unité de libération des verrous de contrôle attribués au module de coordination activé lorsque tous les changements d'état de ladite pluralité d'éléments physiques requis par ladite application sont terminés ou à l'issue d'une période de temps prédéterminée.
13. Procédé de gestion d'un système comprenant au moins un élément physique
(ΡΙ,.,.,ΡΝ) susceptible d'être contrôlé par au moins une application (ΑΡΡΙ,.,.,ΑΡΡΚ) et dont un état peut être modifié au moyen d'un actionneur, ledit procédé de gestion étant destiné à être mis en œuvre par une plateforme de gestion du système et comprenant :
— une étape de modélisation de chaque élément physique du système au moyen d'une entité contrôlable reflétant un état courant de l'élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique ;
— sur réception d'une requête d'obtention (REQ-OBT,Rn) d'un verrou associé à une dite entité contrôlable, provenant d'une application ou d'un représentant d'une application :
· une étape de vérification (E20,F50) d'un état d'attribution dudit verrou ;
• si ledit verrou est déjà attribué, une étape de rejet de la requête d'obtention ;
• sinon, une étape d'attribution (E30,F60) du verrou à ladite application ou audit représentant de ladite application ;
— sur réception d'une requête (REQ-CHG) de changement d'état d'au moins un élément physique du système requis par une application ou par un représentant d'une application, une étape d'exécution (E80,F70,F90) dudit changement d'état requis uniquement si le verrou de contrôle associé à chaque entité contrôlable représentant un dit élément physique dont un changement d'état est requis est attribué à cette application ou à ce représentant d'une application.
14. Procédé de contrôle d'au moins un élément physique d'un système comprenant une pluralité d'éléments physiques, un état dudit élément physique pouvant être modifié au moyen d'un actionneur, ledit procédé de contrôle étant destiné à être mis en œuvre par une application logicielle (APP1,APP2) et comprenant :
— une étape d'envoi (E10), à une entité contrôlable reflétant un état courant dudit élément physique, cette entité contrôlable pouvant prendre un nombre fini d'états et étant associée à un verrou de contrôle unique d'un changement d'état de l'élément physique, d'une requête d'obtention dudit verrou de contrôle ; — une étape de réception (E40), déclenchée si ledit verrou de contrôle est attribué à ladite application logicielle, comprenant la réception d'une preuve de détention (TOK1) dudit verrou de contrôle ; et
— une étape d'envoi (E60) à ladite entité contrôlable d'une requête de changement d'état de l'élément physique, cette requête comprenant ladite preuve de détention du verrou de contrôle.
15. Système cyber-physique (1) comprenant :
— un système physique (2) comprenant une pluralité d'éléments physiques (P1,P2,...,PN) ;
— une pluralité d'applications (ΑΡΡΙ,.,.,ΑΡΡΚ) susceptibles de contrôler lesdits éléments physiques ; et
— une plateforme de gestion (3) du système comprenant ladite pluralité d'éléments physiques selon l'une quelconque des revendications 1 à 7.
PCT/FR2017/053667 2016-12-23 2017-12-18 Plateforme et dispositif de gestion d'éléments physiques d'un système Ceased WO2018115694A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1663365 2016-12-23
FR1663365A FR3061322B1 (fr) 2016-12-23 2016-12-23 Plateforme et dispositif de gestion d'elements physiques d'un systeme

Publications (1)

Publication Number Publication Date
WO2018115694A1 true WO2018115694A1 (fr) 2018-06-28

Family

ID=58547618

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/053667 Ceased WO2018115694A1 (fr) 2016-12-23 2017-12-18 Plateforme et dispositif de gestion d'éléments physiques d'un système

Country Status (2)

Country Link
FR (1) FR3061322B1 (fr)
WO (1) WO2018115694A1 (fr)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KLIEM ANDREAS ET AL: "The Internet of Things Resource Management Challenge", 2015 IEEE INTERNATIONAL CONFERENCE ON DATA SCIENCE AND DATA INTENSIVE SYSTEMS, IEEE, 11 December 2015 (2015-12-11), pages 483 - 490, XP032859517, DOI: 10.1109/DSDIS.2015.21 *
SUMEET GUJRATI: "MODELS AND ALGORITHMS FOR CYBER-PHYSICAL SYSTEMS", 1 January 2013 (2013-01-01), pages 1 - 139, XP055401805, Retrieved from the Internet <URL:https://krex.k-state.edu/dspace/bitstream/handle/2097/16922/SumeetGujrati2013.pdf?sequence=3> [retrieved on 20170829] *

Also Published As

Publication number Publication date
FR3061322B1 (fr) 2021-08-20
FR3061322A1 (fr) 2018-06-29

Similar Documents

Publication Publication Date Title
EP3008872B1 (fr) Procédé d&#39;authentification d&#39;un terminal par une passerelle d&#39;un réseau interne protégé par une entité de sécurisation des accès
FR2884671A1 (fr) Procede d&#39;optimisation de la gestion d&#39;un cache de serveur pouvant etre consulte par des terminaux clients de caracteristiques differentes
FR3061330A1 (fr) Systeme et procede pour la creation et la gestion d&#39;autorisations decentralisees pour des objets connectes
EP3520451B1 (fr) Attribution de profils à une pluralité de terminaux à cartes sim implantées
WO2014122099A1 (fr) Procédé pour router des données, programme d&#39;ordinateur, contrôleur de réseau et réseaux associés
FR3084181A1 (fr) Procede de coordination d&#39;une pluralite de serveurs de gestion d&#39;equipements
EP3539272A1 (fr) Procédé de gestion d&#39;autorisation dans une communauté d&#39;objets connectes
US20230015246A1 (en) Method and system for facilitating identity and access management in a cloud environment
EP3829205A1 (fr) Procédés et applications de contrôle d&#39;accès distribué à un réseau de télécommunications
EP3519958B1 (fr) Procédé d&#39;audit d&#39;une ressource virtualisée déployée dans un réseau informatique en nuage
CN110599144A (zh) 一种区块链节点的入网方法以及装置
EP4199411A1 (fr) Procédé de détermination d&#39;une autorisation de mise en uvre d&#39;une ressource composite, chaîne de blocs, dispositifs et programme correspondants
WO2018115694A1 (fr) Plateforme et dispositif de gestion d&#39;éléments physiques d&#39;un système
US11678150B2 (en) Event-based dynamic prediction in location sharing on mobile devices
EP1501241B1 (fr) Procédé d&#39;approvisionnement de règles de politique dans un réseau géré à base de règles de politique
FR3078462A1 (fr) Procede et dispositif de controle d&#39;un acces a une ressource d&#39;un systeme informatique par des applications logicielles
EP2537114B1 (fr) Procede de verrouillage/deverrouillage a distance d&#39;une machine
EP4606084A1 (fr) Procédé de traitement d&#39;une requête d&#39;exécution d&#39;un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d&#39;ordinateur correspondants
WO2017093641A1 (fr) Procédé de configuration, de contrôle ou de supervision d&#39;une installation domotique
CN116886726A (zh) 一种基于区块链系统的服务访问方法和区块链节点
FR3071630A1 (fr) Procede de gestion de modules logiciels embarques pour un calculateur electronique d&#39;un appareil electrique de coupure
EP4362391B1 (fr) Procédé de gestion d&#39;accès d&#39;un utilisateur à au moins une application, programme d&#39;ordinateur et système associés
FR3094521A1 (fr) Procédés et dispositifs permettant de prouver la connaissance d’une donnée par un utilisateur d’une chaîne de blocs
FR3060791A1 (fr) Procede et dispositif de mise a jour
US20170134302A1 (en) Construct data management between loosely coupled racks

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: 17829248

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: 17829248

Country of ref document: EP

Kind code of ref document: A1