microsoft word - master rad dejan rozgic

UNIVERZITET U BEOGRADU

Elektrotehnički fakultet

Katedra za elektroniku

MASTER RAD

KONCEPT IMPLEMENTACIJE FUNKCIJA SERVISNOG MODULA

PAMETNOG PRETVARAČA NA STRANI MREŽNOG PROCESORA

Autor: Mentor:

dipl. ing. Dejan Rozgić docent Dr. Ivan Popović

U Beogradu,

decembar 2010. godine

„ Implementacija funkcija servisnog modula pametnog pretvarača“

Dejan Rozgić – Master rad

Elektrotehnički fakultet, Beograd – Katedra za elektroniku 2

KONCEPT IMPLEMENTACIJE FUNKCIJA SERVISNOG MODULA PAMETNOG PRETVARAČA NA STRANI MREŽNOG

MODULA

Sažetak – Interoperabilnost je mogućnost da dva ili više heterogena sistema razmenjuju informacije i da te podatke koriste na propisani način. Zbog sve veće upotrebe mernih pretvarača (senzori i aktuatori), javila se potreba da se omogući interoperabilnost istih. Ovaj rad će se baviti standardizovanim interfejsima koji su projektovani od strane IEEE (Institute of Electrical and

Electronic Engineers) i kojima se došlo do željene karakteristike mernih pretvarača, a to je interoperabilnost. Biće opisan razvijeni set standarda IEEE 1451 za merne pretvarače. Ovim standardom je pokriven celokupan interfejs i komunikacija između mernog pretvarača i krajnjeg korisnika, koja se može ostvariti mnogim vidovima umrežavanja. Informacije kojma raspolaže jedan merni pretvarač mogu biti korisne za veliki broj korisnika ali i informacije sa više pretvarača mogu trebati samo jednom korisniku. Ovaj rad se bavi softverskom implementacijom ovog mehanizma. Naime, cilj master rada jeste upravo realizacija funkcija koje se koriste sa strane korisnika kod heterogenih platformi radi očitavanja podataka sa mernih pretvrača.

THE CONCEPT OF IMPLEMENTING A SERVICE FUNCTION MODULE FOR SMART TRANSDUCER ON THE SIDE OF THE

NETWORK PROCESSOR

Abstract – Interoperability is the possibility that two or more heterogeneuos systems

exchange information and that information use in the prescribed manner. Due to the increasing

use of transducers (sensors and actuators), there was a need to facilitate the interoperability of

the same. This paper will deal with standardized interfaces that are designed by IEEE (Institute

of Electrical and Electronics Engineers) and using that reach the desired characteristics of the

transducers, which is interoperability. It will be decsribed a set of standards developed for the

IEEE 1451 transducers. This standards covered by entire interface and communication between

the transducer the last user, which can be made by many different aspects of networking.

Information which has a measuring transducer can be useful for many users and information

from multiple transducers may need only one user. This paper deals with software

implementation of this mechanism. The goal of the master paper is just the realization of function

that are used with user across heterogeneous platforms for reading data from the measurement

transducer.




Sadržaj:

1 UVOD ................................................................................................................................................. 5

2 PAMETNI MERNI PRETVARAČ (SMART TRANSDUCER) .................................................... 6

3 IEEE 1451 STANDARD ................................................................................................................... 8

3.1 IEEE 1451 PAMETNI MERNI PRETVARAČ .......................................................................................... 9 3.2 Arhtektura IEEE 1451 FAMILIJE STANDARDA................................................................................ 10 3.3 Elementi IEEE 1451 FAMILIJE STANDARDA .................................................................................. 11

3.3.1 IEEE 1451.0 .......................................................................................................................... 11

3.3.2 IEEE 1451.1 .......................................................................................................................... 12 3.3.3 IEEE 1451.2 .......................................................................................................................... 13 3.3.4 IEEE 1451.3 .......................................................................................................................... 13 3.3.5 IEEE 1451.4 .......................................................................................................................... 14 3.3.6 IEEE 1451.5 .......................................................................................................................... 14

3.3.7 IEEE 1451.6 .......................................................................................................................... 16 3.3.8 IEEE 1451.7 .......................................................................................................................... 16

3.4 TEDS (TRANSDUCER ELECTRONIC DATA SHEETS) ............................................................. 17 3.5 NCAP (NETWORK CAPABLE APPLICATION PROCESSOR) .............................................. 18

4 KOMANDE ..................................................................................................................................... 19

4.1 STANDARDNE KOMANDE ................................................................................................................ 19 4.1.1 Komande zajedničke za TIM i TransducerChannel ............................................................ 20

4.1.2 Transducer idle state komande ............................................................................................ 26

4.1.3 Transducer operating state komande .................................................................................. 32

4.1.4 Transducer either idle or operating state komande ............................................................ 35

4.1.5 TIM sleep state komande ..................................................................................................... 39

4.2 TIM ACTIVE STATE KOMANDE ......................................................................................................... 39 4.3 TIM ANY STATE KOMANDE ............................................................................................................. 41 4.4 RUČNO DEFINISANE KOMANDE ...................................................................................................... 42

5 STRUKTURA PORUKA ............................................................................................................... 42

5.1 REDOSLED SLANJA PODATAKA I ZNAČENJE BITOVA ....................................................................... 42 5.2 STRUKTURA KOMANDNE PORUKE .................................................................................................. 43 5.3 POVRATNE PORUKE ........................................................................................................................ 43

6 KOMUNIKACIONI INTERFEJS ................................................................................................ 45

6.1 SIMETRIČNI API ............................................................................................................................. 46 6.2 IZBOR IMPLEMENTACIJE ................................................................................................................. 46 6.3 PRIMERI IMPLEMENTACIJA ............................................................................................................. 47 6.4 PČVORNI KOMUNIKACIONI PARAMETRI ......................................................................................... 47 6.5 DESTINACIONI IDENTIFIKACIONI PARAMETAR ................................................................................ 48 6.6 KOMUNIKACIONI PARAMETRI ........................................................................................................ 48




6.7 PARAMETRI PORUKE ...................................................................................................................... 49 6.8 MEMORIJSKA OGRANIČENJA IMPLEMENTACIJE .............................................................................. 49 6.9 KOMUNIKACIONA SEKVENCA ......................................................................................................... 50

7 UVOD U IEEE 1451.0 API ............................................................................................................ 52

7.1 CILJEVI API - JA ............................................................................................................................. 52

8 TRANSDUCER SERVICE API ...................................................................................................... 54

8.1 PODINTERFEJS TIMDISCOVERY........................................................................................................ 55 8.2 PODINTERFEJS TRANSDUCERACCESS ............................................................................................... 56

9 SOFTVERSKA IMPLEMENTACIJA FUNKCIJA SERVISNOG MODULA ............................ 58

9.1 JAVA I VIŠENITNO PROGRAMIRANJE ................................................................................................ 59 9.2 IMPLEMENTACIJA SERVISNIH FUNKCIJA - IDEJNO REŠENJE ............................................................. 59

9.2.1 IEEE 1451.0 procesni detalji .............................................................................................. 62

9.2.2 Mehanizam SendCommand() .............................................................................................. 63

9.3 SOFTVERSKA IMPLEMENTACIJA FUNKCIJA - PAKETI ....................................................................... 64 9.4 IMPLEMENTACIJA I DEVICES STRUKTURE (UREĐAJI) ..................................................................... 66

10 ZAKLJUČAK ................................................................................................................................. 69

11 LITERATURA ................................................................................................................................ 70

12 PRILOG .......................................................................................................................................... 71




1. Uvod

Neprestan razvoj tehnike i tehnologije izrade elektronskih komponenata, razlog je zašto smo svedoci progresa elektrotehnike. Ova dešavanja su dovela do toga da mnogi proizvođači informacionih tehnologija i industrijske opreme u svoje proizvode integrišu funkcije koje se sada popularno nazivaju „plag & play“ da bi bili u korak sa trendom smanjenja nivoa tehničkog znanja i pojednostavljenja instalacije i konfiguracije sistema. Ova pojava se odrazila i na proizvodnju merhih pretvarača, koji sa osobinom „plag & play“ dobijaju i prefiks pametni (smart

transducers). Pametni pretvarači, kao i sve ostalo, postaju sve manji, smanjili su potrošnju i sada obavljaju sve više funkcija. Osim primarne funkcije da mere ili kontrolišu određenu fizičku veličinu, sada je spektar funkcionalnosti znatno proširen, pa imamo samokalibraciju, samoidentifikaciju, samodeskripciju, obradu podataka za slanje i komunikacija sa spoljnim svetom posredstvom velikog broja komunikacionih interfejsa.

Senzori i mreže su ključne komponente u stvaranju ogromne mreže razmene podataka, koje će omogućiti senzorske mreže. Ovakav tip mreža će se koristiti u najrazličitije svrhe, od detekcije oružja za masovno uništenje, preko merenja temperature i pritiska, pa do posmatranja i zaštite nacionalnih parkova, aerodroma, mostova... Veliki broj komunikacionih interfejsa gotovo je učinio nemogućim forimiranje velike mreže mernih pretvarača, što je prouzrokovalo haos na tržištu mernih pretvarača, jer nije postojala kompatibilnost između mernih pretvarača različitih proizvođača.

Sve navedeno do sada je dovelo do stvaranja potrebe za standardizacijom interfejsa za merne pretvarače. Problem rešava IEEE koji je razvio familiju standarda IEEE 1451, kojim su standardizovani interfejsi za merne pretvarače. Formiran je sa ciljem da se opiše pristup podacima mernog pretvarača putem mrežno-nezavisnih komunikacionih interfejsa prilikom njihovog povezivanja sa mikoroprocesorima, instrumentacionim sistemima i mrežama. U ovom radu ćemo se najviše baviti standardom IEEE 1451.0 koji definiše zajedničke operacije za pretvarače i protokole kako da se pristupi podacima putem mreže. Detalje funkcionisanja sistema koji je realizovan poštovanjem ovog standarda ćemo objasniti u nastavku ovog rada.

Ovaj rad će omogućiti čitaocu da uvidi sve prednosti familije standarda IEEE 1451 za komunikaciju sa pametnim pretvarča. Velika pažnja će biti posvećena strukturi komande i poruka kao i načinima komunikacije između korisnika i pametnih pretvarača. Pojmom pametnih mernih pretvarača ćemo se baviti u drugom poglavlju, koji su razvojem tehnologije postali dominantni na tržištu. U trećem poglavlju je ukratko opisan IEEE 1451 standard za interfejse mernih pretvarača. Četvrto poglavlje posvećeno je komandama u ovom protokolu, a peto fizičkoj strukturi komandi i poruka. Šesto i sedmo poglavlje u kratkim crtama opisuju komunikacioni interfejs i API funkcije ovog protokola. U nastavku je dat opis Transducer servisnog modula i




nekih njegovih funkcija čija je softverska implementacija suština ovog rada i ona je opisana u poglavlju 9. U prilogu je dat kompletan Java kod za jednu API funkciju (readData).

2. Pametni merni pretvarač (Smart Transducer)

Danas se senzori i aktuatori koriste u najrazličitijim aplikacijama koje su u dodiru sa svakodnevnim ljudskim životima, signalizacije alarma iz fabričkog postrojenja u odeljenju za monitoring itd. Dakle, šta je merni pretvarač? Merni pretvarač je uređaj koji pretvara energiju iz jednog oblika u drugi. Senzor je pretvarač koji generiše električni signal proporcionalan fizičkom, biološkom ili hemijskom parametru, npr mikrofon. Aktuator je pretvarač koji ima ulazni električni signal i na osnovu koga preduzima određenu fizičku aktivnost, npr zvučnici. Pre pojave mikrokontorlera, senzori ili pretvarači su se uglavnom koristili za merenje fizičkih veličina, kao što su temperatura, pritisak itd. a izmerena vrednost je direktno očitavana sa neke skale od strane posmatrača. Takođe, posmatrač je inicijalno podešavao sistem da bi se dobio što tačniji rezultat. Pametni pretvarač je celina koju čine analogni ili digtalni senzor ili aktuator, procesorska jednica i komunikacioni interfejs. Sadrži još i odgovarajući softer se koriste se za obradu signala, kalibraciju, dijagnostiku i komunikaciju. Prema prethodnoj definiciji, model pametnog pretvarača je prikazan na Slici 1. Kao što se može videti sasatoji se od četiri dela:

• pretvarača (senzor ili aktuator),

• dela za obradu i konverziju signala (A/D, D/A),

• procesora i

• dela za mrežnu komunikaciju.

Analogni izlaz senzora je pojačan i obrađen, a zatim konvertovan u digitalni format pomoću A/D konvertora. Signal senzora koji je digitalizovan, tada se može lako procesirati pomoću mikroprocesora i odgovarajućeg softvera. Na ovaj način se dobijaju izmereni ili izračunati parametri koji se nakon toga mogu prosleđivati do servera ili nadozornog sistema raznim

Slika 1 – Model pametnog mernog

pretvarača

Network communication

Application processor

Signal conditioning and

data conversion (A/D, D/A)

Tranducers

(sensors and actuators)

SmartTransducer

Network




mrežnim protokolima. U obrnutom slučaju, komanda poslata sa servera putem mreže se može koristiti za upravljanje aktuatorom.

Rane indikacije prelaska sa strogo mehaničkih senzora na elektronske tehnike demonstrirane su u oblasti temperaturnog i pozicionog merenja. Termistori i poluprovodnički temperaturni senzori koji su bili jeftiniji, manje veličine i jednostavniji za povezivanje sa ostalim kolima zamenili su termoparove i termometre. Na isti način su i druga dotadašnja rešenja zamenjena naprednijim tehnologijama. Tehnika je učinila korisnim do tada otkrivene osetljivosti na temeraturu, pritisak, magnetska polja i ostale fizičke veličine tranzistora i integrisanih kola. Kako se pametni senzori sastoje od više delova koji se danas lako integrišu u zajedničke celine, na slici 2 možemo videti kako se dolazi do kompletnog senzorskog sistema. Tehnologija proizvodnje je ključni faktor. Prilikom izrade integrisanih komponenata da bismo uštedeli na veličini, potrošnji, smanjenju interkonekcija, a i da bismo povećali osetljivnost na određenu veličinu možemo u istom pakovanju imati kombinaciju obrade signala i senzorskog modula. Sada je moguće napraviti pametan senzor kojim se može meriti više veličina sa dve poluprovodničke komponente: senzorom i mikroprocesorskom jedinicom.

Slika 2 – Migracija senzorske tehnologije




3. IEEE 1451 Standard

Napori industrije su bili fokusirani na definisanje, funkcionalnost i komunikacione standarde pametnih pretvarača. Rezultat ili cilj kome se težilo je interoperabilnost (Slika 1) na širokom sektru aplikacija. Pametni senzori, sa odgovarajućim konfigurisanjem, mogu se ponašati kao samostalni senzori, mogu komunicirati u peer-to-peer odnosu sa drugim senzorima ili aktuatorima ili da se ponašaju kao inteligentni priključci u mreži. Interoperabilnost dozvoliće implementaciju različitih interfejsa na različitim mrežama za mrežno nezavisne operacije. Takav napor bi trebalo da omogući razvoj umrežavanja pametnih pretvarača kao što je slučaj sa razvojem i komercializovanjem pametnih senzora i pametnih aktuatora.

Kao odgovora na potrebe industrije za standardizacijom interfejsa za senzore, IEEE (Institute of Electrical

and Electronic Engineers) je sponzorisao razvoj seta standarda za interfejs pametnih pretvarača, odn. senzora i aktuatora, poznat kao IEEE 1451. Ovaj standard opisuje skup opštih, pristupačnih, mrežno-nezavisnih komunikacionih interfejsa za povezivanje senzora i aktuatora sa mikroprocesorima, instrumentacionim sisitemima i mrežama. Za korisnika bi trebalo da bude neprimetno da li je merni pretvarač direktno povezan sistem ili na mrežu. Ključna komponenta koju propisuje ovaj standard se naziva Električna šema mernog pretvarača – Transducer Electronic Data Sheet (TEDS) koja sadrži meta podatke o mernom pretvaraču u koje je uključena indetifikacija uređaja, informacije o proizvođaču, krive kalibracije, merni opsezi, lokacija itd.

Sa ovim standardnom korisnik će moći da upotrebljava senzor bez nekog velikog dodatnog podešavanja. Kada se senzor priključi na sistem koji je već pod napajanjem, senzor će se identifikovati samostalno i prijaviti sistemu ili mreži. Nakon toga, šalje podatke mreži ili sistemu kojima sebe opisuje. Bazirano na podacima koje je sistem primio, automatski konfiguriše i integriše senzor. Sve funkcije su oformljene bez ljutskog udela ili eventualno sa minimalnim udelom, što može dovesti do potencijalnih grešaka. Nakon ovoga senzor je spreman za upotrebu.

Cilj 1451 je da obezbedi pristup podacima pretvarača kroz zajednički set interfejsa, bez obzira da li je pretvarač povezan na sistem žičanom ili bežičnom (wireless) vezom. Propisuje standardizovan TEDS koji zamenjuje štampane električne šeme i smanjuje mogućnost pravljenja grešaka prilikom ručnog unošenja podataka i konfigurisanja sistema. Takođe, ostavljaju

Slika 3 – Interoperabilnost




mogućnost za razvoj proizvoda jednostavnom promenom TEDS-a. Pošto je sve automatizovano, premeštanje senzora je veoma brzo i jednostavno.

3.1 IEEE 1451 pametni merni pretvarač

Bazirano na definiciji standarda o kome je reč u ovom radu, IEEE 1451 pametni merni pretvarač je opisan kao pametni merni pretvarač koji sadrži dodatne funkcije, pored onih koje su neophodne za korektno predstavljaje merenja ili kontrolisane veličine. Ova funkcionalnost obično omogućava integraciju mernog pretvarača u aplikacije kojie su u mrežnom okruženju. Ovo znači da IEEE 1451 pametni pretvarač ima sposobnost samoidentifikacije, samodeskripcije, samodijagnostike, samokalibracije, informisanja o lokaciji i vremenu, obrade podataka, zaključivanja, spajanja podataka, upozoravanja, standardne formate podataka i komunikacione protokole. Slika 4 pokazuje arhitekuru IEEE 1451 pametnog mernog pretvarača, koja je slična Slici 1. Razlika se ogleda u dodatku TEDS-a i podeli sistema u dve veilke celine:

