Vous êtes sur la page 1sur 60

Réf : 2020/ II3 /29 Soutenu à la session de Juin 2020

Université de la Manouba
École Nationale des Sciences de l’Informatique

Rapport de Stage de Fin d’Etudes

Présenté en vue de l’obtention du titre

D’INGÉNIEUR EN INFORMATIQUE

Par

HAMMAMI Maher

Sujet : Conception,Développement et Intégration d’une solution


IoT pour la télématique temps réel basée sur le projet iotivity
avec client Qt/Qml et génération de la distribution sous
environnement yocto pour la cible phytec

Organisme d’accueil :ACTIA Engineering Services

Nom du Responsable :Mme. Amina MILI

Encadré par :Mr. ZAIRI Wajdi

Supervisé par :Mme. BAKRI Marwa (ENSI)

Adresse :Parc Technologique "El-Ghazala" 1 Rue Newton, BP99 - 2088


ARIANA (Tunisie)
Tél :(+216) 70 68 79 17 Fax :(+216) 70 68 78 92
Appréciations, signature et cachet de
Mr. Wajdi ZAIRI (ACTIA Engineering Services)

Appréciations et signature de
Mme. Marwa Bakri (ENSI)
Dédicaces

Je dédie ce travail à :

A toutes les personnes chères à mon coeur.

A mes très chers parents, Nacer et Yamina qui n’ont jamais cessé de me
soutenir, m’assister et m’encourager.

A ma chère soeur Mouna pour sa précieuse présence durant toutes ces


années.

A mon cher frère Khaled qui n’a cessé de m’encourager.


A toute ma famille et tous mes amis et tous ceux qui n’ont jamais cessé de
croire en moi.

Maher.

ii
Remerciements

Mes remerciements s’adressent, en premier lieu, aux membres de l’équipe, Développe-


ment Linux Embarqué, au sein de l’entreprise ACTIA Engineering Services, où mon stage
a eu lieu.

Je tiens à exprimer mes gratitudes à Monsieur Wajdi ZAIRI, chef d’équipe à ACTIA
Engineering Services, pour m’avoir donné l’occasion d’effectuer ce stage, pour son encadre-
ment, ses corrections et ses multitudes aides.

J’adresse mes sincères remerciements à Madame Marwa BAKRI ma superviseuse à


l’ENSI, pour sa patience, son assistance et ses précieuses recommandations.

Je remercie également Mme. Fatma ALI et Mme. sirine pour l’aide et le soutien qu’elles
m’ont accordées tout au long de ce stage.

Je tiens à remercier vivement Mr.Abdelazize BELHARETH, Mr.Saif eddine el GADAA


et Mr.Taher MACHFAR pour le partage de leurs expériences au quotidien.

Enfin, et pas des moindre, je voudrais exprimer toute ma gratitude envers tous les
membres du jury pour avoir accepté de juger ce modeste travail.

iii
Table des matières

Introduction générale 1

1 Présentation générale 3
1.1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problématique étudiée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.1 Méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.2 Justification du choix méthodologique . . . . . . . . . . . . . . . . . 6

