Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

Если посмотреть на срез (t, время), то вертикальная прямая красная линия как раз показывает, что проект одновременно находится сразу в нескольких стадиях жизненного цикла, т.е. V-модель такая широкая, потому что в современном мире никто не ждет, когда закончится одна стадия (например, стадия разработки требований), начинаются проектирование, изготовление. Таким образом, в этом плане возникают еще бо́льшие требования к координации участников проекта, потому что вы не ждете окончания стадии. где-то еще, может быть, заказчик определяется с требованиями, где-то уже вовсю идет разработка проекта, а где-то уже, грубо говоря, начали копать котлован (потому что про него уже всё понятно, там уже есть проект и т.д.). Собственно, эти темы, связанные с гибкими подходами, с 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 снова приходит в Москву. Увидеть актуальное состояние программы (и, при желании, приобрести билет) всегда можно на сайте конференции.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть