Синхронное АСУ ТП

Теоретические основы проектирования Синхронной АСУ ТП

Задачи:

•          Обеспечение максимально полной независимости от импортных решений, особенно в области теоретических основ (научной базы, стандартов и технологий) АСУ ТП.
•          Особенно важно: Результатом работы должно быть АСУ ТП следующего поколения, а не простое копирование зарубежных наработок.
•          Расширить применения АСУ ТП, до всех областей где нужно чем-то управлять или что-то мониторить (различная инфраструктура, приборостроение, станкостроение,
•          транспортное машиностроение, авиация, флот), в том числе и военного назначения.
•          Максимально упростить и унифицировать процесс создания различных систем управления и мониторинга, что критически важно для гарантированного создания и доработки                    больших проектов. Сложность проекта должна нарастать максимально линейно, от его размера.
•          Совместимость как оборудования, так и методов разработки ПО, для купирования жесткой привязки конечного заказчика к производителю оборудования и ПО.
•          Создание (внедрение) научной базы, инструментов создания, моделирования и анализа состояния систем АСУ ТП.
•          Внедрение методов ИИ. На начальных этапах для мониторинга состояния системы, прогнозирования ресурса и своевременного выявления отклонений от нормального                               состояния. В дальнейшем для непосредственного управления автоматическими системами (транспорт, производство и тд).

Теоретические основы:

•          Не являюсь практикующим специалистом в АСУ ТП и возможно «изобретаю велосипед».
•          Предлагаю договориться, что самое главное свойство (требование) для АСУ ТП это детерминированность, предсказуемость поведения во времени (гарантия времени                           реагирования) вне зависимости от состояния, в котором находится система. Корректность реагирования, это отдельная тема (считаем, что алгоритм работы правильный).
•          Кроме того считаем, что все проекты в АСУ ТП распределенные.
•          Современное АСУ ТП — это «детище» программистов и из дополнительных «теорий» (идей) там только циклическое исполнение (IEC 61131) и попытка решить проблему                           распределенной АСУ ТП используя модель «генерации событий» (IEC 61499).
•          К сожалению, все идеи обычного программирования, это последовательное исполнение, которое никак не «дружат» с контролем времени реакции, особенно для больших                         систем, где «балом правят» параллельность и реальное физическое время.
•         Предлагаю выбрать другую идеологическую основу для проектирования АСУ ТП. Изобретать что-то новое нет необходимости, наиболее близким к требуемому является                     идеология «Синхронной Цифровой схемотехники», здесь накоплено множество знаний, инструментов, имеется внушительный научный бэкграунд.
•          Для дальнейшего понимания желательно изучить инженерный курс «Цифровая схемотехника».
•          Если основываться на синхронной цифровой логике, то АСУ ТП в значимой степени превращается в цифровой автомат «Мура».
•          Выходные данные (управляющие воздействия и новое состояние обработчика) зависят только от входных данных (датчики и предыдущего состояния обработчика).
•         Вычисление нового состояния можно разбить на множество отдельных процессов, которые будут создаваться как различными исполнителями (программистами), так и с                             использованием различных технологий (микроконтроллер, FPGA, схемотехника), да и вычисления могут происходить в вычислителях, расположенных в разных частях                              управляемой установки. При этом все они будут гарантированно согласованны, потому что зависят только от данных текущего шага и никак не зависят от текущих вычислений                  друг друга.
•        Есть возможность на этапе проектирования ПО вычислить максимальное время реакции (самая длинная цепочка вычислений или команд), что позволит гарантировать обработку           данных в заранее заданное время для любого состояния системы.
•        Внимание: работать данный подход будет только при использовании детерминированной сети передачи данных (в данном случае сеть ССИ), для которой каждый виртуальный               канал по своим свойствам не сильно отличается от выделенного «физического проводника».
•        Если сейчас программист вынужден самостоятельно исполнять (контролировать) всю цепочку действий: запрашивать данные, следить за реальным временем, следить за                        корректностью работы алгоритма в текущем времени (что делать если то или иное воздействие или доставка данных произошло не в то время), согласовывать вычисления                      конкретного модуля (по используемым переменным) с другими модулями, держать в голове структуру системы с различными видами задержек, отправлять управляющие                          воздействия с контролем их доставки и все это с использованием сети связи (Ethernet), которая никак не гарантирует время доставки (да и вообще время доставки). Как пример:              что делать если вовремя не пришел пакет с «переменной» или «Event», подождать еще или данные потеряны безвозвратно. Что будет если это пакет пусть и с задержкой будет               доставлен, а вычисления ушли по другой ветке. Получаем очень быстро (и не контролируемо) растущую сложность проекта. Есть насущная необходимость разбивать проект на         отдельные, не требующие каждый момент сложного учета части, что позволит существенно упростить, уменьшить вероятность ошибок и детерминировать логику                 работы системы, в том числе и при коллективной работе многих программистов. Кроме того, такой подход позволяет с минимальными затратами выполнять                           локальные корректировки проекта, не опасаясь проблем с неучтенными зависимостями по другим модулям.

