Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО «ЛС-Технологии»

ИНН 7807258360 ОГРН 1227800102375

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

8 - 2003

Внедрение процесса управления программной документацией

в ФНПЦ РПКБ на основе PDM-системы PartY LT

Олег Гущин

Информационно-поисковые характеристики ПД в PDM

Реализация новых методов представления и управления программной документации

Структурирование информации и управление структурой

Управление качеством

Жизненный цикл программных документов

Выводы по результатам реализации информационной модели и управления графической структурой ПД

Реализация новой технологии управления ПД позволяет

Список документов, использованных при разработке технологии управления ПД

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

Общеизвестно, что 70-80% общих затрат на разработку и производство нового изделия приходится на процесс проектирования, далеко отстоящий от планирования производства и поставок. Технология электронного сопровождения программной документации обеспечивает управление разработкой изделий на ранних стадиях жизненного цикла и помогает ускорить выпуск товаров на рынок.

Технология предназначена для сокращения сроков проектирования авиационной техники в процессе управления программными документами (ПД) в составе изделий, для сравнения составов ПД различных изделий, работы с вариантами изделий и формирования разных спецификаций и ведомостей. Решение поставленной задачи проводилось на основе PDM-системы PartY LT российской фирмы «Лоция Софт».

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

В процессе внедрения новой технологии управления ПД изучался электронный документооборот конструкторской и организационно-распорядительной (офисной) документации на отечественных предприятиях ЧНППП «Элара», РПЗ, НПО «Модуль» и ОАО «Алмаз-Антей».

В ФНПЦ «Раменское приборостроительное конструкторское бюро» (ФНПЦ РПКБ) собственными силами организован электронный архив, на базе которого создана современная высокоэффективная технология хранения и использования электронных версий программных документов. Электронный архив программных документов — это качественно новый уровень использования документальной информации.

На первом этапе внедрения новой технологии в ФНПЦ РПКБ проводилась разработка нормативно-технической базы. На многих предприятиях выполнение работ такого рода по времени существенно отстает от процесса внедрения. Это обстоятельство заставляет предприятие некоторое время (иногда достаточно долго) использовать новые технологии без строгой регламентации, что не лучшим образом отражается на реализации процессов, особенно в части обмена данными между пользователями и системами. Из-за того, что разработка стандартов и нормативных материалов затягивается надолго (от года до нескольких лет), ко времени их выхода меняются технологии, то есть появляются новые поколения компьютеров и программных средств. Таким образом подобные стандарты устаревают уже к моменту их выхода в свет.

Достаточно высокий профессионализм и ответственность сотрудников предприятия, участвовавших в разработке по опережающему внедрению нормативно-технической документации (НТД) по электронному документообороту программной документации, позволили избежать такого хода событий. С июня 2001 года начал действовать электронный архив, и одновременно в службе программной документации были введены в эксплуатацию следующие стандарты предприятия:

• «Техническое задание на программное обеспечение. Построение, изложение, оформление и утверждение»;

• «Термины и определения»;

• «Спецификация. Построение, изложение, оформление и утверждение»;

• «Лист утверждения и титульный лист программных документов. Построение, изложение, оформление»;

• «Текст программы. Требования к содержанию, оформлению и утверждению»;

• «Ведомость держателей подлинников. Построение, изложение, оформление и утверждение»;

• «Программа и методика испытаний программ. Построение, изложение, оформление и утверждение»;

• «Описание программы. Требования к содержанию, оформлению и утверждению»;

• «Формуляр. Требования к содержанию, оформлению и утверждению»;

• «Конструкторская документация на программное обеспечение. Содержание, оформление и утверждение»;

• «Программные документы на электронных носителях данных. Порядок выполнения и обращения»;

• «Порядок разработки, правила оформления, изменения программной и конструкторской документации на программное обеспечение, выполненной на электронных носителях»;

• «Положение о прохождении программной документации».

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

Процесс формирования программного документа завершается в архиве службы программной документации. Таким образом, для используемых на предприятии ПД как объектов управления хранилищем и применения в изделиях уже на этапе их создания формируется система представления и управления информацией в виде графической структуры  — дерева связей проекта. Структура совокупности взаимосвязанных объектов хранилища удовлетворяет требованиям действующих в данной области отраслевых и STEP-стандартов.

Внедрена методология интеграции объектов хранилища структурированной части дерева связей проекта с любыми метаданными ПД — файлами.

Хранилище программных документов предприятия позволяет надежно, быстро и экономично осуществлять оптимальный выбор спецификации при взаимодействии с заказчиками для согласования характеристик готовых изделий уже на этапе проектирования. Таким образом, появилась возможность создания так называемых программно-конфигурируемых изделий, начиная с выработки технического задания (ТЗ) к проекту, то есть возможность интеграции требований и конфигурационных параметров данного ТЗ.

В начало В начало

Информационно-поисковые характеристики ПД в PDM

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

