Miksi integraattorin on vaikea saada Modbus-laitettasi toimimaan?

Kokenut automaatioinsinööri saa laitteen, avaa Modbus-rekisterikartan ja aloittaa yhteyden käyttöönoton. Baudinopeus, pariteetti ja laiteosoite ovat oikein, mutta integraatio ei silti toimi odotetusti.

Helppo johtopäätös on, ettei insinööri ymmärrä Modbusia tai että automaatiojärjestelmä on konfiguroitu väärin.

Joskus näin on.

Mutta jos kokeneet integraattorit joutuvat toistuvasti pyytämään apua saman tuotteen liittämisessä, ongelma voi olla muualla.

Modbus-rajapinta voi toimia teknisesti täysin oikein ja olla silti vaikea integroida.

Laitevalmistajan kannalta tärkeä kysymys ei siksi ole ainoastaan:

Tukeeko laitteemme Modbusia?

Vaan myös:

Pystyykö insinööri, joka ei tunne tuotettamme ennestään, integroimaan sen oikein tarjoamillamme tiedoilla?

Integraattorilla ei ole tuotekehitystiimin hiljaista tietoa

Laitteen kehittäneet insinöörit tietävät valmiiksi, miten tuote toimii.

He tietävät esimerkiksi, että:

• dokumentaation osoite 1 tarkoittaa protokolla-offsetia 0
• lämpötila on tallennettu etumerkillisenä 16-bittisenä arvona
• raaka-arvo pitää kertoa luvulla 0.1
• 32-bittisen arvon ensimmäinen sana tulee ensin
• arvon 1 kirjoittaminen rekisteriin sallii toiminnon eikä käynnistä sitä välittömästi
• tiedonsiirtoasetuksen muutos tulee voimaan vasta uudelleenkäynnistyksen jälkeen

Nämä asiat voivat tuntua tuotekehityksen sisällä itsestään selviltä, koska niitä on käsitelty suunnittelun ja testauksen aikana.

Integraattorilla tätä taustatietoa ei ole.

Hänellä on laite, dokumentaatio ja tuotteen tarjoama rajapinta. Jos integraatiossa tarvittava tieto on olemassa vain tuotekehitystiimin tietona, julkinen rajapinta on asiakkaan näkökulmasta puutteellinen.

Siksi laite voi toimia valmistajan testipenkissä täydellisesti ja aiheuttaa silti ongelmia oikeissa projekteissa.

“Modbus RTU supported” ei vielä kerro integraattorille tarpeeksi

Peruskommunikointiasetukset ovat vasta Modbus-integraation alku.

Modbus RTU:ssa insinöörin pitää yleensä muodostaa fyysinen yhteys ja määrittää esimerkiksi laiteosoite, baudinopeus, pariteetti ja stop-bitit.

Sen jälkeen hänen pitää vielä ymmärtää, miten laitteen sovellusrajapintaa käytetään.

Jokaisesta tarvittavasta arvosta voidaan tarvita esimerkiksi:

• rekisterityyppi ja function code
• rekisteriosoite ja käytetty osoitetapa
• tietotyyppi ja etumerkillisyys
• rekisterien määrä
• usean rekisterin arvojen byte order ja word order
• skaala ja yksikkö
• sallittu alue
• luku- ja kirjoituskäyttäytyminen
• tilabittien tai numeroitujen tilojen merkitys

Jos useampi näistä puuttuu, tiedonsiirto voi toimia mutta integraatio silti epäonnistua.

Tämä ero on tärkeä.

Timeout on selkeästi tiedonsiirto-ongelma. Onnistunut vastaus, joka sisältää väärin tulkitun arvon, on paljon vaikeampi huomata.

Laite vastaa, mutta insinööri lukee väärää rekisteriä

Rekisteriosoitteet ovat yksi yksinkertaisimmista esimerkeistä.

Ensimmäinen holding-rekisteri voidaan esittää esimerkiksi näin:

Kaikki voivat tarkoittaa samaa loogista paikkaa.

