"Module d'infrastructure dans un système de transmission de données"
La présente invention est relative à un module d'infrastructure dans un système de transmission de données suivant le préambule de la revendication 1.
Elle s'applique en particulier dans des application suivant la technologie LonWorks. La technologie LonWorks développée par la société Echelon permet de réaliser des systèmes à intelligence distribuée; les différents modules communiquant entre eux par le protocole LonWorks.
Ce protocole est prévu pour supporter différents types de transmetteurs, cependant chacun de ceux-ci sont définis par des caractéristiques électriques. Ils sont également soumis à certaines limitations telles que distance de câble maximum, nombre maximum d'équipement connecté (dans le cas des liaisons câblées) , ou encore distance maximale de transmission (systèmes câblés et sans fil)
Ces limitations sont contournées en faisant usage d'équipements d'infrastructure.
Deux équipements d'infrastructure courants sont les répéteurs (repeater) et routeurs (router) . L'objet du présent brevet est la protection d'un troisième type d'équipement d'infrastructure: un bridge autonome et plug and play.
Un répéteur physique est un élément d'infrastructure ayant au minimum deux interfaces de communication. Il transmet tout signal reçu par une interface vers les autres interfaces et ce quel que soit la nature du signal reçu, que celui-ci soit utile ou non, valide ou parasité. C'est l'élément d'infrastructure le moins cher car il ne contient aucune intelligence. Il est également le moins fiable car il ne fournit pas d'isolation logique entre ses différentes interfaces et les perturbations présentes sur une partie du réseau peuvent se propager à l'entièreté de celui-ci, le rendant inopérant.
Le routeur quant à lui présente une intelligence qui lui permet de décider si un paquet reçu par une interface doit ou non être transmis aux autres interfaces. Il peut ainsi trier les données suivant leur validité et leur destinataire. Ils présentent une série d'inconvénients tels que le fait de devoir être configurés par un technicien, par le fait qu'ils présentent un coût relativement élevé et qu'ils imposent certaines limitations (notamment la configuration de la taille maximale des paquets de données: un compromis doit être choisi entre le nombre de paquets pouvant être mémorisés et leur taille) .
Dans certaines circonstances les routeurs peuvent être configurés en mode pass-through, dans lequel ils ne vont filtrer les paquets de données que sur base de leur validité et non de leur destinataire; ils se rapprochent d'une fonctionnalité bridge mais conservent les inconvénients précités.
Le but de l'invention est de proposer un module d'infrastructure fiable, facile à utiliser à un coût attractif.
Pour atteindre cet objectif, le module suivant l'invention est caractérisé en ce que qu'une série n de blocs logiques est prévue dans au moins une desdites mémoires, chaque bloc étant prévu, lors d'une réception d'un paquet de données suivant un protocole d'entrée, de convertir le paquet de données suivant le protocole d'entrée en un paquet de données suivant un protocole interne et transmettre le paquet de données suivant le protocole interne à un noeud central, le noeud central étant prévu pour transmettre le paquet de données suivant le protocole interne à au moins un autre desdits blocs logiques, le au moins autre desdits blocs logiques étant prévu pour convertir le paquet de données suivant le protocole interne en un paquet de données suivant un protocole de sortie et transmettre le paquet de données suivant le protocole de sortie à une sortie du module.
Des formes de réalisation particulières de l'invention sont décrites dans les revendications 2 à 12.
L'invention concerne également un procédé de transmission de données suivant la revendication 13.
Le module d'infrastructure suivant l'invention peut être mis en oeuvre dans un module appelé bridge . Le bridge est un élément d'infrastructure situé entre le répéteur physique et le routeur. Il présente des grands avantages par rapport au répéteur dans le sens où il isole logiquement les réseaux interconnectés, offrant ainsi une fiabilité accrue du système dans son ensemble; enfin il ne nécessite pas de configuration et utilise un système de mémoire dynamique qui élimine les inconvénients du routeurs en permettant le stockage d'un grand nombre de petits paquets de données ou bien d'un nombre plus réduit de grand paquets, ou encore d'une combinaison des deux : l'utilisateur doit juste connecter le bridge dans le système pour bénéficier de ses avantages.
Les avantages et caractéristiques du module suivant l'invention, ou suivant une forme avantageuse de l'invention, incluent entre autre:
1. Le module ne requiert aucune configuration, il est plug and play
2. Le module possède une intelligence lui permettant de filtrer les paquets de donnée invalides 3. Le module peut être implémenté dans un FPGA
( Field Programmable Gâte Area ) ou un processeur standard; il peut donc être intégré à un système existant et ne pas nécessiter de hardware complexe, d'où un côut de fabrication réduit. Il est également très compact.
4. De préférence, le module utilise un système d'allocation dynamique de mémoire permettant d'éviter la limitation imposée dans les routeurs par la configuration d'une taille maximale de paquet avec le compromis (nombre de paquets * taille maximale paquet < taille mémoire). Pour l'algorithme module, la limite est (Somme des paquets mémorisés < taille mémoire) . Cet algorithme a également l'avantage de ne pas requérir de configuration. 5. De préférence, le module ne propose pas d'algorithme de routage basé sur l'adresse du destinataire (comme c'est le cas des routeurs), par contre, il permet le filtrage des paquets sur base du contenu de ceux-ci (mode d'adressage, code de message ou données) .
Ceci peut être mis à profit dans certaines utilisations du protocole LonWorks, notamment lorsque 1 ' on a recours à 1 ' envoi de messages broadcast lorsque le réseau n'est pas organisé en utilisant la notion de sous réseaux; le filtrage peut dans ce cas être effectué sur base d'informations applicatives contenues dans les données du message. De manière générale, cette mesure permet d'optimaliser le trafic de données. 6. Un module est constitué par un nombre n de blocs logiques, interconnectés par un canal de communication multi-directionnel (CCMD) : lorsqu'un bloc reçoit un paquet de donnée, il est transmis à tous les autres. Le CCMD agit donc comme un bus virtuel et est indépendant de la vitesse de communication de chaque interface ou de son encodage. 7.
La combinaison d'un nombre quelconque de ces blocs, ainsi que de différents types de blocs (ayant différentes interfaces ou transmetteurs) permet l'obtention de produits différents.
8. Le CCMD peut être implémenté par une mémoire à double accès (Dual Port RAM) pour les configurations contenant 2 blocs logiques.
9. Le CCMD peut être implémenté au moyen d'un serveur central dans les autres cas (LonServer) : ce serveur central ne nécessite aucune configuration; il utilise le protocole LonServer/LonClient défini dans le cadre de ce brevet ou une variante. Le principe est que chaque paquet de donnée reçu par le serveur est transmis à tous les autres clients enregistrés et ayant envoyé un message keepalive récemment. Ce serveur central, lorsqu'il utilise pour sa communication avec les clients un protocole de type point-to-point ou point-to multipoint (par exemple TCP/IP) , permet la délocalisation des différents blocs logiques sur plusieurs unités intelligentes géographiquement distribuées. 10.
La combinaison d'un bloc logique équipé d'une interface standard LonWorks (par exemple FTTIO ou RS485, utilisant le codage natif de la technologie LonWorks, à savoir encodage Manchester) avec un bloc logique implémentant le protocole standard RS232 UART, permet l'utilisation de périphériques standards tels que modems, modems radios (RF) , convertisseurs RS232 vers USB, RS232 vers Ethernet. Le module est donc un traducteur de protocole. 11. Le module résultant de la combinaison d'un bloc logique avec interface standard LonWorks et d'un bloc logique avec interface RS232 peut être utilisé pour l'interconnexion d'un système de supervision ou configuration (ordinateur ou autre système à processeur) avec l'avantage de ne nécessiter que des drivers et port d'interface série disponible sur la plupart des plateformes.
Parmi les exemples d'applications, on peut citer les exemples suivants:
1. Fonctionnalité bridge entre deux segments LonWorks FTT10 or RS485) . Ce principe est illustré dans la figure 1.
2. Interface de communication permettant à un ordinateur d'accéder à un réseau LonWorks par un hardware très simple. 3. Interconnexion de plusieurs réseaux LonWorks par l'intermédiaire d'un mécanisme de transport standard utilisant une communication série asynchrone ou synchrone (Modem RF, interfaces série vers ethernet ... ) . Ce principe est illustré dans la figure 2.
Le principe de fonctionnement est décrit ciaprès pour un exemple de bridge Lonworks vers un protocole interne de série standard.
Dans cet exemple, le mot bridge réfère à un produit intégrant deux blocs logiques du module, un ayant un port de communication compatible LonWorks, l'autre ayant un port de communication au standard
RS232.
Le bridge est à l'écoute de tout paquet de donnée reçu sur son port LonWorks ou RS232 (paquet suivant un protocle d'entrée). Lorsqu'un paquet est reçu, il est stocké dans une zone tampon locale, de manière à gérer correctement l'éventuelle différence de vitesse de transmission entre les deux côtés du bridge. Lorsque le paquet est reçu complètement, il est transmis de l'autre côté.
Les paquets transmis sont des paquets LonWorks non transformés, ils sont cependant encodés de manière à pouvoir être transmis. Le type d'encodage varie suivant le média de communication. Typiquement, l'encodage pour un média compatible LonWorks est un encodage de type Manchester, avec violation du code pour marquer la fin de transmission. L'encodage sur une ligne série asynchrone définit quant à lui un mécanisme permettant l'indication de début et fin de paquet, mécanisme qui n'est pas prévu en standard par ce moyen de transport. Dans cet exemple, le paquet de donnée brutes est encapsulé entre deux marqueurs de début et fin de paquet; lorsqu'un conflit peut survenir entre les données brutes et le marqueur, les données brutes sont modifiées afin de lever 1 ' ambiguïté.
Le module contient de préférence deux tampons circulaires de mémoire (buffers) (typiquement 512 bytes, mais aucune limitation n'est prévue) Tout message entrant est mémorisé dans le buffer; un bit supplémentaire (9ème bit) est utilisé pour marquer la fin de chaque message. Avec ce système, chaque paquet entrant n'utilise que la mémoire strictement nécessaire, et le système s'accommode donc de paquets de données de tailles diverses, sans qu'aucune configuration ne soit requise.
Chaque buffer est utilisé de manière symétrique . Dès qu'un message est complètement entréené et mémorisé, et que l'autre média de communication est disponible, celui-ci est transmis (suivant le protocole de sortie déterminé) .
La raison du stockage complet d'un paquet avant sa retransmission de l'autre côté du bridge est nécessaire pour garantir 1 ' ininterruption de données dans le cas ou les vitesses de transmission ne seraient pas égales, en effet, l'encodage manchester utilisé par le protocole LonWorks utilise le manque de données pour déterminer la fin d'une transmission; un retard dans l'arrivée de données se traduirait donc dans la cassure d'un paquet en plusieurs petits (incomplets) et conduirait à une erreur de transmission.
La simulation illustrée à la figure 3 illustre le transfert d'un paquet de donnée Lonworks au travers de deux bridges interconnectés par une ligne série.
La première ligne représente le paquet LonWorks (encodé manchester) ; il est stocké au fur et à mesure de sa entrée. Dès la fin du message, la transmission sur la ligne série débute (transmission asynchrone, 8 bits data, pas de parité, 1 stop bit) . Cette transmission entre dans le deuxième bridge qui mémorise le paquet. A la fin de la entrée de ce message au protocole UART RS232, le deuxième bridge transmet le résultat avec l'encodage manchester propre au réseau LonWorks.
Dans cette illustration, les deux bridges étaient directement interconnectés, une extension immédiate de ce cas de figure consiste à insérer deux modems ou autres éléments de transmission du protocole UART RS232 entre les deux bridges, afin par exemple de parcourir de grandes distances ou utiliser une liaison sans fil.
Description du protocole LonServer/LonClient
(LSLC) :
Ce protocole a été conçu afin de simplifier la configuration d'un bus virtuel interne ou externe à un système permettant à différentes applications ou bridges de se connecter et échanger des messages.
Une norme internationale définit le protocole EIA852 comme un moyen possible de transport de paquets LonWorks au travers d'Ethernet, mais une limitation importante de ce protocole est la nécessité d'un serveur de configuration, d'une configuration relativement complexe, ainsi qu'un d'un besoin relativement important en ressources (processing et mémoire) qui empêche son utilisation avec des architectures simples et typiquement dans des FPGA ou petits processeurs.
Le protocole LSLC est directement compatible avec la transmission d'un paquet LonWorks sur une ligne série: le paquet brut est encapsulé par un marqueur de début et un marqueur de fin, et chaque ambiguïté possible entre les marqueurs et les données brutes sont levées en modifiant les données brutes.
De préférence, un mécanisme de keepalive est prévu: il permet l'utilisation d'un temps de vie limité pour chaque client du serveur. L'enregistrement/désenregistrement des clients ne nécessite donc pas de configuration particulière: le serveur écoute sur un port TCP/IP; un client doit juste connaître l'adresse du serveur. Dès l'envoi du premier message, le serveur enregistre le client et le maintient dans sa liste jusqu'au moment ou aucun paquet de donnée n'est reçu et aucun message keepalive n'est reçu endéan un certain délai. A ce moment, le client est enlevé.
Le protocole UDP est utilisé, en effet, l'éventuelle retransmission de données non reçues sera effectué par le protocole LonWorks. Ce mécanisme simple de bus virtuel Lonworks sur la couche TCP/IP permet l'utilisation de ce bus au sein d'un équipement, mais également simplifie le développement et le dépannage d'applications en acceptant qu'un équipement externe se connecte.
Un filtrage de sécurité peut être effectué sur base d'une liste d'adresse IP ou MAC valides ou bannies.
La figure 4 illustre schématiquement un exemple de configuration de blocs logiques et d'un noeud central, où on utilise différents protocoles de communication .
La figure 5 illustre à titre d'exemple le détail d'un bloc logique. Le module suivant l'invention ou suivant des formes de réalisation préférentielles selon l'invention permettent d'utiliser une variété des protocoles possibles, d'interconnecter plus que 2 blocs logiques. En particulier, on utilise des marqueurs spécifiques pour séparer les messages envoyés au noeud central (sur le protocole interne) .
"Infrastructure module in a data transmission system"
The present invention relates to an infrastructure module in a data transmission system according to the preamble of claim 1.
It is particularly applicable in applications using LonWorks technology. The LonWorks technology developed by the company Echelon allows for distributed intelligence systems; the different modules communicating with each other by the LonWorks protocol.
This protocol is intended to support different types of transmitters, however each of these are defined by electrical characteristics. They are also subject to certain limitations such as maximum cable distance, maximum number of connected equipment (in the case of cable connections), or maximum transmission distance (wired and wireless systems)
These limitations are circumvented by making use of infrastructure equipment.
Two common infrastructure devices are repeaters and routers. The purpose of this patent is the protection of a third type of infrastructure equipment: a standalone and plug and play bridge.
A physical repeater is an infrastructure element having at least two communication interfaces. It transmits any signal received by an interface to the other interfaces and regardless of the nature of the signal received, whether it is useful or not, valid or parasitized. It is the least expensive infrastructure element because it contains no intelligence. It is also the least reliable because it does not provide logical isolation between its various interfaces and the disturbances present on a part of the network can spread to the whole of it, rendering it inoperative.
The router itself has an intelligence that allows it to decide whether or not a packet received by an interface should be transmitted to other interfaces. It can thus sort the data according to their validity and their recipient. They have a series of disadvantages such as the fact of having to be configured by a technician, the fact that they have a relatively high cost and they impose certain limitations (including the configuration of the maximum size of the data packets: a compromise must be chosen between the number of packets that can be memorized and their size).
In certain circumstances routers can be configured in pass-through mode, in which they will filter the data packets only on the basis of their validity and not of their recipient; they are close to a bridge functionality but retain the aforementioned drawbacks.
The object of the invention is to provide a reliable infrastructure module, easy to use at an attractive cost.
To achieve this objective, the module according to the invention is characterized in that a series n of logic blocks is provided in at least one of said memories, each block being provided on receipt of a next data packet. an input protocol, converting the data packet according to the input protocol into a data packet according to an internal protocol and transmitting the data packet according to the internal protocol to a central node, the central node being provided to transmit the data packet following the internal protocol to at least one other of said logic blocks, the at least one of said logical blocks being arranged to convert the data packet according to the internal protocol into a data packet according to an output protocol and transmit the packet of data data following the output protocol to an output of the module.
Particular embodiments of the invention are described in claims 2 to 12.
The invention also relates to a data transmission method according to claim 13.
The infrastructure module according to the invention can be implemented in a module called bridge. The bridge is an infrastructure element located between the physical repeater and the router. It has great advantages over the repeater in that it logically isolates the interconnected networks, thus providing increased reliability of the system as a whole; finally it does not require configuration and uses a dynamic memory system that eliminates the inconvenience of routers by allowing the storage of a large number of small data packets or a smaller number of large packets, or even a combination of both: the user just needs to connect the bridge in the system to benefit from its advantages.
The advantages and characteristics of the module according to the invention, or according to an advantageous form of the invention, include among others:
1. The module does not require any configuration, it is plug and play
2. The module has an intelligence allowing it to filter invalid data packets 3. The module can be implemented in an FPGA
(Field Programmable Area Area) or a standard processor; it can therefore be integrated into an existing system and not require complex hardware, resulting in a reduced cost of manufacture. It is also very compact.
4. Preferably, the module uses a dynamic memory allocation system to avoid the limitation imposed in routers by the configuration of a maximum packet size with the compromise (number of packets * maximum packet size <memory size ). For the module algorithm, the limit is (sum of stored packets <memory size). This algorithm also has the advantage of not requiring configuration. 5. Preferably, the module does not propose a routing algorithm based on the address of the recipient (as is the case of routers), on the other hand, it allows the filtering of packets based on the content thereof (addressing mode, message code or data).
This can be exploited in certain uses of the LonWorks protocol, especially when using broadcast messages when the network is not organized using the notion of subnetworks; in this case, the filtering can be carried out on the basis of application information contained in the message data. In general, this measure makes it possible to optimize the data traffic. 6. A module consists of a number n of logical blocks, interconnected by a multi-directional communication channel (CCMD): when a block receives a packet of data, it is transmitted to all others. The CCMD acts as a virtual bus and is independent of the communication speed of each interface or its encoding. 7.
The combination of any number of these blocks, as well as different types of blocks (having different interfaces or transmitters) makes it possible to obtain different products.
8. The CCMD can be implemented with Dual Port RAM for configurations containing 2 logical blocks.
9. The CCMD can be implemented by means of a central server in other cases (LonServer): this central server does not require any configuration; it uses the LonServer / LonClient protocol defined in this patent or variant. The principle is that each data packet received by the server is passed to all other registered clients and has sent a keepalive message recently. This central server, when it uses a point-to-point or point-to-multipoint protocol (for example TCP / IP) for its communication with clients, allows the delocalization of the different logical blocks on several geographically distributed intelligent units. 10.
The combination of a logic block equipped with a standard LonWorks interface (eg FTTIO or RS485, using the native coding of LonWorks technology, ie Manchester encoding) with a logic block implementing the standard protocol RS232 UART, allows the use standard devices such as modems, radio modems (RF), RS232 to USB converters, RS232 to Ethernet. The module is therefore a protocol translator. 11. The module resulting from the combination of a logical block with LonWorks standard interface and a logic block with RS232 interface can be used for the interconnection of a supervisory or configuration system (computer or other processor system) with the advantage of requiring only drivers and serial interface port available on most platforms.
Examples of applications include the following examples:
1. Bridge functionality between two LonWorks FTT10 or RS485 segments). This principle is illustrated in Figure 1.
2. Communication interface allowing a computer to access a LonWorks network with very simple hardware. 3. Interconnection of several LonWorks networks via a standard transport mechanism using asynchronous or synchronous serial communication (RF modem, serial to ethernet interfaces ...). This principle is illustrated in Figure 2.
The operating principle is described below for an example of a Lonworks bridge to a standard serial internal protocol.
In this example, the word bridge refers to a product integrating two logical blocks of the module, one having a LonWorks compatible communication port, the other having a standard communication port.
RS232.
The bridge listens for any packet of data received on its LonWorks port or RS232 (packet following an input protocol). When a packet is received, it is stored in a local buffer zone, so as to properly handle the possible difference in transmission speed between the two sides of the bridge. When the packet is received completely, it is transmitted on the other side.
The transmitted packets are non-transformed LonWorks packets, but they are encoded so that they can be transmitted. The type of encoding varies according to the communication medium. Typically, the encoding for a LonWorks-compatible media is a Manchester type encoding, with code violation to mark the end of transmission. Encoding on an asynchronous serial line defines a mechanism for the indication of beginning and end of the packet, a mechanism that is not provided as standard by this means of transport. In this example, the raw data packet is encapsulated between two markers of start and end of packet; when a conflict may occur between the raw data and the marker, the raw data is modified to remove the ambiguity.
The module preferably contains two circular buffers (typically 512 bytes, but no limitation is provided). Any incoming message is stored in the buffer; an extra bit (9th bit) is used to mark the end of each message. With this system, each incoming packet uses only the strictly necessary memory, and the system therefore accommodates data packets of various sizes, without any configuration being required.
Each buffer is used symmetrically. As soon as a message is completely entered and stored, and the other communication medium is available, it is transmitted (according to the determined output protocol).
The reason for the complete storage of a packet before its retransmission on the other side of the bridge is necessary to guarantee the uninterrupted data in case the transmission rates are not equal, in fact, the manchester encoding used by the LonWorks protocol uses the lack of data to determine the end of a transmission; a delay in the arrival of data would therefore result in the break of a packet into several small (incomplete) and would lead to a transmission error.
The simulation illustrated in Figure 3 illustrates the transfer of a Lonworks data packet through two bridges interconnected by a serial line.
The first line represents the LonWorks package (manchester encoded); it is stored as and when it enters. At the end of the message, the transmission on the serial line starts (asynchronous transmission, 8 bits data, no parity, 1 stop bit). This transmission enters the second bridge that memorizes the packet. At the end of the input of this message to the RS232 UART protocol, the second bridge transmits the result with the LonWorks network's own manchester encoding.
In this illustration, the two bridges were directly interconnected, an immediate extension of this case is to insert two modems or other transmission elements of the RS232 UART protocol between the two bridges, for example to travel great distances or use a link wireless.
Description of the LonServer / LonClient protocol
(LSLC):
This protocol was designed to simplify the configuration of an internal or external virtual bus to a system allowing different applications or bridges to connect and exchange messages.
An international standard defines the EIA852 protocol as a possible way to transport LonWorks packets over Ethernet, but an important limitation of this protocol is the need for a configuration server, with a relatively complex configuration, as well as a relatively large need in resources (processing and memory) that prevents its use with simple architectures and typically in FPGAs or small processors.
The LSLC protocol is directly compatible with the transmission of a LonWorks packet on a serial line: the raw packet is encapsulated by a start marker and an end marker, and each possible ambiguity between the markers and the raw data is raised by modifying the raw data.
Preferably, a keepalive mechanism is provided: it allows the use of a limited lifetime for each client of the server. Saving / unregistering clients does not require any particular configuration: the server listens on a TCP / IP port; a client just needs to know the server address. As soon as the first message is sent, the server saves the client and keeps it in its list until no data packet is received and no keepalive message is received within a certain time. At this moment, the client is removed.
The UDP protocol is used, indeed, the eventual retransmission of data not received will be made by the LonWorks protocol. This simple Lonworks virtual bus mechanism on the TCP / IP layer allows for the use of this bus within a device, but also simplifies application development and troubleshooting by allowing an external device to connect.
Security screening can be done based on a list of valid or banned IP or MAC addresses.
Figure 4 schematically illustrates an example configuration of logical blocks and a central node, where different communication protocols are used.
Figure 5 illustrates by way of example the detail of a logic block. The module according to the invention or according to preferred embodiments according to the invention make it possible to use a variety of possible protocols, to interconnect more than 2 logical blocks. In particular, specific markers are used to separate the messages sent to the central node (on the internal protocol).