Table des matières Liste des figures .................................................................................................................................. 3 Liste des tableaux ................................................................................................................................ 4 INTRODUCTION GENERALE ......................................................................................................... 5 1. Chapitre 1 : Le contexte du projet ....................................................................................... 7

1.1. Introduction ...................................................................................................................... 8 1.2. Présentation de SIAB ....................................................................................................... 8 1.3. Description de la problématique ....................................................................................... 8

1.3.1. Besoin de l’industriel .................................................................................................... 8 1.3.2. La raison réelle derrière le besoin ................................................................................ 9

1.4. Concepts et technologies ................................................................................................ 10 1.4.1. Manufacturing Execution System (MES) .................................................................. 10 1.4.2. Les standards pour l’intégration ................................................................................. 11

1.4.2.1. Aperçu ................................................................................................................ 11 1.4.2.2. ISA 95 ................................................................................................................. 12 1.4.2.3. MESA ................................................................................................................. 13 1.4.2.4. L’adoption de l’ISA 95 ....................................................................................... 14

1.5. Feuille de route du projet ................................................................................................ 15 1.5.1. Validation de la demande de SIAB ............................................................................ 15 1.5.2. L’utilisation de l’ISA 95 dans le projet d’intégration ................................................. 15

1.5.2.1. L’ISA 95 comme outil d’analyse ....................................................................... 15 1.5.2.2. Le développement d’une solution MES avec l’ISA 95 ...................................... 17 1.5.2.3. L’ISA 95 appliqué dans l’intégration verticale .................................................. 18

1.5.3. Project Plan ................................................................................................................. 19 1.6. Conclusion ...................................................................................................................... 20

2. Chapitre 2 : La phase d’analyse ................................................................................................. 21 2.1. Introduction .................................................................................................................... 22 2.2. Préparation et méthodologie ........................................................................................... 22 2.3. Définition du périmètre du projet et des « business drivers » ........................................ 23

2.3.1. Définition du périmètre du projet ............................................................................... 23 2.3.2. La définition des « business drivers » ........................................................................ 25

2.4. Présentation générale de l’entreprise .............................................................................. 25 2.4.1. La hiérarchie des activités (étape 3) ........................................................................... 25 2.4.2. Hiérarchie des équipements et segments de processus (étape 4) ................................ 26

2.4.2.1. Modèle hiérarchique des équipements ............................................................... 26 2.4.2.2. Segments de processus ....................................................................................... 27

2.5. Zoom sur la fonction production .................................................................................... 28 2.5.1. Collecte des données de la production ....................................................................... 30 2.5.2. Production tracking .................................................................................................... 31

1

2.5.3. Analyse des performances de la production ............................................................... 32 2.6. Zoom sur la fonction maintenance ................................................................................. 32

2.6.1. Collecte des données de la maintenance..................................................................... 33 2.6.2. Maintenance tracking ................................................................................................. 34 2.6.3. Analyse des performances de la maintenance ............................................................ 34

2.7. Zoom sur la fonction qualité ........................................................................................... 35 2.7.1. Collection des données de la qualité .......................................................................... 35 2.7.2. Quality tracking .......................................................................................................... 36

2.8. Conclusions et recommandations relatives à l’analyse .................................................. 37 2.8.1. Architecture potentielle du système ........................................................................... 37

2.9. Prochaines étapes ........................................................................................................... 37 2.10. Conclusion ...................................................................................................................... 38

3. Chapitre 3 : Conception et Réalisation ...................................................................................... 40 3.1. Introduction .................................................................................................................... 41 3.2. Acquisition Automatique des données des machines ..................................................... 41

3.2.1. Aperçu ........................................................................................................................ 41 3.2.2. Les technologies pour l’acquisition automatique des données ................................... 41

3.2.2.1. Les technologies classiques d’acquisition des données ...................................... 41 3.2.2.2. OPC .................................................................................................................... 42 3.2.2.3. Euromap 63 ........................................................................................................ 43 3.2.2.4. Choix final .......................................................................................................... 44

3.2.3. Implémentation OPC .................................................................................................. 44 3.2.3.1. La solution OPC choisie ..................................................................................... 44 3.2.3.2. Création des serveurs OPC ................................................................................. 45 3.2.3.3. Implémentation du DataLogging ........................................................................ 48 3.2.3.4. Le cas particulier des machines d’injection ........................................................ 49

3.3. Développement de la solution MES ............................................................................... 49 3.3.1. Conception de la solution MES .................................................................................. 49

3.3.1.1. Utilisation des modèles d’objets de l’ISA-95 pour l’architecture de la base de données 49 3.3.1.2. La fonctionnalité de la solution MES ................................................................. 52

3.3.2. Développement de la solution MES ........................................................................... 55 3.4. Intégration verticale ........................................................................................................ 59

3.4.1. L’intégration verticale selon l’ISA-95 ........................................................................ 59 3.4.2. Travail réalisé ............................................................................................................. 60

3.5. Les étapes restantes ........................................................................................................ 61 3.6. Conclusion ...................................................................................................................... 62

Conclusion générale .......................................................................................................................... 63 Bibliographie ..................................................................................................................................... 64 Glossaire ............................................................................................................................................ 65 Annexes ............................................................................................................................................. 66

2

Liste des figures

Figure 1.1 : Le fossé entre la fonction production et la fonction administration………….9

Figure 1.2 : Modèle de hiérarchie fonctionnelle…………………………………………12

Figure 1.3 : les onze activités MESA…………………………………………………….13

Figure 1.4 : Modèle des opérations de management industriel…………………………..15

Figure 1.5 : Modèle générique des activités de la fonction production………………….16

Figure 1.6 : structure d’un message échangé selon l’ISA-95…………………………….18

Figure 1.7 : Planning du projet…………………………………………………………...19

Figure 2.1 : Ligne d’intégration technique……………………………………………….23

Figure 2.2 : Modèle de la hiérarchie des équipements…………………………………...26

Figure 2.3 : Illustration des segments de processus……………………………………...27

Figure 2.4 : modèle d’activité de la fonction production………………………………...28

Figure 2.5 : Modèle d’activités de la fonction Maintenance……………………………..32

Figure 2.6 : Modèle d’activités de la fonction qualité…………………………………...34

Figure 2.7 : Architecture potentielle du système………………………………………...37

Figure 3.1 : Cas des technologies classiques d’acquisition des données………………...41

Figure 3.2 : Cas de la technologie OPC………………………………………………….42

Figure 3.3 : Architecture du système d’acquisition des données utilisé…………………44

Figure 3.4 : Arborescence d’un serveur OPC……………………………………………45

Figure 3.5 : étapes de la création d’une chaine d’un serveur OPC………………………46

Figure 3.6 : Création du dispositif OPC…………………………………………………46

Figure 3.7 : création d’un tag OPC………………………………………………………47

Figure 3.8 : Arborescence finale du serveur OPC crée………………………………….47

Figure 3.9 : Modèle d’objets de l’équipement…………………………………………..49

Figure 3.10 : Modèle d’objets des performances des opérations………………………..50

Figure 3.11 : Diagramme des cas d’utilisation de l’application…………………………52

Figure 3.12 : Logo de la solution MES…………………………………………………..54

Figure 3.13 : Création d’un tableau avec Lightswitch…………………………………...56

Figure 3.14 : Edition d’une relation entre deux tableaux avec Lightswitch……………..57

Figure 3.15 : la classe ‘Equipment’ et ses relations……………………………………...57

Figure 3.16 : le rôle d’un Middleware…………………………………………………...59

Figure 3.17 : Logo de NHIBENATE…………………………………………………….60

3

Liste des tableaux

Tableau 2.1 : Aperçu sur les départements et systèmes……………………………………………..26

Tableau 2.2 : Collecte des données de la production………………………………………………..30

Tableau 2.3 : Production tracking……………………………………………………………………31

Tableau 2.4 : Analyse des performances de la production…………………………………………..32

Tableau 2.5 : Collecte des données de la maintenance………………………………………………33

Tableau 2.6 : Maintenance tracking…………………………………………………………………34

Tableau 2.7 : Analyse des performances de la maintenance………………………………………...34

Tableau 2.8 : Collection des données de la qualité…………………………………………………..35

Tableau 2.9 : Quality tracking……………………………………………………………………….36

Tableau 3.1 : Modèles d’objets à utiliser…………………………………………………………….49

Tableau 3.2 : Acteurs de la solution…………………………………………………………………54

4

INTRODUCTION GENERALE

Au cours des dernières décennies, les entreprises industrielles ont investi beaucoup de temps

et d’argent dans des systèmes ERP orientés vers des tâches administratives et dans l’automa-

tisation liée à la production. Dans une optique de valorisation de ces investissements, l’écart

entre les deux niveaux de support technologique devient évident. En effet, les systèmes ERP

n’ont de valeur effective que si on leur fournit des données en temps réel sur la production.

Le concept Manufacturing Execution System (MES) a ainsi vu le jour. Mais la complexité de

son implémentation due essentiellement à l’hétérogénéité entre les deux niveaux précédem-

ment mentionnés devient un handicap pour le bon déroulement d’un projet d’intégration

d’une telle solution.

En réponse aux problèmes rencontrés, l’ISA a décidé de développer le standard ISA-95 pour

réduire les risques, les coûts et les erreurs dus aux projets d’intégration. Ce standard est vite

devenu la référence dans ce domaine.

C’est dans ce cadre que s’insère mon projet de fin d’études réalisé au sein de l’entreprise

SIAB. En effet, SIAB projette d’intégrer ses ateliers de production à son système ERP. Une

telle décision contribuerait à l’optimisation de la gestion industrielle en offrant des données

relatives à la production. Ceci s’introduit dans l’optique qu’on ne peut optimiser ce qu’on

n’estime pas.

Mon projet de fin d’études consiste alors à développer et implémenter une solution MES

allant des machines de production jusqu’au système ERP. Nous utiliserons le standard ISA-

95 pour être assuré quant à son efficience. Ce dernier comprend tout d’abord l’analyse de la

situation actuelle pour déduire les optimisations à mettre en place. Enfin, il sera question

d’implémenter une solution MES développée en interne.

Ce rapport s’articule en trois chapitres détaillés comme suit :

Le premier chapitre est consacré au contexte du projet. Nous y préciserons la demande de

l’industriel, étudierons les différentes propositions possibles répondant à ce besoin pour indi-

quer finalement les démarches à suivre tout au long du projet.

Le second chapitre est dédié à l’analyse selon le standard ISA-95 grâce à laquelle nous ex-

poserons les disfonctionnements et proposerons des solutions d’optimisation.

5

Pour finir, le troisième chapitre détaillera les différentes phases de réalisation de la solution

MES à savoir l’acquisition automatique des données, le développement de l’application et

pour finir l’intégration verticale entre la solution MES et la solution ERP.

6

1. CHAPITRE 1 : LE CONTEXTE DU PROJET

7

1.1. Introduction

Ce chapitre a pour objectif de présenter le cadre du projet. Il est divisé en quatre parties. La

première étant la présentation de l’entreprise d’accueil « SIAB » et de son activité. Ensuite

nous décrirons au niveau de la deuxième partie la problématique posée par l’industriel lors de

la révélation de son besoin. Dans une troisième partie, nous étudierons les différentes solu-

tions répondant au besoin pour n’en choisir que la plus adéquate. Après adoption de la plus

appropriée, nous développerons dans la quatrième et dernière partie la feuille de route du

projet.

1.2. Présentation de SIAB

La Société Industrielle d’Articles de Bureau «SIAB» a été fondée en 1972 par Feu « Mongi

RIAHI ». Elle est spécialisée dans la fabrication des articles de bureaux et notamment dans la

production sous licence des produits «Reynolds by Papermate», marque déposée de la maison

