CC BY
33
СТАНДАРТИЗАЦИЯ И УПРАВЛЕНИЕ КА ЧЕСТВОМ ПРОДУКЦИИ
УДК 658.562
ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ СИСТЕМЫ ИНФОРМАЦИОННОЙ ПОДДЕРЖКИ КАЧЕСТВА ПРОДУКЦИИ ОБОРОННОГО ПРЕДПРИЯТИЯ
В.Б. Афанасьев
В статье обоснованы технические решения построения системы управления базы данных, выбор программных решений для автоматизированной информационной системы в целях обеспечения результативности системы менеджмента качества оборонного предприятия. Для оборонных предприятий представлен инновационный программный продукт на основе нереляционных NoSQL разработок.
Ключевые слова: информационная система, СУБД, качество, надёжность, информационная среда СМК.
Результативность действующей в настоящий момент системы менеджмента качества (СМК) на наукоёмких машиностроительных и приборостроительных предприятиях оборонно-промышленного комплекса (ОПК) России определяются множеством факторов, важнейшим из которых является фактор информационного обеспечения. Внедрение информационных систем на предприятиях ОПК связано с многочисленными трудностями, обусловленными, в частности, низким уровнем инновационной активности отечественных организаций, вымыванием научного потенциала в период либерализации экономики, а также типичным, для возрастного контингента работников, отрицанием необходимости каких-либо перемен для традиционных методов работы и управления производством. Одновременно с этим объединение на современном этапе предприятий ОПК в вертикально интегрированные структуры (ВИС) Концерны, позволяющее осуществлять централизацию управления, в том числе в системе обеспечения качества и надёжности, ставит новую задачу формирования и обслуживания дополнительных информационных потоков в рамках ВИС.
Таким образом, для решения проблем с качеством ОП в первую очередь необходимо обеспечить применение инновационных технологий в сфере информационной поддержки изделий (ИПИ) на этапах жизненного цикла (ЖЦ), а также построение информационных систем поддержки принятия решений для системы СМК и автоматизированных систем управления предприятиям.
Суть концепции ИПИ, получившей в США название CALS (Continuous Acquisition and Life cycle Support - непрерывная информационная поддержка поставок и жизненного цикла), состоит в применении информационных принципов и технологий в интегрированной информационной среде (ИИС) предприятия или группы предприятий в целях обеспечения управления процессами и взаимодействия всех участников ЖЦ выпускаемой продукции. ИИС - основа, ядро CALS - представляет собой распределенное хранилище данных, существующее в сетевой компьютерной системе, охватывающей (в идеале) все службы и подразделения предприятия, связанные с процессами ЖЦ изделий.
В соответствии с концепцией CALS управление проектно-конструкторскими данными на предприятии в том числе информационными потоками, информационным обеспечением СМК в части качества и надежности продукции и технологических систем на передовых зарубежных предприятиях осуществляется PDM-системой (Product Data Management — управление данными об изделии), являющимся прикладным программным средством.
В настоящее время по оценкам специалистов насчитывается несколько сотен прикладных специализированных программных средств, как зарубежной, так и отечественной разработки, предназначенных для управления данными о выпускаемой продукции [1]. Готовые программные продукты характеризуются различными свойствами и возможностями, отражающими специфику технологических процессов и выпускаемой продукции, в интересах которых эти автоматизированные информационные системы (АИС) разрабатывались. Соответственно с этим в реальных условиях информационно-технологического отставания отечественного ОПК возникают проблемы выбора и обоснования возможных решений по внедрению PDM-системы. За последнее время в ряде научных работ предложены методики выбора PDM-системы из числа готовых специализированных решений в том числе и для предприятий ОПК. Однако в большинстве случаев предложенные методики носят общий не системный характер с использованием ограниченного количества критериев [1, 2] или предлагается формировать иерархическую структуру исходных данных для анализа альтернативных проектов (PDM-систем) и предъявляемых к ним требований [3]. Последнее требует глубокого изучения огромного количества альтернативных АИС, а также тщательной формализации элементов ЖЦ выпускаемой продукции и производственных процессов, что в условии отсутствия подготовленных специалистов становится невозможным или очень затратным.
Одновременно с проблемами выбора готовых специализированных программных продуктов следует учитывать факт опережающего развития базовых программно-информационных решений, появление новых инновационных программных технологий в том числе и в построении БД и СУБД. Это обстоятельство позволяет искать пути создания новых АИС для предприятий путем внедрения инновационных программных продуктов.
Опыт отечественных предприятий ВИС ОПК по внедрению готовых информационных продуктов с возможным реинжинирингом или организации разработки новых прикладных программных средств демонстрирует практическое отсутствие единых стандартов, рекомендаций, а также аналитической базы и системного подхода к выбору оптимального решения. Внедренная в таких условиях РБМ-система обычно не приносит требуемого экономического эффекта, а устранение ошибок, допущенных при ее внедрении, влечет немалые финансовые и временные затраты. Таким образом практика показывает, что в настоящее время комплексная задача разработки, выбора и внедрения РБМ-системы на предприятиях ВИС ОПК остаётся не решённой. При этом эта проблема недостаточно раскрыта как в действующих стандартах, так и в научной литературе. Синтезу, выбору технических решений при построении АИС в интересах СМК предприятий ВИС ОПК посвящена данная работа.
Решение задачи по информационному сопровождению системы управления качеством и надёжностью предприятий ВИС ОПК требует разработки АИС, обеспечивающей накопление и оперативный доступ к статистической информации, в том числе в ряде сложных случаев к параметрическим данным проверок и испытаний, по всем выпускаемым изделиям и их комплектующим компонентам за длительный (несколько месяцев и даже лет) периоды разработки, производства и эксплуатации, а также эффективную обработку разнородной информации с элементами машинного обучения. В этой связи фундаментом построения АИС в интересах СМК предприятия должна являться высокоэффективная система управления баз данных (СУБД), обеспечивающая решение широкого спектра вопросов.
С точки зрения системного подхода задача проектирования СУБД состоит в определении ее структурно-функциональной организации (СФО). В составе СФО СУБД присутствуют следующие основные компоненты:
архитектура организации и построения СУБД, как программного комплекса;
схема данных, т.е., архитектура набора структурных связей классов данных (массивов в нереляционной модели и таблиц в реляционной модели);
программная реализация СУБД.
Соответственно основные компоненты, а также СФО СУБД в целом применительно к рассматриваемому проекту разработки АИС предприятия должны отвечать следующим требованиям:
Во-первых, при разработке АИС предприятия обязательно должны учитываться особенности производства и эксплуатации продукции предприятий ОПК, а также характер самой информации при выборе способов организации интеграции и первичной обработки статистической информации о качестве и надёжности изделий на различных этапах ЖЦ.
Во-вторых, необходимо обеспечить хранение всей информации по результатам ЖЦ продукции, поступающей за длительный промежуток времени.
В-третьих, должен быть реализован оперативный доступ к данным для анализа и обработки статистической информации в целях выработки мероприятий и управленческих решений по обеспечению качества продукции и технологических процессов, в том числе с использованием методов машинного обучения.
В-четвёртых, проблемы внедрения всеобщего менеджмента качества (TQM) в ВИС ОПК безусловно выразятся в необходимости обработки больших объёмов неструктурированной, нечёткой, развивающейся информации поэтому организация базы данных (БД) АИС должна обеспечивать наращивание информационного потенциала без дорогостоящего реинжиниринга БД в процессе развития проектов по обеспечению качества.
Поэтому, на начальном этапе при проектировании АИС крайне важно решение задачи обоснования СФО СУБД, обеспечивающей реализацию вышеуказанных требований, при этом одним из наиболее важных моментов является управление доступом, хранением и использованием информации. Функциональная и эффективная работа современных средств автоматизации невозможна без специализированных средств хранения и обработки информации. С увеличением объемов информации и сложности производимых вычислений возрастают требования к СУБД, которые являются ядром современных АИС с точки зрения обеспечения доступа к данным. Достаточная производительность СУБД при сохранении функциональности и надежности позволяет обеспечить необходимый уровень гибкости и удобства доступа к данным.
Следует отметить, что БД представляют собой совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных [4]. БД и СУБД характеризуется следующими основными параметрами:
скорость доступа к данным на чтение и запись; отказоустойчивость; удобство доступа к данным; масштабируемость.
При работе БД доступ к хранимой информации, так или иначе, получают все приложения в АИС: источники информации, расчетные модули, средства визуализации и т.д. Интенсивность и характер взаимодействия приложений с СУБД различны и определяются функциональностью приложений и спецификой хранимых данных. БД является централизующим звеном в работе любой АИС с функциями поддержки принятия решения. От характеристик её работы, от удобства доступа к данным зависит работа всего комплекса, т.е., при большом количестве обращений к БД, именно она может быть узким местом комплекса с точки зрения производительности. Эффективность работы СУБД и БД зависит от используемых программных средств, осуществляющих доступ к данным, модели данных и производительности используемого оборудования.
На настоящий момент существует большое количество систем управления хранением данных, удовлетворяющих различным запросам. Проектирование БД и СУБД - динамично развивающаяся область создания программного обеспечения, причём различие задач порождает разнообразные по характеристикам и целям применения решения по организации хранилищ данных [5, 6]. Необходимо при этом отметить, что закрытые код и архитектура коммерческих БД не позволяют рассматривать их в качестве средства управления хранением данных для АИС предприятий ОПК. В любом случае, не зависимо от выбора между новой разработкой БД и готовым продуктом возникает вопрос - какая технология из существующих на настоящий момент предпочтительней? Ответ на этот вопрос зависит от особенностей проекта, целей и задач, которые планируется достичь и решить соответственно. В рассматриваемом случае перечень задач по построению ИИС СМК, а также ряд особенностей информационных потоков предприятий ВИС ОПК описан в [7].
Не ставя в данной работе целью проведения детальных сравнительных оценок существующих программных решений в построении АИС, постараемся сформировать основные положения, позволяющие выработать правильные стратегические решения в масштабах предприятия ВИС ОПК для обеспечения быстрого информационного развития. Это позволит минимизировать проблемы реинжиниринга из-за возможных ошибок в описании моделируемых процессов и расширения диапазонов решаемых задач в СМК (TQM).
В мире технологий БД существует два основных сложившихся на настоящий момент направления: SQL и NoSQL, реляционные и нереляционные базы данных. Различия между ними определяются принципами декомпозиции сложной системы, а именно структурный и объектно-ориентированный [8], и заключаются в том, как они спроектированы, какие типы данных поддерживают, как хранят информацию. Реляционные БД хранят структурированные данные, сгруппированные в таблицах, формат которых задан на этапе проектирования виртуального хранилища. Нереляционные БД устроены иначе. Например, документно-ориентированные базы хранят информацию в виде иерархических структур данных. Речь может идти об объектах с произвольным набором атрибутов. То, что в реляционной БД будет разбито на несколько взаимосвязанных таблиц, в нереляционной может храниться в виде целостной сущности.
Внутреннее устройство различных систем управления базами данных влияет на особенности работы с ними. Например, нереляционные базы лучше поддаются масштабированию. Здесь следует также отметить, что некоторые реляционные СУБД поддерживают ряд технологий объектно-ориентированного подхода, например, наследование.
Область применения проектируемой системы также выдвигает ряд требований к используемым архитектурным и программным решениям, определяющих в конечном итоге логику построения АИС. Так, например, согласно практике построения средств автоматизации управления войска-
ми (c4i - command, control, communication, intelligence) ведущими американскими и европейскими компаниями (ThalesGroup, RaytheonCompany, LockheedMartin, NorthropGrumman), для систем управления тактического звена используется «толстый» клиент, при автоматизации оперативного и выше - «тонкий».
Под «тонким» клиентом подразумевается перенос большей части задач по обработке информации на сервер. Соответственно, толстый клиент обеспечивает пользовательским приложениям расширенную функциональность частично независимо от центрального сервера, часть задач по хранению и обработке данных выполняется на стороне клиента.
При проектировании АИС, значительное количество расчетных задач, большой объем и сложные взаимные связи хранимых данных, требуют соответствующих решений в виде производительных СУБД. В то же время, частота обновления информации, а также важность актуальных данных применительно к обработке поступающей информации с изделия требуют создания эффективных механизмов распределения данных. Основной проблемой разработки СУБД АИС является разнородность хранимых данных.
В целом, для каждого готового программного решения, в соответствии с его внутренней архитектурой, существуют данные с «наиболее подходящим» набором свойств, обрабатываемые с наибольшей для данного решения эффективностью и данные с «менее подходящим» набором свойств, обработка которых используемым программным решением затруднена. В то же время, учитывая значительную разнородность хранимых данных, жесткие требования к достоверности оценок и эффективности принимаемых на их основе решений определяет необходимость поиска оптимальных решений для обеспечения производительности АИС при устойчивой фрагментации и согласованности данных.
Таким образом, из приведенного обзора современных средств управления хранением и обработки данных следует, что каждое решение имеет свои достоинства и недостатки, и, при проектировании системы управления, выбор или разработку СУБД следует осуществлять, исходя из предметной области задач и поставленных требований. При этом основным принципиальным моментом при выборе программной архитектуры АИС является сравнительная, альтернативная оценка реляционной и нереляционной моделей СУБД.
В настоящее время не существует баз данных, которые подойдут для решения абсолютно всех проблем. Именно поэтому многие компании используют и реляционные, и нереляционные БД для решения различных задач. Хотя NoSQL-базы стали популярными благодаря быстродействию и хорошей масштабируемости, в некоторых ситуациях предпочтительными могут оказаться структурированные SQL-хранилища.
Наиболее часто используемыми реляционными клиент-серверными БД являются:
OracleDatabase, MSSQLServer - производительные коммерческие
СУБД;
mySQL - популярная СУБД для web-ресурсов;
PostgreSQL - объектно-реляционная СУБД с открытым кодом.
Основанием для выбора реляционной SQL-базы при проектировании АИС могут являться следующие причины [9]:
1. Необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность) [10, 11]. Это позволяет уменьшить вероятность неожиданного поведения системы и обеспечить целостность базы данных. Достигается подобное путём жёсткого определения того, как именно транзакции взаимодействуют с базой данных. Это отличается от подхода, используемого в NoSQL-базах, которые ставят во главу угла гибкость и скорость, а не 100% целостность данных.
2. Данные, которые требуется интегрировать и обрабатывать структурированы, при этом структура не подвержена частым изменением. Если предприятие или область применения АИС на предприятии не находится в стадии экспоненциального роста, вероятно, не найдётся убедительных причин использовать БД, которая позволяет достаточно вольно обращаться с типами данных и нацелена на обработку огромных объёмов информации.
В том случае если есть основания полагать, что база данных может стать узким местом проекта, находящегося в стадии становления и проработки, каким по существу является задача внедрения системы TQM на предприятиях ВИС ОПК, и основанного на работе с большими объёмами разнородной, неструктурированной информации, стоит посмотреть в сторону NoSQL-баз, которые позволяют то, чего не умеют реляционные БД [4]. Ниже представлены возможности, которые стали причиной популярности таких NoSQL баз данных, как MongoDB, CouchDB, Cassandra, HBase:
1. Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных.
2. Использование облачных вычислений и хранилищ. Облачные хранилища — отличное решение, но они требуют, чтобы данные можно было легко распределить между несколькими серверами для обеспечения масштабирования. Использование, для тестирования и разработки, локального оборудования, а затем перенос системы в облако, где она и работает — это именно то, для чего созданы NoSQL базы данных.
3. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы, применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз.
Занимаясь поиском системы управления базами данных, можно выбрать одну технологию, а позже, уточнив требования, переключиться на что-то другое. Однако, разумное планирование позволит сэкономить немало времени и средств. Ниже приведены признаки проектов, для которых идеально подойдут SQL-базы:
имеются логические требования к данным, которые могут быть определены заранее;
очень важна целостность данных;
нужна основанная на устоявшихся стандартах, хорошо зарекомендовавшая себя технология, используя которую можно рассчитывать на большой опыт разработчиков и техническую поддержку;
А вот свойства проектов, для которых подойдёт что-то из сферы NoSQL:
требования к данным нечёткие, неопределённые, или развивающиеся с развитием проекта;
цель проекта может корректироваться со временем, при этом важна возможность немедленного начала разработки;
одни из основных требований к базе данных - скорость обработки данных, фрагментация, масштабируемость и кеширование;
обеспечение возможности перехода к распределённому способу хранения информации в условиях работы предприятий ВИС ОПК.
На предприятии АО «ГосНИИП», входящего в ВИС ОПК, по результатам анализа и формализации информационных потоков СМК [7], с учётом всего комплекса проблем с цифровизацией технологических процессов, стали очевидны недостатки реляционных SQL-разработок, в том числе базовых моделей системы 1С, связанными с необходимостью глубокого реинжиниринга, что значительно повышает стоимость проекта при значительных сроках разработки. Одновременно с этим существует необходимость моделировать структуру АИС в соответствии с действующими на предприятии форматами технологических процессов и нормативных требований без деформации сложившегося производства. Это в свою очередь обеспечит ускоренное внедрение программного продукта, в том числе за счёт снижения информационных рисков, связанных с противодействием новациям со стороны персонала предприятия, обусловленного человеческим фактором [12].
Из приведенного обзора следует необходимость разработки специализированной объектной СУБД, архитектура и основные принципы построения которой описаны в данном разделе.
Таким образом для хранения данных в БД АИС предприятия из зарекомендовавших себя информационных продуктов выбрана и успешно используется документно-ориентированная система управления базами данных MongoDB (далее система). Данный программный продукт является свободно-распространяемой высокопроизводительной системой с открытыми исходными кодами, реализованной в 2014 году на языке С++ компанией Mongo Inc [13].
В основе системы лежит использование массивов JSON-подобных документов вместо таблиц, позволяющих более удобно и эффективно моделировать данные с гибким набором полей. Хранение данных в коллекциях без определённой схемы позволяет избежать затратных по времени операций типа ALTER_TABLE добавления колонки к таблице в классических SQL базах, что позволяет новой системе добавлять дополнительные поля к некоторым документам «на лету».
Для повышения эффективности обработки запросов по мере увеличения объема хранения данных, система позволяет использовать механизм шардирования (разнесения базы данных по нескольким серверам). Данное свойство представляется особенно актуальным при организации информационных связей в цепочке "поставщик КИ - предприятие ВИС ОПК - Концерн", а также для разнесения при интегрировании разнотипной информации о качестве по нескольким предприятиям. Для отказоустойчивости система использует реплицирование (создание и поддержание нескольких копий данных в актуальном состоянии). Кроме того, реплики данных могут использоваться для повышения производительности обработки запросов по чтению данных (чтение из различных реплик).
Благодаря этим механизмам, а так же документно-ориентированной структуре данных, система показывает наилучшую производительность при обработке большого числа запросов по чтению данных, что наилучшим образом согласуется с тематикой её применения в текущей модели -построению большого числа отчетов и визуализации хранимых данных. Данные от независимых экспертов [14] по сравнению производительности Mongo Server и, к примеру, SQL server 2008, демонстрируют более быстрое выполнение запросов типа вставки объекта в 30-50 раз, запросов получения данных из базы в 3-5 раз, и запросов обновления данных в 5-8 раз.
Для тематической работы с системой был реализован веб-интерфейс на языке программирования Python, позволяющий производить учёт всей информации по дефектным комплектующим.
В разрабатываемом программном комплексе СУБД предназначена для учета и хранения информации об отказах базовых и комплектующих изделий, построении отчетов по ним, а так же хранению сопутствующих документов. Кроме этого в целях реализации автоматизированной программы принятия корректирующих производственных решений по состоянию выпускаемой продукции на различных этапах ЖЦ необходима организация хранения и обработки массивов параметрической информации, поступающей из производства, испытаний всех видов, а также эксплуатации. Организация хранения данных, их дальнейшая обработка, информационный обмен реализованы в соответствии со схемой, приведенной на рис. 1.
Схема формирования параметрических данных для базовых и комплектующих изделий показана на рис. 2.
Представленная функциональная схема построения БД АИС предприятия имеет в своей основе модульную архитектуру аналогичную, используемой в АИС по обеспечению качества вооружения ведущими зарубежными компаниями. Так, например, компания Raytheon разрабатывает проект под названием DREAMachine (Defect/Test Reduction Empoweredby Analyticsand Machine Learning), в основу которого положено применение методов машинного обучения, позволяющих оперативно анализировать огромные объемы информации, распознавать сложные зависимости и прогнозировать требуемую выходную информацию для принятия решений на основе имеющихся данных. DREAMachine использует в своей основе мо-
дульную архитектуру (рис. 3) для достижения большей точности прогнозирования и глубокого понимания процессов на уровне системы. Такая архитектура позволяет, не прибегая к серьезным доработкам, интегрировать дополнительные источники данных по мере появления новой информации. Модульная архитектура информационной среды в проекте DREAMachine позволяет активно применять машинное обучение к традиционно разрозненным источникам данных с целью получения представления о функционировании системы в целом, что позволяет сократить время на проведение дополнительных испытаний и спрогнозировать возможные отказы системы в ходе ее дальнейшей работы. Собранные данные фильтруются, анализируются и объединяются в единой базе, связывая информацию о компонентах системы на всех ее уровнях [15,16].
ЗЕ
Информационные массивы
Массивы параметрических данных Сведения об отказах изделий Характеристики изделий Поставщики и потребители Первичные документы
Рис. 1. Схема Архитектура информационной системы
Массивы параметрических данных
Х1,у1, У
А V
Аналитический модуль
Базовое Изделие ...
Рис. 2. Схема формирования параметрических данных ЛИС
264
;
Компонент
Компонент
Подсистема
С
J
Компонент
3
■
. и
ПчДКОМНОНСН! ПОДК'ОМИОНСН
11 ) Под»
'1КОМ1ЮНСН г Полкимпонен i
i Подкомпонент Под ком нон сн i
Рис. 3. Модульная архитектура системы, используемая в проекте
DREAMachine
Использование при разработке БД АИС модульной архитектуры позволило эффективно реализовать возможности и преимущества нереляционной NoSQL-системы. В соответствии с этим объекты внутри БД АИС хранятся в виде коллекций (массивов), каждый из которых представляет собой группу документов. Две основные из них - products_collection и sub-products_collection отвечают за хранение основной информации об отказах базовых и комплектующих изделий.
В соответствии с выбранной архитектурой в виде отдельных массивов хранятся: сведений об отказах базовых изделий (БИ), выпускаемых ДО Концерна; сведений об отказах комплектующих изделий (КИ); наименования БИ и КИ; наименования Потребителей (Пользователей) оборудования производимого ДО Концерна; наименования Поставщиков (Производителей) оборудования; сканов первичных документов по отказам, ремонту и техническому состоянию; параметрические данные. Каждое БИ и КИ в представленных массивах могут быть связаны с единственным изделием базовым или комплектующим. Данные о базовых и комплектующих изделиях хранят набор полей, таких как номер, даты отказа, поступления в ремонт, восстановления, и многие другие. Каждому изделию в коллекции присватается уникальный идентификатор ObjectID, на основе которых организуется связь между базовыми и комплектующими изделиями. Все базовые и комплектующие изделия имеют поля subproducts, в которых хранится массив идентификаторов изделий, из которых состоит данное изделие. В свою очередь все комплектующие изделия имеют поле parent_product_id, в котором хранится идентификатор изделия, в состав которого входит данное.
Информация о документах (например, рекламационных актах, технических актах) хранится в виде массива вложенных документов. В случае, если к документу прикреплены его отсканированные копии, они хранятся в специализированной коллекции document_scans, оптимизация работы с которой основана на специализированных механизмах работы Mongo с бинарными данными.
База данных структурирована по датам, типам изделий, предприятиям потребителям-заказчикам, поставщикам комплектующих изделий, этапам жизненного цикла изделий, типам воздействий на изделия, характеру и видам отказов. Это позволяет обрабатывать и анализировать материал по группам с формированием требуемых отчётов, экспортировать материалы в другие информационные системы в формате Excel, а также про-
водить оценку достигнутого уровня качества, для этого в базу интегрированы инструменты расчётов вероятности безотказной работы (ВБР), плотности ВБР, наработки на отказ и частоты отказов.
Часть из полей БД сформирована с использованием списочных данных, что обеспечивает проведение выборки информации по критериям при построении специализированных отчётов. Порядок обработки, занесения, а также анализ информации реализован в соответствии с внутренними стандартами предприятия по вопросам рекламационной работы и исследованию отказов, учитывающими особенности производственного процесса.
Разработанная СУБД имеет классическую трехуровневую модель. Эта модель является расширением двухуровневой модели (клиент-сервер) и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 4.
Клиент Сервер Сервер БД
Presentation logic Запуск процедуры Хранимые процедура
Business logic
<- Результаты для вывода
Связующие функции Database logic С ) сд >~ -s
Рис. 4. Трехуровневая схема работы базы данных
Данная модель имеет три уровня. Первым уровнем является клиент, отвечающий за логику представления данных пользователю, а так же за логику управления этими данными конечным пользователем. На данном этапе клиент реализован в виде веб-интерфейса. Благодаря этому не требуется установки никакого дополнительного программного обеспечения на компьютер клиента. Текущая реализация клиента имеет поддержку большинства современных браузеров, в том числе: google chrome, safari, opera, mozilla firefox. Клиент представляет данные пользователю в виде загружаемых с сервера веб-страниц, генерируемых на сервере приложений. Часть страниц имеет динамическую структуру и содержимое, загружаемое с сервера при помощи дополнительных запросов к серверу.
Промежуточный уровень трехуровневой системы содержит один или несколько серверов приложений. В данной модели этот уровень представлен python-приложением, работающим на основе WSGI сервера waitress. Данное приложение отвечает за бизнес логику системы управления базой данных, а именно: генерация и направление необходимых запросов к серверу БД, генерация страниц и данных для отправки их пользователю, а так же контроль корректности заполнения БД. Генерация страниц сервером производится при помощи python-пакета flask, позволяющего разделить генерацию представления данных пользователю и логику СУБД.
Сервер базы данных отвечает за корректную загрузку и выгрузку данных из/в базу данных mongo. Реализация данного сервера использует объектно-ориентированный поход к работе с данными, при котором каждому типу объекта (изделиям, документам, наименованиям) соответствует
Python класс, предоставляющий удобный интерфейс для работы с данными типами (корректное добавление, модификация, удаление и загрузка комплектующих частей).
Таким образом, в процессе разработки и продвижения новой информационной системы, одновременно с использованием программных продуктов нового поколения, был реализован инновационный информационно-технологический подход к моделированию, программированию и структуризации элементов СМК без деформации сложившегося производства и в соответствии с действующими на предприятии форматами технологических процессов и нормативных требований. Это обеспечило высокую производительность и эффективность формирования информационных потоков СМК предприятия в кратчайшие сроки. Полученные результаты не могли быть достигнуты за счёт внедрения дорогостоящих, громоздких и в значительной мере устаревших реляционных информационных систем в том числе на базе 1С, требующих кроме всего прочего значительные расходы времени на реинжиниринг. Данное обстоятельство подтверждает высокую эффективность новой АИС и научную новизну информационно-технологического метода, предложенного для оцифровки процессов СМК на предприятиях ВИС ОПК.
Результаты работы по созданию БД были оформлены и зарегистрированы в Федеральной службе интеллектуальной собственности [17].
Список литературы.
1. Третьяк Л.Н., Косых Д.А., Рудь Н.А. Анализ информационного обеспечения системы менеджмента качества // Форум учёных. Материалы VII Международной студенческой научной конференции «Студенческий научный форум» [Электронный ресурс] URL: https:// scienceforum.ru/ 2015 / article/2015013842 (дата обращения: 11.01.2020).
2. Губарев А.В. Информационное обеспечение системы менеджмента качества [Электронный ресурс] URL: https://biblioclub.ru/ index.php? page=book red&id=275224&razdel= (дата обращения: 09.01.2020).
3. Щеглов Д.К. Методика выбора PDM-системы для предприятия ракетно-космической отрасли // Инновации. 2011. №5. [Электронный ресурс] URL: https://cyberleninka.ru/article/n/metodika-vybora-pdm-sistemy-dlya -predpriyatiya-raketno-kosmicheskoy-otrasli (дата обращения: 09.01.2020).
4. Андреев А.М., Березкин Д.В., Самарев Р.С. Внутренний мир объектно-ориентированных СУБД // OSP - Гид по технологиям цифровой трансформации. Открытые системы архитекторам информационных систем. 2001. [Электронный ресурс] URL: https://www.osp.ru/ os/2001/ 03/ 179987/ (дата обращения: 08.12.19).
5. Дейт К. Дж. Введение в системы баз данных. М.: Издательский дом «Вильямс», 2001. 1328 с.
6. Коннолли Т. Базы данных, проектирование, реализация и сопровождение. М.: Издательский дом «Вильямс». 2003. 1440 с.
7. Афанасьев В.Б., Медведев В.М., Остапенко С.Н., Палихов Г.В., Мамаев В.А. Инновационные технологии в управлении качеством и надёжностью продукции предприятий ОПК // Всеросийская научно-техническая конференция «Отечественный и зарубежный опыт обеспечения качества в машиностроении». 2019. С. 273-275.
8. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. М.: Издательство Бином, Спб: Невский диалект, 1998. 558 с.
9. Alon Brody. SQL или NoSQL — вот в чём вопрос // Хабр. 2017. 9 марта. [Электронный ресурс] URL: https://habr.com/ru/ company /ruvds/ blog/324936/ (дата обращения: 20.01.20).
10. Компания SOFTPOINT // Глава 7 - Свойства транзакций и системы (ACID). [Электронный ресурс] URL: http://www.softpoint.ru/ archive/ article_id368.php (дата обращения: 01.12.2019).
11. Gray Jim. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International Conference on Very Large Databases, 1981. P. 144 - 154.
12. Михайлов Ю.М. Властные коммуникации и фактор риска в сетевом обществе: социально-философский анализ [Электронный ресурс] URL: http: //avtoref.mgou.ru/new/d212.155.08/Mihailov/diss.pdf (дата обращения: 10.02.2020).
13. MongoDB // The database for modern applications. [Электронный ресурс] URL: https://www.mongodb.com/ (дата обращения: 20.01.20).
14. Wu C. M., Huang Y. F., Lee J. Comparisons between mongodb and ms-sql databases on the twc website // American Journal of Software Engineering and Applications. 2015. Т. 4. №. 2. P. 35-41.
15. Электронный ресурс компании Raytheon (США) // [Электронный ресурс] URL: https://www.raytheon.com/sites/default/files/ technologyto-day/ 2018/issue1/wp-content/uploads/2018/08/Raytheon TechnologyToday Issue1 2018.pdf (дата обращения: 09.09.2019).
16. Боев С.Ф., Рахманов А.А., Логовский А.С., Медведев В.М., Перлов А.Ю., Казанцев А.М. Современное состояние и направления совершенствования систем технического обслуживания комплексов специального назначения ведущих мировых военно-промышленных компаний // Вестник воздушно-космической обороны. 2018. №4 (24). С. 105 - 113.
17. Свидетельство о государственной регистрации базы данных №2018620285. База данных для оценки уровня качества выпускаемой предприятием продукции на всех этапах жизненного цикла / Афанасьев И.В., Афанасьев В.Б.; заявитель и правообладатель АО «ГосНИИП». №2017621619; заявл. 29.12.2017; регистр. В Реестре баз данных 16.02.18.
Афанасьев Виктор Борисович, начальник отдела, vicbor54@,bk.ru, Россия, Москва, АО «ГосНИИП»
EXPERIENCE OF DESIGNING A SYSTEM OF INFORMA TION SUPPORT OF PRODUCT QUALITY OF A DEFENSE ENTERPRISE
V.B. Afanasyev 268
The article presents and substantiates technical solutions for constructing a database management system, proposes a selection of software solutions for an automated information system designed to ensure the effectiveness of a defense enterprise's quality management system. An innovative software product based on non-relational NoSQL developments was pro-posedfor military enterprises.
Key words: information system, DBMS, quality, reliability, information environment of the QMS.
Afanasiev Victor Borisovich, head of reliability, vicbor54@,bk. ru, Russia, Moscow, JSC «GosNIIP»
УДК 005.6
ИНЖИНИРИНГ КАЧЕСТВА В КОНЦЕПТУАЛЬНОМ ПРОЕКТИРОВАНИИ 3Б-ПРИНТЕРА
Д.В. Ермилина, С.Н. Казандаева, А.О. Сергиенко, И.В. Русских
В статье предложено использование совокупности методов инжиниринга качества QFD, ТРИЗ и FMEA для концептуального проектирования 3D-принтера с более высокой точностью и сохранением времени изготовления. Подобный комплексный подход предполагает всестороннее рассмотрение процесса проектирования принтера и синергетический эффект от применения предложенного набора методов.
Ключевые слова: 3D-принтер, аддитивное производство, послойное наращивание, инжиниринг качества, QFD, ТРИЗ, FMEA, проектирование.
В настоящее время многие фирмы занимаются изготовлением 3D-принтеров для различных областей использования, поэтому конкуренция в этом экономическом секторе достаточно велика. Ситуация осложняется ещё и тем, что проектирование и производство 3D-принтеров - это наукоёмкий процесс, требующий значительных интеллектуальных вложений. При создании такого продукта важно не сделать ошибку ещё на этапе концептуального проектирования.
Аддитивные технологии (3D-печать) (Additive Manufacturing, AM) являются примером инновации в производстве. Технология 3D-печати заключается в «автоматизированном получении изделия послойным наращиванием (принцип «сложения») на специальном оборудовании - 3D-принтере, в соответствии с компьютерной информационной моделью этого изделия и под управлением технологических программ (числовое программное управление - ЧПУ)» [1]. Все больше предприятий внедряют аддитивные технологии в производство. В ежегодном докладе WohlersReport 2019 прогнозируется, что оборот в индустрии 3D-печати в 2020 году составит 15,8 миллиардов долларов [2]. В таких условиях для сохранения конкурентоспособности даже новую технологию, необходимо постоянно улучшать и совершенствовать.