• Network Capable Application Processor (NCAP) i

• Transducer Interface Module (TIM),

a ove dve celine su povezane Transducer Independent Interface (TII). NCAP obezbeđuje obradu u okviru aplikacije i funkciju mrežne komunikacije, dok se TIM sastoji od pretvarača stanja signala u dela za konverziju podatka i određenog broja senzora i aktuatora koji može doći do 255 (Slika 5). Ovo je veoma korisno za rad sa velikim nizovima senzora što su Micro-

Electro-Mechanical-System (MEMS) uređaji ili sa kompleksnim kombinacijama senzora i aktuatora. TII definiše komunikacioni medijum i protokol za transfer senzorskih informacija. Ovaj interfejs propisuje skup operacija, kao što su čitanje, pisanje, čitanje i pisanje poruka, čitanje i pisanje odziva itd. TTI je 10-žični interfejs. Mrežni

interfejs (Network Interface) definiše mrežni komunikacioni protokol za komunikaciju NCAP u mreži.

Osim specifikacije za komunikacione interfejse, druga ključna stvar za

Network communication

Application processor

Transducer signal

conditioning

and data conversion

(A/D, D/A)

Tranducers (sensors and actuators)

Network

CapableApplication

Processor

(NCAP)

Network

Network

Interface

Transducer electronic

Data sheet (TEDS)

Transducer

Independent

Interface (TII)

TransducerInterface

Module(TIM)

Slika 4 – Model IEEE 1451 pametnog mernog

pretvarača

Slika 5 – Transducer Interface

Module (TIM)




IEEE 1451 pametne merne pretvarače je specifikacija standardizovanih TEDS-a i njihovih formata. TEDS je prikačen za merni pretvarač kao identifikaciona kartica njega samog. TEDS sadrži u sebi sačuvane relevantne informacije proizvođača mernog pretvarača, kao što su identifikacija proizvođača, opseg merenja, preciznost, podaci za kalibraciju i ostale informacije koje se uobičajeno nalaze u opisu (data sheet) mernog pretvarača. Uglavnom se nalaze u E2PROM-u ukoliko se podaci ne mogu menjati, a ako podaci mogu menjati obično se nalaze u RAM-u TIM-a.

3.2 Arhitektura IEEE 1451 familije standarda

Sada kada smo stekli jasniju sliku o ovoj oblasti, ponovićemo definiciju koja se nalazi u jednom od prethodnih poglavlja. IEEE 1451 standard opisuje skup opštih, pristupačnih, mrežno-nezavisnih komunikacionih interfejsa za povezivanje senzora i aktuatora sa mikroprocesorima, instrumentacionim sisitemima i mrežama. Familija IEEE 1451 standarda propisuje skup protokola za žičane (wired) ili bežične (wireless) aplikacije za kontrolu i nadzor.

U IEEE 1451 familiji, standard IEEE 1451.0 definiše zajednički set instrukcija za pristup senzorima i aktuatorima koji su povezani u različite konfiguracije, kao što su point-to-point, distribuirana multi-drop i bežične konfiguracije u zavisnosti od potrebe. Postoje tri načina da se pristupi putem mreže senzorima i aktuatorima koji se nalaze u skolpu TIM-a, a oni su:

• IEEE 1451.1,

• IEEE 1451.0 Hyper Text Transfer Protocol i

• Predloženi Web servisi za pametne merne pretvarače – Smart Transducer Web Services

Fizički interfejsi između NCAP-a i TIM-a sadrže sledeće:

Smart transducer

web services

IEEE 1451.X

Signal conditioning and data conversion (A/D, D/A)

NetworkCapable

ApplicationProcessor(NCAP)

Network

IEEE1451.21451.3

1451.5p1451.6p1451.7

IEEE 1451.0 HTTP Protocol

IEEE1451.1

IEEE 1451.0

IEEE 1451.X

Physical layer(PHY)

IEEE 1451.X

IEEE 1451.0 TEDS

IEEE 1451.0

IEEE 1451.X PHY TEDS

IEEE 1451.4 Transducer (optional)

Transducer Transducer

Mixed modeinterface

Transducer interface

Modul(TIM)

Slika 6 – Arhitektura IEEE 1451 standarda




• Point-to-point interfejs koji se može naći u standardu IEEE 1451.2,

• Distribuirani multi-drop interfejs koji se može naći u standardu IEEE 1451.3,

• Bežični (wireless) interfejs, koji se može naći u standardu IEEE 1451.5 (WiFi, Bluetooth i ZigBee),

• CANopen interfejs koji se može naći u predloženom standardu IEEE 1451.6 i

• RFID (Radio Frequency Identification) interfejs koji se može naći u predloženom standardu IEEE 1451.7.

U suštini, interfejsi između mernog pretvarača i obrade signala i ciklusa konvercije nisu specificirani u IEEE 1451 standardima, osim u IEEE 1451.4 stadnardu, koji opisuje low-level, mixed-mode interfejs za merne pretvarače. IEEE 1451.4 definiše TEDS-ove, ali u vezi sa pretvaračkim signalima u analognoj formi.

Standard IEEE 1451.0 definiše jedinstven interfejs za IEEE 1451 pametne merne pretvarače. Cilj standarda IEEE 1451 je da omogući mreži da pristupi standardizovanim podacima mernih pretvarača, a sve to pomoću zajedničkog skupa interfejsa, bez obzira kako su merni pretvarači povezani na mrežu.

3.3 Elementi IEEE 1451 familije standarda

3.3.1 IEEE 1451.0

IEEE 1451.0 standard definiše skup opštih funkcionalnosti, komandi i TEDS-a za interfejs familije standarda IEEE 1451 pametnih mernih pretvarača. Ove funkcionalnosfti su nezavisne od medijuma za fizičku komunikaciju (1451.X) između mernog pretvarača i NCAP-a. Sadrži osnovne funkcije za čitanje i pisanje mernih pretvarača, čitanje i pisanje TEDS-a i slanje

konfiguracionih, kontrolnih i operacionih komandi TIM-a. Ovo Slika 7 – IEEE 1451.0 blok dijagram




omogućava lako dodavanje drugih preloženih IEEE 1451.X fizičkih slojeva ovoj familiji. Takođe, jedan od ciljeva je pružanje pomoći da se dostigne interoperabilnost podataka kada je zajedno povezano više žičanih i bežičnih mreža. IEEE 1451.0 definiše protokol kako da se pristupi podacima mernog pretvarača putem mreže koristeći HTTP. Ovaj standard korisiti klijent/server model. NCAP, povezan sa jednim ili više TIM-ova (senzori ili aktuatori), preuzima ulogu servera. Klijenti mogu postali zahtev NCAP-u za očitavanje veličine koja se meri. Serverov odgovor je u XML formatu.

3.3.2 IEEE 1451.1

IEEE 1451.1 standard definiše specifikacije opšteg modeliranog objekta i interfejsa za komponente umreženog mernog pretvarača. U suštini, modelirani objekat je kolekcija podataka i operacija. Arhitektura softvera IEEE 1451.1 standarda je definisana sa tri modela:

• Model podatka određuje tip i formu informacija za komuniciranje putem određenog interfejsa IEEE 1451.1 objekta za lokalnu i udaljenu komunikaciju,

• Model objekta određuje tipove komponenata softvera za korišćenje prilikom dizajniranja i implementacije aplikacija sistema. U suštini, model objekta propisuje gradivne blokove softvera za aplikacije sistema i

• Dva komunikaciona modela definišu sintaksu i semantiku interfejsa softvera između komunikacione mreže i objekta aplikacije.

IEEE 1451.1 je primenljiv kod aplikacija zasnovanih na distribuiranom merenju i kontroli. Zasnovan je uglavnom na komunikaciji između NCAP-a i između NCAP-ova i ostalih čvorova (nodes) u mreži. Slika 8 prikazuje sastavne blokove i programske komponente parametera, događaja, fajlova i tajmera.

Slika 8 – Komponente modela objekta IEEE 1451.1




3.3.3 IEEE 1451.2

IEEE 1451.2 standard definiše digitalni interfejs za povezivanje mernog pretvarača i mikroprocesora (NCAP), a i TEDS-ove za point-to-point konfiguraciju. Takođe, predstavlja koncept TIM-ova i TII-a. Merni pretvarači su deo TIM-a. Slika 9 pokazuje odnos između

elemenata definisanih u IEEE 1451.2 standardu i mreže. Originalni standard opisuje komunikacioni sloj baziran na SPI-u (Serial Periphral Interface) sa dodatnim hardverski linijama za kontrolu protoka i vremensko očitavanje sa ukupno 10 linija, koje su predviđene za ovaj interfejs. Ovaj standard je kasnije proširen sa još dva popularna serijska interfejsa: UART i Universal Serial Interface.

3.3.4 IEEE 1451.3 IEEE 1451.3 standard definiše

digitalni interfejs između mernih pretvarača i NCAP-a, a i TEDS-ove koristeći multi-drop komunikacioni protokol. Standard omogućava mernim pretvaračima da budu u nizu kao mrežni čvorovi (nodes) u multi-drop mreži, koristeći isti par žica. Koristi se višestruko povezivanje fizički

odvojenih senzora. Ovo je jedan od dva interfejsa koji omogućava digitalnim

Slika 9 – Predloženi hardver po IEEE 1451.2 standardu

Slika 10 – Predložena specifikacija intefejsa

po IEEE 1451.3 standardu




podacima da budu smešteni sa mernim pretvaračem i poslati preko analognih veza (wires). Slika 10 prikazuje intefejs za module koji su fizički odvojeni. Interfejs će podržati TEDS-ove, identifikaciju kanala i protokole za vremensko sinhronizovanje. Transducer bus interface module (TBIM) će sadržati od jednog do N mernih pretvarača, TEDS-ove i logiku za kontrolu i transfer podataka putem magistrale. Transducer bus controller (TBC) će upravljati magistralom i raspoređivati pokretanje i prenos podataka.

3.3.5 IEEE 1451.4

Za razliku od prethodno definisanih standarda koji su za digitalne merne pretvarače, IEEE 1451.4 standard interfejsa za analogne merne pretvarače sa analognim i digitalnim radnim režimom. Analogni merni pretvarači zbog svog povezivanja i opreme za veliki spektar analognih merenja su morali da dobiju svoj standard. Kada se sistem uključi, TEDS-ovi mernog pretvarača se šalju sistemu jednožičnim digitalnim interfejsom. Nakon toga interfejs prelazi u analogni režim i isti interfejs se koristi za prenos analognog signala od mernog pretvarača do sistema.

Ovaj standard nudi kompatabilnost sa postojećim sistemima i omogućava tranziciju na digitalne 1451 standarde. I senzori i aktuatori su podržani IEEE 1451.4 standardom, a interfejs je nevidljiv ako posmatramo sa mrežne strane. Standard omogućava da analogni izlaz komunicira digitalnim podacima sa IEEE 1451 objektom koji je na višem nivou. Slika 11 prikazuje TEDS-ove i IEEE 1451 objekat za alanogni merni pretvarač.

3.3.6 IEEE 1451.5

IEEE 1451.5 standard definiše interfejs između mernih pretvarača i NCAP-a. Takođe propisuje i TEDS-ove za bežičnu (wireless) vezu. Bežični standardi koji su prihvaćeni od IEEE 1451.5 standarda su 802.11 (WiFi), 802.15.1 (Bluetooth), 802.15.4 (ZigBee) i 6LowPAN. Slika 13 prikazuje arhitekturu IEEE 1451.5 bežičnog standarda. NCAP je uređaj koji sadrži jedan ili više uređaja (802.11, Bluetooth i ZigBee) i koji može da komunicira sa jednim

Slika 11 – IEEE 1451.4 interfejs

Slika 12 – Wireless sensor Network




ili više Wireless Transducer Interface Module (WTIM). Takođe, svaki WTIM sadrži jedan bežični uređaj (802.11, Bluetooth i ZigBee). NCAP može bežično da komunicira sa svakim WTIM-om koristeći različiti bežični protokol, a istovremeno da bude i povezan na neki eksternu mrežu.

Slika 13 – Arhitektura IEEE 1451.5 standarda

NCAP IEEE 1451.5

(Bluetooth) Communication

Module

NCAP 1451 Application


Network

CapableApplication

Processor

(NCAP)

Network

NCAP IEEE

1451.5 (802.11) Communication

Module

NCAP IEEE

1451.5 (ZigBee) Communication

Module

NCAP IEEE 1451.0 Transducer Services

TIM IEEE 1451.5 (Bluetooth) Communication Module

TIM 1451.0

Transducer Services IEEE

1451.0 TEDS

1451.5

TEDS

Sensors Actuators


TIM IEEE 1451.5 (802.11) Communication Module

TIM 1451.0


1451.0 TEDS

1451.5

TEDS

Sensors Actuators


TIM IEEE 1451.5 (ZigBee) Communication Module

TIM 1451.0


1451.0 TEDS

1451.5

TEDS

Sensors Actuators

IEEE 1451.5

(Bluetooth)

IEEE 1451.5

(802.11)

IEEE 1451.5

(ZigBee)

WTIM WTIM WTIM




3.3.7 IEEE 1451.6

IEEE 1451.6 standard definiše interfejs između mernih pretvarača i NCAP-a, kao i TEDS-ove koristeći ultra-brzi (high-speed) CANopen mrežni interfejs. Definiše 1451 TEDS-ove koji su mapirani po CANopen rečniku ulaza, kao i komunikacione poruke, obradu podataka, konfiguracione parametre i dijagnostičke podatke.

3.3.8 IEEE 1451.7

IEEE 1451.7 standard definiše interfejs i komunikacioni protokol između mernih pretvarača i RFID (Radio Frequency Identification) sistema. Opisuje komunikacione metode, formate podataka i TEDS-ove za senzore koji rade sa RFID sistemima. Obezbeđivanjem senzorskih podataka prilikom izveštavanja, kao što je identifikovanje uređaja i praćenje njegovog stanja, ovaj standard otvara nove mogućnosti za senzore i RFID sisteme.




3.4 TEDS (Transducer Electronic Data Sheets)

Prikačeni na pretvarač, TEDS-ovi su kao identifikacione kartice koje osobe nose sa sobom i koje ih u potpunosti opisuju. TEDS-ovi u osnovi identifikuju sve što ste želeli ili što ćete želeti da znate o pretvaračima uključujući i:

• Proizvođača, broj modela, serijski broj, tip uređaja i datumski kod za pametne pretvarače;

• Kalibrisane jedinice, promenljive, tip podataka i limite korišćenja;

• Kalibracione konstante;

• Model konverzije signala, dužinu modela i broj označenih bitova;

• Vreme postavke čitanja i upisivanja kanala, period odabiranja, vreme podizanja sistema i vreme osvežavanja;

• Zahteve napajanja (napon i struja) i

• Opšte stvari: dužina TEDS-a i broj kanala.

TEDS je u suštini memorijski uređaj koji sadrži identifikaciju pretvarača, kalibraciju, podatke za ispravku, opseg merenja, proizvođačke podatke itd. TEDS može biti smešten u E2PROM-u ili delove RAM-a koji su deo TIM-a. Deset različitih TEDS-ova su propisani po standardu 1451.0. Ove vrste su korišćene od strane NCAP-a ili operatora. Tu su četiri obavezne i šest opcione TEDS klasifikacije. Na slici 14 imamo listu definisanih TEDS-ova po 1451.0 standardu. Na slici 15 je prikazan primer jednog TEDS-a obaveznog bloka podataka za identifikaciju kanala. 17 polja obezbeđuju proizvodne i senzorske informacije. Funkcija TEDS-a za identifikaciju kanala je da omogući interfejsu da sve informacije budu prepoznate kada kanal bude adresiran. Bajtovi ovog TEDS-a su konstante i mogu

Slika 14 – Tipovi TEDS-ova

Slika 15 – Tipovi TEDS-ova




3.5 NCAP (Network Capable Application Processor)

NCAP je interfejs između procesora, komunikacionih mreža i pretvarača. Tipično, NCAP se sastoji od procesora sa namenskim operativnim sisitemom i sposobnosti za merenje. NCAP-ovi se mogu sastojati od jednostavnih elemenata sa obimnom podrškom za TIM-ove sa mnoštvo kanala, a mogu se biti i veoma kompleksnih dizajnova sa višestukim portovima. Slika 16 ilustruje odnose između blokova objekata, softverskih procesa i jednog NCAP-a. On obezbeđuje komunikaciju mreže i TIM-a, vrši funkcije konvertovanja i obrade podataka i napajanje TIM-a. NCAP može obavljati funkciju mrežnog kontrolera u mreži sastavljenoj od više NCAP. Unutar NCAP-a može biti nekoliko softverskih procesa i funkcionalnom bloku, osnovni blok pretvarača, a takođe i blokovi koji nisu po IEEE 1451 standardu, ali samo jedan lokalni NCAP blok.

Slika 16 – Relacije između blokova i objekata




4. Komande

Komande su podeljene u dve kategorije, standardne i ručno definisane. Bez obzira na kategoriju, komanda je podeljena u dva okteta. Viši oktet definiše klasu komande. Niži oktet, koji se naziva funkcija, specificira komandu u okviru klase. Na primer, viši oktet definiše Transducer idle state command klasu, niži oktet onda definiše komande u okviru ove klase.

Sledeća tabela pokazuje vrste klasa:

cmdClassId Attribute name Category 0 Reserved Reserved 1 CommonCmd Commands common to the TIM and TransducerChanell 2 XdcrIdle Transducer idle state 3 XdcrOperate Transducer operating state 4 XdcrEither Transducer either idle or operating state 5 TIMsleep Sleep state 6 TIMActive Tim active state commands 7 AnyState Any state 8–127 ReservedClass Reserved 128–255 ClassN Open for manufacturers – N = class number

Tabela 1. – Standard command classes (Standardne klase komandi)

TIM može generisati odgovor na komandu u sledeće dve okolnosti. Prva okolnost je kada komanda sama po sebi zahteva odgovor. Primer ovakve situacije je Query TEDS komanda. Druga okolnost je kada je Status event protokol dozvoljen. U ovom slučaju, TransducerChannel

ili TIM šalju odgovor bez obzira na to da li se u statusnom registru nalazi nemaskirajući bit.

