Historie programovatelných automatů a jejich současné efektivní použití

Historie programovatelných automatů a jejich současné efektivní použití

Programovatelné automaty (PA), známé také pod obecně přijímanou zkratkou PLC (Programmable Logic Controller – programovatelné logické řídicí jednotky), nejsou na našem trhu novinkou. V nějaké jejich vývojové formě s nimi projektanti pracují již dobrých 30 let. V článku je stručně popsán dosavadní vývoj PA, především z hlediska softwaru, až do současnosti. Je konstatováno, že uživatelé a projektanti aplikací PA však mají teprve po poměrně krátkou dobu možnost volit způsob, jak s PA efektivně pracovat. Podporou jim při tom jsou především norma IEC 61131-3, definující určité standardní metody (jazyky) pro programování PA, a také „znovuobjevovaný“ systémový poznatek, že v každém projektu by vlastní práci s PA měly předcházet standardní etapy analýzy a návrhu řešeného systému, řádně formálně zdokumentované, jejichž metodická a popř. i počítačová podpora je nyní již běžně dostupná.

1. První začátky

Myšlenka použití počítačů v přímém řízení je jen o málo mladší než samy počítače. Pokusy o konstrukci počítačů použitelných v automatizaci, a tedy vyhovujících požadavkům na činnost v reálném čase, se datují již od konce 50. let minulého století. Stále rostoucí výkonnost a spolehlivost počítačů při současně klesající ceně a požadavcích na provozní podmínky vedly na začátku 70. let k situaci, kdy bylo možné reálně uvažovat o efektivním a masovém uplatnění počítačů v automatizaci. V té době bylo také projektováno mnoho automatizovaných systémů vybavených počítači. Stále však šlo o etapu pokusů a ověřování. Podle výsledků statistických šetření – provedených tehdy ústavem INORGA – bylo v oboru těžkého strojírenství a hutnictví na celém světě zhruba 60 % projektů počítačově automatizovaných systémů neúspěšných. Od této doby však počet aplikací i počet úspěšných projektů a dokončených děl plynule rostl. V cestě širšímu uplatnění počítačů v přímém řízení stála relativně velká cena počítačových systémů. Bylo co zlepšovat i ve spolehlivosti, výkonnosti a dalších parametrech důležitých pro aplikace. Všechny tyto problémy v jisté míře přetrvávají dodnes, ale již nejsou hlavní překážkou aplikací. Do popředí však neustále, a v současné době čím dál tím více, vystupuje otázka ekonomické efektivnosti. Zmíněné otázky však nejsou námětem tohoto referátu. Hospodárnost ale byla v 70. letech dvacátého století důvodem, který vedl ke konstrukci specializovaných počítačových systémů, jež se i v tehdejších podmínkách již dokázaly efektivně uplatnit v automatizaci v průmyslu.

2. Nástup PA začal v 70. létech

2.1 Potřeba náhrady univerzálních počítačů
Zmíněné specializované počítače nalezly uplatnění ve specifické oblasti automatizace – v ovládacích obvodech automatizovaných strojů a zařízení založených na řízení typu ano-ne. Univerzální počítačové systémy byly příliš drahé a pro daný úkol zbytečně složité. To platilo pro technické i pro programové vybavení. V této situaci se na trhu objevily specializované logické procesory a specializované programové vybavení orientované pouze na realizaci ovládacích funkcí. Takové počítačové systémy byly tehdy vyvíjeny a některé z nich i použity v celkem úspěšných projektech i v našem státě – např. počítač PPC4, vyvinutý v ČKD. Postupem času však výrazně poklesla cena stále zdokonalovaných univerzálních procesorů, které postupně nahradily jednoúčelové přístroje dosud používané ve speciálních aplikacích. V průběhu 80. let dosáhl vývoj úrovně srovnatelné s dnešním stavem. V té době se také pro PA vybavené počítači ustálilo označení PLC.

