Egy nagy programegység vagy sok kicsi? A programkövetelmény szerint ezt neked kell eldöntened — ez a fejezet megadja a szempontokat.

A programkövetelmény a 9.1/4. kompetenciánál egyértelműen fogalmaz: a jelölt „eldönti, hogy lineáris, vagy strukturált felépítésű programot ír”. Ez tehát nem stílus kérdése, hanem tudatos tervezői döntés — és a vizsgán számon kérhető.

Ez a fejezet megadja a fogalompár tartalmát, bemutatja a strukturált felépítés igazolt előnyeit, és — mert a magyar szakképzésben sokan Siemens-alapon tanulnak — megadja a Siemens–CODESYS fogalommegfeleltetést is.

11.1 A fogalompár eredete — és egy őszinte megjegyzés

⚠️ Forráshelyzet — nyíltan

A „lineáris” és a „strukturált” felépítésű program szó szerinti, egymással szembeállított gyártói definícióját négy forrásban kerestük — a Siemens Programming with STEP 7 kézikönyvében, a Siemens Programming Guideline-jában, egy magyar egyetemi tananyagban és a CODESYS súgójában —, és nem találtuk meg.

A fogalompár a magyar szakképzési terminológia része: a programkövetelmény használja. A nemzetközi gyártói dokumentációban ennek a modularizáció (modularization) fogalma felel meg, amelynek előnyeit viszont gyártói forrásból pontosan tudjuk idézni (11.4. pont).

A könyv ezért így jár el: a fogalompárt a programkövetelményre hivatkozva vezetjük be, a tartalmát pedig igazolt fogalmakkal töltjük meg — hívási hierarchia, funkcionális részekre bontás, újrafelhasználhatóság. Ahol saját megfogalmazást használunk, azt jelezzük.

11.2 Lineáris felépítés

📗 Lineáris felépítésű program *(a könyv operatív meghatározása)*

A teljes vezérlési logika egyetlen programegységben (POU-ban, illetve Siemens-környezetben egyetlen szervezési blokkban) van leírva, amelyet a task ciklikusan hív. Nincs alárendelt, külön hívott programegység — tehát nincs hívási hierarchia.

LINEÁRIS FELÉPÍTÉS STRUKTURÁLT FELÉPÍTÉS task PLC_PRG szivattyú 1 logikája szivattyú 2 logikája szivattyú 3 logikája szalagvezérlés riasztások HMI-kezelés …mind egy helyen task PLC_PRG (fő) FB_Szivattyu1. példány FB_Szivattyu2. példány FB_Szalagpéldány FB_Riasztaspéldány Nincs hívási hierarchia — minden logika egy programegységben. Egy funkcióblokk, több példány — a logika egyszer íródik meg.
11.1. ábra. Lineáris és strukturált felépítés. Balra minden logika egy programegységben; jobbra funkcionális egységekre bontva, hívási hierarchiával.

Egy lineáris program így néz ki ST-ben (rövidített példa):

ST
PROGRAM PLC_PRG
VAR
    (* szivattyú 1 *)
    tKesleltetes1 : TON;
    bSzivattyu1   : BOOL;
    (* szivattyú 2 *)
    tKesleltetes2 : TON;
    bSzivattyu2   : BOOL;
    (* szivattyú 3 *)
    tKesleltetes3 : TON;
    bSzivattyu3   : BOOL;
END_VAR

