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

[Jan Kasprzak]

	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 :-(

-- 
| 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 <