V technickém vybavení PA se nyní nenachází mnoho rysů, které by bylo třeba podrobněji osvětlovat: univerzální procesory, postupně převážily výrobky firmy Motorola, obvody pro vstup a výstup dvouhodnotových, analogových a čítačových (digitálních) veličin, později i možnost přístupu na komunikační sběrnice. To vše v konstrukčním provedení vhodném pro montáž do běžných rozváděčů v průmyslovém prostředí. V současnosti jsou na trhu dostupné i systémy s velkou odolností proti nízkým i vysokým teplotám, chvění i nárazům a s velkou spolehlivostí, která velmi pravděpodobně zaručuje jejich mnohaletý bezporuchový chod.

Co se týče programového vybavení, situace tak jednoduchá a přehledná jako u hardwaru není. Uživatelé a projektanti zaměření pouze na problematiku automatizace ovládacích funkcí mohou oprávněně hodnotit software pro PLC jako dokonalý, plně vyhovující současným i budoucím potřebám. Z hlediska současných možností počítačového oboru lze, také oprávněně, úroveň programování PA hodnotit jako vcelku jednoduchou záležitost a vývoj v této oblasti jako soustavně více či méně opožděný za možnostmi, které poskytoval a poskytuje vývoj softwarových technik pro univerzální počítače.

K objasnění podstaty uvedených skutečností je třeba se znovu vrátit do 70. let minulého století.

2.2 Vývoj softwaru PA
Automatizované ovládání bylo v minulých dobách založeno na reléové technice, která byla v 60. letech postupně nahrazována polovodičovými integrovanými logickými obvody. U nás to byly např. stavebnice Transimat a Logizet. Matematickým modelem těchto obvodů jsou logické rovnice. U obvodů, u kterých se vystačí s relátky či s jednoduchými logickými funkcemi reprezentovanými jednotkami stavebnice, je skutečně možné celou úlohu popsat soustavou logických rovnic. Pro takovouto úlohu je univerzální programovací jazyk, v tehdejší době např. Fortran, zbytečně komplikovaný a těžkopádný. Naproti tomu stojí úloha „překladače logických rovnic“, kterou i v tehdejší době zvládl schopný analytik a programátor poměrně snadno.

Vedle toho však ovládací úlohy přinášely některé další problémy, které bylo třeba řešit. Jde sice o úlohy napohled jednoduché, využívající jen omezený soubor operací a funkcí. Složitost do nich ale vnášejí velké počty proměnných, se kterými se pracuje. Na to nebyly tehdejší metody programování připraveny. Ovládací úlohy nutně potřebovaly prostředky pro ladění a testování algoritmů a programů pro tyto neobvyklé podmínky. Současně byly vyvinuty simulační a testovací programové nástroje, které, za přispění nekomplikovaných úprav hardwaru, byly plně vyhovující v roli programové podpory testování a uvádění automatizovaných řídicích systémů do provozu. Naštěstí totiž ani tyto doplňkové úlohy nepatřily k mimořádně obtížným softwarovým problémům. Vznikl tak nástroj vyhovující potřebám své doby, který pro většinu řešených úloh nepotřeboval výsledky postupně dosažené vývojem v oblasti univerzálních počítačů, jako jsou operační systémy reálného času, vyšší algoritmické jazyky, strukturované a objektově orientované programování atd. Tak došlo k vydělení problematiky, kterou lze označit jako programování PLC, do samostatné vývojové větve, a až v posledních deseti letech je možné sledovat postupný návrat „ztraceného syna“ do hlavního proudu vývoje.

Byly tedy vytvořeny vlastní programovací postupy a nástroje, vyvinuté a zavedené již v ranných vývojových etapách rozvoje PA. Nutno poznamenat, že projektantů, kteří navrhovali reléové řídicí obvody, bylo mnoho. Stačí jen připomenout elektrické pohony, energetiku a další obory, aby si čtenář uvědomil ohromnou aplikační oblast a masu projektantů, kteří se automatizací ovládání zabývali a museli se jí zabývat i po zavedení počítačů, byť v jejich specializované podobě.

