Северсталь-Инфоком: нужно формировать отечественную экосистему АСУ ТП

---

Северсталь-Инфоком: нужно формировать отечественную экосистему АСУ ТП

Текст интервью получен посредством автоматического распознавания речи 
и не подвергался редактированию, в связи с чем возможны ошибки и неточности.

Что за мероприятие все-таки здесь у нас сейчас происходит, чему оно посвящено?

Оно посвящено презентации разработки прототипа компонента, открытой АСУ ТП. Это рантайм, среда исполнения. Также еще можно назвать это программным ПЛК.

Почему именно программный ПЛК, а не аппаратный, обсуждается? 

Потому что мы видим, что очень хорошо не зависеть от аппаратной платформы. И как раз программный ПЛК тем и хорош, что если вам нужны какие-то ответственные решения, вы покупаете какое-то железо мощное, у вас дорого-богато и надежно. Если у вас какие-то менее ответственные решения, то есть можно купить что-то попроще, и, соответственно, программный ПЛК будет на этой аппаратной платформе, репку купить отечественную и на ней будет тоже работать.

Почему именно Северсталь является "локомотивом" всей этой истории ? Как это получилось исторически вообще?

На самом деле "локомотивом" - громко сказано. Просто получилось, что Северсталь является координатором технической рабочей группы, которая была создана при открытой рабочей группе, открытой АСУ ТП, и является как раз координатором в технической рабочей группе по открытым программам ПЛК и открытой интегрированной среде разработки. И здесь какого-то технического лидерства Северстали нет. Нельзя так говорить, потому что мы очень плотно работаем с коллегами с Норникеля, с Еврахима, с НЛМК, с Газпром. То есть можно перечислять многих. На самом деле технические специалисты очень сильные. И в этой группе мы просто как координаторы. Один из. Поэтому говорить, что мы "локомотив", я так не сказал бы.

Но вообще инициатива достаточно новая. Я так понял, что ей не больше двух лет от роду?

Техническая рабочая группа была создана в 23-м году, в июле. То есть получается чуть больше года. 

И тем не менее такие амбициозные планы анонсируются сейчас, что в 27-м году уже планируются предъявить какие-то рабочие прототипы?

На самом деле планы еще более амбициозные – пробовать показать уже в конце весны 25-го года прототип. Задача – на двух различных аппаратных платформах данный прототип, то есть среду исполнения, портировать на эти две аппаратные платформы и уже показать на стенде.

Стенд будет состоять из какого-то небольшого техпроцесса, например, перекладывателя «Ральганг», бункер какой-то. То есть какой-то небольшой стенд. И этим стендом среда исполнение будет, так скажем, управлять.

Вы анонсировали, что в скором времени она будет представлена публике. Уже, может, не в окончательном, но в каком-то рабочем виде. Это значит, что вы ее начали, наверное, не с нуля разрабатывать?

Все верно, да. Мы тоже смотрели то, что есть на рынке, из open source, то есть из программного обеспечения с открытым исходным кодом. И, наверное, в прототипе мы возьмем что-то уже из этого.

Почему так? Потому что мы понимаем, что нам надо как можно быстрее результат показать, чтобы всех вовлечь, всех заинтересовать. Далее, скорее всего, это будет уже более долгий процесс. Возможно, мы посмотрим все плюсы-минусы. То есть будет полностью переписана среда исполнение уже с применением ПО  с открытым исходным кодом, но уже полностью под свою специфику. Если, показывая прототип, набьем шишек, увидим и поймем, что надо практически все переписать. Мы хотели попробовать среду исполнение от 4diac, то есть 4diac forte, и у них есть определенные проблемы, то есть EPL лицензии. И если мы хотим это реально использовать полностью под себя, то желательно к ней не привязываться, полностью переписать. 

То есть это лицензия для некоммерческого использования?

Ну да, с нюансами по открытию исходного кода. И, соответственно, как у нас все это в стране будет работать, тоже непонятно. Поэтому для прототипа это подойдет. Это как раз быстро показать, вовлечь всех, чтобы все увидели, что действительно это можно сделать. И уже дальше это развивать. 

Что это можно сделать, это и раньше было известно. На самом деле, софт ПЛК это же не новое что-то. 