Odgovor (responce) se šalje u odgovarajućem formatu kako je već bilo objašnjeno (Command message structure). Sledeći paragraf opisuje šta treba biti u komandno-zavisnim oktetima iz tabele u 5.2. Ako se šalje odgovor na komandu ili se prima, on mora imati odgovarajuću strukturu opisanu u 5.3.

U tabelama u ovom odeljku, postoje spiskovi koji su rezervisani za naredne verzije ovog standarda. Neki su, pak, opcioni, i može se izabrati da se oni ne implementiraju. Pojedina nabrajanja koja su rezervisana kao „ otvorena za korekciju “ mogu se koristiti za definisanje uslova koji nisu opisani ovim standardom.

4.1 Standardne komande

Kontrolne funkcije dozvoljavaju komandama da budu poslate celom TIM – u, ili svakom TransducerChannel – u ponaosob, što zavisi od njihovog stanja i operacije. TIM će reagovati na sve neimplementirane komande postavljanjem TIM nevažećeg komandnog bita u statusnom registru.




4.1.1 Komande zajedničke za TIM i TransducerChannel

Ova klasa komandi može biti adresirana ili ka TIM – u ili TransducerChannel – u. Adresa se koristi da pokaže da li se komanda izvršava uz TIM ili TransducerChannel logiku. U tabeli 2 se nalazi spisak komandi iz ove klase. Komande iz ove klase ne bi trebalo da se adresiraju ka AddressGroup, TransducerChannel proxy, ili globalno. Ipak ako se to desi, komanda se ignoriše i reject bit u TIM status – condition registru se postavlja.

cmd Function Id Command State Reply/

expected Required/ optional TransducerChannel T I M

0 Reserved — — — — 1 Query THUS Any Active Yes Required 2 Read TEDS segment Am Active Yes Required 3 Write TEDS segment Any Active No Required 4 Update TEDS Any Active Yes Required 5 Run self-test Idle Active No Required 6 Write service request mask Any Active No Required 7 Read service request mask Any Active Yes Required 8 Read status-event register Any Active Yes Required 9 Read status-condition register Any Active Yes Required 10 Clear status-event register Any Active No Required

11 Write status-event protocol state Idle Active No Required

12 Read status-event protocol state Any Active Yes Required 13-127 Reserved — — — — 128-255 Open for manufacturers — — — —

Table 2. - Common commands (Zajedničke komande)

Query TEDS komanda

Argument : TEDSAccessCode : tip podatka Uint8

Ovu komandu koristi NCAP da bi dobio informaciju potrebnu za čitanje ili upis u TEDS. Postoji samo jedan argument koji identifikuje kom se TED – u pristupa. U tabeli 3 se nalazi lista TEDSAccessCode – ova za TED – ove definisane ovim standardom.

Odgovor na ovu komandu treba da sadrži informacije koje su nabrojane u tabeli 4. Od TED – a se zahteva da omogući odgovor na sve Query TEDS komande, bez obzira da li TEDS pristupni kod bira implementirani TEDS. Polje atributa u odgovoru (tabela 5) treba da pokaže dali je TEDS podržan, da li se može menjati, da li je tekući sadržaj validan, da li se radi o namenskom TEDS – u u TIM – u ili o virtualnom. TEDS statusno polje je opisano u tabeli 6.




Kada je Unsupported TEDS atribut postavljen, TIM će vratiti nulu za TEDSSize i MaxTEDSSize atribute. Kada je Virtual TEDS atribut postavljen, Read – only atributi će takođe biti postavljeni i TIM vraća nulu za TEDSSize,TEDSCkSum, i MaxTEDSSize atribute. To postaje odgovornost NCAP – a ili host procesora da odluči o veličini i argumentima koje će vratiti kao odgovor pozivajućoj aplikaciji. Ako se fajl ne može naći, Unsupported TEDS atribut se postavlja i TIM vraća nulu za TEDSSize, TEDSCkSum, i MaxTEDSSize atribute. Ako se fajl pronađe, Invalid i Unsupported atributi se brišu i Read – only, TEDSSize, TEDSCkSum, MaxTEDSSize atributi treba da budu određeniiz fajla atributa udaljenog fajla u kom se TEDS nalazio.

TEDS access code TEDS name

attribute TEDS Required/optional

0 — Reserved —

1 MetaTEDS Meta-TEDS1 Required

2 MetaIdTEDS Meta-identification TEDS2 Optional

3 ChanTEDS TransducerChannel TEDS1 Required

4 ChanIdTEDS TransducerChannel Identification TEDS2 Optional 5 CalTEDS Calibration TEDS1 Optional

6 CalldTEDS Calibration identification TEDS2 Optional

7 EUASTEDS End users7 application-specific TEDS3 Required

8 FreqRespTEDS Frequency response TEDS1 Optional

9 TransferTEDS Transfer function TEDS1 Optional

10 CommandTEDS Commands TEDS2 Optional

11 TitleTEDS Location and title TEDS2 Optional

12 XdcrXame User's transducer name TEDS3 Required

13 PHYTEDS PHY TEDS1 Required

14 GeoLocTEDS Geographic location TEDS2 Optional

15 UnitsExtention Units extention TEDS2 Optional

16-127 Reserved

12K-25S Manufacturer-defined TEDS Optional

NOTES 1—A binary TEDS 2—A text-based TEDS. 3—User-defined information content.

Table 3. - TEDS access codes




Table 4. - Query TEDS response in the data field

Field Data type

Field attribute name Function l UInt8 TEDSAttrib TEDS attributes (see Table 19) 2 UInt8 TEDSStatus TEDS status 3 UInt32 TEDSSize Current size of the TEDS 4 UInt16 TEDSCkSum TEDS checksum 5 UInt32 MaxTEDSSize Maximum TEDS size

Table 5. - TEDS attributes

Dit Data type Field attribute name Definition 0 (lsb) Boolean TEDSAttrib. Read Only Read-only - Set to true if TEDS may be read but not

written. 1 Boolean TEDSAttrib. Not A vail Unsupported-Set to true if TEDS is not supported by

this TransducerChannel. 2 Boolean TEDSAttrib.Invalid Invalid-Set to true if the current TEDS image is

invaiid. 3 Boolean TEDSAttnb. Virtual Virtual TEDS-This bit is set to true if this is a virtual

TEDS (A virtual TEDS is any TEDS that is not stored in the TIM. The responsibility for accessing a virtual TEDS is vested in the NCAP or host processor.)

4 Boolean TEDSAttri b.TextTEDS Text TEDS-Set to true if the TEDS is text based. 5 Boolean TEDSAttrib. Adaptive Adaptive-Set to true if the contents of the TEDS can

be changed by the TIM or TransducerChannel without the NCAP issuing a WriteTEDS segment command.

6 Boolean TEDSAttrib.M fgrDefine MfgrDefine-Set to True if the contents of this TEDS are defined by the manufacturer and will only conform to the structures defined in the standard if the TextTEDS attribute is also set.

7 (msb) Boolean TEDSAttiib.Reserved[7] Reserved

Table 6. - TEDS status

Bit Data type Held attribute name Definition 0 (lsb) Boolean TEDSStatus.TooLarge Too Large—The last TEDS image received was too

large lo fit in the memory allocated lo this TEDS. 1 Boolean TEDSStatus Reserved[1] Reserved

2 Boolean TEDSStatus Reserved[2] Reserved 3 Boolean TEDSStatus Reserved[3] Reserved

4 Boolean TEDSStatus Open[4] Open to manufacturers 5 Boolean TEDSStatus Open[5] Open to manufacturers 6 Boolean TEDSStatus Open[6] Open to manufacturers 7 (msb) Boolean TEDSStatus Open[7] Open to manufacturers




Read TEDS segment komanda

Ova komanda se koristi za čitanje TEDS – a preko NCAP – a. Argumenti ove komandesu prikazane u tabeli 21. Pošto je maksimalna veličina niza okteta manja od maksimalne veličine TEDS – a , TEDS segment offset se koristi da pokaže gde u okviru TEDS – a počinje čitanje.

Table 7. - Data field for a read TEDS segment command Field Data type Field attribute name Function 1 Uint8 TEDSAccessCode TEDS access code: as defined in Table 17. 2 UInt2 TEDSOffset TEDS Segment offset (0 to [current size – 1]) - This is the

address relative to the beginning of the TEDS at which the block of data shall be read.

Odgovor na Read TEDS Segment koristi strukturu poruke opisane u 5.3. Odgovor –

zavisni okteti koji se vraćaju u okviru poruke trebaju biti kao što je prikazano u tabeli 8. Prvo polje sadrži ofset u TEDS – u od kojeg je blok podataka uzet i najčečće se poklapa sa TEDS

Segment Offset u Read TEDS Segment komandi. Ostali okteti sadrže pročitane podatke iz TEDS – a. Odgovor treba da sadrži sve jedinice u TEDS Segment Offset – u i nula oktete ako je TEDS virtualan, nije podržan ili pogrešan. Broj okteta koji se vraćaju je funkcija dizajna i određena je hederom poruke (5.3). Ako je TEDSOffset veći od dužine TEDS – a, TEDSOffset u odgovoru treba da bude jednak dužini TEDS – a i odgovor će sadržati nula oktete.

Table 8. - Data field for a TEDS segment command reply

Field Data type Field attribute name Function 1 UInt32 TEDSOffset TEDS Segment offset (0 to [current size – 1]) 2 OctetArray KawTEDSBlock TEDS data octets

Write TEDS segment komanda

Ova komanda se koristi za upis u deo TEDS – a. Argumenti ove komande su opisani u tabeli 9. Pošto je maksimalna veličina niza okteta manja od maksimalne veličine za TEDS, TEDS

Segment Offset se koristi za pronalazak mesta u TEDS – u odakle se vrši upis. Ako je TEDSOffset veći od maksimalne dužine TEDS – a, podaci će biti izgubljeni i komandni rejected

bit se postavlja u statusnoj reči.

Table 9. - Data field for a write TEDS command

Field Data type Field attribute name Function 1 UInt8 TEDSAccessCode TEDS access code, as defined in Table 17, 2 UInt32 TEDSOffset TEDS Segment offset (0 to [current size – 1]) 3 OctetArray RawTEDSBlock TEDS Contents




Write TEDS segment komanda koristi komandnu strukturu poruke opisanu u 5.2. Ako je maksimalna veličina TEDS – a prekoračena, dodatni podaci se neće upisati u memoriju i tekuća veličina TEDS – a se postavlja na nulu.

Write TEDS segment komanda treba da kreira novi TEDS ako on ne postoji sa datim pristupnim kodom. Ako TIM ne podržava kreiranje novi TEDS – ova, ova komanda ne treba daupiše nikakve podatke u TEDS memoriju zato što je TEDS nepodržan.

Ova komanda ne vraća nikakav odgovor ( responce ). Ako se inače pokuša upis preko postojećih podataka, taj TEDS se obeležava kao Invalid.

Update TEDS komanda

Argument : TEDSAccessCode : tip podatka Uint8

Ova komanda se koristi da pokrene TEDS koji je prethodno upisan u TransducerChannel da bude verikofan i kopiran u nepromenljivu memoriju. Pošto se TEDS verifikuje on se obeležava kao Valid. Postoji jedan argument u ovoj komandi i on je opisan u okviru tabele 3.

Odgovor na ovu komandu treba da sadrži informacije koje su opisane u okviru odgovora na komandu Query TEDS.

Run self – test komanda

Argument : Test2Run : tip podatka Uint8

Ova komanda se koristi da pokrene adresni uređaj da odradi self – test. Postoji jedan argument u ovoj komandi i to je osmobitna enumeracija koja specificira dijagnostiku ranovanja kao što je pokazano u tabeli 10. Izvršilac može identifikovati dodatne testove koji su dostupni za određeni uređaj. Ako se enumeracija zahteva za uređaj koji nije implementiran, određeni invalid

komandni bit se postavlja u statusnom registru.

Table 10 . - Enumerations for the run diagnostic command

Enumeration Argument attribute name Diagnostic 0 Test2Run.ConfidenceTest Short confidence test 1 Test2RunTestAll Test all 2-255 Test2Run.RunTest[N] 2≤N≤255 Manufacturer-defined

Ako izvršilac implementira dodatne testove, oni će biti nabrojni u komandnom TEDS – u za TransducerChannel ili TIM.

Ova komanda se izvršava samo onda kada je TransducerChannel u idle stanju. Ako se ova komanda primi u svakom drugom slučaju, komandni rejected bit se postavlja.




Ako izvršilac želi da napiše poseban program za testiranje TIM – a i TransducerChannel - a onda komanda treba da bude adresirana na TIM i svi TransducerChannel – i treba da budu u idle

stanju.

Write service request mask

Argument : SRMask : tip podatka Uint32

Ova komanda se koristi za upis service request mask za adresirani TransducerChannel ili TIM. Maska je 32 – bitna.

Read service request mask

Povratni argument : SRMask : tip podatka Uint32

Ova komanda se koristi za čitanje service request mask iz adresiranog TransducerChannel ili TIM – a . Ona nema argumenata. Ipak, generiše odgovor koji ima jedan argument. Ovaj argument daje tekući aktivni service request mask za adresirani TransducerChannel.

Read status – event register

Povratni argument : SERegister : tip podatka Uint32

Ova komanda se koristi za čitanje statusa iz adresiranog TransducerChannel ili TIM – a. Ona nema argumenata. Ipak, generiše odgovor koji ima jedan argument. Ovaj argument daje tekući sadržaj Status – Event registra za adresirani TransducerChannel.

Read status – condition register

Povratni argument : SCRegister : tip podatka Uint32

Ova komanda se koristi za čitanje status – condition registra iz adresiranog TransducerChannel

ili TIM – a. Ona nema argumenata. Ipak, generiše odgovor koji ima jedan argument. Ovaj argument daje tekući sadržaj Status – Condition registra za adresirani TransducerChannel.

Clear status – event register

Povratni argument : SERegister : tip podatka Uint32

Ova komanda se koristi za brisanje statusa iz adresiranog TransducerChannel ili TIM – a. Ako je ceo TIM specificiran, komanda će obrisati sve status – event registre TIM – a, uključujući sve TransducerChannel event registre. Ona ne briše odgovarajuće mask ili condition registre. Takođe, ova komanda nema argumenata.




Write status – event protocol state

Argument : SEProtocol : tip podatka Boolean

Ova komanda se koristi za uklučivanje ili isključivnje status – event protokola. Kada je ovo stanje aktivno, tok podataka se inicira i šallje se 32 – bitni statusni registar kad god je service

request bit postavljen. Ova komanda ima jedan argument. Ako je vrednost tačna protokol je aktivan, u suprotnom nije.

Read status – event protocol state

Povratni argument : SEProtocol : tip podatka Boolean

Ova komanda se koristi za uklučivanje ili isključivnje status – event protokola. Ova komanda nema argumenata. Odgovor ima jedan argument. Ovaj argument vraća stanje tekućeg stanja status – event protokola. Ako je vrednost tačna protokol je aktivan, u suprotnom nije.

4.1.2 Transducer idle state komande

Idle state klasa komandi, koja je prikazana u tabeli 11, se izvršavaju samo onda kada je TransducerChannel u idle stanju. Ako se bilo koja od ovih komandi primi dok je TransducerChannel u nekom drugom stanju, komandni rejected bit u TransducerChannel

statusno – kondicionom registru se postavlja i komanda se ignoriše.

Sve komande iz ove klase zahtevaju da odredišni TransducerChannel broj bude veći od nule. U slučaju da je ovaj broj u oktetnom nizu jednak nuli, komandni rejected bit u TransducerChannel

statusno – kondicionom registru se postavlja i komanda se ignoriše.

Ako se Transducer Idle State komanda pošalje TransducerChannel – u koji ne podržava ovo svojstvo, komanda se ignoriše i invalid TransducerChannel bit se postavlja u statusnoj reči.

TIM bi trebao biti u aktivnom stanju pri prijemu bilo koje od ovih komandi od strane TransducerChannel – a. U suprotnom, komandni rejected bit se postavlja u TIM statusno – kondicionom registru se postavlja i komanda se ignoriše.

Komande koje su deklarisane kao opcione u tabeli 11 postaju važeće ako cvojstvo koje one podržavaju jeste programabilno. Neke komande iz ove klase koje mogu biti izdate TransducerChannel proxy – u.




Table 11. - Transducer Idle state commands

cmd FunctionId

Command Address class

Reply expected

Required/ optionial Transducer

Channel Proxy Group

0 Reserved — — — — — 1 Set TransducerChannel data

repetition count Yes No No No Optional

2 Set TransducerChannel pre-trigger count

Yes No No No Optional

3 AddressGroup definition Yes Yes No No Required 4 Sampling mode Yes Yes No No Optional 5 Data Transmission mode Yes Yes Yes No Optional 6 Buffered state Yes Yes No No Optional 7 End-of-data-set operation Yes Yes No No Optional 8 Actuator-halt mode Yes Yes No No Optional 9 Edge-to-report Yes Yes No No Optional 10 Calibrate

TransducerChannel Yes Yes Yes Yes Optional

11 Zero TransducerChannel Yes Yes Yes Yes Optional Write corrections state Yes Yes No No See

7.1.2.12 13 Read corrections state Yes Yes No No See

7.1.2.13 14 Write TransducerChannel

initiate trigger state Yes No No No Optional

15 Write TransducerChannel initiate trigger configuration

Yes No No No Optional

16-127 Reserved — — — — — 128-255 Open for manufacturers — — — — —

NOTE—Optional commands become required if the features they support are programmable.

Set TransducerChannel data repetition count

Argument : RepCount : tip podatka Uint 16

Ova komanda se koristi za promenu broja data semplova u broj koji može imati vrednost između nule i broja koji se nalazi u Maximum data repetition polju u okviru TransducerChannel TEDS.

Jedini argument je 16 – bitni integer koji daje broj semplova. Ako je ovaj broj veći od Maximum

data repetition, ne dolazi do ikakve promene ovog broja i TransducerChannel komandni rejected bit se postavlja u statusnom registru.




Set TransducerChannel pre - trigger count

Argument : PreTrigCount : tip podatka Uint 16

Ova komanda se koristi od strane TransducerChannel koji je sposoban za radu free – running

režimu i pre – trigger modu, za promenu broja data semplova u podešavanju za podatke koji mogu biti primljeni i smešteni pre trigerovanja. Ovaj broj može imati vrednost između nule i broja koji se nalazi u Maximum pre – trigger samples polju u okviru TransducerChannel TEDS.

