¬аше окно в мир —јѕ–
 
Ќовости —татьи јвторы —обыти€ ¬акансии Ёнциклопеди€ –екламодател€м
—татьи

20 окт€бр€ 2013

—истемы управлени€ проектными данными в области промышленного и гражданского строительства: наш опыт и понимание

јлексей –ындин, јлександр “учков

ќт редакции isicad.ru: Ёта стать€ публикуетс€ по просьбе компании «Ѕюро ESG», стрем€щейс€ охватить как можно больший круг читателей и обсудить с ними актуальные темы современного рынка AEC/BIM. »значально данна€ стать€ была опубликована в журнале «—јѕ– и √рафика» N2, 2013.


ѕредыдущие стать€ из серии, предложенной нашей редакции компанией «Ѕюро ESG»:

и др. вызвали большой интерес читателей isicad.ru.

ќбща€ картина

¬ этой публикации мы попытаемс€ обозначить проблемы, которые накопились в результате более чем 15-летнего опыта работы в сфере создани€ систем управлени€ проектными данными в промышленном и гражданском строительстве (ѕ√—), а также в других отрасл€х. ¬ насто€щее врем€ состо€ние дел в области автоматизации проектных организаций характеризуетс€ наличием различных факторов, на фоне которых с тем или иным успехом проводитс€ внедрение и развитие информационных технологий.   основным реали€м, на наш взгл€д, нужно отнести:

  • наличие подходов к поддержке жизненного цикла:
    • PLM,
    • BIM;
  • проблемы сбора проектных данных и управлени€ ими:
    • структурированные и неструктурированные данные,
    • различное понимание термина «—истемы управлени€ проектными данными»,
    • различное понимание терминов, св€занных с процессом проектировани€, умышленна€ или неумышленна€ их подмена,
    • невозможность на 100% совместить несколько разных методов и инструментов проектировани€;
  • прочие факторы:
    • ментальность,
    • несовершенство нормативных актов,
    • «непоколебимые традиции».

ќ вопросах терминологии

Ќачнем с темы, далекой от проектировани€ в области ѕ√—. Ќемного психологии... —огласно этой науке, существует процесс «манипулировани€ психическим сознанием человека и масс», приблизительно определ€емый как набор действий (приемов), целью которых €вл€етс€ формирование общественного мнени€, мнени€ группы людей или отдельного человека. Ќе вдава€сь в подробности науки, далекой от технических дисциплин и проектно-конструкторской де€тельности, по€сним следующее: процесс манипулировани€ может происходить как осознанно, так и бессознательно; существует р€д характерных приемов манипулировани€ — например: наличие множества непон€тных терминов; недоступность информации (когда нежелательна€ информаци€ просто не доводитс€ до сведени€), одностороннее освещение темы, фабрикаци€ фактов... «—топ!» — возможно, уже произнес читатель. — «ѕричем здесь автоматизаци€ проектно-конструкторской де€тельности?»

ѕо роду де€тельности нам часто приходитс€ общатьс€ с представител€ми проектных организаций на самых разных уровн€х: в производственных подразделени€х, в »“-службах, с высшим руковод€щим составом. ¬сЄ чаще и чаще звучат термины, которые до конца не €сны, часто подмен€ют друг друга. Ѕлагодар€ эффективной или, наоборот, малоэффективной работе компаний — поставщиков »“-решений по созданию мнени€ о продвигаемых средствах и технологи€х, эти термины часто воспринимаютс€ как «панаце€, единственно верное решение», призванное «немедленно подн€ть эффективность производственных процессов, а как следствие — прибыль» в наше «непростое рыночное врем€» (приведены реальные высказывани€). Ќаиболее часто упоминаемые из таких неологизмов: модель, PLM, BIM, система управлени€ проектными данными, жизненный цикл, управление проектами, управление проектированием...

ѕриведем некоторые примеры смешени€ терминов, их заведомо неверной трактовки. ќчень часто, когда речь идет об управлении проектными данными, управлении проектными документами, в результате подмены пон€тий оказываетс€, что (далее цитата) «у нас есть система управлени€ проектами MS Project, котора€ решает всЄ». ѕри этом налицо банальна€ подмена пон€тий, вызванна€ игрой слов. “ермин Project, дословно переводимый как «проект», вовсе не означает совокупность комплектов и томов проектно-сметной документации (ѕ—ƒ) и процессов проектировани€, что подразумеваетс€ под этим словом в проектных организаци€х. ѕроект как Project (тавтологи€, исключающа€, однако, игру слов) есть де€тельность группы по достижению цели, имеюща€ подзадачи, сроки, ресурсы, св€зи с другими задачами и т.д. ѕроект как Project описан и существует в терминах дисциплины Project Management (дословно «”правление проектами»).

ѕозволим себе другой термин — «проект как Design», который описан и существует в терминах другой дисциплины — Design Management. Ќесмотр€ на «неблагозвучность» («ћы не рекламно-дизайнерское бюро, а проектна€ организаци€!» — очередна€ цитата), именно этот термин лучше всего определ€ет управление проектной де€тельностью (не проектом как Project, да простит нас читатель, а производством ѕ—ƒ), что так пон€тно нашим заказчикам.

