Machinebesturing
Gebruik Object Oriented-programmatie
samen met IEC 61131

version française

Object Oriented-programmeren is alles behalve nieuw. De sterkte van OO is dat het, vergeleken met traditioneel programmeren, een veel duidelijke structuur biedt. Voor machinebouw kan de combinatie van IEC 61131 met Object Oriented-programmeren (IEC 31113-3) de ontwikkelaar het leven makkelijker maken. Maar nog belangrijker: de ontwikkelingstijd van een machinesturing - en vooral latere varianten - zal een flink stuk korter zijn.

De machinebesturing vervangt steeds meer de traditionele PLC. Dat is niet zo verwonderlijk, want het ooit zo recht-toe recht-aan cyclische programma dat in de PLC continu draait, biedt niet langer voldoende structuur. Besturingen zijn een stuk complexer vandaag: naast de logische taken, moet de PLC meteen ook een hele rits andere besturingstaken afhandelen, zoals motion control, HMI, rekenkundige bewerkingen, datalogging, alarmering en communicatie. IEC 61131 heeft hier al veel in verbetering in gebracht, maar - ondanks alles - blijft het nog steeds zo dat ‘hoe langer mijn programma, hoe meer tijd nodig is om alle regels af te werken’.

Modulariteit
En daar komt OO in het spel. In een OO-omgeving wordt elke afzonderlijke taak (object) voorzien van een eigen functie met eigen code (methode), een eigen database en een eigen cyclustijd. Dit maakt dat ook onderhoud aan het in een OO geschreven programma eenvoudiger is. Modulariteit staat voorop bij Object Oriëntatie, maar de kracht schuilt ook in de eenvoudiger programmering ten opzichte van de meer traditioneel georiënteerde programmeertalen. Een object hoeft slechts eenmaal te worden ‘geprogrammeerd’, waarna het steeds kan worden hergebruikt. Niet onbelangrijk: een eenmaal gemaakt object kan als zelfstandige eenheid worden getest. Met andere woorden: het object kan geïsoleerd worden van de rest van het programma.

Innovatief
Hét grote voordeel van OO ligtvoor de hand: tijdsbesparing. De Client/Server-technologie in combinatie met objectgeoriënteerde programmering en een grafische presentatie, maakt een veel sneller en eenvoudiger realisatie van machinebesturingen mogelijk. De denkwijze en de manier van presenteren slaan een brug tussen de constructeur en softwareontwikkelaar.
Voordat begonnen wordt met het schrijven van de eerste regel code, wordt eerst vastgesteld uit welke afzonderlijke klassen (functies) de machine bestaat. Elke klasse wordt beschreven en de onderlinge relaties tussen de klassen worden benoemd (client-server kanalen). Vervolgens wordt omschreven wat een klasse moet doen. Oftewel welke functies (methodes) moet de klasse uitvoeren. Denk hierbij aan: Initialiseren, Alarmering, Lezen en Schrijven van variabelen, de cyclische taak (PID, boren, verplaatsen, aan-uitschakelen van ventielen etc.), de real-time taak (servo positioneren, etc.), de background taak (HMI, archivering etc.). Een ‘klasse’ zal zijn gegevens voor de overige klassen verbergen. Andere klassen kunnen deze gegevens niet direct benaderen maar alleen via de publieke Client-Server kanalen. Er wordt een duidelijke scheiding tussen de interface en de implementatie aangebracht. Dit is de essentie van Object Oriented programmeren.
Elke klasse kan nu door een andere programmeur worden gebouwd en kan afzonderlijk worden getest. Een eenmaal goedgekeurde klasse kan probleemloos worden opgenomen in het project en natuurlijk in de bibliotheek.

