- PVSM.RU - https://www.pvsm.ru -
Не секрет что для успешного внедрения любой системы документооборота необходимо произвести несколько логичных шагов, в данном посте я опущу этапы исследования, начну с пилотного проекта. И постараюсь описать проблемы и способы решения оных, которые с уверенностью в 90% существуют на любом пост-советском «кондовом» предприятии.
По результатам этапов были выявлены существующие проблемы на предприятии, связанные с ведением документации:
c) Существующая в системе Search база стандартных изделий чрезмерно избыточна и не соответствует (используются полные Гостовские наименования и параметры, на предприятии приняты наименования из отраслевых ограничительных списков), а так же в ней не хватает некоторых отраслевых элементов из прочих изделия (розетки, разъемы, втулки), насчитывающие тысячи элементов.
d) Не используется библиотека «Материалы». Соответствующая графа заполняется вручную, а так же используются материалы, не существующие в текущих ГОСТах (нить суровая, вместо нить крученая капроновая 3К ОСТ-17-330-84)
8) Не существует единой системы разработки печатные платы и схем. Разработка выполняется в совершенно разных системах проектирования: cheemage, p-cad, orcad, visio, altium designer.
9) В проектах, созданных в системе P-cad не заполнены элементарные, но необходимые атрибуты оформления (разработал… наименование, обозначение), эти параметры нанесены на лист текстом, основная надпись выполнена рисунком. Дополнительно необходимо заполнять design attributes, в меню file.
10) Система Search является параметрической системой, поэтому необходимо соблюдать правила заполнения атрибутов элементов, внесения на схему или печатную плату. Т.е. необходимо заполнять главные атрибуты элементов, из которых формируется полная запись в перечне элементов и спецификации, т.е.: наименование, тип, номинал, допуск, позиционное обозначение. Либо создать отдельный атрибут, например ПЭ3, в котором должно быть прописано полное наименование элемента. Во всех файлах, участвовавших в пилотном проекте «****» существовали следующие ошибки:
a) Атрибуты элементов на схеме (файлы *.sch) и печатной плате(*.pcb) и не заполнены
b) Атрибуты заполнены не полностью, например, проставлено только наименование «конденсатор», без номинала и остальных параметров.
c) Атрибуты от элемента к элементу различаются по составу и наименованию, например: для конденсатора С1 атрибут «description» содержит наименование, а для конденсатора С65 этому атрибуту соответствует поле «name».
d) Проблемы с качественным наполнением этих атрибутов:
i) Номинал указывается не по ГОСТу
ii) Номинал одинаковых элементов с разными обозначениями (мк и мкФ)
iii) Обозначение заполняется не полностью.
11) В ходе подготовки документов к загрузке выяснилось, что перечень элементов создается в отдельной программе – TDD, в которой неполные наименования, полученные из атрибутов системы P-CAD дополняются вручную пользователем. На основе исправленного файла формируется перечень элементов, который сдается в архив конструкторской документации в печатном виде. Утилита TDD позволяет пересохранять перечень элементов обратно, в файл проекта p-cad, чем самым приводя его к идеологически правильной форме, но этого не делается. Этот файл сохраняется рядом с файлами проектов.
12) Из п.10 вытекает новая проблема: при корректировке сданного в ОТД комплекта документов не исправляется файл TDD, следовательно не вносятся корректировки, а перечень элементов правится вручную.
13) На схемах разъемы обозначены как контактная площадка, а не групповой элемент или элемент из библиотеки, что порождает за собой массу элементов типа Х1… Хn в автоматически сгенерированном перечне элементов.
14) Имена файлов и наименования имеют «код», Search построен таким образом, что транслирует код в исполнение.
15) Altium Designer не имеет интегратора к системе Search, т.к. не существует открытого API. В подразделении 2070 совместно с разработчиками НТЦ-4. Ведется разработка обработки, позволяющей перегрузить данные в PDM систему.
16) Не существует единой библиотеки элементов систем разработки печатных плат.
17) Сданные в архив документы, не имеют электронных версий, либо поиск электронных версий затруднителен. Рабочие копии документации хранятся не структурированно, собрать все файлы по минимальной ячейке изделия – блоку не представляется возможным.
Иными словами, на данном этапе система находится на первом, практически на переходном 2 этапе из 3 возможных этапов внедрения:
1. Интеграция на уровне файлов. Подразумевает простейшие операции с данными: сохранить файл в PDM, открыть файл из-под ПДМ. В классификации систем автоматизации это даже не интеграция, а базовый функционал. При таком подходе PDM система заполняет свойства файла некоторой информацией из своих атрибутов, например: наименование документа, обозначение, разработчик, масса. Либо во внешней программе в стандартном интерфейсе используется появится кнопка- «сохранить в PDM», по нажатию на которую, открывает интерфейс PDM системы и у пользователя появляется возможность, в соответствии с правами его доступа и ролью в делопроизводстве, заполнить атрибуты карточки и поместить файл в каталог, соответствующий каталогу, текущей разработке.
2. Интеграция на уровне атрибутов. Под такой интеграцией понимается подход, при котором PDM система считывает атрибуты, находящиеся в файлах документов САПР систем. Разработчик в САПР имеет возможность создавать и заполнять любые согласованные с PDM системой атрибуты в своей модели / чертеже. Эти атрибуты располагаются в системной (отрытой области) файла и PDM система может их прочитать, создать внутри себя объекты и автоматически заполнить свои атрибуты. В этих атрибутах может содержаться как информация, относящаяся к основному штампу так и информация о применяемости, технологических замечаниях, материале детали, весе, и именах внешних ссылок ассоциированных файлов.
Пример: при загрузке в PDM систему 3D модели детали (набора файлов), система:
— обновит обозначение объекта-документа,
— заполнит атрибуты -наименование, разработал и.т.п,
— создаст объект – материал(или укажет на соответствие материала в БД) и укажет его обозначение/наименование если он был назначен на модель,
— заполнит атрибут объекта «деталь» значением атрибута «масса»
— сохранит файл и заполнит атрибуты «дата последнего изменения» и т.п.
3) Чтение электронной структуры изделия (ЭСИ). Иными словами полная интеграция PDM системы в различные САПР. Под таким подходом понимают получение состава, при этом подходе избегается ручной ввод объектов и заполнения атрибутов. ЭСИ содержится в 3D моделях сборки и в документе «спецификация», которые в свою очередь собираются из БД PDM системы, а спецификация напрямую связана с файлами документов.
Т.е. при загрузке документации PDM система читает ЭСИ (системные области файлов, созданных в САПР, где находится ссылки на документы, участвующие в сборке) после чего:
— создается иерархическую структуру изделия с имеющимися количествами деталей, стандартных и покупных изделий.
— далее по хранимым внутри файла ссылкам рекурсивно, для каждого элемента сборки:
-определяется тип объекта (деталь, сборочная единица, библиотечный элемент -крепеж),
-создается обозначение;
-заполняются атрибуты объекта;
-создаются объекты – «документы — 3Д модель детали», задается обозначение
— заполняются атрибуты документа
— сохраняется файл
Если обозначение входящего в сборку объекта системе известно (примененный), то система автоматически создаст ссылку «применяемость» и дополнит существующее дерево состава отсутствующими элементами из БД.
За плохое форматирование — отдельно прошу прощения, в следующем посте исправлюсь.
Автор: netzgiest
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/30973
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/175035/
Нажмите здесь для печати.