Linux jako PLC (MaR, SCADA, ...)

Středa Prosinec 13 17:51:41 CET 2017

Milan Kratochvíl wrote:
: Dobrý den,
: 
: Ze zkušenosti bych řekl, že vše má svá úskalí či jiné objemy prací a
: samozřejmě i jiné ceny.
: 
: U nakupovaných IO modulů a PLC budete řešit zda vám stačí a jak
: obejít nedostatečná zabezpečení, jak obejít, že nemůžete udělat
: vlastní protokol a další a další a to nemluvím o ceně, která bude u
: kusovky astronomická. Faktem je, že pokud do dáte slušně dohromady
: tak to bude běhat i několik let bez jediného zaseknutí.

	Moje zkušenost je jiná. Řešili jsme třeba PLC, které se někdy
jednou za několik měsíců "náhodně" zaseklo. A zaseklo se tak, že operační
systém se rebootoval, PLC tedy vypnulo všechny vstupy, a pak nenaběhl program.
Řádově 100 kW tepelného zisku datacentra bylo najednou bez chlazení.
Zvýšení teploty o 1-2°C za minutu, čili tak za čtvrt hodiny game over.
Výměna PLC nepomohla, byla to zřejmě SW chyba v operačním systému.

	Podle mých zkušeností nejsou "hardwarové" PLC o mnoho
spolehlivější než to Raspberry. Možná dokonce naopak jsou méně spolehlivé.

: U nakupovaných IO modulů a vlastním řízení budete řešit jakou
: sběrnici použít aby to stíhala řídící deska a možná se dostanete do
: stadia kdy nejvíce práce zabere komunikace s moduly a odladění všech
: částí programu tak aby se nesekal po měsíci provozu.
: 
: Nakonec bych řekl, že záleží na počtech IO co potřebujete a na
: prostředí ve kterém budou běhat. Poslední dobou používám moduly od
: Balluffa (IOlink nebo EtherCat) nebo od Beckhofa (Ethercat). Jako
: řízení mám nařízeno Beckhoff což je softwarové PLC běžící na Windows
: (což asi nechcete slyšet). Programuje se to pomocí TwinCat3 což je
: Codesys ve VisualStudiu a tak si můžete udělat skoro cokoli, ale ta
: cena je šílená.
: Pro změnu doma jsem udělal řízení vytápění (včetně kotle na uhlí) na
: Arduinu Mini a byl jsem spokojen dokud jsem nekoupil nový kotel.
: Jakmile padne záruka tak vyhodím Siemense co tam mají osazeného a
: udělám si něco co bude fungovat. Asi opráším Mini jen rozšířím
: hardware, což zase přináší jiná úskalí.
: 
: Shrnul bych to tak, že pokud se primárně chcete věnovat pouze
: vlastnímu programu pro řízení technologie tak je to verze PLC + IO
: moduly, ale ta cena.
: Pokud použijete vlastní desku + IO moduly bude cena menší, ale
: strávíte spoustu času programováním a odlaďováním komunikace s
: moduly.

Ono to má ještě tu výhodu, že když budu mít program pod kontrolou,
tak ho kdykoli budu moct upravit. Zatímco takto jsem byl vázaný
na externí dodavatele, a za čas se dozvíte "tohle už se nevyrábí,
tohle už nepodporujeme".

Samozřejmě je to víc práce a netroufl bych si to zadat externí firmě,
ale zase možná ten výsledek a to, že to celé mám pod kontrolou,
bude ve součtu lepší.

: Pokud použijete vlastní desku + vlastní IO moduly bude cena nejmenší
: (možná) a strávíte opravdu spoustu času na vlastním zprovozněním
: hardware a vlastní program pro řízení technologie bude jen mizivá
: část práce.

	Jo, asi do vlastních modulů bych nešel.

: PS: právě mne ještě napadla varianta použít nakupované PLC + IO pro
: řízení technologie a přidat desku (třeba právě Raspberry) pro
: komunikaci s vnějším světem. Takto jsem to měl před cca 10 lety, ale
: tehdy ještě nebylo Raspberry tak jsem tam měl normální počítač s UPS
: a na něm Debian, který tahal data z PLC pomocí sériové linky a
: Apache + PHP pro přístup z internetu. Web jsem si napsal sám a tak
: bylo zabezpečení jen na mne.

	Já jsem právě chtěl mít pod kontrolou i ten program, nejen
komunikaci. To je prostě zoufalé když chodíte kolem té vizualizace
a přímo vidíte, že "teď by to mohlo dělat něco trochu jiného a ušetřil bych
energii", vidíte, že ta změna by byla pár řádků, ale buďto to nemůžete
zadat dodavateli, nebo by to bylo příliš drahé.

	Tož tak. Díky za názor.

-Y.

