Miten Modbus-laite testataan ennen julkaisua

Modbus-rajapinta ei ole valmis julkaistavaksi siksi, että yksi testiohjelma pystyy lukemaan yhden rekisterin. Asiakas saa laitteen, rekisterikartan ja tiedonsiirtoasetukset. Näiden pitää toimia yhdessä normaalitilanteessa, virheellisillä pyynnöillä, sähkökatkoissa ja todellisissa vikatilanteissa.

Vahvin testi tehdään asiakkaan näkökulmasta. Käytä julkaistavaa dokumentaatiota, tavallista Modbus clientia ja mahdollisimman vähän firmware-tiimin hiljaista tietoa. Jokainen testissä löytyvä dokumentoimaton oletus on hyödyllinen, koska se voidaan vielä korjata ennen kuin asiakkaat rakentavat integraationsa sen ympärille.

Aloita tehdasasetuksista

Aloita tuotteesta siinä tilassa, jossa uusi asiakas sen saa.

Kirjaa ja testaa:

• oletus Modbus-osoite
• baudinopeus
• pariteetti
• stop-bitit
• tuetut Function Codet
• dokumentissa käytetty osoitetapa

Jos ohje lupaa useita baudinopeuksia tai pariteettivaihtoehtoja, testaa ne yhdistelmät, joita valmistaja väittää tukevansa. Käyttöliittymässä näkyvä mutta testaamaton valinta on osa tuotteen rajapintaa heti, kun asiakas voi käyttää sitä.

Pienempi, tarkoituksella tuettu asetusjoukko on parempi kuin kaikki UARTin teknisesti mahdolliset vaihtoehdot, jos osa niistä aiheuttaa kentällä yhteensopivuusongelmia.

Testaa tiedonsiirtoasetuksen muutos kokonaisena työnkulkuna

Modbus-osoitteen, baudinopeuden tai pariteetin muuttaminen Modbusin kautta on erityinen tilanne, koska kirjoitus voi muuttaa samaa kanavaa, jolla kirjoitus tehdään.

Dokumentaation pitää kertoa milloin uusi asetus aktivoituu. Se voi tapahtua vastauksen jälkeen, viiveellä, erillisellä tallennuskomennolla tai uudelleenkäynnistyksessä. Testin pitää noudattaa juuri tätä dokumentoitua käyttäytymistä.

Hyvä testijärjestys on:

1. Yhdistä tehdasasetuksilla.
2. Lue nykyinen tiedonsiirtokonfiguraatio.
3. Kirjoita uusi osoite tai sarjaliikenneasetus.
4. Varmista dokumentoitu vastaus vanhoilla asetuksilla.
5. Aktivoi muutos ohjeen mukaisesti.
6. Yhdistä uusilla asetuksilla.
7. Lue normaalia prosessidataa.
8. Katkaise virta ja käynnistä laite uudelleen.
9. Varmista, että asetus säilyy, jos sen kuuluu säilyä.
10. Palauta tehdasasetus.

Toista sama jokaiselle tiedonsiirtotavalle, joka kuuluu tuotteen spesifikaatioon.

Tarkista rekisterikartta kirjaimellisesti

Jokaisesta julkisesta arvosta pitää tarkistaa, että julkaistava dokumentti vastaa laitetta:

• protokollaosoite
• rekisterityyppi ja Function Code
• tietotyyppi ja etumerkillisyys
• rekisterien määrä
• skaala ja yksikkö
• sallittu alue
• resoluutio
• luku- ja kirjoitusoikeus
• oletusarvo
• tavu- tai sanajärjestys tarvittaessa
• riippuvuudet muihin asetuksiin
• pysyvyys tarvittaessa

Älä tarkista julkaistavaa karttaa sisäistä Exceliä vasten, jos Excelissä on korjauksia joita asiakkaalla ei ole. Julkaistava dokumentti on osa rajapintaa.

