Олег Покровский, «Атомстройэкспорт»: Поддержка жизненного цикла сложных объектов требует уникального решения

Олег Покровский: Да. С 2018 г. разработкой платформы и продуктов Multi-D занималась команда, которая находится внутри АСЭ. Сейчас мы работаем над тем, чтобы активизировать распространение Multi-D на коммерческом рынке. Но, разумеется, Инжиниринговый дивизион как идеолог и первый пользователь Multi-D продолжит разработку и внедрение продуктов этой платформы в проектах капитального строительства новых АЭС.

Олег Покровский: Инжиниринговый дивизион Росатома обладает большим опытом работы с иностранной платформой low-code. Нам было удобно создавать на ее базе решения разных классов, но в определенный момент нам стало понятно, что стратегически это неправильный путь, и что надо создавать собственное ПО. Разработкой идеологии платформы Multi-D мы занялись в 2018 году. А уже в 2019-м приступили к программированию. И сегодня мы имеем продукт высокой степени готовности - на платформе Multi-D в Инжиниринговом дивизионе уже реализуются три проекта.

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

Олег Покровский: Чтобы понять специфику, нужно рассмотреть три основных процесса управления сооружением сложного объекта или изделия: управление требованиями, конфигурациями, изменениями.

Начнем с управления требованиями. Далеко не во всех проектах, даже сходного с АЭС масштаба, формализовано управление требованиями. Есть государственные стандарты и нормативы, в соответствии с которыми идёт сооружение. Формализованные требования контракта, а также требования, которые должны трассироваться через всю рабочую документацию, а потом по ним будет происходить приемка, в том числе получение лицензий на сооружение АЭС, - это удел крупных сооружений. Всего требований к проектам по сооружению атомных станций может быть до десяти тысяч, а в некоторых случаях даже больше. И вот этим массивом требований нужно управлять. Это первая особенность. Чекап для искусственного интеллекта: зачем и как тестировать ИИ-решения?

Вторая особенность состоит в том, что в атомной отрасли - по сравнению, например, с машиностроительными PLM – упрощена система управления конфигурациями. Возьмем для примера автомобиль: его конфигураций может быть очень много. В самом простом варианте, конфигурацией автомобиля мы можем управлять даже в дилерском салоне на стадии покупки: двигатель, коробка передач, цвет, материалы салона и т.д. В случае с атомными станциями, мы имеем дело, фактически, с двумя конфигурациями: конфигурацией изначального проекта и конфигурацией «As built». И это еще одна наша особенность. То есть у нас много требований, но мало конфигураций.

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

Олег Покровский: Да, есть такой способ импортозамещения – взять open source продукт, «завернуть» его в некоторую оболочку, а затем внести в реестр российского ПО и называть российским продуктом. Путь, подкупающий своей простотой… Беда только в одном - в большом массиве «опенсорсного» текста никто разбираться не будет. В любом случае отношение к нему будет, как к «черному ящику»: вроде, он работает, но как и почему работает, никто толком не знает. В таких случаях обычно рассчитывают на помощь сообщества. В надежде, что «там, наверное, умные люди собрались». И что они «наверное, детально в этом ПО разобрались». Но именно «наверное». И это - риск. Может быть, это хорошо для экспериментов. Но не для обеспечения строительства атомной станции.

Поэтому мы в Multi-D используем куски открытого кода только для некритичных участков, где свободное ПО может работать по принципу «черного ящика». Например, BPM-движок для управления бизнес-процессами мы реализовали на базе open-source. Но ядро системы мы писали сами. «С нуля». Иначе потом я не смогу отвечать за работу системы.

Олег Покровский: Платформа построена на базе передовой микросервисной архитектуры. Она подразумевает, что каждая функциональная часть системы (например, система авторизации, система выдачи ролей, система доступа к базам данных, сервис генерации веб-страниц, 3D-движок и т.д.) не составляют с платформой монолитное единое целое, а отдельно взаимодействует со всей платформой через набор открытых интерфейсов API. Отдельный служебный модуль отвечает за контроль того, какие микросервисы активны в данный момент. Таким образом, если какой-то микросервис - например, сервис работы с 3D - мне не нужен, достаточно снять «галочку» в одном списке.

Это позволяет менять сервисы буквально на ходу. Более того, микросервис может быть написан на любом языке. Важно, чтобы он удовлетворял требованиям API платформы. Тогда можно в пару кликов отключить старый микросервис и включить новый. Высокая гибкость платформы – одна из главных характеристик Multi-D: при модификации микросервисов код платформы не надо менять.

Это очень сложная задача для разработчиков и архитекторов. И я не погрешу против истины, если скажу, что у нас собрана команда «мега-гуру».

