Отладка систем управления вместе с моделью объекта. 

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

Все события выдуманы, все совпадения случайны.

Определение:

Технологи - специалисты в конкретной предметной области: физики, электрики, конструктора и проектанты разных сложных объектов. Технолог знает, как работает его сложный технический объект, что и когда включать или что и когда выключать, чтобы не было потом мучительно больно.

Программисты - специалисты в написании программ, умеют закодировать любой бред, который напишут в техническом задании, а также знают, как работает аппаратура управления, и что нужно написать в коде, чтобы получить данные с АЦП в программу, и наоборот отправить из программы в ЦАП.

Каждый из них занимается свои делом по жизни, но, когда нужно создать сложный технический объект, они встречаются как лед и пламень, или лебедь, рак и щука, или мартышка и очки. А все потому, что любой современный технический объект содержит в себе систему управления, которая сейчас почти всегда выполнена в виде программного обеспечения на контроллере, а значит, нам нужен программист, и он должен понимать (хотя бы примерно), что от него хочет технолог.

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

Лирическое отступление

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

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

На самом деле демонстрируемая в видео модель содержит и алгоритмы управления, и элементы объекта, реализованные с помощью одного и того же языка программирования на базе функционально блочных диаграмм FBD.  Например, на следующем рисунке приведены диаграммы, одна из которых – часть алгоритма управления, который прямо сейчас реально управляет одной из АЭС России, а другая является частью математической модели электропривода задвижки.

Можете сказать какая диаграмма - модель, а какая - программа управления? Вот и я не могу, поскольку они одинаковые, хотя и разные.

Модель технического объекта как программа. Технолог как программист

Используя FBD диаграммы, мы можем создать как модель объекта, так и программу управления. При этом, сама модель, судя по рисункам 2 и 3, также является ничем иным как программой. На самом деле пока модель объекта работает на компьютере она (модель) – на самом деле программа. 

А если модель — это программа, то мы можем применить к ней все практики, методы и рабочие инструменты, связанные с разработкой программного обеспечения. Например, мы можем использовать методы оптимизации, применяемые для настройки систем управления, но к конструкции. В этой статье приведен пример, когда мы подбираем не коэффициенты регулятора, а диаметр трубопроводов. 

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

А если у нас есть автоматическая генерация кода из 1D прямо в контроллер, то может быть и скрипач не нужен? Зачем нам программист, если технолог сам себе программист, может менять алгоритмы и заливать их в контроллер, используя графические языки программирования.

Скрипач не нужен?

Графические языки программирования создавались для упрощения понимания программы со стороны технолога, и должны помогать людям без знания текстовых языков программирования создавать программы для управления. А раз они создают программы, то пусть и создают их вплоть до реализации в контроллерах. Это выглядит логично, поскольку для технических объектов конструктор и технолог – главные в процессе создания. В отличие от программ для офисного планктона, ERP банковских приложений или всяких там игрушек с социальными сетями, программы управления объектом без самого объекта, которым программы управляют программы, на фиг никому не нужны. 

В реальности любой конструктор или технолог, как только начинает создавать 1D модель, он по определению начинает создание алгоритмов управления (управляющее ПО) в виде FBD диаграммы, и тут же осуществляет их тестирование вместе с моделью объекта. В этом и есть смысл «модельно-ориентированного проектирования». Получается, что конструктор или проектант, создавая алгоритм управления, одновременно работает программистом, используя проблемно-ориентированный язык программирования. Так, может, пусть он и дальше программирует, не будучи программистом? Тем более, если у нас есть автоматическая генерация кода в контроллер.

Что дороже – программы или железо?

