I – Introduction

1Différents types de Véhicules Industriels (vi) circulent plus ou moins régulièrement en ville, de la benne à ordures ménagères au camion toupie en passant par les camions de déménagement ou les citernes. La majorité d’entre eux sont des camions effectuant une activité de distribution, c’est-à-dire de livraison de produits variés ou de messagerie. Ces véhicules sont généralement des porteurs d’un poids total en charge (ptac) compris entre 3,5 t et 18 t, dont l’encombrement permet de circuler plus facilement en milieu urbain. Les conducteurs de ces véhicules sont des professionnels qui possèdent un permis de conduire spécifique (de catégories C et EC). S’il est vrai que, dans le secteur du Transport Routier de Marchandises (trm) longue distance (national et international), une grande partie du temps de travail des conducteurs est consacrée à la conduite du véhicule (Revah, 2001), il n’en va pas de même dans le secteur de la distribution en ville (Cholez, 2001). Des analyses de l’activité de ces conducteurs ont montré que les phases de conduite ne représentent que 31 % du temps de travail des chauffeurs livreurs (Maincent, 2010).

2Cependant, la conduite du véhicule, même si elle reste centrale quant aux objectifs premiers du transport routier de marchandises – transporter la marchandise d’un point à un autre –, n’est qu’une des multiples composantes du métier de chauffeur-livreur. Celui-ci doit, non seulement être un conducteur expérimenté, c’est-à-dire piloter le véhicule dont il a la responsabilité dans les meilleures conditions de sécurité et dans le respect des règles de circulation, mais il doit aussi effectuer la livraison, en parfait état, et dans les délais fixés, des marchandises qui lui sont confiées. Il doit donc assurer le déchargement du véhicule et la manutention de la marchandise jusqu’à la porte du client.

3En milieu urbain, plusieurs facteurs environnementaux font de la conduite d’un vi une activité complexe. L’existence de zones « aveugles » complique l’exploration visuelle de l’environnement proche du véhicule et engendre des difficultés perceptives. Elles ont pour résultat un traitement de l’information parcellaire pouvant, dans certains cas, s’avérer insuffisant. De plus, la pression temporelle constante, liée aux impératifs de livraison, à laquelle s’ajoutent les comportements à risque des usagers vulnérables (piétons qui traversent à l’improviste devant le vi en mouvement, deux-roues qui se faufilent le long du véhicule tournant à droite, etc.) induisent, chez le chauffeur-livreur, un stress non négligeable (Maincent, Brun & Martin, 2008 a). Les conducteurs sont ainsi soumis à une importante charge de travail physique et cognitive (Van Elslande, 2003). Celle-ci peut avoir, à plus ou moins long terme, des répercussions négatives, tant sur un plan individuel en termes d’attention, de comportements de conduite, de santé, que sur un plan collectif en termes d’impact sur la sécurité routière.

4À cet égard, les études statistiques en sécurité routière montrent, d’une part, que les piétons et les deux roues sont les usagers les plus fréquemment tués en milieu urbain (66,9 % des tués selon Chapelon & Lagache, 2008) et, d’autre part, que la majorité des accidents impliquant un usager vulnérable et un poids lourd ont des conséquences mortelles pour l’usager vulnérable.

5Par ailleurs, les résultats d’une enquête effectuée auprès de 400 usagers vulnérables montrent que, bien que ceux-ci aient une représentation correcte du danger et de la prise de risque associés à certains comportements face aux camions en milieu urbain, la moitié d’entre eux reconnaissent adopter des comportements identiques en termes de risque quand ils se présentent (Maincent, Brun & Martin, 2008 b). De plus, certains secteurs urbains, notamment les secteurs piétonniers, représentent des environnements protégés pour les usagers vulnérables. Or, bien qu’en principe réservés aux piétons et par extension aux usagers vulnérables (hors motocyclistes), à certains moments, ces secteurs doivent être partagés avec les véhicules qui effectuent des livraisons. Compte tenu du caractère prioritaire des usagers vulnérables, les conducteurs devront donc redoubler d’attention vis-à-vis de ceux-ci. Il semble donc que, quel que soit le secteur abordé, le conducteur d’un vi est le seul garant de la sécurité des usagers vulnérables.

6Dans ce contexte, le développement de systèmes d’assistance pour la détection des usagers autour du véhicule lors de manœuvres basse vitesse se révèle d’un intérêt indéniable. En revanche, dans un contexte économique défavorable, le choix de solutions bas coût est devenu une nécessité absolue pour la diffusion de technologies innovantes. Le développement concret de tels systèmes nécessite la réalisation d’études exploratoires précisant leur pertinence et leur faisabilité. Le projet VIVRE2 s’inscrit dans ce contexte puisqu’il a pour objectif de mettre au point, sur un simulateur de conduite de poids lourd, un système d’assistance à la détection des usagers vulnérables intégrant les contraintes de coûts.