Олег Покровский: Платформа Multi-D – это инструмент low-code. Фактически это среда разработки, с помощью которого интегратор или заказчик создает ИТ-системы. Причем, делает это гораздо проще и быстрее, чем если бы разработка системы велась «с нуля».

Этого удается достичь, в первую очередь, за счет наличия на платформе готовых программных модулей, которые реализуют некоторые общие функции, свойственные практически всем проектам. Например: авторизация в системе, ролевая модель, разделение данных по ролям и другие механизмы управления доступа к данным в целях обеспечения безопасности и т.п. Кроме того, есть готовые полезные модули более высокого уровня, например, реализация диаграммы Ганта. Ведь если мы ориентируем систему на крупные предприятия промышленности, значит, обязательно понадобится календарный план. И микросервис диаграммы Ганта сразу дает визуальную часть - все связи, причем, в динамике, и соответствующая табличная часть.

У всех этих компонентов множество способов кастомизации: от цвета элемента до отображаемых данных. Разработчик все человек настраивает с помощью инструментария low-code, ничего не программирует.

Кроме того, реализован инструментарий для создания новых программных модулей без сложного программирования. В этом, собственно, и заключается суть подхода low-code – для адаптации платформы к процессам конкретной компании и ее развития не требуется участия профессиональных программистов. Так, есть инструментарий работы с СУБД. Реализованы визуальные компоненты – кнопки, тул-боксы, списки прокрутки, галочки… Все, что вы видите, когда открываете любую привычную вам программу.

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

Иными словами, при использовании low-code платформы программирование все равно остается. Это не zero-code, что, на мой взгляд, вообще утопия для сложных систем. Но low-code существенно облегчает труд разработчиков. Сокращение сроков разработки достигает, по разным оценкам, от 40% до 60%. И требования к самим разработчикам существенно снижаются. Пример. Мы берем на практику студентов Высшей инженерной школы МИФИ, погружаем их в платформу, и они месяца через четыре начинают довольно уверенно в ней ориентироваться. Ребята у нас прямо в ходе практических занятий уже готовят некоторые блоки информационных систем на базе платформы Multi-D. Есть планы запуска аналогичных программ и с другими ВУЗами.

Олег Покровский: Платформа использует так называемые слои абстракции. Например, один слой абстракции работает на уровне системного ПО - скажем, СУБД. Понятно, что если некоторое ПО ориентировано на использование СУБД Oracle, то перевести его на Postgres по щелчку мыши невозможно. А в среде low-code достаточно дать платформе команду «Создать таблицу». Платформа сама понимает, что в данный момент к ней подключен модуль работы с определенной СУБД, значит, нужно создавать таблицу соответствующим способом.

В такой реализаци замена СУБД проходит практически незаметно. Достаточно сообщить платформе: включить вместо модуля Oracle модуль Postgres. Более того, это позволяет подключить к одному приложению несколько баз данных разного типа. Скажем, где-то мне нужна SQL-СУБД, а для где-то предпочтительнее база данных NoSQL, и я могу их комбинировать в рамках одного приложения.

Еще один важный слой абстракций проходит на уровне бизнес-объектов. Например, протокол совещания - это некий бизнес-объект, который представляет собой текст с определенными атрибутами: дата, время, участники и т.п. Появление такого объекта порождает создание других объектов – так называемых поручений, у которых есть свои атрибуты: даты, ответственные и т.д. В любой бизнес-системе всегда есть протоколы и поручения. Их тоже не нужно придумывать с нуля. Очень важный бизнес-объект - 3D-просмотрщик. Это очень существенное дополнение к строительным чертежам. Вместо того, чтобы ломать голову над плоским чертежом рабочей документации достаточно ввести идентификатор документации и увидеть на общей 3D-картинке, как расположена та труба, которую нужно поменять. Платформа Multi-D поддерживает общепринятые стандарты BIM и совместима с системами САПР.

Олег Покровский: Да. Фронтэнд платформы Multi-D ориентирован на веб-приложения. А это подразумевает множество возможных браузеров и широкое разнообразие характеристик конечных устройств пользователей. Обычно это большая головная боль для разработчика – предусмотреть все возможные варианты реальных ситуаций.

Мы тестировали Multi-D с самым разным пользовательским оборудованием, включая информационные киоски и планшеты с ОС «Аврора». Все отлично работает.

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

Сейчас наш бэклог пополняется, главным образом, исходя из тех задач, которые ставят наш основной заказчик - АСЭ. Но мы ставим себе задачу в будущем году сформировать экосистему партнеров, разработчиков готовых систем на базе Multi-D. Мы параллельно с ними будем создавать новые бизнес-объекты. Если партнер разработал бизнес-объект самостоятельно в строгом соответствии со спецификациями платформы, мы разместим сервис на своем маркетплейсе. Это общепринятая модель коммерциализации для сторонних разработчиков микросервисов.

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

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