Реализация:

•          Телекоммуникационная основа АСУ ТП представляет собой сеть ССИ, реализующую множество виртуальных каналов. Каждый канал имеет один источник данных, но может иметь более одного приемника данных. Получается структура типа «дерево», принимает данные от единственного передатчика и транспортирует их во все точки, где данные используются в вычислениях (управлении). Достаточно точно свойства каналов можно представить моделью из множества последовательно соединенных между собой FIFO размером в три символа (минимальный квант информации – символ и он равен 36 бит). При разветвлении виртуального канала, происходит одновременная запись в несколько FIFO и далее передача идет по разным цепочкам.
•          Время передачи практически константа, отклонения от среднего +-2 периода передачи символов. Если данные не приходят в этот интервал времени, то их не будет никогда (например, обрыв кабеля связи) и нужно реализовать ветку реагирования парирующую данную проблему.
•          Виртуальные каналы могут, создаваться, удаляться в любой момент времени. Пока считаем, что в момент старта установки конфигурация каналов считана из ROM и неизменна все время работы системы. Получаем отдельную «работу», отдельного специалиста по проектированию топологии сети виртуальных каналов связи.
•          Если в обычном цифровом автомате «Мура» используются регистры, то в нашем случае это составное FIFO, ну или множество последовательных регистров. Относительно канонического автомата «Мура» необходимо ввести сущность «нет данных», поскольку доставка в реальности происходит не мгновенно и заменой фронта синхронизации служит именно нахождение требуемых данных на выходе FIFO, а не фронт тактовой синхронизации.
•          Старт команды обработки данных происходит через готовность всех требуемых исходных данных, а не последовательностью команд. Данное свойство позволяет программисту никак не заботиться о наличии данных. Потеря данных — это дополнительное состояние, которое нужно учитывать в алгоритме (видно при чтении из FIFO). Потеря данных выльется в небольшую дополнительную задержку, многократно меньшую чем период цикла.
•          На этапе программирования логики, программист имеет конечный набор данных достаточных для всех вариантов вычислений (запросить дополнительные данные невозможно – для этого нужно создавать новые виртуальные каналы). В том числе и данные предыдущих состояний (циклов), которые обработчик может сохранять в своей локальной памяти. Программист может свободно формировать выходные данные только исходя из логики работы АСУ ТП, не требуется конкретики о работе другого программиста. Поскольку список каналов, соответственно список имеющихся исходных данных сформирован на предыдущем этапе разработки, то он одинаков для всех. Каждый обработчик использует подмножество из общего списка, что сильно сокращает вероятность ошибок при коллективной работе.
•          Для микроконтроллера вычислительный процесс выглядит как зацикленная программа, выбирающая и обрабатывающая данные из одного или нескольких FIFO (готовность данных можно реализовать через аппаратный контроль наличия данных) и записывающая результаты исполнения в другие FIFO. Данные из FIFO будут автоматически доставлены в конце цикла исполнительным устройствам, что позволяет программисту не заботиться о доставке. В следующем цикле программист может получить «квитанцию» о доставке данных от приемника и использовать ее в работе алгоритма.

Совместимость (универсальность):