2 Étude préliminaire 7
2.1 Internet des objets (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Télématique embarquée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Projet Yocto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Caractéristiques du projet Yocto . . . . . . . . . . . . . . . . . . . 9
2.3.3 Défis du projet Yocto . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Projet IoTivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Architecture du projet IoTivity . . . . . . . . . . . . . . . . . . . . 11
2.5 Modèle client/serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Analyse et spécification des besoins 14


3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Étude des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 15

iv
Table des matières v

3.3 Le diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 15


3.4 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Diagramme de séquence pour le scénario de la connexion des clients 16
3.4.2 Diagramme de séquence pour le scénario de la lecture des valeurs des
capteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Diagramme de séquence pour le scénario de modification des valeurs
des capteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4 Diagramme de séquence pour le scénario de déconnexion des clients 20

4 Conception 22
4.1 Conception Architecturale . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Le modèle Client/serveur . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Analogie avec le modèle OSI . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 Conception de la couche Applicative . . . . . . . . . . . . . . . . . 24
4.2.3 Conception de la couche du transport . . . . . . . . . . . . . . . . . 30

5 Réalisation 35
5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Montage des différents composants . . . . . . . . . . . . . . . . . . 38
5.2.2 Génération de la distribution pour la carte cible . . . . . . . . . . . 40
5.2.3 Réalisation de l’application . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.4 Implementation de tableau de bord . . . . . . . . . . . . . . . . . . 46

Conclusion et perspectives 48

Bibliographie 49

Netographie 50
Table des figures

1.1 Implantations du groupe ACTIA [URL1]. . . . . . . . . . . . . . . . . . . . 4


1.2 Communication instrument de bord et capteurs [URL2]. . . . . . . . . . . 5
1.3 Méthode agile SCRUM [URL3]. . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Architecture du projet IoTivity [URL3]. . . . . . . . . . . . . . . . . . . . 12


2.2 Modèle client/Serveur []. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Diagramme de cas d’utilisation global. . . . . . . . . . . . . . . . . . . . . 15


3.2 Diagramme de séquence pour le scénario de la connexion des clients. . . . . 17
3.3 Diagramme de séquence pour le scénario de la lecture des valeurs des cap-
teurs(GET Value). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Diagramme de séquence pour le scénario de modification des valeurs des
capteurs(PUT Value). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Diagramme de séquence pour le scénario de déconnexion des clients. . . . . 21

4.1 Les couches du modèle OSI. . . . . . . . . . . . . . . . . . . . . . . . . . . 23


4.2 Comparaison de protocole CAN-MSP avec le modèle OSI. . . . . . . . . . 24
4.3 Format du message d’ordre. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Format du message réponse. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Ordre des octets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Diagramme d’état/transition d’un esclave . . . . . . . . . . . . . . . . . . . 29
4.7 Exemple d’envoi d’un message fragmenté. . . . . . . . . . . . . . . . . . . . 31
4.8 diagramme d’activité de réception d’un message. . . . . . . . . . . . . . . . 32
4.9 diagramme d’activité d’envoi d’un message. . . . . . . . . . . . . . . . . . . 33
4.10 Décomposition du champ d’arbitrage. . . . . . . . . . . . . . . . . . . . . . 34

5.1 phyBOARD-Mira-imx6 []. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


5.2 Les différents composants du carte phyBOARD-Mira-imx6 []. . . . . . . . . 36
5.3 Écran Tactile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Minicom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 Le montage des composants . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 Photo réelle du montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

vi
Table des figures vii

5.7 Légende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.8 Légende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.9 Photo réelle du montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.10 Messages CAN d’ordre de connexion . . . . . . . . . . . . . . . . . . . . . 43
5.11 Trames échangées entre le maître et un esclave lors de la configuration d’une
sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.12 Ordre de configuration avec des fausses paramètres . . . . . . . . . . . . . 45
5.13 Lecture de la valeur d’une entrée d’un esclave . . . . . . . . . . . . . . . . 46
5.14 Le chronogramme de PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Liste des tableaux

4.1 Liste des codes et des paramètres des ordres. . . . . . . . . . . . . . . . . . 25


4.2 L’ensemble des réponses des esclaves. . . . . . . . . . . . . . . . . . . . . . 27
4.3 Les types des messages de la couche du transport. . . . . . . . . . . . . . . 30
4.4 Composition de chaque type de trame. . . . . . . . . . . . . . . . . . . . . 31

5.1 Caractéristiques du PC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

viii
Liste des sigles et acronymes

BSP Board Support Package


CAN Controller Area Network
CAN-MSP Controller Area Network-Master Slave Protocol
ISO-TP International Organization for Standardization-Transport Layer
OSI Open Systems Interconnection
SPU Safety Power Units

ix
Introduction générale

La croissance exponentielle du nombre d’appareils connectés (réseaux sociaux, sms,


vidéos, mails, objets connectés, etc.) a engendré une explosion du volume des données
échangées. L’exploitation de ces Big Data issues des objets connectés constitue aujour-
d’hui une incroyable source de richesse pour les entreprises particulièrement d’un point de
vue métier et c’est ce qui explique leur recours progressif à l’Internet des Objets (Internet
of Things (IoT) en anglais).
Le terme IoT a été utilisé pour la première fois par l’ingénieur britannique Kevin Ashton
en 1999, pour décrire un système où les objets physiques sont connectés à internet [URL4].
Actuellement, l’IoT désigne la capacité d’un objet physique (un capteur par exemple) à
communiquer avec un objet virtuel (tel qu’un réseau de capteurs). Plus généralement, cette
notion désigne, pour un ensemble d’objets connectés, leur capacité à transmettre des don-
nées entre eux et à interagir de façon autonome. L’IoT est en plein essor ces dernières
années et son émergence est entrain de bouleverser de plus en plus de nombreux secteurs
dont celui de l’automobile.

En effet, dans n’importe quelle voiture proposée aujourd’hui sur le marché, on constate
clairement l’existence de la connectivité inter-systèmes, que ce soit dans le GPS, dans le
tableau de bord ou dans la gestion des sécurités. . . , marquant ainsi l’omniprésence de l’IoT
dans l’industrie automobile.
Dans le cadre du présent projet, nous nous intéressons particulièrement aux tableaux de
bord connectés dans les véhicules automobiles qui, grâce au développement des technolo-
gies informatiques et électroniques et à la croissance de l’IoT dans les années dernières,
sont devenus un accessoire indispensable dans chaque véhicule.

Les tableaux de bord utilisés actuellement dans les véhicules automobiles se présentent
sous la forme d’applications numériques qui communiquent directement avec les capteurs
(température, gasoil, puissance de moteur, vitesse, etc.) et renseignent le conducteur du vé-
hicule sur le fonctionnement du moteur et les paramètres de conduite (vitesse instantanée,
température extérieure, etc.) via un ensemble d’indicateurs et de témoins. Les informations
collectées sont dans ce cas traitées uniquement par le conducteur. Toutefois, dans certains
cas tels que les cas d’urgence, on se trouve dans l’obligation de traiter ces informations à

1
Introduction générale 2

distance. Dans cette optique, la société "ACTIA Engineering Services" cherche une solu-
tion efficace lui permettant la réalisation de ceci à travers plusieurs clients (Android, cloud,
etc.) dans le but de pouvoir contrôler les véhicules automobiles à distance. Ceci constitue
l’objectif principal de notre présente étude élaborée dans le cadre de notre projet de fin
d’étude (PFE) effectué au sein de l’entreprise « ACTIA Engineering Services ». En effet,
notre tâche consiste à intégrer, concevoir et développer une solution IoT pour la téléma-
tique temps réel basée sur le projet IoTivity avec un client QT/Qml et générer la distri-
bution sous l’environnement YOCTO, pour le contrôle à distance des véhicules automobile.

Le présent manuscrit illustre le travail réalisé en cinq chapitres organisés comme suit :
Dans le premier chapitre, nous présentons le cadre général de notre projet et détaillons la
problématique étudiée ainsi que la solution proposée. Le deuxième chapitre, quant à lui,
est consacré à une étude préliminaire, qui présente les définitions des différentes notions
et concepts théoriques dont la compréhension est nécessaire pour la réalisation du projet.
Le troisième chapitre présente l’analyse des besoins à satisfaire lors de la réalisation de la
solution proposée illustrée par certains diagrammes UML. La partie conceptuelle du projet
sera décrite dans le quatrième chapitre qui englobe la conception globale et la conception
détaillée de projet. Tandis que, le cinquième et dernier chapitre illustre la phase de réali-
sation, tests et validation des différentes fonctionnalités de la solution implémentée. Nous
clôturons ce rapport par une conclusion générale présentons une synthèse du travail réalisé
ainsi que nos perspectives.
Chapitre 1

Présentation générale

Dans ce chapitre, Nous présentons le cadre général de notre projet. Nous commençons
ainsi par la présentation de l’organisme d’accueil. Ensuite, nous décrivons la problématique
abordée et détaillons le travail demandé. Nous clôturons ce chapitre par la présentation de
la méthodologie de travail adoptée pour la réalisation de notre projet.

1.1 Cadre général du projet


Le présent projet s’inscrit dans le cadre du projet de fin d’études (PFE) effectué au
sein de l’entreprise « ACTIA Engineering Services (ACTIA ES) » en vue de l’obtention
du titre d’ingénieur en informatique de l’École Nationale des Sciences de l’Informatique
(ENSI). Il a duré quatre mois allant du 01/02/2020 jusqu’à 30/05/2020

1.2 Présentation de l’organisme d’accueil


« ACTIA Engineering Services » est la nouvelle dénomination sociale de « ARDIA », la
filiale du groupe mondial d’origine française ACTIA implantée à Tunis et créée en 2005 pour
accompagner le développement des savoir-faire du groupe en engineering notamment dans
le domaine du logiciel. Ce changement met en lumière la forte intégration et contribution
de cette filiale à l’activité du groupe et à son déploiement à l’international (voir Figure 1.1)
[URL5].
Les domaines d’activités de cet organisme sont principalement [URL5] :
• Diagnostic automobile
— Développement de logiciels de diagnostic après-vente pour des constructeurs spé-
cifiques.
— Développements logiciels de diagnostic multimarques.
• Électronique Embarquée pour véhicules industriels

3
1.3. Problématique étudiée 4

— Développement et validation des logiciels embarqués pour calculateurs électro-


niques.
— Développement de cartes électroniques pour applications temps réel embarqué.

Figure 1.1 – Implantations du groupe ACTIA [URL1].

1.3 Problématique étudiée


Les véhicules automobiles (voitures, camions, etc.) utilisent aujourd’hui des tableaux
de bords classiques, qui sont généralement des applications numériques communiquant di-
rectement avec les capteurs (Température, Gasoil, puissance de moteur, vitesse, etc.) et
renseignant le conducteur du véhicule sur le fonctionnement du moteur et sur les para-
mètres de conduite (vitesse instantanée, température extérieure, etc.).Les informations et
valeurs affichées par les indicateurs du tableau de bord sont traitées dans ce cas seulement
par le conducteur.
Cependant, dans certains cas (cas d’urgence par exemple) et pour certains véhicules au-
tomobiles (les voitures autonomes par exemple), nous sommes obligés de traiter ces infor-
mations à distance pour pouvoir contrôler le véhicule. C’est pourquoi, la société « ACTIA
Engineering Services » s’est mis dernièrement à la recherche d’une solution efficace leur
permettant la réalisation de cet objectif à travers divers clients (Android, Cloud, etc..).
1.4. Critique de l’existant 5

Figure 1.2 – Communication instrument de bord et capteurs [URL2].

1.4 Critique de l’existant

1.5 Solution proposée

1.6 Méthodologie adoptée


Pour réaliser le travail qui nous a été confié, nous avons adopté la méthode agile
SCRUM. Dans ce qui suit, nous présentons cette méthode et justifions notre choix mé-
thodologique.

1.6.1 Méthode SCRUM


Les méthodes agiles caractérisent un mode de gestion des projets informatiques privi-
légiant le dialogue entre toutes les parties prenantes. Elles ont pour origine le manifeste
Agile, qui consacre le terme d’ « agile », et qui définit une approche de gestion de projet
prenant le contre-pied des approches traditionnelles prédictives et séquentielles de type
cycle en V [URL6] ou en cascade [URL7], pour référencer de multiples méthodes existantes
[URL8]. SCRUM est la méthodologie la plus utilisée parmi les méthodes Agiles existantes.
Elle est considérée comme un cadre ou « framework » de gestion de projet. Ce cadre est
constitué d’une définition des rôles, de réunions et d’artefacts [URL8].
1.6. Méthodologie adoptée 6

La méthode agile SCRUM définit 3 grands rôles comme l’illustre la figure 1.3. Ces rôles
sont, respectivement, le Product Owner, le ScrumMaster et l’équipe de développement.
• Le Product Owner est celui qui porte la vision du produit à réaliser (représentant
généralement le client).
• Le Scrum Master est le garant de l’application de la méthodologie SCRUM.
• L’équipe de développement est responsable de la réalisation du produit.

Figure 1.3 – Méthode agile SCRUM [URL3].

1.6.2 Justification du choix méthodologique


Nous avons choisi l’adoption de la méthode agile SCRUM pour la réalisation de notre
projet parce qu’elle présente plusieurs avantages dont nous citons principalement [URL3] :
• La simplicité des processus.
• La clarté de la définition des règles.
• L’augmentation de la productivité.
• L’organisation personnelle.
• Chaque équipe a son lot de responsabilité.
• L’amélioration de la communication.

Conclusion
Dans ce chapitre, nous avons présenté le cadre général de notre projet, ainsi que la
solution proposée pour la résolution de la problématique étudiée et la méthodologie du
travail adoptée pour sa réalisation.
Chapitre 2

Étude préliminaire

Avant de commencer tout travail, il est primordial de mettre le projet à réaliser dans son
cadre technique en définissant les différentes notions et concepts théoriques et en présentant
les différents outils à utiliser dont la compréhension et la maîtrise sont indispensables pour
la réalisation du projet.

2.1 Internet des objets (IoT)

2.1.1 Définition
L’internet des objets (Internet Of Things en anglais (IoT)) a été utilisé pour la première
fois par l’ingénieur britannique Kevin Ashton en 1999 pour définir un système où les objets
physiques sont connectés à internet [URL4].
Pour plus de clarté, il s’agit de systèmes capables de créer et transmettre des données afin de
créer de la valeur pour les utilisateurs à travers divers services (agrégation, analytique, etc.).
Ce terme désigne également selon l’UIT (Union Internationale des Télécommunications)
« une infrastructure mondiale pour la société de l’information, qui permet de disposer de
services évolués en interconnectant des objets (physique ou virtuels) grâce aux technologies
de l’information et de la communication interopérables existantes ou en évolution » [URL9].
Le terme IoT est en plein essor ces dernières années et son émergence est entrain de
bouleverser de plus en plus de nombreux secteurs (santé, agriculture, industrie, automobile,
etc.) et il s’articule autour de 5 composants essentiels qui sont, respectivement [URL9] :
• Les objets (capteurs).
• Le réseau (connectivité).
• Les données.
• Les informations.
• Les applications d’exploitation.

7
2.2. Télématique embarquée 8

2.1.2 Bénéfices
L’Internet des objets promet ainsi une forte plus-value à chaque organisme. En connec-
tant objets, personnes et environnements, il devient possible de développer des améliora-
tions qui ne pourront être que bénéfiques.
Les principaux bénéfices que peut avoir une entreprise dotée d’un système IoT sont [URL10] :
• Amélioration de la productivité : l’IoT permet la surveillance, le monitoring et le
contrôle des différents process, ce qui optimise les différentes opérations qui aug-
mentent la productivité et l’efficacité.
• Analyses prédictives : grâce à la collecte de nombreuses données, les nouvelles tech-
nologies de l’IoT permettent d’examiner les patrons récurrents et contribuent à
l’analyse prédictive qui peut être principalement utilisée en maintenance. Ces infor-
mations précises vont servir à améliorer les process et les services existants.
• Rapidité d’action : les données permettent de suivre en temps réel et même à dis-
tance les systèmes mis en place. Elles facilitent l’optimisation des interventions de
maintenance, mais aussi donnent un avantage stratégique à l’entreprise dans le suivi
de l’évolution des marchés.
• Diminution des erreurs humaines : grâce à la complémentarité des technologies
comme l’intelligence artificielle, l’IoT permet de minorer les erreurs humaines dues
à des tâches mondaines ou répétitives.

2.2 Télématique embarquée


La télématique est un domaine scientifique qui a pour but la transmission longue dis-
tance de l’information informatisée. Cette notion est de plus en plus utilisée aujourd’hui
dans le domaine de la gestion des flottes automobiles [].
Depuis plusieurs années, les entreprises disposent d’un ensemble d’outils efficaces leur per-
mettant de suivre, piloter et gérer en temps réel les opérations de leurs multiples collabo-
rateurs sur le terrain. Cet ensemble d’outils est communément désigné par "télématique
embarquée". Grâce à des boîtiers électroniques de géolocalisation par GPS insérés dans les
véhicules, les systèmes de télématique embarquée sont capables de suivre et de transmettre
en permanence au service d’exploitation de l’entreprise la position géographique, la dis-
tance parcourue, le parcours utilisé, les temps de conduite ou d’arrêt de chaque véhicule.
Ceci permet par conséquent une meilleure compréhension de l’utilisation de la flotte et des
comportements des conducteurs [].
La télématique embarquée compte notamment plusieurs avantages dont nous citons prin-
cipalement [] :
• L’optimisation de la gestion des véhicules et de la mobilité.
• La rationalisation de l’organisation.
• L’amélioration du comportement de conduite et l’aide à la conduite.
• L’augmentation de la sécurité tout en réduisant le TCO (Total Cost Of Ownership).
2.3. Projet Yocto 9

2.3 Projet Yocto


La plupart des utilisateurs et développeurs GNU/Linux utilisent des distributions clas-
siques (UBUNTU, Fedora, OpenSuse, etc.), afin de créer un poste de travail qui peut aller
de la simple bureautique au développement (C/C++, Java, Python, etc.) en intégrant des
outils comme « eclipse ». De même, l’espace occupé par une distribution classique est rela-
tivement important (plusieurs Go, voire plusieurs dizaines de Go) à cause des composants
installés.
Dans un autre point, depuis plusieurs années, GNU/Linux est utilisé pour des solutions
industrielles (embarqués, IoT, etc.). La principale différence correspond à l’empreinte mé-
moire utilisée ainsi qu’à la puissance du matériels (CPU, RAM, Stockge, etc.), c’est pour
cela l’utilisation des distributions classiques (précompilées) dans les systèmes embarqués
n’est pas recommandée et que l’on préfère plutôt créer l’image du système à partir des
sources de composants en utilisant un outil dédié dit outil de construction (build system)
[URL3].
Parmi les outils de construction les plus utiles et les plus performants qui peuvent être uti-
lisés pour créer des images personnalisées à base linux pour les systèmes embarqués, nous
citons le projet Yocto que nous présentons en détails dans les sous-sections qui suivent.

2.3.1 Définition
Le projet Yocto est un projet de collaboration open source, sponsorisé par la fondation
Linux (Linux foundation), qui aide les développeurs à créer des systèmes basés sur Linux
personnalisés dédiés aux systèmes embarqués quelle que soit l’architecture matérielle du
produit utilisé [URL11].
Dans le même point, il est plus qu’un système de construction, le projet Yocto fournit
un ensemble d’outils flexibles et un environnement de développement qui permet aux dé-
veloppeurs des systèmes embarqués à travers le monde de collaborer via des technologies
partagées, des piles de logiciels, des configurations et les meilleures pratiques utilisées pour
créer des images Linux personnalisées [URL12].

2.3.2 Caractéristiques du projet Yocto


Le projet Yocto possède de nombreuses caractéristiques dont nous citons principalement
[] :
• indépendance de l’architecture : le projet Yocto prend en charge les architectures
ARM, MIPS, PPC et autres. La plupart des fournisseurs de puces créent et four-
nissent des Board Support Package (BSP) qui prennent en charge leur matériel.
• Flexibilité : les entreprises utilisent le projet Yocto de différentes manières. Un
exemple est de créer une distribution Linux interne en tant que base de code que la
2.4. Projet IoTivity 10

société peut utiliser dans plusieurs groupes de produits. Grâce à la personnalisation


et à la superposition, un groupe de projets peut tirer parti de la distribution Linux
de base pour créer une distribution qui répond aux besoins de leurs produits.
• Adéquation parfaite aux appareils embarqués et aux contraintes de l’IoT : Contrai-
rement à une distribution Linux complète, il est possible d’utiliser le projet Yocto
pour créer exactement ce dont on a besoin pour les systèmes embarqués. Pour plus
de clarté le projet Yocto nous permet d’ajouter uniquement le support de fonction-
nalités ou les packages dont nous avons absolument besoin pour notre système.
• Images et transfert de code en toute simplicité : la sortie du projet Yocto peut facile-
ment passer d’une architecture à l’autre sans passer à de nouveaux environnements
de développement[URL12].

2.3.3 Défis du projet Yocto


Le projet Yocto présente également quelques défis à surmonter dont nous citons prin-
cipalement [] :
• Travailler dans un environnement cross-build peut sembler inconnu. En effet lors
du développement de code à exécuter sur une cible, la compilation, l’exécution
et les tests effectués sur la cible réelle peuvent être plus rapides que l’exécution
d’une génération BitBake sur un hôte de développement, puis le déploiement de
binaires sur la cible pour le test. Bien que le projet Yocto prend en charge les
outils de développement sur la cible, l’étape supplémentaire consistant à réintégrer
les modifications dans l’environnement de génération du projet Yocto est toutefois
requise.
• Les temps de construction initiaux peuvent être importants : En effet les longs
temps de construction initiaux sont malheureusement inévitables en raison du grand
nombre de packages initialement construits à partir de zéro pour un système Linux
pleinement fonctionnel. Cependant, une fois cette génération initiale est terminée,
le mécanisme de cache à état partagé (sstate) utilisé par le projet Yocto empêche le
système de reconstruire des packages qui n’ont pas été "touchés" depuis la dernière
génération. Le mécanisme « sstate » réduit considérablement les délais de génération
successifs [URL12].

2.4 Projet IoTivity


2.4.1 Définition
Le projet IoTivity est un projet open source permettant une connectivité transparente
entre appareils, où des milliards d’appareils câblés et sans fil peuvent se connecter en toute
sécurité entre eux et à Internet. Ce projet est sponsorisé par l’Open Connectivity Foun-
dation(OCF), un groupe de sociétés technologiques telles que Samsung Electronics, Intel,
2.4. Projet IoTivity 11

Cisco, etc qui, ensemble, élaborent des spécifications standard, des directives d’interopéra-
bilité et un programme de certification pour ces appareils pour activer l’IoT [].
Les API du framework IoTivity exposent le framework aux développeurs, elles sont dispo-
nibles dans plusieurs langages de programmation et pour plusieurs systèmes d’exploitation.
Le cadre prend en charge des protocoles dédiés et optimisés pour l’IoT, avec des considé-
rations spécifiques pour les appareils contraints et s’adressant à tous les types d’appareils,
facteurs de forme, entreprises, écosystèmes et marchés [].
Ce dernier fonctionne comme un middleware sur tous les systèmes d’exploitation et plates-
formes de connectivité et comprend ces quatre éléments constitutifs essentiels [] :
• Découverte : prise en charge de plusieurs mécanismes pour découvrir des appareils
et des ressources à proximité et à distance.
• Transmission de données : prise en charge de l’échange et du contrôle d’informations
sur la base d’un modèle de messagerie et de streaming.
• Gestion des données : prise en charge de la collecte, du stockage et de l’analyse des
données de diverses ressources.
• Gestion des appareils : prise en charge de la configuration, de l’approvisionnement
et des diagnostics des appareils.

2.4.2 Architecture du projet IoTivity


L’objectif architectural du projet IoTivity est de créer une nouvelle norme par laquelle
des milliards d’appareils câblés et sans fil se connecteront entre eux et à Internet. L’objectif
est une architecture extensible et robuste qui fonctionne pour les appareils intelligents et
légers [].
En effet, l’architecture de ce projet, illustrée par la figure 2.1 fournit une feuille de route
aux fabricants et aux fournisseurs de services, leur offrant notamment [] :
• Solution commune : Possibilité de définir une solution de communication et d’inter-
opérabilité sur plusieurs marchés de produits tels que la consommation, l’entreprise,
l’industrie, l’automobile et la santé, ainsi que sur les systèmes d’exploitation, les
plates-formes, les modes de communication, les transports et les cas d’utilisation.
• Protocoles établis : Possibilité de réutiliser les protocoles de communication exis-
tants et en établir de nouveaux pour la découverte et la connectivité sur plusieurs
transports.
• Approches communes : Possibilité d’appliquer des approches communes pour la
sécurité et l’identité.
• Points communs définis : Possibilité de définir des profils, des modèles d’objet et
des interfaces de programmation d’application (API) communs.
• Interopérabilité : Possibilité de promouvoir l’interopérabilité des appareils et des
applications sur les marchés et leurs cas d’utilisation.
• Opportunités d’innovation : Offrir des opportunités d’innovation et permettre la
différenciation.
2.5. Modèle client/serveur 12

• Connectivité nécessaire : Possibilité de tout connecter, du plus petit portable à la


plus grande voiture intelligente
.

Figure 2.1 – Architecture du projet IoTivity [URL3].

2.5 Modèle client/serveur

Le modèle client-serveur désigne un mode de communication à travers un réseau entre


plusieurs programmes : un programme (le client) demande un service ou une ressource à
un autre programme (le serveur).
Le modèle client/serveur, illustré par la figure 2.2, peut être utilisé par des programmes
d’un même ordinateur, mais le concept est surtout utile dans le cadre d’un réseau.
2.5. Modèle client/serveur 13

Figure 2.2 – Modèle client/Serveur [].

Conclusion
Dans ce chapitre nous avons défini les différents concepts théoriques dont la compré-
hension est nécessaire pour la réalisation de notre projet. Dans le prochain chapitre, nous
entamons la partie analyse et spécification des différents besoins à satisfaire lors de la mise
en œuvre de notre solution.
Chapitre 3

Analyse et spécification des besoins

Dans ce chapitre, nous exposons les différents besoins fonctionnels et non fonctionnels à
satisfaire lors de la réalisation de notre projet. Nous y décrivons également le comportement
dynamique de l’application à réaliser tout en introduisant l’interaction entre les clients et
le serveur via différents diagrammes du langage de modélisation unifié (UML).

3.1 Identification des acteurs

3.2 Étude des besoins


Dans cette section, nous détaillons les besoins fonctionnels et non fonctionnels qui
doivent être pris en considération lors de développement de notre application.

3.2.1 Besoins fonctionnels


Le système doit assurer les fonctionnalités suivantes :
• Le serveur peut communiquer avec un ou plusieurs clients à la fois.
• Un client peut envoyer des requêtes (ordre) auxquelles il attend des réponses de la
part du serveur. Ces requêtes peuvent être de type :
— requêtes de connexion/déconnexion.
— requêtes de récupération de valeurs (GET VALUE).
— requêtes d’ajout de valeurs(PUT VALUE).
• Deux clients ne peuvent pas dialoguer ensemble.
• le serveur peut traiter plusieurs requêtes provenant de différents clients simultané-
ment et en temps réel.

14
3.3. Le diagramme de cas d’utilisation 15

3.2.2 Besoins non fonctionnels


Les Besoins non fonctionnels sont des besoins qui caractérisent le système. Il s’agit
des besoins en matière de performance, de type de matériel ou le type de conception. Les
différents besoins non fonctionnels relatifs à notre application sont respectivement :
• Temps de réponse : La communication entre les différents clients et le serveur doit
être en temps réel.
• Sécurité : La communication entre les différents clients et le serveur doit être hau-
tement sécurisés.

3.3 Le diagramme de cas d’utilisation


L’objectif de cette partie est de décrire le comportement attendu du système. Pour ce
faire, nous nous basons sur le diagramme des cas d’utilisation illustré par la figure 3.1 qui
représente un élément essentiel de la modélisation.

Figure 3.1 – Diagramme de cas d’utilisation global.


3.4. Diagrammes de séquence 16

3.4 Diagrammes de séquence

Les diagrammes de séquence UML sont des diagrammes d’interaction qui représentent
comment les opérations sont effectuées. Ils détaillent les différentes interactions entre les
objets à travers le temps []. Dans ce qui suit, nous présentons les diagrammes de séquence
des différents scénarios pouvant avoir lieu entre le serveur et les clients.

3.4.1 Diagramme de séquence pour le scénario de la connexion


des clients

Avant le démarrage, tous les clients(tableau de bord, android, cloud, web, etc) sont à
l’état «déconnecté». Donc avant d’envoyer tout autre ordre, le client principal (tableau de
bord du véhicule) doit envoyer d’abord de façon autonome et automatique une demande
de connexion au serveur pour qu’il passe à l’état «connecté» et pour que le démarrage
soit fait avec succès. Quant aux autres clients (Android, cloud, web), ils passent à l’état
«connecté» de façon manuelle suit à la demande des utilisateurs.
L’opérateur « alt » désigne une alternative. Il représente deux comportements possibles :
c’est l’équivalent du SI...ALORS...SINON : donc, une seule des deux possibilités sera réali-
sée dans un scénario donné. La figure 3.2 illustre le diagramme de séquence système relatif
au scénario de connexion des clients.
3.4. Diagrammes de séquence 17

Figure 3.2 – Diagramme de séquence pour le scénario de la connexion des clients.

3.4.2 Diagramme de séquence pour le scénario de la lecture des


valeurs des capteurs.
Pour avoir les informations nécessaires sur l’état du véhicule (vitesse, état du conduc-
teur, etc), le client peut demander des valeurs à distance des différents capteurs (Device
connecté). Si le client est connecté, il envoie une demande à travers le réseau au serveur qui
à son tour répond par la valeur demandée par le client ou bien il répond avec un message
d’erreur pour indiquer au client que la lecture a échoué ou bien que le périphérique (cap-
teur) n’est pas connecté. La figure 3.3 illustre le diagramme de séquence système relatif au
3.4. Diagrammes de séquence 18

scénario de la lecture des valeurs des capteurs.

Figure 3.3 – Diagramme de séquence pour le scénario de la lecture des valeurs des cap-
teurs(GET Value).

3.4.3 Diagramme de séquence pour le scénario de modification des


valeurs des capteurs.
Afin de manipuler les différents actionneurs et capteurs connectés au serveur, le client
peut envoyer un ordre de modification de la valeur d’un capteur à distance à travers le
réseau. Si le client est connecté, il envoie une demande à travers le réseau au serveur qui
à son tour exécute la modification du capteur et répond par un message indiquant que
l’opération a été effectuée avec succès. Dans le cas contraire, le serveur répond par un mes-
sage d’erreur indiquant au client que la modification a échoué ou bien que le périphérique
(capteur) n’est pas connecté. La figure 3.4 illustre le diagramme de séquence système relatif
au scénario de la lecture des valeurs des capteurs.
3.4. Diagrammes de séquence 19

Figure 3.4 – Diagramme de séquence pour le scénario de modification des valeurs des
capteurs(PUT Value).
3.4. Diagrammes de séquence 20

3.4.4 Diagramme de séquence pour le scénario de déconnexion des


clients

Si un des clients (Android, cloud, agile) n’a plus besoin de traiter certains valeurs, il
envoie une demande de déconnexion au serveur pour pouvoir s’arrêter et passer à l’état
«déconnecté». Pour le client principal (tableau de bord de véhicule), il passe à l’état dé-
connecté automatiquement et de façon autonome.
Lorsqu’un client passe à l’état déconnecté, toutes ses fonctionnalités seront désactivées et il
ne peut plus traiter recevoir aucune information provenant du serveur. La figure 3.4 illustre
le diagramme de séquence système relatif au scénario de la déconnexion des clients.
3.4. Diagrammes de séquence 21

Figure 3.5 – Diagramme de séquence pour le scénario de déconnexion des clients.

Conclusion
Dans ce chapitre, nous avons présenté les différents besoins fonctionnels et non fonc-
tionnels à satisfaire dans notre projet et détaillé les différents services offerts via des dia-
grammes de d’utilisation et de séquence. Dans le chapitre suivant, nous abordons la partie
conceptuelle, qui englobe la conception globale et la conception détaillée du projet.
Chapitre 4

Conception

Après avoir terminé l’analyse et spécification des besoins, nous pouvons aborder la phase
suivante du processus du développement qui est l’étude conceptuelle. Dans ce chapitre, nous
allons passer par deux phases importantes qui sont la conception générale et la conception
détaillée. Pour chaque phase, nous avons choisi de détailler seulement les étapes les plus
importantes.

4.1 Conception Architecturale

4.1.1 Le modèle Client/serveur

Le modèle Client/serveur désigne un mode de communication organisé par l’intermé-


diaire d’un réseau l’association des technologies de l’information et de la communication,
avec des objets, rendus ainsi intelligents et communicants, dans le but est de donner à ces
derniers les moyens d’interagir sans intervention humaine. Les principaux éléments d’un
système fonctionne selon l’architecture client/serveur comprennent :
• un appareil ou un groupe de dispositifs capables de répondre aux demandes de don-
nées contenues dans ces appareils ou capables de transmettre des données contenues
dans ces dispositifs autonomes.
• un lien de communication pour connecter les appareils, voire un groupe de périphé-
riques à un ordinateur ou un autre appareil.
• un logiciel ou processus par le quelle les données peuvent être analysées.
Dans le cas de notre protocole, les appareil sont des calculateurs de voiture qui ce commu-
niquent entre eux via le bus CAN afin de manipuler l’ensemble des périphériques(capteurs
et actionneurs) sans intervention humaine.

22
4.2. Conception détaillée 23

4.2 Conception détaillée

4.2.1 Analogie avec le modèle OSI


Le modèle OSI est une façon standardisée de segmenter en blocs les protocoles de
communication entre deux entités. Chaque bloc résultant de cette segmentation est appelé
couche. Une couche est un ensemble de services accomplissant un but précis. L’utilité de
cette segmentation, c’est que chaque couche du modèle OSI communique avec la couche
au-dessus et au-dessous d’elle. La couche au-dessous pourvoit des services que la couche en
cours utilise, et la couche en cours offre des services dont la couche au-dessus d’elle aura
besoin pour assurer son rôle.Le tableau de la figure FIGURE 4.1 montre les différentes
couches du modèle OSI ainsi que leur rôle.

Figure 4.1 – Les couches du modèle OSI.


4.2. Conception détaillée 24

À cause de la complexité de ce modèle, son implémentations est très difficiles, lourdes


et aussi lentes[URL2]. Nous avons choisi de regrouper les couches qui ont des rôles similaire
dans une seule couche (FIGURE 4.2).

Figure 4.2 – Comparaison de protocole CAN-MSP avec le modèle OSI.

4.2.2 Conception de la couche Applicative


Format du message d’ordre

Figure 4.3 – Format du message d’ordre.

La figure FIGURE 4.3 montre le format d’un message d’ordre envoyé du maître vers
l’esclave. Ce message est composé de deux parties :
• Code d’ordre : c’est un code unique à chaque ordre qui peut être exécuté par l’esclave
codé sur 1 octet (on peut définir jusqu’à 256 ordres).
• Les paramètres : c’est l’ensemble des paramètres nécessaires à l’exécution de l’ordre
par l’esclave. Chaque paramètre peut prendre de 1 jusqu’à 8 octets selon son type.
4.2. Conception détaillée 25

Le tableau TABLE 4.1 illustre les codes et les paramètres nécessaires de chaque ordre.

Paramètres
Code description
Nom Description
1 Connecter Aucun
2 Déconnecter Aucun
3 Réinitialiser MagicNumber Paramètre de sécurité qui doit être égale à
un valeur justifier (sur 4 octet) pour que
l’ordre s’exécute
Configurer une en- IOId Identifiant unique pour chaque entrée ou sor-
4
trée/sortie tie
ParameterType Type de configuration(Analog input, Degital
input, PWM Output, frequnecy input, Resis-
tance input ...)
Description Structure de donnée qui contient une descrip-
tion de la configuration à appliquer(Les va-
leur seuil, DutyCycle, frequence ...)
Réinitialiser une en- IOId Identifiant unique pour chaque entrée ou sor-
5
trée/sortie tie
ParameterType Type de configuration(Analog input, Degital
input, PWM Output, frequnecy input, Resis-
tance input ...)
Modifier la valeur IOId Identifiant unique pour chaque entrée ou sor-
6
d’une sortie tie
Type Type de la valeur à modifier(Voltage,
courent, fréquence ...)
Value La valeur à établir
Lecture rapide de la IOId Identifiant unique pour chaque entrée ou sor-
7
valeur d’une entrée tie
Type Type de la valeur à lire (Voltage, courent,
fréquence, résistance ...)
Lecture avec erreur de IOId Identifiant unique pour chaque entrée ou sor-
8
la valeur d’une entrée tie
Type Type de la valeur à lire (Voltage, courent,
fréquence, résistance ...)

Table 4.1 – Liste des codes et des paramètres des ordres.


4.2. Conception détaillée 26

Format du message de la réponse

La figure FIGURE 4.4 montre le format d’un message de réponse par un esclave à un
ordre du maître. Ce message est composé de deux parties :
• Code d’ordre : 1 octet pour le code de l’ordre exécuté par l’esclave.
• Réponse : c’est le champ qui contient la valeur de la réponse codée sur un nombre
variable des octets selon le type d’ordre.

Figure 4.4 – Format du message réponse.

Le tableau TABLE 4.2 illustre l’ensemble des réponses possibles d’un esclave aux dif-
férents ordres.

Réponse
Code description
Valeur Signification
1 Connecter 0 Connexion réussie
-1 Connexion échouée
2 Déconnecter 0 Déconnexion réussie
-1 Déconnexion échouée
3 Réinitialiser -1 Ré-initialisation échouée
Configurer une en- 0 Configuration réussie
4
trée/sortie
-1 Mauvais paramétrage (IOId fausse, faux Pa-
rameterType, faux description)
-2 Problème de hardware
-3 Problème driver ou pré-condition non respec-
tée
Réinitialiser une en- 0 Réinitialisation réussie
5
trée/sortie
-1 Mauvais paramétrage (IOId fausse, faux Pa-
rameterType)
-2 Problème hardware
-3 Problème driver ou pré-condition non respec-
tée
4.2. Conception détaillée 27

Modifier la valeur 0 Modification réussie


6
d’une sortie
-1 Mauvais paramétrage (IOId fausse, faux
type, valeur qui dépasse les valeurs limites)
-2 Problème de hardware
-3 Problème driver ou pré-condition non respec-
tée
Lecture rapide de la >=0 La valeur lue par l’esclave
7
valeur d’une entrée
-1 Rrreur dans la lecture
Lecture avec erreur de >=0 La valeur lue par l’esclave
8
la valeur d’une entrée
-1 Mauvais paramétrage (IOId fausse, faux
type)
-2 Problème hardware
-3 Problème driver ou pré-condition non respec-
tée

Table 4.2 – L’ensemble des réponses des esclaves.

Ordre des octets

L’ordre des octets utilisé est le big-endian : l’octet du poids le plus fort a l’index le plus
faible. Par exemple 0xA0F8C3B1 en notation hexadécimale est enregistré dans des octets
dans l’ordre qui suit : A0 F8 C3 B1, l’octet de poids le plus fort (ici A0) est enregistré à
l’index le plus petite, l’octet de poids inférieur (ici F8) est enregistré à l’index suivant et
ainsi de suite (FIGURE 4.5).

Diagramme d’état/transition d’un esclave

Les diagrammes d’état/transition montrent les différents états d’une entité. Ces dia-
grammes peuvent également montrer comment une entité réagit à divers événements en
passant d’un état à un autre. Le diagramme d’état/transition est un diagramme UML
utilisé pour modéliser la dynamicité d’un système.
La figure FIGURE 4.6 montre le diagramme d’état/transition d’un esclave.
4.2. Conception détaillée 28

images/byte-order.PNG

Figure 4.5 – Ordre des octets


4.2. Conception détaillée 29

images/state-machine.png

Figure 4.6 – Diagramme d’état/transition d’un esclave


4.2. Conception détaillée 30

4.2.3 Conception de la couche du transport


Fragmentation des messages : le protocole ISO-TP
Le bus CAN est destiné au transfert rapide des données entre les calculateurs. Ceci est
réalisé en fixant une limite de 8 octets maximum pour toute trames envoyées sur le bus. A
cause de cette limitation, l’envoi d’un message de plus de 8 octets doit être fragmenté par
le calculateur émetteur et réassemblé par le(s) calculateur(s) récepteur(s). Le protocole de
transport ISO-TP a été conçu pour cet effet [URL6].
Dans le cas de protocole CAN-MSP, les messages des ordres et des réponses de la couche
applicative sont généralement supérieur à 8 octets. C’est pour cela, nous avons choisi d’im-
plémenter le protocole ISO-TP dans la couche du transport pour surmonter la limitation
à 8 octets du bus CAN.
Le protocole ISO-TP ajoute aux messages à envoyer une entête pour permettre au récep-
teur à savoir quel type de trame (trame simple, trame fragmentée, trame du contrôle) est
transmis, combien d’octets de données seront envoyés dans le message, ou si le récepteur a
perdu des trames. Le tableau TABLE 4.3 montre les différents types des messages utilisés
dans l’ISO-TP.

Type Code Description


Single frame (SF) 0 Message non fragmenté contient de 0 à 7 octets de don-
nées
First frame (FF) 1 C’est la première trame d’un message fragmenté
Consecutive frame 2 La trame suivante d’un message fragmenté
(CF)
Flow control frame 3 La trame de contrôle envoyer par le récepteur pour
(FC) contrôler la procédure d’envoi des messages fragmentés

Table 4.3 – Les types des messages de la couche du transport.

Un message de 7 octets ou moins est envoyé dans une seule trame. le premier octet
contient le type (0) et la longueur de la longueur des données (1-7 octets). Les autres oc-
tets contiennent les données utiles.
Un message de plus de 7 octets nécessite une segmentation sur plusieurs trames. Un trans-
fert segmenté commence par une trame SF. Dans ce cas, l’entête est composé de deux
octets : un premier champ de 4 bits pour le type (type 1) et un deuxième champ de 12
bits pour la taille du message. Le destinataire confirme le transfert à l’aide d’une trame de
contrôle FC. La trame de contrôle est composée de trois octets spécifiant l’intervalle entre
les trames suivantes (ST) et le nombre de trames consécutives qui peuvent être envoyées
(taille de bloc) avant la prochaine trame du contrôle (voir TABLE 4.4). La figure FIGURE
4.7 illustre un exemple de transmission d’un message fragmenté.
4.2. Conception détaillée 31

Bit offset 0..3 4..7 8..15 16..23 ...


(Octet 0) (Octet 0) (Octet 1) (Octet 2)
SF 0 taille (0..7) DATA A DATA B DATA C
FF 0 taille (8..4095) DATA A DATA B
CF 2 index DATA A DATA B DATA C
(0..15)
FC 3 FC flag taille du ST
(0,1,2) bloc

Table 4.4 – Composition de chaque type de trame.

Figure 4.7 – Exemple d’envoi d’un message fragmenté.


4.2. Conception détaillée 32

Pour mieux clarifier le fonctionnement de la couche de transport, nous allons présen-


ter les différents diagrammes d’activités qui nous a aidés à établir une structure précise
du protocole. Ces diagrammes illustrent les activités qui collaborent pour aboutir au bon
fonctionnement de la transmission des données. La figure FIGURE 4.8 schématise le dé-
roulement de la réception d’un message dans les deux cas : cas d’un message fragmenté et
cas d’un message non fragmenté. La figure qui suit (FIGURE 4.9) illustre le déroulement
de l’envoi d’un message par l’émetteur.

images/activ-diag.png

Figure 4.8 – diagramme d’activité de réception d’un message.


4.2. Conception détaillée 33

Figure 4.9 – diagramme d’activité d’envoi d’un message.


4.2. Conception détaillée 34

L’adressage
Le protocole CAN-MSP est conçu pour supporter 64 esclaves connectés a un seule
maître. Donc, nous avons besoin d’une sorte d’adressage pour que les ordres envoyés par
le maître arrivent aux bonnes destinations. Pour assurer cette fonctionnalité, nous avons
utilisé le champ d’arbitrage du bus CAN composé de 11 bits( version standard 2.0A). La
figure 4.10 montre la décomposition de champ d’arbitrage.

modele_rapport_ensi/images/aabb.PNG

Figure 4.10 – Décomposition du champ d’arbitrage.

Le champ d’arbitrage est décomposé en 3 parties :


• Type de message : champ de 1 bit qui définit le type de message s’il s’agit d’un
ordre ou bien d’une réponse : 0 s’il sagit d’un ordre et 1 sinon
• Adresse de l’esclave : c’est le champ qui contient l’adresse de l’esclave. Ce champ
représente l’adresse de destinataire s’il s’agit d’un message d’ordre et il représente
l’adresse de l’émetteur s’il s’agit d’un message de réponse :
— Les esclaves sont identifiés par des adresses attribuées par l’utilisateur.
— L’adresse de chaque esclave est indépendante de son emplacement physique.
— Les adresses vont de 0 à 62
— L’adresse 63 est réservée aux messages de diffusion.
— Deux esclave ne peuvent avoir la même adresse.
• Id du transfert : c’est un champ du contrôle. Ce champ est incrémenté à chaque
ordre envoyé par le maître. La réponse de l’esclave à cette ordre contient la même
valeur dans ce champ. La valeur est incrémentée en modulo 15. La valeur 15 est
réservée aux messages de contrôle de présence des esclaves.

Contrôle de présence des esclaves


Pour contrôler la présence des esclaves et notifier le maître si un esclave devient non
joignable, un message sans données est envoyé chaque 50ms par chaque esclave. Si le maître
ne reçoit pas ce type de message pendant 100 ms, il en conclut que l’esclave est non
joignable.

Conclusion
A travers ce chapitre, nous avons présenté une vue conceptuelle du protocole CAN-
MSP. A ce stade, nous pouvons passer à la réalisation de la solution qui fera l’objet du
chapitre suivant.
Chapitre 5

Réalisation

Dans ce chapitre nous décrivons toutes les phases et les étapes de l’implémentation et
de la réalisation du notre projet qui est l’aboutissement des étapes précédentes débutant
de la présentation générale jusqu’à la conception. En effet, ce dernier représente le dernier
chapitre de ce rapport et il a pour objectif de présenter le projet réalisée. Nous présentons
en premier lieu l’environnement de travail sous les deux aspects : aspect matériel et aspect
logiciel.

5.1 Environnement de travail


Nous allons présenter dans cette section les choix techniques relatifs à l’environnement
matériel et logiciel qui ont contribué à la réalisation du notre projet.

5.1.1 Environnement matériel


phyBOARD-mira-imx6

PhyBOARD-Mira est un microcontrôleur de série phytec. Elle est composée du phyCORE-


i.MX 6 directement soudé sur la carte (par technique DSC) et du processeur i.MX 6 Cor-
tex A9 de chez NXP comme illustré par la FIGURE 5.1. Elle est équipée des interfaces
standards : Ethernet , USB, RS232/RS485, CAN, support micro-SD et miniPCle, de nom-
breuses interfaces d’extension sont possibles, HDMI, LVDS, ainsi que des interfaces et
connexions parallèles pour écran résistif ou capacitif par exemple [].
Elle est caractérisée par :
• Norme Serial ATA ( Serial Advanced Technology Attachment).
• Mini PCI.
• 1 x interface caméra parallèle.
• Choix flexible d’écrans à partir de 10,4".

35
5.1. Environnement de travail 36

Figure 5.1 – phyBOARD-Mira-imx6 [].

Pour donner une idée plus détaillée sur la carte phyBOARD-Mira-imx6, la figure FIGURE
5.2 montre en détaille les différents composants de la carte, ainsi que le processeur utilisé.

Figure 5.2 – Les différents composants du carte phyBOARD-Mira-imx6 [].

Écran tactile
La FIGURE 5.3 montre Un écran tactile (Display with Resistive Touch en anglais), qui
est définit comme étant un outil informatique qui combine les fonctionnalités d’affichage
d’un écran (moniteur) et celles d’un dispositif de pointage comme la souris, le pavé tactile
ou le stylet optique.
5.1. Environnement de travail 37

Cela permet de réduire le nombre de périphériques sur certains systèmes et de réaliser des
logiciels ergonomiques très bien adaptés à certaines fonctions. Les écrans tactiles sont utili-
sés, par exemple, pour les PDA, les GPS, des lecteurs MP3, les smartphones, les tablettes,
les tableaux de bords, etc.

Figure 5.3 – Écran Tactile

PC bureau

L’implémentation est réalisée sur un ordinateur ayant la configuration décrite dans le


tableau TABLE 5.1.

Système d’exploitation UBUNTU 16.04


Mémoire centrale 16 GO
Processeur Intel Core I7
Disque Dur 1 TO

Table 5.1 – Caractéristiques du PC.

5.1.2 Environnement logiciel


Cette section est consacrée à la présentation des différentes technologies et logiciels
utilisés pour le développement de tableau de bord.
5.2. Réalisation 38

QTcreator
Pour le codage et l’implementation du tableau de bord(Application) nous avons utilisé
l’ environnement de développement (IDE) QTcreator compatible avec la programmation
en langage qml et c++. Ce dernier offre plusieurs fonctionnalité d’organisation de code et
une diversité d’options de compilation des codes sources.

Minicom
Minicom est un programme de contrôle de modem et d’émulation de terminal pour les
Unix-like. Il peut être comparé à HyperTerminal dans Windows. Ce programme a été écrit
par Miquel van Smoorenburg d’après le populaire Telix pour MS-DOS. Minicom apporte
une émulation totale ANSI et VT100, un langage de script externe, et d’autres choses
encore. Il est souvent utilisé dans notre projet pour la connexion et l’affichage du terminale
de notre image personnalisé.

Figure 5.4 – Minicom

5.2 Réalisation
5.2.1 Montage des différents composants
Durant la phase de réalisation, développement et de test de notre projet, nous avons
utilisé le montage illustré par la figure 5.5. En effet, ce dernier est composé de :
• 2 cartes phyBOARD-Mira-Imx6.
• 2 alimentation 12V.
• câble Ethernet.
• Écran tactile.
5.2. Réalisation 39

• PC.

Dans le montage, nous avons utilisé deux cartes phyBOARD, pour que nous puissions
exécuter le client et le serveur sur différentes cibles dans le but de valider les différentes
fonctionnalités du projet.

Figure 5.5 – Le montage des composants

Pour plus de clarté, nous allons montrer par la figure 5.9 une vision réelle et plus claire sur
le montage utilisé dans le projet.
5.2. Réalisation 40

Figure 5.6 – Photo réelle du montage

5.2.2 Génération de la distribution pour la carte cible


Avant d’aborder la phase de développement de notre application, nous sommes obligés
de générer une image linux personnalisé pour la cible phyboard-Mira (carte de développe-
ment) pour valider les caractéristiques d’un système embarqué (espace memoire, )

5.2.3 Réalisation de l’application


Dans cette partie, nous allons montrer quelques

Ordre de connexion
Ordre de lecture des valeurs
Les figures ??, ?? et ?? montrent un exemple d’un ordre envoyé par le client au serveur
de renvoyer les valeurs de vitesse, puissance de moteur, température, mode des LEDS.

Ordre de modification des valeurs


Les figures ??, ?? et ?? montrent un exemple d’un ordre envoyé par le client au serveur
de mettre la valeur de la LED entre les modes on/off (SET LED to : 1, SET LED to : 0).
5.2. Réalisation 41

Figure 5.8 – Légende


Figure 5.7 – Légende

Ordre de déconnexion

Ordre de connexion

La figure FIGURE 5.10 montre la trace des trames CAN envoyées au début de la démo
pour connecter les deux esclaves.
La figure FIGURE 5.10 est divisée en 5 champs :
• 1 : Une trame CAN sans données de contrôle de présence envoyée par l’esclave
d’adresse 1.
• 2 : Une autre trame de contrôle de présence envoyée après 50ms par l’esclave
d’adresse 1.
• 3 : Un ordre de connexion envoyé à l’esclave d’adresse 1. L’ID de message est égale
à 0x010. Le premier bit de l’ID est à 0 puisqu’il s’agit d’un ordre envoyé par le
maître. Les 6 bits suivants égales à 000001 en binaire et ils représentent l’adresse de
l’esclave. Les 4 dernier bits sont tous à 0 et ils forment l’Id du transfert. Le champ
de donnée contient la valeur 0x0101 : le premier octet est l’entête de la couche du
transport qui contient le type de message et la longueur des données et le deuxième
octet représente le code d’ordre à exécuter par l’esclave qui est la connexion.
• 4 : C’est la réponse de l’esclave d’adresse 1 à l’ordre envoyé par le maître. L’ID
de message est semblable à celui de message d’ordre seulement le premier bit est
changé à 1 puisqu’il sagit d’une réponse. Le champ de donnée contient 7 octets. Le
premier octet (06) représente l’entête CAN tp : 0 pour le type de message qui est
une trame unique(SF) et le 5 indique la longueur des données utile. Le deuxième
octet 01 indique le code d’ordre exécuté par l’esclave. Le reste de message ( 00 00
00 00 ) indique que l’ordre est bien exécuté par l’esclave.
• 5 : Ordre envoyé à l’esclave d’adresse 5.
5.2. Réalisation 42

Figure 5.9 – Photo réelle du montage

• 6 : Réponse de l’esclave d’adresse 5.

Ordre de configuration d’une sortie


La figure FIGURE 5.11 illustre les différentes trames échangées pour configurer la sortie
d’un esclave par le maître.
La figure est divisée en plusieurs parties :
• 1 : C’est la première trame CAN de message d’ordre fragmenté. Elle est de type FF
et contient 6 octets de données utiles dont le code d’ordre qui égale à 04.
• 2 : Une trame CAN de contrôle FC envoyée par l’esclave récepteur pour indiquer
au maître qu’il peut continuer à envoyer le reste du message avec un délai de 10 ms
entre les trames
• 3 : Deux trames CAN de type CF envoyées avec un décalage de 10ms qui contiennent
le reste des paramètres nécessaires à l’exécution de l’ordre par l’esclave. Le champ
ID de transfert du CAN ID est le même pour tous les fragments du message.
• 4 : La réponse de l’esclave pour informer le maître que la configuration est réussie.
La figure FIGURE 5.12 montre un ordre de configuration envoyé par le maître avec
de faux paramètres. l’esclave répond par la valeur signée 0xFFFFFFFF qui égale à -1 en
décimale pour signaler l’erreur au maître.

Lecture de la valeur d’une entrée d’un esclave


La figure FIGURE 5.13 illustre un ordre envoyé par le maître pour demander la valeur
de la tension de l’entrée numéro 10. l’esclave a répondu par la valeur 0x00002C54 en
hexadécimale qui égale à 11348 mVolt qui est la tension que nous avons appliqué à cette
entrée.
5.2. Réalisation 43

modele_rapport_ensi/images/connect-capture.PNG

Figure 5.10 – Messages CAN d’ordre de connexion


5.2. Réalisation 44

modele_rapport_ensi/images/conf-bonne.PNG

Figure 5.11 – Trames échangées entre le maître et un esclave lors de la configuration


d’une sortie
5.2. Réalisation 45

modele_rapport_ensi/images/conf-fausse.PNG

Figure 5.12 – Ordre de configuration avec des fausses paramètres


5.2. Réalisation 46

modele_rapport_ensi/images/get-val.PNG

Figure 5.13 – Lecture de la valeur d’une entrée d’un esclave

5.2.4 Implementation de tableau de bord


Ce projet a été réalisé du 20 janvier 2020 au 15 juillet 2020. Afin d’organiser le dé-
roulement de ce stage, nous avons établi un chronogramme détaillé des différentes tâches
constituant le projet illustré par la figure FIGURE 5.14.

Conclusion
Dans ce chapitre, nous avons présenter les étapes de la réalisation de notre projet.
En effet, après avoir défini les outils et les technologies utilisés, nous avons décrit les
fonctionnalités de notre projet en présentant des captures écran des différents scénarios
échangés entre le client et le serveur lors d’une démo réelle de l’application. A la fin nous
avons établi le chronogramme qui modélise le déroulement de notre travail.
5.2. Réalisation 47

Figure 5.14 – Le chronogramme de PFE


Conclusion et perspectives

Durant ce stage de fin d’études, nous avons travaillé avec l’équipe de développement
Linux embarqué de la société ACTIA Engineering services (ARDIA), et nous avons beau-
coup appris de cette grande expérience, qui nous a préparé à relever des nouveaux défis
professionnels. L’objectif de ce projet était de Concevoir, Développer et Intégrer une solu-
tion IoT pour la télématique temps réel basée sur le projet iotivity avec client Qt/Qml et
génération de la distribution sous l’environnement yocto pour la cible phytec.
Pour réaliser ce projet, nous avons commencé par une étude approfondi et concise de projet
Yocto, projet IoTivity, la télématique embarqué, l’IoT et son croissance dans le domaine
de l’automobile. A partir de ces études, nous avons pu conclure les fonctionnalités que nous
devons concevoir et implémenter pour satisfaire les besoins de la société ACTIA engineering
services. Partant de la spécification nous avons défini l’architecture de notre application,
et nous avons commencé la conception à travers les différents diagrammes à savoir les
diagrammes d’activité et les machines à état. Le reste du travail consistait à implémenter
l’application et réaliser un montage réelle pour le test et la validation de différent fonction-
nalités.
Durant la période de stage, nous avons eu l’opportunité de mettre en application les diffé-
rentes connaissances acquises durant notre cursus à l’ENSI pour implémenter l’application.
Au lieu d’avoir seulement la position ou le trajet de la véhicule en utilisant le GPS, notre
projet offre une solution plus adéquate qui consiste à collecter toutes les informations né-
cessaires qui nous permettent de consulter le comportement du conducteur et de contrôler
la véhicule à distance. Nous avons réussi à implémenter les fonctionnalités qui permettent
aux clients (QT, Android, web, etc.) de manipuler (lire , modifier) les états des capteurs et
actionneurs des véhicules à travers des requêtes envoyés au serveur. Pour le moment, l’appli-
cation est supporté seulement par l’architecture ARM de la cible phyBOARD-Mira.Imx6.
En conclusion, ce travail a accompli les objectifs, mais notre projet peut être amélioré En
plus, nous pouvons adapter ce projet pour être supporté par d’autres architecture tels que
Mips, PPC, X86-64, etc.

48
Bibliographie

49
Netographie

[URL1] https://www.google.com/search?q=Communication+instrument+
de+bord+et+capteurs&tbm=isch&source=iu&ictx=1&fir=E_
pi1I1TcWiMFM253A252CZ5nQXF3fJAfPHM252C_&vet=1&usg=
AI4_-kQQ_-xXDnWgiR3iEA5nsEGc8SxdDg&sa=X&ved=2ahUKEwi_
0LmUy8vpAhWL3oUKHaieCUAQ9QEwDHoECAoQCQ&cshid=1590292043831260#
imgrc=HA5v5VckKDMN_M , consulté le 10/03/2020.
[URL2] https://fr.wikipedia.org/wiki/Cycle_en_V, consulté le 12/03/2020.
[URL3] https://medium.com/smileinnovation/introduction-à-yocto-db56a550ae51
, consulté le 18/03/2020.
[URL4] https://www.actia.com/fr/presse/actualites/item/
ardia-filiale-du-groupe-actia-specialisee-en-engineering-devient-actia-enginee
consulté le 06/03/2020.
[URL5] https://encrypted-tbn0.gstatic.com/images?q=
tbn3AANd9GcSBCAEIQmB5Z0jzwHLzvEvudM2K2NruVxaawR_xmcjnG3W720Mk&usqp=
CAU , consulté le 10/03/2020.
[URL6] https://www.ionos.fr/digitalguide/sites-internet/developpement-web/
modele-en-cascade/, consulté le 15/03/2020.
[URL7] https://agiliste.fr/introduction-methodes-agiles/, consulté le
15/03/2020.
[URL8] https://encrypted-tbn0.gstatic.com/images?q=
tbn3AANd9GcRuqgxgQe3kjlJ3SgiMlZjWEvdN_WCktfT7b9B4h7FVetV-2e-U&
usqp=CAU, consulté le 18/03/2020.
[URL9] https://www.digora.com/fr/blog/definition-iot-et-strategie-iot ,
consulté le 18/03/2020.
[URL10] https://www.intesens.com/les-benefices-de-liot/ , consulté le
18/03/2020.
[URL11] https://www.linuxfoundation.org/about/ , consulté le 18/03/2020.
[URL12] https://www.yoctoproject.org/docs/2.5/overview-manual/
overview-manual.html , consulté le 18/03/2020.

50