Intégration d’un système de BDTR dans les systèmes d’aide à la conduite 

Télécharger le fichier pdf d’un mémoire de fin d’études

Systèmes de sécurité routière

Les études de l’accidentologie faites par l’Association Prévention Routière (APR) ont montré que la France a enregistré une forte baisse de l’insécurité routière en 2013 par rapport à l’année 2012 : le nombre de tués a diminué de 11% et le nombre de blessés est en baisse de 6,6% [ONISR, janvier 2014]. Ces accidents sont causés par certains facteurs que nous résumons dans les points suivants :
• L’erreur humaine, qui constitue la première cause des accidents. En effet, ce facteur est lié à l’inattention du conducteur, la fatigue, l’inexpérience et le non respect des règles de conduite (e.g., dépassement de la vitesse autorisée et dégradation du contrôle de la trajectoire par le conducteur).
• La perte de contrôle du véhicule, qui est liée généralement à la dynamique du véhi-cule (e.g., freinage inadapté et effet de survirage ou de sous-virage), à l’infrastructure (e.g., chaussées glissantes et présence d’obstacles fixes sur la route) et aux conditions météorologiques (e.g., neige et brouillard).
Les études de l’accidentologie faites par l’APR ont montré que la réduction du nombre d’accidents de la route passe par la conception et le développement des systèmes de sécurité visant à améliorer la sécurité routière et à assurer la sûreté des passagers.
Nous distinguons, d’une part, les systèmes de sécurité passive (e.g., airbag et ceintures de sécurité) qui réduisent les dangers et limitent les conséquences des accidents et, d’autre part, les systèmes de sécurité active (e.g., régulateur de vitesse à contrôle de distance et limiteur de vitesse intelligent) qui servent à éviter les accidents en avertissant le conducteur des dangers (alertes visuelles, sonores ou haptiques) ou en agissant directement sur les commandes du véhicule (freinage automatique, contrôle d’interdistance, etc.).

Systèmes de sécurité passive

Les systèmes de sécurité passive ou secondaire sont destinés à protéger les occupants du véhicule en cas d’accidents et à réduire la gravité des blessures. Les principaux systèmes de sécurité passive sont :
• La ceinture de sécurité, qui permet de maintenir les occupants sur leurs sièges pour limiter leurs mouvements lors d’un choc. En effet, la ceinture de sécurité évite le risque d’éjection du véhicule. Ainsi, elle empêche les occupants de se heurter la tête contre les éléments de l’habitacle tels que le pare-brise, le volant ou le tableau de bord. Lorsque la ceinture est associée à un prétensionneur pyrotechnique 1 [Muller and Linn, 1998] et un limiteur d’efforts 2 [Renault, 2008], elle permet de transférer l’énergie du choc dans les attaches de ceintures pour réduire la force du choc.
• Le coussin gonflable de sécurité (ou airbag) [Evans, 2004], qui permet de protéger l’occupant lors d’une collision. En effet, ce coussin se gonfle rapidement d’air ou de gaz en cas de choc pour éviter que l’occupant ne heurte la tête contre le volant ou que le passager avant ne se projette contre le tableau de bord. Cependant, l’utilisation du coussin gonflable associé à la ceinture assure une sécurité plus efficace [Valeo, 2008].
• L’appui-tête actif (e.g., l’appui-tête actif de Opel [General Motors Corporation, 2008]), qui permet de réduire les risques de blessures cervicales en cas de choc arrière. En cas de ce type de choc, l’appui-tête se déclenche d’une manière mécanique par le mouvement subi par le dos du passager ou du conducteur qui permet à l’appui-tête de s’avancer pour se plaquer à la tête du conducteur ou du passager.
Ces systèmes de sécurité passive protègent les occupants des véhicules contre les chocs forts. Ainsi, ces systèmes rendent les véhicules eux-mêmes moins dangereux en cas d’accidents. Malgré tout ça, l’offre en matière de sécurité routière reste insuffisante vu que certaines règles de conduite ne sont pas toujours adaptées à nos propres limites physiologiques (acuité visuelle, évaluation des distances, perte d’attention, etc.). Pour ces raisons, les constructeurs d’automobiles cherchent à améliorer la sécurité par le développement de nouveaux systèmes de sécurité destinés à éviter les accidents en apportant une assistance au conducteur. De nombreux systèmes de sécurité active ont été développés pour assister le conducteur. Ils sont largement implantés sur les véhicules actuels. Le but de ces systèmes est d’améliorer la contrôlabilité du véhicule et obtenir le meilleur comportement dynamique possible dans toutes les situations, de la plus courante à la plus imprévue.

Systèmes de sécurité active

