Proměna programátora desktop → PLC

Re:Promena programatora Desktop -> PLC
« Odpověď #30 kdy: 12. 03. 2016, 22:10:54 »
http://www.beremiz.org/
Díky! Je trochu problém se v tom vyznat, co je vlastně co a co to má dělat, ale každopádně mě to mj. zavedlo na zajímavej blog https://serverway.wordpress.com/category/projects/plc-from-scratch/

Mj. tam píše, že těch pokusů je prý teď hodně. A navíc jsem se z jeho diplomky dozvěděl, že slovinsky se controller řekne krmilnik, to taky není k zahození! :))


Petr

Re:Promena programatora Desktop -> PLC
« Odpověď #31 kdy: 13. 03. 2016, 02:00:52 »
Zdravím mladší kolegy, po sedmnácti letech práce v průmyslové automatizaci bych se chtěl PLC trochu zastat. Hlavní výhody z pohledu návrháře systémů a programátora:
- Jednoduché připojení prakticky jakýchkoliv V/V do jakékoliv průmyslové sítě (Profibus, průmyslové verze ethernetu, ...). Od digitálních vstupů po pohony či měřicí systémy. To je obrovská výhoda. Žádné bastlení či hraní si s vývojem ovladačů. Moduly jsou v průmyslovém provedení a velice odolné. Rozhodně nesrovnávat s moduly pro Arduino nebo RPi. To jsou jen hračky, které nemají v průmyslu místo.   
- Standardizované jazyky LD, FBD, SFC a pak i nějaký IL nebo něco na způsob jednoduchého C. Můžete se zaměřit na řídicí algoritmus a jazyk je vlastně pořád stejný.
- Realtime systém s definovanou max. dobou odezvy.
- Jednoduchá práce online (za běhu).  Nastavování proměnných (force), změny programu, atd. bez nutnosti zastavovat běžící program.
Možné diskutabilní vlastnosti:
- Závislost na jednom dodavateli. Je to trochu problém, ale výhodou je vysoká spolehlivost. Zákazník má většinou vyškolený personál na jednoho výrobce PLC a tento systém pak požaduje.
- Vysoká cena. Trochu zavádějící argument. Cena PLC systému je většinou v porovnání s cenou řízeného technologického celku zanetbatelná.
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.

Práce programátora (vývoj):
Záleží jakých projektů se účastníte. Na PLC můžete realizovat triviální úlohy typu zapnout/vypnout až po specializované regulátory pro hydrauliku. Na to první Vám stačí SŠ, na to druhé potřebujete znalosti z teorie řízení na úrovni min. klasického VŠ. Bláboly o přeplácených PLC programátorech jsou pak naprostý nesmysl.

Je dobré vědět, že řídicí systémy běží 24/7. Není tady místo pro restarty a výpadky, protože každé zastavení technologie stojí konkrétní velké peníze. Tomu musí odpovídat i kvalita programu. Proto se vše tak dlouho testuje a používají se poměrně triviální ale spolehlivé jazyky. Proto je průmysl tak konzervativní.

txt

Re:Promena programatora Desktop -> PLC
« Odpověď #32 kdy: 13. 03. 2016, 13:08:02 »
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
V této oblasti se už začíná trochu šetřit. Místo létání letadlem kvůli každé prkotině lze použít VPN.
Např. http://ab.rockwellautomation.com/Networks-and-Communications/Network-Address-Translation-Device podporuje Ethernet/IP protokol kterým komunikují PLC.

robotron

Re:Promena programatora Desktop -> PLC
« Odpověď #33 kdy: 13. 03. 2016, 13:22:15 »
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
V této oblasti se už začíná trochu šetřit. Místo létání letadlem kvůli každé prkotině lze použít VPN.
Např. http://ab.rockwellautomation.com/Networks-and-Communications/Network-Address-Translation-Device podporuje Ethernet/IP protokol kterým komunikují PLC.

To jo, ale predrecnik nemel na mysli jen bezpecnost sitoveho pripojeni, ale provozu jako takovyho -- kdo si vezme na triko, ze zmacknutim klavesy sejme nekde spatne stojiciho delnika do vany s vroucim olejem, treba.

