1 Bevezetés
A mikrokontrollereket egyre gyakrabban alkalmazzák az automatizált vezérlőeszközökben, az elektromos hálózatok mikroprocesszor{0} alapú integrált védelmi rendszereiben és más ipari automatizálási vezérlési területeken, miközben ezeknek az eszközöknek a bonyolultsága folyamatosan növekszik. A fejlesztési célok valós-többfeladatos-igényének kielégítése érdekében az egy-CPU, egy-fejlesztői modellt egy együttműködési megközelítés váltja fel, amely több különböző típusú CPU-t és több fejlesztőt is magában foglal. Ez az új fejlesztési paradigma kritikus kihívást jelent: a hardver és a szoftver szabványosítását a CPU-k közötti információcseréhez a megvalósítás során. Ez a szabványosítás kulcsfontosságú az új modell sikeres elfogadása szempontjából. Számos kommunikációs módszer közül az UART{9}}alapú RS-485 soros kommunikációs protokollt széles körben alkalmazzák egyszerű vezetékezése, nagy megbízhatósága és több CPU támogatására való képessége miatt. Ami a szoftveres kommunikációs protokollokat illeti, a Modbus protokoll jelentős előnyöket kínál a felhasználók számára univerzális természetének és kiforrott hibakereső szoftverének köszönhetően. Ezért az új motorok átfogó védelmi eszközének fejlesztése során az RS-485 soros kommunikációs módszert és a Modbus kommunikációs protokollt alkalmazták a több CPU közötti adat- és vezérlőparancs információcsere elérése érdekében. A szerző a soros kommunikáció hatékonyságának és koordinációjának fokozása érdekében számos intézkedést hajtott végre a kommunikációs mechanizmus hardveres és szoftveres architektúrájában, kiváló eredményeket ért el. A rendszerkommunikációs hibakeresési szakaszban olyan módszert alkalmaztak, amelyben minden CPU-modul először kommunikált a szabványos Modbus tesztszoftverrel, mielőtt kölcsönös összekapcsolási hibakeresésen ment keresztül, jelentősen javítva az együttműködési fejlesztés hatékonyságát. A gyakorlat bebizonyította, hogy ez a tervezési filozófia leegyszerűsíti a rendszer felépítését, miközben nagymértékben növeli az eszköz működési hatékonyságát és megbízhatóságát.
2 Az átfogó motorvédelmi eszköz jellemzői
Az átfogó védelmi funkciókon túl a motorvédő készülék mérési, távvezérlési és kommunikációs képességeket is magában foglal. Nagy-képernyője, kínai karakteres LCD-kijelzője felhasználóbarát-felületet tesz lehetővé. A megfigyelő gazdagéppel való CAN-busz-kommunikációt kihasználva alrendszert alkot egy hierarchikus, elosztott alállomás-automatizálási rendszeren belül. A rendszer funkcionalitásának a többfeladatos{5}}követelményekhez való optimalizálása érdekében egy több-processzoros architektúrát fogadtunk el. Egy CPU kezeli az időszakos impulzus-mintavételezést és -átvitelt; a fő CPU modul kezeli az adatfeldolgozást, az elektromos paraméterek kiszámítását, a hibadiagnosztikát és a kapcsolási műveleteket; míg a kártyamodul CPU felügyeli az emberi-gép interakcióját, és megkönnyíti a kommunikációt a fő védelmi modullal és a megfigyelő gazdagéppel. Minden CPU-modulnak világosan meghatározott feladatai vannak, amelyek megkönnyítik a több mérnök által végzett együttműködési fejlesztést a megvalósítás során. A soros kommunikáció összeköti a fő CPU-t és a panel CPU-ját, lehetővé téve az emberi{11}}gép interakciót, és így kritikus pozíciót foglal el. A racionális kommunikációs mechanizmus kialakítása a soros kommunikációs rész magja, amely meghatározza a kommunikáció koordinációját és a hibakeresés hatékonyságát a rendszerfejlesztés későbbi szakaszaiban.
3 Bevezetés a kommunikációs mechanizmusokba
3.1 A kommunikációs mechanizmus hardvertervezése
Az ehhez a rendszerhez javasolt kommunikációs mechanizmus célja a nagy hatékonyság és megbízhatóság. Az RS-485 fél-duplex struktúrát alkalmaz, ami a terepi alkalmazásokban gyakran praktikusabb, mint a full-duplex. Itt egy egyszerűsített csatlakozást alkalmaznak, amely csak két jelvezetéket használ. A rendszer interfész kapcsolási rajza az 1. ábrán látható. A fő védelmi modulon lévő 8051-es mikrokontroller által kiadott TTL logikai szintek optikailag le vannak választva, majd a MAX485 chip RS-495 szintekre konvertálja. Ezt követően a panelmodulon lévő MAX485 chip ezeket visszakonvertálja TTL logikai szintekre, hogy a 8031-es mikrokontroller olvassa. A 8051-es mikrokontroller oldalán a 2. párhuzamos I/O port P2.7 érintkezője vezérli a MAX bemenet engedélyező érintkezőjét és a DE kimenet engedélyező lábát. Amint az 1. ábrán látható, amikor a P2.7 magas szintet ad ki, az RE engedélyezve van, lehetővé téve a mikrokontroller oldalának az adatok fogadását. Amikor a P2.7 alacsony szintet ad ki, a DE engedélyezve van, lehetővé téve a mikrokontroller oldalának adatátvitelt. Ez a megközelítés megakadályozza a vak átvitel által okozott átfedések miatti adatvesztést, biztosítva a kiváló kommunikációs minőséget és megbízható átviteli sebességet.
3.2 Kommunikációs protokoll
A védelmi eszköz két modulja közötti pontos adatátvitel biztosításához elengedhetetlen az információátvitelt szabályozó specifikációk-beleértve az átviteli módokat, az adatformátumokat és a tartalmat-. Ez alkotja a protokollt vagy kommunikációs protokollt. Könnyen elérhető, kiforrott hibakereső szoftver nélkül a fő CPU-modul lényegében fekete dobozként működik, ami számos és nehezen leküzdhető kihíváshoz vezet a rendszerintegrációs tesztelés során. Ezért a széles körben elterjedt Modbus kommunikációs protokollt választották ki és egyszerűsítették, hogy megfeleljen az eszköz specifikus követelményeinek, lehetővé téve a modulok közötti sikeres kommunikációt, bizonyított hatékonysággal. A Modbus mester-szolga kommunikációs modellt alkalmaz. A master először kommunikációs kérési parancsot küld a slave-nek. A slave ezután a kérés parancson belüli funkciókódon alapuló adatokkal válaszol a masternek. Minden szolga egyedi címmel rendelkezik. Mind a master által küldött kérés keretek, mind a slave által küldött válaszkeretek a slave címével kezdődnek. A szolgák csak a maguknak címzett parancsokat olvassák, és figyelmen kívül hagyják a más slave címekkel kezdődő üzeneteket. Ezt a funkciót a 8051-es soros port 2. vagy 3. móddal valósítják meg. Ez a kérdés{19}}és-válasz kommunikációs modell jelentősen javítja a kommunikáció pontosságát. Ebben az eszközben a Modbus RTU átviteli módja van átvéve.
4 Intézkedések a kommunikáció megbízhatóságának növelésére
A Modbus üzenet utolsó két bájtja ellenőrző bájtként szolgál. Az RTU kommunikáció CRC-16 ciklikus redundancia-ellenőrzést alkalmaz a hibaészlelés érdekében. Kódolási/dekódolási mechanizmusa viszonylag egyszerű, alacsony hibaaránnyal, számítási vagy programozási módszerekkel elérhető. Az alábbiakban számos megközelítést ismertetünk:
4.1 Alapvető algoritmus (kézi számítás)
CRC16-CCITT példaként: a CRC ellenőrző összege 16 bit, a generáló polinom pedig 17 bites. Tegyük fel, hogy az adatfolyam 4 bájt: BYTE, BYTE, BYTE, BYTE[0];
Eltolja az adatfolyamot balra 16 bittel, gyakorlatilag 256 × 256-szorosára bővítve. Ezután hajtsa végre a 0x11021 generátorpolinommal való osztást nem-kölcsönző osztás használatával (egyenértékű a bitenkénti XOR-val). Az eredményül kapott maradék a CRC ellenőrző összeg. A továbbított adatfolyam 6 bájtból áll: BYTE, BYTE, BYTE, BYTE[0], CRC, CRC[0].
4.2 Számítógépes algoritmus 1 (bit{2}}típusú algoritmus)
1) Helyezze a kiterjesztett adatfolyam felső 16 bitjét (BYTE, BYTE) (6 bájt) egy 16 bites regiszterbe;
2) Ha a regiszter legjelentősebb bitje 1, tolja el a regisztert egy bittel balra (a következő bájtból a legkisebb jelentőségű bitet kapja), majd hajtson végre egy XOR műveletet a generátor polinom egyszerűsített alakjával; ellenkező esetben egyszerűen tolja el a regisztert egy bittel balra (a következő bájtból a legkisebb jelentőségű bitet kapja meg);
3) Ismételje meg a 2. lépést, amíg a teljes adatfolyam (6 bájt) eltolódik a regiszterbe;
4) A regiszterben szereplő érték a CRC ellenőrzőösszeg CRC, CRC[0].
4.3 2. számítógép-algoritmus (Bájt-típus-algoritmus) (256^n a 256-ot n hatványára emelve)
A byte{0}}rendezett adatfolyamot matematikai polinomként ábrázolja. Legyen az adatfolyam BYTE[n] BYTE[n-1] BYTE[n-2] ... A BYTE[0] matematikai kifejezésként van ábrázolva
BÁJT[n] × 256^n + BÁJT[n-1] × 256^(n-1) + ... + BÁJT × 256 + BÁJT[0], ahol a "+" az XOR műveletet jelöli. Legyen a generátor polinom G17 (17 bites), akkor a CRC kód CRC16.
CRC16=(BYTE[n] × 256^n + BYTE[n-1] × 256^(n-1) + ... + BYTE × 256 + BYTE[0]) × 256^2 / G17
Ez magában foglalja az adatfolyam balra tolását 16 bittel, majd elosztja a G17 generátorpolinommal.
A levezetés azt mutatja, hogy a BYTE[n-1] CRC-ellenőrző kódja megegyezik az előző bájt Y[n] (YH8[n]) CRC-ellenőrző kódjának felső 8 bitjének XOR eredményével és az aktuális BYTE[n-1] bájttal.
A bájt{0}}típusú algoritmus a következő:
1) Inicializálja a CRC regisztercsoportot minden "0"-ra (0x0000).
2) Tolja el a CRC regisztercsoportot 8 bittel balra, és tárolja a CRC regisztercsoportban.
3) Végezzen XOR műveletet az eredeti CRC regisztercsoport magas 8 bitje (8 bittel jobbra tolva) és az adatbájt között, hogy megkapja az értéktáblázatra mutató indexet.
4) Végezzen XOR műveletet az index által mutatott táblázatérték és a CRC regisztercsoport között.
5) Növelje az adatmutatót. Ha az adatfeldolgozás nem fejeződött be, ismételje meg a 2) lépést).
6) Szerezze meg a CRC-t.
5 Intézkedések a kommunikáció hatékonyságának javítására
5.1 Külön kommunikációs fogadási és átviteli feladatok
A 8051-es mikrokontroller a soros porton keresztül tud adatokat küldeni és fogadni megszakításokkal. Az SCON soros port vezérlő támogatja az inicializálást és a bitcímzést. Soros port megszakítási kérés esetén az SCON alsó két bitje reteszeli az adási és vételi megszakításokat. Amikor a CPU adatokat vagy karaktert ír a soros port SUBF átviteli pufferébe (utasítás: MOV SUBF, A), az adó megkezdi a küldést. Egy adatkeret befejezése után a hardver a TI jelzőt "1-re" állítja, jelezve, hogy a soros port megszakítást kér a CPU-tól a következő adatkeret elküldéséhez. Hasonlóképpen, ha a soros port vevője engedélyezve van a vételre, egy adatkeret vételekor az RI jelző 1-re van állítva, jelezve, hogy a soros port megszakítást kér a CPU-tól, hogy kiolvassa az adatokat a vételi adatpufferből.
5.2 A megszakítás időtartamának csökkentése
Mivel a szoftverarchitektúra tervezése során többszörös megszakítást alkalmaznak, a megbízható programműködés biztosítása és a különböző feladatok közötti konfliktusok valószínűségének minimalizálása érdekében a szoftveres implementáció során törekedni kell a különböző megszakítások feladatainak racionalizálására, végrehajtási idejük lerövidítésére. A kommunikációs megszakítási szubrutinon belül a megszakításba való belépéskor olyan alapvető feladatokat hajtson végre, mint például: a megfelelő állapotbitek törlése a soros port vezérlőregiszterében, a fogadott karakterek beolvasása vagy a pufferből továbbítandó karakterek írása, a fogadott vagy továbbított karakterek számának növelése stb. Ezután azonnal lépjen ki a megszakításból. Az egyéb feladatokat, például a keretek érvényesítését, a kapott keretparancsokra való reagálást (telemetria/telecommand) és az átviteli keretek előkészítését a főprogramon belül kell kezelni.
5.3 Hatékony keretmegszakítás-észlelés a kommunikációs stagnálás megelőzése érdekében
Egy dedikált szoftver időzítő használata a fogadott keret végének észlelésére megakadályozza, hogy a kommunikációs feladatok elhúzódjanak, ha egy keret nem teljesen érkezett, ezáltal biztosítva a következő keretek időben történő vételét. Mivel a kereten belüli bájtok közötti idő sokkal rövidebb, mint a -–-kockák közötti időköz, a szoftver időzítője minden új bájt fogadásakor elindul. Az időzítő a minimális képkocka-–-kockaintervallumra van állítva. Ez az intervallum a különböző adatátviteli sebességekkel változik. Ha a következő bájt az előre beállított idő letelte előtt érkezik, az azt jelzi, hogy a keret nem teljes, és az időzítő újraindul. Ha az időzítő sikeresen visszaszámol az előre beállított időig, akkor a megfelelő megszakítási számot váltja ki. Az időzítő megszakítási szubrutinon belül a keretvégjelző bájt be van állítva, ami azt jelzi, hogy a keret vétele befejeződött. Miután a mesterprogram észlelte a keret vételének befejezését, a szolgacím és a ciklikus redundancia-ellenőrző (CRC) bájt ellenőrzésével ellenőrzi a keret integritását. Ha megerősítik, hogy a mesternek szánt keret érvényes, akkor a függvénykódja alapján feldolgozza a frame parancsot, és felkészül a keret küldésére. Amikor a slave hibás üzenetet kap, hibakeretet küld vissza. Ha a fogadott üzenetnek helytelen CRC-je van, a slave dönthet úgy, hogy nem válaszol. Ha a master nem kap választ a slave-től a megadott időn belül, akkor újra elküldi a kérés üzenetet. Ha több újraküldésnél sem sikerül választ kapni a slave-től, a rendszer kommunikációs hibát jelent.
5.4 A kommunikációs sebesség meghatározása
Mivel minden eszköz ugyanazon a házon belül található, a modulok közötti távolság minimális. A Modbus RS485-ön működik a nagy-távolságú kommunikáció érdekében, így nincs szükség az adatátviteli sebességre gyakorolt távolsági hatások figyelembevételére. Ezenkívül a master-slave kommunikációs mód megakadályozza a vonal torlódását. Ezért a kommunikáció hatékonysága szempontjából mindaddig, amíg a beállított adatátviteli sebesség nem haladja meg a modulban használt chip maximális adatátviteli sebességét, a nagyobb adatátviteli sebesség gyorsabb információcserét és nagyobb kommunikációs hatékonyságot eredményez. Az adatátviteli sebesség mindkét kommunikációs fél számára pontosan azonosra történő beállítása biztosítja, hogy a vevő vég minden adatbitet a bitciklus felezőpontjában mintavételezzen, ezáltal megbízható kommunikációt érjen el.
5.5 Ésszerű hibakeresési módszerek
A hibakeresés során először tesztelje az egyes CPU-modulok és a mikroszámítógép közötti kommunikációt az RS485/RS232 adatkonverziós modulon keresztül. A sikeres egyéni tesztelés után folytassa a modulok közötti-hibakereséssel, jelentősen javítva ezzel az általános hibakeresési hatékonyságot. A modulok közötti-–-számítógépes kommunikáció hibakeresése során a számítógép Modbus hibakereső szoftvert használ a master kommunikációs folyamatának szimulálására, és aktívan kér információkat a slave-től. Ez átláthatóvá és világossá teszi a teljes vételi és átviteli folyamatot, lehetővé téve a modulproblémák időben történő megoldását. A közös hibakeresés során a buszfigyelő szoftver mindkét oldal adatait megfigyeli, hogy azonnal azonosítsa és megoldja a problémákat.
6 A jelen dokumentum innovációs szempontjai
Először is, ez a dokumentum a Modbust, egy univerzális ipari szabványt alkalmazza a védelmi eszközben. A szükséges eszközszoftver közvetlenül beszerezhető a megfelelő webhelyekről, szellemi tulajdonnal kapcsolatos költségek nélkül. Másodszor, a védelmi eszköz multitaskingot valósít meg, és a Modbus protokollt használja, hogy ésszerű közös hibakeresési mechanizmust hozzon létre a CPU-modulok között, nagymértékben javítva az együttműködésen alapuló rendszerfejlesztés hatékonyságát.