Bylo proto velmi prozíravé, že se tvůrci prvních PA snažili přizpůsobit metodám, které byly v daném oboru běžné. Tím se totiž vyhnuli potížím, jež museli překonat výpočtáři a konstruktéři při zavádění počítačů v jiných oborech. Ti dříve ve velké míře využívali např. grafické metody a zavádění počítačů je nutilo obracet se k nástroji, který jim dosud sloužil spíše jen výjimečně, k numerické matematice. Řešením často byla až generační výměna.

2.3 Vývoj metod programování PA
Běžným nástrojem projektanta reléových ovládacích obvodů bylo liniové schéma. Velmi jednoduchý grafický popis zapojení reléové sítě, snadno zcela formálně převoditelný na logické rovnice. Bylo tedy již v 70. letech možné vybavit PA potřebným softwarem a projektant mohl navrhovat ovládání způsobem, na který byl zvyklý, a dokonce o něco produktivněji než dříve.

Z obdobných důvodů a podobným způsobem byly doplněny nástroje umožňující navrhovat ovládací obvody sestavované z typových logických funkcí. Obě tyto metody přežívají dosud přesto, že od jejich vzniku došlo k dvojnásobné generační obměně projektantů.

Vývoj PA tak šel svou vlastní cestou. Hlavní proud vývoje počítačů však dosáhl pokroků, které se dříve či později musely prosadit u PA. Děje se tak mnohdy opožděně a za cenu zbytečných ztrát. V 60. letech bylo objeveno objektově orientované programování. Na začátku 70. let byly formulovány principy strukturovaného programování. Několik desetiletí se vyvíjely algoritmické jazyky pro aplikace reálného času, jejichž vývoj byl završen v polovině 80. let jazykem ADA. Postupně byl pochopen význam kybernetiky, zejména vědy o systémech, pro návrh a realizaci automatizovaných systémů a také programových systémů. Ustavily se a v praxi se postupně prosadily obory softwarového a systémového inženýrství. Byly vytvořeny a zaváděny do praxe metody analýzy systémů. Toto vše se ale ve vývoji metod návrhu a programování PA uplatnilo jen velmi málo.

Mezi objevy z počátku 70. let se vyskytl jeden, který měl pro oblast programování PA zásadní význam. Byly to Petriho sítě, matematický nástroj pro zkoumání koordinace procesů. Na jejich základě byla týmem univerzity v Grenoblu vyvinuta metoda GRAFCET (francouzská zkratka názvu funkční graf vazeb kroků a přechodů). Ke škodě věci postihl tuto metodu, zřejmě i ze stejných příčin, stejný osud jako jazyk Simula v objektově orientovaném programování. Delší dobu přežívala v ústraní a na vědomí byla širší komunitou vzata až v polovině 90. let, a to pod označením metoda, popř. jazyk sekvenčních funkčních grafů (Sequential Function Chart – SFC).

3. Metoda sekvenčních funkčních grafů

Základem dobrých vlastností metody sekvenčních funkčních grafů je myšlenka dekompozice jako účinného nástroje ke zjednodušování složitých problémů. Složitý systém se dekomponuje na jeho části. Modulární dekompozice rozkládá systém na moduly. Důležitá je správně zvolená hloubka dekompozice. Obecně platí, že menší moduly jsou jednodušší. Koordinace celku však vrací do dekomponovaného systému složitost. Systém složený z mnoha elementárních modulů je stejně složitý jako původní celek. Správná volba mezi počtem modulů a jejich „lokální“ složitostí je výsledkem dobré práce systémového analytika.

Dekompozice systému může být vedena v jeho struktuře. Pak se vlastně složitost postupně zmenšuje s klesajícím počtem stavových veličin jednotlivých modulů. Každý modul, jakožto subsystém, vykazuje určité chování. To může být také jednodušší nebo složité. Chování systému je typickým procesem. I zde je možné jeho složitost snadněji překonat, dekomponuje-li se chování systému, např. modulu, na dílčí procesy. Každý z dílčích procesů má určitou algoritmickou náplň a jednotlivé procesy se mohou vzájemně ovlivňovat, mohou podléhat určité vzájemné koordinaci. Tím se lze dostat k Petriho sítím – a na těchto principech byla vystavěna metoda GRAFCET.