7Cet article a pour objet de présenter la démarche entreprise au cours du projet VIVRE2 pour mettre en œuvre la conception, le développement et l’évaluation d’un système d’aide destiné aux conducteurs de vi en milieu urbain pour détecter les Usagers Vulnérables (uv). Deux modes d’intervention sont envisagés : le système est informatif et indique au conducteur la position d’uv à proximité du véhicule ou bien, lorsque la situation devient critique, le système devient actif et prend le contrôle du véhicule. La méthodologie proposée s’inspire de l’approche User Centred Design (Maguire, 2001), et tente de pallier les contraintes de développement de ce type de systèmes actifs, nécessitant notamment la réalisation d’analyses de l’activité en milieu naturel. L’application sur simulateur de conduite de cette démarche pour la conception d’un système de détection des usagers vulnérables pour les véhicules industriels devra permettre à l’ensemble des partenaires de proposer une solution technique réaliste et bien acceptée par les utilisateurs finaux.

II – Démarche de conception

8L’équipe de recherche du projet VIVRE2 a adopté une démarche systémique pluridisciplinaire de type User Centred Design (ucd), prenant en compte la problématique de la sécurité des uv dans sa globalité, c’est-à-dire en intégrant les facteurs contextuels, humains et technologiques. Ce type d’approche, classique en ergonomie, est fondé sur la notion d’acceptabilité (Dubois & Bobillier-Chaumon, 2009) et plus précisément celle d’utilisabilité (Nielsen, 1993 ; Barcenilla & Bastien, 2009), telle qu’elle a été définie par Fisher (2001, p. 65) : « to make systems more usable, more useful, and to provide users with experiences fitting their specific background knowledge and objectives ».

9Traditionnellement, les modèles de conception sont basés sur le modèle de développement en V qui a été enrichi par Kolski et Ezzedine (2003) en incluant deux étapes d’évaluation ergonomique pour les phases de spécification et de conception. La démarche itérative, telle qu’elle a été préconisée par Gould & Lewis (1985) et Popovic (1999), y a inclus la notion de spécifications évolutives permettant d’intégrer les résultats issus des analyses de l’activité au fur et à mesure des développements. Un certain consensus concernant la démarche ucd a été atteint avec la création de la norme iso 13407 (Maguire, 2001) (Figure 1). Toutefois, même si une démarche de conception itérative est essentielle, il n’est pas toujours possible de la mettre en œuvre faute de temps ou de crédits.

Figure 1

Processus de conception centrée sur l’humain (d’après iso 13407)

Human centred design process (from iso 13407)

Processus de conception centrée sur l’humain (d’après iso 13407)

Human centred design process (from iso 13407)

10Le travail préliminaire du projet VIVRE2 a consisté à mettre en place une démarche de conception ucd du système d’assistance (Figure 2) en intégrant, d’une part, les contraintes de développement pluridisciplinaire, et d’autre part, les délais nécessaires pour réaliser les analyses ergonomiques indispensables à la définition des besoins réels des utilisateurs. Pour cela, l’ensemble des phases, des outils de conception et des analyses nécessaires ont été définis dès le début du projet afin de minimiser l’occupation du simulateur de conduite et de permettre différentes boucles itératives de développement du système, intégrant les résultats des analyses au fur et à mesure de leur disponibilité.

11Traditionnellement, la démarche ucd prévoit la réalisation itérative d’analyses des contextes d’utilisation, à chaque nouvelle évolution du système. Ici, une seule analyse de l’activité des conducteurs a été réalisée sans système d’assistance. Compte tenu de ses délais de réalisation, il était impossible d’attendre son achèvement pour démarrer le premier cycle de développement. Les résultats ont donc été intégrés au fur et à mesure de leur disponibilité, pour définir des spécifications fonctionnelles de l’assistance de plus en plus précises. En début de projet, celles-ci étaient sommaires (type d’usagers à détecter, type d’information et de contrôle délivrés par l’assistance). Elles se sont raffinées pour, au final, devenir des scénarios d’utilisation du système incluant la description séquentielle des interactions système/conducteur.

Figure 2

Processus de conception centrée sur l’homme utilisé dans le cadre de VIVRE2

New process for human-centred design used in VIVRE2

Processus de conception centrée sur l’homme utilisé dans le cadre de VIVRE2

New process for human-centred design used in VIVRE2

12La Figure 2 représente l’ensemble de la démarche mise au point pour concevoir et développer le système d’assistance VIVRE2. Cette démarche comporte différents cycles itératifs :

• le cycle de définition (cycle D) : il permet d’intégrer les spécifications évolutives émanant des raffinements de l’analyse des contextes, tout en intégrant les contraintes techniques rencontrées dans les étapes de développement ;
• les cycles de validation (cycles V) : le cycle V1 permet de tester la cohérence du fonctionnement de l’assistance sur l’ensemble des cas d’utilisation, le cycle V2 permet de valider le fonctionnement de l’assistance avec la plate-forme sur des données réelles et le cycle V3 permet de valider les choix d’implémentation, les conséquences des contrôles actifs, et de recueillir des données sur simulateur.