américaine mère «Sanford », aujourd’hui filiale du groupe « NEWELL Rubbermaid ».

L’entreprise exporte ses produits vers l´Europe, le Moyen-Orient, l´Afrique et l´Amérique

latine. Implantée dans la zone industrielle de Mégrine, son emplacement favorise des transac-

tions logistiques plus optimales avec ses fournisseurs et clients.

En 2007, l’usine, déjà leader maghrébin dans son domaine, a connu une expansion significa-

tive de son activité lors du transfert en Tunisie de l’usine Reynolds France. La firme améri-

caine SANFORD a ainsi augmenté la capacité de production de SIAB. En effet, l’usine fonc-

tionne 24h/24h et emploie entre 240 à 450 ouvriers, selon la charge du travail. Elle peut ainsi

produire jusqu’à un million de stylos par jour. Elle est devenue ainsi l’une des principales

filiales de la firme américaine SANFORD REYNOLDS.

SIAB connait deux autres sociétés sœurs à savoir SIAB PLC, qui est le premier centre logis-

tique de packaging offshore en Tunisie ainsi que SIAB Trading qui est responsable de la

commercialisation des produits fabriqués par l’usine.

1.3. Description de la problématique

1.3.1. Besoin de l’industriel

Ce projet est né suite à la demande de l’industriel d’avoir en temps réel les informations rela-

tives à la production. Elles couvrent celles concernant les machines et le personnel, deux res-

sources considérées comme très importantes. Ces informations devraient être collectées puis

8

envoyées sous un format compréhensible par la solution ERP (Entreprise Resource Planning)

déjà implémentée, comme par exemple sous le format de tableurs Excel ou Access1.

Bien qu’il soit clair que son souhait est d’intégrer les machines de production au système ERP

existant, la vraie raison derrière une telle demande reste inexprimée. Celle-ci sera développée

dans ce qui suit.

1.3.2. La raison réelle derrière le besoin

Avec l’expansion que connait l’entreprise, et dans le souci d’optimiser l’organisation, une so-

lution ERP, à savoir Adonix X3 de l’éditeur Sage, a été mise en place. Cette dernière maintient

essentiellement les données et supporte les processus relatifs au niveau administratif. Parmi les

défis à relever, on note celui de la synchronisation entre les ateliers de production et les objectifs

de l’entreprise. Ces objectifs sont essentiellement supportés par le niveau administratif donc

par la solution ERP. Une déconnexion entre les deux parties peut créer une inefficacité opéra-

tionnelle. Tous les départements ont besoin d'une visibilité claire sur les performances des ate-

liers en temps réel.

Même les solutions actuelles supportant la production, comme la solution GPAO (Gestion de

la Production Assistée par Ordinateur), actuellement supportée par l’ERP, ou encore la solution

GMAO (Gestion de la Maintenance Assistée par Ordinateur) présentent des problèmes. Ces

derniers sont essentiellement relatifs à des informations en retour trop lentes et parfois même

biaisées.

Pour résumer, le problème qui est à la cause de l’apparition du besoin est le fossé qui apparait

dans la pyramide de l’organisation entre le niveau de management de la production et le niveau

administratif. Ceci peut être résumé dans la figure 1.1.

Pour accroitre cette transparence requise, les obstacles qui existent au niveau de la communi-

cation entre le niveau administratif et le niveau production doivent être supprimés. Les flux

informationnels entre ces deux niveaux doivent être plus explicites et plus rapides (transparence

et réactivité). Ainsi, le challenge à relever au cours de ce projet est d’intégrer les systèmes

supportant la production au système supportant le niveau décisionnel de l’organisation.

1 Microsoft Excel et Microsoft Access sont deux logiciels de la suite bureautique Microsoft Office.

9

Niveau Production

Administration:Système ERP

Qualité

Livraisons pour clients

Ordres de fabrication

Produits finisProduction Packaging

Commandes

?

Figure 1.1 : Le fossé entre la fonction production et la fonction administration

Avant qu’une approche pour résoudre les demandes de l’industriel ne soit développée, les mé-

rites des normes et technologies qui pourraient être sollicitées doivent être examinés.

1.4. Concepts et technologies

1.4.1. Manufacturing Execution System (MES)

L’intégration est apparue suite au constat fait par les industriels que la plupart des systèmes

ERP sur lesquels ils ont investi des sommes assez onéreuses, ne peuvent être à valeur ajoutée

que lorsqu’ils sont fournis par des données en temps réel. Pour ces systèmes qui corrigent ces

lacunes, le concept de MES (Manufacturing Execution System) est apparu. Ainsi, un MES

n’est pas uniquement une solution de collecte de données en temps réel mais plutôt un support

de la fonction fabrication dans n’importe quelle organisation industrielle. Une solution MES

idéale devrait alors inclure les fonctions suivantes :

• Des fonctions relatives au MES, à savoir les fonctions de planification, d’ordonnan-

cement, de gestion de la qualité…

10

• Assurer la communication avec les systèmes d’informations relatifs au niveau admi-

nistratif d’une organisation. Comme par exemple les ERP.

• Assurer la communication avec l’environnement de production.

Avec l’apparition de cette demande, plusieurs industriels ainsi que les intégrateurs de sys-

tèmes d’information ont, chacun de son côté, essayé de créer des solutions selon son propre

point de vue. Cette apogée, non suivie par une standardisation, a démontré bien des lacunes

pour ces systèmes. Certaines d’entre elles sont citées ci-après.

• Patchwork : ce problème est rencontré lors de l’utilisation de plusieurs logiciels en-

semble. Ces solutions ne sont pas coordonnées entre elles et donc ne donnent pas un

résultat global positif.

• Pas de base de données commune : Toutes les parties du système de production ont

besoin d'une base de données spécifique. Bien qu'une grande partie de ces données

nécessaires soit déjà présente au niveau de l’ERP, elles ne sont pas toujours présentes

dans le niveau de détail requis par le MES.

• Temps de réponse important : La non concordance entre les différents systèmes utili-

sés fait apparaître les problèmes de redondance. Ainsi, les problèmes de bugs du sys-

tème global et de temps d’attente importants apparaissent.

Etant donné les problèmes rencontrés à cause de la banalisation des solutions MES, une nor-

malisation de ses fonctions s’est avérée plus que nécessaire. Les standards développés seront

étudiés dans la partie suivante.

1.4.2. Les standards pour l’intégration

1.4.2.1. Aperçu

Une recherche sur les standards existant pour l’implémentation de solutions MES peut créer

une confusion. En effet, une question se pose : Pourquoi autant de références ?

La réponse est que chaque modèle a une perspective assez différente des autres. Le choix

dépend alors du besoin. Certains standards sont plus adaptés aux industries de process alors

que d’autres sont orientés à des solutions déjà existantes.

Pour notre cas, seuls les standards ISA-95 et MESA seront étudiés. Puisque les autres ne sont

pas les mieux adaptés à notre projet. Comme par exemple le standard NAMUR recommandé

pour les industries de process (chimiques ou pharmaceutiques) ou encore le standard SCOR

11

(Supply Chain Operations Reference) qui est plutôt orienté à la fonction Supply Chain Ma-

nagement qu’à la fonction fabrication.

1.4.2.2. ISA 95

Suite au besoin des industriels de mettre fin à l’écart entre les systèmes ERP et le niveau des

ateliers de production, l’ISA (International Society of Automation) s’est mise à développer

un standard. Ce dernier œuvre à combler ces lacunes et aussi à réduire les risques, couts et

erreurs dus au déploiement de systèmes entre ces deux niveaux.

Le but du standard est ainsi de définir ce qu’est un MES. Il définit pour cela un modèle de

hiérarchie fonctionnelle qui distingue deux domaines dans une entreprise industrielle. Le pre-

mier domaine étant relatif à l’administration de l’entreprise (Enterprise Domain) et qui fait

référence au système ERP, il est affecté au niveau 4. Le deuxième domaine est quant à lui

relatif aux ateliers de production, à savoir le système MES (niveau 3) et les systèmes de con-

trôle de la production (niveau 2 et inférieur). Cette architecture est représentée, d’une façon

simplifiée, dans la figure 1.2.

L’ISA-95 a été défini comme une méthodologie à suivre pour assurer une meilleure intégra-

tion. Il comprend cinq parties distinctes à savoir :

• La partie 1 qui présente des modèles et des terminologies pour analyser et standardiser

l’échange d’informations entre le niveau 4 et le niveau 3.

• La partie 2 qui présente un modèle de données pour standardiser la structure et le

contenu des flux informationnels déjà définis dans la partie 1 du standard.

• La partie 3 qui définit quatre groupes d’activité au sein des activités de fabrication. A

savoir la production, la maintenance, la qualité et l’inventaire.

• La partie 4 standardise les flux informationnels entre les quatre opérations définies

dans la partie 3. Cette partie n’est pas encore très utilisée puisque récemment apparue

(fin de l’année 2012).

• La partie 5 standardise les messages échangés entre l’ERP et le système MES.

12

Business Planning and Logistics

Manufacturing Operations & Control

BatchControl

Continuous Control

Discrete Control

Niveau 4

Niveau 3

Niveau 2, 1, 0

Couche ERP

Couche MES

Couche de contrôle de

la production

Enterprise Domain

Control Domain

Figure 1.2 : Modèle de hiérarchie fonctionnelle [1]

1.4.2.3. MESA

L’association MESA (Manufacturing Execution Solutions Association) a une approche assez

pratique décrivant onze activités pour le support du management de la production. Ces der-

nières sont illustrées dans la figure 1.3.

Selon cette approche, les autres systèmes d’information sont définis comme étant des utilisa-

teurs ayant accès à la solution MES. Ces onze activités couvrent celles au sein d’une usine

d’une façon assez approfondie. Incluant ainsi la maintenance, la planification, l’ordonnance-

ment ainsi que la qualité.

13

MES

Operations/ Detail

Scheduling

Resource allocation &

Status

Process Management

Quality Management

Product tracking & genealogy

Performance anlysis

Dispatching producton

units

Document control

Data collection/ Acquisition

Maintenance Management

Labour management

Figure 1.3 : les onze activités MESA [2]

1.4.2.4. L’adoption de l’ISA 95

Un retour vers l’historique montre que le comité de développement de l’ISA-95 a sélectionné

le modèle MESA comme un point de départ. Mais ne la pas indistinctement adopté. Le modèle

ISA-95 est plus clair et plus logique ; il offre une description détaillée des activités pouvant

avoir lieu dans chaque entreprise industrielle, qu’elle soit automatisée ou pas, et définit leurs

frontières. Il définit aussi les relations entre les différentes activités. Pour ce projet, il serait

plus judicieux d’utiliser l’ISA-95 que le modèle définit par l’association MESA. En effet, ce

dernier se base plutôt sur les fonctionnalités offertes par les intégrateurs de solutions MES

que sur un modèle indépendant. En outre, le modèle MESA ne spécifie ni les connections

entre les différentes activités ni les flux d’informations. Il lui manque aussi une explication

détaillée des onze différentes activités.

De plus, les modèles définis par l’ISA-95 peuvent être utilisés comme une structure normali-

sée pour l’entreprise. Si de nouvelles opérations voient le jour ou soient modifiées pour ré-

pondre à un nouveau besoin ou pour optimiser des processus, la solution peut être modulée

selon le standard. Il suffit de trouver le bon modèle défini par l’ISA-95 pour standardiser la

nouvelle activité et être sûr qu’elle se conformera aux autres opérations déjà existantes et sera

dans les plus brefs délais efficiente.

Une fois l’aspect technologique de la solution et le standard choisis, nous passons maintenant

à la réalisation d’une feuille de route du projet.

14

1.5. Feuille de route du projet

1.5.1. Validation de la demande de SIAB