Automatizace ovládání, aplikační doména PA, je příkladem systému, pro který je typickým znakem velké množství vzájemně souvisejících procesů.

Aby čtenář správně pochopil význam nové metody, je nutné ještě se vrátit k otázkám dekompozice struktury a dekompozice chování systému. Mezi nimi je podstatný rozdíl.

Dekompozice struktury je dekompozicí stavu. Pravidlem modulární dekompozice je minimalizace funkčních vazeb. Každý modul, který je částí systému, je určen obecně menším počtem stavových veličin. Chování takovéhoto modulu chápané jako jeden proces musí být vyjádřeno algoritmem, který popíše všechny možné změny stavu všech stavových veličin modulu.

Dekompozice chování je dekompozicí uvedeného souhrnného procesu. Dílčí procesy nemusejí obhospodařovat všechny stavové proměnné daného modulu ve všech stavech, ale dotýkají se jen těch, které spadají pod působnost daného dílčího procesu. Zjednodušení z toho plynoucí je zřejmé.

Z právě uvedeného vyplývá zásadní rozdíl mezi metodou stavů a přechodů mezi nimi a metodou kroků a přechodů.

Metoda stavů a přechodů (state-transition) vychází ze znázornění chování systému stavovým diagramem (síťovým grafem). Jeho uzly jsou stavy, hrany představují přechody mezi nimi. Jednotlivým událostem mohou být přiřazeny různé přechody v závislosti na dodatečné podmínce. Každý přechod mezi stavy může být spojen s akcí, kterou přechod aktivuje. Metoda stavových diagramů je velmi starým a osvědčeným analytickým nástrojem. Je také často doporučována jako nástroj pro popis algoritmů ovládacích automatik. S tím lze souhlasit, jde-li o analytickou část práce, tj. o počáteční fázi projektu. V etapě návrhu algoritmů a v jejich implementaci je to ale již nástroj poněkud těžkopádný. Mimo již zmíněné vlastnosti dekompozice stavů je její nevýhoda i v tom, že je třeba vyšetřit všechny možné přechody mezi stavy, přičemž se snadno ztrácí přehled o jejich vzájemné koordinaci. Nezřídka jsou akce spojené s různými přechody totožné nebo téměř totožné. Akce mohou být někdy značně složité a stavový přístup neposkytuje jednoduché možnosti dalšího zjednodušení. Na závěr tohoto stručného naznačení vlastností stavového přístupu se sluší poznamenat, že struktura algoritmu vyjádřená stavovým diagramem se zásadně liší od toho, jak by daný algoritmus vyjádřil zkušený analytik a programátor, a není tedy zřejmě optimální pro počítačovou implementaci.

4. Metody algoritmizace

Předností stavových digramů je určitý stupeň formalizace úvodních kroků analýzy systému. Definují se všechny možné stavy zkoumaného systému na zvolené úrovni rozlišení a pak se systematicky vyšetří všechny možné přechody mezi nimi. Některé z přechodů budou nerealizovatelné, jiné však budou svou akční náplní shodné s jinými přechody v systému. Tím jednoduchost a přehlednost metody stavových diagramů končí.