Les avancées technologiques de ces dernières années tentent de rendre la conduite plus facile en développant des systèmes de sécurité active ou d’aide à la conduite (ADAS 3). Ces systèmes, dit « intelligents », ont pour but de faciliter la maîtrise du véhicule et d’optimiser la tâche de conduite en informant le conducteur, suffisamment à l’avance, des situations de danger. Ces systèmes identifient des situations critiques en se basant sur des fonctions de risques bien définies. Par exemple, le système de régulation de vitesse à contrôle de distance permet de détecter un risque de collision en se basant sur le calcul de l’indicateur temps avant collision (Time To Collision : TTC).
La figure 1.1 montre l’architecture générale d’un système d’aide à la conduite. Ces sys-tèmes sont basés sur la perception de l’environnement par l’intermédiaire de capteurs pro-prioceptifs et extéroceptifs implantés dans le véhicule. Les capteurs proprioceptifs (e.g., cap-teur de vitesse et accéléromètre) permettent d’acquérir des mesures relatives à l’état et la dynamique du véhicule, telles que sa vitesse et son accélération. Par contre, les capteurs extéroceptifs (e.g., radar et caméra), ils permettent de prélever les informations relatives à l’environnement extérieur du véhicule (e.g., les routes et les obstacles). Chaque donnée ac-quise est ensuite transmise à une unité de fusion pour être traitée (e.g., convertir le signal, réduire le bruit et extraire les informations à partir d’une image). Si des capteurs produisent des données redondantes ou complémentaires, ces données sont fusionnées (e.g., par moyenne) par l’unité de fusion pour obtenir une image précise de l’état actuel. Par la suite, les données traitées par l’unité de fusion sont transmises vers le module de décision, qui permet de les trai-ter, d’analyser la situation courante et de choisir les actions en fonction de l’environnement, du comportement du conducteur et de l’état du véhicule. Enfin, ces actions sont envoyées vers le module d’action, qui produit, soit des alertes (visuelles, sonores et/ou haptiques), soit des actions automatiques sur certains organes pour tenter d’éviter ou de limiter les effets de l’accident.
Les systèmes d’aide à la conduite peuvent être classés selon le contrôle en :
• des systèmes de contrôle latéral, permettant de maintenir la trajectoire du véhicule et d’éviter les collisions. Ils permettent la prévention des changements involontaires de voie tels que le système d’alerte de franchissement de ligne et le système d’aide au changement de voie.
• des systèmes de contrôle longitudinal, permettant de réguler la vitesse et maintenir une distance de sécurité entre les véhicules tels que le régulateur de vitesse à contrôle de distance et le système d’alerte pour la prévention de collision avant.
• des systèmes de contrôle mixte, permettant d’assurer le contrôlé longitudinal et le contrôle latéral.
Dans la suite de cette section, nous citons quelques exemples de systèmes d’aide à la conduite existants dans la littérature. Nous présentons quelques systèmes d’aide au guidage longitudinal, et quelques systèmes assurant le contrôle latéral. Enfin, nous citons quelques exemples de systèmes assurant en même temps le guidage longitudinal et latéral.

Système de contrôle longitudinal