Le projet consiste donc à implémenter une solution MES au sein de l’entreprise SIAB. Cette

implémentation sera réalisée conformément au standard ISA-95.

Les objectifs du projet sont multiples. D’une part, il s’agit d’analyser le besoin de l’entreprise

pour en déduire les fonctions de la solution MES les plus importantes à implémenter. En

deuxième lieu, il s’agit de développer ces fonctions sollicitées et d’adopter les solutions tech-

nologiques les plus adéquates pour l’efficience de la solution. Enfin, nous intégrerons la so-

lution MES développée aux autres systèmes d’information déjà existant.

1.5.2. L’utilisation de l’ISA 95 dans le projet d’intégration

L’ISA-95 est une méthode, une façon de penser, de travailler et de communiquer. Le standard

peut être déployé de façons différentes selon le besoin, allant de l’analyse jusqu’au dévelop-

pement des solutions MES. Pour nos trois objectifs ; analyse, développement et intégration,

nous nous baserons sur ce standard. Chaque partie du standard est spécifique à un objectif.

1.5.2.1. L’ISA 95 comme outil d’analyse

Le but de l’analyse est d’avoir un aperçu sur les exigences de l’entreprise pour ce nouveau

système. L’analyse selon le standard ISA-95 offre une meilleure idée sur les différents aspects

de l’organisation. Les parties 1 et 3 du standard seront utilisées.

En effet, le standard développe, dans sa première partie, un modèle fonctionnel qui reprèsente

une structure organisationnelle de fonctions pouvant être adoptées au sein de l’entreprise. Il

prèsente de la même manière, les frontières entre les deux domaines ‘Enterprise’ et ‘Control’.

Douze fonctions sont présentées. Ce modèle sera utilisé au cours de l’analyse pour déduire

les fonctions au sein de notre entrprise, définir chacune, repérer les flux en relation pour enfin

déduire les manquements dans chaque fontion. Ce modèle est représenté dans la figure 1.4.

15

Figure 1.4 : Modèle des opérations de management industriel [3]

La partie 3 du standard quant à elle représente le même modèle mais en zoomant sur les

opérations propres à la fonction production (la région avec un fond jaune sur la figure 1.4). A

savoir, la production, la maintenance, la qualité et l’inventaire. A noter qu’une opération peut

englober plusieurs tâches. Pour chaque opération, un modèle générique d’activités est

représenté. Il définit les tâches propres à chaque opération. Ce modèle est représenté par la

figure 1.5.

D’autres modèles définis par ces deux parties du standard sont définies et seront importantes

pour l’analyse. Ces derniers seront présentés plus en détail tout au long du chapitre 2 de ce

rapport qui expose la phase d’analyse réalisée.

16

Detailed scheduling

Dispatching

Execution management

Resource management

Definition management

Data collection

Tracking

Operations request

Operations Capability

Operations response

Operations definitions

Analysis

Figure 1.5 : Modèle générique des activités de la fonction production [4]

1.5.2.2. Le développement d’une solution MES avec l’ISA 95

Les flux informationnels au sein d’une entreprise industrielle peuvent se révéler assez com-

plexes. Ainsi, développer un autre système qui gérera une partie de ces informations peut

s’avérer une mission impossible. Pour cela, utiliser l’ISA-95 comme base pour le développe-

ment d’applications MES fait que notre solution soit standardisée, bien conçue et sans oublier

plus simple à interfacer avec les autres systèmes d’informations déjà existant.

La partie 2 du standard prend en charge la standardisation du développement. Elle offre des

modèles d’objets relatifs à chaque flux d’informations présenté par le modèle fonctionnel

défini dans la première partie du standard.

Pour cela, cinq modèles de ressources ont été développés ; personnel, équipement, compo-

sants d’équipements (Physical asset), matière et segment de processus (Process segments).

Ces cinq modèles de ressources forment la base de quatre autres modèles à savoir ; Operation

definition, Operation schedule, Operation performance et Operation capability. Autrement

dit, tout flux d’information entre le système MES et ERP doit contenir des informations

propres à au moins un modèle de ressources. Chaque flux appartient à une de ces catégories :

la disponibilité des ressources (Capability), les produits que l’usine fabrique (Product Defini-

tion), la planification de la production (Production schedule) et les résultats réalisés par la

production (Performance).

17

Les modèles seront plus développés dans la partie 3.3.1 de ce rapport. A noter aussi que la

partie 4 du standard ISA-95 définit des modèles pour les opérations propres à la fonction

fabrication mais ne sera pas utilisée au cours de ce projet car récemment développée et donc

indisponible.

Pour autant, ces modèles ne présentent pas une solution miracle pour le développement de

solutions MES mais l’encadrent.

1.5.2.3. L’ISA 95 appliqué dans l’intégration verticale

• Qu’est-ce qu’une intégration verticale ?

L’intégration verticale concerne l’intégration allant de l’administration aux ateliers de pro-

duction. Elle est l’opposé de l’intégration horizontale qui se préoccupe de l’intégration de la

Supply Chain entière relative à la collaboration de l’entreprise avec ses fournisseurs et clients.

Selon l’ISA-95, l’intégration verticale est celle entre les domaines ‘Enterprise’ et ‘Control’

définis dans le modèle de hiérarchie fonctionnelle.

• Utilisation de l’ISA 95

Les parties 1 et 2 du standard, respectivement utilisées pour l’analyse et le développement,

formulent les informations à échanger entre l’ERP et le MES. Ces deux parties, bien qu’elles

standardisent la structure des messages, ne décrivent pas la façon avec laquelle les messages

seront traités ni au niveau du système émetteur ni celui du système récepteur.

Pour cela, l’ISA-95 définit plusieurs cas de transactions. Une transaction peut être vue comme

étant une conversation entre l’ERP et le MES. Une transaction est propre à un message, et

vice versa. Un message, selon le standard, contient deux parties distinctes ; Application Iden-

tification Area et Data Area. La première accueillant des données dont le système a besoin

pour connaitre d’où vient le message et vers qui il sera envoyé. La deuxième partie contient

un verbe et un nom dont la combinaison crée une commande. Le nom est relatif à l’objet

défini par les parties 1 et 2 du standard. Quant au verbe, on utilise le plus adéquat selon le cas

d’utilisation, pour chaque cas, un modèle est défini ; Push, Pull ou Publish.

• Pull model : un système demande une information de l’autre système

• Push model : un système envoie des données de son propre gré à un autre système.

• Publish model : un système publie des informations sans savoir si les autres systèmes

concernées en auront besoin ou pas.

18

La structure d’un message selon l’ISA-95 est illustrée dans la figure suivante :

Data Message

Application Identification Area

Data Area

Verb Area

NounArea

Figure 1.6 : structure d’un message échangé selon l’ISA-95 [5]

1.5.3. Project Plan

Après validation du projet ainsi proposé à la direction de SIAB, un planning prévisionnel

comportant des deadlines a été adopté pour notre projet. La durée a été estimée à 6 mois,

commençant de mi-Mars, vu que l’étude approfondie du standard et la mise en place d’un

plan d’actions conforme aux directives de celui-ci a pris à peu près 50 jours.

Le graphe suivant décrit la chronologie du projet :

19

Figure 1.7 : Planning du projet

1.6. Conclusion

Au cours de ce chapitre, nous avons introduit l’entreprise et exposé son besoin. Une étude

bibliographique nous a permis de connaitre les technologies et standards pouvant répondre à

ce besoin pour dégager les mieux adaptées pour ce projet. Nous avons enfin adopté un plan

d’actions à suivre tout au long du projet.

Le chapitre suivant s’intéressera à l’étape de l’analyse ISA-95 réalisée lors de ce projet.

DÉBUT DU PROJET

EMISSION DU BLUEPRINT

FIN DE LA PHASE DE CONCEPTION

PREMIER ESSAI SUR TERRAIN

DÉBUT DE L'IMPLÉMENTATION

FIN DU PROJET

18 Mar 18 Apr 18 May 18 Jun 18 Jul 18 Aug 18 Sep 18 Oct

20

2. Chapitre 2 : La phase d’analyse

21

2.1. Introduction

Avant la réalisation de la solution souhaitée, une analyse approfondie sur la situation actuelle

est nécessaire. Cette analyse fera le tour des différentes activités liées à la fabrication pour

décrire les manquements et indiquer les solutions envisageables. A rappeler que notre analyse

se basera sur le standard ISA-95.

Dans ce chapitre, nous présenterons tout d’abord la méthodologie à suivre. Ensuite, nous in-

diquerons le périmètre de notre projet. Après, nous réaliserons une présentation générale de

l’entreprise. Enfin, nous réaliserons des zooms sur les différentes fonctions liées à la fabrica-

tion selon le standard ISA-95.

2.2. Préparation et méthodologie

L’analyse présente la base pour dévoiler les améliorations potentielles et les exigences sou-

haitées du nouveau système. Généralement, une analyse ISA-95 comprend les dix étapes sui-

vantes :

1. Un tour de l’usine, pour avoir une vue globale des différents centres de production.

2. Définition des business drivers pour en déduire les objectifs de l’entreprise envers le

projet d’intégration.

3. Définir les systèmes d’informations déjà utilisés et les départements auxquels ils sont

reliés.

4. Décrire la structure physique de l’entreprise.

5...10 Les étapes suivantes (5-10) fournissent chacune une image détaillée de l’une des

activités relatives à la fonction fabrication. Autrement dit, avec ces étapes, nous ferons un

zoom sur le niveau 3 défini par l’ISA-95 comprenant les fonctions production, mainte-

nance, qualité et inventaire.

Les parties 1 et 3 de l’ISA-95 fournissent plusieurs modèles comme outil principal au cours

de ces étapes. Tout au long de la phase d’analyse, la description de la situation actuelle et

celle souhaitée après le projet d’intégration est essentielle. Cette description inclut ainsi les

besoins nécessaires, les besoins ‘agréables à avoir’ et les points préoccupants pour chaque

activité.

La conduite de l’analyse nous mène à choisir une méthode pour la collecte des informations.

Nous avons choisi d’interviewer le personnel plutôt que de leur demander des rapports à

rendre. L’avantage des entretiens est qu’ils contribuent à ce que le personnel adopte les chan-

gements résultant de l’analyse. En effet, grâce à cette méthode, ils ont pu se considérer comme

22

partie prenante dans le projet en ayant la chance de dévoiler leurs demandes et exigences.

L’implication du personnel est un avantage considérable dans le projet d’implémentation d’un

changement.

Le résultat de l’analyse ISA-95 sera rendu sous forme de documents. Le premier est le blue-

print dont l’objet est de décrire la situation future désirée et les origines des exigences. Ce

document n’est pas celui qui sera rendu à la direction de l’entreprise pour valider le projet

d’analyse mais sera plutôt utilisé comme base pour le développement de la solution.

Pour finir, une présentation pour expliquer les résultats, les conclusions et les recommanda-

tions sera faite.

2.3. Définition du périmètre du projet et des « business drivers »

2.3.1. Définition du périmètre du projet

Au niveau du paragraphe 1.5.2.1 de ce rapport, nous avons mentionné que l’ISA-95 définit

un modèle pour chaque opération propre à la fonction fabrication. Chaque opération englobe

des tâches qui définissent des relations entre elles.

Il est important de préciser le but et le périmètre de l’analyse ISA-95 et de rester dans leur

optique. Autrement, le temps et le budget nécessaires au développement du projet peuvent

significativement devenir onéreux. Aussi, certaines fonctions de la solution implémentée se-

ront sans valeur ajoutée et non adoptées par le personnel. Pour cela, l’annexe A de la partie 3

de l’ISA-95 définit une ligne fictive d’intégration qui détermine les tâches à développer.

