Automat sa konačnim brojem stanja - Ubrizgavanje ponašanja u sistem

Ubrizgavanje ponašanja u sistem – II

Uvod

U prošlom broju magazina upoznali smo se sa idejom/metodom ubrizgavanja ponašanja u sistem (Injection System Behavior) konačnog automata sistema i definisali tri osnovne komponente od kojih je sačinjen: generički konačni automat, definicija stanja i tranziciona matrica. U ovom broju nastavljamo dalje sa temom pri čemu ćemo se upoznati sa različitim aspektima primene, principima, portabilnošću koda i praktičnim problemima prilikom implementacije.

Principi i koncepti

Programabilna autonomna vozila (u nastavku teskta PAV) jesu jedna oblast primene, međutim metod se može iskoristiti u različite svrhe. Vratimo se prvo na visok nivo arhitekture PAV, razlog tome biće jasan uskoro. PAV je sačinjen od: upravljačke jedinice (u našem slučaju 8051 mikrokontroler, mada generalno to može biti bilo koji digitalni računar), pojačavača snage (device driver), aktuatora (DC motori u našem slučaju) i seta senzora koji čine povratnu spregu nazad ka upravljačkoj jedinici (InfoElektronika broj 110 – infrastruktura PAV).

Pitanje: da li ste ikada razmišljali o štampaču i načinu na koji funkcioniše, o njegovo internoj elektronici? ... Štampač je u osnovi robot i spada u domen upravljanja motorima. Generalno gledano, štampači poseduju više različitih tipova motora. Jedan je zadužen za pozicioniranje glave štampača uz bidirekciono kretanje što znači da poseduje H-Bridge kolo ili recimo ULN 2xxx seriju IC-a koje sekvencom signala upravlja motorom pomerajući glavu štampača. Drugi set motora služi za pozicioniranje papira pri čemu se koriste različiti setovi senzora za identifikaciju pozicije, dosupnosti papira itd. Kao što vidite sličnosti su velike. Recimo, Rohm 574 senzor o kome je pisano u magazinu InfoElektronika broj 111 je upravo iskorišćen iz jednog starog štampača. U slučaju štampača konačan automat (u nastavku teksta KA) možemo iskoristiti za implementaciju niskog nivoa upravljačkog software-a. Pogledajmo sada još nekoliko primera.

Izostavimo konkretnu implementaciju PAV i pozabavimo se funkcionalnim aspektima. Već znamo da PAV imaju mogućnost kretanja unapred, unazad (uz reguliaciju brzine), kočenja odnosno zaustavljanja (stop) itd. Video rekorder (u nastavku teksta VCR) sa funkcionalnog aspekta ima: premotavanje kasete unazad, unapred, play, pauza i stop. Da li Vam ovo već liči na to da su PAV i VCR u osnovi slični? ... Naravno, jer VCR takođe poseduje H-Bridge kolo koje upravo služi za pomenuto premotavanje kasete uz mogućnost regulisanja brzine, BA6222 IC. Jednostavno rečeno, VCR uređaj jednim delom spada u domen upravljanja motorima jer poseduje motor, ali i elektroniku za obradu slike videa sa time što nam ista u ovom slučaju nije interesantna.

Uzmimo još jedan primer. Svi smo bili u mega-marketima i gotovo svi na ulazu/izlazu imaju automatska vrata. Stvari su jednostavne, priđemo vratima, pasivni infra crveni senzor detektuje naše kretanje, okine događaj koji mikrokontroler detektuje pomoću interrupt jedinice, startuje H-Bridge, vrata se otvore a zatim se nakon predefinisanog vremena zatvore. Sve navedeno je upravo identično PAV u smislu elektronike.

Postavimo sada novo pitanje: da li su štampač, VCR i automatizovana vrata roboti? To je stvar definicije i ničeg više. Štampač, VCR, automatska vrata i PAV su konceptualno identični uređaji u smislu sličnosti elektronike upravljanja motorima. Ono što je jasno jeste da se pomenuti uređaji mogu modelovati KA, uključujući i motor. Da li ima smisla, svaki od pomenutih uređaja modelovati KA, je odgovor na koji ćemo doći kroz tekst koji sledi.

Portabilnost

