Odprta koda v avtomatizaciji I.
Odprta koda, protokoli in standardi v avtomatizaciji I. del
Kar se je začelo nekoč davno z Richardom Stallmanom in kolegi ter nadaljevalo pot do Linusa Torvaldsa in njegovega Linux kernela, je neizogibno moralo najti svojo pot preko potrošnih izdelkov tudi v same proizvodne procese in hale.
Saj ne, da odprte kode tu ni bilo že prej, a tokrat gre za veliko več. V večnem ciklu optimizacije obstoječih poti in tehnik je na poti Industry 4.0 enostavno vse manj podlage za zaprte rešitve. V okolju in pogojih, kjer mora vsaka rešitev upravičiti svoj obstoj, je tako danes tudi z zaprtimi podatki, formati, protokoli in tudi kodo. Pri vseh gre za postavljanje omejitev, ki vedno zahtevajo določene napore, čas in na koncu tudi denar na tak ali drugačen način in na koncu mora za te omejitve obstajati racionalen razlog, ki ga je danes vse težje in redkeje najti. Ponavadi je to patentirana ali vsaj zaprta rešitev, ki je bistveno bolj napredna v nekem ključnem pogledu glede na odprte verzije, a to je danes, kot že rečeno, čedalje redkeje. Med drugim tudi zato, ker javni interes nagrajuje odprtost, kar pomeni več sredstev za razvoj in s tem hitrejši napredek.
Operacijski sistemi
Tu je razlogov za odprtost mogoče več kot kje drugje. V okolju, kjer je vsaka vrstica kode lahko bistvena in kjer je vse intimno povezano z vsem drugim, je možnost vpogleda v kodo lahko še toliko bolj pomembna. Prej je bil mogoče glavni razlog za prisotnost Linuxa prvotno kje drugje, denimo manj problemov s prenosom in zagotovitvijo licenc glede na zaprto kodno programje.
Danes bi na prvo mesto postavil predvsem varnostno tematiko. Nadaljnji razlog bi bil ob vpogledu v kodo tudi možnost njene spremembe za doseganje danega namena. Ni potrebno tako veliko dela, da na Linux jedru recimo, spremenite obnašanje task schedulerja in nastavite njegov način dodelitve prioritete procesov ali recimo I/O scheduler ali kaj petega. Ali recimo prilagodite kernel svojemu novemu računalniku. To bi bilo brez odprte kode praktično nemogoče.
Res je, da je ravno OS jedro prostor, kjer se da z optimizacijami za določen namen doseči marsikaj, a videti je, da se trg ne ozira kaj dosti na to in da ceni standardizacijo bolj kot pa vidi neke posebne priložnosti v mnogo zaprto kodnih, specializiranih pristopih.
Tako se celoten razvoj giblje počasi v to smer. Čedalje pogostejši so mikrokrmilniki, ki so sposobni udobno poganjati Linux kernel, ponavadi ob potrebni zaščiti pomnilnika (MMU), trg pa je pogosto pripravljen pogoltniti dodatek pri ceni silicija, če to lahko prihrani pri razvoju programskih rešitev.
S tem, da seveda Linux še zdaleč ni edina rešitev. Je na voljo veliko specializiranih odprtokodnih rešitev in ni nujno da je to ravno Linux ali xBSD.
Odprta programska okolja
Tudi tu se krepko pozna prodor odprte kode, ki je s seboj potegnila mnogo programskih jezikov in standardov iz svojih voda, različnih spletnih platform in ne pozabimo ne nazadnje stari dobri IEC-61131, ki je od prvotne izdaje leta 93 doživel svojo tretjo izdajo leta 2013. Sicer pa izbire ne manjka. Python že dolgo velja za standardno odprto izbiro, C++ ima zadnje čase vsako leto ali dve novo reinkarnacijo, pojavljajo se celo rešitve kot je Rust ipd.
Slika1: Robotinin Cybro PLC, ki je eden od prvih znanilcev ustrezne podpore IEC61131 pri nas
Tipičen primer odpro kodnih programskih okolij bi bil denimo Robotinin CybRo program PLCjev, ki ponuja IEC-61131 od samih začetkov. Novejši primer je Opto-22-ov Groov EPIC, ki ravno tako ponuja IEC-61131, preko secure shella pa tudi druge opcije.
Prednosti je tu lahko mnogo. Med drugim denimo ta, da lahko razvoj danega programskega jezika prepustimo drugim in sami poskrbimo samo za ustrezno implementacijo potrebno knjižničnih modulov. Tako lahko nenazadnje prihranimo pri najemu programerja, saj ga lahko izbiramo pri platformi, kjer je izbira največja.
Slika 2: Groov EPIC serija
Slika 3: Različne možnosti upravljanja z EPIC-om
