• Aucun résultat trouvé

Environnement et choix d'une structure système

4.2.1 Introduction

An de réaliser l'architecture présentée au chapitre 3, il est nécessaire d'étudier la manière dont elle s'insère dans un environnement système. C'est l'objet de cette section. La taille des

images à traiter est un paramètre important pour caractériser les éléments de notre architecture. Après avoir choisi ces paramètres, nous décrivons rapidement le système hôte. Il apparaît que SPIDDO se loge sur un module déporté composé de l'unité de traitement et des mémoires. C'est pourquoi nous portons une attention particulière sur les bus d'interfaçage qui serviront au dia-logue entre l'hôte et le module. Un exemple de chaîne de traitement montre la complémentarité des ressources systèmes.

4.2.2 Choix de la taille des images

Le chapitre précédent a mis en évidence que le coût de notre architecture dépend essentiel-lement de la taille des images à traiter. Le choix de la taille des images est largement lié au type d'application. Sur les systèmes de vision industrielle, les images typiquement rencontrées sont de 512512 pixels et évoluent vers des tailles de 10241024 points. Nous avons choisi une taille de 1024512 pixels, qui correspond à la taille des images délivrées par le système d'acquisition d'image de notre hôte.

Le deuxième paramètre à déterminer est la dynamique des pixels, c'est-à-dire le nombre de niveaux de gris possibles dans l'image. Une dynamique de 256 niveaux (8 bits) est communément admise. Ce nombre correspond à la dynamique des échantillons délivrés typiquement par les convertisseurs analogique/numérique présents sur le ot vidéo issu des caméras. C'est la valeur que nous utiliserons pour la mémoire image. La mémoire label est susceptible de stocker des niveaux de gris ou des étiquettes. Elle doit donc pouvoir stocker des niveaux de gris d'une dynamique de 8 bits. En ce qui concerne les étiquettes, une dynamique de 256 niveaux nous semble faible, car elle limite le nombre d'objets distincts à 256. L'étude des chaînes de traitement présentée au chapitre 1 nous conduit à un choix de 4096 valeurs d'étiquettes distinctes, soit un codage des mots de la mémoire label sur 12 bits. Cette dynamique nous paraît susante et ne présente pas un impact trop important sur la largeur des bus de données à l'intérieur de SPIDDO. Dans ce cas, les banques image sont des mémoires de 128 ko et les banques label, des mémoires de 1024128 mots de 12 bits, soit 192 ko. Ces mémoires seront implantées dans un boîtier de 128 ko pour chaque banque image et dans deux boîtiers 128 ko pour chaque banque label.

La dimension de la le d'attente peut aussi être dénie. Le nombre de mots dans la Mémoire de File d'Attente (MFA) est égal au nombre de pixels dans l'image, à savoir 1024512. Les données à stocker sont des triplets (

x;y;lab

). Chaque mot aura une longueur de 31 bits. La MFA avoisine donc 2 Mo, taille qui pourrait être réduite car la MFA n'est que faiblement remplie durant le traitement. Cependant, comme il est prévu à terme que cette mémoire soit vue non seulement par SPIDDO mais aussi par l'ensemble du système, nous n'avons pas cherché à en réduire la taille. La Table Locale de Conversion d'Adresses (TLCA) mémorise un couple d'adresses sur la MFA, soit des mots de 219 bits. Le nombre de ces couples est déterminé par le nombre de segments en MFA qui dépend de la dynamique de la mémoire image. Il y aura donc 256 mots. La TLCA se constituera d'une mémoire double ports de 9,5 kbits soit d'environ 1,25 ko. Le tableau 4.1 résume les besoins en mémoires de SPIDDO.

Tab. 4.1  Taille des mémoires du module.

Mémoire Image Label MFA TLCA

Besoins 4128 ko 4192 ko 2 Mo 9,5 kbits (double ports) Taille eective 4128 ko 4256 ko 2 Mo 1,25 ko (double ports)

4.2. Environnement et choix d une structure système 133

4.2.3 Système hôte

Les systèmes de vision utilisés en milieu industriel ont une structure globale semblable. Ils sont composés d'une carte de base articulée autour de 4 fonctionnalités principales: acquisition, stockage, traitement, restitution, comme le montre la gure 4.1.

ACQUISITION STOCKAGE UNITE DE TRAITEMENTS GENERAUX RESTITUTION Bus externes Bus internes

Fig. 4.1  Agencement typique d'un système de vision industrielle.

L'unité d'acquisition

contient généralement un multiplexeur vidéo permettant l'acquisition d'images provenant de plusieurs caméras (4 dans le cas des systèmes IA512 d'EDIXIA, MaxVideo200 de DATACUBE ou ITEX150 d'IMAGING TECHNOLOGY).

L'unité de stockage