(* --- szivattyú 1 logikája --- *)
tKesleltetes1(IN := bInditas1, PT := T#3S);
bSzivattyu1 := tKesleltetes1.Q AND NOT bHiba1;

(* --- szivattyú 2 logikája: ugyanaz, más változókkal --- *)
tKesleltetes2(IN := bInditas2, PT := T#3S);
bSzivattyu2 := tKesleltetes2.Q AND NOT bHiba2;

(* --- szivattyú 3 logikája: megint ugyanaz --- *)
tKesleltetes3(IN := bInditas3, PT := T#3S);
bSzivattyu3 := tKesleltetes3.Q AND NOT bHiba3;

Ami itt látszik: ugyanaz a logika háromszor le van írva. Ha módosítani kell — például a késleltetés 3 helyett 5 másodperc legyen, vagy új feltétel jöjjön —, akkor három helyen kell javítani. Ha az egyiket elfelejted, az hetekig észrevétlen marad.

💡 Mikor jó mégis a lineáris felépítés?

Kis feladatnál. Ha a program 40–50 sor, nincs ismétlődő rész, és egyetlen ember tartja karban, a lineáris felépítés áttekinthetőbb lehet, mint a fölösleges tagolás. A könyv is így kezdi: az első gyakorlatok (9. fejezet) lineáris programok.

11.3 Strukturált felépítés

📗 Strukturált felépítésű program *(a könyv operatív meghatározása)*

A vezérlési feladatot funkcionális részekre bontjuk, ezeket önálló programegységekben (funkcióblokk, függvény) valósítjuk meg, és a főprogramból hívjuk — így hívási hierarchia alakul ki, az ismétlődő részek pedig újrafelhasználhatók.

Ugyanaz a feladat strukturáltan:

ST
FUNCTION_BLOCK FB_Szivattyu
VAR_INPUT
    bInditas  : BOOL;
    bHiba     : BOOL;
    tKesl     : TIME := T#3S;
END_VAR
VAR_OUTPUT
    bMukodik  : BOOL;
END_VAR
VAR
    tKesleltetes : TON;
END_VAR

tKesleltetes(IN := bInditas, PT := tKesl);
bMukodik := tKesleltetes.Q AND NOT bHiba;

És a főprogram:

ST
PROGRAM PLC_PRG
VAR
    fbSzivattyu1 : FB_Szivattyu;
    fbSzivattyu2 : FB_Szivattyu;
    fbSzivattyu3 : FB_Szivattyu;
END_VAR

fbSzivattyu1(bInditas := bInditas1, bHiba := bHiba1, bMukodik => bSzivattyu1);
fbSzivattyu2(bInditas := bInditas2, bHiba := bHiba2, bMukodik => bSzivattyu2);
fbSzivattyu3(bInditas := bInditas3, bHiba := bHiba3, bMukodik => bSzivattyu3);

Ami itt látszik: a logika egyszer van megírva. Három példány használja, mindegyik a saját időzítőjével és állapotával (10. fejezet). Ha módosítani kell, egy helyen javítasz, és mindhárom szivattyú örökli a változást.

💡 A példányosítás itt válik értékessé

A 10. fejezetben megtanultad, hogy a funkcióblokk példányosítható, és minden példánynak saját állapota van. Itt látod, mire jó ez: a három szivattyú három külön időzítővel működik, pedig a kód csak egyszer létezik.

11.4 A modularizáció négy igazolt előnye

A Siemens programozási irányelve egyértelmű ajánlással kezdi:5

„Structure your automation task. Divide the entire function of your plant into individual areas and form sub-function units.”

És megfogalmazza az eredményt is:5

„Due to a good and structured program you get many function units that can be multiply reused within a project and also in other projects.”

A dokumentum négy konkrét előnyt nevez meg:5

Előny Idézet
Újrafelhasználhatóság „Blocks can be used universally in any location of the user program” és „in different projects”
Átláthatóság „Your project or your plant becomes more transparent”
Karbantarthatóság „Error states in a plant can be more easily detected, analyzed and removed”
Kevesebb hibaforrás „clearly fewer sources of errors” és „simple error diagnostic”
💡 Amit ehhez a könyv hozzátesz

Van egy ötödik előny is, amelyet a gyakorlat mutat meg: a tesztelhetőség. Egy önálló funkcióblokkot külön is ki lehet próbálni — szimulációban (8. fejezet), a valódi folyamattól függetlenül. Egy 400 soros lineáris programot csak egészben lehet tesztelni.

11.5 Mikor melyiket?

A programkövetelmény szerint neked kell döntened. Íme a szempontok:

Szempont Lineáris Strukturált
A feladat mérete néhány I/O, egyszerű logika sok I/O, több funkcionális egység
Ismétlődés nincs ismétlődő részfeladat több hasonló egység → funkcióblokk példányokkal
Áttekinthetőség rövid programnál akár jobb nagy programnál jóval jobb
Tesztelhetőség csak egészben részenként is, önállóan
Hibakeresés a teljes kódot át kell nézni „more easily detected, analyzed and removed”5
Újrafelhasználás nincs „can be used … in different projects”5
Csapatmunka nehéz (mindenki ugyanabban a fájlban) könnyebb (a részek szétoszthatók)
Módosítás költsége minden előfordulásnál javítani kell egy helyen javítasz
⚠️ A döntés valódi kérdése

Nem az, hogy „hány sor a program”, hanem hogy van-e ismétlődés, és fog-e nőni a rendszer. Ha három hasonló egységed van, vagy ha tudod, hogy jövőre lesz negyedik — akkor strukturáltan kezdj. Egy lineáris programot később strukturálttá alakítani jóval drágább, mint eleve úgy megírni.

💡 A könyv gyakorlata

A könyv az első gyakorlatoknál (9. fejezet) lineárisan kezd, mert ott a cél az, hogy egyáltalán fusson valami. A második gyakorlattól kezdve strukturáltan építkezünk — és ez teszi lehetővé, hogy a 26. fejezet záróprojektje (több szivattyú, szalag, HMI, Modbus-bővítés) egyáltalán kezelhető legyen.

A lineáris felépítést a könyv bemutatja és megnevezi, mert a vizsga kérdezi — de nem ezt tanítja munkamódszerként.

11.6 Siemens és CODESYS: ugyanaz más néven

A magyar szakképzésben sokan Siemens-alapon tanulnak, a vizsgára viszont a tanult PLC-t vihetik. Ezért fontos látni, hogy a két világ ugyanazokat a fogalmakat használja, csak más elnevezéssel.

SIEMENS (STEP 7) CODESYS (IEC 61131-3) OB — Organization Block az operációs rendszer hívja ciklikusan FC — Function nincs ciklusokon átnyúló adattárolás FB — Function Block példány-adatblokkal, az értékek megmaradnak DB — Data Block globálisan elérhető adat task definiálja a POU-k hívási láncát FUNCTION állapotmentes, visszatérési értékkel FUNCTION_BLOCK példányosítható, saját állapottal GVL — globális változólista globálisan elérhető adat
11.2. ábra. A Siemens blokktípusai és a CODESYS POU-típusai — ugyanaz a fogalomrendszer, más nevekkel.

A Siemens blokktípusai:5

Blokk Jellemző
OB (Organization Block) az operációs rendszer hívja; indulást, ciklikus feldolgozást, megszakításokat és hibakezelést vezérel
FC (Function) ciklusokon átnyúló adattárolás nélkül; az értékeket minden híváskor paraméterként kell megadni
FB (Function Block) ciklusokon átnyúló adattárolás példány-adatblokkban; az értékek megmaradnak a ciklusok között
DB (Data Block) a felhasználói program egészében elérhető változóadatok

A megfeleltetés:

Siemens CODESYS A közös lényeg
FC — nincs ciklusokon átnyúló adattárolás5 FUNCTION — „functions do not save the values of their variables until the next call”2 állapotmentes
FB — példány-adatblokkban tárol5 FUNCTION_BLOCK — „values … remain unchanged after execution until the next execution”, példányosítással3 állapotos, példányosítható
OB — az operációs rendszer hívja ciklikusan5 task — „The task defines the call chain of your POUs”1 a ciklikus hívás belépési pontja
DB — globálisan elérhető adat5 GVL (globális változólista) globális adat
💡 Ez a táblázat a vizsgán is használható

Ha Siemens-alapon tanultál, de CC100-on vizsgázol (vagy fordítva), ez a megfeleltetés megmutatja, hogy a tudásod átvihető. A fogalmak azonosak: az állapotmentes függvény, az állapotos és példányosítható funkcióblokk, a ciklikus belépési pont és a globális adat.

11.7 A „strukturált” szó két jelentése

Ez a pont azért fontos, mert a vizsgán könnyű összekeverni a kettőt.

⚠️ Két különböző „strukturált”

1. Algoritmuselméleti értelemben (5. fejezet): „strukturált programnak azokat a programokat nevezzük, melyek csak három algoritmikus szerkezetet tartalmaznak: szekvencia, elágazás és ciklus”.4 Ez a Dijkstra-féle strukturált programozás — arról szól, milyen vezérlési szerkezeteket használsz.

2. A PLC-világban — és a programkövetelmény 9.1/4. pontjában: a „strukturált felépítésű program” azt jelenti, hogy a program több POU-ra van bontva, hívási hierarchiába szervezve, szemben a lineáris felépítéssel. Ez arról szól, hogyan tagolod a programot.

A kettő nem ugyanaz, és egymástól függetlenek: egy lineáris program is lehet algoritmuselméletileg strukturált (ha csak szekvenciát, elágazást és ciklust használ), és egy több POU-ra bontott program is lehet algoritmuselméletileg strukturálatlan (ha ugrásokkal dolgozik).

Algoritmuselméleti PLC-szervezési
Mire vonatkozik? a vezérlési szerkezetekre a program tagolására
Ellentéte ugrásokkal („spagetti”) írt kód lineáris felépítés
Hol tanultuk? 5. fejezet ez a fejezet
Kulcsfogalom szekvencia, elágazás, ciklus POU, hívási hierarchia

11.8 Átalakítás a gyakorlatban

Hogyan alakítasz át egy lineáris programot strukturálttá? Négy lépésben:

  1. Keresd meg az ismétlődést. Ha ugyanaz a logika többször szerepel, csak más változónevekkel, az funkcióblokk-jelölt.
  2. Határozd meg a felületet. Mi megy be (VAR_INPUT), mi jön ki (VAR_OUTPUT), és mi marad belül (VAR)? A belső változók — például az időzítő — a blokkban maradnak.
  3. Emeld ki a paramétereket. Ami példányonként más (késleltetési idő, határérték), az legyen bemenet. Ami mindenhol azonos, az lehet a blokkon belüli állandó.
  4. Cseréld le a hívásokat. A főprogramban maradjon csak a példányok deklarálása és hívása.
💡 Elnevezési szokások

A könyv végig ezt a jelölést használja, és a saját programjaidban is érdemes követni:

Előtag Jelentés Példa
b BOOL bInditas, bHiba
i, di INT, DINT iDarab, diOsszes
w, dw WORD, DWORD wReg, dwAllapot
r REAL rHomerseklet
t TIME vagy időzítő tKesleltetes
fb funkcióblokk-példány fbSzivattyu1
FB_ funkcióblokk típusa FB_Szivattyu

Ez a magyaros Hungarian notation: a név elejéről azonnal látszik a típus. Nem kötelező, de nagy programban sokat segít — és a vizsgán is jó benyomást kelt a rendezett kód.

Gyakorlatok

🛠️ 11.1. feladat — Ismétlődés felismerése

Az alábbi leírás alapján döntsd el, lineáris vagy strukturált felépítést választanál, és indokolj két-két érvvel:

  1. Egy présgép: 6 bemenet, 3 kimenet, egyszerű reteszelési logika, nincs bővítés tervben.
  2. Egy szivattyúház: 4 azonos szivattyú, mindegyiknél indítási késleltetés, üzemóra-számlálás és hibafigyelés.
  3. Egy gyártósor: három állomás, mindegyik más feladatot lát el, de mindháromnál van kézi/automata üzemmódváltás és riasztáskezelés.
  4. Egy világításvezérlés: 12 kimenet, mindegyik időzítéssel, azonos logika szerint.
🛠️ 11.2. feladat — Átalakítás

Az alábbi lineáris programrészletben kétszer szerepel ugyanaz a logika. Alakítsd át funkcióblokkos, strukturált felépítésre a 11.8. pont négy lépése szerint!

ST
(* --- 1. szalag --- *)
tKesl1(IN := bStart1 AND NOT bStop1, PT := T#2S);
IF tKesl1.Q AND NOT bVesz THEN
    bSzalag1 := TRUE;
ELSE
    bSzalag1 := FALSE;
END_IF

(* --- 2. szalag --- *)
tKesl2(IN := bStart2 AND NOT bStop2, PT := T#5S);
IF tKesl2.Q AND NOT bVesz THEN
    bSzalag2 := TRUE;
ELSE
    bSzalag2 := FALSE;
END_IF

Figyelj arra, hogy a két szalag késleltetési ideje eltér — mit jelent ez a funkcióblokk felületére nézve?

🛠️ 11.3. feladat — Fogalomtisztázás

Írd le saját szavaiddal, két-három mondatban:

  1. Mit jelent a „strukturált program” az algoritmuselméletben?
  2. Mit jelent a „strukturált felépítésű program” a PLC-programozásban?
  3. Adj példát olyan programra, amely az egyik értelemben strukturált, a másikban nem!

Összefoglalás

A programkövetelmény szerint a PLC programozónak döntenie kell a lineáris és a strukturált felépítés között.

A lineáris felépítésnél a teljes logika egyetlen programegységben van, nincs hívási hierarchia. A strukturált felépítésnél a feladatot funkcionális részekre bontjuk, önálló programegységekben valósítjuk meg, és a főprogramból hívjuk.

A modularizációnak négy, gyártói forrásból igazolt előnye van: újrafelhasználhatóság (projekten belül és más projektekben), átláthatóság, könnyebb hibafelismerés és -elhárítás, valamint kevesebb hibaforrás. A könyv ehhez hozzáteszi az önálló tesztelhetőséget.

A döntés valódi kérdése nem a program hossza, hanem az ismétlődés és a várható növekedés. Ha van ismétlődés, strukturáltan kezdj — az utólagos átalakítás drágább.

A Siemens és a CODESYS ugyanazokat a fogalmakat használja más néven: FC ↔ FUNCTION (állapotmentes), FB ↔ FUNCTION_BLOCK (állapotos, példányosítható), OB ↔ task (ciklikus belépési pont), DB ↔ GVL (globális adat).

Vigyázz a „strukturált” szó két jelentésére: az algoritmuselméletben a vezérlési szerkezetekre (szekvencia, elágazás, ciklus) vonatkozik, a PLC-programozásban a program tagolására.

Ellenőrző kérdések

  1. Mit ír elő a programkövetelmény a lineáris és strukturált felépítéssel kapcsolatban?
  2. Mi a lineáris felépítés meghatározása? Mi hiányzik belőle?
  3. Mi a strukturált felépítés meghatározása? Mi alakul ki benne?
  4. Sorold fel a modularizáció négy igazolt előnyét!
  5. Milyen ötödik előnyt tesz hozzá a könyv, és miért?
  6. Mi a döntés valódi kérdése — mi alapján válassz?
  7. Miért drágább utólag strukturálttá alakítani egy programot?
  8. Melyik Siemens blokktípusnak felel meg a CODESYS FUNCTION_BLOCK-ja, és miért?
  9. Mi a CODESYS megfelelője a Siemens OB-nak és DB-nek?
  10. Mi a különbség a „strukturált program” algoritmuselméleti és PLC-s jelentése között?
  11. Sorold fel az átalakítás négy lépését!
  12. Miért hasznos a típus szerinti elnevezési szokás nagy programokban?

Tudáspróba

Válaszd ki az egyetlen helyes választ!

1. A lineáris felépítésű program jellemzője: a) a teljes logika egyetlen programegységben van, nincs hívási hierarchia; b) több POU-ra van bontva, hívási hierarchiával; c) csak grafikus nyelven írható; d) nem tartalmazhat ciklust.

2. A strukturált felépítés legfőbb előnye ismétlődő feladatoknál: a) gyorsabb a ciklusidő; b) a logika egyszer íródik meg, több példány használja; c) kevesebb memóriát fogyaszt minden esetben; d) nem kell hozzá task.