U trenutku kada započnemo praktičnu realizaciju nekog uređaja, dobra je praksa realizovati ga tako da se komponente mogu ponovo iskoristiti. Dva ključna razloga za to jesu: vreme i testiranje. Ako uređaj stabilno radi to znači da je dobro testiran i da smo za isto potrošili vreme, zato ga treba ponovo koristiti. Istu stvar primenimo i na KA. Kako napisati KA a da isti možemo koristiti na više različitih platformi: Intel 8051, PIC, ARM, x86 itd.? Jasno je svima da je teško napisati 100% portabilan programski kod, ali postoje metode koje portabilnost čine jednostavnijim zadatkom. Odgovor na ovo pitanje leži u standardima i kompajlerima. Takođe možete pogledati tekst iz InfoElektornike broj 110 – Portabilnost platformi za 32bitne mikrokontrolere.

Proizvođači kompajlera svoje proizvode potpisuju u osnovi sa tri stvari, te sledi nekoliko primera. C kompajler proizvođača X je: ANSI C kompajler, sa ekstenzijama za Intel 8051 mikroarhitekturu, platforma Intel 8051 standard. C kompajler proizvođača Y je: ANSI C kompajler, sa ekstenzijama za PIC mikroarhitekturu, platforma PIC Microchip. C kompajler proizvođača Z je: ANSI C kompajler, sa ekstenzijama za x86 mikroarhitekturu, platforma Intel x86. Ono što možemo primetiti iz navedenih primera jesu standardi. Svi pomenuti kompajleri jesu ANSI C standard. I sada dolazimo do suštine. Do portabilnosti dolazimo na taj način što programski kod pišemo ANCI C standardnom i nikako drugačije. To je tačno, ali, obrađene podatke u određenom vremenu je potrebno setovati na izlazne portove mikrokontrolera. Periferije mikrokontrolera spadaju u ono što zovemo ekstenzijama, i takve stvari nisu portabilne jer svaka platforma nosi sa sobom neku specifičnost. Pravilo je jednostavno: suštinu problema pišemo/rešavamo ANSI C standardom na takav način da se u potpunosti izoluje kao celina. To se postiže kreiranjem zasebnih fajlova (.c i .h) i definisanjem interfejsa putem kojih izvršavamo one delove programskog koda koji nisu portabilni.

Dodatna stavka, ANSI C kompajleri sa sobom nose biblioteke jer su deo standarda. Međutim, biblioteke nisu portabilne jer su pisane prema specifičnostima mikroarhitekture/seta instrukcija. Onog trenutka kada je potrebno koristiti metod iz određene biblioteke, isti se mora izdvojiti u zaseban fajl kako bi programski kod postao portabilniji.

Samim tim, razvoj programskog koda nije direktno vezan za razvojna okruženja embedded sistema. Recimo, programski kod KA pisan ANSI C standardom u razvojnom okruženju MikroElektronike testirao sam Microsoft Visual C++ kompajlerom iz razloga što je isti i ANSI C kompajler za x86 platformu.

Definisanje stanja

Svako stanje sistema mora biti implementirano na takav način da generički KA “zna” da ga izvrši. U praksi takve stvari se realizuju definisanjem interfejsa. Interfejs je skup metoda i svojstava koje stanje implementira jer se isti koristi i za implementaciju generičkog KA. Definisanje interfejsa je prvi korak u realizaciji. Kako svrha ovog teksta nije objašnjavanje svake metode interfejsa (jer za isto nemamo ni prostora), pozabavićemo se jednom suštinskom metodom. Interfejs definiše podrazumevani metod pod nazivom DefaultMethod. Kako generički KA koristi interfejs, svako stanje sistema mora implementirati podrazumevanu metodu.