IEC 31113-3: inclusief OO
De IEC 61131-3 norm gaat nog een stap verder doordat hij uitgebreid is met objectgeoriënteerde programmering. Een programmeur kan zich concentreren op de werking van zijn specialisme. Hij zorgt voor de interface naar de omgeving, zoals van te voren is besproken. Zodra hij zijn informatie heeft verkregen kan hij deze verwerken en nieuwe informatie beschikbaar stellen. Met andere woorden: zodra hij van de fotocellen informatie krijgt dat er een werkstuk op zijn plek ligt, kan de bewerking beginnen. Wanneer deze handeling klaar is gaat er een signaal naar de volgende actie bijv. transporteur die zijn beweging in gang zet. De transporteur of rollenband heeft een eigen klasse. Deze is zo geschreven dat automatisch herkend wordt of de band aan het begin van een lijn staat, tussen twee stations in of aan het eind. Automatisch wordt vollopen en aflopen bewaakt. Deze universele klasse wordt onderhouden door één programmeur die eventuele nieuwe wensen van collega’s verwerkt. Zijn collega’s hebben steeds de beschikking over de laatste versie. De herkenbaarheid wordt enorm vergroot, de betrouwbaarheid neemt toe omdat de klassen uitgebreid getest kunnen worden en de ontwikkeltijd van nieuwe applicaties wordt enorm terug gebracht. De inbedrijfstelling wordt teruggebracht tot een minimum.

Debuggen
De grafische weergave van de klassen toont ‘on-line’ duidelijk de samenhang tussen de objecten. In één overzicht zijn het totale project, de functionaliteit, dataverkeer en de interfaces beschikbaar. Complexe koppelingen zijn hierdoor eenvoudig te herkennen, te controleren en zo nodig te wijzigen. De constructeur herkent zijn machine en de programmeur herkent de klassen. Duidelijk is welke informatie wordt verwacht en welke eventueel mist. De klassen zijn afzonderlijk getest, de interne data is voor het overzicht dus niet meer van belang. Door de informatie terug te brengen tot de essentie wordt het overzicht vergroot, de oorzaak van een probleem zal sneller gelokaliseerd worden en de programmeur van de ‘probleem’ klasse hoeft slechts zijn code te controleren. <<

Kader:
Hoe werkt Object Oriented IEC 61131-3 in de praktijk?

Hoe werkt de combinatie van OO en IEC-61131 (of IEC 61131-3) in de praktijk? We bekeken LASAL Class, één van de eerste object georiënteerde programmeeromgevingen die speciaal ontwikkeld is voor de machinebouw/PLC gebruikers.

Het pakket maakt het mogelijk programmacode te schrijven in structured Text volgens IEC- 61131, Instructielijst (AWL/IL), Ladderdiagram (LD/KOP), C++, en het biedt een interpreter voor volgorde besturingen. Er wordt gebruik gemaakt van client-server technologie, grafische presentatie en object oriëntatie. Op eenvoudige wijze kan met meerdere mensen tegelijkertijd en in verschillende talen aan een applicatie worden gebouwd. (‘multi development possibility’).

De programmeur koppelt objecten langs grafische weg aan elkaar. Hij plaatst bijvoorbeeld een I/O-module (een object) op het scherm. Vervolgens trekt hij een lijn van een serverkanaal naar het gewenste cliëntkanaal van bijvoorbeeld een PID-regelaar (een object). De achterliggende methode ‘softwarecode’ koppelt beide softwarematig aan elkaar. Wat de besturing met de I/O-signalen doet ligt vast in het object dat bij de PLC hoort. Dat kan een eenvoudige functie zijn maar net zo goed een zeer complexe functie. Er kan direct een actuator worden aangestuurd, maar ook een timer- of een tellerfunctie of een diagnosefunctie behoren tot de mogelijkheden. Zelfs een complete servoas, een uitneemunit van een spuitgietmachine, een feeder op een verpakkingsmachine, of… kunnen een object vormen. Zo wordt het net zo makkelijk om een servoas aan de hardware te koppelen als het aansluiten van een sensor op een ingang. Specifieke kennis van de klassen is niet nodig om deze te gebruiken. De klassen inclusief hun methodes (functies) worden vastgelegd in een bibliotheek en zijn geschikt voor hergebruik. Via slepen en het eventueel invullen van de betreffende parameters is dat heel eenvoudig geworden.