III – Outils de la méthodologie de conception

13La mise en œuvre des cycles décrits précédemment a nécessité le développement de deux outils spécifiques :

• une Plate-forme d’Intégration pour limiter les temps d’intégration des différentes versions du système ainsi que le coût d’immobilisation du simulateur de conduite ;
• un Générateur de Scénarios Dynamiques (gsd) afin d’assurer un fonctionnement cohérent de l’assistance sur l’ensemble des cas d’utilisation.

III.1 – La plate-forme d’intégration

Figure 3

Diagramme fonctionnel de la plate-forme d’intégration

Functional diagram of integration platform

Diagramme fonctionnel de la plate-forme d’intégration

Functional diagram of integration platform

14L’objectif premier de cette plate-forme est d’alimenter le système VIVRE2 avec les actions du conducteur, ainsi qu’avec les objets de l’environnement du simulateur de conduite, puis de renvoyer à ce dernier les décisions prises par le système (génération d’alarmes ou contrôle du véhicule). Cette plate-forme doit également permettre des développements informatiques de l’assistance de façon autonome, c’est-à-dire indépendamment du simulateur.

15Quatre fonctions ont été définies (Figure 3). Deux de ces fonctions concernent les modes de communication des données : la fonction « temps réel » qui récupère les objets de l’environnement directement du simulateur et la fonction « rejeu », qui récupère les objets de l’environnement dans une base de données. Une troisième fonction, la fonction « recueil », permet l’alimentation de cette base. La dernière fonction « simulation assistance » contient l’ensemble des algorithmes de simulation des capteurs et de calcul des décisions de l’assistance.

16L’intérêt de cette plate-forme est de dissocier les problèmes de communication entre le simulateur et l’assistance, des problèmes liés au développement de cette dernière. Elle permet, de plus, de résoudre certains problèmes techniques en tout début de projet, sans attendre le stade de l’intégration du système pour l’expérimentation finale (Mathern, Bonnard & Tattegrain, 2009). Cette approche a permis, en outre, d’identifier très en amont les données réellement utilisables par le système d’assistance. Au final, l’équipe de développement du simulateur a pu faire évoluer ce dernier en fonction des besoins de l’évaluation finale, tandis que l’équipe de développement de l’assistance a pu tester les spécifications évolutives des besoins des utilisateurs, au fur et à mesure, sans dépendre de la disponibilité du simulateur. Des tests récurrents avec la plate-forme et le simulateur ont permis la validation des différentes versions du système. Les évaluations intermédiaires sur simulateur se sont avérées indispensables pour ajuster les réglages fins de l’assistance en fonction du ressenti réel du conducteur et pour tester les conséquences réelles des contrôles actifs.

17La mise en place de cette méthodologie a été coûteuse en début de projet et a demandé un certain nombre de développements supplémentaires, mais l’expérience a montré qu’elle permettait des cycles itératifs de développement/test ainsi que la prise en compte précoce d’un certain nombre de problèmes techniques.

III.2 – Le générateur de scénarios dynamiques

18Le Générateur de Scénarios Dynamiques (gsd) permet de tester le fonctionnement du système VIVRE2 sur l’ensemble des situations, en laboratoire, c’est-à-dire sans recours au simulateur de conduite. Il est donc nécessaire de pouvoir lui fournir toutes les données correspondant à chacune des situations. Concevoir une assistance nécessite, en outre, une vue dynamique de la situation dans laquelle le système va intervenir. Une approche basée exclusivement sur des scénarios ne permet pas de définir précisément à quel moment l’assistance doit se déclencher, ni quels sont les critères de décision et les valeurs de ces critères. La complexité des contextes de conduite et leur évolution temporelle sont difficilement appréhendables sans un outil qui puisse mettre en scène, d’une part, l’ensemble des usagers de la route pouvant interagir dans ces situations et, d’autre part, les effets de l’assistance sur le déroulement d’un scénario (Tattegrain, Bonnard & Mathern, 2009). Le gsd va tenter de pallier ces difficultés.

19Le gsd comporte un module spécifique de l’application en cours de développement, ainsi qu’un ensemble de différents modules génériques (Figure 4) permettant le paramétrage et le déroulement temporel de scénarios. Ces modules génériques pourraient être réutilisés pour concevoir une autre assistance active.

Figure 4

Diagramme fonctionnel du Générateur de Situation Dynamique

Functional diagram for Dynamic Use Case Generator

Diagramme fonctionnel du Générateur de Situation Dynamique

Functional diagram for Dynamic Use Case Generator

