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

Milan Kratochvíl krata.milan na seznam.cz
Středa Prosinec 13 16:32:45 CET 2017


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

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

Milan

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.


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



Další informace o konferenci Linux