Brevet FR3061322A1 — publié le 20180629

Arrière-plan de l'invention 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 XivelyTM, dont une description est donnée notamment sur le site web https://www.xively.com ou la plateforme PredixTM 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. 3061322 2 A titre illustratif, considérons par exemple le cas d'un plot rétractable qui reçoit deux requêtes de changement d'état R1 et R2 émises respectivement par deux applications concurrentes APP1 et APP2. On suppose ici que la requête R1 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 5 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 R1 et atteint son état bas. L'application APP1 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. 10 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 APP1 distincte de l'application APP2. La conséquence d'un tel conflit est l'écrasement du changement d'état en cours d'exécution 15 (et requis par l'application APP1 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. 20 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 25 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é 30 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 35 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 3061322 3 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. 5 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 oeuvre 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é 10 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 : 15 - 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 20 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 25 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 oeuvre 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. 30 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 35 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. 3061322 4 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 5 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 10 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 15 é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 20 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 25 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. 30 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 35 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. 3061322 5 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é à 5 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 10 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érentiellement à l'application elle-même qui l'insère 15 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 20 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 25 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 30 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 35 à 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. 3061322 6 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 5 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 10 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 15 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 20 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. 25 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 30 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é 35 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 3061322 7 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 oeuvre par le module de coordination. 5 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 10 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 15 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 20 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 25 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 30 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 35 détention du verrou de contrôle. Corrélativement, l'invention vise également un procédé de traitement, destiné à être mis en oeuvre 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 3061322 8 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 5 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 10 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 15 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 20 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 : 25 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 30 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 35 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 oeuvre par une application logicielle et comprenant : 3061322 9 - 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 ; 5 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 10 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 15 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 20 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 25 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 30 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é 35 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. 3061322 10 Corrélativement, l'invention concerne également un procédé de coordination destiné à être mis en oeuvre 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 5 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 à 10 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 15 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 20 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 25 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. 30 En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre 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. 35 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. 3061322 11 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 5 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 10 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 15 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 20 - 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 cyberphysique, le procédé de gestion, le procédé de traitement, le procédé de contrôle, et le procédé de 25 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 30 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 35 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 ; 3061322 12 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 oeuvre 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; 5 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 oeuvre 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 10 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 15 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 P1, 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 20 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 P1, 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 P1, P2,..., PN du système 2. Il peut s'agir par exemple de plots rétractables, de feux de trafic, de barrières, de 25 volets électriques, etc. On suppose toutefois ici que ces éléments sont pourvus de capteurs et d'actionneurs C1/A1, C2/A2,..., CN/AN, les actionneurs permettant de modifier un état des éléments physiques P1, P2,.. .,PN correspondant, sous le contrôle des applications logicielles APP1,...,APPK. En variante, tout ou partie des éléments physiques Pi,. ..,PN ne sont pourvus que 30 d'actionneurs et ne sont pas équipés de capteurs. On note que les éléments physiques Pi,.. .,PN 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 Pi,.. .,PN. Un tel 35 é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. 3061322 13 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 P1,...,PN, et du contexte de mise en oeuvre de l'invention. Ces applications logicielles peuvent être localisées dans tout type 5 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 10 APP1,...,APPK 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 15 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 20 communiquer notamment d'une part avec les capteurs/actionneurs Cn/An des éléments physiques Pn, n=1,...,N, et d'autre part avec les applications APP1,...,APPN. 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 25 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 oeuvre 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 30 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 35 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é 3061322 14 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=1,...,N est attribué à un instant donné à au plus une 5 application APPk, k=1,...,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=1,..,K 10 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 plateforrne de gestion 3, les 15 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=1,...,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 20 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 25 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 30 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 35 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 3061322 15 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. 5 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. 10 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 P1 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. 15 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 P1 pourvu d'un capteur Cl et d'un actionneur Al. A titre illustratif, P1 est par exemple un plot rétractable 20 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 25 d'ordinateur définit des modules fonctionnels (et logiciels ici), configurés pour mettre en oeuvre 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 oeuvre 30 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 oeuvre respectivement, dans le premier mode de réalisation, par la plateforme 3, l'entité contrôlable EC1 représentant l'élément physique P1 et les applications APP1 et APP2. 35 On suppose que lors d'une étape préalable de configuration de la plateforme 3, une modélisation de l'élément physique P1 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 Pl, et peut prendre un nombre fini d'états, à savoir, dans l'exemple du plot rétractable mentionné 3061322 16 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 5 application. On suppose ici que l'application APP1 souhaite obtenir un changement d'état de l'élément physique Pl (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 APP1 doit obtenir le verrou de contrôle Vel associé à l'entité contrôlable EC1 représentant l'élément physique Pl. 10 Pour ce faire, l'application APP1 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 EC1 représentant l'élément physique P1 (étape E10). Sur réception de cette requête d'obtention REQ-OBT(Vel), l'entité contrôlable EC1, via son premier module de vérification 9A, vérifie l'état d'attribution du verrou de contrôle Vel (étape 15 E20). Si l'entité contrôlable EC1 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 APP1. Ce rejet est notifié via la plateforme 3 à l'application APP1. Lorsque l'application APP1 voit sa requête 20 d'obtention rejetée, il est ici de son ressort de redemander ultérieurement le verrou de contrôle de l'élément physique Pl, 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 25 dit à la valeur 0 selon les conventions adoptées ici). L'entité contrôlable EC1 attribue alors, par l'intermédiaire de son module de traitement 9B, le verrou de contrôle Vel à l'application APP1 (étape E30). Dans le premier mode de réalisation décrit ici, le verrou de contrôle Vel attribué à l'application APP1 est géré via un jeton, ou token en anglais, c'est-à-dire un identifiant unique. Plus 30 précisément, lorsque l'entité contrôlable EC1 attribue le verrou de contrôle Vel à l'application APP1, elle génère un jeton TOK1 pour l'application APP1. 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 P1 exécute son changement d'état le plus long. Ainsi, le jeton TOK1 est créé par l'entité contrôlable EC1 lorsque le verrou Vel est attribué à l'application APP1 et est 35 détruit lorsque sa durée de validité est expirée. La destruction du jeton TOK1 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). 3061322 17 Le jeton TOK1 est stocké dans l'entité contrôlable EC1 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 EC1 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. 5 Le jeton TOK1 est alors fourni par l'entité de contrôle via la plateforme 3 à l'application APP1 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 APP1 stocke le jeton TOK1 (étape E50). Puis elle envoie à l'entité contrôlable EC1, via son second module d'envoi 10C et par 10 l'intermédiaire de la plateforme 3, une requête de changement d'état REQ-CHG(TARG,TOK1) de l'élément physique P1 (étape E60). Cette requête comprend l'état cible TARG(=bas dans l'exemple considéré ici) que l'application APP1 souhaite que l'élément physique P1 prenne, ainsi que le jeton TOK1 comme preuve de détention par l'application APP1 du verrou de contrôle Vel. Sur réception de la requête de changement d'état REQ-CHG, l'entité contrôlable EC1 15 vérifie, via son second module de vérification 9C, si l'application APP1 à 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 EC1 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 EC1 rejette la requête de changement d'état de l'application APP1, en lui indiquant qu'elle doit fournir un jeton 20 valide. L'entité contrôlable EC1 n'envoie aucune commande à l'élément physique P1. 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 APP1. Il s'ensuit une exécution par l'entité contrôlable EC1 du changement d'état requis par l'application APP1 de 25 l'élément physique. Plus spécifiquement, l'entité contrôlable EC1 envoie une commande à l'actionneur A1 de l'élément physique P1 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 P1 passe dans l'état TARG=bas (étape E90). Une fois ce changement d'état effectif (et 30 remonté par exemple par le capteur C1 ou à la fin d'un délai prédéfini), l'entité contrôlable EC1 reflète le nouvel état bas courant de l'élément physique P1 (étape E100). Elle notifie l'application APP1 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 APP1 peut demander à l'entité contrôlable EC1 d'autres changements d'état de l'élément physique P1. On 35 note que le choix préférentiel proposé précédemment pour cette durée de validité assure à l'application APP1 de pouvoir commander au moins un changement d'état de l'élément physique P1. 3061322 18 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 APP1, l'application APP2 envoie une requête de changement d'état de l'élément physique Pl à l'entité contrôlable EC1, cette requête se verra 5 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 APP1 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 APP1 et APP2 restent libres d'interroger l'entité contrôlable EC1 pour connaître l'état courant de 10 l'élément physique P1 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 Pl, de l'état d'attribution du verrou Vel. On note par ailleurs que dans ce premier mode de réalisation, le module de gestion 36 et le module de contrôle 3C sont intégrés dans l'entité contrôlable EC1 représentant l'élément 15 physique Pl. Autrement dit, chaque entité contrôlable représentant un élément physique Pn, n=1,...,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 20 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 25 deuxième mode de réalisation. On considère dans cet exemple deux applications logicielles concurrentes APP1 et APP2 susceptibles de contrôler (commander) les éléments physiques P1,...PN 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 APP1 et APP2 des applications de contrôle du trafic routier et de fluidification de ce 30 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 APP1), 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 P1,...PN sont concernés). Elle gère de façon coordonnée les changements 35 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 3061322 19 représentant respectivement les éléments physiques P1,...,PN 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 5 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 oeuvre 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 10 pour traiter la requête de l'application APP1. 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=1,...,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=1,...,N reflète l'état courant de l'élément 15 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 yen 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. 20 On suppose ici que l'application APP1 souhaite obtenir un changement d'état de la pluralité d'éléments physiques P1,...,PN. Chacun de ces éléments physiques Pn, n=1,...,N se trouve dans un état courant INITn. L'application APP1 vise pour chacun de ces éléments physiques un état cible TARGn, n=1,...,N. A cet effet, conformément à l'invention, l'application APP1 doit obtenir le verrou de contrôle Ven associé à l'entité contrôlable ECn représentant chaque élément physique 25 Pn, n=1,...,N. Pour ce faire, dans le deuxième mode de réalisation décrit ici, l'application APP1 envoie à la plateforme 3 de gestion, une requête de changement d'état REQ-CHG des éléments physiques P1,...,PN (étape F10). Cette requête est transmise au module de traitement 3D de la plateforme 3. Elle comprend ici N couples (ECn,TARGn), n=1,...,N, chaque couple associant l'entité contrôlable 30 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 35 instancie dynamiquement un module de coordination ou coordinateur COORD, conforme à l'invention et tel que décrit précédemment (étape F20). 3061322 20 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=1,...,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. 5 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. 10 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 15 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 20 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 25 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 30 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 35 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=1,...,N répond positivement au coordinateur (étape F60). 3061322 21 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 5 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é 10 contrôlable ECn, n=1,...,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 platefornne 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 15 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 20 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. 25 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 30 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 F110). 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 35 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). 3061322 22 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 5 envoie à l'application APP1 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 yen 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 10 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 oeuvre 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 Ve1, Ve2,...,VeN 15 au coordinateur COORD instancié pour représenter l'application APP1, l'application APP2 envoie une requête de changement d'état des éléments physiques P1,...,PN à 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 APP1. Ces verrous étant uniques, deux applications APP1 et APP2 (ou un représentant de ces applications) ne peuvent les détenir simultanément et donc ne peuvent 20 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 APP1 et APP2 restent libres d'interroger les entités contrôlables ECn, n=1,..,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 oeuvrant pour le compte de ces applications) détiennent ou non les verrous de contrôle Ven. 25 On note par ailleurs que dans ce deuxième mode de réalisation, le module de gestion 33 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, 30 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. 35 REVENDICATIONS1. 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 (APP1,...,APPK) 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 (Ve1) 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. 3061322 24 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 5 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é 10 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 15 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 20 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 (P1,...,PN) susceptible d'être contrôlé par au moins une application et dont un état peut être 25 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 30 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 35 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 3061322 25 - 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 5 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 10 physique (Pl) 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 15 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 20 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. 25 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 30 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 35 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 3061322 26 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é 5 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. 10 13. Procédé de gestion d'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 dont un état peut être modifié au moyen d'un actionneur, ledit procédé de gestion étant destiné à être mis en oeuvre 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é 15 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 : 20 - 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 25 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. 30 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 oeuvre 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 35 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 ; 3061322 27 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 5 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) ; 10 une pluralité d'applications (APP1,...,APPK) 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.