Serveur VoIP sur platine ARM et CANOpen

Z.I. Les Illons,
07250 Le Pouzin
51, rue Barthélémy de Laffemas
26901 Valence Cedex 9
Serveur VoIP sur platine ARM et
CANOpen
Rapport de Stage
ROGER Mathieu
Licence Pro. SIL option SIRE
Maı̂tre de Stage : M. Christophe Duhoux
Professeur tuteur : M. Denis Genon-Catalot
Année Universitaire 2007-2008
Rapport rédigé avec LATEX
Remerciement
Je souhaite remercier :
Sébastien Jean et Denis Genon-Catalot pour leurs aides et conseils lors de
mon stage.
Christophe Duhoux pour son aide sur le protocole CANOpen.
L’ensemble des stagiaires pour leur aide et le partage de compétences aussi
bien pour mon projet que pour le leur.
Table des matières
Introduction
1
1 Présentation du stage
1.1 Le lieu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 L’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
2 La platine ARM
2.1 Spécifications matérielles . . . .
2.2 Spécifications logicielles . . . . .
2.2.1 Boot loader . . . . . . .
2.2.2 Noyau Linux . . . . . .
2.2.3 Système de fichiers . . .
2.3 La chaine de compilation croisée
.
.
.
.
.
.
4
4
5
5
6
7
8
.
.
.
.
.
9
9
9
10
11
12
.
.
.
.
.
14
14
15
16
16
17
3 Le serveur téléphonique
3.1 Présentation . . . . . .
3.1.1 La VoIP . . . .
3.1.2 Asterisk . . . .
3.2 Architecture . . . . . .
3.3 Les signaux DTMF . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Autres travaux
4.1 Interface Web pour Asterisk
4.2 Téléphone IP . . . . . . . .
4.3 CANOpen . . . . . . . . . .
4.3.1 CanFestival . . . . .
4.3.2 Ethernet Powerlink .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
18
Bibliographie
19
Table des figures
2.1
Carte Olimex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1
Logo d’Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2
Architecture du système . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3
Nouvelle architecture du système . . . . . . . . . . . . . . . . . . . .
13
4.1
Interface d’administration Internet . . . . . . . . . . . . . . . . . . .
15
Introduction
Étant en fin de cycle de Licence Professionnelle Système Informatique et Logiciel option Système Informatique et Réseaux Embarqués à l’IUT Pierre-MendèsFrance de Valence, j’ai été amené à effectuer un stage de fin d’année pour finaliser
ma formation. J’ai effectué celui-ci au laboratoire valentinois LCIS (plateforme
technique), pour l’entreprise Sprinte : entreprise spécialisée dans les armoires d’ascenseur.
Le sujet du stage est « Utilisation de la VoIP sur platine ARM et module
CANOpen pour ascenseur ». La voix sur IP est destinée à la télésurveillance de
l’ascenseur, c’est-à-dire les appels d’urgence dans le cas où une personne serait
bloquée dans l’ascenseur. Le but de l’implémentation du CANOpen est la prise
de contrôle et la reconfiguration de l’ascenseur à distance via l’Internet nécessaire
pour les appels d’urgence.
Ce rapport va donc s’ordonner en trois parties : tout d’abord, nous verrons
une présentation de la plateforme technique de Valence et de l’entreprise sprinte,
ensuite nous nous pencherons sur le choix de la plateforme, du serveur de VoIP
et de son implémentation sur la carte. Enfin, nous finirons par une partie sur la
configuration et la prise de contrôle de l’ascenseur via CanFestival et Ethernet
Powerlink
1.
1.1
Présentation du stage
Le lieu
Mon stage s’est donc effectué sur la plateforme technique de valence, c’est
une structure de transfert technologique. Elle héberge également les activités de
recherche fondamentale de deux enseignants-chercheurs du groupe CTSYS du laboratoire LCIS (Sébastien JEAN et Denis GENON-CATALOT). On y trouve des
stagiaires de différentes filières de l’IUT tel que DUT Informatique option SI et
GI, DUT R&T, Licence Pro SIRE.
Le laboratoire valentinois LCIS (sous tutelle de l’INPG et de l’UPMF) compte
une vingtaine de chercheurs permanents et une dizaine de doctorants. Ses axes
de recherche couvrent la conception et le test des systèmes complexes, l’étude des
systèmes coopérants (multiagents), la conception de systèmes optoélectroniques et
de radiofréquences et enfin le contrôle des systèmes dynamiques (automatiques).
Le groupe CTSYS s’inscrit dans l’axe « conception et test de systèmes » et
compte cinq enseignants-chercheurs permanents et un doctorant.
Les activités de recherche menées sur la plateforme (et physiquement sur la
plateforme technologique) se focalisent notamment sur la conception de passerelles embarquées (pour applications d’informatique ambiante ou industrielles),
en traitant à la fois des aspects système, intergiciel et réseau.
1. Présentation du stage
1.2
3
L’entreprise
Le travail a été effectué pour l’entreprise SPRINTE Electra Vitoria (SPRINTE
E.V.). Cette entreprise est spécialisée dans la conception et la fabrication d’équipements électriques pour les ascenseurs neufs ou à rénover de manière à ce qu’ils
soient compatibles avec les nouvelles normes en vigueur.
La société SPRINTE a été créée en 1978 par M. Gérard CHOLVY, qui possédait déjà des compétences dans le domaine de l’ascenseur. Dès 1980, SPRINTE
propose, des armoires intégrant des microprocesseurs. En 1996, la société rejoint
le groupe espagnol Electra Vitoria basé à Vitoria (Catalogne) ainsi SPRINTE
devient SPRINTE Electra Vitoria. Elle développe ainsi un savoir-faire dans le
domaine des armoires de commande et de la filerie des ascenseurs.
L’entreprise est maintenant reconnue pour son activité dans les armoires de
rénovation et les installations neuves par des clients tels que OTIS, KONE,
SCHINDLER, ...
SPRINTE E.V. développe des systèmes électriques et électroniques pour le
contrôle des ascenseurs. La société a mis en place une nouvelle gamme d’éléments
de commandes et de capteurs permettant de réduire la longueur des câbles ainsi
que leurs nombres en utilisant notamment des bus de terrain tels que le CAN et
le protocole CANOpen.
L’utilisation du CANOpen a permis à SPRINTE E.V. d’obtenir des architectures plus robustes (sécurité et maintenance) avec des interfaces de communication évoluées (USB, Ethernet).
2.
La platine ARM
La plus grande partie de mon stage s’est déroulée sur l’installation et la configuration de la carte et du serveur de Voix sur IP. Dans cette partie, nous allons
aborder les spécifications de la platine sur laquelle j’ai travaillé.
La plateforme ARM a été choisie par Denis GENON-CATALOT, pour sa
puissance, sa polyvalence et son faible coût (environ 90 euros).
2.1
Spécifications matérielles
La carte d’évaluation est une platine Olimex SAM9-L9260. Celle-ci dispose
de :
– Un processeur ARM9 à 200 MHz
– 64Mo de SDRAM
– 512 Mo de NAND Flash (fait office de disque dur)
– Un port Ethernet 100Mbits
– Un port USB 2.0 maı̂tre (permet de brancher des clefs USB par exemple)
– Un port USB 2.0 esclave (permet de se servir de la carte comme carte réseau
USB)
– 3 ports RS232
– Un lecteur de SD/MMC
– Un bouton réglable (valeure atteignable dans un registre) et un bouton reset
– Une led power, deux leds configurables
Cette architecture dispose donc d’une puissance de calcul non négligeable pour
un prix vraiment attractif, de plus celle-ci dispose de nombreuses entrées-sorties,
2. La platine ARM
5
Fig. 2.1 – Carte Olimex
convertisseur analogique numérique et autres fonctions ce qui la rend vraiment
polyvalente et apte à beaucoup d’usages.
2.2
Spécifications logicielles
La carte est livrée avec un CD contenant tous les utilitaires nécessaires à un
flashage (équivalent du formatage) de celle-ci. On y trouve le code permettant de
gérer la flash et la RAM, le boot loader, le noyau Linux et le système de fichiers.
2.2.1
Boot loader
Le code permettant de gérer la flash et la ram est en fait un mapping des registres, c’est-à-dire une manière plus ou moins matérielle de rediriger les registres
du processeur vers les composants flash et ram. Ce code étant déjà compilé, nous
n’avons pas senti le besoin de l’ouvrir, ni de l’éditer.
2. La platine ARM
6
Le boot loader est un morceau de code qui se charge de lancer le noyau Linux,
sur un PC se serait le Bios (Award, Phoenix. . .), sur notre platine plusieurs sont
possibles : RedBoot, U-boot,. . .celui-ci étant déjà livré et configuré par Olimex
nous n’avons pas non plus ressenti le besoin de le modifier ou de le changer.
2.2.2
Noyau Linux
En ce qui concerne le noyau Linux, la version livrée avec la carte était un
2.5.x.x, le deuxième nombre étant impaire cela signifie que c’est une version instable et en développement. Cela est principalement dû au fait que la majorité
des drivers nécessaires pour la carte n’ont été ajouté que dans cette version, or
lors du début de mon stage la version 2.6.x.x était sortie en version stable, en
conséquence les drivers été intégrés et fonctionnel. Après application d’un patch
nécessaire au fonctionnement du noyau sur la carte, nous avons lancé une compilation qui marcha directement.
Après plusieurs jours de tests et de développement sur le noyau, nous avons
remarqué plusieurs bugs : tout d’abord toutes actions sur la MMC (insertion,
lecture, écriture) étaient écrite dans un fichier journal par le noyau, cela avait
pour conséquence de prendre une place conséquente sur la carte et surtout de
ralentir les accès (en moyenne 30ko/s). Ceci est dû au fait que le driver du lecteur
de carte MMC n’est pas encore tout à fait stable, et donc la fonction de debug de
celui-ci est activée dans le noyau, il a donc suffi de la désactiver. Le deuxième souci
était le fait que l’horloge était mal régler : le temps passait plus lentement sur
la carte, cela du à un mauvais cadencement au niveau du noyau, la modification
de la RTC (Real Time Clock) dans les options du noyau à permit de régler le
problème.
2. La platine ARM
2.2.3
7
Système de fichiers
Le système de fichiers (ou distribution) est l’ensemble des exécutables permettant le fonctionnement de Linux, entre les différents systèmes de fichiers il y
a beaucoup de points communs, par exemple on retrouve tout le temps les commandes ls, mkdir,. . ., qui sont les commandes de bases. En revanche suivant le
système de fichiers certaines commandes plus complexes ne sont pas présentes.
Notre système étant minimal (serveur de voix sur IP plus quelques autres services), nous avons essayé d’utiliser un système de fichier ultraléger : BusyBox,
celui-ci ne pèse que 2 Mo au lieu des 120 Mo utilisés par le système fourni avec la
carte. Nous n’avons malheureusement pas réussit à le mettre sur la carte, le noyau
Linux n’arrivait pas à lire la partition dans la flash. Nous sommes donc retourné
au système de fichiers livré avec la carte et l’avons allégé : suppression de certains
fichiers/exécutables inutiles, suppression des services inutiles au démarrage. . .
2. La platine ARM
2.3
8
La chaine de compilation croisée
La platine étant équipée d’un processeur ARM, les jeux d’instruction matériels
pour faire exécuter des opérations au processeur sont différents que sur une architecture x86 (architecture PC). De ce fait, le compilateur est différent de manière
à être capable de compiler à partir d’une architecture x86 vers un autre type de
processeurs, ici ARM, c’est cette notion que nous appelons la compilation croisée.
Plusieurs compilateurs croisés existent pour ARM, nous avons commencé par
celui livré par Olimex. Après plusieurs jours de tests, nous nous sommes rendu
compte que celui-ci ne marchait pas (impossibilité de lancer les exécutables créés).
Nous avons donc fait le choix de ELDK (Embedded Linux Development Kit)
qui est une panoplie d’utilitaires pour la compilation croisée pour Linux, et ceci
pour différents types de processeurs dont bien sûr l’architecture ARM. Après
installation et compilation d’un Hello World pour les tests, nous avons pût grâce
à ce compilateur recompilé le noyau, le serveur de voix sur IP,. . .
3.
Le serveur téléphonique
La majeure partie du stage s’est déroulée sur le développement, l’installation
et la configuration du serveur de Voix sur IP. Le but étant de mettre en place
un système de télésurveillance pour les ascenseurs, c’est-à-dire le bouton d’appel
d’urgence présent dans les ascenseurs. Suite à une nouvelle norme, l’appui sur
le bouton doit obligatoirement appeler quelqu’un, par exemple les pompiers, la
société d’ascensoriste. . .De plus, plusieurs prises sont présentes pour les pompiers,
les techniciens. . .
3.1
Présentation
Pour essayer d’innover un peu dans le monde de la télésurveillance et surtout pour réduire les coûts inhérents aux appels par France Telecom, nous avons
souhaité une solution numérique. Une solution s’est très vite imposée : la VoIP,
qui est une technique permettant d’effectuer des appels numériques en restant
de bout en bout sur le réseau numérique. Cela permet donc de s’affranchir de
l’abonnement France Telecom, bien qu’un abonnement à Internet soit nécessaire,
mais le principal avantage est que France Telecom facture les appels alors qu’en
général les appels numériques vers un poste analogique sont gratuits.
3.1.1
La VoIP
Présentation inspirée de Wikipédia
La VoIP pour Voice Over IP, littéralement Voix sur IP est une technique permettant de communiquer la voix sur les réseaux informatiques tels que les réseaux
d’entreprise, Internet, ADSL. . .Elle est utilisée pour supporter le service de télé-
3. Le serveur téléphonique
10
phonie IP (ToIP pour Telephony over IP).
La technique se base sur un système de paquets très légers contenant une petite partie de la conversation (environ 30 à 50 ms). De cette manière, les paquets
peuvent être acheminés rapidement et si quelques-uns se perdent l’utilisateur ne
s’en rend quasiment pas compte. Généralement, le protocole est utilisé pour une
communication point à point, mais il est aussi possible d’effectuer des conférences.
Un protocole va de pair avec la VoIP : le SIP (Session Initiation Protocol),
ce protocole permet la signalisation des appels : décrocher, raccrocher. . .Grâce à
ce système nous pouvons passer des appels entre téléphones IP gratuitement à
condition d’être relié à un serveur, mais aussi certains serveurs tels que VoIPBuster ou Free permettent de passer des appels aussi sur les téléphones fixes pour
des coûts très réduits (9 euros pour 6 mois chez VoIPBuster avec appels illimités)
3.1.2
Asterisk
Fig. 3.1 – Logo d’Asterisk
Une fois le principe de transmission de données arrêtées il a fallu choisir un
serveur supportant les appels internes, la connexion à un serveur distant pour les
appels externes, et si possible un système de conférence. Asterisk s’est très vite
départagé des autres solutions, car il existe un support très actif y compris sur
les différentes méthodes permettant de l’intégrer à des processeurs embarqués,
ce qui est notre cas, de plus celui-ci dispose de nombreux modules que l’on peut
3. Le serveur téléphonique
11
activer, désactiver et configurer facilement tels que les conférences ou la gestion
des différents types de compression (codec) utilisés pour la transmission de la voix.
Bien que de la documentation soit disponible pour la compilation d’Asterisk
pour ARM, il y a eu néanmoins quelques problèmes, tout d’abord il m’a fallu
comprendre comment compiler pour ARM le programme, c’est-à-dire l’argument
à donner pour que celui-ci compile correctement. Ensuite il y a eu un problème
de dépendances cassé, il manquait la bibliothèque permettant la colorisation des
textes dans la console, celui-ci étant nécessaire à Asterisk, mais n’existant pas
pour ARM, il a donc fallu télécharger les sources et les compiler.
3.2
Architecture
Le système de télésurveillance se comporte comme un vrai serveur téléphonique d’entreprise, plusieurs téléphones sont présents, ils sont capables de s’appeler entre eux. La principale différence réside dans le fait que certains téléphones
(dans la cabine, sur la cabine. . .) ne disposent que d’un seul bouton qui compose
automatiquement le numéro.
Le système s’architecture comme décrit sur le schéma ci-dessous :
On remarque donc quel les différents téléphones sont reliés à la platine ARM
qui fait office de serveur Asterisk. Les téléphones pompiers, par exemple, eux sont
de vrai téléphone SIP car ils ont la possibilité d’appeler une cabine en particulier,
il leur faut donc avoir un vrai clavier pour pouvoir composer le numéro. On
remarque ensuite que la platine est reliée à un provider SIP (fournisseur de service
SIP), tels que VoIPBuster ou encore Freephonie, qui permettent d’effectuer des
appels vers l’extérieur et notamment vers les lignes analogiques pour appeler les
pompiers ou une société spécialisée en cas d’appui sur le bouton d’appel.
3. Le serveur téléphonique
12
Fig. 3.2 – Architecture du système
3.3
Les signaux DTMF
Les signaux DTMF sont les tonalités que l’on entend lors de l’appui sur les
boutons du téléphone. Sur les téléphones analogiques, ces signaux se traduisent
par deux fréquences envoyées sur la ligne en même temps que la voix. Dans le
milieu de la VoIP il y a plusieurs possibilités : soit ils sont envoyés en « inband »c’est-à-dire comme sur les téléphones analogiques, soit en RFC2833 qui
sont des paquets SIP envoyés en même temps que la voix contenant le numéro de
la touche appuyée.
La méthode « inband »est encore très utilisée, car elle permet une compatibilité totale entre l’analogique et le numérique : si on appelle ma platine à partir
d’un poste analogique les signaux seront en « inband ». De ce fait la platine
ARM doit être capable de les détecter, cela n’a pas été possible pour deux raisons : tout d’abord, le module ztdummy qui permet d’avoir une horloge interne
à Asterisk n’est pas compilable pour ARM de ce fait la base de temps nécessaire
pour trouver les fréquences n’est pas présente, de plus le processeur ne gère pas
nativement les calculs à virgule flottante, une émulation par le noyau est donc
3. Le serveur téléphonique
13
faite, cela est beaucoup trop long à exécuter en conséquence le serveur n’arrive
pas à chercher la bonne fréquence assez rapidement et s’arrête. Les différentes
tentatives de mise en place de ztdummy ont été une grosse perte de temps, environ deux semaines et demi avant que l’on se décide à envisager une autre solution.
Pour pallier à ce problème, nous avons pensé à mettre un serveur central, basé
sur un vrai PC, auquel toutes les platines se connecteront, lui fera la transition
des signaux RFC2833 en « inband ». Cela permet aussi d’avoir une centralisation
des différentes cartes et donc de savoir quand une a perdu la connexion de manière à la réparer rapidement.
Ci-dessous l’architecture avec le serveur central :
Fig. 3.3 – Nouvelle architecture du système
Cette méthode permet donc à une ligne analogique d’appeler un des téléphones
de l’ascenseur en composant le numéro du serveur (numéro classique offert par
Freephonie par exemple) puis de composer le numéro de la platine suivi du numéro
du téléphone interne.
4.
Autres travaux
Dans cette partie, nous allons aborder les autres travaux effectués pendant le
stage. Nous verrons dans un premier temps l’interface Web pour faciliter l’administration d’Asterisk. Dans un deuxième temps, nous verrons la pile CANOpen
CanFestival, puis nous finirons par la technologie d’Ethernet Powerlink.
4.1
Interface Web pour Asterisk
De manière à simplifier l’installation des téléphones sur le serveur, une interface sous forme de page Internet a été réalisée, celle-ci permet :
– D’ajouter et supprimer des téléphones
– De configurer le provider SIP permettant les appels vers l’extérieur de réseau
– D’attribuer un numéro à chaque téléphone
– De configurer qui appeler en cas d’appui sur le bouton d’appel
– De configurer la liaison au serveur central pour les appels entrants
– De demander à la carte d’effectuer un appel entre un poste à l’intérieur du
réseau et un numéro de téléphone fixe.
Des fonctions devraient être rajoutées : la carte servira aussi probablement de
passerelle CAN pour administrer l’ascenseur à distance, de fait l’interface Web
contiendra une section permettant d’envoyer des trames à l’ascenseur.
En ce qui concerne le codage du site Web, le rendu est bien sur en HTML,
langage de toutes les pages web, mais la génération de ce html peut se faire par
plusieurs moyens : PHP, ASP, Python, Ě sont des langages capables de générer de l’HTML. Pour ce site j’ai préféré l’utilisation du Python car celui-ci bien
4. Autres travaux
15
que guère rapide, permet un temps de développement réduit et propose de nombreuses librairies facilitant la tâche du programmeur. Il propose notamment des
fonctions qui permettent de récupérer et de traiter les paramètres passés par la
page web très facilement, mais aussi une grosse librairie permettant de lire, écrire
et modifier les fichiers de configuration s’ils sont formatés d’une certaine manière
ce qui est le cas d’Asterisk.
Voici un aperçu de l’interface d’administration :
Fig. 4.1 – Interface d’administration Internet
4.2
Téléphone IP
Avoir le serveur embarqué pour la téléphonie est bien, mais pas suffisant, il
faut aussi les téléphones capables en un seul bouton d’appeler et de composer.
Nous avons donc travaillé sur un logiciel permettant de le faire (Softphone), le
seul softphone capable de fonctionner sans interface graphique est Linphone. La
compilation croisée de celui-ci n’est vraiment pas aisée, il a besoin de beaucoup
4. Autres travaux
16
de librairies qui doivent, elles aussi, être compilées pour le processeur ARM. La
compilation du logiciel est encore en cours.
À terme celui-ci devrait être capable d’être intégré sur un processeur de type
ARM7, et d’utiliser une des entrées/sorties de celui-ci pour le bouton. Lors de
l’appui sur le bouton, celui-ci composera automatiquement le numéro adéquat.
Lors de la réception d’un appel vers le softphone celui-ci décrochera automatiquement sans action nécessaire de la part de l’utilisateur
4.3
CANOpen
Une fois la mise en place du serveur Asterisk terminée, je me suis concentré
sur les fonctions que l’on pouvait rajouter à la carte ; c’est-à-dire le contrôle et
la configuration de l’ascenseur à distance. Les différentes parties des ascenseurs
(cabine, armoire) développés par Sprinte communiquent via le réseau CAN et le
protocole CANOpen.
Le CANOpen est une couche applicative pour le réseau CAN, celui-ci fonctionne en temps réel. Il est utilisé dans de nombreux domaines tels que l’automobile, les ascenseurs, le domaine médical. Il est connu pour être une solution de
communication économique et très efficace. Le principe repose sur un dictionnaire
d’objet propre à chaque équipement qui lui dit les actions à effectuer, les données,
les entrées sorties, les actions à effectuer à intervalle régulier comme par exemple
prendre une mesure ou encore envoyer une donnée sur le réseau, les valeurs des
objets peuvent être lu et modifier par le maı̂tre du réseau.
4.3.1
CanFestival
CanFestival est une pile CANOpen open source et gratuite. La carte Olimex
ne disposant pas de port CAN, il a fallu compiler les drivers du module USB-CAN
4. Autres travaux
17
PEAK. Une fois ceux-ci compilés on à put compiler CanFestival pour la platine.
Les tests effectués restent pour l’instant très succincts, le programme se lance,
on arrive à changer l’état d’un des nIJuds du réseau : passage en préopérationnel,
en opérationnel, mais on n’arrive pas a effectuer des requêtes de type SDO, par
exemple lire l’identifiant du fabricant.
4.3.2
Ethernet Powerlink
Une autre méthode permet de faire du CANOpen, il s’agit d’Ethernet Powerlink, cette technologie permet d’utiliser le réseau Ethernet/IP pour faire passer
des données CANOpen. Cette technologie permet donc de reconfigurer et contrôler l’ascenseur à distance, mais sans à avoir à utiliser l’interface web. Pour le
moment, nous n’en sommes qu’à la phase de compilation de celui-ci, sans avoir
la certitude de réussir à le faire marcher sur la plateforme Olimex.
Conclusion
Lors du stage, le serveur de VoIP a été le plus gros travail, celui qui a demandé
le plus de temps, notamment sur la détection des signaux DTMF. Ensuite, le travail sur le noyau (amélioration, ajout de fonctionnalité) s’est fait durant toute
la durée du stage. Ce travail a demandé beaucoup de rigueur, car la compilation
croisée n’est pas une chose facile à cause de la multitude des librairies nécessaires.
Les travaux non finis pour l’instant sont principalement le Softphone et CanFestival. Ceux-ci devraient être finis d’ici la fin de mon stage, ou sinon une solution
alternative proposée. La majorité de mon travail s’effectue actuellement sur la pile
CanFestival de manière à réussir à lire et écrire des valeurs dans les différents modules pour pouvoir les reconfigurer et diagnostiquer à distance.
Ce stage m’a permis d’utiliser les compétences acquises lors de mon DUT
et de ma Licence Professionnelle aussi bien pour mon projet que pour celui des
autres. Le travail sur la plateforme a été très bénéfique, car bien que nous ayons
des projets différents, nous partagions nos opinions et compétences sur les projets
de chacun.
Bibliographie
Wikipédia (http ://fr.wikipedia.org) : Encyclopédie en ligne. Utilisée pour les
définitions et quelques renseignements.
VoIP-info (http ://www.voip-info.org/wiki/) : Utilisé pour toute la configuration d’Asterisk.
Asterisk (http ://www.asterisk.org/) : Aide pour la configuration d’Asterisk
et sa compilation croisée.
CanFestival (http ://www.canfestival.org/) : Documentation de CanFestival.
ARM Linux Project (http ://www.arm.linux.org.uk/) : Mailing-list sur Linux
sur processeur ARM
AT91 Linux Patch (http ://maxim.org.za/at91 26.html) : Patchs pour la compilation du noyau pour le processeur
D’ici quelques mois, les ascenseurs devront tous être équipés d’un système de
télésurveillance, permettant lors de l’appui sur le bouton d’urgence d’appeler un
numéro. À l’heure actuelle ce service est généralement proposé en analogique,
mais la technologie veut que cela change : ainsi mon projet a été de réaliser ce
service de manière totalement numérique avec une compatibilité avec les lignes
analogiques pour les fournisseurs non équipés. De plus comme le système sera
relié à Internet, pourquoi ne faire passer que de la voix et pas aussi des données,
nous avons donc regardé à développer un système permettant de diagnostiquer
l’ascenseur et le configurer à distance, sans a avoir à faire déplacer un technicien.
Mots-clefs : ARM, VoIP, Asterisk, SIP, CAN, CANOpen, CanFestival, serveur
SIP, client SIP, Linphone
In few months, the elevators should have a remote monitoring system, allowing
making a call when a button is pushing. At this time, this service is commonly
purposed in analog, but the technology like change, so my project was to accomplish this service in a numerical way with a compatibility with the analog phone
for the persons with only an analog phone. Moreover the system will be connected
to the Internet, so why only use this for the voice and not for data, we have see
to develop a system to diagnostics and configure the elevator without having to
make move a technician.
Keywords : ARM, VoIP, Asterisk, SIP, CAN, CANOpen, CanFestival, SIP
server, SIP client, Linphone