Ок, хозяин-барин. По существу: 1. Рейтинг без четко установленных критериев выборки. 2. Не указано про наличие ПО в реестре Минцифры. 3. Не указано про реализованный функционал защиты информации. 4. Не указано про сами компании-разработчики в плане скилов по РБПО и DevSecOps.
"Атомик софт" - это не интегратор, а вендор. И никакой не карманный по отношению с Транснефти. И Вы ошибаетесь насчет "неизвестна". Скорее это Вы смотрите узко относительно рынка АСУТП. Имея более чем "ядровую" выручку за 2024 год, быть "неизвестной" невозможно. Компания разрабатывает как собственное, так и OEM-ые SCADA-решения, а также имеет собственных дистрибьютеров, партнеров и системных интеграторов.
Разработчик TRACE MODE - ООО "АдАстра Рисерч Груп" даже близко не стоит по объемам продаж, это видно из открытой финансовой информации.
Речь о том, что для решения любой проблемы ему не нужно никому звонить, искать “того самого специалиста” или ждать подрядчика
Так так и пишите, однозначно и без "читайте между строк". Вы же, я надеюсь, технарь.
Но система, которая держится на опыте отдельных людей, неустойчива по определению.
Соглашусь с Вами. Вы не рассматриваете "темные фабрики", а значит везде имеют место быть неустойчивые системы, ибо есть люди. И никакие стандарты не "закроют" этот вопрос. Снизят риски ошибочных и неэффективных действий - да, однозначно, но не более того. Таким образом, рассматривать систему стандартов на любой этапе её жизненного цикла нужно только с учетом действий человека по отношению к этой системе.
Простейший пример из эксплуатации:
в электрических схемах нет обязательной координатной сетки;
нет однозначной привязки элемента к шкафу и месту установки;
держа лист схемы в руках, невозможно понять, куда идти и что искать.
Это только Ваш неудачный опыт. Так и пишите, нечего обобщать. Я имел дело с документацией систем автоматизации в различных отраслях экономики и знаю, что, например, документация проектов систем железнодорожной автоматики и телемеханики удобна и прозрачна.
кто определяет архитектуру всех проектов на предприятии?
ГОСТ — не определяет.
Каждый проект — определяет только себя.
Вы работали с объектами тепловой энергетики - АСУ тепломеханического оборудования? Видели ГОСТы, РД, связанные с этими объектами? Там много чего, включая и архитектуру самих АСУТП.
При этом, чего там нет, так это указанных Вами требований к программному обеспечению.
Я реально работал:
на предприятиях с жёсткими корпоративными стандартами АСУ ТП,
и на предприятиях, где стандартов не было вовсе или они существовали формально.
Не могу Вам ничего навязывать, просто считаю, что следовало бы "во первых строках" сообщить уважаемому сообществу, кто Вы и какой у Вас опыт, дабы сразу снять вопросы и додумки относительно ниже написанного.
Ох и покритикую я сейчас это частное мнение, выставляемое напоказ.
Если стандарта нет — может пройти год и больше, прежде чем человек сможет в одиночку обслуживать завод без постоянного риска что-то сломать
Да какая ересть! Никакой инженер не может обслуживать "никакой" завод "в одну каску". Практика "и жнец и на дуде игрец" крайне ущербна.
Разница между этими сценариями не в уровне специалистов, а в том, есть ли на предприятии система или только набор проектов
В конечном итоге, на предприятии, именно уровень специалистов является определяющим. Даже при "плохой мине" опытный сотрудник может поддерживать безаварийную работу сложного технологического оборудования, вывозя всё и вся "на классе". Не оцениваю, плохо ли это или хорошо, просто как мнение.
ГОСТ и ЕСКД — это не стандарты АСУ ТП
В технических заданиях до сих пор часто можно увидеть формулировку:
«Проект выполнить в соответствии с ГОСТ и ЕСКД».
По сути, это равнозначно фразе: «Делайте как хотите».
Еще одна ересть, особенно последняя фраза!
В ТЗ пишут не с "ГОСТ И ЕСКД", а конкретный перечень стандартов, выполнить требования которых необходимо на этапе разработки проектной и рабочей документации. Отдельный ГОСТ на разработку ТЗ на создание АСУТП четко регламентирует определенный набор требований к: структуре, надежности, безопасности, эргономике и пр. и пр.
ГОСТы и ЕСКД:
не определяют архитектуру АСУ ТП — они не отвечают на вопрос, как и для чего делить систему на зоны, ячейки и оборудование, где проходят границы ответственности и как связаны между собой элементы управления
Архитектуру конерктной АСУ ТП определяет проект. Баста!
Скрытый текст
Есть в природе стандарты, в которых описана архитектура, например: РД 153-34.1-35.127-2002 "Общие требования к АСУ ТП ТЭС", РД 153-34.1-35.137-00 "ТТ к подсистеме технолог. защит"
Сделать АСУ ТП не по ГОСТу практически невозможно — он слишком общий и не накладывает реальных ограничений
Да будет Вам известно, что цель создания ГОСТ совсем другая. Вот для сведения структура документов по стандартизации согласно 162-ФЗ.
Стандарты формируют требования государства к качеству продукции, работ и услуг
ЕСКД в контексте АСУ ТП — отдельная проблема.
Это стандарт, созданный для конструкторской документации прошлого века.
Документация, выполненная строго по ЕСКД:...
КД - это шкафы, оборудование, "железо". О какой логике работы системы, PLC и HMI Вы пишите? Для описания всего этого ГОСТ серии 34 регламентирует наличие соответствующих разделов и документов техно-рабочего проекта. Всё уже дано изобретено и, к счастью, работает. А где конкретного заказчика не устраивает, он разрабатывает свои корпоративные стандарты, а-ля, "общие технические требования к разработке автоматизированных систем управления...".
На практике такую документацию либо не открывают вовсе, либо открывают один раз — и больше к ней не возвращаются
Очень жаль, что Ваша "практика" не "видела" больше "одного раза". В иной, действительной, реальности в КД "заглядывают" чаще. Хотя бы исходя из планового регламента её проверки и соответствия реальному "положению дел".
Эти KPI противоречат друг другу по умолчанию.
В приведенных Вами перечислений нет НИ ОДНОГО конфликтующего друг с другом. Быстрее - не значит "хуже" и "непонятнее для эксплуатации".
Стандарты АСУ ТП не могут эффективно разрабатываться интеграторами ...
...
Рабочие стандарты могут разрабатывать только инженеры
Вы "мухи" и "котлеты" сравниваете: интегратора и инженеров )))) Так, для справки, инженеры работают и у интеграторов. Я знаю одного мощного интегратора, который разработал целый массив стандартов для одной крупной компании с Дальнего Востока. И ничего, приняли, работают, проекты разрабатывают и внедряют.
Так что Ваше обобщение - это просто Ваше частное мнение.
Приведите анализ двух-трех стандартов, чтобы подтвердить Вашу точку зрения про "специфику программирования".
Само наличие стандартов говорит, как минимум о том, что компания, принявшая их, решила упорядочить и систематизировать свои рабочие и производственные процессы. А это уже немало.
Автор, не знаю, откуда Вы брали столь скудную информацию об отечественной стандартизации в АСУ ТП. Впечатление такое, что имеют место быть лишь поверхностные знания.
РЖД уже много десятков лет "живет" со своей четко отлаженной системой стандартов, типовых проектных решений и т. д. и т. п. Один корпоративный стандарт СТО РЖД 1.19.005-2008 "Системы и устройства железнодорожной автоматики и телемеханики. Условные графические изображения" чего стоит.
Транснефть имеет четко выверенную систему стандартов, отлаженный порядок работы как с вендорами, так и с системными интеграторами.
И наконец, вообще ничего не указано про отраслевую стандартизацию в нефтегазе "под флагом" АНО "ИНТИ". А там более 250 стандартов, система оценки вендоров, система оценки СМК, система проведения отраслевых испытаний.
Ставлю жиииирнющий "минус" автору статьи за бездарную подачу материала, результатом которой являются комментарии, с которыми бОльшей частью согласен.
Первое и главное при писательстве подобных текстов - крайне отчётливо представлять целевую аудиторию. А лучше в первом-втором абзаце в явном виде указывать, для кого написан нижеприведенный текст.
Иначе прочитав статью, получаешь непозитивный осадочек из серии "очередная рекламщина".
А теперь по сути:
Абсолютно нет никакой привязки к общефедеральному законодательству и того, что "хочет регулятор". Ни про ПП1912, ни про Указ Президента № 250. Ничего. Сложилось впечатление, что ой, иностранные вендоры ушли, как же плохо. А давайте-ка сделаем что-то своё! Ау, про технологическую независимость слышали?
"Открытость" не значит "Бесплатность", это все должны прекрасно понимать. Ничего не сказано, что коммерческий интерес зарубежных вендоров, а жаль. Уверен, что бессеребренников там нет.
Сразу обращает внимание на то, что автор не проводит какой-либо анализ существующих DCS и выделения общих характеристик, а голословно пишет про их недостатки и слабые места, чтобы, в дальнейшем, вполне логично рассказать про решение отдельного китайского вендора.
Абсолютно нет какой-либо привязки к реалиям отечественного рынка АСУТП и отраслям промышленности. Термин "обрабатывающая" слишком широк.
Алексей, спасибо за рекомендацию книги, обязательно прочитаю.
Согласен с тем, что писательство - это труд и что нужно заставлять себя этим заниматься, особенно, если для тебя это не основная сфера деятельности.
Интересно, было ли у Вас такое: написал несколько страниц, а потом, спустя, например, неделю или две вернулся к ним, увидел, что написано "некрасиво", и переписал?
Считаю, что срач из-за подачи исходного материала. Статьи непродуманные в плане целевой аудитории.
Ну Вы что))))
Больше продаж - больше инсталляций - больше внедрений.
Ок, хозяин-барин.
По существу:
1. Рейтинг без четко установленных критериев выборки.
2. Не указано про наличие ПО в реестре Минцифры.
3. Не указано про реализованный функционал защиты информации.
4. Не указано про сами компании-разработчики в плане скилов по РБПО и DevSecOps.
"Атомик софт" - это не интегратор, а вендор. И никакой не карманный по отношению с Транснефти.
И Вы ошибаетесь насчет "неизвестна". Скорее это Вы смотрите узко относительно рынка АСУТП. Имея более чем "ядровую" выручку за 2024 год, быть "неизвестной" невозможно. Компания разрабатывает как собственное, так и OEM-ые SCADA-решения, а также имеет собственных дистрибьютеров, партнеров и системных интеграторов.
Разработчик TRACE MODE - ООО "АдАстра Рисерч Груп" даже близко не стоит по объемам продаж, это видно из открытой финансовой информации.
Человек опирался на "наблюдение и опыт". Остальное неважно.
Плюсом сразу задал тренд на весь 2026 год
Аааа, мухи и котлеты. Достойно
На основании каких критериев был сформирован именно этот перечень ПО?
Так так и пишите, однозначно и без "читайте между строк". Вы же, я надеюсь, технарь.
Соглашусь с Вами. Вы не рассматриваете "темные фабрики", а значит везде имеют место быть неустойчивые системы, ибо есть люди. И никакие стандарты не "закроют" этот вопрос. Снизят риски ошибочных и неэффективных действий - да, однозначно, но не более того. Таким образом, рассматривать систему стандартов на любой этапе её жизненного цикла нужно только с учетом действий человека по отношению к этой системе.
Это только Ваш неудачный опыт. Так и пишите, нечего обобщать. Я имел дело с документацией систем автоматизации в различных отраслях экономики и знаю, что, например, документация проектов систем железнодорожной автоматики и телемеханики удобна и прозрачна.
Вы работали с объектами тепловой энергетики - АСУ тепломеханического оборудования? Видели ГОСТы, РД, связанные с этими объектами? Там много чего, включая и архитектуру самих АСУТП.
При этом, чего там нет, так это указанных Вами требований к программному обеспечению.
Не могу Вам ничего навязывать, просто считаю, что следовало бы "во первых строках" сообщить уважаемому сообществу, кто Вы и какой у Вас опыт, дабы сразу снять вопросы и додумки относительно ниже написанного.
Ох и покритикую я сейчас это частное мнение, выставляемое напоказ.
Да какая ересть! Никакой инженер не может обслуживать "никакой" завод "в одну каску". Практика "и жнец и на дуде игрец" крайне ущербна.
В конечном итоге, на предприятии, именно уровень специалистов является определяющим. Даже при "плохой мине" опытный сотрудник может поддерживать безаварийную работу сложного технологического оборудования, вывозя всё и вся "на классе". Не оцениваю, плохо ли это или хорошо, просто как мнение.
Еще одна ересть, особенно последняя фраза!
В ТЗ пишут не с "ГОСТ И ЕСКД", а конкретный перечень стандартов, выполнить требования которых необходимо на этапе разработки проектной и рабочей документации. Отдельный ГОСТ на разработку ТЗ на создание АСУТП четко регламентирует определенный набор требований к: структуре, надежности, безопасности, эргономике и пр. и пр.
Архитектуру конерктной АСУ ТП определяет проект. Баста!
Скрытый текст
Есть в природе стандарты, в которых описана архитектура, например: РД 153-34.1-35.127-2002 "Общие требования к АСУ ТП ТЭС", РД 153-34.1-35.137-00 "ТТ к подсистеме технолог. защит"
Да будет Вам известно, что цель создания ГОСТ совсем другая. Вот для сведения структура документов по стандартизации согласно 162-ФЗ.
Стандарты формируют требования государства к качеству продукции, работ и услуг
КД - это шкафы, оборудование, "железо". О какой логике работы системы, PLC и HMI Вы пишите? Для описания всего этого ГОСТ серии 34 регламентирует наличие соответствующих разделов и документов техно-рабочего проекта. Всё уже дано изобретено и, к счастью, работает. А где конкретного заказчика не устраивает, он разрабатывает свои корпоративные стандарты, а-ля, "общие технические требования к разработке автоматизированных систем управления...".
Очень жаль, что Ваша "практика" не "видела" больше "одного раза". В иной, действительной, реальности в КД "заглядывают" чаще. Хотя бы исходя из планового регламента её проверки и соответствия реальному "положению дел".
В приведенных Вами перечислений нет НИ ОДНОГО конфликтующего друг с другом. Быстрее - не значит "хуже" и "непонятнее для эксплуатации".
Вы "мухи" и "котлеты" сравниваете: интегратора и инженеров )))) Так, для справки, инженеры работают и у интеграторов. Я знаю одного мощного интегратора, который разработал целый массив стандартов для одной крупной компании с Дальнего Востока. И ничего, приняли, работают, проекты разрабатывают и внедряют.
Так что Ваше обобщение - это просто Ваше частное мнение.
Пффф, да Вы еще и старую информацию транслируйте...
Приведите анализ двух-трех стандартов, чтобы подтвердить Вашу точку зрения про "специфику программирования".
Само наличие стандартов говорит, как минимум о том, что компания, принявшая их, решила упорядочить и систематизировать свои рабочие и производственные процессы. А это уже немало.
Откуда взята информация по Северстали?
Автор, не знаю, откуда Вы брали столь скудную информацию об отечественной стандартизации в АСУ ТП. Впечатление такое, что имеют место быть лишь поверхностные знания.
РЖД уже много десятков лет "живет" со своей четко отлаженной системой стандартов, типовых проектных решений и т. д. и т. п. Один корпоративный стандарт СТО РЖД 1.19.005-2008 "Системы и устройства железнодорожной автоматики и телемеханики. Условные графические изображения" чего стоит.
Транснефть имеет четко выверенную систему стандартов, отлаженный порядок работы как с вендорами, так и с системными интеграторами.
И наконец, вообще ничего не указано про отраслевую стандартизацию в нефтегазе "под флагом" АНО "ИНТИ". А там более 250 стандартов, система оценки вендоров, система оценки СМК, система проведения отраслевых испытаний.
Овен )))) Шутка. Если "сделано в РФ", то только ПЛК REGUL
А что Вы имеете против ж.-д. статей? ))))
Ставлю жиииирнющий "минус" автору статьи за бездарную подачу материала, результатом которой являются комментарии, с которыми бОльшей частью согласен.
Первое и главное при писательстве подобных текстов - крайне отчётливо представлять целевую аудиторию. А лучше в первом-втором абзаце в явном виде указывать, для кого написан нижеприведенный текст.
Иначе прочитав статью, получаешь непозитивный осадочек из серии "очередная рекламщина".
А теперь по сути:
Абсолютно нет никакой привязки к общефедеральному законодательству и того, что "хочет регулятор". Ни про ПП1912, ни про Указ Президента № 250. Ничего. Сложилось впечатление, что ой, иностранные вендоры ушли, как же плохо. А давайте-ка сделаем что-то своё! Ау, про технологическую независимость слышали?
"Открытость" не значит "Бесплатность", это все должны прекрасно понимать. Ничего не сказано, что коммерческий интерес зарубежных вендоров, а жаль. Уверен, что бессеребренников там нет.
Сразу обращает внимание на то, что автор не проводит какой-либо анализ существующих DCS и выделения общих характеристик, а голословно пишет про их недостатки и слабые места, чтобы, в дальнейшем, вполне логично рассказать про решение отдельного китайского вендора.
Абсолютно нет какой-либо привязки к реалиям отечественного рынка АСУТП и отраслям промышленности. Термин "обрабатывающая" слишком широк.
Общий настрой статьи - маркетинг. И зачем такое?
Резюме: не рекомендую к прочтению.
Ни дня без строчки!
Алексей, спасибо за рекомендацию книги, обязательно прочитаю.
Согласен с тем, что писательство - это труд и что нужно заставлять себя этим заниматься, особенно, если для тебя это не основная сфера деятельности.
Интересно, было ли у Вас такое: написал несколько страниц, а потом, спустя, например, неделю или две вернулся к ним, увидел, что написано "некрасиво", и переписал?
Штанген - это конечно база.
До сих пор помню удивление, когда на уроке труда в школе нам объяснили принцип измерения. Просто и гениально.
Абсолютно все. Как и прокурора: "По совокупности".
Один из пяти-шести