BE1025976B1 - Dispositif pour traiter des données d'un matériel roulant - Google Patents
Dispositif pour traiter des données d'un matériel roulant Download PDFInfo
- Publication number
- BE1025976B1 BE1025976B1 BE2019/5150A BE201905150A BE1025976B1 BE 1025976 B1 BE1025976 B1 BE 1025976B1 BE 2019/5150 A BE2019/5150 A BE 2019/5150A BE 201905150 A BE201905150 A BE 201905150A BE 1025976 B1 BE1025976 B1 BE 1025976B1
- Authority
- BE
- Belgium
- Prior art keywords
- data
- remote
- data messages
- rolling stock
- messages
- Prior art date
Links
- 238000012545 processing Methods 0.000 title claims abstract description 193
- 238000005096 rolling process Methods 0.000 claims abstract description 178
- 238000010606 normalization Methods 0.000 claims abstract description 28
- 238000000034 method Methods 0.000 claims description 48
- 238000004891 communication Methods 0.000 claims description 44
- 230000006870 function Effects 0.000 claims description 40
- 230000008569 process Effects 0.000 claims description 29
- 238000001914 filtration Methods 0.000 claims description 20
- 238000010801 machine learning Methods 0.000 claims description 8
- 238000013136 deep learning model Methods 0.000 claims description 6
- 230000003137 locomotive effect Effects 0.000 description 19
- 238000012423 maintenance Methods 0.000 description 17
- 238000012544 monitoring process Methods 0.000 description 15
- 238000007726 management method Methods 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 10
- 238000013480 data collection Methods 0.000 description 10
- 238000004458 analytical method Methods 0.000 description 6
- 238000003745 diagnosis Methods 0.000 description 5
- XEEYBQQBJWHFJM-UHFFFAOYSA-N Iron Chemical compound [Fe] XEEYBQQBJWHFJM-UHFFFAOYSA-N 0.000 description 4
- 238000002955 isolation Methods 0.000 description 4
- 230000007257 malfunction Effects 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 239000000203 mixture Substances 0.000 description 4
- 239000000284 extract Substances 0.000 description 3
- 238000012417 linear regression Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 229910052742 iron Inorganic materials 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000003252 repetitive effect Effects 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000004378 air conditioning Methods 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000003066 decision tree Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 238000005339 levitation Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000306 recurrent effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L15/00—Indicators provided on the vehicle or train for signalling purposes
- B61L15/0018—Communication with or on the vehicle or train
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L15/00—Indicators provided on the vehicle or train for signalling purposes
- B61L15/0018—Communication with or on the vehicle or train
- B61L15/0027—Radio-based, e.g. using GSM-R
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L15/00—Indicators provided on the vehicle or train for signalling purposes
- B61L15/0018—Communication with or on the vehicle or train
- B61L15/0036—Conductor-based, e.g. using CAN-Bus, train-line or optical fibres
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L15/00—Indicators provided on the vehicle or train for signalling purposes
- B61L15/0072—On-board train data handling
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L15/00—Indicators provided on the vehicle or train for signalling purposes
- B61L15/0081—On-board diagnosis or maintenance
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L25/00—Recording or indicating positions or identities of vehicles or trains or setting of track apparatus
- B61L25/02—Indicating or recording positions or identities of vehicles or trains
- B61L25/025—Absolute localisation, e.g. providing geodetic coordinates
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
- B61L27/40—Handling position reports or trackside vehicle data
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
- B61L27/50—Trackside diagnosis or maintenance, e.g. software upgrades
- B61L27/57—Trackside diagnosis or maintenance, e.g. software upgrades for vehicles or trains, e.g. trackside supervision of train conditions
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
- B61L27/70—Details of trackside communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L2205/00—Communication or navigation systems for railway traffic
- B61L2205/02—Global system for mobile communication - railways [GSM-R]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40293—Bus for use in transportation systems the transportation system being a train
Landscapes
- Engineering & Computer Science (AREA)
- Mechanical Engineering (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Medical Informatics (AREA)
- Small-Scale Networks (AREA)
- Electric Propulsion And Braking For Vehicles (AREA)
- Control Of Metal Rolling (AREA)
Abstract
La présente invention concerne un dispositif (100) comprenant : - une interface d’entrée universelle (101) recevant des messages de données (200) passant sur des bus de messages (20) d’un matériel roulant, où l’interface d’entrée universelle (101) se conforme aux trois couches physiques suivantes : - RS232 ; - RS485 ; - CAN ; à partir desdits bus de messages (20), lesdits messages de données (200) comprenant des données (10) ; - un moteur de traitement (103) recevant une configuration demandée distante (300) comprenant une ou plusieurs règles de traitement (400) ; - une unité de normalisation (102) décodant lesdits messages de données (200) en fonction de ladite configuration demandée distante (300) ; et dans lequel ledit moteur de traitement (103) applique en outre une ou plusieurs desdites unes ou plusieurs règles de traitement (400) en fonction de ladite configuration demandée distante (300).
Description
DISPOSITIF POUR TRAITER DES DONNÉES D'UN MATÉRIEL ROULANT
Domaine de l'invention [01] La présente invention concerne, d'une manière générale, une analyse à distance et fiable de messages de données passant sur des bus de messages d'un matériel roulant.
Arrière-plan technologique de l'invention [02] Le rail joue un rôle important dans la création d'un avenir durable pour le transport dans le monde. Le transport sur rail peut aider à lutter contre le changement climatique, à lutter contre la congestion des routes, à créer de la croissance économique pour un pays, à contribuer à la (ré)-industrialisation de ce pays, et à permettre aux habitants d'être mobiles. Le matériel roulant est un élément essentiel des systèmes ferroviaires et de transport, mais c'est également l'un des plus complexes. Le terme matériel roulant désigne tout véhicule circulant sur une voie ferrée. Il comprend généralement des véhicules motorisés et non motorisés, par exemple des locomotives, des voitures et des véhicules de chemin de fer, des autocars, des trains et des wagons. Du train de roulement à la résistance et à la durabilité, en passant par les entraînements, les freins, les systèmes de régulation et de commande, et jusqu'à la protection incendie et à la santé et la sécurité au travail, toutes les fonctionnalités d'un matériel roulant relatives à la sécurité doivent être en parfait état de fonctionnement à tout moment.
[03] De nos jours, la surveillance des performances des équipements et dispositifs ferroviaires d'un matériel roulant est planifiée régulièrement par les équipes de maintenance afin de détecter et/ou de prévoir un éventuel dysfonctionnement et/ou une éventuelle défaillance de chaque équipement et/ou dispositif ferroviaire à bord du matériel roulant. Chaque anomalie, panne ou défaillance de chaque équipement ou dispositif ferroviaire est détectée individuellement et indépendamment, par exemple en récupérant les informations manuellement ou via un logiciel sur un
BE2019/5150
-2BE2019/5150 ordinateur portable auprès d'un gestionnaire de matériel roulant à bord du matériel roulant, par une inspection par un expert humain directement dans le train. Chaque fois qu'une défaillance ou qu'une série de défaillances est identifiée, le matériel roulant est amené dans un atelier pour une inspection approfondie, un diagnostic et une réparation. Surveiller et/ou diagnostiquer les performances des équipements et dispositifs ferroviaires à bord d'un matériel roulant nécessite donc une immobilisation temporaire mais répétitive tout au long de l'exercice du matériel roulant. Amener le matériel roulant pour un diagnostic et une réparation augmente le temps d'arrêt du matériel roulant, ce qui est peu pratique, inefficient et inefficace dans le contexte de la gestion d'un parc ferroviaire et d'une exploitation ferroviaire.
[04] Un autre problème en ce qui concerne la gestion d'un parc ferroviaire est que les opérateurs et les responsables de la maintenance font face à une énorme complexité en matière de données : chaque locomotive, voiture de chemin de fer ou véhicule de chemin de fer ou train de voyageurs comprend un ensemble différent de dispositifs embarqués pouvant chacun être compatibles avec différents protocoles de communication par bus de messages développés pour un parc ferroviaire, par exemple avec un bus de véhicule multifonction également appelé MVB, ou un protocole d'instrumentation industriel également appelé FIP, ou un Profibus, ou un réseau local de commande également appelé CAN. De plus, l'ensemble de dispositifs embarqués varie d'une locomotive ou d'une voiture de chemin de fer à une autre. Les dispositifs d'une même locomotive ou d'une même voiture de chemin de fer comportent donc différentes interfaces d'entrée et/ou de sortie pour communiquer avec les bus de messages et/ou pour communiquer avec d'autres dispositifs. Par exemple, plusieurs dispositifs peuvent recevoir et/ou générer des messages de données passant sur des bus de messages utilisant une couche physique RS232, tandis que d'autres dispositifs peuvent recevoir et/ou générer des messages de données passant sur des bus de messages utilisant une couche physique CAN. De nombreux connecteurs enfichables et/ou cartes d'interface et/ou cartes d'extension sont nécessaires dans un matériel roulant pour permettre une communication entre les dispositifs eux-mêmes et pour permettre une communication des dispositifs depuis et/ou vers les différents bus de messages du matériel roulant afin de surveiller une condition du matériel roulant et une condition de dispositifs embarqués qui comprennent des signaux utilisant différentes couches
-3BE2019/5150 physiques. Les connecteurs enfichables et/ou les cartes d'interface et/ou les cartes d'extension sont des extensions matérielles qui comprennent des convertisseurs d'interface configurés pour convertir, par exemple, des signaux de données utilisant une première couche physique en des signaux de données utilisant une autre couche physique différente de la première couche physique. Les cartes d'interfaces peuvent convertir des signaux de données utilisant, par exemple, une couche physique RS232 en signaux de données utilisant, par exemple, une couche physique RS485. Les systèmes de surveillance pour la gestion d'un parc ferroviaire doivent alors comprendre une pluralité de connecteurs enfichables et de cartes d'interface ou d'extension, ce qui les rend complexes à fabriquer et à mettre en œuvre dans le matériel roulant. En variante, une pluralité d'interfaces peuvent être configurées pour un seul dispositif à l'aide de cavaliers matériels. Par exemple, une interface série peut être de type RS232 ou de type RS485. Les cavaliers matériels sont de petits cavaliers branchés en tant que connecteurs de court-circuit sur des broches de contacts. Dans ce cas, lorsqu'un cavalier est branché sur des broches, ces broches sont connectées électriquement les unes aux autres. Les cavaliers matériels peuvent également être des résistances 0 Ohm ou des commutateurs doubles en ligne. Une interface peut être de type RS232 et peut être commutée dans les deux sens sur un type RS485 grâce aux cavaliers matériels. Cependant, la présence de cavaliers matériels doit être prise en compte lors du procédé de production des dispositifs et doit être placée dans un procédé de montage correspondant aux interfaces requises. L'ajout ou la suppression d'un ou de plusieurs dispositifs et/ou bus de messages dans un matériel roulant peut modifier les interfaces requises pour chaque dispositif. Les cavaliers matériels ne peuvent alors être modifiés à bord qu'en ouvrant chaque dispositif, ce qui rend leur utilisation peu flexible. Chaque modification prend du temps, est potentiellement source d'erreurs et l'ouverture des dispositifs peut également entraîner l'expiration de leur garantie.
[05] Il reste donc plusieurs défis à relever pour accéder aux données d'un matériel roulant. Les opérateurs et les responsables de la maintenance s'appuient sur une pluralité de PC de diagnostic et sur la disponibilité d'experts pour effectuer la maintenance du matériel roulant. Chaque PC de diagnostic comprend des connaissances spécialisées et est configuré pour surveiller et diagnostiquer un certain type de dispositif embarqué à bord de la locomotive ou de la voiture de
-4BE2019/5150 chemin de fer. En raison de l'utilisation de différentes couches physiques par les dispositifs, un PC de diagnostic peut nécessiter l'utilisation d'une pluralité de connecteurs enfichables et/ou de cartes d'interface ou d'extension pour pouvoir communiquer avec une pluralité de dispositif embarqués, par exemple trois, quatre, cinq cartes d'extension différentes ou même plus. Cela augmente la complexité d'accès aux données des dispositifs embarqués sur un matériel roulant. De plus, l'utilisation d'un PC de diagnostic entraîne la création de bases de données locales, non sécurisées et incomplètes, sur chaque PC de diagnostic, qui doivent ensuite être exportées manuellement par les opérateurs et les responsables de la maintenance, par exemple via des clés USB, etc. Une connaissance détaillée et fiable de l'état de la locomotive ou de la voiture de chemin de fer est donc en premier lieu peu répandue et ne peut être partagée. L'accès à des données provenant d'un matériel roulant n'est donc pas pratique, prend du temps en raison de l'utilisation d'une pluralité de PC et de clés USB, et a lieu généralement trop tard. En effet, l'intervention d'un expert pour diagnostiquer la cause d'une défaillance d'un dispositif est planifiée après que la défaillance s'est déjà produite. Ceci est incompatible avec la mise en place d'une assistance en temps réel pour le conducteur de la locomotive ou de la voiture de chemin de fer et d'une maintenance prédictive, qui vise à anticiper les défaillances avant qu'elles ne surviennent.
[06] De nos jours, l'accès à des données d'un matériel roulant soulève des problèmes de sécurité. L'ensemble du système composant le matériel roulant doit satisfaire à des exigences de sécurité selon des normes et directives nationales et internationales. Les PC de diagnostic et les clés USB utilisés par les opérateurs et les responsables de la maintenance constituent une intrusion dans le système du matériel roulant et menacent l'intégrité de la sécurité du matériel roulant. En effet, un logiciel en cours d'exécution développé pour tester et diagnostiquer un équipement d'origine dans un matériel roulant peut réinitialiser des configurations du bus de messages auquel l'équipement est couplé. Il existe un risque qu'un accès à des données provenant d'un matériel roulant en cours de fonctionnement compromette donc la sécurité de la locomotive ou de la voiture de chemin de fer.
[07] Un défi restant supplémentaire lors de la surveillance des performances des équipements et dispositifs ferroviaires d'un matériel roulant est le paradigme actuel
-5BE2019/5150 quand il s'agit de collecter des données à partir d'un matériel roulant. Les données provenant des équipements et dispositifs ferroviaires à bord d'un matériel roulant sont généralement de préférence collectées sur des serveurs distants, et les données sont, par exemple, envoyées depuis le matériel roulant vers et stockées dans le cloud. Cela nécessite généralement un sous-échantillonnage des données de 10 secondes à 1 minute afin de réduire le débit des données et/ou la taille des données en raison des coûts de transmission et des coûts de stockage de données. Il n'est alors pas possible de détecter avec précision des régimes de transition à partir des données, comme par exemple des pics de courant. Des connexions intermittentes ou irrégulières entre un matériel roulant et les serveurs distants, ainsi que la latence, pourraient également compromettre la précision et la pertinence des données collectées dans le cadre d'un diagnostic en temps réel de l'état du matériel roulant. La quantité pure de données générée pourrait facilement dépasser la bande passante disponible ou être trop coûteuse à envoyer vers le cloud. De plus, au moment où les données sont téléchargées sur le cloud, traitées dans le centre de données et les résultats transférés vers la périphérie, il peut trop tard pour prendre des mesures. De plus, lors de la collecte de données à partir d'un matériel roulant sur un ou plusieurs serveurs distants, plusieurs secondes de latence peuvent être nécessaires pour traiter les données sur le serveur. Des obstacles tels que le débit du réseau, les coûts de communication, la capacité disponible d'un serveur pour traiter les données et les coûts de traitement associés constituent des limitations supplémentaires de ce paradigme.
[08] Un but de la présente invention est de divulguer un dispositif qui surmonte les inconvénients identifiés ci-dessus de solutions existantes. Plus particulièrement, un but est de divulguer un dispositif de traitement de données comprises dans des messages de données passant sur des bus de messages d'un matériel roulant permettant de rassembler de manière centralisée et sûre des données provenant d'un matériel roulant de manière flexible, en minimisant ainsi le temps d'immobilisation du matériel roulant et l'effort de surveillance.
Résumé de l'invention
-6[09] Selon un premier aspect de la présente invention, les buts définis ci-dessus BE2019/5150 sont atteints par un dispositif de traitement de données comprises dans des messages de données passant sur des bus de messages d'un matériel roulant, le dispositif comprenant :
- une interface d'entrée universelle, configurée pour recevoir des messages de données se conformant aux trois couches physiques suivantes :
o RS232 ; o RS485 ; o CAN;
à partir des bus de messages, les messages de données comprenant des données ;
- un moteur de traitement, configuré pour recevoir une configuration demandée distante comprenant une ou plusieurs règles de traitement ;
- une unité de normalisation, configurée pour décoder en fonction de la configuration demandée distante les messages de données en flux de données normalisés comprenant lesdites données ; et dans lequel le moteur de traitement est configuré en outre pour recevoir les flux de données normalisés à partir de l'unité de normalisation, et dans lequel le moteur de traitement est configuré en outre pour traiter les données par l'application d'une ou de plusieurs des unes ou plusieurs règles de traitement sur les données des flux de données normalisés en fonction de la configuration demandée distante.
[10] Le dispositif selon la présente invention comprend une interface d'entrée universelle. Le dispositif est configuré pour traiter des données d'un matériel roulant provenant de messages de données passant sur des bus de messages utilisant une couche physique RS232 et sur des bus de messages utilisant une couche physique RS485 et sur des bus de messages utilisant une couche physique CAN. En d'autres termes, le dispositif selon la présente invention comprend une seule interface d'entrée universelle, sur laquelle des messages de données provenant de différents bus utilisant différentes couches physiques et/ou différents protocoles peuvent être reçus. Des dispositifs se trouvant à l'intérieur de la même locomotive ou de la même voiture ou du même véhicule de chemin de fer ou du même train de voyageurs, qui comprennent différentes interfaces d'entrée et/ou de sortie pouvant être incompatibles les unes avec les autres, sont tous capables de communiquer avec le
-7dispositif selon la présente invention par l'intermédiaire de l'unique interface d'entrée BE2019/5150 universelle du dispositif selon la présente invention. Le dispositif selon la présente invention offre donc une plate-forme unifiée à laquelle la majorité et de préférence la totalité des dispositifs embarqués du matériel roulant peut être couplée sans qu'il soit nécessaire d'interposer, par exemple, des cartes d'extension ou des connecteurs enfichables entre un dispositif embarqué et le dispositif selon la présente invention. Le dispositif selon la présente invention convertit tous les messages de données reçus au niveau de l'interface d'entrée universelle en flux de données normalisés indépendamment de la couche physique utilisée par le bus de messages sur lequel les messages de données passent. Quand le dispositif de la présente invention est utilisé, des systèmes de surveillance pour la gestion d'un parc ferroviaire ne doivent plus comprendre une pluralité de connecteurs enfichables et de cartes d'interface ou d'extension, ce qui rend leur mise en œuvre dans un matériel roulant simple et facile. Le dispositif selon la présente invention devient donc une plate-forme centralisée à partir de laquelle tous les équipements et composants et dispositifs couplés à un ou plusieurs bus de messages peuvent être vérifiés et caractérisés.
[11] Grâce au dispositif selon la présente invention, le traitement de données comprises dans des messages de données passant sur des bus de messages du matériel roulant et de dispositifs à bord du matériel roulant, par exemple une locomotive et/ou des voitures de chemin de fer ou un véhicule de voyageurs, est effectué en continu au cours de temps et peut donc être utilisé pour venir en aide, par exemple, à un conducteur d'une locomotive en temps réel ou pour prendre en charge une aide en ligne centrale distante. De cette manière, une évaluation précise de l'état ou de la condition du matériel roulant et des dispositifs embarqués sur le matériel roulant peut être caractérisée à partir de messages de données passant sur des bus de messages par le dispositif selon la présente invention, et des événements transitoires et des régimes transitoires se produisant à bord du matériel roulant peuvent être détectés en temps réel par le dispositif selon la présente invention sans un sous-échantillonnage des données. L'utilisation du dispositif selon la présente invention peut donc aider un opérateur et/ou un technicien à prévoir un dysfonctionnement ou une défaillance d'un ou plusieurs des dispositifs embarqués sur le matériel roulant et/ou peut aider l'opérateur et/ou le technicien à diagnostiquer le dysfonctionnement ou la défaillance. De cette manière, l'utilisation du dispositif selon la présente invention aide un opérateur et/ou un technicien continuellement au cours du temps dans la maintenance du matériel roulant, sans nécessiter d'immobilisation répétitive ni de temps d'arrêt du matériel roulant pendant toute sa durée de vie. Accéder à des données provenant d'un matériel roulant en temps réel permet de réagir rapidement aux problèmes rencontrés dans le matériel roulant. En effet, un opérateur et/ou un technicien peut être alerté en temps réel des défaillances d'un ou de plusieurs dispositifs embarqués du matériel roulant et/ou dans le matériel roulant, et/ou peut être alerté en temps réel de défaillances à venir dans un ou plusieurs dispositifs du matériel roulant et/ou dans le matériel roulant. Ceci est compatible avec la mise en œuvre d'une aide en temps réel pour le conducteur de la locomotive ou de la voiture de chemin de fer ou du véhicule de voyageurs.
[12] Le dispositif selon la présente invention traite des données provenant d'une pluralité de dispositifs embarqués dans le matériel roulant de manière centralisée. Les messages de données passant sur les bus de messages comprennent des informations indiquant un état d'un ou de plusieurs des dispositifs couplés aux bus de messages. Le dispositif selon la présente invention est configuré pour émettre et recevoir des messages de données vers/depuis des dispositifs embarqués et/ou pour traiter des données de dispositifs embarqués en écoutant ou en recevant les messages de données passant sur des bus de messages couplés aux dispositifs embarqués. En d'autres termes, le dispositif selon la présente invention est configuré pour analyser et/ou surveiller, à partir des messages de données, l'état et/ou les performances d'une pluralité de dispositifs embarqués et de systèmes embarqués. En outre, le dispositif selon la présente invention est configuré pour déterminer des défaillances des dispositifs et des systèmes embarqués sur le matériel roulant quand l'état du matériel roulant n'est pas conforme à une ou plusieurs règles de traitement après analyse des données des messages de données. Un dispositif selon la présente invention effectue une surveillance centralisée d'une pluralité d'équipements embarqués. Les opérateurs et les responsables de la maintenance n'ont donc pas besoin de s'appuyer sur une pluralité de PC de diagnostic et/ou sur la disponibilité d'experts pour effectuer la maintenance du matériel roulant. Cela supprime la complexité d'accès aux données des dispositifs embarqués sur un matériel roulant. De plus, le dispositif selon la présente invention crée une base de données locale et complète de messages de données et de flux normalisés pouvant
BE2019/5150
-9être exportés de manière sécurisée, individuellement ou globalement, vers des BE2019/5150 systèmes distants, par exemple vers des systèmes distants utilisés par les opérateurs et les responsables de la maintenance du matériel roulant. En variante, la base de données créée est accessible à des systèmes distants, par exemple à des systèmes distants utilisés par les opérateurs et les responsables de la maintenance du matériel roulant. Des connaissances détaillées et fiables sur l'état de la locomotive ou de la voiture de chemin de fer sont donc à disposition et peuvent être facilement partagées à partir d'une base de données centralisée comprise dans le dispositif selon la présente invention. Cette plate-forme uniforme permet la centralisation de l'historique de la surveillance et du diagnostic du matériel roulant, par exemple dans le cloud, et rend l'accès aux données d'un matériel roulant largement accessible au personnel d'exploitation et aux experts pouvant utiliser euxmêmes un logiciel d'analyse de données. Accéder à des données provenant d'un matériel roulant est donc pratique. En effet, il devient possible avec le dispositif selon la présente invention d'accéder à des données en temps réel concernant le matériel roulant, par exemple en ligne, d'envoyer des ordres de maintenance en un clic, de suivre les interventions d'équipes mobiles et d'étendre des périodicités de maintenance prédictive.
[13] De plus, le dispositif selon la présente invention effectue une surveillance à distance fiable d'une pluralité de dispositifs et de systèmes embarqués, par exemple de centaines de dispositifs ou de milliers de dispositifs ou de systèmes par exemple simultanément. Il n'est donc pas nécessaire pour un opérateur et/ou un technicien du matériel roulant d'accéder à et d'ouvrir physiquement et individuellement chaque dispositif et système embarqué à bord du matériel roulant pour effectuer l'analyse de ses performances et/ou le dépanner. Cela garantit que tous les dispositifs embarqués restent valides et réduit considérablement les temps d'immobilisation du matériel roulant. En outre, le dispositif selon la présente invention est ajouté au matériel roulant après le procédé de fabrication du matériel roulant, et le dispositif selon la présente invention est simplement enfiché sur un ou plusieurs bus de messages à bord du matériel roulant, ce qui rend son installation facile dans le matériel roulant. La mise en œuvre du dispositif selon la présente invention est non intrusive pour le matériel roulant et, en particulier, non intrusive pour les bus de messages. Le dispositif selon la présente invention effectue une analyse totalement passive et fiable des données du matériel roulant à partir des messages de données BE2019/5150 passant sur les bus de messages tout en se conformant aux exigences de sécurité selon les normes et directives nationales et internationales. Plus aucun PC de diagnostic et plus aucune clé USB utilisé(e) par les opérateurs et les responsables de la maintenance ne sont nécessaires pour accéder aux données provenant d'un dispositif embarqué, et le dispositif selon la présente invention ne constitue pas une intrusion dans le système du matériel roulant ni ne menace l'intégrité de la sécurité du matériel roulant. En effet, un logiciel en cours d'exécution développé pour tester et diagnostiquer un équipement d'origine dans un matériel roulant dans le dispositif selon la présente invention ne réinitialise pas les configurations des bus de messages auxquels le dispositif selon la présente invention est couplé. De plus, si une reconfiguration du dispositif selon la présente invention est requise après l'ajout et/ou le retrait de dispositifs embarqués dans le matériel roulant, le dispositif selon la présente invention peut être reconfiguré à distance sans nécessiter d'intervention manuelle sur le dispositif ou sur les dispositifs embarqués. Cela réduit l'apparition d'erreurs lors d'une intervention manuelle sur des dispositifs embarqués qui pourraient conduire à une immobilisation du matériel roulant, et cela garantit en outre que la configuration à distance du dispositif selon la présente invention reste flexible.
[14] Le dispositif selon la présente invention fait preuve d'une capacité informatique en périphérie de réseau. Informatique en périphérie de réseau signifie que le traitement des données est effectué sur le dispositif à l'intérieur du matériel roulant plutôt que sur un serveur distant. L'avantage principal de ceci est que le dispositif selon la présente invention peut effectuer un calcul de données sans perte sur des données en temps réel des messages de données à une fréquence de l'ordre de la milliseconde. Par exemple, le dispositif selon la présente invention sera capable d'observer un courant anormal transitoire pendant 10 millisecondes sur le moteur de traction ou un moteur de porte, ce qui serait impossible en cas de traitement sur un serveur distant. Par exemple, des centaines de gigabits par mois seraient nécessaires pour stocker sur un serveur l'ensemble des données d'un bus de matériel roulant, ce qui engendrerait des coûts de transmission de données élevés par train et par mois, par exemple une carte SIM, ce qui n'est pas jugé économique. En revanche, une informatique en périphérie de réseau peut effectuer tout le traitement localement et n'envoyer que des alertes anormales. Cette architecture permet de décoder et d'exposer des bus de messages à haut débit selon la présente invention à un moteur de règles hautement configurable, permettant un calcul toutes les millisecondes ou plus, ce qui est particulièrement pertinent à des fins de maintenance prédictive. La plupart des solutions informatiques en périphérie de réseau existantes permettent de sauvegarder des données dans un référentiel de stockage local, et elles offrent facultativement la possibilité de publier les données non traitées dans un environnement cloud pour une analyse hors ligne des données. En d'autres termes, la plupart des solutions informatiques en périphérie de réseau existantes fournissent une fonctionnalité de « stockage et retransmission » ou une certaine forme de fonctionnalité de filtrage de base. D'autre part, le dispositif selon la présente invention fournit une plate-forme d'analyse en périphérie de réseau hautement évolutive et efficace qui permet un traitement sur site en temps réel de flux de données comprises dans des messages de données passant sur des bus de messages provenant d'un matériel roulant. Le dispositif selon la présente invention fournit une solution informatique en périphérie de réseau complète comprenant un moteur de traitement d'événement complexe miniaturisé, également appelé moteur CEP, également connu sous le nom de moteur d'analyse permettant de déduire des informations en temps réel en périphérie avec, par exemple, des modèles d'apprentissage machine. Il est alors possible de définir des conditions de défaillance et de détecter des événements complexes intéressants sur la multitude de données entrantes du matériel roulant. Le traitement des données du matériel roulant avec le dispositif selon la présente invention évite directement des défaillances ou des temps d'arrêt coûteux de la machine. Les données peuvent également être introduites dans des algorithmes appropriés, tels que, par exemple, des algorithmes d'apprentissage machine, afin d'améliorer la détection et la prédiction d'anomalies ou de conditions de défaillance du matériel roulant. Le dispositif selon la présente invention améliore l'efficacité globale et la sécurité du matériel roulant en temps réel.
[15] Le terme matériel roulant désigne tout véhicule qui se déplace sur un réseau ferroviaire. Il comprend généralement à la fois des véhicules motorisés et non motorisés, par exemple une ou plusieurs locomotives, et/ou une ou plusieurs voitures de chemin de fer, et/ou un ou plusieurs véhicules de chemin de fer, et/ou un ou plusieurs trains de voyageurs, et/ou un ou plusieurs autocars, et/ou un ou plusieurs
BE2019/5150
- 12wagons. En d'autres termes, le matériel roulant comprend des moteurs et des BE2019/5150 voitures qui sont utilisés sur les chemins de fer. En d'autres termes, le matériel roulant comprend un ou plusieurs véhicules à roues ou à lévitation magnétique ou hyperloop utilisés sur un chemin de fer, par exemple une ou plusieurs locomotives et/ou un ou plusieurs autocars de passagers et/ou un ou plusieurs wagons de fret et/ou ou plusieurs fourgons de garde, etc.
[16] Les dispositifs embarqués, également appelés dispositifs à bord du matériel roulant, peuvent être par exemple des capteurs de température, des capteurs de pression, des freins, des portes, des détecteurs d'incendie, des moteurs, des systèmes de climatisation, des systèmes de chauffage, des moteurs de traction, des convertisseurs de puissance, des batteries, des pantographes, des moteurs diesel, un système de refroidissement, des systèmes de navigation, etc. Le dispositif selon la présente invention est couplé à ces dispositifs et/ou équipements ferroviaires et/ou composants via un ou plusieurs bus de messages sur lesquels un ou plusieurs messages de données passent. Les messages de données sont générés par des dispositifs embarqués et/ou des systèmes embarqués et/ou par le dispositif selon la présente invention, ce qui permet une communication entre des dispositifs embarqués et le dispositif selon la présente invention. Chaque message de données comprend des données qui comprennent des bits et/ou des octets et/ou des chaînes de données. Les bits et/ou les octets et/ou les chaînes de données comprennent des informations indiquant le fonctionnement du dispositif respectif embarqué sur le matériel roulant et/ou du matériel roulant lui-même. Le dispositif selon la présente invention est donc configuré pour émettre et recevoir des messages de données vers/depuis des dispositifs embarqués et/ou pour analyser les données collectées en écoutant les messages de données passant sur des bus de messages couplés aux dispositifs embarqués. Par exemple, le dispositif selon la présente invention est configuré pour lire et/ou analyser des données provenant d'un système de batterie d'une locomotive, et/ou du système de roulement d'une locomotive ou d'une voiture de chemin de fer et/ou du système de commande et de gestion de train d'un train, également appelé TCMS, et/ou du système de diagnostic à distance du moteur d'une locomotive, et/ou du système de surveillance à distance de l'énergie d'un train, etc. L'unité de normalisation du dispositif selon la présente invention décode les messages de données reçus par l'interface d'entrée universelle en flux de données normalisés en fonction d'une configuration demandée distante. Le moteur de BE2019/5150 traitement du dispositif selon la présente invention surveille l'état du matériel roulant à partir des flux de données normalisés en fonction de la configuration demandée distante comprenant une ou plusieurs règles de traitement. Le moteur de traitement diagnostique la condition du matériel roulant quand une ou plusieurs des règles de traitement ne sont pas satisfaites par la condition du matériel roulant.
[17] Par le traitement des données comprises dans des messages de données selon la présente invention, il est entendu que le moteur de traitement lit et/ou analyse les messages de données passant sur des bus de messages en fonction de la configuration demandée en analysant des flux de données normalisés correspondants et en collectant et/ou en déterminant à partir de ceux-ci des paramètres indiquant et caractérisant, par exemple, un état physique, technique et électrique d'un ou de plusieurs dispositifs respectifs embarqués sur le matériel roulant. Le moteur de traitement est configuré pour évaluer à un instant donné selon une ou plusieurs règles de traitement et/ou sur une période de temps donnée selon une ou plusieurs règles de traitement un état du matériel roulant en collectant, par exemple, des données telles que des paramètres du matériel roulant prédéfinis dans les règles de traitement de la configuration demandée distante provenant de messages de données reçus et/ou en déterminant des données telles que des paramètres du matériel roulant prédéfinis dans les règles de traitement de la configuration demandée distante en traitant les données comprises dans les messages de données reçus. En d'autres termes, le dispositif selon la présente invention est configuré à distance pour lire des données comprises dans des messages de données passant sur des bus de messages d'un matériel roulant. Le dispositif peut en outre être configuré à distance pour transmettre les données lues via, par exemple, un module GSM et/ou un port Ethernet et/ou un émetteur sans fil. En variante, le dispositif selon la présente invention est configuré à distance pour analyser et/ou manipuler et/ou gérer et/ou traiter et/ou préparer des données comprises dans des messages de données passant sur des bus de messages d'un matériel roulant. Le dispositif peut en outre être configuré à distance pour transmettre les données traitées via, par exemple, un module GSM et/ou un port Ethernet et/ou un émetteur sans fil. Le moteur de traitement applique une ou plusieurs règles de traitement pour lire et/ou extraire et/ou calculer à partir des messages de données passant sur les bus de messages des données telles que des paramètres et des caractéristiques du matériel roulant, comme par exemple sa vitesse en temps réel et sa consommation de carburant ou d'énergie électrique, l'état de charge de ses batteries, etc. Les paramètres et caractéristiques identifiés forment la condition du matériel roulant. Le moteur de traitement exécute en outre des règles de traitement pour déterminer si les données identifiées sont conformes aux règles de traitement. Par exemple, une règle de traitement peut comprendre une régression linéaire et le moteur de traitement peut recevoir, par exemple, des flux de données normalisés comprenant la tension, le courant et la température du moteur du matériel roulant. Conformément à une configuration demandée, le moteur de traitement exécute la régression linéaire comprise dans la règle de traitement sur la tension, le courant et la température du matériel roulant afin de déterminer l'état de charge de la batterie du matériel roulant. La condition du matériel roulant comprend alors l'état de charge de la batterie du matériel roulant. Le moteur de traitement exécute ensuite une règle en fonction de la configuration demandée pour déterminer si l'état de charge de la batterie est conforme ou non à la règle de traitement. Par exemple, une règle de traitement comprend un seuil minimal d'état de charge de la batterie et une obligation de comparer l'état de charge déterminé de la batterie au seuil minimal d'état de charge de la batterie et une indication qu'un état de charge de la batterie inférieur au seuil minimal d'état de charge de la batterie est non conforme aux spécifications du fabricant. Dans l'exemple, le diagnostic compare ensuite l'état de charge déterminé de la batterie au seuil minimal d'état de charge de la batterie. Quand les données ne sont pas conformes à une ou plusieurs règles, c'est-à-dire dans l'exemple quand l'état de charge déterminé de la batterie est supérieur au seuil minimal d'état de charge de la batterie, ceci indique au dispositif selon la présente invention que le matériel roulant présente un(e) ou plusieurs défaillances/problèmes/problèmes à venir devant être résolu(e)s.
[18] Selon un aspect facultatif de l'invention, l'interface d'entrée universelle comprend :
- au moins un module d'entrée RS232 configuré pour recevoir des messages de données se conformant à une couche physique RS232, tels qu'un ou plusieurs messages de données se conformant à des interfaces série ;
BE2019/5150
- 15- au moins un module d'entrée RS485 configuré pour recevoir des messages de BE2019/5150 données se conformant à une couche physique RS485, tels qu'un ou plusieurs messages de données se conformant à des couches physiques définies par un ou plusieurs des suivants : J1708, bus de véhicule multifonction, Profibus, Modbus, On-Board Diagnostic, une interface série ; et
- au moins un module d'entrée CAN configuré pour recevoir des messages de données se conformant à une couche physique CAN, tels qu'un ou plusieurs messages de données se conformant à des couches physiques définies par un ou plusieurs des suivants : J1939, réseau local de commande.
[19] Selon un aspect facultatif de l'invention, l'interface d'entrée universelle comprend en outre :
- au moins un module d'entrée Ethernet configuré pour recevoir des messages de données se conformant à la norme PROFINET et/ou un ou plusieurs messages de données se conformant à un réseau de communication ferroviaire, tel qu'un réseau central ferroviaire Ethernet ; et
- au moins un module d'entrée numérique configuré pour recevoir des messages de données numériques.
[20] Par exemple, un bus de messages est un bus de terrain. Plus particulièrement, un bus de messages est, par exemple, un bus de véhicule multifonction ou
| ... un bus de terrain de véhicule utilisant la couche physique suivante. | ... et comprenant le protocole suivant : |
| couche physique RS232 | Modbus |
| couche physique RS485 | bus de véhicule multifonction ou MVB |
| couche physique RS485 | protocole d'instrumentation industriel ou FIP ou WorldFIP |
| couche physique RS485 | Profibus |
| couche physique RS485 | SAE J1708 |
| couche physique RS485 | Modbus |
| couche physique RS485 | bus ferroviaire câblé ou WTB |
| couche physique RS485 | LonWorks |
| couche physique CAN | SAE J1939 |
| couche physique CAN | réseau local de commande ou CANopen |
| Ethernet | Profinet |
| Ethernet, courant porteur | LonWorks |
| Ethernet | Modbus |
| Ethernet | réseau central ferroviaire Ethernet ou ETB |
[21] Un bus de terrain est un système de réseau industriel pour une commande répartie en temps réel. Un bus de terrain couple une pluralité d'instruments, de dispositifs, de composants et de systèmes embarqués sur un train. Un bus de terrain fonctionne sur une structure de réseau qui autorise généralement des topologies de réseau en guirlande, en étoile, en anneau, en branche et en arbre. Auparavant, les ordinateurs étaient connectés à l'aide de connexions série, par exemple RS232, grâce auxquelles seulement deux dispositifs pouvaient communiquer. Le bus de terrain ne nécessite qu'un seul point de communication au niveau du dispositif de commande et permet à plusieurs points analogiques et numériques embarqués sur un train ou un matériel roulant d'être connectés en même temps. Cela réduit à la fois la longueur du câble nécessaire et le nombre de câbles nécessaire. Il existait initialement une forme initiale de la norme IEC 61158 pour un bus de terrain avec huit ensembles de protocoles différents appelés « Types », mais les types de bus de terrain ont ensuite été réorganisés en familles de profils de communication, également appelées CPF, par exemple Profibus.
[22] Le réseau de communication ferroviaire, également appelé TCN, est une combinaison hiérarchique de deux bus de terrain pour une transmission de données dans des trains. Il comprend le bus de véhicule multifonction, également appelé MVB, à l'intérieur de chaque véhicule et le bus ferroviaire câblé, également appelé WTB, pour connecter différentes voitures de chemin de fer.
[23] Le bus ferroviaire câblé ou WTB a été conçu pour des trains internationaux de voyageurs à composition variable. Le support comprend un câble à paires torsadées blindées dupliquées qui passe dans les câbles UIC entre les véhicules. Le connecteur entre les véhicules est le connecteur UIC à 18 pôles. Le connecteur BE2019/5150 standard pour les nœuds WTB est un connecteur DIN à 9 broches. Le niveau physique utilise les niveaux RS485 à un débit de données de 1 Mbit/s. Le codage utilise un code Manchester II et un protocole de trame HDLC avec un équilibrage de tension approprié pour éviter des composantes en CC dans les transformateurs d'isolation galvanique. Le décodeur Manchester utilise une démodulation en phase/quadrature, à l'exception du RS485 qui fonctionne avec des passages par zéro, ce qui permet de couvrir 750 m dans les conditions les plus défavorables, en particulier quand seuls les deux véhicules d'extrémité sont équipés, comme c'est le cas avec une traction multiple pour les trains de marchandises. Une propriété unique du WTB est l'inauguration de train dans laquelle les véhicules nouvellement connectés reçoivent une adresse en séquence et peuvent identifier le côté du véhicule (appelés bâbord et tribord comme dans la marine) afin que les portes s'ouvrent du bon côté. Jusqu'à 32 adresses peuvent être attribuées de manière dynamique. Quand deux compositions de train se rejoignent, les adresses sont réattribuées pour former une nouvelle composition de véhicules avec une adresse séquentielle. Les véhicules sans nœud WTB ne sont pas comptés. Les trames ont une charge utile maximale de 1024 bits. Le WTB fonctionne de manière cyclique pour fournir un fonctionnement déterministe, avec une période de 25 ms, principalement utilisé pour la commande de la traction. Le WTB prend également en charge une transmission sporadique de données à des fins de diagnostic. Le contenu des trames périodiques et sporadiques est régi par la norme UIC 556. Comme la taille de trame est limitée, une version de TCP ayant un surdébit réduit a été utilisée pour la segmentation et le réassemblage des messages, ce qui permet en même temps de faire face aux changements de composition, appelée protocole en temps réel ou RTP.
[24] Le MVB connecte des nœuds individuels au sein d'un véhicule ou dans un ensemble de train fermé. Quand le bus de terrain est un bus de véhicule multifonction, le câble est disponible dans trois normes : les distances électriques moyennes, également appelées EMD, qui utilisent des paires torsadées blindées avec des émetteurs et des transformateurs RS485 pour une isolation galvanique et pour une longueur de l'assemblage de câbles de quelques centaines de mètres, les distances électriques courtes, également appelées ESD, qui utilisent un câblage de fond de panier simple sans isolation galvanique et pour une longueur de BE2019/5150 l'assemblage de câbles allant jusqu'à quelques dizaines de mètres, et enfin les lignes optiques pour des distances de communication très longues et une isolation galvanique. Le MVB fonctionne à 1,5 Mbit/s via des paires de fils torsadées et via des fibres optiques. Il est structuré avec deux canaux pour garantir une plus grande fiabilité de transmission. Ces deux canaux sont séparés par des passages d'un véhicule à l'autre. La transmission des messages de données sur le MVB est commandée par plusieurs dispositifs de gestion de bus ou par un seul dispositif de gestion de bus. Avec cela, le transfert de données est asynchrone. Pour le système, cela signifie que chaque dispositif de gestion de bus a sa propre horloge. Le MVB est basé sur le principe maître-esclave. Le maître peut être couplé au bus à n'importe quel endroit.
[25] Les messages de données passent périodiquement sur le bus de terrain et/ou sporadiquement sur le bus de terrain. Par exemple, le MVB transfère principalement deux types de données : des variables de processus, c'est-à-dire des données périodiques, et des messages, c'est-à-dire des données sporadiques. Les variables de processus sont des données courtes, comme par exemple des messages de données de 16, 32, 64, 128 ou 256 bits, qui fournissent des informations sur l'état du train, par exemple sa vitesse. En variante, les messages de données comprennent 256 bits. Les variables de processus sont transportées par cycles, de manière à garantir une faible latence, à savoir par exemple inférieure à 15 ms dans une voiture de chemin de fer, et par exemple inférieure à 100ms dans un train. Les messages sont des informations plus longues et permettent d'analyser, par exemple, la gestion du réseau. La charge utile d'un message peut varier de quelques octets à plusieurs mégaoctets. Les messages sont envoyés en fonction de la demande, sans contraintes de temps. Des messages de données périodiques et sporadiques passent sur le même bus dans les dispositifs, mais ils sont transmis alternativement et jamais ensemble. Des messages de données de processus sont transmis à tous les appareils sur le bus. Il incombe au maître d'interroger régulièrement l'esclave en envoyant une « trame maître ». Les esclaves surveillent le bus et, quand un esclave obtient une trame maître demandant un paramètre qu'il possède, l'esclave renvoie un message comprenant les données demandées.
[26] Le protocole d'instrumentation industriel ou FIP est un protocole de bus de BE2019/5150 terrain normalisé défini dans la norme européenne EN50170. Un certain nombre de fabricants japonais et américains ont fusionné avec FIP au groupe de normalisation WorldFIP. Le cousin le plus proche de la famille FIP se trouve aujourd'hui dans le bus ferroviaire câblé pour les autocars de train. Cependant, un sous-ensemble spécifique de WorldFIP, connu sous le protocole FIPIO, est largement répandu dans les composants de machine.
[27] Un bus de réseau local de commande, également appelé bus CAN, est une norme de bus de véhicule robuste conçue pour permettre aux microcontrôleurs et aux dispositifs de communiquer entre eux dans des applications sans ordinateur hôte. C'est un protocole basé sur des messages. Comme la norme CAN n'inclut pas des tâches de protocoles de couche d'application, telles qu'une commande de flux, un adressage de dispositif et un transport de blocs de données de plus d'un message, mais surtout des données d'application, de nombreuses implémentations de protocoles de couche supérieure ont été créées. CANopen - EN 50325-4 fait partie de ces implémentations. CANopen est un protocole de communication et une spécification de profil de dispositif pour des systèmes intégrés utilisés en automatisation. En termes de modèle OSI, CANopen implémente les couches audessus et incluant la couche de réseau. La norme CANopen consiste en un schéma d'adressage, plusieurs petits protocoles de communication et une couche d'application définie par un profil de dispositif. Les protocoles de communication prennent en charge la gestion du réseau, la surveillance des dispositifs et la communication entre les nœuds, y compris une simple couche de transport pour une segmentation/désegmentation de messages. Le protocole de niveau inférieur implémentant le lien de données et les couches physiques est généralement un réseau local de commande, bien que des dispositifs utilisant un autre moyen de communication, comme par exemple Ethernet Powerlink, EtherCAT, puissent également implémenter le profil de dispositif CANopen.
[28] Le réseau d'exploitation local, également appelé LonWorks, est une plateforme de mise en réseau spécialement créée pour répondre aux besoins d'applications de commande. La plate-forme est construite sur un protocole créé par Echelon Corporation pour la mise en réseau de dispositifs sur des supports tels qu'une paire torsadée, des lignes électriques, des fibres optiques et la RF. Deux BE2019/5150 technologies de signalisation de couche physique, une « topologie libre » à paire torsadée et une porteuse de ligne électrique, sont généralement incluses dans chacune des normes créées autour de la technologie LonWorks. La couche bifilaire fonctionne à 78 kbit/s en utilisant un codage Manchester différentiel, tandis que la ligne électrique atteint 5,4 ou 3,6 kbit/s, en fonction de la fréquence. En outre, la plate-forme LonWorks utilise une norme de tunnellisation de protocole Internet affiliée ISO/IEC 14908-4 utilisée par un certain nombre de fabricants pour connecter les dispositifs sur des réseaux, précédemment déployés et nouveaux, basés sur la plate-forme LonWorks à des applications compatibles IP ou à des outils de gestion de réseau distants. De nombreuses applications de commande basées sur la plateforme LonWorks sont implémentées avec une certaine sorte d'intégration IP, soit au niveau de l'IU/application, soit dans l'infrastructure de commande. Ceci est accompli avec des services Web ou des produits de routage IP disponibles sur le marché.
[29] Le SAE J1708 est une norme utilisée pour des communications série entre des unités électroniques de commande sur un véhicule utilitaire lourd et également entre un ordinateur et le véhicule. En ce qui concerne le modèle d'interconnexion de systèmes ouverts ou OSI, J1708 définit la couche physique. Des protocoles de couche supérieure communs qui fonctionnent au-dessus de J1708 sont SAE J1587 et SAE J1922. La norme définit un câble bifilaire de calibre 18 qui fonctionne à 9600 bits/s. Un message est composé de 21 caractères maximums, à moins que le moteur ne soit arrêté et que le véhicule ne se déplace pas, auquel cas les émetteurs sont autorisés à dépasser la longueur de message maximale de 21 octets. Les messages commencent par un ID de message ou un caractère MID et se terminent par une somme de contrôle à la fin. Les caractères sont transmis au format 8N1 commun. Le matériel utilisé est constitué d'émetteurs-récepteurs RS-485 câblés pour un fonctionnement en collecteur ouvert grâce à l'utilisation d'un tirage vers le haut et d'un tirage vers le bas des lignes de données séparées. La transmission est accomplie en commandant la broche d'activation de pilote de l'émetteur/récepteur. Ce procédé permet à plusieurs dispositifs de partager le bus sans avoir besoin d'un seul nœud maître. Les collisions sont évitées en surveillant le bus lors de la transmission du MID pour s'assurer qu'un autre nœud n'a pas transmis simultanément un MID ayant une priorité supérieure.
BE2019/5150 [30] Le SAE J1939 est la pratique recommandée pour les bus de véhicule utilisée pour la communication et le diagnostic entre des composants d'un véhicule. Le SAE J1939 est utilisé dans le domaine des véhicules utilitaires à des fins de communication dans tout le véhicule, la couche physique étant définie dans la norme ISO 11898. Le SAE J1939 définit cinq couches dans le modèle de réseau OSI à sept couches, et cela inclut la spécification ISO 11898 du réseau local de commande utilisant uniquement l'identifiant 29 bits/« étendu » pour les couches physiques et de liaison de données. Sous J1939/11 et J1939/15, le débit de données est spécifié comme étant de 250 kbits/s, le J1939/14 spécifiant 500 kbits/s. Tous les paquets J1939, à l'exception du paquet de demande, contiennent huit octets de données et un en-tête standard qui contient un index appelé numéro de groupe de paramètres ou PGN, qui est incorporé dans l'identifiant de 29 bits du message. Un PGN identifie une fonction d'un message et des données associées.
[31] Modbus est un protocole de communication série qui permet une communication entre de nombreux dispositifs connectés au même réseau. Modbus est souvent utilisé pour connecter un ordinateur de supervision à une unité terminale distante dans des systèmes de commande de supervision et d'acquisition de données. Chaque dispositif destiné à communiquer via Modbus se voit attribuer une adresse unique. Dans les réseaux série et MB+, seul le nœud attribué en tant que maître peut initier une commande. Sur Ethernet, tout dispositif peut envoyer une commande Modbus, même si généralement un seul dispositif maître le fait. Une commande Modbus contient l'adresse Modbus du dispositif auquel elle est destinée. Seul le dispositif prévu agira sur la commande, même si d'autres dispositifs peuvent la recevoir. Toutes les commandes Modbus comprennent des informations de somme de contrôle, pour permettre au destinataire de détecter des erreurs de transmission.
[32] L' interface d'entrée universelle est configurée en outre pour recevoir des données analogiques. Par exemple, l'interface d'entrée universelle comprend en outre une unité de collecte de données analogiques qui est configurée pour collecter des données analogiques. Par exemple, l'unité de collecte de données analogiques est configurée pour recevoir des données analogiques provenant du matériel roulant et/ou d'équipements et/ou de dispositifs embarqués sur le matériel roulant. BE2019/5150 Facultativement, le dispositif comprend en outre une unité de collecte de données internes configurée pour collecter des données internes à partir du dispositif. Par exemple, les données internes comprennent un niveau de batterie d'une batterie du dispositif qui est collecté à partir du dispositif par l'unité de collecte de données internes, et/ou les données internes comprennent, par exemple, une température du dispositif et/ou du matériel roulant et/ou d'un composant embarqué, et/ou les données internes comprennent des informations de localisation concernant le matériel roulant, et/ou les données internes comprennent des informations générées par le module GSM et/ou l'émetteur sans fil, par exemple des données cellulaires provenant du GSM module, et/ou les données internes comprennent des paramètres électriques déterminés du dispositif, et/ou les données internes comprennent des données de vibration du dispositif, etc.
[33] Selon un aspect facultatif de l'invention, l'unité de normalisation comprend une pluralité de codecs configurés pour décoder les messages de données normalisés en les flux de données.
[34] De cette manière, la pluralité de codecs décode des messages de données reçus depuis des bus de messages utilisant la couche physique RS232 et depuis des bus de messages utilisant la couche physique RS485 et depuis des bus de messages utilisant la couche physique CAN en flux de données normalisés comprenant les données des messages de données correspondants reçus à partir des bus de message. À chaque bus de messages utilisant une couche physique particulière est associé un codec configuré pour convertir les messages de données correspondants, de sorte que tous les messages de données reçus par le dispositif sont convertis en un format uniforme de flux de données normalisés comprenant les données des messages de données correspondants reçus à partir des bus de messages. En d'autres termes, tous les messages de données reçus par le dispositif sont normalisés dans un format uniforme en les convertissant en flux de données normalisés comprenant les données des messages de données correspondants reçus à partir des bus de messages.
[35] Selon un aspect facultatif de l'invention, le dispositif comprend en outre un BE2019/5150 récepteur de configuration distante, dans lequel le récepteur de configuration distante est configuré pour recevoir la configuration demandée distante ; et dans lequel la configuration demandée distante comprend une sélection d'un ou de plusieurs bus de messages et une sélection d'adresses.
[36] La configuration demandée distante peut être reçue depuis le matériel roulant. En variante, la configuration demandée distante peut être reçue depuis un système distant via, par exemple, une connexion Ethernet et/ou une connexion sans fil. De cette manière, le dispositif peut être (re)configuré à distance sans qu'une intervention manuelle soit nécessaire sur le dispositif ou sur les dispositifs embarqués, par exemple, le dispositif peut être mis à jour par liaison radio, et un grand parc de dispositifs peuvent être mis à jour simultanément par liaison radio et sur une grande série de composants embarqués sur le matériel roulant. En d'autres termes, la configuration demandée distante est reçue, par exemple, à partir d'un éditeur de règles distant, et la configuration demandée distante est configurée pour configurer et/ou mettre à jour le dispositif à la volée. Cela réduit l'apparition d'erreurs qui se produisent lors d'une intervention manuelle sur le dispositif, qui pourraient conduire à une immobilisation du matériel roulant, et cela garantit en outre que la configuration du dispositif reste flexible. La configuration demandée distante est donc programmée à distance et est envoyée au dispositif.
[37] Selon un aspect facultatif de l'invention, le moteur de traitement est configuré en outre pour configurer l'unité de normalisation en fonction de la configuration demandée distante de façon que l'unité de normalisation reçoive les messages de données depuis l'interface d'entrée universelle en fonction de la sélection d'un ou de plusieurs bus de messages.
[38] L' unité de normalisation est configurée par le moteur de traitement pour recevoir sélectivement des messages de données provenant des uns ou plusieurs bus de messages qui sont compris dans la configuration demandée distante reçue. L'unité de normalisation est configurée par le moteur de traitement pour recevoir sélectivement des données à des adresses spécifiques, par exemple des paramètres du matériel roulant, qui sont comprises dans la configuration demandée. De cette manière, le dispositif est configuré pour lire et/ou traiter et/ou surveiller un ou BE2019/5150 plusieurs paramètres spécifiques du matériel roulant et/ou un ou plusieurs composants spécifiques du matériel roulant, par exemple un ou plusieurs dispositifs embarqués spécifiques. En d'autres termes, un opérateur ou un technicien peut donc établir une configuration demandée distante et envoyer la configuration demandée distante au dispositif, de telle sorte que le dispositif soit configuré à distance pour récupérer des données à partir d'un ou de plusieurs paramètres embarqués ou dispositifs embarqués sélectionnés qui sont comprises dans la configuration demandée distante, en recevant ainsi des messages de données provenant des paramètres ou dispositifs embarqués sélectionnés, et de telle sorte que le dispositif soit configuré à distance pour récupérer des données à des adresses spécifiques qui sont comprises dans la configuration demandée distante.
[39] Selon un aspect facultatif de l'invention, les unes ou plusieurs règles de traitement comprennent un ou plusieurs des suivants :
o une ou plusieurs métriques prédéfinies ;
o une ou plusieurs clés prédéfinies ;
o une ou plusieurs estampilles temporelles prédéfinies ;
o un ou plusieurs seuils prédéfinis ;
o une ou plusieurs fonctions algorithmiques ;
o une ou plusieurs règles analogiques ;
o un ou plusieurs compteurs ;
o une ou plusieurs fonctions de sous-échantillonnage ou de suréchantillonnage ;
o une exécution d'un ou de plusieurs modèles d'apprentissage machine préformés ;
o une exécution d'un ou de plusieurs modèles d'apprentissage profond préformés.
[40] Le moteur de traitement du dispositif est un moteur de règles configuré pour exécuter une ou plusieurs règles de traitement sur les données comprises dans les flux de données normalisés que le moteur de traitement reçoit depuis l'unité de normalisation du dispositif. En d'autres termes, le moteur de traitement est configuré pour appliquer les unes ou plusieurs règles de traitement aux données comprises dans les flux de données normalisés. Par exemple, le moteur de traitement est une unité centrale de traitement ou UCT, avec par exemple 1 GHz de puissance de traitement.
[41] Les règles de traitement sont utilisées ou exécutées par le moteur de traitement pour analyser les données comprises dans les flux de données normalisés correspondant aux messages de données reçus depuis les uns ou plusieurs bus de messages sélectionnés et les adresses sélectionnées correspondant à la sélection d'adresses. Le moteur de traitement est configuré pour lire et/ou extraire et/ou analyser des données provenant de dispositifs embarqués correspondants. Par exemple, quand les données dans les flux de données normalisés dépassent un seuil prédéfini alors qu'elles ne devraient pas conformément à une règle de traitement, le moteur de traitement détermine que les données ne sont pas conformes au seuil prédéfini et le moteur de traitement transmet, par exemple, les données.
[42] Par exemple, les règles de traitement comprennent des métriques prédéfinies, pour ainsi indiquer par exemple une valeur de métrique à laquelle les données provenant du bus de messages sélectionné et l'adresse sélectionnée correspondant à la sélection d'adresses doivent être égales. Par exemple, les règles de traitement comprennent des métriques prédéfinies qui correspondent à des données et/ou à des paramètres qui doivent être récupéré(e)s par le moteur de traitement à partir des messages de données provenant des bus de messages sélectionnés et à l'adresse sélectionnée correspondant à la sélection d'adresses, et qui peuvent facultativement être transmis via le module GSM et/ou le module Ethernet et/ou l'émetteur/récepteur sans fil. Par exemple, les règles de traitement comprennent des clés prédéfinies, pour indiquer ainsi par exemple une clé à laquelle les données provenant du bus de messages sélectionné et l'adresse sélectionnée correspondant à la sélection d'adresses doivent être égales. Par exemple, les règles de traitement comprennent des clés prédéfinies qui correspondent à des données et/ou à des paramètres qui doivent être récupéré(e)s par le moteur de traitement à partir des messages de données provenant des bus de messages sélectionnés et à l'adresse sélectionnée correspondant à la sélection d'adresses, et qui peuvent facultativement être transmises via le module GSM et/ou le module Ethernet et/ou l'émetteur/récepteur sans fil. Par exemple, les règles de traitement comprennent des estampilles
BE2019/5150
- 26temporelles prédéfinies qui correspondent à des estampilles temporelles qui doivent être récupérées par le moteur de traitement à partir des messages de données, et qui peuvent facultativement être transmises via le module GSM et/ou le module Ethernet et/ou l'émetteur/récepteur sans fil. Par exemple, les règles de traitement comprennent des estampilles temporelles prédéfinies, pour indiquer ainsi par exemple une estampille temporelle à laquelle les données provenant du bus de messages sélectionné et l'adresse sélectionnée correspondant à la sélection d'adresses doivent être changées ou égales à une valeur de métrique prédéfinie. Par exemple, les règles de traitement comprennent des seuils prédéfinis, pour indiquer ainsi par exemple un seuil pour que les données provenant du bus de messages sélectionné et l'adresse sélectionnée correspondant à la sélection d'adresses ne soient pas supérieures ou inférieures au seuil. Par exemple, les règles de traitement comprennent des fonctions numériques et/ou des fonctions algorithmiques, comme par exemple un traitement de signal numérique ou DSP, des fonctions d'intégration, des fonctions dérivées, des fonctions de multiplexage, des fonctions de conversion, des transformées de Fourier, etc. Par exemple, les règles de traitement comprennent une ou plusieurs règles analogiques à appliquer sur les données analogiques reçues par le dispositif. Par exemple, les règles de traitement comprennent des métriques analogiques prédéfinies qui doivent être récupérées par le moteur de traitement à partir des messages de données, et qui peuvent facultativement être transmises via le module GSM et/ou le module Ethernet et/ou l'émetteur/récepteur sans fil. Par exemple, les règles de traitement comprennent des règles analogiques prédéfinies qui doivent être appliquées par le moteur de traitement aux données comprises dans les messages de données récupérés à partir du bus sélectionné et à l'adresse sélectionnée correspondant à la sélection d'adresses, et qui peuvent facultativement être transmises via le module GSM et/ou le module Ethernet et/ou l'émetteur/récepteur sans fil. Par exemple, les règles de traitement comprennent un ou plusieurs compteurs qui sont exécutés par le moteur de traitement pour compter, par exemple, des métriques prédéfinies qui sont récupérées par le moteur de traitement à partir des messages de données sur une période de temps prédéfinie, et les uns ou plusieurs compteurs peuvent facultativement être transmis via le module GSM et/ou le module Ethernet et/ou l'émetteur/récepteur sans fil. Par exemple, les règles de traitement comprennent une exécution d'un ou plusieurs modèles d'apprentissage machine préformés, comme par exemple des arbres de décision,
BE2019/5150
- 27des régressions linéaires ou polynomiales, un réseau neuronal récurrent ou RNN. Par exemple, les règles de traitement comprennent une exécution d'un ou plusieurs modèles d'apprentissage profond préformés. L'apprentissage des modèles d'apprentissage machine et/ou des modèles d'apprentissage profond n'est pas effectué par le dispositif, mais le dispositif reçoit les modèles d'apprentissage machine préformés et/ou les modèles d'apprentissage profond préformés qui sont formés à distance, ce qui permet d'économiser la puissance et la capacité de traitement du dispositif.
[43] Selon un aspect facultatif de l'invention, l'unité de normalisation comprend :
- au moins un émetteur/récepteur RS232, configuré pour convertir des messages de données avec une couche physique RS232 en signaux de niveau logique TTL ;
- au moins un émetteur/récepteur RS485, configuré pour convertir des messages de données avec une couche physique RS485 en signaux de niveau logique TTL ;
- au moins un émetteur/récepteur CAN, configuré pour convertir des messages de données avec une couche physique CAN en signaux de niveau logique TTL;
- au moins un sélecteur de couche physique, configuré pour recevoir la sélection d'un ou de plusieurs bus de messages à partir du moteur de traitement et configuré en outre pour sélectionner l'émetteur/récepteur RS232 ou l'émetteur/récepteur RS485 ou l'émetteur/récepteur CAN en fonction de la sélection d'un ou de plusieurs bus de messages ; et
- un circuit intégré prédiffusé programmable comprenant :
o la pluralité de codecs, configurés pour décoder lesdits signaux de niveau logique TTL en flux de données normalisés ;
o un multiplexeur, configuré pour sélectionner l'un des codecs en fonction de la configuration demandée ; et o une unité de filtrage et de routage de messages de données, configurée pour filtrer les flux de données normalisés.
[44] Un sélecteur de couche physique est configuré par le moteur de traitement pour sélectionner l'un des émetteurs/récepteurs de l'unité de normalisation en fonction de la sélection des bus de messages compris dans la configuration
BE2019/5150
- 28demandée distante reçue par le moteur de traitement. En d'autres termes, les BE2019/5150 émetteurs/récepteurs sont sélectionnés un par un pour récupérer des messages de données à partir de la sélection de bus de messages compris dans la configuration demandée distante. De plus, un seul multiplexeur du circuit intégré prédiffusé programmable, également appelé FPGA, sélectionne, pour chaque message de données reçu depuis un bus de messages sélectionné configuré par la configuration demandée distante, les uns ou plusieurs codecs à utiliser pour décoder les messages de données correspondants, de façon que tous les messages de données reçus à partir de ce bus de messages soient convertis en un format uniforme de flux de données normalisés. L'unité de filtrage et de routage de messages de données filtre les flux de données normalisés comme demandé par la configuration demandée distante, par exemple en supprimant des données des flux de données normalisés qui ne se trouvent pas à une adresse comprise dans la sélection d'adresses. L'unité de filtrage et de routage de messages de données achemine en outre les flux de données normalisés vers, par exemple, le moteur de traitement. En variante, le dispositif comprend facultativement une mémoire, comme par exemple un cache d'UCT ou une mémoire partagée entre le FPGA et le moteur de traitement, configurée pour stocker des messages de données et/ou des flux de données normalisés et/ou des configurations demandées distantes et/ou des règles de traitement et/ou des données du matériel roulant.
[45] Selon un aspect facultatif de l'invention, le moteur de traitement est configuré en outre pour exécuter une ou plusieurs des unes ou plusieurs règles de traitement sur les données des flux de données normalisés, pour ainsi analyser les données comprises dans les messages de données.
[46] Le moteur de traitement exécute les règles pour lire et/ou analyser les données comprises dans les flux de données normalisés reçus depuis les uns ou plusieurs bus de messages sélectionnés et les adresses sélectionnées correspondant à la sélection d'adresses. En d'autres termes, le moteur de traitement agit comme un moteur de règles qui exécute les règles de traitement sur les flux de données normalisés filtrés par le FPGA de l'unité de normalisation. Le moteur de traitement détermine ainsi un état physique du matériel roulant. Les données analogiques et/ou les données internes peuvent facultativement être utilisées par le
- 29moteur de traitement quand le moteur de traitement exécute une ou plusieurs règles BE2019/5150 de traitement.
[47] Selon un aspect facultatif de l'invention, le dispositif comprend en outre un module GSM et/ou un port Ethernet et/ou un émetteur sans fil, et dans lequel le moteur de traitement est configuré en outre pour envoyer les données via le module GSM et/ou le port Ethernet et/ou l'émetteur/récepteur sans fil.
[48] Le module GSM et/ou le port Ethernet et/ou l'émetteur/récepteur sans fil sont utilisés pour envoyer les données du matériel roulant à un système distant, qui peut se trouver à bord du matériel roulant, pour ainsi alerter en temps réel un opérateur ou un technicien sur le matériel roulant, ou ne pas se trouver à bord du matériel roulant, par exemple dans le cloud. Par exemple, le dispositif comprend facultativement une connectivité sans fil qui permet à des systèmes distants d'accéder à la base de données à distance, en partageant ainsi des connaissances sur l'état physique du matériel roulant en temps réel. De cette manière, les interventions des équipes mobiles peuvent, par exemple, suivre des données du matériel roulant, par exemple dans une application Web. De plus, la connectivité sans fil fournie par le module GSM et/ou un port Ethernet et/ou un émetteur sans fil rend la configuration du dispositif flexible. Des mises à jour de la configuration du dispositif, comme par exemple des mises à jour du mappage de bus, peuvent avoir lieu par liaison radio sans aucun impact sur la sécurité du matériel roulant.
[49] Selon un aspect facultatif de l'invention, le dispositif comprend en outre un module GPS configuré pour générer des informations de localisation, et dans lequel le moteur de traitement est configuré en outre pour coupler les informations de localisation aux données.
[50] Un emplacement géographique du matériel roulant peut être couplé à ses données. De cette manière, les données du matériel roulant peuvent être transmises à un opérateur et/ou à un technicien avec une indication géographique indiquant où les données du matériel roulant ont été collectées et/ou traitées et/ou surveillées. Cela aide un opérateur et/ou un technicien à dresser une carte de la condition du matériel roulant en fonction de l'emplacement géographique du matériel roulant et permet en outre à un opérateur et/ou à un technicien d'identifier des emplacements BE2019/5150 géographiques des données lues et/ou traitées du matériel roulant. De cette manière, il peut être possible d'associer les changements de condition du matériel roulant à des événements auxquels le matériel roulant est soumis à un emplacement géographique donné.
[51] Selon un deuxième aspect de l'invention, un ensemble configuré pour traiter des données comprises dans des messages de données passant sur des bus de messages d'un matériel roulant est fourni, l'ensemble comprenant un dispositif selon le premier aspect de l'invention et dans lequel l'ensemble comprend en outre des bus de messages se conformant aux trois couches physiques suivantes :
- RS232 ;
- R485;
- CAN.
[52] Selon un troisième aspect de l'invention, un système comprenant un dispositif selon le premier aspect de l'invention est fourni, et comprenant en outre un éditeur de règles distant configuré pour générer la configuration demandée distante ; et dans lequel le dispositif est couplé de manière fonctionnelle à l'éditeur de règles distant via ledit récepteur de configuration distante.
[53] De cette manière, le dispositif est mis à jour et configuré à distance sur un réseau de communication et à la volée. Habituellement, des systèmes de surveillance de performances comprennent des codes de dysfonctionnement TCMS qui sont programmés une fois lors de la fabrication des systèmes de surveillance de performances et mis à jour uniquement pour des raisons de sécurité et de conformité, rarement pour des raisons de maintenance. Comme le dispositif est sûr et n'interfère pas nécessairement avec le logiciel du matériel roulant et/ou avec les bus de messages, le système fournit un taux d'itération beaucoup plus rapide pour concevoir de nouvelles règles. L'éditeur de règles comprend, par exemple, une application Web dans laquelle une tierce partie peut programmer des règles sur le dispositif et récupérer des messages télématiques, par exemple via le Web, Message Queuing Telemetry Transport ou MQTT, ou HTTP Rest, par exemple.
- 31[54] Selon un aspect facultatif de l'invention, l'éditeur de règles distant comprend BE2019/5150 une interface utilisateur de génération de règles permettant à un ou plusieurs utilisateurs de générer les unes ou plusieurs règles de traitement.
[55] Le dispositif est de préférence couplé de manière fonctionnelle à l'éditeur de règles distant via le récepteur de configuration distant. En variante, le dispositif peut comprendre l'éditeur de règles distant. De préférence, l'éditeur de règles distant n'est de préférence pas compris dans le dispositif, ce qui permet des mises à jour à distance de la configuration du dispositif. L'éditeur de règles distant est configuré pour permettre à un opérateur et/ou à un technicien d'éditer une configuration demandée distante pour le matériel roulant. La configuration demandée distante comprend une ou plusieurs règles de traitement qui sont donc générées du côté d'un opérateur et/ou d'un technicien. Il est donc possible de sélectionner le ou les bus de messages à surveiller.
[56] Selon un aspect facultatif de l'invention, le système comprend en outre un ou plusieurs modules d'acquisition déportés et un ou plusieurs liens de communication ; et dans lequel :
- chacun des modules d'acquisition déportés comprend :
o une interface d'entrée universelle déportée, configurée pour recevoir des messages de données déportées se conformant aux trois couches physiques suivantes :
RS232;
RS485;
CAN;
à partir de bus de messages, les messages de données déportées comprenant des données déportées ;
o une unité de normalisation déportée, configurée pour décoder en fonction d'une configuration demandée distante les messages de données déportées en flux de données déportées normalisés comprenant les données déportées ;
- le moteur de traitement du dispositif est configuré en outre pour configurer, sur les uns ou plusieurs liens de communication, chacune des unités de normalisation déportées en fonction de la configuration demandée distante de
- 32façon que chacune des unités de normalisation reçoive des messages de BE2019/5150 données déportées depuis l'interface d'entrée universelle déportée respective en fonction de la sélection d'un ou de plusieurs bus de messages ;
- chacun des modules d'acquisition déportés est configuré en outre pour fournir au moteur de traitement du dispositif les flux de données déportées normalisés comprenant les données déportées sur les uns ou plusieurs liens de communication
- le moteur de traitement est configuré en outre pour recevoir les flux de données déportées normalisés depuis les modules d'acquisition déportés ; et
- le moteur de traitement est configuré en outre pour traiter les données déportées par l'application d'une ou de plusieurs des unes ou plusieurs règles de traitement sur les données déportées des flux de données déportées normalisés en fonction de la configuration demandée distante.
[57] De cette manière, un maillage de modules d'acquisition déportés est créé dans le matériel roulant afin de traiter les données déportées du matériel roulant. Le dispositif configure à distance chaque module d'acquisition déporté et chaque module d'acquisition déporté fournit au dispositif les flux de données déportées normalisés comprenant les données déportées. De cette manière, le dispositif reçoit des flux de données déportées normalisés comprenant des données déportées provenant d'un ou de plusieurs bus de messages à qui il est couplé via des modules d'acquisition déportés. En d'autres termes, quand par exemple l'interface d'entrée universelle n'est pas capable de recevoir des messages de données provenant de bus de messages supplémentaires, par exemple quand tous les ports de connexion de l'interface d'entrée universelle sont déjà occupés par les bus de messages, un ou plusieurs modules d'acquisition déportés sont configurés pour recevoir des messages de données déportées comprenant des données déportées provenant de ces bus de messages supplémentaires, et les uns ou plusieurs modules d'acquisition déportés sont configurés en outre pour décoder les messages de données déportées en flux de données déportées normalisés comprenant les données déportées en fonction d'une configuration demandée distante qu'ils ont reçue depuis le dispositif. Le dispositif est ensuite configuré en outre pour recevoir les flux de données déportées normalisés sur un ou plusieurs liens de communication et pour traiter à partir de ceux-ci les données déportées du matériel roulant. En d'autres termes, le moteur de traitement a traité les données déportées du matériel roulant en fonction d'une ou de plusieurs desdites règles de traitement de la configuration demandée distante.
[58] Selon un aspect facultatif de l'invention, les uns ou plusieurs liens de communication comprennent un ou plusieurs des suivants :
- un lien de communication sans fil ;
- un lien de communication Ethernet.
[59] Facultativement, les modules d'acquisition déportés peuvent communiquer seulement avec le dispositif selon la présente invention.
[60] Selon un quatrième aspect de la présente invention, un procédé de traitement de données provenant de messages de données passant sur des bus de messages d'un matériel roulant est fourni, le procédé comprenant les étapes suivantes :
- la réception au niveau d'une interface d'entrée universelle de messages de données se conformant aux trois couches physiques suivantes :
o RS232 ;
o RS485 ;
o CAN;
à partir des bus de messages, les messages de données comprenant des données ;
- la réception d'une configuration demandée distante comprenant une ou plusieurs règles de traitement ;
- le décodage en fonction de la configuration demandée distante des messages de données en flux de données normalisés comprenant les données ; et
- le traitement des données par l'application d'une ou de plusieurs des unes ou plusieurs règles de traitement sur les données des flux de données normalisés en fonction de la configuration demandée distante.
[61] Le procédé selon la présente invention comprend l'utilisation d'une interface d'entrée universelle. Le procédé est configuré pour traiter des données comprises dans des messages de données passant sur des bus de messages utilisant une couche physique RS232 et sur des bus de messages utilisant une couche physique
BE2019/5150
- 34RS485 et sur des bus de messages utilisant une couche physique CAN. En d'autres termes, le procédé selon la présente invention comprend la réception de messages de données se conformant à trois couches physiques différents et/ou protocoles différents. Des dispositifs se trouvant à l'intérieur de la même locomotive ou de la même voiture de chemin de fer, qui comprennent différentes interfaces d'entrée et/ou de sortie pouvant être incompatibles les unes avec les autres, sont tous capables de communiquer par l'intermédiaire de l'unique interface d'entrée universelle. Le procédé selon la présente invention offre donc une plate-forme unifiée à laquelle la majorité et de préférence la totalité des dispositifs embarqués du matériel roulant peut être couplée sans qu'il soit nécessaire d'interposer, par exemple, des cartes d'extension ou des connecteurs enfichables. Le procédé selon la présente invention convertit tous les messages de données reçus au niveau de l'interface d'entrée universelle en flux de données normalisés indépendamment de la couche physique utilisée par le bus de messages sur lequel les messages de données passent. Quand le procédé de la présente invention est utilisé, des systèmes de surveillance pour la gestion d'un parc ferroviaire ne doivent plus comprendre une pluralité de connecteurs enfichables et de cartes d'interface ou d'extension, ce qui rend leur mise en œuvre dans un matériel roulant simple et facile. Le procédé selon la présente invention permet une surveillance continue, en temps réel, fiable, non intrusive et centralisée de la condition d'un matériel roulant.
[62] Selon un cinquième aspect de l'invention, un procédé pour des données comprises dans des messages de données passant sur des bus de messages d'un matériel roulant est fourni, le procédé comprenant les étapes suivantes :
- la fourniture d'un ou de plusieurs modules d'acquisition déportés et d'un ou de plusieurs liens de communication, dans lequel chacun des modules d'acquisition déportés comprend une interface d'entrée universelle déportée et une unité de normalisation déportée ;
- la réception, via les interfaces d'entrée universelles déportées, de messages de données déportées se conformant aux trois couches physiques suivantes :
o RS232 ; o RS485 ;
o CAN;
BE2019/5150
-35à partir de bus de messages, les messages de données déportées comprenant BE2019/5150 des données déportées ;
- le décodage, en fonction d'une configuration demandée distante et via les unités de normalisation déportées, des messages de données déportées en flux de données déportées normalisés comprenant les données déportées ;
- la configuration, sur les uns ou plusieurs liens de communication, de chacune des unités de normalisation déportées en fonction de la configuration demandée distante de façon que chacune des unités de normalisation reçoive des messages de données déportées depuis l'interface d'entrée universelle déportée respective en fonction d'une sélection d'un ou de plusieurs bus de messages ;
- la fourniture, via chacun des modules d'acquisition déportés, au moteur de traitement du dispositif selon un cinquième aspect de l'invention des flux de données déportées normalisés comprenant les données déportées sur les uns ou plusieurs liens de communication ;
- la réception des flux de données déportées normalisés depuis les modules d'acquisition déportés ; et
- le traitement des données déportées par l'application d'une ou de plusieurs des règles de traitement sur les données déportées des flux de données déportées normalisés en fonction de la configuration demandée distante.
Brève description des dessins [63] La figure 1 illustre schématiquement un mode de réalisation d'un dispositif selon la présente invention.
[64] La figure 2 illustre schématiquement un mode de réalisation d'un dispositif selon la présente invention.
[65] La figure3 illustre schématiquement un mode de réalisation d'une unité de normalisation selon la présente invention.
[66] La figure 4 illustre schématiquement un mode de réalisation d'un système selon la présente invention.
BE2019/5150 [67] La figure 5 illustre schématiquement un mode de réalisation d'une interface d'entrée universelle selon la présente invention.
[68] La figure 6 illustre schématiquement des modes de réalisation d'une unité de normalisation selon la présente invention.
[69] La figure 7 illustre schématiquement un mode de réalisation des étapes d'un procédé selon la présente invention.
Description détaillée de mode(s) de réalisation [70] Selon un mode de réalisation présenté sur la figure 1, un dispositif 100 comprend une interface d'entrée universelle 101, une unité de normalisation 102 et un moteur de traitement 103. Un matériel roulant comprend le dispositif 100. De préférence, le dispositif 100 est embarqué sur un matériel roulant. L'interface d'entrée universelle 102 reçoit des messages de données 200 provenant d'un ou de plusieurs bus de messages 20. Les messages de données 200 passent sur des bus de messages 20 utilisant une couche physique RS232, une couche physique RS485 et une couche physique CAN. Les messages de données 200 passant sur les différents bus sont différents les uns des autres. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique RS232, comme une ou plusieurs interfaces série. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique RS485, comme un ou plusieurs bus de messages 20 avec des couches physiques définies par un ou plusieurs des suivants : J1708, bus de véhicule multifonction, Modbus, On-Board Diagnostic, une interface série, etc. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique CAN, comme un ou plusieurs bus de messages 20 avec des couches physiques définies par un ou plusieurs des suivants : J1939, réseau local de commande, etc. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus Ethernet. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus numériques. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus analogiques. En d'autres termes, l'interface d'entrée universelle 102 reçoit des messages de données 200 se conformant aux trois couches physiques suivantes : RS232, RS485, CAN, à partir des bus de messages 20, et les messages de données 200 comprennent des données 10. L'unité de normalisation 102 reçoit les messages de données 200 depuis l'interface d'entrée universelle 101. L'unité de normalisation 102 décode les messages de données 200 en flux de données normalisés 201 comprenant les données 10 en fonction d'une configuration demandée distante 300 reçue par le dispositif 100, où la configuration demandée 300 comprend uneou plusieurs règles de traitement 400. Le moteur de traitement 103 reçoit la configuration demandée distante 300 et reçoit les flux de données normalisés 201 comprenant les données 10 depuis l'unité de normalisation 102. La configuration demandée distante 300 comprend une ou plusieurs règles de traitement 400. Le moteur de traitement 103 traite les données 10 du matériel roulant provenant des flux de données normalisés 201 en fonction de la configuration demandée distante 300 par l'application d'une ou de plusieurs des unes ou plusieurs règles de traitement 400 sur les données 10 des flux de données normalisés 201.
[71] Selon un mode de réalisation présenté sur la figure 2, un dispositif 100 comprend une interface d'entrée universelle 101, une unité de normalisation 102 et un moteur de traitement 103. Un matériel roulant comprend le dispositif 100. De préférence, le dispositif 100 est embarqué sur un matériel roulant. Le dispositif 100 comprend en outre une batterie 109. Facultativement, l'interface d'entrée universelle 101 du dispositif 100 comprend en outre une unité de collecte de données analogiques 160 qui est configurée pour collecter des données analogiques 310 à partir du matériel roulant et/ou de tout dispositif embarqué sur le matériel roulant. Par exemple, l'unité de collecte de données analogiques 160 est configurée pour recevoir des données analogiques 310 provenant du matériel roulant. Facultativement, le dispositif 100 comprend en outre une unité de collecte de données internes 161 configurée pour collecter des données internes 162 à partir du dispositif 100. Par exemple, les données internes 162 comprennent un niveau de batterie de la batterie 109 du dispositif 100 qui est collecté à partir du dispositif 100 par l'unité de collecte de données internes 161, et/ou les données internes 162
BE2019/5150
- 38comprennent, par exemple, une température du dispositif 100, et/ou les données internes 162 comprennent des informations de localisation 500 concernant le matériel roulant, et/ou les données internes 162 comprennent des informations générées par le module GSM 105 et/ou l'émetteur sans fil 107, par exemple des données cellulaires 163 provenant du module GSM 105. Selon un mode de réalisation en variante, le dispositif 100 comprend une prise d'alimentation 109 configurée pour être couplée à une source d'alimentation. Le dispositif 100 comprend en outre un récepteur de configuration distante 104 configuré pour recevoir une configuration demandée distante 300, où la configuration demandée distante 300 comprend une ou plusieurs règles de traitement 400. L'interface d'entrée universelle 101 reçoit des messages de données 200 provenant d'un ou de plusieurs bus de messages 20. L'interface d'entrée universelle 101 comprend au moins un module d'entrée RS232 61 configuré pour recevoir des messages de données 200 se conformant à une couche physique RS232, tels qu'un ou plusieurs messages de données 200 se conformant à des interfaces série, etc. L'interface d'entrée universelle 101 comprend en outre au moins un module d'entrée RS485 62 configuré pour recevoir des messages de données 200 se conformant à une couche physique RS485, tels qu'un ou plusieurs messages de données 200 se conformant à des couches physiques définies par un ou plusieurs des suivants : J1708, bus de véhicule multifonction, Profibus, Modbus, On-Board Diagnostic, une interface série, etc. L'interface d'entrée universelle 101 comprend en outre au moins un module d'entrée CAN 63 configuré pour recevoir des messages de données 200 se conformant à une couche physique CAN, tels qu'un ou plusieurs messages de données 200 se conformant à des couches physiques définies par un ou plusieurs des suivants : J1939, réseau local de commande, etc. Facultativement, l'interface d'entrée universelle 101 comprend en outre au moins un module d'entrée Ethernet 64 configuré pour recevoir des messages de données 200 se conformant à la norme PROFINET et/ou un ou plusieurs messages de données 200 se conformant à un réseau de communication ferroviaire, tel qu'un réseau central ferroviaire Ethernet. Facultativement, l'interface d'entrée universelle 101 comprend en outre au moins un module d'entrée numérique 65 configuré pour recevoir des messages de données numériques 200. Les messages de données 200 passent sur des bus de messages 20 utilisant une couche physique RS232, une couche physique RS485 et une couche physique CAN. Les messages de données 200 passant sur les différents
BE2019/5150
-39bus sont différents les uns des autres. Les uns ou plusieurs bus de messages 20 BE2019/5150 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique RS232, comme une ou plusieurs interfaces série. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique RS485, comme un ou plusieurs bus de messages 20 avec des couches physiques définies par un ou plusieurs des suivants : J1708, bus de véhicule multifonction, Modbus, On-Board Diagnostic, une interface série, etc. Les uns ou plusieurs bus de messages20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique CAN, comme un ou plusieurs bus de messages 20 avec des couches physiques définies par un ou plusieurs des suivants : J1939, réseau local de commande, etc. Les uns ou plusieurs bus de messages 20 peuvent comprendre, par exemple, un ou plusieurs bus Ethernet. Les uns ou plusieurs bus de messages 20 peuvent comprendre, par exemple, un ou plusieurs bus numériques. En d'autres termes, l'interface d'entrée universelle 102 reçoit des messages de données 200 se conformant aux trois couches physiques suivantes : RS232, RS485, CAN, à partir des bus de messages 20, et les messages de données 200 comprennent des données 10. L'unité de normalisation 102 reçoit les messages de données 200 depuis l'interface d'entrée universelle 101. Sur la figure 1, l'interface d'entrée universelle 101 reçoit des messages de données 200 provenant d'un bus de messages 20. L'unité de normalisation 102 comprend un sélecteur de couche physique 142, un émetteur/récepteur RS232 112, un émetteur/récepteur RS485 122, un émetteur/récepteur CAN 132 et un circuit intégré prédiffusé programmable 152 également appelé FPGA 152. Le sélecteur de couche physique 142 de l'unité de normalisation 102 reçoit les messages de données 200 depuis l'interface d'entrée universelle 101. L'unité de normalisation 102 décode les messages de données 200 en flux de données normalisés 201 comprenant les données 10 en fonction de la configuration demandée distante 300. Le sélecteur de couche physique 142 reçoit une sélection 301 d'un ou plusieurs bus de messages 20 provenant du moteur de traitement 103 à partir duquel le dispositif 100 lit et/ou traite des messages de données 200 afin de traiter des données 10 du matériel roulant. En d'autres termes, le moteur de traitement 103 configure l'unité de normalisation 102 en fonction de la configuration demandée distante 300 de façon que l'unité de normalisation 102 lise et/ou collecte des messages de données 200 à des fins de traitement à partir de l'interface d'entrée universelle 101 en fonction de la
- 40sélection 301 d'un ou plusieurs bus de messages 20. La configuration demandée BE2019/5150 distante 300 comprend la sélection 301 d'un ou de plusieurs bus de messages 20 et une sélection d'adresses 302. Le sélecteur de couche physique 142 sélectionne l'émetteur/récepteur RS232 112 ou sélectionne l'émetteur/récepteur RS485 122 ou sélectionne l'émetteur/récepteur CAN 132 en fonction de la sélection 301 des uns ou plusieurs bus de messages 20. L'émetteur/récepteur RS232 112 convertit les messages de données 200 avec une couche physique RS232 en signaux de niveau logique TTL 202. L'émetteur/récepteur RS485 122 convertit les messages de données 200 avec une couche physique RS485 en signaux de niveau logique TTL 202. L'émetteur/récepteur CAN 132 convertit les messages de données 200 avec une couche physique CAN en signaux de niveau logique TTL 202. Le FPGA 152 comprend une pluralité de codecs 120, où chacun des codecs 120 décode les signaux de niveau logique TTL 202 correspondants en flux de données normalisés 201. Le FPGA 152 comprend en outre un multiplexeur 153 qui sélectionne l'un des codecs 120 en fonction de la configuration demandée distante 300. En d'autres termes, le moteur de traitement 103 configure le multiplexeur 153 du FPGA 152 en fonction de la configuration demandée distante 300 pour sélectionner et activer l'un des codecs 120 afin de décoder les signaux de niveau logique TTL 202 correspondants en des flux de données normalisés 201 comprenant les données 10. Le multiplexeur 153 est configuré en outre pour collecter les flux de données normalisés 201 décodés par le codec activé 120 et est configuré en outre pour transmettre les flux de données normalisés 201 à une unité de filtrage et de routage de messages de données 154. Selon un mode de réalisation alternatif, le FPGA 152 comprend en outre un second multiplexeur configuré pour collecter les flux de données normalisés 201 décodés par le codec activé 120 et est configuré en outre pour transmettre les flux de données normalisés 201 comprenant les données 10 à une unité de filtrage et de routage de messages de données 154. Le FPGA 152 comprend en outre une unité de filtrage et de routage de message de données 154 qui filtre les flux de données normalisés 201. Par exemple, le moteur de traitement 103 est configuré pour configurer l'unité de filtrage et de routage de messages de données 154 en fonction de la configuration demandée distante 300. Plus particulièrement, le moteur de traitement 103 est configuré pour configurer l'unité de filtrage et de routage de messages de données 154 en fonction de la sélection d'adresses 302 de la
- 41BE2019/5150 configuration demandée distante 300. L'unité de filtrage et de routage de messages de données 154 filtre ensuite, parmi les flux de données normalisés 201 reçus depuis le multiplexeur 153, uniquement les flux de données normalisés 201 correspondant à la sélection d'adresses 302 de la configuration demandée distante 300. L'unité de filtrage et de routage de messages de données 154 délivre ensuite en sortie les flux de données normalisés 201 comprenant les données 10 correspondant à la sélection d'adresses 302 de la configuration demandée distante 300. Le moteur de traitement 103 reçoit la configuration demandée distante 300 depuis le récepteur de configuration distante 104. Le moteur de traitement 103 reçoit également les flux de données normalisés 201 comprenant les données 10 depuis l'unité de filtrage et de routage de messages de données 154 de l'unité de normalisation 102. Facultativement, le dispositif 100 comprend en outre une mémoire 110. La mémoire 110 est partagée entre le FPGA 152 de l'unité de normalisation 102 et le moteur de traitement 103. Par exemple, la mémoire est un cache d'UCT. Selon un mode de réalisation alternatif, le moteur de traitement 103 comprend la mémoire 110. Selon un autre mode de réalisation alternatif, le FGPA 152 comprend la mémoire 110. L'unité de filtrage et de routage de messages de données 154 peut facultativement stocker des flux de données normalisés 201 correspondant à la sélection d'adresses 302 de la configuration demandée distante 300 dans la mémoire 110 et le moteur de traitement 103 peut facultativement récupérer des flux de données normalisés filtrés 201 à partir de la mémoire 110. La configuration demandée distante 300 reçue depuis le récepteur de configuration distante 104 comprend une ou plusieurs règles de traitement 400. Les unes ou plusieurs règles de traitement 400 comprennent un ou plusieurs des suivants : une ou plusieurs métriques prédéfinies, une ou plusieurs clés prédéfinies, une ou plusieurs estampilles temporelles prédéfinies, un ou plusieurs seuils prédéfinis, un ou plusieurs modèles d'apprentissage machine préformés, un ou plusieurs modèles d'apprentissage profond préformés, un ou plusieurs compteurs, une ou plusieurs fonctions de sous-échantillonnage et/ou fonctions de non échantillonnage, une ou plusieurs fonctions algorithmiques. Le moteur de traitement 103 traite les données 10 du matériel roulant provenant des flux de données normalisés 201 en fonction de la configuration demandée distante 300. Le moteur de traitement 103 comprend un récepteur de configuration de données 113, un récepteur de règles de traitement 123 et un moteur de règles 133. Le récepteur
- 42de configuration de données 113 reçoit la configuration demandée distante 300 BE2019/5150 depuis le récepteur de configuration distante 104. Le récepteur de règles de traitement 123 reçoit les unes ou plusieurs règles de traitement 400 depuis le récepteur de configuration distante et reçoit en outre les données analogiques 310 depuis l'unité de collecte de données analogiques160 du dispositif 1 00 et/ou reçoit en outre les données internes 162 depuis l'unité de collecte de données internes 161. Le moteur de traitement 103 exécute une ou plusieurs des règles de traitement 400 sur les données 10 des flux de données normalisés 201, pour ainsi traiter les données 10 du matériel roulant 10. En d'autres termes, le moteur de traitement 103 comprend un moteur de règles 133 qui exécute une ou plusieurs règles de traitement 400. Les données analogiques 310 et/ou les données internes 162 peuvent facultativement être utilisées par le moteur de règles 133 lors de l'exécution d'une ou de plusieurs règles de traitement 400. Par exemple, le dispositif100 exécute une règle de traitement400 selon une configuration demandée distante 300 pour accéder à la température des freins d'un équipement du matériel roulant, la configuration demandée distante 300 comprenant une sélection 301 du bus de messages 20 sur lequel des messages de données 200 comprenant des données 10 indiquant la température des freins de cet équipement passent. La configuration demandée distante 300 comprend en outre une sélection d'adresses 302 comprenant des informations indiquant l'adresse à laquelle la température des freins doit être trouvée dans les messages de données 200 qui passent sur ce bus de messages 20. L'émetteur/récepteur correspondant qui correspond à la configuration demandée distante 300 convertit ensuite les messages de données 200 reçus en signaux de niveau logique TTL 202 qui sont décodés en flux de données normalisés 201 comprenant les données 10 par le codec 120 correspondant à la configuration demandée distante 300 reçue par le multiplexeur153 qui sélectionne le codec 120 requis. L'unité de filtrage et de routage de messages de données 154 extrait ensuite la température des freins à partir des flux de données normalisés 201 comprenant les données 10 à l'adresse dans les flux de données normalisés 201 correspondant à la sélection d'adresses 302. Le moteur de traitement 103 reçoit les flux de données normalisés 201 correspondant à la température des freins de l'équipement. Le moteur de traitement 103 reçoit la configuration demandée distante 300 depuis le récepteur de configuration 104. Le récepteur de règles 123 reçoit une règle de traitement 400 et/ou facultativement les
- 43BE2019/5150 données analogiques 310 et/ou facultativement les données internes 162. Le moteur de règles 133 du moteur de traitement 103 exécute une règle de traitement 400 en comparant la température des freins à un seuil de température prédéfini pour les freins de l'équipement. Quand la température des freins du matériel roulant dépasse le seuil de température prédéfini, le moteur de règles 133 du moteur de traitement 103 détermine que les données 10, c'est-à-dire, par exemple, la température des freins du matériel roulant 10, doivent être transmises. Le dispositif 100 comprend en outre un module GSM 105 et/ou un port Ethernet 106 et/ou un émetteur sans fil 107. Le moteur de traitement 103 envoie les données 10 du matériel roulant à, par exemple, un système distant via le module GSM 105 et/ou le port Ethernet 106 et/ou l'émetteur sans fil 107. Le dispositif 100 comprend en outre un module GPS 108 qui génère des informations de localisation 500 concernant le matériel roulant. Le moteur de traitement 103 reçoit ces informations de localisation 500 depuis le module GPS 108 et couple les informations de localisation 500 aux données 10 du matériel roulant lors de l'envoi des données 10 du matériel roulant au module GSM 105 et/ou au port Ethernet 106 et/ou à l'émetteur sans fil 107. De cette manière, le moteur de traitement 103 envoie les données 10 du matériel roulant avec des informations de localisation 500. Selon un mode de réalisation alternatif, l'état de charge de la batterie d'un équipement ferroviaire peut être surveillé avec précision et en temps réel par le dispositif 100 lors de l'utilisation d'une règle de traitement 400 comprenant une régression linéaire de la tension et du courant et de la température du moteur d'un équipement ferroviaire.
[72] Selon un mode de réalisation représenté sur la figure 3, une unité de normalisation 102 comprise dans le dispositif de la figure 1 ou de la figure 2 reçoit des messages de données 200 à partir d'un ou de plusieurs connecteurs de l'interface d'entrée universelle 101, par exemple trois connecteurs. La figure 3 est un zoom sur un mode de réalisation de l'unité de normalisation 102 de la figure 1 ou de la figure 2. Des composants ayant des numéros de référence identiques aux composants de la figure 1 ou de la figure 2 remplissent la même fonction. Chaque sélecteur de couche physique 142 de l'unité de normalisation 102 reçoit des messages de données 200 depuis un connecteur de l'interface d'entrée universelle 101. Selon un mode de réalisation alternatif, l'interface universelle d'entrée 101 comprend une pluralité de connecteurs, par exemple deux, trois, quatre, cinq, six, sept, huit, neuf ou dix, pour recevoir des messages de données 200 à partir BE2019/5150 des bus de messages 20, et l'unité de normalisation 102 comprend une pluralité de groupes correspondants de sélecteurs de couche physique 142 et d'émetteurs/récepteurs 112; 122; 132, comme par exemple deux groupes de sélecteurs de couche physique 142 et d'émetteurs/récepteurs 112;122 ;132, ou trois, ou quatre, ou cinq, ou six, ou sept, ou huit, ou neuf, ou dix groupes de sélecteurs de couche physique 142 et d'émetteurs/récepteurs 112; 122 ;132. En d'autres termes, l'unité de normalisation 102 reçoit des messages de données 200 depuis l'interface d'entrée universelle 101 qui reçoit des messages de données 200 passant sur un ou plusieurs bus de messages 20 utilisant une couche physique RS232, une couche physique RS485 et une couche physique CAN et l'unité de normalisation 102 comprend, par exemple, autant de groupes de sélecteurs de couche physique 142 et d'émetteurs/récepteurs 112; 122 ;132 que le nombre de connecteurs de l'interface d'entrée universelle 101. Les messages de données 200 passant sur les différents bus sont différents les uns des autres. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique RS232, comme une ou plusieurs interfaces série. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique RS485, comme un ou plusieurs bus de messages 20 avec des couches physiques définies par un ou plusieurs des suivants : J1708, bus de véhicule multifonction, Modbus, On-Board Diagnostic, une interface série, etc. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus 20 utilisant une couche physique CAN, comme un ou plusieurs bus de messages 20 avec des couches physiques définies par un ou plusieurs des suivants : J1939, réseau local de commande, etc. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus Ethernet. Les uns ou plusieurs bus de messages 20 comprennent, par exemple, un ou plusieurs bus numériques. En d'autres termes, l'interface d'entrée universelle 102 reçoit des messages de données 200 se conformant aux trois couches physiques suivantes : RS232, RS485, CAN, à partir des bus de messages 20, et les messages de données 200 comprennent des données 10. L'unité de normalisation 102 décode les messages de données 200 en flux de données normalisés 201 comprenant les données 10 en fonction d'une configuration demandée distante 300. La configuration demandée distante 300 comprend une sélection 301 d'un ou de plusieurs bus de
- 45BE2019/5150 messages 20 et une sélection d'adresses 302. Le sélecteur de couche physique 142 reçoit la sélection 301 à partir de la configuration demandée distante 300 d'un ou plusieurs bus de messages 20 à partir de laquelle l'unité de normalisation 102 décode des messages de données 200 afin de traiter des données 10 du matériel roulant. En d'autres termes, l'unité de normalisation 102 collecte des messages de données 200 à partir de l'interface d'entrée universelle 101 en fonction de la sélection 301 des uns ou plusieurs bus de messages 20. À chaque sélecteur de couche physique 142 est couplé un émetteur/récepteur RS232 112, un émetteur/récepteur RS485 122, un émetteur/récepteur CAN 132 et un circuit intégré prédiffusé programmable 152 également appelé FPGA 152. Chaque sélecteur de couche physique 142 sélectionne l'émetteur/récepteur RS232 112 correspondant ou sélectionne l'émetteur/récepteur RS485 122 correspondant ou sélectionne l'émetteur/récepteur CAN 132 correspondant en fonction de la sélection 301 des uns ou plusieurs bus de messages 20. Chaque émetteur/récepteur RS232 112 convertit les messages de données 200 avec une couche physique RS232 en signaux de niveau logique TTL 205 ; 206; 207. Chaque émetteur/récepteur RS485 122 convertit les messages de données 200 avec une couche physique RS485 en signaux de niveau logique TTL 205 ;206; 207. Chaque émetteur/récepteur CAN 132 convertit les messages de données 200 avec une couche physique CAN en signaux de niveau logique TTL 205 ;206; 207. L'unité de normalisation 102 comprend en outre un FPGA 152 qui comprend six codecs 120, où chacun des codecs 120 décode les signaux de niveau logique TTL correspondants 205; 206; 207 en des flux de données normalisés 201 en fonction de la configuration demandée 300 reçue depuis un unique multiplexeur 153. Chaque codec est configuré pour décoder les signaux de niveau logique TTL 205; 206 ; 207 correspondant au type d'interface physique sur laquelle les messages de données 200 passent. Selon un mode de réalisation alternatif, le FPGA 152 comprend une pluralité de codecs, par exemple deux, trois, quatre, cinq, dix, des dizaines, des centaines de codecs 120. Le FPGA 152 comprend en outre l'unique multiplexeur 153 qui sélectionne et active un codec 120 pour chaque groupe de sélecteur de couche physique 142 et d'émetteurs/récepteurs 112; 122; 132, et donc pour chaque connecteur de l'interface d'entrée universelle 101, en fonction de la configuration demandée distante 300. Par exemple, sur la figure 3, le FPGA 152 sélectionne un codec 120 pour le premier groupe de sélecteur de couche physique 142 et
- 46BE2019/5150 d'émetteurs/récepteurs 112; 122; 132 et sélectionne un autre codec 120 pour le deuxième groupe de sélecteur de couche physique 142 et d'émetteurs/récepteurs 112; 122; 132, et sélectionne encore un autre codec 120 pour le troisième groupe de sélecteur de couche physique 142 et d'émetteurs/récepteurs 112; 122; 132. L'unique multiplexeur 153 du FPGA 152 est configuré via la configuration demandée distante 300 pour sélectionner un ou plusieurs des codecs 120 afin de décoder les signaux de niveau logique TTL 205; 206 ; 207 correspondants en des flux de données normalisés 201 comprenant les données 10. Selon un mode de réalisation alternatif, le multiplexeur 153 peut sélectionner et activer une pluralité de codecs 120 pour chaque groupe de sélecteur de couche physique 142 et d'émetteurs/récepteurs 112; 122; 132, et donc pour chaque connecteur de l'interface d'entrée universelle 101, en fonction de la configuration demandée distante 300. Par exemple, le multiplexeur 153 peut sélectionner et activer deux codecs 120 quand les messages de données 200 correspondant aux signaux de niveau logique TTL passent sur un bus de messages utilisant une couche physique RS485, comme un bus de véhicule multifonction, et les deux codecs 120 décodent les signaux de niveau logique TTL correspondants en des flux de données normalisés 201 comprenant les données 10. Par exemple, le multiplexeur 153 peut sélectionner et activer trois codecs 120 quand les messages de données 200 correspondant aux signaux de niveau logique TTL passent sur un bus de messages utilisant une couche physique CAN, et les trois codecs 120 décodent les signaux de niveau logique TTL correspondants en des flux de données normalisés 201 comprenant les données 10. Les codecs 120 du FPGA 152 qui ne sont pas activés par le multiplexeur 153 restent inactifs pendant le décodage des signaux de niveau logique TTL 205 ; 206; 207 en des flux de données normalisés 201 comprenant les données 10. Le FPGA 152 comprend en outre un second multiplexeur 155 qui est configuré pour collecter les flux de données normalisés 201 comprenant les données 10 à partir de tous les codecs 120 sélectionnés et activés. Le FPGA 152 comprend en outre une unité de filtrage et de routage de messages de données 154 qui filtre les flux de données normalisés 201 comprenant les données 10 reçues depuis le second multiplexeur 155. Selon un mode de réalisation alternatif, le multiplexeur 153 comprend le second multiplexeur 155. Par exemple, le moteur de traitement 103 est configuré pour configurer l'unité de filtrage et de routage de
- 47messages de données 154 via la configuration demandée distante 300. Plus BE2019/5150 particulièrement, l'unité de filtrage et de routage de messages de données 154 est configurée via la sélection d'adresses 302 de la configuration demandée distante 300. L'unité de filtrage et de routage de messages de données 154 filtre ensuite, parmi les flux de données normalisés 201 comprenant les données 10 reçus depuis le multiplexeur 153, uniquement les flux de données normalisés 201 correspondant à la sélection d'adresses 302 de la configuration demandée 300. L'unité de filtrage et de routage de messages de données 154 délivre ensuite en sortie les flux de données normalisés 201 comprenant les données 10 correspondant à la sélection d'adresses 302 de la configuration demandée distante 300. Les flux de données normalisés 201 délivrés en sortie comprenant les données 10 sont ensuite introduits dans le moteur de traitement du dispositif 100 de la figure 1 ou de la figure 2, comme expliqué dans la description de la figure 1 et de la figure 2.
[73] Selon un mode de réalisation représenté sur la figure 4, un système 1 comprend un dispositif 100 identique au dispositif 100 décrit sur la figure 1 et la figure 2 ou la figure 3. Des composants ayant les mêmes numéros de référence remplissent la même fonction. Le système 1 de la figure 4 comprend en outre un éditeur de règles distant 30 configuré pour générer la configuration demandée distante 300. L'éditeur de règles distant 30 comprend une interface utilisateur de génération de règles 31 permettant à un ou plusieurs utilisateurs 2 de générer les unes ou plusieurs règles de traitement 400. Le dispositif 100 est couplé de manière fonctionnelle à l'éditeur de règles distant 30 via le récepteur de configuration distante 104. Facultativement, le système 1 comprend en outre un ou plusieurs modules d'acquisition déportés 40, par exemple des dizaines ou des centaines de modules d'acquisition déportés 40. De plus, le système 1 comprend en outre un ou plusieurs liens de communication 50, par exemple des dizaines ou des centaines de liens de communication 50. Les uns ou plusieurs liens de communication 50 comprennent un ou plusieurs des suivants : un lien de communication sans fil, un lien de communication Ethernet. Les liens de communication 50 sont positionnés entre le dispositif 100 et chacun des modules déportés 40 de telle sorte que chacun des modules déportés 40 est couplé de manière fonctionnelle au dispositif 100. Selon un mode de réalisation alternatif, les liens de communication 50 sont positionnés entre l'interface d'entrée universelle 101 du dispositif 100 et chacun des
- 48BE2019/5150 modules déportés 40. Chacun des modules déportés 40 comprend une interface d'entrée universelle déportée 41 et une unité de normalisation déportée 42. L'interface d'entrée universelle déportée 41 reçoit des messages de données déportés 203 depuis les bus de messages 20 utilisant une couche physique RS232, une couche physique RS485 et une couche physique CAN. Les messages de données déportés 200 passant sur les différents bus sont différents les uns des autres. L'unité de normalisation déportée 42 décode les messages de données déportés 203 en flux de données déportées normalisés 204 comprenant les données déportées 11 en fonction de la configuration demandée distante 300. Le moteur de traitement 103 du dispositif 100 configure chacune des unités de normalisation déportées 42 sur un ou plusieurs des liens de communication 50 en fonction de la configuration demandée distante 300. De cette manière, chacune des unités de normalisation 42 reçoit des messages de données déportées 203 comprenant des données déportées 11 depuis l'interface d'entrée universelle déportée respective 41 en fonction de la sélection 301 des uns ou plusieurs bus de messages 20. Chacun des modules d'acquisition déportés 40 est configuré en outre pour fournir au moteur de traitement 103 du dispositif 100 les flux de données déportées normalisés comprenant les données 11 sur les uns ou plusieurs liens de communication 50.
[74] Selon un mode de réalisation représenté sur la figure 5, l'interface d'entrée universelle 101 du dispositif 100 telle que représentée sur les figures 1 à 4 comprend cinq connecteurs d'entrée universels identiques 81 ; 82 ; 83 ;84 ; 85. Selon un mode de réalisation alternatif, l'interface d'entrée universelle 101 comprend un ou plusieurs connecteurs d'entrée universels, par exemple un, deux, trois, quatre, six, sept, huit, neuf, dix, etc. De cette manière, l'interface d'entrée universelle 101 est capable de recevoir des messages de données passant sur des bus de messages utilisant une couche physique RS232, une couche physique RS485 et une couche physique CAN. L'interface d'entrée universelle 101 du dispositif 100 comprend en outre deux connecteurs 88 ;89 pour données analogiques qui permettent à l'interface d'entrée universelle 101 de recevoir des données analogiques. L'interface d'entrée universelle 101 du dispositif 100 comprend en outre un connecteur Ethernet 86 configuré pour recevoir et/ou transmettre des données à partir du dispositif 100. L'interface d'entrée universelle 101 du dispositif 100 comprend en outre facultativement une DEL ACT92 qui fournit des informations indiquant un niveau de
- 49batterie du dispositif 100. L'interface universelle d'entrée 101 du dispositif 100 BE2019/5150 comprend en outre facultativement un connecteur USB 87, un connecteur GPS 90 et/ou un connecteur GSM 91.
[75] Selon un mode de réalisation représenté sur la figure 6, plusieurs exemples de configuration de l'interface d'entrée universelle 101 de la figure 5 sont représentés. Les connecteurs d'entrée universels 81 ; 82 ; 83 ; 84 ;85 de la figure 5 sont utilisés pour recevoir et/ou transmettre des messages de données à partir de bus de messages utilisant une couche physique CAN, comme illustré dans la configuration CAN 93. Les connecteurs d'entrée universels 81 ;82 ; 83 ; 84; 85 de la figure 5 sont utilisés pour recevoir et/ou transmettre des messages de données à partir de bus de messages utilisant une couche physique RS485, comme illustré dans la configuration RS485 94. Les connecteurs d'entrée universels 81 ; 82 ;83 ; 84 ; 85 de la figure 5 sont utilisés pour transmettre sur et/ou recevoir depuis des bus de messages utilisant une couche physique RS232, comme illustré dans la configuration RS232 95. Les connecteurs d'entrée universels 81 ; 82 ;83 ; 84 ; 85 de la figure 5 sont utilisés pour transmettre sur et/ou recevoir depuis des bus de messages utilisant une couche physique RS485, comme illustré dans la configuration RS485 en duplex intégral 96. Les connecteurs d'entrée universels 81 ; 82 ;83 ; 84 ; 85 de la figure 5 sont utilisés pour transmettre sur et/ou pour recevoir depuis et respectivement pour une demande de transmission et un signal de voie libre sur des bus de messages utilisant une couche physique RS232, comme illustré dans la configuration de commande de débit matériel RS232 97.
[76] Selon un mode de réalisation représenté sur la figure 7, un procédé est utilisé pour traiter des données 10 d'un matériel roulant à partir de messages de données 200 passant sur des bus de messages. Le procédé comprend l'étape 901 de réception de messages de données 200 se conformant aux trois couches physiques suivantes : RS232, RS485, CAN, à partir des bus de messages 20 via l'interface d'entrée universelle 101, où les messages de données 200 comprennent des données 10. Le procédé comprend en outre l'étape 902 de réception d'une configuration demandée distante 300 comprenant une ou plusieurs règles de traitement 400. Le procédé comprend en outre l'étape 903 de décodage des messages de données 200 en flux de données normalisés 201 comprenant les données 10 en fonction de la configuration demandée distante 300. Dans BE2019/5150 l'étape 904, le procédé comprend le traitement des données 10 du matériel roulant à partir des flux de données normalisés 201 en appliquant une ou plusieurs des règles de traitement 400 de la configuration demandée distante300 sur lesdites données 10 des flux de données normalisés 201 en fonction de la configuration demandée distante 300.
[77] Bien que la présente invention ait été illustrée en se référant à des modes de réalisation spécifiques, il sera apparent à l'homme du métier que l'invention n'est pas limitée aux détails des modes de réalisation illustratifs précédents, et que la présente invention peut être mise en œuvre avec divers changements et diverses modifications sans s'écarter de sa portée. Les présents modes de réalisation doivent donc être considérés à tous égards comme illustratifs et non restrictifs, la portée de l'invention étant indiquée par les revendications annexées plutôt que par la description qui précède, et tous les changements qui entrent dans le sens et la plage d'équivalence des revendications sont donc destinés à être englobés par celles-ci. En d'autres termes, il est envisagé de couvrir toutes les modifications, variations ou tous les équivalents qui entrent dans la portée des principes de base sous-jacents et dont des attributs essentiels sont revendiqués dans la présente demande de brevet. En outre, le lecteur de la présente demande de brevet comprendra que les mots « comprenant» ou « comprendre » n'excluent pas d'autres éléments ou étapes, que les mots « un » ou « une » n'excluent pas une pluralité, et qu'un seul élément, tel qu'un système informatique, un processeur ou une autre unité intégrée, peut remplir les fonctions de plusieurs moyens énoncés dans les revendications. Les signes de référence dans les revendications ne doivent pas être interprétés comme limitant les revendications en question. Les termes « premier », « deuxième », « troisième », « a », « b », « c » et équivalents, lorsqu'ils sont utilisés dans la description ou dans les revendications, sont introduits pour faire la distinction entre des éléments ou des étapes similaires et ne décrivent pas nécessairement un ordre séquentiel ou chronologique. De même, les termes «haut», « bas », «sur», «sous», etc., sont introduits à des fins de description et ne désignent pas nécessairement des positions relatives. Il doit être compris que les termes ainsi utilisés sont interchangeables dans des circonstances appropriées et que des modes de réalisation de l'invention sont capables de fonctionner selon la présente invention dans d'autres séquences, ou dans des orientations différentes de celles décrites ou illustrées ci-dessus. BE2019/5150
Claims (15)
- REVENDICATIONS1. Dispositif (100) configuré pour traiter des données (10) comprises dans des messages de données (200) passant sur des bus de messages (20) d'un matériel roulant, ledit dispositif (100) comprenant :- une interface d'entrée universelle (101), configurée pour recevoir des messages de données (200) se conformant aux trois couches physiques suivantes : o RS232 ;o RS485 ;o CAN;à partir desdits bus de messages (20), lesdits messages de données (200) comprenant des données (10) ;- un moteur de traitement (103), configuré pour recevoir une configuration demandée distante (300) comprenant une ou plusieurs règles de traitement (400) ;- une unité de normalisation (102), configurée pour décoder en fonction de ladite configuration demandée distante (300) lesdits messages de données (200) en flux de données normalisés (201) comprenant lesdites données (10);et dans lequel ledit moteur de traitement (103) est configuré en outre pour recevoir lesdits flux de données normalisés (201) à partir de ladite unité de normalisation (102), et dans lequel ledit moteur de traitement (103) est configuré en outre pour traiter lesdites données (10) par l'application d'une ou de plusieurs desdites une ou plusieurs règles de traitement (400) sur lesdites données (10) desdits flux de données normalisés (201) en fonction de ladite configuration demandée distante (300).
- 2. Dispositif (100) selon la revendication 1, dans lequel ladite interface d'entrée universelle (101) comprend :- au moins un module d'entrée RS232 (61) configuré pour recevoir des messages de données (200) se conformant à une couche physique RS232, tels qu'un ou plusieurs messages de données (200) se conformant à des interfaces série ;- au moins un module d'entrée RS485 (62) configuré pour recevoir des messages de données (200) se conformant à une couche physique RS485, tels qu'un ou- 53plusieurs messages de données (200) se conformant à des couches physiques BE2019/5150 définies par un ou plusieurs des suivants : J1708, bus de véhicule multifonction,Profibus, Modbus, On-Board Diagnostic, une interface série ; et- au moins un module d'entrée CAN (63) configuré pour recevoir des messages de données (200) se conformant à une couche physique CAN, tels qu'un ou plusieurs messages de données (200) se conformant à des couches physiques définies par un ou plusieurs des suivants : J1939, réseau local de commande.
- 3. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel ladite unité de normalisation (102) comprend une pluralité de codecs (120) configurés pour décoder lesdits messages de données (200) en ledit flux de données normalisés (201).
- 4. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel ledit dispositif (100) comprend en outre un récepteur de configuration distante (104), dans lequel ledit récepteur de configuration distante (104) est configuré pour recevoir ladite configuration demandée distante (300) ; et dans lequel ladite configuration demandée distante (300) comprend une sélection (301) d'un ou de plusieurs bus de messages (20) et une sélection d'adresses (302).
- 5. Dispositif (100) selon la revendication 4, dans lequel ledit moteur de traitement (103) est configuré en outre pour configurer ladite unité de normalisation (102) en fonction de ladite configuration demandée distante (300) de façon que ladite unité de normalisation (42) reçoive lesdits messages de données (203) depuis ladite interface d'entrée universelle (41) en fonction de ladite sélection (301) d'un ou de plusieurs bus de messages (20).
- 6. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel lesdites une ou plusieurs règles de traitement (400) comprennent un ou plusieurs des suivants :o une ou plusieurs métriques prédéfinies ;o une ou plusieurs clés prédéfinies ;o une ou plusieurs estampilles temporelles prédéfinies ;o un ou plusieurs seuils prédéfinis ;- 54o une ou plusieurs fonctions algorithmiques ;o une ou plusieurs règles analogiques ;o un ou plusieurs compteurs ;o une ou plusieurs fonctions de sous-échantillonnage ou de suréchantillonnage ; o une exécution d'un ou de plusieurs modèles d'apprentissage machine préformés ;o une exécution d'un ou de plusieurs modèles d'apprentissage profond préformés.
- 7. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel ladite unité de normalisation (102) comprend :- au moins un émetteur/récepteur RS232 (112), configuré pour convertir des messages de données (200) avec une couche physique RS232 en signaux de niveau logique TTL (202) ;- au moins un émetteur/récepteur RS485 (122), configuré pour convertir des messages de données (200) avec une couche physique RS485 en signaux de niveau logique TTL (202) ;- au moins un émetteur/récepteur CAN (132), configuré pour convertir des messages de données (200) avec une couche physique CAN en signaux de niveau logique TTL (202) ;- au moins un sélecteur de couche physique (142), configuré pour recevoir ladite sélection (301) d'un ou de plusieurs bus de messages (20) à partir dudit moteur de traitement (103) et configuré en outre pour sélectionner ledit émetteur/récepteur RS232 (112) ou ledit émetteur/récepteur RS485 (122) ou ledit émetteur/récepteur CAN (132) en fonction de ladite sélection (301) d'un ou de plusieurs bus de messages (20); et- un circuit intégré prédiffusé programmable (152) comprenant :o ladite pluralité de codecs (120), configurés pour décoder lesdits signaux de niveau logique TTL (202) en flux de données normalisés (201) ;o un multiplexeur (153), configuré pour sélectionner l'un desdits codecs (120) en fonction de ladite configuration demandée (300) ; et o une unité de filtrage et de routage de message de données (154), configurée pour filtrer lesdites flux de données normalisés (201).BE2019/5150
- 8. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel ledit moteur de traitement (103) est configuré en outre pour exécuter une ou plusieurs desdites une ou plusieurs règles de traitement (400) sur lesdites données (10) desdits flux de données normalisés (201), pour ainsi analyser lesdites données (10) comprises dans lesdits messages de données (200).
- 9. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel ledit dispositif (100) comprend en outre un module GSM (105) et/ou un port Ethernet (106) et/ou un émetteur sans fil (107), et dans lequel ledit moteur de traitement (103) est configuré en outre pour envoyer lesdites données (10) via ledit module GSM (105) et/ou ledit port Ethernet (106) et/ou ledit émetteur/récepteur sans fil (107).
- 10. Dispositif (100) selon l'une quelconque des revendications précédentes, dans lequel ledit dispositif(100) comprend en outre un module GPS (108) configuré pour générer des informations de localisation (500), et dans lequel le moteur de traitement (103) est configuré en outre pour coupler lesdites informations de localisation (500) auxdites données (10).
- 11. Ensemble configuré pour traiter des données (10) comprises dans des messages de données (200) passant sur des bus de messages (20) d'un matériel roulant, ledit ensemble comprenant un dispositif (100) selon les revendications 1 à 10 et comprenant en outre des bus de messages (20) se conformant aux trois couches physiques suivantes :- RS232 ;- RS485 ;- CAN.
- 12. Système (1) comprenant un dispositif (100) selon les revendications 4 à 10 et dans lequel ledit système (1) comprend en outre un éditeur de règles distant (30) configuré pour générer ladite configuration demandée distante (300) ; et dans lequel ledit dispositif (100) est couplé de manière fonctionnelle audit éditeur de règles distant (30) via ledit récepteur de configuration distante (104).BE2019/5150
- 13. Système (1) selon la revendication 12, dans lequel ledit éditeur de règles BE2019/5150 distant (30) comprend une interface utilisateur de génération de règles (31) permettant à un ou plusieurs utilisateurs (2) de générer lesdites unes ou plusieurs règles de traitement (400).
- 14. Système (1) selon la revendication 12 ou 13, dans lequel ledit système (1) comprend en outre un ou plusieurs modules d'acquisition déportés (40) et un ou plusieurs liens de communication (50) ; et dans lequel :- chacun desdits modules d'acquisition déportés (40) comprend :o une interface d'entrée universelle déportée (41), configurée pour recevoir des messages de données déportées (203) se conformant aux trois couches physiques suivantes :RS232;RS485;CAN;à partir de bus de messages (20), lesdits messages de données déportées (203) comprenant des données déportées (11);o une unité de normalisation déportée(42), configurée pour décoder en fonction d'une configuration demandée distante(300) lesdits messages de données déportées (203) en flux de données déportées normalisés (204) comprenant lesdites données déportées (11) ;- ledit moteur de traitement(103) dudit dispositif (100) est configuré en outre pour configurer, sur lesdits un ou plusieurs liens de communication(50), chacune desdites unités de normalisation déportées (42) en fonction de ladite configuration demandée distante (300) de façon que chacune desdites unités de normalisation(42) reçoive des messages de données déportées (203) depuis ladite interface d'entrée universelle déportée respective (41) en fonction de ladite sélection(301) d'un ou de plusieurs bus de messages (20);- chacun desdits modules d'acquisition déportés (40) est configuré en outre pour fournir audit moteur de traitement(103) dudit dispositif (100) lesdits flux de données déportées normalisés (204) comprenant lesdites données déportées (10) sur lesdits uns ou plusieurs liens de communication(50);- 57- ledit moteur de traitement (103) dudit dispositif (100) est configuré en outre pour recevoir lesdits flux de données déportées normalisés (204) depuis lesdits modules d'acquisition déportés (40) ; et- ledit moteur de traitement (103) dudit dispositif (100) est configuré en outre pour traiter lesdites données déportées (11) par l'application d'une ou de plusieurs desdites une ou plusieurs règles de traitement (400) sur lesdites données déportées (11) desdits flux de données déportées normalisés (204) en fonction de ladite configuration demandée distante (300).
- 15. Procédé de traitement de données (10) comprises dans des messages de données (200) passant sur des bus de messages (20) d'un matériel roulant, ledit procédé comprenant les étapes suivantes :- la réception au niveau d'une interface d'entrée universelle de messages de données (200) se conformant aux trois couches physiques suivantes :o RS232 ;o RS485 ;o CAN;à partir de bus de messages (20), lesdits messages de données (200) comprenant des données (10) ;- la réception d'une configuration demandée distante (300) comprenant une ou plusieurs règles de traitement (400) ;- le décodage en fonction de ladite configuration demandée distante (300) desdits messages de données (200) en flux de données normalisés (201) comprenant lesdites données (10); et- le traitement desdites données (10) par l'application d'une ou de plusieurs desdites unes ou plusieurs règles de traitement (400) sur lesdites données (10) desdits flux de données normalisés (201) en fonction de ladite configuration demandée distante (300).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP18161338.1 | 2018-03-12 | ||
| EP18161338.1A EP3539843B1 (fr) | 2018-03-12 | 2018-03-12 | Dispositif de traitement de données de matériel roulant |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BE1025976B1 true BE1025976B1 (fr) | 2019-08-28 |
Family
ID=61628138
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BE2019/5150A BE1025976B1 (fr) | 2018-03-12 | 2019-03-11 | Dispositif pour traiter des données d'un matériel roulant |
Country Status (17)
| Country | Link |
|---|---|
| US (1) | US11606433B2 (fr) |
| EP (1) | EP3539843B1 (fr) |
| CN (1) | CN111278711A (fr) |
| AU (1) | AU2019235349B2 (fr) |
| BE (1) | BE1025976B1 (fr) |
| BR (1) | BR112020006964B1 (fr) |
| CA (1) | CA3078427C (fr) |
| DK (1) | DK3539843T3 (fr) |
| EA (1) | EA202090643A1 (fr) |
| ES (1) | ES2884300T3 (fr) |
| IL (1) | IL275286B1 (fr) |
| LT (1) | LT3539843T (fr) |
| MX (1) | MX2020005579A (fr) |
| PL (1) | PL3539843T3 (fr) |
| SG (1) | SG11202002790TA (fr) |
| SI (1) | SI3539843T1 (fr) |
| WO (1) | WO2019175144A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112550363A (zh) * | 2020-12-10 | 2021-03-26 | 卡斯柯信号有限公司 | 一种兼容性车载信号系统的车辆接口控制系统及方法 |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111884895A (zh) * | 2020-07-14 | 2020-11-03 | 中车大连电力牵引研发中心有限公司 | 一种用于地铁列车的多通信接口事件记录装置及其使用方法 |
| CN112260916B (zh) * | 2020-09-18 | 2022-11-25 | 富联裕展科技(深圳)有限公司 | 通信电路、通信网络及通信异常处理方法 |
| CN112141174B (zh) * | 2020-09-21 | 2023-01-20 | 通号城市轨道交通技术有限公司 | 一种vobc测试环境中zc仿真系统及方法 |
| CN112134792B (zh) * | 2020-09-24 | 2022-08-30 | 山东交通学院 | 一种远程列车网络通信接口测试网关设备及系统 |
| CN112584439A (zh) * | 2020-11-27 | 2021-03-30 | 重庆邮电大学 | 一种边缘计算中的缓存方法 |
| US11765188B2 (en) * | 2020-12-28 | 2023-09-19 | Mellanox Technologies, Ltd. | Real-time detection of network attacks |
| CN113347599B (zh) * | 2021-05-18 | 2023-02-24 | 交控科技股份有限公司 | 车载网络配置方法及装置 |
| CN113223157B8 (zh) * | 2021-05-26 | 2023-04-25 | 中车青岛四方机车车辆股份有限公司 | 动态线缆的长度参数化计算方法、装置、设备及存储介质 |
| CN113709029B (zh) * | 2021-08-17 | 2023-06-02 | 大连海天兴业科技有限公司 | 一种基于MODBUS通讯协议及Microblaze平台实现的标准MVB网卡系统 |
| CN115071792A (zh) * | 2022-05-20 | 2022-09-20 | 成都西交轨道交通技术服务有限公司 | 一种基于边缘计算的弓网在线监测系统及方法 |
| CN115396490A (zh) * | 2022-08-30 | 2022-11-25 | 上海鸣啸信息科技股份有限公司 | 一种基于数据中台的车辆健康数据中心系统 |
| CN116691769A (zh) * | 2023-05-05 | 2023-09-05 | 西门子交通技术(北京)有限公司 | 列车运行数据的处理方法、可读存储介质及列车 |
Family Cites Families (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6041295A (en) * | 1995-04-10 | 2000-03-21 | Corporate Computer Systems | Comparing CODEC input/output to adjust psycho-acoustic parameters |
| US20020019891A1 (en) * | 1999-12-30 | 2002-02-14 | James Morrow | Generic device controller unit and method |
| US7092803B2 (en) * | 2000-08-18 | 2006-08-15 | Idsc Holdings, Llc | Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components |
| US7149206B2 (en) * | 2001-02-08 | 2006-12-12 | Electronic Data Systems Corporation | System and method for managing wireless vehicular communications |
| US20020113686A1 (en) * | 2001-02-22 | 2002-08-22 | Ludwig Laboratories, Inc. | Transceiver and related method |
| WO2003005155A2 (fr) * | 2001-07-06 | 2003-01-16 | Corporate Computer Systems, Inc. | Codec audio a configuration utilisateur a passerelle de communications audio/donnees pouvant etre branchee a chaud et possedant une capacite d'enregistrement et de lecture audio en continu sur un reseau |
| US9917773B2 (en) | 2008-08-04 | 2018-03-13 | General Electric Company | Data communication system and method |
| WO2004114055A2 (fr) * | 2003-05-23 | 2004-12-29 | Nnt, Inc. | Systeme de gestion globale de l'entreprise muni d'un systeme ingere de detection des defauts et d'information des vehicules |
| CA2454988A1 (fr) * | 2004-01-07 | 2005-07-07 | Alstom Canada Inc. | Systeme pour deployer le protocole ip sur un cable existant ou nouveau a deux conducteurs a bord de vehicules ferroviaires |
| US9418263B2 (en) * | 2005-12-09 | 2016-08-16 | Tego, Inc. | Operating systems for an RFID tag |
| WO2009035694A1 (fr) * | 2007-09-13 | 2009-03-19 | Lockheed Martin Corporation | Système de tri et/ou de rangement de courrier mixte à l'échelle d'un site, ses composants et ses procédés |
| CN101321364B (zh) * | 2008-04-16 | 2011-06-08 | 广东高新兴通信股份有限公司 | 一种对远端设备数据流进行集中解析的方法 |
| FR2932447B1 (fr) * | 2008-06-12 | 2016-09-30 | Alstom Transport Sa | Systeme informatique embarque de gestion d'un train |
| CN101789557A (zh) * | 2010-01-29 | 2010-07-28 | 上海微小卫星工程中心 | 一种多功能接口转换装置 |
| US9658097B2 (en) * | 2012-05-11 | 2017-05-23 | Bristol, Inc. | Systems and methods to initiate a verification test within a flow meter via a flow computer |
| FR2992079A1 (fr) * | 2012-06-15 | 2013-12-20 | France Telecom | Dispositif et procede d'extraction de donnees sur un bus de communication d'un vehicule automobile |
| WO2015088887A1 (fr) | 2013-12-11 | 2015-06-18 | Corning Optical Communications LLC | Programme d'amorçage pour des faisceaux de câbles actifs |
| KR20150135975A (ko) * | 2014-05-26 | 2015-12-04 | 한국전자통신연구원 | 열차의 무선 통신 장치를 제어하는 시스템 및 방법, 그리고 원격으로 열차를 관리하는 방법 및 시스템 |
| CN105515924A (zh) * | 2014-09-25 | 2016-04-20 | 祁艳 | 一种农机装备传感器智能型接口适配器 |
| US10049857B2 (en) * | 2014-12-04 | 2018-08-14 | Mks Instruments, Inc. | Adaptive periodic waveform controller |
| EP3457409B1 (fr) * | 2015-05-02 | 2023-06-07 | F. Hoffmann-La Roche AG | Système de test de point d'intervention |
| WO2017059839A1 (fr) * | 2015-10-05 | 2017-04-13 | Martin Zimmer | Dispositif de préhension à régulateur intégré |
| WO2017176431A1 (fr) * | 2016-04-05 | 2017-10-12 | Wellaware Holdings, Inc. | Dispositif de surveillance et de commande d'un équipement industriel |
| DE102016108997A1 (de) * | 2016-05-17 | 2017-11-23 | Knorr-Bremse Systeme für Schienenfahrzeuge GmbH | Vorrichtung zum Auslesen von Daten aus einem sicherheitskritischen Steuergerät |
| CN206003088U (zh) * | 2016-07-20 | 2017-03-08 | 蚌埠学院 | 磁致伸缩位移传感器的多总线接口电路 |
| EP3559625B1 (fr) * | 2016-12-22 | 2021-07-14 | GEOTAB Inc. | Dispositif et procédé de gestion d'un véhicule électrique |
| US9718564B1 (en) * | 2017-03-16 | 2017-08-01 | Amazon Technologies, Inc. | Ground-based mobile maintenance facilities for unmanned aerial vehicles |
-
2018
- 2018-03-12 PL PL18161338T patent/PL3539843T3/pl unknown
- 2018-03-12 DK DK18161338.1T patent/DK3539843T3/da active
- 2018-03-12 SI SI201830364T patent/SI3539843T1/sl unknown
- 2018-03-12 ES ES18161338T patent/ES2884300T3/es active Active
- 2018-03-12 LT LTEP18161338.1T patent/LT3539843T/lt unknown
- 2018-03-12 EP EP18161338.1A patent/EP3539843B1/fr active Active
-
2019
- 2019-03-11 BE BE2019/5150A patent/BE1025976B1/fr active IP Right Grant
- 2019-03-12 MX MX2020005579A patent/MX2020005579A/es unknown
- 2019-03-12 AU AU2019235349A patent/AU2019235349B2/en active Active
- 2019-03-12 CN CN201980005365.4A patent/CN111278711A/zh active Pending
- 2019-03-12 EA EA202090643A patent/EA202090643A1/ru unknown
- 2019-03-12 WO PCT/EP2019/056113 patent/WO2019175144A1/fr active Application Filing
- 2019-03-12 BR BR112020006964-7A patent/BR112020006964B1/pt active IP Right Grant
- 2019-03-12 SG SG11202002790TA patent/SG11202002790TA/en unknown
- 2019-03-12 IL IL275286A patent/IL275286B1/en unknown
- 2019-03-12 US US16/765,292 patent/US11606433B2/en active Active
- 2019-03-12 CA CA3078427A patent/CA3078427C/fr active Active
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112550363A (zh) * | 2020-12-10 | 2021-03-26 | 卡斯柯信号有限公司 | 一种兼容性车载信号系统的车辆接口控制系统及方法 |
| CN112550363B (zh) * | 2020-12-10 | 2022-08-26 | 卡斯柯信号有限公司 | 一种兼容性车载信号系统的车辆接口控制系统及方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2019235349A1 (en) | 2020-04-23 |
| EP3539843B1 (fr) | 2021-05-26 |
| WO2019175144A1 (fr) | 2019-09-19 |
| CA3078427A1 (fr) | 2019-09-19 |
| AU2019235349B2 (en) | 2020-07-02 |
| DK3539843T3 (da) | 2021-08-09 |
| IL275286B1 (en) | 2024-05-01 |
| IL275286A (en) | 2020-07-30 |
| US11606433B2 (en) | 2023-03-14 |
| PL3539843T3 (pl) | 2021-12-06 |
| CA3078427C (fr) | 2021-12-14 |
| SI3539843T1 (sl) | 2021-11-30 |
| SG11202002790TA (en) | 2020-04-29 |
| EP3539843A1 (fr) | 2019-09-18 |
| US20200287971A1 (en) | 2020-09-10 |
| ES2884300T3 (es) | 2021-12-10 |
| EA202090643A1 (ru) | 2020-07-17 |
| MX2020005579A (es) | 2020-09-10 |
| BR112020006964B1 (pt) | 2022-12-06 |
| LT3539843T (lt) | 2021-09-10 |
| BR112020006964A2 (pt) | 2020-10-06 |
| CN111278711A (zh) | 2020-06-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BE1025976B1 (fr) | Dispositif pour traiter des données d'un matériel roulant | |
| CN201444256U (zh) | 工业自动化系统及工业系统 | |
| CN101179452B (zh) | 用于现场总线系统的诊断方法和诊断设备 | |
| JP5746420B2 (ja) | 協働的なマルチエージェント式の車両障害診断システム及び関連する方法 | |
| CN110633247A (zh) | 利用物联网环境的认知计算系统和服务 | |
| US11445392B2 (en) | Unified management and monitoring of IoT nodes with multiple network connections | |
| FR2828945A1 (fr) | Systeme et procede multi-niveaux de maintenance predictive et de diagnostic a distance extensible a un tres grand nombre de machines | |
| US20050108389A1 (en) | Network endpoint health check | |
| CN111024405A (zh) | 汽车诊断方法、相关装置及系统 | |
| CN101408766B (zh) | 工业自动化系统以及在工业工厂内收集数据的方法和系统 | |
| CN102809953A (zh) | 用于告警捕获和传输的系统及方法 | |
| US20110307219A1 (en) | Method for diagnostic monitoring | |
| EP4285574A1 (fr) | Service d'extraction de données de véhicule | |
| CN103905219A (zh) | 一种业务平台中通信信息的监控存储系统及方法 | |
| US10970942B2 (en) | Fog data agent for connected cars | |
| CN104618341B (zh) | 用于安全的远程访问的系统和方法 | |
| CN108696375B (zh) | 工业网络信息获取装置、方法、监控系统及存储介质 | |
| CN116962184A (zh) | 一种自动部署RoCE集群的方法、系统、终端及介质 | |
| JPWO2020110446A1 (ja) | 車両故障予測システム、監視装置、車両故障予測方法および車両故障予測プログラム | |
| Ajin et al. | Study of security and effectiveness of DoIP in vehicle networks | |
| JP2022071825A5 (fr) | ||
| EA044484B1 (ru) | Устройство для обработки данных подвижного состава | |
| EP2251789B1 (fr) | Module d'entrées/sorties pour capteurs et/ou actionneurs échangeant des informations avec deux unités centrales | |
| JP2023057820A (ja) | 情報収集装置、及び、情報収集方法 | |
| CN110083138A (zh) | 一种工业系统的管理方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG | Patent granted |
Effective date: 20190828 |