Dekompozice procesů založená na metodě kroků a přechodů a navazující na stavovou dekompozici vyhovuje konečnému cíli, tj. implementaci ovládacího algoritmu, mnohem lépe. Postupuje se tak, že pro daný modul se definují všechny procesy, popř. se rozčlení na další dílčí procesy. V praxi projektant často neví, kde a jak začít. Obvykle lze vyjít od procesů, které představují běžnou funkci ovládací automatiky. Tento postup je možné výstižně charakterizovat výrokem: „Začneme 1. ledna v šest hodin ráno.“ Od výchozí situace se pak postupuje dále. Jednotlivé procesy mohou na sebe navazovat i probíhat souběžně. Některé procesy mohou koordinovat jiné nebo být s jinými procesy koordinovány apod. K popisu základní funkce se pak připojí doplňkové procesy, procesy obsluhující nestandardní situace atd. Procesy vždy pracují jen s těmi proměnnými, které jsou danou činností ovlivňovány. Orientace na procesy přináší ještě jednu podstatnou výhodu. V každém časovém okamžiku algoritmus sleduje jen ty kroky, které jsou aktivní (neošetřuje tedy aktivní stav a všechny jeho přechody). To velmi často znamená sledovat jen zlomek počtu operací, kterými chování systému potenciálně disponuje. Praxe ukazuje, že tento přístup je velmi efektivní a otevírá cestu projektantům k programové implementaci řídicích algoritmů bez programátorského zprostředkování.

Metoda kroků a přechodů (GRAFCET) má také některé nedostatky. Metoda musí vyhovět potřebám úloh, pro které je určena. Především pracuje se širším spektrem proměnných, než je v běžné programátorské práci obvyklé. Rozlišují se logické proměnné, analogové proměnné v pevné a v pohyblivé řádové čárce, časové proměnné a textové řetězce. Mnoho jazykových konstrukcí je věnováno vyjádření specifických požadavků ovládacích algoritmů, jako je např. respektování časových závislostí, koordinace dílčích procesů, vyjádření paralelismu a synchronizace procesů apod. To vše jsou nezbytnosti a v konečném důsledku výhody. Zásadním nedostatkem metody je vyjádření větvení procesů. Metoda připouští větvení procesů v závislosti na splnění podmínek. Tyto podmínky nemusejí být disjunktní, což však při implementaci může vést k chybné funkci. Uvedená nevýhoda se odstraňuje požadavkem na disjunktnost podmínek větvení, která však nemůže být formálně kontrolována, a je tedy na tvůrci algoritmu, aby ji dodržel.

Další, podstatnější nevýhodou je, že zavedení cyklů jako prvků tohoto grafického jazyka by značně zkomplikovalo a v jistém smyslu i omezilo jeho vyjadřovací schopnosti. Metoda GRAFCET proto nesplňuje požadavek strukturovaného programování na neexistenci provázaných smyček v algoritmu. To je známý a osvědčený zdroj chyb a ztížení jejich odstranění. Přes tyto jen s obtížemi překonatelné nedostatky je metoda GRAFCET zcela bezkonkurenčním nástrojem algoritmizace ovládacích úloh.

5. Operační systémy PA

Při pozornosti věnované softwarové problematice PA není možné pominout záležitosti navazující na otázky jazyka, kterým je algoritmus zapsán. Není nutné podrobně rozebírat otázky překladu a sestavení do proveditelné formy počítačového programu. Tato procedura nepřináší žádné zvláštní potíže, a jak to jen bylo technicky možné, převládlo použití křížových prostředků, které umožní přeložit, odladit a simulačně ověřit program na výkonném počítači v pohodlném vývojovém prostředí a hotový program přenést (download) do cílového počítače k otestování a zprovoznění.

Pozastavit se však je třeba u systémových prostředků, které zajišťují funkci programu ve vlastním automatu. Myslí se zde především operační systém. Jednoduchost úloh vedla k tomu, že ve vývoji PA nebyly kladeny požadavky na jejich činnost v reálném čase v plném významu tohoto termínu, a tedy na použití operačních systémů reálného času. Jistě zde hrála roli skutečnost, že vždy byl dostatek úloh, u kterých požadavek časové synchronizace byl snadno splnitelný. U pomalých řízených procesů vlastně o skutečný problém reálného času nejde.

