+ 80.000 tags!
Cimplicity beheert vectra- & astralijn

Voor de visualisatie en het beheer van de nieuwe Astra assemblagelijn koos Opel Belgium voor Cimplicity. Terzelfdertijd werden de Vectra lijn en de Power Plant binnen hetzelfde pakket geïntegreerd. Hoe de vork aan de steel zit, licht volgende bijdrage toe.

Met de komst van de nieuwe Astra, ongeveer drie à vier jaar geleden, werd in de koetswerkafdeling heel wat uitbreiding en vernieuwing gedaan en met maar liefst een driehonderdtal nieuwe robots was dit beslist geen kleine verandering. Om het volledige systeem te integreren was er de nood aan een centraal controle- en managementsysteem, dat via een netwerk gekoppeld kon worden met de nieuwe en bestaande installaties. Na een uitgebreide studie werd er geopteerd voor Cimplicity van GE-Fanuc. Door de integratie werd het mogelijk de ganse afdeling te controleren vanuit één centrale controlekamer en eveneens aan een geautomatiseerde productie- en foutenopvolging te doen.

Systeemarchitectuur
Het geheel bestaat uit ongeveer 190 Bosch PLC’s die via het plantnetwerk (MAP Ethernet) verbonden zijn met twee Unix systemen. De reeds bestaande PLC’s en systemen van Allen Bradley, Modicon en GEM daarentegen zijn aan een NT-server gehangen. Een tweede NT-server wordt gebruikt om visualiseringsborden (VMS = Visual Management Systeem) met productiecijfers aan te sturen.
Alle servers hebben een uplink naar het reeds bestaande Office Automation netwerk met de reeds bestaande "Office PC’s" waarvan er ongeveer een zestigtal als viewer gebruikt worden om via de servers gegevens, rapporten en statusbeelden van het proces te krijgen.

Servers
Een Unix-systeem diende ingezet te worden om de MAP-verbinding met alle Bosch PLC’s te kunnen verwezenlijken. Door twee Unix-servers, voorzien van Cimplicity H/U 3.5 te gebruiken werd een redundant systeem bekomen, waarbij elke server op zich nog specifieke taken te verwerken heeft. Zo communiceren beide servers met alle Bosch PLC’s en viewers, maar wordt server 1 speciaal gebruikt voor alarmlogging en server 2 voor datalogging en de "Step Sequence Diagnose"(SSD). Naast de twee Unix-servers zijn er ook nog de twee NT-servers. De eerste heeft eigenlijk dezelfde functie als de twee Unix-servers enkel met dat verschil dat hij de communicatie maakt met alle reeds bestaande Allen Bradley, Modicon en GEM PLC’s. Ook hier wordt er weer gebruik gemaakt van Cimplicity, maar dan wel van Cimplicity NT 3.2. Dezelfde versie van Cimplicity wordt ook gebruikt voor de tweede NT-server, die op zijn beurt communiceert met de VMS-borden, die de productiegegevens en eventueel andere cijfers of berichten visualiseren over de ganse afdeling, inclusief de bureaus.

Viewers
Zoals reeds gezegd hebben al deze servers een uplink naar het Office Automation netwerk (TCP/IP Ethernet) waarop een zestigtal Cimplicity viewers zijn aangesloten. Naast de normale Office toepassingen zoals Excel, Word, en Acces, zijn deze PC’s voorzien van Cimplicity Viewer software. Hiermee kan er informatie gehaald worden uit de verschillende servers gaande van statusbeelden, alarmen en meldingen, tot productiecijfers en cyclustijden. Zo is het zelfs in één beeld mogelijk gegevens vanuit een Unix-server en een NT-server te verenigen zonder dat enig verschil is op te merken.