Naast LASAL Class is er ook LASAL Screen Editor en LASAL Text beschikbaar. Met LSE kunnen grafische objecten ontworpen worden welke een rechtstreekse koppeling hebben met hun besturingsobjecten. LSE biedt de gebruiker een HMI-interface direct geïntegreerd in zijn programmeeromgeving. De huidige processoren zijn zo krachtig dat één enkele CPU volstaat om mits OO geprogrammeerd zowel de besturingstaak als de HMI taak voor zijn rekening te nemen.
Voorbeelden van toepassingen
Sinds de eerste voorzichtige verkenningen, zijn er diverse toepassingen met de OO-methode gerealiseerd. Collega’s maken collega’s enthousiast en systeemintegratoren zien de voordelen in van het hergebruik, de multi-developer mogelijkheden en de platformonafhankelijkheid. Een relatief eenvoudige boormachine die een stuk metaal moet verplaatsen en met een instelbare steek gaten moet boren. Een ‘slicer’ voor kaas/vleeswaren/brood die ingesteld moet kunnen worden op productdikte, gewicht, presentatie. Een VVVS verticale vorm vul sluitmachine die chips, snoep, groente etc. verpakt waarbij de keuze voor servo, draaistroom of zelfs hydroaandrijving gemaakt moet worden. Een sorter waar de klant zelf het aantal afgifte units wil bepalen, elke unit is een klasse geworden die eenvoudig vanuit de bibliotheek toegevoegd worden afhankelijk van het gewenste aantal.

Ook relatief eenvoudige machines halen overigens hun voordeel uit de OO methodiek.

Slotopmerking
De beschikbaarheid van OO-programmeertools zal de komende jaren alleen maar toenemen. Studenten komen immers met deze bagage van hun studie en zijn gewend om in deze structuren te denken. Voor de huidige PLC-programmeurs zal het weer een nieuwe uitdaging zijn om zich ook deze techniek eigen te maken. Dat dat zal lukken lijdt geen twijfel, de stap van schuifregister naar ARRAY en struct is eind vorige eeuw ook gelukt. <<

Commande machine
Utilisez la programmation orientée objet
avec la norme IEC 61131

La programmation orientée objet est tout sauf neuve. La force de l’orientation objet (OO), par rapport à la programmation traditionnelle, réside dans la structure plus claire qu’elle propose. Pour la construction de machines, la combinaison de l’IEC 61131 avec la programmation orientée objet (IEC 31113-3) peut faciliter la vie du développeur. Et plus important encore: le délai de développement d’une commande machine – et surtout des variantes ultérieures – sera sensiblement réduit.

La commande machine remplace de plus en plus le PLC traditionnel. Cela n’a rien de surprenant car le programme cyclique tout ou rien qui tourne en continu dans le PLC n’offre plus une structure suffisante. Les commandes actuelles sont plus complexes: outre les tâches logiques, le PLC doit aussi gérer une série d’autres tâches de commande comme le contrôle de mouvement, la HMI, les opérations de calcul, l’enregistrement de données, les alarmes et la communication. La norme IEC 61131 a déjà apporté de grandes améliorations mais nous en sommes – malgré tout – toujours à une situation où ‘plus mon programme est long, plus la gestion de toutes ces lignes est longue’.

Modularité
Et c’est là qu’intervient l’OO. Dans un environnement OO, chaque tâche distincte (objet) est dotée d’une fonction propre et d’un code propre (méthode), de sa base de données et de son temps de cycle. De ce fait, la maintenance d’un programme écrit en OO est fortement simplifiée. L’OO met la modularité à l’avant-plan. Néanmoins, sa force réside aussi dans la simplification de la programmation par rapport aux langages de programmation à orientation plus traditionnelle. Un objet ne doit être programmé qu’une seule fois, ensuite il est en permanence réutilisable. Cette facilité a son importance: un objet utilisé une fois peut être testé comme unité indépendante. En d’autres termes: l’objet peut être isolé du reste du programme.

