Казаков А. Методы автоматизации строительного проектирования Технологии строительства 2003 №5 C. 126-128

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

Проектирование сложных объектов и решение основных задач проектирования невозможно сегодня без систем автоматизированного проектирования (САПР), систем управления базами данных (СУБД) и систем управления данными о проекте (РОМ). Функциональность таких систем стремительно расширяется. Однако не менее важным фактором, определяющим успешное решение задачи проектирования, является использование соответствующих методологий, позволяющих отслеживать причинно-следственные связи, использовать накопленные ранее знания, порождать и хранить новые.
Реализация современных требований сокращения сроков и стоимости проектирования, повторного использования накопленной информации при проектировании новых зданий и сооружений, обеспечения необходимой информационной поддержки проекта на протяжении всего его жизненного цикла невозможна без применения специальных методологий проектирования. Такие методологии должны учитывать, что на разных этапах жизненного цикла требуются разные представления данных о проекте, и при этом значительную актуальность приобретает требование соблюдения целостности данных (например, в части сохранения причинно-следственных связей).
Современные тяжелые системы автоматизированного проектирования уже давно не являются только системами трехмерного черчения. Они включают в себя развитые средства накопления и использования знаний, проектирования в контексте, параллельного проектирования, разделения по стадиям, подсистемам и ролям и т.д. Соблюдение методологий проектирования частично осуществляется стандартной функциональностью систем за счет реализации организационных мер, позволяющих не только поддерживать новые функции, но и методологические решения в целом. Для автоматизации этих возможностей требуется соответствующая информационная поддержка со стороны PDM, VPDM (Virtual Product Data Management), CPD (Collaborative Product Development), CPC (Collaborative Product Commerce) и т.п., а сегодня позиционируемых как системы cPDm (collaborative Product Definition management).
Таким образом, складывается ситуация, когда нельзя говорить о качественном решении вопроса автоматизации процесса проектирования в строительстве без учета современных компьютерных технологий и методологии организации данного процесса.
В настоящее время пока еще не существует систем, которые в полной мере реализуют концепцию cPDm. Границы между CPD, CPC, VPDM, а также «классическим» PDM размыты по своей природе: не существует абсолютных критериев определения принадлежности системы к какому-то специфическому классу. Многие производители относят свою систему к нужному им классу только потому, что в нее включены соответствующие функции. Если использовать подобные «мягкие» критерии, то почти все современные PDM-системы можно позиционировать как cPDm.
Современные проекты обычно характеризуются жесткими ограничениями по времени, средствам, выделяемым на их выполнение, качеству к выдаваемой проектной документации. Для выполнения таких проектов требуется PLM-решение, позволяющее управлять хранением информации и доступом к ней, составом и структурой проекта; поддерживать логические связи и ассоциативности; обеспечивать многофункциональную среду проектирования, предполагающую быстрый, легкий и надежный обмен проектными данными. Кроме того, в таком решении должен быть обеспечен открытый интерфейс к самой системе, а также в другие РОМ.
Модели сложных проектов с длительным жизненным циклом должны содержать описание всех стадий и состояний этого цикла, а также предусматривать несколько различных способов визуализации. Носитель информации о компоненте содержит множество различных типов элементов данных, а проекты имеют как минимум два различных вида конфигураций: конфигурацию состава (или «Комплектация») и конфигурацию состояния. Проектные данные должны управляться не только параметрами, но и DTs (управляющие таблицы), Rules (правила), Checks (проверки) и т.д.