Автоматизированная система оперативной регистрации технических изменений предприятия радиоэлектронной промышленности

Позаказное многономенклатурное производство радиоэлектронной аппаратуры предполагает проектирование, изготовление и конфигурацию компонентов изделия по требованиям заказчика [1]. Предприятия данного типа характеризуются высоким уровнем сложности производимых изделий, небольшими размерами производимых партий, длительными сроками выполнения заказов и высоким уровнем конфигурации изделия под требования заказчика. Процесс проектирования опытных образцов радиоэлектронной аппаратуры, таких как специализированные средства связи, навигации и комплексы автоматизированного управления, имеет сложную структуру внутренних процессов и отличается значительными сроками выполнения [2–4]. При этом необходимо оперативно отслеживать изменения, вносимые в конструкторскую документацию на изделие, которые увеличивают стоимость конечного изделия и сроки выпуска опытных образцов.

Управление жизненным циклом изделия в целом обеспечивается программными системами класса PLM (Product Lifecycle Management). Данные системы имеют достаточно широкий функционал, но основной их задачей является организация технического документооборота с обеспечением информационной целостности процесса создания, производства и сопровождения продукта [5–7]. PLM-системы различаются как по функциональным возможностям, так и по предоставляемым средствам интеграции в существующее информационное пространство предприятия. Ключевым компонентом PLM-систем являются системы управления данными об изделии (Product Data Management, PDM), обеспечивающие формирование и управление единой информационной базой конструкторской и технологической документации на изделие [8, 9].

Задача автоматизации управления данными об изделии наукоемкого предприятия может быть решения за счет внедрения PLM-систем [10]. При этом предполагается, что предприятие уже обладает соответствующей информационной инфраструктурой, позволяющей интегрировать комплексную PLM-систему, должны быть строго регламентированы процессы создания, внесения изменений, согласования и утверждения конструкторской документации. Также неизбежно возникает вопрос интеграции PLM-системы, существующих баз данных предприятия и используемых систем автоматизированного проектирования и подготовки производства [11].

Второй распространенный подход к решению задачи автоматизации управления данными предполагает разработку специализированного программного обеспечения для решения частных задач управления данными об изделии, не предполагающих формирование единого информационного пространства предприятия [12, 13]. Ключевыми недостатками данного подхода является формирование большого количество программных модулей и надстроек, решающих частные задачи управления производственным документооборотом, сложность синхронизации и интерпретации данных об изделии. И при всех преимуществах использования единых информационных PLM-систем в практике предприятий с существующей информационной инфраструктурой в основном используются программные модули и системы для решения отдельных задач автоматизации проектного документооборота.

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

Формальная модель процесса реализации технических изменений

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

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

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

В итоге исполнитель пункта изменений обязан довести данные корректирующие изменения до производства [14].

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

Рис. 1. Процесс реализации технических изменений в прямоугольной системе координат Fig. 1. Implementation process of technical changes in rectangular coordinate system

Процесс реализации технического изменения подразделен на следующие стадии:

• 1)    оформление соответствующего пункта журнала изменений (стадия «Оформление»);

• 2)    согласование изменения с необходимыми подразделениями (стадия «Согласование»);

• 3)    доработка изделия в соответствии с пунктом журнала изменений (стадия «Выполнение»);

• 4)    проверка изделия после доработки необходимыми подразделениями предприятия (стадия «Проверка»).

Стадии процесса реализации технического изменения представлены на рис. 1 в виде плоскостей. Площадь плоскости зависит от численности персонала, участвующего в той или иной стадии. Плоскость реализации изменений площадью ( l n е L ) • ( d n е D ) с этапами прохождения отдельных стадий φ можно представить как

( L ) • ( D )5( изменение КД ) ,