Régulateur de vitesse adaptatif
Le régulateur de vitesse adaptatif à contrôle de distance, ou ACC (Adaptive Cruise Control) est un système d’assistance permettant une conduite plus sûre et plus confortable. Le système ACC est conçu pour être utilisé sur des autoroutes et il ne fonctionne qu’à partir de 30 km/h. Il est intégré et testé dans les voitures modernes tels que BMW [Prestl et al., 2000]. ACC s’apparente à un régulateur de vitesse standard, où une vitesse est mémorisée par le conducteur et le système agit sur l’accélérateur pour maintenir cette vitesse. En supplément, il maintient une distance de sécurité entre le véhicule et un autre qui le précède. Ceci est rendu possible grâce à un télémètre embarqué (radar ou laser, selon la marque du véhicule) qui permet de contrôler la scène routière à l’avant du véhicule. En effet, le capteur radar ou laser détecte la présence d’un véhicule sur la même voie et mesure la distance du véhicule qui précède ainsi que sa vitesse. De plus, ACC détermine, à partir de l’accélération latérale et de l’angle au volant, la trajectoire du véhicule.
Si le véhicule détecté roule à une vitesse inférieure à celle du véhicule équipé d’ACC, alors le système décélère automatiquement pour conserver la distance de sécurité prédéterminée et avertit le conducteur par une alerte visuelle et sonore si le conducteur doit intervenir. Dans le cas où la voie est à nouveau libre, le système ré-accélère automatiquement jusqu’à la vitesse programmée par le conducteur.
Système de risque de Collision Avant
Le système d’alerte de risque de collision avant, ou FCW (Frontal Collision Warning) a pour objectif d’éviter les collisions. Son principe de fonctionnement s’appuie sur une surveillance de la route à l’aide de capteurs laser [Biral et al., 2010a] ou de caméras [Raphael et al., 2011], qui sont installés à l’avant du véhicule. Ces capteurs permettent de détecter des obstacles et de déterminer la distance entre le véhicule et ces obstacles. Si le système détecte que le véhicule s’approche trop près de l’obstacle, alors il fournit des alertes au conducteur par le biais d’une interface homme-machine afin que le conducteur réagisse et par conséquent évite la collision.
Système d’alerte de vitesse excessive en virage
Le système d’alerte de vitesse excessive en virage (SAVV ou CSW : Cruve Speed War-ning) [Biral et al., 2010b] consiste à avertir le conducteur lorsque sa vitesse est inadaptée en s’approchant d’un virage. Cela va atténuer le danger de perte de contrôle. Son principe réside dans l’utilisation d’un récepteur GPS, un capteur de vitesse, et un capteur de lacet afin de localiser le véhicule, et des cartes routières numériques préexistantes pour extraire les caractéristiques de la route. En combinant les informations sur la localisation du véhicule et les caractéristiques de la route avec des facteurs externes (i.e., conditions météorologiques et situation du trafic), la vitesse maximale autorisée pour le virage est estimée. Si le véhi-cule franchit la vitesse limite autorisée pour un virage, alors le système avertit le conducteur suffisamment à l’avance pour lui permettre d’adapter sa vitesse avant d’entrer dans le virage.
Saspence
Le sous-projet Saspence (SAfe SPEed and Safe DistaNCE) [Bertolazzi et al., 2010] a été introduit au sein du projet PReVENT 4 (PReVENTive and Active Safety Applications). L’ob-jectif principal de ce sous-projet est de développer un système capable d’aider le conducteur à maintenir la vitesse maximale autorisée et la distance de sécurité selon les conditions de conduite données (i.e., géométrie de la route, situation du trafic et conditions météorologiques). Ce système sert à éviter les risques d’accidents liés à une vitesse excessive et à une distance inappropriée à une situation particulière.
Le module de décision du système consiste à estimer une trajectoire optimale et à calculer une manœuvre de référence (i.e., calculer la vitesse maximale et la distance de sécurité) en se basant sur la fusion des données relatives à l’état du véhicule et à son environnement (géométrie de la route, obstacles, etc.). Si le système de décision détecte une situation critique en comparant la manœuvre de référence avec la manœuvre actuelle, alors il fournit des alertes au conducteur (alertes visuelles, sonores ou vibrations de la pédale d’accélération).

Système de contrôle latéral

SAFELANE
Le sous-projet SAFELANE [Amditis et al., 2010] fait partie du projet européen PReVENT. SAFELANE a pour objectif de développer un système permettant d’assister le conducteur en cas de sortie de voie involontairement. Ce système est principalement prévu pour fonctionner sur autoroutes, routes nationales et départementales et dans des conditions défavorables.
Le système SAFELANE est composé d’un système de capteurs, d’actionneurs et d’un composant de décision. Le développement de SAFELANE est basé sur la fusion des données provenant du système de vision et des cartes digitales afin de donner une image précise de l’environnement. Ces données sont ensuite transmises vers le système de décision adaptatif. Ce dernier permet d’analyser ces données, de détecter la voie et d’estimer la trajectoire la plus probable. Au cas où le système de décision détecte une sortie involontaire de voie, il déclenchera une alerte (sonore ou haptique) ou bien une action active, en contrôlant la direction du volant.
Lateral Safe
Le sous-projet Lateral Safe [Amditis et al., 2008] a été étudié au sein du projet PReVENT. Il a pour but de développer un système d’aide à la conduite permettant d’éviter les situations critiques en latéral. Il consiste à assister le conducteur en élaborant des alertes pour accroître la sécurité et éviter les risques de collisions. Ce système fournit des fonctions basées sur les données issues des radars de gamme courte et longue portée, des caméras et des capteurs proprioceptifs. Ces fonctions analysent la situation et envoient les décisions à l’interface homme-machine (visuelle et sonore) afin d’avertir/d’informer/d’alerter le conducteur de la situation actuelle du trafic, si nécessaire. Ces fonctions sont résumées dans les points suivants :
• une fonction d’avertissement de collision latérale, ou LCW (Lateral Collision Warning), qui avertit le conducteur de la présence d’un obstacle et d’un risque imminent de collision. Cette fonction n’est activée que lorsque la vitesse du véhicule est supérieure à 20 km/h.
• une fonction d’avertissement de collision latérale et arrière, ou LRM (Lateral and Rear Monitoring), qui améliore le perception du conducteur. Elle vise à réduire les risques de collision latérale et en arrière, particulièrement en cas d’une mauvaise visibilité ou d’inattention du conducteur.
• une fonction d’aide au changement de voie, ou LCA (Lane Change Assistant), qui assiste le conducteur en cas de changement de voie.
Système d’alerte de franchissement de lignes
L’avertisseur de sortie de voie, ou LDW (Lane Departure Warning), fournit un contrôle latéral en avertissant le conducteur d’un franchissement involontaire des marquages au sol sans actionner le clignotant [Mobileye, 2007].
Le fonctionnement de ce système se base sur la détection des marquages sur la voie à l’aide d’un capteur vidéo. Ce système fonctionne lorsque le véhicule franchit le marquage sans que le clignotant ne soit activé. Lorsqu’il détecte une sortie de voie involontaire, il avertit le conducteur à l’aide d’une alerte acoustique ou des vibrations (un vibreur situé sous le siège du conducteur, sur le même côté où le franchissement de la ligne a lieu ou une légère torsion au volant).