Согласен. Понимаете, проблема всех софт ПЛК, которые были до этого, они вроде софт ПЛК, но они в итоге по факту являются проприетарными софт ПЛК. То есть они вроде и софт ПЛК, но, так скажем, если он работает на аппаратной платформе Schneider, то на Siemens ты его не поставишь. 

Хочешь не хочешь, все равно каким-то образом какая-то прослойка для привязки к аппаратной платформе должна быть, какие-то драйверы. И если вы делаете универсальный софт ПЛК, и вот эта прослойка, которая будет у вас присутствовать, я так полагаю, тоже может создать для вас некие проблемы. Особенно если дело касается повышенной надежности или реал-тайм. 

Все верно. 

Вот как такие вещи вы тогда будете решать? Вы будете писать свои наборы драйверов под каждую аппаратную платформу? 

Мне на какие-то вопросы на самом деле сложно ответить. Я все-таки не разработчик embedded-решений. Я инженер по автоматизации. Но как мы с коллегами беседовали, я всегда говорю, что с точки зрения именно ПЛК, с точки зрения среды управления, например, дискретный вход, он дискретный вход от любого производителя ПЛК, это дискретный вход, это ноль или единица. То есть и мы считаем, что все-таки мы сможем реализовать такую прослойку, которая будет от конкретного железа абстрагироваться.

То есть по факту для среды исполнения, которая выполняет какую-то функцию, функциональный блок, в итоге считывает образ ходов, выполняет логику, выдает управляющие воздействия на выхода, для нее вход и выход,  это вход и выход. То есть и неважно, кто на этом входе-выходе, плата дискретов от Siemens или от Owen, по большому счету, правильно же? Поэтому мы надеемся, что мы все-таки сможем эту проблему решить.

Было, кстати, еще анонсировано, что к 30-му году вообще планируется массовое внедрение вашего продукта. Насколько это реалистичные планы, на ваш взгляд, с учетом того, что планируется внедрение в очень серьезные отрасли, где критически важные процессы, где очень все должно быть строго и сурово. 

Во-первых, планы, как принято говорить, всегда надо ставить амбициозно, чтобы пытаться добежать до звезд, достичь их, это раз.

Второй момент, как раз мы для этого здесь и собрались. Если мы хотим приблизить это будущее намного быстрее, надо, как вот коллеги уже говорили, двигаться параллельными треками. Понятно, если Северсталь одна будет делать у себя пилот и опробировать эти решения, то, конечно, наработку по часам, по всему, на отказы какие-то мы будем получать очень скудно и очень медленно.

И когда это этим будут заниматься несколько компаний параллельно, конечно, какие-то там ошибки будут вылавливаться быстрее, то есть быстрее будет все это исправляться. Поэтому весь смысл, чтобы открыть исходный код среды исполнения, чтобы кто захочет, возьмет для своей аппаратной платформы, портирует для себя, начнет у себя пробовать. И вот это сообщество быстрее поможет развить продукт и устранить ошибки. И быстрее выход будет тогда. 

С технической точки зрения выгода понятно, конечно. Естественно, любые open-source решения, это сразу большой охват. А вот что касается организационных и финансовых вещей, вот ваш коллега из Ростелекома здесь такую мысль высказал, что, в общем-то, действительно не совсем понятно, а как потом делить успех-то?

Я все-таки буду себя относить к техническим специалистам. Мне на этот вопрос сложно отвечать. Почему? Потому что коллеги прорабатывают сейчас какие формы возможны. Может быть, это будет оператор какой-то, по аналогии, не знаю – хорошая она или нет, с ГЛОНАСом, чтобы был единый оператор какой-то. Может быть, это АНО какое-то, которое именно будет являться правообладателем данных компонентов открытой АСУ ТП. Чем это хорошо? Тем, что мы, технические специалисты, понимаем друг друга, но на уровне уже правления тяжело как-то объяснить, что мы берем у своих конкурентов, у Северсталя, условно, НЛМК или ПМХ, и что-то используем. Они скажут, может, они что-то заложили туда, что они будут катать с такой скоростью, а нам пониже сделают что-то.

Я фантазирую, конечно. То есть будет некое отторжение к нашим решениям. И чтобы такого не было, как раз и есть смысл создать или какого-то оператора, или АНО, которое и будет правовладателем. И ни у кого не будет вот этого отторжения, что я должен брать продукты своего конкурента, якобы конкурента. 