Uzmimo za primer stanje kretanje unapred PAV. Ovo stanje implementira metod DefaultMethod. Odgovornost metode je upravljanje H-Bridge-om shodno pravilima kretanja unapred. Onog trenutka kada je to urađeno metod je završen, pri čemu PAV i dalje ostaje u stanju kretanja unapred, a samim tim i KA. Uzmimo sada primer stanja kretanja unazad. Ovo stanje takođe implementira DefaultMethod, pri čemu je odgovornost iste upravljanje H-Bridge-om shodno pravilima kretanja unazad. Onog trenutka kada je to urađeno metod je završen, pri čemu PAV i dalje ostaje u stanju kretanja unazad, a samim tim i KA. Ista stvar je i sa kočenjem, odnosno zaustavljanjem vozila. Evo celokupne slike. PAV se nalazi u stanju mirovanja, samim tim i generički KA se nalazi u stanju mirovanja. Desio se događaj, KA iz stanja mirovanja prelazi u stanje kretanja unapred, to automatski znači da isti startuje izvršavanje DefaultMethod-e stanja u koje je prešao. Šta DefaultMethod zaista radi to nije odgovornost KA, jedina odgovornost istog jeste da startuje njeno izvršenje - u ovom slučaju H-Bridge se setuje shodno pravilima kretanja unapred.

Na koji način KA izračunava naredno stanje sistema, je odgovornost tranzicione matrice.

Slika1. Tablični prikaz konačnog automata – tranziciona matrica

Tranziciona matrica

U prethodnim brojevima magazina, KA je predstavljan isključivo na jedan način, grafički. Pri tome smo koristili kružnice za predstavljanje stanja i strelice za predstavljanje tranzicija. Postoji još jedan način definisanja KA i namerno smo ga čuvali za ovaj tekst, kako bi stvari postale jasne. Radi se o tabelarnom/matričnom definisanju KA što upravo čini tranzicionu matricu (u nastavku teksta TM). Kolone tabele/matrice su stanja dok su redovi tabele/matrice događaji koji utiču na prelaz. Na slici 1. prikazano je mapiranje između dva različita načina definisanja KA. KA sa slike 1.a. je mapiran na tabelu/matricu sa slike 1.b. KA sa slike 1.c. je mapiran na tabelu/matricu sa slike 1.d. Kao što možete zapaziti tabelarni/matrični prikaz nosi sa sobom sve informacije ponašanja KA i ne samo to, one su potpuno različite u prelazima za identičan set stanja i događaja, slike 1.b i 1.d. - čime smo dobili podlogu za razvoj metode ubrizgavanja ponašanja u KA sistema!

Postoje tri tipa tranzicije između stanja: direktna, uslovna i eksterna. Direktna tranzicija navodi generički KA da nakon izvršenja podrazumevane metode – DefaultMethod, automatski pređe u naredno stanje KA sistema. Uslovna tranzicija navodi generički KA da nakon izvršenja podrazumevane metode proveri predhodno izvršeno stanje te ukoliko je uslov ispunjen automatski pređe u naredno stanje. Eksterna tranzicija spada u domen eksternih događaja. Svaki od navedenih prelaza je podoban za rešavanje različitih problema. Recimo, direktne tranzicije su podobne za generisanje PWM i kontrolnih signala. Sa druge strane eksterne tranzicije nam omogućavaju da upravljamo sistemom u zavisnosti od događaja prikupljenih senzorima.

Postavimo sada niz pitanja. Koji tip tranzicije ima najveći prioritet? Da li je to direktna, uslovna ili eksterna tranzicija? Odgovora nema, jer zavisi od problema koji rešavamo, ali ono što možemo uraditi jeste omogućiti da se prioriteti tranzicija konfigurišu. Logično je da eksterne tranzicije imaju veći prioritet od ostalih u slučaju PAV jer vozila menjaju svoj položaj u prostoru te terba obezbediti brzo reagovanje na spoljne faktore. Ali, taj slučaj ne možemo preneti na ostale slučajeve, te mogućnost konfigurisanja prioriteta tranzicija predstavlja adekvatno rešenje problema.

Postoji više načina za praktičnu realizaciju TM. U ovom slučaju korišćen je niz bajtova (stream) koji omogućava lako ubrizgavanje istog u KA sistema odnosno u RAM memoriju mikrokontrolera. Dimenziju niza odnosno broj bajtova određujemo tako što pomnožimo broj kolona i redova. Međutim, iz priloženog programskog koda (link sa sajta InfoElektronike) možete videti da TM nije jedino što ubrizgavamo u sistem. Pored TM ubrizgavamo i informaciju o početnom stanju KA sistema. Shodno tome niz bajtova je proširen za jedan.

