При эксплуатации сложных технических изделий (кораблей, самолетов) существует потребность в актуальных данных по техническим и эксплуатационным характеристикам изделия на протяжении всего жизненного цикла. В настоящее время накопление, хранение и предоставление этих данных возлагается на систему управления жизненным циклом (Product Lifecycle Management – PLM), содержащую цифровую модель изделия. Системы PLM развертываются на специализированных стационарных вычислительных средствах и предоставляют on-line доступ к данным. Доступ к данным в режиме off-line призван удовлетворить автономный формуляр изделия.

Концепция автономного формуляра основана на буферизации данных об изделии и оперативном предоставлении их потребителям, в том числе автоматизированным системам и персоналу организации – эксплуатанта изделия. В отличие от электронного формуляра по ГОСТ 2.612-2011 автономный формуляр содержит только те данные, которые нужны при эксплуатации изделия. Мобильный электронный формуляр, анонсированный в http://www.cnews.ru/news/line/index.shtml?2013/04/09/525249, отчасти также является автономным формуляром.

В соответствии со своим назначением автономный формуляр имеет следующие режимы работы:

– загрузка данных из системы PLM;

– автономная работа, в том числе ведение данных по актуальным техническим и эксплуатационным характеристикам изделия;

– синхронизация данных с системой PLM.

Формуляр может быть сопряжен с бортовыми системами управления и регистрации изделия.

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

– статическую часть – совокупность данных по компонентам изделий, их структуре, связям и характеристикам;

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

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

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

При взаимодействии формуляра с PLM данные для загрузки и обновления БД формируются в виде XML-документов (сообщений). Структура этих документов определяется информационной моделью обмена данными (ИМОД) и включает элементы, представленные на рисунке 2.

Данные содержат

– паспорт сообщения (идентификатор, время формирования, содержание, отправитель и получатель сообщения);

– информацию о характеристиках изделия и его оборудования, классификатор компонентов изделия;

– нормативно-справочную информацию, необходимую для развертывания и последующего обновления БД.

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

Для проверки изложенных решений был разработан программный макет автономного формуляра для взаимодействия с PLM на базе ENOVIA V6. Макет реализован в кроссплатформенном варианте (Windows, Linux) с использованием программных средств с открытыми исходными текстами: СУБД Postgresql, исполнительной подсистемы Java, встраиваемой СУБД Oracle Berkeley DB XML.

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