Описание корпоративной информационной системы: программного комплекса AVEVA PDMS

 

Коллизии  в работе

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

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

     Так же, имел место очень показательный прецедент. Две детали имеют в атрибутах одинаковые координаты. Но располагаются друг от друга на значительном расстоянии. Причём координаты узнавались двумя разными способами. При открытии специальной формы по перемещению объектов в ней обнаружилось, что координаты удалённой детали в два раза отличаются от первой, при перемещении в нужные координаты – детали совпали.

     Т.к. данный комплекс создавался на основании  командной строки, то и многие функции в ней работают ТОЛЬКО через командную строку. Функции не задокументированы и знают их лишь специалисты, которые разрабатывали данный комплекс и специалисты, имеющие большой опыт и стаж работы. Так, например восстановление базы данных, миграция в другую базу – такие важные и нужные функции – делаются только с помощью командной строки и специальных команд. Узнать информацию о том, в каком проекте мы находимся, откуда загружен можно только через командную строчку.

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

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

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

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

     При работе разных групп пользователей  возможны такие случаи, что один пользователь в своей базе пристыковывает свою деталь к детали другого пользователя в его базе. Так как база того пользователя оказывается только для чтения, то записать в неё пользователь не может, а нужно в свойствах детали прописать информацию о том, что она присоединена к такой-то детали. При таких манипуляциях создаются межбазовые макросы, которые должен выполнять администратор системы. В макросе прописывается информация для внесения в конкретную деталь. Информация прописывается в текстовой форме на внутреннем языке PML. Т.к. администратор имеет права на запись во все записи, то и межбазовые макросы должен выполнять только он и только тогда, когда пользователей в сети нет во избежание коллизий с применением изменений до сохранения новых.

 

Система условного кодирования

     Система кодирования зависит от типа элемента, которому назначается имя. Важно  определить, какие параметры включены в систему кодирования.

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

• стандарт/страна изготовитель;
• внутренний стандарт;
• тип;
• специальный тип;
• тип соединения;
• давление;
• исполнение.

 

     Как правило, в имена компонентов  каталога SCOM не включается кодирование  материала, из которого он изготовлен и толщина стенки, так как сам компонент SCOM не содержит описание материала (описание материала назначается как ссылка на этапе составления спецификации). С другой стороны компонент каталога SCOM представляет собой объемное представление детали, где важны только габаритные параметры (наружный диаметр и т.д.).

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

     Далее приведен пример кодирования компонента типа ELBOW (Отвод), выполненного с соответствии со стандартом ANSI, B16.9, крутоизогнутый, с концами под приварку.

     Имя этого компонента будет /AAEA200RR, далее приведена расшифровка каждой позиции в имени:

      

     A  –  American Standards

     A  –  ANSI B16.9 (Американский стандарт  B16.9)

     E  –  Elbow (Отвод)

     A  –  Long radius (радиус гиба 3 1.5 Номинальный диаметр)

     2  –  Bevel (Фаска), тип сварки – BUTT WELD (стыковая)

     0  –  Pressure Rating (Давление)

     0  –  Spare (Запасное поле, для специфических случаев)

     R  –  6” (150 mm) Arrive Bore

     R  –  6” (150 mm) Leave Bore

      

     Следующие таблицы приведены для объяснения выбора каждой позиции в коде имени, согласно параметрам компонента:

       
 

       

     

     Эти таблицы являются лишь выборкой полной Стандартной Системы Кодирования. Полная система кодирования в приложении 1.

 

Заключение

     При всех своих плюсах: ведение проекта  от начала и до выпуска документации в единой системе, возможность отображения  модели с разных ракурсов и полноценное  проектирование в 3D, существуют и огромные минусы и коллизии, которые описаны в работе. И это только маленькая часть огромного тома ошибок, которые могли бы быть задокументированы, при анализе работы программы тестировщиками.

     Хоть  комплекс развивается медленно и  верно с 1980 года, но выглядит очень  сыро. И главная проблема в том, что нет единой системы создания, каждый модуль разрабатывается и дорабатывается отдельно, иногда даже до смешного разными бывают команды и расположения панелей.

     Новомодное  проектирование в 3D накладывает определённые обязательства на проектные организации, выполняющие требования заказчиков. А требования бывают жёсткими и однозначными, например выпуск документации в изометрии со спецификацией, выполненные в программном комплексе AVEVA PDMS. И тут начинается: создание проекта, создание рабочих групп, баз, выкладывание в сеть, резервное копирование и прочее и прочее. Поэтому разработчикам необходимо еще приложить довольно много усилий, чтобы программа при работе не вызывала никаких нареканий и не создавала проблем специалистам, работающим в ней.

 

Список  используемых источников:

1. Система обучения пользователей работе с модулями программы (manuals) от компании Aveva;
2. Интернет портал Aveva.com.

 

     Приложение 1

     СИСТЕМА КОДИРОВАНИЯ