Tuto otazku jsem jiz dal do nekterych diskuzi (HW)ale zajimaly by mne nazory i tady
V cem spoiva realtimost oper. systemu.
1. V tom, ze pokud dojde ke zmene na kteremkoli z napr. binarnich vstupu tak system zareaguje ,vykona program obsluhy vstupu a provede nejakou reakci na tuto zmenu ?
2. V presnem samplovani vstupu v danych casovych intervalech a generovani vystupu dle programu?
Ono asi pravda pokud by se to podarilo jednoduse vyresit, nebylo by potreba drahych PLCaku.
JA jsem zkousel to, ze ve Windows NT jsem privadel na vstup LPT1 impulsy radove stovky Hz a ve vlastnim interruptu jsem stridave negoval vystupni pin tohoto LPT , cele jsem to sledoval oscilem sice jen analogovym ale bylo videt, ze to nejak neni ono, ze se meni strida. To same bych chtel vyzkouset i v Linuxu (QNX) ale tady bude nejspis zalezet zda pobezi v textu nebo Xkach.
> V cem spoiva realtimost oper. systemu.
>1. V tom, ze pokud dojde ke zmene na kteremkoli z >napr. binarnich vstupu tak system >zareaguje ,vykona program obsluhy vstupu a provede >nejakou reakci na tuto zmenu ?
>
>2. V presnem samplovani vstupu v danych casovych >intervalech a generovani vystupu dle programu?
Aj aj. Podstata realtime je v tom, ze istu cinnost vykonas v case, ktory tuto cinnost staci tak aby sme neovplyvnil kvalitu riadenia/riesenia. Klasicke RT OS maju priemerne oneskorenie vykonavania IRQ na urovni 2,4-10 mikrosekund a maximalne na urovni 6,4-50 mikrosekund na 300Mhz x86 CPU. Cize ak regulujes motor s elektrickou casovou konstanmtou 0.1 miliskundy je to niekde realime a niekde nie, lebo teoreticky staci max. oneskorenie odozvy 0.05 milisekundy ale prakticky staci az 0.001 milisekundy
O jadrovom reaktore nehovorim - casova konstanta 1ns.
Na druhej strane ak regulujes teplaren, kde je casova konstanta radovo minuty tak tam je realtime aj Windows 98 s oneskorenim okolo 1s.
>Ono asi pravda pokud by se to podarilo jednoduse >vyresit, nebylo by potreba drahych PLCaku.
Soft PLC uz existuje. Ide SW s realtime podporou emulujuce PLC a je asi o 60% lacnejsi ako bezne PLC.
>JA jsem zkousel to, ze ve Windows NT jsem privadel >na vstup LPT1 impulsy radove stovky Hz a ve >vlastnim interruptu jsem stridave negoval vystupni >pin tohoto LPT , cele jsem to sledoval oscilem >sice jen analogovym ale bylo videt, ze to nejak >neni ono, ze se meni strida. To same bych chtel >vyzkouset i v Linuxu (QNX) ale tady bude nejspis >zalezet zda pobezi v textu nebo Xkach.
v Open RT Linux urcite nie- mame odskusane-. Tam totiz je RT mikroexekutiva, v ktorej ako tasky bezia RT programy a ako idle task bezne jadro Linux.
Kedze X Window bezia v user space tak sa nemoze nic stat. RT programy vsak treba odladit na 100%, lebo su to de facto moduly jadra, ktore vyuzivaju funkcie RT scheduler-a a RT exekutivy. Koli tomu, aby to fungovala treba patchnut jadro. Obdobne pracuje RTAI aj RTX.
Kdyz se to zjednodusi tak realtimovosti se rozumi cisla jako interrupt latency, scheduling latency ...
Jde o to, jak operacni system prideluje zdroje (cas CPU, interrupty, pamet). Linux pouziva pristup "maximalizace prumerneho vykonu" (neni dulezite kdy se akce provede, ale kolik se toho dohromady udela). Proto tyhle cisla u Linuxu nikdo nemuze zarucit, a proto NIKDY nebude dnesni obycejny Linux nasazeny na kritickych aplikacich.
Realtime systemy z principu funguji jinak, u nich je dulezite kdy se akce provede, a ne maximalni efektivita fungovani.
Ruzna RT-rozsireni Linuxu jako TLinux nebo RTAI jsou ve skutecnosti samostatna RT-jadra, ve kterych bezi Linux jako jejich idle thread (kdyz neni prace pro zadny rt-thread, tak muze bezet obycejny linux). Bohuzel je jejich pouzitelnost zatim dost mizerna, kdyz to srovnavam s VxWorks, OS/9, QNX, pSOS. Ale zase do nich pronikaji veci ktere komercni systemy zatim nemaji, jako CBS a EDF scheduler, fault-tolerant management atp.
A jeste jen poznamku k tem drahym PLC. Obecne kde lze PLC pouzit tam se mu zpravidla da prednost pred obecnym pocitacem s OS (alespon prozatim). Je to spolehlivejsi. Ale PLC maji sve limity (vykonove), napr. pro aplikace ktere vyzaduji scan 1 ms a min uz je to fakt problem s PLC udelat. Pak se teprv zacina koukat co rychlejsiho je k dispozici a vede to na reseni typu vykonna CPU deska + nejaky (RT)OS.