CC BY
1
Выполнив как можно больше этих действий, можно уменьшить количество оставляемой о себе информации до минимума.
С распространение Интернета люди все больше доверяют свою информацию открытым источникам. Популярная фраза «Большой брат следит за тобой» из романа-антиутопии Джорджа Оруэлла, с каждым годом все лучше описывает жизнь человека. Только вместо правителя, лидера партии, «Большим братом» выступает Интернет, который помнит все. Список использованной литературы:
1. Разведка по открытым источникам // Wikipedia. URL: https://ru.wikipedia.org/wiki/Разведка_ по_открытым_источникам (дата обращения: 16.12.2023).
2. OSINT // SkillFactory Media. URL: https://blog.skillfactory.ru/glossary/osint/ (дата обращения: 16.12.2023).
© Гулак А.М., 2023
УДК 004.414.2
Дубачев Д.В.
ведущий программист ООО "Автоматизированные Системы Транспорта"
Воронеж, РФ
ПРОЕКТИРОВАНИЕ УНИВЕРСАЛЬНОГО АДАПТЕРА ДЛЯ УПРАВЛЕНИЯ ПЕРИФЕРИЙНЫМИ ФИЗИЧЕСКИМИ УСТРОЙСТВАМИ. ПОСТАНОВКА ЗАДАЧИ. ОРГАНИЗАЦИЯ РАБОТЫ С УСТРОЙСТВАМИ.
Аннотация
Объектом рассмотрения этой статьи является система взаимодействия с периферийным устройством, использующим пакетный тип обмена данными посредством различных технологий передачи данных по каналам связи, организующая универсальный интерфейс и выполняющая функции адаптера. Показаны общие принципы построения систем контроля таких устройств, требования к системам управления и обмена данными, а также приведен вариант построения такой системы.
Ключевые слова
Пакетный тип обмена информацией, периферийные физические устройства, фрейм, объектно-ориентированный подход, функциональные блоки, протокол обмена данными,
очередь команд, множественный доступ.
Dubachev D. V.
DESIGNING A UNIVERSAL ADAPTER FOR PERIPHERAL PHYSICAL DEVICE MANAGEMENT.
PROBLEM STATEMENT. ORGANIZATION OF WORK WITH DEVICES.
Abstract
The object of this article is the system of interaction with a peripheral device that uses a packet type of data exchange through various technologies for transmitting data via communication channels. This system also organizes its own interface and performs the functions of the adapter. General principles of construction of the monitoring systems of such devices, the requirements for control and data exchange systems, and an option for constructing such a system are revealed.
Key words
Packet type of information exchange, peripheral physical devices, frame, object-oriented approach, functional blocks, data exchange protocol, command queue, multiple access.
Введение. Развитие IT технологий непременно требует не только чисто программных средств предоставления сервисов, но в большей степени обеспечивать управление различного рода исполнительными устройствами, а также получать информацию от физических датчиков. Большинство устройств имеет пакетный тип обмена информацией, а также непременно обладают важнейшими общими для всех устройств базовыми функциями. Для программиста, задачей которого является интеграция различного рода оборудования весьма полезно создание не отдельной реализации протокола под каждое устройство, а одной универсальной системы, позволяющей внедрить устройство с его протоколом более эффективно и с наименьшими затратами. Также немаловажным будет более легкая поддержка кода и отладка в дальнейшем за счет использования типовых паттернов при программировании системы.
Принципы организации работы с устройствами. У каждого рассматриваемого здесь устройства система обмена данными представляет из себя совокупность пакетов (фреймов), так или иначе разделенных между собой [2]. Каждый фрейм имеет начало и конец и может быть однозначно определен согласно особенностям того или иного протокола следующими признаками:
- признак начала посылки + минимальный таймаут между посылками
- признак начала посылки + признак конца посылки
- признак начала посылки + длина посылки
- признак начала посылки + фиксированная наперед заданная длина посылки
Для обеспечения повышенного контроля целостности данных при обмене пакетами возможны комбинации предыдущих способов маркировки начала и конца фрейма, а также применение контрольной суммы к данным [4], [7]:
- признак начала посылки + длина посылки + контрольная сумма + признак конца посылки.
При наличии признаков начала/конца фрейма, значение которых не запрещено в передаваемых данных используется замена таких значений на комплементарные пары значений (экранирование специальных/служебных символов). При декодировании соответственно производится обратная операция.
Например, фрейм структуры 0x02......0x03 с данными кодируемыми всеми возможными
шестнадцатеричными значениями (т. е. Включая 0x02 и 0x03) получаем такую таблицу замены (Таблица 1):
Таблица 1
Пример экранирования служебных символов
Исходное значение байта данных Перекодированное значение в комплементарную пару
0x02 0x1B 0xE7
0x03 0x1B 0xE8
0x1B 0x1B 0x00
Организация обмена командами происходит следующим образом:
- хост посылает фрейм с командой на выполнение, устройство присылает фрейм с ответом по окончании операции.
Однако для длительных процессов производители часто предусматривают иной способ
верификации заданного действия:
- хост посылает фрейм с командой на выполнение, устройство немедленно отвечает для подтверждения приема команды, затем присылает дополнительно фрейм по окончании операции. Соответственно поведению второго типа возможны два варианта передачи конечной информации внешней системе:
- передача ответа при получении подтверждения приема команды от устройства, затем уведомление внешней системы об окончании операции по предусмотренному для этого дополнительному каналу связи;
- передача ответа внешней системе только по окончании операции.
Оба метода имеют свои существенные недостатки: в первом случае необходимо предусматривать специальный дополнительный канал связи, второй случай реализовать невозможно при организации обмена например по REST API с использованием GET или POST запросов так как соединение обычно имеет конечный таймаут и есть риск превышения этого таймаута.
Проектирование системы для работы с устройствами. При разработке системы будем руководствоваться объектно-ориентированным подходом и разделять весь код на отдельные функциональные блоки [8] для лучшего понимания процессов, а также возможности выделения блоков, программируемых для каждого устройства и общих блоков, создающих структуру системы.
Таким образом в системе можно структурно выделить следующие необходимые функции, непосредственно участвующие в процессе приема-передачи данных (Рис. 1):
т
constructFrameO
~г
write Frame ()
Рисунок 1 - Общая блок-схема структуры системы
Data to Device
\ \ /
/
• функция-сборщик фрейма constructFrame() компанует все данные фрейма воедино для посылки на устройство, включая экранирование, признаки начала и конца фрейма, контрольную сумму.
• Затем результат функции попадает в систему передачи данных writeFrame(). В ее функции входит не только непосредственная запись данных в порт устройства, но и запуск таймера ожидания ответа, а также контроль повторной посылки (если это применимо) на устройство в случае отсутствия ответа от устройства до того как оно признается недоступным, либо в случае ошибки в принятых данных.
• Функция getFrame() (сборщик принимаемых данных) также производит сборку принимаемых от
устройства данных, включая декодирование специальных символов с экранированием и первичный контроль целостности данных, затем отправляет их на анализ непосредственно в analizeRxData().
• АnalizeData() непосредственно разбирает принятые данные, заполняет необходимые поля статуса устройства и вызывает менеджер очереди nextQueueRequest().
Сборщик фрейма, сборщик принимаемых данных и функция анализа данных программируются для каждого протокола отдельно, в то время как функция отправки остается единой для любого протокола. Дальнейшая детализация структуры системы покажет автоматизацию работы с устройствами и к программируемым для каждого устройства функциям добавится только конвертор запросов внешних систем в элементы очереди команда на устройство.
При работе с устройствами доступность каждого из них должна быть достоверно определена с минимально возможным лагом по времени. Для этого производитель обычно предусматривает возможность периодического запроса команды keepalive (или heartbeat) [6]. В случае если в протоколе устройства такая команда отсутствует, то её можно заменить на запрос статуса/установку состояния в случае, если это не приведет к существенным затратам на обмен данными и обработку самим устройством или артефактам установки состояния (мерцание экрана, износ реле при постоянном переключении и т.д.)
При этом необходимо продумать роль keepalive в системе, так как необходимость этой функции отпадает при частом обмене данными с устройством. В случае частой установки состояния и редкого запроса статуса keepalive целесообразно трактовать как промежуточный запрос статуса для подтверждения достоверности соответствия состояния устройства заданному состоянию. Можно выделить три варианта реализации keepalive и они должны быть переключаемые (настраиваемые) для каждого устройства.
- каждый раз при обмене информацией перезапускать таймер посылки команды keepalive.
- перезапускать таймер команды keepalive только при определенных запросах (запрос статуса) от внешних систем, в случае если keepalive представляет собой запрос статуса.
- независимо от частоты обмена данными с устройством посылать команду keepalive (точнее запрос статуса).
Основной проблемой сопряжения работы с устройствами внешних систем является организация последовательной посылки команд и приема ответов от устройства, в особенности если это устройство используется более чем одной внешней системой, и они не синхронизируют действия между собой. Тем самым, легко может возникнуть ситуация конфликта запросов на устройство, особенно если это касается установки состояния. Главная задача системы управления устройствами — менеджмент запросов от внешних систем, преобразование их в очередь конкретных команд для устройства, контроль ответа от устройства, контроль состояния устройства [5].
Центральной частью всей системы является объект очереди команд на устройство queue (Рис. 1). При приеме запроса от внешней системы этот запрос преобразуется в последовательность команд в функции constructNewQueueItem() и записывается в очередь. Элемент очереди должен содержать указатель на породивший его запрос requestID (если это не внутренний сервисный запрос типа keepalive или команды инициализации устройства) для отправки ответа, а также все необходимые данные для отправки запроса на устройство. Функция nextQueueRequest() представляет собой менеджер очереди, который отправляет ответ внешней системе на текущий (первый) запрос на устройство в очереди и уничтожает этот элемент (либо помечает как отработанный), беря в работу следующий элемент и запуская новый сеанс обмена данными с устройством.
Для дальнейшей детализации процесса обратимся к вариантам организации физических устройств (Рис. 2).
а. Ь.
Рисунок 2 - Способы распределения устройств по их контроллерам-хостам
В первом (а.) случае показана ситуация, когда каждое устройство имеет в своем составе один собственный контроллер и управляется независимо.
Во втором (b.) случае имеется один контроллер, который управляет сразу несколькими физическими устройствами. Таким образом, изолирование внешней системы от внутренней инфраструктуры устройств требует от функции constructNewQueueItem() распределения запросов адресованных на устройство по контроллерам-хостам этих устройств. А это означает необходимость добавления указателя на устройство deviceID в каждый элемент очереди контроллера Oontroller, по которому возможно будет идентифицировать изменение статуса целевого устройства при приеме пакета данных от контроллера.
Выделяют простые запросы, детерменированные одним сеансом обмена данными с устройством, и составные запросы — требующие для достижения конечного состояния или сбора всех интересующих данных нескольких команд. Обозначим запрос достижения определенного состояния устройства и в том и в другом случае действием — action, а элементарную команду, посылаемую устройству за один сеанс связи — command. Структурная схема элемента очереди в таком случае может быть организована следующим образом (Рис. 3):
queue
queuelteml request!D, deviceID. action
comma n d/da ta 1
comma nd/data2
command/da ta 3
queueltem2 requestlD deviceID. action
command/data"!
comma nd/data2
command/data3
Рисунок 3 - Представление элементов очереди с подэлементами команд
Для обеспечения универсальности очереди такая структура может быть использована и для простых запросов, в каждом элементе очереди будет присутствовать строго одна команда, однако такое усложнение позволяет даже в случае использования изначально простых запросов агрегировать команды под одним действием, включая и сервисные команды типа инициализации устройства, а также позволяет конструировать укрупненные действия, используемые внешними системами. Таким образом, функция nextQueueRequest() проходит по вложенным элементам очереди и один за одним обрабатывает их (помечает к обработке, либо удаляет из очереди). При этом по достижении выполнения последней команды посылается ответ на запрос requestID внешней системы.
Структура сброса соединения и последующей инициализации устройства выглядит следующим образом (Рис. 4):
Рисунок 4 - Структурная схема алгоритмов сброса и инициализации устройства
Как уже говорилось выше, процедура writeFrame() осуществляет не только запись в порт устройства, но и запускает таймаут ответа, по истечении которого либо команда посылается повторно, либо устройство считается недоступным. При этом необходимо реализовать процедуру сброса устройства reset(), включая закрытие порта устройства reset port, а также остановку процесса keepalive и пометку всех элементов очереди ошибкой устройства и последующий вызов менеджера очереди nextQueueRequest(), так как при наличии в работе внешнего запроса, а также следующих запросов в очереди требуется ответ на каждый из них с пометкой о недоступности устройства на каждый запрос в очереди. Через таймаут, также запущенный в reset(), устройство вновь инициализируется функцией init() с открытием порта open port и загрузкой в очередь команд устройства отдельно указанных команд инициализации init commands. Таким образом, система циклически пытается перезапустить связь с устройством и одновременно информирует системы о недоступности устройства. Устройство вновь станет доступным только после корректного приема ответа на команды инициализации (которыми могут быть и команды keepalive).
Заключение. В этой статье были озвучены основные принципы построения системы команд для
управления абсолютным большинством периферийных устройств, показаны общие моменты в реализации протокола обмена с этими устройствами и особенности распространенных вариаций протокола. Также показана полезность создания общей системы управления устройствами для разработчика с точки зрения получения четкой структуры кода, возможности переиспользования основных функциональных блоков в разных сценариях физической и логической организации устройств и необходимых действий, разработки общей концепции системы. На основании заключений статьи был спроектирован и представлен один из вариантов системы, отвечающей абсолютному большинству протоколов обмена с периферийными устройствами с одной стороны, а также универсализации обмена информацией (включая полную изоляцию от внутренней структуры) с внешними системами обмена с другой стороны.
Список использованной литературы:
1. Лошаков, С. Периферийные устройства вычислительной техники / С. Лошаков. 2-е изд. — Москва: Интуит, 2016. — 435 с.
2. Мараев, И.Е. Запросно-ответный протокол обмена данными для систем автоматизации / И.Е. Мараев // Вестник Науки. — 2023. — No 7 (64) Т. 4. — C. 244—249.
3. Сычев, А.Н. ЭВМ и периферийные устройства: учеб. пособие / А.Н. Сычев. — Томск: Издательство ТУСУРа, 2017. — 131 с.
4. Таныгин, М.О. Алгоритм определения источника фрагментированных сообщений / М.О. Таныгин // Известия высших учебных заведений. Приборостроение. — 2020. — No 8 Т. 63. — C. 702—710.
5. Черныш, Б.А. Разработка ядра интегрированной информационной системы / Б.А. Черныш, А.С. Картамышев // Программные продукты и системы. — 2021. — No 2 Т. 34. — C. 237—244.
6. Шаптала, В.С. О современных форматах обмена данными между компонентами распределительной вычислительной системы / В.С. Шаптала, Д.В. Солнцев // Техника средств связи. — 2019. — No 4 (148) — C. 51—58.
7. Ball, S. A Course in Algebraic Error-Correcting Codes / Ball S. — Birkhauser, 2020. — 177 p.
8. Choudhary, Prashant K. Software development & programming: Guide / Choudhary Prashant K. — Independently published, 2023. — 294 p.
9. Frenzel, Louis E. Handbook of Serial Communications Interfaces: A Comprehensive Compendium of Serial Digital Input/Output I/O Standards / Frenzel Louis E. Amsterdam: Newnes, 2015. — 340 p.
© Дубачев Д.В., 2023
УДК 621.311
Инсебаев Е.Н.
магистрант ОГУ, г. Оренбург, РФ
АВТОМАТИЗАЦИЯ РАСПРЕДЕЛИТЕЛЬНЫХ СЕТЕЙ ЭЛЕКТРОСНАБЖЕНИЯ
Аннотация
Наиболее актуальной тенденцией в современной электроэнергетике на сегодняшний день является полная автоматизация технологических процессов. Внедрение современных систем автоматизации крайне необходимо для повышения надежности работы единой национальной электрической сети (ЕНЭС).