20Le gsd permet de créer les différents scénarios en modifiant les caractéristiques d’un scénario (nombre d’usagers vulnérables avec des positions et des vitesses différentes, vitesse et position du vi) ou le comportement du conducteur (temps de réaction aux différentes alertes, vitesse et accélération désirées par défaut). Le fonctionnement de l’assistance peut, quant à lui, être paramétré en modifiant la taille des zones de détection ou les caractéristiques du véhicule (encombrement du vi, accélération et freinage maximum). Le déroulement dynamique des scénarios est géré par un processus itératif entre la mise à jour des paramètres dynamiques (vitesse et position du vi) et la simulation des déplacements (du véhicule et des usagers vulnérables). Enfin, le gsd permet l’affichage en temps réel de la situation (visualisation du vi, des usagers vulnérables…) ainsi que des courbes qui décrivent le déroulement du scénario (vitesse et accélération, état de l’assistance).

21Cet outil permet ainsi de tester un système actif utilisant des décisions prises par l’assistance pour mettre à jour des paramètres dynamiques. Il tient compte également des différents comportements possibles du conducteur, susceptibles d’influencer le déroulement temporel d’un scénario. Au final, la possibilité de pouvoir jouer l’ensemble des scénarios prévus permet de valider la cohérence du fonctionnement d’UN système dans PLUSIEURS situations.

IV – Application de la méthode

IV.2 – Spécification de l’assistance

25Le système VIVRE2 a été conçu pour assister les conducteurs de vi en milieu urbain et à basse vitesse dans des situations potentiellement accidentogènes impliquant des usagers vulnérables, piétons et cyclistes. Afin de réaliser leur implémentation sur le simulateur conduite, ces situations critiques ont été définies à partir de plusieurs sources d’information, dont les résultats de l’enquête auprès des usagers vulnérables (Maincent, Brun & Martin, 2008 b), les analyses de l’activité des chauffeurs-livreurs (Maincent, op. cit.) et différents rapports d’accidentologie (ceesar, base de données VOLVO 3P, rapports onisr).

26Les situations retenues se veulent représentatives des accidents statistiquement les plus fréquents ainsi que des situations auxquelles sont quotidiennement confrontés les conducteurs de vi et qu’ils décrivent comme particulièrement stressantes. C’est le cas, notamment, des situations de manœuvre en marche arrière, pour lesquelles les conducteurs rencontrés ont clairement exprimé le besoin d’avoir une assistance (vision et détection des usagers). Il en va de même pour les situations de traversée inopinée d’un piéton entre deux voitures en stationnement dont les occurrences d’apparition sont fréquentes au cours d’une tournée de distribution. Enfin, la situation de tourne à droite avec un cycliste dans l’angle mort droit du vi a été retenue, du fait de la recrudescence de ce type d’accidents dans les grandes villes, notamment depuis la mise en service du « vélo en libre-service » (Maincent, op. cit.).

Tableau 1

Description des situations critiques retenues pour l’évaluation du système

Critical situation description for system assessment

Description des situations critiques retenues pour l’évaluation du système

Critical situation description for system assessment

27Au total, six situations critiques ont été identifiées (Tableau 1) : deux situations de marche arrière (en mouvement et au démarrage), deux situations de marche avant (en mouvement et au démarrage), une situation de tourne à droite après un démarrage sur feu tricolore et une situation de dépassement d’un usager sur la chaussée (piéton ou cycliste) dans le même sens de circulation. L’ensemble de ces situations a été mis en scène sur trois parcours expérimentaux différents pour l’évaluation ergonomique et fonctionnelle des systèmes sur le simulateur de conduite de Renault Trucks.

28Concrètement, le système développé dans le projet VIVRE2 comporte deux modes d’assistance définis selon le niveau d’interaction du système avec le conducteur : un mode que l’on peut qualifier de « passif » ou « informatif » : le système délivre des informations et des alarmes, sans agir sur le pilotage ; et un mode dit « actif » ou « automatisé » qui tient compte des comportements et intentions du conducteur : le système prend temporairement en charge le pilotage du véhicule.

29D’un point de vue fonctionnel, le mode « informatif » est basé sur la détection des usagers vulnérables par les différents capteurs, en fonction des situations rencontrées. Ce mode envoie au conducteur une information sous forme d’alarmes lumineuses (une action engagée par le conducteur pourrait s’avérer dangereuse) ou sonores (une manœuvre dangereuse est initiée par le conducteur).

30Le mode « actif » comprend trois niveaux d’action (limiteur de vitesse, freinage d’urgence et antidémarrage) dont l’enclenchement diffère selon deux niveaux de criticité de la situation :

• la situation est critique quand la trajectoire de l’usager vulnérable est en direction du vi et proche de ce dernier : seule la vitesse est limitée par le système ;
• la situation est très critique quand la trajectoire de l’usager vulnérable croise celle du vi. Dans ce cas, le système prend le contrôle du vi (freinage d’urgence ou antidémarrage).

L’ihm du système VIVRE2 est une interface multimodale qui comprend des composants visuels et des composants sonores. L’ensemble de ces composants est piloté par le système VIVRE2 et organisé en fonction des stratégies d’assistance déterminées.

