Idekit – vaše řešení pro vývoj automatizačního softwaru
Dnes již prakticky každé složitější technické zařízení nebo funkční celek používá pro své řízení mikroprocesorovou jednotku. Její vývoj a výroba má v porovnání se strojní částí některé specifické vlastnosti, které mohou pro výrobce představovat rizika. V posledních letech tuto oblast postihlo zdražování a nedostupnost mikroprocesorů, trvalým problémem je nedostatek programátorů, doba pro uvedení zařízení na trh se neustále zkracuje, je nutno přicházet se zákaznickými modifikacemi... Domat Control System proto nabízí Idekit. Je to soubor nástrojů, který umožňuje oddělit runtime (základní software, který obsluhuje vstupy, výstupy, komunikace, displej atd.) od aplikačního softwaru (tedy od programu, který řídí strojní technologii podle požadavků zákazníka nebo zadavatele).
Obr. Oddělení runtime a aplikace v programovatelném řídicím systému
Zejména u výpočetně méně náročných zařízení, jako je tepelné čerpadlo, čistička odpadních vod, zavlažovací systém nebo klimatizační jednotka, obvykle probíhá vývoj softwaru v některým z nižších programovacích jazyků. To by v zásadě tolik nevadilo. Co je ale podstatné: v jednom kódu – byť v různých knihovnách – je řešeno vše, od nízkoúrovňové komunikace s hardwarem (fyzické vstupy a výstupy) přes nahrávání programu a vlastní funkce technologie až po uživatelské rozhraní, jako je obsluha LCD displeje nebo webového serveru. Tento přístup s sebou nese určitá rizika. První z nich je v samotné osobě programátora.
Programování embedded zařízení je vysoce specializovaná činnost. Programátor má vysokou kvalifikaci, obtížně se shání a není levný. Proto je potřeba jeho čas využít na maximum a ne ho nechat cestovat po realizacích, kde často řeší i provozní problémy, které s jeho prací nesouvisejí. Na svou práci by se měl mít možnost soustředit a ne fungovat coby technická podpora, jak tomu často bývá (i když umí poradit, protože zná dopodrobna kód). Neměl by být nucen zabývat se řízenou technologií; je sice obrovská výhoda, když technologii rozumí, a „v prvním přiblížení“ to zrychluje vývoj, protože tento univerzální programátor se nemusí s nikým domlouvat. Zároveň tím ale podstupujeme další riziko – personální, protože celá funkce technologie stojí a padá s jedním softwarářem. Řešení se tedy nabízí samo: oddělit programování specifické pro hardware (říkejme mu systémové) od programování aplikačního, tedy toho, které se přímo týká funkcí řízené technologie a uživatelského rozhraní. Aplikační programování pak probíhá v některém z jazyků podle IEC EN 61131-3, typicky pomocí funkčních bloků nebo strukturovaného textu, případně kombinace obou.
Proč bychom to měli chtít?
Lepší řízení lidí, zastupitelnost pracovníků
Místo skupiny univerzálních programátorů nám vzniknou systémoví programátoři a aplikační programátoři. Je vhodné, když se částečně vzájemně překrývají, jednak kvůli zastupitelnosti, jednak to zvyšuje motivaci. Je totiž dobré, když úlohy nejsou příliš abstraktní a programátor vidí, jak vypadá jeho práce v praktickém nasazení. Aplikační programátoři nemusí řešit koncepci hardwaru, zabývají se funkcemi technologie a snaží se ve spolupráci s marketingem a obchodním oddělením vyvinout takový software, který co nejlépe plní očekávání uživatele. Naproti tomu systémoví programátoři zajišťují přizpůsobení vývojového prostředí a runtimu určité hardwarové platformě (tedy použitému procesoru v konkrétním zapojení, se vstupy, výstupy a komunikačními rozhraními). Existují dokonce případy, kdy návštěva „skalního“ programátora u zákazníka může být z obchodního hlediska kontraproduktivní.
Podrobná a pravdivá dokumentace
Jedno z významných rizik při kombinovaném vývoji je to, že po programátorovi zůstane kód, který je dokumentován špatně nebo vůbec. Na psaní dokumentace během vývoje není čas a při realizaci zakázky narychlo vzniká dokumentace pro koncového uživatele, aby zařízení šlo vůbec předat.
Oddělení aplikace od systému ovšem znamená, že aplikační technici musejí dostat předdefinovaný přístup na vstupy a výstupy, třeba i s názvem datového bodu. Taková dokumentace je vlastně podmínkou pro vývoj aplikačního programu. Proto máme jistotu, že vznikne a že bude k dispozici na dvou místech – u vývojáře i u programátora aplikace. U složitějších systémů se navíc na vývoji musí podílet v jednom okamžiku i více osob, jinak by nebylo možné dodržet termíny. Dobře popsaný řídicí systém je proto nutnou podmínkou úspěšného dokončení akce.
Snižování personálních a operačních rizik
Poslední dva roky ukázaly, jak důležité je počítat i se situací, kdy klíčová osoba najednou není dostupná. Zdokumentovaný a snadno čitelný program umožňuje zastupitelnost softwarářů i servisních techniků. Nemělo by se tedy stát, že zákazník musí čekat dva týdny nebo déle, než se podaří předat know-how.
Snadnější redesign hardwaru
I tento bod se v nedávné době projevil jako klíčový. Pro nedostupnost součástek a jejich zvyšující se ceny, které mnohdy zcela rozvrátily ekonomickou kalkulaci řídicí jednotky, bylo (a stále je) nutné pružně reagovat na změny v sortimentu a redesignovat hardware řídicích desek tak, aby mohly být nasazeny dostupnější procesory. Zkušenost Domatu je jasná: za poslední tři roky bylo nutné upravit deset platforem kvůli naprostému nedostatku používaných procesorů nebo ukončení jejich výroby. Zákazník by si toho v ideálním případě neměl ani všimnout, protože jakékoli změny navenek mají významný dopad do projekce a servisu. Při oddělení runtimu a aplikace je výhodou, že aplikace (kterých může být i více nad jedním hardwarem, když jedna deska je použita ve více typech zařízení) není již nutné nijak zvlášť testovat, jde o prověřený kód, a můžeme se soustředit na správnou funkci runtimu. Znamená to tedy lehčí a rychlejší přechod na nový - dostupnější, levnější nebo jen výkonnější - hardware.
Řada nadstavbových funkcí je již hotova
Řídicí systém dnes není jen izolovaným ostrůvkem technologie. Jeho důležitou součástí jsou i komunikační možnosti. Nejde pouze o místní uživatelské rozhraní, jako je ovládací panel s klávesnicí a displejem, ale i o připojení na vizualizaci (nejlépe pomocí otevřeného protokolu, jako je Modbus nebo BACnet), webový server, OPC server, konektivita do cloudu, API (otevřené datové rozhraní pro snadnou integraci do cizích systémů) nebo odesílání historických dat do výkonné databáze. Všechny tyto funkce Idekit obsahuje – a podobně jako u řídicího programu, tvorba menu na panelu nebo webových stránek je otázkou aplikačního programování, nikoli nízkoúrovňového vývoje.
Pohodlný prototyping
Pro malosériovou výrobu nebo zkušební provoz technologie se nevyplatí vyvíjet cenově optimalizovaný hardware. Pokud pro nový model nestačí nějaká z již vyvinutých řídicích desek, můžeme použít univerzální, snadno dostupnou platformu, jako například Raspberry Pi nebo dokonce počítač s Linuxem či Windows, a doplnit je vstupně-výstupními moduly. Aplikace se pak dá poměrně snadno přenést na finální zařízení, které bude robustnější a levnější. Nedopusťme, aby potíže při vývoji řídicího systému ovlivnily time-to-market celé technologie.
Výborná diagnostika
Nejen při vývoji řídicího systému, ale i při uvádění technologie do provozu se stává, že se vyskytne problém. Při jeho diagnostice je dobré vidět „dovnitř do systému“, jednak na hodnoty proměnných, jednak na tok dat na komunikačních linkách. K tomu slouží komfortní debugovací prostředí včetně skeneru sériových komunikací, tzv. port monitoru. Je možné trasovat program, vytvářet zálohy nastavených parametrů, vzorkovat okamžitou i dlouhodobou historii online i offline atd., a to vše i na dálku po síti, bez zásahu do řídicí desky a nejrůznějších programovacích adaptérů. Zjistit, že například elektroměr odpovídá na jiné adrese, než bylo domluveno s dodavatelem, je otázka několika minut.
Z čeho se tedy Idekit skládá?
V podstatě jde o dva základní programy: Idekit Studio, což je vývojové prostředí pro tvorbu aplikací, a Idekit Runtime, neboli program, který běží na cílovém hardwaru a umožňuje nahrání a spuštění vyvinuté aplikace. Tyto dva programy jsou doplněny řadou dalších volitelných modulů pro komunikaci s periferiemi i nadřazenými systémy, pro obsluhu zařízení přes mobilní telefon nebo webový prohlížeč atd. Konkrétní funkce závisí na požadavcích zákazníka, ale i na výkonových možnostech použitého hardwaru.
Obr. Programování v jazyce funkčních bloků v Idekit Studio
Nezávislost na dodavateli
Častým argumentem proti používání různých placených frameworků, knihoven a prostředí je finanční a strategická závislost jejich uživatelů na dodavatelské firmě. Ani to však u Idekitu nemusí být problém. Rozhraní mezi firmami je možné stanovit podle kompetencí a potřeb zákazníka. Existuje celá řada scénářů, od trvalé podpory po pouhý prodej a zaškolení. Pokud se zákazník rozhodne pro trvalou podporu, má jistotu, že se bude moci věnovat právě jen aplikačnímu programování – a veškeré práce nutné pro implementaci a udržování runtime dodává Domat. Má-li ovšem vlastní vývojový tým systémových programátorů, po zakoupení licence si může Idekit modifikovat a rozvíjet podle vlastních potřeb a priorit. Jakmile získá know-how, dosáhne nezávislosti na dodavateli a využívá výhod Idekitu bez dalších externích nákladů. Domat Control System je nicméně stále k dispozici pro případnou pomoc při budoucích implementacích, rozšiřování či upgradech.
Historie ukázala, že vlastní vývoj podobného systému u řady firem skončil neúspěchem nebo byl zastaven pro neudržitelný růst nákladů. Nezanedbatelným hlediskem je i časový faktor – případné zpoždění při vývoji řídicího systému může ohrozit dodávky technologie v řádově vyšších finančních objemech, nemluvě o dopadech na pověst firmy. Idekit vychází z programového balíku pro programování procesních stanic Merbon, je vyvíjen od r. 2012 a runtime již běží od roku 2014 na tisících podstanic po celém světě. Značka Idekit dnes nabízí sílu prověřeného systému nejen programátorům systémů řízení budov, ale i dodavatelům specializovaných technologických zařízení, jako jsou klimatizační jednotky, tepelná čerpadla, vzduchotechniky a podobně.
Obr. Některé hardwarové platformy, na něž byl Idekit implementován