Pour notre projet, les tâches qui seront développées sont celles au-dessus de la ligne d’inté-

gration (en rouge) sur la figure 2.1. Ainsi, l’opération Inventaire est hors du périmètre du

projet vu qu’elle est supportée par l’ERP. Quant aux autres opérations, les tâches choisies

sont celles liées à la collecte des données (Data Collection), à la transformation de ces der-

nières en des informations compréhensibles par les différents systèmes (tracking) et enfin à

l’analyse des données en vue d’optimiser ou de corriger (Performance Analysis).

A noter aussi que le standard définit d’autres opérations propres à la fonction fabrication

comme le management de la documentation ou encore le management de la sécurité. Aucune

ne sera développée puisqu’elles ont été définies comme étant hors du périmètre du projet.

23

Level 2 Level 2

Detailed production scheduling

Production dispatching

Production execution

management

Production resource

management

Production definition

management

Production data

collection

Production tracking

Production schedule

Production Capability

Production performance

Product definition

Production performance analysis

Production

Detailed Inventory scheduling

Inventory dispatching

Inventory execution

management

Inventory resource

management

Inventory definition

management

Inventory data

collection

Inventory tracking

Inventory schedule

Inventory Capability

Inventory performance

Inventory definition

Inventory analysis

Inventory

Detailed Maintenance

scheduling

Maintenance dispatching

Maintenanceexecution

management

Maintenance resource

management

Maintenancedefinition

management

Maintenance data

collection

Maintenance tracking

Maintenance schedule

MaintenanceCapability

Maintenanceperformance

Maintenance definition

Maintenance analysis

Maintenance

Detailed Quality

scheduling

Quality dispatching

Quality execution

management

Quality resource

management

Quality definition

management

Quality data

collection

Quality tracking

Quality schedule

Quality Capability

Quality performance

Quality definition

Quality analysis

Quality

Figure 2.1 : Ligne d’intégration technique

24

A noter que le modèle d’activité pour chaque opération sera plus détaillé (et plus clair) au

niveau du zoom sur chaque fonction (paragraphes 2.5, 2.6 et 2.7).

2.3.2. La définition des « business drivers »

L’implémentation stratégique d’une solution MES a plusieurs avantages. L’annexe C de la

partie 1 de l’ISA-95 définit des business-drivers qui clarifient ce que l’entreprise doit optimi-

ser pour arriver à son but. Pour ce projet, trois business drivers ont été adoptés :

• Réduction du temps de cycle : pour cela, on doit identifier les sources des problèmes

causant des retards et les corriger.

• Maximisation de l’efficience de l’équipement : il est question de maximiser l’effi-

cience de l’équipement dans le processus de production.

• Amélioration de la planification : pour cela, l’accès en temps réel aux performances

de la production ainsi qu’à l’historique est impératif.

Après avoir déterminé l’objet et le périmètre de l’analyse ISA-95, nous passons maintenant à

la description des caractéristiques de l’entreprise. Nous utiliserons les modèles fournis par le

standard, qui entrent dans le périmètre du projet, dans l’ordre suivant :

• Modèle de la hiérarchie fonctionnelle (étape 3)

• Modèle hiérarchique des équipements et segments de processus (étape 4)

• Modèle de l’opération Production (étape 6)

• Modèle de l’opération Maintenance (étape 7)

• Modèle de l’opération Qualité (étape 8)

Nous noterons l’absence de l’étape 5 dans ce projet relative à l’analyse des fonctions hors du

domaine fabrication comme le service achat, financier ou encore marketing.

2.4. Présentation générale de l’entreprise

2.4.1. La hiérarchie des activités (étape 3)

Nous utilisons le modèle de la hiérarchie fonctionnelle (voir figure 1.2) pour avoir une vue

globale des différents départements de l’entreprise, ainsi que des systèmes informatiques sup-

portant chaque niveau.

Pour choisir les départements et les systèmes inclus dans la fonction fabrication, le standard

donne des critères relatifs aux activités qui serviront de ligne directrice. Parmi eux, toujours

dans l’optique de ce projet, on trouve :

25

• L’activité est essentielle pour la fiabilité.

• L’activité est essentielle pour l’efficience.

• L’activité est essentielle pour la qualité du produit fabriqué.

Le tableau 2.1 qui suit indique les résultats obtenus après la conduite de cette étape.

Tableau 2.1 : Aperçu sur les départements et systèmes

Départements Systèmes

Niveau 4 Qualité, IT, Achat, Planifi-cation

ERP Sage ADONIX X3, GMAO Optimaint

Niveau 3 Production, Maintenance, Qualité, Logistique, Planifi-cation, Achat

ERP Sage ADONIX X3, GMAO Optimaint

Niveau 2, 1, 0 Production, Maintenance Aucun

Nous noterons qu’aucun système ne supporte les niveaux 2, 1, 0 généralement supporté par

des systèmes de supervision et/ou d’alarme.

2.4.2. Hiérarchie des équipements et segments de processus (étape 4)

2.4.2.1. Modèle hiérarchique des équipements

Ce modèle (voir figure 2.2) est utilisé pour décrire la hiérarchique physique de l’entreprise.

Autrement dit, il aide à déterminer les équipements entrant dans le processus de fabrication,

les zones de stockage des matières ainsi que d’indiquer le type de l’industrie (lot (batch),

discrète ou continue).

Pour ce modèle, l’ISA-95 indique cinq niveaux arborés du plus haut au plus bas ci-après :

Entreprise, Site, Zone qui indique les départements de fabrication, Centre de travail qui

peut être selon le type d’industrialisation une cellule de processus, une unité de production,

une ligne de production ou encore une zone de stockage. Le cinquième et dernier niveau est

l’Unité de travail qui selon le type du centre de travail peut être une unité, une cellule de

travail ou une unité de stockage.

Le tableau de l’annexe A dans ce rapport décrit la hiérarchie des équipements de SIAB. Notre

modèle indique la présence de zones de stockage ainsi que de lignes de production puisque

SIAB utilise des processus discrets (cas où le résultat de la production est quantifiable).

26

Figure 2.2 : Modèle de la hiérarchie des équipements [6]

2.4.2.2. Segments de processus

Après avoir défini la hiérarchie physique de l’entreprise, nous nous concentrons à présent sur

les processus. En effet, précédemment nous avons défini les machines entrant dans la produc-

tion sans décrire le travail sollicitant chacune. Aussi, certains processus n’utilisent pas de

machines comme l’emballage dans notre cas. Pour chaque processus, nous avons décrit les

équipements, les systèmes informatiques et la matière qu’il utilise, le nombre de personnel

pour chaque opération ainsi que pris des notes comme par exemple le nombre d’échantillons

pris pour le contrôle de la qualité ou encore le pesage des lots fabriqués.

Les processus relevés lors de l’analyse sont les suivant :

• Stockage de la matière première.

• Injection plastique des différents composants du stylo.

• Marquage si nécessaire des corps en plastique.

• Stockage des produits semi-finis (provenant du centre injection et/ou marquage).

• Extrusion des tubes en plastique pour le centre cartouche.

• Fabrication des cartouches

27

• Stockage des cartouches.

• Assemblage Stylos.

• Emballage.

Stockage M.P

Injection

Extrusion

Fabrication des cartouches

Assemblage Stylos

Marquage

Emballage

Stockage S.F

Stockage des cartouches

Stockage commun

Figure 2.3 : Illustration des segments de processus

Nous passons à présent à l’analyse des activités liées à la fonction fabrication. Nous réalise-

rons pour cela un zoom sur chacune des activités (production, maintenance et qualité).

2.5. Zoom sur la fonction production

Cette étape représente la première des quatre modèles des ‘operations management’ définis

au niveau de l’ISA-95 Part 3. Pour chaque activité qui a été requise dans le cadre de ce projet,

nous déterminerons le département et personnes sollicités ainsi que nous décrirons le proces-

sus actuel tout en proposant des points d’optimisation de l’activité en question.

Toutes les activités sont reliées entre elles. Ceci rend très difficile, pour ne pas dire impos-

sible, le fait de ne discuter que des aspects d’une seule activité lors d’une réunion avec les

personnes ad-hoc. Par exemple, il y a un lien très étroit entre l’activité ‘Production data col-

lection’ et ‘Production tracking’ ou encore ces deux dernières avec l’activité ‘Production per-

formance analysis’. Ceci a conduit à présenter l’approche de ces trois activités ensemble lors

28

de chaque réunion pour mettre le responsable dans le cadre du projet. La dextérité de cet

exercice apparait alors dans l’aptitude à ne développer qu’une activité, avec ses flux informa-

tionnels qui forment l’interface avec les autres activités de production, à la fois.

La figure suivante montre le modèle d’activités de la fonction production définit par le stan-

dard ISA-95.

Figure 2.4 : modèle d’activité de la fonction production [7]

Pour l’analyse de chaque activité (toutes les fonctions comprises), nous avons choisi un mo-

dèle résumant le travail réalisé. Nous utiliserons ainsi un tableau comportant les informations

suivantes :

• Description de la situation actuelle.

• Flux informationnels : ceci décrit les relations existant entre l’activité en question et

les autres comme démontré sur le modèle de chaque activité.

• Points préoccupants.

• Besoins nécessaires.

• Les agréables à avoir.

29

2.5.1. Collecte des données de la production

Cette activité est relative à l’acquisition des données de production et leur archivage. L’ana-

lyse de cette activité a donné les points suivant :

Tableau 2.2 : Collecte des données de la production

Description de la situation actuelle Actuellement, un sous-service affecté au service de planification assure ce processus. Il est

question de collecter, chaque fin de semaine, les dossiers de production pour chaque ordre

de fabrication fini. Il comprend, le bon de travail, le rapport de production, le bon de sortie

matières, les bons de travail maintenance relatifs aux interventions au cours de la fabrica-

tion et les interventions qualité. Le dossier n’est clôturé que lorsque les données qui y sont

inscrites sont manuellement retransmises au système Sage ERP X3. Flux Informationnels Les informations reçues du niveau 2 reflètent les processus en cours et les ressources solli-

citées. Il est important d’automatiser ces informations et de trouver une solution pour com-

bler le vide entre les niveaux 2 et 3 dans l’activité de production.

Les informations allant aux deux activités ‘Production tracking’ et ‘analyse des perfor-

mances de la production’ sont relatives à l’historique et doivent être stockées sur une base

de données commune pour qu’elles soient accessibles.

Les autres informations déterminant l’interface avec les activités hors du périmètre du pro-

jet ne seront pas prises en compte.

Points préoccupants Ces points sont exclusivement liés à la collecte manuelle des données. En effet, ces der-

nières ne sont pas disponibles en temps voulu, imprécises, sans oublier le fait qu’elles peu-

vent être non objectives.

Besoins nécessaires L’adoption d’un système de collecte automatique des données s’impose. L’analyse a aussi

révélé que seulement trois types de données collectées seront importants selon le périmètre

du projet. Ces informations concernent la quantité, l’historique des statuts de la machine

(marche ; arrêt ; changement de série) et les erreurs machines qui ont eu lieu lors de la

production.

30

Les agréables à avoir Des interfaces avec les activités « Production Dispatching » et « Production Execution Ma-

nagement » pour que les responsables production soient les plus réactifs possible aux chan-

gements dus au retards de production et autres phénomènes sollicitant le changement de

planning de la production.

2.5.2. Production tracking

Cette activité est définie comme étant celle qui prépare les données relatives à la production

pour le niveau 4. L’analyse de cette activité a donné les points suivant.

Tableau 2.3 : Production tracking

Description de la situation actuelle Cette activité est actuellement liée à celle de la collecte des données de production. Aucune

distinction entre les deux n’existe. Les données de la production sont manuellement re-

transmises au système ERP.