Hyvä katselmointitapa on antaa laite ja ohje insinöörille, joka ei kirjoittanut firmwarea. Jos hän joutuu kysymään tarkoittaako osoite 1 protokolla-offsetia 0, mitä “Holiday” oikeasti tekee tai mikä pariteetti todella toimii, katselmointi on löytänyt korjattavan kohdan.

Testaa kirjoitettavat arvot normaalialueen ulkopuolelta

Kirjoitettava rekisteri vaatii enemmän testausta kuin pelkkä mittaus, koska pyyntö muuttaa laitteen tilaa.

Testaa jokaisesta kirjoitettavasta arvosta:

• pienin sallittu arvo
• suurin sallittu arvo
• arvo juuri alarajan alapuolelta
• arvo juuri ylärajan yläpuolelta
• arvo, joka ei osu todelliseen resoluutioon
• saman arvon toistuvat kirjoitukset
• välitön takaisinluku
• käyttäytyminen uudelleenkäynnistyksen jälkeen
• vaikutus muihin rekistereihin tai säätölogiikkaan

Tuotetiimin pitää päättää hylätäänkö, rajataanko vai normalisoidaanko virheellinen arvo. Käyttäytyminen pitää dokumentoida eikä jättää firmware-tyyppimuunnosten sattuman varaan.

Resoluutio ja takaisinluku voivat luoda jatkuvan kirjoitussilmukan

Oletetaan, että asetusarvo esitetään 0.1 °C lukuina mutta laite tukee vain 0.5 °C askelia. PLC kirjoittaa raaka-arvon 198. Laite normalisoi sen arvoon 200 ja palauttaa seuraavassa luvussa 200.

Jos PLC tulkitsee kaiken muun kuin arvon 198 epäonnistuneeksi kirjoitukseksi, se voi kirjoittaa 198 uudelleen loputtomasti. Jos parametri tallennetaan EEPROMiin, rajapinnan oletuserosta voi tulla muistinkulumisongelma, vaikka jokainen Modbus-pyyntö ja -vastaus on täysin kelvollinen.

Testissä pitää siis tarkistaa todellinen käytettävä ja tallennettava arvo, dokumentoitu resoluutio sekä se, välttääkö firmware tarpeettoman fyysisen EEPROM- tai flash-kirjoituksen, kun efektiivinen arvo ei muutu.

Testaa virheelliset ja tukemattomat pyynnöt

Älä testaa vain onnistunutta polkua. Julkinen Modbus server saa ennemmin tai myöhemmin pyyntöjä, jotka ovat tukemattomia, väärin konfiguroituja tai muuten virheellisiä.

Testaa vähintään:

• ensimmäinen validi osoite
• viimeinen validi osoite
• osoite juuri validin alueen ennen ja jälkeen
• lohkoluku varatun tai tukemattoman aukon yli
• pyyntö, joka alkaa validilta alueelta ja päättyy sen ulkopuolelle
• tukematon Function Code
• kirjoitus vain luku -rekisteriin
• kirjoitus varattuun osoitteeseen
• virheellinen enum-arvo
• tukematon rekisterimäärä

Oikea vastaus riippuu funktiosta ja laitteen suunnittelusta, mutta yksi vaatimus on yleinen: pyyntö ei saa horjuttaa laitetta. Tukematon luku ei saa muuttua taulukon ulkopuoliseksi muistiviittaukseksi, resurssivuodoksi tai uudelleenkäynnistykseksi.

Toista virheellisiä pyyntöjä myös pitkäkestoisessa testissä. Osa vioista näkyy vasta, kun puskureita, laskureita tai resursseja on käsitelty väärin monta kertaa.

Testaa anturi- ja alijärjestelmäviat fyysisesti

Kelvollinen Modbus-vastaus ei todista, että taustalla oleva mittaus on kelvollinen. Irrota anturielementti tai luo muu turvallinen vikatilanne ja katso mitä client todella näkee.

Kysy:

