Hem SIGBI Automation ABKontaktSitemap

Spagettikod eller Objektorienterad programmering

Implementera maskinen med rätt programvara och förenkla det komplexa arbetet

OOP objektorienterad programmering spagettikod
Genom att använda den objektorienterade tekniken vid sin mjukvaruutveckling kan man spara mycket tid både genom att återanvända programkod och vid framtida felsökning.
Trots sina uppenbara fördelar finns det inom maskintillverkning en viss försiktighet när det kommer till objektorienterad programmering. Det borde inte vara så. Med rätt programvara kan användaren förenkla en stor del av det komplexa arbete som det innebär att implementera sin maskin.

Ingenjörer och studenter, alla lär och använder objektorienterad programmering

Objektorienterad programmering, förkortat OOP, har funnits på marknaden sedan mer än 30 år tillbaka i tiden. I skolan och på universiteten lär man inte ut något annat. Inom PLC-programmering och automation möter OOP däremot ofta på motstånd. Egentligen svårt att förstå då inget annat område passar lika bra för OOP som just maskintillverkning. Inom OOP har man precis det ”tänk” som utspelar sig hos just varje konstruktör, designer och maskinbyggare. Man tänker i komponenter - t.ex. motorer, växlar osv. Samtidigt önskar utvecklare sig en tydlig, smidig och framförallt gratis utvecklingsmiljö. Utvecklingsmiljö som är objektorienterad och användarvänlig kortar snabbt ner utvecklingstiderna.

Programmera objektorienterat i komplexa projekt och effektivisera arbetet

Vid en närmare genomgång visar det sig att objektorienterad programmering egentligen är mycket enklare än vanlig ”traditionell” PLC-programmering, åtminstone ju mer komplext projektet blir. Utvecklingsverktyget LASAL ifrån SIGMATEK bygger helt på den objektorienterade tekniken. I LASAL använder man från grunden objektorienterade funktioner och har så gjort sedan slutet av 1990 talet. Sigmatek har alltså ett försprång på minst 10 år gentemot automationsleverantörer som idag lanserar det "senaste", "Objektorienterad programmering". Många automationsleverantörer på marknaden använder sig ibland av en påbyggnad som liknar objektorienterad programmering ovanpå den grund, den PLC-programmering, som man tidigare har använt. I framtiden kan man inte undgå OOP så passa på att informera dig nu.

Objektorienterad programmering reducerar risken för rörig kod ex. spagettikod

Vad innebär egentligen OOP mer i detalj? Själva grundidén är att kod och data sammanfattas i logiska enheter. Det är ju egentligen självklart eftersom en viss programkod ansvarar för en viss data och/eller funktion. Programkod och data är sammanfattad och instängd i ett objekt så att främmande programkod utifrån inte kan komma in och påverka något. Bakom ett objekt finns alltid en klass där all programmeringskod och dataelement är inkapslad. Så, varför är det så viktigt? Jo, alla programmerare känner till problemet med rörigt implementerad program. Problemen är tydliga när man delar på variabler kors och tvärs i programmet och man kan inte riktigt förutse vad en ändring kommer att leda till för den övriga styrningen.

Klar och tydlig struktur på hur man får ändra och bearbeta variablers värden

Inom OOP kan man bara ändra ett värde på en variabel om man har behörighet att göra så. Det definieras med de klasser som man implementerar som representerar maskinens egentliga komponenter. En klass definieras som en abstrakt modell av en verklig komponent. Det finns bara en klass i sitt slag men det kan finnas flera instanser, dvs. objekt, av en klass. Objekten, sätts ihop precis som byggklossar och genom den modulära uppbyggnaden kan man enkelt återanvända kod till andra projekt i framtiden.

Ärvning och aggregation

Genom ärvning kan man förfina en klass genom att skapa en underklass med samma funktioner som huvudklassen men som man samtidigt vidareutvecklar på olika sätt. Genom ”Aggregation” sätter man ihop olika klasser till komplexa klasser. Med denna funktion kan man nu bygga ihop specialfunktioner hos en maskin med minimal programmering. Kostnaden för utveckling minskar avsevärt. Gränssnittet mellan maskinbyggare och mjukvaruutvecklare blir härmed mycket enklare då hårdvarudelen speglas i själva mjukvaran, medarbetare från olika avdelningar har lättare för att förstå varandra.

