Tekniske detaljer

Årsager til stabilitet
Dette beskriver den underliggende maskine, som programmøren ikke kommer i direkte kontakt med:

De dele af systemet som kører realtid, d.v.s soft-PLC og SCADA bruger i alt væsentligt samme principper.
Der er tale om fuld-kompileret kode med deraf følgende hastigheds fordele, og det ville være meningsfuldt at sammenligne med såvel andre PLC-systemer som gammeldags 3-die generations sprog som f.ex. c.
PLC-systemer kan groft deles op i 2 kategorier (forudsat de overhovedet kører kompileret og ikke fortolket kode). Den ene kategori fokuserer på løbende rekalkulation af logiske statements (typisk for ældre systemer), den anden fokuserer på tilstandsmaskiner, f.ex. sekvensere. GOPA har klart mest til fælles med sidstnævnte. Da PLC-systemerne er en broget skare, vælges for nemheds skyld at sammenligne med kompileret c under en traditionel realtidskerne.
Fordeling af CPU-tid
I forbindelse med multitasking skelnes normalt mellem frivillig (cooperative) og tvungen (preemptive) tidsdeling. Kort fortalt besluttes det på kompileringstidspunktet, i hvilke situationer CPU-en skal skifte tråd ved frivillig tidsdeling, mens det ved tvungen tidsdeling sker som følge af en ydre begivenhed (interrupt).

Den fremgangsmåde GOPA bruger, har vi valgt at kalde for super-frivillig tidsdeling. Som navnet antyder,
er den mest beslægtet med frivillig tidsdeling for såvidt trådskifter planlægges på kompilerings tidspunktet. Der er dog væsentlige forskelle i forhold til klassisk frivillig tidsdeling hos kompilerede sprog:

1. Normalt er det op til programmøren at huske at frigive tråden gennem funktionskald. Her sørger selve kompileren for at indsætte nødvendige instruktioner.

2. Normalt er der et vist tidsforbrug ved at skifte tråd. Her er omkostningen enten helt elimineret (samkompilering), eller tidsforbruget minimeret til 1-2 maskin-instruktioner. Det skyldes, at vi ikke bruger hver-tråd-sin-stak princippet. Det giver en overordentlig god udnyttelse af CPU-tiden ved både kontrol-opgaver (soft-PLC) og grafisk animation (SCADA). Her ville man under normal frivillig eller tvungen tidsdeling ofte komme ud for, at tidsforbruget ved at skifte tråd væsentligt oversteg tidsforbruget ved nytte-instruktioner mellem trådskifter.

3. Hvor aktuel trådadresse normalt flytter sig rundt i de LIFO stakke, som tildeles hver tråd, er de her samlet i en fælles FIFO stak, hvor de ganske som cellerne i et array, kan gøres til genstand for lineær aritmetik. Det giver en række muligheder (blandt meget andet hierakisk tildeling af cpu-tid) som ellers
   ville have været for dyre at administrere.

Det afgørende med hensyn til stabilitet er, at frigivelse af CPU-tid og prioritering af processer forudplanlægges på compileringstidspunktet ud fra en worst-case antagelse.

I det følgende nævnes en række fejlkilder typiske for kompilerede sprog:

Stack overflow
Dette er et problem for realtidssystemer, fordi der ikke er tid til at stoppe programmet og frigøre ram ved at swappe til disk. Det egentlige problem er, at man normalt bruger stakken på LIFO-basis (call/return), og det kan være besværligt at forudsige værst tænkelige stakforbrug. Det bliver særlig slemt når man kører den hastigheds-effektive driftsform, hvor der ikke sker privilegie-skift ved interrupts. Under denne driftsform skal hver eneste stak have plads nok til interrupt-handlerens forbrug udover trådens eget.
GOPA har ikke dette problem fordi stakken ikke bruges på den svært forudsigelige LIFO (call/return) måde, men på en i forvejen kontrolleret FIFO måde (ingen call, kun return).

Illegal pointer / array overflow
Vi bruger pointere, men memory adresser bliver aldrig beregnet på runtidspunktet. Implicitte pointere loades med værdier fra tabeller, hvis indhold kontrolleres allerede på compile/link tidspunktet. Opgaver som under et 3-die generations sprog ville være blevet løst med arrays af dataregistre, løses i stedet med arrays af komplette PLC-er med egne tråde. I stedet for at regne sig frem til en bestemt celle, udsendes en “meddelelse” som høres af alle PLC-erne. Kun den PLC, der genkender meddelelsen som henvendt til sig selv, vil reagere på meddelelsen.

Out of memory
Fænomenet kan ikke optræde hos soft-PLCen (helt normalt for PLC-er som normalt ikke genbruger ram), men for SCADA-delen kunne det i princippet ske. Muligheden hindres ved kontrol på kompileringstidspunktet, i kombination med et simpelt koncept, hvor der ved programstart allokeres ram nok til det største SCADA billede i projektet.