80.000 punten
Om gegevens uit de verschillende PLC’s te halen diende men per PLC de gewenste punten te verzamelen en aan de server te bezorgen. Door gebruik te maken van een gestandaardiseerde datablok, met vaste posities, werden al deze punten gestructureerd in de servers binnengelezen. In totaal worden zo een 80.000 punten binnengelezen en verwerkt. Met deze standaard interface en via een speciaal ontwikkeld programma, "Pointgeneration" genaamd, werden automatisch PuntID’s gecreëerd met hun alarmklasse, beschrijving, alarmtekst en offsetnummer. Na het aanmaken van deze "Pointgeneration"-bestanden werden deze via het programma DPL_Export uitgebreid met de nodige Cimplicity velden en geëxporteerd in een ander bestand bruikbaar voor Cimplicity.

Logging
Het loggen van alle gegevens gebeurt in de Unix-servers. Hier worden "log-files" aangemaakt voor de alarmen, gegevens en SSD’s. Nadien worden deze log-files door een in CimBasic geschreven uitvoerbestand uitgelezen en in verschillende tabellen van de SQL-database gegoten.

Rapporten
Met een Acces toepassing worden de gegevens uit de SQL-database gehaald en in de verschillende rapporten verwerkt. Enkele voorbeelden van gebruikte rapporten zijn: alarmlistings, alarmfrequentierapporten, alarm top tien grafieken, gegevensrapporten van een specifieke installatie en van alle installaties tesamen etc. Deze rapporten kunnen op afroep of op vastgelegde tijdstippen gegenereerd worden. De SSD rapporten daarentegen worden automatisch gegenereerd wanneer een bepaalde fout een bepaalde frequentie- of een tijdsduurlimiet overschrijdt.

Gebruikersschermen
De procesvisualisatie die op alle viewers beschikbaar is, bestaat uit een aantal schermen die door de operator geraadpleegd kunnen worden. Zo is er een globaal afdelingsoverzicht, met statusbeelden van koetswerk noord en zuid. Vaste kleurconventies laten een vlugge lokalisatie en herkenning van de aard van de fout toe en door een druk op desbetreffende zone kan men inzoomen tot op installatieniveau. Robotten, stations, lassturingen, deuren, laadoperaties, liften en transporten worden dynamisch weergegeven, conform de actuele status van bijv. noodstoppen, fouten, tijdsoverschrijdingen, buiten gebruik melding, enz.
Buiten de statusbeelden beschikt men per installatie nog over schermen met detail alarmlijsten, productiegegevens, aanduiding van de productie-flow en de plaats-coördinaten. Op deze manier kan het ganse proces vanuit de controlezaal of de verschillende operatorstations geraadpleegd en eventueel beheerd worden. Productierendementen worden ingesteld. De uurresultaten verschijnen in het productiebeeld, met aanduiding van het productiestreefgetal. Cyclustijden, productietijdschema’s, informatie voor Visual Management displays, verschillende setpunten en kloksynchronisaties worden allen centraal beheerd.

Programmatie
Voor de programmatie van de verschillende schermen en rapporten werd uitvoerig gebruik gemaakt van de mogelijkheden die Cimplicity HMI biedt. Object georiënteerde programmatie, eenvoudig te implementeren Visual Basic scrips, groeperen van objecten met hun verschillende proporties, toekenning van variabelen aan objecten, OLE-ODBC componenten en ACTIVE X zijn allemaal mogelijk met Cimplicity.
Deze hulpmiddelen hebben niet enkel de programmatie van het project aanzienlijk vergemakkelijkt, maar bovendien de implementatietijd aanzienlijk verkort. Daar Cimplicity HMI een volwaardige 32-bits pakket is, werden na tuning geen problemen vastgesteld met betrekking tot de responstijden. Wat de dynamische beelden, de alarmweergave of de historische logging betreft liep de indiensttreding evenzeer probleemloos.
Een half miljoen events worden per dag weggeschreven naar een SQL database onder Windows NT. Door gebruik te maken van de ODBC-mogelijkheden is de verwerking van de gegevens met Acces en Excel eenvoudig. Downtime analyse, alarmfrequentie-analyse, installatie- en productiebeschikbaarheid worden historisch ontleed. De precisie van het systeem is daarbij zeer opvallend. Niettegenstaande het groot aantal loggings per dag vertoont het systeem geen afwijkingen die groter zijn dan enkele seconden. De openheid van Cimplicity heeft in elk geval vele voordelen opgeleverd binnen het totaalproject.