Если вы внимательно посмотрите на картинку 1, вам может показаться, что левая часть системы, там где создается программное обеспечение, выглядит значительно более дешевой, чем правая. Какие-то два шкафа автоматики, а с другой стороны, на картинке – АЭС стоимостью 8 ярдов зелени.  (Конечно, два шкафа – это только на реакторное отделение, но это все равно, как говорят в Одессе это две большие разницф очевидна).  На самом деле это вам не кажется, так оно и есть. Производители современных технических систем сообщают о росте количества строк кода управляющего ПО. Даже в современном автомобиле содержится уже более 5 млн строк кода. Но этот код ничего не стоит по сравнению с железом автомобиля, хотя бы потому что код можно размножать бесплатно копированием, а вот размножать бесплатно кузова и двигатели человечество не научилось.  Не говоря уже о промышленных объектах, таких как АЭС. 

Поэтому если вы обнаружили ошибку в управляющем ПО на стадии отладки, вы ее можете легко поправить. А если эта ошибка проявилась в реальном объекте, то поправить может быть ее уже не так легко, а иногда даже совсем поздно. (Привет, Чернобыль!) Такие ошибки могут делать очень и очень больно, и стоить очень и очень дорого.  

Возникает вопрос: можно ли прежде, чем подключать дешёвый код для управления дорогим техническим объектом, проверить его на математической модели.

И ответ давно найден. Конечно, можно! Вот, например, картинка 2004 года, когда алгоритмы, созданные с использование функционально-блочных диаграмм для реактора чернобыльского типа РБМК, были проверены на модели, а потом результаты работы этих алгоритмов сравнивали с результатами работ реальной станции. Цифровой двойник как он есть, до того, как это стало модно.

Модель как жизнь, жизнь как модель

Глядя на рисунок, можно возразить, что тут же совершенно разные графики: розовая линия (расчетные значения в модели) гладкие, а реальные показания бьются в истерике вокруг рассчитанного значения. Как это учитывается в модели? В модели все просто: рассчитала модель давление, отдали его в алгоритм и все пучком. А вы уверены, что алгоритмы сработают, когда реальный сигнал придет искаженным, с шумами и задержками? Поскольку у нас модель, то мы легко можем добавить в алгоритм и задержек и шумов, чтобы он был такой же, как в реальной жизни. Если нам нужно добавить шумов и задержек в сигнал, чтобы он был как в реальной жизни, это делается достаточно просто. На следующей схеме типовой алгоритм обработки сигнала с датчика, где мы добавляем смещение и пульсации, и если в математической модели давление ведет себя ровно и стабильно, то в алгоритмах мы получим такие пульсации и смещения, которые пожелаем. 

Ну, а сам размер и частота пульсаций задается технологом с помощью следующей схемы:

Таким образом, в алгоритм для обработки предается не рассчитанное моделью значение, а искаженное, и приближенное к реальным измерениям на объекте. Если наши алгоритмы с ними хорошо работают, значит есть хороший шанс, что на объекте все будет также. 

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

Получается, что для разработки алгоритмов управления сложными системами с использованием модельно-ориентированного подхода и графических языков программирования программист не нужен? Не все так однозначно.

Из мягкой (soft) виртуальности в суровую (hard) реальность

Конечно, в виртуальном мире математического моделирования все можно проверить и отладить на модели с минимальными затратами времени и денег. Но система управления из виртуального мира среды проектирования должна перейти в контроллер, где и будет управлять нашим объектом.

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

Одним из способов ответа на этот животрепещущий вопрос является отладка алгоритмов управления, уже реализованных на аппаратуре управления. У наших зарубежных друзей это называется Hardware-in-the-loop. 

Вот как от этом пишет буржуйская Wikipedia

Hardware-in-the-loop (HIL) simulation, or  HWIL, is a technique that is used in the development and testing of complex real-time embedded systems. HIL simulation provides an effective testing platform by adding the complexity of the process-actuator system, known as a plant, to the test platform. The complexity of the plant under control is included in testing and development by adding a mathematical representation of all related dynamic systems. These mathematical representations are referred to as the "plant simulation". The embedded system to be tested interacts with this plant simulation.

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

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

Получается, что графические языки, как водка и Nokia, connecting people. 

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

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

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

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

