Я закончил бывший Днепропетровский инженерно-строительный институт - тот же, в котором сейчас работаю, - причем поступив в него по причинам, так сказать, династического характера (ещё мой дед работал в строительстве, а с отцом мы и сейчас работаем вместе). Конечно, тема оценки неопределённостей (к которой относятся статистические методы, интервалы и многое другое) довольно далека от специализации моего далеко не самого математически продвинутого вуза, однако я решил заняться ей в диссертации, можно сказать, наперекор обстоятельствам.
Тема диссертации - после горячей дискуссии с научным руководителем, уступок необходимой практичности в ущерб идеализму - стала такой: "Учет неопределенности при анализе безопасности железобетонных конструкций атомных станций". Полученные в той работе знания помогают участвовать в разговоре о неопределенностях, статистике и надежности на каком-то приемлемом уровне, но на практике не использовались. Поэтому такое совпадение интересов у меня и Алексея - это определённо счастливый случай, который напомнил мне, как важно принимать радикальные решения.
Я хочу сказать, что с моим базовым образованием заняться чем-либо более близким ко всегда интересовавшей меня математике и информационной технологии было довольно сложно; во многом это были кустарно добытые знания, которые остались поверхностными. Теперь я постоянно стараюсь наверстать упущенное в основном за счёт самообразования.
У нас интересно: с одной стороны, лаборатория остаётся частью типичного постсоветского вуза со всеми недостатками организации и инфраструктуры, с другой стороны, мы умудрялись часто быть инноваторами - конечно, в сравнении со своей предметной областью и своим окружением. Лаборатория очень рано начала компьютеризацию работы, мы до сих пор, после расцвета частных инженерных предприятий и всеобщей доступности высоких технологий, одними из первых начинаем использовать новую технику.
Что касается информационной технологии в инженерном деле, то я получил возможность увидеть и поработать со множеством проблем, которые преследуют небольшие коллективы: неорганизованность, отсутствие централизованного внедрения технологий и ПО, болезни роста и проблемы оснащения и инфраструктуры и государственной бюрократии. С технической стороны разнообразие объектов и их сложность (мы работаем на всех АЭС Украины и на множестве других предприятий промышленности и гражданских объектах) также позволили мне получить довольно хорошее представление о широком диапазоне практических ситуаций, бывающих в AEC.
Ещё со школы я искренне полюбил математику (скорее, даже конкретно - геометрию), информационные технологии и программирование, поэтому при любой возможности стараюсь внедрять у нас автоматизацию и информационные производительные средства. Занявшись Автокадом, я прикоснулся к миру прикладной разработки для CAD - мы успешно проработали на моём приложении для стандартизации и оформления 2D-документов около пяти лет, пока не появились аналогичные инструменты аннотирования от самого вендора. Впрочем, подобные занятия занимали лишь остаточное время. В такой среде о внедрении тяжелых комплексов чего угодно - САПР, документооборота, рабочего процесса - думать не приходится, поскольку нерешёнными постоянно остаются задачи меньшего уровня. Всё это и сформировало мой интерес к так называемым "низкотехнологичным" методам работы, доступным небольшим коллективам за небольшие деньги, и особенно - к открытому ПО, менее зависимому от вендоров и дарящему уверенность, что выбранная и внедрённая практика работы не будет нарушена с новым релизом или с новым акционером.
Объекты, как я уже говорил, у нас бывают самые разные: начиная от массивных монолитных и грунтовых сооружений, продолжая мостами и заканчивая контайнментами реакторов, такими чудесными с точки зрения инженерии и такими непостижимыми с точки зрения моделирования. Подчеркну, что мы, как правило, работаем с существующими конструкциями, хотя бывают и исключения.
Острая необходимость автоматизировать работу над большим количеством проектно-инженерной информации, а также интерес к 3D-моделированию для расчетов конструкций естественным образом привёл меня к BIM и вообще к цифровому моделированию в AEC. Как раз в это время BIM стал играть серьёзную роль в инструментах для анализа конструкций, так что не заняться этим направлением было бы для меня преступлением.
А ещё я занимаюсь помимо основной работы такими вещами, как технические переводы (в том числе для локализаций программного обеспечения одного очень крупного западного разработчика, которого не могу назвать), отчеты по осмотру покупаемых объектов для иностранных клиентов (когда они ищут в сети LinkedIn украинских инженеров, у них, как правило, остаётся в итоге выбор между мной и моим спаниелем - коллеги, используйте соцсети!). В этом году я впервые за много лет поучаствую и в учебном процессе - буду помогать нашим интернам сделать хорошие дипломные работы, насколько это позволит образовательная система.
После того, как я (с вашей, Давид, и Изикада помощью) некоторое время помаячил на радаре AEC-публицистов и создал в целом впечатление дарования, мне сделали предложение, от которого совершенно невозможно было отказаться: поучаствовать в этом раньше невиданном для меня деле в роли консультанта и генератора идей. Я взял на себя смелость описать для специалистов АСКОНа перспективы и проблемы интегрированного моделирования в специализированной области AEC (анализ конструкций и расчетное моделирование) и возможности, потенциально реализуемые в будущем ПО для улучшения практик работы в этой области. Затем в офисе АСКОНа мы организовали что-то вроде неформального семинара, на котором обменялись знаниями и идеями - это был один из самых замечательных эпизодов моей работы. Думаю, что это - мой конкретный вклад в развитие программных средств для информационного моделирования и дальше, по мере развития продуктов АСКОНа, он продолжит расти.
На разных стадиях в этой работе продолжают участвовать и другие широко известные в наших узких кругах люди, которые, если захотят, расскажут об этом сами :).
А другие языки? Немецкий и французский, ответил я и густо покраснел. Этих двоих я знаю на уровне ломаного чтения и ещё более ломаного изрыгания очень базовых изъяснений.
Если серьёзно, я надеюсь на рождение точки непротиворечивости (насколько она возможна) во взглядах на пределы применимости, эффективность, область компетенции информационного моделирования в AEC. Мы постараемся достигнуть объективности в обсуждении дополняющих и альтернативных подходов к автоматизации, интегрированному моделированию, возможных способов радикально улучшить рабочие процессы с "низкотехнологичной" точки зрения.
Такую точку консенсуса в идеале возможно будет задокументировать: описать и ссылаться на неё в будущем, или хотя бы зафиксировать характер и причины принципиального и аргументированного расхождения во взглядах. Для тех, кто хотя бы краем глаза видел BIM-дискуссии, актуальность такой проблематики круглого стола будет очевидна.
Программа-максимум круглого стола - перейти от осознания "пределов BIM" к ясным формулировкам стоящих перед отраслью, во-первых, вызовов, а во-вторых, точек будущего качественного перелома в информационном моделировании и автоматизации AEC; актуальных не только для местного рынка, но и глобально. Откровенно говоря, думаю, что тут будут уместны средства и правила мозгового штурма, поэтому я призываю планирующих участие в работе стола настроиться на некритичный лад.
Я начал писать блог во время работы над диссертацией и выбирал в основном технические темы - тогда это было редкостью; блог создавался как записная книжка для того, что было для меня интересным, но не попадало в формат таких технических мест размещения контента, как DWG.ru или CADuser.ru. Было много разных планов собирать знания по приемам работы и моделирования для инженеров, поскольку одна из самых больших проблем в инженерном деле - это отсутствие онлайн-инфраструктуры: вики-систем, сервисов, баз знаний и платформ обмена контентом. В этом деле инженеры бедны, как церковные крысы, - если, например, сравнить с программистами.
Так продолжалось, пока я не узнал о форуме COFES/isicad и не увидел возможность посредством своего участия реализовать профессиональный интерес к трём вещам: моделированию, геометрии и обработке информации. Расчётное моделирование - на тот момент моя основная специализация - очень зависит от этих трёх тем, но является технической дисциплиной, а мне хотелось получить опыт общения на более общем уровне: уровне идей. Я заинтересовался BIM ещё до своего участия в isicad (а ещё раньше имел базовый опыт с некоторыми пакетами, которые сейчас считаются информационно-моделирующими) в связи с поглощением Autodesk разработчиков расчетного ПО Robot и наблюдением за рыночной эволюцией то, что сейчас называется AutoCAD Structural Detailing; кроме того, разве можно пройти мимо нового и интересного сегмента отрасли? Абсолютно невозможно.
Невозможно с этим не согласиться. Добавлю, что диалог людей, никак иначе друг с другом кроме общей специализированной области не связанными, часто перерастает в не очень разбирающееся в средствах соревнование в том, кто больший профессионал, причем каждый в таком случае, естественно, будет стараться переключить внимание диалога на свою профессиональную зону комфорта. Это и даёт, наверное, механизм разгона страстей. Так часто происходит, как мне сейчас вспоминается, во многих профессиональных группах независимо от их языка общения.
В таких случаях я полагаюсь на самое верное средство разрешения конфликта - свою отвратительную память, которая не позволяет мне долго помнить, кто и как мне что сказал. К сожалению, это помогает далеко не всегда.
Получается, эта проблема сломанности профессиональной коммуникации - очень серьёзная и преследует, по моему впечатлению, буквально всех, но по разным причинам: проектировщиков и экспертов-теоретиков, у нас и на Западе. Если говорить конкретно о BIM-дискуссии на портале isicad, то я хотел бы подчеркнуть две системные проблемы мышления и попросить участников дискуссии искоренять их у себя.
Во-первых, это проблемы с тем, что в отдельных случаях мы подразумеваем под BIM. Так получилось, что BIM - понятие многослойное, похожее на луковицу. Его можно определить на нескольких уровнях: на технологическом уровне, на уровне методов (процессов), на уровне парадигмы; а в англоязычном контексте BIM обозначает ещё и саму информационную модель. Например, спор о том, является ли BIM инструментом, технологией, методикой, процессом или парадигмой - это по сути непонимание того, какая конкретно ипостась обсуждается. На практике именно это непонимание влечёт за собой споры о том, чем является и чем не является BIM, и массу других поводов обесценить дискуссию.
Во-вторых, это презумпция благополезности прогресса. Часто программному продукту или функции достаточно быть новыми, чтобы заработать похвалу и роль аргумента в споре. Между тем технологический прогресс очень часто бывает ошибочным или неочевидным. Можно привести такие свежие примеры из потребительского IT, как проблемы Фейсбука с чрезвычайно прогрессивной технологией HTML5 или противоречивое отсутствие технологий беспроводной зарядки и связи по ближнему полю в последнем выпуске Айфона.
Между тем, и дискуссия, и Круглый стол имеют смысл как место, откуда можно вынести знания, а не представление о том, у кого какое мнение. Поэтому я отношусь к организации Круглого стола как к самообучению и возможности проверить собственные рассуждения в жёстких полемических условиях. Ценящее идеи и настроенное на равноправный обмен знаниями онлайн-сообщество у нас ещё формируется (в основном за счёт социальных сетей), поэтому живое мероприятие - один из немногих способов научиться друг у друга хорошему, а не полемическим уловкам.
Так, в результате перегретой дискуссии вокруг единой модели, аналитических моделей и пределов применимости BIM и последующей работы с публикациями появилась небесполезная заметка о конструкционном BIM. Тогда я и стал интересоваться теоретическими вопросами моделирования в BIM (необходимая оговорка: имею в виду парадигму, а не технологию) и публикациями о (не)возможности и фактическом отсутствии единого интегрированного моделирования в BIM (по этой теме интересны, например, статья и дискуссия в LinkedIn).
Сильно изменилось (а местами - нашло новые аргументы) моё представление о том, как в мировой дискуссии о BIM расставлены акценты и какие проблемы актуальны, как и за счет чего происходит прогресс в BIM и поддерживающих его технологиях вроде IFC, кто в рабочем процессе является выгодоприобретателем от BIM: коротко говоря, BIM гораздо в меньшей степени относится к проектировщикам, инженерам и вендорам, чем раньше представлялось; и больше он должен интересовать инвесторов и подрядчиков. Остальные подробности можно посмотреть в моих комментариях внутри перевода "Семи смертных грехов BIM" авторства Д. Хольцера.
Далее, особенно поразила меня видимая неспособность IT решать концептуальные проблемы отрасли - притом что именно технология, программные реализации, события в среде вендоров BIM-технологии в основном оказываются предметом новостей и обсуждения. Например, из беседы с автором книг о BIM и одним из разработчиков универсального формата IFC Чарльзом Истменом у меня сложилось впечатление о сугубой техноцентричности экосистемы вокруг IFC, которую заботят только технические аспекты формата и сложности взаимодействия с вендорами (которые попросту хотят получать бесплатно готовый современный формат обмена данными). Я хочу сказать, что нельзя надеяться на решение возникающих с BIM проблем со стороны IT-сообщества, нужно самому вовлекаться в работу над будушим BIM.
Своё нынешнее понимание текущих возможностей BIM я хочу проиллюстрировать аналогией с физическим процессом, перколяцией. Можно представить себе проникновение и эффективность BIM для спектра разных задач в AEC показанной на рисунке картиной "просачивания" вещества через пористую среду. Попросту говоря, во всём диапазоне задач AEC BIM оказывается эффективным (и получающим широкое внедрение, хотя не обязательно одновременно то и другое) на отдельных участках. Со временем BIM "перколирует" и в смежные области, расширяя своё присутствие в индустрии. Однако если какая-то область осталась "не пропитанной" BIM, то и вертикального интегрированного процесса в ней не сделаешь.
Начну с принципиального заблуждения о том, является ли составной частью BIM (как видим, проблема опять в области определения!) архитектурный эскиз, первичный замысел, концептуальное формообразование. Я и сам разделял раньше заблуждение о том, что BIM включает в себя эту самую раннюю стадию проектирования. Это страшно мне не нравилось с эстетической точки зрения, поскольку BIM на практике всегда устанавливает дополнительные рамки, требует большой подготовительной работы и вращается вокруг требований к информационному наполнению, которому на этом этапе просто неоткуда взяться.
Недавно я был рад узнать, что эта проблема решается гораздо проще, чем казалось: попросту не стоит включать этот этап в зону компетенции BIM, и тогда сразу всё станет на свои места. Такая сегрегация ответственности между концптуальным моделированием и BIM может показаться надуманной: если BIM эффективен для поздних стадий, что мешает применить его для концептуализации, кроме трудно оцениваемых эстетических предубеждений против, так сказать, индустриальной природы BIM?
Оказывается, если попробовать выяснить об отношении к такой сегрегации, то всё оказывается даже круче: не только BIM, но даже и просто компьютерное черчение оказывается незваным в царстве чистой архитектуры. В качестве примеров аргументации я порекомендую сторонние источники (поскольку архитектором не являюсь и сам рассуждать об эстетических аспектах AEC опасаюсь) от западных экспертов: "Мёртв ли чертёж?" (Эрик Льюис), "Архитектура и забытое искусство изображения" (Нью-Йорк Таймс), "Мода на здания-зомби: убивает ли она наши города?" (ArchitectureSource).
Другой вопрос, который я не устаю поднимать - это проблема единой модели в BIM. Её понимают очень по-разному, и с точки зрения парадигмы BIM, комплекс информационной модели и множества других моделей для простоты принимают за единую модель. С точки зрения технологии BIM, вопрос выглядит совсем просто: единой модели не существует. Конечно, есть привязанная к конкретному вендору инфомодель, но единой для всех дисциплин модели - определим её с информационной точки зрения как "единственный, унитарный, интегрированный источник актуальной информации" - на практике не бывает (кстати, обсуждение похожей проблематики для BIM-формата IFC можно найти на LinkedIn, "В BIM не бывает центральной модели").
Собственно, она и не нужна. Главный принцип для моделирования и построения рабочих процессов: каждая задача должна решаться инструментом, лучше всего подходящим для этой задачи (с учетом опыта оператора, конечно); иными словами, BIM должен давать возможность использовать те же специальные инструменты моделирования, которые были бы выбраны и в случае отсутствия BIM-процесса. А такой принцип требует горизонтального сопряжения моделей по заранее определенным правилам.
И, наконец, третий момент - более или менее стандартный для всякой новой и популярной технологии.
BIM катастрофически сильно оброс пропагандой. Так, если крупным игроком ПО для BIM выпускается новый продукт, в специализированных изданиях не будут тратить силы на его анализ по существу, а просто перепечатают пресс-релиз разработчиков, который в нечастых, но прискорбных случаях может вводить в заблуждение.
Некритичный BIM-энтузиазм ведёт к проблемам объективности. Говорят о высоком проникновении BIM в западную практику AEC - а на практике мы узнаём, что проникновение в большой доле случаев оканчивается контрактными требованиями предоставить двумерную документацию и только её, по возможности выполняя базовые требования BIM даже не как процесса, а как конкретной технологии выполнения документации.
Говорится о том, что настоящая ценность BIM в работе на всём жизненном цикле здания - а в реальности, по некоторым данным, полезная модель заказчику передаётся в единичных случаях.
Высокая и некритичная освещаемость BIM плоха ещё тем, что внимание сообщества и ключевых игроков переносится на BIM в ущерб другим возможным направлениям. Такая ситуация чем-то напоминает историю с финансированием медицинских исследований в Индии: после того как фонд Гейтсов направил десятки миллионов на борьбу с ВИЧ, выяснилось, что такое обилие внимания и финансов спровоцировало колоссальный отток ценных медицинских кадров из других областей (например, туберкулёз), которые не получили такого преимущества, но от этого не перестали быть тяжелыми проблемами.
Таким образом, думаю, поиск критики BIM ещё долго будет гораздо более интересным занятием, чем поиск благоприятных трендов. Из таких лично мне интересны продукты, направленные на упрощение и междисциплинарный обмен информацией. Примеры - это относительно недавняя покупка Autodesk технологий Horizontal Glue, которые должны стать частью BIM360; очень интересный в своей простоте и полезности инструмент BIMLink (который извлекает из Revit данные для табличного редактирования и может возвращать их обратно); и, вероятно, одно из последних достижений Autodesk - Revit LT. Думаю, перечисленные продукты - это примеры очень правильного подхода к решению стоящих перед парадигмой BIM вызовов.
Проблематику Хольцера и своей первой статьи на isicad можно долго дополнять, однако такие перспективные направления развития BIM для меня остались актуальными:
- развитие модульных компонентов, инструментов частичного внедрения инфомоделирования, способных работать с ПО разных вендоров (сейчас это направление сводится к инструментам, обменивающимся данными в формате IFC);
- другой уровень обмена данными: появление новой "горизонтальной" автоматизации для более простых, чем BIM, методов моделирования;
- отказ от тотального внедрения BIM-процесса в пользу автоматизации существующих процессов до уровня, способного работать с BIM (в отличие от перехода на более оптимальные, "родные" для BIM процессы).
В этих направлениях поменялось другое: понимание того, что такое развитие имеет мало отношения к BIM-парадигме. Оно имеет отношение к автоматизации рабочих процессов в более широком смысле и на более простом уровне интеграции.
Думаю, что следующим шагом должно быть определение области информационной технологии в AEC, ответственной за такую автоматизацию. Зачем это нужно? Затем, что BIM не может и не должен заниматься одновременно и революционной вертикальной "перепрошивкой" рабочих процессов, и всеми возможными дисциплинами в AEC (а кроме этого, есть ещё смежные области, например, в MCAD, которые было бы так интересно интегрировать в нашу отрасль!) Мы должны осознать пределы применимости BIM и её отношение с методами автоматизации - существующими и будущими. Это очень важно в первую очередь для таких дисциплин в AEC, которые (если говорить о парадигме, а не о существующих технических реализациях) не относятся к BIM. К ним я бы отнёс архитектурный дизайн, построение исследовательских моделей, расчетных моделей (т.е. симуляцию) и - частично - автоматизированное документирование (с этим сложнее; конечно, есть и документирование, выполняемое полностью в рамках BIM-парадигмы).
Как ясно определить такую область IT для AEC? Это должна быть область, определенная на основе главного понятия инженерного дела: модели. На понятие модели опираются современные средства автоматизации инженерного дела в любой профессиональной области (больше по этому вопросу - в августовской статье Эвана Яреса "Почему вам нужно понимать инженерию на основе модели"). Один из китов BIM - это объектная модель высокого уровня связности и интеллектуализации.
Я думаю, что зонтичный термин "инженерия на базе моделей" довольно удачен, поскольку определён самой сутью цифровой инженерии. Всё, что мы делаем в рамках цифровой инженерии (и аналоговой, "бумажной" тоже) - от реализации отдельной формулы из нормативных документов до инфомоделирования в рамках BIM - можно и нужно представить как модель. Это позволит наконец получить термин для предметной области, так часто и ошибочно причиcляемой к BIM и не получающей должного внимания пользователей и вендоров.
Приложение сил в предметной области AEC в направлении "инженерии на базе моделей" и других основанных на моделировании направлений должно быть направлено на горизонтальное связывание самых разных моделей, на построение инфраструктуры для их формализации и обмена данными (а в перспективе - и обогащенной семантикой информацией, "цифровыми знаниями"). Это сулит, как я себе представляю, появление множества мощных инструментов на базе использования существующего кода моделей. Вы встречаетесь с локальными реализациями таких инструментов (на уровне от таблицы в Excel до программирования с использованием библиотек визуализации и дизайнерских инструментов, как в случае, например, работы НАСА) в других отраслях всегда, когда рассматриваете инфографику, информационные презентации, результаты научных исследований. По такой схеме работают программисты, ученые, визуализаторы, специалисты по обработке информации и многие другие люди, работающие с информацией - но не инженеры. Это надо понимать так, что ключевой технологией инженерии на базе моделей должна стать возможность связывать модели без "настоящего" программирования. Сейчас, я думаю, настало время осознания того, что инженер будущего - это тоже информационный специалист. Пора создавать инструменты для этого специалиста.
Суммируя этот ответ, необходимо пояснить: это не прогноз, а очень поверхностная дорожная карта, сценарий развития информационной технологии, возможность достижения интегрированной работы на совершенно другом уровне, чем тот, который мы можем достичь в нынешних реалиях. Недавно я пошутил в Твиттере про то, что интегрированное проектирование - это когда в Ревит можно будет интегрировать написанную в какой угодно системе так называемую глайдерную пушку - математическую модель клеточного автомата. В каждой шутке есть доля правды: пушку - не пушку, а произвольные расчеты на базе модели (такие, как, например, расчет штормового затопления, сделанный в рамках научной работы и никак не имеющий в виду инфомоделирование) можно будет бесшовно интегрировать в вашу информационную модель.