ћного путаницы возникает вокруг термина «модель». —меем заверить читателей, что его трактовка даже в области автоматизации проектной де€тельности без «необходимых дополнений» очень широка. “ак, существует пон€тие «3D-модель» — результат работы в 3D-—јѕ–, и пон€тие «информационна€ модель». ¬ первом случае речь идет о 3D-графике, как правило, содержащей различные атрибуты, например те или иные характеристики арматуры, конструкций, трубопроводов и прочих конструктивных элементов проектируемого при помощи 3D-—јѕ– объекта, его конструкций и компонентов. ѕри этом в качестве таких атрибутов может быть использована информаци€, св€занна€ с различными аспектами той или иной стадии жизненного цикла (∆÷) объекта. Ќапример, на стадии ∆÷ «ѕроектирование и строительство» такими атрибутами могут быть данные материально-технического обеспечени€ (ћ“ќ) (издели€, оборудование, материалы) и их отдельные характеристики (диаметры, массы, геометрические размеры и т.д.). Ќа стадии ∆÷ «Ёксплуатаци€» наиболее востребована «технически€ атрибутика» эксплуатируемого объекта (температура, влажность, давление, параметры технологических процессов, св€занные с производственной де€тельностью объекта, например технологической установки).

“ермин «информационна€ модель» несколько шире. ¬овсе не об€зательно, что информаци€ об объекте представлена в виде 3D-графики с упом€нутой выше атрибутикой. Ќесомненно, информационна€ модель может быть построена и таким способом. ’от€ в р€де случаев 3D-графика необ€зательно €вл€етс€ «центром информационной модели». ¬сЄ зависит от конкретного объекта моделировани€ и принципов поддержки ∆÷, например от того, как построена система управлени€ проектными данными. „асто бывает, что в информационную модель включают 3D-модели, вовсе не €вл€ющиес€ «ее центром». ¬ р€де случаев информационна€ модель может вообще не содержать 3D-модели.

ѕодробнее остановимс€ на новых технологи€х, часто использующих моделирование. ѕроектирование в области ѕ√— идет тем же путем, который был сравнительно недавно пройден нашими коллегами из сферы машиностроени€, авиастроени€, приборостроени€, судостроени€. ¬ этих област€х уже довольно давно говор€т о технологи€х поддержки жизненного цикла издели€: CALS, »ѕ», PLM. —равнительно недавно в ѕ√— началс€ бум (иначе не скажешь), св€занный с поддержкой жизненного цикла объекта. ѕри этом всЄ чаще говоритс€ о «модели».

ѕостараемс€ расставить все точки над «i». √рафическа€ информаци€ 3D-модели может использоватьс€ «в центре» технологии поддержки ∆÷ объекта. ѕри этом 3D-графика дополн€етс€ разными атрибутами, которые в различных технических реализаци€х имеют «разную физическую природу» (внешние базы данных (Ѕƒ), Ѕƒ конкретных —јѕ–, «ручное» добавление значений). ¬ любом случае такие атрибуты образуют Ѕƒ, св€занную с 3D-моделью, либо «встроенную» в 3D-модель (зависит от реализации). ѕри этом 3D-графика часто выполн€ет функции удобной навигации, визуализации, взваливает на себ€ функционал пользовательского интерфейса. Ќа основе использовани€ 3D-графики «в центре» информационной модели и реализована технологи€ BIM. ћы предлагаем называть такую информационную модель 3D-центричной. ’от€ отметим, что BIM вовсе не отрицает св€зь с внешними Ѕƒ. Ѕолее того, всЄ чаще в модел€х примен€етс€ информаци€ из таких Ѕƒ. ѕри этом, как правило, точкой доступа к информации внешних Ѕƒ дл€ пользовател€ €вл€етс€ 3D-графика. ¬опросы «степени отношений» с внешними Ѕƒ определ€ютс€ производителем решений и обусловлены в конкретных случа€х лишь техническими причинами, политикой создани€ решени€ и ведени€ бизнеса.

ћы вынуждены оп€ть вернутьс€ к вопросу терминологии, поскольку аббревиатура BIM имеет два значени€, существенно различающиес€ при переводе на русский €зык: Building Information Modeling — информационное моделирование зданий (процесс) и Building Information Model — информационна€ модель здани€ (далеко не процесс).  роме того, заметим, что BIM без B превращаетс€ в «информационную модель» (следу€ логике родного €зыка), центром которой необ€зательно €вл€етс€ 3D-модель, да и, вообще, 3D-графика в информационной модели может отсутствовать...

ќчень часто приходитс€ слышать, что BIM — единственно правильное решение и цель современной автоматизации дл€ поддержки ∆÷. ѕостараемс€ быть объективными и по€снить, почему это далеко не всегда так.

ѕри моделировании несложных с точки зрени€ технологии строительства производственных и технологических процессов (да прост€т мен€ представители гражданского строительства!) объектов, таких как, скажем, жилой дом, BIM часто €вл€етс€ очень удачным решением. ƒействительно, использование одной 3D-—јѕ– на стадии ∆÷ «ѕроектирование» эффективно. ¬ созданную на этом этапе ∆÷ 3D-модель могут быть сравнительно нетрудоемко добавлены необходимые атрибуты. “ака€ модель может быть облегчена (примен€ютс€ «легкие» форматы графики, поскольку дл€ последующих этапов ∆÷ графика, созданна€ на стадии проектировани€, избыточна). ѕосле такой адаптации к дальнейшей жизни модель может быть передана на последующие стадии ∆÷.

