Проблема BIM заключается в том, что ее еще нет в полном объеме — даже у западных компаний. В текущей реализации BIM — это скорее религия и концепция, чем работающая технология. Если концепция и работает, то только среди 2-3-х специальностей, а маркетинг затем уже это разгоняет до «ой, вы еще не работаете в BIM? ой, вы отстаете, весь мир уже работает, несите деньги к нам»… Вы и несете в западные решения, образуя финансы для дальнейшей работы, раскрутки и, без сомнения, новых разработок. В этом и есть сила маркетинга и сила западных компаний: люди предпочитают покупать, а не думать…
Если маркетинг откинуть, то существует сейчас два подхода: BIM от одного производителя и BIM от разных производителей.
Наиболее ярко первый подход реализует Autodesk, маркетинговые буклеты которого заявляют, что его Revit подходит архитекторам-конструкторам-инженерам. В реальности все несколько печальнее пока — на мой взгляд Revit дает относительно хороший инструмент конструкторам (но, кстати, только моделирование (!), расчеты уже в другой программе), относительно сносный архитекторам (ArchiCAD все-таки сильнее) и практически никакой инженерам (нет баз, расчетов, кантрификации да и как моделирующий инструмент вообще хромает)…
Второй подход более сложный и во многом лежит на плечах внедренцев: например, архитектура в ArchiCAD, конструкции в Tekla, вентиляция в MagiCAD, электрика в nanoCAD Электро — кто-то способен увязать это в единое решение? а заплатить за это? или вложиться в НИОКР?
Учтите, что BIM еще относительно неплохо работает при общественно-гражданском проектировании (т.е. там, где технологии более-менее зафиксированы, не сложные и играют не самую главную роль). Если вы выйдете в промышленное проектирование (например, нефтеперерабатывающий завод), то там уже главное, чтобы сооружение перерабатывало нефть — т.е. важны расчеты, техпроцесс, контроль, безопасность и все остальное. BIM должна быть другой, особенной…
Ну, и еще… BIM шикарная вещь на стадиях концептуальной проработки проекта и собственно проекта. На стадии выпуска рабочей документации BIM избыточна. Она выдает заготовки чертежей и, если вам этого хватает, то отлично. Но чаще всего модели BIM мало для выпуска полноценной рабочей документации. Часто изменения в BIM модель более сложные, чем исправления документации. Часто BIM модель все-таки несколько условна, чтобы получить точную рабочую документацию. И тут происходит разрыв между САПР и BIM… и nanoCAD начинает рулить ))
А так без сомнения — будущее за BIM. Именно поэтому nanoCAD Электро, ВК, Отопление, СКС и ОПС относятся к САПР, реализующим идеи BIM. У СиСофт Дев есть Model Studio, которое еще ближе к концепции BIM (для промышленного проектирования)… Работать только тут много. И эта работа будет только в том случае, если рынок будет вкладывать финансы в это…
А мое мнение, хорошо, что не вложили ;-) Сколько ни наблюдал внедрений Vault (около десятка) ни разу не увидел положительный результат… Ну, это мое мнение — вы можете поэкспериментировать…
ну… Железобетон и Конструкции — это конкурирующие между собой решения. Их нет смысла устанавливать на одной машине — масло-масленое…
ВК и Геоника с модулем Сети — да, согласен, что их надо ставить на одной машине, если вэкашник делает и «внутрянку» по воде, и наружные сети. Но уже СПДС в эти продукты внутрь добавлять также не имеет смысла, т.к. и ВК и Геоника дают все средства для оформления и выпуска «рабочки». Плюс по сути оба вида работ настолько разные, что вряд ли их будешь выполнять одновременно — скорее всего эти работы разнесены по времени. И что в этом такого, что для одной задачи мы запустим один продукт, а для другой — другой? Учитывая, что у спецов обычно кроме AutoCAD используется еще с десяток программ для расчетов (как минимум Excel и Word, но вообще еще расчетные программы, базы оборудования и т.п.), то все равно не будет одного решения и надо будет использовать несколько программ. Почему же использование приложений под САПР-платформу должно выполняться в рамках одного профиля?
В общем извините, но я не считаю, что это критичная ситуация на данный момент ))
И еще спрошу: а кому нужна связка СПДС Железобетон и ВК? Какая специальность работает с двумя такими разными продуктами? На мой взгляд, это все равно, что учитель биологии запрашивает макет вселенной и телескоп для изучения планет…
Подчеркну, что это один из минусов для вас :-) Для других будут другие минусы, а для третьих это вообще не будет минусом… Например, для кого-то собранность решения в моноблок «платформа+вертикалка» — это скорее плюс, т.к. не надо заморачиваться с установкой платформы, потом вертикалки, а потом не надо решать проблемы с пропавшими меню, как это часто бывает в AutoCAD…
У того, что мы сейчас решения объединяем в моноблок есть одно простое для понимания объяснение — в моноблоке платформа зафисирована. Это значит, что мы можем развивать платформу дальше, выпускать обновления, патчи, новые моноблоки с более расширенным функционалом, не оглядываясь на уже выпущенные решения. И таким образом развиваться быстрее.
Хотя без сомнения, в будущем мы выйдем на принцип «фиксированная платформа» + самостоятельно распространяемые и устанавливаемые вертикальные решения. Только в этом случае платформа будет выходить раз в 4-5 лет и это будет событие для всех. Например, после этого разработчики вертикальных приложений должны будут разрабатывать новые версии своих приложений под новую версию платформы. Т.е. делать так, как это делает AutoCAD сейчас.
у Электро различаются базы общие (все объекты) и база проекта. Общие базы могут быть на сервере организации. Но база проекта — она локальная, т.к. у Электро (и AutoCAD!) нет механизма совместной работы над проектом.
При этом разработчики Электро идут к тому, чтобы сделать один общий проект и разграничить доступ к нему с разных рабочих мест, но для этого надо придумать, как обойти ограничения платформ (AutoCAD и, как следствие, nanoCAD) на то, что с файлом DWG не может работать одновременно несколько пользователей. Идеи есть, идет реализация, рано или поздно будет результат. Но пока смысла в сетевых базах данных проекта нет.
Не совсем )) по-моему повышение автоматизации и эффективности — это просто непрекращающаяся задача; выйдя на один уровень, начинаешь смотреть на другой. Институт навел порядок в используемом ПО и таким образом повысил эффективность. А после этого увидел, что можно совершенствоваться и автоматизироваться дальше.
По стоимости перехода — согласен, это интересный вопрос. Порекомендую Ивану задуматься над этим вопросом и написать на эту тему статью или расширить текущую…
это же фича: у вас фактически есть AutoCAD LT, только более дешевый + с возможностью под него разрабатывать приложения + с возможностью за допфинансы расширить на 3D!
>> В Компасе были разные справочники стандартных изделий — есть ли такое в наноКАДе?
Есть в специализированном решении, заточенном под машиностроение — nanoCAD Механика (см. раздел «Библиотека стандартных и унифицированных элементов»): www.nanocad.ru/products/detail.php?ID=374. Правда, она пока на базе nanoCAD Plus 6.0 выстроена — на 7-ку планируют перейти к осени. Да еще и 3D модуль, наверное, возьмут… ))
Ну, Vault — это решение от Autodesk. У него очень много конкурентов — не только Search. Выше я называл еще тройку… И что из них лучше, а что хуже очень сильно зависит от задач, целей и умения пользователей…
Потому что для публикации торговой марки в официальных материалах нужно получить официальное разрешение от владельца торговой марки. Понятно, что такое разрешение компания Autodesk просто так не дает. Плюс есть закон о рекламе, насколько я знаю…
Хороши от плюс до минус бесконечности )) насколько я понимаю, ни одна из них не достигла идеала… Но повторю, создать версию документа и сохранить\достать ее в\из базы документов — сама по себе задача тривиальная и не принципиальная. Она достаточно легко решается и системами чуть круче Dropbox, если вы создаете документы по принципу «один чертеж — один DWG-файл».
Но в реальности так очень редко бывает: внутри DWG-файла можно сохранить до сотни чертежей. А уж если один чертеж является подложкой другого, или внутри DWG файла активно используется пространство листа и видовые экраны, или из трехмерной модели «генерится» куча документации разного типа (чертежи, спецификации, текстовые отчеты, 3D модели и визуализации), то понятие версии документа весьма размывается — версия чего: файла, документа, модели или всего комплекса?
>> Как вы храните историю 3д? Есть ли история изменений (версионирование)?
История построения 3D тела хранится внутри DWG файла. А вот версионность внутри DWG не предусмотрена спецификацией этого формата — т.е. мы-то сделать можем, но тогда нарушится совместимость с AutoCAD и другими DWG-редакторами-просмоторщиками.
>> Есть ли сейчас что-то вроде git для САПР?
Вообще версионность возлагается в САПР на системы документооборота, которые могут быть встроенные (аля в ArchiCAD или больших машиностроительных САПР), либо внешние (так сделано для AutoCAD-подобных систем). Соответственно, nanoCAD может интегрироваться с внешними системами документооборота (или еще PDM-системами) — например, TDMS или TechnoligiCS от СиСофт Девелопмент, TeamCenter от Siemens, Лоцман от Аскон, Search от Интермех и еще десятка других систем. Понятно, что при этом будет интеграция на общелогическом уровне, понятно, что в каждом конкретном случае захочется больше, чем предлагают системы. Но и само понятие проектного документооборота очень расплывчато и сильно зависит от решений, технологии работы, бизнес-потоков, которые используются или сложились в проектной организации.
В общем это тема для очень большой дискуссии и обсуждения )) Хранение версий документа — это меньший из вопросов, который стоит при организации взаимодействия между проектировщиками. Гораздо важнее вопрос права редактирования…
Ничего себе как за время моего окончания института шагнули ВУЗы… Я в институте вычерчивал 7 листов по деталям машин и считалось это офигенно круто. Причем разрабатывал с нуля. А тут генплан подробный да еще от кого-то пошедший ;-)
Если маркетинг откинуть, то существует сейчас два подхода: BIM от одного производителя и BIM от разных производителей.
Наиболее ярко первый подход реализует Autodesk, маркетинговые буклеты которого заявляют, что его Revit подходит архитекторам-конструкторам-инженерам. В реальности все несколько печальнее пока — на мой взгляд Revit дает относительно хороший инструмент конструкторам (но, кстати, только моделирование (!), расчеты уже в другой программе), относительно сносный архитекторам (ArchiCAD все-таки сильнее) и практически никакой инженерам (нет баз, расчетов, кантрификации да и как моделирующий инструмент вообще хромает)…
Второй подход более сложный и во многом лежит на плечах внедренцев: например, архитектура в ArchiCAD, конструкции в Tekla, вентиляция в MagiCAD, электрика в nanoCAD Электро — кто-то способен увязать это в единое решение? а заплатить за это? или вложиться в НИОКР?
Учтите, что BIM еще относительно неплохо работает при общественно-гражданском проектировании (т.е. там, где технологии более-менее зафиксированы, не сложные и играют не самую главную роль). Если вы выйдете в промышленное проектирование (например, нефтеперерабатывающий завод), то там уже главное, чтобы сооружение перерабатывало нефть — т.е. важны расчеты, техпроцесс, контроль, безопасность и все остальное. BIM должна быть другой, особенной…
Ну, и еще… BIM шикарная вещь на стадиях концептуальной проработки проекта и собственно проекта. На стадии выпуска рабочей документации BIM избыточна. Она выдает заготовки чертежей и, если вам этого хватает, то отлично. Но чаще всего модели BIM мало для выпуска полноценной рабочей документации. Часто изменения в BIM модель более сложные, чем исправления документации. Часто BIM модель все-таки несколько условна, чтобы получить точную рабочую документацию. И тут происходит разрыв между САПР и BIM… и nanoCAD начинает рулить ))
А так без сомнения — будущее за BIM. Именно поэтому nanoCAD Электро, ВК, Отопление, СКС и ОПС относятся к САПР, реализующим идеи BIM. У СиСофт Дев есть Model Studio, которое еще ближе к концепции BIM (для промышленного проектирования)… Работать только тут много. И эта работа будет только в том случае, если рынок будет вкладывать финансы в это…
ВК и Геоника с модулем Сети — да, согласен, что их надо ставить на одной машине, если вэкашник делает и «внутрянку» по воде, и наружные сети. Но уже СПДС в эти продукты внутрь добавлять также не имеет смысла, т.к. и ВК и Геоника дают все средства для оформления и выпуска «рабочки». Плюс по сути оба вида работ настолько разные, что вряд ли их будешь выполнять одновременно — скорее всего эти работы разнесены по времени. И что в этом такого, что для одной задачи мы запустим один продукт, а для другой — другой? Учитывая, что у спецов обычно кроме AutoCAD используется еще с десяток программ для расчетов (как минимум Excel и Word, но вообще еще расчетные программы, базы оборудования и т.п.), то все равно не будет одного решения и надо будет использовать несколько программ. Почему же использование приложений под САПР-платформу должно выполняться в рамках одного профиля?
В общем извините, но я не считаю, что это критичная ситуация на данный момент ))
У того, что мы сейчас решения объединяем в моноблок есть одно простое для понимания объяснение — в моноблоке платформа зафисирована. Это значит, что мы можем развивать платформу дальше, выпускать обновления, патчи, новые моноблоки с более расширенным функционалом, не оглядываясь на уже выпущенные решения. И таким образом развиваться быстрее.
Хотя без сомнения, в будущем мы выйдем на принцип «фиксированная платформа» + самостоятельно распространяемые и устанавливаемые вертикальные решения. Только в этом случае платформа будет выходить раз в 4-5 лет и это будет событие для всех. Например, после этого разработчики вертикальных приложений должны будут разрабатывать новые версии своих приложений под новую версию платформы. Т.е. делать так, как это делает AutoCAD сейчас.
При этом разработчики Электро идут к тому, чтобы сделать один общий проект и разграничить доступ к нему с разных рабочих мест, но для этого надо придумать, как обойти ограничения платформ (AutoCAD и, как следствие, nanoCAD) на то, что с файлом DWG не может работать одновременно несколько пользователей. Идеи есть, идет реализация, рано или поздно будет результат. Но пока смысла в сетевых базах данных проекта нет.
По стоимости перехода — согласен, это интересный вопрос. Порекомендую Ивану задуматься над этим вопросом и написать на эту тему статью или расширить текущую…
Есть в специализированном решении, заточенном под машиностроение — nanoCAD Механика (см. раздел «Библиотека стандартных и унифицированных элементов»): www.nanocad.ru/products/detail.php?ID=374. Правда, она пока на базе nanoCAD Plus 6.0 выстроена — на 7-ку планируют перейти к осени. Да еще и 3D модуль, наверное, возьмут… ))
Но в реальности так очень редко бывает: внутри DWG-файла можно сохранить до сотни чертежей. А уж если один чертеж является подложкой другого, или внутри DWG файла активно используется пространство листа и видовые экраны, или из трехмерной модели «генерится» куча документации разного типа (чертежи, спецификации, текстовые отчеты, 3D модели и визуализации), то понятие версии документа весьма размывается — версия чего: файла, документа, модели или всего комплекса?
История построения 3D тела хранится внутри DWG файла. А вот версионность внутри DWG не предусмотрена спецификацией этого формата — т.е. мы-то сделать можем, но тогда нарушится совместимость с AutoCAD и другими DWG-редакторами-просмоторщиками.
>> Есть ли сейчас что-то вроде git для САПР?
Вообще версионность возлагается в САПР на системы документооборота, которые могут быть встроенные (аля в ArchiCAD или больших машиностроительных САПР), либо внешние (так сделано для AutoCAD-подобных систем). Соответственно, nanoCAD может интегрироваться с внешними системами документооборота (или еще PDM-системами) — например, TDMS или TechnoligiCS от СиСофт Девелопмент, TeamCenter от Siemens, Лоцман от Аскон, Search от Интермех и еще десятка других систем. Понятно, что при этом будет интеграция на общелогическом уровне, понятно, что в каждом конкретном случае захочется больше, чем предлагают системы. Но и само понятие проектного документооборота очень расплывчато и сильно зависит от решений, технологии работы, бизнес-потоков, которые используются или сложились в проектной организации.
В общем это тема для очень большой дискуссии и обсуждения )) Хранение версий документа — это меньший из вопросов, который стоит при организации взаимодействия между проектировщиками. Гораздо важнее вопрос права редактирования…