Innovateur
Le grand avantage de l’OO est évident: le gain de temps. La technologie client/serveur en combinaison avec la programmation orientée objet et une présentation graphique, permet une réalisation plus rapide et plus simple des commandes machine. La méthode de réflexion et la manière de présentation jettent un pont entre le constructeur et le développeur de logiciels.
Avant de démarrer l’écriture de la première ligne de code, il faut d’abord déterminer les différentes classes (fonctions) de la machine. Chaque classe est décrite et les relations réciproques entre les classes sont nommées (canaux client-serveur). Vient ensuite la description de la tâche d’une classe, c.-à-d. les fonctions (méthodes) dont elle doit s’acquitter. Pensez par exemple à l’initialisation, au déclenchement d’alarmes, à la lecture et l’écriture de variables, aux tâches cycliques (PID, forage, déplacement, activation-désactivation de vannes…), aux tâches temps réel (positionnement asservi…), aux tâches en arrière-plan (HMI, archivage…). Une ‘classe’ dissimulera ses données aux autres classes. Les autres classes ne peuvent s’approcher directement de ces données, seulement via des canaux client-serveur publics. Il existe une séparation claire entre l’interface et l’implémentation. Voilà l’essence de la programmation orientée objet.
Chaque classe peut désormais être construite par un autre programmeur et testé séparément. Une classe qui a été approuvée peut être reprise sans problème dans le projet et, naturellement, dans la bibliothèque.

IEC 31113-3: y compris l’OO
La norme IEC 61131-3 va un pas plus loin car elle est étendue avec la programmation orientée objet. Un programmeur peut se concentrer sur le fonctionnement de sa spécialité. Il se charge de l’interface avec l’environnement, comme discuté auparavant. Dès qu’il a obtenu son information, il peut la traiter et mettre de nouvelles informations à disposition. En d’autres termes: dès qu’il reçoit des photocellules l’information qu’une pièce de travail est en place, le traitement peut démarrer. Lorsque cette opération est prête, un signal part vers l’action suivante, par exemple le transporteur qui initie son mouvement. Le transporteur ou convoyeur à rouleaux a sa propre classe. Celle-ci est décrite de manière à reconnaître automatiquement si la bande se trouve en début de ligne, entre deux stations ou à la fin. Le remplissage ou le vidage est automatiquement surveillé. Cette classe universelle est maintenue par un seul programmeur qui traite les éventuelles nouvelles demandes de collègues. Ses collègues disposent toujours de la dernière version. La reconnaissance est fortement accrue, la fiabilité augmente car les classes peuvent être testées extensivement et le délai de développement des nouvelles applications est sensiblement raccourci. La mise en service est réduite à son minimum.

Débogage
La représentation graphique des classes montre clairement ‘en ligne’ la cohésion entre les objets. Le projet global, la fonctionnalité, le trafic de données et les interfaces sont disponibles dans un seul aperçu. Les liaisons complexes se reconnaissent, se contrôlent et se modifient dès lors aisément. Le constructeur reconnaît sa machine et le programmeur reconnaît les classes. Les informations escomptées et les informations manquantes sont clairement identifiées. Les classes sont testées séparément, les données internes n’importent donc plus pour l’aperçu. En ramenant l’information à l’essentiel, l’aperçu est agrandi, la cause d’un problème sera plus vite localisée et le programmeur de la classe ‘problématique’ n’a plus qu’à vérifier son code. <<

Cadre:
Comment fonctionne la norme IEC 61131-3 orientée objet dans la pratique?

Comment fonctionne la combinaison de l’OO et de la norme IEC 61131 (ou IEC 61131-3) dans la pratique? Nous avons examiné LASAL Class, un des premiers environnements de programmation orientés objet, spécialement conçu pour les constructeurs de machines/utilisateurs de PLC.

