Если вы прикрепите MPU6050 к исправному насосу и к насосу с битым подшипником, разницу в спектре выше 300 Гц вы не измерите. Подшипник качения на 3000 об/мин генерирует дефектные частоты в районе 100-300 Гц, а на 15000 об/мин — выше 1 кГц. MPU6050 их просто не увидит. 10 Гц (каждые 100 мс) — это частота вибрации здания, а не станка. Промышленная вибродиагностика начинается от 1 кГц (для низкооборотных механизмов) до 20-40 кГц (для подшипников качения). Вибродиагностика работает с спектром (БПФ) или огибающей, а не с амплитудой ускорения во времени. Увеличение среднеквадратичного значения (std) в 2 раза может быть из-за проезда погрузчика рядом, а не из-за дефекта сепаратора. Функция if anomaly_score > -0.1: return 2 — это фейк. В предиктивной аналитике нет линейной связи «аберрация -> часы до отказа». Реальный RUL требует либо физической модели износа, либо регрессии на историях смертей. Пора уже экспертам в ИТ и ИБ заниматься ИТ и ИБ, что думаете?
"У нас корпротоивный стандарт Емерсон и Якогава". А далее поскольку с тандарте уже прописана поставщик начинают использовать, то что есть у поставщика в плане типовых решений, а поскольку большой и крупный производитель имеет эти решения, то корпоративный стандарт првращяетс в копию предложений вендра.
Это распространённое заблуждение, но оно путает причину со следствием.
Крупные корпорации приходят к вендору и говорят: «нам надо так». И вендор делает так, как надо.
У GM была отдельная версия RSLogix, которую Rockwell делал специально под них.
У Kraft Foods — стандарт, разработанный Siemens под их задачи.
Отношения с вендорами в Европе и Америке выстроены иначе. GM пришёл к Rockwell и сказал: «сделайте нам контроллер». Те взяли и сделали.
И да, стандарт только частично завязан на железо. Это ПО — его можно адаптировать под любую платформу. К вендору компании привязываются из других соображений, не из-за стандарта.
У меня есть и обратные кейсы в практике. Однажды в разговоре с вендором я спросил: «А вы могли бы поставить другие контроллеры?» На что получил ответ: «Да. Но нас об этом никто не просил».
Всё, собственно. Рынок даёт то, что заказывают. Заказываете копию мануала — получаете копию. Заказываете решение под свои задачи — получаете его.
Менеджеру удбоно, не надо слушать инженеров в поле, он берет лучшее мировае решение и внедряеет "best practic". Инженерам удобно куча готовых элементов и полно знакомых у которых можно спроситить. Собственник переплачивает за бренд вендора, но кого волнуют чужие деньги когда есть отакты поставщика оборудования.
Вот основная проблема этого высказывания: компании не рассказывают про свои реальные best practices. О них можно узнать, только поработав внутри. Про 5S и бережливое производство рассказывают все. А вот как компании реально становятся эффективными — стараются помалкивать.
Так что менеджеры «как-то по-другому определяют, что покупать». И я бы не сказал, что за бренд переплачивают. Это производство. Титулованные бренды титулованы не просто так. Они надёжны, проверены годами эксплуатации. Незнакомый бренд может вылиться в простой и огромные потери. Это называется митигация рисков. И искать инженеров под незнакомые контроллеры — то ещё приключение.
Все изменяется если вдруг нужно сменить поставщика. Например он умер, или внезапно настипило импоротозамещение, или как у немцев было сусидии фраму Меркель выдала с условием, что бы французкую каталическую Dassault заменили на православный протестанстки Siemens, да мало ли случаев когда нужно сменит вендра. И тут выясняется что
И вот здесь как раз раскрывается сильная сторона стандарта. Если он есть — всё становится понятно. Вы просто выбираете другой ПЛК, разрабатываете стандарт под него и стратегию миграции. Львиную долю работ можно автоматизировать — переход становится безболезненным.
То же самое происходит, когда оборудование устаревает. Это не форс-мажор. Были S5 — перешли на S7, потом на TIA Portal. Это нормальный жизненный цикл. А вот когда стандарта нет — каждая линия превращается в самостоятельный пазл.
При этом сами вендры, делают все что бы ПО, типовые решения, и средства разработки не могли быть использованы для оборудования другого поставщика.
Думаю, это нормально. Есть вещь, которую никто не учитывает, говоря про «открытые системы АСУТП». ПЛК — это не только программа. Программу, кстати, повторить можно. И если ПЛК использует стандартный МЭКовский язык — это довольно просто.
Но у ПЛК есть ещё настройки железа. И вот здесь всё ломается. У всех разные протоколы, разные архитектуры ввода-вывода, разная обработка прерываний. Поэтому у каждого вендора — свой софт, чтобы максимально использовать железо. И это не злой умысел, а инженерная реальность.
И да, хотелось бы проговорить ещё одну вещь. Есть вендор, а есть интегратор. Вендор делает железо и даёт инструмент. А вот как этот инструмент использовать — решает интегратор. Здесь и проходит главная развилка. Можно написать чистый, прозрачный, переносимый софт. А можно…
Любое внедрение стандратов должно сокращать затраты сразу, а не через 4 года.
Слишком много эффектов даёт внедрение стандартов. Часть из них работает сразу. Часть имеет отложенный эффект. Это не «или-или», это «и-и».
И ещё один момент, который часто теряют в таких дискуссиях.
Завод — это не проект на год. Это не стартап. И даже не 5-10 лет.
Завод — это стратегическое предприятие с горизонтом планирования 20-30-50 лет. Линии, которые вы запускаете сегодня, будут работать, когда нынешние менеджеры уже уйдут на пенсию. А ПЛК, который вы выбрали, возможно, будет снят с производства ещё при жизни завода.
Если вам нужен только быстрый эффект — вы получите быстрый эффект. Но не получите стратегического.
Вопрос не в том, чтобы выбрать что-то одно. Вопрос в том, чтобы не мешать быстрым эффектам убивать долгосрочные, и наоборот.
Стандарт — это инструмент, который позволяет заводу думать на десятилетия вперёд, не проигрывая в текущей эффективности. Тот, кто этого не понимает, строит не завод, а дорогой конструктор «собери сам».
Пример с атомной отраслью понятен, но он не отменяет типовую ситуацию в промышленности.
На практике пусконаладчик часто:
работает в жёстких сроках
решает задачу «запустить, чтобы работало»
не занимается поиском оптимального UX диагностики
И важно — его это устраивает не потому, что это лучший вариант, а потому что он не видел других подходов и не сравнивал с лучшими практиками.
Если нет насмотренности:
не возникает требований к компактности
не возникает требований к inline-диагностике
не возникает понимания влияния на MTTR
Человек просто адаптируется к инструменту.
Кроме того, инструмент часто вообще не выбирается инженером.
Решение принимают:
менеджеры
закупка
ИТ/цифровые блоки
И эти решения нередко принимаются:
без глубокого понимания эксплуатации
без учёта MTTR
без сравнения с лучшими практиками
Даже если кто-то из них раньше был инженером,
это не означает, что он остаётся в актуальной практике.
Отдельный момент — кто формирует требования.
Во многих проектах это делает инжиниринговая компания,
у которой KPI:
сдать проект
уложиться в сроки и бюджет
А не:
обеспечить удобство эксплуатации на 10–20 лет
Поэтому вопросы диагностики и MTTR просто не попадают в требования.
Вы пишете, что проект в SimInTech сразу используется в PLC как рабочая логика.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос: если одна и та же модель является рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
И здесь возникает проблема — то, что удобно для моделирования, не равно тому, что удобно для быстрого поиска причины в аварии.
Если инструмент действительно сильный в:
моделировании
верификации
отладке
Но тогда его нужно так и позиционировать —
как специализированный инструмент.
А не как универсальное решение для всего жизненного цикла.
Иначе получается «кухонный комбайн»:
часть функций действительно сильная
часть — слабая
но внедряется сразу всё.
В итоге:
сильные стороны не компенсируют слабые
а слабые проявляются каждый день в эксплуатации
Моя позиция простая:
софт должен делаться для тех, кто с ним реально работает,
и позиционироваться под те задачи, в которых он действительно эффективен.
В массовой промышленности реальность такая:
грамотного технолога найти сложно
технологи не стремятся выполнять задачи АСУ ТП
в аварии работает дежурный инженер, а не автор системы
Система должна быть удобна:
любому инженеру
без предварительного погружения
без «понимания модели»
И именно поэтому в развитых странах стандартизируют PLC-ПО:
структуру
архитектуру
подходы к диагностике
чтобы:
снизить MTTR
сделать систему понятной любому инженеру
обеспечить предсказуемую эксплуатацию
Если система:
требует разбираться
требует переходов
требует времени
она увеличивает MTTR.
А значит — увеличивает прямые потери бизнеса,
независимо от того, насколько она удобна в разработке.
Вы пишете, что проект в SimInTech сразу используется в PLC как рабочая логика.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос.
Если одна и та же модель является и рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
И здесь возникает ключевая проблема — то, что удобно для моделирования, не равно тому, что удобно для быстрого поиска причины в аварии.
Отдельно про «ничто не мешает сделать LAD».
Важно не то, что можно реализовать,
а то, что является основным способом работы в системе.
В промышленности LAD — это не опция, а фундамент, потому что он:
компактный
позволяет видеть больше логики на экране
даёт мгновенную диагностику без переходов
FBD в этом плане проигрывает именно по плотности информации и скорости восприятия.
Про «технолог делает пусконаладку».
В реальности:
грамотного технолога сейчас найти крайне сложно
технологи не стремятся выполнять задачи АСУ ТП
в аварии работает дежурный инженер, а не автор системы
Поэтому система должна быть удобна любому инженеру, а не только тому, кто её моделировал.
И главное.
Если система действительно сильна в:
моделировании
верификации
отладке
это нормальная и полезная ниша.
Но тогда вопрос — зачем позиционировать её как универсальное решение для эксплуатации, если она оптимизирована под разработку?
В развитых странах это давно поняли, поэтому стандартизируют не только оборудование, но и программное обеспечение PLC:
Ваш ответ подробно описывает, как можно найти информацию о сигнале, но моя исходная мысль была не об этом.
В эксплуатации ключевая задача — не «найти», а максимально быстро диагностировать причину остановки.
Когда линия стоит, инженер не знает:
какой сигнал искать,
где именно проблема,
причина это или следствие.
Поэтому подход «несколько кликов, поиск, база, схема» в реальности не работает как инструмент оперативной диагностики — это уже анализ, а не быстрый поиск причины.
В зрелых системах (Siemens, Allen-Bradley) логика строится иначе:
открываешь сеть (LAD),
и сразу видишь, где разорвалась цепочка,
какой interlock не даёт запуск.
Без переходов, без поиска, без дополнительных действий.
Отдельно про FBD. Его не используют как основной инструмент диагностики не только из-за читаемости, но и по более простой причине — он занимает слишком много места на экране.
В результате:
на одном экране видно мало логики,
сложно охватить цепочку целиком,
приходится постоянно перемещаться и масштабировать.
LAD гораздо компактнее:
на одном экране помещается больше условий,
сразу видна причинно-следственная цепочка,
легче «сканировать» глазами.
Поэтому в реальной эксплуатации LAD выигрывает не теоретически, а именно по скорости работы инженера.
Отдельно про pop-up значения — это ухудшение диагностики.
Любое дополнительное действие:
выбивает из контекста,
замедляет,
мешает видеть общую картину.
Именно поэтому в промышленных системах значения отображаются inline, прямо в логике.
И главное — про MTTR.
Время поиска и устранения неисправности — это не абстрактная метрика.
Это:
прямые потери от простоя,
недовыпуск продукции,
срывы отгрузок.
Разница даже в несколько минут при частых остановках превращается в существенные деньги на масштабе производства.
Поэтому подходы в Siemens и Allen-Bradley сформированы не «по привычке», а как результат десятилетий оптимизации именно под снижение MTTR.
Отдельно важно понимать более широкий контекст.
Попытка ускорить разработку в ущерб эксплуатации — это системная ошибка с точки зрения бизнеса.
Разработка проекта длится условно несколько месяцев (± полгода),
а эксплуатация системы 10–20 лет.
Все потери во время эксплуатации:
из-за долгой диагностики,
сложной логики,
неудобного интерфейса
на порядки превышают стоимость разработки.
Поэтому оптимизация «под скорость разработки» без учёта эксплуатации — это экономически неверное решение.
К сожалению, на практике часто происходит следующее длительное время ремонта списывают на «низкую квалификацию персонала», вместо того чтобы задать вопрос к самой системе.
При этом редко анализируется насколько сама архитектура помогает или мешает диагностике.
В результате появляются решения, которые удобно разрабатывать и демонстрировать, но которыми тяжело пользоваться в реальной эксплуатации.
И ещё один важный момент — те, кто проектирует такие решения, как правило, сами не работают с ними в условиях аварии, когда счёт идёт на минуты и любое лишнее действие критично.
Поэтому попытки объяснить, что такой подход «удобен»,
часто исходят не из опыта эксплуатации, а из опыта разработки.
Ваш подход может быть удобен для разработки и анализа,
но в эксплуатации он увеличивает время диагностики — а значит, увеличивает потери бизнеса.
Ваш подход действительно интересен с точки зрения разработки и переносимости алгоритмов.
Но вы полностью игнорируете ключевой аспект промышленной автоматизации — эксплуатацию.
АСУ ТП после ввода — это не «модель» и не «алгоритм».
Это инструмент диагностики и ремонта.
В аварии инженеру не нужно:
анализировать поведение системы,
изучать FBD,
смотреть, как «бегут цифры».
Ему нужно за минуты понять:
где разорвалась логика,
какой сигнал не прошёл,
какой interlock заблокировал запуск.
Именно поэтому во всех зрелых платформах: Siemens, Allen-Bradley и тд.
используются:
LAD как основной инструмент диагностики
декомпозиция на сети / рутины
inline значения сигналов
cross-reference
встроенная диагностика в коде
Это не «олдскул» — это результат десятилетий эксплуатации.
FBD и модели — отличный инструмент проектирования.
Но в реальной аварии они уступают по скорости диагностики в разы.
Генерация кода (особенно в C) дополнительно усугубляет ситуацию:
теряется прозрачность,
код превращается в «чёрный ящик»,
возрастает MTTR.
Именно поэтому подобные подходы почти не используются в массовой промышленной эксплуатации.
Если система не позволяет инженеру за 2–5 минут найти причину остановки — она не пригодна для реального производства, независимо от того, насколько она красива архитектурно.
По поводу «избыточной жёсткости» и «бюрократизации» — вы абсолютно правы. В тексте я лишь обозначил направление, чтобы не перегружать. Но тема важнейшая, поэтому давайте конкретизирую практические механизмы, которые помогают избегать «окаменения» стандарта. Ревью — это не переписывание документа «под настроение», а цикл, встроенный в эксплуатацию. Хорошо работает такой подход: • Фиксированный период (например, раз в 12–18 месяцев). • Обязательный сбор обратной связи «снизу»: от инженеров эксплуатации и пусконаладки. • Принцип «изменения только ради эффекта»: если правка не снижает MTTR (Среднее время ремонта), не упрощает диагностику или не страхует от ошибок — она отклоняется. Важно смотреть не только на то, что добавить, но и на то, что удалить или упростить. Разделение на «Жёсткое ядро» и «Адаптивную периферию». Структурно делим стандарт на две части: • Ядро: архитектура, именование, безопасность (меняется крайне редко). • Адаптивная часть: шаблоны, библиотеки, примеры реализации (здесь допустима эволюция). Это снимает бюрократию: инженеру не нужно согласовывать каждое улучшение кода, если он работает в рамках «адаптивного слоя». Принцип «стандарт не должен мешать при авариях». Главный маркер плохой бюрократии — когда стандарт мешает быстро поднять «упавшую» линию. В зрелых системах стандарт проверяется на сценариях нештатной эксплуатации (аварии, частичные отказы). Если выясняется, что требования стандарта затягивают поиск неисправности или блокируют временные обходные решения— это прямой кандидат на немедленный пересмотр. Сознательное ограничение детализации. Стандарт отвечает на вопрос «Как система должна вести себя и взаимодействовать», но не диктует «как писать каждую строку кода». Микроменеджмент в коде всегда ведет к формализму. По поводу сокращений — замечание абсолютно справедливое, принято. В следующий раз обязательно добавлю глоссарий или буду внимательнее к расшифровке.
Вы правы насчёт документирования блоков — это основа. Но корпоративный стандарт — это и есть системный способ сделать так, чтобы сотни этих задокументированных блоков собирались в предсказуемое целое, а не в хаос. Это «генплан», а не только «кирпичи».
По поводу вендорозависимости — здесь ключевое заблуждение. Хороший стандарт фиксирует не бренд ПЛК, а архитектуру, интерфейсы, модели данных и протоколы. Именно это и даёт свободу. Если завтра нужно сменить вендора, вы адаптируете под новую платформу не 1000 разрозненных проектов, а одну централизованную библиотеку и шаблоны. Это сложная, но управляемая задача.
Без стандарта каждая программа уникальна. Миграция такого «зоопарка» в условиях санкций будет астрономически дорогой и рискованной. Стандарт же превращает вашу автоматизацию в переносимый актив, снижая риски, а не увеличивая их.
Стандартизация — это стратегия независимости, а не зацикленности.
Вам надо задуматься над тем что вы только что написали =) Может пора, что то менять, а то так и будем на жигулях ездить. Это кстати видно из ваших рамок в документации.
Вы правы, SimInTech — отличный инструмент для проектанта. Но мой тезис не о возможностях анализа, а о рабочих инструментах ремонта в условиях аварии.
Инженеру на производстве недостаточно «открыть диаграмму и добайтать». Ему нужен инструмент для действий, причём в формате, который он знает:
Диагностика: Быстро найти, какая именно ветка логики сработала или не сработала. Для этого нужны не графы в SimInTech, а триггеры, трассировка, статусы в реальном времени в том же LAD, который он видит на инженерной станции.
Экстренная модификация: Иногда нужно быстро дописать сервисный код (логирование, обход сломанного датчика, временный алгоритм пуска), чтобы запустить оборудование до прибытия запчастей. Для этого нужен доступ к программе ПЛК в родном, понятном ему языке, а не в сгенерированном C или блок-схемах SimInTech.
Языковой барьер: С — это язык системного программиста, а не инженера-наладчика. На производстве живут МЭКовские языки (LAD, FBD, ST), и LAD — король для визуальной диагностики. Инженеров, знающих С на уровне чтения чужого сгенерированного кода под давлением, — единицы.
Пример: аварийный дизель-генератор на АЭС. Время на поиск — минуты. Нет времени «изучать и повторять» алгоритм в SimInTech. Нужно открыть программу ПЛК этого дизеля, на родном языке, увидеть, почему не прошёл сигнал запуска, и, возможно, временно заблокировать ложный сигнал от неисправного датчика давления масла — чтобы обеспечить энергобезопасность сейчас.
Именно об этом я и говорю: сквозное проектирование должно быть «сквозным» и для эксплуатации. Генерация кода на С — это тупик для ремонтопригодности. Идеальная платформа должна позволять:
Генерировать/анализировать логику в высокоуровневых средах (SimInTech).
Предоставлять для эксплуатации ту же самую логику в нативных МЭКовских языках с возможностью безопасной временной модификации и продвинутой диагностики.
Иначе мы получаем идеально смоделированную систему, которая в момент реальной поломки превращается для персонала в непрозрачную магию, потому что ключ к пониманию (родная программа ПЛК) заменён на шифр (бинарник на С).
Отличный и подробный материал про сквозное проектирование. Однако, как всегда, в погоне за технологичностью и красотой для интегратора забывается ключевой аспект — ремонтопригодность и удобство для службы эксплуатации. Внедрение языков типа С и сложных модульных сред (NordWind) без учета реальных навыков и практик персонала, который будет обслуживать систему 20-30 лет, — это создание будущей "черной коробки". Прежде чем тратить годы на создание такой платформы, нужно было провести годы в беседах с наладчиками, дежурными инженерами и ремонтниками. Спросить: "Как вы ищете поломку? Что вам нужно видеть в первую очередь при аварии? Какие инструменты вы реально умеете и готовы использовать?". Иначе мы получаем идеальную систему, отлаженную на модели, но абсолютно хрупкую и непонятную в реальной жизни. Интегратор уйдет через полгода с готовым проектом, а завод останется с загадкой на долгие десятилетия.
Вы абсолютно правы, и в вашем примере хорошо видна правильная, дисциплинированная работа на уровне отдельного проекта или объекта (подстанции).
Действительно, наличие полного комплекта проектной и исполнительной документации, листингов и открытого проекта — это необходимый минимум для ввода в эксплуатацию и основа для дальнейшего обслуживания. Вы описываете правильный и грамотный процесс сдачи одного проекта.
О чем я говорю в статье? О проблеме, которая возникает на уровень выше — на уровне не одного проекта, а десятков и сотней проектов в рамках одного предприятия или холдинга.
Проблема не в том, что нет документации по конкретной подстанции. Проблема в том, что на 10 разных подстанциях (или заводских линиях), даже построенных по одним ГОСТам и с одинаковой документацией, сама система устроена по-разному:
Логика одинаковой операции «включить выключатель» может быть реализована в 10 разных программных блоках с 10 разными названиями.
Диагностические сообщения об одной и той же неисправности будут сформулированы и выведены на SCADA 10 разными способами.
Архитектура тегов, структура программы, организация базы данных — уникальны для каждого интегратора.
В вашем случае эксплуатационщик, изучив документацию, становится экспертом по конкретной подстанции №5. В ситуации же, которую описываю я, чтобы стать экспертом по заводу, ему нужно изучить 50 уникальных проектов, как 50 разных книг, написанных на диалектах одного языка.
Таким образом, ваша практика решает задачу: «Мы знаем, как устроена эта система». Задача корпоративного стандарта — решить проблему: «Все наши системы устроены единообразно, поэтому мы знаем, как устроена любая из них».
Это позволяет:
Тиражировать решения и знания. Найденное улучшение на подстанции №1 можно безопасно внедрить на подстанциях №2-10, потому что их код и логика структурированы одинаково.
Мгновенно адаптировать персонал. Инженер, освоившийся на одной подстанции, уже на 90% готов работать на любой другой, потому что не нужно заново изучать архитектуру.
Менять подрядчиков без потери управляемости. Новый интегратор получает не просто ТЗ, а архитектурный регламент, который гарантирует, что его проект войдет в общую экосистему, а не станет очередным «уникальным островом».
Итог: Вы описываете качественное выполнение проекта — и это отлично. Я же говорю о системном управлении портфелем проектов как единым активом на протяжении десятилетий. Первое — необходимое условие. Второе — следующий уровень зрелости, который радикально снижает совокупную стоимость владения. Спасибо, что дали возможность это уточнить!
Apoheliy, спасибо! Вы задели важный момент. Наше недопонимание, кажется, кроется в самой сути объектов обсуждения.
Вы говорите о софте — виртуальном продукте, который не имеет физического износа. Его не «чинят» в привычном смысле, а обновляют или исправляют ошибки. Требовать менять его архитектуру постфактум действительно может быть странно.
Но я говорю о физическом заводе. АСУ ТП здесь — это не самостоятельный продукт, а инструмент для обслуживания и ремонта постоянно ломающегося оборудования. Механизмы изнашиваются, датчики загрязняются, а так же не исключены ошибки в коде ПЛК. Код ПЛК — это в первую очередь диагностическая карта для инженера, который бежит на линию с мультиметром и программатором, чтобы определить в чем проблема. А модернизацию на заводе иногда приходится делать внезапно ночью из за того, нужного оборудования нет на складе для простой замены, а линию запускать надо.
Поэтому стандарт кодирования — это вопрос безопасности и экономики. Если код написан «как Бог на душу положит», инженер теряет часы на поиск причины, а завод теряет сотни тысяч рублей в час простоя. Нам не нужно менять «ядро» — нам нужно, чтобы инженеру требовалось минимальное количество времени на определение проблемы.
Спасибо за дискуссию! Она хорошо показывает, насколько специфичны требования к системам, которые работают не в идеальном мире битов, а в суровой реальности железа, масла и вибрации.
Производитель действительно может делать продукт как угодно.
Вопрос не в этом.
Вопрос в том, готово ли предприятие жить с последствиями этого выбора десятилетиями.
Если у заказчика нет собственного стандарта, то:
архитектура системы полностью определяется вендором или интегратором;
внутренняя логика проекта становится уникальной;
модернизация возможна только через того же производителя или его партнёров;
выход вендора автоматически означает потерю поддержки и знаний.
2022 год наглядно показал, что сценарий «производитель всегда будет рядом» — это иллюзия.
В один момент можно остаться:
без обновлений,
без лицензий,
без поддержки,
без возможности легальной модернизации.
И тогда остаётся два варианта:
ничего не трогать, пока система окончательно не устареет;
полный реинжиниринг за большие деньги и с высокими рисками.
Корпоративный стандарт не гарантирует, что вендор будет сотрудничать.
Но он гарантирует другое:
если вендор уходит, предприятие остаётся хозяином своей архитектуры.
Стандарт:
фиксирует структуру системы;
отделяет логику управления от конкретного продукта;
делает код, диагностику и документацию воспроизводимыми;
позволяет модернизировать систему частями, а не «сносить всё».
Да, возможна ситуация, когда производитель скажет: «мы так делать не будем».
Это честная ситуация, и тогда заказчик принимает осознанное решение — принимать продукт как есть или искать альтернативу.
Хуже другое: когда стандарта нет, заказчик даже не формулирует требований, а значит автоматически принимает любые ограничения вендора — зачастую не осознавая их до момента кризиса.
Стандарт — это не попытка заставить производителя «делать по-своему».
Это способ не оказаться заложником чужих решений, когда выбора уже нет.
И именно в российских реалиях это перестало быть теорией.
И здесь как раз показательная история из практики.
На одном из заводов установили оборудование с ПЛК вендора, которого раньше на предприятии не было. В результате:
увеличился склад запасных частей;
инженерам пришлось изучать новый софт и среду разработки;
понадобилось покупать дополнительные лицензии;
усложнилась поддержка и сопровождение.
Когда я разговаривал с производителем я задал логичный вопрос:
«А можно было сделать оборудование на ПЛК, которые уже используются на заводе?»
ответ был предельно честный:
«Да, конечно. Просто вы нас об этом не просили.»
И это ключевой момент.
Производитель и интегратор не обязаны угадывать предпочтения заказчика.
Если у заказчика нет стандарта, значит:
нет требований к платформам;
нет ограничений по архитектуре;
нет критериев унификации.
В этом случае подрядчик выбирает то, что удобно ему — и формально он прав.
Корпоративный стандарт нужен именно для того, чтобы такие требования были сформулированы заранее:
какие платформы допустимы;
где возможны отклонения и на каких условиях;
какие последствия несёт выбор нестандартных решений.
Без стандарта предприятие платит не только за оборудование, но и за:
Это распространённое мнение, и именно оно на практике и приводит к тем проблемам, о которых говорится в статье. Эксплуатационная документация сама по себе не является стандартом. Она описывает конкретную реализацию, но не задаёт правил, по которым эта реализация должна быть построена. В результате каждая новая АСУ ТП снова оказывается уникальной — с собственной архитектурой, логикой, подходом к диагностике и сопровождению. Корпоративный стандарт АСУ ТП не подменяет документацию и не конкурирует с ней. Он отвечает на другие вопросы: как в принципе строятся системы управления на предприятии; где проходят границы ответственности; как организована диагностика; как должна выглядеть структура программ и данных; как обеспечивается воспроизводимость решений. Без этого эксплуатационная документация всегда остаётся описанием частного случая, а не инструментом управления системой в масштабе предприятия. Что касается «слишком общего» или «слишком частного» — именно поэтому рабочие стандарты и строятся модульно: есть общий архитектурный уровень (применимый ко всем объектам), а есть частные модули под типовое оборудование и процессы. Так работают промышленные корпорации с десятками и сотнями предприятий. Вот мои статьи на эту тему: https://habr.com/ru/articles/956460/https://habr.com/ru/articles/963160/ Если ограничиться только документацией, предприятие каждый раз платит заново: за поиск уже известных проблем, за обучение новых инженеров, за зависимость от конкретных исполнителей, за невозможность тиражировать решения. Документация описывает то, что получилось. Стандарт определяет то, как это должно получаться. Именно эту разницу и важно не терять.
Если вы прикрепите MPU6050 к исправному насосу и к насосу с битым подшипником, разницу в спектре выше 300 Гц вы не измерите. Подшипник качения на 3000 об/мин генерирует дефектные частоты в районе 100-300 Гц, а на 15000 об/мин — выше 1 кГц. MPU6050 их просто не увидит. 10 Гц (каждые 100 мс) — это частота вибрации здания, а не станка. Промышленная вибродиагностика начинается от 1 кГц (для низкооборотных механизмов) до 20-40 кГц (для подшипников качения). Вибродиагностика работает с спектром (БПФ) или огибающей, а не с амплитудой ускорения во времени. Увеличение среднеквадратичного значения (std) в 2 раза может быть из-за проезда погрузчика рядом, а не из-за дефекта сепаратора. Функция if anomaly_score > -0.1: return 2 — это фейк. В предиктивной аналитике нет линейной связи «аберрация -> часы до отказа». Реальный RUL требует либо физической модели износа, либо регрессии на историях смертей. Пора уже экспертам в ИТ и ИБ заниматься ИТ и ИБ, что думаете?
Это распространённое заблуждение, но оно путает причину со следствием.
Крупные корпорации приходят к вендору и говорят: «нам надо так». И вендор делает так, как надо.
У GM была отдельная версия RSLogix, которую Rockwell делал специально под них.
У Kraft Foods — стандарт, разработанный Siemens под их задачи.
Отношения с вендорами в Европе и Америке выстроены иначе. GM пришёл к Rockwell и сказал: «сделайте нам контроллер». Те взяли и сделали.
И да, стандарт только частично завязан на железо. Это ПО — его можно адаптировать под любую платформу. К вендору компании привязываются из других соображений, не из-за стандарта.
У меня есть и обратные кейсы в практике. Однажды в разговоре с вендором я спросил: «А вы могли бы поставить другие контроллеры?» На что получил ответ: «Да. Но нас об этом никто не просил».
Всё, собственно. Рынок даёт то, что заказывают. Заказываете копию мануала — получаете копию. Заказываете решение под свои задачи — получаете его.
Вот основная проблема этого высказывания: компании не рассказывают про свои реальные best practices. О них можно узнать, только поработав внутри. Про 5S и бережливое производство рассказывают все. А вот как компании реально становятся эффективными — стараются помалкивать.
Так что менеджеры «как-то по-другому определяют, что покупать». И я бы не сказал, что за бренд переплачивают. Это производство. Титулованные бренды титулованы не просто так. Они надёжны, проверены годами эксплуатации. Незнакомый бренд может вылиться в простой и огромные потери. Это называется митигация рисков. И искать инженеров под незнакомые контроллеры — то ещё приключение.
И вот здесь как раз раскрывается сильная сторона стандарта. Если он есть — всё становится понятно. Вы просто выбираете другой ПЛК, разрабатываете стандарт под него и стратегию миграции. Львиную долю работ можно автоматизировать — переход становится безболезненным.
То же самое происходит, когда оборудование устаревает. Это не форс-мажор. Были S5 — перешли на S7, потом на TIA Portal. Это нормальный жизненный цикл. А вот когда стандарта нет — каждая линия превращается в самостоятельный пазл.
Думаю, это нормально. Есть вещь, которую никто не учитывает, говоря про «открытые системы АСУТП». ПЛК — это не только программа. Программу, кстати, повторить можно. И если ПЛК использует стандартный МЭКовский язык — это довольно просто.
Но у ПЛК есть ещё настройки железа. И вот здесь всё ломается. У всех разные протоколы, разные архитектуры ввода-вывода, разная обработка прерываний. Поэтому у каждого вендора — свой софт, чтобы максимально использовать железо. И это не злой умысел, а инженерная реальность.
И да, хотелось бы проговорить ещё одну вещь. Есть вендор, а есть интегратор. Вендор делает железо и даёт инструмент. А вот как этот инструмент использовать — решает интегратор. Здесь и проходит главная развилка. Можно написать чистый, прозрачный, переносимый софт. А можно…
Слишком много эффектов даёт внедрение стандартов. Часть из них работает сразу. Часть имеет отложенный эффект. Это не «или-или», это «и-и».
И ещё один момент, который часто теряют в таких дискуссиях.
Завод — это не проект на год. Это не стартап. И даже не 5-10 лет.
Завод — это стратегическое предприятие с горизонтом планирования 20-30-50 лет. Линии, которые вы запускаете сегодня, будут работать, когда нынешние менеджеры уже уйдут на пенсию. А ПЛК, который вы выбрали, возможно, будет снят с производства ещё при жизни завода.
Если вам нужен только быстрый эффект — вы получите быстрый эффект. Но не получите стратегического.
Вопрос не в том, чтобы выбрать что-то одно. Вопрос в том, чтобы не мешать быстрым эффектам убивать долгосрочные, и наоборот.
Стандарт — это инструмент, который позволяет заводу думать на десятилетия вперёд, не проигрывая в текущей эффективности. Тот, кто этого не понимает, строит не завод, а дорогой конструктор «собери сам».
Пример с атомной отраслью понятен, но он не отменяет типовую ситуацию в промышленности.
На практике пусконаладчик часто:
работает в жёстких сроках
решает задачу «запустить, чтобы работало»
не занимается поиском оптимального UX диагностики
И важно — его это устраивает не потому, что это лучший вариант, а потому что он не видел других подходов и не сравнивал с лучшими практиками.
Если нет насмотренности:
не возникает требований к компактности
не возникает требований к inline-диагностике
не возникает понимания влияния на MTTR
Человек просто адаптируется к инструменту.
Кроме того, инструмент часто вообще не выбирается инженером.
Решение принимают:
менеджеры
закупка
ИТ/цифровые блоки
И эти решения нередко принимаются:
без глубокого понимания эксплуатации
без учёта MTTR
без сравнения с лучшими практиками
Даже если кто-то из них раньше был инженером,
это не означает, что он остаётся в актуальной практике.
Отдельный момент — кто формирует требования.
Во многих проектах это делает инжиниринговая компания,
у которой KPI:
сдать проект
уложиться в сроки и бюджет
А не:
обеспечить удобство эксплуатации на 10–20 лет
Поэтому вопросы диагностики и MTTR просто не попадают в требования.
Вы пишете, что проект в SimInTech сразу используется в PLC как рабочая логика.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос: если одна и та же модель является рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
И здесь возникает проблема — то, что удобно для моделирования, не равно тому, что удобно для быстрого поиска причины в аварии.
Если инструмент действительно сильный в:
моделировании
верификации
отладке
Но тогда его нужно так и позиционировать —
как специализированный инструмент.
А не как универсальное решение для всего жизненного цикла.
Иначе получается «кухонный комбайн»:
часть функций действительно сильная
часть — слабая
но внедряется сразу всё.
В итоге:
сильные стороны не компенсируют слабые
а слабые проявляются каждый день в эксплуатации
Моя позиция простая:
софт должен делаться для тех, кто с ним реально работает,
и позиционироваться под те задачи, в которых он действительно эффективен.
В массовой промышленности реальность такая:
грамотного технолога найти сложно
технологи не стремятся выполнять задачи АСУ ТП
в аварии работает дежурный инженер, а не автор системы
Система должна быть удобна:
любому инженеру
без предварительного погружения
без «понимания модели»
И именно поэтому в развитых странах стандартизируют PLC-ПО:
структуру
архитектуру
подходы к диагностике
чтобы:
снизить MTTR
сделать систему понятной любому инженеру
обеспечить предсказуемую эксплуатацию
Если система:
требует разбираться
требует переходов
требует времени
она увеличивает MTTR.
А значит — увеличивает прямые потери бизнеса,
независимо от того, насколько она удобна в разработке.
Вы пишете, что проект в SimInTech сразу используется в PLC как рабочая логика.
То есть по сути предлагается подход, где:
модель = разработка
модель = документация
модель = исполняемый код
Это интересная концепция, но она только усиливает основной вопрос.
Если одна и та же модель является и рабочей логикой, то требования к ней должны определяться не удобством разработки, а удобством эксплуатации и диагностики.
И здесь возникает ключевая проблема — то, что удобно для моделирования, не равно тому, что удобно для быстрого поиска причины в аварии.
Отдельно про «ничто не мешает сделать LAD».
Важно не то, что можно реализовать,
а то, что является основным способом работы в системе.
В промышленности LAD — это не опция, а фундамент, потому что он:
компактный
позволяет видеть больше логики на экране
даёт мгновенную диагностику без переходов
FBD в этом плане проигрывает именно по плотности информации и скорости восприятия.
Про «технолог делает пусконаладку».
В реальности:
грамотного технолога сейчас найти крайне сложно
технологи не стремятся выполнять задачи АСУ ТП
в аварии работает дежурный инженер, а не автор системы
Поэтому система должна быть удобна любому инженеру, а не только тому, кто её моделировал.
И главное.
Если система действительно сильна в:
моделировании
верификации
отладке
это нормальная и полезная ниша.
Но тогда вопрос — зачем позиционировать её как универсальное решение для эксплуатации, если она оптимизирована под разработку?
В развитых странах это давно поняли, поэтому стандартизируют не только оборудование, но и программное обеспечение PLC:
архитектуру
структуру кода
правила диагностики
именно для того, чтобы:
снизить MTTR
обеспечить предсказуемую поддержку
сделать систему понятной любому инженеру
Подробно это разобрано в моих статьях.
Ваш ответ подробно описывает, как можно найти информацию о сигнале, но моя исходная мысль была не об этом.
В эксплуатации ключевая задача — не «найти», а максимально быстро диагностировать причину остановки.
Когда линия стоит, инженер не знает:
какой сигнал искать,
где именно проблема,
причина это или следствие.
Поэтому подход «несколько кликов, поиск, база, схема» в реальности не работает как инструмент оперативной диагностики — это уже анализ, а не быстрый поиск причины.
В зрелых системах (Siemens, Allen-Bradley) логика строится иначе:
открываешь сеть (LAD),
и сразу видишь, где разорвалась цепочка,
какой interlock не даёт запуск.
Без переходов, без поиска, без дополнительных действий.
Отдельно про FBD. Его не используют как основной инструмент диагностики не только из-за читаемости, но и по более простой причине — он занимает слишком много места на экране.
В результате:
на одном экране видно мало логики,
сложно охватить цепочку целиком,
приходится постоянно перемещаться и масштабировать.
LAD гораздо компактнее:
на одном экране помещается больше условий,
сразу видна причинно-следственная цепочка,
легче «сканировать» глазами.
Поэтому в реальной эксплуатации LAD выигрывает не теоретически, а именно по скорости работы инженера.
Отдельно про pop-up значения — это ухудшение диагностики.
Любое дополнительное действие:
выбивает из контекста,
замедляет,
мешает видеть общую картину.
Именно поэтому в промышленных системах значения отображаются inline, прямо в логике.
И главное — про MTTR.
Время поиска и устранения неисправности — это не абстрактная метрика.
Это:
прямые потери от простоя,
недовыпуск продукции,
срывы отгрузок.
Разница даже в несколько минут при частых остановках превращается в существенные деньги на масштабе производства.
Поэтому подходы в Siemens и Allen-Bradley сформированы не «по привычке», а как результат десятилетий оптимизации именно под снижение MTTR.
Отдельно важно понимать более широкий контекст.
Попытка ускорить разработку в ущерб эксплуатации — это системная ошибка с точки зрения бизнеса.
Разработка проекта длится условно несколько месяцев (± полгода),
а эксплуатация системы 10–20 лет.
Все потери во время эксплуатации:
из-за долгой диагностики,
сложной логики,
неудобного интерфейса
на порядки превышают стоимость разработки.
Поэтому оптимизация «под скорость разработки» без учёта эксплуатации — это экономически неверное решение.
К сожалению, на практике часто происходит следующее длительное время ремонта списывают на «низкую квалификацию персонала», вместо того чтобы задать вопрос к самой системе.
При этом редко анализируется насколько сама архитектура помогает или мешает диагностике.
В результате появляются решения, которые удобно разрабатывать и демонстрировать, но которыми тяжело пользоваться в реальной эксплуатации.
И ещё один важный момент — те, кто проектирует такие решения, как правило, сами не работают с ними в условиях аварии, когда счёт идёт на минуты и любое лишнее действие критично.
Поэтому попытки объяснить, что такой подход «удобен»,
часто исходят не из опыта эксплуатации, а из опыта разработки.
Ваш подход может быть удобен для разработки и анализа,
но в эксплуатации он увеличивает время диагностики — а значит, увеличивает потери бизнеса.
Ваш подход действительно интересен с точки зрения разработки и переносимости алгоритмов.
Но вы полностью игнорируете ключевой аспект промышленной автоматизации — эксплуатацию.
АСУ ТП после ввода — это не «модель» и не «алгоритм».
Это инструмент диагностики и ремонта.
В аварии инженеру не нужно:
анализировать поведение системы,
изучать FBD,
смотреть, как «бегут цифры».
Ему нужно за минуты понять:
где разорвалась логика,
какой сигнал не прошёл,
какой interlock заблокировал запуск.
Именно поэтому во всех зрелых платформах: Siemens, Allen-Bradley и тд.
используются:
LAD как основной инструмент диагностики
декомпозиция на сети / рутины
inline значения сигналов
cross-reference
встроенная диагностика в коде
Это не «олдскул» — это результат десятилетий эксплуатации.
FBD и модели — отличный инструмент проектирования.
Но в реальной аварии они уступают по скорости диагностики в разы.
Генерация кода (особенно в C) дополнительно усугубляет ситуацию:
теряется прозрачность,
код превращается в «чёрный ящик»,
возрастает MTTR.
Именно поэтому подобные подходы почти не используются в массовой промышленной эксплуатации.
Если система не позволяет инженеру за 2–5 минут найти причину остановки — она не пригодна для реального производства, независимо от того, насколько она красива архитектурно.
Кровь из глаз пойдет у инженеров от такого визуала. Им с помощью этого нужно чинить оборудование.
Проект после ввода в эксплуатацию становится инструментом диагностики. Инженер должен мгновенно понимать:
что это за скорость,
откуда она берется,
где искать ее в схеме,
и что это вообще за сигнал.
Здесь должна быть простая и прозрачная логика. А у вас — как в PCS:
ни комментариев, ни декомпозиции на небольшие алгоритмы (нетворки, рутины).
Вы правда думаете, что крупные международные компании делают это просто так?
Зачем снова изобретать велосипед?
Инженеры десятилетиями оттачивали подходы к диагностике и сопровождению. А здесь предлагается решение, которое игнорирует этот опыт.
Как вообще появляются такие решения?
Сходите «в поля», посмотрите, как люди реально работают с системой.
Не придумывайте красивые концепции, которые не имеют ничего общего с эксплуатацией.
Люди будут работать не только с вашим проектом.
У них есть оборудование, электрические схемы, документация.
И при этом значение сигнала — в отдельном всплывающем окне. Серьезно?
Так у вас реализован онлайн-контроль?
Для кого это вообще сделано?
Это выглядит как продукт, ориентированный на презентацию менеджерам, а не на реальную эксплуатацию.
А потом инженеры 10–20 лет вынуждены с этим жить и обслуживать производство.
По поводу «избыточной жёсткости» и «бюрократизации» — вы абсолютно правы. В тексте я лишь обозначил направление, чтобы не перегружать. Но тема важнейшая, поэтому давайте конкретизирую практические механизмы, которые помогают избегать «окаменения» стандарта.
Ревью — это не переписывание документа «под настроение», а цикл, встроенный в эксплуатацию. Хорошо работает такой подход:
• Фиксированный период (например, раз в 12–18 месяцев).
• Обязательный сбор обратной связи «снизу»: от инженеров эксплуатации и пусконаладки.
• Принцип «изменения только ради эффекта»: если правка не снижает MTTR (Среднее время ремонта), не упрощает диагностику или не страхует от ошибок — она отклоняется. Важно смотреть не только на то, что добавить, но и на то, что удалить или упростить.
Разделение на «Жёсткое ядро» и «Адаптивную периферию». Структурно делим стандарт на две части:
• Ядро: архитектура, именование, безопасность (меняется крайне редко).
• Адаптивная часть: шаблоны, библиотеки, примеры реализации (здесь допустима эволюция). Это снимает бюрократию: инженеру не нужно согласовывать каждое улучшение кода, если он работает в рамках «адаптивного слоя».
Принцип «стандарт не должен мешать при авариях». Главный маркер плохой бюрократии — когда стандарт мешает быстро поднять «упавшую» линию. В зрелых системах стандарт проверяется на сценариях нештатной эксплуатации (аварии, частичные отказы). Если выясняется, что требования стандарта затягивают поиск неисправности или блокируют временные обходные решения— это прямой кандидат на немедленный пересмотр.
Сознательное ограничение детализации. Стандарт отвечает на вопрос «Как система должна вести себя и взаимодействовать», но не диктует «как писать каждую строку кода». Микроменеджмент в коде всегда ведет к формализму.
По поводу сокращений — замечание абсолютно справедливое, принято. В следующий раз обязательно добавлю глоссарий или буду внимательнее к расшифровке.
Вы правы насчёт документирования блоков — это основа. Но корпоративный стандарт — это и есть системный способ сделать так, чтобы сотни этих задокументированных блоков собирались в предсказуемое целое, а не в хаос. Это «генплан», а не только «кирпичи».
По поводу вендорозависимости — здесь ключевое заблуждение. Хороший стандарт фиксирует не бренд ПЛК, а архитектуру, интерфейсы, модели данных и протоколы. Именно это и даёт свободу. Если завтра нужно сменить вендора, вы адаптируете под новую платформу не 1000 разрозненных проектов, а одну централизованную библиотеку и шаблоны. Это сложная, но управляемая задача.
Без стандарта каждая программа уникальна. Миграция такого «зоопарка» в условиях санкций будет астрономически дорогой и рискованной. Стандарт же превращает вашу автоматизацию в переносимый актив, снижая риски, а не увеличивая их.
Стандартизация — это стратегия независимости, а не зацикленности.
Вам надо задуматься над тем что вы только что написали =) Может пора, что то менять, а то так и будем на жигулях ездить. Это кстати видно из ваших рамок в документации.
А зачем вы делаете велосипед? И кому проще. Да и если проще значит нельзя делать сложные вещи? Вопросов больше чем ответов =)
Вы меня не слышите. Но дам вам один совет. Привлеките в свой проект экспертизу реальной эксплуатации.
Вы правы, SimInTech — отличный инструмент для проектанта. Но мой тезис не о возможностях анализа, а о рабочих инструментах ремонта в условиях аварии.
Инженеру на производстве недостаточно «открыть диаграмму и добайтать». Ему нужен инструмент для действий, причём в формате, который он знает:
Диагностика: Быстро найти, какая именно ветка логики сработала или не сработала. Для этого нужны не графы в SimInTech, а триггеры, трассировка, статусы в реальном времени в том же LAD, который он видит на инженерной станции.
Экстренная модификация: Иногда нужно быстро дописать сервисный код (логирование, обход сломанного датчика, временный алгоритм пуска), чтобы запустить оборудование до прибытия запчастей. Для этого нужен доступ к программе ПЛК в родном, понятном ему языке, а не в сгенерированном C или блок-схемах SimInTech.
Языковой барьер: С — это язык системного программиста, а не инженера-наладчика. На производстве живут МЭКовские языки (LAD, FBD, ST), и LAD — король для визуальной диагностики. Инженеров, знающих С на уровне чтения чужого сгенерированного кода под давлением, — единицы.
Пример: аварийный дизель-генератор на АЭС. Время на поиск — минуты. Нет времени «изучать и повторять» алгоритм в SimInTech. Нужно открыть программу ПЛК этого дизеля, на родном языке, увидеть, почему не прошёл сигнал запуска, и, возможно, временно заблокировать ложный сигнал от неисправного датчика давления масла — чтобы обеспечить энергобезопасность сейчас.
Именно об этом я и говорю: сквозное проектирование должно быть «сквозным» и для эксплуатации. Генерация кода на С — это тупик для ремонтопригодности. Идеальная платформа должна позволять:
Генерировать/анализировать логику в высокоуровневых средах (SimInTech).
Предоставлять для эксплуатации ту же самую логику в нативных МЭКовских языках с возможностью безопасной временной модификации и продвинутой диагностики.
Иначе мы получаем идеально смоделированную систему, которая в момент реальной поломки превращается для персонала в непрозрачную магию, потому что ключ к пониманию (родная программа ПЛК) заменён на шифр (бинарник на С).
Отличный и подробный материал про сквозное проектирование. Однако, как всегда, в погоне за технологичностью и красотой для интегратора забывается ключевой аспект — ремонтопригодность и удобство для службы эксплуатации. Внедрение языков типа С и сложных модульных сред (NordWind) без учета реальных навыков и практик персонала, который будет обслуживать систему 20-30 лет, — это создание будущей "черной коробки". Прежде чем тратить годы на создание такой платформы, нужно было провести годы в беседах с наладчиками, дежурными инженерами и ремонтниками. Спросить: "Как вы ищете поломку? Что вам нужно видеть в первую очередь при аварии? Какие инструменты вы реально умеете и готовы использовать?". Иначе мы получаем идеальную систему, отлаженную на модели, но абсолютно хрупкую и непонятную в реальной жизни. Интегратор уйдет через полгода с готовым проектом, а завод останется с загадкой на долгие десятилетия.
Из этого комментария хорошо видно одно: мы говорим о разных реальностях.
Вы рассуждаете из позиции нормативных документов, формальных ролей и «как должно быть».
Я — из позиции реальной эксплуатации промышленного оборудования.
Давайте зафиксируем несколько принципиальных моментов, чтобы дальше не спорить о терминах, а говорить о реальной эксплуатации.
1. Что значит “инженер обслуживает завод”
Речь не о том, что один человек физически делает всё.
Речь о том, что для решения любой проблемы ему не нужно никому звонить, искать “того самого специалиста” или ждать подрядчика.
В реальной практике (особенно в России):
ночью инженер на смене часто один кто может принимать решения;
он первым приходит на аварию;
без его понимания логики системы работа не начинается;
механики и электрики действуют по его указаниям.
Это не теория и не «ущербная практика», а повседневная реальность большинства промышленных предприятий.
И именно в этой реальности становится понятно, обслуживаемая система или нет.
2. “Всё решает уровень специалистов” — опасная иллюзия
Да, сильный специалист может «вывозить на опыте».
Но система, которая держится на опыте отдельных людей, неустойчива по определению.
Это означает:
уход человека = потеря знаний;
рост нагрузки = выгорание;
масштабирование = невозможность повторить результат.
Стандарт нужен не для того, чтобы заменить специалистов,
а для того, чтобы их знания перестали быть единственной точкой отказа.
3. Про ГОСТы, ЕСКД и подмену понятий
ГОСТы серий 34, 19 и ЕСКД — нужны.
Они задают нормативный минимум и правила оформления. С этим никто не спорит.
Проблема в другом — в подмене понятий, которая массово происходит на практике.
Когда в ТЗ пишут «выполнить по ГОСТ и ЕСКД»,
очень часто считают, что:
архитектура автоматически правильная;
система автоматически качественная;
эксплуатация автоматически обеспечена.
Это неверно.
ГОСТы:
не задают архитектуру АСУ ТП;
не регламентируют структуру PLC-кода;
не описывают диагностику как инструмент эксплуатации;
не обеспечивают повторяемость решений между проектами.
Они сознательно этого не делают — и это нормально.
Но они и не могут заменить корпоративный стандарт АСУ ТП, ориентированный на жизненный цикл.
4. Документация по ЕСКД — отдельная боль эксплуатации
Проблема такой документации не только в том, что она «не помогает»,
а в том, что она часто объективно неудобна и плохо применима в реальной работе.
Простейший пример из эксплуатации:
в электрических схемах нет обязательной координатной сетки;
нет однозначной привязки элемента к шкафу и месту установки;
держа лист схемы в руках, невозможно понять, куда идти и что искать.
Инженер в аварии должен ответить на вопрос:
где этот элемент физически находится прямо сейчас.
Документация по ЕСКД на этот вопрос чаще всего не отвечает.
Формально она корректна, но как навигационный инструмент — бесполезна.
А время при этом тикает.
Оборудование стоит.
Производство теряет деньги.
Это не вопрос вкуса. Это вопрос пригодности документации к реальной эксплуатации.
5. Про архитектуру и проекты
Да, архитектуру конкретной АСУ ТП определяет проект.
Но тогда возникает следующий вопрос:
кто определяет архитектуру всех проектов на предприятии?
ГОСТ — не определяет.
Каждый проект — определяет только себя.
Если нет корпоративного стандарта:
каждый проект уникален;
каждый подрядчик делает по-своему;
каждую проблему приходится решать заново.
Именно это и приводит к ситуации, когда:
решения не тиражируются;
модернизация становится риском;
система живёт «пока помнят люди».
Речь в статье не о том, что:
ГОСТы плохие (хотя это действительно так);
документация не нужна;
специалисты не важны.
Речь о том, что:
ГОСТ — это минимум;
документация — это следствие архитектуры;
уровень специалистов не должен быть единственной страховкой системы.
Корпоративный стандарт АСУ ТП нужен не «вместо», а поверх ГОСТов —
чтобы система была:
обслуживаемой;
масштабируемой;
понятной без автора проекта;
жизнеспособной через 5–10–20 лет.
И пока предприятия продолжают путать нормативный минимум с архитектурным стандартом, они будут получать ровно то, что получают сегодня:
документы есть, специалисты сильные — а система всё равно держится на людях, а не на правилах.
И ещё один важный момент, который почему-то постоянно ускользает из подобных обсуждений.
Корпоративный стандарт — это и есть best practice.
Причём не «чья-то фантазия», а нормальная мировая практика крупных промышленных компаний.
Во всём мире:
автомобильная промышленность,
нефтехимия,
энергетика,
горнодобывающая отрасль,
работают не по принципу «каждый проект уникален», а по принципу:
единая архитектура,
единые правила построения,
единые требования к коду, диагностике и документации.
Именно поэтому у них:
решения тиражируются между заводами;
инженеры могут переходить между площадками;
уход подрядчика или вендора не означает катастрофу;
модернизация не превращается в полный реинжиниринг.
Никто не называет это «навязыванием».
Это называется управление жизненным циклом систем.
Когда корпоративного стандарта нет, предприятие каждый раз:
изобретает архитектуру заново;
платит за обучение снова;
повторяет одни и те же ошибки;
и в итоге «вывозит на опыте» отдельных людей.
Поэтому корпоративный стандарт АСУ ТП — это не частное мнение и не избыточная бюрократия.
Это концентрированный опыт эксплуатации, оформленный в правила.
И именно так выглядит best practice — не в документах «как должно быть», а в системах, которые работают годами без героизма.
Отдельно зафиксирую, откуда вообще взялось это «частное мнение».
Оно сформировалось не из теории и не из чтения стандартов, а из реального опыта работы в американский, европейских и российских.
Я реально работал:
на предприятиях с жёсткими корпоративными стандартами АСУ ТП,
и на предприятиях, где стандартов не было вовсе или они существовали формально.
И разница между этими мирами колоссальная и хорошо наблюдаемая на практике.
Там, где стандарт есть:
проекты повторяемы;
архитектура предсказуема;
инженер может разобраться в системе без автора;
модернизации делаются без страха;
уход подрядчика или специалиста не ломает систему.
Там, где стандарта нет:
каждый проект уникален;
эксплуатация держится на конкретных людях;
документация существует отдельно от реальной работы;
ночью инженер остаётся один на один с системой;
любое изменение — риск.
Поэтому это действительно частное мнение — но частное мнение человека, который видел обе стороны: и работу «по стандарту», и работу «на опыте».
И именно этот контраст и стал причиной написания статьи.
Вы абсолютно правы, и в вашем примере хорошо видна правильная, дисциплинированная работа на уровне отдельного проекта или объекта (подстанции).
Действительно, наличие полного комплекта проектной и исполнительной документации, листингов и открытого проекта — это необходимый минимум для ввода в эксплуатацию и основа для дальнейшего обслуживания. Вы описываете правильный и грамотный процесс сдачи одного проекта.
О чем я говорю в статье? О проблеме, которая возникает на уровень выше — на уровне не одного проекта, а десятков и сотней проектов в рамках одного предприятия или холдинга.
Проблема не в том, что нет документации по конкретной подстанции. Проблема в том, что на 10 разных подстанциях (или заводских линиях), даже построенных по одним ГОСТам и с одинаковой документацией, сама система устроена по-разному:
Логика одинаковой операции «включить выключатель» может быть реализована в 10 разных программных блоках с 10 разными названиями.
Диагностические сообщения об одной и той же неисправности будут сформулированы и выведены на SCADA 10 разными способами.
Архитектура тегов, структура программы, организация базы данных — уникальны для каждого интегратора.
В вашем случае эксплуатационщик, изучив документацию, становится экспертом по конкретной подстанции №5. В ситуации же, которую описываю я, чтобы стать экспертом по заводу, ему нужно изучить 50 уникальных проектов, как 50 разных книг, написанных на диалектах одного языка.
Таким образом, ваша практика решает задачу: «Мы знаем, как устроена эта система».
Задача корпоративного стандарта — решить проблему: «Все наши системы устроены единообразно, поэтому мы знаем, как устроена любая из них».
Это позволяет:
Тиражировать решения и знания. Найденное улучшение на подстанции №1 можно безопасно внедрить на подстанциях №2-10, потому что их код и логика структурированы одинаково.
Мгновенно адаптировать персонал. Инженер, освоившийся на одной подстанции, уже на 90% готов работать на любой другой, потому что не нужно заново изучать архитектуру.
Менять подрядчиков без потери управляемости. Новый интегратор получает не просто ТЗ, а архитектурный регламент, который гарантирует, что его проект войдет в общую экосистему, а не станет очередным «уникальным островом».
Итог: Вы описываете качественное выполнение проекта — и это отлично. Я же говорю о системном управлении портфелем проектов как единым активом на протяжении десятилетий. Первое — необходимое условие. Второе — следующий уровень зрелости, который радикально снижает совокупную стоимость владения. Спасибо, что дали возможность это уточнить!
Apoheliy, спасибо! Вы задели важный момент. Наше недопонимание, кажется, кроется в самой сути объектов обсуждения.
Вы говорите о софте — виртуальном продукте, который не имеет физического износа. Его не «чинят» в привычном смысле, а обновляют или исправляют ошибки. Требовать менять его архитектуру постфактум действительно может быть странно.
Но я говорю о физическом заводе. АСУ ТП здесь — это не самостоятельный продукт, а инструмент для обслуживания и ремонта постоянно ломающегося оборудования. Механизмы изнашиваются, датчики загрязняются, а так же не исключены ошибки в коде ПЛК. Код ПЛК — это в первую очередь диагностическая карта для инженера, который бежит на линию с мультиметром и программатором, чтобы определить в чем проблема. А модернизацию на заводе иногда приходится делать внезапно ночью из за того, нужного оборудования нет на складе для простой замены, а линию запускать надо.
Поэтому стандарт кодирования — это вопрос безопасности и экономики. Если код написан «как Бог на душу положит», инженер теряет часы на поиск причины, а завод теряет сотни тысяч рублей в час простоя. Нам не нужно менять «ядро» — нам нужно, чтобы инженеру требовалось минимальное количество времени на определение проблемы.
Спасибо за дискуссию! Она хорошо показывает, насколько специфичны требования к системам, которые работают не в идеальном мире битов, а в суровой реальности железа, масла и вибрации.
Именно поэтому стандарт и нужен.
Производитель действительно может делать продукт как угодно.
Вопрос не в этом.
Вопрос в том, готово ли предприятие жить с последствиями этого выбора десятилетиями.
Если у заказчика нет собственного стандарта, то:
архитектура системы полностью определяется вендором или интегратором;
внутренняя логика проекта становится уникальной;
модернизация возможна только через того же производителя или его партнёров;
выход вендора автоматически означает потерю поддержки и знаний.
2022 год наглядно показал, что сценарий «производитель всегда будет рядом» — это иллюзия.
В один момент можно остаться:
без обновлений,
без лицензий,
без поддержки,
без возможности легальной модернизации.
И тогда остаётся два варианта:
ничего не трогать, пока система окончательно не устареет;
полный реинжиниринг за большие деньги и с высокими рисками.
Корпоративный стандарт не гарантирует, что вендор будет сотрудничать.
Но он гарантирует другое:
если вендор уходит, предприятие остаётся хозяином своей архитектуры.
Стандарт:
фиксирует структуру системы;
отделяет логику управления от конкретного продукта;
делает код, диагностику и документацию воспроизводимыми;
позволяет модернизировать систему частями, а не «сносить всё».
Да, возможна ситуация, когда производитель скажет: «мы так делать не будем».
Это честная ситуация, и тогда заказчик принимает осознанное решение — принимать продукт как есть или искать альтернативу.
Хуже другое: когда стандарта нет, заказчик даже не формулирует требований, а значит автоматически принимает любые ограничения вендора — зачастую не осознавая их до момента кризиса.
Стандарт — это не попытка заставить производителя «делать по-своему».
Это способ не оказаться заложником чужих решений, когда выбора уже нет.
И именно в российских реалиях это перестало быть теорией.
И здесь как раз показательная история из практики.
На одном из заводов установили оборудование с ПЛК вендора, которого раньше на предприятии не было. В результате:
увеличился склад запасных частей;
инженерам пришлось изучать новый софт и среду разработки;
понадобилось покупать дополнительные лицензии;
усложнилась поддержка и сопровождение.
Когда я разговаривал с производителем я задал логичный вопрос:
«А можно было сделать оборудование на ПЛК, которые уже используются на заводе?»
ответ был предельно честный:
«Да, конечно. Просто вы нас об этом не просили.»
И это ключевой момент.
Производитель и интегратор не обязаны угадывать предпочтения заказчика.
Если у заказчика нет стандарта, значит:
нет требований к платформам;
нет ограничений по архитектуре;
нет критериев унификации.
В этом случае подрядчик выбирает то, что удобно ему — и формально он прав.
Корпоративный стандарт нужен именно для того, чтобы такие требования были сформулированы заранее:
какие платформы допустимы;
где возможны отклонения и на каких условиях;
какие последствия несёт выбор нестандартных решений.
Без стандарта предприятие платит не только за оборудование, но и за:
рост складских запасов,
обучение персонала,
лицензии,
усложнение эксплуатации на годы вперёд.
И это не ошибка подрядчика.
Это отсутствие требований со стороны заказчика.
Сравнивать завод с компьютером не правильно.
Сбор «good practices» — полезен, но он не заменяет стандарт.
Библиотека удачных решений отвечает на вопрос «как можно сделать».
Корпоративный стандарт отвечает на вопрос «как делаем у нас и почему именно так».
Без стандарта good practices остаются:
необязательными;
применяемыми по желанию;
интерпретируемыми каждым по-своему.
В результате при смене подрядчика, команды или проекта эти «лучшие практики» перестают быть лучшими и перестают применяться вовсе.
На практике зрелый подход выглядит так:
стандарт задаёт архитектуру и обязательные принципы,
good practices дополняют его конкретными приёмами и примерами.
Одно без другого не работает.
Это распространённое мнение, и именно оно на практике и приводит к тем проблемам, о которых говорится в статье. Эксплуатационная документация сама по себе не является стандартом. Она описывает конкретную реализацию, но не задаёт правил, по которым эта реализация должна быть построена. В результате каждая новая АСУ ТП снова оказывается уникальной — с собственной архитектурой, логикой, подходом к диагностике и сопровождению. Корпоративный стандарт АСУ ТП не подменяет документацию и не конкурирует с ней. Он отвечает на другие вопросы:
как в принципе строятся системы управления на предприятии;
где проходят границы ответственности;
как организована диагностика;
как должна выглядеть структура программ и данных;
как обеспечивается воспроизводимость решений.
Без этого эксплуатационная документация всегда остаётся описанием частного случая, а не инструментом управления системой в масштабе предприятия.
Что касается «слишком общего» или «слишком частного» — именно поэтому рабочие стандарты и строятся модульно: есть общий архитектурный уровень (применимый ко всем объектам), а есть частные модули под типовое оборудование и процессы. Так работают промышленные корпорации с десятками и сотнями предприятий. Вот мои статьи на эту тему: https://habr.com/ru/articles/956460/ https://habr.com/ru/articles/963160/
Если ограничиться только документацией, предприятие каждый раз платит заново:
за поиск уже известных проблем,
за обучение новых инженеров,
за зависимость от конкретных исполнителей,
за невозможность тиражировать решения.
Документация описывает то, что получилось. Стандарт определяет то, как это должно получаться. Именно эту разницу и важно не терять.