3. Melyik NEM szerepel a modularizáció gyártói forrásból idézett előnyei között? a) újrafelhasználhatóság b) átláthatóság c) rövidebb ciklusidő d) könnyebb hibafelismerés

4. A Siemens FC blokk CODESYS-megfelelője: a) PROGRAM b) GVL c) FUNCTION_BLOCK d) FUNCTION

5. A Siemens FB blokk jellemzője: a) példány-adatblokkban tárol, az értékek megmaradnak; b) nincs ciklusokon átnyúló adattárolása; c) az operációs rendszer hívja közvetlenül; d) csak adatot tartalmazhat.

6. A Siemens OB blokknak a CODESYS-ben leginkább megfelel: a) a GVL; b) a task; c) a FUNCTION; d) a VAR_INPUT.

7. Az algoritmuselméleti „strukturált program” azt jelenti, hogy: a) több POU-ra van bontva; b) funkcióblokkokat használ; c) csak szekvenciát, elágazást és ciklust használ; d) grafikus nyelven íródott.

8. Az átalakítás első lépése lineárisról strukturáltra: a) a task beállítása; b) a program nyelvének megváltoztatása; c) a globális változók törlése; d) az ismétlődés megkeresése.

9. Ha három hasonló egységed van, és tudod, hogy jövőre lesz negyedik: a) strukturáltan kezdj; b) lineárisan kezdj, majd később alakítsd át; c) mindegy, a fordító optimalizálja; d) külön projektet készíts mindegyikhez.