Le progiciel permet d’écrire un code programme en Texte structuré selon la norme IEC-61131, en liste d’instructions (AWL/LIST), en schéma à contact (LD/CONT), en C++ et offre un interpréteur pour les commandes séquentielles. Il a recours à la technologie client-serveur, à la présentation graphique et à l’orientation objet.
Plusieurs personnes peuvent travailler simultanément en toute simplicité à une application dans différents langages (‘multi development possibility’). Le programmeur connecte les objets de manière graphique. Il place par exemple un module d’E/S (un objet) à l’écran. Ensuite, il tire une ligne d’un canal serveur vers le canal client souhaité d’un régulateur PID par exemple (un objet). La méthode sous-jacente ‘code logiciel’ les relie ensemble par logiciel. Ce que fait la commande avec les signaux d’E/S est déterminé dans l’objet qui va de pair avec le PLC. Cela peut être une fonction simple mais cela peut être aussi une fonction très complexe. Un actionneur peut être piloté directement. Cependant, une fonction de temporisation ou de comptage ou encore, une fonction de diagnostic est également envisageable. Même l’asservissement d’un axe complet, une unité d’enlèvement d’une machine de pulvérisation, un distributeur d’une machine d’emballage… peuvent constituer un objet. Il est ainsi tout aussi facile de relier un axe asservi que de raccorder un capteur à une entrée. Pas besoin de connaissances spécifiques des classes pour les utiliser. Les classes, y compris leurs méthodes (fonctions) sont définies dans une bibliothèque et sont aisément réutilisables par simple glissage et remplissage éventuel des paramètres adéquats. Outre LASAL Class, il y a aussi LASAL Screen Editor et Lasal Text. LSE permet de développer des objets graphiques qui ont un lien direct avec leurs objets de commande. LSE offre à l’utilisateur une interface HMI directement intégrée dans son environnement de programmation. Les processeurs actuels sont tellement puissants qu’une seule CPU peut se charger - moyennant une programmation OO - tant de la tâche de commande que de la tâche HMI.

Exemples d’applications
Depuis les premières explorations prudentes, diverses applications ont été réalisées avec la méthode OO. Les collègues suscitent l’enthousiasme d’autres collègues et les intégrateurs de système apprécient les avantages de la réutilisation, les possibilités multi-développeur et l’indépendance de la plate-forme.
Une foreuse relativement simple qui doit déplacer un bout de métal et forer des trous avec un point de réglage. Une trancheuse pour le fromage/la charcuterie/le pain qui doit être réglée en fonction de l’épaisseur de coupe, du poids, de la présentation. Une scelleuse d’emballage vertical plein pour l’emballage de chips, bonbons, légumes… laissant le choix entre un entraînement servo, à courant triphasé ou hydraulique. Un autoclave, des robots multi-axe. Un élevage de vaches laitières nécessitant plusieurs régulations de vannes identiques, une station météo et une commande d’éclairage. Une trieuse permettant au client de déterminer lui-même le nombre d’unités de sortie, chaque unité se matérialisant par le simple rajout d’une classe à partir de la bibliothèque, en fonction de la quantité souhaitée. Ou encore une bobineuse avec une cisaille à la volée, une balance industrielle, une planteuse, une machine de traitement de pâte, des éplucheuses d’oignons… Même des machines assez simples profitent de la méthode OO.

Remarque finale
La disponibilité d’outils de programmation OO ne fera qu’augmenter dans les prochaines années. Les étudiants disposent en effet de ce bagage en fin d’études et sont habitués à réfléchir dans ces structures. Pour les programmeurs de PLC actuels, l’appropriation de cette technique constituera un nouveau défi. Pas de doute qu’ils y parviendront. En effet, le pas du registre à décalage à la matrice et au struct a également été réussi le siècle dernier.<<

 

©