Une ingénierie pour l’Operational Design Domain
Qu’est-ce que l’ODD ?
Le concept d’ODD a été utilisé pour la première fois dans le domaine automobile. Depuis lors, diverses industries ont réutilisé cette notion, parfois en en faisant leur propre interprétation. Cette observation a également été confirmée au sein du programme Confiance.ai, qui rassemble divers acteurs de différents domaines. Ainsi, une étape nécessaire si l’ont veut appliquer les concepts qui sous-tendent cette notion à une IA digne de confiance est de s’assurer que nous développons tous la même compréhension des enjeux de l’ODD.
Dans cette optique, nous avons effectué un tour d’horizon de différentes définitions issues de la littérature – et sur de notions similaires -, avec une analyse des avantages et des inconvénients que présente chacune de ces définitions. Suite à cette analyse, il nous a semblé indispensable d’élaborer une définition de l’ODD appropriée au programme Confiance.ai. Ce besoin est motivé par les raisons majeures suivantes :
- Trouver un consensus sur une définition qui sera partagée par tous les acteurs impliqués dans le processus de développement d’une IA de confiance et pas seulement les acteurs du domaine de la conduite autonome ;
- Définir clairement ce qu’est l’ODD et ce qu’il ne l’est pas car l’interprétabilité du concept originel pourrait conduire à une mauvaise compréhension de sa portée réelle ;
- Démystifier la notion d’ODD pour les acteurs qui la considéraient comme l’unique solution à la question de la spécification de l’IA ;
- Identifier (si nécessaire) d’autre(s) artefact(s) d’ingénierie qui couvre(nt) le périmètre non couvert par la définition choisie d’ODD et requis pour le processus de développement d’un système basé sur l’IA.
La notion d’ODD que nous proposons a été définie au travers de plusieurs ateliers, notamment un qui a eu lieu sur le site de l’usine Renault au Mans. Ainsi, nous avons étudié entre experts de différents domaines, les besoins et usages autour de l’ODD, en nous servant du contexte opérationnel du système de qualification de Soudure de Renault déployé sur ce site comme élément d’étude. Ledit système utilise l’IA dans un système d’inspection visuelle pour classer des cordons de soudure comme conforme ou non conforme. Étant donné que toutes les composants de ce système ne sont pas automatisé ou n’utilisent pas l’IA, nous avons également dû (re-)définir des notions supplémentaires qui peuvent être adjacentes à la notion d’ODD.
Ci-dessous, nous présentons quelques définitions issues de nos travaux :
| Terme | Définition | Exemplification sur le cas de soudure |
| Domaine opérationnel | Le domaine opérationnel représente le monde réel dans lequel le système fonctionnera à un moment donné. | Le système de qualification de soudure fonctionne dans les ateliers de soudure de l’usine Renault à Le Mans |
| Sous-système / Composant | Sous-système ou Composant qui couvre le modèle de bout en bout de capture de résultats/données (avec capteur, traitement et actionnement). | Dans le cadre global du système de qualification des soudures, un Sous-système de perception utilisant un algorithme IA réalise l’inspection visuelle des soudures. |
| Operational Design Domain | Restriction volontaire du domaine opérationnel dans lequel le fonctionnement nominal d’un système basé sur l’IA est assuré.
L’ODD est d’une description des conditions de fonctionnement prévisibles dans lesquelles un (sous-)système/composant utilisant de l’IA doit fonctionner. Les éléments prévisibles dans ce contexte doivent être mesurables.
|
L’ODD du système de qualification de soudure est une restriction du domaine opérationnel qui inclut uniquement les conditions opérationnelles qui permettront l’inspection visuelle de cordons de soudure. |
On notera au regard de l’état de l’art que de nombreuses définitions sont orientées vers la description du concept, sans nécessairement indiquer comment définir le périmètre propre de l’ODD. Il est sage de rappeler que « décrire » n’est pas synonyme de « définir ». Dans le cadre de Confiance.ai, notre objectif principal est de définir un processus pour construire l’ODD d’un système basé sur l’IA et potentiellement d’identifier les artefacts d’ingénierie supplémentaires nécessaires à la spécification d’un tel système qui ne sont pas couverts par l’ODD.
Comment spécifier l’ODD ?
L’état de l’art concernant la description de l’ODD est assez documenté mais l’état de l’art sur le processus de définition est beaucoup plus succinct. Les quelques travaux proposant des exemples des ODD indiquent l’utilisation de taxonomie et d’ontologie sans donner plus de détail sur la conduite spécifique pour sa construction. Durant l’année 2021, nous avons défini une approche basée sur ces éléments pour définir une approche de construction d’un ODD pour le système de qualification de soudure.
Figure 1 : Une schématisation de l’ODD pour le système de qualification de soudure de Renault
Récemment, nous proposons une autre approche pour généraliser un processus de définition d’un ODD. Pour cela, nous partons du postulat que pour tout nouveau développement industriel, il existe des études en amont qui permettent une définition préalable du système et une approche incrémentale qui conduit à améliorer ou étendre un référentiel préexistant. Rappelons tout d’abord que la construction d’un ODD n’a de sens que lorsqu’elle est appliquée à un système avec un niveau d’autonomie spécifié, dans un contexte opérationnel ouvert. L’ODD s’applique à une fonctionnalité qui est partiellement/entièrement automatisée ou autonome. Notre approche se décline ainsi en trois étapes successives :
- Identification des enjeux : l’objectif de la première étape du processus est de connaître les enjeux à traiter dans l’ODD pour une fonctionnalité identifiée. Nous nous concentrons sur les enjeux qui pourraient mettre le système dans une situation potentiellement dangereuse ou qui définissent une limitation d’un bon fonctionnement. De ce point de vue, la démarche est similaire à du SOTIF ISO/DIS 21448 (Clause 7 : identification et évaluation des insuffisances fonctionnelles et conditions déclenchantes). Cette méthode nécessite un ou plusieurs référentiels avec les retours d’expérience de terrain associés. Exemple : Le Système de référence étant le Contrôle visuel de soudure par un opérateur humain (100%), le système autonome à définir est un système de Contrôle visuel de soudure via caméra
- Définition des caractéristiques : l’étape 1 spécifiant une liste d’enjeux à traiter dans la définition de l’ODD. L’étape 2 vise à détailler ces enjeux de manière technique avec des caractéristiques et des limites pour chacun d’entre eux. Exemple de caractéristique : Capacité à détecter les soudures sur une image de cordon. avec un certain niveau de flou
- Consolidation de l’ODD : à partir de la liste des caractéristiques mesurables et leurs limites identifiées pour chaque enjeu lors de l’étape 2, l’objectif de l’étape 3 est de consolider les résultats précédents avec les caractéristiques et les limites pour l’ensemble du système. L’objectif est de définir des limites cohérentes concernant le fonctionnement du système (ou de ses caractéristiques).
Le processus de développement de l’ODD présenté ci-dessus est principalement pour la définition d’un ODD préliminaire. Un ODD atteindra différents niveaux de maturité durant le cycle de développement du système pour un résultat d’exploitation satisfaisant selon la phase d’ingénierie. Il est important de prendre en considération ces aspects temporels dans la définition de l’ODD. La figure ci-dessous propose notre vision de la façon dont ces différents ODD pourraient évoluer en parallèle des activités de spécification, de design et de construction des jeux de données.
Figure 2 : Façon dont les ODD pourraient évoluer en parallèle des activités de spécification, de design et de construction des jeux de données
Les différents usages de l’ODD
Bien que nos définitions et notre processus de développement de l’ODD ont pour objectif d’être agnostique d’un domaine d’application particulier, notre analyse avec les experts autour du système de qualification de Soudure de Renault, nous a permis de mettre en évidence différents besoins autour de l’ODD selon les parties prenantes.
Les utilisations de l’ODD peuvent, entre autres, avoir pour finalité principale de :
- Communiquer avec les utilisateurs et les autorités sur le système et ses capacités. L’ODD est alors défini d’un point de vue fonctionnel de l’application métier avec une description des différents facteurs ayant une influence sur le service attendu
- Communiquer les contraintes opérationnelles aux équipes d’ingénierie, notamment celle élaborant les briques IA. L’ODD précisera dans ce contexte, les paramètres et métriques nécessaires des conditionnelles opérationnelles (ou combinaisons de ces conditions) pour assurer la sécurité et la performance du système.
De plus, la phase d’ingénierie du processus de développement du système à base d’IA, d’autres informations métiers sont nécessaires pour exploiter l’ODD. Par exemple, pour le data engineering, des informations contextuelles supplémentaires sont ainsi nécessaires sur la nature des données et le processus de collection de celles-ci pour la construction des différents jeux de données d’entraînement, de test et de validation des modèles d’apprentissage automatique.
Concernant la Vérification & Validation, comme tout artefact d’ingénierie, l’ODD doit être validé au sens où il devra respecter des propriétés similaires à celle que l’on attend d’une spécification des exigences : valide, nécessaire et suffisant sont les principales caractéristiques recherchées. De plus, lors de l’exécution du système, l’ODD doit être surveillé pour détecter tout écart par rapport au comportement nominal et exécuter les solutions d’atténuation appropriées en conséquence. On s’intéressera intrinsèquement à ce stade à identifier les frontières de l’ODD et les données hors ODD. Donc l’ODD doit également être validé par rapport à sa robustesse vis-à-vis de telles conditions.
Nous en tirons la conclusion qu’au-delà de l’ODD, l’ingénierie des données a besoin d’informations supplémentaires. Cette analyse semble être vraie pour différentes ingénieries. Il est nécessaire d’identifier, au-delà de l’ODD, la nature du ou des artefact(s) caractérisant les informations complémentaires pour la spécification d’un système IA de confiance et leur source (pour chaque ingénierie).
Conclusion
L’ODD définit les conditions de fonctionnement prévisibles – et mesurables – dans lesquelles un système IA est conçu pour opérer de façon autonome. Dans le cadre de Confiance.ai, nous menons des travaux pour préciser la portée de ce concept et son incidence dans le processus de développement d’un système IA. Nous avons quelques résultats préliminaires concernant des méthodologies de construction d’une ODD et l’identification de besoins métier spécifiques autour de cet artefact. Il s’agit de travaux en cours que nous sommes toujours en train d’enrichir et de mieux formaliser. Mais, ils mettent d’ores et déjà en évidence que l’ingénierie autour de l’ODD n’a pas pour objectif de remplacer les processus et artefacts classiques d’ingénierie. L’ODD doit plutôt être exploité en complément de ceux-ci pour préciser les exigences garantes de la performance de la fonction autonome d’un système qui intègre une fonction autonome.
Dans la suite de nos activités, nous travaillerons à consolider le processus d’ingénierie de l’ODD, ses relations avec les autres processus d’ingénierie ainsi qu’à définir le(s) format(s) approprié(s) pour la spécification de l’ODD selon les parties prenantes.
Un article rédigé par Morayo Adedjouma.
