Ez a lecke a FFB-on való kommunikációk ütemezésének alapjairól szól. Első dolgunk legyen az, hogy áttekintjük, miféle kommunikációkról is van szó!

A FFB-ra kötött eszközök feladatait két csoportra oszthatjuk:
- Szigorúan azonos idővel ismétlendő feladatok
- Maradék időben megoldható feladatok.

A szigorúan ütemezendő feladatok:
- Bemenetek olvasása
- Szabályzó algoritmusok végrehajtása
- Kimenetek írása

Maradék időben megoldható (?):
- Paraméterek fogadása felső szintről
- Paraméterek feladása felső szintre
- Önadminisztráció (lásd később)

Azt gondolom könnyű belátni, miért azok vannak az első csoportban akik.
Egy szabályzókör beavatkozásainak ciklusideje akkor jó, ha tízszer rövidebb a szabályozott szakasz időállandójánál. Ha ez nem teljesül, a szabályzásunk megbolondulhat. (Pl. a nyomás már rég elszaladt, mi pedig még rá se néztünk a távadóra...)

Szóval a kontroll az elsődleges. A kontroll meghatározott feladatok kötött sorrendben való végrehajtását jelenti. Ezek a feladatok tipikusak, így létrehozhatók olyan programblokkok, melyek egy-egy ilyen tipikus feladatot látnak el.

A FFB alapvető funkcióblokkjai a következők:
- AI analóg bemenet olvasása
- AO analóg kimenet írása
- B bias
- CS control selector
- DI kétállapotú bemenet olvasása
- DO kétállapotú kimenet írása
- ML kézi töltés
- PD PD szabályzó
- PID (ezt nem árulom el...)
- RA arány

Hol futnak ezek az algoritmusok?
Természetesen a terepi eszközbe épített hardvereken. A távadóba pl. beépíthető az AI blokk, szelep pozícionálóba az AO blokk, és így tovább...

Nézzünk egy egyszerű szabályzókört! A példánkban a buszon nincs más, csak egy távadó és egy szelep. Ezek mást nem csinálnak, csak egy sima szabályzókört. Ehhez a következő lépések szükségesek: A távadó által mért értéket felteszem a buszra, ezt a PID szabályzó elolvassa, végrehajtja a PID szabályzó algoritmust, felteszi a buszra a végrehajtó jelet, ezt a szelep elolvassa és végrehajtja. Ezt kell folyamatosan ismételni adott ciklusidővel.
Leegyszerűsítve, grafikusan:



Látható, hogy a ciklusidőt úgy kell kiszámolni, hogy a 3 funkcióblokk után még maradjon idő a "maradék időben megoldandó" feladatokra, pl. új alapjel vétele a kezelőtől.

Nyilvánvaló, hogy a funkcióblokkok sorrendje sem közömbös:



Itt a blokkok abszolut sorrendje nem változott (...PID,AO,AI,PID,AO...) de a PID szabályzó mindig egy ciklussal régebbi mért értéket kap, azaz a valós helyzettől el van maradva. A blokkok sorrendjének optimalizálása is igen fontos feladat, amit a konfiguráló szoftvernek tudnia kell. Legjobb, ha ezt kézi és automatikus módban is lehetséges megtenni.

Most nézzünk egy olyan buszt, ahol kettő szabályzókör van:



Miért olyan fontos ez? Látnunk kell, hogy a FFB nem "multitasking"-os, azaz a feladatok nem tudnak időben "párhuzamosan" futni (pl. vivőfrekvenciák alkalmazásával). Minél több eszköz ÉS minél több algoritmus fut a buszon, annál hosszabb lesz minden kör ciklusideje.

Mennyi az idő?
Az időbeli nagyságrendekről annyit, hogy az egyszerűbb funkcióblokkok időigénye is többször 10 msec nagyságrendű. Egy szabályzókör ezek szerint kb. 100 msec. Ehhez hozzá kell adni a nem ütemezett kommunikáció idejét, durván és általam saccolva 10 msec/eszköz. Ezt be kell szorozni a szabályozókörök számával, majd rá kell hagyni (szerintem) 30% tartalékot. Legyen ez a ciklusidő. Jobb rendszerek képesek szemléletes adatokat adni a busz foglaltságról. Mindig ellenőrizzük!

Fentiek miatt óvatosságra szeretnék inteni mindenkit, aki alapos felkészültség nélkül FFB rendszert kíván konfigurálni vagy a meglevő buszára "csak úgy" fel kíván tenni még egy távadót. Hagyja ezt a bizonylatolt szakemberekre!
Abban az esetben ugyanis, ha a ciklusidőt a kelleténél rövidebbre szabjuk, nem lesz idő a mért értékek feladására a monitorra, vagy éppen egy alarmra...

Ki ütemezi a funkcióblokkok végrehajtását?
Többnyire a FFB kártya, de korszerűbb terepi eszköz is lehet ütemező azaz LAS (link active scheduler). Az ütemezés token passing-elvű, ami azt jelenti, az ütemező egy tokent ad az eszközöknek sorban, majd adott idő múlva elveszi tőlük. Míg a token az eszköznél van, övé a busz.
Látható, hogy a LAS központi szerepet játszik. Ha nincs LAS (pl. meghibásodott) az egész busz leáll. Ennek elkerülésére dolgozták ki a LAS redundanciát, ami azt jelenti, hogy a LAS leállása esetén az arra képes eszköz átveheti annak funkcióját. Ez a folyamat bonyolult, nem fogom ismertetni. Lényeg, hogy van ilyen, de a működés nem automatikus, ezt is konfigurálni kell...