1 Вступ
Мікроконтролери все частіше застосовуються в автоматизованих пристроях керування, інтегрованих системах захисту-на основі мікропроцесорів для електромереж та інших галузях керування промисловою автоматизацією, при цьому складність цих пристроїв постійно зростає. Щоб задовольнити-багатозадачність у реальному часі,-вимоги до цілей розробки, модель єдиного-ЦП, одного-розробника замінюється на спільний підхід із залученням кількох ЦП різних типів і кількох розробників. Ця нова парадигма розробки представляє критичну проблему: стандартизацію апаратного та програмного забезпечення для обміну інформацією між центральними процесорами під час впровадження. Ця стандартизація має ключове значення для успішного впровадження нової моделі. Серед численних методів зв’язку протокол послідовного зв’язку RS-485 на основі UART- широко поширений завдяки його простому підключенню, високій надійності та здатності підтримувати декілька ЦП. Що стосується програмних протоколів зв'язку, протокол Modbus пропонує значні переваги для користувачів завдяки своїй універсальності та зрілому програмному забезпеченню для налагодження. Таким чином, під час розробки нового пристрою комплексного захисту двигуна, метод послідовного зв’язку RS-485 і протокол зв’язку Modbus були прийняті для забезпечення обміну даними та інформацією про команди керування між декількома процесорами. Щоб підвищити ефективність і координацію послідовного зв’язку, автор реалізував численні заходи в апаратній і програмній архітектурі механізму зв’язку, досягнувши чудових результатів. Під час фази налагодження системного зв’язку використовувався метод, за якого кожен модуль центрального процесора спочатку спілкувався зі стандартним тестовим програмним забезпеченням Modbus перед проходженням налагодження взаємного з’єднання, що значно підвищило ефективність спільної розробки. Практика довела, що така філософія дизайну спрощує структуру системи, одночасно значно підвищуючи ефективність і надійність пристрою.
2 Особливості пристрою комплексного захисту двигуна
Окрім комплексних функцій захисту, пристрій захисту двигуна об’єднує можливості вимірювання, дистанційного керування та зв’язку. Його великий-РК-дисплей із китайськими символами забезпечує зручний-інтерфейс. Використовуючи зв’язок по шині CAN із хостом моніторингу, він утворює підсистему в ієрархічній розподіленій системі автоматизації підстанції. Щоб оптимізувати функціональність системи для її багатозадачних вимог, було прийнято багато-процесорну архітектуру. Один центральний процесор обробляє періодичну вибірку та передачу імпульсів; головний модуль центрального процесора керує обробкою даних, розрахунком електричних параметрів, діагностикою несправностей і операціями перемикання; тоді як центральний процесор модуля плати контролює взаємодію людини-машини та полегшує зв’язок із головним модулем захисту та хостом моніторингу. Кожен модуль ЦП має чітко визначені завдання, що сприяє спільній розробці кількома інженерами під час впровадження. Послідовний зв’язок з’єднує головний центральний процесор і центральний процесор панелі, уможливлюючи-взаємодію між людиною та машиною та, таким чином, займаючи критичну позицію. Встановлення раціонального механізму зв’язку є ядром розділу послідовного зв’язку, що визначає координацію зв’язку та ефективність налагодження на наступних етапах розвитку системи.
3 Введення в механізми зв'язку
3.1 Апаратна конструкція механізму зв'язку
Механізм зв'язку, запропонований для цієї системи, спрямований на високу ефективність і надійність. RS-485 використовує напів-дуплексну структуру, яка часто більш практична, ніж повний дуплекс у польових застосуваннях. Тут використовується спрощене з'єднання з використанням лише двох сигнальних ліній. Принципова схема інтерфейсу системи показана на малюнку 1. Логічні рівні TTL, що виводяться мікроконтролером 8051 на головному модулі захисту, оптично ізольовані, а потім мікросхемою MAX485 перетворюються на рівні RS-495. Згодом мікросхема MAX485 на модулі панелі перетворює їх назад на рівні логіки TTL для зчитування мікроконтролером 8031. На стороні мікроконтролера 8051 висновок P2.7 паралельного порту вводу/виводу 2 керує контактом RE дозволу входу MAX і контактом DE дозволу виходу. Як показано на малюнку 1, коли P2.7 видає високий рівень, RE вмикається, дозволяючи стороні мікроконтролера отримувати дані. Коли P2.7 видає низький рівень, DE вмикається, дозволяючи стороні мікроконтролера передавати дані. Такий підхід запобігає втраті даних через перекриття, спричинене сліпою передачею, забезпечуючи високу якість зв’язку та надійну швидкість передачі.
3.2 Протокол зв'язку
Для забезпечення точної передачі даних між двома модулями всередині захисного пристрою необхідний набір специфікацій, що регулюють передачу інформації-включаючи режими передачі, формати даних і вміст-. Це становить протокол або протокол зв'язку. Без готового, зрілого програмного забезпечення для налагодження головний модуль ЦП по суті функціонує як чорний ящик, що призводить до численних і важко{4}}-подолання проблем під час тестування системної інтеграції. Тому було вибрано широко поширений протокол зв’язку Modbus і спрощено відповідно до конкретних вимог пристрою, що забезпечує успішний між-модульний зв’язок із доведеною ефективністю. Modbus використовує модель зв’язку «головний-підлеглий». Ведучий спочатку надсилає команду запиту на зв'язок підлеглому. Потім підлеглий пристрій відповідає головному з даними на основі коду функції в команді запиту. Кожен підлеглий пристрій має унікальну адресу. І кадри запиту, надіслані головним, і кадри відповіді, надіслані підлеглим, починаються з адреси підлеглого. Підлеглі читають лише команди, адресовані їм самим, і ігнорують повідомлення, що починаються з інших підлеглих адрес. Ця функція реалізована за допомогою режиму 2 або 3 послідовного порту 8051. Ця модель зв’язку-і-відповідей значно підвищує точність зв’язку. У цьому пристрої використовується режим передачі RTU Modbus.
4 Заходи для підвищення надійності зв'язку
Останні два байти повідомлення Modbus служать байтами контрольної суми. Зв'язок RTU використовує перевірку циклічної надлишковості CRC-16 для виявлення помилок. Його механізм кодування/декодування відносно простий з низьким рівнем помилок, що досягається за допомогою обчислювальних методів або методів програмування. Нижче наведено кілька підходів:
4.1 Основний алгоритм (обчислення вручну)
На прикладі CRC16-CCITT: контрольна сума CRC становить 16 біт, а генеруючий поліном — 17 біт. Припустимо, що потік даних становить 4 байти: BYTE, BYTE, BYTE, BYTE[0];
Зсув потоку даних вліво на 16 біт, фактично розширюючи його на коефіцієнт 256×256. Потім виконайте ділення на генераторний поліном 0x11021 за допомогою не-позикового ділення (еквівалентно побітовому XOR). Отриманий залишок є контрольною сумою CRC. Потік переданих даних складається з 6 байтів: BYTE, BYTE, BYTE, BYTE[0], CRC, CRC[0].
4.2 Комп’ютерний алгоритм 1 (алгоритм бітового-типу)
1) Помістіть старші 16 біт (BYTE, BYTE) розширеного потоку даних (6 байт) у 16-бітний регістр;
2) Якщо старший біт регістра дорівнює 1, зрушити регістр вліво на один біт (отримавши молодший біт із наступного байта), потім виконати операцію XOR зі спрощеною формою генераторного полінома; в іншому випадку просто зсув регістра вліво на один біт (отримання молодшого значущого біта з наступного байта);
3) Повторюйте крок 2, поки весь потік даних (6 байт) не буде зсунутий у регістр;
4) Значення в регістрі є контрольною сумою CRC CRC, CRC[0].
4.3 Комп’ютерний алгоритм 2 (алгоритм типу байт-) (256^n позначає 256 у ступені n)
Уявіть упорядкований по байтам потік даних як математичний поліном. Нехай потік даних буде BYTE[n] BYTE[n-1] BYTE[n-2] ... BYTE[0] представлено як математичний вираз
BYTE[n] × 256^n + BYTE[n-1] × 256^(n-1) + ... + BYTE × 256 + BYTE[0], де «+» позначає операцію XOR. Нехай генераторний поліном буде G17 (17-біт), тоді код CRC буде CRC16.
CRC16=(БАЙТ[n] × 256^n + БАЙТ[n-1] × 256^(n-1) + ... + БАЙТ × 256 + БАЙТ[0]) × 256^2 / G17
Це передбачає зсув потоку даних вліво на 16 біт, а потім ділення на генераторний поліном G17.
Виведення показує, що контрольний код CRC для BYTE[n-1] дорівнює результату XOR старших 8 біт контрольного коду CRC попереднього байта Y[n] (YH8[n]) і поточного байта BYTE[n-1].
Алгоритм типу byte- такий:
1) Ініціалізуйте групу регістрів CRC усіма «0» (0x0000).
2) Зрушити групу регістрів CRC на 8 біт вліво та зберегти її в групі регістрів CRC.
3) Виконайте операцію XOR між старшими 8 бітами початкової групи регістрів CRC (зміщеними на 8 біт праворуч) і байтом даних, щоб отримати індекс, що вказує на таблицю значень.
4) Виконайте операцію XOR між табличним значенням, на яке вказує індекс, і групою регістрів CRC.
5) Збільшити покажчик даних. Якщо обробка даних не завершена, повторіть крок 2).
6) Отримайте CRC.
5 Заходи для підвищення ефективності зв'язку
5.1 Окремі завдання отримання та передачі зв’язку
Мікроконтролер 8051 може передавати і отримувати дані через послідовний порт за допомогою переривань. Контролер послідовного порту SCON підтримує ініціалізацію та бітову адресацію. Коли виникає запит на переривання послідовного порту, молодші два біти SCON фіксують переривання передавання та отримання. Коли ЦП записує дані або символ у буфер передачі SUBF послідовного порту (інструкція: MOV SUBF, A), передавач починає надсилання. Після завершення одного кадру даних апаратне забезпечення встановлює прапор TI на «1», вказуючи, що послідовний порт запитує переривання від ЦП для надсилання наступного кадру даних. Подібним чином, якщо приймач послідовного порту ввімкнено для прийому, після отримання кадру даних прапор RI встановлюється на 1, вказуючи, що послідовний порт запитує переривання від ЦП для читання даних із буфера отриманих даних.
5.2 Зменшення тривалості переривання
Оскільки в розробці архітектури програмного забезпечення використовуються численні переривання, для забезпечення надійної роботи програми та мінімізації ймовірності конфліктів між різними завданнями програмна реалізація повинна прагнути оптимізувати завдання різних переривань і скоротити час їх виконання. У підпрограмі переривання зв’язку виконайте основні завдання після входу в переривання, наприклад: очищення відповідних бітів стану в регістрі керування послідовним портом, читання отриманих символів або запис символів, які потрібно передати з/до буфера, збільшення кількості отриманих або переданих символів тощо. Потім негайно вийдіть із переривання. Інші завдання, такі як перевірка кадрів, відповідь на отримані команди кадрів (телеметрія/телекоманда) і підготовка кадрів передачі, повинні виконуватися в рамках основної програми.
5.3 Ефективне виявлення завершення кадру для запобігання застою зв’язку
Використання спеціального програмного таймера для виявлення кінця отриманого кадру запобігає затримці завдань зв’язку, якщо кадр отримано не повністю, тим самим забезпечуючи своєчасне отримання наступних кадрів. Оскільки проміжок часу між байтами в кадрі набагато коротший, ніж інтервал від-до-кадру, програмний таймер запускається щоразу, коли надходить новий байт. Таймер встановлено на мінімальний інтервал--кадр. Цей інтервал залежить від різних швидкостей передачі даних. Якщо наступний байт отримано до закінчення встановленого часу, це означає, що кадр не завершений, і таймер перезапускається. Якщо таймер успішно відраховує встановлений час, він запускає відповідний номер переривання. У підпрограмі переривання таймера встановлюється байт прапора кінця кадру, що означає, що прийом кадру завершено. Після того, як головна програма виявляє завершення прийому кадру, вона перевіряє цілісність кадру, перевіряючи адресу підлеглого та байт перевірки циклічної надлишковості (CRC). Якщо кадр підтверджено як дійсний, призначений для головного, він обробляє команду кадру на основі свого функціонального коду та готується до надсилання кадру. Коли підлеглий пристрій отримує неправильне повідомлення, він повертає кадр помилки. Якщо отримане повідомлення має неправильний CRC, підлеглий пристрій може не відповідати. Якщо головний не отримає відповідь від підлеглого протягом зазначеного часу, він повторно передасть повідомлення запиту. Якщо кілька повторних передач не можуть отримати відповідь від підлеглого, повідомляється про збій зв’язку.
5.4 Визначення швидкості зв'язку
Оскільки всі пристрої знаходяться в одному шасі, відстань між модулями мінімальна. Modbus працює на RS485 для-зв’язку на великій відстані, усуваючи необхідність враховувати вплив відстані на швидкість передачі даних. Крім того, режим зв’язку «головний-підлеглий» запобігає перевантаженню лінії. Таким чином, з точки зору ефективності зв’язку, доки встановлена швидкість передачі даних не перевищує обмеження максимальної швидкості передачі даних мікросхеми, що використовується в модулі, більш висока швидкість передачі даних призводить до швидшого обміну інформацією та вищої ефективності зв’язку. Встановлення абсолютно однакової швидкості передачі даних для обох сторін зв’язку гарантує, що приймаюча сторона відбирає кожен біт даних у середині бітового циклу, таким чином досягаючи надійного зв’язку.
5.5 Розумні методи налагодження
Під час налагодження спочатку перевірте зв’язок між кожним модулем центрального процесора та мікрокомп’ютером через модуль перетворення даних RS485/RS232. Після успішного індивідуального тестування перейдіть до між-налагодження модулів, значно покращуючи загальну ефективність налагодження. Під час налагодження зв’язку від-до-комп’ютера комп’ютер використовує програмне забезпечення для налагодження Modbus для імітації процесу зв’язку провідного, активно запитуючи інформацію від підлеглого. Це робить весь процес прийому та передачі прозорим і зрозумілим, що дозволяє своєчасно вирішувати проблеми з модулями. Під час спільного налагодження програмне забезпечення моніторингу шини спостерігає за даними з обох сторін, щоб швидко виявляти та вирішувати проблеми.
6 інноваційних моментів цієї статті
По-перше, цей документ використовує Modbus, універсальний промисловий стандарт, у пристрої захисту. Необхідне інструментальне програмне забезпечення можна отримати безпосередньо з відповідних веб-сайтів без витрат на інтелектуальну власність. По-друге, пристрій захисту реалізує багатозадачність і використовує протокол Modbus для створення прийнятного механізму спільного налагодження між модулями ЦП, що значно підвищує ефективність спільної розробки системи.