¬ случае же проектировани€ сложного промышленного объекта круг дисциплин очень широк и использование одной 3D-—јѕ– просто невозможно. ѕримен€етс€, как правило, несколько —јѕ– (не все 3D!); кроме того, существует огромное количество неструктурированных данных, иногда даже и в электронных форматах. ƒа и о «бумажной» документации забывать пока не стоит. ƒалее под неструктурированными данными мы будем понимать необходимые дл€ нашей модели значени€ атрибутов, которые невозможно получить из содержащего их источника с требуемыми достоверностью, степенью автоматизации и скоростью. Ќапример, сканированна€ таблица технических параметров насоса или та же таблица в бумажном (например, нормативном) документе, несомненно, содержит необходимые атрибуты дл€ модели. ƒл€ получени€ значений из таких источников и добавлени€ их в модель требуетс€ выполнить р€д действий (как правило, «вручную» найти, прочесть и записать). ≈сли же данные структурированы, например, в таблицах —”Ѕƒ, то эти же самые действи€ могут быть практически полностью автоматизированы и времени на них будет тратитьс€ гораздо меньше.

Ёксплуатаци€ объекта гражданского строительства (еще раз просим прощени€ у специалистов в этой области!) на несколько пор€дков проще, чем эксплуатаци€, скажем, химического комбината или электростанции. ƒействительно, говор€ €зыком заказчика, при эксплуатации жилого здани€ в основном поддерживаютс€ следующие системы: «¬одопровод и канализаци€», «Ёлектрика и освещение», «ќтопление, вентил€ци€ и кондиционирование», которые в жилом здании несколько проще, чем на производственном объекте. ѕоэтому на стадии ∆÷ «Ёксплуатаци€» использовать 3D-модель «в центре» информационной модели жилого здани€ очень удобно. ѕри падении температуры в помещении с помощью трехмерной навигации несложно найти соответствующий датчик, элементы системы отоплени€, технические характеристики, содержащиес€ в атрибутах, эксплуатационную документацию, руководство по замене, сведени€ о поставщиках, возможных заменах на аналогичное оборудование и т.д.

ѕри эксплуатации предпри€ти€, даже если и удалось бы создать его полную 3D-модель, содержащую в атрибутах максимальное количество параметров, в случае отклонени€ важных технологических характеристик «не спеша бродить по 3D» просто недопустимо. ѕри повышении концентрации газа на химическом производстве или, не дай Ѕог, угрозе неуправл€емой реакции на јЁ— должна сработать автоматика. ≈сли клапаны не закрылись или стержни в рабочую зону не сбросились, «бродить по 3D» в поисках решени€ нет времени — примен€ютс€ резервные способы выхода из аварийной ситуации, заранее проработанные и выполн€емые соответствующим персоналом на автомате, оп€ть же далекие от применени€ трехмерной модели.

¬ св€зи с этим подчеркнем, что, на наш взгл€д, технологи€ поддержки жизненного цикла на основе 3D-центричной модели (например, BIM) может использоватьс€ в области гражданского строительства. ¬ сфере проектировани€, строительства и эксплуатации промышленных объектов BIM вр€д ли применима в масштабе всего предпри€ти€. ƒа и перва€ буква в аббревиатуре BIM, на которой внимание ранее не акцентировалось, обозначает Building, то есть в наиболее точном переводе — «здание» (термин из гражданского строительства и термин, обозначающий лишь некую часть завода, фабрики, электростанции, верфи и прочих промышленных объектов).

„тобы окончательно запутать читателей, сообщим, что также существуют термины PIM (Plant Information Modeling) — информационна€ модель завода и сPLM — система управлени€ жизненным циклом объекта капитального строительства.

ќ «непримиримых технологи€х»

ѕеред тем, как перейти к вопросам, св€занным с системами управлени€ проектными данными, невозможно хот€ бы кратко не остановитьс€ на ситуации вокруг «двух непримиримых технологий», примен€емых в насто€щее врем€ в проектных организаци€х. ѕрежде всего речь пойдет о двумерном и трехмерном (2D и 3D) проектировании.

»значально переход к компьютеризованным средствам проектировани€ включал внедрение двумерных —јѕ–. ¬с€ технологи€ «плоского проектировани€», по сути, пытаетс€ максимально повторить принципы и подходы проектировани€ на кульмане. –езультатом работ €вл€етс€ ѕ—ƒ в электронном виде, сгруппированна€ по томам и/или комплектам.

ƒл€ хранени€ разрабатываемой и/или разработанной ѕ—ƒ в электронном виде может примен€тьс€ банальный способ — хранение в файловой системе. ѕри этом аналогом разделов проекта, томов, комплектов, а также структурных единиц «складировани€ ѕ—ƒ», например, узлов, зданий сооружений зачастую €вл€ютс€ каталоги (папки), имеющие соответствующие обозначению имена. јналогом же документов €вл€ютс€ файлы, размещенные в соответствующих папках (аналог тома или комплекта). ѕри этом файлы именуютс€ в соответствии с обозначением того или иного чертежа комплекта. Ќесколько усложненный способ подразумевает использование —”Ѕƒ. ¬ этом случае все структурные элементы ѕ—ƒ и непосредственно файлы имеют атрибутивные карточки, по которым в дальнейшем возможен поиск, сортировка и группирование документов. Ќесомненно, второй способ более прогрессивен. ѕон€тие «электронный документ» соответствует определению √ќ—“ 2.051-2006 (≈— ƒ. Ёлектронные документы. ќбщие положени€).

