Comments 7
Главное хорошо документировать не систему целиком, а ее составные части - функциональные блоки - интерфейсы, типы сигналов и тп, протоколы с примерами данных обмена - и поддерживать проще, и взаимозаменяемость можно обеспечить. А зацикленность на одном виде ПЛК хороша для обеспечения горячего запаса запчастей, но плоха в условиях санкций.
Вы правы насчёт документирования блоков — это основа. Но корпоративный стандарт — это и есть системный способ сделать так, чтобы сотни этих задокументированных блоков собирались в предсказуемое целое, а не в хаос. Это «генплан», а не только «кирпичи».
По поводу вендорозависимости — здесь ключевое заблуждение. Хороший стандарт фиксирует не бренд ПЛК, а архитектуру, интерфейсы, модели данных и протоколы. Именно это и даёт свободу. Если завтра нужно сменить вендора, вы адаптируете под новую платформу не 1000 разрозненных проектов, а одну централизованную библиотеку и шаблоны. Это сложная, но управляемая задача.
Без стандарта каждая программа уникальна. Миграция такого «зоопарка» в условиях санкций будет астрономически дорогой и рискованной. Стандарт же превращает вашу автоматизацию в переносимый актив, снижая риски, а не увеличивая их.
Стандартизация — это стратегия независимости, а не зацикленности.
Получил большое удовольствие от прочтения. Четко, лаконично, аргументированно. Нмв, образцовая статья. Спасибо.
Прошу уточнить на уровне практических рекомендаций методы купирования "избыточной жесткости" и "бюрократизации". Вы упомянул "ревью стандарта", но очень кратко.
Мелкая придирка. Уверен, вы знаете правила введения сокращений в тексте. Либо раздел "Термины и сокращения", либо расшифровка при первом упоминании.
По поводу «избыточной жёсткости» и «бюрократизации» — вы абсолютно правы. В тексте я лишь обозначил направление, чтобы не перегружать. Но тема важнейшая, поэтому давайте конкретизирую практические механизмы, которые помогают избегать «окаменения» стандарта.
Ревью — это не переписывание документа «под настроение», а цикл, встроенный в эксплуатацию. Хорошо работает такой подход:
• Фиксированный период (например, раз в 12–18 месяцев).
• Обязательный сбор обратной связи «снизу»: от инженеров эксплуатации и пусконаладки.
• Принцип «изменения только ради эффекта»: если правка не снижает MTTR (Среднее время ремонта), не упрощает диагностику или не страхует от ошибок — она отклоняется. Важно смотреть не только на то, что добавить, но и на то, что удалить или упростить.
Разделение на «Жёсткое ядро» и «Адаптивную периферию». Структурно делим стандарт на две части:
• Ядро: архитектура, именование, безопасность (меняется крайне редко).
• Адаптивная часть: шаблоны, библиотеки, примеры реализации (здесь допустима эволюция). Это снимает бюрократию: инженеру не нужно согласовывать каждое улучшение кода, если он работает в рамках «адаптивного слоя».
Принцип «стандарт не должен мешать при авариях». Главный маркер плохой бюрократии — когда стандарт мешает быстро поднять «упавшую» линию. В зрелых системах стандарт проверяется на сценариях нештатной эксплуатации (аварии, частичные отказы). Если выясняется, что требования стандарта затягивают поиск неисправности или блокируют временные обходные решения— это прямой кандидат на немедленный пересмотр.
Сознательное ограничение детализации. Стандарт отвечает на вопрос «Как система должна вести себя и взаимодействовать», но не диктует «как писать каждую строку кода». Микроменеджмент в коде всегда ведет к формализму.
По поводу сокращений — замечание абсолютно справедливое, принято. В следующий раз обязательно добавлю глоссарий или буду внимательнее к расшифровке.
Где та грань между абстрактным стандартом-философией и прямой инструкцией "мануалом" а том, "как писать строчки кода"?..
Под стандарт больше подходит например "спецификация" или "технические требования", в то же время на этапе эксплуатации стандарт на АСУТП будет более локальным документом, учитывающий существующие процессы в компании, более адаптированный под "жизненные реалии" предприятия.
Общий стандарт скорее всего, должен иметь более высокую "юридическую силу", включая все стадии жизненного цикла, АСУТП, а эксплуатационный стандарт быть более "живым", привязанным к "местности", содержащий информацию о том, как конкретно вести контроль версий и тд.
Т.е. иерархия - философия (стандарт), далее стратегия, далее регламент.
Не все понимаю до конца, но согласен, что если какие-то проекты делаются по шаблонам со старых проектов, то назревает необходимость создания стандарта с описанными и реализованными вариантами решений. Чисто на бумаге стандарт конечно не работает, а вот когда есть реализация в "железе", то уже проще будет придерживаться стандарта, чем создавать новые реализации.
Корпоративные стандарты АСУ ТП — это внутренние правила и решения, разработанные самой компанией и обязательные для всех её проектов и подрядчиков. Они учитывают:
конкретные типы оборудования и поставщиков;
Многие корпоративные стандарты сильно привязаны к конкретной платформе (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 года.
Корпоративные стандарты АСУ ТП: какие эффекты они реально дают бизнесу