Поэтому, наверное, надо думать, как это сделать правильно, чтобы как раз всем было и выгодно, и отторжения не было. 

Тем более, что крупные участники вот этого проекта вкладывают свои собственные немалые средства в эту разработку. То есть потом они просто отдадут, подарят как бы сообществу ее, несмотря на это. 

Надо понимать, что при этом крупные игроки закрывают множество своих рисков. Это, во-первых, зависимость от иностранных решений. Это жесткое регулирование от правительства, там 1912, то есть по пакам, по доверенным пакам. Сейчас если будут закручиваться гайки, то есть все АСУ ТП станет объектом КИИ, и все. И всех заставят в принудительном порядке переходить. 

То есть вы рынок используете для своих опытов.

Мы понимаем, что мы здесь выгоду тоже преследуем. И опять же, как показывает практика, на каких-то открытых решениях можно очень хорошо зарабатывать. Как Денис Кладяжный, мой коллега, показывал, это та же Кавка, тот же Postgre, Android.

То есть на самом деле можно же зарабатывать на сервисе, на каких-то решениях. Ну вот у кого-то нет желания самому спортировать среду исполнения на свое железо. Ну нет специалистов или просто нет желания. Вот эта услуга, если ты это сделаешь, то ты за это получишь деньги. Опять же, если ты захочешь к среде исполнения или к среде разработки, например, какой-то аддон, плагины разработать, которые, например, мы в технических требованиях, может, даже и не показывали. Может, какую-то киллер-фичу. И ты за это можешь попросить денег. Почему нет? То есть в зависимости, кому нужен данный функционал, он это за деньги может уже приобрести.

Поэтому, на самом деле, это ошибочное мнение, что на программном обеспечении с открытым исходным кодом нельзя зарабатывать. 

Все время речь шла о среде исполнения. А что касается средств разработки. CodeSys, как известно, это вот прям мировой бестселлер в этом смысле программирования PLK. Некоторые проприетарные системы еще, Siemens и прочие держат практически 99% всего рынка. У вас планируется использовать для программирования вашего продукта стандартный какой-то известный программный продукт? Или будет свой тоже? 

Смотрите, на этапе прототипа, если мы берем среду исполнения 4diac forte, соответственно, мы и берем среду разработки 4diac IDE. Но, опять же, это как раз будут дискуссии, это будут дискуссионные вопросы. Мы как раз и хотим здесь какие-то для себя моменты подискутировать, чтобы коллеги поделились своими знаниями, нас предостерегли от каких-то ошибок, поговорить, среда исполнения все-таки намертво гвоздями прибита к среде разработки или нет. Или все-таки может быть несколько сред разработки, может быть несколько сред исполнения. По аналогии с IT миром, Java машина, при этом IDE для того, чтобы фреймворки, IDE, как их ни назови, которые под нее могут какое-то ПO разработать, их же много. Поэтому здесь надо думать об этом. И это даже еще, наверное, более сложный вопрос, чем даже среда исполнения. И как я говорил, мы здесь понимаем, что мы одни, наверное, не сможем возможно даже прототип разработать. Будем стараться, но мы всех привлекаем к участию, чтобы нам помогли и людьми, и ресурсами различными.

Если взять тот же самый CodeSys, о котором мы уже упоминали, он же не прибит гвоздями к конкретному аппаратному контроллеру. С его помощью программируется миллион разных контроллеров. Точно так же, наверное, по аналогии и ваш софт ПЛК должен программироваться независимым инструментом.

Просто должны некие стандарты программирования соблюдаться. Понимаете, CodeSys, мне кажется, не очень корректный пример. Почему? Потому что как раз среда исполнения, как у них таргеты называются под ПЛК, они с определенным тулчейном разрабатываются. Ты можешь делать таргеты для различной аппаратной платформы. Но по факту же сам CodeSys, она одна среда разработки остается.

Понятно, кто-то его переоблицовывает под свою линейку ПЛК. Кто-то оставляет прямо в цветах CodeSys, ничего не делая. Кто-то может и назвать его по-другому, переоблицовать маленько. Но в сущности одна и та же. Поэтому здесь как раз пример, так скажем, разные целевые платформы, но среда разработки по факту все равно остается одна. А здесь как раз вопрос дискуссии, а может ли среда исполнения быть, например, вот такая портированная и ПО разрабатывать в разных средах разработки для этой среды исполнения. Вот это, мне кажется, даже еще более интересно, чем в CodeSys реализованно. 