Ќо и тот и другой способ — большей частью попытка повторени€ работы с «бумагой», естественно, с учетом того, что используютс€ другие средства проектировани€, имеющие соответствующие особенности. Ќапример, «проводить изменени€ в поле чертежа, если его читаемость не нарушаетс€», приемлемо на бумаге, а в электронном документе, согласно приведенному выше √ќ—“у, изменени€ провод€тс€ в новой версии. — по€влением средств трехмерного моделировани€ принципиально изменилась сама методика ведени€ проектных работ. »спользование 3D-—јѕ– не соответствует ранее прин€тым подходам к «плоскому проектированию», имеет р€д преимуществ, например, высокое качество ѕ—ƒ за счет исключени€ коллизий, высокую производительность, более привлекательные финансово-экономические показатели.  роме того, по€вилась нормативна€ база. Ќо так ли всЄ безоблачно?

јвторы статьи проводили небольшой эксперимент — в многочисленной аудитории представителей проектных организаций в области ѕ√— просили отозватьс€ тех, кто не отгружает заказчику «плоскую ѕ—ƒ» (тома и комплекты тех или иных марок), а отгружает только трехмерную модель, по своим параметрам соответствующую законодательству, легитимность которой подтверждена электронной цифровой подписью (Ё÷ѕ) (реализованной на основе ‘едерального «акона)... „итатель догадываетс€ о результатах опроса?

¬ машиностроении, которое развиваетс€ в соответствии со специфическими принципами, теоретически, в отличие от ѕ√—, можно (или, надеемс€, в скором времени будет можно) получить утвердительный ответ на этот вопрос. ¬ области же ѕ√—, особенно св€занной с проектированием сложных с технологической точки зрени€ объектов, на наш взгл€д в обозримом будущем такое просто невозможно, по следующим причинам:

  • использование —јѕ– различных производителей, и далеко не только 3D (о какой единой 3D-модели может идти речь?);
  • невозможность применени€ нормативной базы;
  • ментальность;
  • традиции;
  • необходимость качественного скачка к новой технологии, при современных подходах и средствах часто просто несовместимой с «традиционной» технологией.

“аким образом, при всех прогрессивных и положительных аспектах применени€ 3D-—јѕ– ситуаци€ по отношению к «плоскому» проектированию напоминает мытарства ќстапа Ѕендера со сценарием «Ўе€», который должен быть только либо «немым», либо «звуковым». Ќапомню, что сценарий не был экранизирован по причине того, что «немого кино уже нет», а «звукового кино нет еще».

–азличные точки зрени€ на построение системы управлени€ проектными данными

“очка зрени€ 1
»так, перейдем к описанию подходов к построению систем управлени€ проектными данными (далее —”ѕƒ).

—разу отметим, что цель публикации — не «научить и рассказать, как надо», а, скорее, показать, какие есть подходы и варианты, позвол€ющие автоматизировать управление проектными данными с учетом описанных в предыдущих разделах реалий. «абега€ вперед, ответим на посто€нно задаваемый вопрос: « акую конкретно систему управлени€ проектными данными вы посоветуете?» (÷итата.) ƒело в том, что говорить о том или ином решении можно, лишь пон€в то, какими проектными данными вы собираетесь управл€ть, какие используете —јѕ– и как у вас поставлена методика самого процесса проектировани€, что €вл€етс€ источником данных, что и кто потребл€ет данные... ѕеречень вопросов далеко не полный. ѕри этом ответы должны учитывать факторы, описанные в предыдущих разделах статьи.

—уществует наиболее распространенна€ точка зрени€ о том, что представл€ет собой —”ѕƒ. ¬ этом случае под термином «проектные данные» понимаетс€ чуть ли не вс€ информаци€, порождаема€ на стадии проектировани€. “ака€ —”ѕƒ, естественно, «отражает ча€ни€» основных участников процессов работы с информацией на стадии ∆÷ «ѕроектирование» — проектные организации. ѕрежде всего, така€ —”ѕƒ — едина€ среда, позвол€юща€ накапливать данные, раздел€ть права доступа к ним, автоматизировать различные процессы, св€занные с управлением этими самыми данными, например процессы разработки, обмена между проектными специальност€ми, выгрузки дл€ внешних потребителей, получени€ данных от внешних исполнителей, проведени€ экспертиз и т.п.

—хема —”ѕƒ, в которой реализованы перечисленные подходы, приведена на рис. 1.

–ис. 1. —хема —”ѕƒ

»деологи€ такой —”ѕƒ заключаетс€ в следующем:

  • основные типы данных, которые накапливает и обрабатывает —”ѕƒ, приведены в верхней части рисунка;
  • данные порождаютс€ и потребл€ютс€ различными источниками. —ама —”ѕƒ никаких данных не порождает. »сключением €вл€ютс€ отчеты и некоторые документы, автоматическое формирование которых возможно в виде документов-отчетов и/или файлов со структурированными данными, например перечень основных комплектов, состав комплекта, отчеты по объемам данных, документов, состо€нию процессов автоматизируемых —”ѕƒ и т.д.;
  • к источникам данных относ€тс€ —јѕ–, расчетные программы, текстовые редакторы, Ѕƒ ћ“ќ и ERP, внешние организации и т.д. Ёти источники выдают данные как в структурированном, так и в неструктурированном виде (например, результаты работы в —јѕ–) и/или потребл€ют их (например, при отгрузке ѕ—ƒ на экспертизу или заказчику);
  • дл€ —”ѕƒ процесс разработки данных €вл€етс€ «таинством», а сам набор источников данных — «черным €щиком».