Одно дело, когда вы пишете алгоритмы по требованиям от технолога, и совсем другое, когда требования от технологов вы можете посмотреть непосредственно на модели объекта и проверить, как ваша программа управления с ними справляется. И тогда в рамках тестирования управляющего ПО, можно проверять не вход-выход алгоритма, а параметры технического объекта в процессе моделирования. 

Может технолог и конструктор не нужны, и все сделает программист, если ему дать хорошую 1Dмодель, созданную на хорошем графическом модельно-ориентированном языке программирования?   И тогда главным становится программист, вооруженный хорошей и понятной моделью.

Чтобы понять кто в итоге главный в качестве примера рассмотрим реальную систему управления реакторным отделением АЭС, которая создается на графическом языке программирования и заливается в контроллер с помощью автоматической генерации кода.

А как оно бывает в реальности?

Рассмотрим реальный проект управления реакторного отделения АЭС, как раз случайно оказался под рукой. На рисунке 9 представлен верхний уровень проекта системы управления реакторным отделением одной из российских АЭС, выполненный в виде альбома функционально-блочных диаграмм. Данный проект полностью готов к генерации исходного кода и заливки в стойки управления.

 Общее количество листов алгоритмов 82 стр. Из них 39 листов – технологических алгоритмов. Это те алгоритмы, которые создавал технолог, они описывают непосредственную реакцию системы управления на изменения параметров объекта. Остальные 41 лист алгоритмов — это алгоритмы, связанные с получением сигналов с датчиков и преобразованием их в переменные проекта, готовые для использования в алгоритмах технолога. 

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

Пройдем по цепочке преобразования данных от измерения температуры термопарой до команды регулятору на открытие или закрытие клапана. 

Ввод данных в систему управления

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

Данная диаграмма описывает связь проводов с переменными в контроллере. Слева – список контактов плат, справа – имена переменных, доступных для обработки алгоритмов.

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

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

Этот код должен создавать программист-разработчик непосредственно данной платы, и задача автоматического кодогенератора – поместить данный код в нужное место общих исходных кодов программы.

Подготовка данных

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

Если мы потеряли связь (обрыв линии) с одним из контактов платы, плата ввода выдаст недостоверность данного сигнала. Но, если термопара потеряла контакт поверхностью, но продолжает работать, и температура в систему попадает, плата не видит отказа и считает сигнал достоверным. Но эта температура совсем не та, которую нужно использовать в алгоритмах управления. И совсем не та, на которую рассчитывает технолог.

Поэтому следующий этап — еще одна проверка достоверности полученных данных, в которой уже анализируются полученные данные на предмет достоверности самого значения.

Для оценки полученных данных используется набор параметров, приведенных на рисунке 12.

Например, мы можем оценить достоверность по величине показаний, по скорости изменения или по времени, когда параметр не изменяется. 

Таким образом, достоверный для платы сигнал, в случае, когда термопара потеряла контакт с контролируемой поверхностью, будет определен как недостоверный после анализа показаний. Пример обработки показаний датчика приведен на рисунке 13.

С помощью данного расчетного кода происходит пересчёт полученного значения в миллиамперах в единицы измерения температуры, расчет величины показания в процентах от диапазона (верхняя часть алгоритма), а также анализ полученных данных на достоверность.

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

Сложные параметры

Простого определения достоверности сигнала зачастую нам недостаточно, поскольку в алгоритмах технолог может использовать, не просто температуру с датчика, а более сложный производный параметр, например, среднюю температуру или максимальную температуру в объекте, а такие значения получаются не с одной термопары, а с нескольких, которые также уже проверены на достоверность. 

И теперь при расчете средней температуры мы можем отбросить те показания, которые не достоверны. А учитывать только показания достоверных датчиков.

Пример реализации вычисления сложных сигналов приведен на рисунке 15.

Функциональное ПО

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

Именно эта часть непосредственно и обеспечивает управление технологическим процессом и регулирования параметров объекта.

Обратите внимание на нижнюю часть алгоритма рисунка 15: в качестве входных сигналов в алгоритм используются признаки отказов, которые используются для принятия решения и оказывают влияние на результат.