Jedini argument ove komande je 16 – bitni integer koji daje broj semplova u podešavalju za podatke . Ako je ovaj broj veći od Maximum pre – trigger broja, ne dolazi do ikakve promene ovog broja i TransducerChannel komandni rejected bit se postavlja u statusnom registru.

AddressGroup definition

Argument : GroupAdd : tip podatka Uint 16

Ova komanda dodeljuje TransducerChannel adresnoj grupi (AddressGroup ). Ima jedan argument koji ukazuje na adresnu grupu. Tabela 11 pokazuje više detalja o ovim adresama. Adresirani TransducerChannel , standardan ili proxy, je dodeljen grupi. Ako je ovaj argument jednak nuli, adresirani TransducerChannel izbacije iz svih adresnih grupa kojima je bio dodeljen.

Sampling mode

Argument : SamplingMode : tip podatka Uint8

NCAP koristi ovu komandu kada menja sempling mod TransducerChannel – a. Nisu svi dozvoljeni modovi ovim standardom prihvatljivi za određeni TransducerChannel. Prihvatljivi modovi za dati TransducerChannel zavise od osobina semplovanja za taj TransducerChannel.

Ova komanda ima jedan argument . Lista prihvatljivih vrednosti za taj argument se nalazi u tabeli 12. Ako se ova komanda pošalje TransducerChannel – u koji ne podržava taj mod ili ne podržava njegovu promenu, invalid komandni TransducerChannel bit se postavlja u statusnoj reči.

Table 12. - Allowable values for the sampling mode argument

Enumeration Argument attribute name Operating mode 0 SampleMode.Reserved[0] Reserved 1 SampleMode.TriggerInit Trigger-initiated 2 SampIeMode.FreeNoPre Free-running without pre-trigger 3 SampleMode.FreePreTrig Free-running with pre-trigger




4 SampleMode.Continuous Continuous sampling 5 SampleMode.Immediate Immediate operation 6-127 SampIeMode.Reserved[N] 6≤N≤127 Reserved 128-255 SampIeMode Open[N] I28≤N≤255 Open to manufacturers

Data transmission mode

Argument : XmitMode : tip podatka Uint8

Ova komanda se koristi za kontrolu transmisionog moda podataka. Ona ima jedan argument . Lista prihvatljivih vrednosti za taj argument se nalazi u tabeli 13. Ako se ova komanda pošalje TransducerChannel – u koji ne podržava taj mod ili ne podržava njegovu promenu, invalid komandni TransducerChannel bit se postavlja u statusnoj reči.

Buffered state

Argument : BufferOnOff : tip podatka Boolean

Ova komanda se koristi za uljučivanje ili isključivanje baferovane operacije. Da li dati TransducerChannel podržava baferisanu operaciju opisano je u TransducerChannel TEDS – u. Takođe ima jedan argument, koji ako je tačan baferovanje je omogućeno, u suprotnom nije.

End – of – Data – set operation mode

Argument : EndDataSetMode : tip podatka Uint8

Ova komanda se koristi za aktuatore u cilju opisivanja, koju akciju treba da preduzme aktuator kada dođe do kraja podataka. Ako dati aktuator podržava End-of-Data-Set operaciju mogući modovi su opisani u TransducerChannel TEDS – u.

Komanda ima jedan argument, i lista mogućih vrednosti ovog argumenta se nalazi u tabeli 13. Ako se End – of – Data – set operation mode komanda pošalje TransducerChannel – u koji ne podržava taj mod ili ne podržava njegovu promenu, invalid komandni TransducerChannel bit se postavlja u statusnoj reči.

Table 13. - Allowable values for the End-of-Data-Set operation mode argument

Enumeration Argument attribute name Operating mode 0 EndDataSetMode.Reserved 101 Reserved 1 EndDataSetMode.Hold Hold 2 EndDataSetMode.Recirc Recirculate 3-127 EndDataSetMode.Reserved[N] 3≤N≤127 Reserved 128-256 EndDataSetMode.Open[N] 128≤N≤255 Open to manufacturers




Actuator halt operating mode

Argument : ActuatorHalt : tip podatka Uint8

Ova komanda se koristi za kontrolu izlaza aktuatora, u smislu šta on radi kada primi TransducerChannel idle komandu dok procesira podatke. Mogućnosti za dati aktuator su date u okviru TransducerChannel TEDS – a. Takođe ova komanda ima jedan argument koji opisuje moguće vrednosti ( tabela 14).

Table 14.- Allowable values for the actuator halt operating mode argument

Enumeration Argument attribute name Operating mode 0 ActuatorHalt.Reserved[0] Reserved 1 ActuatorHalt.Hold Hold 2 ActuatorHalt.Finish Finish data set 3 ActuatorHalt.Ramp Ramp 4-127 ActuatorHalt.Reserved[N] 4≤N≤127 Reserved 128-256 ActuatorHalt.Open[N] 128≤N≤255 Open to manufacturers

Edge-to-Report

Argument : EdgeReported : tip podatka Uint8

Ova komanda se koristi za opisivanje na koju ivicu ili ivice dati senzor šalje izveštaj. Mogućnosti za dati senzor su date u oviru TransducerChannel TEDS – a.

Takođe ima jedan argument i moguće vrednosti ovog argumenta su date u tabeli 15.

Table 29. - Allowable values for the Edge-to-Report operation mode argument

Enumeration Argument attribute name Operating mode 0 EdgeReported.Reserved[0] Reserved 1 EdgeReported.Rising Report Rising Edges 2 EdgeReported.Falling Report Falling Edges 3 EdgeReported.BothEdges Report both Edges 4-127 EdgeReported.Re served [N] 4≤N≤127 Reserved 128-256 EdgeReported.Open[N] 128≤N≤255 Open to manufacturers

Calibrate TransducerChannel

Ova komanda se koristi da izazove TransducerChannel da pokrene proceduru koja verifikuje da li je njegov izlaz ono što se očekuje. Tačna definicija toga šta se dešava kao rezultat na Calibrate




TransducerChannel komandu je funkcija dizajna TransducerChannel – a i nije tema ovog standarda.

Odgovor na ovu komandu se uvek generiše nakon završetka operacije. Odgovor treba da bude isti kao odgovor na Read Status –Event Register komandu.

Zero TransducerChannel

Ova komanda se koristi da izazove TransducerChannel da pokrene proceduru koja anulira njegovulaz ili izlaz. Tačna definicija toga šta se dešava kao rezultat na Zero TransducerChannel

komandu je funkcija dizajna TransducerChannel – a i nije tema ovog standarda.

Odgovor na ovu komandu se uvek generiše nakon završetka operacije. Odgovor treba da bude isti kao odgovor na Read Status –Event Register komandu.

Write corrections state

Argument : CorrectState : tip podatka Uint8

Ova komanda se koristi od strane TransducerChannels koji su sposobni za ispravku grešaka u okviru TIM – a. Komanda izaziva TransducerChannel da uključi proces korekcije tako da jedinica šalje podatke u Physical Units specificiranim u Calibration TEDS – om. Ova komanda je obavezna za TransducerChannels koji podržavaju built – in correction.

Komanda ima jedan argument. Ako je vrednost argumenta tačna, mogućnost korekcije je važeća, u suprotnom nije. Correction disabled statusni bit se briše nakon prijema komande.

Read correction state

Povratni argument : CorrectState : tip podatka Uint8

Ova komanda se koristi od strane TransducerChannels koji su sposobni za ispravku grešaka u okviru TIM – a. Komanda je obavezna za TransducerChannels koji podržavaju built – in

correction.

Odgovor na komandu ima jedan argument. Ako je vrednost argumenta tačna, mogućnost korekcije je važeća, u suprotnom nije.

Write TransducerChannel Initiate trigger state

Argument : EventTrig : tip podatka Boolean




Ova komanda dozvoljava senzoru TransducerChannel - a da pokrene trigger komandu kada se desi trigerovanje. Ako senzor ili aktuator primi ovu komandu automatski će postaviti komandni rejected bit u statusnoj reči. Komanda ima jedan argument. Ako je vrednost ovog argumenta tačna, senzor ima dozvolu da pokrene trigerovanje kada se događaj desi. U suprotnom nema.

Write TransducerChannel Initiate trigger configuration

Argument : InitTrig : tip podatka Boolean

Ova komanda se koristida obezbedi informaciju koja je potrebna senzoru da započne trigger komandu. Argumenti ove komande su prikazani u tabeli 16.

Table 16. - Write TransducerChannel initiate trigger configuration

Field Data type Argument attribute name

Function

1 UInt16 InitTrig.destId The "destId" specifies the desired destination. 2 UInt16 InitTrig.channelId The "channelId" specifies the desired TransducerChannel. 3 Struct InitTrig.qosParams The "qosParams" is the desired quality of service

parameters. See 9.3.1.3 for details.

4.1.3 Transducer operating state komande

Transducer operating state klasa komandi se izvršava samo onda kada je TransducerChannel u operacionom ( operational ) stanju. Ako se neka od ovih komandi primi dok je TransducerChannel u nekom drugom stanju , komandni rejected bit se postavlja u TransducerChannel statusno – kondicionom registru, a komanda se ignoriše.

Komande iz ove klase su prikazane u tabeli 17.

TIM će biti u aktivnom stanju ako se bilo koja od ovih komandi primi od strane TransducerChannel – a. U suprotnom, tj. ako se TIM ne nalazi u aktivnom stanju, komandni rejected bit se postavlja u TIM statusno – kondicionom registru i komanda se ignoriše.

Sve komande iz ove klase zahtevaju da destinacioni TransducerChannel broj bude veći od nule. U suprotnom, komandni rejected bit se postavlja u TIM statusno – kondicionom registru i komanda se ignoriše.

Table 17. - Transducer operating state commands

Cmd Function Id

Command Address class

Reply expected

Required/ optional Transducer

Channel Proxy

Group/ global

0 Reserved — — — — — 1 Read Yes Yes No Yes See




TransducerChannel data-set segment

NOTE

2 Write TransducerChannel data set segment

Yes Yes No No See NOTE

3 Trigger command Yes Yes Yes No Required 4 Abort Trigger Yes Yes Yes No Optional 5-127 Reserved — — — — — 128 -255 Open for manufacturers — — — — — NOTE - A Read TransducerChannel data set segment command is required for sensors. A Write TransducerChannel data set segment command is required for an actuator.

Read TransducerChannel data-set segment

Argument : DataSetOffset : tip podatka UInt32

Ova komanda se koristi za čitanje segmenta podataka. Ima samo jedan argument. Ovaj argument specificira ofset odakle treba da počne čitanje segmenta. Pošto maksimalna veličina oktetnog niza, koji može biti primljen u toku fizičkog transporta, manja od maksimalne veličine celine podataka, ofset se koristi za pronalazak mesta unutar podataka odakle treba početi čitanje.

Odgovor na Read TransducerChannel data-set segment komandu koristi Replay message strukturu (6.3). Replay – dependent okteti koji se dobijaju kao odgovor u okviru dijagrama (replay message) imaju strukturu opisanu u 6.3. Kao što je prikazano u tabeli 18, prvo polje sadrži ofset u segmentu podataka odakle je preuzet blok podataka i u najvećem broju slučajeva on se poklapa sa Data-set Segment Offset – om u okviru TransducerChannel data-set segment

komande. Preostali okteti sadrže pročitane podatke. Odgovor treba da sadrži sve jedinice u data

set segment ofset – u i sve nule ako je data set prazan. Broj okteta koji se vraća je funkcija dizajna TransducerChannel – a , i NCAP treba da odredi broj iz argumenata API metoda koji se koristi za povratnu poruku. Ako je ReadSensorOffset veći od broja okteta u data set – u , ReadSensorOffset u odgovoru treba da bude isti kao i maksimalan broj okteta u data set – u i odgovor će sadržati nula oktete.

Table 18. - Read TransducerChannel data set segment reply arguments

Field Data type Argument attribute name Function 1 UInt32 ReadSensorOffset Data set offset (0 to [current size - 1]) - This is the

address relative to the beginning of the data set at which reading of the data shall begin.

2 N*UInt8 ReadSensorData The block of data read from the sensor.

Ako se TransducerChannel nalazi u bilo kom streaming transmission modu, komandni rejected bit se postavlja u statusnom registru a komanda se ignoriše.




Ako je odredišni TransducerChannel broj u nizu okteta jednak nuli, komandni rejected bit se postavlja u TIM statusno – kondicionom registru i komanda se ignoriše.

Write TransducerChannel data-set segment

Argument : WriteActuator

Ova komanda se koristi za upis bloka podataka u TransducerChannel preko bilo kog prethodnog sadržaja. Argumenti ove komande su opisani u tabeli 19.

Pošto maksimalna veličina oktetnog niza, koji može biti primljen u toku fizičkog transporta, manja od maksimalne veličine celine podataka, ofset se koristi za pronalazak mesta unutar podataka odakle treba početi upis. Ako je WriteActuatorOffset veći od maksimalne dužine u data

set – u , podaci se odbacuju i komandni rejected bit se postavlja u statusnoj reči.

Table 19. - Write TransducerChannel data set segment command data field

Held Data type Argument attribute name Function 1 UInt32 WriteActuator.Offset Data set offset (0 to [current size - 1]) - Tbis is the address relative to the beginning of the data set at which writing of the data shall begin.

2 N*UInt8 WriteActuator.DataBIock Data block

Ako TransducerChannel radi u streaming modu, komandni rejected bit se postavlja u statusnom registru a komanda se ignoriše. Ako je odredišni TransducerChannel broj u nizu okteta jednak nuli, komandni rejected bit se postavlja u TIM statusno – kondicionom registru i komanda se ignoriše.

Trigger komanda

Ova komanda nema argumenata a izaziva trigerovanje. Može biti adresirana ka TransducerChannel – u, TransducerChannel proxy, AddresssGroup ili globalno. Ako se adresira globalno, ona treba da trigeruje svaki trigger-enabled TransducerChannel u okviru TIM –a. Ako je TransducerChannel senzor, TransducerChannel treba da se ponaša prema Sensor

Triggerind State dijagramu. U slučaju da je TransducerChannel aktuator, TransducerChannel treba da se ponaša prema Actuator Triggerind State dijagramu.

Abort trigger

Ova komanda prekida trigerovanje. Ako je TransducerChannel senzor, TransducerChannel treba da se ponaša prema Sensor Triggerind State dijagramu. U slučaju da je TransducerChannel

aktuator, TransducerChannel treba da se ponaša prema Actuator Triggerind State dijagramu.




Ova komanda nema argumenata. Takođe, može biti adresirana ka TransducerChannel – u, TransducerChannel proxy, AddresssGroup ili globalno. Ako se adresira globalno, ona treba da prekine trigerovanje svakog triggered TransducerChannel – a u okviru TIM –a.

4.1.4 Transducer either idle or operating state komande

Komande u ovoj klasi mogu biti izdate TransducerChannel – u u bilo koje vreme pošto on napusti Transducer Initialization stanje. Komande u ovoj klasi su date u tabeli 20.

Table 20. - TransducerChannel idle or operational state commands

Ako bilo koja opciona komanda ove klase bude poslata TransducerChannel – u koji ne podržava tu komandu, komandni rejected bit se postavlja u TransducerChannel statusno – kondicionom

Cmd Function Id

Command

Address class

Reply expected

Required/ optional Transducer

Channel Proxy

Group/ global

0 Reserved —

1 TransducerChannel Operate Yes Yes Yes No Required 2 TransducerChannel Idle Yes Yes Yes No Required 3 Write TransducerChannel

trigger state Yes Yes Yes No Optional

4 Read TransducerChannel trigger state

Yes Yes Yes No Required

5 Read TransducerChannel data repetition count

Yes No No Yes See NOTE 1

6 Read TransducerChannel pre-trigger count

Yes No No Yes See NOTE 2

7 Read AddressGroup assignment

Yes Yes No Yes Required

8 Read Sampling mode Yes Yes No Yes Optional 9 Read data transmission mode Yes Yes No Yes 10 Read buffered state Yes Yes No Yes Optional 11 Read end-of-data-set ope ration Yes Yes No Yes Optional 12 Read actuator halt mode Yes Yes No Yes Optional 13 Read edge-to-report mode Yes Yes No Yes Optional 14 Read TransducerChannel initiate

trigger state Yes No No Yes Optional

15 Read TransducerChannel initiate trigger configuration

Yes No No Yes Optional

16 Device clear Yes Yes Yes No Optional 17-127 Reserved — — — — — I28-255 Open for manufacturers — — — — — NOTE t—This function is required if the Set TransducerChannel data repetition count is implemented. NOTE 2—This function is required if the Set TransducerChannel pre-trigger count is implemented.




registru, a komanda se ignoriše. Sve komande ove klase zahtevaju destinacioni TransducerChannel broj veći od nule. U suprotnom, komandni rejected bit u TransducerChannel statusno – kondicionom regestru se postavlja i komanda se ignoriše.

TIM treba da bude u aktivnom stanju za bilo koju od ovih komandi.

TransducerChannel operate

Ova komanda izaziva TransducerChannel koji je u Transducer Idle stanju da pređe u Transducer Operating stanje. Ako se TransducerChannel već nalazi u ovom stanju, komanda se ignoriše. Ova komanda nema argumenata.

TransducerChannel idle

Ova komanda primorava adresirani TransducerChannel da pređe u Transducer Idle stanje. Ako se TransducerChannel već nalazi u ovom stanju, komanda se ignoriše. Ova komanda nema argumenata.

Write TransducerChannel trigger state

Argument : TrigState : tip podatka Boolean

Ova komanda se koristi za uključivanje ili isključivanje trigerovanja TransducerChannel – a. Ima jedan argument, koji ako je potvrdan, trigerovanje se uključuje, u suprotnom isključuje. Ako TransducerChannel ne podržava trigerovanje a komanda se primu, komandni rejected bit se postavlja u statusno – dogadjajnom registru se postavlja i komanda se ignoriše.

Read TransducerChannel trigger state

Povratni argument : TrigState : tip podatka Boolean

Ova komanda se koristi da pročita stanje trigera TransducerChannel – a. Ima jedan argument, koji ako je potvrdan, trigerovanje je uključen, u suprotnom isključen. Ako TransducerChannel ne podržava trigerovanje, odgovor na ovu komandu treba da bude False.

Read TransducerChannel data repetition count

Povratni argument : RepCount : tip podatka Uint16