Opel Belgium a choisi Cimplicity pour la visualisation et le contrôle de sa nouvelle ligne d’assemblage de l’Astra. La ligne de la Vectra et le Power Plant ont, du même coup, été intégrés dans le projet. Un bref aperçu.

L’arrivée de la nouvelle Astra, voici trois ans, allait de pair avec une extension et une modernisation du département carrosserie. L’acquisition de quelque 300 nouveaux robots représentait évidemment un gros changement. Pour intégrer l’ensemble, il fallait un système de contrôle et de gestion centralisé, pouvant être relié par un réseau aux installations nouvelles et existantes. Après une étude approfondie, le choix se porta sur Cimplicity de GE Fanuc. Par cette intégration, il devint possible de contrôler tout le département au départ d’une salle de contrôle centrale et d’effectuer un suivi automatique de la production et des erreurs.

Architecture du système
L’ensemble comprend 190 PLC de marque Bosch, reliés au travers du réseau de l’usine (MAP Ethernet) à deux systèmes Unix. Les PLC et autres systèmes existants d’Allen Bradley, Modicon et GEM sont par contre reliés à un serveur NT. Un deuxième serveur NT est utilisé pour piloter les tableaux de visualisation (VMS = Visual Management System) affichant les chiffres de production.
Tous les serveurs ont une liaison ascendante vers le réseau actuel ‘Office Automation’ reliant les ‘Office PC’ existants. Une soixantaine de ceux-ci sont utilisés comme simple poste de visualisation pour obtenir via les serveurs des données, des rapports et des images d’états du processus.

Serveurs
Il fallait implémenter un système Unix pour pouvoir réaliser la connexion MAP avec tous les PLC Bosch. L’utilisation de deux serveurs Unix, équipés de Cimplicity H/U 3.5, a permis d’obtenir un système redondant au sein duquel chaque serveur doit néanmoins traiter certaines tâches spécifiques. Les deux serveurs communiquent ainsi avec tous les PLC Bosch et postes de visualisation, mais le serveur 1 est utilisé spécialement pour l’enregistrement des alarmes et le serveur 2 pour l’enregistrement des données et le ‘Step Sequence Diagnose’ (SSD). Outre les deux serveurs Unix, il y a également deux serveurs NT. Le premier a la même fonction que les deux serveurs Unix à la différence qu’il établit la communication avec tous les PLC existants d’Allen Bradley, Modicon et GEM. Ici aussi, Opel utilise Cimplicity, mais dans sa version Cimplicity NT 3.2. Cette même version est utilisée pour le deuxième serveur NT, qui communique à son tour avec les tableaux VMS, qui affichent les données de production et éventuellement d’autres chiffres ou messages dans tout le département, y compris dans les bureaux.

Postes de visualisation
Comme nous l’avons déjà mentionné, tous ces serveurs disposent d’une liaison ascendante vers le réseau Office Automation (TCP/IP Ethernet) auquel sont raccordés une soixantaine de postes de visualisation Cimplicity. Ces PC sont équipés des habituelles applications Office telles que Excel, Word et Access ainsi que du logiciel de visualisation Cimplicity. Celui-ci permet d’extraire des informations des différents serveurs. Ces informations couvrent les images d’états, alarmes et messages ainsi que les chiffres de production et temps de cycles. Il est même possible de rassembler les données d’un serveur Unix et d’un serveur NT sans qu’aucune différence ne se marque.

