eCMR, un projet pour faciliter le suivi et optimiser la gestion des flottes de transport

Collaborations et partenaires

Ce projet implique un certain nombre d’entreprises et d’organismes qui travaillent et développent des parties bien spécifiques du projet.

Les sociétés Orditool (coordinatrice du projet) et Smolinfo se chargent d’énoncer les besoins du système de définir les contrôles et scénarios au niveau applicatif et de développer le progiciel d’exploitation des données remontées par le système.

Le CRID, Centre de Recherches Informatique et Droit, travaille sur les éléments juridiques et légaux à prendre en compte pour, entre autre, la modification des formulaires de CMR, le respect de la vie privée.

Les sociétés Connector et Docledge développent la technologie permettant d’effectuer la reconnaissance de l’écriture manuscrite des formulaires de CMR numérisé. Docledge met à disposition les tablettes utilisées pour la saisie des CMR papiers.

Le CETIC a la charge d’étudier, concevoir et mettre en œuvre l’infrastructure hardware et software de communication, aussi bien du côté serveur que du côté du véhicule.

La société de transport PAQUET SA, est chargée de mettre à disposition des véhicules pour les phases de tests et de prototypage et de fournir un retour d’expérience sur l’usage de l’équipement déployé.

La capture électronique et transmission du document CMR

Ce projet n’envisage pas d’abandonner le CMR papier, seul document à valeur légale pour le transport de marchandise, mais de reproduire électroniquement les informations qui y sont saisies manuellement. Nous avons donc introduit un équipement spécifique, appelé tablette par abus de langage, et qui permet de générer des fichiers informatiques correspondant à ce qui est saisi manuellement sur un document papier déposé dessus.

La tablette ne dispose pas d’intelligence embarquée intrinsèque. Elle n’est pas programmable et en termes de connectivité, elle se comporte comme une clé USB.
L’utilisation de la tablette et la transmission de ses données doivent être possibles même en l’absence d’un ordinateur embarqué dans le véhicule de transport. Ainsi le CETIC a développé une interface électronique intelligente pour la tablette permettant la détection automatique des nouveaux fichiers et la gestion de leur processus d’envoi par Bluetooth à un équipement embarqué se chargeant de leur transmission au serveur. Cet équipement n’est pas nécessairement de type PC : un téléphone mobile doté d’une connectivité GPRS et muni d’une application adéquate suffit.
Pour plus de détails voir cette page

Afin d’atteindre ce but, différents systèmes et logiciels ont été mis en place et sont décrit ci-dessous.

L’architecture logicielle

Dans le cadre du projet eCMR il est question de gérer des configurations variées au niveau des équipements disponibles dans le véhicule de transport. En d’autres termes, il est possible que le camion soit équipé ou non d’un PC embarqué, et que certains périphériques et interfaces ne soient pas toujours disponibles. Nous considérons par contre qu’une connectivité de type GPRS est toujours présente. Ainsi, la remontée des informations depuis le camion vers une application serveur impose le développement d’une architecture software modulaire et flexible pour tenir compte des différentes situations sur le terrain.

Le CETIC a étudié deux cas de figures, correspondants à deux configurations majeures. Cependant, les différences de la configuration embarquée n’affectent pas l’architecture serveur qui est la même quelle que soit l’utilisation.

Architecture serveur

Le système logiciel du serveur est divisé en plusieurs couches, qui fournissent successivement plusieurs niveaux d’abstraction pour l’accès aux données.

Architecture logicielle du serveur

Les différentes couches ont des rôles bien précis :

1. La couche réseau (Port Layer) reçoit et gère les connexions de type Internet des différents terminaux embarqués qui se connectent en GPRS
2. Une couche de routage (Dispatcher) vient ensuite diriger les données des terminaux vers différents modules :
   1. Le gestionnaire de session (Session Manager) qui surveille l’état des terminaux, mais qui gère aussi l’authentification des terminaux lors de leur connexion
   2. La couche de décodage (Protocol Layer)
3. Une couche de décodage (Protocol Layer) qui contient différents modules dédiés à des protocoles de communication spécifique. Cette couche sert d’interface entre les terminaux distants et le système d’abstraction des données. Elle sert à décoder les données provenant des équipements embarqués disponibles dans le véhicule de transport.
4. Une couche de concentration des données (Signal Layer) qui regroupe toutes les données des terminaux qui ont été décodées et qui les mémorise sous une forme standardisée (signal).
5. Une couche de communication (Communication Layer) qui est l’interface avec le système chargé d’exploiter les données. Les éléments qui la composent mettent en œuvre un protocole de communication unifié qui donne accès aux données collectées pour une application utilisateur de plus haut niveau.

Le rôle du serveur n’est pas seulement de concentrer les données des différents terminaux, mais aussi de fournir un accès homogène et standardisé aux données. Un protocole simple et robuste a donc été défini au niveau de la couche de communication, de sorte qu’une application de gestion de flotte (Top Level Application) puisse facilement accéder aux données du serveur.
Il s’agit d’un protocole de type « requête/réponse » sous forme de commande texte qui permet de connaître

