Memoire Online - Modélisation & Simulation Transfert de l'encre dans le système d'encrage

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation;

with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU

IUP M.A.I _ LICENCE 2001-2002

Ecole Française de Papeterie et des Industries Graphiques(EFPG) _ INPG

REMERCIEMENTS

Je remercie vivement mon maître de stage Monsieur Robert Catusse de l'Ecole Française de Papeterie et des Industries Graphiques pour m'avoir accueilli et guidé dans la réalisation de ce stage.

Je tiens à exprimer ma sincère reconnaissance à Monsieur Mazen Mahrous de l'Ecole Française de Papeterie et des Industries Graphiques pour m'avoir apporté tous les moyens matériels et logistiques nécessaires à l'accomplissement de mon travail.

Mes remerciements sont également adressés à Messieurs Lionel Chagas et Gérard Baudin de l'Ecole Française de Papeterie et des Industries Graphiques pour l'attention qu'ils m'ont consacrée et pour l'aide précieuse qu'ils m'ont offerte pour la synthèse de ce stage et la rédaction de ce rapport.

Je remercie Madame Françoise Jung et Monsieur Eric Bonnetier de leur participation au jury et de leur encadrement au niveau de la formation et du stage.

Je tiens à faire part de ma plus profonde gratitude envers tout le personnel administratif et technique de l'EFPG pour leur support et leur travail sans oublier Monsieur Christian Voillot le directeur de l'école.

Enfin, ces remerciements s'adressent à mes collègues de travail, aux stagiaires de l'UFRIMA et à tous ceux qui ont contribué au bon déroulement de ce stage.

SOMMAIRE

INTRODUCTION

Dans le cadre de ma Licence d'IUP GMI MAI (Institut Universitaire Professionnalisé, Génie Mathématique et Informatique, spécialité Mathématiques Appliquées et Industrielles) à l'université Joseph Fourier de Grenoble, j'ai réalisé, du 28 mai au 2 août 2002, un stage à l'EFPG (Ecole Française de Papeterie et des Industries Graphiques).

L'objectif principal de ce stage était pour moi d'être confronté à un nouveau milieu, de relever les responsabilités d'un projet, d'apporter mes connaissances et d'en assimiler de nouvelles. C'est dans ce contexte que m'a été confiée la tache de mettre au point un simulateur relatif au transfert de l'encre dans une presse offset.

J'ai bénéficié d'un grand degré de liberté ainsi que d'un très bon soutien pédagogique pour mener à bien ce projet. Dès lors, j'ai pu exploiter mon approche personnelle du sujet lors de la phase de développement. Ainsi, le langage multi-plateformes JAVA a été retenu à mon initiative et une interface a été mise en place pour une plus grande accessibilité du simulateur. Autre atout et non des moindres de ce langage de programmation, sa très forte adaptabilité au réseau (Internet ou Intranet).

Afin de rendre compte du travail effectué, je présenterai, dans ce rapport, l'EFPG, qui m'a accueillie, et le cahier des charges du projet qui m'a été confié. Ensuite, je développerai en trois parties les différentes phases de mon travail : l'acquisition de la théorie avec la présentation du procédé d'impression offset, la modélisation, puis les divers aspects du simulateur(le produit fini). Enfin, la conclusion fera le bilan de ce stage et laissera entrevoir les ouvertures possibles pour l'avenir.

En annexes, vous trouverez les références, les listings ainsi que les autres documents mentionnés dans ce rapport.

PRESENTATION DE L'EFPG

L'Ecole Française de Papeterie et des Industries Graphiques, créée par la profession papetière en 1907, est située sur le campus de St-Martin-d'Hères. Premier centre de formation d'ingénieurs en Europe dans sa spécialité, l'EFPG constitue, avec le Centre Technique du Papier, son voisin, l'un des 5 pôles mondiaux de la recherche papetière.

Précisons que l'EFPG est l'une des neuf écoles de l'INPG. L'Institut National Polytechnique de Grenoble accueille chaque année plus de 4 000 étudiants. Fédération de neuf grandes écoles, où la recherche est fortement liée à la formation, l'INPG compte plus de 30 laboratoires et un collège doctoral en sciences de l'ingénieur. Relations industrielles et relations internationales sont deux axes essentiels de la politique de l'établissement, qui représente aujourd'hui, avec 1000 nouveaux ingénieurs diplômés par an, le 1er pôle français de formation d'ingénieurs.

Financée en partie par les industriels du secteur, l'EFPG est un établissement de droit privé, sous tutelle du Ministère de l'Enseignement Supérieur, et ratt aché à l'INPG. Elle accueille environ 180 élèvesingénieurs en cursus normal et en formation par l'apprentissage. Les liens étroits qui existent entre l'école et les entreprises des secteurs papetiers et graphiques, assurent une parfaite adéquation entre les attentes industrielles et la formation des ingénieurs EFPG. Le corps enseignant comprend 30 permanents et 30 enseignants vacataires dont la plupart est issue du milieu industriel ; 35 personnels ingénieurs, techniciens et administratifs contribuent à la logistique et au fonctionnement de l'établissement.

