«Камо грядеши…»: современные стратегии междисциплинарного сотрудничества в век BIM
Принцип интегрированного выпуска проекта (Integrated Project Delivery, IPD)* призывает нас к сотрудничеству. Конечно, само по себе сотрудничество — не новость для строительной отрасли, да и для всего человечества: эффективное взаимодействие — фундаментальное понятие сообщества людей. Вероятно, ярчайшим примером коллективного взаимодействия было строительство пирамид в Древнем Египте. Строительная индустрия явила и другие потрясающие образцы совместных проектов — например современные небоскребы.
И все же взаимодействие при проектировании — явление для архитектурно-строительной области относительно новое. Ясно, чтобы добиться хороших результатов при строительстве, архитекторы и инженеры должны работать вместе: здания становятся сложнее и сложнее, проектировщики уходят во все более узкую специализацию. Но сегодня, даже работая над одним зданием, архитекторы и инженеры используют разный набор инструментов и разные технологии проектирования. Неудивительно, что процесс проектного взаимодействия осложнен проблемами координации данных и их обмена между решениями.
В этой статье я расскажу о том, как различные поставщики программного обеспечения решают вопросы взаимодействия своих клиентов. Также я хотел бы коснуться некоторых очень важных проблем, решение которых нам предстоит искать сообща.
Сначала был DWG...
Во времена плоских САПР междисциплинарное взаимодействие было ограничено технологически простейшим уровнем: плоская 2D-информация передавалась через файлы DWG (рис. 1). Этот механизм просто повторял традиционные принципы проектирования: курсирующие бумажные чертежи «доносили» проектную идею. До определенного момента такие ограничения устраивали участников проектного процесса. Просто они мало зависели друг от друга или не зависели вообще — передавалась только базовая информация о проекте.
Рис. 1. Типичный процесс 2D-черчения во времена плоских САПР
Изменение парадигмы
С развитием принципа BIM-проектирования (Building Information Modeling — информационное моделирование зданий) появились новые возможности: общение проектировщиков на уровне модели, через ее различные части, с использованием информации, уже заложенной в модель. В то же время обнаружилось неожиданное препятствие: различные системы моделирования обладают собственными форматами файлов, которые содержат (и это важно!) уникальные для этих систем данные о моделях.
Поставщики программного обеспечения (системные интеграторы) сформировали три основные стратегии, которые позволяют обойти эту преграду. Позволю себе рассказать об этих стратегиях.
Единый язык описания
Для разработки единого стандарта IFC (Industry Foundation Classes) — открытого файлового формата, не обремененного правами собственности на него, производителями САПР-систем был образован Международный альянс по интероперабельности (International Alliance for Interoperability, IAI). Новый формат призван стандартизовать «язык общения» систем автоматизированного проектирования, которые используют метод проектирования, основанный на модели.
Стандарт ISO, лежащий в основе IFC-формата, определяет встроенный набор «умных» строительных конструкций и, по сути, является некой «картой соответствия» при конвертации моделей между приложениями, поддерживающими формат IFC. Благодаря возможности сохранения/открытия «универсального» IFC-файла пользователи могут напрямую передавать модели в программные решения, применяемые другими специалистами.
Прямые интерфейсы
Другой способ, предложенный системными интеграторами, — это разработка специализированных связок между решениями. Иногда этот шаг делается только в одну сторону и реализуется с помощью API (Application Programming Interface) от другого приложения. Но, конечно же, оптимальные результаты достигаются, если поставщиков программного обеспечения связывают долговременные отношения. В таком случае при разработке связки они не только определяют, каким образом решения обмениваются данными, но и стараются сделать эту связку максимально удобной и эффективной для пользователей.
Единая платформа
Принципиально другая стратегия реализуется, когда поставщик программного обеспечения обладает достаточной компетенцией во всех областях AEC-рынка и стремится охватить своими решениями весь спектр потребностей. Понятно, что в этом случае собственный закрытый формат файла позволяет без проблем обмениваться данными между различными приложениями, входящими в «единую» продуктовую линейку (семейство). Взаимодействуя на «родном» языке, приложения должны обеспечить эффективную координацию.
Какой путь лучше?
Защищая любую из вышеописанных стратегий, можно найти весьма любопытные аргументы: о проблемах стандартизации, о поддержке единого рабочего процесса и т.п. Но все эти аргументы тем только и интересны, что любопытны! Как сделать выбранные решения максимально полезными для клиентов? — вот основной вопрос, на который должен ответить поставщик при выборе пути.
Далее я обозначу вопросы, на которые, по моему мнению, очень важно найти верные ответы.
Разнообразный мир
Без сомнения, решение, базирующееся на единой платформе, имеет свои преимущества. Но окружающий мир (который мы же и проектируем) гораздо разнообразнее. Должны ли архитекторы и инженеры жертвовать своими возможностями совместной работы ради взаимодействия с теми компаниями-подрядчиками, которые применяют инструменты единой продуктовой линейки?
Пожалуй, за исключением крупных архитектурно-строительных холдингов, где под одной крышей собраны все специальности, ответ будет отрицательным — так ответит большинство фирм, занимающихся архитектурной практикой. Потому что каждая из них использует решение, которое прежде всего заточено под ее нужды. Потому что каждый день в процессе работы над проектами они сотрудничают с широким спектром специалистов, которые могут применять свой спектр программного обеспечения.
В свою очередь, настроенная матрица взаимодействия между решениями дает дополнительные плюсы. Наиболее интересный — возможность построить гармоничную цепочку решений, состоящую из специализированных, лучших в своем классе программных продуктов, и при этом остаться в рамках технологии BIM-проектирования. В этом случае профессионалы, использующие проверенные решения и предоставляющие гарантированные результаты, могут продолжать работу в той среде, которой они доверяют и которой привыкли пользоваться.Итак, серьезный вопрос: сможете ли вы объединить преимущества единой платформы с преимуществами узкоспециализированных решений, которых так много в окружающем нас разнообразном мире?
Ожидания от IFC
Несмотря на то что существует стандарт ISO, можно ли ожидать, что формат IFC достигнет такого уровня, который обеспечит «бесшовный» процесс сотрудничества и высокое качество конвертации данных?
Наиболее распространенное мнение сводится к тому, что IFC охватывает только 80% потребностей. Это означает, что в целом он подходит, но по всем конкретным случаям полагаться на него мы не можем.
Что и говорить, аргумент серьезный, но боюсь, что подобные выводы — результат ошибочных ожиданий. Структура данных IFC гораздо богаче потребностей любого BIM-приложения, которому из этих данных нужна лишь малая часть, относящаяся к зданию, да и работа над самим форматом еще не завершена.
Существует великое множество успешных примеров сотрудничества, построенного на формате IFC. Правда, это сотрудничество основывалось на простом экспорте IFC-данных, предназначенных для общих задач, без ответа на простейший вопрос: как переданные части будут в дальнейшем использоваться в модели?
Думая о цельном рабочем процессе
В конце концов, сам по себе процесс экспорта данных проектировщика или специалиста не интересует. Его интересует эффективная и «бесшовная» интеграция с выбранным программным обеспечением.
Именно по этой причине поверхностный взгляд на IFC приводит к ошибочному выводу: получили IFC-данные (без контекста и смысла) — и этого достаточно. В действительности это ограниченные данные (если их вообще можно назвать данными)!
Желая наладить действительно качественную совместную работу, мы должны думать о двусторонней интеграции, при которой специфические разделы разбиты на части, а повторяющиеся процессы управляемо изменяются и выполняются в рамках соответствующей дисциплины.
Поэтому рабочий процесс должен строиться на логике двух дисциплин. Распознав ее, мы определимся и с методом передачи данных. Что именно окажется самым подходящим: IFC, API или закрытый формат — вопрос второстепенный.
Рис. 2. Взаимосвязь ArchiCAD — Revit Structure: переданы только нагруженные конструкции
Если принять эту точку зрения, то, при некоторой оптимизации, идеальным решением может стать IFC. Интересный пример такой интеграции — взаимодействие через формат IFC между ArchiCAD и Revit Structure. Принимая во внимание специфические требования программного продукта Revit Structure, ArchiCAD способен выдать «вычищенный» набор данных, необходимый для работы конструкторов (рис. 2). Это решение обеспечит технологический процесс взаимодействия между архитекторами и конструкторами через платформу IFC.
Стандартизованный протокол?
Интеграция приложений, показанная в нашем примере, обладает большим потенциалом для тех компаний, которые выстраивают взаимодействие на стандарте IFC-интерфейса. А в реальной проектной деятельности нужно создавать «двунаправленные» методы сотрудничества между архитекторами и инженерами. Вы можете возразить: мир гораздо сложнее и каждую связку, каждый рабочий процесс невозможно прорабатывать до мелочей.
У меня другое мнение! Основы подобных процессов во многом однотипны и, взяв за основу проработанную логику взаимодействия для одного решения, инфраструктура очень быстро адаптирует ее к другим. На рис. 3 приведена схожая диаграмма рабочего процесса по связке ArchiCAD с Tekla Structures.
Рис. 3. Взаимодействие ArchiCAD — Tekla Structures: изменения, внесенные архитектором, отражаются на мониторе инженера-конструктора
Резюме
Цель моей статьи — обозначить проблемы, которые возникают при совместной работе, и начать дискуссию о том, как сблизить архитекторов и конструкторов, наладить их взаимодействие. Я пытался показать, что настоящий вопрос, связанный с BIM-интеграцией, формулируется очень четко: как поставщик программного обеспечения может объединить преимущества единой платформы с преимуществами узкоспециализированных решений, которых так много в окружающем нас разнообразном мире?
Совершенно ясно, что наиболее подходящее решение — то, которое учитывает особенности взаимосвязанных проектных дисциплин. Единственно возможный (и уже проверенный) ответ — это продуманное решение, основанное на IFC-платформе. Я верю, что в наших общих интересах не потерять «биологическое разнообразие» нашей планеты. Во всех смыслах — в том числе и в стратегии сотрудничества.
Перевод с английского Дениса Ожигина (ЗАО «Нанософт»)
Опубликовано: AECbytes. № 43 (16 марта) 2009; http://www.aecbytes.com/viewpoint/2009/issue_43.html
*Принцип интегрированного выпуска проекта (Integrated Project Delivery, IPD) — современная инициатива западной строительной индустрии по организации комплексного процесса проектирования. Инициатива объединяет людей, технологии, системы, кадровую политику и регламенты таким образом, чтобы направлять таланты и умения всех участников единого процесса на сокращение затрат и повышение производительности на всех стадиях проектирования, производства и строительства. Подробности — на сайте Американского института архитектуры (The American Institute of Architects, AIA). — Прим. перев.
Виктор Варконий (Viktor Va’rkonyi)
CEO компании Graphisoft. На протяжении последних 20 лет участвует в развитии архитектурно-строительных технологий проектирования на базе ArchiCAD — одного из лучших BIM-решений для архитекторов. Задать вопросы автору и получить комментарии по этой статье вы можете по адресу: vvarkonyi@graphisoft.com.
 |
|