31Trois zones spatiales ont été définies autour du véhicule : à l’arrière, à l’avant et sur le côté droit. L’ihm du système VIVRE2 (Figure 5) a donc été scindée en trois composants visuels distincts comportant chacun un retour sur écran (arrière et latéral) ou par miroir (antéviseur avant).

Figure 5

Interfaces Visuelles pour les zones arrière, avant et latérales

Visual interfaces for back, front-on and lateral zones

Interfaces Visuelles pour les zones arrière, avant et latérales

Visual interfaces for back, front-on and lateral zones

32Les diodes lumineuses sont des interfaces intuitives utilisées pour orienter le regard du conducteur dans une direction donnée. Ce dernier peut ainsi vérifier la présence d’un obstacle dans cette direction. Ces diodes sont complétées par une interface visuelle qui se compose de plusieurs pictogrammes d’information intégrés au cluster d’affichage du tableau de bord. Ces pictogrammes ne servent pas d’alarme, mais apportent des précisions au conducteur : ils signalent la zone dans laquelle un usager vulnérable est détecté, précisent le mode d’assistance activé (antidémarrage, freinage d’urgence, limiteur) et indiquent dans quel mode fonctionnement se trouve le système (actif ou informatif).

IV.3 – Développement de l’assistance

33L’architecture du système a été développée en utilisant une approche de type « technologie adaptative », c’est-à-dire qui adapte le fonctionnement du système en tenant compte du comportement du conducteur dans une situation donnée (Bellet, Tattegrain-Veste & Bonnard, 2005). Pour cela, un modèle d’intention du conducteur a été implémenté. Ce modèle est utilisé par le système d’assistance comme n’importe quelle entrée au même titre que les données de perception de l’environnement extérieur (Tattegrain & Bonnard 2010).

IV.3.1 – Architecture de l’assistance

34Le système sélectionne le type d’assistance à l’aide des deux sources d’informations disponibles : les informations sur la position d’éventuels usagers vulnérables (devant, derrière ou sur le côté droit du vi) et les informations sur les actions du conducteur (Figure 6). Ces informations sont ensuite confrontées à un modèle des intentions du conducteur, afin de déterminer la stratégie d’assistance adaptée, puis de piloter l’ihm.

Figure 6

Architecture de l’assistance

Assistance Architecture

Architecture de l’assistance

Assistance Architecture

IV.3.2 – Principes de détection

35Le système VIVRE2 a pour principe de s’activer en présence d’usager(s) vulnérable(s). Son action sera différente selon la proximité de ces usagers vulnérables. Trois familles de zones de décision ont donc été définies (Figure 7) :

• la zone centrale ou zone de « Freinage d’urgence » (ZoneF) gère les situations très critiques. Lorsqu’un usager vulnérable se situe dans cette zone, la prise de contrôle du véhicule par un freinage d’urgence est enclenchée automatiquement par le système ;
• la zone de « Warning » (ZoneW) correspond aux situations dans lesquelles un usager est en danger si le conducteur ne réagit pas assez rapidement. Dans ce cas, une alerte intrusive (visuelle et sonore) est donnée au conducteur pour lui faire prendre conscience du danger. S’il ne réagit pas, le « freinage d’urgence » pourra être activé ;
• le troisième type de zone n’est que potentiellement critique, c’est une « Zone d’information » (ZoneL), pour laquelle une indication de danger non intrusive (visuelle) est donnée au conducteur tandis que la vitesse du véhicule est limitée afin de conserver un temps à la collision minimum de 2s.

Figure 7

Zones de décision du fonctionnement de l’assistance

Decision zones for assistance functioning

Zones de décision du fonctionnement de l’assistance

Decision zones for assistance functioning

IV.3.3 – Modèle d’intention du conducteur

36La typologie du modèle d’intention du conducteur est guidée par les différents comportements attendus du système selon le type de scénarios à couvrir : démarrages et roulages basse vitesse « avant » et « arrière », et « tourne à droite ».

37La phase de démarrage du vi est notamment très détaillée, car les informations données au conducteur peuvent être différentes. Par exemple, si un usager vulnérable est à quelques mètres du véhicule, en zone de « warning », le chauffeur ne sera pas alerté tant qu’il n’aura pas démarré. S’il démarre le moteur, une indication visuelle de la présence de cet usager (niveau informatif 1) sera envoyée, elle sera complétée par une alarme sonore dès la mise en mouvement du véhicule (niveau informatif 2).

Figure 8

Modèle d’intention du conducteur

Driver intention model

Modèle d’intention du conducteur

Driver intention model

38Le modèle comporte ainsi trois niveaux de phases d’action du conducteur (sélection du sens de la manœuvre, démarrage et roulage) pouvant être mises en œuvre dans chacune des trois situations. Neuf états combinent donc les deux critères (situation à couvrir et phases d’activité du conducteur) et le dernier correspond à « arrêt » (véhicule arrêté et aucune action du conducteur), comme représenté en Figure 8.