A leur sortie de l'école, la plupart des élèves désirent s'orienter vers des activités de production : d'abord ingénieurs de fabrication, ils sont appelés rapidement à des responsabilités élevées. Environ 25% des ingénieurs EFPG actuellement en activité sont directeurs de production, de site ou PDG de leur entreprise. On trouve également dans l'éventail des fonctions offertes des Ingénieurs de production, ou R&D, des ingénieurs de conception, d'affaires, de vente, ou encore des ingénieurs qualité.

Grâce à la politique de recrutement de l'école, qui tient compte de la conjoncture, les diplômés EFPG n'ont jamais eu de problèmes de placement. Le salaire annuel brut d'un ingénieur EFPG débutant est compris en moyenne entre 170 KF et 220 KF, 17% exercent à l'étranger.

Ci-dessous les répartitions des ingénieurs de l'EFPG par secteur et par poste.

Le budget de 33 MF (salaires inclus-données 1995) est assuré par un financement à hauteur de : - 40 % par la Taxe d'Apprentissage

- 25 % par des ressources propres (contrats de recherche, formation continue, prestations diverses)

Les équipements modernes et spécialisés permettent d'assurer une formation de haut niveau :

- 4 stations de travail SUN et outils spécifiques de simulations de procédés...

- 2 machines à papier équipées de systèmes de conduite centralisée - 1 presse offset 2 couleurs

- 1 scanner à plat et des systèmes d'épreuve numérique couleur - 1 pilote de traitement mécanique des suspensions fibreuses - 1 pilote de traitement en lit fluidisé des effluents

- analyse et caractérisation des structures fibreuses : porosimétrie, granulométrie, rhéologie...

L'EFPG dispose ainsi de la plupart des équipements spécialisés dans le monde pour la fabrication et la caractérisation des papiers, cartons et des produits de leur transformation.

Voici la liste des moyens pour contacter l'EFPG ainsi que ses postes dirigeants :

CAHIER DES CHARGES

Le contenu de ce cahier des charges résulte du dialogue que j'ai entretenu pendant le stage avec Mr Catusse mon maître de stage. D'autre part, dans l'étude qui va suivre, le système de mouillage de la presse offset a été délibérément mis de coté du fait qu'il ne rentrait pas dans le cadre de la modélisation.

L'EFPG a mis à ma disposition tout le nécessaire pour mener à terme ce projet, soit un PC (pentiumIII 800MHz MMX, 256MO SDRAM), muni de l'environnement de développement JBUILDER version 4.0 pour le codage du simulateur, ainsi que de FrontPage pour la conception du contenu de la page destinée à l'intranet (hors applet). Un navigateur WEB supportant JAVA et un accès à Internet, destinés aux tests du simulateur et à la recherche de documentation, étaient également installés.

I - Le procédé d'impression Offset

1 - Le procédé offset

Le procédé offset est actuellement le procédé d'impression le plus couramment utilisé dans le monde. Cette position est principalement due à la qualité de l'impression, aux faibles coûts de production et à son adaptabilité à une large gamme de produits. Ce procédé a été utilisé pour la lithogravure dès 1978 par Aloys Senefelder.

Le principe fondamental du procédé offset repose sur l'antagonisme de l'eau et des corps gras afin d'imprimer avec une forme sans relief. En effet, l'impression offset appartient à la famille des procédés d'impression << à plat >>. D'autre part, ce procédé est dit indirect du fait que la forme imprimante n'est pas en contact direct avec le support d'impression, à savoir le papier. Effectivement, l'image est reportée deux fois (to set off = reporter), tout d'abord de la forme imprimante, la plaque, vers le blanchet, matériau caoutchouteux, puis du blanchet vers le papier.

Afin d'obtenir une impression de qualité, l'épaisseur d'encre déposée sur le papier doit être homogène. C'est pour cela que l'encre transite par une batterie de rouleaux disposés en cascade que l'on appellera dorénavant << batterie d'encrage >>. Celle-ci a pour fonction de distribuer l'encre, de façon homogène, de l'encrier jusqu'au cylindre porte-plaque.

Plusieurs facteurs intervenant dans le transfert de l'encre induisent de fortes perturbations sur le flux de l'encre. Ainsi le rouleau encrier, en amont de la batterie d'encrage, a une vitesse linéique de surface moindre que le reste de la batterie d'encrage, et ce pour assurer le broyage de l'encre. Par conséquent, ces deux parties ne sont pas en contact et l'encre est acheminée du rouleau encreur à la batterie d'encrage par le << preneur d'encre >>, qui effectue un mouvement de va-et-vient entre le rouleau encrier et le premier rouleau de la batterie d'encrage.

2 - La formation de l'image

La plaque, c'est à dire la forme imprimante, est constituée d'un matériau polymère dégradé par photogravure. La partie dégradée de la plaque forme la zone image ou la zone non-image, respectivement selon que la plaque est positive ou négative. La zone image doit être hydrophobe et doit pouvoir recevoir l'encre grasse, inversement la zone non-image doit être hydrophile afin de recueillir la solution de mouillage constituée en majeur partie d'eau. Le pourcentage de zone image par rapport à la totalité de la surface de la plaque est appelé << pourcentage de couverture >>.