10. A fbSzivattyu1 : FB_Szivattyu; deklarációban: a) FB_Szivattyu a példány, fbSzivattyu1 a típus; b) fbSzivattyu1 a példány, FB_Szivattyu a típus; c) mindkettő példány; d) mindkettő típus.

A megoldókulcs a B függelékben található.

A fejezet forrásai

Forrásmegjegyzés. A „lineáris” és „strukturált” felépítés meghatározása a könyv saját, operatív megfogalmazása; alkotóelemei (hívási hierarchia, funkcionális részekre bontás, újrafelhasználhatóság) a fenti forrásokból igazoltak. A fogalompárt maga a 07145003-as programkövetelmény használja (9.1/4. kompetencia).


  1. CODESYS Online Help: Task Configuration. CODESYS GmbH, V3.5.22.0. (2026-07-29) ↩

  2. CODESYS Online Help: Object — Function. CODESYS GmbH, V3.5.22.0. (2026-07-29) ↩

  3. CODESYS Online Help: Object — Function Block. CODESYS GmbH, V3.5.22.0. (2026-07-29) ↩

  4. Programozási alapismeretek — algoritmusleíró eszközök. ELTE, TÁMOP-4.1.2.A/2-10/1. (2026-07-29) ↩

  5. Siemens AG: Programming Guideline for S7-1200/1500. Entry ID 81318674, V1.6, 12/2018. (2026-07-29) ↩↩↩↩↩↩↩↩↩↩

Mennyire volt hasznos ez a fejezet?

Még nincs értékelés.