Выпуск #4/2012
А.Сабунин
Организация единой базы данных ЭРИ. Пример работы с Altium Designer
Организация единой базы данных ЭРИ. Пример работы с Altium Designer
Просмотры: 3735
Системы автоматизированного проектирования (САПР) – неотъемлемая часть процесса создания радиоэлектронной аппаратуры на всех его этапах. Однако помимо внедрения САПР, для эффективного и качественного проектирования и изготовления изделий необходимо обеспечить интеграцию всех используемых САПР. Важнейшим и, вероятно, самым сложным этапом интеграции является создание единой базы данных ЭРИ и организация управления ею.
Применение систем автоматизированного проектирования при разработке электронных устройств сегодня является нормой для большинства предприятий радиоэлектронной отрасли. Хотя в нашей стране еще есть предприятия, где разводка многослойной платы выполнятся на кульмане разноцветными карандашами, это скорее редкое исключение, подтверждающее повсеместно устоявшиеся правила. Однако многие разработчики, и, что более печально, крупные предприятия, используют далеко не все возможности имеющихся САПР. Это не позволяет им получить требуемое качество продукции и высокую производительность при проектировании.
Основная идея всех применяющихся САПР – это организация единого маршрута проектирования изделия. Нельзя сказать, что все проектируемые изделия могут быть разработаны в единой системе, хотя для управления структурой и жизненным циклом сложных изделий используются системы PDM (Product Data Management) или PLM (Product Lifecycle Management). Однако можно утверждать, что для отдельных задач проектирования могут быть использованы соответствующие САПР. Например, для маршрута проектирования ПЛИС – Quartus (Altera) или ISE Foundation (Xilinx), для маршрута проектирования СБИС – пакеты Cadence или Synopsys, для проектирования печатных плат – Altium Designer (Altium) или Allegro (Cadence). Если проектирование ПЛИС и СБИС – сравнительно новые области для отечественных разработчиков и их разработка зачастую невозможна без соблюдения полного маршрута проектирования и установленного соответствующего САПР, то проектирование печатных плат (ПП) в нашей стране выполняется довольно давно, еще до появления соответствующих САПР. И именно при их разработке на отечественных предприятиях наблюдается отсутствие устоявшихся маршрутов проектирования с использованием САПР, начиная от применения нескольких программ для решения данной задачи и до отсутствия единого маршрута проектирования. Часто приходится видеть такую картину: схема сформирована в OrCAD (а бывает и хуже – в AutoCAD), а плата затем реализуется в P-CAD или PADs. На отечественных предприятиях задачи разработки схемы и проектирования ПП чаще всего выполняют разные специалисты и даже разные подразделения, которые к тому же могут быть разделены территориально. Все это приводит к тому, что каждый делает так, "как привык" или "как удобнее", при этом многие понимают, что такие методы неприемлемы, но практически никто не решается на изменение устоявшихся маршрутов проектирования.
Сегодня многие отечественные предприятия внедряют современные САПР (Altium Designer, пакеты Mentor или Cadence), но на многих из них процесс внедрения заканчивается покупкой лицензии на право использования этих программных средств. Зачастую разработчик, которому на рабочем месте устанавливают легальную копию программы, еще несколько лет по инерции работает так же, как и раньше (чаще всего в P-CAD). Сложность в основном заключается в том, что разработчики и конструкторы печатных плат не могут перейти на новые САПР без ранее созданных библиотек компонентов и подробного описания нового маршрута проектирования. Структура библиотечной базы данных (БД), порядок работы с ней, а также маршрут проектирования плат в САПР должны быть утверждены на уровне стандарта организации (СТО) и быть обязательными для исполнения всеми участниками процесса. В данной статье речь пойдет, наверное, о самой сложной части при внедрении САПР на крупных предприятиях – об организации БД и порядке работы с ней. Принципы организации БД будем рассматривать на примере САПР Altium Designer, хотя подобные методы могут быть применены и при внедрении других САПР ПП, с возможными незначительными вариациями.
При организации БД для САПР на предприятии возникает целый ряд вопросов: как организовать БД без остановки процесса проектирования, что должна содержать БД электрорадиоизделий (ЭРИ) и, самое главное, кто должен заниматься организацией БД ЭРИ? Ответ на последний вопрос очевиден, но при его реализации на многих предприятиях возникают административные трудности: библиотеки должны создаваться самими пользователями и затем проверяться администратором базы данных. Сложнее всего назначить того, кто будет исполнять обязанности администратора БД, так как ранее такой должности на многих предприятиях не существовало, но сейчас такой специалист необходим.
Теперь попробуем подробнее разобраться с порядком организации БД и о роли ее администратора в данном процессе. Обычно сквозной процесс проектирования печатных плат с использованием САПР в упрощенном виде выглядит так: разработка схемы (Э3), формирование технического задания на плату, проектирование печатной платы, разработка конструкции, оформление конструкторской (КД) и технологической документаций (рис.1). Чтобы маршрут проектирования представлял собой именно сквозной процесс, необходимо, чтобы данные, внесенные на первых этапах проектирования, дополнялись на последующих этапах и именно из них были получены итоговые данные как для производства (gerber, NC drill, placement), так и для документации (перечень элементов, спецификация и др.). Для этого компонент, используемый при создании схемы, должен содержать необходимый набор данных для всех последующих этапов проектирования: посадочное место для печатной платы, модели для моделирования, атрибуты для формирования текстовой документации и др.
Начиная создавать новый проект, разработчик должен использовать только компоненты из центральной БД (предположим, она уже имеется). В том случае, если в новом проекте появляются ЭРИ, которые ранее не использовались и отсутствуют в БД, предполагается применение библиотеки проекта, в которую разработчик добавляет недостающие компоненты. Для упрощения работы разработчика заранее должен быть проработан шаблон проекта, в котором имеются все необходимые документы, а также шаблон компонента в библиотеке проекта. Использование шаблонов исключает "человеческий фактор" при создании типового компонента базы данных и способствует повышению производительности при добавлении новых компонентов.
После того, как все недостающие компоненты добавлены в библиотеку проекта в виде соответствующих схемных символов, разработчик формирует заявку на внесение данного компонента в центральную БД. Заявка должна содержать минимальный набор сведений о компоненте: PartNumber – название компонента по каталогу поставщика, Footprint – название посадочного места по документации (datasheet) к компоненту и ID – уникальный номер компонента в БД предприятия для последующей синхронизации. Для удобства работы в заявке для компонентов могут быть указаны дополнительные параметры, например, Manufacturer – производитель, Part – функциональная группа компонента и др. Заявка утверждается начальником отдела и согласовывается с технологом и соответствующими службами, ответственными за применяемость и закупку ЭРИ, после чего она вместе с библиотекой проекта передается администратору БД. Администратор несет ответственность за пополнение центральной БД предприятия и за ее целостность, поэтому при обработке заявки он должен проверить созданные символы в библиотеке проекта, добавить к ним соответствующие посадочные места и сформировать карточку с атрибутами компонентов. При таком подходе к наполнению БД она будет содержать только используемые компоненты, утверждение которых происходит параллельно с процессом проектирования изделия.
Отдельно стоит сказать о карточке атрибутов компонента. Практически на каждом предприятии возникают долгие споры о ее необходимости и, позднее, о ее составе. Тут важно определить задачи, для решения которых создается данная карточка: во-первых, она используется для автоматического формирования текстовой части КД (перечень элементов, спецификация, ведомость покупных изделий и др.), во-вторых – для оптимизации поиска компонента по центральной БД предприятия. Для текстовой части КД каждому компоненту необходима всего одна запись, но так как в данной документации в соответствии с ЕСКД необходима сортировка записей по разным полям, компонент должен содержать все необходимые атрибуты, по которым выполняется сортировка. Например, в случае резистора, необходимо наличие атрибутов, определяющих его номинал, мощность, допуск и т.д., хотя это не свойственно иностранной номенклатуре, когда вся информация о компоненте представлена в виде единого кода (Part Number).
К моменту, когда проект с техническим заданием на проектирование печатной платы поступает к конструктору, в центральной БД уже должны быть добавлены те компоненты, которые в текущем проекте использовались из библиотеки проекта. Последний этап работы разработчика – синхронизация проекта с центральной БД, т.е. замена тех компонентов, которые использовались временно, на утвержденные по результатам заявки. Такая синхронизация позволяет передать более полную информацию об ЭРИ из центральной БД в проект, после чего можно начать работу над проектированием печатной платы, а также получить из проекта выходную документацию.
При описанном подходе к организации БД на предприятии наиболее важную роль играет администратор БД, который должен обладать знаниями во всех направлениях деятельности, сопутствующих полному маршруту проектирования. Администратор проверяет правильность создания компонента в соответствии с документацией, создает посадочное место и оформляет карточку компонента, поэтому именно он несет ответственность за полноту и своевременное обновление центральной БД.
Возможны некоторые изменения процедуры добавления компонентов в централизованную БД предприятия. Например, в некоторых случаях согласование компонентов происходит в процессе согласования проекта, и добавление новых компонентов, используемых в текущем проекте, в БД происходит по факту сдачи проекта в архив. В таком случае значимость администратора БД уменьшается, так как он уже не несет ответственности за содержимое БД, а отвечает лишь за своевременность ее пополнения.
Показанный на рис.1 маршрут проектирования печатных плат с некоторыми изменениями используется на многих предприятиях России, причем он не привязан к конкретной САПР.
Следующий важный вопрос – что из себя представляет центральная база данных? Конечно, в каждой САПР возможна организация библиотек в своем внутреннем формате, но более предпочтительной выглядит организация библиотек компонентов в виде реляционной БД. В самом простом случае такая БД будет содержать набор таблиц, в каждой из которых отдельная запись содержит всю информацию, относящуюся только к одному конкретному компоненту. Применительно к САПР такая база данных должна содержать информацию об условно-графическом отображении (УГО) компонента на схеме, топологическом посадочном месте (ТПМ) для платы и атрибутах, описанных выше (см. таблицу). Непосредственно УГО и ТПМ представлены в формате применяемой САПР и хранятся либо в некоторых библиотеках, либо в виде отдельных файлов.
Например, в программе Altium Designer возможно подключение к любой внешней БД с помощью создания специального файла DBLib. На рис.2 показан пример такой базы, в основе которой лежит файл в формате Excel. В этом случае каждая таблица (лист в Excel) содержит список компонентов и определяет используемые ими УГО, ТПМ, а также пользовательские атрибуты. Все файлы, ссылки на которые даются в БД, хранятся отдельно и организованы в виде файловой структуры (см.рис.2). Работа с такой БД возможна как через СУБД, так и через интерфейс САПР. На рис.3 показан порядок организации такой библиотеки в Altium Designer:
1. Создание файла DBLIB. Этот файл предназначен для взаимодействий графического редактора Altium Designer с внешней БД.
2. Подключение к внешней БД. Может быть выполнено путем выбора типа БД Excel или Access, а также указанием строки для подключения другой БД. После выбора БД необходимо выполнить подключение (кнопка Connected).
3. Добавление новой записи в БД. Выполняется через контекстное меню в разделе Table Browser (см. рис.3).
4. Определение атрибутов компонента в БД, через окно New Component. При этом предполагается, что УГО и ТПМ были ранее созданы в САПР и необходимо лишь определить их применяемость в том или ином компоненте.
Описанный процесс формирования БД в САПР Altium Designer выполняется вышеупомянутым администратором БД, при этом все составные части этой базы (или, по крайней мере, УГО) должны быть предоставлены автором заявки.
Основное преимущество организации библиотек ЭРИ на крупных предприятиях с помощью БД – возможность синхронизации с другими БД, например, с отделом комплектации. Обычно посредником между различными БД в рамках предприятия выступает PDM-система. В некоторых случаях база PDM является общей для всех структурных подразделений и создает единое информационное пространство, способное увязать между собой все этапы жизненного цикла изделия.
При использовании PDM-, PLM- и CAD-систем в общем процессе проектирования большую роль играет их взаимная интеграция. Обычно на отечественных предприятиях сначала внедряются САПР для решения прикладных задач проектирования, и только потом решается задача внедрения PDM- и PLM-систем. При этом вопрос об интеграции этих систем появляется только на последнем этапе, когда возможности для реализации этой интеграции минимальны, а работы по ее осуществлению становятся очень дороги. Для создания единого информационного пространства в рамках всего цикла проектирования, с использованием различных систем, наличие единой БД ЭРИ просто необходимо. В идеальном случае процесс наполнения БД ЭРИ должен начинаться с добавления компонента в PDM-систему, и только после этого он может быть использован в прикладной САПР, будь то Altium Designer на уровне проектирования ячейки или другая система на уровне проектирования блока (частью которого является ячейка).
В заключение хотелось бы отметить, что при внедрении САПР и организации БД ЭРИ на крупных предприятиях необходимо учитывать все аспекты организации единого цикла проектирования и производства, а не решать локальные прикладные задачи в САПР, как это происходит сейчас. Внедрение САПР, а тем более PDM- и PLM-систем – это долгосрочная стратегия развития предприятия, и от ее проработанности зависит успешность и эффективность процесса внедрения. Оно должно сопровождаться строгим планом, в котором описаны все бизнес-процессы, структура БД и порядок ее наполнения. По итогам процесса внедрения все пользователи должны иметь СТО и инструкции, подробно описывающие деятельность каждого исполнителя.
Литература
ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания, 1992.
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Техническое задание на создание автоматизированной системы, 1990.
Сабунин А.Е. Altium Designer. Новые решения в проектировании электронных устройств. – М.: Солон-Пресс, 2009.
Основная идея всех применяющихся САПР – это организация единого маршрута проектирования изделия. Нельзя сказать, что все проектируемые изделия могут быть разработаны в единой системе, хотя для управления структурой и жизненным циклом сложных изделий используются системы PDM (Product Data Management) или PLM (Product Lifecycle Management). Однако можно утверждать, что для отдельных задач проектирования могут быть использованы соответствующие САПР. Например, для маршрута проектирования ПЛИС – Quartus (Altera) или ISE Foundation (Xilinx), для маршрута проектирования СБИС – пакеты Cadence или Synopsys, для проектирования печатных плат – Altium Designer (Altium) или Allegro (Cadence). Если проектирование ПЛИС и СБИС – сравнительно новые области для отечественных разработчиков и их разработка зачастую невозможна без соблюдения полного маршрута проектирования и установленного соответствующего САПР, то проектирование печатных плат (ПП) в нашей стране выполняется довольно давно, еще до появления соответствующих САПР. И именно при их разработке на отечественных предприятиях наблюдается отсутствие устоявшихся маршрутов проектирования с использованием САПР, начиная от применения нескольких программ для решения данной задачи и до отсутствия единого маршрута проектирования. Часто приходится видеть такую картину: схема сформирована в OrCAD (а бывает и хуже – в AutoCAD), а плата затем реализуется в P-CAD или PADs. На отечественных предприятиях задачи разработки схемы и проектирования ПП чаще всего выполняют разные специалисты и даже разные подразделения, которые к тому же могут быть разделены территориально. Все это приводит к тому, что каждый делает так, "как привык" или "как удобнее", при этом многие понимают, что такие методы неприемлемы, но практически никто не решается на изменение устоявшихся маршрутов проектирования.
Сегодня многие отечественные предприятия внедряют современные САПР (Altium Designer, пакеты Mentor или Cadence), но на многих из них процесс внедрения заканчивается покупкой лицензии на право использования этих программных средств. Зачастую разработчик, которому на рабочем месте устанавливают легальную копию программы, еще несколько лет по инерции работает так же, как и раньше (чаще всего в P-CAD). Сложность в основном заключается в том, что разработчики и конструкторы печатных плат не могут перейти на новые САПР без ранее созданных библиотек компонентов и подробного описания нового маршрута проектирования. Структура библиотечной базы данных (БД), порядок работы с ней, а также маршрут проектирования плат в САПР должны быть утверждены на уровне стандарта организации (СТО) и быть обязательными для исполнения всеми участниками процесса. В данной статье речь пойдет, наверное, о самой сложной части при внедрении САПР на крупных предприятиях – об организации БД и порядке работы с ней. Принципы организации БД будем рассматривать на примере САПР Altium Designer, хотя подобные методы могут быть применены и при внедрении других САПР ПП, с возможными незначительными вариациями.
При организации БД для САПР на предприятии возникает целый ряд вопросов: как организовать БД без остановки процесса проектирования, что должна содержать БД электрорадиоизделий (ЭРИ) и, самое главное, кто должен заниматься организацией БД ЭРИ? Ответ на последний вопрос очевиден, но при его реализации на многих предприятиях возникают административные трудности: библиотеки должны создаваться самими пользователями и затем проверяться администратором базы данных. Сложнее всего назначить того, кто будет исполнять обязанности администратора БД, так как ранее такой должности на многих предприятиях не существовало, но сейчас такой специалист необходим.
Теперь попробуем подробнее разобраться с порядком организации БД и о роли ее администратора в данном процессе. Обычно сквозной процесс проектирования печатных плат с использованием САПР в упрощенном виде выглядит так: разработка схемы (Э3), формирование технического задания на плату, проектирование печатной платы, разработка конструкции, оформление конструкторской (КД) и технологической документаций (рис.1). Чтобы маршрут проектирования представлял собой именно сквозной процесс, необходимо, чтобы данные, внесенные на первых этапах проектирования, дополнялись на последующих этапах и именно из них были получены итоговые данные как для производства (gerber, NC drill, placement), так и для документации (перечень элементов, спецификация и др.). Для этого компонент, используемый при создании схемы, должен содержать необходимый набор данных для всех последующих этапов проектирования: посадочное место для печатной платы, модели для моделирования, атрибуты для формирования текстовой документации и др.
Начиная создавать новый проект, разработчик должен использовать только компоненты из центральной БД (предположим, она уже имеется). В том случае, если в новом проекте появляются ЭРИ, которые ранее не использовались и отсутствуют в БД, предполагается применение библиотеки проекта, в которую разработчик добавляет недостающие компоненты. Для упрощения работы разработчика заранее должен быть проработан шаблон проекта, в котором имеются все необходимые документы, а также шаблон компонента в библиотеке проекта. Использование шаблонов исключает "человеческий фактор" при создании типового компонента базы данных и способствует повышению производительности при добавлении новых компонентов.
После того, как все недостающие компоненты добавлены в библиотеку проекта в виде соответствующих схемных символов, разработчик формирует заявку на внесение данного компонента в центральную БД. Заявка должна содержать минимальный набор сведений о компоненте: PartNumber – название компонента по каталогу поставщика, Footprint – название посадочного места по документации (datasheet) к компоненту и ID – уникальный номер компонента в БД предприятия для последующей синхронизации. Для удобства работы в заявке для компонентов могут быть указаны дополнительные параметры, например, Manufacturer – производитель, Part – функциональная группа компонента и др. Заявка утверждается начальником отдела и согласовывается с технологом и соответствующими службами, ответственными за применяемость и закупку ЭРИ, после чего она вместе с библиотекой проекта передается администратору БД. Администратор несет ответственность за пополнение центральной БД предприятия и за ее целостность, поэтому при обработке заявки он должен проверить созданные символы в библиотеке проекта, добавить к ним соответствующие посадочные места и сформировать карточку с атрибутами компонентов. При таком подходе к наполнению БД она будет содержать только используемые компоненты, утверждение которых происходит параллельно с процессом проектирования изделия.
Отдельно стоит сказать о карточке атрибутов компонента. Практически на каждом предприятии возникают долгие споры о ее необходимости и, позднее, о ее составе. Тут важно определить задачи, для решения которых создается данная карточка: во-первых, она используется для автоматического формирования текстовой части КД (перечень элементов, спецификация, ведомость покупных изделий и др.), во-вторых – для оптимизации поиска компонента по центральной БД предприятия. Для текстовой части КД каждому компоненту необходима всего одна запись, но так как в данной документации в соответствии с ЕСКД необходима сортировка записей по разным полям, компонент должен содержать все необходимые атрибуты, по которым выполняется сортировка. Например, в случае резистора, необходимо наличие атрибутов, определяющих его номинал, мощность, допуск и т.д., хотя это не свойственно иностранной номенклатуре, когда вся информация о компоненте представлена в виде единого кода (Part Number).
К моменту, когда проект с техническим заданием на проектирование печатной платы поступает к конструктору, в центральной БД уже должны быть добавлены те компоненты, которые в текущем проекте использовались из библиотеки проекта. Последний этап работы разработчика – синхронизация проекта с центральной БД, т.е. замена тех компонентов, которые использовались временно, на утвержденные по результатам заявки. Такая синхронизация позволяет передать более полную информацию об ЭРИ из центральной БД в проект, после чего можно начать работу над проектированием печатной платы, а также получить из проекта выходную документацию.
При описанном подходе к организации БД на предприятии наиболее важную роль играет администратор БД, который должен обладать знаниями во всех направлениях деятельности, сопутствующих полному маршруту проектирования. Администратор проверяет правильность создания компонента в соответствии с документацией, создает посадочное место и оформляет карточку компонента, поэтому именно он несет ответственность за полноту и своевременное обновление центральной БД.
Возможны некоторые изменения процедуры добавления компонентов в централизованную БД предприятия. Например, в некоторых случаях согласование компонентов происходит в процессе согласования проекта, и добавление новых компонентов, используемых в текущем проекте, в БД происходит по факту сдачи проекта в архив. В таком случае значимость администратора БД уменьшается, так как он уже не несет ответственности за содержимое БД, а отвечает лишь за своевременность ее пополнения.
Показанный на рис.1 маршрут проектирования печатных плат с некоторыми изменениями используется на многих предприятиях России, причем он не привязан к конкретной САПР.
Следующий важный вопрос – что из себя представляет центральная база данных? Конечно, в каждой САПР возможна организация библиотек в своем внутреннем формате, но более предпочтительной выглядит организация библиотек компонентов в виде реляционной БД. В самом простом случае такая БД будет содержать набор таблиц, в каждой из которых отдельная запись содержит всю информацию, относящуюся только к одному конкретному компоненту. Применительно к САПР такая база данных должна содержать информацию об условно-графическом отображении (УГО) компонента на схеме, топологическом посадочном месте (ТПМ) для платы и атрибутах, описанных выше (см. таблицу). Непосредственно УГО и ТПМ представлены в формате применяемой САПР и хранятся либо в некоторых библиотеках, либо в виде отдельных файлов.
Например, в программе Altium Designer возможно подключение к любой внешней БД с помощью создания специального файла DBLib. На рис.2 показан пример такой базы, в основе которой лежит файл в формате Excel. В этом случае каждая таблица (лист в Excel) содержит список компонентов и определяет используемые ими УГО, ТПМ, а также пользовательские атрибуты. Все файлы, ссылки на которые даются в БД, хранятся отдельно и организованы в виде файловой структуры (см.рис.2). Работа с такой БД возможна как через СУБД, так и через интерфейс САПР. На рис.3 показан порядок организации такой библиотеки в Altium Designer:
1. Создание файла DBLIB. Этот файл предназначен для взаимодействий графического редактора Altium Designer с внешней БД.
2. Подключение к внешней БД. Может быть выполнено путем выбора типа БД Excel или Access, а также указанием строки для подключения другой БД. После выбора БД необходимо выполнить подключение (кнопка Connected).
3. Добавление новой записи в БД. Выполняется через контекстное меню в разделе Table Browser (см. рис.3).
4. Определение атрибутов компонента в БД, через окно New Component. При этом предполагается, что УГО и ТПМ были ранее созданы в САПР и необходимо лишь определить их применяемость в том или ином компоненте.
Описанный процесс формирования БД в САПР Altium Designer выполняется вышеупомянутым администратором БД, при этом все составные части этой базы (или, по крайней мере, УГО) должны быть предоставлены автором заявки.
Основное преимущество организации библиотек ЭРИ на крупных предприятиях с помощью БД – возможность синхронизации с другими БД, например, с отделом комплектации. Обычно посредником между различными БД в рамках предприятия выступает PDM-система. В некоторых случаях база PDM является общей для всех структурных подразделений и создает единое информационное пространство, способное увязать между собой все этапы жизненного цикла изделия.
При использовании PDM-, PLM- и CAD-систем в общем процессе проектирования большую роль играет их взаимная интеграция. Обычно на отечественных предприятиях сначала внедряются САПР для решения прикладных задач проектирования, и только потом решается задача внедрения PDM- и PLM-систем. При этом вопрос об интеграции этих систем появляется только на последнем этапе, когда возможности для реализации этой интеграции минимальны, а работы по ее осуществлению становятся очень дороги. Для создания единого информационного пространства в рамках всего цикла проектирования, с использованием различных систем, наличие единой БД ЭРИ просто необходимо. В идеальном случае процесс наполнения БД ЭРИ должен начинаться с добавления компонента в PDM-систему, и только после этого он может быть использован в прикладной САПР, будь то Altium Designer на уровне проектирования ячейки или другая система на уровне проектирования блока (частью которого является ячейка).
В заключение хотелось бы отметить, что при внедрении САПР и организации БД ЭРИ на крупных предприятиях необходимо учитывать все аспекты организации единого цикла проектирования и производства, а не решать локальные прикладные задачи в САПР, как это происходит сейчас. Внедрение САПР, а тем более PDM- и PLM-систем – это долгосрочная стратегия развития предприятия, и от ее проработанности зависит успешность и эффективность процесса внедрения. Оно должно сопровождаться строгим планом, в котором описаны все бизнес-процессы, структура БД и порядок ее наполнения. По итогам процесса внедрения все пользователи должны иметь СТО и инструкции, подробно описывающие деятельность каждого исполнителя.
Литература
ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания, 1992.
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Техническое задание на создание автоматизированной системы, 1990.
Сабунин А.Е. Altium Designer. Новые решения в проектировании электронных устройств. – М.: Солон-Пресс, 2009.
Отзывы читателей