Flux Informationnels Les informations échangées avec l’activité ‘analyse des performances de la production’

sont relatives à la performance de la production.

Points préoccupants La compatibilité des données échangées entre l’ERP et la solution MES doit être prise en

considération.

Toutes les données de l’activité ‘analyse des performances de la production’ ne sont pas

exclusivement destinées à l’activité ‘production tracking’.

Besoins nécessaires Une intégration verticale entre la solution MES à implémenter et l’ERP s’avère indispen-

sable. Elle automatisera le rôle de l’activité en question qui est actuellement manuelle.

Les agréables à avoir Une interface avec la planification de la production est un plus. Ainsi, les plannings de la

production peuvent être automatiquement mis à jour selon les capacités et performances

actuelles de la production.

31

2.5.3. Analyse des performances de la production

C’est l’activité qui analyse et crée des rapports sur les performances de la production.

L’analyse a donné les points suivant.

Tableau 2.4 : Analyse des performances de la production

Description de la situation actuelle L’historique de la production est rarement consulté pour prendre en considération les ré-

elles capacités de la production lors de la planification. Aussi, des tableaux de bord existent

dans chaque centre de production, mais sont très peu exploités.

L’activité de l’analyse de la performance de la production est ‘vivifiée’ à chaque réalisation

des bilans.

Flux Informationnels On reçoit de l’activité ‘collecte des données de la production’ les données machines sur les

états de la machines, les quantités produites et les erreurs.

Points préoccupants La culture ‘analyse des performances’ n’est pas très considérée. L’explication de son im-

portance par rapport aux autres activités est importante.

Besoins nécessaires +L’analyse de la traçabilité des ressources (matière, équipement et personnel)

+L’analyse des processus de production

Les agréables à avoir Des outils de simulation et de création de KPI lors des projets d’optimisation industrielle.

2.6. Zoom sur la fonction maintenance

La fonction maintenance forme la base pour l’analyse et la description de toutes les activités

qui lui sont relatives. Son modèle d’activités définit par l’ISA-95 est présenté sur la figure

suivante.

L’analyse de la fonction maintenance est détaillée dans les paragraphes qui suivent.

32

Figure 2.5 : Modèle d’activités de la fonction Maintenance [8]

2.6.1. Collecte des données de la maintenance Tableau 2.5 : Collecte des données de la maintenance

Description de la situation actuelle Lors de chaque intervention maintenance, l’intervenant remplie un document appelé bon

de travail. Ce bon est ensuite manuellement retransmis sur la solution GMAO ‘Optimaint’.

Flux Informationnels Les informations venant des niveaux 1,2 sont relatives aux causes d’arrêt.

Points préoccupants Les informations sont parfois biaisées. Parmi ces informations on cite le temps d’interven-

tion, la cause de l’arrêt ou encore le matériel utilisé.

De plus, parfois, des bons de travail ne sont pas retransmis sur ‘Optimaint’ par oubli.

Besoins nécessaires Automatiser la collecte de ces données en minimisant le plus possible les saisies manuelles. Les agréables à avoir Aucun.

33

2.6.2. Maintenance tracking Tableau 2.6 : Maintenance tracking

Description de la situation actuelle Aucun système d’automatisation de cette activité n’existe. Actuellement, elle est liée à l’ac-

tivité de la collection des données de la maintenance qui retransmet manuellement ces don-

nées sur la solution GMAO.

Flux Informationnels Les flux de l’activité ‘collecte des données de la maintenance’ concernent des données sur

le personnel impliqué, les causes, le matériel utilisé et e temps d’opération.

Points préoccupants Les mêmes que pour l’activité précédente.

Besoins nécessaires Une interface avec la solution GMAO automatisant cette interface. Une intégration verti-

cale est la solution la mieux adaptée.

Les agréables à avoir Aucun.

2.6.3. Analyse des performances de la maintenance Tableau 2.7 : Analyse des performances de la maintenance

Description de la situation actuelle Les bons de travail de la maintenance sont manuellement retransmis sur la GMAO ‘Opti-

maint’. Aucune activité d’analyse des performances de la production n’est considérée dans

le cas présent.

Flux Informationnels Les données sur l’historique de la maintenance viennent de l’activité ‘collecte des données

de la maintenance’. Points préoccupants Les données de l’activité ‘collecte des données de la production’ seront aussi considérées.

En effet, elles impliquent des données sur les états de la machines ainsi que sur les erreurs.

Besoins nécessaires

34

L’implémentation d’un module d’analyse des données de la maintenance est nécessaire

pour créer un support pour d’éventuels projets d’optimisation de cette fonction.

2.7. Zoom sur la fonction qualité

Pour la fonction qualité, nous noterons que l’activité ‘Analyse des performances de la qua-

lité’ n’est pas considérée dans le périmètre du projet. La raison derrière cela est que cette ac-

tivité ne peut réellement implémentée en aussi peu de temps.

Le modèle d’activité de la fonction qualité définit par l’ISA-95 est présenté sur la figure qui

suit.

Figure 2.6 : Modèle d’activités de la fonction qualité [9]

2.7.1. Collection des données de la qualité Tableau 2.8 : Collection des données de la qualité

Description de la situation actuelle Les données relatives à la qualité sont manuellement inscrites sur le dossier de production

de chaque ordre de fabrication.

35

Flux Informationnels Les données inscrites ne sont relatives qu’au nombre de rebus. Les causes de ces derniers

ne sont pas considérées. Une exception existe pour les machines du centre d’injection plas-

tique, où des informations sur les moules beaucoup plus détaillées sont inscrites. Points préoccupants Les informations relatives à la qualité sont très basiques et ne reflètent pas des données qui

pourraient être utilisées dans des projets de gestion de la qualité. Besoins nécessaires L’informatisation de la saisie des données. Les agréables à avoir Développer d’autres données pour la qualité.

2.7.2. Quality tracking Tableau 2.9 : Quality tracking

Description de la situation actuelle Les quelques informations relatives à la qualité sont retransmises au système ERP lors de

la saisie des informations de la production. Flux Informationnels Même cas que pour l’activité précédente. Points préoccupants Les données relatives à la qualité sont considérées comme des données relatives à la pro-

duction, sauf pour le cas des machines d’injection. Besoins nécessaires Distinguer les données de la qualité des données de la production.

Les agréables à avoir Aucun.

36

2.8. Conclusions et recommandations relatives à l’analyse

La dernière, et plus importante, étape dans l’analyse ISA-95 est la rédaction des conclusions

et recommandations. Cette partie est celle qui a été présentée à la direction de SIAB. Elle

inclut un résumer des problématiques repérées lors de l’analyse et les recommandations issues

pour enfin décrire une architecture potentielle du système à implémenter et qui contribuerait

à répondre à nos besoins.

Dans ce rapport, seule l’architecture potentielle du système sera présentée car les autres par-

ties ont déjà été développées au cours de ce chapitre lors du zoom sur chaque activité.

2.8.1. Architecture potentielle du système

Dans la description de la conclusion, une étape très importante est celle de l’architecture po-

tentielle du système. Elle est résumée dans un schéma utilisant à la base le modèle des opé-

rations de management industriel (figure 1.4), démontrant les activités les plus importantes à

intégrer ainsi que les flux informationnels qui feront le transfert des données entre les diffé-

rents systèmes.

Ce schéma est illustré dans la figure 2.7 de ce rapport. Il montre les activités que chaque

système gère et les flux d’informations à automatiser.

2.9. Prochaines étapes

Selon la conclusion et les recommandations, nous avons déterminé les étapes à réaliser pour

le projet d’intégration. Ces étapes sont les suivantes :

• Acquisition automatique des données.

• Développement et mise en place d’une solution MES.

• Intégration verticale entre les différents systèmes d’informations utilisés.

37

2.10. Conclusion

Ce chapitre a mis les points sur les différentes étapes de l’analyse réalisée selon le standard

ISA-95. A la fin de ce chapitre, nous avons proposé une architecture potentielle du système

à mettre en place.

Le chapitre suivant s’intéressera à la conception et au développement de la solution MES.

38

Production Control (3.0)

Material and Energy

Control (4.0)

Product Inventory

Control (7.0)

Maintenance Mangement

(10.0)

Quality Assurance

(6.0)

Marketing and sales (12.0)R&D and

engineering (13.0)

Procurement (5.0)

Order Processing

(1.0)Production Scheduling

(2.0)

Product Cost Accounting

(8.0)

Product Shipping

Admin (9.0)

Hors du périmètre

A améliorer au niveau de l’ERP

MES System

Hors du périmètreHors du périmètreA automatiser

GMAO OptiMaint

Figure 2.7 : Architecture potentielle du système

39

3. Chapitre 3 : Conception et Réalisation

40

3.1. Introduction

Comme indiqué au niveau de la feuille de route du projet (paragraphe 1.5 de ce rapport), le

développement de la solution MES et l’intégration verticale sont deux étapes primordiales

pour ce projet.

Dans ce chapitre, nous allons décrire les différentes parties réalisées. Nous commencerons

par l’implémentation d’une solution d’acquisition automatique des données. Par la suite, nous

passerons au développement de la solution MES. Après, nous décrirons le projet de l’intégra-

tion verticale. Pour finir, nous indiquerons les étapes restantes pour que le projet d’intégration

prenne fin.

3.2. Acquisition Automatique des données des machines

3.2.1. Aperçu

Dans le paragraphe 2.8.2 de ce rapport relevant les orientations issues lors des ateliers de

l’analyse ISA-95, nous avons mentionné l’importance de l’adoption d’une solution automa-

tique pour la collecte des données des machines.

Au début de la réalisation du projet d’implémentation, il s’est avéré que plusieurs solutions

existent, des plus classiques aux plus spécifiques. Cette multitude est surtout liée aux de-

mandes différentes de chaque industriel visant l’implémentation d’une solution d’acquisition

automatique des données. Plusieurs facteurs entrent en jeux : budget, temps, volume des don-

nées à acquérir, ou encore le coût d’apprentissage et de la maitrise de la technologie.

Nous allons, tout au long de la partie 3.2 étudier les technologies disponibles, choisir la plus

adéquate et décrire le projet d’implémentation de cette dernière.

3.2.2. Les technologies pour l’acquisition automatique des données

3.2.2.1. Les technologies classiques d’acquisition des données

Dans ce cas, aucune standardisation n’entre en jeux. Il n’est question que des spécifications

du vendeur de l’API. En effet, pour chaque machine ayant un API, nous allons communiquer

avec ce dernier pour avoir les données selon son propre protocole de communication. De

même, la solution MES que nous implémenterons devrait apprendre le protocole de l’API.

Rien qu’ici, la solution MES devrait ainsi faire partie intégrante du système d’automatisation

(niveaux 0, 1, 2 selon le standard ISA-95), chose qui mettra en question la conformité de notre

solution avec le standard ISA-95 qui spécifie que la couche MES devrait s’intéresser exclu-

sivement au niveau 3.

41

De plus, comme pour notre projet nous avons à communiquer avec différentes marques

d’API, la tâche s’avère onéreuse, tant pour le facteur budgétaire, puisque pour chaque ma-

chine un driver (pilote) API spécifique, que pour le facteur temps puisque le grand nombre

de protocoles propriétaires requiert plus de développement et de maintenance pour la solu-

tion MES. La figure 3.1 illustre la problématique précédemment décrite.

Driver C

C

Driver B

B

Driver A

A

Application MES

C B ADD

Figure 3.1 : Cas des technologies classiques d’acquisition des données

3.2.2.2. OPC

Par OPC (Ole for process control), nous spécifions une technologie d’échange des données

entre deux systèmes. C’est un protocole qui a été spécifiquement développé pour l’interfa-

çage avec les machines. De plus, il a l’avantage d’être standardisé et défini par un consor-

