Le langage d’interrogation SPARQL 

La régulation continue

La boucle de régulation fermée constitue la base de l’automatique continue. Elle est constituée d’un capteur-transmetteur qui mesure en permanence la grandeur réglée. Cette mesure est transmise `a un régulateur. Le régulateur compare la mesure `a la consigne (valeur optimale de fonctionnement de la grandeur réglée), décidé de la meilleure correction `a apporter au procédé grâce a une loi de commande et transmet cette correction `a la vanne de régulation. La vanne de régulation exécuté l’ordre donne par le régulateur, modifie ainsi le débit qu’elle contrôle (la grandeur réglante). Cette modification de l’état du procédé doit contribuer `a ramener le plus efficacement possible la grandeur réglée `a la valeur de consigne.

La spécificité des industries agroalimentaires

Les procédés agroalimentaires, dans un cadre industriel ou de recherche, ont des caractéristiques particulières vis-`a-vis de l’automatisation. Les opérations sont parfois instables (fermenteurs, par exemple), souvent non linéaires et caractérisées par beaucoup de grandeurs dont une petite partie est observable.
La nature des grandeurs qui caractérisent les opérations est variée : elle est souvent analogique, ou événementielle, parfois symbolique et le plus souvent multidimensionnelle.

Exemple

Prenons l’exemple de la fabrication du pain. La phase de fermentation est discontinue du point de vue des flux de matière. La levure est mélangée `a la farine et repose un certain temps dans une ´etuve `a 25 ➦C pour assurer le levage, puis l’´etuve est vidée et le cycle reprend. Les informations utilisées sont des évolutions de température, de volume de produit.
Ce sont des informations de nature analogique (`a variation continue dans le temps). Ce type d’operation est une opération batch, ou discontinue.
Le four qui réalise la cuisson procédé d’une operation continue. Les pains défilent sur un tapis, un temps donne dans le four. Les informations nécessaires au contrôle sont de nature analogique : température, teneur en eau, volume, couleur, etc. Ce typ e d’opération est appelé opération continue. Si l’on détaillé les informations `a recenser pour le contrôle de l’operation, on trouve des grandeurs analogiques, des données de nature symbolique (par exemple, produit bien cuit, croute fine, mie moelleuse, etc.), et des données de nature événementielle : démarrage de four, arret, changement de production, etc. Il apparaît également que nombre des opérations nécessaires ne sont pas mesurables avec des capteurs.

Les logiciels de supervision

La gestion informatique d’un procédé peut se réaliser au travers de l’utilisation d’un logiciel dit ≪ de supervision ≫. Ce type de logiciel, souvent assez coûteux, intégré un certain nombre de fonctionnalités de base indispensables pour gérer le procédé.
La plupart du temps, on retrouve trois grands modules :
– une couche pilote de matériel, capable de dialoguer avec le matériel (les capteurs et actionneurs),
– une couche de contrôle qui assure d’une part la régulation du procédé par intermédiaire d’une loi de commande et d’autre part la sauvegarde des données,
– une interface utilisateur pour suivre le cours du procédé en observant les mesures.

Les principaux acteurs du marche

Il nous semble intéressant de présenter quelques logiciels de supervision rencontres dans les laboratoires ou l’industrie. Ces logiciels sont de fait des incontournables du métier. Nous citons ici trois exemples.

LabVIEW

LabVIEW est un logiciel de développement d’application de la société américaine National Instrument bas´e sur un langage de programmation graphique appel´e langage G. Les domaines d’application traditionnels de LabVIEW sont la commande et la mesure `a partir d’un PC (acquisition de données, contrôle-commande d’instruments de mesure, de dispositifs expérimentaux, de bancs de test).
Pour le développeur, un programme en langage G se présente comme un schéma, le diagramme, réunissant différentes icônes reliées par des fils de couleur. Chaque fil symbolise le passage d’une donnée depuis une source dont elle sort (comme résultat), vers une cible o`u elle entre (comme paramètre).

Variables d’un procédé et acquisition des données

Les mesures et les consignes sur les procédés doivent être stockées dans le système . Elles deviennent des mesures de variables. Elles peuvent être classées selon leurs usages dans le procédé.
Nous présentons ici une typologie de ces variables. Nous traiterons ensuite des différents modes d’acquisition des mesures, c’est-`a-dire de leur passage du procédé au système.

Variables d’etat et variables objectifs