Каждый файл или каталог имеет имя, размер, дату, а также ряд других атрибутов (табл. 1 и 2).

Реализация проекта ПД осуществляется с помощью объектов пяти типов:

• проектный каталог;

• каталог программного документа;

• каталог конструкторской документации на программное обеспечение;

• каталог сетевой интеграции;

• файловый каталог.

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

Присвоение инвентарного номера объекту осуществляется по уровням графа.

По каждому атрибуту или комбинации атрибутов объектов можно организовать их поиск и классификацию в БД. Для всех объектов БД средствами администрирования формируются атрибуты, являющиеся информационно-поисковыми характеристиками (ИПХ).

В процессе создания архива ПД были сформированы следующие необходимые атрибуты для объектов типа «каталог» (см. табл. 1) и «файл» (см. табл. 2).

Данную настройку набора атрибутов можно легко модифицировать без программирования в соответствии с потребностями конкретного проекта и заказчика.

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

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

Работа проводилась в строгом соответствии с действующими стандартами серии ЕСПД и ЕСКД (см. врезку) и базовыми стандартами серии ГОСТ Р ИСО 10303, определяющими представление информации об изделии, стандартами электронного обмена и управления данными и стандартами на представление текстовой и графической информации:

• ГОСТ Р ИСО 10303-1-99. «Системы автоматизации производства и их интеграции. Представление данных об изделии и обмен этими данными». Часть 1. «Общие представления и основополагающие принципы»;

• ГОСТ Р ИСО 10303-11-2000. «Системы автоматизации производства и их интеграции. Представление данных об изделии и обмен этими данными». Часть 21. «Методы реализации. Кодирование открытым текстом структуры обмена»;

• ГОСТ Р ИСО 10303-22-2001. «Системы автоматизации производства и их интеграции. Представление данных об изделии и обмен этими данными». Часть 22. «Методы реализации. Стандартный интерфейс доступа к данным»;

• ГОСТ Р ИСО 10303-41-99. «Системы автоматизации производства и их интеграции. Представление данных об изделии и обмен этими данными». Часть 41. «Интегрированные обобщенные ресурсы. Основы описания и поддержки изделий».

• РС Р 50.1.027-2001. «Информационные технологии поддержки жизненного цикла продукции. Автоматизированный обмен технической информацией. Основные положения и общие требования».

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

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

Конечная цель использования новой технологии — решение конкретных практических задач предприятия, а именно:

• выполнение требований заказчика по учету, хранению и обращению программной документации;

• поддержка проектирования и подготовки производства приборов авиационной техники (анализ состава, анализ требований, проектирование спецификаций требований и быстрое моделирование) в соответствии с регламентирующими стандартами представления данных об изделии и его компонентах (ИСО 10303 и ИСО 15384);

• организация информационной поддержки ПД на протяжении всего ЖЦ документов.

В начало В начало

Реализация новых методов представления и управления программной документации

При формировании документов в графической структуре дерева связей объектов используется файловая система Каталог/подкаталог/файл.

Весь набор объектов БД связывается определенными отношениями в логически структурированное представление данных внутри БД. Логическая структуризация данных внутри БД позволяет идентифицировать каждый объект и выполнять над ним требуемые действия. Данная совокупность называется внутренним представлением информационной модели БД. Каждая PDM-система имеет свою форму внутреннего представления.

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

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

В соответствии с действующими стандартами, в том числе и со стандартами предприятия, программная документация принимается и формируется в хранилище комплектно. Комплектный ПД состоит из главного документа и совокупности подчиненных документов, характеризующихся единым целевым назначением и логически связанных друг с другом. Главный ПД (каталог) включает единую для всех подчиненных программных документов реквизитную часть, содержащую атрибуты ПД в целом, и общую содержательную часть. Каждый подчиненный ПД обязательно имеет собственную реквизитную и содержательную части.

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

Содержательная часть подчиненного ПД состоит исключительно из объектов типа «файловый». Номенклатура документов в комплекте определяется следующим набором: каталог — главный ПД (имеющий децимальный номер, входящий в атрибуты «описание» и «обозначение») и совокупности подчиненных ПД — подкаталогов (Txt — текст, Spc — спецификация, Ops — описание, Mtd — методика, Vdp — ведомость держателей подлинников и Frm — формуляр), имеющих единое предназначение и логически связанных друг с другом. Между содержательными частями комплектного ПД информационная связь отсутствует.

Кроме того, реализована и так называемая макетная часть в виде подкаталога, начинающегося с аббревиатуры АСС, в котором находятся два объекта типа «файловый»: etic и mnz (этикетка и ведомость электронного носителя).

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

• проектного каталога (Архив_ПД);

• каталога сетевой интеграции (00001_NEXT_PC; рис. 2);

• каталога программной документации (например, 0082_КМИВ00279.03);

• файлового каталога (например, spc_00279_03.doc), находящегося в подкаталоге Spc главного ПД с именем 0082_КМИВ00279.03 (рис. 3);