Système de contrôle longitudinal et latéral

Système d’alerte pour prévenir les sorties de route
Le système d’alerte pour prévenir les sorties de route, ou RDCWS (Road Departure Crash Warning System) a été réalisé dans le cadre du projet RDCW FOT [LeBlanc et al., 2006]. Il sert à fournir une assistance longitudinale en délivrant un avertissement sur la vitesse maximale autorisée à l’approche d’un virage ainsi qu’une assistance latérale, en avertissant le conducteur s’il fait un déplacement latéral excessif.
Ce système est constitué des deux sous-systèmes suivants : (i) le système d’alerte de vitesse excessive en virage, CSW (Curve Speed Warning) et (ii) le système d’alerte d’une dérive latérale, LDWS (Lateral Departure Warning System). Ce dernier fournit une assistance latérale en alertant le conducteur d’une dérive involontaire de la route à cause de l’inattention ou de la fatigue du conducteur.
LDWS utilise les informations issues d’un capteur vidéo et des algorithmes de détection de marquages, en combinaison avec les informations à propos de la dynamique du véhicule (i.e., vitesse et position) pour déterminer la position et l’orientation du véhicule. Cela va permettre de calculer un indicateur de risque qui est le temps de sortie de voie, ou TLC 5 (T LC = DLCv , avec DLC la distance au bord de la voie et v la vitesse du véhicule). Le système délivre une alerte dans le cas où la valeur de TLC est inférieure à une valeur seuil. L’avertissement peut être acoustique ou haptique (i.e., une vibration du siège du conducteur ou une légère torsion sur le volant).
Navigation Aided Intelligent Cruise Control
Le projet NAICC (Navigation Aided Intelligent Cruise Control) consiste à élaborer un système permettant la détection d’une situation critique, relative à une vitesse et/ou à une trajectoire du véhicule, inadaptée à la condition de conduite [Lauffenburger, 2002]. Ce sys-tème a évolué de la manière suivante : (i) dans un premier temps, il a été considéré comme un système d’information du conducteur, permettant d’informer le conducteur de la consigne adéquate à la situation détectée, (ii) puis, il est devenu un système d’assistance active per-mettant de contrôler la vitesse et/ou la trajectoire du véhicule.
NAICC intègre l’assistance longitudinale en régulant la vitesse du véhicule et l’assistance latérale en contrôlant la trajectoire. L’assistance longitudinale sert à calculer la vitesse ap-propriée à la situation de conduite (virage, intersection, etc.) en fonction de la localisation du véhicule sur la route. Par la suite, le système consiste à définir les caractéristiques de l’action de freinage, tels que la distance et le potentiel de freinage. Cette assistance se base principalement sur les informations provenant des cartes digitales, de la localisation du vé-hicule et de la dynamique du véhicule. L’assistance latérale est fondée sur la localisation du véhicule afin d’estimer une référence de trajectoire. Cette référence est déterminée à l’aide de la dynamique du véhicule et de la situation de conduite.

Systèmes de commande tolérants passifs