TM može predstavljati veliki problem jer je “gladna memorije”. Što više stanja i događaja definišemo to je više memorije potrebno za skladištenje iste. Shodno tome postoje određene metode optimizacije zasnovane na mod aritmetici koje omogućavaju da jedan bajt iskoristimo za definisanje više stanja/događaja. Način izračunavanja takođe možete naći u priloženom programskom kodu.

Slika2. Stepper motor modelovan konačnim automatom

Kodiranje stanja i tipova tranzicija

Kao što smo već napomenuli u primeru TM problem nedostatka memorije može postati veliki, pogotovo u slučaju malih memorijskih modela, pri čemu TM može zauzeti i do 80% memorije ostavljajući malo prostora za ostale stvari - čuvanje koda stanja/tipa tranzicije. Ovakav problem rešavamo na taj način što kod stanja/događaja ustvari predstavlja poziciju/indeks TM. Na taj način dodatni memorijski prostor za čuvanje koda stanja/događaja nije potreban.

Za kodiranje eksternih tranzicija odnosno događaja koristimo prioritetan enkoder (u nastavku teksta PE) – CD4532 IC. Na ulaz PE spežemo tastere simulirajući pritiskom na iste različite eksterne događaje. U konkretnim implementacijama, na ulaz PE dovodimo signale sa različitih tipova senzora - za potrebe testiranja i izrade prototipa tasteri su dovoljno dobri. Za PE odlučio sam se iz razloga što isti daje mogućnost prioritetizovanja eksternih događaja. Na neke eksterne događaje je potrebno reagovati pre nego na ostale, te PE predstavlja adekvatan izbor.

Stepper motor modelovan konačnim automatom

Pre nego što se upustimo u modelovanje stepper motora KA, potrebno je osvrnuti se na funkcionalne aspekte istog. Kako je za cilj da metod ubrizgavanja učinimo razumljivim vodićemo se jednostavnim primerima. Već smo pisali o unipolarnim stepper motorima, InfoElektronika broj 110, ali ponovimo osnovno. Stepper motori su prepoznatljivi po većem broju izvoda od kojih je jedan zajednički (common - primer: vezujemo ga na +12V) i više kontrolnih izvoda koji služe za kontrolisanu rotaciju u jedno od dva moguća smera. Rotiranje se odvija u koracima, pri čemu je minimalan stepen rotacije deklarisan od strane proizvođača. Generisanjem sekvence signala u vremenu generišemo i sekvencu diskretnih koraka koje čine rotaciju motora. Unošenjem vremenske zadrške između generisanih signala unosimo i vremensku zadršku između koraka, čime regulišemo brzinu rotacije motora.

Analizom funkcionalnih aspekata stepper motora sledi niz zaključaka u cilju definisanja stanja KA. Zaključak: kako se rotacija odvija koračno u dva moguća smera, sledi da su dva rotaciona stanja potrebna: korak u smeru kazaljke na satu (Step CW) i korak obrnut od smera kazaljke na satu (Step CCW). Zaključak: vremenska zadrška između koraka uvodi dodatno stanje – timer. Poslednje stanje je stanje čekanja (idle) – u ovom stanju KA čeka eksterni događaj. Poslednje stanje se prosto nameće samo po sebi, jer onoga trenutka kada se inicijalizuje, KA čeka eksterne događaje – primer: automati za kafu, jer su isti takođe KA. Kao što vidimo, imam ukupno četiri stanja na osnovu kojih možemo opisati ponašanje stepper motora na različite načine:

1. Step CW – jedan korak rotacije u smeru kazaljke na satu.
2. Step CCW – jedan korak rotacije u obrnutom smeru kazaljke na satu.

3. Timer – vremenska pauza između koraka

4. Idle – stanje čekanja eksternih događaja, početno stanje