En automatique, les variables d’etat déterminent la transformation, au cours du procédé, des propriétés d’un matériel alimentaire. Ces propriétés peuvent être micro-biologiques et toxicologiques, organoleptiques (texture, couleur, goˆut, etc.), nutritionnelles (teneur en protéines, valeur nutritionnelle, etc.) et technologiques (densité, teneur en eau, etc.). Parmi elles se trouvent les variables objectifs, qui correspondent aux objectifs de l’operation, par exemple la teneur en eau d’un produit après un procédé de séchage.

Variables de commande

Les variables de commande, ayant un effet sur le système, englobent toutes les variables que l’on veut maîtriser pour obtenir une certaine évolution des variables d’´etat du produit.
L’´établissement des trajectoires de variables de commande, au lieu des consignes constantes, est l’option la plus adéquate vis-`a-vis de la conduite des procédés alimentaires.

Variables perturbatrices

Les variables perturbatrices sont des conditions qui agissent sur le système en provoquant des changements dans les variables d’etat. Elles peuvent être mesurables ou non et agir de façon aléatoire ou systématique. La variabilité de la matière première, les conditions environnementales au moment de la production sont des exemples des ces perturbations. Un des objectifs en automatique est de réduire les effets de celles-ci sur le système.

L’acquisition des données

Les données issues du procédé peuvent être classées selon leur mode d’acquisition. On distinguera les données hors-ligne des données en ligne. Elles peuvent également être envisagées sous l’angle de leur dimension, certaines données peuvent être qualifiées de complexes.

Données hors-ligne

Ces données ne font pas l’objet d’une acquisition automatique. Elles nécessitent la plupart du temps le prélèvement d’un échantillon sur le procédé. Elles peuvent de ce fait introduire un biais dans le cours du procédé. On essaiera autant que possible de limiter ce biais en rendant négligeable la quantité prélevée.
Il s’agit souvent d’analyses sur le substrat mettant en jeu d’autres Equipements plus ou moins automatises.
Il est fréquent d’effectuer des analyses sur la matière première, avant le début du procédé ou bien lorsqu’il est termine. Les mesures hors-ligne ont de ce point de vue un caractère statique.
Notons ´également que leur quantité est souvent plus faible.

Données en ligne

Les données en ligne sont issues automatiquement du procédé, pendant son déroulement.
Elles nécessitent des capteurs sophistiques capables de transformer une réalité physique en une grandeur numérique. C’est l’abondance de ces mesures qui fait leur intérêt car elles permettent de saisir l’´evolution d’un procédé dans sa dynamique temporelle. Généralement, on capture simultanément un ensemble de valeurs correspondant `a un instant donne. Il est cependant possible de rencontrer des installations produisant des groupes de données non synchronises. Ce cas de figure aura des implications sur le système d’information associe.

La lettre de mission

Apr`es avoir pr´esent´e le contexte g´en´eral des proc´ed´es agroalimentaires, il convient de p ´eciser la probl´ematique de ce memoire. Les proc´ed´es ont une nature complexe, il est en soi un d´efi pour un laboratoire de mobiliser les moyens pour les mettre en œuvre, ce qui entraine un coˆut de production de la donnee eleve.
Or, on constate une exploitation relativement limit´ee de ces donn´ees. Limitation due en grande partie `a l’absence de reflexion sur le systeme d’information hˆote. La plupart du temps, une serie d’experimentations est lancee par un chercheur ou une équipe, avec un objectif de recherche bien défini. L’accumulation des données commence et se poursuit jusqu’`a l’achevement du programme de recherche. Une production scientifique est faite. Les équipes passent. La donnée retombe dans l’oubli.
Dans la realite, le tableau que nous d´epeignons est parfois moins sombre. Un groupe d’experimentations fait souvent partie d’un projet implicite (these, programme de recherche, partenariat avec un industriel, etc.), les ´equipes peuvent identifier pendant un certain temps dans quel contexte se situe une donn´ee. Cependant, mˆeme dans ce cadre l`a, l’absence d’un certain nombre d’informations peut s’averer bloquante. La figure 1.7 montre la repr´esentation graphique de la vitesse de d´egagement de CO2 lors d’une fermentation alcoolique. La courbe en bleu repr´esente les donn´ees pr´esentes dans la base. Les indications en rouge, expliquant les pics de variation dans les mesures, ne sont pratiquement jamais pr´esentes. Elles sont pourtant fondamentales pour pouvoir exploiter `a nouveau ce jeu de donn´ees. En leur absence, on ne peut plus rien faire des donn´ees brutes.

L’´etat de l’art

Les systemes d’information autour des procedes

L’´etat de l’art s’int´eresse `a l’existant, c’est-`a-dire aux syst`emes d’information que l’on retrouve associ´es aux proc´ed´es. Le terme ≪ syst`eme d’information ≫ peut avoir de multiples d´efinitions, pour lever toute ambigu¨ıt´e nous retiendrons la suiv ante. Syst`eme d’information Un syst`eme d’information (SI) est l’ensemble des ressources humaines, logicielles et de donn´ees participant `a la gestion, au traitement, au transport et `a la diffusion de l’information au sein d’une organisation.
Il est h´elas fr´equent, dans le contexte des recherches exp´erimentales, de ne pas disposer d’un syst`eme d’information informatis´e permettant de garantir la p´erennit´e des exp´eriences et des donn´ees afin de permettre leur utilisation ult´erieure. Nous diff´ erencierons `a cet effet la notion de syst`eme exp´erimental, qui peut ˆetre informatis´e, de syst`eme d’information qui pr´esente les caract´eristiques mentionn´ees ci-dessus.
Nous recensons ici diff´erentes architectures de systemes experimentaux rencontrées dans les laboratoires de recherche. Nous pr´esentons une typologie non exhaustive de l’organisation des syst`emes exp´erimentaux dans les proc´ed´es alimentaires. Les solutions retrouvées dépendent grandement des comp´etences locales des informaticiens responsables des SI.