Druhou vážnou příčinou bylo hledisko ekonomické. Řídicí počítače musely cenově konkurovat klasickým řídicím prostředkům a jejich cena musela být v relaci s přínosem pro ekonomickou efektivnost řízené technologie. Většina PA pracovala, a i dnes jich mnoho pracuje, pod jednoduchým operačním systémem. Ten je realizován jednoduchým cyklem, ve kterém se stále opakují fáze navzorkování vstupních veličin, vyhodnocení ovládacích algoritmů a přenesení hodnot výstupních veličin z počítače na vstupy technologického procesu. Pokud doba potřebná pro provedení jedné otočky tohoto cyklu vyhoví požadavkům řízeného procesu, není třeba hledat komplikovanější řešení. Stále dostupnější velmi výkonné a hlavně levné počítače pole působnosti tohoto přístupu soustavně rozšiřují. Existuje však nemálo úloh, které daleko vybočují z mezí charakteristik typických pro ovládací automatiky. V těchto případech se nelze vyhnout použití operačního systému reálného času. To se týká i tzv. úloh spojitého řízení, které se ovšem neobejdou bez obsáhlých ovládacích modulů. Poznamenejme, že pro tyto aplikace je metoda GRAFCET vybavena mechanismem funkčních bloků a jí příslušející moduly běží pod plnohodnotným operačním systémem reálného času.

6. Současné PA

6.1 Celkové trendy
Samostatný vývoj hardwaru PA se zdá být uzavřen a bude pravděpodobně sledovat další vývoj strojů na zpracování dat. Jedinou novinku, kterou se sluší na tomto místě uvést, představuje vznik tzv. softPLC. Jedná se o softwarovou realizaci PA na počítači typu (průmyslového) PC nebo jiném průmyslovém počítači, kde specifický hardware reprezentují pouze doplněné vstupní a výstupní desky. Rostoucí spolehlivost těchto počítačů v oblasti hardwaru i softwaru, jejich popularita a existující okruh vhodných úloh zajišťují těmto prostředkům další rozšíření působnosti.

Významný vliv na technické řešení PA má dnes již převládající distribuované řešení počítačových automatizačních systémů. Pro PA to znamená klesající požadavky na jejich složitost. Mohou zůstat jednoduchými stroji, do jisté míry specializovanými. Rostou pouze požadavky na schopnost komunikace a v souvislosti s tím na možnost jednoduchého zapojení do informačních sítí.

Software PA se postupně také konsoliduje, i když poněkud váhavěji.

Všechny používané programovací metody se sešly v normě, která nese označení IEC 61131 část 3 (stručně 61131-3). Implementovat všechny metody zahrnuté v této normě na svých PA se v současnosti snaží již všichni významní výrobci. Stále se sice lze setkat s množstvím odchylek a nepříjemných omezení, nicméně situace se soustavně zlepšuje. Zatímco v roce 1990 nabízel na našem trhu metodu GRAFCET jen jediný dodavatel (PEP Modular Computers), dnes ji, alespoň formálně, nabízejí všichni.

6.2 Projektování automatizace s PA
Uživatelé a projektanti aplikací PA jsou, ve srovnání s více než třicetiletým vývojem PA, teprve krátké, nejvýše pětileté období, postaveni před volbu, jak s PA efektivně pracovat. V oblasti hardwaru to není problém příliš složitý. Spolehlivý, v jistých mezích výkonný technický prostředek jim dnes nabídne každý z výrobců.

Prvním důležitým okruhem otázek, které musejí řešit, je to, co lze shrnout pod název metodika projektování. Až dosud jsou PA jako počítačové systémy předkládány jako nástroje pro realizaci algoritmu zapsaného ve formě daného programového modulu nebo soustavy modulů. Shromáždění požadavků, jejich analýza, systémový návrh, ze kterého teprve vzejdou jednoznačně definované moduly, jsou ponechány na libovůli projektantů a metodě „dělej jak umíš“. To však není vada způsobená samými PA. Zde působily jen nepřímo tím, že byly předkládány jako komplexní nástroje pro řešení projektů. Zmíněné úvodní etapy projektu však byly jen nahrazovány generováním dokumentace programu PA v celkem primitivní formě.

V současné době již je mnohým projektantům jasné, že v každém projektu by vlastní práci s PA měly předcházet i etapy analýzy a návrhu, dnes již dostatečně zpřístupněné popisem metod v literatuře i účinnou počítačovou podporou (softwarové nástroje, systémy CASE – Computer Aided System Engineering).