39L’avantage de ce type de modèle est double. Premièrement, il prend en compte les intentions du conducteur qui sont inférées à partir de son comportement en temps réel (par exemple, lorsque le conducteur passe la marche arrière et que la vitesse est inférieure à un seuil donné et que l’accélérateur est dans une position supérieure à un seuil donné, l’intention est « sélection arrière »). Cette démarche nécessite de définir les différents états du conducteur puis de rechercher les mesures objectives qui pourraient les différencier. Deuxièmement, ce modèle apporte une sémantique de l’activité compréhensible quelle que soit la discipline : les ergonomes pourront valider le fonctionnement des ihm selon les états du conducteur et les technologues pourront travailler sur les algorithmes permettant de les identifier. Tout changement de technologie sur le vi (par exemple, un changement du type de boîte de vitesse) n’affectera que ce deuxième versant.

IV.3.4 – Sélection de l’aide adaptée

Tableau 2

Extrait d’une table de décision

Excerpt from the decision table

Extrait d’une table de décision

Excerpt from the decision table

40La partition spatiale définie autour du vi en termes de zones de détection et la catégorisation de l’activité du conducteur définie en dix états permettent d’obtenir un nombre fini d’états possibles des entrées. Deux tables de décision (l’une pour le fonctionnement informatif et l’autre pour le fonctionnement actif) à deux dimensions (activité, zone de décision) indiquent, pour chaque combinaison, le niveau d’assistance fournie : pas d’assistance (pasAss), une information non intrusive (Inf), une alarme (W) ou une assistance active (Fu freinage d’urgence, Si antidémarrage).

41Ces tables permettent également d’appréhender les évolutions des situations en tenant compte de l’évolution de la manœuvre du fait du comportement du conducteur (décision de démarrer, démarrage, roulage) ou l’évolution du déplacement d’un usager vulnérable.

42Quand il y a présence d’un uv dans la zone avant proche (Tableau 2), l’information donnée évolue d’une absence d’assistance vers une assistance informative peu intrusive puis vers une assistance informative plus forte au fur et à mesure de la progression de la manœuvre. Dans le cas du déplacement d’un uv de la zone droite proche vers la zone très proche, l’information visuelle peu intrusive est complétée par l’alarme sonore jusqu’à l’activation de l’anti-démarrage. Cette double lecture permet d’avoir une vision du déroulement temporel des situations et ainsi d’assurer une cohérence de fonctionnement de l’assistance suivant l’évolution de la situation.

IV.4 – Test de l’assistance

43La figure 9 illustre un fonctionnement de l’assistance basé sur les besoins du conducteur. Les courbes montrent un exemple de déclenchement du limiteur de vitesse suivi d’un freinage d’urgence assorti d’une alarme visuelle en présence d’un usager vulnérable devant le vi ainsi que la position des différentes zones de détection.

Figure 9

Interface du Générateur de Scénario Dynamique

Interface for Dynamic Scenario Generator

Interface du Générateur de Scénario Dynamique

Interface for Dynamic Scenario Generator

44Le gsd nous a permis de valider un concept, celui de « Scénario Dynamique » qui, à partir d’un cas d’utilisation standard, simule le fonctionnement de plusieurs de ses variantes (Tattegrain, Bonnard & Mathern, 2009). Des variations très faibles du comportement des usagers vulnérables se sont révélées capables d’engendrer des fonctionnements complètement différents allant jusqu’à adresser un autre cas d’utilisation. Ce type d’outil est, en outre, capable de gérer suffisamment longtemps une situation, pour permettre l’obtention d’un cycle complet : alerte, déclenchement du contrôle actif et redémarrage après la situation critique.

IV.5 – Évaluation

45Au final, le système développé a été évalué sur le simulateur dynamique de vi de Renault Trucks (scoop). La charge mentale des conducteurs, l’acceptabilité du système, son utilité et la compréhension des stratégies d’assistance par les conducteurs ont été plus particulièrement étudiées. Les protocoles ont été élaborés pour tester également la pertinence des principes et des stratégies de fonctionnement du système ainsi que celles de leur mode de restitution (ihm et alarmes).

46Pour la campagne de tests, le simulateur a été équipé d’une cabine de type « Renault Midlum » (Figure 10) montée sur une plate-forme dynamique à six degrés de liberté. Le véhicule interactif était un porteur de 7 m de long, disposant d’une puissance de 385 cV pour un poids total en charge de 12 t.

Figure 10

Plate-forme du simulateur de conduite équipée d’une cabine Midlum

Driving simulator platform equipped with Midlum cabin

Plate-forme du simulateur de conduite équipée d’une cabine Midlum

Driving simulator platform equipped with Midlum cabin