•         Решение проблемы совместимости возможно только через отсутствие каких-либо упоминаний о реальной аппаратуре в программном коде.
•         Предлагаю на начальном этапе ввести наименование виртуального канала, которое будет задаваться в момент проектирования топологии сети виртуальных каналов.
•         Данный подход хоть и не гарантирует автоматического встраивания нового типа аппаратуры взамен старой, но позволяет отконфигурировать новый прибор до состояния не отличимого от старого.
•         На начальном этапе, конфигурирование прибора производить, через написание обработчика аналогичного тем, что реализуют логику основного проекта АСУ. Исполняться он должен или непосредственно в новом приборе или в проектируемом модуле ASU_TP_SOM (модуль интерфейса сети ССИ).
•         Такой подход позволит обеспечить совместимость со всем существующим в данный момент оборудованием и одновременно отделить логику работы установки, от внутренней логики периферийного оборудования.
•         По мере «взросления» технологии «Синхронного АСУ ТП», можно будет сформулировать принципы универсального интерфейса (своеобразное P&P) и для большинства случаев задача подключения нового оборудования станет полностью автоматической задачей.

Иерархия:

•          Любой объект должен иметь некоторую иерархическую внутреннюю структуру.
•          Наиболее оптимальны будет разделение на зоны, в которых используется один и тот же сигнал цикловой синхронизации. В цифровой схемотехнике есть аналогичное понятие «Clock domen».
•          В пределах одного домена опрос датчиков, вычисление управляющих воздействий и запись управляющих воздействий гарантированно происходят за время одного цикла синхронизации. Такое деление более оправдано, чем разделение по функционалу.
•          Период цикловой синхронизации может быть самым разным. Например, есть программа управления двигателем со своими механизмами управления силовыми ключами, контролем токов и напряжений, опросом энкодера, контролем температуры, механических вибраций и прочего. Есть внешняя программа, выдающая задания с параметрами направления, скорости вращения и тд. Понятно, что для контроллера управления двигателем необходимо время реакции лучше 100 мкс, а для внешнего управления и 1 мс может быть излишним.
•          Зоны с различными цикловыми синхросигналами физически могут находиться в одной (единой) сети ССИ (сеть ССИ может создавать виртуальные каналы с произвольной скоростью потока символов) и не влияющие на производительность других каналов.
•          Формально разницы между виртуальными каналами нет и все они могут быть разделены на два типа (опрос датчиков и команды для исполнительных устройств), но предлагаю выделить для интерфейса к вышележащим системам управления (только для указания функции в топологии сети) еще два типа канала (постановка задачи и текущее состояние). Для управляющего интерфейса эти каналы будут идентифицироваться как опрос датчиков и команды для исполнительных устройств, что позволит сформировать иерархическую структуру ПО управления.
•          Из-за разницы сигналов цикловой синхронизации, на границе доменов, нарушится принцип получения ответа в том же цикле, когда и был отправлен запрос. Для предотвращения коллизий и неоднозначности (ответ или запрос потерян или нет) необходимо постоянно транслировать в обе стороны некие символы заполнения (нет запроса-нет ответа, ну или все хорошо или ошибка и дв) и в нужный момент производить их замену на рабочую информацию. Данный механизм, кроме разрешения неоднозначности, будет сигналом готовности управляемого устройства без необходимости отправки специального запроса на готовность. Данный сервис может постоянно мониторить состояния управляемого объекта без выделения для этого специальной полосы пропускания.

Взаимодействие с асинхронными структурами (находятся за пределами сети ССИ)