Например, наш датчик отлично работает и ПИД регулятор рассчитывает команды на клапан, наличие сигнала «авария» или отказов приводят регулятор в состояние «отключен». Таким образом в алгоритмах напрямую используются сигналы от отказов оборудования. И что делать в случае отказа, решает как раз специалист по технологии процесса.

Вывод данных

После того, как ПИД регулятор сформировал команду на открытие или закрытие клапана, нам нужно передать сигнал на плату вывода. Диаграмма выглядит как на рисунке 17. В принципе, все то же самое, что и для ввода, только наоборот. 

Слева – переменные, рассчитанные в алгоритмах управления, справа – контакты платы. И пользователь просто сообщает системе, что и куда послать. 

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

В правой нижней части алгоритма часть команд отправляется на видеокадры, а также формируется логика выбора контроллера для управления в случае дублированного контроллера. 

Вкратце на этом все: получили данные, выработали команды и повторяем все на каждом такте работы контроллера.

С точки зрения зоны ответственности, можно в общем проекте системы управления выделить две части: 

1)        технологическую, которая полностью определяется технологом или конструктором объекта, и которая обеспечивает заданные параметры процесса

2)         аппаратную, которая определяется конкретной аппаратурой, на которой работает система управления. Здесь необходима работа программиста.

Синим цветом обозначены части системы, которые непосредственно зависят от аппаратуры (плат ввода-вывода) и требуют создания специального кода. Кирпичный цвет — это функциональное ПО, чистая математика, алгоритмы управления.

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

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

HIL – просто добавь модель процесса

Если у нас есть модель процессов, где мы рассчитываем параметры, нужные для технологически алгоритмов, то соединив модель объекта и алгоритмы в контроллере, мы можем проверить работу нашей системы управления на модели.

 Однако, для реализации нам необходимо не просто соединить модель и контроллер, А сделать это так, что обойти платы ввода-вывода и записать входные значения для технологических алгоритмов из математической модели, а результаты работы алгоритма предать обратно в модель.  В этом случае мы получим схему взаимодействия, представленную на рисунке 19. 

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

Таким образом мы перешли к проверке алгоритмов технолога на аппаратуре управления. Алгоритм управления, созданный и отлаженный в комплексной модели, заливается в контроллер и подключается к этой же комплексной модели (см. рис. 20). Вся остальная модель остается без изменений, она уже готова.

И в этой конфигурации прогоняются все те же тексты, что и в модели, но уже с контроллером. Вот вам и Hradware In The Loop.

Видео с примером отладки алгоритма на контроллере.

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

И снова возникает вопрос или даже два:

1) Кто должен это делать: программист или технолог?

2) Второй вопрос: а причем здесь графические языки программирования?

На самом деле ответ на первый вопрос зависит от ответа на второй.

Наличие графических языков, а также средств отладки, и определяет, кто будет выполнять тестирование аппаратуры совместно с моделью объекта. 

Если мы сгенерировали код из графического языка, загрузили в контроллер, и не имеем возможности отлаживать работу в графическом виде, то здесь нам нужен программист. Для технолога такой контроллер становится черным ящиком. Отладка программы управления идет по реакции системы на воздействия. И эту отладку будет делать программист, поскольку технолог или конструктор, как правило не понимает ничего в его Си, ST или, прости господи, ассемблере. И здесь у нас рождаются тома стандартов, регламентов, требований на предмет того, как всё-таки убедиться, что программист в контроллере имеет именно то, что имеет в голове технолог. Верификация и валидация, формальная и неформальная и прочие танцы вприсядку с бубном. 

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

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

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

После этого подключается программист и завершает работу, активируя и настраивая платы ввода-вывода. Можно, кстати, и на этом этапе провести еще одну проверку, но это уже другая история.

Выводы

Все профессии важны, все профессии нужны. Технолог и программист одинаково нужны и полезны при разработке системы управления сложных технических объектов, но технолог нужнее!