Modbus-rekisterikartan suunnittelu integraattoria varten

Modbus-rekisterikartta on osa tuotetta. Kun asiakkaat rakentavat julkaistujen osoitteiden ympärille PLC-ohjelmia, BMS-laitepohjia, grafiikoita ja hälytyslogiikkaa, kartasta tulee julkinen rajapinta, jota valmistajan täytyy ylläpitää.

Protokolla voi toimia täydellisesti ja tuote voi silti olla hankala integroida. Tärkeät arvot voivat olla vaikeasti löydettävissä, osoitetapa epäselvä, kirjoitettavan rekisterin käyttäytyminen voi poiketa taulukosta ja firmware-päivitys voi siirtää arvoja, joihin asiakkaan järjestelmä jo luottaa.

Hyvä suunnittelukysymys ei siis ole “mitkä sisäiset muuttujat voimme julkaista?” vaan:

Mitä ulkoinen automaatiojärjestelmä tarvitsee tuotteelta ja miten siitä tehdään ilmeinen ja vakaa polku?

Tämä artikkeli tiivistää laajemman laitevalmistajille kirjoitetun rekisterikarttamateriaalin. Sen perusajatus on, että integraatiotyö on osa tuotteen todellista kustannusta: yksi valmistajalla ratkaisematta jäänyt epäselvyys voi aiheuttaa saman selvitystyön jokaiselle asiakkaalle.

Aloita asiakkaan normaalista integraatiopolusta

Älä tee julkista karttaa kopioimalla sisäisen firmware-rakenteen muuttujat peräkkäisiksi Modbus-rekistereiksi. Firmware on järjestetty toteutuksen tarpeiden mukaan. Julkinen rajapinta pitäisi järjestää käyttötavan mukaan.

Huoneanturissa BMS tarvitsee yleensä ensimmäisenä lämpötilan, CO2-pitoisuuden, kosteuden, läsnäolon ja laitteen terveystilan. Näytön kirkkaus, kalibrointihistoria, valmistustiedot sekä huolto- ja diagnostiikkalaskurit voivat olla hyödyllisiä, mutta niiden ei pitäisi peittää jatkuvasti luettavia prosessiarvoja.

Yksi mahdollinen korkean tason rakenne on:

Nämä osoitealueet eivät ole Modbus-standardin vaatimus eikä niitä pidä kopioida sellaisenaan joka tuotteeseen. Periaate on tärkeämpi: yhdessä käytettävät arvot pitäisi löytää helposti ja lukea mahdollisuuksien mukaan yhdessä.

Lähdemateriaali korostaa samaa: tärkeät prosessiarvot ryhmitellään asiakkaan käyttötavan eikä sisäisen tietotyypin tai firmware-rakenteen mukaan.

Tee osoitetavasta mahdoton tulkita väärin

Pelkkä sarake Address ei usein riitä.

Sama holding-rekisteri voidaan esittää esimerkiksi näin:

Modbus-pyyntö sisältää protokollaosoitteen, ei numeroa 40001 kirjaimellisena 40001:n osoitteena. Jos 4xxxx-viitteistä on asiakkaille hyötyä, näytä ne erillisessä selkeästi nimetyssä sarakkeessa.

Esimerkiksi:

Taulukon lähelle yksi lause:

Kaikki tämän dokumentin osoitteet ovat nollapohjaisia Modbus-protokollaosoitteita. Offset 0 vastaa holding-rekisteriviitettä 40001.

Sanamuoto voi olla muu, mutta asiakkaan ei pitäisi joutua selvittämään indeksipohjaa kokeilemalla. Lähdemateriaalissa nostetaan esiin myös vaarallisempi tilanne: väärän viereisen rekisterin onnistunut luku voi näyttää uskottavalta ja jäädä käyttöönotossa huomaamatta.

Katso tarkempi selitys: Modbus-osoitteet: 40001, 0-pohjainen ja 1-pohjainen.

Dokumentoi datan esitystapa, ei vain muuttujan nimi

Modbus-rekisteri on 16 bittiä. Protokolla ei kerro clientille, onko kyse INT16, UINT16, bittikentästä vai 32-bittisen arvon puolikkaasta.

Jokaisesta julkisesta arvosta pitäisi dokumentoida tulkintaan vaikuttavat ominaisuudet:

