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

ИНН 7726601967 ОГРН 1087746953557

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

ИНН 5018019971 ОГРН 1035003357366

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

ИНН 7715938849 ОГРН 1127747049209

2 - 2003

Технология подготовки электронной эксплуатационной документации в системе TGBuilder

Андрей Петров, Илья Галин

Формирование требований к документации

   Схема кодирования МД

   Шаблоны типовых МД

   Шаблон структуры ЭЭД

   Словари терминов, сокращений, определений и используемых стандартов

   Библиотека элементов оформления документации

Формирование плана-проспекта и планирование работ

Создание модулей данных

   Формирование текстово-графических МД

   Формирование электронных каталогов

Сопровождение документации

   Ведение электронного архива извещений

   Проведение изменений в модулях данных

   Выгрузка обновлений

В прошлом номере журнала были изложены основные понятия и принципы разработки и сопровождения электронной эксплуатационной документации (ЭЭД). В данной статье рассказывается о TGBuilder версии 2.3 — системе подготовки ЭЭД, которая позволяет автоматизировать процесс создания ЭЭД.

В системе реализованы принципы и методики построения ЭЭД, изложенные в стандарте AECMA1000D, разработанном Европейской ассоциацией производителей аэрокосмической техники. Кратко обозначим его основные положения:

  1. ЭЭД — это техническая информация, представленная как совокупность так называемых модулей данных (МД), каждый из которых имеет статусную (идентификационную) и содержательную части.
  2. В ходе разработки документации создаваемые МД помещаются в общую базу данных (Common Source Data Base). При публикации документа из базы данных извлекается определенный набор МД, составляющих нужный документ в бумажной или электронной форме (Electronic Technical Publication).Такой документ в терминах указанного стандарта называют электронной публикацией. Комплект публикации составляет ЭЭД на изделие.

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

Формирование требований к документации

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

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

Схема кодирования МД

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

Правила кодирования МД регламентированы стандартом AECMA1000D, где определены вид и формат кода, то есть задана схема кодирования МД. Формализованное описание схемы кодирования соответственно должно содержаться в шаблоне документации. Рассмотрим пример формального описания схемы кодирования в системе TGBuilder.

Схема кодирования является шаблоном позиционного кода и может выглядеть, в частности, следующим образом: YYY-XX-XX, где: символ Y — буква или цифра, символ X — цифра, а символ «-» обозначает разделитель. Этот шаблон кода состоит из трех полей, отделенных друг от друга разделителями. Несколько полей кода и разделителей могут объединяться в сегмент кода. Схема кодирования МД может состоять из набора сегментов, разделителей и полей кода.

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

Использование стандартизованной схемы кодирования не является единственным требованием к ЭЭД — содержательная часть МД также оформляется в соответствии с используемыми стандартами. Требования к оформлению, включающие в свой состав правила верстки, форматирования текстовых данных МД и требования к содержанию МД, находят отражение в шаблонах типовых МД.

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

Шаблоны типовых МД

Шаблон типового МД является заранее размеченной формой (клише), так что создание модуля сводится к выбору и заполнению нужной формы. При этом автору МД не нужно заботиться о правильности верстки и форматирования, поскольку шаблон заранее подготовлен в соответствии с этими требованиями.

Разработка шаблонов происходит следующим образом: основываясь на требованиях стандартов, разрабатывается список типовых МД. Типы модулей данных по стандарту AECMA1000D даны в табл. 1.

Общие типы МД, представленные в этой таблице, можно разделить на определенные варианты и задать оформление для них. Например, модули типа «Описательная информация» могут иметь следующие варианты:

  • «Общие сведения»;
  • «Устройство и работа»;
  • «Технические характеристики».

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

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

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

Шаблон структуры ЭЭД

К ЭЭД предъявляются требования и по структуре в плане порядка глав, разделов и подразделов в публикациях, составляющих ЭЭД. Формализованное представление структуры эксплуатационной документации позволяет задать правила расположения отдельных разделов, подразделов, конкретных модулей данных. Автоматически применяя эти правила, автор электронной публикации формирует ее структуру.

На рис. 2 приведен пример шаблона структуры «Руководства по эксплуатации», построенного в соответствии с требованиями стандарта ГОСТ 2.601-95. «Руководство по эксплуатации» может состоять из семи разделов. В шаблоне заранее проставлены их названия, последовательность и правила использования. Например, раздел «Текущий ремонт» может отсутствовать в ЭЭД на конкретное изделие, если это изделие не ремонтируется. Это свойство раздела отражено в шаблоне структуры в виде модификатора .

В зависимости от правил использования при построении шаблона структуры применяются модификаторы, представленные в табл. 2.

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

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

Словари терминов, сокращений, определений и используемых стандартов

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

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

Библиотека элементов оформления документации

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

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

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

Формирование плана-проспекта и планирование работ

План-проспект является по своей сути оглавлением документации, в котором отражена структура ЭЭД на описываемое изделие. Создавая оглавление ЭЭД в соответствии с ранее разработанным шаблоном структуры и определяя все необходимые шаблоны типовых МД, автор получает план-проспект документации. Кодирование разделов и МД проводится по указанной в шаблоне схеме. Значения полей кода выбираются разработчиком из присоединенных к схеме справочников стандартных значений.

Разработка ЭЭД в системе TGBuilder может проводиться как в однопользовательском, так и в многопользовательском режиме. После формирования плана-проспекта руководитель проекта может раздать задания на подготовку частей ЭД группе авторов. В системе TGBuilder существуют механизмы постановки, контроля и управления таких заданий. Для удобства просмотра текущего состояния работ можно использовать встроенный редактор диаграмм Ганта. Кроме того, у руководителя проекта имеются инструменты для формирования различных отчетов по всей документации и по любому ее разделу. Например, руководитель может получить отчет о сроках проведения работ по подготовке выбранной главы или раздела. На рис. 3 приведен типичный пример плана-проспекта эксплуатационной документации в системе TGBuilder с описанными выше атрибутами.

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