47La démarche d’évaluation s’est déroulée en deux temps. La première phase, réalisée auprès de divers experts en tests de systèmes (essayeurs professionnels) et ergonomes de Renault Trucks, a permis d’identifier les « points durs » à corriger, tant sur le plan des stratégies d’assistance que sur le plan du déroulement des situations virtuelles. La seconde phase a constitué la partie expérimentale dédiée à l’évaluation finale du système auprès de 15 conducteurs masculins, âgés de 25 à 57 ans (m = 45, écart type = 11).

48Chaque conducteur a rencontré quatre conditions expérimentales différentes sur un circuit urbain complexe et dense : une condition de « familiarisation », une condition « sans système d’assistance », une condition « avec système informatif seul » et une condition « avec système informatif et actif ». Chaque condition était constituée d’un itinéraire à parcourir simulant une tournée de livraison en ville avec différentes manœuvres à effectuer pour prendre un stationnement. Six situations-tests ont été reproduites dans chaque condition, d’une part, pour permettre aux sujets d’évaluer les systèmes dans différentes conditions et, d’autre part, pour tester l’efficacité du système en évaluant le nombre d’accidents potentiels évités.

49Les résultats de l’évaluation ergonomique du système VIVRE2 sur simulateur se sont montrés très concluants sur toutes les dimensions retenues.

50La charge de travail des conducteurs, évaluée à l’aide du nasa tlx modifié (Maincent, 2010) n’a pas montré d’augmentation significative lors de la conduite avec les systèmes. De plus, le nasa tlx a mis en évidence une diminution du facteur stress dans la condition de conduite avec le système VIVRE2 complet (informatif et actif).

51Les stratégies d’assistance et d’information du système VIVRE2 ont été parfaitement comprises par l’ensemble des sujets. De plus, les résultats de l’évaluation par critères ergonomiques (efficacité, utilité, agrément et facilité d’utilisation, perturbation, etc.) de l’ensemble des systèmes nous permettent de conclure que le système VIVRE2 devrait être bien reçu et son fonctionnement accepté par les conducteurs de véhicules industriels. Enfin, le système VIVRE2 a permis d’éviter 89 % des situations critiques sur simulateur.

Tableau 3

Évaluation quantitative de l’efficacité du système VIVRE2

Quantitative evaluation of VIVRE2 system efficiency

Sans système Informatifs Actifs Total Vies Sauvées Accidents évités grâce au système 19 26 41 89 % Usagers vulnérables renversés 39 7 0 46

Évaluation quantitative de l’efficacité du système VIVRE2

Quantitative evaluation of VIVRE2 system efficiency

52L’efficacité objective du système a été évaluée grâce au comptage, d’une part, du nombre d’usagers vulnérables renversés en l’absence de système et, d’autre part, du nombre d’accidents évités grâce au système en mode informatif et/ou actif (Tableau 3). En conclusion, le système VIVRE2 tel qu’il a été conçu et testé présente un intérêt certain pour la diminution des accidents entre usagers vulnérables et véhicules industriels en milieu urbain. Néanmoins, le développement d’un tel système nécessite encore plusieurs phases itératives d’évaluations fonctionnelle et ergonomique, notamment en situation réelle de conduite et d’activité.

V – Points forts et limites

53Du point de vue de la conception, la démarche mise en œuvre est une démarche centrée sur l’utilisateur (User Centred Design). Elle prend les besoins des utilisateurs comme point central des développements et permet ainsi de concevoir une assistance bien acceptée par ces derniers. Le cycle itératif des ucd répond bien au besoin de remise en cause régulière des spécifications. En revanche, si la démarche traditionnelle implique des développements itératifs parfois très coûteux, il s’est avéré nécessaire de trouver des solutions permettant des développements menés en parallèle par les différentes équipes du projet. Nous avons donc proposé une méthodologie intégrant de nouveaux cycles de validation pour réduire les coûts des tests. Ces cycles ont permis de prendre en compte les résultats des analyses d’activité des conducteurs menées en parallèle et les différentes étapes du processus telles qu’elles sont décrites par Maguire (2001).

54La planification d’un tel processus centré sur l’homme est loin d’être anecdotique. Elle a permis de réaliser l’ensemble des analyses ergonomiques et, plus encore, de définir la méthodologie à mettre en œuvre et ses outils associés. Ces derniers ont permis de réduire les coûts du processus itératif et de rendre ainsi cette approche facilement utilisable dans un contexte industriel. Dans un premier temps, des formats des spécifications très basiques ont été définis, afin de prévoir leur intégration dès le début du développement du système. La granularité de ces spécifications s’est raffinée au fur et à mesure de l’avancement du projet. La méthodologie de conception a été définie ensuite. Très coûteuse en début de projet, elle a nécessité quelques développements supplémentaires. L’expérience a montré que cette méthodologie permet des cycles itératifs rapides de développement/test ainsi qu’une prise en compte précoce d’un certain nombre de problèmes techniques. L’utilisation d’une plate-forme d’intégration a permis de traiter les problèmes liés au développement de l’assistance indépendamment des problèmes de communication entre simulateur et cette dernière.