• Jääkö mittaus viimeiseen kelvolliseen arvoon?
• Muuttuuko se varatuksi virhearvoksi?
• Aktivoituuko vikabitti?
• Kuinka nopeasti vika näkyy?
• Jatkaako laite Modbus-vastauksia?
• Mitä tapahtuu, kun anturi palautuu?
• Säilyykö arvo tai vikatila uudelleenkäynnistyksessä?

Jos rajapinta säilyttää viimeisen tunnetun arvon, anna erillinen validiteetti- tai vikailmaisu. Näin BMS pystyy erottamaan vakaan huoneen kuolleesta anturista.

Normaalitesti todistaa, että rekisterikartoitus toimii. Vikatesti todistaa, että rajapinta pysyy ymmärrettävänä myös silloin, kun tuote ei toimi normaalisti.

Testaa realistinen pollaus ja pitkäkestoinen käyttö

Laite, joka kestää käsin tehtävän lukupyynnön muutaman sekunnin välein, voi epäonnistua todellisen BMS:n kuormassa. Pollaa normaaleja lohkoja realistisella aikavälillä ja lisää mukaan uudelleenyrityksiä, satunnaisia virheellisiä pyyntöjä ja yhteyskatkoja.

Tarkkaile:

• kasvavaa vasteaikaa
• menetettyjä pyyntöjä
• muistinkasvua tai resurssivuotoja
• watchdog-uudelleenkäynnistyksiä
• ylivuotavia laskureita
• timeoutin jälkeen tulevia vanhoja vastauksia
• syklisistä komennoista syntyviä turhia kirjoituksia

Älä keksi yhtä yleistä pollaustaajuutta kaikille Modbus-tuotteille. Jos laite tarvitsee minimiviiveen, suurimman lohkokoon tai muun rajan, mittaa se, spesifioi se ja testaa se.

Regressiotestaa vanhat integraatiot

Kun rekisterikartta on julkaistu, siitä tulee yhteensopivuusrajapinta. Uuden firmwaren pitäisi edelleen palauttaa vanhat arvot samoista osoitteista samoilla tietotyypeillä, skaaloilla, alarm-biteillä ja kirjoituskäyttäytymisellä, ellei yhteensopimaton muutos ole tietoinen päätös.

Pidä vähintään yksi regressiotesti, joka edustaa aiemmin julkaistua rajapintaa. Se voi olla automatisoitu tai osittain automatisoitu, mutta sen pitää testata sitä, mitä vanha PLC- tai BMS-integraatio odottaa, ei vain nykyistä sisäistä toteutusta.

Julkaisua edeltävä tarkistuslista

Ennen julkaisua varmista, että:

• osoitetapa on yksiselitteinen
• tärkeät arvot voidaan lukea järkevinä lohkoina
• jokaisella rekisterillä on määritelty tyyppi, skaala, yksikkö ja käyttöoikeus
• kirjoitettavien arvojen rajat, resoluutio, normalisointi ja takaisinluku on kuvattu
• pysyvät ja haihtuvat arvot on erotettu tarvittaessa
• kaikki luvatut tiedonsiirtoasetukset on testattu
• konfiguraatiomuutokset säilyvät uudelleenkäynnistyksessä silloin kun niiden kuuluu
• mittausvioilla on määritelty käyttäytyminen ja laatutieto
• varatut ja tukemattomat osoitteet käsitellään turvallisesti
• pitkäkestoinen pollaus ei horjuta laitetta
• vanhat integraatiot toimivat firmware-päivityksen jälkeen
• joku firmware-tiimin ulkopuolinen on testannut julkaistavaa ohjetta kirjaimellisesti

Tavoite ei ole todistaa, että kehitystiimi osaa saada laitteen kommunikoimaan. Tavoite on varmistaa, että asiakas pystyy integroimaan tuotteen oikein pelkän julkisen rajapinnan avulla.

Suunnittelupuolesta tarkemmin: Modbus-rekisterikartan suunnittelu integraattoria varten.