Nakon definisanja stanja, sledi korak definisanja različitih zadataka/ponašanja stepper motora. Slika 2.a prikazuje polaznu tačku. Kao što vidite, prikazana su isključivo stanja, tranzicija nema. Prvo ponašanje: na eksterni događaj iz stanja čekanja pređi u stanje neprekidnog rotiranja u smeru kazaljke na satu, slika 2.b. Drugo ponašanje: isto što i prvo uz dodatnu mogućnost regulisanja brzine na zadate eksterne događaje, slika 2.c. Treće ponašanje: isto što i drugo uz dodatnu mogućnost regulacije smera rotacije na zadate eksterne događaje, slika 2.d. Kao što vidimo sa slike 2.b, prvo ponašanje definiše tranziciju između tri stanja KA: Step CW, Timer i Idle. To je upravo ono o čemu smo pisali u InfoElektronici broj 112 – sva gore pomenuta stanja, ukupno četiri, čine skup S – skup svih mogućih stanja sistema, ali samo tri su potrebna za realizaciju prvog ponašanja (skup zadatka Sz). Drugo ponašanje takođe eliminiše Step CCW, slika 2.c, pri čemu se isto uvodi tek u trećem ponašanju jer zahtevamo i rotaciju u suprotnom smeru, slika 2.d. Obratimo pažnju da prvo ponašanje koristi jednu eksternu tranziciju a da zatim sledi niz beskonačnih direktnih tranzicija između dva stanja Step CW i Timer, čineći KA automatom sa beskonačno mnogo prelaza između stanja – InfoElektronika broj 112. Drugo i treće ponašanje unose dodatne eksterne tranzicije radi regulisanja brzine i promene smera okretanja respektivno.

Nakod definisanja tranzicija između stanja naredni korak je mapiranje dijagrama stanja u TM pravilom prikazanim na slici 1. Sledeći korak je implementacija stanja pri čemu svako implementira interfejs koji definiše podrazumevani metod – DefaultMethod. Iz priloženog programskog koda, obratite pažnu da između stanja Step CW i Step CCW postoji dosta sličnosti uz razliku smera pomeranja bitova shift bitwise operatorom programskog jezika ANSI C. Poslednji korak je pakovanje TM u zasebne fajlove sa ekstenzijom bin. U ovom slučaju postoji ukupno tri bin fajla. Prvi bin fajl sadrži TM prvog ponašanja, drugi TM drugog ponašanja i treći TM trećeg ponašanja. Fajlove sa ekstenzijom bin ubrizgavamo u KA sistema, odnosno u RAM memoriju mikrokontrolera putem RS232 komunikacije – način ubrizgavanja je vaš izbor.

Zaključak

Svaki metod nosi sa sobom prednosti i mane, te shodno tome i metod ubrizgavanja ponašanja u sistem KA. Uvek postoji čuvena izreka, “što dobiješ na mostu izgubićeš na ćupriji”. Ubrizgavanjem eliminišemo reprogramiranje što smanjuje vreme modifikacije ponašanja sistema. Sa druge strane nepotrebna stanja nepotrebno zauzimaju memoriju te gubimo dragocene resurse. Na početku teksta navedeno je nekoliko primera sistema koje je moguće modelovati KA. Međutim, da li ima smisla koristiti generički KA za automatska vrata mega-marketa? Po mom mišljenju ne, jer to je sistem koji trpi malo izmena nakon što je napravljen. Sa druge strane, metod je podoban za PAV. Zašto? Onog trenutka kada praktično realizujete PAV sigurno ćete imati želju da uradite što je moguće više različitih stvari sa istim. U tom slučaju metod ubrizgavanja se čini odličnim izborom jer omogućava brzu promenu ponašanja robota. Jedino što preostaje jeste da opišete ono što od PAV i očekujete da uradi.

Kompletan programski kod generičkog konačnog automata možete preuzeti sa sajta magazina InfoElektronike. Priloženi programski kod uključuje i testiranje generičkog KA u razvojnom okruženju MS Visual C++ za x86 platformu. Napomena: nazivi stanja nisu 1:1 sa nazivima stanja u priloženom programskom kodu. Kako sve to izgleda u praksi pogledajte kroz priložene youtube video linkove.

Autor: Vladimir Savić

Tekst je objavljen u InfoElektronika magazinu broj 15

Napomena: tekst će biti preveden na engleski jezik by Nera Marković.

Prvi deo o Ubrigavanju ponašanja u sistem.

YouTube linkovi:http://www.youtube.com/watch?v=4ZGx8zq_t6k&feature=player_embedded

http://www.youtube.com/watch?v=Ei9KdeeKOBI&feature=player_embedded

http://www.youtube.com/watch?v=UL981FDDahA&feature=player_embedded