Az eddigi hét fejezetben megismerted a legfontosabb ipari és terepi buszrendszereket — most itt az ideje, hogy ezt a tudást egy önálló, gyakorlati projektben is bizonyítsd. Ez a fejezet végigvezet azon, hogyan válassz feladatot, hogyan építs ki és tesztelj egy valódi rendszert, és hogyan dokumentáld a munkádat úgy, hogy az a portfóliódba is bekerülhessen.
8.1 A projektfeladat célja és helye a vizsgán
Egy önállóan választott, ipari példa alapján megvalósított folyamatirányító rendszer kialakítása tesztpadon, egy választott, az előző fejezetekben tanult buszrendszer alkalmazásával — tesztelve, hibakeresve, üzemeltetve és dokumentálva.
A programtanterv egy választott buszrendszert ír elő, tehát a projektfeladat magja egyetlen busz, amelyet te jelölsz ki. A vizsgán felépítendő architektúrában emellett más eszköztípusok is szerepelnek (PLC vagy mikrovezérlő, IoT-eszköz, felügyeleti eszköz), de a te tantárgyi feladatod a terepi busz.
A KKK szakmai vizsga projektfeladat-részének 2. vizsgarésze kifejezetten megköveteli, hogy a vizsgázó előre meghatározott topológia szerint építsen fel egy hálózati architektúrát, amelyben szerepel legalább egy terepi buszrendszeren keresztül kommunikáló eszköz (távadó vagy beavatkozó) — ez pontosan az eddig tanultakra épít.
A tantárgyi projektfeladatnál te döntöd el, milyen ipari példát modellezel és milyen elrendezésben építed meg. A vizsgán viszont előre meghatározott topológia szerint kell dolgoznod: a feladatkiírás mondja meg, mi hova kapcsolódik. Gyakorláskor tehát arra is készülj, hogy egy KAPOTT rajz alapján is fel tudd építeni a rendszert, ne csak a magad kitalálta elrendezésben.
A terepi busz nem mellékszál a vizsgán: a projektfeladat értékelési szempontjai között a „Terepi buszrendszer kapcsolat felépítése” 15%-ot ér (a 2. vizsgarész 70%-os részarányán belül). Ennyit ér pontokban az, amit ebben a tantárgyban tanultál.
A projektfeladat fejezete NEM ad új technikai tudást a buszrendszerekről — hanem megmutatja, HOGYAN kell a már megtanult 1-7. fejezet tartalmát egy önálló, végigvitt feladatban alkalmazni. Ha egy technikai kérdés felmerül (pl. „milyen lezárás kell a CAN-buszhoz”), lapozz vissza a megfelelő fejezethez.
8.2 Feladatválasztás
A jó projektfeladat-választás szempontjai:
- Ipari relevancia: válassz olyan példát, ami egy valódi ipari folyamatot modellez (pl. egy tartály szintszabályozása, egy szállítószalag vezérlése, egy hőmérséklet-felügyeleti rendszer).
- Elérhető eszközök: a választott buszrendszert (CAN, Modbus, Profibus stb.) olyan eszközökkel valósítsd meg, amelyek ténylegesen rendelkezésedre állnak (fejlesztőpanel, szimulátor, valódi ipari eszköz).
- Illeszkedő komplexitás: a feladat legyen elég összetett ahhoz, hogy több fejezetben tanult ismeretet is felhasználj (pl. buszkiépítés + hibakeresési módszer + dokumentáció), de ne legyen kezelhetetlenül nagy a rendelkezésre álló idő alatt.
Írj egy fél oldalas javaslatot egy választott ipari példára: milyen folyamatot modellezel, milyen buszrendszert használsz, milyen eszközök kellenek hozzá, és mit vársz el a rendszertől (mit mér, mit vezérel).
8.3 Rendszertervezés és kiépítés
A projekt kiépítésénél kövesd a korábbi fejezetekben tanult gyakorlati lépéseket:
- Fizikai réteg: a választott buszrendszernek megfelelő kábelezés, lezárás (terminátor), a megfelelő eszközök összekötése (lásd 1-6. fejezet).
- Konfigurálás: a kommunikációs paraméterek (sebesség, cím, protokoll-specifikus beállítások) beállítása gyártói dokumentáció alapján.
- Adatmodell megtervezése: milyen adatot (mérési érték, vezérlési parancs) küldenek és fogadnak az egyes eszközök, milyen formátumban (pl. Modbus-regiszter, CAN-azonosító).
A rendszer kiépítése és tesztelése közben mindig tartsd be a munkavédelmi és érintésvédelmi szabályokat — a feszültségmentesítés, a megfelelő kábelezés és a szakszerű csatlakoztatás a projektfeladat értékelésének is része lehet.
8.4 Tesztelés, hibakeresés, hibaelhárítás
A kiépített rendszert szisztematikusan kell tesztelni:
- Fizikai réteg ellenőrzése: lezárási ellenállás mérése, kábelezés ellenőrzése (CAN-nál a 2.1., Foundation Fieldbus H1-nél a 3.2., Profibus-DP-nél a 6.2. gyakorlat mutatja meg, hogyan; Modbus RTU-nál az RS-485 lezárásáról az 1.4. alfejezetben olvastál, HART-nál pedig nincs lezárás).
- Kommunikáció ellenőrzése: forgalom megfigyelése oszcilloszkóppal, buszelemzővel vagy a konfigurációs szoftver diagnosztikai funkcióival.
- Funkcionális tesztelés: a tervezett funkció (mérés, vezérlés) valóban helyesen működik-e.
- Szándékos hibaelőidézés: egy-egy jellemző hiba (pl. hiányzó lezárás, rossz sebességbeállítás, laza csatlakozó) előidézése és a hibajelenség dokumentálása — ez bizonyítja, hogy nem csak működő állapotban érted a rendszert, hanem hibás állapotban is fel tudod ismerni a problémát.
Fizikai réteg → kommunikációs beállítások → funkcionális működés — ebben a SORRENDBEN érdemes ellenőrizni egy hibás rendszert, mert egy alsóbb rétegbeli hiba (pl. hibás lezárás) sokféle, első ránézésre értelmezhetetlen felsőbb szintű hibát okozhat.
A hibaelhárítási jegyzőkönyv felépítése
A hibakeresés akkor ér valamit a vizsgán, ha utólag is követhető. Ehhez nem kell bonyolult űrlap, de hét rovatnak mindig szerepelnie kell benne:
- Azonosító és időpont — melyik rendszeren, mikor dolgoztál.
- A rendszer állapota a hiba előtt — mi működött, milyen beállításokkal.
- Tünet — amit az ÜZEMELTETŐ lát, nem a feltételezett ok.
- Feltételezések — mi okozhatja, rétegenként rangsorolva.
- Vizsgálati lépések és eredményük — minden lépésnél a mért/látott érték.
- A hiba oka — a bizonyított ok, nem a gyanú.
- Javítás és ellenőrzés — mit csináltál, és mivel igazoltad, hogy megszűnt.
A leggyakoribb dokumentációs hiba, hogy a „Tünet” rovatba már a feltételezett ok kerül („rossz a lezárás”). Ha ezt írod le, a jegyzőkönyv olvasója nem tudja ellenőrizni a gondolatmenetedet, és ha tévedtél, a tévedés is beépül a dokumentációba. A tünet mindig megfigyelés: mit látsz, mit hallasz, mit ír ki a szoftver.
Kitöltött minta
Az alábbi példa egy CAN-buszos tesztpadon keletkezett, szándékosan előidézett hibát dokumentál. A számok a 2. fejezet lezárási szabályából következnek (két 120 Ω-os terminátor párhuzamosan kb. 60 Ω).
| Rovat | Tartalom |
|---|---|
| Azonosító, időpont | PRJ-01 tesztpad, CAN 250 kbit/s, 3 csomópont (2 hőmérséklet-távadó, 1 vezérlő) |
| Állapot a hiba előtt | A rendszer 30 percig hibátlanul futott, mindkét távadó 2 másodpercenként küldött mérési keretet |
| Tünet | A kezelői felületen az egyik távadó értéke szabálytalan időközönként „elavult” lesz; a vezérlő diagnosztikája időnként Bus-Off állapotot jelez |
| Feltételezések | 1. fizikai réteg: hiányzó vagy laza lezárás, sérült ér · 2. beállítás: eltérő bitsebesség az egyik csomóponton · 3. alkalmazás: küldési ciklus hibája |
| Vizsgálati lépések | lásd alább |
| A hiba oka | A busz egyik végéről hiányzott a 120 Ω-os lezáró ellenállás, ezért a jel visszaverődött, és véletlenszerű keretsérüléseket okozott |
| Javítás, ellenőrzés | A hiányzó terminátor visszahelyezése, újramérés (60 Ω), majd 30 perc megfigyelés hibajelzés nélkül |
A vizsgálati lépések rovat tartalma — minden sorban ott a MÉRT érték, ez teszi ellenőrizhetővé a jegyzőkönyvet:
1. Feszültségmentesítés, majd ellenállásmérés CAN_H és CAN_L között Elvárt: kb. 60 Ω Mért: 120 Ω → eltérés, tovább a fizikai rétegen 2. A busz mindkét végének szemrevételezése Az egyik végponti eszköznél a lezárás kapcsolója kikapcsolt állapotban 3. Bitsebesség ellenőrzése mindhárom csomópont konfigurációjában Mindhárom 250 kbit/s → a 2. feltételezés kizárva 4. Javítás: a végponti lezárás visszakapcsolása 5. Ismételt ellenállásmérés Elvárt: kb. 60 Ω Mért: 59,4 Ω → fizikai réteg rendben 6. 30 perces megfigyelés üzem közben Bus-Off jelzés: 0 db, elmaradt keret: 0 db → a hiba megszűnt
Ha a méréseket csak a javítás után jegyzed le emlékezetből, éppen az fog kimaradni, ami a legértékesebb: a kizárt feltételezések. Az, hogy a bitsebesség RENDBEN volt, ugyanolyan fontos eredmény, mint a megtalált hiba — ez bizonyítja, hogy módszeresen haladtál, nem véletlenül találtad meg az okot.
Idézz elő szándékosan egy hibát a kiépített rendszeredben, majd írj egy rövid jegyzőkönyvet a fenti hét rovat szerint: mi volt a tünet, milyen feltételezésekkel indultál, milyen lépésekben kerested a hibát (mérési értékekkel), mit találtál, hogyan javítottad ki, és mivel igazoltad a javítást.
8.5 Üzemeltetés, dokumentálás, portfólió szerkesztése
A projekt lezárásának kötelező része a dokumentáció:
- Rendszerleírás: milyen folyamatot modellez a rendszer, milyen buszrendszert és milyen eszközöket használ.
- Kapcsolási/hálózati rajz: a fizikai összekötés és a topológia ábrázolása.
- Konfigurációs adatok: a beállított paraméterek (sebesség, cím, adatformátum) rögzítése.
- Tesztelési jegyzőkönyv: a 8.4. alfejezetben végzett tesztek és hibakeresések eredménye.
- Üzemeltetési megjegyzések: mire kell figyelni a rendszer normál működtetése során.
A projektdokumentáció sablonja lépésről lépésre
A dokumentációt nem a projekt végén kell megírni, hanem a projekttel együtt. Az alábbi sablon a fenti öt elemet bontja konkrét, sorrendben elvégezhető lépésekre. Minden lépésnél ott van, MIKOR érdemes megírni — ez a sorrend menti meg a munkádat attól, hogy a végén emlékezetből kelljen rekonstruálnod.
1. Címoldal és összefoglaló (a projekt kezdetén, később pontosítva) Projekt neve és azonosítója · készítő neve · dátum A modellezett ipari folyamat 2-3 mondatban A választott buszrendszer megnevezése 2. Rendszerleírás (a tervezés után, a kiépítés előtt) Mit mér és mit vezérel a rendszer Milyen eszközök alkotják (szerep szerint: távadó, beavatkozó, vezérlő, kezelői felület) · miért ezt a buszt választottad 3. Hálózati és kapcsolási rajz (a kiépítéssel egy időben) Topológia · csomópontok és címeik · lezárások helye · tápellátás Szabály: a rajzon minden eszköz neve egyezzen a szövegbelivel 4. Konfigurációs adatlap (közvetlenül a beállítás után, táblázatban) Eszközönként: név · cím/azonosító · bitsebesség Busz-specifikus paraméterek (pl. Modbus-regiszter tartomány, CAN-azonosító, GSD-fájl neve és verziója) 5. Adatmodell-táblázat (a konfiguráció után) Jel neve · forrás- és céleszköz · adattípus és mértékegység Cím/regiszter · frissítési idő 6. Tesztelési jegyzőkönyv (minden mérés UTÁN azonnal) A 8.4 alfejezet négy lépése: fizikai réteg, kommunikáció, funkció, szándékos hiba Soronként: mit vizsgáltál · elvárt érték · mért érték · megfelelt-e 7. Hibaelhárítási jegyzőkönyv(ek) (a hibakeresés közben) A 8.4 alfejezet hét rovata szerint, hibánként egy jegyzőkönyv 8. Üzemeltetési megjegyzések (a projekt lezárásakor) Indítás és leállítás menete Normál működés ismérvei (mit látsz, ha jó) A leggyakoribb hiba és első teendője · karbantartási pontok 9. Mellékletek és önreflexió (utolsóként) Fényképek, képernyőképek, adatlap-hivatkozások 5-10 mondat arról, mi volt a legnehezebb, mit csinálnál másképp
A KKK a projektfeladat 1. vizsgarészénél, a weblap alapú portfóliónál külön kéri, hogy a feltöltött dokumentumokon, képeken és videókon felül legyen egy önreflexiós rész is, amelyben röviden leírod az alkalmazott technológiákat. Ez mutatja meg a bizottságnak, hogy érted is, amit építettél, nem csak összeraktad egy leírás alapján.
A tanulmányaid alatt elkészített munkák (projektek, dokumentációk, fényképek, videók) gyűjteménye, amelyet a szakmai vizsgán bemutatsz — a projektfeladat dokumentációja jellemzően a portfólió egyik fontos eleme.
Írd meg a dokumentációt úgy, hogy egy, a projektet nem ismerő olvasó egyedül, csak a leírás alapján is megértse és üzemeltetni tudja a rendszert. Ez nemcsak a vizsgán fontos szempont, hanem a valós ipari gyakorlatban is — egy rosszul dokumentált rendszert a jövőben senki nem tud hatékonyan karbantartani.
Állítsd össze a 8.2. és 8.3. alfejezetben megtervezett és kiépített projekted teljes dokumentációját a fenti kilencpontos sablon szerint: rendszerleírás, hálózati rajz, konfigurációs adatlap, adatmodell-táblázat, tesztelési jegyzőkönyv, hibaelhárítási jegyzőkönyv (a 8.2. gyakorlat alapján), üzemeltetési megjegyzések és önreflexió. Ez a dokumentum a portfóliód része lehet.
Összefoglalás
- A projektfeladat a tantárgy záró, gyakorlati fejezete: egy önállóan választott, ipari példa alapján megvalósított rendszer kiépítése, tesztelése és dokumentálása.
- A feladatválasztásnál fontos az ipari relevancia, az elérhető eszközök és az illeszkedő komplexitás.
- A kiépítés a korábbi fejezetekben tanult fizikai réteg, konfigurálás és adatmodell-tervezés gyakorlati alkalmazása.
- A tesztelés/hibakeresés módszeresen, rétegenként (fizikai → kommunikáció → funkcionális) halad.
- A hibaelhárítási jegyzőkönyv hét rovata (azonosító, előzmény, tünet, feltételezések, vizsgálati lépések mért értékekkel, a bizonyított ok, javítás és ellenőrzés) teszi a hibakeresést utólag is követhetővé — a tünet nem azonos a feltételezett okkal.
- A dokumentáció (rendszerleírás, rajz, konfigurációs adatlap, adatmodell, teszt- és hibaelhárítási jegyzőkönyv, üzemeltetési megjegyzések, önreflexió) a projekt kötelező lezáró eleme, és a portfólió része lehet; a projekttel EGYÜTT készül, nem utólag.
- A KKK 2. vizsgarészében előre meghatározott topológia szerint kell építkezni, és a „Terepi buszrendszer kapcsolat felépítése” szempont 15%-ot ér.
Ellenőrző kérdések
- Mi a projektfeladat célja a tantárgy záró fejezeteként?
- Milyen szempontok alapján érdemes projektfeladatot választani?
- Milyen sorrendben érdemes egy hibás rendszert ellenőrizni, és miért éppen ebben a sorrendben?
- Milyen rovatokból áll a hibaelhárítási jegyzőkönyv, és miért nem szabad a „tünet” rovatba a feltételezett okot írni?
- Mi a portfólió, és hogyan kapcsolódik hozzá a projektfeladat dokumentációja?
- Miért fontos a szándékos hibaelőidézés a tesztelési fázisban?
- Milyen biztonsági szempontokra kell figyelni a rendszer kiépítése és tesztelése közben?
- Miért mondjuk, hogy a jó dokumentációnak „önmagában is érthetőnek” kell lennie?
Tudáspróba
1. Milyen sorrendben érdemes egy hibás ipari buszrendszert ellenőrizni? a) Kommunikáció → fizikai réteg → funkcionális b) A sorrend mindegy, csak mindent ellenőrizz c) Funkcionális → kommunikáció → fizikai réteg d) Fizikai réteg → kommunikáció → funkcionális
2. Melyik NEM szempont a projektfeladat választásánál? a) A lehető legtöbb protokoll egyidejű használata b) Illeszkedő komplexitás c) Ipari relevancia d) Elérhető eszközök
3. Egy CAN-buszos tesztpadon feszültségmentesített állapotban 120 Ω-ot mérsz a CAN_H és a CAN_L között, miközben kb. 60 Ω lenne az elvárt érték. Melyik rétegben van a hiba, mi a valószínű oka, és mi a következő lépésed?
4. Igaz vagy hamis: a projektfeladat dokumentációjának csak a kész, működő állapotot kell bemutatnia, a tesztelés és hibakeresés menete nem szükséges.
5. Sorold fel a projekt dokumentációjának legalább négy kötelező elemét.
6. Mit ír elő a KKK a projektfeladat 2. vizsgarészében a hálózati architektúra topológiájáról, és mi a konkrét elvárás a terepi buszrendszerrel kapcsolatban?
7. Miért mondjuk, hogy ez a fejezet „nem ad új technikai tudást”?
8. Egy vizsgázó dokumentációjában nincs hálózati rajz, csak szöveges leírás. Miért lehet ez probléma?