Jos dokumentaatiossa lukee ainoastaan:

Address: 1

integraattorin pitää edelleen päätellä, mitä 1 tarkoittaa.

PLC-ohjelmisto voi odottaa nollapohjaista protokollaosoitetta. Toinen työkalu voi näyttää yksipohjaisia rekisterinumeroita. Laiteohje voi käyttää 4xxxx-viitteitä.

Vaarallisin tilanne ei ole aina timeout.

Oletetaan, että rekisterikartassa on:

Jos integraation osoitteet ovat yhden rekisterin verran siirtyneet, laite voi palauttaa täysin normaalisti tuloilman asetusarvon.

Arvo voi jopa näyttää järkevältä.

Tiedonsiirto toimii. Integraatio on silti väärin.

Katso osoiteongelmasta tarkemmin: Modbus-osoitteet: 40001, 0-pohjainen ja 1-pohjainen.

Rekisterin arvo ei kerro itse, mitä se tarkoittaa

16-bittisen rekisterin lukeminen ei vielä kerro integraattorille, mitä bitit esittävät.

Otetaan esimerkiksi raaka-arvo:

0xFF9C

Se voidaan tulkita näin:

Jos rekisteri esittää lämpötilaa muodossa INT16 x0.1 °C, todellinen arvo on:

-100 x 0.1 = -10.0 °C

Modbus-vastaus itsessään ei kerro BMS-järjestelmälle tätä.

Rekisterikartan täytyy kertoa se.

Ongelma korostuu 32-bittisissä arvoissa, koska integraattorin pitää tietää sekä tietotyyppi että se, missä järjestyksessä usean rekisterin arvo yhdistetään.

Jos dokumentaatiossa lukee vain:

Supply temperature
Address: 120

insinöörille jää monta avointa kysymystä.

Onko kyseessä INT16, UINT16 vai FLOAT32? Käyttääkö arvo yhtä vai kahta rekisteriä? Onko siinä skaalausta? Mikä on yksikkö? Jos rekistereitä on kaksi, mikä on niiden sanajärjestys?

Kokenut Modbus-insinööri pystyy kokeilemaan eri tulkintoja.

Se ei tarkoita, että hänen pitäisi joutua tekemään niin.

Oikea numero voi silti tarkoittaa väärää asiaa

Joskus arvon numeerinen tulkinta on täysin oikein, mutta rekisterin toiminnallinen merkitys jää epäselväksi.

Otetaan esimerkiksi rekisteri:

Night cooling
0 = Off
1 = On

Mitä tapahtuu, kun BMS kirjoittaa siihen arvon 1?

Se voi tarkoittaa esimerkiksi:

• automaattisen yöjäähdytystoiminnon sallimista
• yöjäähdytyksen pyyntöä
• yöjäähdytyksen pakko-ohjausta
• tietoa siitä, että yöjäähdytys on parhaillaan aktiivinen

Nämä ovat eri asioita.

Firmware-kehittäjä voi tietää täsmälleen, mitä rekisteri tarkoittaa. Integraattori näkee vain nimen ja arvomääritykset.

Termejä kuten Enable, Request, Command, Active, Status ja Feedback kannattaa käyttää johdonmukaisesti ja selittää niiden vaikutus silloin, kun toiminta ei ole itsestään selvä.

Tämä korostuu sitä enemmän, mitä älykkäämpi Modbus-laite on.

Huonesäädin, lämpöpumppu tai IV-koneen säädin sisältää omaa sisäistä logiikkaa. Rekisteriin kirjoittaminen ei välttämättä tarkoita fyysisen lähdön suoraa muuttamista.

Kirjoitettavat arvot tuovat vielä yhden epävarmuuden

Taulukon merkintä R/W kertoo, että rekisteriin voidaan kirjoittaa.

Se ei vielä välttämättä kerro, mitä kirjoituksen jälkeen tapahtuu.

Kirjoitettavasta asetusarvosta olisi hyödyllistä kertoa esimerkiksi:

• sallittu alue
• todellinen resoluutio
• mitä tukemattomille arvoille tapahtuu
• milloin uusi arvo aktivoituu
• mitä myöhempi takaisinluku palauttaa
• säilyykö arvo uudelleenkäynnistyksen jälkeen

Oletetaan, että lämpötila-asetusarvo esitetään 0.1 °C askelina.

BMS kirjoittaa:

198 = 19.8 °C

Laite tukee kuitenkin vain 0.5 °C askelia ja tallentaa:

200 = 20.0 °C

Seuraavalla lukukerralla BMS saa arvon 200.

Epäonnistuiko alkuperäinen kirjoitus?

Ei.

Laite normalisoi arvon todelliseen resoluutioonsa.

Jos tätä käyttäytymistä ei ole dokumentoitu, ohjain ja laite voivat kuitenkin olla eri mieltä siitä, miltä onnistunut kirjoitus näyttää. Joissakin toteutuksissa tämä voi johtaa jopa jatkuvaan uudelleenkirjoittamiseen, kun ohjain yrittää palauttaa alkuperäisen arvon.

Fyysisessä tiedonsiirrossa on omat oletuksensa

Osa integraatio-ongelmista syntyy jo ennen kuin rekisterikarttaa edes käytetään.

Modbus RTU:n RS-485-yhteydessä myös fyysisen rajapinnan pitää olla ymmärrettävä.

Yksi tavallinen esimerkki on A/B-liittimien nimeäminen. Eri valmistajien käyttämät merkinnät eivät ole aina niin yhdenmukaisia, että napaisuus voitaisiin päätellä pelkästään kirjaimista.

Dokumentaation pitäisi siksi kertoa riittävästi, jotta yhteys voidaan kytkeä ilman kokeilemista.

Sama koskee tuotekohtaisia vaatimuksia, kuten:

• tuettuja sarjaliikenneasetuksia
• terminointia
• tiedonsiirron ajoitusrajoituksia
• pyyntöjen kokoa koskevia rajoituksia

Nämä kannattaa dokumentoida kyseisen tuotteen mukaan eikä olettaa, että ne ymmärretään automaattisesti siksi, että laite käyttää Modbusia.

Kokeilu ei ole hyvä rajapintamäärittely

Kokeneet automaatioinsinöörit ovat usein erittäin hyviä saamaan myös heikosti dokumentoidun laitteen toimimaan.

He voivat:

• vaihtaa RS-485-johtimet keskenään
• kokeilla viereisiä rekisteriosoitteita
• testata eri function codeja
• vaihtaa signed- ja unsigned-tulkinnan välillä
• vaihtaa 32-bittisten sanojen järjestystä
• kokeilla eri skaalauksia
• kaapata ja purkaa raakoja Modbus-kehyksiä

Lopulta oikea yhdistelmä voi löytyä.

Tällöin integraatio näyttää onnistuneelta, vaikka taustalla oleva tuoterajapinnan ongelma jää piiloon.

Jos jokaisen asiakkaan pitää selvittää erikseen sama osoitetapa, skaalaus tai dokumentoimaton asetus, epäselvyyden kustannus toistuu jokaisessa projektissa.

Yksi tunti rajapinnan selkeyttämiseen valmistajalla voi muuten muuttua yhdeksi vianhakutunniksi jokaiselle tuotetta integroivalle asiakkaalle.

Katso ongelmaa myös teknisen tuen näkökulmasta

Toistuvat integraatiokysymykset ovat arvokasta palautetta tuotteesta.

Jos tekniseen tukeen tulee jatkuvasti kysymyksiä kuten:

• Minkä osoitteen syötän PLC:lle?
• Käytänkö Function Code 03:a vai 04:ää?
• Onko tämä arvo signed?
• Mitä skaalausta käytän?
• Kumpi sana tulee ensin?
• Mitä tämä statusbitti tarkoittaa?
• Miksi arvo muuttuu kirjoituksen jälkeen?
• Vaatiiko tiedonsiirtoasetuksen muutos uudelleenkäynnistyksen?

