CC BY
29
УДК 004.75 DOI: 10.17213/0321-2653-2017-1-13-18
ОЦЕНКА ВРЕМЕНИ ОТКЛИКА ЭЛЕМЕНТОВ В МОДУЛЬНЫХ ИНФОРМАЦИОННО-ИЗМЕРИТЕЛЬНЫХ И УПРАВЛЯЮЩИХ СИСТЕМАХ, ИСПОЛЬЗУЮЩИХ ИНТЕРФЕЙС CAN
ELEMENTS RESPONSE TIME EVALUATION IN MODULAR INFORMATION, MEASUREMENT AND CONTROL SYSTEMS THAT
USE CAN INTERFACE
© 2017 г. Д.А. Плотников
Плотников Дмитрий Александрович - канд. техн. наук, доцент, кафедра «Автоматика и телемеханика», ЮжноРоссийский государственный политехнический университет (НПИ) имени М.И. Платова, г. Новочеркасск, Россия. E-mail: [email protected]
Plotnikov Dmitry Älexandrovich - Candidate of Technical Sciences, assistant professor, department Automatics and Telemechanics», Platov South-Russian State Polytechnic University (NPI), Novocherkassk, Russia. E-mail: dpl161rus@ yahoo.com
Выявлены и проанализированы факторы, влияющие на величину времени отклика элементов информационно-измерительных и управляющих систем, использующих интерфейс CAN для организации межмодульного взаимодействия. Описаны причины, по которым распространенные протоколы высокого уровня не всегда обеспечивают необходимое быстродействие. Предложены способы количественной оценки верхней и нижней границ времени ожидания передачи и времени передачи сообщения. Даны рекомендации по уменьшению времени отклика элементов системы. Приведены примеры практических решений, направленных на уменьшение средней длины сообщений и времени подготовки сообщений.
Ключевые слова: интерфейс CAN; время отклика; время доставки сообщения; информационно-измерительная система.
The factors influencing the response time value of the information, measurement and control systems elements that use the CAN interface for the inter-module interaction are identified and analyzed. Article describes the causes for which popular high-level protocols do not always provide the necessary performance. The methods of quantifying upper and lower boundaries of the identified factors are proposed. Recommendations to reduce the response time are made. Examples of practical solutions to reduce the average message length and message preparation time are presented.
Keywords: CAN interface; response time; message delivery time; information and measuring system.
Современные информационно-измерительные и управляющие системы (ИИУС) нередко имеют модульную структуру, показанную на рис. 1. В соответствии с этой структурой ИИУС представляет собой совокупность взаимодействующих друг с другом функционально законченных модулей.
Для организации взаимодействия модулей друг с другом удобно использовать интерфейс CAN 2.0 [1], среди достоинств которого можно выделить следующие:
1) ориентированность на создание распределенных ИИУС, работающих в режиме реального времени;
2) высокая степень достоверности передаваемых данных и вероятность обнаружения ошибок;
3) экономичная шинная архитектура, невысокая стоимость аппаратных средств;
4) широкая поддержка со стороны производителей однокристальных микропроцессорных контроллеров (ОМК).
Линии ввода-вывода
Рис. 1. Типовая схема построения ИИУС: ПМ - процессорный модуль; МВВ - модули ввода-вывода; ММИ - межмодульный интерфейс; ВУ - верхний уровень
Важным параметром межмодульного интерфейса, определяющим возможность своевременной доставки информации и подлежащим оценке на начальных этапах проектирования ИИУС, является время отклика модулей системы на запросы, формируемые другими модулями. Широко распространенные высокоуровневые протоколы, реализованные на основе CAN, такие, например, как CANopen или DeviceNet, не всегда обеспечивают приемлемые значения времени отклика, что обусловлено их универсальностью и, как следствие, некоторой избыточностью, приводящей к снижению быстродействия. В частности, полноценная реализация протокола CANopen [2] требует постоянных обращений к объектному словарю, что увеличивает время подготовки сообщений. Кроме того, спецификация протокола жестко регламентирует использование идентификаторов сообщений, не позволяя оптимизировать его для конкретного применения. Похожие ограничения имеются и у протокола DeviceNet [3], который к тому же не позволяет работать на максимальной скорости CAN 1 Мбит/с. В связи с вышеизложенным, при создании высокопроизводительных ИИУС, использующих интерфейс CAN, нередко возникает задача разработки собственных протоколов взаимодействия, минимизирующих время отклика модулей на поступающие запросы.
Рассмотрим факторы, влияющие на время отклика модулей ИИУС. С точки зрения приложения, функционирующего на запрашивающем модуле, это время складывается из следующих величин:
1) время подготовки запроса ГПГЗ - включает в себя все операции по формированию кода запроса и его параметров, по настройке аппаратных средств запрашивающего модуля на передачу;
2) время ожидания доступа к каналу связи для передачи запроса ТОПЗ;
3) время передачи запроса ТПЗ;
4) время подготовки ответа ТПГО - включает в себя все операции по формированию кода ответа и его параметров, по настройке аппаратных средств запрашиваемого модуля на передачу;
5) время ожидания доступа к каналу связи для передачи ответа ТОПО;
6) время передачи ответа ТПО;
Полное время отклика определяется выражением
T = ^з+ТОГО+ТПЗ+ТПГО+ТОПО+ТПО .
Рассмотрим способы оценки этих параметров для интерфейса CAN.
Время подготовки запроса Tnr3 и ответа Tnro существенно зависит от быстродействия модулей и от сложности задач, выполняемых на верхних уровнях модели OSI [4]. Общие подходы к оценке этих параметров описаны в [5], способы уменьшения времени подготовки запроса и ответа, использованные автором, описаны далее.
Для оценки времени передачи сообщения Tn3, Tno проанализируем формат сообщений, предназначенных для обмена данными, а именно Data Frame. В соответствии со спецификацией CAN 2.0B [1] имеется два варианта Data Frame: стандартный (Standard) и расширенный (Extended). Как видно из рис. 2, сообщения содержат определенный набор полей. Полное описание и особенности использования каждого их них приведены в [1], в данной статье рассмотрены лишь факторы, влияющие на время передачи сообщения.
Все поля, за исключением поля данных, имеют фиксированную длину, показанную на рис. 2 (по умолчанию подразумевается длина 1 бит). Размер поля данных определяется значением поля DLC: оно задает число байтов данных в сообщении и может принимать значения от 0 до 8.
Рис. 2. Форматы сообщений типа Data Frame: а - стандартный; б - расширенный
Формат сообщения задается полем IDE: для стандартного формата его значение равно нулю, для расширенного - единице. Исходя из этого можно записать следующее выражение, позволяющее вычислить количество битов N в сообщении:
N = 44 + 20IDE + 8DLC.
(1)
Таким образом, суммарная длина сообщения стандартного формата варьируется в зависимости от размера поля данных в диапазоне от 44 до 108 битов, а длина сообщения расширенного формата - от 64 до 128 битов.
Время передачи одного бита T0 - величина, фиксированная для всех узлов сети CAN, и определяется выбранной скоростью обмена. Например, для скорости 1 Мбит/с T0 = 1 мкс. Однако, даже зная количество битов N в сообщении и время передачи бита T0, точно вычислить время передачи всего сообщения невозможно. Это связано с использованием технологии вставки битов (bit stuffing), суть которой заключается в следующем: если передатчик обнаружит в потоке передаваемых данных пять последовательных битов с одинаковыми значениями, то он автоматически вставляет в поток дополнительный бит с противоположным значением. Приемник, получая данные, автоматически удаляет дополнительные биты. Описанная процедура выполняется для предотвращения длительного нахождения линии связи в неизменном доминантном (ноль) или рецессивном (единица) состоянии, поскольку это помешает синхронизации приемников с потоком передаваемых данных.
Вставка битов не оказывает влияния на результат обмена данными, но может увеличить время передачи сообщения, причем количество дополнительных битов будет зависеть от содержания конкретного сообщения и поэтому в общем случае является случайной величиной.
В наиболее благоприятном случае число дополнительных битов равно нулю. Тогда время передачи сообщений стандартного и расширенного форматов Тм^ мм с учетом выражения (1) будет определяться как
TMSG MIN
= T0 (44 + 20IDE + 8DLC)
Далее рассмотрим наименее благоприятный случай для сообщений стандартного формата. Если поле «11 bit ID» равно 0x000 или 0x7FF, то в начале сообщения передаются двенадцать битов одинаковой полярности: SOF и «11 bit ID» или «11 bit ID» и RTR соответственно. Из-за этого в сообщение добавляются два дополнительных бита; затем между полями RTR и IDE происходит изменение уровня с 1 в 0, обнуляющее счетчик последовательных битов. Максимальное количество дополнительных битов NDS в полях IDE, r0 и «Данные» будет добавлено при передаче нулевых данных (при DLC = 3 - единичных); его можно вычислить по формуле, в которой квадратными скобками обозначена операция нахождения максимального целого числа, не превышающего заданную величину:
Nds =[8DLC/5]+A ,
где A = 1 при DLC е {0, 1, 3, 8}; иначе A = 0.
Значение поля CRC определяется содержимым предыдущих полей, однако зависимость количества последовательных одинаковых разрядов в этом поле от ранее переданных значений достаточно сложна и ее выявление, по мнению автора, нецелесообразно. Вместо этого будем считать, что в поле CRC могут быть добавлены максимум три дополнительных бита (в тех случаях, когда его значение равно 0x0000 или 0x7FFF). К оставшимся полям сообщения дополнительные биты не добавляются. Таким образом, для сообщений стандартного формата максимальное число дополнительных битов NBS может быть вычислено по формуле
NBS = 5+[8DLC/5]+A . (2)
Следовательно, максимальное время передачи сообщения стандартного формата TMSG_S_MAX с учетом (1) и (2) можно определить как
Tmsg s max = To (49+8DLC+[8DLC/5]+A) . (3)
Проанализируем наименее благоприятный случай для сообщений расширенного формата. Если поля «11 bit ID» и «18 bit ID» равны 0x7FF и 0x3FFFE соответственно, то в начале сообщения передаются тридцать битов со значением 1: «11 bit ID», SRR, IDE - и семнадцать старших разрядов поля «18 bit ID». Из-за этого в сообщение добавляются шесть дополнительных битов. Максимальное количество дополнительных битов Nde в полях RTR, r1, r0 и «Данные» с учетом нулевого значения в младшем разряде поля «18 bit ID» можно вычислить по формуле
Nde =[8DLC/5]+1+B ,
где B = 1 при DLC = 3; иначе B = 0.
Ранее было показано, что в поле CRC может быть добавлено три дополнительных бита. Следовательно, для сообщений расширенного формата максимальное число дополнительных битов Nbe может быть вычислено по формуле:
Nbe =10+[8DLC/5]+B . (4)
Максимальное время передачи сообщения расширенного формата TMSG_E_MAX с учетом (1) и (4) можно определить как
Tmsg e_max = T (74+8DLC+[8DLC/5]+B). (5)
Таким образом, минимальные значения параметров Tn3, Tno соответствуют величине Tmsgmn, а максимальные - величине Tmsg_s_max для сообщений стандартного формата и TMSG_E_MAX для сообщений расширенного формата.
Время ожидания доступа к каналу связи (ТОПЗ, ТОПО) определяется приоритетами и количеством других сообщений, ожидающих передачи, а также состоянием канала (свободен или занят) в момент запроса на передачу. Поскольку интерфейс CAN имеет шинную архитектуру, в каждый момент времени может передаваться лишь одно сообщение. В первую очередь передаются высокоприоритетные сообщения, затем -менее приоритетные. Вопросы назначения приоритетов решаются на верхних уровнях модели OSI, не описываемых спецификацией CAN, и
выходят за рамки данной статьи. Некоторые рекомендации по оценке времени доставки сообщений с учетом их приоритетов приведены в [5].
Проанализируем время ожидания доступа для наиболее приоритетного сообщения. Если в момент запроса на его передачу канал связи свободен, то передача начинается немедленно и время ожидания равно нулю. Если же канал связи занят, то запрос на передачу будет обработан лишь после освобождения канала независимо от приоритета ожидающего сообщения. Максимальная длительность занятого состояния канала связи равна максимальному времени передачи сообщения (выражения (3), (5)). Кроме того, согласно [1] минимальный интервал между сообщениями (interframe space) составляет 3T0. Следовательно, максимальное время ожидания доступа к каналу связи для наиболее приоритетного сообщения стандартного формата определяется выражением
twait_s_max =T0(52 + 8DLCmax +[8DLCmaxi5]+ A),
где DLCmax - максимальное количество байтов в поле данных передаваемых сообщений.
Для сообщений расширенного формата
TWAIT_E_MAX =T0 (77+8DLCmax +[8DLCmax/5]+ A) .
Таким образом, минимальные значения параметров ТОПЗ, ТОПО равны нулю, а максимальные - величине TWAIT_S_MAX для сообщений стандартного формата и Twait e max для сообщений расширенного формата.
Из приведенных выражений очевидно, что для уменьшения среднего времени отклика модулей ИИУС следует стремиться к уменьшению времени подготовки запроса ТПГЗ и ответа ТПГО, а также средней длины передаваемых сообщений. Этого можно добиться следующими способами:
1. Осуществлять подготовку запросов и ответов заранее. Если число различных запросов невелико, их можно сформировать при инициализации приложения и сохранить в специальных областях памяти контроллера CAN - в так называемых объектах сообщений (message objects MO). Широко используемый в настоящее время в составе ОМК контроллер C CAN [6] обеспечивает работу с тридцатью двумя MO. В этом случае подготовка запроса к передаче в рабочем режиме сводится лишь к записи команды «Передача MO» в соответствующий регистр управления.
Аналогичным образом может быть выполнена и подготовка ответов: данные для передачи записываются в МО сразу после их изменения (и только в этом случае), а при поступлении запроса приложение формирует команду «Передача» соответствующего МО. Описанный подход был использован автором при разработке модульного регистратора событий [7] на базе ОМК LPC11C24 [8] и позволил уменьшить время подготовки запроса ТПГЗ до нескольких десятков наносекунд, а время подготовки ответа ТПГО (с учетом времени анализа запроса) - до единиц микросекунд.
2. По возможности передавать данные полностью или частично не в поле данных, а в поле идентификатора сообщения; при этом размер поля данных уменьшить до минимально необходимой величины - в предельном случае до нуля. Это возможно в тех случаях, когда требуется небольшое количество типов сообщений: тогда одна часть поля идентификатора используется для указания типа сообщения, а другая - для передачи данных. Примерами данных, полностью передаваемых в поле идентификатора, могут служить признаки состояния (исправен / неисправен, готов / не готов), номер запрашиваемого модуля, признак запрашиваемой информации и т.п.
3. Избегать передачи данных с длинными последовательностями битов одинакового значения для предотвращения вставки битов. Из выражений (2) и (4) следует, что из-за таких последовательностей к сообщениям стандартного формата может быть добавлено до восемнадцати дополнительных битов, что составляет 16,6 % от номинального размера сообщения. К сообщениям расширенного формата добавляется до двадцати двух битов (17,2 %). Соответственно увеличивается и время передачи сообщений. Если вероятность появления описанных последовательностей высока, то данные перед передачей целесообразно модифицировать (например, складывать по модулю «2» с числом 0x55), а после приема - восстанавливать. Длительность операций модификации и восстановления данных на современных ОМК обычно существенно меньше времени передачи дополнительных битов.
4. Комбинировать использование сообщений стандартного и расширенного форматов. Первые имеют небольшую длину, вторые позво-
ляют передать больше полезной информации (обладают меньшей избыточностью) за счет частичного использования поля идентификатора для передачи данных. Контроллеры CAN современных ОМК [6, 8] предоставляют возможность одновременной работы с сообщениями обоих форматов.
Приведенные рекомендации были использованы автором при разработке протоколов взаимодействия модулей регистратора событий [7], а также элементов цифровой системы вибромониторинга, описанных в [9, 10]. Полученные протоколы позволили уменьшить среднее время отклика модулей на 40.. .60 % по сравнению с протоколом CANopen, функционирующим в тех же условиях.
Литература
1. CAN Specification. Version 2.0 / Robert Bosch GmbH, 1991. 73 p. URL: http:// www.bosch-semiconductors.de / media / ubk_semiconductors / pdf_1 / canliteratur / can2spec.pdf (дата обращения: 23.01.2017).
2. CANopen application layer and communication profile. Version: 4.2.0 21 February 2011 / CAN in Automation e. V. 2011. 58 p. URL: http://www.can-cia.org (дата обращения: 23.01.2017).
3. DeviceNet - CIP on CAN Technology / ©1999-2016 ODVA, Inc. - 2016. - 8 p. URL: https:// www.odva.org / Portals / 0 / Library / Publications_Numbered / PUB00026R4_Tech-Adv-Series-DeviceNet.pdf (дата обращения: 23.01.2017).
4. ГОСТ Р ИСО/МЭК 7498-1-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель. введ. 1.01.2000. М.: Изд-во стандартов, 1999. 58 с.
5. Никифоров В.В., Шкиртиль А.И. Оценка времени доставки сообщений в распределенных системах реального времени с CAN-интерфейсом // Изв. вузов. Приборостроение. 2010. № 7. С. 33 - 39.
6. C_CAN User's Manual. Revision 1.2. / Robert Bosch GmbH, 2000. - 45 p. URL: http:// www.keil.com / dd / docs / datashts / silabs / boschcan_ug.pdf (дата обращения: 23.01.2017).
7. 4226-002-0162835132-07 РЭ Регистратор событий «Пуль-сар-М». Руководство по эксплуатации. - 2016. - 30 c. URL: http:// www.pulsar-m.ru / docs / pulsar_m_re.pdf (дата обращения: 15.12.2016).
8. LPC11Cx2/Cx4 32-bit ARM Cortex-M0 microcontroller. Rev. 3.2 - 4 January 2016. © NXP B.V. - 2016. - 64 p. URL: http:// www.nxp.com / documents / data_sheet / LPC11CX2_CX4.pdf (дата обращения: 23.01.2017).
9. Лачин, В.И., Малина А.К., Плотников Д.А. Многоуровневая распределенная система мониторинга вибрационного состояния и защиты турбоагрегатов // Информаци-
онные технологии и управление: юбилейный сб. науч. тр. факультета информационных технологий и управления / Юж.-Рос. гос. техн. ун-т. Новочеркасск: ред. журн. «Изв. вузов. Электромеханика», 2001. С. 69 - 74.
10. Плотников, Д.А. Совершенствование интеллектуального датчика вибрации для систем вибрационного монито-
ринга турбоагрегатов // Микропроцессорные, аналоговые и цифровые системы: проектирование и схемотехника, теория и вопросы применения: материалы X Междунар. науч.-практ. конф., г. Новочеркасск, 29 окт. 2010 г. / Юж.-Рос. гос. ун-т (НПИ). Новочеркасск: ЮРГТУ, 2010. С. 49 - 51.
References
1. CAN Specification. Version 2.0 / Robert Bosch GmbH, 1991. 73 p. Available at: http:// www.bosch-semiconductors.de / media / ubk_semiconductors / pdf_1 / canliteratur / can2spec.pdf (accessed: 23.01.2017).
2. CANopen application layer and communication profile. Version: 4.2.0 21 February 2011 / CAN in Automation e. V. 2011. 158 p. Available at: http://www.can-cia.org (accessed: 23.01.2017).
3. DeviceNet - CIP on CAN Technology / ©1999-2016 ODVA, Inc. - 2016. 8 p. Available at: https:// www.odva.org / Portals / 0 / Library / Publications_Numbered / PUB00026R4_Tech-Adv-Series-DeviceNet.pdf (accessed: 23.01.2017).
4. GOST R ISO/IEC 7498-1-99 Information technology. Open Systems Interconnection. Basic Reference Model. Part 1. The Basic Model. - introduced [GOST R ISO/MEK 7498-1-99 Informatsionnaya tekhnologiya. Vzaimosvyaz' otkrytykh sistem. Bazovaya etalonnaya model'. Chast' 1. Bazovaya model'.]. Moscow, Izd-vo standartov, 2000, 58 p.
5. Nikiforov V.V., Shkirtil' A.I. Otsenka vremeni dostavki soobshchenii v raspredelennykh sistemakh real'nogo vremeni s CAN-interfeisom [Estimation of Message Delivery Time in Distributed RealTime Systems with CAN-Interface]. Izvestiya vysshikh uchebnykh zavedenii. Priborostroenie, 2010, no. 7, pp. 33-39. [In Russ.]
6. C_CAN User's Manual. Revision 1.2. / Robert Bosch GmbH, 2000. 45 p. Available at: http:// www.keil.com / dd / docs / datashts / silabs / boschcan_ug.pdf (accessed: 23.01.2017).
7. 4226-002-0162835132-07 UM Events Registrator «Pulsar M». User's Manual. 2016. 30 p. Available at: http:// www.pulsar-m.ru / docs / pulsar_m_re.pdf (accessed: 15.12.2016).
8. LPC11Cx2/Cx4 32-bit ARM Cortex-M0 microcontroller. Rev. 3.2 - 4 January 2016. © NXP B.V. 2016. 64 p. Available at: http:// www.nxp.com / documents / data_sheet / LPC11CX2_CX4.pdf (accessed: 23.01.2017).
9. Lachin V.I., Malina A.K., Plotnikov D.A. [Multi-level distributed system for vibromonitoring and protection of turbine units]. Informatsionnye tekhnologii i upravlenie: yubileinyi sb. nauch. tr. fakul'teta informatsionnykh tekhnologii i upravleniya [Information Technologies and Control: an anniversary collection of scientific papers of the Information Technologies and Control Faculty]. Novocherkassk, Red. zhurn. «Izv. vuzov. Elektromekhanika», 2001, pp. 69-74. [In Russ.]
10. Plotnikov D.A. [Improving smart vibration sensor for turbine units monitoring]. Mikroprotsessornye, analogovye i tsifrovye sistemy: proektirovanie i skhemotekhnika, teoriya i voprosy primeneniya: materialy X Mezhdunar. nauch.-prakt. konf. [Microprocessor, analog and digital systems: engineering and circuit design - theory and application issues: Materials of the X International scientific and practical conference]. Novocherkassk, SRSTU, 2010, pp. 49-51. [In Russ.]
Поступила в редакцию 24 января 2017 г.