K PA je tedy nakonec přistupováno s definovanou soustavou programových modulů, které se implementují na daném PA. Otázka, kterou z metod (programovacích jazyků) předkládaných normou IEC 61131-3 použít, je složitá jen zdánlivě. Předem je třeba si uvědomit, že norma si neklade za cíl vybrat a pevně v praxi zakotvit to nejdokonalejší a nejlepší. Různé vlivy způsobí, že se v normě objeví vše, co je v dané době rozšířeno a výrobci náležitě podporovano bez ohledu na to, zda jde o záležitost novou a nadějnou a nebo o zanikající relikt dob minulých. Naštěstí v současnosti nejsou normy závazné, ale mají sloužit sjednocení terminologie a informování jejich uživatelů. To by si měli uvědomit zejména starší projektanti, kteří mají v krvi nedotknutelnost normy a chápou ji jako zákon.

6.3. Současné programování PA

6.3.1 Norma IEC 61131-3
Mezinárodní norma IEC 61131-3 nabízí celkem pět metod – jazyků pro programování PA. Téměř všechny již byly v předchozím výkladu zmíněny. V dalších podkapitolách budou stručně charakterizovány a bude vymezeno jejich postavení v současných aplikacích PA. Uvedeny jsou v chronologickém pořadí vývoje, a to pod doporučenými českými i nyní platnými anglickými názvy.

6.3.2 Kontaktní schémata (Ladder Diagram – LD)
Metoda LD je označení pro klasická liniová nebo také kontaktní schémata. Jejich výhodou bylo, že tuto techniku ovládali všichni elektroprojektanti navrhující reléové ovládací obvody. To byla hlavní a asi jediná přednost této metody. Liniové schéma je ekvivalentní soustavě logických rovnic, přesněji řečeno sekvenci přiřazovacích příkazů přiřazujících logickým proměnným hodnoty definované logickým výrazem na pravé straně tohoto příkazu. U této jednoduché formy zápisu musí automat soustavně vyhodnocovat všechny příkazy. I ty, které v dané chvíli vyhodnocovány být nemusí. Tato potíž může být odstraněna, umožní-li se v sekvenci příkazů skoky, které však jsou plně v režii tvůrce algoritmu. Z toho plynoucí možnost vzniku chyb je nasnadě. Implementace této metody bývá různě modernizována, princip ovšem zůstává.

Metoda LD je zjevně zastaralá a lze jen těžko, mimo setrvačnost a neinformovanost uživatelů, nalézt vážný důvod pro její další přežívání.

6.3.3 Funkční bloky (Function Blocks – FB)
Metoda funkčních bloků má stejný původ jako metoda LD, jen předpokládá projektanty „postreléové“ generace znalé projektování ovládacích schémat z integrovaných prvků realizujících základní logické funkce. Hodnocení významu je shodné jako u metody LD, jen jednotlivé bloky mohou pracovat s menším počtem proměnných.

6.3.4 Seznam příkazů (Instruction List – IL)
Metoda IL je návratem do dávné minulosti. Byla užívána u nejprimitivnějších automatů. Z úsporných důvodů byla používána i v nedávné době u jednodušších systémů. Jedná se v podstatě o jazyk symbolických adres, tzv. assembler. Používání tohoto jazyka může být zdůvodněno jen zvláštními okolnostmi dané aplikace.

6.3.5 Strukturovaný text (Structured Text – ST)
Metoda ST je první z metod, které vyhovují požadavkům doby. Jedná se o jednoduchý programovací jazyk typu autokódu, tzn. – řečeno novější terminologií – jde o jazyk „basicovského“ typu. Podobných jazyků je dnes velmi mnoho. Patří sem Visual Basic, všechny tzv. skriptové jazyky, kterými jsou vybaveny mnohé současné programové systémy a které slouží k uživatelskému přizpůsobování jejich funkcí. Příkladem je tvorba dokumentace v systémech třídy CASE. Jazyky si jsou navzájem velmi podobné a jsou velmi jednoduché. Lze se je snadno naučit a jejich používání nevyžaduje dlouhodobou soustavnou praxi. Strukturovaný text by neměl být chápan jako samostatný programovací prostředek. Jeho význam je nutné posuzovat v souvislosti s následující metodou SFC.

