Comments 21
«Проект выполнить в соответствии с ГОСТ и ЕСКД».
По сути, это равнозначно фразе: «Делайте как хотите».
Есть хороший бытовой пример - колбаса по ГОСТу... почитайте, даже советский ГОСТ 23670-79... и слово колбаса по ГОСТу приобретет противоположное значение... В общих чертах если мясо не мяукало и не каркало - то для колбасы сойдет...
Если кратко описать смысл статьи:
давайте возрождать НИИ и КБ. Например, предлагается создать НИИ АСУ ТП - который будет разрабатывать стандарты, и работать там будут гении: и проектированием они занимались, и программированием они занимались, и работали со стороны как интегратора, так и эксплуатации. Причем, очень желательно, чтобы каждый из "гениев" обладал полным комплектов навыков - иначе "бодание за KPI" плавно перетечёт из завода на совещания в этот НИИ;
давайте возрождать многолетнее планирование для целой отрасли и обмен опытом (горизонт планирования - десятилетия; найденная ошибка на одном заводе должна исправляться и на другом заводе при единой стандарте и т.д.). А кто не соответствует стандарту - того забросать тряпками. Вот честно, у меня в голове появляются буквы Г, О, С, П, Л, А, Н. Но это так, к слову.
В общем, всё развивается по спирали: звериный капитализм надоел, в статье предлагается переползти в коммунизм-социализм.
Эта статья как раз про капитализм. Все крупные американские и европейские корпорации данным давно так работают. И делают они это потому, что умеют считать деньги.
Э-э-э, из того, что:
Все крупные американские и европейские корпорации данным давно так работают
совсем не следует, что эти корпорации работают в капитализм.
Если же почитать определения:
Капитализм — социально-экономическая система производства и распределения товаров и услуг, основанная на принципах частной собственности, юридического равенства участников, купли-продажи рабочей силы, свободного рынка и свободной конкуренции.
...
Свобода предпринимательства — люди имеют возможность начинать и вести бизнес на основе своих решений.
Социали́зм (от лат. socialis — «общественный») — политическая, экономическая и социальная философия и идеология
...
Нерыночный социализм предполагает замену рыночных факторов производства и денег инженерно-техническими критериями, основанными на расчётах, выполненных в натуральной форме, тем самым создавая экономический механизм, который функционирует в соответствии с экономическими законами, отличными от законов капитализма. Нерыночный социализм направлен на то, чтобы обойти неэффективность ...
То (почему-то) предлагаемые Вами подходы ближе находятся к социализму.
Сурпрайз! :)
То (почему-то) предлагаемые Вами подходы ближе находятся к социализму.
Сурпрайз! :)
А что в этом плохого? На всех предприятиях, где нужно стабильно выпускать продут или услугу, есть планирование. При этом никто не мешает им работать в рыночной системе. Вы точно не путаете рыночную, плановую экономики и капитализм, социализм? Наличие планирования не означает совковую систему.
АСУ ТП как следует из определения - автоматизированная система.
На автоматизированные системы действуют стандарты серии 34.
Писать и говорить "ГОСТы и ЕСКД" неправильно. Есть ГОСТы ЕСКД (2 серия)- единая система конструкторской документации, посвящённые правилам оформления и управления конструкторской документации. Поскольку ГОСТы ЕСТД, а также ГОСТы 34 и 19 серии ссылаются на ЕСКД в плане оформления, то на автоматизированные системы и программы документы оформляются также.
Искать в стандартах какую-то истину не надо. Стандарт это минимальные требования. Стандарты 34 серии устанавливают требования к наличию документации, но не к её содержанию. Тут уже заказчик определяет.
И вот к каждой АСУ ТП по ГОСТу должна быть эксплуатационная документация, отдельно инструкции для операторов, отдельно для тех, кто занимается поддержкой. Если такой документации нет, значит система сделана не по ГОСТу. Либо управление документацией на заводе не построено в соответствии с ЕСКД и контрольные экземпляры документации давно пролюбили.
Возможно, вы не дочитали статью до конца.
Речь в ней не о том, что ГОСТы или ЕСКД «неправильные», а о том, что они не являются архитектурными и эксплуатационными стандартами АСУ ТП. ГОСТы серий 34 и 19 действительно задают минимальные требования к составу и оформлению документации, но сознательно не регламентируют структуру систем управления, логику программ, диагностику и сопровождение в жизненном цикле.
Именно поэтому фраза «сделано по ГОСТу» на практике никак не отвечает на вопросы эксплуатации, тиражирования и модернизации, о чём и говорится в статье.
ГОСТ — это нормативный минимум. Стандарт АСУ ТП предприятия — это архитектура и правила жизни системы после сдачи проекта.
На АСУ ТП конкретных предприятий писать стандарты не имеет особого смысла. Любой стандарт будет либо слишком общим и описывать только форму, либо будет частным, который применим только в узкой сфере.
Должна быть эксплуатационная документация и всё.
Это распространённое мнение, и именно оно на практике и приводит к тем проблемам, о которых говорится в статье. Эксплуатационная документация сама по себе не является стандартом. Она описывает конкретную реализацию, но не задаёт правил, по которым эта реализация должна быть построена. В результате каждая новая АСУ ТП снова оказывается уникальной — с собственной архитектурой, логикой, подходом к диагностике и сопровождению. Корпоративный стандарт АСУ ТП не подменяет документацию и не конкурирует с ней. Он отвечает на другие вопросы:
как в принципе строятся системы управления на предприятии;
где проходят границы ответственности;
как организована диагностика;
как должна выглядеть структура программ и данных;
как обеспечивается воспроизводимость решений.
Без этого эксплуатационная документация всегда остаётся описанием частного случая, а не инструментом управления системой в масштабе предприятия.
Что касается «слишком общего» или «слишком частного» — именно поэтому рабочие стандарты и строятся модульно: есть общий архитектурный уровень (применимый ко всем объектам), а есть частные модули под типовое оборудование и процессы. Так работают промышленные корпорации с десятками и сотнями предприятий. Вот мои статьи на эту тему: https://habr.com/ru/articles/956460/ https://habr.com/ru/articles/963160/
Если ограничиться только документацией, предприятие каждый раз платит заново:
за поиск уже известных проблем,
за обучение новых инженеров,
за зависимость от конкретных исполнителей,
за невозможность тиражировать решения.
Документация описывает то, что получилось. Стандарт определяет то, как это должно получаться. Именно эту разницу и важно не терять.
можно конечно разрабатывать корпоративные стандарты - СТО.
Но в целом лучше и проще собирать библиотеку правильных решений - "good practices".
Сбор «good practices» — полезен, но он не заменяет стандарт.
Библиотека удачных решений отвечает на вопрос «как можно сделать».
Корпоративный стандарт отвечает на вопрос «как делаем у нас и почему именно так».
Без стандарта good practices остаются:
необязательными;
применяемыми по желанию;
интерпретируемыми каждым по-своему.
В результате при смене подрядчика, команды или проекта эти «лучшие практики» перестают быть лучшими и перестают применяться вовсе.
На практике зрелый подход выглядит так:
стандарт задаёт архитектуру и обязательные принципы,
good practices дополняют его конкретными приёмами и примерами.
Одно без другого не работает.
И как результат применения этого подхода (вангую):
у поставщика есть продукт (АСУ ТП или др.), продукт сделан по определённой архитектуре, а ещё продукт может быть сертифицирован;
Приходит заказчик и выставляет требования: всё сделать согласно нашим good practices, стандартам и т.д.. Причём не только внешнее отображение, и не стык в другими системами по открытым (или не очень открытым) протоколам, а именно внутрянку;
... варианты ответа, полагаю, вы сами можете предположить (и это необязательно то, что вы, возможно, подумали: см. примечание).
Прим.: вспоминается ситуация с ПО для проектного управления: отдельным товарищам очень хотелось Microsoft Project заменить. Итак, поискали: есть аналогичные продукты (и российские в том числе), но они "другие": кнопочки не там, планирование по-другому, отчёты непривычные. Результат: заказчики обратились к разработчикам - хотим своё и как project; разработчики выкатили деньги и сроки; заказчики поняли, что они не заказчики.
Именно поэтому стандарт и нужен.
Производитель действительно может делать продукт как угодно.
Вопрос не в этом.
Вопрос в том, готово ли предприятие жить с последствиями этого выбора десятилетиями.
Если у заказчика нет собственного стандарта, то:
архитектура системы полностью определяется вендором или интегратором;
внутренняя логика проекта становится уникальной;
модернизация возможна только через того же производителя или его партнёров;
выход вендора автоматически означает потерю поддержки и знаний.
2022 год наглядно показал, что сценарий «производитель всегда будет рядом» — это иллюзия.
В один момент можно остаться:
без обновлений,
без лицензий,
без поддержки,
без возможности легальной модернизации.
И тогда остаётся два варианта:
ничего не трогать, пока система окончательно не устареет;
полный реинжиниринг за большие деньги и с высокими рисками.
Корпоративный стандарт не гарантирует, что вендор будет сотрудничать.
Но он гарантирует другое:
если вендор уходит, предприятие остаётся хозяином своей архитектуры.
Стандарт:
фиксирует структуру системы;
отделяет логику управления от конкретного продукта;
делает код, диагностику и документацию воспроизводимыми;
позволяет модернизировать систему частями, а не «сносить всё».
Да, возможна ситуация, когда производитель скажет: «мы так делать не будем».
Это честная ситуация, и тогда заказчик принимает осознанное решение — принимать продукт как есть или искать альтернативу.
Хуже другое: когда стандарта нет, заказчик даже не формулирует требований, а значит автоматически принимает любые ограничения вендора — зачастую не осознавая их до момента кризиса.
Стандарт — это не попытка заставить производителя «делать по-своему».
Это способ не оказаться заложником чужих решений, когда выбора уже нет.
И именно в российских реалиях это перестало быть теорией.
И здесь как раз показательная история из практики.
На одном из заводов установили оборудование с ПЛК вендора, которого раньше на предприятии не было. В результате:
увеличился склад запасных частей;
инженерам пришлось изучать новый софт и среду разработки;
понадобилось покупать дополнительные лицензии;
усложнилась поддержка и сопровождение.
Когда я разговаривал с производителем я задал логичный вопрос:
«А можно было сделать оборудование на ПЛК, которые уже используются на заводе?»
ответ был предельно честный:
«Да, конечно. Просто вы нас об этом не просили.»
И это ключевой момент.
Производитель и интегратор не обязаны угадывать предпочтения заказчика.
Если у заказчика нет стандарта, значит:
нет требований к платформам;
нет ограничений по архитектуре;
нет критериев унификации.
В этом случае подрядчик выбирает то, что удобно ему — и формально он прав.
Корпоративный стандарт нужен именно для того, чтобы такие требования были сформулированы заранее:
какие платформы допустимы;
где возможны отклонения и на каких условиях;
какие последствия несёт выбор нестандартных решений.
Без стандарта предприятие платит не только за оборудование, но и за:
рост складских запасов,
обучение персонала,
лицензии,
усложнение эксплуатации на годы вперёд.
И это не ошибка подрядчика.
Это отсутствие требований со стороны заказчика.
Сравнивать завод с компьютером не правильно.
Особенно повеселил пункт:
модернизация возможна только через того же производителя или его партнёров;
Уважаемый ePGfree, если потребитель в поставленной мной системе начнёт сам что-то менять или модернизировать ... вот, даже мысль замерла.
На самом деле, я на практике таких "странных людей" не встречал. В нашей поставке даже версию винды/линукса/браузера обновить нельзя.
С другой стороны, если потребитель хочет что-то модернизировать, то кто может ему помешать. Но если при условном обновлении ядра линукса вдруг не найдётся подходящий драйвер модуль ядра - ну, тяжело ему будет.
Apoheliy, спасибо! Вы задели важный момент. Наше недопонимание, кажется, кроется в самой сути объектов обсуждения.
Вы говорите о софте — виртуальном продукте, который не имеет физического износа. Его не «чинят» в привычном смысле, а обновляют или исправляют ошибки. Требовать менять его архитектуру постфактум действительно может быть странно.
Но я говорю о физическом заводе. АСУ ТП здесь — это не самостоятельный продукт, а инструмент для обслуживания и ремонта постоянно ломающегося оборудования. Механизмы изнашиваются, датчики загрязняются, а так же не исключены ошибки в коде ПЛК. Код ПЛК — это в первую очередь диагностическая карта для инженера, который бежит на линию с мультиметром и программатором, чтобы определить в чем проблема. А модернизацию на заводе иногда приходится делать внезапно ночью из за того, нужного оборудования нет на складе для простой замены, а линию запускать надо.
Поэтому стандарт кодирования — это вопрос безопасности и экономики. Если код написан «как Бог на душу положит», инженер теряет часы на поиск причины, а завод теряет сотни тысяч рублей в час простоя. Нам не нужно менять «ядро» — нам нужно, чтобы инженеру требовалось минимальное количество времени на определение проблемы.
Спасибо за дискуссию! Она хорошо показывает, насколько специфичны требования к системам, которые работают не в идеальном мире битов, а в суровой реальности железа, масла и вибрации.
Добрый день, в автоматизации подстанций на стадии начала конфигурирования есть проектная документация, по окончании наладки появляется исполнительная. По ней и выполняют эксплуатацию. В документации давно прописывается логика управления, листинг программы (если возможно) и передается проект доступный для редактирования. Таким образом, ситуация, когда реализована какая-то логика управления распред. устройством, а какая она никто не знает, исключена.
Вы абсолютно правы, и в вашем примере хорошо видна правильная, дисциплинированная работа на уровне отдельного проекта или объекта (подстанции).
Действительно, наличие полного комплекта проектной и исполнительной документации, листингов и открытого проекта — это необходимый минимум для ввода в эксплуатацию и основа для дальнейшего обслуживания. Вы описываете правильный и грамотный процесс сдачи одного проекта.
О чем я говорю в статье? О проблеме, которая возникает на уровень выше — на уровне не одного проекта, а десятков и сотней проектов в рамках одного предприятия или холдинга.
Проблема не в том, что нет документации по конкретной подстанции. Проблема в том, что на 10 разных подстанциях (или заводских линиях), даже построенных по одним ГОСТам и с одинаковой документацией, сама система устроена по-разному:
Логика одинаковой операции «включить выключатель» может быть реализована в 10 разных программных блоках с 10 разными названиями.
Диагностические сообщения об одной и той же неисправности будут сформулированы и выведены на SCADA 10 разными способами.
Архитектура тегов, структура программы, организация базы данных — уникальны для каждого интегратора.
В вашем случае эксплуатационщик, изучив документацию, становится экспертом по конкретной подстанции №5. В ситуации же, которую описываю я, чтобы стать экспертом по заводу, ему нужно изучить 50 уникальных проектов, как 50 разных книг, написанных на диалектах одного языка.
Таким образом, ваша практика решает задачу: «Мы знаем, как устроена эта система».
Задача корпоративного стандарта — решить проблему: «Все наши системы устроены единообразно, поэтому мы знаем, как устроена любая из них».
Это позволяет:
Тиражировать решения и знания. Найденное улучшение на подстанции №1 можно безопасно внедрить на подстанциях №2-10, потому что их код и логика структурированы одинаково.
Мгновенно адаптировать персонал. Инженер, освоившийся на одной подстанции, уже на 90% готов работать на любой другой, потому что не нужно заново изучать архитектуру.
Менять подрядчиков без потери управляемости. Новый интегратор получает не просто ТЗ, а архитектурный регламент, который гарантирует, что его проект войдет в общую экосистему, а не станет очередным «уникальным островом».
Итог: Вы описываете качественное выполнение проекта — и это отлично. Я же говорю о системном управлении портфелем проектов как единым активом на протяжении десятилетий. Первое — необходимое условие. Второе — следующий уровень зрелости, который радикально снижает совокупную стоимость владения. Спасибо, что дали возможность это уточнить!
Ох и покритикую я сейчас это частное мнение, выставляемое напоказ.
Если стандарта нет — может пройти год и больше, прежде чем человек сможет в одиночку обслуживать завод без постоянного риска что-то сломать
Да какая ересть! Никакой инженер не может обслуживать "никакой" завод "в одну каску". Практика "и жнец и на дуде игрец" крайне ущербна.
Разница между этими сценариями не в уровне специалистов, а в том, есть ли на предприятии система или только набор проектов
В конечном итоге, на предприятии, именно уровень специалистов является определяющим. Даже при "плохой мине" опытный сотрудник может поддерживать безаварийную работу сложного технологического оборудования, вывозя всё и вся "на классе". Не оцениваю, плохо ли это или хорошо, просто как мнение.
ГОСТ и ЕСКД — это не стандарты АСУ ТП
В технических заданиях до сих пор часто можно увидеть формулировку:
«Проект выполнить в соответствии с ГОСТ и ЕСКД».
По сути, это равнозначно фразе: «Делайте как хотите».
Еще одна ересть, особенно последняя фраза!
В ТЗ пишут не с "ГОСТ И ЕСКД", а конкретный перечень стандартов, выполнить требования которых необходимо на этапе разработки проектной и рабочей документации. Отдельный ГОСТ на разработку ТЗ на создание АСУТП четко регламентирует определенный набор требований к: структуре, надежности, безопасности, эргономике и пр. и пр.
ГОСТы и ЕСКД:
не определяют архитектуру АСУ ТП — они не отвечают на вопрос, как и для чего делить систему на зоны, ячейки и оборудование, где проходят границы ответственности и как связаны между собой элементы управления
Архитектуру конерктной АСУ ТП определяет проект. Баста!
Скрытый текст
Есть в природе стандарты, в которых описана архитектура, например: РД 153-34.1-35.127-2002 "Общие требования к АСУ ТП ТЭС", РД 153-34.1-35.137-00 "ТТ к подсистеме технолог. защит"
Сделать АСУ ТП не по ГОСТу практически невозможно — он слишком общий и не накладывает реальных ограничений
Да будет Вам известно, что цель создания ГОСТ совсем другая. Вот для сведения структура документов по стандартизации согласно 162-ФЗ.
Стандарты формируют требования государства к качеству продукции, работ и услуг
ЕСКД в контексте АСУ ТП — отдельная проблема.
Это стандарт, созданный для конструкторской документации прошлого века.
Документация, выполненная строго по ЕСКД:...
КД - это шкафы, оборудование, "железо". О какой логике работы системы, PLC и HMI Вы пишите? Для описания всего этого ГОСТ серии 34 регламентирует наличие соответствующих разделов и документов техно-рабочего проекта. Всё уже дано изобретено и, к счастью, работает. А где конкретного заказчика не устраивает, он разрабатывает свои корпоративные стандарты, а-ля, "общие технические требования к разработке автоматизированных систем управления...".
На практике такую документацию либо не открывают вовсе, либо открывают один раз — и больше к ней не возвращаются
Очень жаль, что Ваша "практика" не "видела" больше "одного раза". В иной, действительной, реальности в КД "заглядывают" чаще. Хотя бы исходя из планового регламента её проверки и соответствия реальному "положению дел".
Эти KPI противоречат друг другу по умолчанию.
В приведенных Вами перечислений нет НИ ОДНОГО конфликтующего друг с другом. Быстрее - не значит "хуже" и "непонятнее для эксплуатации".
Стандарты АСУ ТП не могут эффективно разрабатываться интеграторами ...
...
Рабочие стандарты могут разрабатывать только инженеры
Вы "мухи" и "котлеты" сравниваете: интегратора и инженеров )))) Так, для справки, инженеры работают и у интеграторов. Я знаю одного мощного интегратора, который разработал целый массив стандартов для одной крупной компании с Дальнего Востока. И ничего, приняли, работают, проекты разрабатывают и внедряют.
Так что Ваше обобщение - это просто Ваше частное мнение.
Из этого комментария хорошо видно одно: мы говорим о разных реальностях.
Вы рассуждаете из позиции нормативных документов, формальных ролей и «как должно быть».
Я — из позиции реальной эксплуатации промышленного оборудования.
Давайте зафиксируем несколько принципиальных моментов, чтобы дальше не спорить о терминах, а говорить о реальной эксплуатации.
1. Что значит “инженер обслуживает завод”
Речь не о том, что один человек физически делает всё.
Речь о том, что для решения любой проблемы ему не нужно никому звонить, искать “того самого специалиста” или ждать подрядчика.
В реальной практике (особенно в России):
ночью инженер на смене часто один кто может принимать решения;
он первым приходит на аварию;
без его понимания логики системы работа не начинается;
механики и электрики действуют по его указаниям.
Это не теория и не «ущербная практика», а повседневная реальность большинства промышленных предприятий.
И именно в этой реальности становится понятно, обслуживаемая система или нет.
2. “Всё решает уровень специалистов” — опасная иллюзия
Да, сильный специалист может «вывозить на опыте».
Но система, которая держится на опыте отдельных людей, неустойчива по определению.
Это означает:
уход человека = потеря знаний;
рост нагрузки = выгорание;
масштабирование = невозможность повторить результат.
Стандарт нужен не для того, чтобы заменить специалистов,
а для того, чтобы их знания перестали быть единственной точкой отказа.
3. Про ГОСТы, ЕСКД и подмену понятий
ГОСТы серий 34, 19 и ЕСКД — нужны.
Они задают нормативный минимум и правила оформления. С этим никто не спорит.
Проблема в другом — в подмене понятий, которая массово происходит на практике.
Когда в ТЗ пишут «выполнить по ГОСТ и ЕСКД»,
очень часто считают, что:
архитектура автоматически правильная;
система автоматически качественная;
эксплуатация автоматически обеспечена.
Это неверно.
ГОСТы:
не задают архитектуру АСУ ТП;
не регламентируют структуру PLC-кода;
не описывают диагностику как инструмент эксплуатации;
не обеспечивают повторяемость решений между проектами.
Они сознательно этого не делают — и это нормально.
Но они и не могут заменить корпоративный стандарт АСУ ТП, ориентированный на жизненный цикл.
4. Документация по ЕСКД — отдельная боль эксплуатации
Проблема такой документации не только в том, что она «не помогает»,
а в том, что она часто объективно неудобна и плохо применима в реальной работе.
Простейший пример из эксплуатации:
в электрических схемах нет обязательной координатной сетки;
нет однозначной привязки элемента к шкафу и месту установки;
держа лист схемы в руках, невозможно понять, куда идти и что искать.
Инженер в аварии должен ответить на вопрос:
где этот элемент физически находится прямо сейчас.
Документация по ЕСКД на этот вопрос чаще всего не отвечает.
Формально она корректна, но как навигационный инструмент — бесполезна.
А время при этом тикает.
Оборудование стоит.
Производство теряет деньги.
Это не вопрос вкуса. Это вопрос пригодности документации к реальной эксплуатации.
5. Про архитектуру и проекты
Да, архитектуру конкретной АСУ ТП определяет проект.
Но тогда возникает следующий вопрос:
кто определяет архитектуру всех проектов на предприятии?
ГОСТ — не определяет.
Каждый проект — определяет только себя.
Если нет корпоративного стандарта:
каждый проект уникален;
каждый подрядчик делает по-своему;
каждую проблему приходится решать заново.
Именно это и приводит к ситуации, когда:
решения не тиражируются;
модернизация становится риском;
система живёт «пока помнят люди».
Речь в статье не о том, что:
ГОСТы плохие (хотя это действительно так);
документация не нужна;
специалисты не важны.
Речь о том, что:
ГОСТ — это минимум;
документация — это следствие архитектуры;
уровень специалистов не должен быть единственной страховкой системы.
Корпоративный стандарт АСУ ТП нужен не «вместо», а поверх ГОСТов —
чтобы система была:
обслуживаемой;
масштабируемой;
понятной без автора проекта;
жизнеспособной через 5–10–20 лет.
И пока предприятия продолжают путать нормативный минимум с архитектурным стандартом, они будут получать ровно то, что получают сегодня:
документы есть, специалисты сильные — а система всё равно держится на людях, а не на правилах.
И ещё один важный момент, который почему-то постоянно ускользает из подобных обсуждений.
Корпоративный стандарт — это и есть best practice.
Причём не «чья-то фантазия», а нормальная мировая практика крупных промышленных компаний.
Во всём мире:
автомобильная промышленность,
нефтехимия,
энергетика,
горнодобывающая отрасль,
работают не по принципу «каждый проект уникален», а по принципу:
единая архитектура,
единые правила построения,
единые требования к коду, диагностике и документации.
Именно поэтому у них:
решения тиражируются между заводами;
инженеры могут переходить между площадками;
уход подрядчика или вендора не означает катастрофу;
модернизация не превращается в полный реинжиниринг.
Никто не называет это «навязыванием».
Это называется управление жизненным циклом систем.
Когда корпоративного стандарта нет, предприятие каждый раз:
изобретает архитектуру заново;
платит за обучение снова;
повторяет одни и те же ошибки;
и в итоге «вывозит на опыте» отдельных людей.
Поэтому корпоративный стандарт АСУ ТП — это не частное мнение и не избыточная бюрократия.
Это концентрированный опыт эксплуатации, оформленный в правила.
И именно так выглядит best practice — не в документах «как должно быть», а в системах, которые работают годами без героизма.
Отдельно зафиксирую, откуда вообще взялось это «частное мнение».
Оно сформировалось не из теории и не из чтения стандартов, а из реального опыта работы в американский, европейских и российских.
Я реально работал:
на предприятиях с жёсткими корпоративными стандартами АСУ ТП,
и на предприятиях, где стандартов не было вовсе или они существовали формально.
И разница между этими мирами колоссальная и хорошо наблюдаемая на практике.
Там, где стандарт есть:
проекты повторяемы;
архитектура предсказуема;
инженер может разобраться в системе без автора;
модернизации делаются без страха;
уход подрядчика или специалиста не ломает систему.
Там, где стандарта нет:
каждый проект уникален;
эксплуатация держится на конкретных людях;
документация существует отдельно от реальной работы;
ночью инженер остаётся один на один с системой;
любое изменение — риск.
Поэтому это действительно частное мнение — но частное мнение человека, который видел обе стороны: и работу «по стандарту», и работу «на опыте».
И именно этот контраст и стал причиной написания статьи.
Речь о том, что для решения любой проблемы ему не нужно никому звонить, искать “того самого специалиста” или ждать подрядчика
Так так и пишите, однозначно и без "читайте между строк". Вы же, я надеюсь, технарь.
Но система, которая держится на опыте отдельных людей, неустойчива по определению.
Соглашусь с Вами. Вы не рассматриваете "темные фабрики", а значит везде имеют место быть неустойчивые системы, ибо есть люди. И никакие стандарты не "закроют" этот вопрос. Снизят риски ошибочных и неэффективных действий - да, однозначно, но не более того. Таким образом, рассматривать систему стандартов на любой этапе её жизненного цикла нужно только с учетом действий человека по отношению к этой системе.
Простейший пример из эксплуатации:
в электрических схемах нет обязательной координатной сетки;
нет однозначной привязки элемента к шкафу и месту установки;
держа лист схемы в руках, невозможно понять, куда идти и что искать.
Это только Ваш неудачный опыт. Так и пишите, нечего обобщать. Я имел дело с документацией систем автоматизации в различных отраслях экономики и знаю, что, например, документация проектов систем железнодорожной автоматики и телемеханики удобна и прозрачна.
кто определяет архитектуру всех проектов на предприятии?
ГОСТ — не определяет.
Каждый проект — определяет только себя.
Вы работали с объектами тепловой энергетики - АСУ тепломеханического оборудования? Видели ГОСТы, РД, связанные с этими объектами? Там много чего, включая и архитектуру самих АСУТП.
При этом, чего там нет, так это указанных Вами требований к программному обеспечению.
Я реально работал:
на предприятиях с жёсткими корпоративными стандартами АСУ ТП,
и на предприятиях, где стандартов не было вовсе или они существовали формально.
Не могу Вам ничего навязывать, просто считаю, что следовало бы "во первых строках" сообщить уважаемому сообществу, кто Вы и какой у Вас опыт, дабы сразу снять вопросы и додумки относительно ниже написанного.
Жизненно написано. По сути желаемый автором стандарт АСУ ТП предприятия должен излагаться в Техническом Задании, Задании на проектирование, т.е. договорных документах для Интегратора. Жить на предприятии стандарт может в виде "Технических требований к АСУ ТП", которые ещё и могут пересматриваться. Соответственно стандарт АСУ ТП предприятия должен вестись теми людьми, что готовят/владеют ТЗ и ЗП. Скорее всего это главный инженер и его замы, ведущие специалисты по АСУ ТП. Если всем интеграторам будет выставляться схожее и в достаточной мере конкретное ТЗ - будет получен схожий результат.
Если же договорной работой занимаются юристы и получают для вставки в договор некую отписку "делать по ГОСТ и ЕСКД", тогда получается как получается.
Кроме того проект АСУ ТП должен согласовываться, проверяться на соответствие ТЗ, ЗП, ТТ и это тоже работа.
Почему стандарт должен быть выше проекта