•          Асинхронным взаимодействиями считаем все взаимодействия, не использующие сеть ССИ
•          В большинстве случаев, асинхронное взаимодействие, это взаимодействие с вычислительной машиной. В большинстве операционных систем обработка сетевого трафика имеет практически максимальный приоритет. Сетевой интерфейс максимально стандартизирован, имеет достаточно широкий вариант скоростей передачи и достаточно просто реализуем, то наиболее эффективно выбрать именно его для взаимодействия с сетью ССИ.
•          Для минимизации влияния присущей таким сетям асинхронности, предлагаю всегда взаимодействовать напрямую с вычислительной системой (сетевой картой).
•          Взаимодействие строить через прием передачу пакетов с заранее согласованной структурой. Сеть ССИ в начале цикла передает шлюзу необходимые данные, ПО шлюза их упаковывает в пакет и отправляет в сторону компьютера.
•          Размер данных, период цикла заранее рассчитаны так что бы не перегрузить внешний сетевой интерфейс.
•          Скорость отправка данных (управляющей информации) в сторону сети ССИ регулируется через объем входящего буфера. Например, есть договоренность, что размер входящего буфера равен N байт. Отправляя, в сторону сети ССИ пакет, сразу вычитаем из текущего объема буфера размер пакета. Отправляем пакеты до момента пока буфер не будет заполнен. При получении ответа считаем, что пакет обработан и прибавляем к объему буфера размеры обработанных пакетов.
•          Подучив данные пакета, шлюз дожидается начала нового цикла, «разбирает» содержимое пакета и используя сеть ССИ отправляет данные адресатам, которые их обработают и сформируют ответные данные или управляющие данные и в конце цикла отправят их дальше (исполнительным устройствам или назад шлюзу).
•          Такой подход позволяет не нарушать предсказуемость работы системы из-за непредсказуемости времени взаимодействия с внешней вычислительной системой.
•          Один пакет (имеющий один адрес) обрабатывается в течении одного цикла. Если необходимо обрабатывать два и более пакета за цикл, то требуется назначить пакету другой адрес и создать дополнительный канал в маршрутизаторе.
•          Число таких шлюзов в сети ССИ никак не ограничены.
•          Если есть необходимость, то межкомпьютерное взаимодействие также может реализовываться через сеть ССИ. Можно создать многопроцессорную вычислительную систему, для которой сеть ССИ будет играть роль ядра, синхронизирующего его работу. 

Применение технологий ИИ в АСУ ТП

•          Управляющее ПО для АСУ ТП в данном случае стало очень похоже на «нейронную сеть», преобразует входные данные в выходные. Работа в целом ациклична (кроме основного цикла) и представляет собой ацикличный направленный граф. Осталось сменить базис с дискретной математики на умножение + сложение и будет обычная нейронная сеть.
•          Данное направление работ очень перспективно и в пределе развития приведет к полностью автоматическим самообучающимся системам управления (в фантастике их называют «Искинами»), но пока нет профильных ученых придется ограничиться малым.
•          На основе теории нейронных сетей построим систему сигнализации о возникновении нештатных ситуаций в самом общем случае.
•          В процессе работы конкретной реализации АСУ ТП собираем всю последовательность считываемых и записываемых данных, которую используем для обучения нейронной сети.
•          После обучения, сеть будет пытаться предсказывать состояние установки на несколько циклов синхронизации вперед. Если происходят значительные отклонения от предсказанного, то указывать оператору на возможную проблему и место ее возникновения.

Сервис оценки оставшегося времени до отказа конкретных узлов

•          Чинить оборудование уже после отказа не самое умное дело, необходимы предупредительные ремонты. Вот только нужно понять, какие элементы оборудования требуют плановой замены.
•          Можно делать многократно резервированные системы, при отказе блока его функцию возьмет на себя дублирующий и делать это желательно без обязательной остановки системы.
•          Можно постоянно измерять косвенные параметры составных частей. Как пример, концевой выключатель может выходить из строя не сразу, на начальном этапе начинается нетипичный «дребезг» контактов, изменение сопротивления в открытом закрытом состоянии. Примерно тоже самое можно сказать и про линии связи, винт в клеммнике постепенно раскручивается и начинаются изменения. Привод начинает излишне греться, потреблять больше энергии, вибрировать. Да и вообще изменяется рисунок вибрационной картины в несущих конструкциях.
•          Кроме того, при проектировании исключать необходимость считывания постоянных значений сигналов (может провод оборвался и мы смотрим просто не подключенный вход). Для опроса концевого выключателя это выльется в подачу сигналов различной полярности и тд.
•          Сейчас данные параметры в большинстве случаев никак не отслеживаются и не интерпретируются. Если сделать такую систему достаточно компактной, то как минимум в самолетостроении это станет базовым стандартом.