Ova komanda se koristi da pročita aktualni broj TransducerChannel data repetition counts, koji su dodeljeni adresiranom TransducerChannel – u. Ova komanda nema argumenata, međutim generiše odgovor u vidu jednog Uint16 argumenta.




Read TransducerChannel pre-trigger count

Povratni argument : PreTrigCount : tip podatka Uint16

Ova komanda se koristi da pročita aktualni broj TransducerChannel pre-trigger counts, koji su dodeljeni adresiranom TransducerChannel – u. Ova komanda nema argumenata, međutim generiše odgovor u vidu jednog Uint16 argumenta.

Read AddressGroup assignment

Povratni argument : GrpAssignment : tip podatka Uint16

Ova komanda se koristi za čitanje adresne grupe (AddressGroup) kojoj je dodeljen adresirani TransducerChannel. Komanda nema argumenata. Ipak generiše odgovor u vidu jednog Uint16 argumenta koji daje adrese adresne grupe kojoj je TransducerChannel dodeljen. Ako je vrednost ovog argumenta nula, to znači da TransducerChannel nije dodeljen ni jednoj adresnoj grupi.

Read sampling mode

Povratni argument : SampleMode : tip podatka Uint8

Ova komanda dozvoljava NCAP – u da odredi aktualni sampling mod u kojem TransducerChannel radi. Komanda nema argumenta, ali generiše odgovor u vidu jednog argumenta tipa Uint8. Lista mogućih vrednosti za ovaj argument je data u tabeli 12.

Read data transmission mode

Povratni argument : XmitMode : tip podatka Uint8

Ova komanda dozvoljava NCAP – u da odredi aktualni data transmission mod TransducerChannel – a.

Read buffered state

Povratni argument : BufferOnOff : tip podatka Boolean

Komanda nema argumenata, ali generiše odgovor u vidu jednog argumenta tipa Boolean. Ako je on tačan, baferovanje je uključeno, u suprotnom nije.

Read end-of-data- set operation mode

Povratni argument : EndDataSetMode : tip podatka Uint8




Ova komanda omogućava NCAP – u da odredi akciju koju će aktuator TransducerChannel preduzeti kada dođe do kraja seta podataka u slučaju da drugi set nije upisan dalje.

Komanda nema argumenata ali generiše odgovor u vidu jednog argumenta. Tabela 13 daje moguće vrednosti ovog argumenta.

Read actuator halt mode

Povratni argument : ActuatorHalt : tip podatka Uint8

Komanda nema argumente, ali generiše odgovor u vidu jednog povratnog argumenta. Tabela 14 daje moguće vrednosti ovog argumenta.

Read Edge-to-report mode

Povratni argument : EdgeReported : tip podatka Uint8

Komanda nema argumente, ali generiše odgovor u vidu jednog povratnog argumenta. Tabela 15 daje moguće vrednosti ovog argumenta.

Read TransducerChannel initiate state

Povratni argument : EventTrig : tip podatka Boolean

Komanda dozvoljava NCAP – u da odredi da li je događajni senzor TransducerChannel – a podešen da pokrene trigger komandu kada se promena desi. Ako senzor ili aktuator primi ovu komandu, automatski se postavlja Command rejected bit u statusnoj reči.

Komanda nema argumenata. Generiše odgovor u vidu jednog povratnog argumenta. Ako je vrednost povratnog argumenta tačna, senzor je uključen da počne trigerovanje kada se događaj desi. U suprotnom nije.

Read TransducerChannel initiate trigger configuration

Povratni argument : InitTrig : tip podatka Boolean

Ova komanda se koristi za čitanje informacije potrebne za dozvolu TransducerChannel – a da započne trigger komandu. Komanda nema argumenta, ali odgovor ima jedan povratni argument čije su moguće vrednosti pobrojane u tabeli 16.




Device clear

Ova komanda se koristi za brisanje svih ulaznih i izlanih bafera adresiranih TransducerChannel – a. Komanda nema ni ulaznih ni povratnih argumenata.

4.1.5 TIM sleep state komande

Sledeće komande mogu se izvršavati samo kada je TIM u sleep stanju. Tabela 21 daje pregled komandi ove klase.

Sve komande ove klase zahtevaju destinacioni TransducerChannel broj veći od nule. U slučaju da je on nula , komandni rejected bit se postavlja u TransducerChannel statusno–kondicionom registru, i komanda se ignoriše.

Table 21. - Sleeep state commands

cmdFunctionId Command Address class Reply expected

Required/ optional TIM Global

0 Reserved — — — — 1 Wake-up Yes No Yes Optional 2-127 Reserved — — — — 128-255 Open for manufacturers — — — —

Wake-up

Ova komanda prebacuje adresirani TIM u aktivno stanje.

Komanda nema argumenata. Odgovor na ovu komandu se uvek generiše nakon završetka operacije. Odgovor ima istu formu kao i odgovor na Read Status-Event Register komandu.

4.2 TIM active state komande

Sledeće komande mogu se izvršavati samo kada je TIM u active stanju. U suprotnom, komandni rejected bit u TIM statusno-kondicionom registru se postavlja, i komanda se ignoriše.

Sve komande ove klase zahtevaju destinacioni TransducerChannel broj jednak nuli. U slučaju da je različit od nule , komandni rejected bit se postavlja u TIM statusno–kondicionom registru, i komanda se ignoriše.




Table 22. - TIM active state commands


Required/ optional TIM Global

0 Reserved — — — — 1 Read TIM version Yes No Yes Required 2 TIM Sleep Yes No No Optional 3 Store operational setup Yes No No Required 4 Recall operational setup Yes No No Required 5 Read 1EEE 1451.0 Version Yes No Yes Required 6-127 Reserved — — — — 128-255 Open for manufacturers — — — —

Read TIM version

Povratni argument : TIMVersion : tip podatka Uint16

Komanda se koristi za čitannje verzionog broja TIM – a. Nema argumenata, ali generiše jedan povratni argumenat. Vrednost ovog argumenta je ručno definisani TIM verzioni broj.

TIM sleep

Ova komanda stavlja adresirani TIM u low-power stanje u kojem reaguje samo na wake-up komandu.Nema ulaznih i povratnih argumenata.

Store state

Argument : StorState[N], 0 N : tip podatka Uint8

Ova komanda se koristi da pokrene TIM i sve TransducerChannel u okviru TIM – a da skladište njihove state informacije tako da je moguća restauracija ovih informacija prilikom svakog setup-a. Postoje dva uslova prilikom kojih se vrši restauracija :

1. Potvrda recall state komande 2. Povratak iz kvara na napajanju

Komanda ima jedan argument tipa UInt8 i on služi da identifikuje stanje. Power-up stanje treba da bude nula. Ova komanda nema odgovor.

Store state

Argument : StorState[N], 0 N : tip podatka Uint8

Ova komanda se koristi da vrati setup TIM – a i svih TransducerChannel – a u okviru TIM – a u stanje u kojem su bili pre nego što je primljena komanda Store State.




Komanda ima jedan argument tipa UInt8 i on služi da identifikuje stanje koje se opoziva. Nema odgovora na ovu komandu.

Read the IEEE 1451.0 version

Povratni argument : StandardVersion : tip podatka Uint8

Komanda se koristi da pročita verziju ovog standarda podržanog od strane TIM – a. Ova komanda nema argumenata. Odgovor na ovu komandu treba da ima jedan oktet sa verzionim brojem IEEE 1451.0 kako je objašnjeno u tabeli 23.

Table 23. - Enumeration of IEEE 1451.0 version numbers

Standard version IEEE 1451.0 standard version 0 Reserved for prototype or other nonstandard IEEE 1451.0 versions 1 This will correspond to the original release of this standard 2-127 Reserved for future releases of the standard 128-255 Open to manufacturers

4.3 TIM any state komande

Sledeće komande se mogu izvršavati kada je TIM u bilo kojem stanju. Tabela 38 daje listu komandi iz ove klase.

Sve komande iz ove klase zahtevaju destinacioni TransducerChannel broj jednak nuli. Ako ovaj broj nije jednak nuli, komandni rejected bit se postavlja u TransducerChannel statusno kondicionom registru a komanda se ignoriše.

Table 24. -TIM any state commands


Required/ optional

TIM Global

0 Reserved — — — —

1 Reset Yes No No Optional

2-127 Reserved — — — —

128-255 Open for manufacturers — — — —

Reset

Ova komanda se koristi da resetuje TIM i sve TransducerChannel - e povezane sa TIM – om. Pošto je ova komanda prosleđena TIM – u, TIM i svi TransducerChannel – i povezani sa njim treba da pređu u initialization/ boot-up stanje. Ako su stanja ili stanje već bili skladišteni pomoću Store State komande, onda će stanje 0 biti restornirano tokom inicijalizacije. Komanda nema argumenata i ne zahteva odgovor.




4.4 Ručno definisane komande

Korisnik može uključiti i nestandardne komande koje su mu potrebne tako što će ih sam implementirati. Korisnik je znači odgovoran za kompletan softver u tom slučaju.

5. Struktura poruka

Ovaj pasus definiše strukturu poruka koje se šalju preko Komunikacionog Interfejsa (Module Communication Interface).

5.1 Redsosled slanja podataka i značenje bitova

Redosled slanja podataka i hedera ovde opisan, je objašnjen i učinjen na oktetnom nivou. Naredna tabela, pokazuje slanje okteta po redu kako su numerisani.

Kada smo na nivou okteta, bit koji se nalazi skroz levo je bit najveće težine. Sledeća tabela daje primer.

5.2 Struktura komandne poruke

Struktura komandne poruke je data u tabeli.




Destinacioni TransducerChannel broj

Ovo polje daje 16 – bitni TransducerChannel broj za odredište ove poruke.

Komandna klasa

Komandne klase su definisane u poglavlju 4.

Komandna funkcije

Komandne funkcije su definisane u poglavlju 4. One se posmatraju u okviru komandnih klasa.

Dužina

Ovo polje daje brij komandno – zavisnih okteta u poruci. Ako dužina primljene poruke ne odgovara dužine naznačenoj u ovom polju za primljenu poruku, poruka se briše i bit greške se postavlja u statusnom registru.

Komandno – zavisni okteti

Ovo polje sadrži informacije koje treba da budu definisane za ovu komandu. Objašnjeno u poglavlju 4.

5.3 Povratne poruke

Ove poruke se koriste kao odgovor na primljenu komandu. Format ovih poruka je dat u tabeli.




Success/Fail fleg

Ako je ovaj oktet nenulti, to indicira da je komanda uspešno isvršena. U slučaju da je nula, došlo je do neuspeha i potrebno je pronaći uzrok greške.

Dužina

Ovo polje daje broj okteta u povratnoj poruci. Ako se ovaj broj, u datom polju poruke, ne poklapa sa stvarnim brojem povratnih okteta, poruka se briše i bit greške se postavlja u statusnom registru.

Reply-dependent okteti

Ovo polje sadrži informacije koje moraju biti definisane za ovu komandu. Objašnjeno u prethodnim poglavljima.

Struktura TIM initiated poruke

Format poruke koja je inicirana od strane TIM – a je dat u sledećoj tabeli. Primer ovakvih poruka su statusne poruke.




Source TransducerChannel broj

Ovo polje daje 16 – bitni TransducerChannel broj kao izvorište poruke. Ostala polja su ista kao i kod komandnih poruka.

6. Komunikacioni interfejs

Komunikacija između NCAP – a i TIM – ova ili između TIM – ova je upravljana od strane Module Communication API. Četiri aspekta ovog API – ja su:

1. Komunikacija može biti jednosmerna od inicijatora ka cilju, ili dvosmerna, gde inicijator šalje komandu ka prijemniku koji onda šalje odgovor.

2. Komunikacija može biti od jednog izvora ka jednom prijemniku ( one-to-one ), kada su samo dva uređaja uključena u komunikaciju, ili od jednog izvora ka više prijemnika (one-

to-many). Ovaj vid komunikacije gde više prijemnika učestvuje može biti samo jednosmeran.

3. Komunikacija može biti ili default ili special Quality of Service. Default je najisplativiji vid komunikacije.

4. Fizički interfejs može biti prosto point-to-point link ili mrežni gde više uređaja deli komunikacioni medijum.

Ovaj modul API – ja je podeljen u tri glavna interfejsa : Comm, Registration, Receive. Comm

interfejs je implementiran od strane IEEE 1451.X sloja i poziva se od strane IEEE 1451.0 sloja i služi za kontrolu komunikacije između NCAP – a i TIM - ova. Registration interfejs se implementira od strane IEEE 1451.0 sloja i poziva od strane IEEE 1451.X sloja. Služi za samoregistraciju i za prijavu željene destinacije. Receive interfejs se implementira od strane IEEE 1451.0 sloja i poziva od strane IEEE 1451.X sloja kada se primi komunikaciona poruka od strane IEEE 1451.X sloja preko linka.




Svaki od ovih interfejsa je posebno podeljen na dva podinterfejsa : jedan za slučaj point-to-point

komunikacije kada NCAP i TIM direktno komuniciraju, i network slučaj kada NCAP i više TIM – ova komunicira. Prefiksi P2P i Net se koriste za razlikovanje ova dva slučaja.

6.1 Simetrični API

Ovakvi API – ji koji su simetrični podržavaju NCAP – TIM, TIM – NCAP i opciono TIM – TIM komunikaciju. Svaka komunikacija počinje od strane početnog čvora koji šalje poruku ka jednom ili više prijemnih čvorova. Opciono, prijemni čvorovi mogu vratiti odgovarajući odgovor početnom čvoru.

Moguću scenariji su sledeći :

Dvosmerna/jedan na jedan : Primer : NCAP izdaje read TEDS komandu ka specificiranom TIM – u . TIM odgovara TEDS – u.

Jednosmerna/jedan na jedan : Primer : TIM generiše periodična merenja koje šalje kasnije NCAP –u.

Jednosmerna/jedan ka više : Primer : NCAP izdaje više triger komandi ka TIM – ovima koji učestvuju u merenju.

6.2 Izbor implementacije

NCAP i TIM-ovi mogu napraviti različite izbore u smislu koje interfejse implementirati, a i dalje vršiti međusobnu komunikaciju. Ključno pitanje je da li uređaj treba da komunicira sa više drugih uređaja, ili se radi samo o jednoj destinaciji. Zastareli način zahteva sigurno implementiranje NetComm interfejsa. Kasnije se implementirao P2PComm interfejs. Uređaj koji samo prima poruke i odgovara na njih takođe mora da implementira P2PComm interfejs.

Drugo pitanje jeste da treba razmotriti koliko različitih IEEE1451.X komunikacionih putanja podržava uređaj i da li su one statiče ili dinamičke. Najčešće se radi o jednoj putanji. Prema tome, software build process (npr. linker) se koristi da poveže IEEE1451.X implementaciju sa IEEE1451.0 implementacijom. Ovo negira potrebu za korišćenjem nekih metoda Registration interfejsa.

Malo kompleksniji uređaji obezbeđuju fiksan set IEEE1451.X komunikacionih putanja. Opet, pošto su ove putanje poznate tek u vreme ’bildovanja’, software build process (npr. linker) se može koristiti za upravljanje registracijom. IEEE 1451.0 sloj je odgovoran za korišćenje ispravne IEEE 1451.X instance kada se vrši komunikacija.




Najmoderniji uređaji mogu biti sposobni za dinamičko upravljnje sa IEEE1451.X. U ovom slučaju, dinamički registracioni mehanizam dozvoljava IEEE1451.X implementaciji da obavesti IEEE1451.0 sloj da je slobodan. Ovo je pogodno i za P2Pcomm i za NetComm situaciju.

Uređaj koji je povezan sa IEEE1451.X mrežom i treba da započne komunikaciju sa više od jedne destinacije treba da implementira NetComm interfejs. Interfejs obezbeđuje dodatne metode i parametre da bi mogao uspešno upravljati simultanom komunikacijom sa više destinacija.

6.3 Primeri implementacija

Najprostiji primer jeste kada TIM prosto odgovara na zahtev NCAP – a. Ovo se vrši preko point-to-pont linka (npr. IEEE1451.2-RS232) ili preko network fizičkog linka (npr. 1451.5-2007). Sa tačke gledišta TIM – a on samo odgovara na zahtev. Nikada ne započinje komunikaciju. Pošto su komunikacioni zahtevi tako prosti, TIM IEEE1451.X implementacija zahteva P2Pcomm interfejs. Dakle, pošto postoji samo jedna IEEE 1451.X Comm

implementacija, registracija se obavljapreko statičkog linka koji je obezbeđen kroz software

build process.

Sledeći primer je prosti NCAP sa jednom point-to-pont konekcijom komunicira sa TIM – om (npr. IEEE 1451.2-RS232). Ovde NCAP IEEE1451.X implementacija takođe obezbeđuje P2PComm interfejs. IEEE 1451.X ka IEEE 1451.0 link se obezbeđuje kroz software build

process.

Kompleksniji primer je NCAP sa višestrukom point-to-point fizičkom konekcijom (npr. višestruki IEEE 1451.2-RS232 portovi ). U ovom slučaju potrebne su višestruke IEEE 1451.X instance, jedna za svaku fizičku konekciju. IEEE 1451.0 implementacija NCAP – a je odgovorna za korišćenje odgovarajućeg IEEE 1451.X interfejsa prilikom komunikacije sa svakim TIM – om.

Najkompleksniji NCAP mora da obezbedi višestruke fizičke interfejse različitih tipova, a konfiguracija je dinamička. Svaki fizički interfejs treba da ima ili P2PComm ili NetComm instance. Ove instance se registruju dinamički tako da 1451.0 sloj zna kada su one dostupne.

6.4 Čvorni komunikacioni parametri

U NetComm konfiguraciji, svaki čvor u mreži se identifikuje uz pomoć IEEE1451.X čvornih komunikacionih parametara. Na primer, kod IEEE 1451.5-802.11, svaki čvor ima jedinstvenu IP adresu i mrežni portovi su alocirani za IEEE 1451.0 komunikaciju. Svaka IEEE1451.X tehnologija ima različit set potrebnih parametara.

Iako je priroda ovih parametara specifična za svaku IEEE1451.X tehnologiju, IEEE1451.0 sloj zahteva mogućnost provere i prosleđivanja parametara u sistemu u generičkoj




formi. Funkcija getNodeParams() se koristi za smeštanje ovih parametara u ArgumentArray. Ona dakle, vraća parametzre iz lokalnog IEEE1451.X sloja.