• tietotyyppi ja etumerkillisyys
• rekisterien määrä
• skaala
• yksikkö
• sallittu alue
• sovelluksen todellinen resoluutio, jos se eroaa numeerisesta esityksestä
• tavu- ja sanajärjestys usean rekisterin arvoissa

Yksinkertainen skaalattu kokonaisluku on usein erittäin hyvä rakennusautomaation arvoille, koska se on helppo käsitellä eri PLC- ja BMS-järjestelmissä. Huonelämpötila voi olla INT16 x0.1 °C ja CO2 UINT16 x1 ppm. FLOAT32 on oikea valinta silloin, kun sovellus tarvitsee sitä, ei vain siksi että prosessori käyttää sisäisesti liukulukuja.

Skaala ja resoluutio ovat eri asioita

Oletetaan, että lämpötila-asetusarvo esitetään muodossa INT16 x0.1 °C, mutta laite tukee oikeasti vain 0.5 °C askeleita.

Taulukon pitäisi kertoa molemmat:

Skaala:      x0.1 °C
Resoluutio:  0.5 °C

Muuten ulkoinen ohjain voi kirjoittaa 19.8 °C ja perustellusti odottaa laitteen säilyttävän juuri tämän arvon, vaikka tuote pystyy käyttämään vain 20.0 °C arvoa.

Dokumentoi mitä toiminto tekee, ei vain bittien sisältöä

Rekisteri Night cooling, jossa 0 = Off ja 1 = On, voi silti olla epäselvä. Arvon 1 kirjoittaminen voi käynnistää jäähdytyksen heti, sallia automaattisen algoritmin, pyytää toimintoa ehtojen alaisena tai raportoida, että toiminto on jo aktiivinen.

Käytä toiminnallisia termejä tarkoituksella:

Valmistajan ei tarvitse käyttää juuri näitä sanoja. Tärkeää on johdonmukaisuus ja se, että kuvaus kertoo mitä rekisterin muuttaminen aiheuttaa.

Tämä on erityisen tärkeää älykkäissä säätimissä. IV-koneen säädin ei ole etä-I/O-moduuli. BMS:n Enable voi antaa sisäiselle logiikalle luvan toimia käynnistämättä fyysistä lähtöä suoraan. Lähdemateriaali erottaa juuri tästä syystä Enable-, Request-, Active- ja Feedback-käsitteet.

Kirjoitettavalla rekisterillä pitää olla validointi- ja takaisinlukukäytäntö

Pelkkä R/W ei riitä kirjoitettavan parametrin dokumentaatioksi.

Asiakkaan pitää tietää myös:

• hyväksytty alue
• hyväksytty askel tai resoluutio
• mitä alueen ulkopuoliselle arvolle tapahtuu
• hylätäänkö, rajataanko vai normalisoidaanko tukematon arvo
• mitä seuraava luku palauttaa
• milloin uusi arvo aktivoituu
• säilyykö arvo uudelleenkäynnistyksessä
• muuttaako kirjoitus muita rekistereitä tai logiikkaa

Pieni resoluutioero voi muuttua laitteisto-ongelmaksi

Hyvä kenttäesimerkki on ohjain, joka kirjoittaa raaka-arvon 198. Laite hyväksyy pyynnön mutta normalisoi käytettävän arvon 200:aan. Ohjain lukee 200, tulkitsee ettei haluttu 198 tullut voimaan ja kirjoittaa 198 uudelleen.

Jos asetus tallennetaan EEPROMiin, sarja voi toistua loputtomasti ja aiheuttaa tarpeettomia ei-haihtuvan muistin kirjoituksia. Tiedonsiirto toimii koko ajan oikein. Vika syntyy asiakkaan takaisinlukuoletuksen ja laitteen todellisen resoluution välisestä erosta.

Lähdemateriaali kuvaa saman mekanismin ja useita tapoja estää se: dokumentoi todellinen resoluutio, hylkää tukemattomat arvot, normalisoi clientissa tai vältä fyysistä EEPROM-kirjoitusta, jos efektiivinen arvo ei muutu.

Usein jatkuvasti ohjattavat arvot kannattaa erottaa pysyvästä konfiguraatiosta. Aktiivinen asetusarvo voi olla RAMissa ja muuttua usein, kun taas oletusarvo tai kalibrointiparametri voidaan tallentaa pysyvästi ja muuttaa vain käyttöönotossa.

Käsittele tiedonsiirtoasetuksia tuotteen ominaisuuksina

