О путях создания систем управления инженерными данными

Александр Тучков
К.т.н., технический директор Бюро ESG
Алексей Рындин
Заместитель директора Бюро ESG по внешним связям

О создании систем управления инженерными данными

Мы уже неоднократно писали о создании систем управления инженерными данными. Нынешняя статья продолжает эту тему и описывает различные подходы в зависимости от конкретных условий и поставленных задач.

По сложившейся традиции в начале изложения остановимся на вопросах терминологии. Что подразумевается под термином «инженерные данные»? Несомненно, речь идет о различных атрибутах, технических, физических параметрах, технических и технологических характеристиках, показателях, которые относятся как к объектам, так и оборудованию, изделиям, материалам, КИПиА — то есть ко всем сущностям, составляющим объект или используемым на всех стадиях его жизненного цикла. Постараемся перечислить «источники», содержащие инженерные данные:

• проектно­сметная документация;
• технологические принципиальные схемы (PFD) и монтажные схемы с приборами КИПиА (P&ID);
• электрические и электротехнические схемы (E&I);
• 3D­модели промышленных объектов, состоящие из интеллектуальных 3D­моделей компонентов с атрибутивной информацией и логическими связями;
• базы данных и документация по оборудованию, приборам и материалам;
• чертежи и спецификации на различных стадиях готовности («как спроектировано» — «как построено»);
• паспорта, сертификаты оборудования;
• генеральные планы;
• исполнительная документация;
• прочие источники, необходимые для проектирования и модернизации, монтажа и строительства, эксплуатации и утилизации объекта.

Достаточно часто термин «инженерные данные» ассоциируют с понятием «документов». Это далеко не всегда корректно. Дело в том, что инженерные данные могут содержаться в контенте документов, но помимо данных контент содержит прочие элементы — графику, описания и т.д. Поэтому, с одной стороны, стоит, скорее, говорить о «системе управления инженерной (технической) информацией и документами». С другой стороны, термин «система управления инженерными данными» достаточно плотно вошел в употребление, поэтому, дабы не противоречить сложившимся традициям и тенденциям, мы будем говорить о системе управления инженерными данными (далее СУИД), но с учетом приведенных нами пояснений.

Напомню основные реалии, перечисленные в предыдущих наших публикациях, которые характеризуют современное положение дел:

1. Наличие двух больших групп данных:

• структурированные инженерные данные:

- данные, получаемые из САПР (если они структурированы),

- данные, получаемые из БД, индексированные данные (например, параметры оборудования и т.д.);

• неструктурированные инженерные данные:

- содержащиеся в контенте бумажных документов,

- содержащиеся в контенте сканированных документов,

- содержащиеся в контенте документов, получаемых с использованием САПР, текстовых редакторов и прочего ПО без использования правил структурирования и соответствующих функций ПО.

2. «Островки информации» — ситуация, особенно характерная для действующих предприятий с непрерывным производственным циклом. Суть ее заключается в следующем: инженерные данные (как структурированные, так и нет) находятся в не связанных единой средой подразделениях. Часть информации, например, может находиться в проектно­конструкторском бюро завода, часть — в разрозненных архивах предприятия (служб главного технолога, главного механика, главного энергетика, отдела капитального строительства, проектных офисах и т.д.). Какая­то часть инженерных данных вообще может находиться вне предприятия — у сторонних проектантов и обслуживающих организаций. При этом «основное зло» — отнюдь не дублирование информации (которое просто неизбежно при описанном подходе), а отсутствие актуальной информации о предприятии и, порой, невозможность ее актуализации.

3. Отсутствие необходимых регламентов по управлению данными.

Современное положение дел нагядно иллюстрирует рис. 1.

Рис. 1. Различные типы и источники инженерных данных на современном предприятии

Подчеркнем, что на рисунке приведена ситуация, наиболее характерная для действующего предприятия.

На практике сложилось так, что чаще всего вопросы автоматизации управления инженерными данными решались на стадии проектирования. Это обусловлено тем, что при современном развитии САПР подавляющее большинство инженерных данных порождается при проведении проектных работ в электронном виде, что позволяет эффективно строить СУИД. Совсем иначе обстоят дела с источниками данных и, как следствие, — с подходами к построению СУИД на существующих предприятиях.

О трех путях создания СУИД

В предыдущих публикациях мы рассматривали систему электронного архива как первую ступень на пути построения СУИД. В этой статье мы хотим акцентировать внимание и на других путях. Это связано с тем, что создание СУИД, первой ступенью которой является электронный архив,— вовсе не «единственно верная дорога». Здесь мы будем говорить как минимум о трех подходах:

• путь построения СУИД, основной функционал которой изначально управляет неструктурированными данными (чаще — документами). Такую систему мы будем кратко называть «СУИД от неструктурированных данных»;
• путь построения СУИД, функционал которой изначально управляет структурированными данными. Кратко — «СУИД от структурированных данных»;
• путь построения СУИД, функционал которой изначально направлен на управление как структурированными, так и неструктурированными данными. Кратко — «СУИД от реалий».

Следует подчеркнуть, что целью статьи ни в коей мере не является «пропаганда» одного из названных путей. Дело в том, что выбор того или иного подхода, как и решение любой практической задачи, определяется конкретными условиями, исходными данными, целями создания СУИД. Существуют примеры если не «полномасштабных» внедрений СУИД, то хотя бы внедрений ее компонентов каждым из трех перечисленных способов. Далее мы попробуем описать условия применения того или иного пути и привести реальные примеры.

Идею о трех путях прекрасно иллюстрирует народный эпос (рис. 2):

Рис. 2

• каждый путь, хоть и связан с затратами, но требует неизбежного выбора;
• не все пессимистичные прогнозы сбываются.

Построение СУИД «от неструктурированных данных»

Ранее, рассматривая эволюцию создания СУИД, мы обосновали вывод о том, что в подавляющем большинстве случаев создание СУИД на первом этапе сводится к реализации системы электронного архива инженерной (проектно­сметной) документации. Аргументировалось это тем, что по ряду объективных причин, несмотря на развитие САПР, подавляющий объем инженерных данных существует в неструктурированном виде (в электронных документах и документах на бумажных носителях).

При этом такой электронный архив должен не только автоматизировать централизованное хранение, но и содержать некий минимальный набор функционала:

подсистему структурирования и кодификации ПСД в соответствии с требованиями, определяемыми действующими нормативами (например, структуру разделов в соответствии с Постановлением 87, «заполненную» томами и комплектами документации);

• подсистему пополнения (минимально возможная автоматизация процесса размещения комплектов/томов документов в соответствующих разделах с возможностью контроля и исключения ошибок);
• подсистему проведения отгрузок документов заказчику проектных работ (выгрузка документов, формирование накладных на отгрузку, регистрация факта отгрузки и получения документов заказчиком);
• подсистему проведения изменений (с формированием разрешений);
• сервисные подсистемы (поиск, разграничение прав доступа, автоматизированное формирование некоторых документов, например перечня основных комплектов, состава документов комплекта, бланков накладных на отгрузку, этикеток CD, отгружаемых заказчику, аналитических отчетов по состоянию работ, отгрузок и т.д.).
• Отметим следующее:
• без перечисленного функционала электронный архив ПСД, на наш взгляд, не является полноценным;
• возможны дальнейшие «надстройки» над перечисленным базовым функционалом, при этом доработки производятся в двух направлениях:
• автоматизация потоков документов и работ, в основном не предусматривающая «извлечения» данных из документов для последующей серьезной обработки. Такой подход чаще рассматривает документ с содержащимися в нем инженерными данными как «конечный и неделимый контейнер». Подобные надстройки наиболее характерны для систем электронного архива и ведут к созданию систем технического документооборота (TDM) и систем автоматизации обмена проектными заданиями между специальностями (в проектных организациях области ПГС). Отметим, что описываемый путь не исключает наличия программных интерфейсов со средствами разработки. Следует помнить, что такие интерфейсы не предназначены для «полного извлечения инженерных данных из контейнера». В основном «извлекается» сравнительно небольшая часть параметров, атрибутов, которой чаще всего достаточно лишь для решения «сервисных» задач. Примером подобного интерфейса является достаточно распространенный функционал синхронизации полей углового штампа чертежа с соответствующими полями электронной карточки документа в системе электронного архива (при изменении информации в угловом штампе автоматически меняется информация в соответствующем поле карточки),
• автоматизация потоков документов и работ, предусматривающая «извлечение» данных из документов для последующей обработки (выходящей за пределы «сервисных» функций). Наш опыт говорит, что успешные полномасштабные реализации подобного функционала, «надстраиваемого над электронным архивом», практически не встречаются. Такой путь дальнейшего развития электронного архива крайне трудоемок в подавляющем большинстве случаев. Это обусловлено тем, что, если изначально документ рассматривался как «неделимый контейнер» и отсутствовали жесткие правила внесения инженерных данных в контент, «извлечь» данные для обработки с приемлемой степенью автоматизации практически невозможно;

