Это не теоретические рассуждения о будущем промышленной автоматизации. Именно такие вопросы возникают у компаний, которые проектируют, внедряют и эксплуатируют системы управления на крупных промышленных объектах. В интервью Артём Кононов – генеральный директор компании ИНСОФТ предлагает посмотреть на концепцию открытой АСУ ТП с позиции интегратора, для которого надёжность системы – не декларация в техническом описании, а ответственность за реальную работу объекта.
За этим разговором стоит показательный профессиональный путь: от многолетнего внедрения систем Siemens до создания российских решений для крупной электроэнергетики. С 2016 года команда последовательно развивает направление отечественной автоматизации. Среди реализованных проектов — Балаклавская и Таврическая электростанции, где объём обработки достигал 4 млн тегов при 33 тыс. физических входов и выходов. На этих объектах впоследствии была внедрена Альфа платформа Атомик Софт, ставшая программным фундаментом кроссплатформенного ПТК «ИНКОНТ».
Но главный предмет разговора — не история импортозамещения и не сравнение отечественных продуктов с зарубежными аналогами. Гораздо интереснее то, какие противоречия обнаруживаются, когда принципы открытости пытаются применить к сложным и ответственным системам управления.
Представим, что заказчик получает возможность самостоятельно выбирать контроллеры, программные компоненты и другие элементы АСУ ТП из доверенного репозитория. Кто проверит их совместимость? Кто гарантирует работоспособность всей системы? И кто будет нести юридическую и финансовую ответственность, если что-то пойдёт не так?
На первый взгляд, ответ очевиден: интегратор, который собрал систему. Но здесь возникает следующая проблема. Разработчик отдельного компонента может поставлять его по принципу «как есть», не принимая на себя обязательств за работу в составе чужого комплекса. Значит, интегратору придётся самостоятельно проводить экспертизу, испытания и проверку совместимости, а затем отвечать за результат. Не окажется ли такая модель слишком затратной и рискованной, особенно для небольших компаний?
Ещё сложнее ситуация с системами повышенной безопасности. Можно ли требовать открытости интерфейсов и шин от сертифицированного продукта SIL-3? Если изменение интерфейса фактически означает создание нового продукта, не придётся ли заново проходить весь путь оценки соответствия и сертификации? И где в таком случае заканчивается открытая архитектура и начинается ответственность конкретного разработчика?
В интервью поднимается и менее очевидное противоречие. Открытость должна расширить возможности заказчика и интеграторов, обеспечить взаимозаменяемость компонентов и снизить зависимость от отдельных поставщиков. Но если каждый интегратор будет самостоятельно собирать, проверять и сертифицировать собственную систему, не получим ли мы множество уникальных решений вместо типизированных и многократно проверенных продуктов? Где тогда окажутся экономия на масштабе, накопленная статистика эксплуатации и эффект многолетней отработки платформ?
Собеседник противопоставляет этой модели собственный опыт построения кроссплатформенного комплекса, в котором возможность замены отдельных аппаратных компонентов закладывалась изначально. Он объясняет, почему для крупных объектов с высокими требованиями к отказоустойчивости принципиально важно сохранять единую ответственность за конечный результат, и почему универсального ответа на вопрос об открытости, вероятно, не существует.
Отдельный интерес представляет взгляд на российский рынок: действительно ли открытая АСУ ТП станет возможностью для небольших интеграторов или преимущество получат крупные компании, способные принять на себя всю полноту ответственности? Почему интересы заказчика, разработчика и интегратора в этом вопросе могут оказаться противоположными? И как оценивать экономическую целесообразность разных моделей, если затраты на проверку совместимости никуда не исчезают, а лишь перемещаются от одного участника проекта к другому?
В разговоре также затрагиваются практические результаты применения российских контроллеров, программных платформ и средств автоматизации, развитие Альфа платформы и необходимость согласования единых стандартов, протоколов и интерфейсов.
Можно ли построить открытую АСУ ТП, в которой заказчик действительно свободен в выборе, компоненты взаимозаменяемы, а ответственность за надёжность не размывается между десятками участников? Или для наиболее ответственных объектов единственным разумным решением останется модель единого поставщика полного цикла?
У собеседника нет готового универсального рецепта. Зато есть практический опыт, конкретные аргументы и вопросы, которые отрасли ещё предстоит разрешить. Именно поэтому это интервью стоит прочитать всем, кто участвует в разработке, проектировании, внедрении и эксплуатации современных систем промышленной автоматизации.
Интервью и его транскрипция
Медиапортал СЭТА
СМОТРИТЕ интервью на канале СЭТА
VK видео | RUTUBE | YouTube | ДЗЕН
© СТА-ПРЕСС, 2026
За этим разговором стоит показательный профессиональный путь: от многолетнего внедрения систем Siemens до создания российских решений для крупной электроэнергетики. С 2016 года команда последовательно развивает направление отечественной автоматизации. Среди реализованных проектов — Балаклавская и Таврическая электростанции, где объём обработки достигал 4 млн тегов при 33 тыс. физических входов и выходов. На этих объектах впоследствии была внедрена Альфа платформа Атомик Софт, ставшая программным фундаментом кроссплатформенного ПТК «ИНКОНТ».
Но главный предмет разговора — не история импортозамещения и не сравнение отечественных продуктов с зарубежными аналогами. Гораздо интереснее то, какие противоречия обнаруживаются, когда принципы открытости пытаются применить к сложным и ответственным системам управления.
Представим, что заказчик получает возможность самостоятельно выбирать контроллеры, программные компоненты и другие элементы АСУ ТП из доверенного репозитория. Кто проверит их совместимость? Кто гарантирует работоспособность всей системы? И кто будет нести юридическую и финансовую ответственность, если что-то пойдёт не так?
На первый взгляд, ответ очевиден: интегратор, который собрал систему. Но здесь возникает следующая проблема. Разработчик отдельного компонента может поставлять его по принципу «как есть», не принимая на себя обязательств за работу в составе чужого комплекса. Значит, интегратору придётся самостоятельно проводить экспертизу, испытания и проверку совместимости, а затем отвечать за результат. Не окажется ли такая модель слишком затратной и рискованной, особенно для небольших компаний?
Ещё сложнее ситуация с системами повышенной безопасности. Можно ли требовать открытости интерфейсов и шин от сертифицированного продукта SIL-3? Если изменение интерфейса фактически означает создание нового продукта, не придётся ли заново проходить весь путь оценки соответствия и сертификации? И где в таком случае заканчивается открытая архитектура и начинается ответственность конкретного разработчика?
В интервью поднимается и менее очевидное противоречие. Открытость должна расширить возможности заказчика и интеграторов, обеспечить взаимозаменяемость компонентов и снизить зависимость от отдельных поставщиков. Но если каждый интегратор будет самостоятельно собирать, проверять и сертифицировать собственную систему, не получим ли мы множество уникальных решений вместо типизированных и многократно проверенных продуктов? Где тогда окажутся экономия на масштабе, накопленная статистика эксплуатации и эффект многолетней отработки платформ?
Собеседник противопоставляет этой модели собственный опыт построения кроссплатформенного комплекса, в котором возможность замены отдельных аппаратных компонентов закладывалась изначально. Он объясняет, почему для крупных объектов с высокими требованиями к отказоустойчивости принципиально важно сохранять единую ответственность за конечный результат, и почему универсального ответа на вопрос об открытости, вероятно, не существует.
Отдельный интерес представляет взгляд на российский рынок: действительно ли открытая АСУ ТП станет возможностью для небольших интеграторов или преимущество получат крупные компании, способные принять на себя всю полноту ответственности? Почему интересы заказчика, разработчика и интегратора в этом вопросе могут оказаться противоположными? И как оценивать экономическую целесообразность разных моделей, если затраты на проверку совместимости никуда не исчезают, а лишь перемещаются от одного участника проекта к другому?
В разговоре также затрагиваются практические результаты применения российских контроллеров, программных платформ и средств автоматизации, развитие Альфа платформы и необходимость согласования единых стандартов, протоколов и интерфейсов.
Можно ли построить открытую АСУ ТП, в которой заказчик действительно свободен в выборе, компоненты взаимозаменяемы, а ответственность за надёжность не размывается между десятками участников? Или для наиболее ответственных объектов единственным разумным решением останется модель единого поставщика полного цикла?
У собеседника нет готового универсального рецепта. Зато есть практический опыт, конкретные аргументы и вопросы, которые отрасли ещё предстоит разрешить. Именно поэтому это интервью стоит прочитать всем, кто участвует в разработке, проектировании, внедрении и эксплуатации современных систем промышленной автоматизации.
Интервью и его транскрипция
Медиапортал СЭТА
СМОТРИТЕ интервью на канале СЭТА
VK видео | RUTUBE | YouTube | ДЗЕН
© СТА-ПРЕСС, 2026
Если вам понравился материал, кликните значок — вы поможете нам узнать, каким статьям и новостям следует отдавать предпочтение. Если вы хотите обсудить материал —не стесняйтесь оставлять свои комментарии : возможно, они будут полезны другим нашим читателям!
