Корпоративные стандарты АСУ ТП: какие эффекты они реально дают бизнесу

[serafims]

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

[ePGfree]

Вы правы насчёт документирования блоков — это основа. Но корпоративный стандарт — это и есть системный способ сделать так, чтобы сотни этих задокументированных блоков собирались в предсказуемое целое, а не в хаос. Это «генплан», а не только «кирпичи».

По поводу вендорозависимости — здесь ключевое заблуждение. Хороший стандарт фиксирует не бренд ПЛК, а архитектуру, интерфейсы, модели данных и протоколы. Именно это и даёт свободу. Если завтра нужно сменить вендора, вы адаптируете под новую платформу не 1000 разрозненных проектов, а одну централизованную библиотеку и шаблоны. Это сложная, но управляемая задача.

Без стандарта каждая программа уникальна. Миграция такого «зоопарка» в условиях санкций будет астрономически дорогой и рискованной. Стандарт же превращает вашу автоматизацию в переносимый актив, снижая риски, а не увеличивая их.

Стандартизация — это стратегия независимости, а не зацикленности.

[Elpi]

1. Получил большое удовольствие от прочтения. Четко, лаконично, аргументированно. Нмв, образцовая статья. Спасибо.

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

3. Мелкая придирка. Уверен, вы знаете правила введения сокращений в тексте. Либо раздел "Термины и сокращения", либо расшифровка при первом упоминании.

[ePGfree]

По поводу «избыточной жёсткости» и «бюрократизации» — вы абсолютно правы. В тексте я лишь обозначил направление, чтобы не перегружать. Но тема важнейшая, поэтому давайте конкретизирую практические механизмы, которые помогают избегать «окаменения» стандарта.
Ревью — это не переписывание документа «под настроение», а цикл, встроенный в эксплуатацию. Хорошо работает такой подход:
• Фиксированный период (например, раз в 12–18 месяцев).
• Обязательный сбор обратной связи «снизу»: от инженеров эксплуатации и пусконаладки.
• Принцип «изменения только ради эффекта»: если правка не снижает MTTR (Среднее время ремонта), не упрощает диагностику или не страхует от ошибок — она отклоняется. Важно смотреть не только на то, что добавить, но и на то, что удалить или упростить.
Разделение на «Жёсткое ядро» и «Адаптивную периферию». Структурно делим стандарт на две части:
• Ядро: архитектура, именование, безопасность (меняется крайне редко).
• Адаптивная часть: шаблоны, библиотеки, примеры реализации (здесь допустима эволюция). Это снимает бюрократию: инженеру не нужно согласовывать каждое улучшение кода, если он работает в рамках «адаптивного слоя».
Принцип «стандарт не должен мешать при авариях». Главный маркер плохой бюрократии — когда стандарт мешает быстро поднять «упавшую» линию. В зрелых системах стандарт проверяется на сценариях нештатной эксплуатации (аварии, частичные отказы). Если выясняется, что требования стандарта затягивают поиск неисправности или блокируют временные обходные решения— это прямой кандидат на немедленный пересмотр.
Сознательное ограничение детализации. Стандарт отвечает на вопрос «Как система должна вести себя и взаимодействовать», но не диктует «как писать каждую строку кода». Микроменеджмент в коде всегда ведет к формализму.
По поводу сокращений — замечание абсолютно справедливое, принято. В следующий раз обязательно добавлю глоссарий или буду внимательнее к расшифровке.

[Teemon]

Где та грань между абстрактным стандартом-философией и прямой инструкцией "мануалом" а том, "как писать строчки кода"?..

Под стандарт больше подходит например "спецификация" или "технические требования", в то же время на этапе эксплуатации стандарт на АСУТП будет более локальным документом, учитывающий существующие процессы в компании, более адаптированный под "жизненные реалии" предприятия.

Общий стандарт скорее всего, должен иметь более высокую "юридическую силу", включая все стадии жизненного цикла, АСУТП, а эксплуатационный стандарт быть более "живым", привязанным к "местности", содержащий информацию о том, как конкретно вести контроль версий и тд.

Т.е. иерархия - философия (стандарт), далее стратегия, далее регламент.

[Cordekk]

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

[petuhoff]

Корпоративные стандарты АСУ ТП — это внутренние правила и решения, разработанные самой компанией и обязательные для всех её проектов и подрядчиков. Они учитывают:

• конкретные типы оборудования и поставщиков;

Многие корпоративные стандарты сильно привязаны к конкретной платформе (Rockwell Studio 5000, Siemens TIA Portal, AVEVA System Platform). Замена вендора в будущем требует либо полной переписки библиотек, либо сохранения старой платформы — оба варианта дорогостоящие.

Забавно, что первым пунктом стандарта автоматизации идет список поставщиков. И уже ниже по тексту аккуратно многие.

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

Уже на этом этапе менеджеры любой компании ловят клин. И заявляют уже не стесняясь:

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

Менеджеру удбоно, не надо слушать инженеров в поле, он берет лучшее мировае решение и внедряеет "best practic". Инженерам удобно куча готовых элементов и полно знакомых у которых можно спроситить. Собственник переплачивает за бренд вендора, но кого волнуют чужие деньги когда есть отакты поставщика оборудования.

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

Ну и сами вендры шарашат по мозгам, как хорошо иметь станраты от вендора:

В одном из кейсов Siemens описан опыт глобального поставщика автокомпонентов, который при миграции на Siemens внедрил корпоративный стандарт ПЛК и типовую архитектуру проектов. 

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

Самый болезненный этап — перевод старых линий под новый стандарт. В реальных проектах компании тратят 2–4 года и десятки миллионов евро только на то, чтобы привести хотя бы 50–60% парка в соответствие. 

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

Но за 2 - 4 года, может многое изменится. И на кону мочало - начинай сначала! Вон очередной дед, запретит применять контроллеры Siemens на американских заводах, и куда можно будет засунуть копрпоративный стандарт?

Поэтому отличная статья и внедрени стандартов отличная и правильная тема. только вот если это внедрении требует 2–4 года и десятки миллионов евро только на то, чтобы привести хотя бы 50–60%, не делайте этого.

Любое внедрение стандратов должно сокращать затраты сразу, а не через 4 года.

[ePGfree]

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

Это распространённое заблуждение, но оно путает причину со следствием.

Крупные корпорации приходят к вендору и говорят: «нам надо так». И вендор делает так, как надо.

• У 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 лет. Линии, которые вы запускаете сегодня, будут работать, когда нынешние менеджеры уже уйдут на пенсию. А ПЛК, который вы выбрали, возможно, будет снят с производства ещё при жизни завода.

Если вам нужен только быстрый эффект — вы получите быстрый эффект. Но не получите стратегического.

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

Стандарт — это инструмент, который позволяет заводу думать на десятилетия вперёд, не проигрывая в текущей эффективности. Тот, кто этого не понимает, строит не завод, а дорогой конструктор «собери сам».