Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 25
КонтроЛеры, они такие контроЛеры, что даже орфография над ними не властна.
Фамилия автора в точности описывает стиль и смысл статьи)) хорошая дипломная работа для 4 курса, которая не имеет ничего общего с реальными объектами.
То что меня в коментариях постоянноу учат правильно весть бизнес я к этому привык. А вот, то что SimInTech не имеет ничего обещего с реалным объектам это что-то новое.
Моя дипломная работа 4-го курса, это нештатная система регистрации параметров для атомной подводной лодки (сегодя как раз юбилей подводно флота), и она 20 лет назад уже на лодке работала.
А конце статьи видео с испытаний реальной АСУ ТП турбины АЭС. Это АСУ ТП создано ровно по тем технологиями, которые описаны в статье. И технологии эти атомным реакторами управляет где то с 2007 года.
Что до фамилии, так это просто тест на IQ, я это еще в 2 классе школы понял.
После видео стало понятнее, беру свои слова обратно, искьюз-муа. Вопрос к обслуживанию. Вряд-ли штатный персонал заказчика может забрать обслуживание на себя без должного переобучения, насколько внедрение такого подхода будет дешевле..вопрос, сравнительных спецификаций нет, да и по железу вопросы, чтобы крутить модель нужны сервера, да и ещё с платами ввода-вывода,да и ещё возможно не один сервер (отдельный для базы данных, отдельный для модели, мб не так понял), а это ещё и ПЛК в шкафу, без нормальной схемы КТС непонятно сколько оборудования. И что делать с объектами на +-100 сигналов?
Подытожим: кроме того что заказчику необходимо купить ПЛК, так ещё надо купить кучу серверов, купить лицензии для simintech (возможно), найти подрядчиков с компетенциями разрабатывать проекты в simintech, которых как я понимаю не так много, с точки зрения "бизнеса" можно понять, Ваш подход хорош. Также потом как-то надо обслуживать это всё, не все могут позволить себе тех.поддержку. Вопросы к железу, где покупать все эти платы ввода-вывода, опять же, все эти сервера, на которых крутится модель и база данных "православные".... не думаю.
Возможно это хорошее решение в каком-то узком направлении, в масштабах всего АСУ ТП трудно представить такую модель как рабочую.
p.s. возможно в чем-то не прав, опять же я без негатива, эт же просто форум.
*комментарии с привкусом хейта тоже своего рода тест на IQ))
Может быть у меня профдеформация, но мне кажется что никакого переобучения большого тут не нужно. По сути дела на объекте нужен только ноутбук с SimInTech подключили к окнтроллеру и смотрим на схеме что там внутри его происходит. На экране FBD диаграмма по линиям бегут цифры, все наглядно прозрачно.
По моим оценкам любой програмист ПЛК или разработчик алгоритмов управления осилит SimInTech недели за две.
Модель всего объекта тоже не обязательна. В пирмере я просто бак с насосами и задвижками собрал за 15 минут. Но можно еще упростить - поставить источник - уровень и два коэффициента для его снижения при одном включенном насосе или двух насосах. Будет примерно как нагреватель в статье https://habr.com/ru/articles/307090/
Можно вообще без модели прямо в SimInTech задавать воздействия входы и смотерть что там алогритм на выход выдает.
Для подключения плат ввода-вывода, дестивительно уже нужен программист, который понимает как с ними работать. И тут дествительно нужна воля производителей что бы они эту поддрежку включили. С другой стороны если код Си для доступа к палтам есть, то упаковать его в блоки SimInTech это не сложная задача.
В итоге на объекте нужен только ноутбук с SimInTech, что бы проверять работу алгоритмов и их модифицировать.
Кровь из глаз пойдет у инженеров от такого визуала. Им с помощью этого нужно чинить оборудование.
Проект после ввода в эксплуатацию становится инструментом диагностики. Инженер должен мгновенно понимать:
что это за скорость,
откуда она берется,
где искать ее в схеме,
и что это вообще за сигнал.
Здесь должна быть простая и прозрачная логика. А у вас — как в PCS:
ни комментариев, ни декомпозиции на небольшие алгоритмы (нетворки, рутины).
Вы правда думаете, что крупные международные компании делают это просто так?
Зачем снова изобретать велосипед?
Инженеры десятилетиями оттачивали подходы к диагностике и сопровождению. А здесь предлагается решение, которое игнорирует этот опыт.
Как вообще появляются такие решения?
Сходите «в поля», посмотрите, как люди реально работают с системой.
Не придумывайте красивые концепции, которые не имеют ничего общего с эксплуатацией.
Люди будут работать не только с вашим проектом.
У них есть оборудование, электрические схемы, документация.
И при этом значение сигнала — в отдельном всплывающем окне. Серьезно?
Так у вас реализован онлайн-контроль?
Для кого это вообще сделано?
Это выглядит как продукт, ориентированный на презентацию менеджерам, а не на реальную эксплуатацию.
А потом инженеры 10–20 лет вынуждены с этим жить и обслуживать производство.
Проект после ввода в эксплуатацию становится инструментом диагностики. Инженер должен мгновенно понимать:
что это за скорость,
откуда она берется,
где искать ее в схеме,
и что это вообще за сигнал.
Если речь идет о скорости на риснке из коментанитя то это пример быстрого создания модели для тестирования алгоритма, и она берется из характеристик оборудования, когда нужно быстро превратить последовательность срабатывания каких либо защит при нагреве и охлаждении. Для в проекте, есть куча способов быстро определилить источник сигнала, начиная с системы кодирования, закзаничвания поиском источника по всем проектам. Ну например я как раз тупо менеджер и забыл как у меня сто работает подключаю ноутбук к контроллеру и открываю алгаоримт защиты вижу датчики. LBA20CP001A -технолог уже на это месте может расказать какая система какой датчик и какая труба, но я тупой менегер.
Кликаю на поиск и попдаю в базу данных где руским языком для дебила написано написано что это давления в ГПК (Главный паровой коллектор)
После этого открываю схему гидравлики поиск и вижу где у меня стоят эти датики
тоже самое могу сделать с любым сиганлом в работающем в контроллер алгоритме. Наприме у меня в алгоритме учитывается положение задвижки. Два кличка мышки и я про это задвижку занаю все что нужно.
Там же я могу посомтрть не только заначения показания датчика или задвижки но еще и под сотню параметров описывающих датчик или задвижку как в проекте (см. пример на рисунке). Хотите посомтреть списком сигналв выбирайте и смотрите
И при этом значение сигнала — в отдельном всплывающем окне. Серьезно?
В отдельно всплывающем окне я могу посмотреть значения на линии связи во время выполенения алгорима, это не сигнал это промежуточные вычисления, которые происходят в алгоритмме, если он достаточно сложный или нужно посмотреть за накоплением в интеграторах или счетчиках во время отладки жто бывает полезно
ни комментариев, ни декомпозиции на небольшие алгоритмы (нетворки, рутины).
Тут сама диаграмма это один сплошной окментарий. Здесь сам принцип формирования алгоритма обязывает разработчика декомпозировать на листы алгоритмов и системы, просто потому что это диаграмма алгоритмов.
Инженеры десятилетиями оттачивали подходы к диагностике и сопровождению. А здесь предлагается решение, которое игнорирует этот опыт.
Это решение уже 20 лет реакторами АЭС и АПЛ управляет. Это решение разработано как раз под созлание сложного АСУ ТП для атомных реакторов.
Ваш подход действительно интересен с точки зрения разработки и переносимости алгоритмов.
Но вы полностью игнорируете ключевой аспект промышленной автоматизации — эксплуатацию.
АСУ ТП после ввода — это не «модель» и не «алгоритм».
Это инструмент диагностики и ремонта.
В аварии инженеру не нужно:
анализировать поведение системы,
изучать FBD,
смотреть, как «бегут цифры».
Ему нужно за минуты понять:
где разорвалась логика,
какой сигнал не прошёл,
какой interlock заблокировал запуск.
Именно поэтому во всех зрелых платформах: Siemens, Allen-Bradley и тд.
используются:
LAD как основной инструмент диагностики
декомпозиция на сети / рутины
inline значения сигналов
cross-reference
встроенная диагностика в коде
Это не «олдскул» — это результат десятилетий эксплуатации.
FBD и модели — отличный инструмент проектирования.
Но в реальной аварии они уступают по скорости диагностики в разы.
Генерация кода (особенно в C) дополнительно усугубляет ситуацию:
теряется прозрачность,
код превращается в «чёрный ящик»,
возрастает MTTR.
Именно поэтому подобные подходы почти не используются в массовой промышленной эксплуатации.
Если система не позволяет инженеру за 2–5 минут найти причину остановки — она не пригодна для реального производства, независимо от того, насколько она красива архитектурно.
Ему нужно за минуты понять:
где разорвалась логика,
какой сигнал не прошёл,
какой interlock заблокировал запуск.
Именно поэтому во всех зрелых платформах: Siemens, Allen-Bradley и тд.
используются:
LAD как основной инструмент диагностики
Даввйте все таки разделим задачу на две части 1
1) Где разорвалсь логика и какой interlock заблокировал запуск - это логика работы технологическая (то что определяет разработчик объекта будь это реактор атомный, реактор химический или мехенизьм открытия дверей в электричке) эта логика определяется объектом и должна быть реализована "как есть"
2 ) какой сигнал не прошел - здесь уже присутсвует аппаратура, может провод отошел, может датчик оказал, может на плате ввода вывода скис кондесатор и сгорела микросхема.
Разберем по частям
Для первой части, хотите вы или нет вам нужно понимать логику работы особенное если алгоритмы сложные, здесь возможность посмотреть что происходит очень важна.
Из живых примеров, на АЭС перегрев подпятника насоса зваеден как сигнал предупредеительной сигнализации. Выключение насоса шататно приводит к останову и посадке подпятника - температура повышается, вся система в истерике предупреждает оператора о проблемах. Не пройдя всю цепочку выснить какой датчик нужно отключить из логики обрабоки ошибок при остановки не возможно. Неделю искали причину с привлечение технологов протестантов, завода изготовителя насоса и наладчиков. Будь у них SimInTech пройдя по схемам FBD увидили бы это как раз за минуту. За вторую минут добавили переключатель, который снимает эту сигнализацию при штатном отключении насоса.
2. Диагностирование отказа в железе так же возможно прямо в SimInTech для этого мы просто делаем интерфесные блоки в которых прямо на схеме связываем контакты плат ввода вывода и переменные в базе данных сигналов проекта. Более того у нас по умолчанию каждыйсигнал на входе имеет статус (достоверность) и време измерения. И тогда мы опять таки лекго прямо в SimInTech видим на какой ножке платы или с какого устройства по протоколу мы получили проблемы.
Теперь если у меня ошибка логическая я вижу в диагремме где она произошла и что таам сломалось, я работаю с переменными в программе. Если у меня ошибка аппаратная, и диагностируется аппаратурой я тоеже вижу на такой же диаграмее которая описывает плату ввода вывода
И для упрощения отладки я в блок в SimInTech любую индикацию для отладки. Например зелейную или красную лампочку, что бы точно определить на каком контакте у меня косяк
Что касается LAD, ничто не мешает вам реализаовать логику работы в виде релейных контактов используюя SimInTech в статье как раз пример использования элементов LAD и приведен.
Генерация кода (особенно в C) дополнительно усугубляет ситуацию:
теряется прозрачность,
код превращается в «чёрный ящик»,
возрастает MTTR.
Генерация кода Си это просто внутренний механизьм обеспечивающих кросс платформенность. Си обеспечивает загруску диаграммы из SimInTech куда угодно от микроконтроллеров АРМ до супер ЭВМ без всякого изменения и градацией математической однозначности. Нарисовал один раз и используй везеде и всегда. Для разной аппаратуры используй просто разные компиляторы, которые понимают СИ. А Си понимают примерно все.
Никакая прозрачность не теряется если вы используете SimInTech. То что у вас между Схемой и контроллреом есть байтовая прошивка или бинарный исполняемый файл в системах с ОСРВ, вас не смущает? Тоже теряется прозрачность, на котроллере крутится не совсем то что рисуете в LAD диаграммах средства разработки от Сименса Шнайдреа или Ален бренди.
Ваш ответ подробно описывает, как можно найти информацию о сигнале, но моя исходная мысль была не об этом.
В эксплуатации ключевая задача — не «найти», а максимально быстро диагностировать причину остановки.
Когда линия стоит, инженер не знает:
какой сигнал искать,
где именно проблема,
причина это или следствие.
Поэтому подход «несколько кликов, поиск, база, схема» в реальности не работает как инструмент оперативной диагностики — это уже анализ, а не быстрый поиск причины.
В зрелых системах (Siemens, Allen-Bradley) логика строится иначе:
открываешь сеть (LAD),
и сразу видишь, где разорвалась цепочка,
какой interlock не даёт запуск.
Без переходов, без поиска, без дополнительных действий.
Отдельно про FBD. Его не используют как основной инструмент диагностики не только из-за читаемости, но и по более простой причине — он занимает слишком много места на экране.
В результате:
на одном экране видно мало логики,
сложно охватить цепочку целиком,
приходится постоянно перемещаться и масштабировать.
LAD гораздо компактнее:
на одном экране помещается больше условий,
сразу видна причинно-следственная цепочка,
легче «сканировать» глазами.
Поэтому в реальной эксплуатации LAD выигрывает не теоретически, а именно по скорости работы инженера.
Отдельно про pop-up значения — это ухудшение диагностики.
Любое дополнительное действие:
выбивает из контекста,
замедляет,
мешает видеть общую картину.
Именно поэтому в промышленных системах значения отображаются inline, прямо в логике.
И главное — про MTTR.
Время поиска и устранения неисправности — это не абстрактная метрика.
Это:
прямые потери от простоя,
недовыпуск продукции,
срывы отгрузок.
Разница даже в несколько минут при частых остановках превращается в существенные деньги на масштабе производства.
Поэтому подходы в Siemens и Allen-Bradley сформированы не «по привычке», а как результат десятилетий оптимизации именно под снижение MTTR.
Отдельно важно понимать более широкий контекст.
Попытка ускорить разработку в ущерб эксплуатации — это системная ошибка с точки зрения бизнеса.
Разработка проекта длится условно несколько месяцев (± полгода),
а эксплуатация системы 10–20 лет.
Все потери во время эксплуатации:
из-за долгой диагностики,
сложной логики,
неудобного интерфейса
на порядки превышают стоимость разработки.
Поэтому оптимизация «под скорость разработки» без учёта эксплуатации — это экономически неверное решение.
К сожалению, на практике часто происходит следующее длительное время ремонта списывают на «низкую квалификацию персонала», вместо того чтобы задать вопрос к самой системе.
При этом редко анализируется насколько сама архитектура помогает или мешает диагностике.
В результате появляются решения, которые удобно разрабатывать и демонстрировать, но которыми тяжело пользоваться в реальной эксплуатации.
И ещё один важный момент — те, кто проектирует такие решения, как правило, сами не работают с ними в условиях аварии, когда счёт идёт на минуты и любое лишнее действие критично.
Поэтому попытки объяснить, что такой подход «удобен»,
часто исходят не из опыта эксплуатации, а из опыта разработки.
Ваш подход может быть удобен для разработки и анализа,
но в эксплуатации он увеличивает время диагностики — а значит, увеличивает потери бизнеса.
Ничто не мешает реализовать в SimInTech LAD диаграмму элементы даже приведены в статье.
Задача SimInTech, здесь не сократить сроки разработки а сократить время пусконаладки (и ремнто пригодности). Одним из реальных примеров внедрения, был отказ брать на пусконаладку на объект программиста. Всю настройку делал технолог с SimInTech.
Сама разработка скорее замедляеется поскольку проектант вынужден видеть ошибки до того как их положили в контроллер через 2 года полсе начала проекта.
Технология SimInTech разработана для АЭС, там где один день простоя раектора на 1000 МВТ электрических стоит дороже любых систем возможных протстоев любого конвейера на любом заводе.
Дороже возможно только остановка станка по печати денег.
Вы пишете, что проект в SimInTech сразу используется в PLC как рабочая логика.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос.
Если одна и та же модель является и рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
И здесь возникает ключевая проблема — то, что удобно для моделирования, не равно тому, что удобно для быстрого поиска причины в аварии.
Отдельно про «ничто не мешает сделать LAD».
Важно не то, что можно реализовать,
а то, что является основным способом работы в системе.
В промышленности LAD — это не опция, а фундамент, потому что он:
компактный
позволяет видеть больше логики на экране
даёт мгновенную диагностику без переходов
FBD в этом плане проигрывает именно по плотности информации и скорости восприятия.
Про «технолог делает пусконаладку».
В реальности:
грамотного технолога сейчас найти крайне сложно
технологи не стремятся выполнять задачи АСУ ТП
в аварии работает дежурный инженер, а не автор системы
Поэтому система должна быть удобна любому инженеру, а не только тому, кто её моделировал.
И главное.
Если система действительно сильна в:
моделировании
верификации
отладке
это нормальная и полезная ниша.
Но тогда вопрос — зачем позиционировать её как универсальное решение для эксплуатации, если она оптимизирована под разработку?
В развитых странах это давно поняли, поэтому стандартизируют не только оборудование, но и программное обеспечение PLC:
архитектуру
структуру кода
правила диагностики
именно для того, чтобы:
снизить MTTR
обеспечить предсказуемую поддержку
сделать систему понятной любому инженеру
Подробно это разобрано в моих статьях.
И ещё один важный момент — те, кто проектирует такие решения, как правило, сами не работают с ними в условиях аварии, когда счёт идёт на минуты и любое лишнее действие критично.
Первое внедрение SimInTech это отдел создания АСУ ТП для реакторов типа РБМК полсе Чернобыльской аварии. Все кто ставил задачу разрабочику ПО, непосредственно сидели на обёкте во время ППР и работали с АСУ ТП. Поэтому все идеи наработки и решения непосредсвенно с поля, где счет идет на часы ППР (день простоя - миллиарды), а ошибка это Чернобыль.
Пример с атомной отраслью понятен, но он не отменяет типовую ситуацию в промышленности.
На практике пусконаладчик часто:
работает в жёстких сроках
решает задачу «запустить, чтобы работало»
не занимается поиском оптимального UX диагностики
И важно — его это устраивает не потому, что это лучший вариант, а потому что он не видел других подходов и не сравнивал с лучшими практиками.
Если нет насмотренности:
не возникает требований к компактности
не возникает требований к inline-диагностике
не возникает понимания влияния на MTTR
Человек просто адаптируется к инструменту.
Кроме того, инструмент часто вообще не выбирается инженером.
Решение принимают:
менеджеры
закупка
ИТ/цифровые блоки
И эти решения нередко принимаются:
без глубокого понимания эксплуатации
без учёта MTTR
без сравнения с лучшими практиками
Даже если кто-то из них раньше был инженером,
это не означает, что он остаётся в актуальной практике.
Отдельный момент — кто формирует требования.
Во многих проектах это делает инжиниринговая компания,
у которой KPI:
сдать проект
уложиться в сроки и бюджет
А не:
обеспечить удобство эксплуатации на 10–20 лет
Поэтому вопросы диагностики и MTTR просто не попадают в требования.
Вы пишете, что проект в SimInTech сразу используется в PLC как рабочая логика.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос: если одна и та же модель является рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
И здесь возникает проблема — то, что удобно для моделирования, не равно тому, что удобно для быстрого поиска причины в аварии.
Если инструмент действительно сильный в:
моделировании
верификации
отладке
Но тогда его нужно так и позиционировать —
как специализированный инструмент.
А не как универсальное решение для всего жизненного цикла.
Иначе получается «кухонный комбайн»:
часть функций действительно сильная
часть — слабая
но внедряется сразу всё.
В итоге:
сильные стороны не компенсируют слабые
а слабые проявляются каждый день в эксплуатации
Моя позиция простая:
софт должен делаться для тех, кто с ним реально работает,
и позиционироваться под те задачи, в которых он действительно эффективен.
В массовой промышленности реальность такая:
грамотного технолога найти сложно
технологи не стремятся выполнять задачи АСУ ТП
в аварии работает дежурный инженер, а не автор системы
Система должна быть удобна:
любому инженеру
без предварительного погружения
без «понимания модели»
И именно поэтому в развитых странах стандартизируют PLC-ПО:
структуру
архитектуру
подходы к диагностике
чтобы:
снизить MTTR
сделать систему понятной любому инженеру
обеспечить предсказуемую эксплуатацию
Если система:
требует разбираться
требует переходов
требует времени
она увеличивает MTTR.
А значит — увеличивает прямые потери бизнеса,
независимо от того, насколько она удобна в разработке.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос: если одна и та же модель является рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
Кстати а ведь реально, мы для технолога по сути заменили рисование в визио и описание алгоритмов текста, на модель которая ужен на стадии разработки может запускатся на исполнение. И следовательно он уже на стадии разработки вынужден заниматся отгадкой! Таким образом его стадия разработки технического задания на автоматизацию превращается местами в стадию эксплуатции и диагностики. Если он запускает свой алгоритм на исполнение. Что бы заставить алгоритм работать ему волей не волей приходится влезать в шкуру отладчика исоотвесвенно. Поэтому наш инструменит взлетает у наладчиков как только они ни его попробуют, возращатся назад не хотят.
И важно — его это устраивает не потому, что это лучший вариант, а потому что он не видел других подходов и не сравнивал с лучшими практиками.
Как только я слышу "best practics" моя рука тянется к пистолету. В 99% вам пытаются впарить устаревшее дерьмо динозавра от ведущих вендоров, ни имеющее никаких реальных преимуществ для любого современного предприятия.
LAD это не основа современной автоматизации это рудимент зашоренных мозгов автоматичков со време релейных схем, которым лень включить мозг. И решает только самые примитивыне задачи включения - выключения. Любой современный алгоритм содержит более сложную математику на которой LAD просто не работает.
Ladder notation is best suited to control problems where only binary variables are required and where interlocking and sequencing of binary is the primary control problem. Like all parallel programming languages, the sequential order of operations may be undefined or obscure; logic race conditions are possible which may produce unexpected results. Complex rungs are best broken into several simpler steps to avoid this problem. Some manufacturers avoid this problem by explicitly and completely defining the execution order of a rung, however, programmers may still have problems fully grasping the resulting complex semantics.
Analog quantities and arithmetical operations are clumsy to express in ladder logic and each manufacturer has different ways of extending the notation for these problems. There is usually limited support for arrays and loops, often resulting in duplication of code to express cases that in other languages would call for use of indexed variables.
Если у вас автоматизации уровня вкл - выкл, то LAD если делает хоть что то с регулированием (а сейчас даже унитзы делают с регулирование слива) то FBD
Без переходов, без поиска, без дополнительных действий.
Отдельно про FBD. Его не используют как основной инструмент диагностики не только из-за читаемости, но и по более простой причине — он занимает слишком много места на экране.
В результате:
на одном экране видно мало логики,
сложно охватить цепочку целиком,
приходится постоянно перемещаться и масштабировать.
LAD гораздо компактнее:
на одном экране помещается больше условий,
сразу видна причинно-следственная цепочка,
легче «сканировать» глазами.
Здесь вы путаете интсрументарий для создания программы АСУ ТП SimInTech и конкретнкю архитектуру кокретной системы управления. У нас в SimInTech ничто не мешает вам упаковать ПИД регулятор в субмодель а на верх вывести нужные для быстрой отладки значения, причем определить, что нужно показывать можно и сточки зрения удобства выпуска документации, и с точки зрения удобства отображения в режиме наладки на контролере. И здесь вопрос уже не к технологии VМодельно ориентированного проектирования в SimInTech, а к разработчику. Вот например реальная упаковка сложных алгоритмов в блок, который в режиме отладке, когда SimInTech подключкен у контроллеру выдвет и вунтренние значения в виде числе и цветовую индикацию состояния. Это сделано именно разработчиком, который с десчток лет отлаживает эти алгоритмы и в модели и в контроллере.
В принципе если стоит задача сделать отображение в виде LAD диаграммы, то прямо сверху алгоритма ее можно изобразить ровно так как привыкли отладчик, а значения для отображения состояния барть из FBД диаграммы.
Не Вексельберг, а Вайншток. В Транснефти примерно с года 1980 могли управлять трубопроводом с ЭВМ, СМ2 например, а не так как вы описываете. Ну кто хотел конечно. Обидно за ветеранов АСУ ТП, не с вас все началось, уж извините.
Вайншток это Транснефть эксплуатация после постройки. Мы тут участовавли на этапе проетирования. Курировать проект назначили ВНИИСТ, за нми стоял Вексельберг через Кипрскую контору. Его люди же и набрал кучу атомщиков тогда для присмотра за проектом на стадии проектирования и создания моделей.
Могли - это ключевое слово. А как управляли и как проектировали управление это другое. Возможно но зачем? :))))
«Твоя жалкая частная лавка “ИЧП Напрасный труд” схлопнется в самое ближайшее время.
А что сейчас с SimInTech? Форум мертвый, обновлений с 24го года нет. Таки жива компания? Разработка продукта продолжается или схлопнулась, а разрабы разбежались в VWL и другие дочки?
Кроме того,, не могли бы Вы подробнее рассказать про синтаксис встроенного ЯП, насколько понял это С? А зачем тогда ссылки на ООП? Задвижки, клапана, насосные это всё понятно. А если чуть шаг в сторону, а там прокатный стан тандем с одним референс проектом на несколько ПЛК или проект слежения с жонглированием массивов данных или параметрируемая машина состояний?
Ну и еще 5 копеек в сторону "не моего фаворита" Siemens - COMOS и SIMIT у них продолжает развиваться, т.к. это глабальная история.
Все прото отлично, не знаю кто ходит на формы в 2026 году:
В телеграме пользователей более семи тысяч сообщений
Так что все хорошо у нас с развитием.
Кроме того,, не могли бы Вы подробнее рассказать про синтаксис встроенного ЯП, насколько понял это С?
Нет встроенный язык это скриптовый язык сместь языка матлаба, который сделали сначала с паскалем, поскольку на страте все хотели begin end. В Си происходит генерация кода, для того что бы залить алгоритмы разработанные в SimInTech в виде диаграммы FBD, в лбой современный контроллер или микро контроллер
А зачем тогда ссылки на ООП? Задвижки, клапана, насосные это всё понятно. А если чуть шаг в сторону, а там прокатный стан тандем с одним референс проектом на несколько ПЛК или проект слежения с жонглированием массивов данных или параметрируемая машина состояний?
ООП, это парадигма которую мы в SimInTech реализовали в графическом языке программирования. Чего нет не у одного моделирующего пакета вклюяая прямых конкурентов Simulink и Amesim. Весь цимес в том сто работая с объектам в графической среде, при генерации кода вы получаете читый СИ, соответвующий всем требования безопасности для систем управления выжных для безопасности АЭС.
Любую машину сосотоянию тысячи сигналов. Проект системы автоматического регулирования реакторного отделения как раз содержал порядка 7000 контролируемых параметров с 2016 года Балоковска АЭС работает под управления ПО созданного в SimInTech.
Так что ваш прокатный стан это как стакан семек на сдачу вот вам видео с куском модели АЭС прокатный стан отдыхает
форум!? хахаха. А кто-то говорил что динозавры ковид не переживут. Родной, ты тоже скучаешь по сайтам и форумам? Ничего, чебурнет включат, всё вернется. То ли дело зумеры, они не могут два блока соединить, находят директора миллиардного бизнеса в соцсети, пишут ему, а он ещё им и отвечает. Форум... )
Мне даже ответили, yep.
Давайте по-порядку.
1. Касаемо ЯП, где всё-таки спецификация?
"скриптовый язык сместь языка матлаба, который сделали сначала с паскалем, поскольку на страте все хотели begin end "
2. А в современны APC SimInTech способно? - разделить структуру ПО на ресурсы (Task) и разложить их на ядра?
3. А можно этот dataflow разложить на задачи с разным циклом исполнения? напрммер свободный цикл, статичный цикл и прерывания?
4. Как выполнено взаимодействие с другими ПЛК/APC системы? Какая шина данных для скоростной передачи данных может быть использована и какие протоколы обмена поддерживаются? Есть возможность использования оптической сети аля Reflective memory/ где передача данных исчисляется сотнями наносекунд? Вы не обижайтесь, просто температуры и давление это не прокатка.
5. Про автомат состояний Вы так и не поняли. Не сложно написать программируемый блок машины состояний на 16/32 состояния и перехода для каждого состояния, - сложно сделать удобный генератор для, напрммер, 256 состояний и переходов из каждого состояния на DSL языке. Для этого и есть текстовые языки и описательные генераторы.
6. Кроме того не забывайте про моменты разервирования и их степени R/S (холодный/горячий резерв и его вариации), - где он в SimInTech?
7. Какие используете станции ввода/вывода и какая для них используется ина данных? - ведь важна не только средняя производительность, а именно детерминированность и гарантированное время реакции. У нас ключевыми являются требования жёсткого реального времени. Типичный цикл управления порядка 1 мс включает: дискретизацию аналоговых сигналов, вычисление управляющих воздействий, формирование выходных сигналов, синхронизацию с оборудованием .
1. Касаемо ЯП, где всё-таки спецификация? "скриптовый язык сместь языка матлаба, который сделали сначала с паскалем, поскольку на страте все хотели begin end "
Конечно есть. заходите в справку и читает полное описание языка всех его возможностей и встроенных функций, куча примеров в демо.
А в современны APC SimInTech способно? - разделить структуру ПО на ресурсы (Task) и разложить их на ядра?
Конечно и на ядра и запустить с разным на одном ядре тоже способно. Вообще струкруное моделирование в графическом виде учень удобно в плане разделения большого проекта на малые куски и сборки болшого проекта из малых кусков.
Мы же в статье вытащили кусок большой модели и запустили его на контроллере с заданным тактом
3. А можно этот dataflow разложить на задачи с разным циклом исполнения? напрммер свободный цикл, статичный цикл и прерывания?
Прямо в виде задвали цикл и количество исполнений для системы реального времени
4. Как выполнено взаимодействие с другими ПЛК/APC системы? Какая шина данных для скоростной передачи данных может быть использована и какие протоколы обмена поддерживаются? Есть возможность использования оптической сети аля Reflective memory/ где передача данных исчисляется сотнями наносекунд? Вы не обижайтесь, просто температуры и давление это не прокатка.
Тут вы уже путаете железную реализацию передачи данных (оптику драйвера работы с оптическими преобразователями) и проектирования алгоритма его локиги работы. На стадии проектирования я создаю графически алгоритм где беру одни блоки и соединию их с другим, на этой стадии я указываю что и где я хочу взять какие математические операции совершить и куда отправить результат - это чистая математика схема обработки данных. И я считаю что все происходит мгновенно в пределах одного временного такта.
Потом она переносится на контроллер, где появляются требования к скорости и вычислений и передачи данных. И может оказатся так что моя процедура вычислений вообще не укладывается в заданный временной промежуток. Это задачи проектирования аппаратной части, взять более производительный контроллер, или вернутся в SimInTech и распареллить вычисления или упростить. Обычный процесс разработки систем управления.
По передачи данных и ее скорости это тоже процесс привязки к аппаратному окружению. В SDK для контроллероной части NordWind есть две процедуры readsignal и writesignал (получить значение из памяти контроллера и записать). Если контроллер поддерживает оптическую сеть просто добавляете код передачи по этой сети. Можно в контроллер написать как подпрограмму. А можно код записать прямо в блок на схеме, и пре генерации прошивки он будет добавлен и в исходное Си для сборки прошивки через средства компиляции контроллера. Пользователь ставит блок на схему и получает при генерации все что нужно для передачи данных по любой поддерживаемой сети.
Ну и разумеется стандратные протоколы обмена данным распостраненные уже есть готовые прямо в виде блоков.
5. Про автомат состояний Вы так и не поняли. Не сложно написать программируемый блок машины состояний на 16/32 состояния и перехода для каждого состояния, - сложно сделать удобный генератор для, напрммер, 256 состояний и переходов из каждого состояния на DSL языке. Для этого и есть текстовые языки и описательные генераторы.
Все я прекрасно понял, если бездумно рисвавт все линиями то дейстивиетльно 256 состояний будут выглядеть как паутина и тексто действительно часто быстрее. Но как только вы хотите отладить текст, особенно если там сложная и запутаная логика. То даже паутина с подсветкой заначени и состояния становится более удобной.
Хотя для этого нужно иметь набитую руку и некий опыт. Вот например я как то заморочился и в графическом виде сделел алгоритм поиска оптимального пути. Да пришлось комбинировать скрипт,графический язык, и струкры базы данных. Но оказалось возомжно, хотя мой опыт програмиирования уровня тупого джуна. Просто захотелось нарисовть струкрутным методом логистическую задачу https://habr.com/ru/articles/698694/
А вот тут полотенце текста правил нечеткой логике собрал в читаемую графическую схему и прямо в процессе расчета на схеме можно
6. Кроме того не забывайте про моменты разервирования и их степени R/S (холодный/горячий резерв и его вариации), - где он в SimInTech?
И снова у вас смешивается аппаратура и ПО. С точнки зрения управляюющего ПО резервирование, это задача безударного ввода. Что бы при подключении резервного контроллера, все состояния счетчиков и регуляторов соотвевовали наработанным в данный момент у работающего контроллера. Система безударного ввода резерва у на реализована и уже 10 лет работает на станции. Новый введенный в систему контроллер получает состояний у работающих по подхаватывает управление без проблем.
Но уже аппаратное обеспечение (отключение питание, шины данны и т.п.) за производителем оборудования.
7. Какие используете станции ввода/вывода и какая для них используется ина данных? - ведь важна не только средняя производительность, а именно детерминированность и гарантированное время реакции. У нас ключевыми являются требования жёсткого реального времени. Типичный цикл управления порядка 1 мс включает: дискретизацию аналоговых сигналов, вычисление управляющих воздействий, формирование выходных сигналов, синхронизацию с оборудованием .
Здесь попрос чисто аппаратный, на АЭС используется система реального рвемени QNX (версия КПДА сертефицирования).
SimInTech это среда разработки алгоритмов управления, которая выдает СИ готовый к загрузке в любой контроллер, что его поддерживает. Нет зависимости от поставщика аппаратуры.
NordWind это рантайм для котроллеров под QNX и Linux исполниетельная среда для прокрутки алгоритмов созданны в SimInTech (поэтому если ОСРВ на контроллере позволяет укладыватся в 1 мs то все заработает, если нет то и нет)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
АСУ ТП для нефтепровода 20 лет спустя. Старые программы в новые контролеры