contient les mémoires de sauvegarde des images provenant d'une acqui-sition ou du résultat d'un traitement. Leurs tailles sont gées ou modiables par modules d'extension.

L'unité de traitement

s'articule autour d'un processeur général (68040 de MOTOROLAr

dans le cas de l'IA512), qui donne au système la souplesse d'une architecture convention-nelle assurant la versatilité des tâches à eectuer, ainsi qu'un confort de développement lié à la programmation au moyen d'un langage de haut niveau.

L'unité de restitution

permet un retour vidéo des images et contient des fonctions d'incrus-tation graphique et de palettes de visualisation.

Les systèmes de vision sont équipés de bus de communication permettant un lien avec une in-terface utilisateur, typiquement un micro-ordinateur, mais aussi avec des modules de traitement spéciques. C'est pourquoi on distinguera deux types de bus:

 le premier a comme but l'interfaçage avec des équipements industriels standards. Les pro-tocoles de communication sont donc ceux utilisés dans le milieu industriel: VME, RS232, PCI, etc.

 le second est spécique au système de vision et sert à la communication entre les éléments internes et avec des modules de traitements spéciques optionnels. On peut citer le MaxBus de DATACUBE, les VideoBus d'IMAGING TECHNOLOGY, le bus IGOR d'EDIXIA. Les modules de traitements spéciques sont des accélérateurs basés sur des processeurs (ou DSP) puissants: WEITEK XL8032 sur le système ITEX 150 d'IMAGING TECHNOLOGY, ou des circuits dédiés à des traitements spéciques: le circuit IGOR (DavidetLattard, 1994) sur l'IA512 d'EDIXIA. Le module IGOR est composé de deux IGOR pouvant accéder aux données issues d'une caméra ou d'une mémoire d'image. Il est destiné aux opérateurs de base de la morphologie inconditionnelle (dilatation, érosion), au ltrage linéaire (gradient, convolution...) et aux opérations inter-images (addition...).

4.2.4 Choix d'un module déporté

SPIDDO s'inscrit tout à fait dans la catégorie des accélérateurs de traitements spéciques. D'autre part, il est dicilement envisageable de modier le système d'accueil pendant le déve-loppement de SPIDDO. Nous décidons donc que son implantation matérielle sera l'objet d'un module de traitement câblé rapide disponible à la demande. Il reste à déterminer si le module utilisera les ressources mémoire de la carte mère ou une unité de stockage locale. L'utilisation de mémoires déportées sur la carte mère imposerait des bus de communication très larges. Nous décidons, de ce fait, que les mémoires nécessaires au fonctionnement du module seront présentes directement sur ce module.

Lorsque SPIDDO sera nalisé, il faudra réévaluer les avantages et les inconvénients d'un module déporté, d'autant plus que les mémoires de l'IA512 d'EDIXIA, partenaire de cette étude, sont déjà organisées en 4 banques. Seuls les bus de ces mémoires devraient être modiés. De plus, il serait pertinent que la Mémoire de File d'Attente (MFA) soit directement accessible par le reste du système.

Nous devons maintenant étudier les liens de communication entre le système de vision et le module SPIDDO. Comme nous l'avons évoqué plus haut, nous distinguons deux types de bus:

bus système

qui permet le chargement des registres de programmation du module SPIDDO, ainsi que les coordonnées des marqueurs manuels, le cas échéant. L'échange de para-mètres de résultats sera également transmis par ce bus. Dans le cas de notre module, le bus système sera au standard VME.

bus de données

permettant l'échange de données pixels depuis le ot vidéo ou les mémoires image du système hôte, en vue du chargement et de la sauvegarde des mémoires image et label de notre module. Dans notre cas il s'agira du bus IGOR.

Notre module doit être doté des interfaces permettant de dialoguer avec le système hôte sur le bus IGOR et le bus VME.

On ajoute de nouvelles fonctionnalités permettant de gérer ces interfaces:  le chargement des mémoires image et label;

 la sauvegarde des données label;  le chargement de marqueurs manuels;  la sauvegarde de paramètres.

Il existe plusieurs congurations de chargement des mémoires image et label de notre module:  chargement des deux mémoires avec les mêmes images;

 chargement de la mémoire label seule;

 chargement de la mémoire image et initialisation de la mémoire label à une valeur constante. On se reportera à (Pellerin, 1997) pour les détails sur l'interfaçage du module SPIDDO vers le système hôte, en particulier en ce qui concerne la programmation du module.

Lors du chargement, la taille de l'image à traiter est automatiquement détectée. Le traite-ment est ensuite eectué sur cette image ou dans une fenêtre d'intérêt rectangulaire dont les caractéristiques (coin supérieur gauche et coin inférieur droit) sont spéciées lors du chargement des paramètres de conguration.

4.3. Méthodologie de conception 135