A chaque tour, la solution de mouillage est déposée sur la plaque, elle n'est retenue que par la zone non-image, ce qui empêchera le dépôt d'encre sur les dites zones. A noter qu'il existe une variante du procédé offset qui n'utilise pas de solution de mouillage grâce à l'utilisation de plaque de technologie différente, ce procédé est appelé << offset waterless >>. Cependant le principe reste similaire dans les deux cas (figure2).

Une fois l'image formée sur la plaque, elle est reportée sur le blanchet, qui est constitué de plusieurs couches de matériaux caoutchouteux. L'image inversée présente sur le blanchet est alors transférée sur le papier. On obtient alors l'image initiale, celle de la plaque, sur le papier.

Pour obtenir une image en couleurs, il faut utiliser plusieurs plaques : une pour chaque couleur primaire utilisée, plus une pour le noir. La presse offset de l'EFPG (modèle << favorit >> de M.A.N ROLAND) dispose de deux systèmes d'encrage, il n'est donc pas possible de restituer toutes les couleurs en un seul passage.

La qualité de l'image ne dépend pas uniquement de la qualité des consommables utilisés (papier, encre, etc.) et des conditions d'impression (vitesse, chaleur, humidité) mais également de l'habileté du conducteur de la presse. Actuellement, le transfert de l'encre dans la batterie d'encrage, du fait de la complexité des mécanismes mis en jeu, ne bénéficie pas ou peu d'automatismes aptes à assister la conduite de la machine. Actuellement, des recherches sont menées à ce sujet.

3 - La batterie d'encrage

La batterie d'encrage, destinée à transférer l'encre du rouleau encrier au cylindre porte-plaque, est une structure complexe composée de rouleaux agencés de façon à éviter tout phénomène nuisible à la qualité de l'impression.