1. Les terminaux connectés
2. L’état des terminaux
3. Les données disponibles pour chaque terminal

Le protocole de communication prévoit aussi la remonté d’événements pour signaler notamment :

1. La connexion d’un nouveau terminal
2. La déconnexion d’un terminal
3. L’entrée ou la sortie d’une zone géographique prédéfinie (geofencing)

La communication entre le serveur et l’application de gestion de flotte est réalisée à l’aide d’une connexion de type Internet, de sorte qu’il est tout a fait possible d’utiliser plusieurs systèmes d’exploitation des données mêmes distantes avec le même serveur.

Scénario sans intelligence embarqué

Cette configuration est la plus simple. Le véhicule embarque un terminal autonome avec une connectivité GPRS. Ces terminaux sont capables de retourner des informations brutes provenant d’équipements intégrés ou connectés au terminal GPRS comme par exemple des données de positionnement, d’accélération, d’entrée sortie, etc..

Architecture sans intelligence embarquée

Puisque le terminal n’embarque aucune intelligence, les données brutes (du GPS dans l’exemple de la figure ci-dessus) sont transmises au serveur qui se charge de les décoder. Bien que cela augmente la charge de calcul du serveur cette possibilité est très intéressante car elle permet d’utiliser des terminaux embarqués relativement basiques et donc moins onéreux.

Les applications autorisées par cette configuration sont assez limitées, et se résument au suivi (tracking) de véhicule et à la remontée d’événements ou de données spécifiques.

Le CETIC a mis en œuvre et testé ce scénario à de nombreuses occasions, notamment lors de l’inauguration du Microsoft Innovation Center de Mons.
Pour cette démonstration le système de gestion de flotte a été remplacé par une application permettant de visualiser, sur une cartographie, la position et la vitesse d’une voiture équipée du terminal autonome embarqué dans une voiture roulant dans la ville de Mons. La démonstration a également illustré les mécanismes de geofencing, en signalant que le véhicule entrait ou sortait d’une zone sélectionnée interactivement avec l’interface utilisateur de l’application de démonstration.

Démonstrateur utilisé lors de l’inauguration du MIC

Scenario avec intelligence embarqué

Cette configuration plus complète offre plus de possibilités par rapport à celle décrite précédemment.
Le véhicule embarque un ordinateur, doté d’une connectivité GPRS, auquel sont reliés différents périphériques et systèmes de mesures :

1. un récepteur GPS, permettant d’obtenir des informations liées au positionnement géographique et à la vitesse du véhicule

1. un tachygraphe numérique qui fournit des données sur l’état d’activité du chauffeur, ainsi que des données plus précises sur la vitesse du véhicule
2. une interface CAN/FMS qui donne de nombreuses informations sur l’état du véhicule, par exemple le régime moteur, le kilométrage, la consommation de carburant, le nombre de coup de freins, le pourcentage d’enfoncement de pédale d’accélérateur, etc.
3. une tablette graphique, connectée par Bluetooth, qui transmet les images numériques des CMR. Les images seront ensuite transmises au serveur pour être converties en données informatiques exploitables.

Pour des applications particulières, d’autres périphériques peuvent êtres ajoutés. Il est en effet possible de connecter toutes sortes de systèmes à l’ordinateur embarqué.

Architecture avec intelligence embarquée

Dans cette configuration, ce n’est plus le serveur qui a la charge de décoder et de mettre en forme les données issues des différents instruments. C’est l’ordinateur embarqué qui réalise ces tâches, déchargeant ainsi le serveur.

L’ordinateur permet également de nombreuses fonctionnalités supplémentaires par rapport à la configuration précédente.
En effet, la récupération et la transmission des formulaires de CMR numérisés, fonctionnalité essentielle dans le projet eCMR, n’est possible que dans ce scénario.
Par ailleurs, la capacité de stockage de l’ordinateur embarqué permet de mémoriser de nombreux paramètres qui pourront êtres exploités plus tard. Si la transmission en temps réel de ces paramètres n’est pas indispensable cela constitue un double intérêt, technique et économique lié à l’utilisation de la bande-passante GPRS.
Il est également possible de réaliser des systèmes conditionnels complexes, capables de remonter des informations ou des alarmes uniquement lorsque cela est nécessaire.

Une interface utilisateur peut aussi être ajoutée afin d’échanger des informations avec le conducteur du véhicule.

Le démonstrateur final qui sera présenté pour la fin du projet correspond à ce scénario, appliqué à un véhicule poids-lourds.

L’ordinateur embarqué permettra donc de remonter au serveur les données provenant :

1. du tachygraphe
2. de l’interface FMS
3. du GPS
4. de la tablette graphique de numérisation du CMR

Lotfi Guedria (Senior R&D Project Manager)
Mathieu Ocaña (Senior R&D Engineer)