Solution manuelle

Dans ce cas de figure, de plus en plus rare, il n’y a pas d’informatisation. Les différents acteurs effectuent des prélèvements d’échantillons sur le procédé, réalisent des analyses et notent les résultats sur des cahiers de laboratoire. La régulation est nécessairement manuelle.

Modeles pour les bases de donnees

Nous avions signal´e pr´ec´edemment que le support de stockage des donn´ees pouvait ˆetre une base de donn´ees. Nous pr´esentons ici les diff´erents mod`eles pour les syst`emes d’information utilisant des bases de donn´ees relationnelles. Ce sont des mod`eles logiques, nous discuterons bri`evement des avantages et inconv´enients de chacun d’eux. L’exp´erimentation et les mesures associ´ees sont en g´en´eral repr´esent´ees par deux tables : une pour le le concept d’exp´erimentation, une pr´esentant les divers type de mesures (cens´es ˆetre connus `a l’avance). Le code de l’exp´erimentation, cl´e de la table exp´erimentation, est cl´e ´etrang`ere dans la table des mesures.

Cas 1 : une table pour les mesures

Le modèle est organise autour d’une table qui enregistre les données des grandeurs mesurées.
Un champ est utilise pour chaque variable mesurée.

Description des expérimentations

D´ecrire une experimentation est fondamental pour lui donner une utilite future. Il est important d’indiquer :
– le contexte de recherche dans lequel elle s’inscrit,
– les parametres de base comme les matieres premieres, les produits ajout´es, le volume, etc.
– les parametres de r´egulation.
La regulation (voir page 10) qui s’op`ere par les actionneurs consiste `a fournir des trajectoires cibles pour certaines variables du proc´ed´e. Elle s’applique `a un procede unitaire.
La r´egulation peut s’op´erer manuellement par l’intermediaire d’un opérateur humain. Lorsqu’elle est automatisee, elle utilise une loi de commande. La loi de commande s’appuie sur un certain nombre de consignes (ou variables de commande) et sur les mesures issues du procede.
Elle effectue des calculs et transmet ´eventuellement des ordres au module de commande qui d´eclenchera les actionneurs.

Mise en œuvre

Ce chapitre presente une proposition d’implementation et d’integration de notre modélisation.
L’idee generale est d’utiliser l’ontologie definie au chapitre precedent en tant que ciment pour le systeme d’information. Le d´eploiement est présente au chapitre suivant, le lecteur peut se reporter `a la figure page 51 pour avoir une vue d’ensemble.
Le chapitre est structure en deux parties. La premi`ere pr´esente le mod`ele relationnel de la future base d´erive d’une partie du mod`ele du chapitre pr´ec´ edent. La seconde présente les technologies du web s´emantique ainsi que leur utilisation dans le cadre des bioprocedes.

Le modèle pour les données brutes

Le modèle relationnel

Le modèle relationnel propos´e par E.F. Codd repose sur des principes mathématiques ensemblistes.
On appelle ≪ schéma relationnel ≫ un ensemble d’attributs définissant une intention, et chaque instance de ce schéma est appelee relation et comporte un ensemble de n-uplet. Les relations sont habituellement représentées sous forme de table. Codd a défini une algèbre relationnelle et des opérateurs permettant de construire d’autres relations `a partir de relations. Cette théorie est `a la base de la plupart des systèmes de gestion de base de données.
Nous ne nous étendrons pas d’avantage sur le modèle relationnel. Ce qui est important pour nous, c’est que les technologies le mettant en œuvre ont et éprouvées, sont fiables et performantes.

La dérivation du modèle d’analyse

Par dérivation, nous entendons ≪ changer de niveau d’abstraction ≫, c’est-`a-dire s’approcher du modèle physique qui sera implant´e en machine. Ce nouveau modèle est adapte a une base de données relationnelle sans que nous nous soyons arrêtés sur un type particulier de SGBD.

Table des matières
Introduction 
1 Définitions, contexte des procédés de transformation alimentaire 
1.1 Domaine a la croisée de l’informatique, de l’automatique et des agrosciences
1.1.1 La démarche d’automatisation
1.1.2 La régulation continue
1.1.3 La spécificité des industries agroalimentaires
1.1.4 Les logiciels de supervision
1.2 Variables d’un procédé et acquisition des données
1.2.1 Variables d’état et variables objectifs
1.2.2 Variables de commande
1.2.3 Variables perturbatrices
1.3 L’acquisition des données
1.3.1 Données hors-ligne
1.3.2 Données en ligne
1.3.3 Données complexes
1.3.4 Données symboliques
1.4 La lettre de mission
1.5 Cas d’utilisation de référence
2 L’état de l’art 
2.1 Les systèmes d’information autour des procédés
2.1.1 Solution manuelle
2.1.2 Solution d’acquisition automatisée
2.1.3 Solution distribuée
2.2 Modeles pour les bases de données
3 Analyse et proposition 
3.1 Méthodologie
3.2 Noyau du modèle
3.2.1 Procédé et procédé unitaire
3.2.2 Le modèle
3.2.3 Les produits
3.2.4 Les mesures
3.3 Ajouts sémantiques
3.3.1 Les thèmes de recherche
3.3.2 Les événements
3.3.3 Le contexte d’instrumentation
3.3.4 Description des expérimentations
4 Mise en œuvre
4.1 Le modèle pour les données brutes
4.1.1 Le modèle relationnel
4.1.2 La dérivation du modèle d’analyse
4.2 Le modèle sémantique
4.2.1 Les langages du web semantique
4.2.2 Unicode, URI et espace de noms
4.2.3 Le cadre de description de ressources RDF
4.2.4 Les Schemas RDF
4.2.5 Le langage d’ontologie OWL
4.2.6 L’extensibilite de OWL
4.2.7 Le langage d’interrogation SPARQL
4.2.8 Construction de l’ontologie
5 Implantation 
5.1 Les choix technologiques
5.1.1 Une interface web
5.2 Architecture
5.2.1 Sous-système de synchronisation
5.2.2 Sous-système de consultation
5.2.3 Sous-système d’interrogation d’ontologies
5.3 Fonctionnement
5.3.1 Annotations nombreuses
5.3.2 Annotations peu nombreuses
6 Résultats 
6.1 Ergonomie générale
6.1.1 La consultation des experimentations et des mesures
6.1.2 Déclaration d’experimentation
6.1.3 Déclaration d’analyse
6.1.4 Les annotations : ´ev´enements, commentaires
Conclusion 
A Script SQL du trigger présente
A.1 La fonction de creation de la table
A.2 Mise en place du trigger
B Les unit´es de référence du système international
C Installation de tomcat et axis sur Linux
C.1 telechargement du programme
C.2 Installation
C.3 Ajout d’un service tomcat sur le systeme
C.4 Lancement automatique au demarrage du systeme
C.5 Creation d’un utilisateur administrateur
C.6 Demarrage de tomcat
C.7 installation d’AXIS
C.8 D´eploiement d’un Web Service
C.9 Liste des librairies
C.10 Fichiers journaux de Tomcat
D Les critères d’ergonomie de Bastien et Scapin
D.1 Favoriser la simplicité
D.2 Alléger les pages
D.3 Etre cohérent
D.4 Informer l’utilisateur
D.5 Indiquer clairement les actions
D.6 Prevenir les erreurs
D.7 Utiliser les conventions
E L’architecture du sous-système de consultation
E.1 Les classes du modèle
E.2 Le contrôleur
E.3 Les vues
E.4 Les actions
E.4.1 L’appel de l’action par le contrôleur général
E.4.2 L’appel des squelettes par les contrôleurs
E.5 Les services

Télécharger le rapport complet