такой электронный архив мы рассматривали как ступень к созданию СУИД.

Построение СУИД «от структурированных данных»

В области ПГС нашими заказчиками неоднократно выражалось желание управлять лишь структурированными данными. Как правило, подразумевается, что и изначально при проектировании будут «порождаться» только структурированные данные, и на последующих стадиях ЖЦ информационная модель объекта будет пополняться структурированными данными.

Высказывая такое желание, заказчики часто ссылаются на опыт машиностроителей, авиастроителей и коллег в других отраслях, «давно прошедших текущую в ПГС стадию эволюции», успешно внедривших PLM­системы, которые позволяют управлять инженерными данными, изначально структурированными.

Такой подход в области ПГС вполне справедлив и логичен, но на практике в действие вступают следующие ограничения:

• далеко не все инженерные данные структурированы, что особенно актуально для давно существующих объектов (предприятий);
• для вновь проектируемых объектов далеко не все данные поступают изначально в структурированном виде. Чем крупнее объект ПГС, тем больше средств разработки задействовано (для изделий машиностроения перечень используемых средств гораздо короче). Кроме того, практически неизбежно наличие субподрядных организаций. Подрядчики далеко не всегда (крайне редко) выдают генпроектировщику инженерные данные в структурированном виде, позволяющем извлекать их, передавать (например, расчетным подсистемам и другим средствам проектирования) и обрабатывать с высокой степенью автоматизации;
• далеко не все представления данных, например трехмерные модели, а также результаты проектирования в двумерных САПР, легитимны с точки зрения действующего законодательства (они могут быть, к примеру, не оформлены в соответствии с требованиями стандартов РФ, не подписаны ЭЦП). Не все из них могут передаваться участникам ЖЦ и обрабатываться в дальнейшем с оптимальной степенью автоматизации. Данная проблема оказывается особенно актуальной в случае, если проектант, заказчик проектных работ, строительная и эксплуатирующая организация — это разные лица (организации), а требования к результатам передаваемой информации, сформулированные заказчиком, в лучшем случае включают строку «передача, в том числе и в электронном виде» (без дальнейшего раскрытия «этого самого вида»).

Перечисленные факторы вовсе не делают построение полноценной СУИД, управляющей лишь структурированными данными, чем­то нереальным.

Существуют различные технические и технологические решения. Можно пытаться полностью структурировать инженерные данные перед их «размещением» в СУИД. Например, можно проводить распознавание сканированных образов с дальнейшей «ручной» верификацией. Можно «восстановить» трехмерную модель, содержащую структурированные данные в САПР, «руководствуясь» информацией, получаемой из двумерных чертежей (такая информация может быть, например, получена «визуально» из чертежей на бумаге). Бюро ESG имеет опыт проведения и таких работ. При этом отметим следующее:

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

Построение СУИД «от реалий»

Несмотря на оптимизм, высказанный в заключительных строках предыдущего раздела, вернемся к перечисленным выше реалиям.

На практике, несмотря на успехи в построении СУИД или ее компонентов описанными нами путями, в подавляющем большинстве случаев возникает неизбежная необходимость управлять в рамках СУИД как структурированными, так и неструктурированными данными. Действительно, с одной стороны, нерационально использовать современные средства разработки, например трехмерные САПР, а затем «размещать» инженерные данные в неструктурированном виде в графических форматах и управлять документами. С другой стороны, не всегда целесообразно пытаться структурировать данные, которые находятся в контенте документов графических форматов, полученных при сканировании бумажных носителей. Такие подходы далеко не всегда оправдывают немалые вложения во внедрение технологий трехмерного проектирования (в первом случае) или структурирование данных, получаемых из контента электронных образов «бумажных» документов (во втором).

Некоторые примеры и тенденции

Построение СУИД, управляющей неструктурированными данными

На наш взгляд, такой путь наиболее приемлем в крупных проектных организациях, которые характеризуются следующими признаками:

• крупные объекты проектирования,
• большое количество проектных дисциплин;
• отсутствие интегрированных (способных обмениваться инженерными данными) средств разработки (прежде всего САПР) и/или технологий проектирования, позволяющих максимально автоматизировать процессы обмена структурированными данными между проектными дисциплинами;
• большое количество субподрядчиков;
• отсутствие требований со стороны генподрядчика к субподрядчикам и со стороны заказчика проектных работ по предоставлению электронных моделей (структурированные данные которых могут интегрироваться в единую среду);
• большое количество используемых типизированных решений, данные о которых хранятся в бумажном или электронном виде и не структурированы.