tium (OPC Foundation), donc non lié à un vendeur particulier de solutions. En effet, la ma-

jorité des constructeurs d’API ont fait que leurs produits soient compatibles avec l’OPC.

Il se base essentiellement sur la technologie COM/DCOM de Microsoft qui joue le rôle

d’intermédiaire entre les différents systèmes (comme décrit dans la figure 3.2).

Cette technologie est plus intéressante puisqu’elle facilite d’une part la tâche d’intégration

des machines de production et d’une autre part fait qu’on soit conforme au standard ISA-95.

L’inconvénient de l’OPC est sa dépendance envers la technologie COM/DCOM qui nous

limite aux technologies de Microsoft.

42

Driver C

OPC

Driver B Driver A

Application MES

OPC

OPC OPC OPC

OPC OPC

OPC

COM/ DCOM

Figure 3.2 : Cas de la technologie OPC

3.2.2.3. Euromap 63

Vu que SIAB a un centre d’injection comportant seize machines, nous nous sommes inté-

ressés à l’Euromap 63 qui est une interface standardisée pour l'échange de données avec les

machines d'injection qui a été défini par le Comité Européen des Fabricants de Machines

(Euromap). L'interface Euromap 63 a les propriétés suivantes :

• L’Euromap 63 est spécialisée dans l'échange de données avec des machines

d'injection.

• L’Euromap 63 n'est pas liée à une plateforme particulière. La compatibilité est plutôt

une propriété du contrôleur de la machine d’injection.

En raison de la grande variété des contrôleurs utilisés par les fabricants de machines comme

au fait que le contenu de l'interface soit librement définissable par les fabricants de ma-

chines, la mise en œuvre effective varie d'un fabricant à l'autre. Le degré d'intégration ne

sera donc aussi bon qu'avec la technologie OPC. De plus, les machines du centre d’injection

dans notre cas ne sont pas compatibles avec l’Euromap 63 (aucune interface n’est définie

par le fabricant2 des machines).

Plus de détails sur l’intégration des machines d’injection seront développés au niveau de la

partie 3.2.3.4 intitulée ‘Cas particulier des machines d’injection’.

2 BILLION est un fabricant français de machines d’injection plastique.

43

3.2.2.4. Choix final

Le but derrière le projet d’implémentation d’une solution d’acquisition des données est de

générer une base de données qui sera intégrée à la solution MES.

La technologie OPC est de loin la plus adéquate :

• Budgétairement, elle coute moins cher que si l’on utilisait les solutions propres à

chaque constructeur d’API.

• Elle facilite l’intégration des machines et réduit considérablement le temps d’implé-

mentation.

• Elle peut gérer d’important flux de données simultanément, et peut générer des

bases de données comme spécifié précédemment.

• Elle rend le projet d’intégration conforme au standard ISA-95 en déconnectant la

couche MES des niveaux 0, 1 et 2.

Donc le choix final était d’utiliser la technologie OPC pour intégrer les machines en acqué-

rant en temps réel des données de leurs API.

3.2.3. Implémentation OPC

3.2.3.1. La solution OPC choisie

Plusieurs vendeurs de solutions OPC vantent les mérites de leurs produits. Notre choix s’est

surtout basé sur les points suivant :

• La compatibilité avec les API avec lesquels nous communiquerons pour ce projet ;

• La variété des solutions compatibles qui font qu’au final, nous générerons une base

de données ;

• Le prix de la solution.

Nous avons alors choisi, après étude, la solution de ‘Kepware Technologies’ grâce surtout à

sa compatibilité avec le protocole Unitelway propre aux API de ‘Schneider Electric’ (peu

supporté) sans oublier les technologies OPC qu’il offre pour générer une base de données.

La figure 3.3 suivante indique les technologies utilisées lors de ce projet.

44

Mac

hine

s Transaction Manager

BDD

Data LoggerServeur OPC

Figure 3.3 : Architecture du système d’acquisition des données utilisé

Dans ce qui suit, la définition de chaque technologie :

• Serveur OPC : le protocole OPC définit une dualité serveur/client. Le serveur repré-

sente la première interface directement connectée aux machines. Il s’occupe de la

communication physique avec l’API, de la génération des informations voulues et

les stocke en interne. Toutes les autres technologies qui viennent après, sont des

clients qui sollicitent le serveur OPC.

• Data Logger : c’est un programme qui rassemble les données issues de la production

pour enfin les stocker sur une base de données.

• Transaction Manager : ce programme reçoit les données brutes du Data Logger, les

analyse pour enfin les envoyer vers la base de données.

• BDD : c’est la base de données comportant les différentes informations générées par

le serveur OPC. Nous avons décidé pour qu’elle soit de type SQL pour des raisons

postérieures propres à la programmation de la solution MES.

Les étapes qui suivent montrent le développement du projet de mise en place de la couche

OPC.

3.2.3.2. Création des serveurs OPC

Kepware Technologies offre une solution pour la création de serveurs OPC appelée

KEPServerEx. Un serveur peut gérer plusieurs API, donc machines, à la fois. Ceci mènera à

plus d’investissement dû principalement à l’achat de modules réseaux pour chaque API et la

mise en place de tout un réseau industriel. Nous avons alors opté pour une solution moins

couteuse qui est la communication directement avec le port de programmation de chaque

45

API. Donc pour chaque machine, un ordinateur supportant le serveur OPC. Une solution as-

sez onéreuse si ce n’est notre choix d’utiliser ces mêmes ordinateurs comme des IHM

propres à la solution MES.

Un serveur OPC possède trois composantes comme suit :

• Chaine : elle représente un support de communication de l'ordinateur vers un ou plu-

sieurs dispositifs externes. Une chaine peut être utilisée pour représenter un port sé-

rie ou Ethernet.

• Dispositif : les dispositifs représentent les automates ou tout autre matériel avec le-

quel le serveur communique, comme par exemple une carte d’acquisition. Le pilote

de périphérique que la chaine utilise restreint la sélection du dispositif.

• Tag : représente les adresses au sein de l'API ou tout autre périphérique avec lequel

le serveur communique.

Le schéma qui suit montre l’arborescence d’un serveur OPC :

Figure 3.4 : Arborescence d’un serveur OPC

L’annexe B de ce rapport décrit le parc des machines, selon les centres, et leurs spécificités

à savoir : le type de l’API, le protocole de communication, le driver KEPServerEx utilisé et

si la tâche d’intégration est terminée ou pas. Pour ce qui suit, nous ne prendrons que le cas

de la machine 2516-R3, du centre assemblage stylos, avec un API de type Modicon

TSXPremium intégrant un CPU de type TSX PSY 2600.

L’implémentation d’un serveur OPC requiert la création de ses trois composantes. Les

étapes de création de ces dernières sont décrites dans ce qui suit.

1. Création d’une chaine :

Nous y spécifions tout d’abord le nom de la chaine avec le type du driver adéquat (Uni-tel-

way dans notre cas). Nous indiquons ensuite les paramètres de communication avec l’auto-

mate comme le port sur lequel nous sommes connectés ou encore sa parité. Enfin, nous

avons indiqué que la nouvelle valeur d’un tag écrase l’ancienne. La figure 3.5 indique les

étapes réalisées.

46

Figure 3.5 : étapes de la création d’une chaine d’un serveur OPC

2. Création du dispositif :

Lors de la création du nouveau dispositif, nous indiquons son modèle. Par exemple ici il

s’agit d’un ‘Large frame’ relatif à la gamme TSX Premium. D’autres paramètres sont défi-

nis comme l’auto-demotion qui indique la réaction du serveur OPC suite à la déconnexion

de l’API. La figure 3.6 montre la création du dispositif.

Figure 3.6 : Création du dispositif OPC

3. Création des tags :

Pour cela, nous indiquons le nom du tag, son adresse selon le type de l’API (dans ce cas il

s’agit d’un compteur dont l’adresse est %C3) puis les propriétés de la donnée que l’adresse

génère.

47

Figure 3.7 : création d’un tag OPC

Il est plus utile de regrouper les tags selon leurs fonctions voulues. Rappelons que nous vou-

lons des informations sur l’état, les erreurs et les compteurs des machines. Pour cela, nous

avons créé pour chaque serveur OPC les trois groupes comme indiqué sur la figure 3.8.

Figure 3.8 : Arborescence finale du serveur OPC crée

3.2.3.3. Implémentation du DataLogging

Cette étape consiste à générer une base de données des différents serveurs OPC. Pour cette

tâche, nous avons utilisé la solution ‘DataLogger client’ de Kepware. Tous les serveurs

OPC génèrent leurs informations sur une même base de données centrale composée de trois

tableaux, à savoir : Compteurs, Défauts et Etats.

Le DataLogging consiste à choisir la base de données sur laquelle le serveur OPC en ques-

tion générera ses données et à faire du DataMapping. Ce dernier, le DataMapping, consiste

à indiquer pour chaque tag la donnée qui lui correspond au niveau de la base de données.

48

3.2.3.4. Le cas particulier des machines d’injection

L’un des centres les plus importants est celui de l’injection plastique. L’intégration de ses

seize machines n’a pas pu être mise en place vu qu’aucune documentation sur les contrôleurs

(comme le protocole de communication ou les adresses mémoires) n’a été communiquée par

le constructeur des machines et ce malgré les incessantes demandes réalisées de notre part.

L’utilisation de cartes d’acquisition des données en intermédiaire entre le PC et la machine

dans ce cas s’est avérée obligatoire. Cette partie n’a pas été développée vu l’attention qu’il

faut porter lors du choix des cartes qui doivent être compatibles avec notre solution OPC

sans oublier le temps important pour la mise en place.

3.3. Développement de la solution MES

3.3.1. Conception de la solution MES

3.3.1.1. Utilisation des modèles d’objets de l’ISA-95 pour l’archi-

tecture de la base de données

Nous passons maintenant à la conception de la solution MES. Le standard ISA-95 définit,

dans sa deuxième partie, des modèles d’objets pour faciliter cette tâche. Ces modèles ont été

indiqués dans la partie 1.5.2.2 dans ce rapport. Pour cette partie, seuls les modèles sollicités

pour notre projet seront développés.

Dans la figure 2.7 de ce rapport, nous avons indiqué les flux informationnels entre les diffé-

rents systèmes que nous développerons. L’ISA-95 donne pour chaque flux, le modèle adé-

quat. Le tableau suivant définit les modèles adéquats selon le flux d’informations réclamé.

Tableau 3.1 : Modèles d’objets à utiliser

Flux d’information Fonction de départ

Fonction d’arrivée

Modèle d’objets dans la partie 2

Schedule Production schedule Production control Operations schedule

information

Production from plan Production control

Production schedule

Operations perfor-mance information

Production capability Production control

Production schedule

Operations capability information

Process data Production control Quality assurance Operations perfor-

mance information

49

QA Results Quality Assurance Production Control

Material information & Operations perfor-mance information

Maintenance requests Production Control

Maintenance Management

Operations schedule information

Maintenance responses

Maintenance management Production control Operations perfor-

mance information Maintenance technical feedback

Maintenance Management Production control Non mentionné

Bien que parmi les modèles de ressources, seul celui du matériel est indiqué dans le tableau,

les autres modèles sont aussi importants pour notre solution. Parmi ces modèles, on s’inté-

resse tout particulièrement à celui définissant les équipements. La figure suivante montre ce

modèle.

Figure 3.9 : Modèle d’objets de l’équipement

L’ISA-95, dans sa deuxième partie, définit les classes d’objets, avec attributs, propres à

chaque modèle. Par exemple, pour le modèle d’équipements, on distingue les classes sui-

vantes :

• Classe d’équipement : c’est le type de l’équipement comme par exemple ‘machine

d’injection’.