prezek

  • ***
  • 229
    • Zobrazit profil
Re:Promena programatora Desktop -> PLC
« Odpověď #34 kdy: 13. 03. 2016, 13:47:44 »
PLC mi nepřijdou nijak závratně drahá. Rád bych s nimi získal nějakou praxi. Teď dělám systémy založené na mikrokontrolérech a od zadání k realizaci je hrozně dlouhá doba. 1. vytipování součástek 2. návrh schématu 3. návrh DPS 4. osazení DPS 5. Oživení DPS, první SW 6. zahození DPS, protože nějaký parametr nevyhovuje (přehřívání, EMI, součástky s jinými parametry, než uvádí výrobce, popletená popiska), návrat k bodu 1.
.... 7. konečně nějak funkční SW. Součástí a HW pak musí být nějaké kontrolní mechanismy, bootloader, obslužný SW pro PC...
U vlastního HW je často potřeba komunikovat s každou součástkou jinak.
U PLC stačí (podle mého nezasvěceného pohledu) nakoupit kompatibilní komponenty, snímače a výstupy a pomocí omezených jednoduchých příkazů vše spojit ve funkční celek.


Yarda

Re:Promena programatora Desktop -> PLC
« Odpověď #35 kdy: 13. 03. 2016, 15:45:00 »
Teď bude v Brně tahle výstava
http://elektrika.info/news/voucher-na-amper-2016
Divil bych se, kdyby tam nebyly firmy co nějaká ta péelcéčka nabízejí a pořádají o nich školení.

ewrfiweirh

Re:Proměna programátora desktop → PLC
« Odpověď #36 kdy: 14. 03. 2016, 11:42:55 »
 prezek:
Ano mas pravdu par jednoduchych prikazov a vuala... presne ak chces jednoduchy HTML formular par prikazov kdezto v C++ by si musel riesit xyz veci. Ale ak chces od PLC napriklad ovladanie vodnej elektrarne tak uz len to "simple command list" uz nefunguje. :D A k tej praxy. Je uplne genialne ked si doma slasnostne postavis ovladanie vrtacky, Zapni , vypni , chod na poziciu ale uplne na pichu vo vyrobe kde take primitivne veci proste nepouzijes a az tam zistis co je to "PLC chlebik" ale kazdopadne skus.
Pracu PLC programatora si predstav asi takto. Pridem k zariadeniu (dopravnik + miesacka) a nejde len o to ze nasekas program. Musis ho odladit na danu technologiu. Musis si napriklad odladit regulatory, pohony, dokonale ovladat proces tak aby si pripadne vedel upravit co treba. Takze napriklad projekt pre automaticku balicku cukrikov mas tak 30% za PC (programovanie) 30% fyzicky osahavas HW (menice, motory, enkodery....) 40% doladujes a testujes na tu danu technologiu + 100% casu na FAT testy a dokumentacie.

Petr

Re:Proměna programátora desktop → PLC
« Odpověď #37 kdy: 14. 03. 2016, 12:38:22 »
Citace
V této oblasti se už začíná trochu šetřit. Místo létání letadlem kvůli každé prkotině lze použít VPN.
Např. http://ab.rockwellautomation.com/Networks-and-Communications/Network-Address-Translation-Device podporuje Ethernet/IP protokol kterým komunikují PLC.