6.5 Destinacioni identifikacioni destId parametar

U IEEE1451.0 sloju, jedan NCAP i povezani TIM – ovi formiraju logičku komunikacionu grupu. Svakomčvor ( bilo NCAP ili TIM) je dodeljen jedinstveni Uint16 ID od strane IEEE1451.0 sloja sa NCAP strane. Vrednost 0x0000 je rezervisana za broadcast adresu, a vrednost 0x0001 je ‘svojstvena’ NCAP adresa.

Sa NCAP strane, IEEE1451.X sloj je odgovoran za otkrivanje svih TIM – ova u komunikacionoj grupi i za njihovo registrovanje sa NCAP strane IEEE1451.0 sloja pozivom funkcije registerDest(). IEEE1451.0 sloj će dodeliti jedinstveni destId, i IEEE1451.X sloj će pokupiti odgovarajuće čvorne informacije. Na primer, IEEE 1451.5-802.11 implementacija dovodi u vezu destId sa udaljenom čvornom IP adresom i brojem porta.

Sa strane TIM – a, IEEE1451.X sloj mora da zna kako da vrši komunikaciju sa svojstvenim NCAP – om koristeći destId 0x0001.Ne zahteva se nikakva registracija sa TIM strane IEEE1451.0 sloja.

Kao opcija, u slučaju da TIM inicira komunikaciju sa različitim destinacijama, IEEE1451.0 komanda je obezbeđena sa TIM strane da bi obavila neophodnu konfiguraciju. ArgumentArray koji se dobija funkcijom getNodeParams() za destinacioni TIM (ili grupu) se prosleđuju ka inicirajućem TIM – u IEEE1451.0 sloja. Ova informacija se prosleđuje dalje ka TIM – u IEEE1451.X sloja sa pozivom funkcije addDestination() , gde on dobija privatne mrežne informacije. U ovom slučaju, IEEE1451.X sloj sa inicirajućem TIM – u ne poziva IEEE1451.0 registerDest()funkciju.

Pošto je destId 0x0000 rezervisan kao broadcast adresa za komunikacionu grupu, on se samo koristi za jednosmerne poruke kada treba obavestiti sve čvorove u okviru grupe.

6.6 Komunikacioni commId parametar

Kada se inicira komunikacija, IEEE1451.0 sloj će aktivirati open() ili openQoS() funkcije i specificirati parametre destId i commId. Ako pozivi ovih funkcija budu uspešni, IEEE1451.0 će referistati toj akciji postavljanjem parametra commId. Kada IEEE1451.0 sloj obavi svoje, poziva se funkcija close() da bavesti IEEE1451.0X sloj da je aktivnost završena i da IEEE1451.X elementi mogu biti sigurno korišćeni.

Opciono, IEEE1451.X sloj može podržavati višestruke open() pozive ka istim ili različitim destinacijama. Kada IEEE1451.X dostigne mrežne ili memorijske limite, potrebno je da generiše propisne neuspele kodove. IEEE1451.0 sloj treba da pokuša da pozove call() funkciju da IEEE1451.X izvor pre poziva nove open() funkcije.




Za podršku višestrukih open() funkcija, IEEE1451.X dozvoljava preklapanje komunikacija koje najčešće rezultuju poboljšanjem karakteristika. Ovo svojstvo je opcione prirode.

U slučaju kada je čvor u prijemnom stanju, IEEE1451.X poziva notifyMsg() metod ka IEEE1451.0 sloju i obezbeđuje jedinstveni commId parametar. U ovom slučaju, funkcija open() se ne poziva sa prijemne strane. IEEE1451.0 sloj će koristiti taj commId da pročita dolazeće mrežne podatke preko poziva readMsg() funkcije. Opciono, IEEE1451.0 će koristiti taj commId

da pošalje odgovor nazad inicijalnom čvoru. IEEE1451.0 sloj neće pozvati close() funkciju za ovaj commId zato što ovim rukovodi IEEE1451.X sloj.

6.7 Parametar poruke msgId

Kada se inicira komunikacija posle uspešnog poziva funkcije open() ili openQoS(),IEEE1451.0 sloj će početi komunikaciju pozivom metoda writeMsg(). IEEE1451.0 sloj će obezbediti odgovarajući commId tako da IEEE1451.X sloj zna koju komunikakcionu akciju da preduzme. IEEE1451.0 sloj će takođe specificirati jedinstveni msgId tako da IEEE1451.X sloj zna kako da dovede u vezu ( poveže ) odgovor sa odlazećem porukom. IEEE1451.X sloj je odgovoran za keširanje ovih ID – ova da bi ih iskoristio u notifyRsp() pozivu funkcije kada IEEE1451.0 sloj primi odgovor.

Opciono, IEEE1451.X sloj može podržavati višestruke pozive funkcija writeMsg() sa istim parametrom commId ali sa različitim msgId. Ovo omogućava preklapanje komunikacija u istoj komunikacionoj sesiji i može rezultirati znatnim poboljšanjem performansi. Kada IEEE1451.X sloj dostigne memorijske i mrežne limite, dolazi do neuspelog sledećeg pokušaja poziva funkcije writeMsg(). IEEE1451.0 sloj čeka dok odgovor ne bude primljen pre budućeg poziva funkcije writeMsg().

6.8 Memorijska ograničenja implementacije

Dizajn ovih API funkcija je namenjen njihovom radu na uređajima koji imaju ozbiljne RAM memorijska ograničenja kao što je npr. 8 – bitni PIC mikroprocesor. Kada IEEE1451.0 sloj poziva metode koje čitaju ili upisuju OctetArray (nizove okteta) iz/u IEEE1451.X sloj (readMsg(), readRsp(), writeMsg(), writeRsp()), IEEE1451.0 sloj će uvek specificirati maksimalan broj okteta koji može proslediti ili primiti. Višestruki pozivi ovih metoda mogu zahtevati transfere velikih nizova okteta (OctetArrays). Fleg last se koristi da signalizira kada je kompletirani OctetArray poslat.

U ovim memorijski – zavisnim situacijama, veoma je važno da IEEE1451.X sloj obezbedi mehanizam protoka okteta kroz mrežu. Banalan primer je memorijski zavisan TIM koji izvodi operaciju upisa. Ako je TEDS blok veći od dostupne memorije sa TIM strane, potrebno je da IEEE1451.0 sloj sa TIM strane čita OctetArray u delovima kroz readRsp() pozive. Svaki deo se upisuje u odgovarajuće trajno skladište memorije (npr. fleš). Ovo može uzeti puno vremena




ako se fleš mora obrisati. U svakom slučaju, IEEE1451.X sloj ima obavezu da čeka dok IEEE1451.0 sloj ne obavi sledeći poziv readMsg() funkcije. Obično, ovo zahteva da IEEE1451.X razmenu kontrolnih poruka između NCAP – a i TIM – a.

6.9 Komunikaciona sekvenca

Dijagram na slici 17 ilustruje tipičnu pozivajuću sekvencu između inicirajućeg i prijemnog čvora za jednosmerne operacije. Informacije teku od IEEE1451.0 sloja inicirajućeg čvora ka IEEE1451.0 prijemnom čvoru.

Ovaj primer podrazumeva da prijemna strana ima dovoljno memorije za višestruke pozive readMsg() funkcija. Takođe, ilustrovano je korišćenje IEEE1451.X niti za prijemno procesiranje. Funkcija notifyMsg() sepoziva samo po završetku procesiranja sa prijemne strane. Takođe, openQoS() funkcija se poziva u cilju obezbeđivanja ‘ kvaliteta servisa ’ zahteva IEEE1451.X sloja.

Sa strane inicijalnog čvora, IEEE1451.0 sloj poziva openQoS(), writeMsg(),close() funkcije. Sa druge strane, prijemni čvor, IEEE1451.X poziva receiveMsg() metod da obavesti IEEE1451.0 sloj da je nova komunikacija počela. IEEE1451.0 sloj odgovara IEEE1451.X sloju sa dva readMsg() poziva da bi dobio informacije u etapama. Funkcije openQoS(), close(), open() se pozivaju samo od strane inicirajućeg čvora.

Iako je samo jedna asinhrona poruka predstavljena između dva IEEE1451.X sloja, tačnije imeđu inicirajućeg i prijemnog čvora, stvarni broj mrežnih poruka je izvan domašaja ovog standarda. IEEE1451.X sloj može zahtevati da pošalje numerisane mrežne poruke u oba pravca da bi kompletirao komunikacioni ciklus. Pitanja protoka, kontrole, segmentacije, gomilanja podataka su pitanja o kojima se mora voditi računa.

Dijagram na slici 18 ilustruje dvosmernu razmenu podataka između IEEE1451.0 sloja sa inicirajuće strane i IEEE1451.0 sloja sa prijemne strane za Network slučaj. Prijemna strana generiše odgovor koji se prosleđuje inicirajućoj strani ( čvoru ). Za ilustraciju svrhe, funkcija open() se koristi zato što je default ‘ kvaliteta servisa ’ prihvatljiv za inicijatora komunikacije.

U slučaju da se zahtevaju poboljšane performanse, savetuje se da se koristi više-nitna arhitektura da bi se prilagodilo preklapanje komunikacionih procesa. Primećuje se da se notifyMsg() i notifyRsp() funkcije ne blokiraju za vreme trajanja procesa. Implementacija treba da obezbedi mehanizme buđenja ili pokretanja procesnih niti tako da se obave neophodni procesi.




Na dijagramima, vreme teče ‘ na dole ’. Standardne blokirajuće funkcije ili metodi su predstavljne punom strelicom sa punim zaglavljem. Povratne akcije su predstavljene crticama – otvorenim strelicama. Za asinhrone funkcije, korišćene su pune strelice sa otvorenim zaglavljem.

Slika17. – Jednosmerna komunikaciona sekvenca

Slika18. – Dvosmerna komunikaciona sekvenca




7. Uvod u IEEE 1451.0 API

Dve API funkcije su definisane u ovom standardu. Ovaj paragraf defniše opšte aspekte API funkcija. ’’ Trancducer Services Interfaces ’’ objašnjen u paradrafu 10 je NCAP-only API koji se koristi kada je u pitanju merenje ili kontrolne aplikacije za pristup IEEE 1451.0 sloju. Ovaj API sadrži metode za čitanje i upis TrancducerChannels, za čitanje i upis TEDS, za slanje konfiguracije, i operacione komande za TIMs. Takođe, interfejs je tako definisan tako da se može implementirati aplikacijama koje podržavaju neblokirajuće čitanje i upisne operacije kao i prijem mernih podataka .

Ove API definicije su obezbeđene za sisteme koje imaju vidljive interfejse i čije su strukture monolitne za TIMs i NCAPs, one sa jednim setom hardvera i softvera bez obzira na karakteristike različitih interfejsa između IEEE 1451.0 i IEEE 1451.X sistema. One su takođe opcione sve dok su poruke na vidljivim interfejima u skladu sa ostatkom standarda. Ovako definisane API funkcije omogućavaju lakši način implementacije kao i to da različiti korisnici mogu obezbediti različite funkcionalnosti.

’’ Module Communication Interface ’’ ili Komunikacioni servisni interfejs je virtualni sloj između standarda i neke druge famulije 1451 tipa. To je simetrični interfejs koji se implementira sa obe strane (i NCAP i TIM). Ove API funkcije sadrže metode koje se implementiraju od strane IEEE 1451.X sloja i koje poziva ovaj standard da bi inicirao komunikaciju. Takođe ove API funkcije sadrže i metode koje se implementiraju od strane standarda i koje poziva IEEE 1451.X sloj da bi dobio korisne podatke.

Veza između interfejsa i drugih entiteta IEEE 1451 je data na slikama 19, 20.

7.1 Ciljevi API-ja

Osnovni ciljevi koji se moraju ostvariti korišćenjem API funkcija su :

1. Obezbediti API funkcije koje se dobro slažu sa potrebama mernih sistema zasnovanih na IEEE 1451 .

2. Obezbediti takve API funkcije da olakšaju interakciju između mernih i kontrolnih aplikacija na NCAP i TIM-u. Ključna opsluživanja :

• Pronalazak TIM-a

• Pristup pretvaraču

• Kontrola pretvarača

• TEDS kontrola




3. Obezbediti abstraktnu komunikaciju koja je nezavisna od podsloja IEEE 1451.X tehnologije

4. Prilagoditi širinu opsega korišćenja poznatog IEEE 1451.X određenih komukikacionih tehnologija i dozvoljene IEEE 1451.X grupe koje koriste najpogodnije mehanizme komunikacije.

5. Prilagoditi širinu opsega korišćenja poznatih CPU i RAM memorija dostupnih za NCAP i TIM, sa veoma malim (sličnim PIC-u) 8-bitnim mikroprocesorima.

6. Obezbediti izlazne ili prekidne mehanizme gde IEEE 1451.X sloj može prekinuti komukikaciju sa mrežnim slojem.

7. Da obezbedi mehanizme prolaska gde ’’ pametne ’’ aplikacije mogu da pošalju korisniku poruke (komande) kroz IEEE 1451.0 sloj u cilju obrade lokalno ili od strane udaljenog IEEE 1451.X sloja.

Slika19. – Prikaz protokola 1451 sa slojevima




Slika20. – Protokol 1451

8. Transducer service API

Servisni API modul (Transducer service API) obezbeđuje interfejs između aplikacija sa NCAP strane i funkcija definisanim ovim standardom.

Svi interfejsi se koriste primarno od strane mernih i kontrolnih aplikacija u okviru IDL modula. Takođe, ovaj servisni modul je podeljen u pet podinterfejsa koji su nabrojani u tabeli. Prva četiri interfejsa implementirana od strane ovog standarda se pozivaju od strane mernih aplikacija. Ako aplikacija zahteva dodatne opcione karakteristike, potrebno je implementirati AppCallback

interfejs, koji će ovaj standard pozvati.

Table 24 – Transducer Services API classes and intterfaces

Interface Description TimDiscovery Methods for applications to discover available IEEE 145.X communications

modules, TIMs, and TransducerChannels are organized in this interface. TransducerAccess When an application desires to access sensor and actuator TransducerChannels, it

will use methods on ths interface. TransducerManager Applications that need more control over TIM access will use methods on this

interface. For example, to lock the TIM for exclusive use and to send arbitrary commands to the TIM.

TedsManager Applications use methods on this interface to read and write TEDS. This class also manages the NCAP-sside TEDS cache information.

CommManager Handles access to the communication module on the local device.




AppCallback Applications that need advanced features need to implement this interface. For example, this allows the application to configure measurement streams and the IEEE 1451.0 layer will invoke appropriate callbacks in the application.

8.1 Podinterfejs TimDiscovery

Ovaj interfejs je implementiran od strane IEEE 1451.0 sloja i poziva se od strane aplikacija da bi se obezbedili mehanizmi pronalaska dostupnih TIM – ova i TransducerChannel

– a. Metode ove interfejsa su nabrojane u tabeli i njihov kratak opis je dat u nastavku.

Table 25 - TimDiscovery

IEEE1451dot0::TransducerServices::TimDiscovery Args::UInt16 reportCommModule(out Args::Uint8Array moduleIds); Args::UInt16 reportTims(in Args::Uint8 moduled, out Args::Uint16Array timIds) Args::UInt16 reportChannels(in Args::Uint16 timId, out Args::Uint16Array channelIds, out Args::StringArray names);

Metoda reportCommModule

UInt16 reportCommModule ( out Args : : UInt8Array moduleIds);

Ova metoda obaveštava o slobodnom komunikacionom modulu koji je registrovan ovim standardom. Naime, u ModuleCommunication postoji metoda registerModule() metod koji IEEE 1451.X sloj poziva kada je spreman za ovu operaciju. U ovoj metodi, IEEE 1451.0 sloj će dodeliti jedinstveni moduleId svakom IEEE 1451.X interfejsu.

Ovaj metod ima jedan izlazni parametar koji se vraća od strane 1451.0 sloja ka aplikaciji. Ovaj niz sadrži sve dostupne komunikacione module sa strane NCAP – a.

Metoda reportTims

UInt16 reportTims (in Args: :UInt8 moduleId, out Args : : UInt16Array timIds);

Ova metoda vraća dostupne TIM uređaje interfejsu. U ModuleCommunication postoji metoda registerDestination() metod koji IEEE 1451.X sloj poziva kada registruje novi TIM uređaj.

Metoda ima dva parametra. Ulazni parametar je ID željenog IEEE1451.0 komunikacionog modula. Izlazni parametar se vraća aplikaciji i sadrži sve dostupne TIM – ove ovog IEEE 1451.X modula.




Metoda reportChannels

UInt16 reportChannels (in Args: :UInt16 timId, out Args : : UInt16Array channelIds, out Args

: : StringArray names);

Ova metoda vraća listu TransducerChannel sa imenima za dati TIM.

Metoda ima tri parametra. Ulazni parametar je ID željenog TIM – a. Izlazni parametari se vraćaju aplikaciji i predstavljaju ID – ove TransducerChannel – a ovog TIM – a sa njihovim imenima.

8.2 Podinterfejs TransducerAccess

Interfejs TransducerAccess je obezbeđen od strane IEEE 1451.0 sloja i poziva se od strane aplikacije da obezbedi pristup ka TransducerChannel – ima. Za većinu aplikacija, radi se o metodama koje obavljaju TIM čitanje i operacije upisa. Da bi ovaj interfejs ostao mali, komplikovanije metode su smeštene u TransducerManager interfejs. Metode ovog interfejsa su pobrojane u sledećoj tabeli, a u nastavku je dat kratak opis pojedinih metoda čija je implementacija klučna za ovaj rad.

Table 26 – TransducerAccess methods