Laiteosoite, baudinopeus ja pariteetti näyttävät yksinkertaisemmilta kuin sovelluksen rekisterikartta, mutta mikään muu ei toimi ennen niitä.

Tue vain sellaisia vaihtoehtoja, jotka on oikeasti toteutettu ja testattu. Kiinteä 9600, 8E1 voi olla helpompi integroida kuin laite, joka lupaa kuusi baudinopeutta ja kolme pariteettitapaa mutta käyttäytyy osassa yhdistelmiä epäjohdonmukaisesti.

Jos tiedonsiirtoasetuksia voidaan muuttaa Modbusin kautta, dokumentoi aktivointijärjestys. Se, milloin uusi osoite tai baudinopeus tulee voimaan, on osa rajapintaa.

Koko asiakkaan työnkulku pitää testata:

1. Yhdistä tehdasasetuksilla.
2. Lue nykyiset asetukset.
3. Kirjoita uusi asetus.
4. Vastaanota dokumentoitu vastaus.
5. Aktivoi asetus.
6. Yhdistä uudella konfiguraatiolla.
7. Katkaise virta ja käynnistä uudelleen.
8. Varmista pysyvyys.

Suunnittele vikatila ennen kuin anturi hajoaa

Modbus server voi jatkaa täysin normaalia vastaamista, vaikka yhden rekisterin taustalla oleva mittaus olisi kuollut. Tiedonsiirron terveys ja prosessiarvon kelvollisuus ovat eri asioita.

Oletetaan, että huoneanturi on raportoinut 21.4 °C ja anturielementti rikkoutuu. Viimeisen kelvollisen arvon säilyttäminen voi olla hyvä ratkaisu, mutta vain jos vastaanottava järjestelmä pystyy näkemään mittauksen olevan vanhentunut.

Yksinkertainen rajapinta voisi sisältää:

Kun lämpötila-anturi vikaantuu, lämpötilarekisteri voi jäädä arvoon 21.4 °C mutta vikabitti aktivoituu. BMS voi tämän perusteella harmaannuttaa arvon, hälyttää, lopettaa sen käytön säädössä tai käyttää varamittausta.

Lähdemateriaali korostaa eroa: uskottava jäätynyt mittaus voi jäädä pitkäksi aikaa huomaamatta, koska Modbus-yhteys itsessään on kunnossa.

Pidä hälytyssanat yhden käsitteen ympärillä

Bittikenttä toimii hyvin, kun kaikki bitit vastaavat samaan ylätason kysymykseen. 16-bittinen hälytyssana voidaan suunnitella niin, että 0 tarkoittaa ettei aktiivisia hälytyksiä ole ja mikä tahansa muu arvo tarkoittaa vähintään yhtä hälytystä.

Älä täytä vapaita bittejä tavallisilla käyttötiloilla vain siksi, että tilaa on. Jos samassa sanassa on anturivika, Holiday mode, näytön taustavalo ja puhaltimen komento, yksinkertainen testi hälytyssana > 0 ei enää kerro mitään hyödyllistä.

Ryhmittele normaali pollaus järkeviksi yhtenäisiksi lohkoiksi

Modbus RTU on pyyntö-vastaus-liikennettä. Jokainen ylimääräinen pyyntö vie väyläaikaa ja luo uuden paikan viiveelle, timeoutille tai retrylle.

Jos lämpötila, CO2, kosteus ja läsnäolo tarvitaan jatkuvasti, sijoita ne mahdollisuuksien mukaan yhtenäiseen luettavaan lohkoon. Älä hajauta niitä osoiteavaruuteen vain siksi, että sisäiset muuttujat ovat eri C-rakenteissa tai tietotyypeissä.

Huomioi myös aukot. Jos BMS tarvitsee rekisterit 10, 12 ja 14, se voi perustellusti lukea koko alueen 10-14. Jos osoitteet 11 ja 13 aiheuttavat koko pyynnön poikkeuksen, kartta voi olla teknisesti sallittu mutta hankala käyttää. Sijoita suuremmat varatut alueet mahdollisuuksien mukaan toiminnallisten lohkojen väliin eikä eniten pollattavan lohkon sisään. Tämä kompromissi on kuvattu lähdemateriaalin pollaus- ja toimintavarmuusosassa.

Säilytä julkaistujen rekisterien merkitys firmware-versioiden yli

Julkaistu rekisteriosoite on yhteensopivuuslupaus.

