Мы уже привыкли, что запуск тестов производится нажатием одной кнопки. Проверки проходят автоматически при каждом коммите, статистики собираются без участия тестировщика, а баги заводятся в полуавтоматическом режиме. В общем, мы привыкли применять технологии программной и системной инженерии к нашим программным проектам. А теперь представьте себе, что перед вами стоит задача протестировать работу атомной электростанции. Нужно не только протестировать её софт, но и провести испытания всех её составляющих.
Разумеется, никто не сможет сначала построить станцию и потом перенести несущую стену из-за того, что система вентиляции не сможет быть смонтирована в текущей конфигурации. Поэтому процессы реального мира всё больше уходят в «цифру». Как вам понравится комментарий к коммиту «Перенос капитальной стены на 2 метра севернее»? При проектировании и тестировании АЭС применяется полностью цифровой подход: создается информационная модель, к ней применяется классическая V-модель управления жизненным циклом. Таким образом, АЭС превращается в тиражируемый и полностью цифровой объект. Тестирование и запуск современных АЭС происходит в цифровом виде, и только после этого строители приступают к монтажу, используя всё те же цифровые модели.
Из этой статьи вы узнаете о том, что представляет собой современная информационная система, как происходит разработка и тестирование «капитальных» объектов на примере АЭС.
В основе материала — расшифровка доклада Вячеслава Аленькова, директора по системной инженерии и информационным технологиям инжиниринговой компании «Атомстройэкспорт» (ASE) с нашей декабрьской конференции Heisenbug 2017 Moscow.
В этой статье я расскажу о том, как мы используем технологии управления информацией, тестирование различного рода процессов при сооружении крупных капитальных объектов (в нашем случае это атомные станции). С учетом того, что в капитальном строительстве идет глобальное внедрение цифровых технологий и эти технологии все больше и больше проникают в разные индустрии, в том числе связанные с физическим миром, то и технологии, связанные с ИТ, тоже активно входят в это направление.
Небольшое введение: «Атомстройэкспорт» (ASE) — это компания, которая является инжиниринговым дивизионом госкорпорации «Росатом». Мы отвечаем за проектирование, закупку/поставку и сооружение практически всех атомных станций в России и за рубежом, более чем в 15 странах мира. Более 90% наших проектов — это строительство и проектирование станций за рубежом, и в этом плане мы впитываем лучшие требования, лучшие практики со стороны международных регуляторов, задающих нормативы и правила, со стороны международных заказчиков.
Во многих странах тема требований к «цифре» очень высока. Многим заказчикам уже нужен не только построенный объект в бетоне/железе, который — вот он, стоит в поле. Теперь нужно рядом сдать цифровую модель объекта, которая будет жить потом на протяжении всего жизненного цикла атомной станции. Станция строится 5-10 лет, эксплуатируется потом 60 и более лет, то есть всё, что мы сделали (с учетом вывода из эксплуатации до 100 лет) будет потом использоваться и жить на соответствующем объекте. При этом, как вы понимаете, чуть ли не каждый год в ИТ с точки зрения технологий что-то кардинально меняется, и как это спрогнозировать на 100 лет — это, конечно, большая проблема.
Атомная станция — на сегодняшний день, наверное, один из самых сложных объектов, которые строит человечество, с точки зрения сложности объекта, количества участников, а также обеспечения безопасности этих объектов. Поэтому без цифровых технологий эти объекты практически невозможно построить. Сейчас заказчики (несмотря на то, что объект сложный) каждый раз ставят требования построить объект «ещё быстрее» и «ещё дешевле», при этом мы одновременно строим и проектируем 30 таких сложных объектов в разных странах мира, и управлять таким массивом информации без цифровых технологий невозможно. К примеру, основные параметры — это сотни тысяч позиций разного оборудования, и каждая позиция сама по себе является сложным инженерным объектом. Это десятки тысяч уникальных классов оборудования, десятки и сотни тысяч цифровых требований на входе (чуть позже расскажу об этом подробнее), это информационная модель, в которой содержится сотни тысяч, иногда миллионы элементов, взаимосвязанных между собой, — и всё это не конечный продукт: модель всё ещё «течёт», меняется, с этой цифровой информацией одновременно работает огромное количество участников, между ними возникает большое количество коллизий, и очень важно взаимосвязано управлять всем этим процессом, чтобы это всё не разъехалось. Конечно, существуют вопросы, связанные с подготовкой «контейнеров» для складирования этой информации, создания связей между элементами, для приемки/проверки/тестирования всего, что происходит в процессе проектирования. На этапе проектирования возникает больше всего информации об объекте, и уже потом, на стадии сооружения, она меняется. Как раз на стадии проектирования создается информационная модель объекта, у нас есть набор технологий — их там большое количество, но я выделил здесь несколько ключевых, которые позволяют управлять этой информацией, чтобы это всё не рассыпалось.
Одна из первых стадий — это создание информационной модели, которая, само собой, включает в себя понятие 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-модели (при этом вы можете обернуться вокруг себя, прокрутить, посмотреть), и справа вы можете видеть, что, с точки зрения модели, в этот момент времени должно было быть сделано, а слева видите реальную фотографию того, что же на самом деле в этот момент происходит на стройке. И вы очень быстро можете сопоставить, по плану всё это идет или не по плану, есть отклонения или нет отклонений. Раньше для этого нужно было провести огромное количество сравнительных операций — посмотреть документы, сравнить с графиком — а сейчас очень быстро, за считанные минуты, вы можете увидеть движение проекта, причем удаленно, т. е. не надо физически ехать на этот объект, вы смотрите, как все происходит на самом деле. Внизу — ползунок по времени, если его прокрутить, то у вас будет «кино» о том, что происходит — и в модели, и реальной жизни.
Соответственно, как я уже сказал, важным моментом является не только моделирование, но и проверка по факту выполнения работ. Многие вещи делаются уже не «на глазок», когда вы пришли и увидели — да, действительно поставили оборудование или залили бетон, но у вас нет средств формального контроля. Сейчас такие средства есть — вы можете с помощью лазера просканировать объект, увидеть, что он действительно не отклонился ни от одной из своих осей. Более того, сейчас это можно делать с помощью дронов, если говорить про объекты не внутри здания, а на площадке. Технология активно развивается: человеку даже не нужно ходить и тратить время, если объект большой. Вы можете регулярно, более того — в автоматизированном режиме заполнять, запускать по какому-то алгоритму дроны, которые будут сканировать и уже по факту давать информацию, есть ли отклонения от того, что у вас в модели на текущий момент времени. Есть соответствующие другие средства контроля внутри объекта, те же самые сферические панорамы — таким образом, вы фактически делаете срез системы автоматизированного контроля (автоматического контроля, тестирования, говоря вашим языком) того, действительно ли делают то, что изначально вы запрограммировали в виде проекта, в виде информационной модели.
В заключение я хотел бы сказать, что с учетом тотальной цифровизации физического мира (а тренд все заметнее и заметнее), те навыки, которые сейчас развиты в ИТ-индустрии, в том числе тестирование, все активнее и активнее проникают в реальные физические индустрии. И в этом плане я хотел бы, может быть, даже раскрыть потенциал технологий. Например, когда мы берем себе сотрудников, то очень многих берем на инженерные позиции, но из ИТ-индустрии, потому что иногда легче из айтишника сделать инженера, чем в некоторых инженеров перенести навыки этой культуры, гибких подходов и т.д., хотя это, конечно, не всегда так.
Разумеется, никто не сможет сначала построить станцию и потом перенести несущую стену из-за того, что система вентиляции не сможет быть смонтирована в текущей конфигурации. Поэтому процессы реального мира всё больше уходят в «цифру». Как вам понравится комментарий к коммиту «Перенос капитальной стены на 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 снова приходит в Москву. Там будут и полезные советы, и удивительные истории, и миры тестировщиков и разработчиков вновь соприкоснутся. Увидеть актуальное состояние программы (и, при желании, приобрести билет) всегда можно на сайте конференции.