: Dne 13.12.2017 v 15:17 Jan Kasprzak napsal(a):
: >	Dobrý den,
: >
: >TL;DR: jak byste řídili průmyslové procesy v Linuxu? Jakým hardwarem
: >	a jakým softwarem?
: >
: >Podrobně: možná budu specifikovat nebo i nakupovat a třeba i programovat
: >řídící systém pro nějaké technologické procesy (nic realtimového,
: >představte si třeba chlazení/topení, řádově větší desítky I/O),
: >a protože z pozice zákazníka a uživatele už bohužel mám s pár takovými
: >systémy zkušenosti, a z pozice programátora a uživatele Linuxu by se tyto
: >zkušenosti daly povětšinou shrnout do zkratky "WTF", přemýšlím o tom,
: >jestli jde toto toto dělat lépe.
: >
: >Jedna věc je fyzická stránka - kde vzít nějaké elektricky a fyzicky
: >robustní vstupy a výstupy - jednak rozumně spravovatelné, na DIN lištu,
: >odolné proti rušení i elektrostatice, digitální i analogové (0-10V, třeba).
: >
: >Druhá věc je "procesorový modul". Tady jsem potkal jen brutálně předražené
: >a poddimenzované proprietární věci, ke kterým často potřebujete proprietární
: >IDE, někdy i s HW klíčem, a u kterých brzo narazíte na to, že "tohle
: >už neupočítáme". A přitom máte dost jasnou představu, že Raspberry Pi
: >za tisícovku toho v Perlu nebo Pythonu zvládne daleko víc, než proprietární
: >PLC v kompilovaném jazyce. A to nemluvím o bezpečnosti typu "nezměnitelné
: >implicitní heslo", nešifrované HTTP, nebo "webové rozhraní bez kontroly
: >parametrů"[1]. Ale zase Raspberry není přímo napájitelné ze standardních 24 V.
: >
: >Třetí věc je software: já bych to asi programoval v Perlu protože proč ne,
: >ale radši se zeptám, jestli jsou reálně použitelné i jiné možnosti,
: >kde by ta věc byla lépe připravená na "událostní" řízení, generování
: >vizualizací, ladění za běhu, atd.
: >
: >No a poslední věc je komunikace: protokolů je spousta, jeden horší než
: >druhý :-)
: >
: >- SNMP nemá transakčnost, v3 skoro nikdo neposkytuje, načítat třeba každou
: >	vteřinu stovku hodnot není rozumně realizovatelné.
: >- MODBUS je jednoduchý, ale RTU (a některé implementace TCP) poskytují
: >	jen jednu session, nelze k tomu přistupovat zvlášť třeba Nagiosem
: >	a zvlášť nějakou vizualizací. Taky není samodokumentující se
: >	a nemá "push" notifikace, je nutný polling
: >- BACnet je samodokumentující se, událostně řízený, se sofistikovaným
: >	skládáním skutečných hodnot z různých automatick nastavených a ručně
: >	přenastavených priorit, ale je to obrovský mastodont, který navíc
: >	každý výrobce implementuje trochu jinak a navzájem nejsou příliš
: >	kompatibilní. Některá BACnetová PLC (Delta) ale mají programy přímo
: >	čitelné jako zdroják a editovatelné přes samotný BACnet, což je pěkné.
: >- s CAN jsem zatím nepracoval, takže nevím
: >
: >Zatím mi jako nejlepší vychází koupit něco proprietárního, co má rozumně
: >elektricky a mechanicky udělané vstupy a výstupy, a tyto jen tupě překládat
: >třeba na MODBUS/RTU (něco takového dělá třeba WAGO), a vedle toho postavit
: >Rasberry nebo jiný obecný počítač, a na něm dělat tu inteligenci,
: >jejíž výsledky dál posílat jako SNMP/JSON/cokoli dalšího. Toto by mohlo mít
: >výhodu lepší napojitelnosti i na další věci, které třeba samy komunikují přes
: >SNMP nebo jiné protokoly.
: >
: >Máte někdo nějaké zkušenosti s takovýmito systémy? Jak byste tohle dělali?
: >
: >-Yenya
: >
: >[1] Potkal jsem například zařízení, kde ve webovém rozhraní se četl logovací
: >soubor na URL http://to_zarizeni/log?file=/var/log/log.txt. A skutečně se
: >to tak chovalo, při změně parametru "file" to bylo ochotné poskytnout
: >jakýkoli soubor :-(
: >
: 
: _______________________________________________
: Linux mailing list
: Linux na linux.cz
: http://www.linux.cz/mailman/listinfo/linux

-- 
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| http://www.fi.muni.cz/~kas/                         GPG: 4096R/A45477D5 |
> That's why this kind of vulnerability is a concern: deploying stuff is  <
> often about collecting an obscene number of .jar files and pushing them <
> up to the application server.                          --pboddie at LWN <