• Propriétés de la classe d’équipements.

• Equipement : définit l’équipement en soi. Par exemple ‘machine ACART-01’.

50

• Propriétés de l’équipement : ce sont les valeurs des propriétés selon la classe de

l’équipement.

• Les tests de capacité et leurs résultats ne nous intéressent pas pour ce projet.

De même, l’ISA-95 définit quatre autres modèles à savoir : Performance, Capacité, Défi-

nition et planification. La figure suivante montre le modèle de performance des opéra-

tions.

Figure 3.10 : Modèle d’objets des performances des opérations

Donc, les modèles définis par l’ISA-95 représentent le modèle de base de données pour

notre cas. Nous passons maintenant à la description des fonctionnalités de notre solution

MES.

51

3.3.1.2. La fonctionnalité de la solution MES

Pour déduire la fonctionnalité de la solution MES souhaitée, nous avons développé les

points suivant :

• Définir le périmètre de la solution. C’est-à-dire, identifier ce qui appartient ou pas au

système.

• Identifier ceux qui seront ciblés par la solution.

• Découvrir quelles activités seront développées.

• Identifier les contraintes du système.

Le développement de ces points nous mène à concevoir un modèle statique qui est le dia-

gramme de cas d’utilisation qui fait partie des modèles statiques de la conception UML3. Ce

diagramme démontre les acteurs ciblés par la solution et les fonctionnalités qu’ils utilisent.

La figure suivante représente le diagramme conçu.

3 Unified Modeling Language (UML) est un langage de modélisation des applications. Il utilise des descrip-tions visuelles pour la conception de ses types de diagrammes.

52

Opérateur Machine

Ouvrir une session machine

Identifier Machine

Identifier Utilisateur Principal

Identifier deuxième opérateur

<<include>>

<<include>>

<<extend>>

Visualiser l'IHM propreà la machine

Demander intervention

Demander intervention Maintenance

Demander intervention Qualité

<<extend>>

<<extend>>

Responsable qualité

Confirmer OF

Responsable Maintenance

Recevoir demandesd'intervention Maintenance

Accéder à et générer des rapports d'analyse sur la maintenance

Intervenant Maintenance

Confirmer la fin de l'intervention

Entrer les causes de l'intervention

Entrer une nouvelle cause Choisir parmi

la liste

<<include>>

<<extend>><<extend>>

S'identifier à chaque début d'intervention

Serveur OPC

Flasher son badge

<<include>>

Responsable ProductionCentre

Manager

Responsable Planification

Clôlurer OF

Analyse des performances du centre

Analyse des performancesde production

Analyser les performances de toutes les activités

Générer des tableurs Excel utilisés pour la définition des KPI et la simulation

Générer une base de données des propriétés relatives à chaque machine

Figure 3.11 : Diagramme des cas d’utilisation de l’application

53

Il y a donc huit acteurs pour notre cas. Le rôle de chacun est décrit dans le tableau 3.2 qui

suit. A noter qu’un acteur est sélectionné s’il répond à ces points :

• Un acteur est toujours un participant hors du système.

• Un acteur interagit directement avec le système.

• Un acteur représente des rôles.

Tableau 3.2 : Acteurs de la solution

Acteur Rôle

Opérateur Machine

Cet acteur interagit avec le système par l’intermédiaire d’une IHM propre à la machine. Ses responsabilités incluent la sélection des don-nées relatives à l’ordre de fabrication et à demander des interventions s’il le faut.

Responsable production Il est responsable du suivi des ordres de fabrication.

Responsable planification

Il est responsable de la planification de la production. Il utilisera pour cela l’historique pour optimiser la planification.

Intervenant Maintenance

Cet acteur intervient en cas de demande. Il se doit de sélectionner la cause de l’arrêt de la machine.

Responsable Qualité

Il intervient en cas de problème lié à la qualité. De plus, il est respon-sable, à chaque fin d’ordre de fabrication, de clôturer le dossier qua-lité.

Responsable Maintenance

Cet acteur reçoit les demandes d’intervention maintenance pour assi-gner la personne adéquate. Il peut aussi générer des données relatives à la maintenance pour les analyser.

Manager Cet acteur veut avoir une vue concise sur les performances de la pro-duction. Il peut aussi générer des tableurs Excel sur l’historique pour qu’il puisse les utiliser dans des projets de simulation ou pour la défi-nition de KPI.

Serveur OPC Le serveur OPC génère une base de données qui sera utilisée par la solution MES.

Ainsi, la partie de la conception de la solution MES prend fin. La modélisation nous a per-

mis de déterminer d’une part la structure des données et d’une autre part la fonctionnalité de

la solution. Nous passons maintenant au développement de l’application.

54

3.3.2. Développement de la solution MES

Au début du projet de développement de la solution MES, nous nous sommes intéressés à la

création d’une identité visuelle pour cette dernière. En effet, nous avons observé que la plu-

part du personnel désignait les systèmes par leurs identités et non par leurs dénominations

techniques. A titre d’exemple, ils utilisent plutôt le mot ‘Adonix’ pour désigner l’ERP ou

encore ‘Optimaint’ pour désigner la solution GMAO. Donc, créer une identité pour notre

solution fera en sorte que le projet soit mieux apprécié et vite adopté par le personnel.

Nous avons choisi pour nom de la solution le mot ‘RABET’ qui vient du mot arabe "رابط"

dont la traduction en français est ‘lien’. En effet, par ‘RABET’, nous désignons le lien fait

grâce à notre solution entre la production et le système ERP.

La réalisation d’une identité visuelle inclut nécessairement la création d’un logo. Ce dernier

est présenté dans la figure suivante.

Figure 3.12 : Logo de la solution MES

L’identité visuelle réalisée, nous passons maintenant au choix des caractéristiques de la so-

lution MES à développer. La première caractéristique est le type du client, à savoir qu’il en

existe deux :

• Client lourd : l’application client doit être installée sur le terminal de l’utilisateur.

Seule la base de données est centralisée dans un serveur unique. Nous aurons besoin

de ce type d’application car seuls des clients de ce type peuvent générer des tableurs

Excel qui seront utilisés dans les projets de définition des KPI ou encore des projets

de simulation.

• Client léger : l’utilisateur n’a pas besoin d’installer l’application sur le terminal qu’il

utilise. Il a accès à l’application par l’intermédiaire d’un navigateur Web. L’applica-

tion avec la base de données est implémentée sur un serveur. Ce type de client aussi

55

nous intéresse. En effet, une telle application est plus facile à maintenir en cas de

mise à jour (il ne faut mettre à jour que le client sur le serveur). De plus, elle peut

être accessible par des terminaux mobiles (comme les tablettes ou les smartphones).

Donc, l’application à mettre en place doit répondre à la dualité client lourd/ léger. Une autre

caractéristique importante pour notre cas, est la possibilité d’intégrer dans la solution une

base de données externe, qui est celle générée par la couche OPC déjà mise en place.

Sur ces caractéristiques, nous choisirons l’environnement de développement le plus adéquat.

Après une étude approfondie, nous avons choisi de développer sur l’environnement de pro-

grammation ‘Lightswitch Visual Studio’. Il est basé sur le Framework4 .NET propre à Mi-

crosoft. D’une part, il facilite la programmation des solutions traitant beaucoup de données

comme la nôtre. Et d’une autre part, c’est la meilleure solution sur le marché qui peut ré-

pondre à nos besoins, à savoir le déploiement à la fois d’un client léger et d’un client lourd

ainsi qu’il offre la possibilité de se connecter à une base de données externe qui sera utilisée

par la solution.

Une application Lightswitch se compose de trois niveaux :

• Niveau des données : l’information utilisée par l’application est stockée et récupérée

à ce niveau qui comprend les requêtes venant du niveau logique de l’application.

c’est à ce niveau que nous connecterons la base de données résultant de la couche

OPC.

• Niveau logique : ce niveau est responsable de l’exécution des tâches et fonctions

propres à l’application.

• Niveau de la présentation : il représente le niveau le plus haut pour toute application.

C’est l’interface graphique qu’observe l’utilisateur.

Par rapport à la partie conception de la solution MES développée dans le paragraphe 3.3 de

ce rapport, chaque niveau de l’application Lightswitch correspond à une partie. En effet, les

modèles d’objets du standard ISA-95 correspondent au niveau des données. Quant aux cas

d’utilisation, ils correspondent aux fenêtres crées par le niveau de la présentation. Pour finir,

le niveau logique prend en charge l’identification des acteurs utilisant la solution.

4 En programmation informatique, un Framework est un ensemble cohérent de composants logiciels struc-turels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d'un logiciel

56

Maintenant que nous avons choisi l’environnement de programmation, nous passons à la

description de la programmation de l’application. Ceci a été réalisé en trois parties :

• Création des données :

Ici, nous allons ajouter les classes, avec leurs attributs, propres aux modèles d’objets.

Lightswitch simplifie la tâche en offrant une interface graphique comme montré sur la fi-

gure suivante.

Figure 3.13 : Création d’un tableau avec Lightswitch

• Création des relations :

Les relations entre les classes de l’application sont graphiquement éditées. La figure sui-

vante montre l’édition d’une relation entre la classe ‘Equipment’ et la classe ‘Equip-

mentClass’. Ainsi, un équipement doit avoir une classe d’équipement (EquipmentClass)

alors que cette dernière peut avoir plusieurs équipements. Nous pouvons aussi indiquer les

restrictions quant à la suppression d’une classe. De ce fait, une classe d’équipement ne peut

être supprimée si des équipements y sont reliés.

57

Figure 3.14 : Edition d’une relation entre deux tableaux avec Lightswitch

Sur la figure suivante, nous observons les relations qui existent entre la classe ‘Equipment’

et les autres classes. Même les autoréférences (relations entre une classe et elle-même) sont

supportées.

Figure 3.15 : la classe ‘Equipment’ et ses relations

58

• Création des requêtes

C’est le développement du niveau logique. En effet, bien que Lightswitch simplifie considé-

rablement la définition des données, il laisse au développeur la tâche de construire la lo-

gique de sa solution. Pour cela, nous avons utilisés le langage de programmation Visual Ba-

sic. Par la création des requêtes, nous avons définis les points suivant :

o Gestion des autorisations au niveau de l’application.

o Génération de tableurs Excel pour les clients lourds.

o Gérer les méthodes générales et les méthodes d’accès.

Ainsi, nous avons fini le développement de la solution MES. A noter que nous n’avons pas

pu avoir assez de temps pour développer des interfaces graphiques pour notre application.

Bien sûr, cette partie sera développée prochainement.

Les données de notre application doivent être communiquées au système ERP, de même, ce

dernier doit communiquer à son tour des données à notre solution MES. Ce travail fait l’ob-

jet de l’intégration verticale qui sera développée dans le paragraphe qui suit.

3.4. Intégration verticale

3.4.1. L’intégration verticale selon l’ISA-95

Une brève explication sur certaines technologies d’échange d’informations est nécessaire

pour comprendre le rôle de l’ISA-95 dans un projet d’intégration verticale.

Tout d’abord, pour comprendre l’utilité de l’intégration verticale prenons l’exemple ou pour

un planning de production donné, il est question d’envoyer une information de l’ERP à la

solution MES concernant le temps auquel l’ordre de fabrication doit être lancé. L’ERP ap-

pelle cette information ‘date de début’ alors que la solution MES l’appelle ‘Start time’ vu

que sa base de données a été développée selon l’ISA-95 donc en anglais.

Ce genre de problèmes est assez fréquent lors de l’échange d’informations entre deux sys-

tèmes. Ceci est dû à la différence au niveau des « Metadata » (comme ‘start time’) et des sé-

mantiques (la signification de la donnée comme 25-07-2013).

