Технологический суверенитет не означает полного импортозамещения. Речь про независимость от узкой группы производителей.
Так так и пишите. Частичный технологический суверенитет.
Написано, что вендоры заявляя о своей ответственности за комплексную РСУ забывают про роль системных интеграторов.
И Вы имеете право на эту личную оценку.
Это будет реклама
Это не реклама, а проявление компетенции. На мой взгляд, статьи, подобные Вашей, страдают от того, что авторы завуалированно пишут о каких-либо фактах, событиях, людях, организациях, будучи не готовыми написать про них открыто. Тем более, что такие авторы высказывают собственную точку зрения.
Здравствуйте, Юрий! Спасибо за статью! Давно и с интересом слежу за развитием ОАСУТП. Мои комментарии по написанному
достижение технологического суверенитета в области АСУ ТП
Технологический суверенитет относительно какой структуры: государства, бизнеса в целом, отдельных промышленных компаний?
На данный момент, в области АСУ ТП подобное "отмежевание" технически и технологически не возможно. И никогда не будет реализовано. Те, кто говорит обратное, очевидно не понимают всей подноготной микропроцессорного оборудования и того стека технологий, который используется при разработке ПО.
снижение совокупной стоимости владения АСУ ТП для непрерывных производств
Были ли исследования относительно этого? Технико-экономическое обоснование, расчеты, статистика... Понятно, что информация не носит открытый характер, но всё-таки.
С техническим описанием архитектуры на русском языке можно ознакомиться в документе: ПНСТ «Системы киберфизические. Открытые системы промышленной автоматизации. ОТКРЫТЫЕ РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ. Общая архитектура, интерфейсы и основные требования». Документ доступен для скачивания на сайте ТК 194
Вы знаете, почему стандарт по открытой РСУ был разработан на базе ТК, который к АСУ ТП имеет, скажем так, никакое отношение?
...вендор занимается разработкой и производством продуктов, а интегратор — созданием и сопровождением комплексных решений
Так это уже сейчас есть и работает. И декларируемый Вами принцип "открытости" здесь вообще не нужен.
Вендор - разработчик ПЛК, SCADA и/или ПТК, несет ответственность за разработанное решение, в то время, как системный инегратор несет ответственность за АСУ ТП, разработанную на базе продуктов вендора. Интегратору проще, быстрее, удобнее, дешевле разработать АСУ ТП на базе продуктов одного вендора или нескольких, имеющих подтвержденную совместимость друг с другом, но никак не используя "лоскутное одеяло". Хотя, "одеяло" так и так имеется, ибо компонентов АСУТП большое количество и в каждом проекте они могут быть своими. Но мы же говорим об основных компонентах, без среднего и верхнего уровней АСУ ТП, верно?
Российские вендоры АСУ ТП тут не будут исключением: уже сейчас некоторые оценивают свои новые продукты как практически соответствующие стандартам O‑PAS, и по мере разработки новых поколений степень соответствия будет расти. По крайней мере, у лидеров рынка.
Приведите пожалуйста примеры этих "лидеров рынка". Так сказать, чтобы понимать, кого Вы имеете в виде.
А то, как показала недавно опубликованная статья на Хабре, посвященная рейтингу SCADA, у каждого автора своё понимание "лидеров".
Ок, хозяин-барин. По существу: 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 и выделения общих характеристик, а голословно пишет про их недостатки и слабые места, чтобы, в дальнейшем, вполне логично рассказать про решение отдельного китайского вендора.
Абсолютно нет какой-либо привязки к реалиям отечественного рынка АСУТП и отраслям промышленности. Термин "обрабатывающая" слишком широк.
Алексей, спасибо за рекомендацию книги, обязательно прочитаю.
Согласен с тем, что писательство - это труд и что нужно заставлять себя этим заниматься, особенно, если для тебя это не основная сфера деятельности.
Интересно, было ли у Вас такое: написал несколько страниц, а потом, спустя, например, неделю или две вернулся к ним, увидел, что написано "некрасиво", и переписал?
Так так и пишите. Частичный технологический суверенитет.
И Вы имеете право на эту личную оценку.
Это не реклама, а проявление компетенции. На мой взгляд, статьи, подобные Вашей, страдают от того, что авторы завуалированно пишут о каких-либо фактах, событиях, людях, организациях, будучи не готовыми написать про них открыто. Тем более, что такие авторы высказывают собственную точку зрения.
Вопрос стандартизации и вопрос создания (разработки) РСУ - это, так сказать, два разных человека.
Здравствуйте, Юрий!
Спасибо за статью! Давно и с интересом слежу за развитием ОАСУТП.
Мои комментарии по написанному
Технологический суверенитет относительно какой структуры: государства, бизнеса в целом, отдельных промышленных компаний?
На данный момент, в области АСУ ТП подобное "отмежевание" технически и технологически не возможно. И никогда не будет реализовано. Те, кто говорит обратное, очевидно не понимают всей подноготной микропроцессорного оборудования и того стека технологий, который используется при разработке ПО.
Были ли исследования относительно этого? Технико-экономическое обоснование, расчеты, статистика...
Понятно, что информация не носит открытый характер, но всё-таки.
Вы знаете, почему стандарт по открытой РСУ был разработан на базе ТК, который к АСУ ТП имеет, скажем так, никакое отношение?
Так это уже сейчас есть и работает. И декларируемый Вами принцип "открытости" здесь вообще не нужен.
Вендор - разработчик ПЛК, SCADA и/или ПТК, несет ответственность за разработанное решение, в то время, как системный инегратор несет ответственность за АСУ ТП, разработанную на базе продуктов вендора. Интегратору проще, быстрее, удобнее, дешевле разработать АСУ ТП на базе продуктов одного вендора или нескольких, имеющих подтвержденную совместимость друг с другом, но никак не используя "лоскутное одеяло". Хотя, "одеяло" так и так имеется, ибо компонентов АСУТП большое количество и в каждом проекте они могут быть своими. Но мы же говорим об основных компонентах, без среднего и верхнего уровней АСУ ТП, верно?
Приведите пожалуйста примеры этих "лидеров рынка". Так сказать, чтобы понимать, кого Вы имеете в виде.
А то, как показала недавно опубликованная статья на Хабре, посвященная рейтингу SCADA, у каждого автора своё понимание "лидеров".
Считаю, что срач из-за подачи исходного материала. Статьи непродуманные в плане целевой аудитории.
Ну Вы что))))
Больше продаж - больше инсталляций - больше внедрений.
Ок, хозяин-барин.
По существу:
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 и выделения общих характеристик, а голословно пишет про их недостатки и слабые места, чтобы, в дальнейшем, вполне логично рассказать про решение отдельного китайского вендора.
Абсолютно нет какой-либо привязки к реалиям отечественного рынка АСУТП и отраслям промышленности. Термин "обрабатывающая" слишком широк.
Общий настрой статьи - маркетинг. И зачем такое?
Резюме: не рекомендую к прочтению.
Ни дня без строчки!
Алексей, спасибо за рекомендацию книги, обязательно прочитаю.
Согласен с тем, что писательство - это труд и что нужно заставлять себя этим заниматься, особенно, если для тебя это не основная сфера деятельности.
Интересно, было ли у Вас такое: написал несколько страниц, а потом, спустя, например, неделю или две вернулся к ним, увидел, что написано "некрасиво", и переписал?