Наиболее ярким примером является полномасштабное внедрение подобной системы в ОАО «Гипроспецгаз» — крупнейшем проектном институте газовой отрасли России.

На первом этапе с участием Бюро ESG была разработана и внедрена система электронного архива ПСД, обладающая перечисленным выше функционалом. На последующих этапах были реализованы подсистемы управления технической документацией и управления проектными заданиями (обмена заданиями) между специальностями (отделами) системы технического документооборота. Кроме управления «техническими» документами, в единой среде автоматизировано управление потоками организационно­распорядительной, «административной» документации (ОРД). При этом существует связь между различными потоками, позволяющими, например, осуществлять переход по связям от входящего письма субподрядчика (обрабатывается в потоке ОРД) к комплекту субподрядной документации — приложению к письму (обрабатывается в «техническом» потоке).

Всего в системе работает примерно 700 пользователей. Весь функционал реализован с участием Бюро ESG в среде программного комплекса TDMS.

Построение СУИД, управляющей структурированными данными

На наш взгляд, подобный подход к построению СУИД может быть реализован лишь в условиях, когда инженерные данные поступают в структурированном виде от всех участников жизненного цикла объекта, причем структура данных заранее регламентирована.

Приведем пример, а скорее — опишем некую концепцию, вектор развития. Обратим внимание на то, что речь пойдет не об уже реализованной СУИД, которая, управляя лишь структурированными данными, является полноценной, а о предпосылках и наших прогнозах на ее создание.

Примеров использования передовых технологий при проектировании, строительстве, эксплуатации и утилизации объектов атомной энергетики описано немало. Как правило, ГК «Росатом» и является заказчиком проектирования и строительства, и отвечает за эксплуатацию объектов атомной энергетики. Этим объясняется то, что, несмотря на техническую сложность атомной станции, урегулировать вопросы об используемых технологиях и средствах разработки, формате передаваемых инженерных данных между различными участниками процессов на различных стадиях ЖЦ в рамках «одного ведомства» оказывается проще. По нашим оценкам, отрасль лидирует в области автоматизации процессов информационного обеспечения ЖЦ. При существующей динамике развития четко прослеживается перспектива создания СУИД «от структурированных данных».

Построение СУИД «от реалий»

Остановимся на примерах построения СУИД с учетом существующих реалий и вновь акцентируем внимание на наиболее «проблемной», на наш взгляд, нише. Прежде всего, речь пойдет о существующих промышленных предприятиях. Итак, СУИД должна, с одной стороны, управлять оптимально систематизированными неструктурированными данными, а с другой — управлять структурированными данными, получаемыми от средств разработки и прочих источников.

СУИД «от реалий» для существующих предприятий

В качестве первого примера приведем технологии компании Intergraph. СУИД, реализованная на основе использования среды SmartPlant for Owner/Operators, позволяет управлять как структурированными, так и неструктурированными данными с учетом особенностей и реалий, сложившихся на современных существующих предприятиях с непрерывным производственным циклом.

Как отмечалось выше, для управления неструктурированными данными изначально их надо как­то подготовить для ввода в единую среду — систематизировать, индексировать, «упорядочить» каким­либо другим способом, наиболее оптимальным и приемлемым для конкретного случая. Для выполнения этой задачи предназначен набор инструментов компании Intergraph — технология SmartPlant Fusion.

Технология SmartPlant Fusion позволяет «дифференцированно» подойти к способам пополнения БД СУИД в зависимости от форматов, структур, атрибутики и прочих параметров представления как структурированных, так и неструктурированных существующих инженерных данных. Иными словами, для каждой группы инженерных данных технология Intergraph SmartPlant Fusion предлагает тот или иной набор инструментов для пополнения единой БД и создания необходимых связей. Спектр предлагаемых SmartPlant Fusion механизмов широк — от средств автоматизированной загрузки структур каталогов и файлов из файловой системы до сложных программных интерфейсов с различными САПР и прочими источниками инженерных данных, позволяющих «получать» данные непосредственно «из контента» моделей, чертежей и прочих результатов работы в различных средствах.

Данные консолидируются в единой БД. Технология моделирования включает три ступени:

• подготовка;
• внесение данных в единую базу;
• построение связей.

