Разработка автоматизированных тестов для проверки соответствия программных и аппаратных средств протоколу обмена данными Модбас

Современные информационные технологии/2. Вычислительная техника и программирование

И.Ю. Кривокора

Санкт-Петербургский государственный политехнический университет, Россия

Истинным преимуществом любого открытого стандарта является обеспечение пользователей уверенностью, что покупаемые ими продукты будут взаимодействовать без проблем. К сожалению, любая спецификация, независимо от того, насколько тщательно она написана, подлежит различному толкованию и случайным недоразумениям и ошибкам в её реализации. И именно возможность наличия ошибок в программной реализации делает актуальным и необходимым создание набора тестов и испытаний на соответствие стандарту.

Учитывая широкое распространение протокола обмена данными Модбас для нужд промышленной электроники, проверка изготовляемой продукции на корректность реализации спецификациям протокола Модбас проводится в целях повышения качества продукции и её конкурентной привлекательности.

В связи с этим цель разработки данного испытания – повышение и способствование полноте функциональности различных программных и аппаратных средств, использующих протокол обмена данными Модбас.

1. Общее описание протокола Модбас

Протокол Модбас был разработан компанией Modicon (в настоящее время принадлежит SchneiderElectric) для использования в её контроллерах с программируемой логикой. Впервые спецификация протокола была опубликована в 1979 году. В настоящее время развитием протокола занимается некоммерческая организация Modbus-IDA.

Контроллеры на шине Модбас взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов — «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы) и может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство отвечает на запрос, адресованный именно ему.

Протокол является необходимой частью работы системы. Он определяет, как главное и подчиненное устройства устанавливают и прерывают контакт, как идентифицируются отправитель и получатель, каким образом происходит обмен сообщениями, как обнаруживаются ошибки. Протокол управляет циклом запроса и ответа, который происходит между главным и подчиненным устройствами, как это показано на рисунке 1.

Рисунок 1 – Цикл запрос-ответ, происходящий между главным и подчиненным устройствами

Некоторые характеристики протокола Modbus фиксированы. К ним относятся формат кадра, последовательность кадров, обработка ошибок коммуникации и исключительных ситуаций и выполнение функций.

При передаче по линиям данных, сообщения помещаются в «конверт». «Конверт» покидает устройство через «порт» и «пересылается» по линиям адресуемому устройству. Протокол Modbus описывает «конверт» в форме кадров сообщений. Информация в сообщении представляет адрес требуемого получателя, что получатель должен сделать, данные, необходимые для выполнения этого, и механизм контроля достоверности.

Когда сообщение достигает интерфейса подчиненного устройства, оно попадает в адресуемое устройство через похожий «порт». Адресуемое устройство вскрывает конверт, читает сообщение, и, если не возникло ошибок, выполняет требуемую задачу. Затем оно помещает в конверт ответное сообщение и посылает его «отправителю». Информация в ответном сообщении представляет собой адрес адресуемого устройства, выполненную задачу, данные, полученные в результате выполнения задачи, и механизм контроля достоверности.

2. Разработка спецификации тестов

Испытания на соответствие протоколу Модбас должны проверять корректность ответов подчиненными устройствами на поддерживаемые коды функций Модбас. Необходимо проверять формат ответного сообщения, но, при этом, возвращаемые в ответе специфические данные не должны проверяться. На соответствие проверяются положение и информация в полях, не являющимися полями данных. Также проверяются другие аспекты спецификации, включая коды исключительных ситуаций в ответах на поврежденные сообщения или неподдерживаемые коды функций.

В сообщении к подчиненному устройству указывается код функции, который определяет, какое действие адресуемое устройство должно выполнить. Список кодов modbus-функций отражен в таблице 1.

Каждая из указанных функций имеет строго определенный формат как посылаемого к подчиненному устройству сообщения, как и его ответа к главному устройству. Исходя из этих данных существует возможность создания конечного набора тестов, проверяющего как корректность ответа на запрос, так и действий подчиненного устройства в случае ошибок в отправляемом ему запросе.

Таблица 1 – Список кодов функций протокола Модбас

Код (dec)	Имя	Тип данных
1	Чтение логических ячеек (ReadCoils)	0x
2	Чтение дискретных входов (ReadDiscreteInputs)	1x
3	ЧтениеHolding-регистров (Read Holding Registers)	4x
4	ЧтениеInput-регистров (Read Input Registers)	3x
5	Записьоднойячейки (Write Single Coil)	0x
6	Записьодногорегистра(Write Single Register)	4x
8	Тестовая функция (Diagnostics)	Диагностическая функция
15	Запись нескольких ячеек (WriteMultipleCoils)	0x
16	Запись нескольких регистров (WriteMultipleRegisters)	4x
17	Чтение информации об адресуемом устройстве (ReportSlaveID)	Диагностическая функция

Во время обмена данными могут возникать ошибки двух типов:

- ошибки, связанные с искажениями при передаче данных;

- логические ошибки.

