Dobrý den,
...a ono to (zřejmě) není potřeba řešit u spousty aplikací. Docela mě dostala přednáška Pavla Píši z FELu (který určitě ví, o čem mluví), kde rozebíral, jestli je na automatizaci použitelné RPi: https://www.youtube.com/watch?v=I_4cAhW46dM Dost zajímavá je pasáž, kde ukazuje, jak se latence na non-realtime OS dá docela solidně řešit prostě statisticky - pokud to na X pokusů projde, tak je to na daný účel dostatečné (EDIT: na videu někde kolem 1:10:00).
Pokud je na leccos použitelné RPi, tak s jednoúčelovými MCU bez OS je situace ještě o řád lepší...
byl bych velmi nerad, aby moje přednáška vzbudila v naivněji myslících jedincích a především obchodních (s jejich nechápáním reality mám dost zkušeností) představu, že solidní HW není potřeba a vše nahradíme Raspberry Pi za pár korun. Hlavní motivace k přednášce byla, že i nadšenci mají možnost otestovat přístupy, které se přibližují profesionálním řešením a na svoje hraní mohou taková řešení použít. Zároveň nemusí padat údivem před PLC a mohou si uvědomit, že ty firmy, které PLC vyrábí hluboko pod vrstvami reklamních sloganů a PR používají často otevřené technologie a GNU/Linux, který většina z čtenářů Roota velmi dobře zná.
Bezpečně například vím, že Natial Instruments přechází ve svých novějších vlajkových systémech na fully-preemptive Linux kombinovaný s FPGA (Xilinx Zynq) a spolupracuje s OSADL na trvalém dohledu nad stavem jádra. Zajímavá a velmi otevřená přednáška a diskuze byla na loňském Real-Time Linux Workshopu
https://www.osadl.org/Abstract-7-From-in-house-dedicated-RTO.rtlws17-abstract7.0.htmlPřednáška byla v rámci prezentace firem a vývojářů RT patchů a spíše určená pro "domácí publikum" takže stejně jako interní přednáška BMW o zpracování obrazu (detekci chodce) a další nejsou zaznamenané a nejsou ani v tištěných materiálech konference.
Pokud chcete takové "RPi/Arduino" od NI použít, tak jsme pro sestavu s s okolo dvacítkou digitálních vstupů a výstupů, podobným počtem analogových kanálů, nějakými (překvapivě) vstupy PWM a komunikacemi CAN, FlexRay, Lin dostali nabídku něco mezi 500 tisíc až miliónem kč. Protože to potřebujeme pro testování našeho HW (jednotky na bázi bezpečnostního procesoru navrženou původně jednoho velkého výrobce automobilů) a testovací prostředí má běžet jen v místnosti a nakonec jakákoliv chyba i den odstávky nic neznamená, tak si kvůli ceně nakonec vyhovující řešení ubastlíme na Begle Bone Black s našimi studenty.
Ale pokud by se jednalo o reálné nasazení v průmyslu, kde musí být zajištěná spolehlivost, servis, certifikace, tak by volba padla na HW od prověřeného výrobce. Ono i PC, které lze dodat do průmyslu a má naději vydržet v takových podmínkách budete kupovat třeba od firmy Kontron a cena s V/V kartami bude srovnatelná.
Co se programování týče, tak NI nám nabízelo i možnost vlastních bloků do FPGA části i programování na úrovni OS. Ale hlavní hodnota jejich řešení je vizuální nebo PLC programování, kdy jsou bloky a kód na nižší úrovni prověřené.
Sám nemám programování na úrovni PLC jazyků rád a v oblasti, kde především působím - to je interní firmware laboratorních a lékařských přístrojů, ani hotové PLC kvůli ceně a zástavbě použít nelze. Pro průmyslové aplikace ale v mnoha případech striktní programování na úrovni PLC jazyků a blokových řešení je z hlediska kontroly návrhu nutností. Moje expertíza je pak spíš na úrovni vytváření a konzultací řešení pro ty výrobce PLC, kde se plně znalosti RTOS projeví.
Velká část PLC je pak založena nebo přechází na řešení založená na jádře Linux. Wago již desítku let, Siemens po ztrátě týmu okolo x86 kompilátoru přešel (pokud jsou tamtamy pravdivé) před deseti lety s celou vlajkovou lodí Sinumeric na Linux atd.
Mnoho PLC aplikací není jen o otočení ventilu, kde jsou sekundy času. Návrh a ověřování smyček PLC pak není zcela triviální a třeba v systémech NI se rychlé části návrhu převádí na kód/konfiguraci pro FPGA.
Přesto, že se mi prostředí OS Linux líbí a na desktopu je mým hlavním OS asi od roku 1994, tak pro kritické aplikace si stále myslím, že nedozrál a pro mnoho ani nikdy nedozraje. Když jsme před deseti lety řešili návrh hardware infúzních pump, tak jsem rovnou Linux a všechny jeho RT varianty vyřadil a použili jsme otevřený systém RTEMS, který vznikl pro americkou armádu a používá ho ESA i NASA. Stejně jsme ještě systém kvůli bezpečnosti rozdělili na dva procesory a na menším MCU běží řídicí a kontrolní algoritmy bez OS. Dnes je Linux s FPK, co se týče predikce spolehlivosti, udržení latencí odezvy v mnoha oblastech použitelnou alternativou. Kvůli požadavkům na grafiku a ovládání (Qt, animace, video atd.) jsme demonstrátory nové generace infúzní techniky řešili na Linuxu. Ale z hlediska bezpečnosti z toho stále dobrý pocit nemám. Jádro je pouze testovatelné, tak obrovské množství kódu verifikovat nelze. A to je problém. Existují snahy vytvořit podklady, které by umožnily certifikovat řešení na bázi subsetu Linuxu na úrovni SIL2
https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html .
Pro mnoho aplikací je to ale málo a hardware, který má být opravdu bezpečný většinou ani běh systému velikosti Linuxu neumožňuje. Systémy s plně ECC zabezpečenou Flash, RAM, sběrnicemi a vícenásobným CPU mívají dnes okolo max 200, 300kB RAM a 3 MB Flash. Takže i ta extrémně testovaná výkonná PLC postavená na Linuxu jsou použitelná jen tam, kde stačí zaručení středních dob bez poruchy v miliónech hodin - to je zjednodušeně aplikace, které ohrožují okolí buď jen ekonomicky nebo v jednotkách lidských životů (například jeřáb, jeden ze SIL2 Linux use cases). Pro atomové elektrárny a letadla musí být kritické systémy v jiné třídě bezpečnosti, to dnes znamená extrémně testované a analyzované menší RTOS, specializované nástroje, většinou programování bez jediného použití dynamicky alokované paměti atd.
Co se týče predikce do budoucnosti, tak z pohledu bezpečného programování bude požadavek zůstávat při návrhu aplikací u "relátkových" jazyků - PLC. Ve firmách ale začíná zásadní problém s množstvím různých PLC a především po jejich propojení do sítě, která je přes vyšší úrovně propojená s Internetem, začíná být zásadním problémem bezpečnost a možnost update firmware. Tím již přestává platit původní doktrína nasazení PLC a desítek roků spolehlivé operace bez update. Přitom zajištění update starých PLC je problém. Začíná se tedy objevovat názor deklarovaný lidmi, kteří jsou opravdu špička a vidí do přípravy nové generace řešení od velkých firem (Siemens atd.), že je potřeba vzít PLC z rukou techniků a přenést je pod zprávu síťařů do servroven. Představa je taková, že se bude používat výkonné železo (mnohaprocesorový Intel atd.) kdy v budoucnu bude možné zajistit jeho spolehlivost (ono ECC a mnoho dalších kontrolních technologií již výkonné procesory integrují) a takový hardware se zpátky rozparceluje na jednotlivé subsystémy, ve kterých poběží jednotlivá PLC realizovaná třeba pomocí RTOS softwarově. Vlastní řízení ke strojům bude dotažené rychlými distribuovanými vstupně výstupními sběrnicemi a vlastní IO rozhraní budou tak jednoduchá, že je po mnoho let nebude nutné updatovat. Příkladem je třeba projekt Siemensu Jailhouse
https://github.com/siemens/jailhouseUrčitě na "serveru" pro správu poběží Linux, ale kritická PLC budou nejspíš pod jiným OS. My třeba uvažujeme o systému Erica Enterprise od našich partnerů a to i pro řízení autonomních vozidel na platformě spíše postavené nad ARMem
http://hercules2020.eu/K centralizaci mnoha řídicích procesů v automobilech, mobilních telefonech na méně výkonnějších procesorů dojít nejspíše musí, současná situace s mnoha desítkami rozdílných systémů uvnitř jedné krabičky od tictacu je neudržitelná. V průmyslovém řízení to asi také tak bude, druhou alternativou je naopak distribuce řízení, kdy jednotlivé vodiče již jsou a do budoucna plně budou nahrazené sběrnicemi. Ale jak bude rozložená v těchto systémech inteligence a řídicí algoritmy je otázkou. Dnes již komunikační rychlosti dovolují rozdělení v podstatě libovolné.
Jinak pokud máte zájem se naučit jak programovat a pracovat s PLC, tak na naší katedře je celá skupiny na tuto oblast zaměřené. I když vždy je základem mít představu, jak vytvořit algoritmus, chápat, jak se ovlivňují a synchronizují věci probíhající na mnoha jednotkách (a i v reálném světě) paralelně a jaká existují fyzikální omezení (na komunikaci po čipu, sběrnici, zastavení motoru) a dynamika vnějšího světa mimo počítač, a tak je vlastně jedno, jestli dobře umíte základy souhry procesů v tisíci systémovém cloudu, nebo se problémy naučíte na souběhu a pipeliningu instrukcí na jednoduchém CPU, nebo na začátek programujete Lego robota
http://www.robosoutez.cz/ . Pokud si dokážete ze všech takových předmětů a externích podmětů vytvořit schopnost nadhledu a i analýzy od základů směrem nahoru, tak zjistíte, že se oblasti překrývají a schopnosti pohledu z různých perspektiv a oborů se vzájemně násobí. Zde mám obavu, že mnoho studentů si to dnes neuvědomuje a chce rychle být špičkou (nebo dobře oplaceným zaměstnancem) v úzkém oboru.
Pro zájemce o pochopení a pohrání si s řízením na levném (často vysloveně "pouťovém") HW, připravuji s redakcí Roota dva články shrnující moje prezentace a bude-li zájem, tak třeba bude i pokračování. Pokud by se našli zájemci, co by si téma pořádně nastudovali, zkusili si mnou prezentované levné řešení nabastlit a pak se chtěli sejít a poradit s dotažením do funkčního stavu, tak nabízím uspořádat seminář/workshop v rámci setkání SUT. Bohužel z minima reakcí na přednášky mám spíš pocit, že většina se ráda nechá pobavit, ale o to trávit kvůli opravdovému pochopení hodiny s pájkou a desítky hodin před klávesnicí zájem nemá.
Pokud chcete pokročit na vyšší úroveň znalostí, tak je nejlepší se po nějakém takovém seznámení (např. náš předmět
Programování systémů reálného času
https://support.dce.felk.cvut.cz/psr/) zapojit do nějakého projektu na některé univerzitě, kde se počítá s tím, že na projektu nepracují ještě hotoví, najmutí profesionálové/zaměstnanci a máte možnost se učit od pedagogů/vývojářů se zkušenostmi a především od svých kolegů, kteří třeba již v určité oblasti pokročili dále (někdy i než jejich pedagogové/vedoucí). Přitom v projektech na školách není většinou problém s uzavřeností, hlídáním know-how a konkurencí (mezi-firemní i mezi zaměstnanci) jako je v reálném životě.
S pozdravem
Pavel Píša
ČVUT FEL, Katedra řídicí techniky, člen týmu
http://industrialinformatics.cz/Vývojář a vedoucí koncepcí řešení firmy
http://www.pikron.com/
59 Odpovědí
30649 Zhlédnutí