А нужно ли несколько разных сред разработки, если будет один единый хороший софт ПЛК? Может быть, стремиться и в плане среды разработки к этому же, чтобы она стала одной единой, не распыляться, а лучше сконцентрироваться на создании и последовательном улучшении этой среды?

У нас видение здесь было больше похоже, как вы сказали, с Linux. Есть ядро, технические требования все для них разрабатывали. Они эти технические требования вышли на рынок, ядро разработали, скинулись, разработали, то есть выложили его на гит, например, в ветку в какую-то. А далее, по идее, ничто не запрещает это кому-то взять и – даже такую крамольную вещь скажу – и пропретарное на этом что-то сделать. 

Так и делают. 

Да, то есть, в принципе, ничего в этом такого страшного нет, если даже это такое развитие получится. Но больше, конечно, согласен с вами, что, если мы хотим ускорить процесс, все-таки такие среды разработки уровней, теперь портал, CodeSys, ISaGRAF, они не один год разрабатываются. И, конечно, сейчас рынок специалистов, и у нас, может быть, нет десятилетия, чтобы это разрабатывать. Поэтому здесь, наверное, соглашусь, здесь лучше объединиться для усилий.

Насколько вот эта разработка – это вообще рыночная история? Или это все-таки история про то, что крупные предприятия наши хотят добиться импортонезависимости? А о рыночных выгодах здесь речи не идет.

Ну, как я уже скажу, наверное, да, в первом приближении. Когда ты закрываешь свои риски, это же тоже выгоды определенные. Можно как-то защищаться через риски, можно защищаться через историю, как это продать и сколько на этом заработать. То есть это тоже, если мы часть своих рисков уберем, мы, соответственно, часть своих денег не потеряем на этом. И, опять же, я считаю, что производителям ПЛК, аппаратных платформ, это у них тоже очень больная тема. То есть те, кто использовали CodeSys и ISaGRAF, это для них очень больная тема. Она, может быть, мое мнение, даже больнее, чем нам, заказчикам. То есть им надо было на что-то переходить, если я говорю, как сейчас будет все ужесточаться. И то, что попало под каким-то предлогом в реестр по переоблицованной CodeSys, оно может также оттуда и исчезнуть.

И чем вы будете тогда пользоваться? Я считаю, что здесь как раз нашим разработчикам и надо объединяться. Почему раньше, когда они пользовались одной средой разработки CodeSys, они не считали, что они как-то конкурируют. Это, наоборот, было классно. Он может, так скажем, раз обучиться, а теперь вдруг все решили отдельно взять деньги и отдельно начать делать свою среду разработки. Зачем? То есть для чего? Раньше вы конкуренцию не чувствовали, когда пользовались одной средой, а теперь вдруг вы решили конкурировать. Может, вам как раз объединяться и совместно делать что-то такое одно, единое.

Мне кажется, у них в этой истории выгоды не меньше, чем у нас, у заказчиков. Они должны, наоборот, в нее идти. 

Интересно получается, что ваш комитет продвигает идею создания софт-ПЛК, единого продукта, такого универсального, который будет хорош для любого применения в любой отрасли. То есть вы сейчас создаете прям серьезную прямую угрозу нашим отечественным производителям хард-ПЛК?

Нет. Но, как я уже говорил, практически все современные ПЛК, именно современные, Schneider, PhenicsContact, Siemens, Yokogawa, я не знаю, кого не возьми, у них по факту же у всех софт-ПЛК, над их аппаратной частью работает именно софтовый, то есть рантайм, который исполняет прикладное программное обеспечение. Как я уже говорил, они сами пришли к этому по множеству причин. Как я говорил про Siemens, у них раньше было свое подразделение, которое производило чипы для их ПЛК, Fuji Siemens. Сейчас нет у них его.