IEEE1451dot0::TransducerServices::TransducerAccess Args::UInt16 open(in Args::UInt16 timId, in Args::UInt16 channelId, out Args::UInt16 transCommId); Args::UInt16 openQoS( in Args::UInt16 tmId, in Args::UInt16 channelId, inout Args::QoSParams qosParams, out Args::UInt16 transCommId); Args::UInt16 openGroup( in Args::UInt16Array timIds, in Args::UInt16Array channelIds, out Args::UInt16 transCommId ); Args::UInt16 openGroupQoS( in Args::UInt16Array timIds, in Args::UInt16Array channelIds, inout Args::QoSParams qosParams, out Args::UInt16 transCommId); Args::UInt16 close( in Args::UInt16 transCommId); Args::UInt16 readData( in Args::UInt16 transCommId, in Args::TimeDuration time-out, in Args::Uint8 SamplingMode, out Args::ArgumentArray result); Args::UInt16 writeData(in Args::UInt16 transCommId, in Args::TimeDuration time-out, in Args::UInt8 Sampling Mode, in Args::ArgumentArray value); Args::UInt16 start ReadData( in Args::UInt16 trans CommId, in Args::TimeInstance triggerTime, in Args::TimeDuration time-out, in Args::Uint8 SamplingMode, in AppCallback callback, out Args::UInt16 operationId); Args::UInt16 start WriteData( in Args::UInt16 trans CommId, in Args::TimeInstance, triggerTime, in Args::TimeDuration time-out, in Args::Uint8 SamplingMode, in Args::ArgumentArray value, in AppCallback callback, out Args::UInt16 operationId); Args::UInt16 startStream( in Args::UInt16 trans CommId, in AppCallback callbac, out Args::UInt16 operationId); Args::UInt16 cancel( in Args::UInt16 operationId);

Metoda open

UInt16 open( in Args : : UInt16 timeId, in Args : : UInt16 channelId,




out Args : : UInt16 transCommId);

Ova metoda otvara komunikacioni kanal ka željenom TIM/TransducerChannel – u i vraća jedan izlazni parametar koji se koristi u kasnijim pozivima. Prvi ulazni parametar specificira željeni TIM. Drugi ulazni parametar specificira željeni TransducerChannel. Ovo polje dozvoljava adresiranje jednog TransducerChannel – a, TransducerChannel proksija, ili grupe TransducerChannel – a povezanih na NCAP. Ako adresiramo TIM, koristi se nulti TransducerChannel.

Kao što smo rekli izlazni parametar se vraća od strane IEEE1451.0 aplikaciji i koristi u kasnijim pozivima.

Metoda readData

UInt16 readData( in Args : : UInt16 transCommId, in Args : : TimeDuration timeout,

in Args : : UInt8 SamplingMode, out Args : : ArgumentArray result);

Ova metoda omogućava blokirajuće čitanje specificiranog TransducerChannel – a. Tip ArgumentArray može imati više atributa; svaki atribut se predstavlja odvojenim Argument tipom.

U slučaju da se radi o čitanju jednog TransducerChannel kanala, rezultat će biti tipa Argument. Pak, ako se radi o čitanju grupe TransducerChannel – a dolazi do uklještenja rezultata, i naš ArgumentArray sadrži po jedan Argument za svaki TransducerChannel u grupi. Njima se pristupa po numeričkom redu u nizu tako što se počinje od nulte pozicije.

Parametri:

transCommId - specificira koju komunikacionu sesiju koristi.

timeout – kazuje koliko dugo da čeka rezultate čitanja a da ne generiše grešku.

SamplingMode – specificira mehanizam trigerovanja.

result – vraćeni rezultati čitanja.

Metoda writeData

UInt16 writeData( in Args : : UInt16 transCommId, in Args : : TimeDuration timeout,

in Args : : UInt8 SamplingMode, in Args : : ArgumentArray value);

Ova metoda omogućava blokirajući upis u specificirani TransducerChannel. Tip ArgumentArray može imati više atributa; svaki atribut se predstavlja odvojenim Argument tipom.




U slučaju da se radi o upisu u jedan TransducerChannel, onaj koji poziva ovu funkciju obezbeđuje value tipa Argument. Pak, ako se radi o upisu u grupu TransducerChannel – a, biće uklještenih vrednosti ( value ), i naš ArgumentArray sadrži po jedan Argument za svaki TransducerChannel u grupi. Njima se pristupa po numeričkom redu u nizu tako što se počinje od nulte pozicije.

Parametri:

transCommId - specificira koju komunikacionu sesiju koristi.

timeout – kazuje koliko dugo da čeka rezultate čitanja a da ne generiše grešku.

SamplingMode – specificira mehanizam trigerovanja.

value – vrednosti koje trebaju biti upisane u odgovarajuće aktuatore.

9. Softverska implementacija funkcija Transducer

servisnog modula

Pošto smo se upoznali sa samim protokolom 1451.0 za pametne senzore, kao i sa važećim komandama, njihovom strukturom, potrebno je najpre dati algoritamsko rešenje implementacije pojedinih funkcija servisnog modula ovog protokola. Jasno je da se mora uzeti u obzir višenitni pristup problemu. Naime, jasno je da funkcije iz ovog modula imaju neke ulazne parametre i izlazne parametre koje dobijaju sa strane pametnih senzora, tj. sa TIM strane. U ovom master radu naš posao je bio da osmislimo softver sa NCAP strane. Konkretno, u svrhu testiranja napravljena je simulacija u smislu povratne informacije ( generišu se određeni dummy odgovori).

Dakle, pošto se mora uzeti u obzir da prilikom prosleđivanja komande na TIM stranu, inicijatorska strana ( NCAP ) mora da čeka dok se ne vrati odgovor, tj. prosledi rezultat, najverovatnije očitavanje sa nekog senzora, jasno je da u strukturi imamo najmanje dve niti (threads). Jedna glavna nit, koja čeka na prispeće odgovora, i druga koja obavlja raspakivanje komande i vraća određene rezultate NCAP strani.

Idejna realizacija funkcija servisnog modula je data u nastavku a kompletan kod u objektno-orijentisanom jeziku Java dat je u prilogu. Kod je urađen opšte, ali za potrebe provere kompletno je realizovana funkcija readData iz određenog seta funkcija Transducer service API, kao i simulator mreže.




9.1 Java i višenitno programiranje

Za razliku od mnogih drugih programskih jezika, u Javu je ugrađena podrška za višenitno programiranje (multithreaded programming). Višenitni program ima dva ili više delova koji mogu istovremeno da se izvršavaju. Svaki deo ovakvog programa naziva se nit, a svaka nit definiše poseban tok izvršavanja. Zbog toga višenitni rad predtsvalja posebnu varijantu višeprogramskog rada (multitasking).

Javin izvršni sistem se za mnoge poslove oslanja na programske niti a sve ugrađene biblioteke klasa prvenstveno su pravljene za višenitni rad. U stvari, Java pomoću programskih niti omogućava da čitavo okruženje bude asinhrono. Programske niti mogu da budu u više stanja. Nit može da bude u stanju izvršavanja. Ona može da bude spremna za izvršavanje čim joj se dodeli procesorsko vreme. Nit koja se izvršava može da bude suspendovana, čime se njena aktivnost prekida neko vreme. Suspendovana nit može da bude nastavljena pri čemu svoju aktivnost nastavlja od tačke gde je prekinuta. Takođe, nit može da bude blokirana kada čeka da pristupi resursu. U bilo kom trenutku nit može da se završi.

Zbog toga što višenitni rad uvodi asinhrono ponašanje u programe, morea postojati način da se niti sinhronizuju kada je potrebno. Na primer, ako želite da dve programske niti sarađuju i razmenjuju podatke. Dakle mora se obezbediti da se niti ne sukobljavaju. Za ovu svrhu Java

obezbeđujeelegantnu varijantu jednog starog modela za sinhronizovanje procesa : monitor. Konkretno, ovakav pristup je korišćen i u našem slučaju sinhronizacije niti u master radu. Monitor se može zamisliti kao jedna mala kutija u koju staje samo jedna programska nit. Kada u monitor uđe jedna programska nit sve druge moraju da čekaju dok ona ne izađe. Na taj način monitor sprečava da više niti istovremeno radi sa istim deljenim resursom.

Većina sistema za višenitni rad zahteva da vaš program izričito kontroliše monitore i da sa njima radi. Java nudi elegantno rešenje. Ne postoji klasa zvana Monitor već svaki objekat unapred sadrži sopstveni monitor u koji se automatski ulazi čim se pozove neka od sinhronizovanih metoda tog objekta. Kada se nit nađe unutar sinhronizovane metode, nijedna druga nit ne može da pozove bilo koju sinhronizovanu metodu istog objekta.

9.2 Implementacija servisnih funkcija – idejno rešenje

Na sledećoj slici je predstavljen grubi prikaz idejnog rešenja implementacije funkcija servisnog modula. Kao što je poznato i kako je prikazano, sa NCAP strane imamo servisni i komunikacioni modul. Kao što smo već rekli naš fokus predstavlja servisni modul.




Slika21. – Implementacija funkcija – opšta šema – idejno rešenje

Dakle, zamišljeno je da se svaka funkcija koja se poziva, iz glavne programske niti, formira svoju nit izvršavanja, kako je i prikazano. U okviru te niti, ona prolazi kroz određene faze, tj. stupnjeve. Moguće je za svaku od tih faza praviti zasebne niti, samo bi to dodatno




usložnjavalo problem. Znači, jasno je da se kroz tu nit mora izvršiti kreiranje komande na osnovu argumenata. Zatim izvršiti enkodovanje komande, tj. prebacivanjeu niz okteta (bajtova), da bi se kao takvi podaci spremili za prenos. I dalje se vrši, grubo rečeno, prosleđivanje podataka komunikacionom modulu, koji prozivanjem komande write() pokreće oktetni niz ka TIM – u. Onda se ova nit blokira dok joj se ne proslede rezultati merenja ukoliko ih očekuje od strane TIM – a. Kao što je prikazano, ova realizavija podrazumeva da može imati N niti, odnosno device – ova, kako je zamišljeno. Naime, u slučaju da želimo više komandi da prosledimo istom TransducerChannel – u, za njih se formira poseban uređaj (device). Te komande u okviru tog uređaja formiraju listu, tj. red čekanja. Komanda i njen receivingHandler čine jedan događaj (event), pa se zapravo radi o listi događaja. U specifikacijama je navedeno da se u okviru jednog uređaja te komande moraju opsluživati po FIFO sistemu. U slučaju kada želimo proslediti različite komande različitim TransducerChannel-ima moramo praviti posebne niti tj. uređaje.

Slika22. – Struktura Device – a

Vrlo je važno napomeniti da sve ove niti u sebi mogu imati određene prioritete, pa ako bi došlo do prosleđivanja određene komande višeg prioriteta, vrlo lako se nit koja se trenutno izvršava može suspendovati, da bi se kasnije ponovo pokrenula kada nit višeg prioriteta odradi svoje. Primer toga je recimo prosleđivanje neke komande sa komunikacione strane, na primer hardverskog prekida. U tu svrhu je na globalnoj šemi prikazan deo option.

Dakle jasno je da ovakav sistem može opsluživati više komandi paralelno. Kada se završi procesiranje sa TIM strane, komunikacioni modul prosleđuje oktetni niz ka NCAP strani. Naravno radi se o posebnoj strukturi (replay komandna poruka), kao što je i objašnjeno u prethodnim poglavljima. Prosleđuje se komanda notifyRsp() koja budi uspavane niti koje čekaju podatake. Dalje se vrši dekodovanje poruke tj. prebacivanje oktetnog niza u ArgumentArray niz. Ovaj niz predstavlja izlazne podatke i on se formatira tako da se od njega dobijaju željeni atributi merenja.

Pošto je već napomenuto da ćemo se u nastavku baviti praktičnom realizacijom funkcije readData(), daćemo i uprošćeni algoritamski prikaz idejnog rešenja funkcije čitanja. Jasno je da je jedna od najčešćih mernih aplikacija čitanje vrednosti sa TransducerChannel – a. Ako predpostavimo da TransducerChannel radi u immediate operation sampling modu, automatski se vrši trigerovanje i vraća se rezultat. Aplikacija može pozivati metodu za čitanje više puta ako je




potrebno obaviti višestruka čitanja. Kada aplikacija završi poziva se close() metoda koja oslobađa resurse.

9.2.1 IEEE 1451.0 procesni detalji

Da bi ilustrovali tip procesiranja koje se pojavljuje iza read() poziva prilikom merenja, urađen je sledeći dijagram. Aplikacija je predstavljena sa leve strane, a IEEE 1451.X sloj je u sredini. Primetimo da open() poziv i procesiranje sa TIM – ove strane nije ilustrovano.

Ovde predpostavljamo da aplikacija vrši neposredno čitanje TransducerChannel – a iz željenog TIM – a. Dakle kada aplikacija pozove read() metodu dolazi do :

a) Odgovarajuća komanda se formatira da bi se uputila TIM-u da bi došlo do čitanja željenog TransducerChannel – a sa specificiranim sampling modom. I svi ulazni argumenti su upakovani u inArgs tipa ArgumentArray.

Slika23. – Read operacija – dijagram sekvence




b) Koristi se encode() metod da bi napravio komandni payload oktetni niz. Pošto je ovo komanda za čitanje ovaj niz sadrži sledeće oktete : TransducerChannel – ov ID, oktet komandne klase, oktet komandne funkcije, DataSetOffset ... Komanda write() se poziva od strane IEEE 1451.X sloja da pokrene transfer oktetnog niza ka TIM – u. Onda se ova nit blokira dok se ne obavi merenje. Kada se završi procesiranje sa TIM strane, IEEE 1451.X sloj će proslediti oktetni niz nazad ka NCAP strani. I poziva se notify() metoda. Ona budi blokirane niti. Sada se koristi metoda decode() koja konvertuje oktetni niz u ArgumentArray niz. Ovaj niz predstavlja izlazne podatke i on se formatira tako da se od njega dobijaju željeni atributi merenja.

9.2.2 Mehanizam SendCommand()

Kao što je objašnjeno u četvrtom poglavlju, mnoge komande su definisane u IEEE 1451.0 sloju. U mnogim slučajevima, obezbeđene su specijalne metode koje su tu da olakšaju aplikaciji rad, na primer, čitanje TransducerChannel – a ili TIM – a. Iza ovih „ pogodnih “ metoda stoji implementiran tzv. sendCommand() mehanizam. U nastavku sledi objašnjenje ovog mehanizma :

Open() metoda služi za prosleđivanje transducerId željenog TIM – a i TransducerChannel – a. Takođe, parametar commandID je selektiran u svim komandama numerisanim u poglavlju 4. Ovaj 16-bitni broj sadrži klasu u viših 8 bitova i komandnu funkciju u nižih osam bitova. Svi komandni ulazni argumenti su upakovani u inArgs tipa ArgumentArray.Pozicija i tip argumenata u ovim nizu za zahtevima specificiranim u komandi. Onda se poziva sendCommand()

mehanizam. Izlazni argumenti se vraćaju upakovani u outArgs tipa ArgumentArray.Sledeća slika ilustruje mehanizam.

Slika24. – Dijagram SendCommand() sekvence




9.3 Softverska implementacija funkcija – paketi

Pošto smo videli da proučavajući strukturu komandi i poruka ovog protokola, sistem operiše sa određenim tipovima podataka (nizovi argumenata, nizovi okteta...) prvi korak pri praktičnoj realizaciji ovih funkcija jeste da se naprave takve strukture podataka, i da im se ugrade određena svojstva koja će kasnije dosta olakšati njihovo korišćenje. U tu svrhu napravljen je paket arguments koji sadrži implementirane klase ArgumentArray, IntArray, Argument. Prva klasa je opremljena konstruktorima i metodama za smeštanje argumenta u niz, ispis niza, vraćanje veličine niza, vraćanje argumenta sa odrećene pozicije itd.. Pošto kasnije vršimo razne operacije sa ovim nizovima, a nigde u protokolu nije specificirano kako precizno treba implementirati, ceo rad je odrađen za jedan tip argumenta – tipa Int. U tu svrhu je izvršeno proširivanje i napravljena specijalno klasa IntArgument.

Slika25. – Paket arguments

Takođe, pošto je ceo kod odrađen opšte moramo uvesti i određene nebrojive strukture podataka (enum), zato što pri izboru funkcije koju treba implementirati figurišu upravo takvi podaci. Na primer, iz koje je komandne klase (cmdClassId), koja metoda iz CommonCmds, koje je mod semplovanja (SamplingMode). Zato je napravljen poseban paket sa ovim tipovima u okviru kojeg su implementirane još dve klase koje se kasnije puno koriste. Jedna je za rad sa nizovima okteta (OctetArray) i druga za vreme (TimeDuration). Ove klase sadrže i propratne metode za njihovo korišćenje.




Slika26. – Paket types

Sledeći paket koji je realizovan, a sadrži vrlo bitne klase za implementaciju funkcija servisnog modula jeste paket utils. Pošto se razmena podataka i komandi između NCAP –a i TIM –a sa druge strane, obavlja u oktetnom (bajtovskom) svojstvu, implementirana je klasa Codec. Ova klasa sadrži metode za prebacivanje niza argumenata u niz okteta i obrnuto( argumentArray2OctetArray i octetArray2ArgumentArray). Takođe sadrži metode za enkodovanje i dekodovanje komandi u skladu sa protokolom o čemu je bilo govora u prethodim poglavljima.

Slika27. – Prikaz odabira funkcije servisnog modula




U ovom paketu se nalazi i klasa ReceivingHandler koja služi za prijem niza okteta. Naime, kod nje je izvršena sinhronizacija niti preko Monitora tako što se čeka određeno vreme da se prime podaci sa strane TIM – a. To je odrađeno u okviru metode waitToReceive(TimeDuration

timeout). Ovaj paket sadrži još jednu klasu. To je generička klasa Out koja predstavlja izlazni tip podataka.

9.4 Implementacija funkcija i devices

Postoji još jedan paket ključan za dalju implementaciju funkcije. To je paket device. U okviru ovog paketa implementirana je klasa AbstractDevice. Naime, zamišljeno je da određenom senzoru tj. kanalu pridruži virtulno uređaj (device). Pošto se može više komandi poslati istom uređaju ili različitim uređajima u kratkom vremenskom periodu, u okviru klase AbstractDevice formira se red privatnih klasa Event. Svaku ovakvu klasu karakterišu komanda (command) i njen ReceivingHandler.

Slika28. – Klasa device i njen algoritam

Dakle, svaki Device tj. uređaj određuje posebnu nit u sklopu čije se metode run() vrši enkodovanje komande, prijem niza bajtova, dekodovanje poruke i generisanje replay – a. U tu




svrhu su i napravljene metode u okviru ove klase tipa handleReceiver(OctetArray command),