На первой ступени проводится анализ возможностей автоматизированного ввода (по именам файлов и каталогов, в которых хранится документация; по структуре данных, полученных в различных САПР и других программных средствах). После анализа происходит настройка системы и трансляторов.

На второй ступени производится автоматизированное внесение данных в единую базу. В процессе ввода используются трансляторы для структурированных данных, источниками которых являются, например, САПР. Для необходимого «упорядочения» неструктурированных данных, содержащихся в файлах и каталогах файловой системы, применяются алгоритмы разбора имен. Подобные механизмы, например, используются для структур и имен каталогов файловой системы — «аналогов» разделов рабочей документации и комплектов и имен файлов — «аналогов» документов.

На третьей ступени строятся необходимые связи между внесенными элементами информационной модели.

Рис. 3. Связи проектной позиции с различными данными в единой среде

Кроме средств подготовки и ввода данных, набор инструментов SmartPlant Fusion включает различные средства просмотра данных файлов и моделей, средства визуализации, средства работы с результатами лазерного сканирования, веб­портал и средства получения необходимых отчетов.

Результат работы технологии SmartPlant Fusion показан на рис. 3 и заключается в следующем:

• существует некая проектная позиция (в нашем случае насос, см. рис. 3);
• существуют следующие связанные с проектной позицией сущности:

- технологическая схема,

- система,

- трехмерная модель оборудования,

- информация о производителе,

- результаты лазерного сканирования,

- информация о ТО и Р, заменах, поставщиках, расходных материалах,

- данные заказа,

- прочие данные и документы.

• в единой среде­СУИД, куда поступают данные, существует возможность перехода по связям для сбора необходимой информации о проектной позиции, параметрах, документах, моделях и т.д.;
• поскольку все сущности имеют набор атрибутивных параметров, а среда использует современную СУБД, имеется возможность формирования тех или иных запросов с целью получения отчетов.

SmartPlant Fusion позволяет подготовить данные, передать их в единую среду и построить связи. После этого информацией управляет СУИД, построенная на основе другого решения от компании Intergraph — SmartPlant Enterprise For Owner/Operators (SPO) — рис. 4. Подчеркнем, что вопросы упорядочения, актуализации и управления разнородными структурированными и неструктурированными данными, полученными из множества «внешних» и «внутренних» источников, наиболее остро стоят на ранее спроектированных и построенных действующих предприятиях. В связи с этим мы и описываем СУИД на примере SPO.

Рис. 4. Взаимодействие технологий при построении СУИД инструментами Intergraph

Решение SPO включает механизмы, обеспечивающие поддержку общих, наиболее критичных рабочих процессов производственного предприятия. Рамки статьи не позволяют привести описания всех подсистем SPO. Очень кратко остановимcя лишь на некоторых функциях, представляющих особый интерес.

Несомненно, инженерные данные применяются и имеют связи с прочими важнейшими системами автоматизации современных предприятий, прежде всего, с системами обеспечения эксплуатации, контроля технологических процессов, обеспечения технического обслуживания и ремонта. В связи с этим SPO имеет необходимые механизмы для обмена данными с такими системами.

Мы неоднократно писали об использовании результатов лазерного сканирования в процессе модернизации. Напомним, что облако точек — результат сканирования существующих объектов — может быть, например, «подключено» к модели, получаемой в специальных средствах консолидации данных от различных САПР и результатов лазерного сканирования, например Intergraph SmartPlant Revew, Autodesk Nevisworks и др. Помимо облака точек в такую модель подключаются данные — результаты проектирования новых объектов. В процессе модернизации предоставляется возможность проверки на коллизии, измерения расстояний между строящимися и существующими объектами, проверки ширины проходов, необходимой для правильной последовательности установки оборудования, и т.д. Подчеркнем, что перечисленный функционал, требующий наличия облака точек, наиболее востребован при модернизации. Для стадии ЖЦ эксплуатации существует другая, на наш взгляд, «более наглядная» и «менее затратная» технология, суть которой заключается в следующем:

• в работе для трехмерной визуализации объектов на стадии эксплуатации используется не облако точек, а трехмерная панорамная фотография, получаемая с применением оборудования и технологий Leica;
• специальным инструментарием строятся связи между областями панорамной фотографии и любыми инженерными данными (реализуется концепция, изображенная на рис. 3);
• переход осуществляется кликом мыши по соответствующей области фотографии.

Пользовательский интерфейс — панорамная фотография и связанные инженерные данные — показан на рис. 5.