Nejde mi o technické řešení připojení PLC na internet. Stroj nemusí mít motory o výkonu v MW či hydrauliku se silami v MN. I poměrně malý robot Vám může zpřerážet kosti. Sám vím o experimentálním ověření tohoto postulátu spočívajicím ve vyblokování safety okruhu a vstupu na území robota, který se pak nenadále pustil do práce. Věřte, že s tím vetřelcem byl rychle hotov. Budíž mu země lehká.
Pokud uvádíte do provozu nebo testujete reálný stroj s rotujícími nebo pohybujícimi se částmi, tak v civilizovaných zemích ho musíte obehnat páskou a přidat zákaz vstupu. Také tam musí být hlídač pro případ, že by nějaký mentálně znevýhodněný jedinec zákaz vstupu porušil. Dále je dobré předem otestovat ústupovou strategii pro případ nepředvídaných problémů (e-stop, quick stop apod.). Zkrátka někdo musí být schopen okamžitě zmáčknout stopku. To se na dálku dělá dost špatně. Navíc, co když Vaše změna způsobí postranní efekt v jiné části programu? Kdo to pak bude opravovat a znovu testovat? Vůbec už nemluvím o získání kontroly nad PLC nějakým útočníkem. Proto bezpečnost především. Na jednoduché věci lze spíše využít někoho šikovného z místní údržby. Řici mu co a jak a po záloze běžícího programu to změnit a otestovat. Na něco většího si firmy raději zaplatí fyzickou přítomnost programátora. Pokud se jedná o přidání nové funkce, tak se často dělá i nový integrační test.
Ještě poznámka. Na většinu SW v průmyslové automatizaci se vztahuje záruka. Součásti projektu je tzv. Final Acceptance Test, který musí zákazník podepsat. V té době už musí být všechny nedodělky v SW uzavřeny. Jinak nejsou peníze.

Re:Proměna programátora desktop → PLC
« Odpověď #38 kdy: 15. 03. 2016, 12:53:42 »
Hlavně je potřeba si uvědomit, že je obrovský rozdíl v programování PLC a desktopových aplikací. Je to dáno už z principu věci. Jak tu již bylo popsáno, PLC funguje (zjednodušeně) takto:

1. - načtou se do proměnných stavy vstupů
2. - vykoná se vlastní program (jedna nebo několik POU - Program Organisation Unit) napsaný v některém z jazyků (IL, ST, LD či dokonce C/C++)
3. - přepíšou se hodnoty na výstupy
4. - ve volné chvíli (tzv. idle time) PLC komunikuje s vnějškem například pro potřeby SCADA programů (OPC, etherenetové komunikace atd.)
5. - jde se na bod 1

Samozřejmě se hlídá doba smyčky (tedy bod 2 nesmí překročit určitou dobu + tolerance) tato doba můžou být stovky mikrosekund až třeba jednotky vteřin, podle toho, jak rychle chci reagovat v programu na "vnější svět - I/O" a samozřejmě podle typu technologie kterou řídím. Třeba na řízení dopravníku a zastavování od fotonky mi stačí smyčka 10ms (což je z hlediska moderních PLC strašně dlouhá doba), kdežto třeba na skenování čárových kódů na jedoucím dopravníku 1,6m/s s jejich realtime odesíláním z PLC někam pryč si nastavím smyčku třeba 1ms, nebo méně. A hlavně při programování PLC se nesmí zapomenout, že program běží stále v té smyčce, na rozdíl od programování desktop aplikací na PC.


Kdežto programování pro desktop je zcela něco jiného. 99% času programu se čeká na nějakou uživatelovou reakci (tedy na nějaký event) a 1% je vlastní program, který něco udělá.

Jinak samozřejmě lze na některé účely využít destičky typu Arduino (jehož programování se spíš podobá PLC programování), nebo RaspberryPi, avšak nejsou to vhodné věci na řízení technologie v ceně statisíců až X milionů korun.

Re:Promena programatora Desktop -> PLC
« Odpověď #39 kdy: 21. 03. 2016, 09:11:39 »
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
Řídící systémy jsou k internetu připojeny běžně a je vidět, že hlupák nebudeš možná ty. Budeš se divit, ale existují vpn sítě které bezpečnost docela dobře řeší. Nevim co to má společného s bezpečností lidí v jakémkoliv směru???

SP.

Re:Promena programatora Desktop -> PLC
« Odpověď #40 kdy: 21. 03. 2016, 17:31:36 »
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
Řídící systémy jsou k internetu připojeny běžně a je vidět, že hlupák nebudeš možná ty. Budeš se divit, ale existují vpn sítě které bezpečnost docela dobře řeší. Nevim co to má společného s bezpečností lidí v jakémkoliv směru???