55Les phases de spécification des besoins de l’utilisateur ont permis de décrire des situations critiques et des scénarios d’accidents représentatifs de ces situations, des accidents les plus fréquents, et des situations particulièrement stressantes pour les conducteurs. Six situations types ont alors été définies : deux situations de marche arrière (en mouvement et au démarrage), deux situations de marche avant (en mouvement et au démarrage), une situation de tourne à droite après un démarrage sur feu tricolore et une situation de dépassement d’un usager vulnérable sur la chaussée dans le même sens de circulation. Les stratégies d’assistances ont été élaborées ensuite par l’équipe des ergonomes, qui a spécifié les alarmes lumineuses et sonores en fonction du comportement du conducteur et de la criticité des situations. Des retours informatifs composés de systèmes de vision directe et indirecte et d’alarmes lumineuses et sonores ont été également conçus pour alerter le conducteur d’un risque potentiel, tout en lui laissant, ou non, l’initiative de l’action. En effet, une assistance active, composée d’un système d’antidémarrage, d’un système de freinage d’urgence et d’un limiteur de vitesse, a été conçue pour effectuer des actions correctrices, si nécessaire, à la place du conducteur (prise en charge du pilotage du véhicule par le système).

56L’originalité du projet réside dans le fait que le système développé est un système « adaptatif », c’est-à-dire qu’il adapte son fonctionnement en fonction du comportement du conducteur dans une situation donnée. Le modèle sous-jacent permet une catégorisation des informations concernant la position des usagers vulnérables, formalisée par la définition de zones de détection autour du véhicule, et des informations sur les actions du conducteur, formalisées par un modèle d’intention du conducteur. Ce modèle apporte une sémantique de l’activité facilement compréhensible quelles que soient les disciplines et limite les conséquences d’un changement de technologie sur le vi. Cette catégorisation des informations permet également d’utiliser des tables de décision et d’avoir une vision du déroulement temporel des situations permettant d’assurer un fonctionnement cohérent de l’assistance, quelle que soit l’évolution de la situation.

VI – Conclusion

57L’utilisation de ce type de système devrait diminuer de manière significative, d’une part, le nombre d’accidents et, d’autre part, le stress provoqué par la conduite en environnement urbain et, par conséquent, la charge mentale des conducteurs. Cependant, pour être efficace et accepté par ces derniers, le système proposé doit répondre aux contraintes ergonomiques et cognitives liées à la conception des assistances à la conduite ou des systèmes embarqués, tant en termes de charge informationnelle qui ne doit pas être trop importante, qu’en termes d’acceptabilité par les conducteurs et de fiabilité du système. Il était donc nécessaire de concevoir des stratégies d’assistance et des ihm qui prennent en compte l’activité du conducteur et son fonctionnement cognitif, sous peine de développer des systèmes qui ne seraient pas (ou mal) acceptés par les conducteurs et donc sous-utilisés, voire rejetés ou détournés (Rabardel, 1997).

58En résumé, l’approche pluridisciplinaire adoptée dans le cadre du projet VIVRE2 a permis de proposer un système d’assistance efficace, le système VIVRE2. Conçu pour diminuer les accidents entre usagers vulnérables et véhicules industriels en milieu urbain, il s’appuie sur des stratégies dynamiques d’assistance en fonction des comportements du conducteur et de(s) usager(s) vulnérable(s). Évalue en milieu virtuel par un panel de conducteurs de vi, le système VIVRE2 a montré son efficacité sur simulateur de conduite : 89 % des accidents ont été évités grâce à lui sur l’ensemble des expérimentations. De plus, les résultats de l’évaluation ergonomique permettent de conclure que le système VIVRE2 devrait être bien accepté par les conducteurs de vi et que son fonctionnement ne devrait pas entraîner de surcharge visuelle ou cognitive.

59En conclusion, le cadre méthodologique générique présenté dans cet article a prouvé son efficacité et répond aussi bien aux objectifs du projet, qu’à son utilisation dans des projets futurs pour concevoir sur simulateur des systèmes d’aide basés sur les besoins du conducteur et utilisant des technologies de perception. Ce type d’approche pourrait être étendu à la conception de démonstrateurs en situations réelles de conduite, mais il faudrait, pour cela, prévoir une phase plus longue de planification pour le développement d’une plate-forme d’intégration. Les phases d’évaluation devraient aussi être plus nombreuses, car des problèmes supplémentaires de fausses alarmes et de non-détection, dus au passage du simulateur vers un démonstrateur, risquent de demander des cycles complémentaires. En effet, le passage du monde simulé au monde réel génère un certain nombre de problèmes imprévisibles. Et cette méthodologie ne permet d’anticiper que des problèmes prévisibles. L’approche décrite ici permet toutefois de prendre en compte ces problèmes de façon très précoce.