Pour cela, l’ISA-95 a standardisé au niveau de sa partie 5 cet échange de données. Il est plus

connu sous le nom de « Datamapping ». Cette méthode se base surtout sur deux technolo-

gies à savoir :

59

• XML : (eXtensible Markup Language) les documents de ce type contiennent à la

fois les metadata et leurs données. Le format XML est le plus utilisé pour l’échange

des données.

• B2MML (Business to Manufacturing Markup Language) : il se base sur XML mais

est spécialement dédié au standard ISA-95. Pour faire simple, c’est la traduction des

modèles d’objets développés par l’ISA-95 en des schémas XML en prenant en

compte les verbes de publication de la partie 5 du standard ISA-95 (revoir la partie

1.5.2.3 de ce rapport).

3.4.2. Travail réalisé

Le « datamapping » entre une solution MES et un ERP se fait par l’intermédiaire d’un

« Middleware » qui joue le rôle de traducteur pour l’échange de données. Le schéma suivant

montre l’importance d’un tel dispositif dans le projet d’intégration verticale.

Figure 3.16 : le rôle d’un Middleware [10]

Ainsi, un middleware (rectangles en jaune) reçoit par exemple un message de la solution

MES, le traduit en un message B2MML puis le transforme en un langage compréhensible

par l’ERP.

60

Plusieurs Middleware propriétaires existent sur le marché, mais le cout d’acquisition de ces

derniers est parfois même exorbitant. Nous avons alors opté pour une solution Open source

appelée « Nhibernate » (voir figure suivante) qui est spécialement dédiée à la technologie

.NET (le Framework utilisé par l’environnement de développement Lightswitch).

Figure 3.17 : Logo de NHIBENATE

Le projet d’intégration nous a menés à la réalisation des étapes suivantes :

• Déterminer les flux informationnels (il nous a suffi de revenir à la figure 2.7 de ce

rapport).

• Déterminer les modèles d’objets (étape réalisée au niveau du paragraphe 3.3.1.1 lors

de la conception de la base de données de notre application).

• Sélectionner les schémas B2MML relatifs selon le modèle d’objets et le verbe adé-

quat pour l’échange. Ainsi, nous créons la connexion entre la donnée au niveau de la

solution MES et son équivalent en message B2MML.

Notons que seule la partie MES à B2MML a été mise en place vu que seulement en cas d’im-

plémentation de la solution MES sur un serveur qu’on pourrait terminer la partie ERP->

B2MML.

Ainsi, la description des tâches réalisées au cours de ce projet prend fin. Il est clair que le

projet n’est pas arrivé à sa fin et que certaines étapes restent à faire. Le paragraphe suivant

décrira ceci.

3.5. Les étapes restantes

Les étapes restantes pour que le projet d’intégration prenne fin sont les suivantes :

• Implémentation de la couche OPC pour les machines d’injection qui nécessitent

l’utilisation de cartes d’acquisition des données comme intermédiaire entre la ma-

chine et le PC.

• Génération d’interfaces utilisateurs pour l’application MES réalisée.

61

• Implémenter la solution MES sur un serveur d’une part pour le déploiement d’un

client léger et d’une autre part pour que la génération d’une base de données utilisée

aussi par les clients lourds.

• Terminer le projet d’intégration verticale en traçant le lien entre les données au ni-

veau de l’ERP et de la solution GMAO avec les schémas B2MML adéquats.

• Formation du personnel sur la nouvelle solution pour qu’elle soit le mieux utilisée.

• Optimiser la solution selon les retours des utilisateurs.

3.6. Conclusion

Au cours de ce chapitre, nous avons pu décrire les différentes phases de développement du

projet d’intégration commençant par l’acquisition des données des machines en passant par

le développement de la solution MES pour finir par l’intégration verticale.

62

Conclusion générale

Dans le cadre de ce projet de fin d’études, nous avons développé une solution MES inté-

grant les ateliers de production aux autres systèmes informatiques existant.

Nous avons commencé notre travail par une recherche approfondie sur les technologies et

les standards relatifs au domaine de l’intégration. Nous avons ainsi pu déterminer les plus

adéquats. A la fin de cette étape nous avons abouti à valider le projet et à mettre en place un

plan d’actions selon les directives du standard ISA-95.

Dans une seconde étape, nous nous sommes intéressés à analyser le besoin de l’industriel

pour déduire les manquements et proposer les solutions les mieux adaptées. Ceci est fait

tout en suivant le standard ISA-95. A la fin de cette étape, des orientations pour notre projet

ainsi qu’une architecture potentielle du futur système à implémenter ont été définies.

L’étape suivante du projet était la réalisation de la solution MES. Pour cela, nous sommes

passés par trois étapes. La première concerne l’acquisition automatique des données des ma-

chines, pour cela, nous avons utilisé la technologie OPC. Après, nous sommes passés à

l’étape de développement de la solution MES en utilisant les modèles d’objets offerts par

l’ISA-95. La troisième et dernière étape était l’intégration verticale de la solution MES aux

autres solutions utilisées au sein de SIAB. Nous avons utilisé pour cela les schémas

B2MML et un middleware appelé ‘Nhibernate’.

En perspectives, nous comptons terminer le développement des interfaces graphiques de la

solution MES, à finir le projet de l’intégration verticale ainsi qu’à acquérir les données des

machines d’injection, incompatibles avec la technologie OPC. Aussi, nous projetons une

implémentation complète et fonctionnelle à la fin du mois d’Octobre.

63

Bibliographie

[1] ISA, ANSI/ISA-95.00.01-2010, May 2010

[2] Bianca S., The road to integration, 2007

[3], [6], [7], [8], [9] ISA, ANSI/ISA-95.00.03-2005, Juin 2005

[5] ISA, ANSI/ISA—95.00.05-2007, Janvier 2007

[4], [10] Jean V., ISA-95/B2MML Tutorial : Integration practice from use cases to xml

messages, Décembre 2012

64

Glossaire

API Automate Programmable Industriel

B2MML Business to Manufacturing Markup Language

BDD Base de données

ERP Enterprise Ressource Planning

ISA International Society of Automation

KPI Key Performance Indicator

MES Manufacturing Execution System

OF Ordre de fabrication

OLE Object Linking and Embedding

OPC Ole for Process Control

SQL Structured Query Language

UML Unified Modeling Language

XML eXtensible Markup Language

65

Annexes Annexe A : Modèle Hiérarchique des Equipements

Annexe B : Parc des machines

66

Annexe A : Modèle Hiérarchique des Equipements Entreprise Sites Areas Work

Centers Work Areas

SIAB SIAB PLC (Hors du péri-

mètre du projet)

SIAB Traiding (Hors du péri-mètre du projet)

SIAB Megrine Centre d'assemblage Car-

touche

Ligne de Production (Ligne de produc-tion)

ACART 1000 (Unité de travail)

ACART 26 (Unité de travai)

ACART 28 (Unité de travai)

ACART 30 (Unité de travai)

ACART 29 (Unité de travai)

ACART 25 (Unité de travai)

DECOUP (Unité de tra-vai)

MCR (Sto-rage zone)

Centre D'assemblage Stylos Feutres

Ligne Assemblage Stylo Feutre (Ligne de production )

HIFI-215 (Unité de tra-vai)

JMA-200-SA (Unité de travai)

GENGOH JMA-200-SA (Unité de travai)

Centre D'assemblage stylos à billes

Ligne d'assemblage stylos à billes (Ligne de production)

R6 (Unité de travail) R1 (Unité de travail) R2 (Unité de travail) R3 (Unité de travail) R4 (Unité de travail)

67

R5 (Unité de travail) S4 (Unité de travail) S3 (Unité de travail) S2 (Unité de travail) JBA-200 (Unité de tra-

vail) Centre d'emballage manuel Ligne Production Crayon (Ligne de pro-

duction) MARQ-CRAY (Unité

de travail) DECP-CRAY (Unité de

travail) TAILLAGE (Unité de

travail) Ligne emballage manuel (Ligne de pro-

duction) Magasin commun pour as-

semblage

MGS (Sto-rage Zone)

Centre Injection Plastique Park des Presses (Ligne de production) PRESS 02 (Unité de tra-

vail) PRESS 03 (Unité de tra-

vail) PRESS 04 (Unité de tra-

vail) PRESS 05 (Unité de tra-

vail) PRESS 06 (Unité de tra-

vail) PRESS 07 (Unité de tra-

vail) PRESS 08 (Unité de tra-

vail) PRESS 09 (Unité de tra-

vail) PRESS 10 (Unité de tra-

vail) PRESS 11 (Unité de tra-

vail) PRESS 12 (Unité de tra-

vail) PRESS 13 (Unité de tra-

vail) PRESS 14 (Unité de tra-

vail)

68

PRESS 15 (Unité de tra-vail)

PRESS 16 (Unité de tra-vail)

PRESS 17 (Unité de tra-vail)

Centre extrudeuse (Ligne de produc-tion)

BELLAFORM (Unité de travail)

MSF (Sto-rage zone)

Stock Matière première

MMP (Storage zone)

69

Annexe B : Parc des machines

Nom de la machine Centre API Protocole de

communication Driver utilisé Avancement de la tâche d’intégration

R4 Assemblage stylos LX TSX7 Unitelway Unitelway Finie

R6 Assemblage stylos LX TSX7 Unitelway Unitelway Finie

R3 Assemblage stylos

TSX Pre-mium Unitelway Unitelway Finie

R5 Assemblage stylos

TSX Pre-mium Unitelway Unitelway Finie

S4 Assemblage stylos

TSX PRE-MIUM Unitelway Unitelway Finie

STICK 2020

Assemblage stylos

Mitsubishi A161PN Série Mitsubishi se-

rial Finie

JMA 200 Assemblage stylos

Omron CQM1H Série OMRON Host

Link Finie

Feutre Assemblage stylos

Omron CQM1H Série OMRON Host

Link Finie

R2 Assemblage stylos

TSX Pre-mium Unitelway Unitelway Finie

R1 Assemblage stylos

TSX Pre-mium Unitelway Unitelway Finie

3000 Assemblage stylos S7-300 MPI SIEMENS S7

MPI Finie

Machine 28 Cartouche TSX Nano Unitelway Unitelway Finie Machine 31 Cartouche TSX Nano Unitelway Unitelway Finie Machine 29 Cartouche TSX Nano Unitelway Unitelway Finie Corps Bar-rels Cartouche TSX Nano Unitelway Unitelway Finie

Machine 27 Cartouche Sans API _ _ Non finie Machine 26 Cartouche TSX Nano Unitelway Unitelway Finie

Machine 25 Cartouche TSX Pre-mium Unitelway Unitelway Finie

Markem 04 Marquage TSX Nano Unitelway Unitelway Finie Markem 03 Marquage TSX Nano Unitelway Unitelway Finie Markem 02 Marquage TSX Nano Unitelway Unitelway Finie Marken 01 Marquage TSX Nano Unitelway Unitelway Finie BILLON 1006 Injection Microrack

AR5 Inconnu Inconnu Non finie

BILLON 1005 Injection Microrack

AR5 Inconnu Inconnu Non finie

BILLON 1007 Injection Microrack

AR5 Inconnu Inconnu Non finie

BILLON 86 Injection Microrack AR5 Inconnu Inconnu Non finie

70

BILLON 1010 Injection Microrack

AR5 Inconnu Inconnu Non finie

BILLON 1008 Injection Microrack

AR5 Inconnu Inconnu Non finie

BILLON 72 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 76 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 79 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 1009 Injection Microrack

AR5 Inconnu Inconnu Non finie

BILLON 80 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 81 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 78 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 82 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 77 Injection Microrack AR5 Inconnu Inconnu Non finie

BILLON 71 Injection Microrack AR5 Inconnu Inconnu Non finie

71