Un système de commande tolérant passif est basé sur des techniques de contrôle robuste afin d’assurer que le système en boucle fermée est robuste aux incertitudes et à certains défauts connus a priori [Oudghiri, 2008]. Ces défauts sont considérés lors de la conception du système de commande. Par conséquent, cette approche ne demande pas d’informations en ligne sur les défauts [Steffen et al., 2009] et permet de tolérer les défauts sans modifier les paramètres du contrôleur. Ce qui fait que cette approche ne nécessite aucun module de détection de défauts, ni de reconfiguration du système. Mais, l’application de cette approche est limitée en raison de ses inconvénients. En effet, un système de commande tolérant passif possède une capacité limitée de tolérances aux fautes vu qu’il ne considère qu’un nombre restreint de défauts. Il semble donc que l’approche passive soit suffisante dans les applications qui présentent une classe de défauts restreints et connus [Oudghiri, 2008]. En outre, plus le nombre de défauts sera important et leur impact sur le système grave, moins le système de commande tolérant passif sera capable de tolérer ces défauts, ce qui augmente la dégradation du système.
Plusieurs stratégies adaptées à l’approche passive ont été proposées pour tolérer les défauts des capteurs pour les systèmes automobiles. Parmi ces stratégies, on trouve : la technique de l’inégalité matricielle linéaire (LMI : Linear Matrix Inequality) [Tong et al., 2011], la commande robuste H∞ [Varrier et al., 2013] et la commande H2/H∞ [Habibinia et al., 2013].

Systèmes de commande tolérants actifs

L’approche active de commande tolérante aux fautes consiste à réagir à des défauts impré-vus affectant le système en modifiant les lois de commande (i.e., modifier la structure et/ou certains paramètres) de manière à assurer la stabilité du système [Oudghiri, 2008]. Cette approche exige des techniques de détection, d’isolation et d’accommodation de ces défauts (i.e., adaptation des paramètres du régulateur) [Blanke et al., 2001] ou reconfiguration du système (i.e., modification de la structure du système pour compenser les défauts) [Boskovic and Mehra, 2004] ou restructuration (i.e., modification des paramètres du régulateur et de la structure du système) [Staroswiecki and Gehin, 2001]. Le principal mode de fonctionne-ment d’un système de commande tolérant actif s’appuie généralement sur les deux modules suivants :
• Un module de détection et d’isolation de défauts (FDI : Fault Detection and Isolation), qui permet de détecter et de localiser les défauts. De plus, il permet d’estimer les paramètres d’état du système. À l’apparition d’un défaut, le module FDI fournit en ligne au module FTC (Fault Tolerant Control) les informations relatives au défaut détecté (e.g., type de défaut et instant d’apparition) et l’état du système.
• Un module de tolérance aux défauts (FTC : Fault Tolerant Control), basé sur un méca-nisme de reconfiguration (ou d’accommodation ou de restructuration) pour maintenir la stabilité et les performances du système. La reconfiguration (ou l’accommodation ou la restructuration) dépend des informations délivrées par le module FDI.
Plusieurs stratégies, utilisant l’approche active pour les défauts de type capteurs dans les véhicules, ont été développées dans la littérature. Parmi ces stratégies, on peut citer : les réseaux de neurones [Sangha et al., 2012], les filtres (e.g., filtre de kalman et le filtre Luenberger) [Gietelink, 2007] [Tabbache et al., 2013], les observateurs [Abdo et al., 2009] [Viehweider et al., 2012] et la logique floue [Quet and Salman, 2007].

Composants logiciels

Dans [Szyperski, 2002], un composant logiciel est défini comme « une unité de composition présentant des interfaces contractuelles et des dépendances explicites avec son contexte ». Dans [Etienne and Bouzefrane, 2006], un composant logiciel est défini comme : « une entité logicielle de calcul entièrement indépendante, interagissant avec son environnement au moyen d’interfaces bien définies ». Pour qu’un composant soit réutilisé dans plusieurs applications, il est nécessaire qu’il soit interopérable au niveau plate-forme et langage. L’interopérabilité de plates-formes signifie qu’un composant peut communiquer avec d’autres composants présents sur différents types de plates-formes. Quant à l’interopérabilité de langage, elle désigne le fait qu’un composant est indépendant de son langage d’implantation. Ainsi, l’interopérabilité permet d’assurer la compatibilité des logiciels, et par conséquent, leur intégration sera plus facile. De nombreuses technologies supportant les composants logiciels ont été proposées, tels que EJB, CORBA, COM/DCOM/.NET. Les composants logiciels sont appliqués pendant la phase d’implantation d’une application. Ils permettent la réutilisation du code source, mais ils ne permettent pas d’appliquer la réutilisation lors des phases d’analyse des besoins et de conception.

Composants métier

