Brevet FR2882599A1 — publié le 20060901

SYSTEME DE COMMUNICATION AVEC COMPATIBILITE CROISEE ET TRAME DE COMMUNICATION ASSOCIEE L'invention concerne un système de communication permettant d'assurer une compatibilité croisée entre des produits d'une ancienne génération et des produits d'une nouvelle génération. Par compatibilité croisée, on entend une compatibilité ascendante et descendante. La compatibilité ascendante est assurée lorsque de nouveaux récepteurs acceptent et comprerment des données transmises selon un ancien protocole par d'anciens émetteurs; et la compatibilité descendante est assurée lorsque d'anciens récepteurs acceptent et comprennent des données transmises selon un nouveau protocole par de nouveaux émetteurs. La présente invention se rapporte au domaine de la commande à distance d'actionneurs et notamment à la commande sans fil d'actionneurs utilisés dans un système domotique permettant le confort et la sécurité du bâtiment, par exemple pour l'éclairage, la manoeuvre des fermetures, des protections solaires, des systèmes de ventilation et d'air conditionné, etc.... Les systèmes domotiques comportent classiquement des actionneurs avec capteurs associés formant des récepteurs d'ordres pilotés par des unités de contrôle ou points de commande formant des émetteurs d'ordres. On désignera par la suite par émetteur un organe adapté à émettre des données de commande et par récepteur un organe adapté à recevoir et interpréter des données de commande. Les récepteurs sont liés à des actionneurs, par exemple des actionneurs électromécaniques, pour transformer l'ordre reçu en action sur un élément du système domotique. La transmission de données entre l'émetteur et le récepteur se fait classiquement par un lien de type radiofréquence, bien que d'autres supports de transmission soient possibles, comme un lien infrarouge par exemple. Les émetteurs et récepteurs peuvent être nomades ou fixes et comporter une alimentation autonome, par exemple sur piles. Un récepteur fixe peut lui-même être alimenté par piles ou par l'intermédiaire de cellules photovoltaïques par exemple, s'il est relié à un actionneur autonome, ce qui évite les câblages; et la fonction réception peut être activée sur commande ou par intermittence pour limiter la consommation. Les données transmises entre un émetteur et un récepteur contiennent des informations relatives à la nature de la commande, à l'identification du récepteur et de l'émetteur et d'autres informations telles que des données relatives au cryptage, à l'historique des commandes émises et à la vérification de l'intégrité des données transmises. Les données transmises sont organisées de manière prédéterminée par un protocole. On entend par protocole un ensemble de spécifications décrivant des conventions et des règles à suivre dans un échange de données. Les protocoles servent à garantir l'efficacité dans les échanges de données. R3Brevets\23500\23527.doc - 23/02/05 - 1602 - 1/17 Certains protocoles existants utilisent des trames de longueur fixe et l'ensemble des bits de la trame est exploité. C'est le cas du protocole RTS (Radio Technology SomfyTM) utilisé dans les systèmes domotiques installés par la demanderesse. Dans une telle situation, pour permette une évolution des fonctionnalités pour de nouveaux produits, il est courant de construire un nouveau protocole dans lequel l'ensemble des fonctionnalités existantes ou nouvellement étudiées est pris en compte et qui prévoit des octets disponibles pour des évolutions futures. L'inconvénient d'un nouveau protocole est généralement sa non-compatibilité avec les produits déjà installés, sans compter les coûts de développement générés. Le document WO 92/01979 présente une extension de protocole de communication non filaire pour passer de codes fixes à des codes tournant, ce qui s'apparente à une augmentation du nombre d'adresses possibles pour le protocole. Les anciennes trames comportent des messages de dix mots de 4 bits chacun. Deux trames consécutives sont séparées par des pauses (intervalles blancs) de 39 bits. Chaque début de trame est signalé par un bit de synchronisation. Dans le cas d'une communication radio entre un émetteur et un récepteur, la trame est répétée un certain nombre de fois, tant que l'appui sur la touche de l'émetteur à l'origine de cette transmission est maintenu. Les temps de transmission de trames sont en effet généralement bien inférieurs au temps d'un appui manuel. Le récepteur reconnaît le format émis en détectant un bit de synchronisation suivant un intervalle blanc et il enregistre le message de 10 mots émis. Les nouvelles trames comportent, quant à elles, des signaux de vingt mots, divisées en deux messages de dix mots. Chaque message de dix mots est transmis de manière traditionnelle, c'est-à-dire comme une ancienne trame avec des intervalles blancs séparant les deux messages. Le bit de synchronisation du deuxième message est cependant modifié par rapport au premier. Chaque partie de message est enregistrée successivement par le récepteur. Le bit de synchronisation du deuxième message sert à identifier s'il s'agit d'une deuxième partie de message, et donc d'une trame de la nouvelle génération, ou d'un autre message de l'ancienne génération (répétition de la trame ou trame à contenu différent). Le document WO 01/31873 présente une extension de protocole pour des trames de longueur fixe et à contenu prédéterminé. Cette demande de brevet décrit l'état de l'art en mentionnant que les extensions de protocole connues permettant une compatibilité descendante consistent à fournir un mécanisme explicite indiquant une extension des trames, par exemple par une indication de la longueur de trame, un codage d'indicateur ou des données réservées. Ces méthodes connues ne sont pas systématiquement applicables et en particulier ne sont pas applicables dans le cas d'un protocole à trames de longueur fixe, dans lesquelles tous les bits sont utilisés ou R:\Brevets\23500\23527. doc - 23/02/05 - 16:02 - 2/17 réservés. En effet, selon la solution présentée dans ce document, les extensions de champs ne sont pas accolées à des champs existant du protocole, mais placés ailleurs dans le message. Le document WO 98/34208 décrit un système de gestion de la compatibilité entre une ancienne génération de produits utilisant une transmission infrarouge et une nouvelle génération de produits utilisant une transmission radiofréquence. La compatibilité descendante est définie telle que les produits d'une ancienne génération ne considèrent qu'une partie des données transmises pour leur fonctionnement mais l'ensemble des données pour le calcul d'une somme de vérification, connue sous le terme de checksum . Le protocole de la nouvelle génération doit maintenir le checksum comme dernière donnée transmise afin de conserver cette compatibilité. La compatibilité ascendante est assurée par le contrôle du nombre de données transmises et la détermination du type de protocole correspondant par les récepteurs de la nouvelle génération. Dans ce système, les données à l'intérieur de la trame sont réorganisées et non pas accolées à la suite d'une ancienne trame. Les extensions de protocole décrites dans les documents précités WO 01/31873 et WO 98/34208 nécessitent des adaptations des trames du protocole existant. Par ailleurs, l'extension de protocole décrit dans le document précité WO 92/01979 peut perturber la réception d'un message par des récepteurs d'une ancienne génération. En effet, les informations complémentaires ne sont pas intégrées dans la même trame et le flux d'émission (répétition cyclique des trames et des intervalles inter-trame) de messages lisibles par les récepteurs d'une ancienne génération n'est pas le même selon qu'il s'agisse d'une émission par un émetteur d'une ancienne ou d'une nouvelle génération. Il existe donc un besoin pour une extension de protocole qui permette de conserver l'organisation et le contenu des données d'une trame ancienne tout en ajoutant des informations supplémentaires, le tout étant transmis dans une même trame. A cet effet, l'invention propose d'ajouter des informations supplémentaires à la suite d'une trame classique d'un protocole existant en transmettant ces informations dans l'intervalle inter-trame habituellement prévu dans le protocole. L'invention concerne ainsi une trame de commande comportant: - une première partie comprenant des première données et un premier champ de contrôle; - une seconde partie comprenant des secondes données et un second champ de contrôle; un bit de relais débutant la seconde partie, ledit bit de relais ayant une valeur prédéterminée. R:\Brevets\23500\23527.doc - 23/02/05 - 16:02 - 3/17 Selon les modes de réalisation, la trame de commande selon l'invention comporte une ou plusieurs des caractéristiques suivantes: la seconde partie de la trame suit directement la première partie de la trame; - le premier champ de contrôle est propre à la première partie de la trame; le second champ de contrôle est propre à la seconde partie de la trame ou est global à l'ensemble de la trame; le bit de relais est fixé à l' ; - les secondes données de la seconde partie de trame sont cryptées avec une première clé de cryptage transmise dans la première partie de trame; - les secondes données de la seconde partie de trame sont cryptées avec une seconde clé de cryptage transmise dans la seconde partie de trame; L'invention concerne aussi un système de commande d'actionneurs comprenant: un émetteur d'ordres d'une ancienne génération, adapté à émettre une trame de commande de manière cyclique selon un premier protocole; - un émetteur d'ordres d'une nouvelle génération, adapté à émettre une trame de commande de manière cyclique selon un second protocole, ladite trame du second protocole comportant une trame du premier protocole directement suivie d'informations supplémentaires; - un récepteur d'ordres d'une ancienne génération, lié à un actionneur et adapté à recevoir et interpréter une trame de commande selon les premier et second protocoles; - un récepteur d'ordres d'une nouvelle génération, lié à un actionneur et adapté à recevoir et interpréter une trame de commande selon les premier et second protocoles. Selon les modes de réalisation, système de commande d'actionneurs selon l'invention comporte une ou plusieurs des caractéristiques suivantes: - la trame de commande du second protocole est une trame selon l'invention; la trame du premier protocole a une longueur fixe; - le premier protocole émet des trames séparées par des silences inter- trame et en ce que les informations supplémentaires des trames du second protocole sont émises pendant les silences inter-trame du premier protocole; R:\Brevets\23500\23527doc - 23/02/05 - 1602 - 4/17 25 - les informations supplémentaires des trames du second protocole ne sont interprétées que par les récepteurs d'ordres de la nouvelle génération, les récepteurs d'ordres de l'ancienne génération interprétant uniquement la trame du premier protocole contenue dans la trame du second protocole; - une trame du second protocole est émise avec un premier débit lors de l'émission de la trame du premier protocole et avec un second débit lors de l'émission des informations supplémentaires, le second débit étant supérieur au premier; - les informations supplémentaires d'une trame du second protocole sont interprétées en combinaison avec les données de la trame du premier protocole contenue dans la trame du second protocole; -les cycles d'émission des trames de commande du premier protocole et du second protocole sont identiques; au moins une portion de la trarne du second protocole est cryptée; - la portion cryptée est la trame du premier protocole contenue dans la trame du second protocole; L'invention concerne également un émetteur d'ordres pour système de télécommunication adapté à émettre des trames de commande selon l'invention. L'invention concerne en outre un récepteur d'ordres pour système de télécommunication adapté à recevoir des trames de commande selon l'invention. Selon une caractéristique, le récepteur est adapté à interpréter le contenu de la seconde partie de données. Selon une caractéristique, le récepteur interprète le contenu de la seconde partie 25 de données en fonction du contenu de la première partie de données. Selon une autre caractéristique, le récepteur est adapté à interpréter le contenu de la première partie de données et à interpréter la seconde partie de données comme du bruit. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit des modes de réalisation de l'invention, donnés à titre d'exemple uniquement et en références aux dessins qui montrent: - figure 1, une représentation d'un protocole de transmission connu RTS; - figure 2, l'organisation des données d'une trame du protocole RTS de la figure 1; - figure 3, une représentation d'un protocole de transmission selon la présente invention; R. \Brevets\23500\23527. doc - 23/02/05 - 16.02 - 5/17 - figure 4, l'organisation des données d'une trame du protocole de la figure 3 selon l'invention; - figure 5, une représentation d'un système à compatibilité croisée selon la présente invention. Dans la suite de la description, l'invention est décrite dans un exemple d'application à un système domotique. On utilise dans la suite les mots émetteurs d'ordres et récepteurs d'ordres pour désigner des objets qui ont pour fonction d'émettre ou recevoir les ordres donnés par un utilisateur.émetteur d'ordres est aussi couramment appelé unité de commande, tandis qu'un récepteur d'ordres est un capteur commandant un actionneur d'ouvrant ou d'écran mobile. L'invention vise une extension de protocole existant. La description qui suit est faite en référence au protocole existant RTS (Radio Technology SomfyTM) mis en ceuvre dans la transmission entre des émetteurs d'ordres et des récepteurs d'ordres commercialisés par la demanderesse, utilisé par exemple pour les moteurs Altus RTS, Oximo RTS, Axovia, Axorn et les commandes Telis, Inis RTS, Centralis RTS, Chronis RTS ou Keytis. Le protocole RTS est un protocole largement éprouvé et répandu dans le monde de la domotique. Il est lié à des ergonomies connues par les installateurs et ses qualités de transmission sont fiables, notamment en terme de puissance et d'acceptation des trames par les récepteurs d'ordres. La figure 1 illustre une transmission de trame RTS classique. Une telle trame, désignée par la suite comme une trame de base, est introduite par un certain nombre d'impulsions de synchronisation électronique (dites hardware ) et débute par une impulsion de synchronisation logicielle (dite software ). Les trames RTS sont répétées cycliquement et séparées entre elles par des silences inter-trame, pendant lesquelles aucun signal n'est émis. Lors d'une commande émise par un émetteur d'ordres selon le protocole RTS, les trames de commande sont répétées plusieurs fois cycliquement pour garantir qu'au moins une des trames est reçue correctement par le récepteur et/ou vérifier que certaines commandes ne sont pas maintenues de manière prolongée. Par exemple, lors de l'appui sur une touche de télécommande d'un émetteur par un utilisateur, le temps de réaction de l'émetteur entraîne la transmission de plusieurs trames complètes correspondant au même appui. Il est prévu un épuisement du temps (dit time-out ), par exemple de 10s, pour cesser l'émission, par exemple dans le cas d'un appui prolongé sur la touche de télécommande. L'ensemble comprenant le silence inter-trame et les bits de synchronisation hardware est appelé intervalle inter-trame. Il est entendu que le récepteur ne perçoit R \13revets\23500\23527.doc -23/02/05 - 1602 6/17 pas du silence pendant cet intervalle, mais du bruit, par opposition à des données interprétables. Ces intervalles de silence non codés permettent à l'électronique du récepteur de bien repérer chaque début et fin de trame et d'avoir le temps de bien traiter les données reçues, comme par exemple effectuer le décryptage et le calcul du checksum. La durée entre le début de deux trames consécutives est constante pour un protocole donné. En revanche, le temps de silence inter-trame n'est pas déterminant pour une transmission correcte de la trame et il peut être légèrement variable sans que cela influe sur une réception correcte des données. L'intervalle inter-trame permet surtout de garder une marge de sécurité pour le traitement des données dans la trame transmise précédemment et sert également à bien marquer le flux des différentes trames répétées cycliquement. Le flux de trame est défini par un débit de transmission d'ensembles constitués chacun d'une trame et d'un intervalle inter-trame. La durée de transmission d'une trame complète selon le protocole RTS est de l'ordre de 140 ms, en incluant la synchronisation hardware, la synchronisation software, la trame de données en tant que teille et le silence de fin de trame. Le temps de silence entre la fin de la trame de données et une nouvelle synchronisation hardware est de l'ordre de 34 ms. La figure 2 illustre l'organisation des données dans une trame RTS classique. Une trame RTS contient 56 bits repartis comme suit. Le premier octet contient une clé de cryptage constituée par un nombre aléatoire. Le deuxième octet contient 4 bits identifiant la nature de la commande (ouverture de porte ou fermeture par exemple) et 4 bits de somme de vérification, dits checksum. Les troisième et quatrième octets sont des bits de code tournant, modifiés selon un algorithme prédéterminé à chaque appui sur la télécommande de l'émetteur pour constituer une sécurité au piratage. Les octets suivants comportent les bits d'adresses identifiant l'émetteur. Les 24 bits d'adresse permettent de créer des appariements entre émetteurs et récepteurs. Le partage d'un identifiant commun permet au récepteur de reconnaître les commandes provenant d'un émetteur d'ordres, pour y répondre. On peut assimiler à la liste des identifiants toute information relative au contrôle d'un récepteur d'ordres particulier par un émetteur d'ordres particulier. Il peut donc s'agir d'une clé de cryptage propre à cette paire d'éléments ou de toute donnée confidentielle utile à la transmission et ou l'exécution d'un ordre. On constate sur la figure 2 que tous les bits de la trame RTS classique sont utilisés et une modification de trame entraînerait une incompatibilité de transmission avec les anciens produits. En effet, la trame RTS est constituée intégralement de R: \Brevets\23500\23527doc 23/02/05 - 1602 - 7/17 données exploitées; de nouvelles évolutions ou fonctionnalités ne peuvent plus être implantées en utilisant la trame classique. En particulier, le nombre d'adresses disponibles ne peut plus être augmenté, le cryptage et le checksum sont limités. Par ailleurs, le protocole RTS classique n'est pas optimal pour une application à des récepteurs autonomes. En effet, les produits autonomes ne sont pas connectés au réseau électrique et ont donc des ressources en énergie limitées. Les récepteurs autonomes ont généralement le fonctionnement suivant: l'électronique du récepteur est mise en sommeil pour des raisons d'économies d'énergie. Régulièrement, le récepteur se réveille, écoute s'il reçoit un signal et dans le cas contraire, se rendort. Pour être adapté à une communication suivant un protocole de type RTS ou équivalent, il faut prévoir un temps de réveil du récepteur au moins équivalent au temps de silence inter-trame. Ce silence inter-trame est relativement long dans le cas du protocole RTS, ce qui n'est pas compatible avec les standards de consommation ou les durées de vie requis pour les produits autonomes. Selon l'invention, une trame pour un protocole d'une nouvelle génération est créée. Une telle trame comporte une première partie constituée par une trame RTS de base comprenant des premières données et un premier champ de contrôle, tel qu'un premier checksum, et une seconde partie comprenant des secondes données et un second champ de contrôle, tel qu'un second checksum. La seconde partie de trame de la nouvelle génération débute par un bit de relais fixé à une valeur prédéterminée. La figure 3 illustre une transmission de trame selon un protocole de la nouvelle génération, par exemple émise par un émetteur d'une nouvelle génération. On constate, par comparaison avec la figure 1, qu'une partie du silence inter-trame est remplacée par une quantité d'information qui est interprétable par des récepteurs de la nouvelle génération. En particulier, des données supplémentaires sont simplement accolées à une trame de base. La seconde partie de la trame suit donc directement la première partie de données constituée par une trame RTS classique. Ces données supplémentaires peuvent alors être utilisées pour gérer de nouvelles fonctionnalités des produits. La durée de l'intervalle inter-trame du protocole de la nouvelle génération est ainsi réduite par rapport à la durée de l'intervalle intertrame du protocole de l'ancienne génération, et en particulier la durée du silence inter-trame. Cependant le décalage temporel entre chaque début de trame au cours d'une émission cyclique des trames est constant et identique à celui de l'ancienne génération. Le flux de trames est donc conservé entre le protocole de la nouvelle génération et le protocole de l'ancienne génération. Ainsi, les fonctionnalités basées sur le flux de trame peuvent être conservées telles que dans le nouveau protocole, par exemple le nombre de trames répétées pour une commande ou le tune-out en cas de commande prolongée. R: \Breve*s\23500\23527.doc - 23/02/05 - 16:02 - 8/17 Le protocole de la nouvelle génération est aussi particulièrement adapté aux produits autonomes puisque la durée du silence inter-trame est réduite par la transmission de la seconde partie de données; le temps de réveil du récepteur requis est donc largement diminué. La figure 4 montre l'organisation des données dans une trame RTS de nouvelle génération. On constate que la trame du protocole de la nouvelle génération contient une première partie constituée par une trame RTS de base de 56 bits à laquelle est ajoutée une seconde partie constituée par 24 bits d'informations supplémentaires; en particulier un bit de relais et 23 autres bits utilisables pour de la transmission de données complémentaires aux données de la trame de base. En effet, dans le cadre de l'invention, la seconde partie de trame transmise est de préférence liée à la première partie, c'est à dire que les secondes données vont permettre de mieux définir les informations des premières données transmises dans la trame RTS de base. Par exemple, les informations supplémentaires viennent compléter ou paramétrer la trame RTS de base en ajoutant de nouvelles fonctionnalités, de nouveaux paramètres, en renforçant la sécurité de la transmission, etc. Les informations supplémentaires n'ont pas nécessairement de valeur intrinsèque, c'est-àdire qu'elles sont éventuellement sans objet si elles sont prises indépendamment de la trame RTS de base. En l'occurrence, si les informations des données de la première partie de trame sont cryptées pour des raisons de sécurité, il ne sera pas nécessaire de crypter les informations des secondes données supplémentaires de la seconde partie de trame, qui en elles-mêmes, n'ont pas de fonction propre de commande. Si les secondes données de la seconde partie de trame devaient néanmoins être cryptées, une même clé de cryptage que celle utilisée pour les premières données de la trame RTS de base pourrait être utilisée, ou une autre clé de cryptage, transmise avec les secondes données dans la seconde partie de trame. Le nombre d'octets de la seconde partie de trame, correspondant à la quantité d'informations supplémentaires transmise, sera choisi en fonction du temps de silence inter-trame disponible, en ménageant éventuellement une marge de sécurité pour le traitement des informations par l'électronique du récepteur. Eventuellement, la transmission de la seconde partie de trame pourra s'étendre sur une partie de la synchronisation hardware en plus du silence inter-trame. En effet, dans le cas du protocole RTS, le nombre d'impulsions de synchronisation prévu est compris entre 6 et 12, dont 6 impulsions sont obligatoires. Dans certains cas de mise en oeuvre du protocole, le silence inter-trame peut être utilisé pour la transmission d'impulsions de synchronisation facultatives. Ces impulsions peuvent alors être remplacées par les données supplémentaires. R'Brevets\23500\23527.doc - 23/02/05 - 16:02 - 9/ 17 La trame selon l'invention, pour un protocole RTS d'une nouvelle génération, contient donc une première partie constituée par la trame RTS de base et une seconde partie comprenant des informations supplémentaires. La trame selon l'invention comporte aussi deux champs de contrôle distincts, dits checksum. Un premier champ de contrôle, propre à la trame RTS de base, est placé dans la première partie de trame, par exemple dans le deuxième octet (CKS 1), et un second champ de contrôle (CKS2) est placé dans la deuxième partie de trame. Le second champ de contrôle peut être propre à la deuxième partie de trame pour vérifier l'intégrité des données supplémentaires transmises. Le second champ de contrôle peut aussi être calculé sur l'ensemble de la trame plutôt que sur la seconde partie uniquement. La trame selon l'invention comporte aussi un bit de relais fixé à une valeur prédéterminée et qui débute la seconde partie de trame. Ce bit de relais peut informer les récepteurs de la nouvelle génération que des informations supplémentaires suivent, mais surtout, le bit de relais peut informer les anciens récepteurs que les informations qui suivent ne les concernent pas et qu'ils doivent les considérer comme du bruit. Cette information est en particulier nécessaire lorsqu'un code de type Manchester est utilisé pour déterminer l'état d'un bit. Or, le protocole RTS classique utilise un code Manchester et contrôle systématiquement la fin de trame. Dans un code du type Manchester, l'état du bit de donnée est fourni par un front montant ou descendant au milieu du temps de transmission de ce bit. Dans le cadre d'une trame RTS classique, un front montant représente un bit de logique 1 et un front descendant représente un bit de logique 0. Pour valider un bit lu, trois facteurs sont pris en compte: le comptage des bits lus, le sens du front (montant ou descendant) et l'intervalle de temps At entre deux fronts (classiquement de 1280 las, correspondant au temps de transmission d'un bit). Pour vérifier la fin d'une trame, le protocole RTS classique vérifie la présence d'un front descendant dans un intervalle de temps donné égal à la moitié du temps de transmission d'un bit, soit At/2 (640 s). Si le dernier bit de la trame est à 0, le front descendant correspondant au 0 valide le dernier bit. En revanche, si le dernier bit de la trame est à 1, l'obtention d'un front descendant va dépendre du signal qui suit la fin d'émission de la trame classique. Si le bruit est tel qu'il prolonge de manière sensiblement stable l'état haut du signal, sans front descendant au delà du signal horloge ou qu'il correspond par exemple à un bit de valeur 0, le prochain front descendant ne sera obtenu qu'après un intervalle supérieur à At/2 (640 las). La trame sera alors refusée. Ce phénomène aléatoire est rare et éventuellementcompensé par la succession cyclique de répétition des trames. En revanche, si des informations supplémentaires sont ajoutées en fin d'une trame RTS classique, la probabilité d'avoir un code logique à 0 sur le premier bit d'information supplémentaire est de 50%. Cela entraînerait un refus des trames R:\Brevets\23500\23527.doc - 23/02/05 - 16.02 - 10/17 RTS classiques par les anciens récepteurs trop fréquent pour être acceptable. Le premier bit d'information supplémentaire doit donc être calé à 1 pour que les anciens récepteurs valident l'ensemble de la trame R.TS de base constituant la première partie de données de la nouvelle trame, quelque soit la valeur du 56ème bit clôturant la trame RTS de base. En ajoutant un certain nombre de bits à la fin de la première partie de trame, on réserve donc un premier bit d'information supplémentaire dans la seconde partie de trame, dit bit de relais, qui sera systématiquement calé à 1. Ainsi, en forçant un front montant sur le bit suivant juste le dernier bit de la trame RTS de base, on garantit qu'un front descendant (au moment du signal horloge) intervient dans un intervalle de At/2 (640 ms). Les anciens récepteurs, ayant reçu un nombre suffisant et compréhensible de bits, ne réagissent pas aux nouvelles informations transmises qu'ils interprètent comme du bruit. Si on ne force pas ce premier bit d'information supplémentaire à 1, les données supplémentaires de la seconde partie de trame pourraient débuter par un zéro et compromettre l'acceptation de la première partie de la trame par un ancien récepteur. Cet arrangement est dans ce cas lié au choix des critères pour valider la trame de l'ancien protocole et dépend également du codage utilisé, en particulier du choix du code logique pour un front montant ou descendant pour un codage Manchester. L'invention concerne aussi un système de télécommunication comprenant au moins un émetteur d'ordres d'une ancienne génération, un émetteur d'ordres d'une nouvelle génération, un récepteur d'ordres d'une ancienne génération et un récepteur d'ordres d'une nouvelle génération. La figure 5 illustre le système selon l'invention. Les émetteurs EMa et récepteurs RCa de l'ancienne génération sont respectivement adaptés à émettre et à recevoir et interpréter une trame de commande TRa cyclique selon un premier protocole, par exemple un protocole RTS classique. Par ailleurs, les émetteurs EMb et récepteurs RCb de la nouvelle génération sont respectivement adaptés à émettre et à recevoir et interpréter une trame de commande TRb cyclique selon un second protocole. La trame du second protocole comporte une trame du premier protocole directement suivie d'informations complémentaires, par exemple une trame RTS de nouvelle génération telle que décrite précédemment. Les récepteurs RCa ou RCb sont liés à des actionneurs, par exemple ainsi que représentés sur la figure 5, des motoréducteurs tubulaires pour l'entraînement de protections solaires. Le récepteur peut faire partie intégrale de l'actionneur, par exemple être contenu dans le boîtier de l'actionneur tubulaire à l'intérieur du tube d'enroulement de l'écran de protection solaire. R: \13revets\23500\23527.doc - 23/02/05 - 16:02 - 11/17 Selon l'invention, un récepteur RCa de l'ancienne génération est également adapté à recevoir et interpréter une trame de commande TRb selon le nouveau protocole et un récepteur RCb de la nouvelle génération est également adapté à recevoir et interpréter une trame de commande TRa selon l'ancien protocole. La trame de l'ancien protocole a une longueur fixe, par exemple 56 bits, et l'ancien protocole émet des trames séparées par un intervalle intertrame. La trame du nouveau protocole émet des informations complémentaires pendant les silences inter-trame définis dans les intervalles inter-trame de l'ancien protocole. Ainsi, les données supplémentaires transmises par les trames TRb du nouveau protocole apparaissent comme du bruit pour les anciens récepteurs RCa alors que les données fournies dans l'intervalle inter-trame peuvent être traitées par les nouveaux récepteurs RCb. Puisque la trame du premier protocole se retrouve intégralement dans le nouveau protocole et que le flux de trame n'est pas modifié, la nouvelle trame est lisible par les anciens types de récepteurs; on assure ainsi la compatibilité descendante avec une communication entre nouveaux émetteurs EMb et anciens récepteurs RCa. De même, la compatibilité ascendante est assurée avec une communication entre anciens émetteurs EMa et nouveaux récepteurs RCb; des blancs (silence inter-trame) sont reçus par les nouveaux récepteurs à la place des données supplémentaires, mais le message est lisible par les nouveaux récepteurs car le format de la trame de base est identique pour les deux types de protocoles. Le nombre d'octets transmis dans une trame de commande TRb de la nouvelle génération dépend du silence inter-trame disponible, mais peut être augmenté par une augmentation du débit de transmission de ces données. La trame du nouveau protocole peut être émise avec un premier débit lors de l'émission de la trame de base puis avec un second débit lors de l'émission des informations supplémentaires, le second débit étant supérieur au premier. Ainsi, le message émis par les émetteurs de la nouvelle génération pourra comprendre une première partie de transmission avec un premier débit correspondant à celui de l'ancien protocole suivie d'une seconde partie de transmission de données à un débit supérieur de manière à transmettre un nombre d'octets supérieur. Cette modification de débit sera transparente pour les anciens récepteurs qui ne traitent pas les données supplémentaires. Par contre, elle implique éventuellement une modification de l'électronique de traitement des données pour les émetteurs et récepteurs de nouvelle génération, si le débit choisi est supérieur au débit maximal que peuvent traiter les émetteurs et récepteurs de l'ancienne génération. L'invention concerne ainsi un émetteur d'ordres EMb pour système de télécommunication selon l'invention adapté à transmettre des trames de commande TRb selon le nouveau protocole et un récepteur d'ordres RCb pour système de R313revets\23500\23527doc - 23/02/05 - 16.02 - 12/ 17 télécommunication selon l'invention adapté à recevoir des trames de commande TRb selon le nouveau protocole. En particulier, les récepteurs de la nouvelle génération sont adaptés à interpréter le contenu des informations supplémentaires transmises à la suite d'une trame de base dans les nouvelles trames. Ces informations supplémentaires sont interprétées en combinaison avec les données de la trame de base qui est entièrement contenue dans la trame du nouveau protocole. Ces informations supplémentaires peuvent comprendre des compléments d'identification ou d'adresses. En effet, le protocole RTS existant a un nombre d'adresses limité, codées sur 24 bits, ce qui peut conduire à une saturation. Il est donc possible, dans le cadre du nouveau protocole, d'utiliser certains octets d'informations supplémentaires pour coder un complément d'adresse. Ce complément d'adresse peut représenter une indication de famille, correspondant à un type de produit, à un revendeur utilisant le protocole sur ses propres produit ou autre, ou simplement correspondre à un complément de code aléatoire. Si on choisit de différencier des familles de produits fonctionnant sur le protocole de la nouvelle génération selon l'invention, on peut prévoir des fonctionnalités de blocage du récepteur sur une famille particulière, selon le ou les premiers codes reçus dans les informations supplémentaires de la seconde partie de trame. Les informations supplémentaires peuvent aussi permettre de renforcer la sécurité de la transmission d'une trame. En effet, de nouvelles fonctionnalités d'authentification peuvent être ajoutées dans la seconde partie de la trame transmise selon le protocole de la nouvelle génération. Par exemple, l'émetteur fournit, dans la seconde partie de données de la trame, un nombre aléatoire en même temps qu'un résultat de calcul basé sur une clé qu'il partage avec un récepteur. A réception de la trame, le récepteur refait le calcul à partir clu nombre aléatoire transmis et vérifie le résultat avec celui transmis dans les informations supplémentaires de la trame. Cette authentification peut intervenir en complément de la vérification de l'identifiant de l'émetteur avec les données de la première partie de la trame. Bien entendu, la présente invention n'est pas limitée aux modes de réalisations décrits à titre d'exemple. Tout protocole de commande d'actionneurs utilisant des trames de longueur fixe répétées cycliquement peut être utilisé dans le cadre de l'invention pour construire un nouveau protocole consistant à ajouter, à la trame de base classique, des informations supplémentaires placées dans le silence inter-trame défini par le protocole classique. R:U3revets\23500\23527doc - 23/02105 - 1602 - 13/17 14 REVENDICATIONS, 1. Système de transmission d'ordres destinés à commander des actionneurs dans lequel un ordre est transmis par une trame de commande comportant: une première partie comprenant des première données et un premier champ de contrôle (CKS 1) ; - une seconde partie comprenant des secondes données et un second champ de contrôle (CKS2) ; - un bit de relais débutant la seconde partie, ledit bit de relais ayant une valeur prédéterminée. 2. Système de transmission d'ordres selon la revendication 1, caractérisée en ce que la seconde partie de la trame suit directement la première partie de la trame. 3. Système de transmission d'ordres selon la revendication 1 ou 2, caractérisée en ce que le premier champ de contrôle est propre à la première partie de la trame. 4. Système de transmission d'ordres selon l'une des revendications 1 à 3, caractérisée en ce que le second champ de contrôle est propre à la seconde partie de la trame. 5. Système de transmission d'ordres selon l'une des revendications 1 à 3, caractérisée en ce que le second champ de contrôle est global à l'ensemble de la 20 trame. 6. Système de transmission d'ordres selon l'une des revendications 1 à 5, caractérisée en ce que le bit de relais est fixé à 41'. 7. Système de transmission d'ordres selon l'une des revendications 1 à 6, caractérisée en ce que les secondes données de la seconde partie de trame sont cryptées avec une première clé de cryptage transmise dans la première partie de trame. 8. Système de transmission d'ordres selon l'une des revendications 1 à 6, caractérisée en ce que les secondes données de la seconde partie de trame sont cryptées avec une seconde clé de cryptage transmise dans la seconde partie de trame. R\Brevets\23500\23527.doc - 30/06/05 - 18:06 - 14/17 9. Système de transmission d'ordres selon l'une des revendications 1 à 8, le système comprenant: - un émetteur d'ordres (EMa) d'une ancienne génération, adapté à émettre un ordre transmis de manière cyclique par une trame de commande (TRa) selon un premier protocole; - un émetteur d'ordres (EMb) d'une nouvelle génération, adapté à émettre un ordre transmis de manière cyclique par une trame de commande (TRb) selon un second protocole, ladite trame du second protocole comportant une première partie constituée par une trame du premier protocole directement suivie par une deuxième partie comportant des d'informations supplémentaires; - un récepteur d'ordres (RCa) d'une ancienne génération, lié à un actionneur et adapté à recevoir et interpréter une trame de commande selon les premier et second protocoles; - un récepteur d'ordres (RCb) d'une nouvelle génération, lié à un actionneur et adapté à recevoir et interpréter une trame de commande selon les premier et second protocoles. 10. Le système selon la revendication 9, caractérisé en ce que la trame du premier protocole a une longueur fixe. 11. Le système selon l'une des revendications 9 ou 10, caractérisé en ce que le premier protocole émet des trames séparées par des silences intertrame et en ce que les informations supplémentaires des trames du second protocole sont émises pendant les silences inter-trame du premier protocole. 12. Le système selon l'une des revendications 9 à 11, caractérisé en ce que les informations supplémentaires des trames du second protocole ne sont interprétées que par les récepteurs d'ordres de la nouvelle génération, les récepteurs d'ordres de l'ancienne génération interprétant uniquement la trame du premier protocole contenue dans la trame du second protocole. 13. Le système selon l'une des revendications 9 à 12, caractérisé en ce qu'une trame du second protocole est émise avec un premier débit lors de l'émission de la trame du premier protocole et avec un second débit lors de l'émission des informations supplémentaires, le second débit étant supérieur au premier. 14. Le système selon l'une des revendications 9 à 13, caractérisé en ce que les informations supplémentaires d'une trame du second protocole sont interprétées en R:1Brevets123500123527.doc - 30/06/05 -18:06 - 15/17 combinaison avec les données de la trame du premier protocole contenue dans la trame du second protocole. 15. Le système selon l'une des revendications 9 à 14, caractérisé en ce que les cycles d'émission des trames de commande du premier protocole et du second protocole sont identiques. 16. Le système selon l'une des revendications 9 à 15, caractérisé en ce qu'au moins une portion de la trame du second protocole est cryptée. 17. Le système selon la revendication 16, caractérisé en ce que la portion cryptée est la trame du premier protocole contenue dans la trame du second protocole. 18. Emetteur d'ordres pour système de télécommunication adapté à émettre des ordres transmis selon le système de transmission de l'une des revendications 1 à 8. 19. Récepteur d'ordres pour système de télécommunication adapté à recevoir des ordres transmis selon le système de transmission de l'une des revendications 1 à 8 20. Récepteur selon la revendication 19, caractérisé en ce qu'il est adapté à interpréter le contenu de la seconde partie de données. 21. Récepteur selon la revendication 20, caractérisé en ce qu'il interprète le contenu de la seconde partie de données en fonction du contenu de la première partie de données. 22. Récepteur selon la revendication 19, caractérisé en ce qu'il est adapté à interpréter le contenu de la première partie de données et à interpréter la seconde partie de données comme du bruit. R\Brevets\23500\235274oc - 30/06/05 - 18:06 - 16/17