Настоящая статья является предваряющей анонсированной статьи по устройству приёмника умного звуковых датчиков по технологии обработки данных в потоке.
Мне представляется, что каждый специалист по АСУ самостоятельно изобретает общее видение задачи, чтобы потом перейти к практической работе по реализации или эксплуатации АСУ. Будучи разработчиком программ станков ЧПУ и систем управления технологическими установками, я тоже на практике выработал общие схемы, которые использовал для разработки архитектуры приёмника данных умных звуковых датчиков. Классификация приёма/передачи и обработки данных даётся в виде 3–ёх базовых схем.
Поясню, какой смысл я вкладываю в термин умный датчик. Датчик находится в сети обработки данных в потоке, и он знает, кому и в каком формате эти данные направить!
Добавлю, что неумный датчик выкладывает свои данные в обусловленное место, как правило в регистр, откуда они забираются потребителем или "посредником", который кладет их в уже другое место, например, в БД.
1 Предыстория вопроса
Разработке схем, которые я покажу ниже, предшествовала курьезная история.
Я дружу с профессором авиационного университета. Да, я знаю, что университета уже нет, что он административной волею растворился как чеширский кот, но люди и субстракт их дел ещё сохранился.
Мы с ним познакомились и подружились на платформе нашего совместного интереса к новым идеям в области автоматизированных систем управления (АСУ). Этой дружбой я очень дорожу, т.к. профессор для меня единственный человек, с которым я могу обсуждать разные абстрактные теории. Именно он сподвигнул меня перейти с C++ на использование функциональных языков при разработке АСУ технологической установкой. Он рецензировал мою статью «Концепция альтернативного программирования распределенного объектного кода на основе потоков данных между узлами коллектива вычислителей. Инженерный подход», которая на Хабре прошла под названием «Анти-Тьюринг».
Так вот, однажды встречаемся мы с ним для обсуждения рукописи моей очередной статьи по коммуникационному контроллеру на базе технологии обработки данных в потоке, и я неосторожно бросаю фразу:
– Датчики пассивны.
Более корректно фраза звучала бы так: "Данные с датчиков в программных системах АСУ пассивны." Но это произносить долго и сложно.
В ответ слышу:
– Что вы сказали?! Повторите.
Я повторяю, не ожидая последующей бурной реакции профессора. Образно, то, что произошло далее, можно, обрисовать так: мы сидели, спокойно играли в шахматы, и вдруг профессор достаёт клюшку и переводит игру в эмоциональный хоккей.
Он стал энергично чиркать рукопись, в сердцах произнося заклинания:
– После этой фразы вы мне не коллега... Это элементарная неграмотность... Больше ко мне не ходите...
Я сохранил спокойствие, т.к. был уверен в правоте своих мыслях, оставался за "шахматной доской" и просто удивленно смотрел на "хоккейном поле", где профессор в несвойственной ему манере «колотил клюшкой по льду».
Через минуту профессор остыл также неожиданно, как и вспылил. Тут до меня дошло, что у нас просто разные ракурсы рассмотрения проблемы: у профессора классическая аналоговая схема управления в, а у меня — опосредованная через ПО.
Тем не менее беседа была скомкана. Я собрался и ушел. По дороге домой у меня окончательно сложились варианты схемы АСУ. Я рассмеялся и тут же прямо с улицы позвонил по сотовому профессору. Продолжая смеяться, я попытался на пальцах объяснить причину аберрации нашего воззрения на датчики. Похоже, что до него тоже стало доходить разность наших подходов: у него аналоговая схема с проводами, а у меня программная среда с регистрами.
В результате у меня получилась классификация АСУ, состоящая из 3–х базовых схем, о которых я осмелюсь здесь рассказать, прежде чем перейти к описанию устройства приёмника звуковых данных в следующей статье.
2 Базовые схемы получения и обработки данных с датчиков АСУ.
2.1 Аналоговая схема передачи и обработки данных
Анализ схем АСУ будем проводить на примере реализации регулятора управления, отталкиваясь от классической схемы цикла регулирования, изображенного на Рис. 1.
Традиционно схема регулирования базируется на схеме аналогового регулирования. Задание совмещен с блоком регулятора, т.к. задатчики фактически входят в состав аппаратуры. Стрелка связи от датчика на регулятор показывает, что датчик по отношению к регулятору является активным элементом, а регулятор выступает в качестве пассивного элемента.
Элементы привода и управляемый объект здесь играют традиционные роли и в комментировании не нуждаются.
2.2 Схема получения и обработки данных в традиционной технологии АСУ
Схема получения и обработки данных в традиционной технологии программирования АСУ показана на Рис. 2
Схема АСУ претерпела существенные трансформации. Между процессом регулятора и Объектом располагается оболочка доступа пространству памяти. Архитектура пространства памяти может быть различной: от распределенной по локальным контроллерам куста до консолидированной на сервере OPC. Это не принципиально. Важно, что данные после генерации прямо попадают в ОЗУ или БД, где ожидают своей очереди обработки. Для однообразия и удобства Задание на схеме я тоже разместил в общем пространстве памяти.
На схеме не детализируются механизмы получения пространством памяти данных от Датчиков и передачи параметров Приводов – за этим теперь стоит целая индустрия интерфейсов и уровней АСУ ТП. Главное, что взаимодействие Объекта и Регулятора теперь производится опосредовано через элементы пассивной памяти.
Регулятор взаимодействует не напрямую с датчиками и приводами. Для получения данных датчиков регулятор обращается к регистрам пространства памяти через вызов оболочки, а оболочка уже возвращает результат. Аналогично, для воздействия на привод, регулятор так же вызывает функцию оболочки. Эта функция может возвращать пустой результат (void), что показано пунктирной стрелкой (Рис. 2).
Реализовать описанный регулятор можно на любом современном универсальном языке: C++, Python, Java или на специализированном DSL, а доступ к данным датчиков осуществлять при помощи соответствующей библиотеки API, например, Modbus.
Для нашей классификации важно отметить, что на схеме автоматического регулирования на базе традиционного процедурного программирования характер взаимодействия регулятора и датчика меняются: регулятор по отношению к данным датчиков становится активным, а сами датчики прикрыты пассивным прокси оперативной памяти или базы данных.
2.3 Схема передачи и обработки данных при реализации событийно–ориентированного подхода
Возникает правомерный вопрос: «Можно ли реализовать программный регулятор управления по аналоговой схеме, в которой датчикам возвращена активность?» Оказывается – да. Последние лет 20 на Западе успешно развивается технология обработки данных в потоке, которая по–другому называется событийно-ориентированным подходом, короче обозначаемого аббревиатурой EDA (Event Driven Architecture).
Для программирования в подходе EDA существует много соответствующих средств программирования [1,2,3]. Для Python существует множество популярных библиотек для реализации EDA [4]. Лично я предпочитаю реализацию обработки данных в потоке на базе функционального языка программировании, например, Elixir [5], который наследует из Erlang встроенный механизм посылки сообщения.
Рассмотрим альтернативную схему программной реализации регулятора управления с событийно–ориентированном подходом передачи и обработки данных.
Альтернативная схема регулятора становится однородной по составу элементов: все представлено процессами. Процессы являются параллельными. Данные датчиков, параметры приводов и задание регулятора являются состояниями процессов. Процессы взаимодействуют через посылки сообщений. Процесс таймера задаёт тактовую частоту передачи данных с датчика и начала нового цикла регулирования.
Промежуточные выводы
Архитектурное решение EDA возвращает датчику статус активного устройства. Таким образом, при программировании обработки данных в потоке схема регулирования становится подобной по понятиям начальному классическому виду аналоговой схемы, что может вызвать одобрение со стороны специалистов АСУ.
В парадигме обработки данных в потоке датчики работают напрямую без посредников. Это убыстряет скорость обработки сигналов.
Может возникнуть вопрос, как и в каком качестве существует совокупность данных. Как говорится в источнике [1], «В потоковой модели нет общей базы данных. Поток событий это и есть база данных». Я обычно образно сравниваю поток событий с виртуальными проводами в физической аппаратуре: здесь тоже наблюдается гонка параметров и требуются механизмы синхронизации сигналов/событий.
При программировании АСУ в технологии обработки данных в потоке необходимо учитывать два фактора:
1) у механизма посылки сообщения время обработки очереди событий не предсказуемо, но, тем не менее, его достаточно для обработки «ленивых» технологических процессов с мягкой реакцией в диапазоне мс–сек [3].
2) в коммуникациях при передаче данных с конкуренций за шину возможны непредумышленные потери.
В противоположность этому, у реализации схемы регулирования в традиционном стиле есть существенное достоинство, а именно предсказуемое время реакции на событие. Обработку события можно реализовать через прерывание, тогда время обработки становится детерминированным, что очень важно для обработки событий жесткого реального времени.
3 Шина CAN
Думаю, что многие, особенно автомобилисты, о стандарте CAN слышали. Стандарт CAN (Controller Area Network) создан компанией Robert Bosch GmbH в середине 1980-х годов. Он очень подходит к обработке данных в потоке. Да–да, в 80–х годах концепции EDA ещё не было, а стандарт CAN был!
Этот протокол на основе сообщений первоначально был разработан для мультиплексирования электропроводки в автомобилях с целью экономии меди, но он также может использоваться во многих других контекстах. Сейчас стандарт CAN стали применять задачах автоматизации промышленности.
Согласно Википедии, CAN — стандарт промышленной сети, ориентированный, прежде всего, на объединение в единую сеть различных исполнительных устройств и датчиков. Режим передачи — последовательный, широковещательный, пакетный.
Непосредственно стандарт CAN компании Bosch не привязан к физическому уровню – он может быть каким угодно, например, радиоканалом или оптоволокном. Но на практике под CAN-сетью обычно подразумевается сеть топологии «шина» с физическим уровнем в виде дифференциальной пары проводов. Поэтому обычно говорят о стандарте CAN–шины.
Преимуществами стандарта CAN–шины являются:
· Возможность работы в режиме жёсткого реального времени.
· Простота реализации и минимальные затраты на использование.
· Высокая устойчивость к помехам.
· Арбитраж доступа к сети без потерь пропускной способности.
· Надёжный контроль ошибок передачи и приёма; вероятность невыявления ошибки передачи оценивают как 4,7×10−11.
· Широкий диапазон скоростей работы.
· Наличие широкого ассортимента продуктов от различных поставщиков.
Что важно, так это высокая скорость CAN–шины до 1Mb/c (на расстоянии 40 м). Для примера, в промышленном стандарте Modbus RTU поддерживаемая скорость не превышает 115 Kb/c.
3.1 Почему Шина CAN прямо принадлежит области обработке данных в потоке
Я нигде не встречал оценок, что шина CAN прямо принадлежит технологии EDA. Попробую это показать.
Особенностью стандарта CAN, на которую в первую очередь обращаешь при ознакомлении с ней внимание, является отсутствие адресного пространства как такового. По сравнении с распространённой в промышленности стандарта Modbus у CAN нет ни слейвов (подчиненных устройств), ни мастера (ведущего устройства), есть только принимающие и передающие узлы (устройства) с разными приоритетами передачи данных.
Шина CAN является синхронной шиной с типом доступа Collision Resolving (разрешение коллизии), который обеспечивает детерминированно доступ на передачу сообщения, в отличие от Collision Detect (обнаружение коллизии) в сетей Ethernet. Передача ведётся кадрами, или пакетами, причем, кадры принимаются всеми устройствами, включая передающие устройства.
Узлы начинают передавать пакеты с данными по шине в одно и то же время. Передающий узел одновременно проверяет состояние шины и продолжает передачу до момента получения доминантного бита в идентификаторе пакета при посылке собственного рецессивного бита. Так решается вопрос разрешения коллизий.
В пакетах присутствует идентификатор. Пакеты забираются из шины в узлы управления согласно уникальному идентификатору. Узлы управления анализируют и используют данные в пакете по назначению и могут породить передачу следующего пакета, т.е. сообщения и т.д.
Из приведенного описания можно сделать однозначное заключение, что шина CAN полностью соответствует технологии обработки данных в потоке.
3.2 Схема реализации систем на базе CAN-шины
Работа с CAN–шиной организована следующим образом. В пакетах CAN–шины присутствуют уникальные идентификаторы, связанных с назначением. Поэтому для программной работы в системе CAN–шины надо знать фиксированные 11-разрядные номера идентификаторов. Для распознания идентификаторов есть сканеры CAN–шины.
Для примера рассмотрим гипотетическую схему, представленную на рис. 4, состоящую из микропроцессоров типа STM–32, взаимодействующих по CAN–шине.
Два микропроцессора (ПЛК1 и ПЛК2), снабженные датчиками, получают информацию и передают по CAN–шине данные на правый микропроцессор (ПЛК3), который снабжен исполнительными элементами или в данном случае выполняет роль коммуникационного устройства и передает данные далее в аналитический центр принятия решения. Устройства присоединены через CAN–трансиверы на общих условиях и на них запущены процессы, которые «слушают» все пакеты на шине. Библиотеку драйвера для подключения к CAN–шине можно найти на сайте GitHub.
Схема, изображенная на рис. 4, является часто применяемой в дистанционном контроле транспортного средства, но она достаточно универсальна, чтобы применять её в других областях. Главное, что следует отметить, глядя на схему, это:
· параллельность/распределённость работы вычислительных узлов схемы,
· независимость программных обеспечений (ПО) на узлах друг от друга, что положительно может сказаться на интегрировании ПО разных разработчиков в единую систему,
· хотя это неявно, но применение проверенной и надежной CAN–шины ведет к повышению быстродействия и безотказности работы системы.
Результат
В следующей статье будет описано устройство приёмника звуковых данных с рассмотренной CAN–шиной на базе технологии обработки данных в потоке.
Литература
1. Бен Стопфорд, Проектирование событийно-ориентированных систем. Концепция и шаблоны проектирования сервисов потоковой обработки данных с использованием Apache Kafka, Иркутск: ITSumma Press, 2019
2. Э.Дж. Пселтис, Потоковая обработка данных. Конвейер реального времени.— М.: ДМК Пресс, 2018.
3. Ф. Уэски, В. Калаври, Потоковая обработка данных. — М.: ДМК Пресс, 2021.
4. https://habr.com/ru/companies/otus/articles/740578/
5. Юрич С, Elixir в действии. — М.: ДМК Пресс, 2020.
6. Ф. Чезарини, С. Томпсон, Программирование в Erlang.– М.: ДМК Пресс, 2012.