Uppbyggnad av klasser och objekt kommer utav analys av maskinen

Alla programmerare som har utvecklat mjukvara till en maskin måste sätta sig in i detalj hur maskinen ska fungera. Vilka delar består maskinen av? Hur är de uppbyggda? Hur hänger de ihop och hur påverkar de varandra? Genom en analys av maskinen och en definition av de enstaka maskindelarna, så trillar de olika klasserna och egenskaperna som kommer att användas i OOP, ut av sig själv. Även delar av maskinen, som uppträder lika eller har liknande uppgifter, analyseras, extraheras och definieras därefter i mer allmänna klasser.

Exempel - transportlinje

Vi tar ett exempel med en transportlinje för lådor. Maskinen består utav tre efterföljande transportband där varje band drivs utav en motor och styrs med hjälp av en start- och stoppknapp. Vid slutet av varje band finns en cylinder som puttar över lådan på nästa band alternativt på en lastpall. Om man här försöker att ta ut motsvarande klasser så märker man att man har tre transportband med liknande uppgift.

Implementation av transportlinjen

Vi implementerar tre olika klasser. En klass sköter om motorstyrningen. En andra klass sköter cylindern. Den tredje klassen är huvudklassen för själva transportbandet som känner av start- och stoppknapparna, styr cylindern samt motorn. Genom aggregation av dessa klasser bygger man nu en komplex klass ”Transportband”. Den slutliga styrningen av maskinen kommer då att bestå utav 3 objekt, ett för varje transportband. Även om detta var ett enklare exempel så jobbar man precis likadant vid mer komplexa maskiner. Vi bryter ner och bygger upp. Vill man i framtiden byta ut cylindern mot en robot eller en annan mekanisk rörelse så implementerar man enkelt den nya klassen och byter ut vårt cylinderobjekt mot det nya. Därefter behöver vi inte göra några fler ändringar.

Stora projekt är enklare att förstå om de implementerats med OOP

Vid objektorienterad programmering är designen av utvecklingsmiljön lika viktig som själva implementeringen. Här ligger fokus på de inkapslade objekten som via olika gränssnitt kommunicerar med världen utanför. När man sätter sig in i hur dessa funktioner och objekt är uppbyggda och fungerar, så ter sig objekt väldigt enkla att testa och byta mot andra objekt och funktioner, även efter flertalet år. Denna objektorienterade struktur hjälper maskinbyggare avsevärt då maskiner och projekt blir mer och mer komplexa. Desto större projektet är och desto fler som har varit inblandade i utvecklingen desto viktigare visar sig då fördelen med en tydlig överblick tack vare en genomtänkt inkapsling av programkoden. Ännu mer överskådligt blir projektet när utvecklingsmiljön dessutom erbjuder en grafisk presentation.

Grafisk presentation av objekt för en enklare mjukvaruutveckling och komplement till OOP

I LASAL presenteras de olika klassernas objekt i olika nätverk. Fördelen här är att man efterliknar den verkliga maskinen även i själva mjukvaran. Med andra ord, utvecklaren ser direkt en viss maskindels egenskaper t.ex. kommunikationen med andra objekt, dvs. andra maskindelar. En verklig styrka framträder senare när man kopplar upp sig mot styrningen. Direkt när man har etablerat en anslutning till sin maskin så åskådliggörs alla är-värden hos de olika objekten. Det betyder att man kan följa alla värden och status från de olika objekten inom projektet utan att sätta sig in i källkoden. Servicetekniker och personal inom idrifttagning får genom denna grafiska bild å ena sidan en bättre och enklare förståelse för projektets struktur, å andra sidan förenklas diagnostisering också avsevärt då även programkoden är grafiskt inkapslad. Har ett objekt ett felaktigt värde så felsöker man i motsvarande klass och inte i någon annan kod. Apropå programspråk, structured text är faktiskt enklare att läsa då det är implementerat objektorienterat. Med OOP behöver man inte ta hänsyn till olika dataområde som anropas hos ofta förkommande programavsnitt, kod är inkapslad i en klass såvida man inte specifikt vill ge tillåtelse till åtkomst utifrån. Dessutom, vid en programändring räcker det oftast att implementera och testa den berörda klassen och inte hela projektet.


Fler pressreleaser