company_banner

Как тестируют атомные электростанции

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

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

    Из этой статьи вы узнаете о том, что представляет собой современная информационная система, как происходит разработка и тестирование «капитальных» объектов на примере АЭС.


    В основе материала — расшифровка доклада Вячеслава Аленькова, директора по системной инженерии и информационным технологиям инжиниринговой компании «Атомстройэкспорт» (ASE) с нашей декабрьской конференции Heisenbug 2017 Moscow.

    В этой статье я расскажу о том, как мы используем технологии управления информацией, тестирование различного рода процессов при сооружении крупных капитальных объектов (в нашем случае это атомные станции). С учетом того, что в капитальном строительстве идет глобальное внедрение цифровых технологий и эти технологии все больше и больше проникают в разные индустрии, в том числе связанные с физическим миром, то и технологии, связанные с ИТ, тоже активно входят в это направление.

    Небольшое введение: «Атомстройэкспорт» (ASE) — это компания, которая является инжиниринговым дивизионом госкорпорации «Росатом». Мы отвечаем за проектирование, закупку/поставку и сооружение практически всех атомных станций в России и за рубежом, более чем в 15 странах мира. Более 90% наших проектов — это строительство и проектирование станций за рубежом, и в этом плане мы впитываем лучшие требования, лучшие практики со стороны международных регуляторов, задающих нормативы и правила, со стороны международных заказчиков.

    Во многих странах тема требований к «цифре» очень высока. Многим заказчикам уже нужен не только построенный объект в бетоне/железе, который — вот он, стоит в поле. Теперь нужно рядом сдать цифровую модель объекта, которая будет жить потом на протяжении всего жизненного цикла атомной станции. Станция строится 5-10 лет, эксплуатируется потом 60 и более лет, то есть всё, что мы сделали (с учетом вывода из эксплуатации до 100 лет) будет потом использоваться и жить на соответствующем объекте. При этом, как вы понимаете, чуть ли не каждый год в ИТ с точки зрения технологий что-то кардинально меняется, и как это спрогнозировать на 100 лет — это, конечно, большая проблема.

    Атомная станция — на сегодняшний день, наверное, один из самых сложных объектов, которые строит человечество, с точки зрения сложности объекта, количества участников, а также обеспечения безопасности этих объектов. Поэтому без цифровых технологий эти объекты практически невозможно построить. Сейчас заказчики (несмотря на то, что объект сложный) каждый раз ставят требования построить объект «ещё быстрее» и «ещё дешевле», при этом мы одновременно строим и проектируем 30 таких сложных объектов в разных странах мира, и управлять таким массивом информации без цифровых технологий невозможно. К примеру, основные параметры — это сотни тысяч позиций разного оборудования, и каждая позиция сама по себе является сложным инженерным объектом. Это десятки тысяч уникальных классов оборудования, десятки и сотни тысяч цифровых требований на входе (чуть позже расскажу об этом подробнее), это информационная модель, в которой содержится сотни тысяч, иногда миллионы элементов, взаимосвязанных между собой, — и всё это не конечный продукт: модель всё ещё «течёт», меняется, с этой цифровой информацией одновременно работает огромное количество участников, между ними возникает большое количество коллизий, и очень важно взаимосвязано управлять всем этим процессом, чтобы это всё не разъехалось. Конечно, существуют вопросы, связанные с подготовкой «контейнеров» для складирования этой информации, создания связей между элементами, для приемки/проверки/тестирования всего, что происходит в процессе проектирования. На этапе проектирования возникает больше всего информации об объекте, и уже потом, на стадии сооружения, она меняется. Как раз на стадии проектирования создается информационная модель объекта, у нас есть набор технологий — их там большое количество, но я выделил здесь несколько ключевых, которые позволяют управлять этой информацией, чтобы это всё не рассыпалось.



    Информационная модель и V-модель


    Одна из первых стадий — это создание информационной модели, которая, само собой, включает в себя понятие 3D. (3D-модель проще для понимания, потому что всё представлено визуально.) Мы говорим про информационную модель, потому что 3D — часть информации: там большое количество различных математических данных и атрибутов. Возьмем какой-нибудь элемент, например, насос (которых, как я уже говорил, сотни тысяч): каждый из них обладает каким-то набором атрибутов, которые свойственны этому насосу, и эти атрибуты меняются на протяжении всего жизненного цикла. Эта информационная модель фактически — единый источник правды, к которому все обращаются, берут эту информацию и используют её в своей деятельности при проектировании таких больших объектов, как атомная станция.

    Соответственно, вокруг информационной модели создаётся единое информационное пространство, которое позволяет всем участникам получать туда доступ, отслеживать изменения, которые делает он сам или делают какие-то другие участники проекта, которые географически распределены, и единственное, что их собирает вместе, — вот эта информационная модель.

    Важный момент — это процессы управления требованиями и процессы управления конфигурацией. Большая часть этих процессов в свое время пришла как раз из управления проектами, которые перекочевали из программной инженерии, перешли в системную инженерию (это уже про большие инженерные объекты, создаваемые в физическом мире).

    Наверное, все знакомы с понятием «V-модель» — собственно, программное обеспечение разрабатывается тоже в соответствии с V-моделью: формируются требования, на следующем этапе формируется архитектура, дальше идет процесс проектирования (проект, проектирование, рабочее проектирование), затем стадии реализации, создания объекта. И потом идет обратно-восходящий процесс, когда нужно протестировать, провести различные процессы, связанные с верификацией, с приемкой, с проверкой и в конечном итоге сдать заказчику, который должен убедиться, что он получил именно то, что задумал. Поэтому есть два процесса — проверка и приемка. Я думаю, все знают, чем они отличаются. Проверка — это формальное соответствие техническому заданию: у вас было 500 пожеланий — напротив каждого мы поставили галочку, вот, исполнили 500 формальных ответов. А приемка включает еще и удовлетворенность заказчика, т. е. не только вы все формально выполнили, но и он действительно получил то, что хотел. Поэтому оба процесса важны.



    V-модель такая широкая, потому что в современном мире никто не ждет, когда закончится одна стадия (например, стадия разработки требований), начинаются проектирование, изготовление. Если посмотреть на срез (t, время), то вертикальная прямая красная линия как раз показывает, что проект одновременно находится сразу в нескольких стадиях жизненного цикла, т.е. где-то еще, может быть, заказчик определяется с требованиями, где-то уже вовсю идет разработка проекта, а где-то уже, грубо говоря, начали копать котлован (потому что про него уже всё понятно, там уже есть проект и т.д.). Таким образом, в этом плане возникают еще бо́льшие требования к координации участников проекта, потому что вы не ждете окончания стадии. Собственно, эти темы, связанные с гибкими подходами, с Agile — они сейчас активно применяются и на этапе строительства, потому что вы не сможете управлять несколькими параллельными стадиями одновременно, если не применяете такие вот гибкие подходы и командообразующие мероприятия, когда участники, находящиеся на разных стадиях, одновременно работают над проектом.

    В чем смысл горизонтального красного овала: на самом деле вся ценность управления проектом (крупным проектом в том числе и даже, может быть, в первую очередь) сконцентрирована как раз внутри этого овала. Всё, что выше него — это роль заказчика: он формирует идею, иногда очень абстрактную, иногда формализованную, и он же принимает потом продукт к себе в эксплуатацию, как результат. Всё, что ниже овала — это могут быть различные подрядчики, участники, поставщики, какие-то партнеры. Центр овала — это и есть основная фишка, т.е. надо уметь поговорить с заказчиком и правильно сформулировать требования; надо правильно их декомпозировать, убедиться, что все они одинаково всеми понимаются (есть формальные критерии, как протестировать и принять это требование в работу); надо уметь поставить задачу нижестоящему слою участников (к примеру, всем подрядчикам или разработчикам программного обеспечения), чтобы она была четко сформулирована и ничего не потерялось. А в правой части надо уметь сделать всё наоборот, т. е. принять работу, протестировать на соответствие тем требованиям, которые были изначально, и продемонстрировать это заказчику, сказать: «Смотри: то, что ты хотел, то мы, собственно, тебе и передали».

    Еще один такой общий, теоретический, может быть, аспект: наверное, все знакомы с классическим треугольником управления проектом, когда надо обеспечить три параметра — сроки, стоимость и качество в проекте. Стандартная шутка: «выбери два любых». В управлении сроками и управлении стоимостью все технологии давно придуманы, т.е. бери, применяй лучшие практики, обучайся технологиям, методикам. Но основные проблемы, которые возникают в проекте, всегда связаны с качеством. Из моего опыта (а я имею довольно большой опыт в разных направлениях и отраслях): всегда есть какая-то проблема с постановкой требований, которая потом всплывает в конце проекта, либо что-то кто-то неправильно сделал, неправильно проверили, протестировали, и это всплыло уже на следующем этапе. Поэтому основной упор при работе над проектом сейчас надо делать на качество. С качеством можно работать, в международных стандартах (ISO 9000 и т.д.) есть стандартизированные документационные описания понятия качества.

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

    Для объектов капитального строительства, скажем, атомной станции, очень важно, чтобы у вас была детальная информационная модель, т.е. почти всё сейчас переносится в цифру: если вы что-то сделали не в цифровых технологиях, то с высокой долей вероятности произойдет ошибка на этапе сооружения. Например, какая-нибудь вентиляционная труба и труба, связанная с пожаротушением, где-нибудь пересекутся, и вы это обнаружите не в компьютере, где можно было очень дешево и быстро поправить, а тогда, когда все это уже сварено, прикручено, потрачены реальные деньги, и вам нужно будет что-то ломать, перепроектировать, иногда даже что-то нужно будет менять с точки зрения согласований проекта — это сразу влияет на стоимость, на сроки. Поэтому очень важно многие вещи протестировать еще в виртуальной среде. Фактически когда мы строим/создаем объект, мы тестируем его дважды: первый раз полностью делаем цифровой двойник в информационной среде и проверяем там работу систем, работу, связанную с сооружением и с проектированием; второй раз, когда первая проверка пройдена, — в реальном физическом мире. Это очень важный момент, потому что сейчас это самый главный тренд с точки зрения «физики»: очень многое делается в компьютере.

    Раньше, например, как делали самолет: проектировали, потом проводили огромное количество натурных испытаний (аэротруба, огромные макеты), всё это продувалось, потом строили самолет, он тестировался — проходило много лет… Была поставлена задача — а можно ли всё это сделать в виртуальной среде, т.е. чтобы первый же построенный самолет сразу взлетал и летел соответственно заложенным характеристиками. Эта задача сейчас решена: большая часть самолетов проектируется полностью в компьютере и там же тестируется вплоть до того, что тестируются все лётные характеристики и уже потом дается правильное задание на изготовление, делается контроль процесса изготовления, чтобы всё соответствовало виртуальным моделям, — и первый же построенный самолет летит соответственно характеристикам (понятно, что идут какие-то мелкие доводки, но нет такой большой критики, как было раньше).

    Аналогичная ситуация и происходит сейчас в капитальном строительстве: почти всё должно быть сделано в виртуальной среде, и уже потом на этапе строительства основная задача должна заключаться в проверке, чтобы реальное здание соответствовало тому, что вы нарисовали в компьютере, и чтобы всё делалось именно по этой технологии. Как пример, есть так называемые технологические схемы: мы моделируем физические процессы работы оборудования, видим, как оно будет себя вести в той или иной среде, как будет перекачивать жидкость/газ и т. д. — всё это моделируется в компьютере, связанном с 3D.



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

    Управление требованиями




    Важный процесс, как я уже говорил, — управление требованиями. На «входе», когда к нам приходит заказчик, особенно квалифицированный, он дает нам не классическое техническое задание (талмуд на бумаге «собрать станцию»), а базу данных цифровых требований. Это примерно 15-20 тысяч требований, каждое из которых имеет формализованный вид, и задача — обеспечить исполнение этих требований в ходе проекта, т.е. проверка проекта будет происходить на соответствие этим требованиям. И заказчик говорит: «На этапе всего процесса создания объекта, проектирования объекта вы мне каждый раз доказывайте, что делаете этот объект во имя исполнения требований, а не придумывайте что-то, чтобы через пять лет принести не соответствующий требованиям проект. У вас должна быть информационная система, в которую я в любой момент времени могу зайти и увидеть, что все действия, которые вы делаете, как-то связаны с исполнением тех требований, которые я вам изначально поставил».

    При этом важно, что эти 15-20 тысяч — это еще не конечные требования. Да, очень часто они, казалось бы, звучат грубо, очень просто — например, «выполнять такой-то стандарт». Но по факту этот стандарт сам по себе представляет огромный массив требований следующего уровня, и одна из первых задач — дойти до последнего конечного требования, которое уже можно посчитать/измерить. И очень быстро эти 15-20 тысяч превращаются в сотни тысяч. Сами понимаете, что без информационных технологий это практически невозможно сделать.

    Более того, по каждому требованию нужно иметь программу испытаний, методику тестирования, в этом участвует огромное количество участников проекта, распределенных географически, и как раз это (когда мы говорим про горизонтальный красный овал на V-модели) есть основная ценность качественного управления проектом.

    Всё это происходит, в первую очередь, через технологию работы с требованиями — они живут по всему жизненному циклу. Первый раз вы проверяете требования, когда выполняете информационные модели, разрабатываете проектно-рабочую документацию — вы говорите: «Смотрите, мы сделали цифровую модель объекта, и она соответствует вашим требованиям». На этом этапе происходит тестирование, приемка-проверка — заказчик говорит: «Да, отлично!». Дальше второй этап, когда вы начинаете закупать оборудование и тоже ставите соответствующий набор требований заводам-изготовителям, поставщикам оборудования (уже про конкретную железяку, которая будет стоять в этом проекте), и проверяете, что они на заводе действительно изготавливают это так, как вы спроектировали в своей модели, чтобы это соответствовало базовым требованиям. На следующем этапе возникает процесс строительства, когда все эти железки, насосы, задвижки приезжают на объект, и вы из них, как из большого конструктора, собираете сложный объект. Но таких элементов сотни тысяч, и все они между собой должны быть как-то связаны, проверены. И уже на этом этапе проверяется технология изготовления, тестируется сам технологический процесс. Когда объект уже построится, вы тестируете — а работает ли он так, как вы изначально cпроектировали в информационной модели?

    Управление конфигурацией




    Далее идет процесс, скажем так, следующего уровня по сложности — это процесс управления конфигурацией. Он на самом деле очень простой. С точки зрения идеологии есть три сущности, которыми вы управляете в проекте:

    • то, что вы хотели сделать, т.е. изначальная идея, требования, все те базовые посылы, которые появились перед тем, как вы начали создавать свой объект;
    • то, что вы думаете и делаете, т.е. всё, что описывает ваш объект: чертежи, информационные модели, документация — виртуальное описание физического объекта;
    • собственно, сам построенный вами объект в бетоне или в металле.

    Стандарт управления конфигурацией говорит простую вещь: вы должны обеспечить, чтобы все эти три элемента в любой момент времени соответствовали друг другу. Тогда получится, что вы построили объект качественно, в соответствии с требованиями, описали то, что на самом деле сделали и сделали то, что на самом деле описали. Но когда у вас, как я уже говорил, сотни тысяч требований, миллионы элементов в проекте, тысячи участников, то управление этим процессом и обеспечение соответствия элементов друг другу превращается в мегасложную задачу, к которой в плане информационных технологий только недавно подошли с практической точки зрения: ведь это должна быть не научная вещь, а практическая, этой технологией должны пользоваться обычные люди, простые проектировщики, монтажники. У нас сейчас такая технология есть, и она как раз построена на серьезной онтологической модели данных, которые изначально зашиваются в систему.



    Здесь tag — это центральный элемент системы, проектная позиция (проще говоря, насос, задвижка), собственно, то, из чего состоит ваш объект. В нашем случае это сотни тысяч элементов — каждый из них сетевым образом связан с каким-то набором характеристик, атрибутов, т.е. у него есть свойства, связанные с физикой (тяжелый, легкий, красный, белый и т.д.), с его параметрами (с какой скоростью он перекачивает жидкость), в общем, что делает этот предмет. У него есть описание для того, чтобы вы могли осуществить закупку. Вначале вы даже не знаете, что это за насос и какой завод его произведёт — вы просто знаете, что он должен перекачивать жидкость из одного места в другое. Это характеристика, функция. И только потом она обрастает какими-то элементами, показывающими, что это конкретное изделие. Вам должно быть понятно, где этот элемент находится: если представить себе атомную станцию (условно — 150 объектов, существующих рядом), надо понять, где он стоит физически — на каком этаже, в какой инженерной системе, в каком здании, т. е. это тоже набор параметров, которые определяют географию, положение. Таких параметров много. Возникает сеть семантически связанных между собой различных атрибутов, которые и закладываются в модель данных, позволяющую потом всем участникам проекта управлять процессами конфигурации.

    На картинке ниже показан пример: сначала вы думаете, что это какая-то «штука» (как думает проектировщик: «Здесь должна быть какая-то штука, перекачивающая жидкость из этой точки в эту точку с какой-то скоростью»). На втором шаге появляется какой-то набор параметров (на картинке примеры выделены оранжевым цветом). Дальше вы переходите на следующую стадию жизненного цикла проекта, где понимаете, что на самом деле штук должно быть две, потому что нужен резерв (если одна сломается, вторая должна обязательно включиться) и т.д. Возникает логическая схема: появляется еще набор параметров, которые свойственны этому элементу на этой стадии. Дальше вы переходите на следующую стадию, где говорите: «Да, теперь я понимаю, что ты на самом деле насос, а не задвижка, у тебя такие-то характеристики, и я могу начать покупать». И в конце концов вы покупаете конкретный элемент, приезжает конкретная железка с заводским номером, на котором написано «я не просто чайник — я чайник производителя такого-то под номером таким-то» — и это уже другая характеристика. Это пример движения одного элемента по жизненному циклу.



    Как я уже говорил, есть сотни тысяч таких элементов, которые одновременно живут какой-то своей жизнью, и, значит, вы в какой-то момент времени смотрите на эту огромную информационную модель как на слона — с одной стороны увидели хвост, с другой — хобот, и каждый видит эту модель со своей колокольни. Очень важно примирить всех между собой и сказать: «В настоящий момент важным для нас является вот такой срез этой модели». Возникают так называемые конфигурационные линии, т.е. вы говорите: несмотря на то, что у нас тут миллион элементов, важными на сегодня для нас являются вот эти вот 25 тысяч — и мы их отслеживаем, хотим, чтобы они не нарушили свои параметры. А следующие элементы возникают только на следующей стадии, иначе этот процесс будет просто неуправляемым. Конфигурационные линии — как раз то, что позволяет удержать в голове такое большое количество данных одновременно.



    Тестирование на практике


    Например, про атомную станцию мы говорим, что у неё существует информационная модель, и держим в голове вот еще что: потом этот объект будет эксплуатироваться, у него есть уже существующие эксплуатационные и технологические процессы (он должен генерировать электрическую энергию, работать по определенным принципам). Соответственно, существует управляющая информационная система, которая будет этим объектом потом управлять. В процессе проектирования и создания самого объекта вы параллельно с V-моделью проектируете и создаете автоматизированную систему управления технологическими процессами объекта, который вы построите. Эта система тоже проходит соответствующие стадии жизненного цикла. Атомная станция оснащена огромным количеством датчиков, которые генерируют различную информацию, они связаны между собой в компьютерную сеть, и, соответственно, вы тоже должны спроектировать объект и протестировать его: а действительно ли управляющие сигналы пройдут на эти исполнительные устройства так, как вы задумывали в компьютере; не случится ли потом, что, нажав кнопочку, вы не откроете что-то, а закроете. Этот элемент проходит тестирование в компьютере, как классический объект, потом отдельно тестируется каждая инженерная система, а потом еще и весь объект в целом, и получается многоступенчатый подход к приемке результатов выполненных работ. И при этом очень важно, что бо́льшая часть тестирования должна проходить в компьютере, потому что здесь еще более сложная ситуация, чем просто проектирование, создание объекта.



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

    Следующая стадия — стадия сооружения, создание самого объекта, когда вы уже выходите в поле, начинаете копать, лить бетон, варить металл и т.д. Здесь есть очень важный момент: многие вещи вы тоже должны заранее смоделировать в компьютере: вы должны увидеть последовательность операций, понять, что этот большой насос действительно влезет в этот проем, в эту дверь (а не как бывает на самом деле: вы его привезли, а его нельзя затащить, потому что там двери меньшего размера). Бытовой пример: к вам домой принесли пианино, а оно в дверь не влезло. Когда вы строите атомную станцию, такого в принципе быть не должно, хотя у вас таких «пианино» сотни тысяч, и понятно, что без компьютерного моделирования, проверки всех маршрутов, последовательностей операций это практически невозможно сделать. Это значит, что на объекте нужно будет принимать какие-то нестандартные решения (что неправильно), поэтому у нас в том числе развита технология моделирования процесса строительства.



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

    Аналогично происходит с точки зрения последовательности операций: кто, зачем делает, варим мы сначала одну трубу или другую — вся последовательность должна быть протестирована. Этим занимаются разные организации, поэтому, если вы не сделали этого в централизованном виде (в компьютерной системе), то потом между ними возникает огромное количество противоречий.



    На картинке изображение мелкое, но смысл такой: справа внизу — это фактически программирование работы монтажника по выполнению той или иной операции, последовательность, что когда он должен сделать (вплоть до расписывания по дням, иногда по часам). Но когда у вас горизонт 5 лет, то дневное планирование — это довольно детальное планирование. Фактически мы программируем процесс работы монтажников на площадке, и он должен быть проверен также и в компьютерной среде.

    Оцифрованное строительство


    На самом деле тренд такой, что всё больше и больше вещей будет заменяться, в том числе роботами. Если посмотреть на завод BMW, который изготавливает машины — там практически нет людей. Еще какое-то количество лет назад это было невозможно. Как это происходит? С моей точки зрения, это стало возможным только благодаря тому, что всё это было оцифровано. Если компьютер может играть в шахматы, то уж машину сварить ему никаких проблем не составляет, если всё правильно оцифровали, заалгоритмизировали и проверили.

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



    На картинке один из примеров: фактически мы программируем работу монтажников на площадке — есть соответствующие инструменты, ИТ-механизмы. Как пример (внизу слева) что-то похожее на терминал для мобильной оплаты — это такой антивандальный киоск, который стоит прямо в котловане или на объекте в бетоне, в металле, весь в пыли, с соответствующей защитой. Любой монтажник может подойти к нему, ввести свой пароль, увидеть трехмерную модель объекта, который он сейчас должен делать, через Wi-Fi распечатать или скопировать себе на планшет задание, пойти выполнить эту работу, отметить, что он сделал, вернуться и сдать работу. Раньше для этого он должен был идти, например, в штаб, который находится в километре от объекта, — сейчас всё происходит непосредственно на площадке. И это всё ближе и ближе: скоро эти мониторы будут не нужны, человек будет получать всё это прямо на планшет. Пока мы ставим такие штуки, потому что там много бетона, металла и не всегда работают современные сети связи, а так никаких ограничений уже нет. Молодое поколение сейчас уже без смартфона или планшета в принципе не существует. Те, кто сейчас становится строителями, уже в базе спокойно работают с компьютерными технологиями, в принципе, им уже не нужны будут графики, может, будет достаточно симулятора в компьютере, который показывает, что, где и зачем человек должен сделать. Это быстрее, чем рисовать графики по старинке.



    Более того, если двигаться дальше, вот пример с ростовской станции, которую мы начали запускать в эксплуатацию в так называемой студии визуального моделирования. Фактически это такой инженерный 3D-кинотеатр, когда вы надеваете очки и оказываетесь, грубо говоря, внутри атомной станции — видите вокруг себя трубы, можете их даже передвинуть, перепланировать (это одновременно делает несколько человек), можете увидеть последовательность операций, протестировать, действительно ли пройдет тот или иной элемент. Здесь же проводятся различные сложные совещания: вместо того чтобы ехать на объект, который строится, например, в Бангладеш, все специалисты могут подключиться удаленно и увидеть текущую ситуацию на объекте, сравнить ее с виртуальной моделью и подсказать какие-то решения команде, которая в этот момент находится на площадке. Это распределенная виртуальная реальность, тоже элемент компьютерной игры, но перенесенный в инженерную, практическую деятельность. Вы не просто прозябаете в компьютерной игре — вы реально создаете какую-то ценность, строя серьезный большой объект, применяя абсолютно те же самые навыки, которые вы применяли, например, при программировании или компьютерном моделировании.



    Например, на картинке показан монтаж корпуса реактора, одного из основных элементов атомной станции. Всё, что справа и снизу — это виртуальная симуляция. Корпус весит примерно 330 тонн, довольно тяжелый элемент, смонтировать его нужно с точностью до миллиметра, и он не должен никак перекоситься. Потом к нему подключаются огромные трубопроводы, у которых градусы всех углов подключения также регламентированы, иначе всё пойдет не по проекту. И, конечно же, всё это моделируется в компьютере: моделируются операции, краны, и уже потом объект устанавливается на необходимое место, где с помощью, например, лазерного сканирования идет тестирование — а действительно ли мы выполнили все те параметры, которые изначально закладывали в проекте?



    На картинке — еще один пример: на каком-то этапе сооружения для контроля за ходом строительства вы в компьютерной информационной модели отмечаете точки, которые хотите отслеживать с точки зрения хода работ. А дальше очень простая технология — в этих точках делается сферическая фотография на 360 градусов (этим тоже сейчас никого не удивишь), она совмещается с точкой из 3D-модели (при этом вы можете обернуться вокруг себя, прокрутить, посмотреть), и справа вы можете видеть, что, с точки зрения модели, в этот момент времени должно было быть сделано, а слева видите реальную фотографию того, что же на самом деле в этот момент происходит на стройке. И вы очень быстро можете сопоставить, по плану всё это идет или не по плану, есть отклонения или нет отклонений. Раньше для этого нужно было провести огромное количество сравнительных операций — посмотреть документы, сравнить с графиком — а сейчас очень быстро, за считанные минуты, вы можете увидеть движение проекта, причем удаленно, т. е. не надо физически ехать на этот объект, вы смотрите, как все происходит на самом деле. Внизу — ползунок по времени, если его прокрутить, то у вас будет «кино» о том, что происходит — и в модели, и реальной жизни.



    Соответственно, как я уже сказал, важным моментом является не только моделирование, но и проверка по факту выполнения работ. Многие вещи делаются уже не «на глазок», когда вы пришли и увидели — да, действительно поставили оборудование или залили бетон, но у вас нет средств формального контроля. Сейчас такие средства есть — вы можете с помощью лазера просканировать объект, увидеть, что он действительно не отклонился ни от одной из своих осей. Более того, сейчас это можно делать с помощью дронов, если говорить про объекты не внутри здания, а на площадке. Технология активно развивается: человеку даже не нужно ходить и тратить время, если объект большой. Вы можете регулярно, более того — в автоматизированном режиме заполнять, запускать по какому-то алгоритму дроны, которые будут сканировать и уже по факту давать информацию, есть ли отклонения от того, что у вас в модели на текущий момент времени. Есть соответствующие другие средства контроля внутри объекта, те же самые сферические панорамы — таким образом, вы фактически делаете срез системы автоматизированного контроля (автоматического контроля, тестирования, говоря вашим языком) того, действительно ли делают то, что изначально вы запрограммировали в виде проекта, в виде информационной модели.

    В заключение я хотел бы сказать, что с учетом тотальной цифровизации физического мира (а тренд все заметнее и заметнее), те навыки, которые сейчас развиты в ИТ-индустрии, в том числе тестирование, все активнее и активнее проникают в реальные физические индустрии. И в этом плане я хотел бы, может быть, даже раскрыть потенциал технологий. Например, когда мы берем себе сотрудников, то очень многих берем на инженерные позиции, но из ИТ-индустрии, потому что иногда легче из айтишника сделать инженера, чем в некоторых инженеров перенести навыки этой культуры, гибких подходов и т.д., хотя это, конечно, не всегда так.
    Если вам понравился этот доклад, обратите внимание: 6-7 декабря Heisenbug снова приходит в Москву. Там будут и полезные советы, и удивительные истории, и миры тестировщиков и разработчиков вновь соприкоснутся. Увидеть актуальное состояние программы (и, при желании, приобрести билет) всегда можно на сайте конференции.
    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

    Комментарии 36

      +8
      Классный доклад, без шуток. К сожалению, видимо, в реальности ситуация в Атомстройэкспорте напоминает известный мем о сбере («Блокчейн, бигдэйта, машин лернинг» против «Вот где карту открывали, туда и идите»). По крайней мере все эти цифорвые модели и управление требованиями не помешали крановщикам стыдобищно уронить корпус реактора первого энергоблока на строящейся БелАЭС, а менеджменту — долго отрицать очевидное в стиле «ничего не было, а если было — то пофиг».
      ru.wikipedia.org/wiki/%D0%91%D0%B5%D0%BB%D0%BE%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%90%D0%AD%D0%A1#%D0%9F%D1%80%D0%BE%D0%B8%D1%81%D1%88%D0%B5%D1%81%D1%82%D0%B2%D0%B8%D1%8F
        +2
        Уронить на этапе строительства наверное не так страшно.

        Страшно что нет внешнего контроля с перехватом управления, когда к пульту доберется очередной Акимов с опытом управления угольной ТЭЦ и начнет выполнять тестирование реактора по решения партии и без понимания как работает реактор.
          +5
          В смысле, не страшно? Так не страшно, что видео так и не показали, врали, что не упал, а только чуть поцарапался, а в итоге были таки вынуждены, судя по всему, под давлением заказчика, заменить, заявив при этом, что найдут, где использовать покоцанный? Если что, микродефекты под воздействием радиации имеют свойство развиваться.
            +1

            "внешнего контроля с перехватом управления" — потенциальная дыра в безопасности

              0
              Внешнее — не обязательно за территорией АЭС.

              Лет 20 назад былa проведена проверка — смогут ли сотрудники российских спецлужб захватить контроль нас ядерными установками — в том числе и на атомоходах.

              Им удалось это сделать в 100% случаев, даже при том что к их приходу готовились.

              Ужесточение протоколов работы и усиление охраны может быть недостаточно.

            +3
            А на строящейся ЛАЭС-2 аналогичным образом уронить блок защитных труб реактора (огромная сложная деталь массой порядка 70 тонн — по сути верхняя половина ВВЭР реактора) расфигачив в хлам и сам этот блок и бассеин для отработанного ядерного топлива куда он упал.
              +1

              Какие-то «гражданские активисты», «антиядерщики» раздувают эту историю, судя по вашей же ссылке. Очень дурно пахнет от всей это истории, и вовсе не из-за «падения».

                +5
                Ну да, по моим ощущениям, у соседнего прибалтийского государства пригорает от этой стройки, и (опять же, мои субъективные ощущения) дело там не только в озабоченности экологией, а и в изменениях в локальном рынке поставщиков энергии.
                Но давайте посмотрим на произошедшие факты без оценки их дальнейшего освещения в медиа. Стропы порвались? Порвались. Корпус упал? Упал. Могло ли это случиться, если бы все прекрасные вещи, описанные в статье выше, применялись на практике (а там есть и про симуляцию нагрузок на стрелу крана как раз)? Нет, не могло случиться.
                Я сейчас очень мягко говорю. По факту у меня есть пара знакомых на низовых позициях в этой структуре, и в их описании ситуация в целом там сильно напоминает, прости господи, ситуацию в Роскосмосе. Команда молодых инновационных менеджеров наверху с околонулевым пониманием специфики отрасли, и потихоньку вымываемые старички с кульманами снизу, невеликими силами которых и делается реальная работа.
                  +2
                  Остановить «раздувание» ее очень просто: взяли бы и показали видео, которое снималось, на котором видно, что 330 тонн корпуса со сварными швами не гулко бамкнулся, а слабо швыркнулся. Но почему-то этого видео никто не показывает.
                  А дурно пахнет скорее от заявления о том, что найдут, где использовать забракованный заказчиком корпус. Т.е. ему приедет нормальный, а потенциально поврежденный уедет к кому-то еще. Весёлая лотерея.
                  –2
                  Гладко было на бумаге, да забыли про овраги.
                  Эта древняя истина отлично иллюстрирует тот факт, что никакая виртуализация не смоделирует все детали, например, идеальный прочностной расчёт не предскажет поведение «оптимизировнаной до предела» балки в условия «экономии» и «оптимизации» современного менеджмента. А запас прочности, который по ТУ необходим, всегда вступит в противоречие с размером личной прибыли, которая и имеется в виду в нынешнем мире везде, при выполнении любых деяний.
                  Что победит, техника безопасности или личная прибыль, предсказать не трудно. Что важнее, закон (физики!) или личная прибыль для индивидуума? Тоже не трудно понять.
                    +3
                    Почитать так у нас все круто! При входе в главный офис АСЭ(Атомстройэкспорт) в Москве, много демонстраций большие экраны с демками, водят иностранцев показывают. А на деле вся проектная документация на бумаге, нормоконторль на бумаге. Из всей «цифровизации» заменили кульманы на ПК со SmartPlant. Обещанного взаимодействия между специальностями добиться не удалось, доходит до абсурда что проектировщики отвечающие за здание но по разным системам «рисуют» совершенно разные планировки, а выяснятся это перед передачей документов заказчику. Стена на 2 метра севернее это еще цветочки.
                    Мой коллега отвечающий за подготовку 3D модели Финской станции. С сожалением признался мне что не понимает зачем он всем этим занимается поскольку по регламенту процесса проектирования нет места применению разрабатываемой 3D модели.
                      +1
                      А между тем — строят, оно работает, портфель заказов растёт.
                        0
                        Дай бог, дай бог! Искренне желаю, чтобы одна из немногих российских хайтек отраслей мирового уровня жила как можно лучше. Просто когда читаешь о таких случаях, как на БелАЭС или ЛАЭС, кажется, что строят и работают там часто не благодаря, а вопреки(
                        Ну типа как вторую мировую выиграли под чутким руководством сами знаете кого.
                          +1
                          Ну, знаете, в СССР безо всяких информационных систем, на одних кульманах и ватманской бумаге вышли на темпы поточного сооружения АЭС с ВВЭР, и успешно реализовывали задачи. А это — очередные «воздушные замки». Сама по себе идея верная, но в настоящей, невыдуманной менеджерами Росатома реальности, она не востребована. Достаточно вспомнить судьбу проекта ВВЭР-ТОИ.
                        –1
                        Странное тестирование — в тексте нет ни одного слова авария, отказ или сбой.
                          +4
                          До меня только после прочтения вашей статьи начало доходить, чем на самом деле приходится заниматься, например, NASA, и почему у них дорого и долго (по мнению тамошних аудиторов).

                          Как вы полагаете, насколько полной и детальной должна быть информационная модель сложного объекта для того, чтобы она стала прям сильно помогать?
                            +3
                            Ага, я вот тоже был таким оптимистом-программистом, утрировано говоря, считал что надо натравить машин лернинг, блокчейн, 3д принтер и дронов, и тогда можно будет заменить всех этих старых «пердунов» из Арева и Росатома на молодых, красивых и успешных стартаперов двигающих зелёную энергетику, заменить НАСА на успешный СпейсХ, а Вольксваген на Теслу, Аирбас да Боинг на кого-то из строящих персональные электролёты…
                            Познакомившись поближе с предметными областями, оказалось что ничего подобного — сложность там сейчас такая что у уму не постижима. И все эти стартапы стоят на плечах тех самых «пердунов» с их сложными и дорогими процессами.
                              +1
                              Если бы везде так, вон в физике частиц в симуляциях магниты и другие различные элементы представлены матрицами 4х4 или в лучшем случае 6х6. И как-то работает.
                            +5
                            Иногда очень сильно удивляешься, как люди раньше разрабатывали такие сложные проекты(АЭС, самолеты, ракеты, небоскребы и прочее). Сейчас с суперкомпьютерами, миллионами тестов и симуляций, мгновенной коммуникацией на любом расстояние и прочими прелестями 21-го века, это все делается очень долго, сложно, дорого и без ошибок.
                            А пол столетия тому, все схемы, модели и документация хранилась на миллионах бумажках, разбросанных по тысячам кабинетам. А большинство математических и физических расчетов делалось вручную. И при этом многие рекорды до сих пор остались за разработками 60-70х годов.
                              +2
                              Отчасти (не будем вспоминать 90-е) поэтому за ними и остались. Планы и расчеты на миллионах бумажках в тысячах кабинетов невозможно воспроизвести, только сделать ту же работу заново. Ну и все же современная АЭС и «АЭС из 70-х» по сложности отличаются на порядок.
                                +6
                                Подскажите пожалуйста, а где принципиально иной уровень?
                                Новые датчики, насосы, трубы?
                                Что из этого выполняет принципиально новую функцию?
                                Скада система, которая позволяет управлять мышкой, вместо настоящих кнопок и не бегать по пульту управления и километры проводов к ней — да, изобретение 21 века.
                                Ловушка расплава — новый элемент.
                                Но что означает принципиально новый уровень сложности, мне, извините непонятно.
                                Я, безусловно, хотел бы иметь более точные сравнительные данные, сколько же строителей реально было задействовано раньше, в 80е, а сколько сейчас. Тоже самое с материалами — сколько потрачено на материалы сейчас и сколько закуплено впрок, и какие данные тогда. Это, на мой взгляд, объективно показало бы эффективность внедрения всех описываемых в презентации дорогостоящих систем, стоимость которых, как это не странно, тоже влияет на конечную стоимость станции и в конечном счете на стоимость электроэнергии.
                                +1
                                Иногда очень сильно удивляешься, как люди раньше разрабатывали такие сложные проекты(АЭС, самолеты, ракеты, небоскребы и прочее). Сейчас с суперкомпьютерами, миллионами тестов и симуляций, мгновенной коммуникацией на любом расстояние и прочими прелестями 21-го века, это все делается очень долго, сложно, дорого и без ошибок.


                                Раньше было сильно по другому:

                                Миланский собор строился 579 лет
                                Собор Святого Вита строился 585 лет
                                Кёльнский собор — 632 года
                                Великая Китайская стена — 2000 лет

                                  +1
                                  Там вопрос финансирования. Во время войн и голода тяжело собрать пожертвования для постройки объекта не первоочередной важности.
                                    +1
                                    Там вопрос финансирования

                                    Сейчас — ровно то же самое.
                                    Имел удовольствие пообщаться с сотрудниками конторы, являющейся генеральным заказчиком строительства (это такая организация, через которую проходят государственные средства для строительства).
                                    Спросил — какие дома лучше по качеству и почему где-то строят быстро, а где то медленно.
                                    На что мне с хитрым прищуром ответили, что дело только в деньгах.
                                    То есть если строится за считанные месяцы — то все отлично с финансированием.
                                    Если строится такое же здание годами — то дело вовсе не в технической сложности, дело именно в финансировании.
                                    То же самое — деньги — относится и к качеству построенного.
                                    +2
                                    Да ну, римляне стокилометровые акведуки возводили за десяток-другой лет. А в наши дни метрополитены строят тоже уже столетиями.
                                  +1
                                  Было бы круто узнать про стек технологий, на которых всё это работает. Как делается интеграция с легаси.

                                  И, собственно, больше про само тестирование.
                                    –2
                                    Похоже, что ни каких подробностей мы не узнаем. Доклад делался с основной целью — реклама Росатома и Атомстройэкспорт.
                                    Комментарии из этой ветке людей, знакомых с ситуацией, отчасти это подтверждают.
                                    Также о недобросовестности докладчика косвенно говорит и то, что «живых» фотографий всех этих чудо-технологий (дроны-тестировщики, монтажники с планшетами, дата-киоск в котловане, сферические панорамы с автоматическим определением отклонений от проекта) в докладе нет.
                                    Подозреваю, что это доклад о технологиях типа «как могло бы быть» а не о «как есть на самом деле».
                                      +1
                                      «Доклад делался с основной целью — реклама»
                                      Доклад делался на конференции, основная направленность которой — тестирование в IT. Думаю, IT-тестировщики нечасто заказывают строительство атомных электростанций. И даже с точки зрения HR-бренда это для компании непрофильное мероприятие. В общем, если бы это было рекламой, то самой загадочной рекламой в мире: для чего такая нужна-то, что и кому она продаёт?
                                        +1
                                        Насколько знаю, JUG.ru Group принципиально не берет никакие рекламные доклады. Этот доклад хотела аудитория — она его и получила.

                                        Кроме того, как уже сказал Женя, непонятно, чего кому тут продавать. Разве что, продавать идею о светлом будущем профессии тестировщика. Но с каких пор это стало чем-то плохим?
                                          0
                                          В общем, если бы это было рекламой, то самой загадочной рекламой в мире: для чего такая нужна-то, что и кому она продаёт?

                                          Я вас умоляю…
                                          Грамотный маркетолог с легкостью превратит доклад на серьезной конференции в годную рекламу. Несколько вариантов:
                                          1. Отчет о конференции на сайте.
                                          2. Перепечатать доклад в профильном журнале для атомщиков (особенно в иностранном).
                                          3. Использовать части доклада в своих рекламных продуктах для заказчиков.
                                          Ссылка на уважаемую площадку, на которой делался доклад, придаст веса рекламным сообщениям.
                                            +1
                                            Кроме того, как уже сказал Женя, непонятно, чего кому тут продавать.

                                            См. мой ответ выше.
                                            Кроме того, я хочу добавить, что в тех местах доклада, в которых докладчик остается компетентным, о технологиях, которые реально (фактически) внедрены, доклад ни какого отторжения не вызывает. Например о сложности цифровой инфраструктуры из сотен тысяч элементов системы, которые нужно обслуживать, о стратегиях управления стадиями проектирования и строительства.
                                            Непонятки возникают в тех местах, в которых мечты и фантазии выдаются за сбывшийся факт, при реализации методов управления в материальном мире (всё то, что я перечислил выше — (дроны-тестировщики, монтажники с планшетами, дата-киоск в котловане, сферические панорамы с автоматическим определением отклонений от проекта).
                                              0
                                              «Перепечатать доклад в профильном журнале для атомщиков (особенно в иностранном)… ссылка на уважаемую площадку придаст веса»

                                              Боюсь, читателям иностранных журналов для атомщиков будет абсолютно непонятно, является ли российская айтишная конференция по тестированию (о которой они, работая в другой стране и в другой сфере, никогда не слышали) уважаемой площадкой.
                                                +1

                                                теория заговора прям.


                                                Не знаю, поверите ли вы, если скажу из первых рук, что докладчик уж точно не приходил выступать с целью попиариться сам или попиарить атомную промышленность.
                                                Цель была показать альтернативный мир (не сугубо программной разработки), в котором тоже есть место для тестирования.

                                                  0
                                                  Грамотный маркетолог может что угодно превратить во что угодно. И что? :)

                                                  Что, по вашему, должен делать докладчик — сидеть дома, ничего не говорить публично и прятаться от людей только по той причине, чтобы некий «грамотный маркетолог» не превратил это в рекламу?

                                                  Кстати, я конечно разработчик, но сейчас я работаю в отделе маркетинга. Не боитесь меня? Страшный человек же. :-)
                                                    +2
                                                    В принципе рекламировать себя и свою команду на конференциях можно и нужно, и в этом нет ничего плохого. Конференции для этого и организуются. Но здесь докладчика упрекают в том что он выдает желаемое за действительное. Система правда хороша, там заложено много умных идей и подходов. Но она не работает так как о ней рассказано в докладе максимум это 10% от представленного. Почему не работает Я не знаю, честно. Это вопрос из той-же оперы что и почему у нас не летает ангара, или почему у нас не пошел ё-мобиль, и не взлетел йотафон? И почему у нас получаются инновации?

                                                    Кроме того, как уже сказал Женя, непонятно, чего кому тут продавать.

                                                    Не для кого не секрет что, АСЭ сейчас пытается занять новую нишу на рынке. Это разработка и поддержка IT систем управления капитального строительства промышленных объектов. И этим докладом выступают на многих IT конференциях и выставках.
                                            +1
                                            Божественно! Испытал нереальное эстетическое удовольствие!!!

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

                                            Самое читаемое