80.000 points
Pour extraire des données des différents PLC, il fallait rassembler les points souhaités par PLC et les envoyer au serveur. Par l’utilisation d’un bloc de données standardisé, contenant des positions fixes, tous ces points ont été stockés de façon structurée dans les serveurs. Un total d’environ 80.000 points sont ainsi lus et traités. Grâce à cette interface standard et à l’aide d’un programme spécialement conçu à cette fin, nommé ‘Pointgeneration’, des PuntID ont été automatiquement créés avec leur classe d’alarme, leur description, texte d’alarme et valeur d’offset. Après la réalisation, ces fichiers ‘Pointgeneration’ sont complétés au travers du programme DPL_Export avec les champs nécessaires à Cimplicity et ensuite exportés dans un autre fichier pouvant être exploité par Cimplicity.

Enregistrement
L’enregistrement des données se fait dans les serveurs Unix. C’est ici que sont réalisés les ‘log-files’ pour les alarmes, les données et les SSD. Ces log-files sont ensuite lus dans un fichier d’exécution créé en CimBasic et injectés dans différents tableaux de la base de données SQL.

Rapports
A l’aide d’une application Access, les données sont extraites de la base de données SQL et traitées dans les différents rapports. Parmi les rapports utilisés, nous avons les listings d’alarmes, les rapports de fréquence d’alarmes, les graphiques des dix alarmes les plus fréquentes, les rapports de données d’une installation spécifique et de l’ensemble des installations, etc. Ces rapports peuvent être générés sur demande à des moments bien précis. Les rapports SSD, par contre, sont automatiquement générés lorsqu’une certaine erreur dépasse une limite de fréquence ou de durée de temps.

Ecrans utilisateurs
La visualisation du processus disponible sur tous les postes de visualisation comprend plusieurs écrans pouvant être consultés par l’opérateur. Ceci permet un aperçu global du département, avec des images d’états de la carrosserie nord et sud. Des conventions de couleurs fixes permettent une localisation rapide et une reconnaissance du type d’erreur. En cliquant sur la zone en question, vous pouvez faire un saut au niveau de l’installation. Les robots, stations, postes de soudage, portes, opérations de chargement, monte-charges et convoyeurs sont représentés dynamiquement, en ce compris les arrêts d’urgence, les erreurs, les dépassements de temps, les messages hors service, etc.
Outre les images d’états, l’utilisateur dispose, par installation, d’écrans reprenant les listes détaillées des alarmes, des données de production, l’indication du flux de production et les coordonnées des emplacements. Tout le processus peut ainsi être consulté et éventuellement géré à partir de la salle de contrôle ou des différentes stations opérateur. Des rendements de production sont établis. Les résultats horaires apparaissent dans l’image de production, indiquant le chiffre de production à réaliser. Les temps de cycles, les calendriers de production, l’information pour les affichages du ‘Visual Management’, les différents points de consigne et les synchronisations d’horloge sont tous gérés d’un point central.

Programmation
La programmation des différents écrans et rapports s’appuie fortement sur les possibilités offertes par Cimplicity HMI. Une programmation orientée objet, des scripts en Visual Basic faciles à implémenter, le regroupement d’objets avec leurs différentes proportions, l’attribution de variables à des objets, des composants OLE-ODBC et ACTIVE X… tout cela est possible avec Cimplicity. Ces outils ont, d’une part, considérablement facilité la programmation du projet et d’autre part engendré une réduction significative du temps d’implémentation. Cimplicity HMI étant un progiciel 32 bits de qualité supérieure, aucun problème n’a été constaté au niveau des temps de réaction après la mise au point. En ce qui concerne les images dynamiques, la représentation des alarmes ou l’enregistrement de l’historique, la mise en service n’a, de même, présenté aucun problème.
Un demi million d’événements sont transférés quotidiennement vers une base de données SQL tournant sous Windows NT. Grâce à l’utilisation des possibilités ODBC, le traitement des données avec Acces et Excel est simple. Analyse des temps d’arrêt, analyse de la fréquence des alarmes, disponibilité de l’installation et de production sont analysés historiquement. La précision du système à cet égard est remarquable. Nonobstant le grand nombre d’enregistrements par jour, le système ne montre aucune déviation supérieure à quelques secondes. L’ouverture de Cimplicity a incontestablement offert de nombreux avantages tout au long du projet. (hp)