Ошибки первого типа обнаруживаются при помощи фреймов символов, контроля чётности и циклической контрольной суммы CRC-16-IBM.

Для сообщений об ошибках второго типа протокол Модбас предусматривает, что устройства могут отсылать ответы, свидетельствующие об ошибочной ситуации.

Коды исключительных ситуаций приведены в таблице 2.

Таблица 2 - Исключительные ситуации протокола Модбас

Код (hex)	Имя	Значение
01	ILLEGAL FUNCTION	Код функции, переданный в запросе, является недопустимым для данногоSL.
02	ILLEGAL DATA ADDRESS	Адрес данных, переданный в запросе, является недопустимым для данногоSL.
03	ILLEGAL DATA VALUE	Значения, содержащиеся в поле данных запроса, являются недопустимыми для данного SL.
04	FAILURE IN ASSOCIATED DEVICE	Возникновение критической ошибки при попытке SL выполнить запрос.
05	ACKNOWLEDGE	SL получил запрос и обрабатывает его, но обработка займет большое количество времени.
06	SLAVEDEVICEBUSY	SL выполняет долговременную операцию программирования.
07	NAK-NEGATIVE ACKNOWLEDGMENT	Функция программирования не может быть выполнена.

Когда адресуемое устройство обнаруживает одну их этих ошибок, оно посылает ответное сообщение главному устройству, содержащее адрес, код функции, код ошибки и контрольную сумму. Для указания на то, что ответное сообщение – это уведомление об ошибке, старший бит поля кода функции устанавливается в 1.

Рассмотрим, например, исключительную ситуацию с кодом 2. Для контроллера с 100 регистров протокольная единица обмена адресует первый регистр как 0, и последний как 99. Если в запросе номер первого регистра 96 и количество регистров равно 4, то такой запрос будет успешно обработан для регистров 96, 97, 98, 99. Если в запросе номер первого регистра 96 и количество регистров равно 5, то такой запрос должен вызвать исключительную ситуацию с кодом 0x02 "IllegalDataAddress", так как будет предпринята попытка работы с регистрами 96, 97, 98, 99 и 100, но регистра с адресом 100 нет. Что требует отдельной проверки.

На рисунке 2 изображен алгоритм проверки модбас-сообщения, на основании которого должен работать набор тестов проверки соответствия протоколу.

3. Реализация набора тестов протоколаМодбас

3.1. Определение исходных данных для тестов

Тест проверяет на ошибки передачи или приема только модбас-сообщения. Документация к устройству должна указывать, какие коды modbus-функций поддерживаются устройством. Поддерживаются следующие типы:

- 0x– логические ячейки;

- 1x– дискретные входы;

- 3x– Input-регистры;

- 4x– Holding-регистры.

Также разработчик должен предоставить следующую информацию об испытываемом устройстве:

- количество регистров каждого из поддерживаемых типов;

- какие из логических ячеек или holding-регистров предназначены только для чтения;

- есть ли некоторый уникальный предел для максимального количества данных, которые могут быть прочитаны или записаны за один запрос;

- возможность доступа на запись/чтение регистров при разных режимах работы.

Рисунок 2 – Алгоритм проверки модбас-сообщения

3.2. Пример методики испытаний функции с кодом 3

В испытании для функции с кодом 3 (чтение Holding регистров) отправленный modbus-запрос будет следующего вида:

01 03 00 05 00 01 94 0b

Где:

Адрес SL: 01

Код функции: 03

Старший байт физического адреса первого регистра: 00

Младший байт физического адреса первого регистра: 05

Старший байт количества регистров для чтения: 00

Младший байт количества регистров для чтения: 01

Контрольная сумма: 94 0b

Чтобы пройти этот тест, устройство (прибор) должно вернуть ответ следующего вида:

01 03 02 XX XX YY YY

Где:

Адрес SL: 01

Код функции: 03

Количество байт в поле данных: 02

Содержимое регистра (два байта): XX XX

Контрольная сумма (два байта): YY YY

Для выполнения испытаний разработчик предоставляет список используемых адресов Holding-регистров (карту регистров). Если иное не оговорено, в ходе испытания считается, что адреса регистров начинаются с 400001 (физический адрес 0). Все валидные регистры должны поддерживать валидные ответы. Испытываемое устройство должно поддерживать запросы на чтение регистров в количестве от 1 до 125 (если иное не оговорено в спецификации устройства). Любой запрос к регистру за пределами валидного диапазона должен получать соответствующий ответ с правильным кодом исключительной ситуации. Испытываемое устройство должно правильно отвечать на валидный запрос на чтение первого регистра, последнего регистра и максимального поддерживаемого блока регистров с валидными адресами. Эта функция должна рапортовать об исключительной ситуации в случае неверного запроса.

# firstreg reading

note = 'Чтениепервогорегистра'

messages = dev.functions_34(first_reg,1,function_code)

report_testcase(note + '\nПосылаетсязапрос: {0}'.format(vzmodbus.payloadToString(messages[0])),