Bien que l’approche à base de composants ait été adoptée en premier lieu dans les activi-tés de programmation, de nouvelles propositions d’unités réutilisables commencent à émerger afin de répondre à des problèmes lors de la phase de recensement des besoins, d’analyse et de conception. Les composants métier s’intègrent dans cette démarche. Un composant métier est défini de plusieurs manières. Une définition donnée par [Barbier, 2002] est la suivante : « A business component models and implements business logic, rules and constraints that are typical, recurrent and comprehensive notions characterizing a domain or business area. Within software engineering, business components are key abstractions that are captured du-ring the domain engineering activity. They are software artefacts in the sense that they are not part of reality but embody and represent recurrent invariants relevant to requirements, particularly at the earliest phases of development ». Une autre définition est donnée dans [Heineman and Councill, 2001] : « A business component is a software component that pro-vides functions in a business domain. (…) for example, an order management application is part of the Enterprise Resource Planning (ERP) business domain ».
On peut donc définir un composant métier comme une unité de réutilisation des connais-sances au sein d’un même domaine d’applications, dès les phases d’analyse et de conception. En effet, il met l’accent sur la représentation, l’implémentation et le déploiement d’un concept de domaine dans un système logiciel. Ce type de composant diffère des composants logiciels par la prise en considération explicite d’un domaine d’applications. Les composants métier sont représentés par des diagrammes UML : diagrammes de classes, diagrammes d’états-transitions, diagrammes d’activités ou diagrammes de composants. Par ailleurs, l’intégration de cette forme de composants logiciels est une tâche difficile. En fait, la collaboration entre composants a souvent été présente en termes syntaxiques tandis que les véritables enjeux sont l’interopérabilité sémantique [Barbier et al., 2002]. En effet, les mécanismes de gestion de conflits sémantiques permettent d’assurer que les concepts échangés par les composants métier ont une signification commune. Ainsi, l’absence de ces mécanismes peut réduire la réutilisation de ces composants.

Frameworks

Un framework 1 est défini dans [Johnson, 1997] comme étant « un modèle réutilisable pour tout ou partie d’un système. Il est représenté par un ensemble de classes abstraites et le moyen avec lequel leurs instances interagissent ». Selon cette définition, on peut déduire qu’un framework est considéré comme une application semi-complète. En effet, il permet de capturer l’architecture d’un ensemble d’applications relatives à un domaine donné, et permet de définir une structure globale de ces applications. Cette structure est exprimée à l’aide d’un ensemble de classes abstraites et coopérantes ; un framework définit des collaborations entre les classes le constituant, contrairement aux bibliothèques de classes. De ce fait, un framework doit s’adapter à toutes les applications du domaine visé par instanciation et/ou spécification des éléments de sa structure globale pour créer une application complète. En effet, la structure et le comportement fournis peuvent être réutilisés sans aucune modification ou les adapter en modifiant et ajoutant des éléments spécifiques à l’application considérée. Par conséquent, l’utilisation du framework consiste à faciliter la réalisation d’une application et à simplifier sa maintenance [Gamma et al., 1995]. En général, les frameworks sont classés en deux catégories :
• Les frameworks de domaine ou frameworks verticaux, qui capturent l’expertise d’un domaine particulier. Ils sont donc dépendants de ce domaine. Il existe plusieurs propo-sitions de frameworks dédiés pour différents domaines d’application : les applications multimédia (e.g., [Ha et al., 2013] [Lopez-Otero et al., 2014]), les bases de données temps réel [Idoudi et al., 2009], l’ingénierie de l’interaction Homme-Machine (e.g., [Bhojan et al., 2014]), etc.
• Les frameworks d’application ou frameworks horizontaux, qui capitalisent les connais-sances d’une large variété d’applications appartenant à différents domaines, tels que les frameworks STRUTS [Goodwill, 2003].
Un framework permet de réutiliser des éléments de conception et du code source car il permet de conserver l’architecture d’une famille d’applications et les modes de collaboration. L’inconvénient majeur d’un framework réside dans le fait qu’il dépend de l’environnement de développement dans lequel il est défini. En outre, un framework est constitué de plusieurs dizaines de classes, ce qui rend sa compréhension difficile.

Modèle de domaine

« Un modèle de domaine exprime des connaissances de haut niveau réutilisables dans le développement de tous les systèmes d’un même champ d’application » [Semmak, 1998]. Selon cette définition, on peut déduire qu’un modèle de domaine présente un espace de référence pour développer toutes les applications appartenant à ce domaine. Il existe plusieurs propositions de modèles de domaine, allant des modèles de domaine orientés objets aux abstractions de domaine issues de l’intelligence artificielle [Nellborn, 1999]. Un modèle de domaine orienté objet sert à décrire les concepts, les liens entre ces concepts et les contraintes d’un domaine spécifique. Il permet également de décrire les similarités et les différences entre les connaissances des systèmes logiciels dans un domaine.
Les modèles de domaine sont applicables pendant les phases amont d’un processus de développement pour représenter les connaissances relatives à l’expression des problèmes d’un domaine particulier. Il présente aussi une base pour créer d’autres composants réutilisables, telles que les architectures à base de composants logiciels [John and Dörr, 2003]. L’utilisation des modèles de domaine est considérée importante dans le cas où la structure et le compor-tement sont soumis à de nombreuses modifications. Cette forme de composant réutilisable permet donc de diminuer le coût total et le temps nécessaire pour effectuer ces modifications.