Создание модулей данных

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

  • дата выпуска МД;
  • язык;
  • применяемость;
  • прочие.

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

  • текстовая и графическая информация;
  • электронные каталоги.

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

МД этих типов формируются средствами редакторов, встроенных в систему. Для каждого типа информации предусмотрен специальный редактор.

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

Формирование текстово-графических МД

Текстово-графические МД создаются в текстовом редакторе системы TGBuilder. Хотя по общим принципам работы и возможностям этот редактор аналогичен редактору MS Word, однако в нем есть ряд возможностей, существенно отличающих его от обычного текстового редактора. Основной особенностью является ориентация оформления содержания МД на два представления: электронное и печатное. Для всех объектов в модуле данных имеются специфические настройки, определяющие вид того или иного объекта при печати и на дисплее (рис. 4).

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

Простановка ссылок в редакторе не представляет никакой сложности. Поддерживаются внутренние (перекрестные) ссылки на элементы текущего МД и внешние ссылки на другие МД.

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

Интерактивные схемы с выносками позволяют оформлять различные чертежи и схемы. Для этих объектов средствами TGBuilder можно организовывать интерактивные выноски. Инструменты текстового редактора позволяют ссылаться из текста на конкретную позицию в чертеже, схеме и т.п. Пользователь документации, изучая чертеж, может получить информацию о том или ином элементе простым щелчком мыши на выноске. Исходными объектами для организации подобных схем могут быть многочисленные растровые форматы, а также чертежи в формате *.dxf, *.dwg (AutoDesk AutoCAD) и *.wmf (Windows Metafile).

Внедрение интерактивных трехмерных объектов преследует аналогичные цели, что и организация схем с выносками. Преимущество трехмерных моделей состоит в том, что их можно импортировать непосредственно из CAD-систем. TGBuilder поддерживает формат представления 3D-моделей IDASF, разработанный компанией Immersive Design. Этот формат хранит каркасную модель изделия и позволяет не передавать параметры модели (так как эти данные могут быть секретными), а также дает возможность сократить объем файлов модели. Для перевода моделей в формат IDASF существуют специальные программы-конверторы, которые распространяются либо как встроенные средства CAD-систем либо как отдельные программные пакеты.

По встроенным схемам с выносками и по данным из 3D-моделей можно автоматически получить спецификации с различными атрибутами и вставить их в содержание МД.

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

В публикации можно использовать три варианта отображения диаграмм:

  • список действий — текстовый список действий;
  • иллюстрация;
  • диалог «вопрос — ответ».

Представление диаграммы в виде диалога позволяет пользователю ЭЭД просматривать на дисплее описание последовательности действий в зависимости от выбранных ответов. При этом описание каждого действия может сопровождаться иллюстрацией, поясняющей процесс, и списком возможных переходов.

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

Формирование электронных каталогов

Как было сказано выше, электронный каталог по своей сути является таблицей и предназначен для хранения различных перечней объектов. В зависимости от того, какой тип перечней мы хотим хранить в таком представлении, меняется набор столбцов этой таблицы. Например, для хранения каталога деталей и сборочных единиц в таблице нужно предусмотреть следующие столбцы: «Наименование», «Обозначение», «Количество», «Масса», «Линейные размеры» и пр. Каждая деталь или сборочная единица в подобной таблице будет представлена строкой (записью, позицией) с соответствующими значениями в столбцах. Набор столбцов задается на стадии подготовки шаблона МД.

Наполнение электронных каталогов в системе TGBuilder может проводиться несколькими способами. Первый (традиционный) — ручное заполнение всех столбцов для каждой позиции каталога. В системе TGBuilder в столбцах электронного каталога могут быть:

  • строки;
  • многострочный текст;
  • списки значений и строк;
  • ссылки на модули данных;
  • ссылки на элементы 3D-моделей и схем с выносками;
  • списки ссылок;
  • файлы;
  • цифровые изображения.

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

В системе TGBuilder предусмотрен экспорт электронного каталога в формат MS Excel, который является самым распространенным форматом обмена электронными таблицами. Это позволяет использовать разработанные каталоги в распространенных офисных приложениях.

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

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

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

Сопровождение документации

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

  • получение и учет пришедшего извещения об изменении (ИИ);
  • анализ документации с целью выявления МД, подлежащих изменению;
  • проведение соответствующих изменений;
  • выгрузка обновлений ЭЭД на внешний носитель и передача изделия эксплуатанту.
В начало В начало

Ведение электронного архива извещений

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

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

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

Проведение изменений в модулях данных

Если изменения по какому-либо извещению затрагивают содержание МД, это служит причиной создания новой версии модуля данных. В поле «Причина выпуска новой версии МД» указывается обозначение соответствующего ИИ и формализованная причина изменений по ГОСТ.

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

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

Выгрузка обновлений

Система TGBuilder предоставляет возможность обновлений опубликованной документации. Создание таких обновлений не очень отличается от процесса публикации исходной документации. Как и при осуществлении публикации всей ЭЭД, в системе TGBuilder указываются параметры статусных частей МД: дата выпуска, версия и т.д. Указанные параметры влияют на состав набора МД, которые войдут в публикацию. Соответственно можно сформировать такой набор, который составлен из версий МД, созданных в определенный промежуток времени, например квартальных изменений.

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

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

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

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

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

ИНН 7751031421 ОГРН 5167746333838

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

ИНН 7726601967 ОГРН 1087746953557