Отладка систем управления вместе с моделью объекта.
В данной статье рассмотрены примеры использования графических языков программирования в жизненном цикле модельно-ориентированного проектирования для систем управления сложными техническими объектами. А также продемонстрировано, как графические языки программирования делают жизнь проще, но интересней. И чтобы читатель не заскучал, мы рассмотрим противостояние программистов и технологов. Это как Монтекки и Капулетти, физики и лирики, красное и белое. Разберемся кто из них главный, а кто лишний.
Все события выдуманы, все совпадения случайны.
Определение:
Технологи - специалисты в конкретной предметной области: физики, электрики, конструктора и проектанты разных сложных объектов. Технолог знает, как работает его сложный технический объект, что и когда включать или что и когда выключать, чтобы не было потом мучительно больно.
Программисты - специалисты в написании программ, умеют закодировать любой бред, который напишут в техническом задании, а также знают, как работает аппаратура управления, и что нужно написать в коде, чтобы получить данные с АЦП в программу, и наоборот отправить из программы в ЦАП.
Каждый из них занимается свои делом по жизни, но, когда нужно создать сложный технический объект, они встречаются как лед и пламень, или лебедь, рак и щука, или мартышка и очки. А все потому, что любой современный технический объект содержит в себе систему управления, которая сейчас почти всегда выполнена в виде программного обеспечения на контроллере, а значит, нам нужен программист, и он должен понимать (хотя бы примерно), что от него хочет технолог.
Я нахожусь ровно по середине: как бывший технолог, физик-ядерщик по первому образованию, я уже забыл почти всю физику, но программировать так и не научился, то есть застрял на середине на пути от технолога к программисту. И, значит, я могу быть непредвзятым и объективным. Вообще технологи программист, это просто голоса в моей голове. Погнали.
Лирическое отступление
В предыдущей статье о синтаксическом сахаре для графических языков программирования я привел схему разработки модели, где волюнтаристски решил назначить 1D модель программой, созданной на проблемно-ориентированном языке программирования. Повторю ту картинку.
![Рисунок 1. 1D моделирование сложных объектов Рисунок 1. 1D моделирование сложных объектов](https://habrastorage.org/getpro/habr/upload_files/4d2/d29/e15/4d2d29e15643d1e12a82faad0509063c.png)
В дискуссии, которая развернулась под прошлой статьей, некоторые несознательные товарищи, которые не совсем товарищи, и не сталкивались с моделированием сложных объектов, не понимают, почему на вопрос о демонстрации отработки отказов я показал, как легко задать отказ в комплексной модели. Вот это видео.
На самом деле демонстрируемая в видео модель содержит и алгоритмы управления, и элементы объекта, реализованные с помощью одного и того же языка программирования на базе функционально блочных диаграмм FBD. Например, на следующем рисунке приведены диаграммы, одна из которых – часть алгоритма управления, который прямо сейчас реально управляет одной из АЭС России, а другая является частью математической модели электропривода задвижки.
![Рисунок 2. Интегратор в модели клапана Рисунок 2. Интегратор в модели клапана](https://habrastorage.org/getpro/habr/upload_files/88b/863/93e/88b86393e60a00d2b778f7c51033b494.png)
![Рисунок 3. Интегратор в ПИД регуляторе Рисунок 3. Интегратор в ПИД регуляторе](https://habrastorage.org/getpro/habr/upload_files/e7a/89b/7b7/e7a89b7b7b7a37b8e94c32d15f116f07.png)
Можете сказать какая диаграмма - модель, а какая - программа управления? Вот и я не могу, поскольку они одинаковые, хотя и разные.
Модель технического объекта как программа. Технолог как программист
Используя FBD диаграммы, мы можем создать как модель объекта, так и программу управления. При этом, сама модель, судя по рисункам 2 и 3, также является ничем иным как программой. На самом деле пока модель объекта работает на компьютере она (модель) – на самом деле программа.
А если модель — это программа, то мы можем применить к ней все практики, методы и рабочие инструменты, связанные с разработкой программного обеспечения. Например, мы можем использовать методы оптимизации, применяемые для настройки систем управления, но к конструкции. В этой статье приведен пример, когда мы подбираем не коэффициенты регулятора, а диаметр трубопроводов.
1D модель, таким образом, становится инструментом конструирования и проектирования. А это значит, что с этой моделью работает не программист, а конструктор или технолог. И здесь возникает закономерный вопрос: нельзя ли отдать технологу также и задачу разработки программного обеспечения для системы управления? Кто, кроме него, лучше знает как этой херовиной управлять?
А если у нас есть автоматическая генерация кода из 1D прямо в контроллер, то может быть и скрипач не нужен? Зачем нам программист, если технолог сам себе программист, может менять алгоритмы и заливать их в контроллер, используя графические языки программирования.
Скрипач не нужен?
Графические языки программирования создавались для упрощения понимания программы со стороны технолога, и должны помогать людям без знания текстовых языков программирования создавать программы для управления. А раз они создают программы, то пусть и создают их вплоть до реализации в контроллерах. Это выглядит логично, поскольку для технических объектов конструктор и технолог – главные в процессе создания. В отличие от программ для офисного планктона, ERP банковских приложений или всяких там игрушек с социальными сетями, программы управления объектом без самого объекта, которым программы управляют программы, на фиг никому не нужны.
В реальности любой конструктор или технолог, как только начинает создавать 1D модель, он по определению начинает создание алгоритмов управления (управляющее ПО) в виде FBD диаграммы, и тут же осуществляет их тестирование вместе с моделью объекта. В этом и есть смысл «модельно-ориентированного проектирования». Получается, что конструктор или проектант, создавая алгоритм управления, одновременно работает программистом, используя проблемно-ориентированный язык программирования. Так, может, пусть он и дальше программирует, не будучи программистом? Тем более, если у нас есть автоматическая генерация кода в контроллер.
Что дороже – программы или железо?
Если вы внимательно посмотрите на картинку 1, вам может показаться, что левая часть системы, там где создается программное обеспечение, выглядит значительно более дешевой, чем правая. Какие-то два шкафа автоматики, а с другой стороны, на картинке – АЭС стоимостью 8 ярдов зелени. (Конечно, два шкафа – это только на реакторное отделение, но это все равно, как говорят в Одессе это две большие разницф очевидна). На самом деле это вам не кажется, так оно и есть. Производители современных технических систем сообщают о росте количества строк кода управляющего ПО. Даже в современном автомобиле содержится уже более 5 млн строк кода. Но этот код ничего не стоит по сравнению с железом автомобиля, хотя бы потому что код можно размножать бесплатно копированием, а вот размножать бесплатно кузова и двигатели человечество не научилось. Не говоря уже о промышленных объектах, таких как АЭС.
Поэтому если вы обнаружили ошибку в управляющем ПО на стадии отладки, вы ее можете легко поправить. А если эта ошибка проявилась в реальном объекте, то поправить может быть ее уже не так легко, а иногда даже совсем поздно. (Привет, Чернобыль!) Такие ошибки могут делать очень и очень больно, и стоить очень и очень дорого.
![](https://habrastorage.org/getpro/habr/upload_files/029/e0f/7ae/029e0f7aea6e0e18cf16d74527796c7f.png)
Возникает вопрос: можно ли прежде, чем подключать дешёвый код для управления дорогим техническим объектом, проверить его на математической модели.
И ответ давно найден. Конечно, можно! Вот, например, картинка 2004 года, когда алгоритмы, созданные с использование функционально-блочных диаграмм для реактора чернобыльского типа РБМК, были проверены на модели, а потом результаты работы этих алгоритмов сравнивали с результатами работ реальной станции. Цифровой двойник как он есть, до того, как это стало модно.
![Рисунок 4. Сравнение модели и реальной АЭС Рисунок 4. Сравнение модели и реальной АЭС](https://habrastorage.org/getpro/habr/upload_files/121/331/c47/121331c4775ee9b576ee0931ae0939d5.png)
Модель как жизнь, жизнь как модель
Глядя на рисунок, можно возразить, что тут же совершенно разные графики: розовая линия (расчетные значения в модели) гладкие, а реальные показания бьются в истерике вокруг рассчитанного значения. Как это учитывается в модели? В модели все просто: рассчитала модель давление, отдали его в алгоритм и все пучком. А вы уверены, что алгоритмы сработают, когда реальный сигнал придет искаженным, с шумами и задержками? Поскольку у нас модель, то мы легко можем добавить в алгоритм и задержек и шумов, чтобы он был такой же, как в реальной жизни. Если нам нужно добавить шумов и задержек в сигнал, чтобы он был как в реальной жизни, это делается достаточно просто. На следующей схеме типовой алгоритм обработки сигнала с датчика, где мы добавляем смещение и пульсации, и если в математической модели давление ведет себя ровно и стабильно, то в алгоритмах мы получим такие пульсации и смещения, которые пожелаем.
![Рисунок 5. Модель датчика Рисунок 5. Модель датчика](https://habrastorage.org/getpro/habr/upload_files/039/2dd/573/0392dd573f0bf202c16ba51391a3eea5.png)
Ну, а сам размер и частота пульсаций задается технологом с помощью следующей схемы:
![Рисунок 6. Имитация шумов в датчики Рисунок 6. Имитация шумов в датчики](https://habrastorage.org/getpro/habr/upload_files/e7a/4e7/077/e7a4e707768789ae586824e045c23f10.png)
Таким образом, в алгоритм для обработки предается не рассчитанное моделью значение, а искаженное, и приближенное к реальным измерениям на объекте. Если наши алгоритмы с ними хорошо работают, значит есть хороший шанс, что на объекте все будет также.
Здесь мы снова видим, что технолог и конструктор, или специалист по измерительной аппаратуре гораздо важнее программиста, поскольку без специального образования и советующего опыта оценить, насколько модель соответствует правде жизни, невозможно. И снова чистый программистидет лесом, а технологи берут судьбу в свои руки и сами создают тестовые модели для управляющего программного обеспечения. Видео по теме.
Получается, что для разработки алгоритмов управления сложными системами с использованием модельно-ориентированного подхода и графических языков программирования программист не нужен? Не все так однозначно.
Из мягкой (soft) виртуальности в суровую (hard) реальность
Конечно, в виртуальном мире математического моделирования все можно проверить и отладить на модели с минимальными затратами времени и денег. Но система управления из виртуального мира среды проектирования должна перейти в контроллер, где и будет управлять нашим объектом.
На этом месте у технологов всегда остается вопрос. А вдруг в момент переноса наших замечательных и проверенных на модели алгоритмов в контроллер управления, какой-то программист своими кривыми руками все испортил? Как это проверить? И когда на объекте что-то идет не так, начинается аттракцион по перебрасыванию друг другу ответственности.
![Кто виноват и что делать? Кто виноват и что делать?](https://habrastorage.org/getpro/habr/upload_files/797/0bf/ee1/7970bfee135f2c623eeb4d0dfea7bbfc.gif)
Одним из способов ответа на этот животрепещущий вопрос является отладка алгоритмов управления, уже реализованных на аппаратуре управления. У наших зарубежных друзей это называется 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 моделирования обеспечивают связь между научными знаниями и их инженерным применением, как показано на следующем рисунке. Позволяя ученым быть проще, чтобы к ним тянулись инженеры.
![Рисунок 7. Ученый, будь проще! И к тебе потянутся инженеры Рисунок 7. Ученый, будь проще! И к тебе потянутся инженеры](https://habrastorage.org/getpro/habr/upload_files/eab/3fc/696/eab3fc696d4aabd621b65ae1fbc0c9eb.png)
Действительно, вместо зубодробительных трехэтажных математических формул описания динамики процесса мы смотрим на принципиальную гидравлическую электрическую или механическую схему, где размещены датчики (исходная данные для алгоритма управления) и видим, что происходит с системой в результате работы алгоритма. Вот, например модель гидравлической системы управления подводной добычи газа.
![Рисунок 8. Модель гидравлической системы подводного модуля Рисунок 8. Модель гидравлической системы подводного модуля](https://habrastorage.org/getpro/habr/upload_files/3a3/9dc/72c/3a39dc72c8c76fe8adcc54ae5d57ff91.png)
Если у нас модель объекта представлена в таком виде, то даже программисту без знания механики жидкости и газа, будет понятно, когда его задвижка открылась, и сколько времени этот процесс происходил. И что вообще у него происходит в модели системы.
Одно дело, когда вы пишете алгоритмы по требованиям от технолога, и совсем другое, когда требования от технологов вы можете посмотреть непосредственно на модели объекта и проверить, как ваша программа управления с ними справляется. И тогда в рамках тестирования управляющего ПО, можно проверять не вход-выход алгоритма, а параметры технического объекта в процессе моделирования.
Может технолог и конструктор не нужны, и все сделает программист, если ему дать хорошую 1Dмодель, созданную на хорошем графическом модельно-ориентированном языке программирования? И тогда главным становится программист, вооруженный хорошей и понятной моделью.
Чтобы понять кто в итоге главный в качестве примера рассмотрим реальную систему управления реакторным отделением АЭС, которая создается на графическом языке программирования и заливается в контроллер с помощью автоматической генерации кода.
А как оно бывает в реальности?
Рассмотрим реальный проект управления реакторного отделения АЭС, как раз случайно оказался под рукой. На рисунке 9 представлен верхний уровень проекта системы управления реакторным отделением одной из российских АЭС, выполненный в виде альбома функционально-блочных диаграмм. Данный проект полностью готов к генерации исходного кода и заливки в стойки управления.
Общее количество листов алгоритмов 82 стр. Из них 39 листов – технологических алгоритмов. Это те алгоритмы, которые создавал технолог, они описывают непосредственную реакцию системы управления на изменения параметров объекта. Остальные 41 лист алгоритмов — это алгоритмы, связанные с получением сигналов с датчиков и преобразованием их в переменные проекта, готовые для использования в алгоритмах технолога.
![Рисунок 9. Структура ПО системы управления реакторного отделения Рисунок 9. Структура ПО системы управления реакторного отделения](https://habrastorage.org/getpro/habr/upload_files/591/ad2/ed5/591ad2ed514c6bc2cfd8f7c4c71a5f1b.png)
Общий поток данных в алгоритмах управления соответствует стрелкам, изображенным на рисунке. Есть получение данных с датчиков, их обработка и выдача управляющего воздействия. Дополнительно существует возможность ввести аналоговые сигналы для настройки уже работающих алгоритмов, например, коэффициентов регуляторов или характеристик измерительных датчиков.
Пройдем по цепочке преобразования данных от измерения температуры термопарой до команды регулятору на открытие или закрытие клапана.
Ввод данных в систему управления
Термопара в зависимости от температуры изменяет свое сопротивление, и меняется ток. Линия с током подключается к плате ввода, где происходит считывание токового сигнала и преобразование его в цифровое значение. На следующем рисунке изображена диаграмма обработки токовых сигналов.
![Рисунок 10. Алгоритм обработки сигналов с дублированной платы ввода Рисунок 10. Алгоритм обработки сигналов с дублированной платы ввода](https://habrastorage.org/getpro/habr/upload_files/aa3/da2/6bc/aa3da26bc4cfddbcc7b612d54c2502ad.png)
Данная диаграмма описывает связь проводов с переменными в контроллере. Слева – список контактов плат, справа – имена переменных, доступных для обработки алгоритмов.
Поскольку данная палата ввода дублирована, она содержит в себе два контакта для каждого из сигналов. Для каждого, кроме непосредственного значения, полученного с термопары или другого датчика, формируется значение переменной «недостоверность канала». Алгоритм деградации обеспечивает переключение с недостоверного канала на достоверный.
Надо сказать, что недостоверность на этом уровне алгоритмов получена непосредственно с конкретной платы, сама плата содержит элементы диагностики своего состояния и сообщает об этом в контроллер. Поэтому для конкретной платы в управляющем ПО мы должны сгенерировать соответствующий код, на схеме этот код содержится в блоке «аппаратная привязка» в левом нижнем углу.
Этот код должен создавать программист-разработчик непосредственно данной платы, и задача автоматического кодогенератора – поместить данный код в нужное место общих исходных кодов программы.
![Рисунок 11. Элемент исходного кода на Си для работы с платой Рисунок 11. Элемент исходного кода на Си для работы с платой](https://habrastorage.org/getpro/habr/upload_files/e5a/c1a/287/e5ac1a2873b915c36527498a7d312bd7.png)
Подготовка данных
Нужно понимать, что недостоверность, полученная на этом этапе обработки входных данных, связана исключительно с работой платы преобразования. И отсутствие недостоверности на этом этапе не гарантирует, что сигнал достоверный.
Если мы потеряли связь (обрыв линии) с одним из контактов платы, плата ввода выдаст недостоверность данного сигнала. Но, если термопара потеряла контакт поверхностью, но продолжает работать, и температура в систему попадает, плата не видит отказа и считает сигнал достоверным. Но эта температура совсем не та, которую нужно использовать в алгоритмах управления. И совсем не та, на которую рассчитывает технолог.
Поэтому следующий этап — еще одна проверка достоверности полученных данных, в которой уже анализируются полученные данные на предмет достоверности самого значения.
Для оценки полученных данных используется набор параметров, приведенных на рисунке 12.
![Рисунок 12. Набор параметров для проверки достоверности показаний датчика Рисунок 12. Набор параметров для проверки достоверности показаний датчика](https://habrastorage.org/getpro/habr/upload_files/6b3/299/ffa/6b3299ffafcc5f9c21c23448a1b833a7.png)
Например, мы можем оценить достоверность по величине показаний, по скорости изменения или по времени, когда параметр не изменяется.
Таким образом, достоверный для платы сигнал, в случае, когда термопара потеряла контакт с контролируемой поверхностью, будет определен как недостоверный после анализа показаний. Пример обработки показаний датчика приведен на рисунке 13.
![Рисунок 13. Схема обработки показания для определения достоверности Рисунок 13. Схема обработки показания для определения достоверности](https://habrastorage.org/getpro/habr/upload_files/d6a/eb6/556/d6aeb6556e418ba981af1e968023a3e4.png)
С помощью данного расчетного кода происходит пересчёт полученного значения в миллиамперах в единицы измерения температуры, расчет величины показания в процентах от диапазона (верхняя часть алгоритма), а также анализ полученных данных на достоверность.
При этом нужно понимать, что технолог в алгоритмах тоже должен учитывать состояние недостоверности измеряемых каналов. И в этом случае отказы оборудования должны быть использованы как исходные данные для технологического алгоритма, обеспечивающего обработку отказов. Например, если мы потеряли показания датчиков температуры, то должна включаться защита, которая блокирует работу регулятора температуры, выдает предупредительную сигнализацию оператору, а в некоторых случаях автоматически останавливает процесс. Либо, если у нас резервированная система измерения, алгоритм должен переключиться на резервный канал измерения. Это такой же технологический алгоритм, который должен разработать технолог при проектировании объекта.
![Рисунок 14. Обработка отказов в оборудовании Рисунок 14. Обработка отказов в оборудовании](https://habrastorage.org/getpro/habr/upload_files/d17/541/60b/d1754160b6aa27cc9f8253fb1d14276a.png)
Сложные параметры
Простого определения достоверности сигнала зачастую нам недостаточно, поскольку в алгоритмах технолог может использовать, не просто температуру с датчика, а более сложный производный параметр, например, среднюю температуру или максимальную температуру в объекте, а такие значения получаются не с одной термопары, а с нескольких, которые также уже проверены на достоверность.
И теперь при расчете средней температуры мы можем отбросить те показания, которые не достоверны. А учитывать только показания достоверных датчиков.
Пример реализации вычисления сложных сигналов приведен на рисунке 15.
![Рисунок 15. Расчет максимальной температуры петлей циркуляции Рисунок 15. Расчет максимальной температуры петлей циркуляции](https://habrastorage.org/getpro/habr/upload_files/720/7e9/4c9/7207e94c9d1f5d037cd150db0b974206.png)
Функциональное ПО
Только после того, как мы обработали сигналы на предмет достоверности, вычислили сложные сигналы, мы можем переходить непосредственно к расчету управляющего воздействия. На следующем рисунке достоверный сигнал используется в регуляторе для формирования команд открытия или закрытия задвижки.
Именно эта часть непосредственно и обеспечивает управление технологическим процессом и регулирования параметров объекта.
Обратите внимание на нижнюю часть алгоритма рисунка 15: в качестве входных сигналов в алгоритм используются признаки отказов, которые используются для принятия решения и оказывают влияние на результат.
Например, наш датчик отлично работает и ПИД регулятор рассчитывает команды на клапан, наличие сигнала «авария» или отказов приводят регулятор в состояние «отключен». Таким образом в алгоритмах напрямую используются сигналы от отказов оборудования. И что делать в случае отказа, решает как раз специалист по технологии процесса.
![Рисунок 16. Регулятор расхода, использующий датчик температуры Рисунок 16. Регулятор расхода, использующий датчик температуры](https://habrastorage.org/getpro/habr/upload_files/968/1da/52a/9681da52ad070c713741eb60a8c04d3f.png)
Вывод данных
После того, как ПИД регулятор сформировал команду на открытие или закрытие клапана, нам нужно передать сигнал на плату вывода. Диаграмма выглядит как на рисунке 17. В принципе, все то же самое, что и для ввода, только наоборот.
![Рисунок 17. Диаграмма вывода команд системы управления Рисунок 17. Диаграмма вывода команд системы управления](https://habrastorage.org/getpro/habr/upload_files/0bb/cf4/e4d/0bbcf4e4d124680e38895a4872dfd85b.png)
Слева – переменные, рассчитанные в алгоритмах управления, справа – контакты платы. И пользователь просто сообщает системе, что и куда послать.
Также понятно, что для конкретной платы необходимо добавить в код привязку к аппаратуре, которая обеспечит передачу команд на нужные контакты платы. И здесь снова появляется программист, который должен работать с платой.
В правой нижней части алгоритма часть команд отправляется на видеокадры, а также формируется логика выбора контроллера для управления в случае дублированного контроллера.
Вкратце на этом все: получили данные, выработали команды и повторяем все на каждом такте работы контроллера.
С точки зрения зоны ответственности, можно в общем проекте системы управления выделить две части:
1) технологическую, которая полностью определяется технологом или конструктором объекта, и которая обеспечивает заданные параметры процесса
2) аппаратную, которая определяется конкретной аппаратурой, на которой работает система управления. Здесь необходима работа программиста.
![Рисунок 18. Структура ПО для управления АЭС Рисунок 18. Структура ПО для управления АЭС](https://habrastorage.org/getpro/habr/upload_files/c41/f44/79e/c41f4479e7d5443020cf871e70e91921.png)
Синим цветом обозначены части системы, которые непосредственно зависят от аппаратуры (плат ввода-вывода) и требуют создания специального кода. Кирпичный цвет — это функциональное ПО, чистая математика, алгоритмы управления.
Обозначенная синим цветом часть программы зависит от аппаратной реализации. Используя разные платы ввода, мы будем использовать разное программное обеспечение, предназначенное для конкретной платы. Для разработки требуются специалисты со знанием конкретной аппаратуры. И, как правило, здесь нужно писать драйвера и использовать стандартные языки программирования. В самом деле, с датчика температуры в систему управления приходит не температура в градусах Цельсия или Кельвина, а значение токового сигнала в миллиамперах. Для превращения этого сигнала в значение переменной в памяти нужно выполнить программный код для конкретной платы. Изменили плату – изменяем код. И здесь без программиста, знающего аппаратуру, не обойтись.
С другой стороны, можно сказать, что подготовка данных и технологические алгоритмы вообще не зависят от выбранной аппаратной реализации системы управления. Если в алгоритмах подготовки данных еще может участвовать информация, полученная от аппаратуры (как правило данные об неисправностях), то уже в технологических алгоритмах используются только технологические параметры объекта управления, например, температура, давление, расход и т.п. И эти вычисления не зависят от выбранной аппаратуры управления, а определяются исключительно процессом в техническом объекте.
HIL – просто добавь модель процесса
Если у нас есть модель процессов, где мы рассчитываем параметры, нужные для технологически алгоритмов, то соединив модель объекта и алгоритмы в контроллере, мы можем проверить работу нашей системы управления на модели.
Однако, для реализации нам необходимо не просто соединить модель и контроллер, А сделать это так, что обойти платы ввода-вывода и записать входные значения для технологических алгоритмов из математической модели, а результаты работы алгоритма предать обратно в модель. В этом случае мы получим схему взаимодействия, представленную на рисунке 19.
![Рисунок 19. Отладка технологических алгоритмов в контроллере Рисунок 19. Отладка технологических алгоритмов в контроллере](https://habrastorage.org/getpro/habr/upload_files/a2d/b21/cf4/a2db21cf46ab68ab89503e2abe19b4e0.png)
Причем, как это показано в начале статьи, мы можем передавать в контроллер, не рассчитанные значения из моделей, а рассчитанные значения с шумами и задержками, чтобы контролёр получал данные, максимально похожие на полученные с карт ввода-вывода.
Таким образом мы перешли к проверке алгоритмов технолога на аппаратуре управления. Алгоритм управления, созданный и отлаженный в комплексной модели, заливается в контроллер и подключается к этой же комплексной модели (см. рис. 20). Вся остальная модель остается без изменений, она уже готова.
И в этой конфигурации прогоняются все те же тексты, что и в модели, но уже с контроллером. Вот вам и Hradware In The Loop.
![Рисунок 20. Отладка алгоритмов на аппаратуре в составе комплексной модели Рисунок 20. Отладка алгоритмов на аппаратуре в составе комплексной модели](https://habrastorage.org/getpro/habr/upload_files/afe/32e/051/afe32e051512463b93e63261be2eaa15.png)
Видео с примером отладки алгоритма на контроллере.
Теперь мы можем проверить, что после переноса нашей модели из среды моделирования в контроллер, все работает ровно так же, как и в модели. И что выбранная аппретура управления обеспечивает заданные параметры управления. Например, хватает ли тактовой частоты, оперативной памяти для выполнения вычислений тех алгоритмов, которые мы тут напридумывали.
И снова возникает вопрос или даже два:
1) Кто должен это делать: программист или технолог?
2) Второй вопрос: а причем здесь графические языки программирования?
На самом деле ответ на первый вопрос зависит от ответа на второй.
Наличие графических языков, а также средств отладки, и определяет, кто будет выполнять тестирование аппаратуры совместно с моделью объекта.
Если мы сгенерировали код из графического языка, загрузили в контроллер, и не имеем возможности отлаживать работу в графическом виде, то здесь нам нужен программист. Для технолога такой контроллер становится черным ящиком. Отладка программы управления идет по реакции системы на воздействия. И эту отладку будет делать программист, поскольку технолог или конструктор, как правило не понимает ничего в его Си, ST или, прости господи, ассемблере. И здесь у нас рождаются тома стандартов, регламентов, требований на предмет того, как всё-таки убедиться, что программист в контроллере имеет именно то, что имеет в голове технолог. Верификация и валидация, формальная и неформальная и прочие танцы вприсядку с бубном.
А если средства 1D моделирования обеспечивают протокол отладки совместно с аппаратурой, когда на схеме алгоритма в графическом языке, отражается работа в контроллере в реальном времени, то отладкой в контроллере может заниматься технолог, для которого процесс отладки визуально ничем не отличается от комплексного моделирования. Если графический язык поддерживает отладку алгоритмов в контроллере, то в процессе отладки можно видеть значение параметров непосредственно на схеме алгоритмов, и, таким образом, поиск ошибок и отклонений значительно упрощается.
Например, на следующем рисунке, показан процесс отладки комплексной модели. Технолог видит показания датчика в модели, видит значение полученное ПИД регулятором, видит промежуточные значения вычисления, результат в виде команды исполнительному механизму в модели и видит, что происходит с давлением температурой и прочими технологическим параметрами в модели. Такая отладка обеспечивает полную прозрачность работы объекта, значительно упрощает поиск и устранения неполадок и позволяет выполнять настройку и оптимизацию всех процессов.
![Риснок 21. Отладка алгоритма вместе с моделью Риснок 21. Отладка алгоритма вместе с моделью](https://habrastorage.org/getpro/habr/upload_files/0d2/bdd/75b/0d2bdd75ba40b387af57123a9fe2b19c.png)
В этом случае технолог может в комплексной модели провести все необходимые тесты по верификации и валидации работы алгоритмов в различных режимах. Потом залить алгоритмы в котроллер и, используя ровно те же самые тесты, проверить работу алгоритмов уже на контроллере, что значительно сокращает общее время отладки и стоимость разработки.
После этого подключается программист и завершает работу, активируя и настраивая платы ввода-вывода. Можно, кстати, и на этом этапе провести еще одну проверку, но это уже другая история.
Выводы
Все профессии важны, все профессии нужны. Технолог и программист одинаково нужны и полезны при разработке системы управления сложных технических объектов, но технолог нужнее!
Комментарии (28)
lumen_xp
04.08.2024 22:57+1Подскажите как генерировать алгоритмы (рисунки 13-17)? По блок-схема все понятно, а по этой части документацию с ходу не нашел.
lumen_xp
04.08.2024 22:57+1И сразу второй вопрос, как дела обстоят с OPC DA, UA. У обычных смертных не работающих с активной зоной контроллеры то буржуазные, хотелось бы модель покрутить с реальным ПЛК.
Indemsys
04.08.2024 22:57Здесь https://habr.com/ru/articles/581468/ пример как выглядят портируемые модели на ПЛК.
petuhoff Автор
04.08.2024 22:57OPC и OPC UA блоки в закладке Устройства. Работает в нескольких проектах уже.
В папке демо пример есть
petuhoff Автор
04.08.2024 22:57Если ваш контроллер с Linux или QNX то там все должно идти по кнопке. Если у вас микроконтроллер из поддерживаемых по умолчанию то там все тоже одной двумя кнопками. Если нет нужно брать один из шаблонов генерации и по образцу и подобию переделывать его под задачу
В папке SimInTech после установке есть папка doc в ней Программирование встраиваемых систем
C:\SimInTech64\doc\Программирование встраиваемых систем
Indemsys
04.08.2024 22:57+3Статью прочитать не смог, невозможный для восприятия стиль. Отдал ChatGPT на анализ. Тот ответил, что в статье утвержадется, что для построения моделей типа HIL обязательно нужен технолог.
Я что-то здесь сомневаюсь. В случае HIL не будет построено адекватеной модели. Там в лучшем случае можно помоделировать разные виды аварий и неисправностей на коротких отрезках времени. Зачем там технолог?
Другое дело SIL, как вот в этой статье, вот тут технолог бы пригодился со своими эвристиками. Потому что тут реально нужен прошлый опыт технолога при взаимодействии с ситемой.
А зачем технолог при моделировании аварий в HIL, о которых технолог даже не подозревает и в жизни не сталкивался?
petuhoff Автор
04.08.2024 22:57+1На вкус и цвет все фломастеры разные, мне лично наоборот стиль научных публикаций и учебников никогда не нравился. В свое время я еще студентом, купил книгу Очков В.Ф. "Mathcad 6 для студентов и инженеров" купил ее просто потому, что нужно было курсовой сделать. Купил как справочник, только потому что там в содержании был интересующий меня пример. Открыл эту книжку в метро пока добирался из центра Москвы в свое замкадье, и не отрываясь прочитал всю пока ехел с двумя пересадками. Это было оченьку круто, читать книгу по программе как художественную литературу. Автор в предисловии поясняет:
"С другой стороны, автор понимает, что стиль этюдов (из которых составлена книга) не всегда импонирует читателю издательства "КомпьютерПресс", привыкшему к краткому, четкому и в то же время по возможности полномуизложению.
С тех по когда сам пишут тексты страюсь в меру своих слабых сил писать с художественными извращениям, что бы было не скучно. Конечно до Очкова мне как до Пекниа раком, но это не значит, что не надо пробовать.
Отдал ChatGPT на анализ.
Это порадовало реально. ChatGPT тоже ошибается. Основная мысль статьи что программист, как скрипач, не нужен а все может сделать технолог и даже отладить программу в контроллере. :))))) У нас был пример когда програмиста престали брать на объект, технолог гонял программу в конктроллере на модели, а потом сам заливал ее в контролел на АЭС. А определение технолога в начале:
Технологи - специалисты в конкретной предметной области: физики, электрики, конструктора и проектанты разных сложных объектов. Технолог знает, как работает его сложный технический объект, что и когда включать или что и когда выключать, чтобы не было потом мучительно больно.
Возможно мы говорим о системах разной размерности и сложности
В случае HIL не будет построено адекватеной модели. Там в лучшем случае можно помоделировать разные виды аварий и неисправностей на коротких отрезках времени.
Если говорить про реальные сложные системы, то например для отладки аппаратуры ледокола, используется полноценная модель реактора и турбины которую создают в ОКБМ на стадии проектирования, и на ней гоняют систему управления уже залитую в стойки и режимы там могут суткам моделировать, если разогрев реактора проверяют
Indemsys
04.08.2024 22:57+1Если бы существовали "полноценные" модели реакторов никто бы так не боялся их.
Тут даже полноценных моделей асинхронных моторов сделать не могут. Потому что полноценные модели либо слишком детализированы и с их расчетом в реальном времени не справляются компьютеры, либо моделируемые системы недостаточно изучены. Неспроста появился AI. Вручную наращивать детализацию люди больше не могут.
Программисты критически нужны в обоих случаях. В первом случае чтобы поддерживать модели на нужном уровне производительности и повышать её, во втором чтобы обеспечивать гибкость архитектуры модели. Ну и чтобы уже переходить на AI.
Если обходятся одним технологом значит модель морально устарела.petuhoff Автор
04.08.2024 22:57+1Никто реакторов не боится, так же как никто не боится автомбилей и электро самокатов. Это просто устройства, хотя автомбили больше убили людей чем все реакторы вместе взятые.
Потому что полноценные модели либо слишком детализированы и с их расчетом в реальном времени не справляются компьютеры, либо моделируемые системы недостаточно изучены.
Нужно понимать, нет понятия "полноценная модель", для разных задач используются разные модели, даже для одного и того же устройства. Используются разные математические модели. Полнота модели и степень детализации определяются задачами. В статье речь и идет о програмнном обеспечении в системах управления сложными техническими устройствами. А значит нам нужна такая модель, которая выдаст значения соответсвющие точностями реального измерения, в точнее не надо, система управления и программа управления все равно эту точность не получат, в качестве исходных данных, следовательно для целей тестировани HIL она избыточна
Вот здесь пример создания модели для авиационного теплообменника и его сравнение с реальными данным, для определени минимально необходимой точности модели Модельно ориентированное проектирование. Создание достоверной модели, на примере авиационного теплообменника
Если обходятся одним технологом значит модель морально устарела.
С чего это? Реактор работате 60 лет, систему управления для него меняют раз в 10 лет, как может морально устареть модель, если сам объект не изменился?
Или взять модель движения летательного аппарата в Matlab Simulink, там просто уравнения Ньютона, как уравнение Ньютона могут морально устареть?
Программисты критически нужны в обоих случаях. В первом случае чтобы поддерживать модели на нужном уровне производительности и повышать её,
В статье шла речь про прогамирование систем управления для технических объектов, саму систему управления пишут программисты.
NutsUnderline
04.08.2024 22:57+1никто не боится автомбилей и электро самокатов
в профильных топиках говорят иначе ;)
Indemsys
04.08.2024 22:57+1А значит нам нужна такая модель, которая выдаст значения соответсвющие точностями реального измерения, в точнее не надо, система управления и программа управления все равно эту точность не получат, в качестве исходных данных, следовательно для целей тестировани HIL она избыточна
Тут запутали окончательно.
Модель в HIL не про точность , а про поведение, как я понимаю эту технологию.
И поведение это придумывается чисто умозрительно не опираясь ни на какой опыт. Например придумать сколько датчиков откажет и какого типа отказы будут.
Будет ли это дребезг, спорадические выбросы, разрывы, утечки и смещение показаний или прочее. Вот такие сценарии в HIL и отрабатывают. При чем тут технолог?
Это комбинаторная задача не уровня технолога.
Вы же не можете создать модель реактора прямо повторяющую физику реактора. Иначе бы в Чернобыле не ставили эксперименты на живом реакторе. Вы можете только моделировать переключатели и простые грубые зависимости типа звеньев второго - третьего порядка. А дальше неизвестность и эвристики.Про колическтво листов в модели тоже не аргумент в пользу ее полноты и комплексности. Это может быть простое механическое масштабирование, когда вместо одного вентиля моделируют сотню. Вот вам и сотня листов или тысяча если рисовать, как на ваших скриншотах, заполняя все непропорционально большими блоками и рамками.
Т.е. тема адекватности моделей и принципов их создания в HIL не раскрыта.
petuhoff Автор
04.08.2024 22:57Вы же не можете создать модель реактора прямо повторяющую физику реактора. Иначе бы в Чернобыле не ставили эксперименты на живом реакторе. Вы можете только моделировать переключатели и простые грубые зависимости типа звеньев второго - третьего порядка. А дальше неизвестность и эвристики.
Вполне себе можем. Для этого и придумали целый раздели математики диференциальное исчисление называется. Если у вас есть система диференциальных уравнений описывающая процесс, то вы можете его рассчитать. Переключения и грубые зависимости это для слабаков полупокерсов с Simulink. У нас SimInTech отмоделируюет все что движется, а что что не движется подвигает и тоже отмоделирует. :))))))
Т.е. тема адекватности моделей и принципов их создания в HIL не раскрыта.
Тема адекватности раскрыта, только ChatGPT этого не понимает, вот картинка из статьи:
Сравнение модели реактора и реального реактора Это может быть простое механическое масштабирование, когда вместо одного вентиля моделируют сотню. Вот вам и сотня листов или тысяча если рисовать, как на ваших скриншотах, заполняя все непропорционально большими блоками и рамками.
Конечно сотни и даже тысячи задвижек, калпанов и вентилей не показатель, комплексности модели, но вот когда эта сотня задвижек и клапанов, стоит в системе взаимосвязаных трубопроводов, реактора и турбины вмесе с насосами и теплообменниками, и когда перемещения клапана в одной части системы меняют всю систему с обратными связями по давлению, тогда да. У нас первой столконовение с Simulink было когда в систем было всего три клапана и один блок конденсатора, Simulink не смог решит задачу именно из-за уравнений механики жидкости и газа. Когда три клапана влияют на праметры всей системы через уравненьния Бернули и Новье-Стокса
А из последнего веселого у нас есть 8000 среверов у каждого из которых хитрый ПИД регулятор с 4 вентиляторами, в зависимости от нагрзуки на дата центра, греется либо процессор либо память либо жестки диски все это стоит в дата центре и динамически в течении дня меняет нагрузуку на все сревера.
Как я чуть не стал миллионером, продавая воздух, или почему Россия – не Америка
Indemsys
04.08.2024 22:57У нас SimInTech отмоделируюет все что движется, а что что не движется подвигает и тоже отмоделирует. :))))))
Моделировать то можно, но в HIL модель должна работать в реальном времени.
Поэтому я не верю, что вы имеете модель реактора со всей тысячей клапанов работающей в реальном времени.
Тема все же не раскрыта.Simulink то хоть может откомпилировать модель и запустить на специальной RealTime платформе, а не на Windows. А ваш SimInTech чё?
petuhoff Автор
04.08.2024 22:57Поэтому я не верю, что вы имеете модель реактора со всей тысячей клапанов работающей в реальном времени.
Если на клетке слона прочтешь надпись: буйвол, — не верь глазам своим!
Вот у меня на макбуке в виртуальной машине крутится часть модели реактора с турбиной там 5 проектов (пять моделей которые можно на разные компьторы разнести), 300 задвижек и клапанов 500 датчиков в гидравлике 1465 объемов.
Считает в 5 раз быстрее реального времени. То есть даже здесь можно модель увеличить в 5 раз и попадать в реальное время. А если несколько компьютеров поставить? Обычно модель реактора ледокола на 5 машинах разворачивается и спокойно сичтает.
Считать больше быстрее точнее! Simulink то хоть может откомпилировать модель и запустить на специальной RealTime платформе, а не на Windows. А ваш SimInTech чё?
У вас просто представление о моделировании испорченно тормозным Simulink-ом.
У нас тоже можно скопиилировать модель в Си и запустить хоть в контроллере, но если запас в 5 раз быстрее реального времени, можно таким извращением не заниматся, а использовать модель в SimInTech на рабочей станции.
Indemsys
04.08.2024 22:57+1А, сорри, понял в чем подвох. У вас реальное время с очень длинными тактами.
Тогда вопрос снят.
Приколько только что вы умудряетесь писать про системы управления и не упоминать длительность такта.Кстати интересен вопрос выбора масштаба самого реального времени.
petuhoff Автор
04.08.2024 22:57Правильно! Если требуемый так управления маленький то никакой компьютре не успевает, даже на простой модели. В теплогидаравлической модели турбины шаг интегрирования плавающий в зависимости от процессов модель его меняет от 0.1 до 0.001 секунды, для автоматики шаг постоянный 0.05 сек. На контроллере такой же.
petuhoff Автор
04.08.2024 22:57Вот тут сравнение Simulink - SimInTech одинаковые методы модели и шаги урпаления скорост в 4 раза
Indemsys
04.08.2024 22:57Это вообще не серьезно.
Во-первых, профилировщик сам замедляет работу модели. Покажите для начала такой же мощный профилировщик у SimInTech. Во-вторых реально модель выполняется за 2.7 сек. В третьих, есть еще отладочная информация, это тоже занимает время. И в оригинальной модели графиков гораздо больше чем у вас.
Словом если что-то моделируется в несколько раз быстрее, то ищите проблему в этой самой быстрой модели. Там наверняка будет либо меньше отладочных данных, либо меньше диагностики, либо она будет менее точная (проверьте типы данных)
petuhoff Автор
04.08.2024 22:57Нет, не прокатит :))) Тут как раз эталонная модель, для прямого сравнения лоб в лоб, в отчете до 14 знака отклонения искали поэтому и методы интегрирования, и шаги и графики все 1 в 1.
Indemsys
04.08.2024 22:57Этому нет подтверждения. Но здравый смысл говорит, что софт не может отличаться по быстродействию если он принципиально считает одно и тоже.
Сравните компиляторы. Там отличия на проценты. Сравните симуляторы - аналогично. Я вам даже скажу, что ваша модель атомной станции не так сложна по сравнению с моделью обычного Buck-Boost конвертера, если в нем применяют детализацию моделей транзисторов уровня L3.
Давайте я вам дам мою state machine в Similink и сделайте ее сгенерированный код в 5 раз быстрее. (это риторика, конечно вы его быстрее не сделаете, его даже вручную уже несоптимизировать)
Обратите внимание на нули в профилировщике для подблоков модели. Т.е. они считаются вообще мгновенно. Все время уходит на накладные расходы на отладочные фичи.
Словом вы не привели доказательств, да и в модели Simulink применены закрытые блоки, типа модели атмосферы, которые вы врядли могли воспроизвести один в один.
petuhoff Автор
04.08.2024 22:57Словом вы не привели доказательств, да и в модели Simulink применены закрытые блоки, типа модели атмосферы, которые вы врядли могли воспроизвести один в один.
Именно 1:1 и даже отчеты по валидации блоков с тестовыми моделиями в это работе были. Вот скриншот страницы
сравнение блока с учтом ветра А вот полученные отклонения
petuhoff Автор
04.08.2024 22:57Словом вы не привели доказательств, да и в модели Simulink применены закрытые блоки, типа модели атмосферы, которые вы врядли могли воспроизвести один в один.
Вот здесь: https://habr.com/ru/articles/787668/
Indemsys
04.08.2024 22:57Ну это, скажет так, просто реверсинжениринг.
Хитрыми уловками вы могли просто скомпилить .exe или .dll в Simulink и представить это своим заказчикам, как результат компиляции SimInTech.Такие вещи скриншотами не доказываются. Тут все потроха надо рассматривать под лупой. Но это не принципиально. И так видно что Simulink пока гораздо сильнее в плане отладочных инструментов и косвенно это подтверждается скоростью ваших моделей.
petuhoff Автор
04.08.2024 22:57так мы в очете и показываем все потороха, и лупа тут не нужна, кстати блок ISA атмосферы открыт в Simulink
Если посмотреть под маску
NickRomo
04.08.2024 22:57+1Словарь Ожегова(вроде) залупить - отодвинуть кожу с пальца
petuhoff Автор
04.08.2024 22:57здесь от англиского луп - петля :))))))
lws0954
04.08.2024 22:57+1По Ожегову есть и такое - "завернуться". Например, "старая краска залупилась". Но мне припоминается и не очень официальное - типа "выступить не по делу" ;)
Но "запетлиться" - это, безусловно, что-то новое даже для Ожегова :)
А если подключить китайский язык? Вот где простор для воображения! Пресловутое и безобидное конкурентное программирование (concurrent programming) - просто отдыхает! :)
Yuri0128
Маленькое замечание: термопара не меняет свое сопротивление (меняет его терморезистор) а генерирует термоЭДС, которая идет на усилитель и преобразователь...
Вам еще стать немного электронщиком в дополнение к немного уже не технолог и немного программист.