FR 3078738 A1 20190913 FR 1900170 A 20190108 Description Titre de l'invention : Utilisation de serveurs existants dans un envi- ronnement de puits de forage comme sources de données pour les serveurs de transmission Domaine technique [0001] La présente invention concerne, d'une manière générale, des systèmes et des procédés qui doivent être utilisés dans un environnement de puits de forage. Plus spécifiquement, mais en aucun cas de façon limitative, la présente invention concerne l'utilisation de serveurs existants comme sources de données pour les serveurs de transmission pour fournir un accès aux données concernant un environnement de puits de forage. Contexte [0002] Les données provenant d'un environnement de puits de forage peuvent être utilisées pour surveiller l'environnement, prendre des décisions par rapport à l'environnement et planifier d'autres puits de forage, entre autres. Une source de données, telle qu'un serveur de données, au niveau d'un environnement de puits de forage peut stocker des données provenant de divers capteurs et les données peuvent être accessibles à d'autres dispositifs. On peut accéder aux données à distance à travers un protocole de demande et de réponse par lequel le client envoie une demande pour certains types de données et la source de données répond à la demande avec les données. Le dispositif est souvent localisé à de grandes distances de la source de données et l'échange de données se fait souvent sur un réseau étendu (WAN) pour lequel il peut y avoir des délais pour l'accès aux données. Brève description des figures [0003] [fig. 1] La figure 1 est un schéma d'un exemple d'un environnement de réseau utilisé pour fournir un accès aux données concernant un environnement de puits de forage selon un aspect de l'invention. [0004] [fig.2] La figure 2 est un schéma de principe d'un exemple d'un serveur de transmission qui peut être utilisé pour exécuter un code de programme pour l'utilisation des serveurs existants comme sources de données selon un aspect de l'invention. [0005] [fig.3] La figure 3 est un diagramme d'état d'une machine à état de serveur de transmission selon un aspect de l'invention. [0006] [fig.4] 2 La figure 4 est un organigramme d'un procédé pour l'utilisation de serveurs existants comme sources de données pour les serveurs de transmission selon un aspect de l'invention. [0007] [fig.5] La figure 5 est un organigramme d'un procédé pour l'initiation d'une configuration de transmission de données entre un serveur de transmission et un serveur existant selon un aspect de l'invention. [0008] [fig.6] La figure 6 est un organigramme d'un procédé d'interrogation de données entre un serveur de transmission et un serveur existant selon un aspect de l'invention. Description détaillée [0009] Certains aspects et caractéristiques de la présente invention concernent l'utilisation d'un serveur existant comme source de données pour un serveur de transmission pour fournir un accès aux données concernant un environnement de puits de forage. Un dispositif client peut envoyer une demande à travers un réseau étendu (WAN) dans un format de transmission de données vers un serveur de transmission pour accéder à des données de l'environnement de puits de forage dans un serveur de base de données. Le serveur de transmission, utilisant un protocole de demande et de réponse, peut transmettre des données dans un format standardisé sur un réseau local (LAN) à un serveur existant, qui peut utiliser un protocole de demande et de réponse différent. Le serveur existant peut demander et récupérer des données concernant un environnement de puits de forage à partir d'un serveur de base de données. Le serveur de transmission peut transmettre les données de l'environnement de puits de forage, relayées par le serveur existant, dans un format de transmission au dispositif client. L'émission-réception de données à travers les protocoles de demande et de réponse d'un serveur existant sur un WAN peut être chronophage, augmentant le délai pour qu'un dispositif client reçoive les données demandées. Comparativement, la transmission de données sur un WAN à travers un serveur de transmission lors de l'exécution de protocoles de demande et de réponse de serveur existants plus lents à travers un LAN peut réduire la latence globale dans la voie de communication. En outre, la mise en oeuvre d'un serveur de transmission peut fournir un gain en efficacité sur la quantité totale de données traversant le réseau : un protocole de demande et de réponse requiert généralement l'envoi d'informations d'état sur chaque demande de sorte que le serveur puisse retourner les données appropriées, ce qui demande plus de largeur de bande. [0010] Dans certains exemples, le serveur de transmission peut être un adaptateur entre les dispositifs client et les serveurs existants qui n'utilisent pas les protocoles standards les 3 plus récents de l'industrie. Le serveur de transmission peut établir la communication entre deux protocoles différents pour permettre aux dispositifs client d'obtenir des données provenant des serveurs existants. Le serveur de transmission intermédiaire peut permettre une utilisation continue des serveurs existants sans avoir à développer un serveur totalement nouveau ou à refactoriser un serveur existant pour communiquer à travers les protocoles les plus récents. En l'absence d'échange d'informations du serveur de transmission à travers divers protocoles, les clients pourraient utiliser des ressources considérables pour restructurer et reconstruire des flux de données à travers des serveurs existants pour communiquer avec les serveurs utilisant le protocole le plus récent. L'emploi de serveurs de transmission utilisant des serveurs existants comme sources de données peut permettre la transmission automatique de données aux dispositifs client, contrairement au fait que le dispositif client demande et reçoit des données directement à partir des serveurs existants, ce qui pourrait constituer un processus plus lent. [0011] Dans certains exemples, le serveur de transmission et le serveur existant peuvent être couplés en communication à travers un LAN, et le serveur de transmission et le dispositif client peuvent être couplés en communication à travers un WAN. Le couplage en communication d'un serveur de transmission à un serveur existant à travers un LAN, en comparaison à un WAN, peut réduire le temps de transfert de données vers un dispositif client. Le protocole de demande et de réponse du serveur existant, qui fonctionne moins efficacement qu'un protocole de transmission, est réalisé localement à travers un LAN et le protocole de transmission est réalisé à travers un WAN. Les dispositifs client sont généralement connectés aux sources de données à travers un WAN, qui est généralement plus lent qu'un LAN, par nécessité (par ex., emplacement distant ou hors site). Il peut être souhaitable dans le contexte de la performance globale du système d'implémenter davantage de protocoles de demande et de réponse chronophages à travers un LAN, alors que les protocoles de serveur de transmission plus rapides peuvent être implémentés à travers le WAN plus lent mais nécessaire. Dans certains exemples, le dispositif client peut être localisé à l'intérieur du même LAN que le serveur de transmission et le serveur existant. Dans d'autres exemples, les protocoles de demande et de réponse peuvent être réalisés à travers un WAN, en perdant l'avantage de la latence réduite des exemples précédents mais en gardant la capacité d'assurer les protocoles de communication entre le dispositif client et le serveur existant. Par exemple, le dispositif client est couplé en communication au serveur de transmission à travers un WAN ou un LAN et le serveur de transmission est couplé en communication au serveur existant à travers un WAN. [0012] Dans certains exemples, des versions du langage de balisage standard de transfert d'informations de puits (WITSML) peuvent être utilisées. Le WITSML est une norme 4 d'échange de données pour spécifier et échanger des données pour des puits et des opérations et objets concernant les puits, tels que le forage, la diagraphie et la diagraphie de boue. Le WITSML peut procurer un flux sans heurts et au bon moment des données de puits entre des opérateurs et des entreprises de services pour accélérer et améliorer la prise de décision. Le WITSML 2.0 a été développé pour améliorer les transmissions de données dans l'industrie du pétrole. Le protocole sous-jacent du WITSML 2.0 est le protocole de transfert énergétique (ETP), qui peut fonctionner à des vitesses d'échange de données plus rapides que des versions précédentes du WITSML. L'ETP définit un mécanisme de transmission de sorte que les récepteurs de données ne soient pas obligés d'interroger des données et peuvent recevoir de nouvelles données aussitôt qu'elles sont disponibles à partir d'un fournisseur de données. [0013] Un exemple d'un serveur de transmission peut être un serveur utilisant le WITSML 2.0 utilisant l'ETP. Le serveur de transmission peut permettre la transmission de données de sorte que les données soient transmises à un dispositif client en réponse à la disponibilité des données, sans que le dispositif client soit obligé de demander spécifiquement les données (c.-à-d., les données sont automatiquement transmises au dispositif client par le serveur de transmission lorsque les données sont disponibles à partir d'une source de données). [0014] Un exemple d'un serveur existant peut être un serveur WITSML 1.x, dans lequel « 1.x » représente une quelconque version de WITSML 1.0 avant WITSML 2.0 (par ex., WITSML 1.0, WITSML 1.3.1, WITSML 1.4.1.1, etc.). Un dispositif client ou un serveur de transmission peut initier une demande pour des données à travers un protocole de demande et de réponse pour obtenir des informations provenant d'un serveur existant. [0015] Dans certains exemples, le protocole de demande et de réponse utilisé par le serveur de transmission pour communiquer avec un serveur existant peut comprendre les protocoles d'accès à objet simple (SOAP). Le protocole SOAP est une spécification de protocole permettant l'échange d'informations structurées dans l'implémentation de services Web dans des réseaux informatiques. Le SOAP utilise un format de message d'ensemble de données XML, et repose sur des protocoles de couche d'application, tels que le protocole de transfert hypertexte (HTTP) ou le protocole de transfert de courrier simple (SMTP), pour la négociation et la transmission de message. Le SOAP peut permettre l'exécution de processus sur des systèmes d'exploitation distincts (tels que Windows et Linux) pour communiquer avec un langage de balisage extensible (XML), et peut permettre aux clients d'invoquer des services Web et de recevoir des réponses indépendamment du langage et des plateformes. Dans certains exemples, le protocole de demande et de réponse utilisé par le serveur existant peut être basé sur le protocole de procédure à distance (RPC), qui est distinct du SOAP. Un RPC peut exécuter une procédure dans un espace d'adresse différent, généralement sur un autre ordinateur sur un réseau partagé, qui est codé comme s'il s'agissait d'un appel de procédure local. [0016] Dans certains exemples, le serveur de transmission peut générer une tâche d'interrogation correspondant à un canal spécifique du serveur existant. La tâche d'interrogation du serveur de transmission peut transmettre des instructions au serveur existant. La tâche d'interrogation peut comprendre des instructions pour ordonner au serveur existant de relayer des données à l'intérieur d'un serveur de base de données vers le serveur de transmission. En réponse à la réception des instructions de la tâche d'interrogation à travers une demande de données consécutive provenant du serveur de transmission, le serveur existant peut relayer des données à l'intérieur du serveur de base de données vers le serveur de transmission lorsqu'elles sont disponibles. En réponse à la réception de données dans le serveur de base de données provenant du serveur existant, le serveur de transmission peut déterminer si des données sont nouvelles ou modifiées. [0017] Dans certains exemples, le serveur de transmission peut convertir les données provenant d'un dispositif client en un format de données standardisé. Un exemple de format de données standardisé est un format WITSML 1.x. Le serveur de transmission peut convertir les données provenant d'un serveur existant en un format de données de transmission. Le format de données de transmission peut être un format WITSML 1.x utilisant l'ETP. Les conversions entre un format de données de transmission et un format de données standardisé peuvent permettre au serveur de transmission de transmettre des données dans un format compréhensible du dispositif client vers le serveur existant et du serveur existant vers le dispositif client. [0018] Ces exemples illustratifs sont donnés pour introduire le lecteur à l'objet général de la présente invention et ne sont pas destinés à limiter la portée des concepts divulgués. Les sections suivantes décrivent diverses caractéristiques et exemples supplémentaires en référence aux figures dans lesquelles des chiffres identiques désignent des éléments identiques, et les descriptions de direction servent à décrire les aspects illustratifs mais, comme les aspects illustratifs, ne doivent pas servir à limiter la présente invention. [0019] La figure 1 illustre un schéma d'un environnement de réseau utilisé pour fournir un accès aux données concernant un environnement de puits de forage selon un exemple. Un dispositif client 102 peut être couplé en communication à travers un WAN 116 à un serveur de transmission 104, qui peut être couplé en communication au serveur 106 à travers un LAN 114. Un serveur 106 peut être un « serveur existant » tel que décrit dans l'un quelconque des exemples précédents. Le dispositif client 102, le serveur de transmission 104 et le serveur 106 peuvent être couplés en communication dans une configuration de réseau tel que décrit dans l'un quelconque des exemples précédents. 6 [0020] Le serveur 106 peut être couplé en communication à un serveur de base de données 108, qui peut être couplé en communication à un système d'acquisition en temps réel 110. Dans certains exemples, le serveur 106 peut être localisé à proximité du serveur de base de données 108, connecté au serveur de base de données à travers le LAN 114. Dans d'autres exemples, le serveur 106 peut être localisé à distance du serveur de base de données 108 et connecté à travers un WAN. Le système d'acquisition en temps réel 110 peut être couplé en communication à un système de puits 112. Le système d'acquisition en temps réel 110 peut être localisé à proximité ou à l'intérieur de l'environnement du système de puits 112, ou localisé à distance et couplé en communication aux dispositifs à l'intérieur du système de puits 112 à travers un réseau. Les données concernant le système de puits 112 peuvent être reçues par le système d'acquisition en temps réel 110 provenant du système de puits 112. Le serveur de base de données 108 peut recevoir des données concernant le système de puits 112 provenant du système d'acquisition en temps réel 110. Le serveur de base de données 108 peut stocker de nouvelles données ou mettre à jour des données existantes en réponse à la réception de données provenant du système d'acquisition en temps réel 110. Dans certains exemples, le serveur de base de données 108 peut être localisé à proximité du système d'acquisition en temps réel 110, connecté au système d'acquisition en temps réel 110 à travers le LAN 114. Dans d'autres exemples, le serveur de base de données 108 peut être localisé à distance du système d'acquisition en temps réel 110 et connecté à travers un WAN. [0021] Le dispositif client 102 peut émettre une demande et recevoir des réponses provenant du serveur de transmission 104 dans un format de données de transmission. Le serveur de transmission 104 peut interpréter la demande provenant du dispositif client 102, convertir la demande et les données associées en un format de données standardisé, et transmettre la demande au serveur 106. Le serveur 106 peut recevoir la demande en un format de données standardisé à partir du serveur de transmission 104. La demande peut ordonner au serveur 106 de demander des données auprès du serveur de base de données 108. Le serveur de base de données 108 peut transmettre n'importe quelles données au serveur 106 en réponse à la demande provenant du serveur 106. En réponse à la réception des données demandées provenant du serveur de base de données 108, le serveur 106 peut formater les données en un format de données standardisé et transmettre les données au serveur de transmission 104. En réponse à la réception des données en un format de données standardisé provenant du serveur 106, le serveur de transmission 104 peut convertir les données en un format de données de transmission et transmettre les données au dispositif client 102. À travers les connexions précédemment décrites, le dispositif client 102, qui effectue les demandes initiales en un format non interprétable par un serveur de format de données standardisé (par ex., le 7 serveur 106), peut demander et indirectement recevoir des données provenant d'un serveur de base de données 108 à travers le serveur de transmission 104 et le serveur 106. Le serveur de transmission 104 peut agir comme un intermédiaire entre le dispositif client 102 et le serveur 106, communiquant avec le dispositif client 102 et le serveur 106 à travers des protocoles de communication distincts et convertissant les données et les demandes en formats de données appropriés. [0022] La figure 2 est un schéma de principe d'un exemple d'un serveur de transmission 104 qui peut être utilisé pour exécuter un code de programme pour l'utilisation des serveurs existants comme sources de données selon un exemple. Le serveur de transmission 104 peut comprendre un processeur 202, un bus 204, un port de communication 206 et une mémoire 208. Dans certains exemples, les composants illustrés dans la figure 2 (par ex., le processeur 202, le bus 204, le port de communication 206 et la mémoire 208) peuvent être intégrés en une structure unique. Par exemple, les composants peuvent être à l'intérieur d'un boîtier unique. Dans d'autres exemples, les composants illustrés dans la figure 2 peuvent être répartis (par ex., dans des boîtiers distincts) et en communication électrique les uns avec les autres. [0023] Le processeur 202 peut exécuter une ou plusieurs opérations pour la mise en oeuvre de certains exemples. Le processeur 202 peut exécuter des instructions stockées dans la mémoire 208 pour réaliser les opérations. Le processeur 202 peut comprendre un dispositif de traitement ou de multiples dispositifs de traitement. Des exemples non limitatifs du processeur 202 comprennent un réseau de portes programmables par l'utilisateur (FPGA), un circuit intégré spécifique à une application (ASIC), un microprocesseur, etc. [0024] Le processeur 202 peut être couplé en communication à la mémoire 208 à travers le bus 204. La mémoire non volatile 208 peut comprendre un quelconque type de dispositif de mémoire qui conserve les informations stockées lorsqu'il est éteint. Des exemples non limitatifs de la mémoire 208 comprennent une mémoire morte programmable et effaçable électriquement (« EEPROM »), une mémoire flash, ou un quelconque autre type de mémoire non-volatile. Dans certains exemples, au moins une partie de la mémoire 208 peut comprendre un support à partir duquel le processeur 202 peut lire les instructions. Un support lisible par ordinateur peut comprendre des dispositifs de stockage électroniques, optiques, mécaniques ou d'autres dispositifs de stockage qui peuvent fournir au processeur 202 des instructions lisibles par ordinateur ou d'autres codes de programme. Des exemples non limitatifs de support lisible par ordinateur comprennent (mais sans limitation) un ou des disques magnétiques, une ou des puces de mémoire, une ROM, une mémoire à accès aléatoire (RAM), un ASIC, un processeur configuré, un stockage optique ou un quelconque autre support à partir duquel un processeur d'ordinateur peut lire des instructions. Les instructions peuvent 8 comprendre des instructions spécifiques à un processeur générées par un compilateur ou un interpréteur à partir du code écrit dans un quelconque langage de programmation informatique, comprenant, par ex., C, C++, C#, etc. [0025] La mémoire 208 peut comprendre un code de programme pour un module de gestionnaire de session 210, un module de transmission de canal 212, un module de message du serveur 214 et un module de conversion 216. Le module de gestionnaire de session 210, en réponse à la réception d'une demande de communication à travers le port de communication 206, peut créer et configurer des canaux de communication en préparation à la transmission de données en implémentant les protocoles d'établissement de liaison nécessaires. Le module de gestionnaire de session 210 peut initier des canaux de communication entre le serveur de transmission 104 et le dispositif client 102 et le serveur de transmission 104 et le serveur 106. Le module de transmission de canal 212 peut configurer des canaux de communication pour transmettre des données entre le serveur de transmission 104 et le serveur 106 en transmettant des demandes de début d'interrogation et d'arrêt d'interrogation au serveur 106 à travers le port de communication 206. Le module de message du serveur 214 peut traiter des protocoles de demande et de réponse utilisés par le serveur de transmission 104 pour communiquer avec le serveur 106. Le protocole de demande et de réponse utilisé par le serveur de transmission 104 pour communiquer avec le serveur 106 peut comprendre les demandes et réponses SOAP. Le module de message du serveur 214 peut envoyer une demande et recevoir une réponse provenant du serveur 106 à travers le port de communication 206. Le module de conversion 216 peut convertir des demandes en un format de données de transmission, provenant du dispositif client 102, en demandes dans un format de données standardisé. Le module de conversion 216 peut convertir des réponses et des données en un format de données standardisé, provenant du serveur 106 en réponse à la demande par le dispositif client 102, en un format de données de transmission. [0026] La figure 3 est un diagramme d'état d'une machine à état de serveur de transmission 302 selon un exemple. Au niveau du bloc 304, le serveur de transmission 104 est à l'écoute active des dispositifs dans un réseau, ce qui peut être réalisé sur une URL bien connue. Au niveau du bloc 306, un client (par ex., un dispositif client 102) qui est en mesure de communiquer à travers des messages de transmission dans un format de données de transmission se connecte au serveur de transmission 104 et émet un message de session ouverte, qui peut être un message ETP de session ouverte. Le canal de communication entre le client et le serveur de transmission 104 est créé et configuré par le module de gestionnaire de session 210, qui peut implémenter un Protocole 0 ETP dans le bloc 310 pour traiter les procédures d'établissement de liaison initiales. Une fois connecté, comme illustré dans le bloc 308, le client peut émettre des messages 9 dans une session donnée. [0027] De multiples protocoles sont définis à l'intérieur de la machine à état de serveur de transmission 302 : le Protocole 0 dans le bloc 310, le protocole de transmission de canal dans le bloc 312, le protocole de serveur standard dans le bloc 314 et un quelconque autre protocole délimité comme protocole n dans le bloc 316. Les messages dans un format de données de transmission reçus par le serveur de transmission 104 sont relayés au module de transmission de canal 212 pour le traitement par le protocole de transmission de canal dans le bloc 312. Les messages dans un format de données standardisé reçus par le serveur de transmission 104 sont relayés au module de message du serveur 214 pour le traitement par le protocole de serveur standard dans le bloc 314. [0028] La figure 4 est un organigramme décrivant un procédé pour l'utilisation de serveurs existants comme sources de données pour les serveurs de transmission selon un exemple. [0029] Dans le bloc 402, le serveur de transmission 104 reçoit un message de serveur de transmission demandant des données auprès d'un serveur existant. Après l'établissement d'une voie de communication à travers le module de gestionnaire de session 210, un client (par ex., le dispositif client 102) peut envoyer un message de demande au serveur de transmission 104 dans un format de données de transmission, qui peut être un format WITSML 2.0. Le serveur de transmission 104 peut recevoir le message de demande à travers le port de communication 206. Le message de demande peut comprendre des instructions pour ordonner au serveur de transmission 104 d'établir un canal de communication de transmission avec le dispositif client 102 et pour générer une tâche d'interrogation pour continuellement demander des données auprès d'un serveur existant (par ex. , le serveur 106) sans autre demande de la part du dispositif client 102. [0030] Dans le bloc 404, le serveur de transmission 104 convertit le message de serveur de transmission reçu en un format de données standardisé. Le module de conversion 216 du serveur de transmission 104 peut convertir le message de demande reçu dans le bloc 402 provenant d'un format de données de transmission en un format de données standardisé, qui peut être un format WITSML 1.x. La conversion du message de demande d'un format de données de transmission en un format de données standardisé peut permettre la transformation des données du message de demande en un format compris par le serveur 106, qui utilise des protocoles différents de celui du dispositif client 102. [0031] Dans le 406, le serveur de transmission 104 transmet le message de demande converti au serveur 106. Le port de communication 206 du serveur de transmission 104 peut transmettre le message de demande en un format de données standardisé vers le serveur 106. Le message de demande converti peut ordonner au serveur 106 de recevoir les données demandées provenant du serveur de base de données 108, qui peuvent ensuite être transmises vers le serveur de transmission 104. Le message de demande converti peut être transmis par le serveur de transmission 104 à l'aide d'une demande SOAP générée par le module de message du serveur 214, et ensuite reçu par le serveur 106 qui peut implémenter le protocole WITSML 1.x basé sur un RPC. Le message de demande converti peut comprendre des instructions pour interroger le serveur 106 générées par le module de transmission de canal 212. [0032] En faisant toujours référence au bloc 406, un canal du module de message du serveur 214 peut être verrouillé, de sorte que le serveur de transmission 104 ne prenne aucune autre mesure par rapport au serveur 106 qui a reçu le message de demande converti, jusqu'à ce qu'une réponse appropriée soit reçue à partir du serveur 106. Une fois qu'une réponse appropriée est reçue à partir du serveur 106, le module de message du serveur 214 peut déverrouiller ce canal spécifique pour permettre d'autres mesures par le serveur de transmission 104. Le serveur de transmission 104 peut toujours créer et faire fonctionner des canaux de communication indépendants supplémentaires contrôlés par le module de message du serveur 214 ; le module de message du serveur 214 peut établir et verrouiller/déverrouiller des canaux distincts pour la communication avec de multiples serveurs existants indépendamment du statut des autres canaux. [0033] Dans le bloc 408, le serveur de transmission 104 reçoit un message de réponse provenant du serveur 106 contenant les données demandées en un format de données standardisé. En réponse à la transmission du message de demande en un format de données standardisé par le serveur de transmission 106, le serveur 106 peut communiquer avec le serveur de base de données 108 pour recevoir les données demandées provenant du serveur de base de données 108, convertir les données reçues en un format de données standardisé, s'il y a lieu, et transmettre les données demandées vers le serveur de transmission 104. Ce processus peut se produire indéfiniment jusqu'à réception d'une instruction contraire, comme il est également décrit dans la figure 6, permettant au serveur 106 de continuellement transmettre des données au serveur de transmission 104. Le serveur de transmission 104 peut recevoir les données demandées à l'aide d'une réponse SOAP interprétable par le module de message du serveur 214. En outre, dans le bloc 408, le serveur de transmission 104 peut déterminer si l'une quelconque des données provenant du serveur 106 est nouvelle ou modifiée par rapport aux versions précédentes des données. [0034] Dans le bloc 410, le serveur de transmission 104 convertit le message de réponse provenant du serveur 106 en un format de données de transmission. Le module de conversion 216 du serveur de transmission 104 peut convertir le message de réponse reçu au niveau du bloc 408 provenant d'un format de données standardisé en un format 11 de données de transmission, qui peut être un format WITSML 2.0. La conversion du message de demande d'un format de données de transmission en un format de données standardisé peut permettre la transformation des données du message de réponse en un format compris par le dispositif client 102, qui utilise des protocoles différents de ceux du serveur 106. [0035] Dans le bloc 412, le serveur de transmission 104 transmet le message de réponse en un format de données de transmission vers le dispositif client 102. Le message de réponse transmis par le serveur de transmission 104 en un format de données de transmission peut comprendre une quelconque donnée provenant du serveur de base de données 108 que le dispositif client 102 a demandée dans le bloc 402. [0036] La figure 5 est un organigramme décrivant un procédé pour l'initiation d'une confi- guration de transmission de données entre un serveur de transmission et un serveur existant selon un exemple. [0037] Dans le bloc 502, le serveur de transmission 104 reçoit un message du serveur de transmission demandant des données auprès du serveur 106 à travers un canal spécifique. Le dispositif client 102 peut demander la transmission d'un quelconque canal que le serveur de transmission 104 transmet comme disponible pour la transmission. [0038] Dans le bloc 504, le serveur de transmission 104 cartographie le canal demandé sur un objet et un canal correspondants dans le serveur 106. En réponse à la réception du message du serveur de transmission dans le bloc 502, le module de transmission de canal 212 du serveur de transmission 104 peut déterminer un objet et un canal appropriés du serveur 106 correspondant aux données dans le message de demande provenant du dispositif client 102. Le serveur de transmission 104 peut cartographier un canal dédié au dispositif client 102 avec l'objet et le canal déterminés du serveur 106. La cartographie du canal du dispositif client 102 avec le canal du serveur 106 peut permettre au serveur de transmission 104 d'établir une voie de communication simplifiée avant la réception/l'émission des données demandées du serveur 106 vers le dispositif client 102. Le canal du serveur 106 peut être cartographié sur des données ou des canaux de données spécifiques dans le serveur de base de données 108 après l'instruction du serveur de transmission 104, ou par défaut avant toute communication avec le serveur de transmission 104. [0039] Dans le bloc 506, le serveur de transmission 104 génère une tâche pour interroger le serveur 106 concernant des changements à l'intérieur du canal demandé. Le module de transmission de canal 212 peut générer une tâche pour interroger le canal demandé du serveur 106, qui peut être cartographié pour des données spécifiques à l'intérieur du serveur de base de données 108. Les instructions de la tâche d'interrogation peuvent être comprises dans le message de demande en un format de données standardisé tel 12 qu'il est décrit dans le bloc 406 de la figure 4. La tâche d'interrogation peut être générée en réponse à la réception d'un message « channelstreamingstart ». Une fois générée, la tâche d'interrogation peut être initiée, permettant au serveur de transmission 104 de demander continuellement des données en temps réel auprès du serveur 106 à travers des messages de demandes consécutifs jusqu'à ce que le serveur de transmission 104 reçoive une instruction d'arrêt d'interrogation. [0040] Dans le bloc 508, le serveur de transmission 104 reçoit un message du serveur de transmission provenant du dispositif client 102 demandant au serveur de transmission 104 d'arrêter l'interrogation du serveur 106. Lors de la réception d'une instruction d'arrêt d'interrogation provenant du dispositif client 102, le serveur de transmission peut arrêter la génération de messages de demande pour des données en temps réel à travers un canal correspondant à un serveur spécifique 106 et un serveur de base de données 108. Les instructions d'arrêt d'interrogation peuvent être un message « channelstreamingstop ». Un dispositif client 102 peut à nouveau initier le processus d'interrogation en transmettant un nouveau message de demande du serveur de transmission au serveur de transmission 104 tel qu'il est décrit dans le bloc 402. [0041] La figure 6 est un organigramme décrivant un procédé d'interrogation de données entre un serveur de transmission et un serveur existant selon un exemple. La description suivante des blocs 602, 604, 606, 608 et 610 fournit d'autres détails à l'exemple décrit dans le bloc 506 de la figure 5 pour la génération d'une tâche d'interrogation pour interroger les changements à l'intérieur d'un canal demandé. [0042] Dans le bloc 602, le serveur de transmission 104 génère une demande de serveur pour des données nouvelles ou modifiées provenant du serveur 106. Dans le cadre de la génération d'une tâche d'interrogation dans le bloc 506 à la demande du dispositif client 102, le serveur de transmission 104 peut générer une demande de serveur à transmettre au serveur 106. La demande de serveur (telle que décrite dans le bloc 406 de la figure 4) peut être dans un format de données standardisé, qui peut être un format WITSML 1.x. La demande de serveur au serveur 106 peut comprendre des instructions permettant au serveur 106 de surveiller des données dans un canal donné du serveur de base de données 108, et de transmettre les données au serveur de transmission 104. [0043] Dans le bloc 604, le serveur de transmission 104 transmet la demande de serveur au serveur 106. La demande de serveur peut être transmise par le serveur de transmission 104 à l'aide d'une demande SOAP, et ensuite reçue par le serveur 106, qui peut utiliser WITSML 1.x basé sur un RPC. [0044] Dans le bloc 606, le serveur de transmission 104 reçoit une réponse de serveur provenant du serveur 106. La tâche d'interrogation telle que décrite dans la figure 6 peut arrêter les processus d'interrogation jusqu'à ce que le serveur 106 retourne une réponse à la demande du serveur transmise dans le bloc 604. Le serveur de 13 transmission 104 peut déterminer si l'une quelconque des données reçues dans la réponse du serveur provenant du serveur 106 sont nouvelles ou modifiées en comparaison avec les versions précédentes des données. [0045] Dans le bloc 608, le serveur de transmission 104 transmet des données nouvelles ou modifiées dans la réponse du serveur au dispositif client 102. Les données nouvelles ou modifiées peuvent être converties en un format de données de transmission pour la transmission vers le dispositif client 102. Si le serveur de transmission 104 détermine que la réponse du serveur ne contient aucune donnée nouvelle ou modifiée, le serveur de transmission 104 pourrait n'envoyer aucune information au dispositif client 102, et peut procéder vers le bloc 610. [0046] Dans le bloc 610, la tâche d'interrogation attend pendant un temps d'intervalle d'interrogation prédéterminé. Le temps d'intervalle d'interrogation peut être un quelconque temps prédéterminé défini par un utilisateur. Le temps d'intervalle d'interrogation peut également être un quelconque temps capable à la fois de minimiser l'usage de la bande passante causé par des messages de demande et de réponse du serveur répétitifs et de minimiser le temps pour le dispositif client 102 de recevoir des données nouvelles ou modifiées lors du stockage initial des données dans le serveur de base de données 108. Après avoir attendu la durée du temps d'intervalle d'interrogation, la tâche d'interrogation du serveur de transmission 104 peut commencer un nouveau cycle de demande de données auprès du serveur 106 en initiant à nouveau le processus décrit dans les blocs 602, 604, 606, 608 et 610, en commençant dans le bloc 602. [0047] Dans le bloc 612, le serveur de transmission 104 met fin à l'interrogation après réception d'un message du serveur de transmission provenant du dispositif client 102 demandant au serveur de transmission 104 d'arrêter l'interrogation du serveur 106. Sauf en cas d'instruction contraire à travers un message de demande d'arrêt d'interrogation provenant du dispositif client 102, le serveur de transmission 104 peut réaliser indéfiniment les opérations d'interrogation en boucle comme il est décrit dans la figure 6 et décrit dans les blocs 602, 604, 606, 608 et 610. [0048] Dans certains aspects, systèmes, dispositifs et procédés pour l'utilisation de serveurs existants comme sources de données pour les serveurs de transmission selon l'un ou plusieurs des exemples suivants : [0049] L'Exemple 1 est un système comprenant : un serveur qui peut être couplé en commu- nication à un serveur de base de données et comprenant un code stocké sur un support non transitoire lisible par ordinateur et exécutable par un processeur pour transmettre des données concernant un environnement de puits de forage au serveur de base de données et un serveur de transmission utilisant un protocole de demande et de réponse ; et le serveur de transmission comprenant : un port de communication réseau ; 14 un processeur et un support non transitoire lisible par ordinateur comprenant un code qui est exécutable par le processeur pour amener le serveur de transmission à fournir à un dispositif client un accès aux données dans le serveur de base de données sous forme de données de transmission en : transmettant, à travers le port de communication réseau, des données dans un format de données standardisé au serveur ; et en transmettant, à travers le port de communication réseau, des données en format de données de transmission à un dispositif client. [0050] L'Exemple 2 est le système de l'Exemple 1, dans lequel le serveur de transmission est un serveur de protocole de transfert énergétique (ETP), dans lequel le serveur est un serveur de langage de balisage standard de transfert d'informations de puits (WITSML). [0051] L'Exemple 3 est le système de l'Exemple 2, dans lequel le format de données standardisé est un format WITSML version 1 et le format de données de transmission est un format ETP faisant en sorte que les données peuvent être transmises au dispositif client en réponse à la disponibilité des données sans nécessiter l'interrogation des données par le dispositif client. [0052] L'Exemple 4 est le système de l'Exemple 1, dans lequel le serveur de transmission et le serveur peuvent être couplés en communication à travers un réseau local, et le serveur de transmission et le dispositif client peuvent être couplés en communication à travers un réseau étendu. [0053] L'Exemple 5 est le système de l'Exemple 1, le support non transitoire lisible par or- dinateur comprenant également un code qui est exécutable par le processeur pour amener le serveur de transmission à recevoir des données du serveur en : générant une tâche d'interrogation correspondant à un canal du serveur, la tâche d'interrogation comprenant des instructions de la tâche d'interrogation pour ordonner au serveur de relayer des données nouvelles ou modifiées à l'intérieur du serveur de base de données vers le serveur de transmission ; en transmettant, à travers le port de communication réseau, des instructions de la tâche d'interrogation au serveur ; et en recevant, à travers le port de communication réseau, des données nouvelles ou modifiées du canal à partir du serveur en réponse aux instructions de la tâche d'interrogation. [0054] L'Exemple 6 est le système de l'Exemple 1, le support non transitoire lisible par or- dinateur comprenant également un code qui est exécutable par le processeur pour amener le serveur de transmission à fournir à un dispositif client un accès aux données dans le serveur de base de données sous forme de données de transmission en : convertissant des données provenant du dispositif client en format de données standardisé ; et en convertissant des données provenant du serveur en format de données de transmission. [0055] L'Exemple 7 est le système de l'Exemple 1, dans lequel le protocole de demande et de réponse qui peut être utilisé par le serveur de transmission pour transmettre des données au serveur comprend des protocoles d'accès à objet simple, et le protocole de demande et de réponse du serveur comprend des appels de procédure à distance. [0056] L'Exemple 8 est un serveur de transmission comprenant : un port de communication réseau qui peut être couplé en communication à un serveur qui peut être couplé en communication à un serveur de base de données ; un processeur ; et un support non transitoire lisible par ordinateur comprenant un code qui est exécutable par le processeur pour amener le serveur de transmission à fournir à un dispositif client un accès aux données concernant un environnement de puits de forage dans le serveur de base de données sous forme de données de transmission en : transmettant, à travers le port de communication réseau, des données dans un format de données standardisé au serveur en utilisant un protocole de demande et de réponse ; et en transmettant, à travers le port de communication réseau, des données dans un format de données de transmission à un dispositif client. [0057] L'Exemple 9 est le serveur de transmission de l'Exemple 8, dans lequel le serveur de transmission est un serveur de protocole de transfert énergétique (ETP), dans lequel le serveur est un serveur de langage de balisage standard de transfert d'informations de puits (WITSML). [0058] L'Exemple 10 est le serveur de transmission de l'Exemple 9, dans lequel le format de données standardisé est un format WITSML version 1 et le format de données de transmission est un format ETP faisant en sorte que les données peuvent être transmises au dispositif client en réponse à la disponibilité des données sans nécessiter l'interrogation des données par le dispositif client. [0059] L'Exemple 11 est le serveur de transmission de l'Exemple 8, dans lequel le serveur de transmission et le serveur peuvent être couplés en communication à travers un réseau local, et le serveur de transmission et le dispositif client peuvent être couplés en communication à travers un réseau étendu. [0060] L'Exemple 12 est le serveur de transmission de l'Exemple 8, le support non transitoire lisible par ordinateur comprenant également un code qui est exécutable par le processeur pour amener le serveur de transmission à recevoir des données du serveur en : générant une tâche d'interrogation correspondant à un canal du serveur, la tâche d'interrogation comprenant des instructions de la tâche d'interrogation pour indiquer au serveur de relayer des données nouvelles ou modifiées à l'intérieur du serveur de base de données vers le serveur de transmission ; en transmettant, à travers le port de communication réseau, des instructions de la tâche d'interrogation au serveur ; et en recevant, à travers le port de communication réseau, des données nouvelles ou modifiées du canal à partir du serveur en réponse aux instructions de la tâche d'interrogation. 16 [0061] L'Exemple 13 est le serveur de transmission de l'Exemple 8, le support non transitoire lisible par ordinateur comprenant également un code qui est exécutable par le processeur pour amener le serveur de transmission à fournir à un dispositif client un accès aux données dans le serveur de base de données sous forme de données de transmission en : convertissant des données provenant du dispositif client en format de données standardisé ; et en convertissant des données provenant du serveur en format de données de transmission. [0062] L'Exemple 14 est le serveur de transmission de l'Exemple 8, dans lequel le protocole de demande et de réponse qui peut être utilisé par le serveur de transmission pour transmettre des données au serveur comprend des protocoles d'accès à objet simple, et le protocole de demande et de réponse du serveur comprend des appels de procédure à distance. [0063] L'Exemple 15 est un procédé comprenant : la réception, par un serveur de transmission, d'une demande provenant d'un dispositif client pour accéder à des données concernant un environnement de puits de forage dans un serveur de base de données qui est couplé en communication à un serveur qui est couplé en communication au serveur de transmission ; la transmission, à travers le serveur de transmission, des données dans un format de données standardisé au serveur en utilisant un protocole de demande et de réponse ; et la transmission, à travers le serveur de transmission et dans un format de données de transmission, des données à partir du serveur de base de données à un dispositif client. [0064] L'Exemple 16 est le procédé de l'Exemple 15, dans lequel le serveur de transmission est un serveur de protocole de transfert énergétique (ETP), dans lequel le serveur est un serveur de langage de balisage standard de transfert d'informations de puits (WITSML). [0065] L'Exemple 17 est le procédé de l'Exemple 16, dans lequel le format de données standardisé est un format WITSML version 1 et le format de données de transmission est un format ETP faisant en sorte que les données sont transmises au dispositif client en réponse à la disponibilité des données sans nécessiter l'interrogation des données par le dispositif client. [0066] L'Exemple 18 est le procédé de l'Exemple 15, dans lequel le serveur de transmission et le serveur sont couplés en communication à travers un réseau local, et le serveur de transmission et le dispositif client sont couplés en communication à travers un réseau étendu. [0067] L'Exemple 19 est le procédé de l'Exemple 15, comprenant également : la conversion des données provenant du dispositif client en format de données standardisé ; la génération, à travers le serveur de transmission, d'une tâche d'interrogation correspondant à un canal du serveur en réponse à la réception de données provenant du dispositif 17 client, la tâche d'interrogation comprenant les instructions de la tâche d'interrogation pour ordonner au serveur de relayer des données nouvelles ou modifiées dans le serveur de base de données vers le serveur de transmission ; la transmission, à travers le port de communication réseau, des instructions de la tâche d'interrogation vers le serveur en format de données standardisé ; la réception, à travers le port de communication réseau, de données nouvelles ou modifiées du canal provenant du serveur en réponse aux instructions de la tâche d'interrogation ; et la conversion des données provenant du serveur en format de données de transmission. [0068] L'Exemple 20 est le procédé de l'Exemple 15, dans lequel le protocole de demande et de réponse qui peut être utilisé par le serveur de transmission pour transmettre des données au serveur comprend des protocoles d'accès à objet simple, et le protocole de demande et de réponse du serveur comprend des appels de procédure à distance. [0069] L'Exemple 21 est un serveur de transmission comprenant : un port de communication réseau qui peut être couplé en communication à un serveur qui peut être couplé en communication à un serveur de base de données ; un processeur ; et un support non transitoire lisible par ordinateur comprenant un code qui est exécutable par le processeur pour amener le serveur de transmission à fournir à un dispositif client un accès aux données concernant un environnement de puits de forage dans le serveur de base de données sous forme de données de transmission en : transmettant, à travers le port de communication réseau, des données dans un format de données standardisé au serveur en utilisant un protocole de demande et de réponse ; et en transmettant, à travers le port de communication réseau, des données dans un format de données de transmission à un dispositif client. [0070] L'Exemple 22 est le serveur de transmission de l'Exemple 21, dans lequel le serveur de transmission est un serveur de protocole de transfert énergétique (ETP), dans lequel le serveur est un serveur de langage de balisage standard de transfert d'informations de puits (WITSML). [0071] L'Exemple 23 est le serveur de transmission de l'un quelconque des Exemples 21 et 22, dans lequel le format de données standardisé est un format WITSML version 1 et le format de données de transmission est un format ETP faisant en sorte que les données peuvent être transmises au dispositif client en réponse à la disponibilité des données sans nécessiter l'interrogation des données par le dispositif client. [0072] L'Exemple 24 est le serveur de transmission de l'un quelconque des Exemples 21 à 23, dans lequel le serveur de transmission et le serveur peuvent être couplés en communication à travers un réseau local, et le serveur de transmission et le dispositif client peuvent être couplés en communication à travers un réseau étendu. [0073] L'Exemple 25 est le serveur de transmission de l'un quelconque des Exemples 21 à 24, le support non transitoire lisible par ordinateur comprenant également un code qui 18 est exécutable par le processeur pour amener le serveur de transmission à recevoir des données du serveur en : générant une tâche d'interrogation correspondant à un canal du serveur, la tâche d'interrogation comprenant des instructions de la tâche d'interrogation pour ordonner au serveur de relayer des données nouvelles ou modifiées à l'intérieur du serveur de base de données vers le serveur de transmission ; en transmettant, à travers le port de communication réseau, des instructions de la tâche d'interrogation au serveur ; et en recevant, à travers le port de communication réseau, des données nouvelles ou modifiées du canal à partir du serveur en réponse aux instructions de la tâche d'interrogation. [0074] L'Exemple 26 est le serveur de transmission de l'un quelconque des Exemples 21 à 25, le support non transitoire lisible par ordinateur comprenant également un code qui est exécutable par le processeur pour amener le serveur de transmission à fournir à un dispositif client un accès aux données dans le serveur de base de données sous forme de données de transmission en : convertissant des données provenant du dispositif client en format de données standardisé ; et en convertissant des données provenant du serveur en format de données de transmission. [0075] L'Exemple 27 est le serveur de transmission de l'un quelconque des Exemples 21 à 26, dans lequel le protocole de demande et de réponse qui peut être utilisé par le serveur de transmission pour transmettre des données au serveur comprend des protocoles d'accès à objet simple, et le protocole de demande et de réponse du serveur comprend des appels de procédure à distance. [0076] L'Exemple 28 est le serveur de transmission de l'un quelconque des Exemples 21 à 27, dans lequel le serveur de transmission est dans un système qui comprend : le serveur qui peut être couplé en communication au serveur de base de données et qui comprend un code stocké sur un support non transitoire lisible par ordinateur et exécutable par un processeur pour transmettre des données concernant l'environnement du puits de forage au serveur de base de données et au serveur de transmission à l'aide d' un protocole de demande et de réponse. [0077] L'Exemple 29 est un procédé comprenant : la réception, par un serveur de transmission, d'une demande provenant d'un dispositif client pour accéder à des données concernant un environnement de puits de forage dans un serveur de base de données qui est couplé en communication à un serveur qui est couplé en communication au serveur de transmission ; la transmission, à travers le serveur de transmission, des données dans un format de données standardisé au serveur en utilisant un protocole de demande et de réponse ; et la transmission, à travers le serveur de transmission et dans un format de données de transmission, des données à partir du serveur de base de données à un dispositif client. [0078] L'Exemple 30 est le procédé de l'Exemple 29, dans lequel le serveur de transmission 19 est un serveur de protocole de transfert énergétique (ETP), dans lequel le serveur est un serveur de langage de balisage standard de transfert d'informations de puits (WITSML). [0079] L'Exemple 31 est le procédé de l'un quelconque des Exemples 29 à 30, dans lequel le format de données standardisé est un format WITSML version 1 et le format de données de transmission est un format ETP faisant en sorte que les données sont transmises au dispositif client en réponse à la disponibilité des données sans nécessiter l'interrogation des données par le dispositif client. [0080] L'Exemple 32 est le procédé de l'un quelconque des Exemples 29 à 31, dans lequel le serveur de transmission et le serveur sont couplés en communication à travers un réseau local, et le serveur de transmission et le dispositif client sont couplés en communication à travers un réseau étendu. [0081] L'Exemple 33 est le procédé de l'un quelconque des Exemples 29 à 32, comprenant également : la génération, à travers le serveur de transmission, d'une tâche d'interrogation correspondant à un canal du serveur, la tâche d'interrogation comprenant des instructions de la tâche d'interrogation pour ordonner au serveur de relayer des données nouvelles ou modifiées à l'intérieur du serveur de base de données vers le serveur de transmission ; la transmission, à travers le port de communication réseau, des instructions de la tâche d'interrogation au serveur ; et la réception, à travers le port de communication réseau, des données nouvelles ou modifiées du canal à partir du serveur en réponse aux instructions de la tâche d'interrogation. [0082] L'Exemple 34 est le procédé de l'un quelconque des Exemples 29 à 33, comprenant également : la conversion des données provenant du dispositif client en format de données standardisé ; et la conversion des données provenant du serveur en format de données de transmission. [0083] L'Exemple 35 est le procédé de l'un quelconque des Exemples 29 à 34, dans lequel le protocole de demande et de réponse qui peut être utilisé par le serveur de transmission pour transmettre des données au serveur comprend des protocoles d'accès à objet simple, et le protocole de demande et de réponse du serveur comprend des appels de procédure à distance. [0084] La description précédente de certains exemples, y compris les exemples illustrés, a été présentée dans un but illustratif seulement et il n'est pas envisagé que la description soit exhaustive ou qu'elle limite l'invention aux formes précises décrites. De nombreuses modifications, adaptations et utilisations de celle-ci seront apparentes à un spécialiste du domaine sans s'écarter de la portée de l'invention. [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]