Правая верхняя часть — результат панорамного фотографирования с использованием технологий Leica. На изображении каждой позиции оборудования «размещена» метка (ссылка). При инициализации ссылки (на рисунке — позиция Р 7701А) осуществляется отображение оборудования в технологической схеме (правая нижняя часть окна), чертежей (левая нижняя часть окна) и эксплуатационной документации (левая верхняя часть окна).

Рис. 5. Панорамная фотография и связанные инженерные данные

Несомненно, говорить о примерах полномасштабной реализации СУИД таким путем с применением описанных технологий Intergraph пока рано. Тем не менее такой подход уже используется. Отечественная ядерная энергетика и в этом направлении лидирует. Так, при строительстве Ростовской АЭС проектным институтом НИАЭП совместно с компанией Intergraph успешно проведен пилотный проект по созданию СУИД с использованием технологии SmartPlant Fusion. С помощью этого инструментария данные были подготовлены для ввода и введены в единую информационную среду. Далее были построены все необходимые связи, идеология которых приведена на рис. 3. Кроме того, в процессе работ использовались результаты лазерного сканирования.

СУИД «от реалий» для проектных организаций

Путь создания СУИД «от реалий» вполне приемлем и в проектных организациях, которые характеризуются одновременно двумя следующими факторами:

• основные проектные дисциплины используют САПР, порождающие структурированные данные и позволяющие обмениваться ими в рамках единой среды;
• существует большой объем неструктурированных данных (например, порождаемых в соответствующих средствах разработки типовых решений, хранящихся в неструктурированных форматах, и данных, поступающих от субподрядчиков).

Примером инструментария для построения СУИД «от реалий» для проектной организации могут служить и новые разработки компании InterCAD на базе линейки продуктов Autodesk. Работы активно ведутся, но пока еще рано говорить о завершенной работе, скорее, реализован первый этап системы консолидированного хранения инженерных данных. При этом идеология построения системы в основных подходах подразумевает работу как со структурированными, так и не со структурированными инженерными данными.

В качестве инструмента объединения данных, поступающих от различных источников, используется продукт Autodesk Vault — единое хранилище информации. Источниками структурированных данных являются:

• САПР Autodesk Revit (всё семейство, функционал полностью разработан);
• САПР AutoCAD Civil 3D (разработка в стадии завершения);
• САПР AutoCAD MEP (разработки запланированы).

В качестве источников неструктурированных данных могут служить любые другие САПР, расчетные пакеты, текстовые редакторы, документы, полученные путем сканирования «бумажных» носителей.

Отметим, что в разрабатываемой технологии, с одной стороны, учтены разработанные компанией InterCAD передовые методики проектирования, связанные прежде всего с использованием трехмерных САПР. С другой стороны, технология позволяет не только управлять структурированными и неструктурированными инженерными данными, но и представлять результаты проектных работ в соответствии с требованиями Постановления № 87 «О составе разделов проектной документации и требованиях к их содержанию» от 16 февраля 2008 года.

Краткие выводы

• Опыт говорит о том, что существуют три основных пути построения СУИД;
• пути различаются подходами к «управляемой сущности» — только неструктурированные данные, только структурированные данные, те и другие;
• все три пути имеют полное право на существование и положительную историю успеха, если не при «полномасштабных» внедрениях СУИД, то при внедрении ее компонентов;
• наличие различных подходов прежде всего обусловлено конкретными условиями и задачами, с учетом которых можно говорить о приоритетах того или иного пути. 

Список литературы:

1. Галкина О., Кораго Н., Рындин А., Тучков А. Система электронного архива Д’АР — первый шаг к построению системы управления проектными данными // САПР и графика. 2013. № 9.
2. Рындин А., Тучков А. Системы управления проектными данными в области промышленного и гражданского строительства: наш опыт и понимание // САПР и графика. 2013. № 2.
3.  Чиковская И. Внедрение BIM — опыт, сценарии, ошибки, выводы // САПР и графика. 2013. № 8.
4. Чиковская И., Турецкий О. Цифровое моделирование зданий. Новые разработки компании InterCAD // Электронный сборник публикаций http://esg.spb.ru/articles/126.
5. Малашкин Ю., Шатских Т., Юхов А., Галкина О., Кораго Н., Рындин А., Фертман И. Опыт разработки системы электронного документооборота в ОАО «Гипроспецгаз» // САПР и графика. 2011. № 12.

САПР и графика 2`2014