Hochu, vylez ze své IT bubliny, přečti si ještě jednou celý příspěvek od pana Petra a zamysli se nad tím.  Petr ví moc dobře o čem hovoří. Ty ne. Nevím, co jsi chtěl naznačit první větou, pokud jsi chtěl říct, že je pan Petr hlupák, tak se mu omluv, pokud ne zkus to napsat srozumitelněji.

Táta cca od 1980 navrhuje zapojení PLC a dělá technika při uvádění zařízení do provozu. V mládí jsem s ním jezdil jako výpomoc, ale obor mě nezaujal.

Praxe při uvádění zařízení do provozu nebo úpravách je následující: O zařízení se stará tým techniků a programátoři. Technici řeší problémy typu nefunkční, špatně zapojené snímače. Testují se bezpečnostní okruhy. Po vyřešení problémů a kontrole bezpečnostní okruhů programátor spouští program a zařízení se rozbíhá, technici s vysílačkami jsou na místě u kritických přívodů energie (Plyn, stlačený vzduch, elektřina, .... ). V případě, že dojde k něčemu neočekávanému, technici na povel velitele (hlavní technik, nebo programátor) zastaví příslušné přivody energie. Potom se pátrá po příčině, to už bývá programová záležitost. Dále se zařízení testuje v rámci daných provozních omezení. Vždy je ale nutná součinnost techniků a programatorů přímo u zařízení. Chyba v programu může i přes všechny bezpečnostní okruhy pořád způsobit smrt spousty lidí a značné materiální škody (Desítky milionů Kč). Takže představa, že programátor bude sedět v práci a přes net nahraje do PLC program a potom ho upraví je zcela mylná. Bez součinnosti s techniky na místě to prostě nejde a seriozní dodavatel zařízení to ani jinak nedovolí.

kkjan

Re:Proměna programátora desktop → PLC
« Odpověď #41 kdy: 21. 03. 2016, 17:33:07 »
S bezpecnostou ludi to ma spolocne hodne ak nie najviac. Napriklad ak urobis nejaku zmenu na dialku tak ako si zabezpecis aby ti  obsluha nestala pri stroji ak by daco nevyslo? Alebo ako zabezpecis aby sa ti nejaka obsluha nemotala pod nejakou napriklad nadrzou ak by nahodou pretiekla? Pripadne ak daco nevyjde ako ma tak ak nie si priamo pri tom tak nemas sancu rychlo a promptne reagovat na vzniknutu situaciu apod. napriklad aj nudzovym stop tlacitkom:-D Treba si uvedomit ze PLC je priemysel a tam sa pracuje i s tocivymi strojmi, vysokym napatim, nebezpecnymi latkami, kyselinami, zasadami plynovym ohrevom a neviem cim vsetkym este. Ano vyuziva sa to a docela hodne ale iba ako servis na vzdialenu diagnostiku pripadne pre minimalne zasahy. Urcite nie  pre kompletne spustanie technologie alebo rozsiahlejsie upravy programu.

v

Re:Proměna programátora desktop → PLC
« Odpověď #42 kdy: 21. 03. 2016, 18:41:26 »
Napriklad ak urobis nejaku zmenu na dialku tak ako si zabezpecis aby ti  obsluha nestala pri stroji ak by daco nevyslo?
úplně stejně jako když se to dělá místně?

Yarda

Re:Proměna programátora desktop → PLC
« Odpověď #43 kdy: 22. 03. 2016, 07:36:12 »
Napriklad ak urobis nejaku zmenu na dialku tak ako si zabezpecis aby ti  obsluha nestala pri stroji ak by daco nevyslo?
úplně stejně jako když se to dělá místně?
IMHO je dost důležité, aby se řešitel seznámil, nejlépe osobně a opakovaně se situací na místě, kde jeho zařízení má pracovat. Je trochu rozdíl vymýšlet řešení v pohodlí kanceláře a přímo u zařízení ke kterému je přístup vleže po zádech s baterkou v zubech, aby se zjistilo, že vedle je instalované zařízení jiného řešitele co kolem sebe fouká horký vzduch a proto PLC trvale indikuje překročení maximální teploty >:(

Re:Promena programatora Desktop -> PLC
« Odpověď #44 kdy: 25. 03. 2016, 12:17:48 »
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.html

Př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/jailhouse

Urč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/