Аф = (ф 1 Ф 2 Фэ ^

при этом прохождение всех стадий реализации технического изменения в виде переходов между плоскостями площадью l • d можно представить как

^Ф  > N ( l n • d n )^^ H ( l n • d n )^^ VV ( l n • d n )^^ F ( l n • d n ) .

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

φ 1

φ 2

φ 3

φ 4

N ( l n , d n )

H ( l n , d n )

V ( l n , d n )

F ( l n , d n )

t 0                                t n

-----------1-------------1—► th                    tv                        tf

Рис. 2. Процесс реализации технических изменений в двумерной системе координат Fig. 2. Implementation process of technical changes in 2D coordinate system

Функциональная модель реализации электронного журналаоперативной регистрации изменений

Журнал оперативной регистрации (ЖОР) изменений – это ключевой документ, обеспечивающий оперативное доведение сведений о вносимых в конструкцию выпускаемых изделий внеплановых изменений до исполнителей, непосредственно отвечающих за производство изделия, и служб предприятия, ответственных за управление производством [15]. Использование электронного журнала оперативной регистрации изменений способствует снижению производственных издержек и росту производительности предприятия при производстве опытных образцов радиоэлектронной аппаратуры.

Согласно ГОСТ 2.503–2013, журнал изменений включает следующие графы (рис. 3):

• –    порядковый номер изменений, общий для всех производимых изменений в одном документе;

• –    дата записи в журнале;

• –    обозначение изменяемого документа;

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

• –    должности, фамилии, подписи соответствующих лиц, дата подписания;

• –    сведения о внесении изменений в подлинники и копии;

• –    дополнительные сведения о внесении изменений.

  

  Рис. 3. Общая форма журнала изменений по ГОСТ 2.503–2013

  Fig. 3. The general form of the change log in accordance with GOST 2.503–2013

  
  

Рассмотрим функциональную модель процесса создания и реализации пункта журнала оперативной регистрации изменений (рис. 4). Процесс создания ЖОР изменений инициируется входным сообщением о необходимости внесения изменений в конструкторскую документацию, которое может быть вызвано:

• –    ошибками в текущей версии конструкторской документации;

• –    несоответствием заявленных конструктивных решений технологическим требованиям производства;

• – модернизацией изделия и его компонентов.

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

Рис. 4. Функциональная модель процесса создания и реализации пункта журнала оперативной регистрации изменений

Fig. 4. Functional model of the process of creating and implementing an item in the log of operational registration of changes

Ниже представлена декомпозиция процессов «Согласование» (рис. 5) и «Выполнение пункта журнала» (рис. 6).

Рис. 5. Функциональная модель процесса «Согласование» Fig. 5. Functional model of the process “Agreement”

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

Рис. 6. Функциональная модель процесса «Выполнение пункта журнала» Fig. 6. Functional model of the process “Execution of log item”

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

На базе проведенного анализа и рассмотренной модели процессов реализации технических изменений разработана архитектура электронного журнала оперативной регистрации изменений, представленная на диаграмме вариантов использования (рис. 7), диаграмме классов (рис. 8) и диаграмме последовательности (рис. 9) нотации UML.

На диаграмме вариантов (см. рис. 7) использования показаны актеры – участники процесса формирования и реализации технических изменений, прецеденты данного процесса и их отношения друг к другу.

На диаграмме классов (см. рис. 8) представлены объекты системы и статические отношения между ними. Она включает следующие классы: пользователь (класс user), журнал оперативной регистрации изменений (класс magazine), классы модального окна управления электронным ЖОР изменений и реализации вносимых изменений (классы developers, technologist, QCD).

В классе user реализованы функции авторизации пользователя. В классе magazine представлены функции поиска по разделам журнала изменений и управления пользовательским интер- фейсом. Функции создания и согласования журнала оперативной регистрации изменений открывают одно из модульных окон классов developers – «Разработчики», technologist – «Инженер-технолог» и QCD – «Отдел контроля качества», в которых пользователь вводит необходимые данные и выполняет соответствующие операции.

Создать пункт ЖОР

«include»

Разработчик

«include»

Доведение до производства

«include»

Пункт журнала оперативной регистрации

Согласование с технологом

Исполнитель

Согласование с ОКК

Инженер-технолог

Представитель ОКК

Рис. 7. Диаграмма вариантов использования Fig. 7. Use Case Diagram

Рис. 8. Диаграмма классов

Fig. 8. Сlass diagram

Рис. 9. Диаграмма последовательности

Fig. 9. Sequence diagram

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

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

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

На АО «Научно-производственное предприятие «Радиосвязь» главное окно системы оперативной регистрации технических изменений конструкторской документации организовано в виде таблицы электронного журнала оперативной регистрации изменений со следующими столбцами (рис. 10):

– номер пункта журнала;

– отдел разработчика;

– обозначение документа;

– наименование изделия;

– дата создания изменения;

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

• –    нужный для доработки продукции цех и его участок;

  – содержание изменения;

• –    информация о производственном заделе;

  – исполнитель изменения;

• –    технолог, подписавший изменение;

• –    представитель технического контроля, согласовавший изменение;

• –    мастер участка, определенного для внесения изменений в изделие;

• –    срок внесения изменений;

  – примечание;

• –    извещение об изменении;

  – дата выпуска.

Рис. 10. Главное окно системы оперативной регистрации изменений конструкторской документации Fig. 10. Main window of the registration system changes in design documentation

Разработчик, убедившись в наличии проблем в конструкторской документации, создает пункт электронного журнала оперативной регистрации изменений (рис. 11).

Рис. 11. Окно создания пункта журнала оперативной регистрации изменений Fig. 11. Log item creation window

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

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

Рис. 12. Окно согласования технического изменения с инженером-технологом

Fig. 12. Technical Change Approval Window with a process engineer

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

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

Пункт Журнала 37824

Цек 15 Ум. 33, tie*

16УЧ.6

Отдел-

Исполнитель:

Lama создании

Сектор 6 5^0

26.852023

С5оз*а*«ение документе Изделие

№. 825 886f^ ?- 8-22-52 ГУ

Со держание изменения

Требуете» жраниробат» кабель

Служебная;

Принйтсе решение

Цех 15 дополмипел» но Оплетку на

Модель оплести

Л* !7   №.825 6 86-

проволокой

корпус разь ема Wf

ММС до разбетбления бьбадит». Не допускается

соприкосновение внешнего и внутреннего эсраноб

Lex >6 Кобел» Л*/7 направит» 5 иех *5 для доработки.

Технолог- ilex f6- Спклемитх кобел» от придороД холодей Г8 бинтоб M4J, демомпиробег?» из жгута (ссезот» 5 стяжек}, уложить 6 бухту передать на дорадотгу После дарадопки кобель проложит», закрепит^ подслснит» к приборам

Прилагаемой фСиЛ

Информация о заделе

доработать 20 комплектов (з»аз 207222}

Срож

Технолоз

Военной предстабипеле'

Мастер

ВТК

Приме мание-

Рис. 13. Форма представления технического изменения для внесения доработки в изделие Fig. 13. Technical change submission form to improve the product

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

Заключение

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