handleCommonCommand(Byte cmdFunctionId, ArgumentArray inArgs), handleReadTEDS(

ArgumentArray inArgs). Naravno, prva od ovih funkcija je odrađena bez gubitka opštosti, ali kao što sam već napomenuo mi smo see ograničili na komande Common tipa. A pošto smo realizovali konkretno komandu readData onda treća od ovih metoda se stara baš o tome. Odgovor koji se vraća u vidu rezultata je neki dummy i stavio sam da to bude neki random broj od nula do 1000.

Slika29. – Komunikacija korisnik – pametni senzor

Opšta šema po kojoj je izvršena implementacija je data na slici. Naravno, ceo kod je odrađen da radi za jedan device, ali se može napraviti i više uređaja (devices) i pokretati se iz glavnog programa. U tu svrhu je i urađena klasa TransducerAccess koja sadrži tabelu sa device – ovima i njihovim ključevima (HashMap). Od metoda sadrži metodu za registrovanje uređaja i metodu koju smo implementirali, tj. metodu readData. Tok rada ove klase je prikazan na slici. Takođe, urađena je i pomoćna klasa za mrežnu simulaciju i generisanje odgovora. Njen odnos sa drugim klasama je takođe prikazan na slici.




Network

Simulator waittoReceive(timeout)

Device

ReceivingHandler

receivefr

omDevice

(comman

d,

receiving

Handler)

receive(command,device,timeout)

Vazno je napomenuti da se iz glavnog programa vrši startovanje uređaja i njegovo registrovanje u okviru klase TransducerAccess.

TransducerAccess

redaData(transCommId,timeout,samplingMode,result)

encodeCommand

replay=receive(command,device,timeout)

Paket Codec

Network

Simulator

registerDevice(transCommId,

device)

transCommId

HashMap

Device1

transCommId

Device2

return decodeResponse(replay,successflag,result)

Slika30. – Prikaz simulacije operacije čitanja – readData




10. Zaključak

Ovaj master rad opisuje način implementacije funkcija servisnog modula pametnih pretvarača.Takođe, u radu se nalaze koncepti pametnih pretvarača, IEEE 1451 standarda za pametne pretvarače, arhitekture IEEE 1451 familije standarda. Detaljno su opisane komande u ovom protokolu, komandne klase, kao i struktura poruka, kako komandnih tako i povratnih. Dat je i opis komunikacionog interfejsa i Transducer servisnog API – ja. Master rad u nastavku daje idejno rešenje za implementaciju funkcija Transducer servisnog modula. Naravno kod za jednu funkciju je dat u prilogu i u tom kodu je ostavljeno mesto za realizaciju ostalih funkcija, a njime se samo htela verifikovati ispravnost zamišljenog.

IEEE 1451 standard ima za cilj da obezbedi interoperabilnost u sferi korišćenja pretvarača. Situacija pre pojave ovog standarda je bila veoma loša, jer je postajalo na stotine različitih specifikacija za implementaciju pametnih pretvarača. Ovo je dovodilo do nekompatabilnosti u komunikaciju između pretvaračkih aplikacija. Ovaj standard značajno popravlja situaciju i zato je potrebno insitirati na sve većoj njegovoj primeni.

Prilikom izrade ovog rada sam uvideo koliko je programiranje bitno u svim oblastima elektronike. Naime, do sada sam u elktronici, imao prilike da koristim samo low-level programiranje. Ispunjeni su svi zahtevi iz specifikacija protokola, a problem je rešen objektno – orijentisanim programiranjem. U dosadašnjem školovanju moje usmrenje se baziralo na spoju elektronike i fizike. U svom daljem školovanja, voleo bih da unapredim i svoje programerske veštine, a ovaj rad je upravo dobrano poslužio u te svrhe. Još želim da spomenem da je kod i napravljen da bude lako izmenjiv i prilagodljiv na promene i dodatke. Naravno autor je svestan činjenice da predstavlja jedno moguće rešenje i da verovatno postoje bolja i jednostavnija, i unapred je zahvalan na svakoj korekciji.




11. Literatura

[1] "Proposed IEEE Standard P1451.0 - Defining the core features of smart sensors to fasilitate boarder adoption", Robert N. Johnson, Telemonitor, Inc., Kolumbia, Maryland

[2] "Thinking in Java", third edition Bruce Eckel, president, MindView, Inc. PDF 13-9-2002

[3] "JAVA-J2SE5", Herbert Shildt, preveli Miljenko Šućur, Dejan Smiljanić, Milorad Popović Mikroknjiga 2006, Beograd

[4] "IEEE 1451.0 Standard for a Smart Transducer Interface for Sensors and Actuators - Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats", IEEE, 3 Park Avenue, New York, NY 10016-5997, USA, 21 September 2007, IEEE Instrumentation and Measurement Society, Sponsored by the Technical Committee on Sensor Technology (TC-9)

[5] “ Rešeni zadaci iz programskog jezika Java”, Laslo Kraus, Akademska misao, Beograd drugo izdanje, 2007

[6] "Understanding Smart Sensors", Second Edition, Randy Frank

[7] "Understanding IEEE 1451—Networked Smart Transducer Interface Standard", Eugene Y. Song and Kang Lee




12. Prilog

Package utils

package utils;

import java.nio.ByteBuffer;

import types.OctetArray;

import arguments.Argument;

import arguments.ArgumentArray;

import arguments.IntArgument;

public class Codec

{

public static short encodeCommand(shortchannelId, byte cmdClassId, byte

cmdFunctionId, ArgumentArray inArgs, Out<OctetArray> payload) {

Out<OctetArray> argPayload = new Out<OctetArray>();

if (argumentArray2OctetArray(inArgs, argPayload) != 0) return 1;

ByteBufferbuf= ByteBuffer.allocate(6+argPayload.getValue().getData().length);

buf.putShort(channelId);

buf.put(cmdClassId);

buf.put(cmdFunctionId);

buf.putShort((short)argPayload.getValue().getData().length);

buf.put(argPayload.getValue().getData());

payload.setValue(new OctetArray(buf.array()));

return 0;

}




public static short decodeCommand(OctetArray payload, Out<Short>

channelId, Out<Byte> cmdClassId, Out<Byte> cmdFunctionId, Out<ArgumentArray>

inArgs) {

ByteBuffer buf = ByteBuffer.wrap(payload.getData());

channelId.setValue(buf.getShort());

cmdClassId.setValue(buf.get());

cmdFunctionId.setValue(buf.get());

int length = buf.getShort();

byte[] data = new byte[length];

buf.get(data);

return octetArray2ArgumentArray(new OctetArray(data), inArgs);

}

public static short encodeResponse(boolean successFlag, ArgumentArray

outArgs, Out<OctetArray> payload) {

Out<OctetArray> argPayload = new Out<OctetArray>();

if (argumentArray2OctetArray(outArgs, argPayload) != 0)return 1;

ByteBuffer buf =

ByteBuffer.allocate(3+argPayload.getValue().getData().length);

buf.put((byte)(successFlag?1:0));

buf.putShort((short)argPayload.getValue().getData().length);

buf.put(argPayload.getValue().getData());


return 0;

}

public static short decodeResponse(OctetArray payload, Out<Boolean>

successFlag, Out<ArgumentArray> outArgs) {





successFlag.setValue(buf.get()!=0);

int length = buf.getShort();

byte[] data = new byte[length];

buf.get(data);

return octetArray2ArgumentArray(new OctetArray(data), outArgs);

}

public static short argumentArray2OctetArray(ArgumentArray inArgs,

Out<OctetArray> payload) {

ByteBuffer buf = ByteBuffer.allocate(2+inArgs.size()*4);

buf.putShort(inArgs.size());

for(short i =0 ;i<inArgs.size();i++) {

Out<Argument> out = new Out<Argument>();

inArgs.getByIndex(i, out);

buf.putInt(((IntArgument)out.getValue()).intValue);

}


return 0;

}

public static short octetArray2ArgumentArray(OctetArray payload,

Out<ArgumentArray> outArgs) {


short count = buf.getShort();

ArgumentArray result = new ArgumentArray(count);

for(short i = 0;i<count;i++) {

result.putByIndex(i, new IntArgument(buf.getInt()));

}

outArgs.setValue(result);

return 0;}}




/////////////////////////////////////////////////////////////////////////////

package utils;


import types.TimeDuration;

public class ReceivingHandler

{

private final Object monitor = new Object();

OctetArray data;

public void received(OctetArray data) {

this.data = data;

synchronized (monitor) {

monitor.notifyAll();

}

}

/**

* Returns null if timeouted, otherwise received array.

*/

public OctetArray waitToReceive(TimeDuration timeout) {

long timeLeft = timeout.secs * 1000000000L + timeout.nsecs;

long endNanoTime = System.nanoTime() + timeLeft;

synchronized (monitor) {

while (data == null)

try

{

timeLeft = endNanoTime - System.nanoTime();

if (timeLeft < 0)




return null;

long timeLeftMS = timeLeft / 1000000;

int timeLeftNS = (int) (timeLeft % 1000000);

monitor.wait(timeLeftMS, timeLeftNS);

}

catch (InterruptedException e)

{

e.printStackTrace();

}

}

return data;

}

}

/////////////////////////////////////////////////////////////////////////////

package utils;

public class Out<T>

{

T value;

public T getValue()

{

return value;

}

public void setValue(T value)

{

this.value = value;

}}




Package device

package device;

import java.util.concurrent.LinkedBlockingQueue;

import types.CmdClassId;

import types.CommonCmds;


import utils.Codec;

import utils.Out;

import utils.ReceivingHandler;


public abstract class AbstractDevice implements Device, Runnable

{

private static class Event {

final OctetArray command;

final ReceivingHandler handler;

public Event(OctetArray command, ReceivingHandler handler)

{ this.command = command;

this.handler = handler;

}

}

private final LinkedBlockingQueue<Event> events = new

LinkedBlockingQueue<Event>();




@Override

public void receiveFromDevice(OctetArray command, ReceivingHandler

receivingHandler)

{

events.offer(new Event(command, receivingHandler));

}

@Override

public void run()

{

while (true) {

try

{

Event event = events.take();

OctetArray array = handleReceiver(event.command);

event.handler.received(array);

}


{


}

}

}

protected OctetArray handleReceiver(OctetArray command)

{

Out<Short> channelId = new Out<Short>();

Out<Byte> cmdClassId = new Out<Byte>();




Out<Byte> cmdFunctionId = new Out<Byte>();

Out<ArgumentArray> inArgs = new Out<ArgumentArray>();

if (Codec.decodeCommand(command, channelId, cmdClassId, cmdFunctionId,

inArgs)!=0)

return null;;

switch (CmdClassId.values()[cmdClassId.getValue()])

{

case CommonCmd:

return handleCommonCommand(cmdFunctionId.getValue(), inArgs.getValue());

default: return null;

}

}

protected OctetArray handleCommonCommand(Byte cmdFunctionId, ArgumentArray

inArgs)

{

switch (CommonCmds.values()[cmdFunctionId])

{

case Read_TEDS:

Out<OctetArray> result = new Out<OctetArray>();

Codec.encodeResponse(true, handleReadTEDS(inArgs), result);

return result.getValue();

default: return null;

}

}

protected abstract ArgumentArray handleReadTEDS(ArgumentArray inArgs);}




/////////////////////////////////////////////////////////////////////////////

package device;

import java.util.Random;


import arguments.IntArgument;

public class RandomIntDevice extends AbstractDevice

{

Random rand = new Random();

@Override

protected ArgumentArray handleReadTEDS(ArgumentArray inArgs)

{

try

{

Thread.sleep(rand.nextInt(1000));

}


{


}

return new ArgumentArray(new IntArgument(rand.nextInt(1000)));

}

}

/////////////////////////////////////////////////////////////////////////////




package device;



public interface Device

{ void receiveFromDevice(OctetArray command, ReceivingHandler

receivingHandler);

}

Package arguments

package arguments;

import java.util.Arrays;

import utils.Out;

public class ArgumentArray

{

private final Argument[] arguments;

public ArgumentArray(Argument... arguments)

{

this.arguments = arguments;

}

public ArgumentArray(int count)

{

this.arguments = new Argument[count];

}

public short getByIndex(short index, Out<Argument> reference) {

if (index >= 0 && index<=arguments.length) {

reference.setValue(arguments[index]);

return 0;

}




return 1;

}

public short putByIndex(short index, Argument value) {

if (index >= 0 && index<=arguments.length) {

arguments[index] = value;

return 0;

}

return 1;

}

public short size() {

return (short)arguments.length;}

@Override

public String toString()

{

return "ArgumentArray [arguments=" + Arrays.toString(arguments) +

"]";

}

// UInt16 getByName( in _String name, out Argument reference);

// UInt16 getByIndex( in UInt16 index, out Argument reference);

// UInt16 putByName( in _String name, in Argument value);

// UInt16 putByIndex( in UInt16 index, in Argument value);

// UInt16 stringToIndex( in String name, out UInt16 index);

// UInt16 getNames( out StringArray names);

// UInt16 getIndexes( out UInt16Array indexes);

// UInt16 size();

}




/////////////////////////////////////////////////////////////////////////////

package arguments;

public class IntArgument extends Argument

{

public final int intValue;

public IntArgument(int intValue)

{

this.intValue = intValue;

}

@Override

public String toString()

{

return "IntArgument [intValue=" + intValue + "]";

}

}

/////////////////////////////////////////////////////////////////////////////

package arguments;

public abstract class Argument{}

Package types

package types;

public class TimeDuration

{ public final int secs;

public final int nsecs;

public TimeDuration(int secs, int nsecs)

{

this.secs = secs;

this.nsecs = nsecs;

}




}

/////////////////////////////////////////////////////////////////////////////

package types;

public class OctetArray

{ byte[] data;

public OctetArray(byte[] data)

{

this.data = data;

}

public byte[] getData()

{return data;}

public void setData(byte[] data)

{

this.data = data;

}

}

/////////////////////////////////////////////////////////////////////////////

package types;

public enum SampleMode

{ Reserved,

TriggerInit,

FreeNoPre,

FreePreTrig,

Continuous,

Immediate; }

/////////////////////////////////////////////////////////////////////////////

package types;

public enum CmdClassId {




Reserved,

CommonCmd,

XdcrIdle,

XdcrOperate,

XdcrEither,

TIMsleep,

TIMActive; }

/////////////////////////////////////////////////////////////////////////////

package types;

public enum CommonCmds {

Reserved,

Query_TEDS,

Read_TEDS,

Write_TEDS,

Update_TEDS,

Run_self_test;}

/////////////////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////////////////

import java.util.HashMap;

import java.util.Map;

import types.CmdClassId;

import types.CommonCmds;



import utils.Codec;

import utils.Out;


import device.Device;




public class TransducerAccess

{

private final Map<Short, Device> devices = new HashMap<Short, Device>();

public void registerDevice(short transCommId, Device device) {

devices.put(transCommId, device);

}

public short readData (short transCommId, TimeDuration timeOut, byte

samplingMode, Out<ArgumentArray> result) {

Device device = devices.get(transCommId);

if (device == null)

return 1;

Out<OctetArray> command = new Out<OctetArray>();

if (Codec.encodeCommand(transCommId, (byte)CmdClassId.CommonCmd.ordinal(),

(byte)CommonCmds.Read_TEDS.ordinal(), new ArgumentArray(), command)!=0)

return 1;

OctetArray reply = NetworkSimulator.receive(command.getValue(), device,

timeOut);

if (reply == null)

return 1;

Out<Boolean> successFlag = new Out<Boolean>();

return Codec.decodeResponse(reply, successFlag, result);

}

}

//IDL: Args::UInt16 readData(

// in Args::UInt16 transCommId,

// in Args::TimeDuration timeout,




// in Args::UInt8 SamplingMode,

// out Args::ArgumentArray result);

//This method performs a blocking read of the specified TransducerChannel(s).

//The ArgumentArray can have many attributes as discussed in Clause 7 and

//Clause 8; each attribute is represented by a separate “Argument” in the

//ArgumentArray. The application can control which attributes are returned

//through the use of the TransducerManager::configureAttributes( ) call.In

//cases where this is a read of a single TransducerChannel, there will always

//be a “result” Argument that contains the TransducerChannel reading. The

//type of this Argument is determined by the TransducerChannel’s data model

//and if the TransducerChannel has a Calibration TEDS. For example, a read of

//a simple TransducerChannel that does not specify Calibration TEDS will

//always be in the TransducerChannel’s native format (for example, UInt8 or

//Float32Array). If the TransducerChannel does specify NCAP-side correction

//via the Calibration TEDS, the data type will always be Float32 or

//Float32Array.In cases where this is a read of a group of

//TransducerChannels, there will always be a nested “result” ArgumentArray

//that contains an Argument for each TransducerChannel in the group. These

//will be accessed in numerical order beginning with array position “0”. This

//organization corresponds to the order of TIM/TransducerChannel pairs in the

//openGroup( ) or openGroupQoS( ) call. The data type for each returned

//Argument will be like the single TransducerChannel read discussed in the

//previous paragraph. .

// Parameters: The “transCommId” parameter indicates which transducer

//communication session to use. The “timeout” parameter specifies how long to

//wait to perform the reading without generating a time-out error. Note a

//time-out can occur due to communication or trigger failures. The

//“SamplingMode” specifies the triggering mechanism. The [out] “result”

//ArgumentArray is the returned values.

//Return result: Error code

/////////////////////////////////////////////////////////////////////////////




import device.Device;

public class NetworkSimulator

{ public static OctetArray receive(OctetArray command, Device device,

TimeDuration timeout) {

ReceivingHandler receivingHandler = new ReceivingHandler();




device.receiveFromDevice(command, receivingHandler);

return receivingHandler.waitToReceive(timeout);}}

/////////////////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////////////////


import utils.Out;


import device.AbstractDevice;

import device.RandomIntDevice;

public class Main

{ public static void main(String[] args)

{

AbstractDevice device = new RandomIntDevice();

startDevice(device);

TransducerAccess transducerAccess = new TransducerAccess();

transducerAccess.registerDevice((short)1, device);

for (int i = 0;i<5;i++) {

Out<ArgumentArray> result = new Out<ArgumentArray>();

short errorCode = transducerAccess.readData((short)1, new TimeDuration(1, 0),

(byte)0, result);

System.out.println(errorCode + "\t" + result.getValue());

}

}

private static void startDevice(AbstractDevice device)

{

Thread deviceThread = new Thread(device);

deviceThread.setDaemon(true);

deviceThread.start();

}}

microsoft word - master rad dejan rozgic

Documents