Uuden kosteusarvon lisääminen varattuun paikkaan on asiakkaalle yleensä halpa muutos. Sen lisääminen keskelle vanhaa karttaa niin, että kaikki myöhemmät osoitteet siirtyvät, voi rikkoa PLC-ohjelmia, laitepohjia, grafiikoita, trendejä ja hälytyksiä jo asennetuissa järjestelmissä.

Yhteensopivuus on muutakin kuin numero. Myös näiden muuttaminen voi rikkoa vanhan integraation:

• tietotyyppi
• skaala
• yksikkö
• kirjoituskäyttäytyminen
• hälytysbittien merkitys
• oletusarvo tai riippuvuus

Suosi additiivisia muutoksia. Jos tuoteperheen tiedetään kehittyvän, jätä realistisesti tilaa niiden toimintojen lähelle, joihin uusia ominaisuuksia todennäköisesti tulee. Tuhansien tyhjien rekisterien varaaminen ilman syytä ei ole tavoite. Tavoite on vakaa kehitys.

Lähdemateriaalin yhteensopivuusosuus suosittelee samaa: säilytä vanhat osoitteet ja käytä varattuja paikkoja uusiin ominaisuuksiin aina kun se on käytännöllistä.

Julkisen rekisteritaulukon pitää sisältää toteutukseen tarvittava tieto

Hyvä ydintaulukko voi sisältää:

Jokainen yksinkertainen mittaus ei tarvitse omaa kappaletta. Monimutkaiset kirjoitettavat arvot, bittikentät, enumit ja riippuvuudet yleensä tarvitsevat.

Rekisterikartan alkuun kannattaa lisätä myös lyhyt integraatioyhteenveto ennen suurta taulukkoa: tiedonsiirron oletukset, osoitetapa, tuetut Function Codet, suositeltu pollauslohko ja tärkeät yleissäännöt kuten kiinteät yksiköt tai arvojen pysyvyys.

Katselmoi kartta ennen kuin julkinen rajapinta lukitaan

Paras hetki siirtää rekisteri on ennen kuin yksikään ulkopuolinen on integroinut sen.

Anna julkaistava dokumentaatio ja laite henkilölle, joka ei ollut mukana firmware-toteutuksessa. Pyydä integroimaan tuote ilman suullisia korjauksia. Jokainen kysymys on todiste siitä, että julkisessa rajapinnassa voi vielä olla piilotettu oletus.

Katselmoi sekä yksittäiset rivit että koko kartan muoto:

• Ovatko päämittaukset helppo löytää?
• Voidaanko yhdessä käytettävät arvot lukea yhdessä?
• Erottuvatko Command, Enable, Status ja Feedback toisistaan?
• Onko osoitetapa yksiselitteinen?
• Onko tyyppi, skaala, yksikkö, alue ja resoluutio määritelty?
• Onko kirjoitus ja takaisinluku määritelty?
• Erottuvatko pysyvät ja haihtuvat arvot tarvittaessa?
• Näkyykö anturivika vaikka Modbus-yhteys jatkuu?
• Muodostavatko hälytysbitit yhden selkeän kokonaisuuden?
• Voiko kartta kasvaa siirtämättä vanhoja osoitteita?
• Tarkoittaako sama osoite samaa asiaa myös seuraavassa firmware-versiossa?

Lähdemateriaalin julkaisun tarkistuslista laajentaa tämän virheellisiin pyyntöihin, pitkäkestoiseen pollaukseen ja vanhan rajapinnan regressiotestaukseen.

Täydellinen valmistajan testiprosessi on artikkelissa Miten Modbus-laite testataan ennen julkaisua.

Tavoitteena on tylsä integraatio

Paras Modbus-rajapinta on yleensä se, jota integraattorin ei tarvitse ajatella pitkään. Yhteys toimii ohjeen asetuksilla. Lämpötila näyttää lämpötilalta. Enable sallii toiminnon. Status kertoo tilan. Vikaantunut anturi ilmoittaa vian. Firmware-päivitys ei siirrä osoitteita hiljaa.

Tuote voi silloin hävitä osaksi suurempaa automaatiojärjestelmää ja insinööri voi keskittyä rakennuksen prosessiin laitteen rajapinnan käänteisen selvittämisen sijaan.

Jos valmistat Modbus-laitetta ja haluat integraattorin näkökulmasta tehtävän rekisterikartan, dokumentaation tai testisuunnitelman katselmoinnin, katso Modbus-konsultointi.