ќсновным «преимуществом» такой —”ѕƒ €вл€етс€ отсутствие необходимости затрат на разработку интеграционных решений с источниками данных, отсутствие «глобальных изменений» в традиционных бизнес-процессах. Ќесомненно, при переходе на электронное управление проектными данными реинжиниринг неизбежен, но он, как правило, минимально захватывает непосредственно методику проектировани€, работы с —јѕ– по сравнению с другими подходами.

ќсновным «недостатком» такой —”ѕƒ €вл€етс€ то, что очень часто управление проектными данными в такой системе сводитс€ в основном к управлению документами — результатами работы источников (см. рис. 1). Ёто св€зано с низкой степенью интеграции. ѕри этом часто в таких документах данные неструктурированы.

ќтметим, что слова «преимущество» и «недостаток» вз€ты в кавычки. ѕричина проста: в 50% конкретных случаев, в зависимости от методики проектировани€ в проектной организации, используемых средств — источников данных, да и вообще от специфики самих проектируемых объектов «преимущество» можно указывать как «недостаток», и наоборот.

“очка зрени€ 2
–ассмотрим альтернативную точку зрени€ на —”ѕƒ. ≈е можно сформулировать так: «ѕроектные данные — те значени€ атрибутов объекта и вход€щих в него частей, которые были заложены на стадии ∆÷ „ѕроектирование“; далее они могут быть изменены на стадии ∆÷ „—троительство“. ќни, как правило, в той или иной степени отличаютс€ от данных, которые есть у реального объекта. ¬опрос лишь в допустимости или недопустимости величин отклонений».

“ака€ точка зрени€ на —”ѕƒ преобладает на стади€х ∆÷ «—троительство» и «Ёксплуатаци€» объекта. ”прощенна€ схема системы на стадии ∆÷ «Ёксплуатаци€» объекта приведена на рис. 2.

–ис. 2