Patrons

Le terme patron est la traduction du terme anglais « pattern » qui désigne un modèle de génie logiciel à objet et un modèle simplifié d’une structure. Le développement de logiciels par la réutilisation de patrons constitue une nouvelle approche pour capitaliser les expériences des experts et obtenir des logiciels de meilleure qualité. Il a été introduit par Beck et Cun-ningham [Beck and Cunningham, 1987] dans le domaine de l’informatique. Ils ont proposé une adaptation à la programmation orientée objet du langage de patrons, introduit par C. Alexander [Alexander, 1979] dans le domaine de l’architecture des bâtiments.
Un patron est défini par C. Alexander, dans le contexte de l’architecture et de l’urbanisa-tion, ainsi « Chaque patron décrit à la fois un problème qui se produit très fréquemment dans votre environnement et l’architecture de la solution à ce problème de telle façon que vous puissiez utiliser cette solution des millions de fois sans jamais l’adapter deux fois de la même manière ». Il définit également le patron comme « une règle en trois parties, exprimant une relation entre un contexte, un problème et une solution ».
De manière générale, un patron est défini comme une solution aux problèmes récurrents dans un contexte [Schmidt et al., 1996] :
• Contexte : se réfère à un ensemble de situations récurrentes.
• Problème : définit un but à atteindre.
• Solution : permet de résoudre un problème en l’adaptant à un contexte particulier. Les patrons permettent de bénéficier des avantages de la réutilisation pour toute les étapes d’ingénierie des systèmes d’information dès les phases d’analyse et de conception [Rieu et al., 1999b].
Les patrons jouent un rôle d’aide à l’analyse et à la conception, en offrant des solutions éprouvées aux problèmes de modélisation rencontrés. De plus, ils permettent de présenter les systèmes d’une manière simple, en masquant les détails non nécessaires. Ainsi, les pa-trons offrent un vocabulaire commun aux concepteurs dans le but d’assurer une meilleure compréhension.
Dans le paragraphe suivant, nous allons comparer les différents composants présentés dans ce paragraphe afin de cerner le composant le mieux adapté à l’ingénierie des systèmes d’aide à la conduite.

Patrons d’ingénierie

Comparaison entre les composants réutilisables