6.3.6 Sekvenční funkční graf (Sequential Function Chart – SFC)
Metoda SFC je vlastně pouze přejmenovanou metodou GRAFCET. Odchylky jsou nepodstatné. Metoda sama o sobě může být použita jen k hrubší analýze nebo k hrubému návrhu algoritmů. Funkční náplň jednotlivých kroků v tom případě reprezentuje popis v podobě poznámek přiřazených ke graficky znázorněným krokům. Plnohodnotná metoda vznikne, až když je možné zapsat algoritmickou náplň jednotlivých kroků v nějakém programovacím jazyce. U metody GRAFCET to byl jazyk GPL (GRAFCET Programming Language). Jeho rovnocennou náhradou je strukturovaný text. Norma IEC 1131-3 předpokládá, že pro zápis algoritmů lze použít kterýkoliv z ostatních jazyků. Případy, kdy k tomu bude rozumný důvod, již byly uvedeny. Při zavádění metod programování PA není důvod volit jinak než kombinaci SFC a ST, i když se vlastně jedná o metodu jednu.

6.3.7 Další metody
Na závěr kapitoly o metodách programování PA se dotkněme některých kuriozit v podobě dalších metod, se kterými se lze u některých systémů setkat.

Jedním z příkladů jsou vývojové diagramy. Zde jsou míněny skutečně klasické vývojové diagramy, zaváděné v programátorské praxi již od 50. let. Je samozřejmé, že libovolný algoritmus lze zapsat v libovolném programovacím jazyce, pokud tento jazyk disponuje úplným souborem instrukcí, což platí pro převážnou většinu programovacích jazyků. Lze tedy také použit klasický vývojový diagram. Proč však? Snad jen proto, že se programátor nechce nic nového naučit. Vývojový diagram nepodporuje zásady strukturovaného programování, ovšem stejně jako SFC. A ještě jedna související poznámka. Mezi projektanty se metoda SFC občas nazývá také vývojový diagram. Tím se ovšem nevhodným termínem zastírá jeho podstata, nehledě na to, že tento termín je již půl století vyhrazen něčemu jinému.

Ve spojení s metodou SFC se také někdy mluví o její souvislosti se stavovým diagramem. V objektově orientované metodice UML (Unified Modelling Language) se oba přístupy dokonce směšují. Jedná se o hluboké neporozumění, jak vyplývá z předchozího výkladu.

7. Budoucnost PA

PA zřejmě mají i nadále zajištěnou budoucnost. Možnost distribuce funkcí na samostatné počítačové jednotky, vyplývající především z nízké ceny počítačů, poskytne i dále prostor pro specializované počítače. Jejich specializace však bude spočívat především v softwaru. Distribuované řešení přitom předpokládá, že budou k dispozici kvalitní, spolehlivé a rychlé způsoby komunikace. I v tomto směru je současná situace dosti uspokojivá. Tím se ovšem nelze zbavit potíží vyplývajících ze složitosti řešených úloh. Do jisté míry specifickým produktem se svými specifickými problémy tedy budou PA i v budoucnosti. Nebudou však ani tak problémem samy o sobě, problémem bude jejich začlenění do širšího celku a souvislostí. To bude vyžadovat, aby PA byly vždy chápány jako neoddělitelná část celku, a tedy část, kterou nelze vyjmout ze souhrnného automatizačního projektu.

Příspěvek vznikl v rámci řešení výzkumného záměru Fakulty aplikovaných věd Západočeské univerzity v Plzni č. MSM 235200004.

doc. Ing. Jiří Cendelín, CSc.,
Západočeská univerzita v Plzni
(cendelin@kky.zcu.cz)