Tous les cylindres du système tournent à la même vitesse linéique de surface, à l'exception du rouleau encreur qui, pour entretenir un bon état physique de l'encre, tourne à une vitesse inférieure à celle du reste de la batterie. En effet, la presse doit maintenir une cadence assurant une productivité élevée (de l'ordre de plusieurs milliers de feuilles par heure). Par conséquent, le rouleau encreur n'est pas en contact avec le reste de la batterie d'encrage. L'encre est transférée entre les deux parties par un cylindre débrayable, le << preneur >>. Ce cylindre est dit << fou >>, c'est à dire qu'il n'a pas de vitesse propre, il est entraîné par contact avec le rouleau preneur ou avec le rouleau de la batterie d'encrage. La prise d'encre qui intervient à une fréquence ajustable, généralement 1 prise d'encre par tour machine, est effectuée par le preneur qui effectue un mouvement de va-et-vient entre le rouleau encreur et le premier rouleau de la batterie.

La prise d'encre en amont du système, parce que non continue, est source de fortes perturbations dans le flux de l'encre. C'est pour absorber toute hétérogénéité dans le film d'encre que sont disposés ainsi les cylindres de la batterie d'encrage. Leur nombre assure une efficacité accrue.

Les toucheurs, en aval de la batterie d'encrage, déposent sur la plaque une couche d'encre d'épaisseur homogène. Les gorges répondent à des contraintes techniques liées à la fixation de la plaque offset, à la saisie des feuilles et à leurs tailles, elles sont plutôt caractéristiques des presses offset << à feuilles >>. Sur les rotatives, les gorges sont inexistantes ou réduites à des tailles négligeables.

4 - Le transfert de l'encre

En amont du système d'encrage de la presse offset, l'encre est distribuée par l'encrier. En fonction de la forme de l'image, il n'est pas nécessaire de couvrir d'encre la totalité de la largeur des rouleaux. Ainsi, c'est le conducteur de la machine qui détermine le << profil d'encrage >> en ouvrant ou en fermant les << tiroirs >> disposés sur l'encrier(figure 4). Il règle de la même façon l'épaisseur d'encre à distribuer.

Cette encre est ensuite transférée de cylindres en cylindres au niveau de chaque contact par scission du film d'encre. Le << coefficient de scission >> détermine quelle quantité d'encre est distribuée sur chacun des deux rouleaux en sortie d'un contact(figure5).

La valeur de ces coefficients est difficile à calculer, cependant des valeurs expérimentales ont été déterminées. La modélisation à venir utilisera ce type de valeurs.

II - La Modélisation

1 - Points de départ

La modélisation du système d'encrage de la presse offset est, et a été, le sujet d'études diverses. Il en résulte que plusieurs modèles existent déjà. L'objectif ici est de créer un modèle plus performant et plus complet. Bien sûr, le modèle doit être fiable, et le plus proche possible de la réalité.

J'ai consacré les trois premières semaines du stage à me documenter et à réfléchir à la modélisation la plus fonctionnelle possible. Pour ce faire, je me suis appuyé sur le pré rapport de stage de Farida Seddik, étudiante en DEA Génie des procédés. Elle-même a mis au point un premier simulateur fonctionnant sous Excel, et un deuxième tournant sous Matlab. Je n'ai pas réutilisé ces modèles car ils ne répondaient pas aux attentes du cahier des charges( vitesse, paramètres pris en compte...). Cependant, je me suis inspiré d'une de ses sources pour la << structure >> de mon modèle. Il s'agit de Mac Phee, qui est à l'origine d'un type de modélisation basé sur la discrétisation du système d'encrage en divisant en longueurs égales la circonférence des cylindres.

Dès lors, j'ai mis à profit mon expérience de la programmation en JAVA pour concrétiser cette approche du sujet. J'ai également bénéficié de l'expérience acquise en cours d'année grâce au sujet de Travaux Pratiques, simulation de modèles à événements discrets avec files d'attente , sujet proposé par J-M Cagnat en module M42 de licence d'IUPMAI. Toutefois, une période d'apprentissage de l'environnement de développement Jbuilder a été nécessaire.

A partir de cela, les principales difficultés étaient d'incorporer dans le modèle simplifié du système d'encrage les différents paramètres mentionnés dans le cahier des charges. Le modèle complété, il est nécessaire, pour qu'il soit performant, que tous les paramètres soient modifiables, y compris le pas de discrétisation que l'on doit pouvoir descendre le plus bas possible.

La presse à modéliser est en fait la presse de l'EFPG, il s'agit d'une presse offset << à feuilles >> 2 couleurs (modèle << favorit >> de M.A.N ROLAND, photo ci-dessus). Par ailleurs, il est nécessaire de préciser que le modèle à réaliser est celui d'une coupe latérale de la presse. Ce modèle à deux dimensions a des limites que l'on exposera dans la conclusion de ce rapport.

2 - La discrétisation du système

Dans la réalité, la presse offset tourne en continu. Le principe de modélisation que nous avons retenu consiste à dire que la presse ne tourne plus en continu mais qu'à chaque pas de temps elle avance d'un pas de longueur. Ainsi, le problème consiste plus simplement à traiter un modèle à évènements discrets.

Pour discrétiser la circonférence des cylindres, on se base sur deux données : la circonférence du porte-plaque et le paramètre << longueur du pas >>. La circonférence du porte-plaque sert de base car, un tour effectué par le cylindre porte-plaque équivaut à un tour machine. La longueur du pas détermine la précision de la simulation. Dans les calculs, on se réfère au diamètre du porte-plaque et non à sa circonférence ; cela allège les calculs et n'altère en rien le procédé puisque circonférence et diamètre sont proportionnels (P = ðD). La discrétisation se fait alors en divisant le diamètre du porte-plaque par la longueur du pas. La valeur ainsi obtenue, arrondie à l'entier le plus proche, correspond au nombre de pas n nécessaires pour réaliser un tour complet (figure 6).

Le même procédé appliqué aux autres cylindres, conjugués avec les données du constructeur de la

presse, permet d'obtenir pour chaque contact entre un cylindre C1 et un cylindre C2 : - Le nombre de pas séparant le contact du prochain contact sur C1. - Le nombre de pas séparant le contact du prochain contact sur C2.

Toutes ces données permettent de concevoir la presse offset virtuelle du programme JAVA, on crée pour cela un ensemble constitué d'éléments, ou objets, que l'on nomme << contacts >>.

3 - Les « contacts »

Du point de vue de la modélisation, on peut considérer que le système d'impression de la presse offset est constitué de contacts entre rouleaux. Tous ces contacts font circuler l'encre de façon rationnelle et prévisible. A partir des données du constructeur, on a créé le schéma ci-dessous :

Le système d'impression de la presse offset est composé de 20 cylindres, en incluant le cylindre de contre-pression qui supporte le papier. On décompte 24 contacts entre les rouleaux, le 24^èmeétant le contact entre le blanchet et le papier(impression). Au niveau de la programmation, on a donc 24 instances de l'objet << contact >>, celles-ci sont stockées dans un tableau rendant leur accès(par indices) plus rapide.

Il reste alors à relier tous les contacts entre eux. Pour ce faire, on a retenu des relations simples qui nécessitent le moins de ressources possible lors de l'exécution du programme. Sur le schéma de la figure 7, on effectue les observations suivantes :

- En entrée, un contact dispose de deux films d'encre, un pour chaque rouleau en contact. - En sortie, l'encre est divisée en deux films dirigés vers deux autres contacts.

Il y a des différences pour certains contacts(blanchet-papier, preneur/batterie, preneur/encreur) que nous aborderons plus tard, cette partie visant à expliquer le modèle d'une façon générale.

On se propose de caractériser un << contact >>. Ces caractéristiques rempliront les champs de l'objet << contact >>(figure8). On définit donc pour chaque contact :

- 2 files d'attentes qui contiennent tous les << pas >> entre ce contact et les contacts qui le précèdent sur chacun des deux rouleaux en contacts.

- 2 références aux contacts suivants, contacts vers lesquels sont dirigés les films d'encre en

sortie. Les contacts étant stockés dans un tableau, il s'agit en fait de deux indices.

- Pour chacun des contacts référencés, il est nécessaire d'indiquer l'indice de la file d'attente

- Un coefficient de scission qui détermine comment est dispatché le film d'encre entrant.

Cette structure complétée par un jeu de fonctions destinées à gérer le parcours de l'encre, permet d'ores et déjà d'obtenir un modèle simple de la batterie d'encrage. Les fonctions appelées à chaque pas de temps et pour chaque contact scindent les films d'encre, obtenus par sommation des films entrants, et les dispatchent dans le système selon sa configuration. On ne détaillera pas plus ces fonctions commentées en détail dans le code source de la classe << contact >> (fourni en annexes).

Ce modèle bien que primitif est déjà une représentation << solide >> de la presse offset, c'est à dire qu'en procédant de cette manière, il est facile de s'assurer à ce stade qu'il n'y a pas d'erreurs. En vérifiant, grâce au débogueur fourni par Jbuilder, l'état des variables du début à la fin de la simulation, on peut s'assurer de la validité de l'état du système. Plus particulièrement, l'état des files d'attente est un très bon indicateur car s'il y a des éléments en trop ou en moins cela implique un état incorrect du système. Quant aux valeurs numériques que l'on obtient, elles dépendent uniquement des paramètres entrés, tels que les coefficients de scission, le hasard n'intervenant nulle part dans cette modélisation.

Pour satisfaire le cahier des charges, et obtenir ainsi un modèle plus réaliste, il reste à intégrer dans cette ébauche d'autres paramètres ou propriétés comme le preneur, les gorges, le pourcentage de couverture, etc...

4 - Les gorges et le pourcentage de couverture

Ces deux notions, bien que différentes, peuvent être modélisées de la même manière. Cela grâce à la représentation que l'on en a faite.

Les gorges sont des zones de non-transfert de l'encre. En effet, au niveau des gorges, la surface du cylindre est en retrait(figure 10). Le film d'encre à la surface du rouleau sans gorge ne subit aucune modification. On trouve une gorge sur le porte-plaque, ainsi que sur le porte-blanchet.

Le pourcentage de couverture informe sur la surface de la plaque, il s'agit du pourcentage de zone image sur cette surface. La zone de non-image est, comme la gorge, une zone de non-transfert de l'encre. Du point de vue de la modélisation, le pourcentage de couverture sera traité en alternant de façon uniforme, et en fonction du pourcentage de couverture, les zones image et les zones non-image(figure1 1).

		50% de couverture
Zone image	Zone non-image
		10% de couverture

Figure 11 : Schéma de représentation du pourcentage de couverture _ Vue de la plaque

On retrouve les caractéristiques précédemment illustrées sur la figure 2 (cf. I.2). Ainsi, on modélise gorges et couverture de la même façon, on marque ces zones de non-transfert de l'encre afin qu'elles soient traitées différemment. La fonction Contact. cheminEncre2 gère le transfert de l'encre lorsqu'il y a présence de la gorge ou d'une zone non-image.(cf. annexes, code source : Contact & SimuApplet.creerGorges)

5 - La prise d'encre

Plus complexe à modéliser et à programmer, la prise d'encre est fonction de plusieurs des paramètres mentionnés dans le cahier des charges. En effet, la fréquence de la prise, la vitesse de rotation du rouleau encreur, le temps de trajet encreur~batterie par le preneur, la durée de la prise et l'épaisseur d'encre sur le rouleau encreur sont autant de paramètres qui interviennent dans le processus.

Tous ces paramètres sont pris en charge dans les deux fonctions du programme qui gèrent la prise d'encre (cf. annexes, code source : Contact.).

Le principe est pourtant assez simple : les paramètres << fréquence de prise >>, << temps de trajet encreur~batterie par le preneur >> et << durée de prise >> permettent de déterminer la position du preneur à un instant donné. Il suffit ensuite d'un traitement au cas-par-cas.

La vitesse de rotation du rouleau encreur est en fait exprimée par un pourcentage, la vitesse linéique de surface relative du rouleau encreur par rapport à celle du reste de la batterie. Alors le déplacement, discrétisé, du rouleau encreur est fonction du pourcentage. Par exemple, si la vitesse relative vaut 20% (20% = 1/5), il faut 5 pas de temps pour traiter 1 élément de longueur ; concrètement, si la durée de prise dure 5 tours, il ne se passe rien pendant 4 tours et le 5^èmetour la scission du film d'encre a lieu. La batterie, elle, continue de tourner à la même vitesse que le preneur soit en contact ou non.

6 - La structure du programme

Le programme JAVA correspondant à cette modélisation est en fait composé de 5 classes. La classe principale, << SimuApplet >>, est une applet qui contient une interface utilisateur. La classe << Contact >>, véritable base de cette modélisation, contient les fonctions de gestion du transfert de l'encre ainsi que les informations relatives à une zone de contact (cf. II.3). Les structures de données nécessaires aux files d'attentes et éléments de longueur sont contenues dans les classes << File >> et << Elem >>. Pour l'affichage et le stockage de courbes et résultats, une classe << CadrePourCourbe >> a été créée.

Le programme lui-même est conçu pour ne comporter qu'un minimum de boucles. Ainsi, le déroulement de la simulation se fait plus claire. De plus, tous les paramètres imposés par le cahier des charges sont des variables déclarées comme champs de la classe SimuApplet ce qui rend leur accès aisé.

III - Le Simulateur

1 - Présentation

Dans le but de proposer un outil qui soit à la fois pédagogique, accessible et simple d'utilisation, une interface a été conçue. Le simulateur est contenu dans une applet JAVA. Cela lui procure la possibilité d'être installé sur un réseau. Pour fonctionner, la machine hôte doit disposer d'un navigateur JAVA et des plugs-in JAVA que l'on peut se procurer gratuitement sur www.sun.fr .

Une telle interface entre l'utilisateur et la machine doit garantir un niveau de sécurité maximal en ce qui concerne l'intégrité de la machine et du serveur qui héberge l'application. De même, l'utilisateur doit être informé de l'état du simulateur et de la démarche à suivre. Ces contraintes imposent une démarche rigoureuse dans la construction du programme, mais surtout, une partition de tous les évènements possibles doit être mise à jour afin de pouvoir parer les erreurs nuisibles.

D'autre part, la programmation de ce simulateur a nécessité l'utilisation de composants << lourds >>, et ce pour éluder toute utilisation d'éléments qui ne seraient pas supportés par une majorité de machines. Ainsi, les traditionnels composants JAVA.awt ont été préférés aux composant JAVA.swing plus récents, plus << légers >> mais également plus marginaux.

Le produit fini que j'ai présenté à la fin de mon stage à l'EFPG était composé d'une disquette contenant :

- Simulateur, version certifiée et signée(écriture sur disque), son environnement WEB, ses fichiers source(code), sa documentation (format javadoc), sa clé et son certificat, ses classes JAVA. Prêt à installer et à utiliser.(compressé)

- Simulateur, version standard(pas d'écriture sur disque), son environnement WEB, ses fichiers source(code), sa documentation (format javadoc), ses classes JAVA. Prêt à installer et à utiliser. (compressé)


	Version signée

	Version standard

Deux versions ont été élaborées, une qui permet une utilisation sans contraintes autre que l'installation d'un plug-in JAVA, l'autre plus performante qui requiert en plus l'acceptation d'un certificat de sécurité.

2 - Interface utilisateur

Les paramètres imposés par le cahier des charges sont tous ajustables par l'utilisateur, et ce par l'intermédiaire d'une interface. Celle-ci a pour vocation de rendre l'utilisation du programme simple et fonctionnelle.

La saisie des paramètres se fait par l'intermédiaire de champs que l'utilisateur peut à souhait modifier ou ignorer. Des valeurs par défaut, réglages courants, sont installées (figure 16).

Le Simulateur renvoie des informations dynamiquement, c'est à dire que dès que son état est modifié (saisie d'un paramètre, bouton appuyé, etc...) l'interface est mise à jour. Ainsi, les étiquettes des champs et la zone de messages située en dessous du bouton rouge peuvent afficher des informations relatives à la saisie des paramètres ou à l'état du simulateur.

Pour permettre un bon filtrage des paramètres et éviter tout disfonctionnement, j'ai consacré près de trois semaines du stage à tester le programme et son interface. Cela m'a amené à réaliser un certain nombre de modifications et à mettre en place une barrière de filtres. La saisie étant dynamique, l'utilisateur est instantanément informé lorsqu'il entre une valeur incorrecte (figure 17).

Dans le programme, la capture d'erreurs se fait grâce à l'instruction try.. catch qui encadre les portions du code susceptibles de générer des erreurs ou exceptions. Toutefois, une hiérarchisation de la capture des erreurs était nécessaire pour que l'information retournée à l'utilisateur soit la plus claire possible.

L'interface telle qu'elle est présentée ci-dessus est une applet que l'on peut déployer depuis un compilateur JAVA ou, plus intéressant, que l'on peut intégrer dans une page HTML. Nous avons retenu la deuxième possibilité pour les nombreux avantages qu'elle apporte. Cependant, il reste possible de la lancer ET de la modifier depuis un compilateur. Dans l'hypothèse où le programme serait repris pour une extension ou pour tout autre motif, le code est disponible et commenté, spécifications et documentation compris (cf. annexes).

3 - Les Résultats

Le simulateur fournit plusieurs sortes de résultats. Pour avoir un aperçu du déroulement de la simulation, deux graphiques sont immédiatement affichés à l'écran. Ces deux graphes sont très représentatifs, l'un expose l'épaisseur d'encre moyenne sur chaque feuille (abscisses : numéro de feuille ; ordonnées : épaisseur d'encre, figure 18), l'autre l'épaisseur d'encre sur la dernière feuille(abscisses : distance au bas de la feuille ; ordonnées : épaisseur d'encre, figure 19).

Ces résultats ne sont pas suffisants pour une étude approfondie de la simulation, le scientifique doit pouvoir observer comment a évolué le flux de l'encre dans tout le système pendant la simulation. Des résultats significatifs peuvent sortir de cette étude. C'est pourquoi le simulateur stocke toutes les épaisseurs d'encre dans chaque contact et à chaque instant. Cette quantité de données peut être exploitée grâce, par exemple, à Excel de Microsoft.

Une difficulté consistait à savoir comment et où stocker toute cette information. Pour le comment, la solution retenue a été de stocker temporairement les données dans un StringBuffer, variable de stockage de chaînes de caractères qui permet des manipulations très efficaces (cf. doc. de SUN pour JAVA), de les vider dans un conteneur lorsque le StringBuffer est plein et de recommencer ainsi jusqu'à la fin de la simulation. Cette méthode a l'avantage d'éviter d'utiliser les fonctions << d'écriture en fin >> pour chaque nouvelle donnée, ces fonctions sont en effet assez << lourdes >>.Le conteneur est une fenêtre dans la version standard et un fichier sélectionné par l'utilisateur dans la version certifiée. Dans les deux cas les données sont présentées tel que le montre la figure 20.

Chaque colonne correspond à un contact (références dans la figure 7), chaque ligne à un pas de temps( à partir de t=0). Pour exploiter les données fournies par la version standard, l'utilisateur doit copier le contenu de la fenêtre et le coller dans un éditeur de texte (wordpad, nedit, etc...).

Dans la version signée, les données sont donc écrites dans un fichier que l'utilisateur choisit. Cette sélection se fait par l'intermédiaire d'une boîte de dialogue de type FileDialog(Figure 21). Elle permet de naviguer dans les répertoires et registres de la machine hôte. L'utilisateur choisit ainsi le répertoire et le fichier dans lesquels il souhaite écrire les résultats. Si ce fichier n'existe pas, la machine demande la permission de le créer, sinon elle demande la permission d'écraser les données existantes.

Le fichier spécifié ne doit pas avoir d'extension, ou alors des extensions dédiées aux données( « .data » ou autres). La taille de ce fichier dépend des paramètres saisis. La formule qui donne la taille du fichier est la suivante :

DiamètreDuPortePlaque

TailleDuFichier = × × ×

NombreDeFeuilles NombreDeContacts TailleDuTypeDouble

LongueurDuPas

Cette expression est déduite du code. A chaque pas de temps, tous les contacts sont parcourus. Pour tous, la valeur de l'épaisseur du film d'encre qui est une variable de type double est écrite dans le fichier. Le nombre de pas pour faire un tour est exprimé en fonction du diamètre du porte-plaque et de la longueur du pas (cf. II.2). La boucle est répétée tant que le nombre de feuilles n'est pas atteint.

TailleDuFichier

NombreDeFeuilles

()2832416

octets×××

LongueurD uPas

TailleDuFichier(Mo) 0.1×	NombreDeFeuilles
	LongueurDuPas

Cette valeur ne prend pas en compte, la zone de texte au début des fichiers résultats, zone qui contient un rappel des paramètres de la simulation.

4 - Environnement WEB

L'utilisation de ce simulateur ainsi que l'exploitation des résultats qu'il fournit requiert des connaissances d'ordre technique. C'est pourquoi le simulateur a été intégré dans une page HTML que j'ai conçue, celle-ci contient un rappel du procédé offset, des définitions, des schémas du modèle (avec les références/numéros des contacts), un manuel d'utilisation et des liens vers les sites Internet de l'UFRIMA, de l'EFPG et de l'UJF).

5 - Certificat & Sécurité

Le modèle de sécurité original fourni par la plate-forme Java est connu sous le nom de << sandbox ». Il a été conçu dans le but de mettre à disposition de l'utilisateur un environnement qui contrôle l'accès aux ressources du client. Le principe de la << sandbox >> est de considérer que le code local (application) a un accès total (trusted) aux ressources vitales du système (tel que le système de fichiers) alors que le code téléchargé sur le Web (applet) ne peut accéder qu'à des ressources limitées (untrusted).

Par défaut, une applet est untrusted, pour que l'applet puisse avoir accès aux ressources du système, il est nécessaire de << signer >> et << certifier >> l'applet. L'utilisateur se verra alors proposer, au démarrage de l'applet, d'autoriser ou non cette applet à avoir tous les droits (figure 23). C'est à ce moment que sera affichée la signature du concepteur.

Il existe plusieurs méthodes pour signer et certifier une applet. Soit on passe par un organisme qui entamera alors une procédure de vérification de l'entreprise, soit on utilise les outils fournis par les développeurs. La première est payante et plutôt destinée aux sites professionnels ou commerciaux. J'ai donc opté pour la méthode << manuelle >>. Il faut alors utiliser les outils du JDK fourni par SUN, keytool et jarsigner. (cf. annexes, Sécurité et certificat)

Une fois signée et certifiée, l'applet peut écrire sur le disque si l'utilisateur accepte le certificat. C'est le cas pour la version signée du simulateur. Il en devient plus performant car des données stockées dans une fenêtre utilisent la mémoire vive (RAM) de l'ordinateur, c'est le cas de la version standard du simulateur, alors que des données écrites directement dans un fichier ne monopolisent pas d'espace mémoire (vive). On peut ainsi réduire la longueur du pas et augmenter le nombre de feuilles de façon considérable, et ce dans les limites de la machine.

Conclusion

Le cahier des charges a été respecté et les améliorations réalisées ont un potentiel exploitable dès à présent. En effet, le simulateur est fonctionnel et accessible au plus grand nombre de par sa mise sur le réseau sur le site de l'EFPG ( www.efpg.inpg.fr). Son aspect pédagogique et scientifique est appuyé par une interface claire et commentée, mis à la portée de l'étudiant jusqu'à celle du spécialiste.

La modélisation du transfert de l'encre dans la batterie d'encrage d'une presse offset est aujourd'hui sujet de recherches assez diversifiées. Les applications futures de tels modèles permettront la création de systèmes automatisés d'optimisation du système d'impression. Le prochain cap à franchir est de modéliser le système d'encrage dans son intégralité. Le modèle élaboré lors de ce stage ne considère qu'une coupe du système. Plusieurs propriétés du système, comme le mouvement de << balade >> de certains rouleaux ou encore comme le profil d'encrage, ne sont toujours pas prises en considération.

C'est une grande satisfaction pour moi d'avoir mené ce projet à terme. J'en tire une expérience substantiellement accrue, notamment par rapport à l'organisation dans le travail. Ainsi, j'ai appris à m'adapter à de nouvelles méthodes dans les domaines de la programmation, de la rédaction, de la documentation et de la stratégie de projet.

D'autre part, une observation très nette se dégage de tout le travail réalisé : les mathématiques alliées à l'informatique sont des outils dont la puissance n'a de limites que l'imagination. La formation suivie en IUPMAI développe une double compétence dans ces deux disciplines. Cet atout est une grande source de motivation relativement aux objectifs de mon cursus universitaire.

Finalement, je suis convaincu que de plus amples avancées peuvent être réalisées par le << mariage >> d'un plus grand nombre encore de spécialités. J'ai regretté à plusieurs reprises pendant mon stage de ne pas avoir les compétences ou les ressources nécessaires pour être plus créatif et innovant. C'est pourquoi, selon moi, il est indispensable qu'une nouvelle application passe entre de nombreuses mains, quitte à être modifiée, pour en extraire un maximum de possibilités.

Bibliographie

- J. Mac Phee, P. Kolesar and A. Federgun . «relationship between ink coverage and mean ink residence time» , Advances in printing Science and Technology , 1986.

- John Mac Phee. «Fundamentals of lithographic printing», volume 1 «mechanics of printing», GA TF Press (Pittsburgh), 1998.

- Mac Phee J., An engineer's Analysis of the Lithographic Printing Process, TAGA Proceeding, p.23'7-2'7'7, 19'79.

- G. Baudin, R. Catusse, K. Boumaïza. «Transfert de l'encre dans le système d'encrage d'une presse offset», 8^èmecongrès francophone de Génie des Procédés, texte paru dans Reant Progrès en Génie des Procédés, volume 13, édition Lavoisier, p.4'73, 2001.

- Farida Seddik. «Transfert de l'encre dans le système d'encrage d'une presse offset», prérapport de stage en laboratoire LGP2, 2002.

Annexes

a) Sécurité et Certificat

Pour signer et certifier une applet, il est d'abord indispensable de créer une archive pour son programme il s'agit d'un fichier que le navigateur chargera et qui fait référence à tous les fichiers utilisés pour l'exécution du programme. Ce fichier est de type « .jar » . On crée ce dernier à partir d'un expert proposé par Jbuilder.

Le certificat et l'archive signée ainsi créés, ils doivent être appelés par le fichier HTML contenant l'applet :

!!! Il est très important d'être rigoureux dans la définition des chemins d'accès !!!

b) Diagrammes de Gantt

c) Listings

Les listings de toutes les classes utilisées sont présentés (32 pages). Communes aux deux versions, File, Elem, Contact et CadrePourCourbe sont en un exemplaire. Les deux versions de SimuApplet sont imprimées.

- SimuApplet.java, version standard.(12 pages) - SimuApplet.java, version signée. (13 pages) - File.java(1 page)

Je tiens à souligner que le code est commenté, spécifié et documenté. La documentation n'est pas jointe à ce rapport, elle est obtenue par extraction des commentaires du code par la commande javadoc. Elle se compose de plusieurs fichiers HTML formatés. Elle a été fournie avec le reste du projet à l'EFPG. Ainsi, quiconque souhaite revenir sur la programmation à tous les éléments nécessaires pour le faire.

GNU Free Documentation License Version 1.2 November 2002

59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document

straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file

format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats

include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the

machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in

formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title"

of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies

to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the

Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.