И если сейчас заняться реверс-инженерингом, статьи по реверс-инженерингу почитать, открыть ПЛК 1200, потереть чип, и там мы обнаружим ARM, обычный ARM. Получается, что они таким путем себя подстраховали, что они могут эту свою среду исполнения, свой софт-ПЛК, легко взять чипы у другого поставщика и портировать. Соответственно, они именно вот этой прослойке стали независимы. И плюс, сейчас их софт-ПЛК сдерживается только их проприетарными протоколами, то есть аппаратной частью. Но по факту это же и у них уже софт-ПЛК. 

То есть производители аппаратных ПЛК тоже, в принципе, должны быть заинтересованы в этой инициативе. То есть они будут создавать аппаратные платформы, а вы будете им предоставлять надстройку верхнего уровня. 

Да, даже не так, как я говорил. Исходники открыты. Они могут, если есть у них компетенции, сами взяли, сами для своего ПЛК все это накатили, портировали, разработали драйвера, и все, у них все это работает. А нет, так скажем, компетенций, – обращайтесь. Вот пошла история, как уже заработать на open-source,– для них портировать, написать драйвера. То есть исходники будут открыты.

То есть они и сами смогут это взять, если есть компетенции, и сами все это сделают для своей аппаратной платформы.

Какова роль государственных органов в этом, если не секрет? Вот Минпромторг участвует, видимо, в этом деле как-то.

На данный момент прототип мы разрабатываем своими силами. То есть у государства мы никаких субсидий под это дело не просим. Поэтому роль государства, – надо посмотреть. Можно грандов раздать на тысячу одну систему, среды разработки. И будет у нас тысяча одна среда разработки, она по факту будет нужна только именно для этой железочки. Больше никому она будет не нужна.

Я считаю, что идти таким путем – это утопия. Надо все-таки делать что-то глобальное для всех. Но, как я уже говорил, именно в этой истории мы у государства пока ничего не просим.

Но ваша инициатива единственная в своем роде у нас в России? Или есть еще конкурирующие такие движения в этом же направлении? 

На самом деле, что касаемо софт-ПЛК, конечно, мы не уникальны. Как я говорил, у всех современных брендов по факту есть софт-ПЛК. Но чтобы кто-то был готов это открыть, то есть разработать это и открыть. Вот здесь, я думаю, мы все-таки уникальны.

То есть ваша уникальность в том, что вы будете дарить все это?

Мы будем всем все дарить. 

То есть те, кто имеет уже свои готовые проприетарные решения, они, получается, ваши конкуренты. 

Они могут к нам прийти и попробовать нашу среду исполнения накатить на свою аппаратную платформу и сравнить. То есть джиттеры, метрики какие-то, как главный цикл выполняется на их зашитой прошивке, и на нашей среде исполнения. И, может быть, у нас будет даже быстрее.

То есть вот такого вот еще одного подобного рода комитета, или неважно, как это называть, по разработке, больше нет? Получается, вы единственные в своем роде?

Я думаю, да. Если касается рабочей группы, открытой АСУ ТП. Мы же говорили, у нас технических рабочих групп много, компонентов много. То есть мы же сами понимаем, что ПЛК – это всего лишь кубик вообще в АСУ ТП. Причем кубик, который довольно-таки внизу находится. Но он такой фундаментальный кубик, без которого сложно представить систему управления без ПЛК, без современной системы управления.

То есть она же из многих кубиков состоит, от ЧМА, SCADA до ПЛК. 

Сейчас есть разные концепции,  IIoT вообще без всяких ПЛК может обходиться. 

Когда надо непосредственно техпроцессом рулить, здесь сложно чем-то ПЛК заменить. Одно дело, когда это сбор данных какой-то для аналитики какой-то, МЕС-система, ERP-система. Но когда все-таки мы говорим о техпроцессе, тяжело это куда-то в облако унести. У нас есть такие ПЛК, трекинговые ПЛК, которые именно с других ПЛК поднимают информацию, делают какие-то расчеты. Но по факту, физического входа-выхода может не быть. У него будут только связи с другими ПЛК, интерфейсные. А чисто техпроцессом установки без ПЛК управлять, я не знаю. Я пока с трудом представляю. 

И поэтому уникальность в том, что мы хотим это разработать, открыть. Всех призываем вместе участвовать, потому что, по компоненту, как среда разработки, мы понимаем, что мы не осилим сами. Здесь, возможно, и к государству мы пойдем за помощью и всех просим участвовать, чтобы быстрее получить нормальный продукт.


© СТА-ПРЕСС, 2024