Plusieurs critères permettent de comparer les différents composants réutilisables (e.g., [Cauvet et al., 2001]). Dans cette thèse, nous retenons les quatre critères présentés dans [Rieu, 1999] : couverture, portée, granularité et techniques d’implantation.
• Couverture. La couverture représente le degré de généralité des composants. Ces der-niers peuvent être généraux, dans le cas où le problème traité est fréquent dans de nombreux domaines d’applications, ou spécifiques, si le problème traité est spécifique à un domaine particulier. Les frameworks, les composants métier et les composants lo-giciels peuvent encapsuler les connaissances relatives à un domaine particulier, comme ils peuvent être destinés à différents domaines. Les patrons peuvent être utilisés dans n’importe quel domaine (patrons généraux [Gamma et al., 1995]), mais peuvent égale-ment être appliqués à un domaine particulier (patrons temps réel (e.g., [Rekhis et al., 2010b] [Marouane et al., 2010]). Cependant, les modèles de domaine sont dédiés à un domaine spécifique [Barbier et al., 2004].
• Portée. La portée d’un composant réutilisable est évaluée en fonction de l’étape de l’in-génierie (analyse, conception, implémentation) à laquelle il s’adresse. Les frameworks peuvent être utilisés pendant les étapes d’analyse ou durant la conception architectu-rale des systèmes. Les patrons sont réutilisables lors des phases d’analyse, de concep-tion et d’implantation. De même, les composants métier s’orientent vers ces phases en amont du développement des systèmes d’information [Barbier, 2002]. Quant aux composants logiciels, ils sont dédiés à la phase d’implantation.
• Granularité. Elle mesure le plus souvent le nombre d’entités (e.g., classes et modules) constituant un composant. Elle permet d’identifier le degré de complexité de l’archi-tecture que ce composant propose. Elle peut être faible (nombre d’entités inférieur à 10), moyenne (nombre d’entités inférieur à 100) ou forte (nombre d’entités supérieur à 100). Les patrons offrent des diagrammes constitués d’un nombre limité d’objets ou de classes vu qu’ils présentent des solutions à des problèmes restreints. Par exemple, les patrons d’analyse de Coad [Coad et al., 1996], ou ceux de conception proposés dans [Gamma et al., 1995], proposent des diagrammes de deux à six classes. De même, les modèles de domaine sont des structures de faible granularité comme les patrons. Quant aux composants métier et les composants logiciels, ils peuvent avoir une gra-nularité allant de quelques classes à quelques dizaines. Au contraire, la majorité des frameworks offrent des architectures constituées d’une grande variété de classes, ce qui les rend trop rigides et très difficiles à réutiliser.
Les patrons fournissent des unités légères et très modulaires. De ce point de vue, la réutilisation des patrons présente un avantage par rapport aux autres types de composants.

Table des matières

Introduction générale
I Étude de l’existant et contexte 
1 Systèmes d’aide à la conduite
1.1 Introduction
1.2 Systèmes de sécurité routière
1.2.1 Systèmes de sécurité passive
1.2.2 Systèmes de sécurité active
1.3 Caractéristiques des systèmes d’aide à la conduite
1.3.1 Contraintes temps réel
1.3.2 Imprécision
1.3.3 Fiabilité
1.3.4 Sécurité
1.3.5 Tolérance aux fautes
1.4 Méthodes pour la tolérance aux fautes
1.4.1 Redondance matérielle
1.4.2 Redondance logicielle
1.4.3 Synthèse
1.5 Conclusion
2 Réutilisation et patrons d’ingénierie
2.1 Introduction
2.2 Réutilisation
2.2.1 Définition
2.2.2 Processus de réutilisation
2.2.3 Composants réutilisables
2.3 Patrons d’ingénierie
2.3.1 Comparaison entre les composants réutilisables
2.3.2 Différents types de patrons
2.4 Patrons de conception
2.4.1 Formalismes de description des patrons
2.4.2 Profils UML pour les patrons de conception
2.4.3 Synthèse
2.5 Patrons de conception temps réel
2.5.1 Patrons de conception définis par Rekhis et al
2.5.2 Patrons de conception définis par Alho et al
2.5.3 Patrons de conception définis par Sarika et al
2.5.4 Patrons de conception définis par Gerdes et al
2.5.5 Synthèse
2.6 Conclusion
II Contribution
3 Intégration d’un système de BDTR dans les systèmes d’aide à la conduite
3.1 Introduction
3.2 Systèmes de bases de données temps réel
3.2.1 Caractéristiques des données TR
3.2.2 Caractéristiques des transactions TR
3.2.3 Synthèse
3.3 Intégration d’un système de BDTR dans les systèmes d’aide à la conduite
3.3.1 Nouvelle architecture des systèmes d’aide à la conduite
3.3.2 Modèle du système de BDTR
3.3.3 Estimateurs des données manquantes
3.4 Validation de l’intégration d’un système de BDTR dans les systèmes d’aide à la conduite
3.4.1 Système SQLite3
3.4.2 Simulateur PreScan
3.4.3 Résultats et discussion
3.5 Conclusion
4 Profil UML pour les patrons de conception temps réel
4.1 Introduction
4.2 Langage de modélisation UML
4.3 Profil UML
4.4 Profil UML-RTDB2
4.4.1 Extensions pour la spécification des patrons de conception TR
4.4.2 Extensions pour l’instanciation des patrons de conception TR
4.5 Définition des contraintes OCL
4.6 Conclusion
5 Patrons de conception pour les systèmes d’aide à la conduite
5.1 Introduction
5.2 Description des systèmes d’aide à la conduite
5.2.1 Système de régulateur de vitesse à contrôle de distance
5.2.2 Système d’avertissement de sortie involontaire de voie
5.2.3 Système SAFERIDER
5.3 Modélisation des patrons de conception
5.3.1 Processus de création de patrons de conception
5.3.2 Construction du patron « Acquisition des données »
5.3.3 Construction du patron « Contrôle de données »
5.3.4 Construction du patron « Action »
5.4 Conclusion
6 Réutilisation des patrons de conception
6.1 Introduction
6.2 Processus de réutilisation
6.2.1 Choix des variantes à sélectionner
6.2.2 Adaptation du modèle réduit du patron
6.2.3 Exemple de réutilisation de patrons
6.3 Mise en œuvre des patrons de conception proposés
6.3.1 Eclipse
6.3.2 Présentation de l’outil ADAS-Patterns
6.4 Conclusion
7 Évaluation des patrons de conception proposés
7.1 Introduction
7.2 Métriques d’évaluation
7.2.1 Métriques de réutilisabilité
7.2.2 Métriques de réutilisation
7.3 Évaluation des patrons de conception
7.3.1 Évaluation du patron « Acquisition des données »
7.3.2 Évaluation du patron « Contrôle de données »
7.3.3 Évaluation du patron « Action »
7.4 Conclusion
Conclusion générale 
Publications 
Références 
Annexe A Relations linguistiques et règles d’unification
Annexe B Modélisation des applications d’aide à la conduite

Télécharger le rapport complet