Ћогика работы системы следующа€:

  • существует Ѕƒ значений атрибутов объекта и его составл€ющих (эти значени€, говор€ прин€той в –‘ терминологией, содержатс€ в исполнительной документации, на «ападе есть пон€тие «As Build» — « ак построено». Ќе будем подробно останавливатьс€ на всех способах получени€ такой Ѕƒ, ибо диапазон велик — от «ручной» корректуры документации до 3D-сканировани€;
  • существуют датчики контрол€ значений, показани€ которых поступают в систему (не будем углубл€тьс€ в описание работы в дискретных режимах или режиме реального времени);
  • полученные значени€ сравниваютс€ соответствующим механизмом на предмет отклонени€;
  • результаты работы отображаютс€ через пользовательский интерфейс.

¬ернемс€ к началу статьи, где мы говорили о технологии BIM. ƒело в том, что в р€де случаев пользовательский интерфейс такой системы, представленной в виде трехмерной модели, очень удобен. Ќапомним: мы считаем, что наиболее рационально использовать 3D-визуализацию в тех случа€х, когда речь идет об объекте-здании со сравнительно несложными технологическими процессами, чаще — о жилом здании или отдельном здании на предпри€тии. ѕри поддержке на стадии ∆÷ «Ёксплуатаци€» сложного производственного, энергетического или другого сравнимого объекта использование 3D не «всегда удобно», а иногда и просто неуместно. ¬прочем, тут мы начинаем вторгатьс€ в область автоматизированных систем безопасности промышленных объектов, что не €вл€етс€ предметом рассмотрени€ этой публикации.

“очка зрени€ 3
–ассмотрим еще одну альтернативную точку зрени€. ќна характерна дл€ стадии ∆÷ «ѕроектирование».

—хема такого подхода к реализации —”ѕƒ приведена на рис. 3.

–ис. 3

Ћогика работы по схеме (см. рис. 3) следующа€:

  • проектные данные поступают в единую Ѕƒ —”ѕƒ из источников — —јѕ–. ѕри этом данные:
    • в основном структурированные,
    • представл€ют собой атрибуты моделей (их частей), причем способы добавлени€ значений таких атрибутов могут быть самыми различными («ручной ввод» через пользовательский интерфейс —јѕ–, подключение к внешним Ѕƒ, например каталогам стандартных изделий и материалов, Ѕƒ MTO, Ѕƒ нормативных документов и т.п.);
    • существует инструментарий-надстройка над Ѕƒ, котора€ позвол€ет работать с данными, получать отчеты и т.д.

«ѕионерами» подобного подхода €вл€лись производители машиностроительных —јѕ–, создавшие PDM/PLM-системы. ќсновное их отличие в том, что дл€ машиностроительных —јѕ– подобные системы создавались изначально дл€ одного «родного» —јѕ–: Windchill дл€ ProE, Teamcenter дл€ Unigraphics, Enovia дл€ Catia и пр. Ќесомненно, производители утверждают, что «есть интерфейсы с любыми —јѕ–»... ¬ области проектировани€ дл€ ѕ√—, в отличие от машиностроени€, как правило, на крупных проектах используютс€ «линейки» —јѕ–, автоматизирующие проектирование в той или иной области (марке, проектной специальности). ѕоэтому подобные —”ѕƒ изначально создавались дл€ нескольких —јѕ–. ¬ качестве примеров подобных решений можно привести систему Autodesk Vault от компании Autodesk и систему ProjectWise от компании Bentley. “акой подход к управлению проектными данными в насто€щее врем€ имеет некоторые «размытости» в понимании того, как должна выгл€деть конкретна€ реализаци€, ибо все —”ѕƒ — настраиваемые среды, которые необходимо как-то адаптировать. ќсновными проблемами, с которыми придетс€ столкнутьс€ тому, кто пойдет подобным путем реализации —”ѕƒ, можно назвать следующие:

  • система — детище производител€ одной линейки —јѕ–. Ќесомненно, в этой линейке она способна «собирать» необходимые значени€ — проектные данные и управл€ть ими. „то касаетс€ интерфейсов с —јѕ– других производителей, то, как за€вл€ют поставщики, «есть интерфейсы с любыми —јѕ–» (цитата). — одной стороны, производитель подобной системы, естественно, стремитс€ вывести ее на рынок, создав в том числе и механизмы взаимодействи€ дл€ «неродных» (говор€ пр€мо — конкурирующих) —јѕ–. — другой стороны, любой производитель, совершенству€ свой —јѕ– и, cкажем пр€мо, защища€ свой уникальный продукт и бизнес, довольно часто мен€ет форматы данных, интеграционные механизмы. ѕри этом, несомненно, реализуетс€ совместимость со своей «предыдущей» продукцией... ј вот совместимость с продукцией «сторонних» производителей систем управлени€ проектными данными (того типа, о котором говорим сейчас) поддерживать просто бессмысленно, а зачастую и невыгодно с точки зрени€ бизнеса (если есть сво€ «линейка», позвол€юща€ успешно делать то же, что и конкурентна€).   тому же подобна€ несовместимость вынуждает конечного пользовател€ писать интерфейс к новой версии «чужого —јѕ–» за свой счет или использовать «родную» дл€ —јѕ– —”ѕƒ;
  • методика проектировани€ при использовании различных инструментов отличаетс€.  акие данные существенны?  акие должны передаватьс€, накапливатьс€ и обрабатыватьс€ в —”ѕƒ? ≈сть еще много вопросов, ответ на которые можно получить, лишь осуществив «постановку» основных принципов работы с конкретными —јѕ– в той или иной области...ѕоэтому говорить о «выборе конкретной —”ѕƒ» без выполнени€ этих меропри€тий преждевременно;
  • что делать с неструктурированными документами и проектными данными, не порождаемыми —јѕ–, которые всЄ равно есть и будут?
  • такого рода система оп€ть сталкиваетс€ с противоречи€ми, о которых мы говорили ранее. ѕрин€тые и усто€вшиес€ принципы проектировани€, проведени€ изменений, нормативна€ база и т.д. пока что делают невозможным только такой подход (—”ѕƒ по такой схеме в «чистом виде»).

Ќаша точка зрени€ на —”ѕƒ

ѕозволим вз€ть на себ€ инициативу и ввести новый термин «идеальна€ —”ѕƒ». »збега€ разночтений, подмен и прочих глупостей, описанных в начале статьи, сразу дадим определение. –ассмотрим лишь стадию ∆÷ «ѕроектирование» объектов промышленного и гражданского строительства.

ѕод «идеальной —”ѕƒ» будем понимать такую систему, котора€ управл€ет всеми типами проектных данных, реально существующими в современных услови€х (в проектных организаци€х –‘), учитывает уровень автоматизации, развитие нормативной базы, принципы проведени€ проектных работ, ментальность, традиции, наличие двух основных подходов (2D и 3D) и прочие факторы.

ѕример управлени€ «идеальной —”ѕƒ» приведен на рис. 4.

–ис. 4

“ака€ —”ѕƒ должна управл€ть двум€ большими группами данных:

  • структурированными;
  • неструктурированными.
ћы уже дали определение таких данных в первой части статьи. ¬ этой части приведем некоторые примеры, иллюстрирующие указанные группы.

  первой группе относ€тс€ данные из таблиц, Ѕƒ MTO и ERP, планово-ресурсные показатели из систем ресурсного планировани€, —RM, договорных систем. Ќесомненно, такими данными €вл€ютс€ атрибуты 3D-моделей. —труктурированию подлежат данные, содержащиес€ в форматах файлов MS Excel, MS Word (если они содержатс€ в структурированных элементах документов, например в таблицах, колонтитулах и т.д.). ‘айл DWG изначально имеет структуру.

¬ то же врем€ существует огромный пласт неструктурированных проектных данных. ¬ основном они содержатс€ в документах. ѕолучить такие данные с целью дальнейшей обработки, управлени€ в —”ѕƒ не просто, не всегда окупаемо, далеко не всегда целесообразно. ¬ таких случа€х документ — носитель проектных данных рассматриваетс€ как некое «неделимое целое». Ќапример, если формат DWG €вл€етс€ структурированным, это далеко не всегда означает, что получить данные из него просто. ѕри отсутствии должной стандартизации текст может быть, например, просто текстом, значением атрибута блока и т.д. ќтсутствие шаблонов, стандартов, позвол€ющих даже в структурируемом приложении получать произвольно «разбросанные» в структуре файла данные, ведут к сложност€м, а иногда и невозможности доступа к таким данным. ≈сть группа форматов, примен€емых в проектной де€тельности, доступ к данным «внутри которых» еще сложнее — сканированные образы чертежей, таблиц и т.п.  онечно, «можно всЄ автоматически распознать». ј вы пробовали? Ёто — отдельна€ больша€ тема. ѕросим читател€ пока прин€ть на веру тот факт, что распознавание носит €рко выраженный веро€тностный характер и далеко не всегда «овчинка стоит выделки» в св€зи с низкой рентабельностью.

Ќе хочетс€ возвращатьс€ к теме «войны технологий» (2D и 3D), но дл€ реализации «идеальной —”ѕƒ» эта война должна как-то закончитьс€. ѕричем совсем не важно, как, но пока нет никакого «компромисса сторон» или «победы одной из сторон», вопрос, как создать «идеальную —”ѕƒ», остаетс€ без ответа.

¬ыводы

Ќе будем никого интриговать и обманывать, привод€ примеры «идеальной —”ѕƒ». „естно признаем следующее:

  • в насто€щее врем€ управление проектными данными в большинстве случаев сводитс€ к управлению документами;
  • —”ѕƒ, управл€юща€ структурированными данными, часто «упускает» данные, содержащиес€ в неструктурированных документах, и наоборот;
  • сегодн€ существует р€д предпри€тий, использующих отдельно —”ѕƒ, управл€ющую неструктурированными данными (по сути, навороченный «электронный архив»), и —”ѕƒ, управл€ющую структурированными данными (по сути, систему управлени€ спецификаци€ми и ведомост€ми или недоразвитую PDM-систему);
  • авторы не вид€т путей реализации «идеальной —”ѕƒ» в существующих нормативных и ментальных (традиционных) реали€х;
  • на р€де предпри€тий существуют реализации, которые в той или иной мере приближаютс€ к «идеальной —”ѕƒ», но этот опыт фактически невозможно тиражировать на другие предпри€ти€.

ѕозволим себе процитировать первую фразу этой статьи:
«¬ этих заметках мы пытаемс€ обозначить понимание тех проблем, которое накопились в результате более чем 15-летнего опыта работы в сфере создани€ систем управлени€ проектных данных в промышленном и гражданском строительстве».

ћы очень надеемс€, что наше, веро€тно, сумбурное изложение проблем заставит наших партнеров и в первую очередь наших заказчиков задуматьс€, ради чего мы все вместе пытаемс€ внедрить современные технологии проектировани€ и управлени€ проектными данными. ƒл€ нас ответ очевиден — это повышение качества и сокращение сроков проектировани€ и строительства промышленных и гражданских объектов.

—писок литературы:
  1. –ындин ј., √алкина ќ., Ѕлагодырь ј.,  ораго Ќ. јвтоматизаци€ потоков документации — важный шаг к созданию ≈»ѕ // REM.2012. № 4. —. 42-48.
  2. „иковска€ »., ƒанилова Ћ., Ћ€нда ј. ѕереход на трехмерную технологию проектировани€ станций —анкт-ѕетербургского метрополитена на основе вертикальных решений компании Autodesk, Inc. // —јѕ– и графика.2012. № 9. —. 108-112.
  3. ћалашкин ё., Ўатских “., ёхов ј., √алкина ќ.,  ораго Ќ., –ындин ј., ‘ертман ». ќпыт разработки системы электронного документооборота в ќјќ «√ипроспецгаз» // —јѕ– и графика. 2011. № 12. —. 96-98.
  4. ƒолгалев ƒ. ќбмен данными между различными системами // —јѕ– и графика. 2011. № 9. —. 73-75.
  5. —ладковский ј.,  узьмин ≈., Ўалаева ќ. »нформационна€ система визуализации 3D-моделей на базе Intergraph SmartPlant Review // —јѕ– и графика. 2011. № 9. —. 2-5.
  6. “учков ј., ћаксимов Ќ. –абота с данными на разных этапах жизненного цикла промышленных объектов с использованием SmartPlant Enterprise // —јѕ– и графика. 2011. № 8. —. 2-5.
  7. ¬оробьев ј., ƒанилова Ћ., »гнатов Ѕ., –ындин ј., “учков ј., ”ткин ј., ‘ертман »., ўеглов ƒ. —ценарий и механизмы создани€ единого информационного пространства // CADmaster. 2010. № 5. —. 48-51.
  8. Ћатыпов ≈., ’уснутдинова  ., ёмашев Ё. ќпыт применени€ технологии SmartPlant Enterprise на прот€жении всего жизненного цикла объектов обустройства нефт€ных и газовых месторождений // CADmaster. 2010. № 5. —. 80-83.
  9. —анев ¬., —услов ƒ., —мирнов —. »спользование информационных технологий в «јќ «÷Ќ»» судового машиностроени€» // CADmaster. 2010. № 3(53). —. 29-32.
  10. ƒанилова Ћ., ўеглов ƒ. ћетодологи€ создани€ единого информационного пространства ракетно-космической отрасли // REM.2010. № 6. —. 14-15.
  11. ¬оробьев ј., ѕивоваров ¬., ўеглов ƒ., јлимов ћ., ¬едерникова “., ƒанилова Ћ., –ындин ј., “учков ј., ‘ертман ».  онцепци€ создани€ единой среды проектировани€, как первый этап обеспечени€ жизненного цикла изделий (опыт ќјќ « Ѕ—ћ») // CADmaster. 2008. № 2. —. 18-20.
  12. √рачев ¬. —овременное состо€ние дел с электронными архивами // CADmaster. 2008. № 2. —. 92-97.
  13. “учков ј. ¬недрение электронных архивов инженерной документации // CADmaster. 2008. № 3. —. 42-49.
  14. „иковска€ ». “иха€ революци€. Ёлектронный кульман или информационна€ модель здани€ // CADmaster. 2008. № 3. —. 88-92.
  15. –ындин ј., “учков ј., ‘ертман ». —тупени внедрени€ »ѕ»-технологий. ќпыт реализации электронного документооборота. ћатериалы конференции «ћоринтех-практик информационные технологии в судостроении — 2006», 2006 г.
  16. јлимов ћ., –ындин ј., “учков ј., ‘ертман ». —тупени внедрени€ »ѕ»-технологий. ќпыт реализации электронного документооборота // REM. 2006. № 2.
  17. –ындин ј., –€бенький Ћ., “учков ј., ‘ертман ». —тупени внедрени€ »ѕ»-технологий // —удостроение. 2005. № 4.
  18. ¬едерникова “., —мирнов —. »спользование современных достижений информационных технологий в ÷Ќ»» судового машиностроени€ // CADmaster. 2005. № 5. —. 31-33.
  19. „иковска€ ». Autodesk Architectural Desktop — едина€ среда дл€ коллективной работы над проектом // CADmaster. 2005. № 2. —. 63-65.
  20. √алкина ќ., –ындин ј., –€бенький Ћ., “учков ј., ‘ертман ». ѕостроение информационных моделей изделий судостроени€ на различных стади€х жизненного цикла с элементами логистической поддержки. —борник докладов конференции «“ехнологии информационной поддержки жизненного цикла сложных изделий в российской промышленности», 2004 г.
  21. Ѕененсон ј., –€бенький Ћ., “учков ј., Ўептунов ». ќпыт организации системы сквозного проектировани€ — изготовлени€ дл€ судостроени€. —борник докладов конференции «–оль и значение „јдмиралтейских верфей“ в научно-техническом развитии российского и мирового судостроени€», 2004 г.
  22. √олованов ¬., –€бенький Ћ., ƒавыденко —., ќстрокопытов ƒ., “учков ј., ‘ертман ». ќпыт внедрени€ комплексных программно-аппаратных решений —јѕ– и электронного архива инженерной документации на судостроительных предпри€ти€х. Cборник докладов конференции «–оль и значение „јдмиралтейских верфей“ в научно-техническом развитии российского и мирового судостроени€», 2004 г.
  23. –ындин ј. ¬вод сканированных документов в электронный архив предпри€ти€ // CADmaster. 2003. № 1. —. 41-43.
  24. –ындин ј. јрхив без пыльных полок, или —пособы организации архива предпри€ти€ // JetInfo. 2002. 10/113.
  25. ‘ертман »., “учков ј., ѕопов  . јппаратное обеспечение электронного технического документооборота // CADmaster 2001. № 8/3.
  26. —омов »., Ћисицын Ќ., ѕорфирьев ƒ., –аменский ¬. ќпыт использовани€ √»— AutoCAD Map 2000 в услови€х нефтеперерабатывающего завода ќќќ « иришинефтеоргсинтез» // CADmaster. 2001. № 1. —. 26-29.
  27. ƒавыденко —., ѕавлович ћ. –еализаци€ системы конструкторского документооборота и решение проблемы тиражировани€ документации в ÷ Ѕ ћ“ «–”Ѕ»Ќ» // CADmaster. 2000. № 5. —. 16-19.


„итайте также:


¬акансии:

јктуальное обсуждение

RSS-лента комментариев

ƒавид Ћевин
ƒавид Ћевин
ќт редактора: —емь советов молодым инженерам
ѕроект ЂЌародное —јѕ–-интервьюї

—лучайна€ стать€:

Dassault Systèmes наращивает инвестиции в –оссию — ≈лена √ореткина (15 ма€ 2019)
isicad Top 10

—амые попул€рные материалы

   ‘орумы isicad:

isicad-2010 isicad-2008
isicad-2006 isicad-2004

ќ проекте

ѕриглашаем публиковать на сайте isicad.ru новости и пресс-релизы о новых решени€х и продуктах, о проводимых меропри€ти€х и другую информацию. јдрес дл€ корреспонденции - info@isicad.ru

ѕроект isicad нацелен на

  • укрепление контактов между разработчиками, поставщиками и потребител€ми промышленных решений в област€х PLM и ERP...
ѕодробнее

»нформаци€ дл€ рекламодателей


¬се права защищены. © 2004-2019 √руппа компаний «Ћ≈ƒј—»

ѕерепечатка материалов сайта допускаетс€ с согласи€ редакции, ссылка на isicad.ru об€зательна.
¬ы можете обратитьс€ к нам по адресу info@isicad.ru.