ratkaisun ei pitäisi aina olla uusi tukivastaus.

Jos useampi asiakas kysyy samaa asiaa, tieto kuuluu todennäköisesti rajapinnan dokumentaatioon.

Tämä korostuu OEM-tuotteissa, joita voivat integroida monet eri BMS-yritykset, PLC-ohjelmoijat ja järjestelmäintegraattorit.

Valmistaja ei voi olettaa, että sama henkilö tai yritys tekee jokaisen käyttöönoton.

Anna laite insinöörille, joka ei ole koskaan nähnyt sitä

Yksinkertainen testi kertoo paljon.

Anna kokeneelle automaatioinsinöörille:

• tuotantoversio laitteesta
• julkaistu käyttöohje
• julkaistu Modbus-rekisterikartta
• tavallinen Modbus-client tai PLC
• normaalit liitäntätarvikkeet

Älä anna sisäisiä kehitysmuistiinpanoja.

Pyydä häntä tekemään muutama tavallinen integraatiotehtävä:

1. Muodosta yhteys.
2. Lue yksi tärkeä mittaus.
3. Muunna se oikeaksi tekniseksi arvoksi.
4. Lue laitteen toimintatila.
5. Muuta yhtä tavallista kirjoitettavaa asetusta.
6. Lue asetus takaisin ja varmista lopputulos.
7. Selvitä, miten laite ilmoittaa viasta.

Katso, missä kohdassa hänen pitää pysähtyä kysymään lisätietoa.

Jokainen kysymys paljastaa tiedon, joka voi puuttua, olla epäselvä tai löytyä liian vaikeasti.

Tämä testi on eri asia kuin pyytää firmware-kehittäjää osoittamaan, että Modbus toimii.

Firmware-kehittäjä tietää vastaukset jo ennestään.

Testin tarkoitus on selvittää, selittääkö julkinen rajapinta itsensä riittävän hyvin tuotteen tarkoitetulle käyttäjälle.

Mitä käyttökelpoisen Modbus-rajapinnan pitäisi kertoa integraattorille?

Tarkka dokumentaatio riippuu tuotteesta, mutta integraattorin pitäisi yleensä pystyä selvittämään ainakin seuraavat asiat ilman laitteen reverse engineeringiä:

Jokainen laite ei tarvitse monimutkaista käyttöohjetta.

Yksinkertaiselle anturille voi riittää pieni taulukko.

Oleellista on, että taulukko sisältää kaiken kyseisen tuotteen integrointiin tarvittavan tiedon.

Integroinnin vaikeus on osa tuotetta

Laite ei kilpaile pelkästään teknisillä ominaisuuksillaan.

Asiakkaan näkökulmasta kokonaisuuteen kuuluu myös aika, joka tarvitaan laitteen liittämiseen, datan ymmärtämiseen ja luotettavan integraation rakentamiseen muun automaatiojärjestelmän kanssa.

Kaksi teknisesti hyvin samanlaista tuotetta voi siksi aiheuttaa projektissa hyvin erilaisen työmäärän.

Yksi laite voidaan integroida 20 minuutissa selkeän rekisterikartan ja testattujen esimerkkien avulla.

Toisen kanssa voidaan tarvita useita yhteydenottoja tekniseen tukeen ennen kuin samat asiat saadaan selvitettyä.

Tämä integraatiotyö koetaan osaksi tuotetta riippumatta siitä, näkyykö se laitteen teknisissä tiedoissa.

Katso käytännön ohje rajapinnan parantamiseen: Modbus-rekisterikartan suunnittelu laitevalmistajille.

Ennen uuden laitteen tai firmware-version julkaisua katso myös Kuinka testata uusi Modbus-laite ennen julkaisua.

Jos valmistat Modbus-laitteita ja haluat ulkopuolisen arvion rekisterikartasta, dokumentaatiosta tai laitteen integroinnista, katso LumiBMS Modbus -konsultointi.