• каталога конструкторской документации на программное обеспечение (например, 0234-1_Km.466225.006-09, 0234-2_Km.466225.006- 09, 0235_Km.466225.006-08, 0236_Km. 466225.006-07; рис. 4).

PartY LT позволяет управлять информацией на одном компьютере с совмещением функций оператора и администратора. Исходя из требований информационной безопасности предприятия вся оперативная информация БД, содержащая программную документацию, должна располагаться на жестких дисках двух компьютеров. При необходимости любой файл, являющийся как бы зеркальным отображением подлинника на первом компьютере, может быть считан со второго компьютера. С этой целью был создан каталог сетевой интеграции 00001_NEXT_PC (рис. 2).

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

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

В начало В начало

Структурирование информации и управление структурой

Для проектирования логической структуры базы данных первоначально определяются информационные потоки, а затем формируется методология, основанная на трактовке данных в контексте их взаимосвязи с другими данными, принципами электронного обмена и управления данными. Основными конструкциями графической модели являются объекты, отношения и атрибуты. Графическая модель данных изображается совокупностью блоков, линий, соединяющих блоки, и имен атрибутов внутри блоков. Фрагменты древовидной структуры БД представлены на рис. 2, 3 и 4. К середине 2003 года БД содержала более 2000 объектов, и ее объем постоянно увеличивается.

Инженерно-техническому персоналу, имеющему доступ к программной документации, находящейся в хранилище, необходимо управлять занесением информации, поиском, внешним и внутренним представлением, модификацией, обменом, хранением, изготовлением копий, удалением и формированием подборок объектов. Для редактирования графической структуры можно использовать как меню, так и метод drag-and-drop. Пользователь, несущий ответственность за принятие окончательного решения, может добавить в свою или чужую подборку любую версию программного документа и посмотреть, как проведенное изменение повлияет на функциональность всей подборки, что позволит принять правильное техническое решение.

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

Методика полнофункционального управления данной графической структурой на основе PartY LT изложена в специальной инструкции для пользователя, созданной в службе программной документации предприятия.

В начало В начало

Управление качеством

Обеспечение требуемого качества информации является одной из целей реализации концепции CALS, поэтому управление качеством (в терминах стандартов серии ИСО 9000:2000) следует отнести к базовым технологиям управления. Управление качеством в данном хранилище ПД предприятия следует понимать как контроль управления информацией на соответствие требованиям, обеспечивающий качество вводимой информации. Данная цель достигается гибким использованием бизнес-правил контроля действий PartY.

После выполнения пользователем одного из разрешенных действий система производит выборку соответствующих правил и выполняет их проверку. Если они «истинны» (выполняются), то результаты выполняемого действия заносятся в БД. Применение этих бизнес-правил значительно сокращает число ошибок. Настройки правил контроля действий остаются невидимыми для пользователя.

В начало В начало

Жизненный цикл программных документов

Сегодня иностранные заказчики отечественной военно-технической продукции выдвигают требования, удовлетворить которые невозможно без внедрения ИПИ (CALS)-технологий.

Под жизненным циклом документа в электронной форме понимается все время жизни под управлением системы — от момента создания или импорта электронного документа до его экспорта или уничтожения. ЖЦ программного документа состоит из следующих этапов:

• разработки версии ПД;

• создания версии ПД;

• согласования и утверждения версии ПД;

• выпуска версии;

• обращения версии ПД;

• внесения изменений в ПД (смена версии);

• изъятия из обращения версии ПД;

• аннулирования версии ПД.

Для описания жизненного цикла ПД в системе предусмотрен простой и эффективный механизм, который заключается в следующем: жизненный цикл состоит из этапов в соответствии со специфическими требованиями предприятия, а полученные этапы «насыщаются» шаблонами, соответствующими последовательности выполнения работ на каждом из этапов (файлы izm, mnz, etic). В результате обычный пользователь просто и эффективно решает задачи составления жизненных циклов, с помощью графического интерфейса — интуитивно понятного механизма заполнения шаблонов в виде таблиц.

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

На современном этапе освоения информационных технологий необходимо создание отдельных технологических цепочек. Как показала практика, новая технология управления ПД, реализованная в ФНПЦ РПКБ, — создание полнофункционального электронного архива и формирование БД программной документации — оказалась весьма эффективной.

В начало В начало

Выводы по результатам реализации информационной модели и управления графической структурой ПД

1. Модель построена в строгом соответствии с действующими стандартами, а также с общими концепциями CALS-технологий.

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

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

В начало В начало

Реализация новой технологии управления ПД позволяет

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

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

3. Повысить качество изделий.

4. Увеличить скорость обмена информацией и повысить степень актуальности, полноты и доступности информации об изделии.

5. Улучшить взаимодействие производителей и заказчиков.

6. Тиражировать технологию управления ПД заинтересованным организациям.

В начало В начало

«САПР и графика» 8'2003

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО «НТЦ ГеММа»

ИНН 5040141790 ОГРН 1165040053584