CC BY
15УДК 629.76
DOI 10.18698/23 08-6033-2017-5-1612
Оптимизация моделирующих стендов для изделий ракетно-космической техники в условиях экономического кризиса
© Л.С. Точилов
ОАО «ВПК «НПО машиностроения», г. Реутов, Московская обл., 143966, Россия
В статье исследуется актуальная проблема сокращения расходов на разработку изделий ракетно-космической техники (РКТ) на примере процесса отработки систем управления этих изделий посредством выполнения «электронных пусков» в наземных условиях на моделирующих стендах (МС) двух видов: стендах математического моделирования и стендах полунатурного моделирования. На примере МС рассмотрены краткая история их развития, вариант будущего состояния как желаемый вариант оптимизации, вопросы управления рисками при оптимизации отработки систем управления изделий РКТ на МС. В качестве ключевой технологии оптимизации МС представлена возможность отработки алгоритмов бортовой цифровой вычислительной машины на языке C++, открывшая новые возможности реинжиниринга процесса отработки систем управления изделий РКТ на МС. Показано, что некоторые полученные результаты могут оказаться полезными при выработке подхода к оптимизации ракетно-космической отрасли, более приемлемого, чем попытки применения концепции производственной системы Toyota «Бережливое производство» в принципиально иных условиях.
Ключевые слова: ракетно-космическая техника, экономический кризис, оптимизация расходов, моделирующие стенды, стенды полунатурного моделирования, стенды математического моделирования, система управления, алгоритмы системы управления, бортовая цифровая вычислительная машина, язык C++, бережливое производство, Toyota
Введение. Очевидно, что в условиях экономического кризиса предприятия ракетно-космической отрасли (РКО) вынуждены изыскивать возможности сокращения затрат [1]. Для этого существуют два основных пути: революционный и эволюционный. Теоретической основой революционного пути является реинжиниринг [2], эволюционного — система менеджмента качества [3]. Эволюционный путь подходит для стабильных условий хозяйствования, а при резких внешних изменениях необходимо оперативное реагирование. Теоретически реинжиниринг может стать реакцией на сокращение сроков разработок и уменьшение финансирования. Однако большие риски проектов по реинжинирингу в организациях ракетно-космической отрасли [4] в условиях кризиса возрастают настолько, что заставляют от них отказаться.
Между этими двумя теоретическими полюсами существуют концепции, созданные на базе опыта передовых компаний. Особую по-
пулярность в РКО получила концепция производственной системы Toyota «Бережливое производство». Но эта концепция предназначена для серийных производств, а не для научно-производственных организаций.
Если представить РКО одним большим серийным производством ракетно-космической техники (РКТ), то, применив к ней концепцию «Бережливое производство», придется оставить за скобками проблемы ученых и конструкторов, обеспечивающих разработку и испытания изделий РКТ.
В статье на примере моделирующих стендов (МС) рассмотрены основные риски оптимизации процесса комплексной отработки систем управления изделий РКТ в наземных условиях. Из правила проектного треугольника [5] следует, что сокращение разработок сроков и уменьшение финансирования неизбежно ведут к сокращению объема и ухудшению качества работ. Единственной возможностью избежать деградации качества работ в условиях кризиса и минимизировать риски оптимизации РКО является создание новых технологий и базирующихся на них концепций развития.
В рамках задачи оптимизации РКО предлагается новая концепция развития МС, основанная на таком сугубо технологическом факторе, как реализация возможности отработки алгоритмов бортовой цифровой вычислительной машины (БЦВМ) на языке C++.
Основные принципы оптимизации РКО. Эти принципы, изложенные первым заместителем генерального директора ОАО «ОРКК» П.Д. Поповым на II Афанасьевских чтениях [1], состоят в следующем:
1) ликвидация дублирования при выпуске космических аппаратов несколькими предприятиями;
2) ликвидация дублирования при выпуске колоссального объема комплектующих на каждом уровне кооперации;
3) ликвидация дублирования технологий на предприятиях отрасли;
4) сокращение избыточных мощностей;
5) уменьшение объемов незавершенного производства.
Реализовав указанные условия оптимизации, ОАО «ОРКК» и ГК
«Роскосмос» смогут более эффективно решать первоочередные задачи (рис. 1 ).
Краткая история развития МС. Моделирование полетов изделий РКТ началось еще до использования в этих целях компьютеров. С помощью логарифмических линеек проводились многочисленные расчеты вариантов траекторий и динамики полетов. Поведение систем управления описывалось математически. Использование компьютеров позволило автоматизировать этот процесс. Описание поведения системы управления стало программой — сначала на языке низкого уровня (Ассемблер), а затем на языке высокого уровня (Фортран).
Планирование Планирование Планирование Планирование
выпуска продукции компонентов процессов производства
Рис. 1. Первоочередные задачи и приоритеты в работе предприятий ОАО «ОРКК»
и ГК «Роскосмос» [1]
Важно отметить, что БЦВМ первоначально программировались на машинном языке (программа на машинном языке — это последовательность нулей и единиц).
Таким образом, с одной стороны, существует объект — БЦВМ — с заложенными в него реальными программами на машинном языке (под реальными будем понимать программы, выполняемые БЦВМ в процессе полета), а с другой — программная модель БЦВМ на универсальном компьютере, моделирующем полет изделия РКТ в конструкторском бюро. Что предпринять, если поведение БЦВМ в полете отличается от поведения ее модели на компьютере при «электронном пуске» в конструкторском бюро?
Чтобы ответить на этот вопрос, обратимся к практике взаимодействия предприятия — разработчика бортовых систем управления (БСУ) и головного предприятия — разработчика РКТ. Головное предприятие — разработчик РКТ выдает техническое задание, другие исходные данные предприятию — разработчику БСУ.
После выполнения работ по программированию БЦВМ (и других приборов) в составе БСУ она передается головному предприятию — разработчику РКТ как «черный ящик», удовлетворяющий требованиям технического задания.
На стенде математического моделирования (СММ) головного предприятия — разработчика РКТ математическая модель (ММ) БСУ проверяется методом «электронного пуска». Если получен положитель-
ный результат, изделие РКТ допускается к летно-конструкторским испытаниям (ЛКИ). При неудачных ЛКИ для анализа работы БСУ привлекаются специалисты предприятия — разработчика БСУ, так как для специалистов головного предприятия — разработчика РКТ БСУ — «черный ящик».
В этом случае возникает конфликт интересов: специалист предприятия — разработчика БСУ должен найти ошибку, за которую его накажут. Соответственно, вместо реальной ошибки специалист будет искать недочеты, ответственность за которые можно возложить на другое лицо. Если бы за найденные ошибки награждали, результат мог быть иным.
На этом примере хорошо прослеживается отличие системы, построенной на ответственности (поиск виновных), от системы менеджмента качества (поиск ошибок). Однако на практике часто создается промежуточный вариант, включающий черты обеих систем, что означает фактическое отсутствие системы. Именно поэтому после рапортов предприятий о внедрении системы менеджмента качества результаты порой оказываются хуже, чем при использовании существовавшей ранее системы качества. Такой же риск существует и при оптимизации, если вместо решения реальных проблем заниматься вопросами сертификации или обсуждать принципы оптимизации.
В любом случае в каждой системе есть запрос на снижение неопределенности, зависящей от интересов сотрудников и предприятий кооперации. С начала 1980-х годов у головных предприятий появились технические возможности (гибридные аналого-цифровые вычислительные системы (АЦВС) реального времени на базе управляющих вычислительных комплексов серии малых или мини-ЭВМ и аналоговых вычислительных комплексов) для создания МС, в состав которых включались реальные БСУ.
Пришло время стендов полунатурного моделирования (СПМ). Вопрос адекватности ММ БСУ и реальных БСУ был снят тем, что на СПМ использовались реальные БСУ. Анализ входов и выходов реальных БСУ в процессе «электронного пуска» позволял объективно выявлять ошибки функционирования БСУ в наземных условиях. Это позволило снижать риски ЛКИ и экономить значительные средства (проведение ЛКИ на порядки дороже, чем «электронный пуск»).
Главной особенностью СПМ является то, что функционирование реальных БСУ происходит в режиме реального времени с тактом работы БЦВМ. Чтобы вовремя подыграть ей, программы, моделирующие движение изделия РКТ, должны успевать принимать данные, выполнять вычисления и возвращать результаты в БСУ за один такт работы БЦВМ. Этого невозможно было достичь при низкой производительности цифровых управляющих вычислительных комплексов.
Поэтому в помощь им для расчета систем дифференциальных уравнений подключались высокоскоростные аналоговые вычислительные комплексы, обладающие, однако, невысокой точностью вычислений. В целом получалась довольно сложная АЦВС (первая проблема), моделирующая движение изделия РКТ с невысокой точностью (вторая проблема).
Еще одна (третья) проблема была связана с тем, что некоторые приборы БСУ сложно, а некоторые и невозможно заставить работать в наземных условиях, как в полете. Примерами могут служить соответственно гироскопы и датчики угловых скоростей.
Есть три варианта решения этой проблемы, имеющие свои достоинства и недостатки. Перечислим их в порядке возрастания стоимости реализации: 1) использование вместо прибора БСУ программы, имитирующей его работу в полете; 2) создание специального устройства — аппаратно-программного имитатора (АПИ) работы прибора БСУ в полете; 3) воссоздание в наземных условиях воздействий, характерных для полета, с целью «обмануть» прибор (например, размещение гироскопов на трехстепенном поворотном стенде, управляемом от АЦВС).
В том или ином виде эти проблемы решаются, однако вопрос оптимизации такой сложной системы, как СПМ, долго оставался актуальным. Его решению способствовал постоянный рост производительности персональных компьютеров (ПК). На определенном этапе их использование позволило снять проблемы работы в реальном времени и точности моделирования. Также на основе ПК оказалось легко создавать и использовать АПИ приборов БСУ. Стандартом для программирования на СПМ де-факто стал язык С++.
Развитие технологий коснулось и БСУ изделий РКТ. Важным шагом стало использование мультиплексного канала информационного обмена (МКИО) между БЦВМ и другими приборами БСУ изделия. Это позволило стандартным образом подключать АПИ приборов БСУ к МКИО, прослушивать МКИО, фиксируя весь информационный обмен с привязкой к времени. Базовым стал СПМ в составе ПК и БЦВМ, связанных МКИО, с возможностью подключения приборов БСУ или АПИ.
Другой, менее заметный, но еще более значимый шаг был сделан разработчиками программного обеспечения (ПО) для БСУ изделий РКТ. Для программирования алгоритмов систем управления стали использовать язык С++, а для их отладки — обычный ПК.
Не вдаваясь в технологию того, как программы на языке С++ трансформируются в коды для БЦВМ, отметим факт рождения полной копии программ БСУ на языке С++. Важно отметить, что автором и гарантом соответствия программ систем управления и их ко-
пий на языке С++ является разработчик БСУ, который заинтересован в их идентичности.
Такая автоматизация открывает новую возможность для головного предприятия — разработчика РКТ. Если прежде программы в машинных кодах, а позднее на Ассемблере отдельно от БЦВМ были ему не нужны, то алгоритмы БСУ изделия на языке С++ для него просто необходимы.
Благодаря им выполнить «электронные пуски» с реальными алгоритмами БСУ изделия РКТ стало возможным на ПК без БЦВМ. Более того, открылись новые перспективы сотрудничества головного предприятия — разработчика РКТ и предприятия — разработчика БСУ на основе создания одинаковых МС для изделий РКТ. Для этого предприятие — разработчик БСУ представляет алгоритмы БСУ на языке С++, а головное предприятие — разработчик РКТ — модель движения изделия РКТ на языке С++. Решив вопрос согласованного внесения изменений, каждое предприятие может проводить исследования в области своей компетенции, проверяя результаты с помощью «электронных пусков».
При таком подходе существуют определенные риски. Главный риск связан с позицией разработчика алгоритмов БСУ на языке С++ (владельца ключевой технологии). Прежний опыт призывает его к закрытости. Но, во-первых, алгоритмы — фактически совместный интеллектуальный продукт специалистов головного предприятия — разработчика РКТ и предприятия — разработчика БСУ.
Во-вторых, алгоритмы на языке С++ — это еще не программа в БЦВМ. Переводом их в программу БЦВМ, как правило, занимаются люди старшего поколения, ответственные, опытные. Тем не менее риск, что они могут ошибиться, существует. Поскольку кроме них в программах БЦВМ никто больше не разбирается, то неизвестно, кто окажется виноватым в случае неудачных ЛКИ. В этой ситуации более молодым разработчикам алгоритмов БСУ на языке С++ союзник в лице головного предприятия не будет лишним. Кроме того, двойная проверка на двух МС действительно придает дополнительную уверенность в правильности алгоритмов БСУ.
В-третьих, появляется интерес головного предприятия в получении этих алгоритмов. И если их не предоставить, то такой отказ от сотрудничества можно будет объективно трактовать как действие или бездействие, приводящее к неудачам ЛКИ. Так что преграды на этом пути преодолимы, если есть их правильное понимание.
Условия для развития МС. Магистральное направление дальнейшего развития МС пока находится в стадии исследования. Однако в условиях кризиса долгосрочным вектором развития становится оптимизация всех видов деятельности. Что касается МС, то
трехстепенные поворотные стенды, АПИ и другие дорогостоящие компоненты будут уходить в прошлое, во всяком случае на головном предприятии — разработчике РКТ (для разработчика гироскопов специализированные стенды, в том числе поворотные, безусловно, нужны, и их применение оправданно). В будущем оптимизированные МС — это исключительно стенды математического моделирования (СММ), но с повышенной точностью и достоверностью.
В настоящее время результаты, полученные на СММ с реальными алгоритмами БСУ, проверяются на СПМ с реальной БЦВМ. Фактически на СПМ проверяются три составляющие, не охваченные СММ: 1) машинный код в БЦВМ; 2) работа аппаратной части БЦВМ; 3) интерфейс обмена БЦВМ.
Машинный код в БЦВМ. То, что преобразование программ на языке С++ в машинный код БЦВМ не производится полностью автоматически, является настолько очевидным недостатком в работе создателя БСУ, что подстраиваться под него в планах на будущее не имеет смысла.
В свое время разработчики БСУ активно противились развитию технологии программирования, связанного с переходом на язык Ассемблера взамен программирования на машинном языке. Одним из весомых, как тогда казалось, аргументов было представление о том, что программисты не допускают ошибок, а если ошибется транслятор, не ясно, кого наказывать.
За такой мотивировкой, как правило, стояло желание сохранить большой штат кодировщиков, обеспечить закрытость разработки от внешнего контроля и, как следствие, свое влияние. Однако прогресс, с трудом, но пробил себе дорогу. Транслятор с Ассемблера в машинные коды, в отличие от людей, не ошибался, что и стало решающим аргументом в его пользу. В настоящее время разработчикам БСУ надо пройти тот же путь на новом витке развития, когда транслятор с языка С++ будет вытеснять программистов на Ассемблере. Технически решить этот вопрос несложно, препятствиями для этого являются монополизм предприятия — разработчика БСУ и его желание сохранить свое «ноу-хау» в виде устаревшей закрытой технологии.
Тем не менее, поскольку современную молодежь обучать этому «ноу-хау» не представляется возможным, а старые кадры уходят, то предприятие — разработчик БСУ рискует оказаться в отстающих. Чем скорее оно осознает, что времени на отказ от устаревшей технологии практически нет, тем выше его шансы на выживание в будущем.
Работа аппаратной части БЦВМ. Наиболее полно эту работу может проверить только ее разработчик БЦВМ. Для этого у него несравнимо больше возможностей, чем у головного предприятия. В первую очередь — специалисты, разработавшие БСУ, во вторую — всевозможные проверочные стенды и методики, в том числе методи-
ка эталонного «электронного пуска», которая может быть предоставлена головным предприятием — разработчиком РКТ.
Предположим, что в работе некоторых приборов БСУ присутствуют какие-либо незадекларированные особенности. Во-первых, лишь разработчик БСУ может не просто выявить их, а предпринять действенные шаги к устранению. Во-вторых, если полагаться на добрую волю разработчика БСУ, то в случае невозможности устранения каких-либо вероятностных ошибок, по его мнению не критичных, он либо просто сообщит о них головному предприятию — разработчику РКТ, либо дополнительно предоставит программы, моделирующие эти ошибки.
При отсутствии доброй воли о вероятностных ошибках разработчик БСУ может, конечно, не сообщить. Чем же в этом случае головному предприятию — разработчику РКТ мог бы помочь СПМ? Представляется, что мало чем. Во-первых, на СПМ проводятся разовые «электронные пуски», целью которых является не анализ отдельных ошибок, слабо влияющих на результат, а в первую очередь результат виртуального полета. Вероятность выявления на СПМ случайной ошибки крайне мала, а при ее выявлении анализ без привлечения разработчика БСУ обычно невозможен. Для привлечения разработчика БСУ требуется доказательная база, т. е. нужно продемонстрировать повторяемость ошибки, а что может оказаться проблемой. Разработчик БСУ на своем стенде должен убедиться в возможности ошибки, т. е. в итоге возвращаются к проверкам на предприятии — разработчике БСУ. В случае критической ошибки, выявленной на СПМ, процесс аналогичен.
Таким образом, СПМ головного предприятия — разработчика РКТ ориентирован в первую очередь на выявление регулярных критических ошибок, которые могут быть доказательно продемонстрированы разработчику БСУ. Но это означает наличие такого очевидного брака, который ставит под сомнение жизнеспособность всей системы менеджмента качества предприятия — разработчика БСУ. Нельзя сказать, что такой брак не может возникнуть, но вероятность этого на порядок ниже, чем появление разного рода случайных ошибок, которые по большей части игнорируются как недоказанные или несущественные.
Интерфейс обмена БЦВМ. Интерфейс обмена БЦВМ является частью аппаратно-программного комплекса БЦВМ, который используется для тестирования БЦВМ на предприятии — разработчике БСУ. Что, кроме разъемов и кабелей (проходящих автономные проверки), теоретически может привести к ошибкам в интерфейсе обмена БЦВМ? Если такие причины известны и не могут быть выявлены проверками, осуществляемыми предприятием — разработчиком БСУ, то тогда, конечно, необходимость СПМ будет очевидна. Другой веской причиной могут стать опасения головного предприятия относи-
тельно вероятности брака продукции предприятия — разработчика БСУ. По сути, главной причиной необходимости наличия СПМ на головном предприятии будет недоверие к системе менеджмента качества предприятия — разработчика БСУ. Отсюда и возникает потребность в дополнительной проверке на СПМ. Фактически СПМ дублирует функции СМК предприятия — разработчика БСУ на головном предприятии — разработчике РКТ. Очевидно, что подобное дублирование надо исключать, но при условии гарантии качества со стороны предприятия — разработчика БСУ, как его понимает головное предприятие — разработчик РКТ.
Модели ошибок приборов систем управления. К сожалению, даже СПМ не позволяет выявить все ошибки работы приборов БСУ, которые могут проявляться случайно. Учитывая то, что в разных условиях и при различных состояниях изделия последствия таких ошибок могут существенно различаться, необходимо статистическое моделирование, которое может обеспечить только СММ с алгоритмами БСУ.
На основе многочисленных испытаний прибора БСУ с фиксацией разного рода отклонений разработчик создает программу, моделирующую ошибки прибора БСУ. Наряду с программой моделирующей работу прибора, программа, моделирующая его ошибки, передается на СММ головного предприятия — разработчика РКТ для статистического моделирования. Проведя тысячи «электронных пусков», более точно моделирующих «полет» с учетом неидеальной работы «приборов БСУ», можно будет делать выводы о допустимости или недопустимости использования таких приборов для ЛКИ.
Отсюда может возникнуть неверное суждение о том, что работа могла бы вестись гораздо эффективнее, если бы головное предприятие — разработчик РКТ само разрабатывало БСУ. Однако это не так. Большинство перечисленных проблем сохранилось бы, но внутри головного предприятия — разработчика РКТ.
Проблема разработки концепции развития МС. Эта ключевая проблема, не зависящая от того, на одном или на разных предприятиях производятся БСУ и РКТ, связана с наличием четырех вариантов развития. Каждый из них может претендовать на роль концепции.
1. Концепция «Программный стенд» — ПС (рис. 2).
Алгоритмы приборов системы управления помещаются в ПК вместе с моделью движения изделия, и исследуется полет при различных настройках системы управления. Преимущества такого варианта — полнота, результативность, объективность, прозрачность, невысокая стоимость. Необходимость создания такого стенда для каждого вида изделия РКТ очевидна, а возможность доказана.
Этот вариант представляется оптимальным как с точки зрения затрат, которые идут главным образом на развитие алгоритмов и тончайшего слоя технической элиты, разбирающейся в алгоритмах БСУ,
так и с точки зрения получения высококачественного результата при условии правильности ММ приборов БСУ.
Проверки
Рис. 2. Программный стенд
2. Концепция «Программно-аппаратный стенд» — ПАС (рис. 3). Если ММ приборов БСУ неверны или отсутствуют, их можно разрабатывать, искать и устранять ошибки. Но можно к ПАС подключить реальные приборы БСУ.
Рис. 3. Программно-аппаратный стенд
Хотя на первый взгляд этот вариант представляется более простым и достоверным, его достоинство проявляется лишь при наличии ошибок программистов в ММ приборов на ПС.
Кроме того, важно отметить, что каждый прибор БСУ подключается к стенду как «черный ящик». Знаний о его работе меньше, затрат — больше: настройка программ моделирования под циклограмму работы прибора (режим реального времени), организация и отработка аппаратных и программных интерфейсов, сопровождение.
Учитывая ресурсные ограничения приборов БСУ, в итоге можно рассчитывать на ограниченное число испытаний, для анализа кото-
рых нужен еще и разработчик БСУ, не заинтересованный в раскрытии своих ошибок, так что ценность такого анализа невысока. Подобная практика оправдана лишь в отношении наиболее сложных приборов БСУ, таких как БЦВМ.
3. Концепция «Аппаратно-программный стенд» — АПС (рис. 4). Если прибор БСУ работает неверно, например, имеет нестандартные ограничения, проявляющиеся лишь при проведении «электронного пуска», если его поместили на ПАС как стандартный, настроились на работу с ним и получили положительный результат, то это не означает, что результат будет положительным, если заменить прибор БСУ с нестандартными ограничениями прибором БСУ со стандартными ограничениями.
В этом варианте во главу угла ставится комплексная проверка приборов БСУ на СПМ. С одной стороны, все приборы должны тщательно проверяться, и это правильно. С другой стороны — почему дважды: у разработчика и у заказчика? Здесь просматривается резерв для оптимизации: АПС использует только разработчик БСУ, а головное предприятие оказывает поддержку по части алгоритмов и программ. Более того, проведение комплексного тестирования на АПС разработчиками БСУ создает для них потребность в профессиональных контактах со специалистами головного предприятия.
4. Концепция комплексного стенда (КС), или стенда как комплекса элементов (рис. 5).
До сих пор рассматривался вариант, что могут работать неправильно приборы системы управления, а программы на стенде работают верно. Но ошибки могут возникать на всех уровнях. Так пусть каждый специалист занимается своим делом: улучшает, оптимизирует, устраняет ошибки в алгоритмах, программах, интерфейсах, приборах систем управления, ведет работу с создателями этих приборов, составляет планы развития. Единственный возникающий вопрос: как
Рис. 4. Аппаратно-программный стенд
управлять этими видами деятельности на уровне ошибок, в условиях отсутствия или непредоставления информации?
Вывод прост: если существуют четыре варианта развития МС, за каждым из которых стоит реальная практическая работа, то можно определить приоритеты, а именно решить, что развивать в первую очередь, а что — во вторую и где.
Для разработчика БСУ наибольший интерес представляет АПС, позволяющий комплексно тестировать приборы БСУ при выполнении контрольных «электронных пусков».
Для головного предприятия важно уходить от «черных ящиков» в составе стендов и приходить к реальным алгоритмам работы БСУ, т. е. к ПС. Переходный этап — ПС и ПАС.
Концепция развития МС для БСУ на головном предприятии — разработчике РКТ на переходном этапе. Задача МС — обеспечить максимально приближенное к условиям реального полета функционирование изделий РКТ или их функциональных моделей на МС в наземных условиях для исследования работы БСУ и поведения изделий в полете при различных настройках БСУ, полетных заданиях, внешних условиях и т. п.
Множество исследуемых вариантов требует большого числа «электронных пусков». Достоверность результатов должна обеспечиваться всеми имеющимися в распоряжении разработчиков РКТ средствами. Для исследования результатов ЛКИ МС должны настраиваться на моделирование с использованием данных, полученных в ходе ЛКИ (в том числе о неисправностях БСУ).
Третья концепция МС была основана на том, что полные ММ БСУ разработчики БСУ, как правило, не предоставляли. Поэтому для каждого вида изделий РКТ создавались два вида МС — СММ и СПМ.
Проверки
Рис. 5. Комплексный стенд
Для моделирования полета изделий с упрощенной ММ БСУ служат СММ для моделирования полета изделий с реальной БСУ — СПМ. Они создаются путем перепрограммирования клона СММ для работы в режиме реального времени и подключения вместо ММ БСУ реальной БСУ; СПМ не могут существовать без СММ, так как не решают задачу МС вследствие ограничений на число производимых «электронных пусков».
Эти ограничения обусловлены невозможностью проводить «электронные пуски» автоматически, затратами времени на обслуживание реальных БСУ и выполнение подготовительно-заключительных операций, а также ограничениями на эксплуатационный ресурс дорогостоящих БСУ. Все это не позволяет исследовать на СПМ необходимый набор вариантов «электронных пусков» и вероятностные ошибки.
Вторым недостатком СПМ является то, что БСУ с их ПО используется как «черный ящик». В связи с этим контроль работы ПО БСУ возможен лишь опосредованно, через интерфейсы обмена.
Основные достоинства СПМ: 1) тестирование работы реальных БСУ; 2) перепроверка финальных вариантов, полученных на СММ.
Новая концепция МС базируется на том, что разработчики БСУ будут обязаны предоставлять полную ММ БСУ и вероятностные модели ошибок БСУ. Это позволит вместо СММ создавать ПС.
В состав ПС включены полные ММ и вероятностные модели ошибок БСУ, что обеспечивает более достоверное решение задачи МС. Достоверность финальных вариантов, полученных на ПС, может быть повышена, если они будут перепроверены с использованием реальной БСУ на СПМ, создаваемых из клона ПС для работы в режиме реального времени. Также СПМ позволит проводить тестирование БСУ и сравнивать работу БСУ с работой ММ БСУ. В таблице приведены сравнения рассмотренных концепций по критериям.
Концепции развития МС для БСУ
Концепция
Критерий Прежняя Новая
СММ СПМ ПС СПМ
Наличие не- Реальные ал- Алгоритмы Алгоритмы Алгоритмы
известных горитмы БСУ БСУ — «чер- БСУ известны БСУ из-
алгоритмов отсутствуют ный ящик» вестны
Ограничения Нет ограниче- Ограниченное Нет ограниче- Ограничен-
на число ний на прове- число «элек- ний на прове- ное число
«электронных дение большо- тронных пус- дение большо- «электрон-
пусков» для го числа ков» го числа ных пус-
исследования «электронных пусков» «электронных пусков» ков»
Окончание таблицы
Критерий Концепция
Прежняя Новая
СММ СПМ ПС СПМ
Тестирование ПО БСУ Нет возможности Опосредованно, через контроль интерфейсов Да, ПО БСУ, перенесенное на ПС Да, ПО БСУ в составе аппаратуры БСУ
Тестирование аппаратного обеспечения БСУ Нет аппаратного обеспечения БСУ и моделей ошибок аппаратного обеспечения Ограниченное число проверок интерфейсов обмена БСУ на отобранных на СММ вариантах Программное моделирование вероятностных ошибок аппаратного обеспечения БСУ Ограниченное число проверок работы БСУ на отобранных на ПС вариантах
Достоверность результатов / возможность анализа результатов ЛКИ Средняя / средняя Высокая* / средняя Высокая / высокая Высокая* / высокая
Полная стоимость: создания / владения Средняя / низкая Высокая / средняя Средняя / средняя Высокая / средняя
Жизненный цикл (ЖЦ) * Двойная провер Может использ Совпадает с ЖЦ изделия ка с ММ БСУ и рег оваться в разработк Совпадает с ЖЦ изделия 1льными БСУ. е новых видов изде Совпадает с ЖЦ изделия** лий. До подтверждения полного соответствия БСУ их ММ
Заключение. С использованием ПС основная задача МС решается на качественно более высоком уровне, нежели с использованием СММ и СПМ. Вместе с тем достоверность финальных результатов, полученных на ПС, при отсутствии стопроцентной гарантии идентичного функционирования ММ БСУ и реальной БСУ, желательно подтвердить на СПМ с реальной БСУ. Одновременно это можно рассматривать как задачу тестирования БСУ.
Поэтапная реализация новой концепции развития МС позволит решить задачу оптимизации затрат, обеспечив более высокое качество отработки изделий РКТ на МС.
ЛИТЕРАТУРА
[1] Попов П.Д. Первоочередные задачи и приоритеты в работе предприятий ОАО «ОРКК» и ГК «Роскосмос». II Афанасьевские чтения. Москва, Техномаш, 2016.
[2] Хаммер М., Чампи Дж. Реинжиниринг корпорации: Манифест революции в бизнесе. Москва, Манн, Иванов и Фербер, 2006.
[3] Системы менеджмента качества — требования. Международный стандарт ISO 9001:2015.
[4] Точилов Л.С., Ванюшин В.П., Кречетов А.Ю. Реинжиниринг процесса обращения конструкторской и технологической документации в ракетно-космической организации. Сб. докл. XXXVI Академических чтений по космонавтике. Москва, ОАО «ВПК «НПО машиностроения», 2012, с. 195-201.
[5] Проектный треугольник. URL: https://support.oifice.com/ru-ru/article/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BD %D1%8B%D0%B9-
%D1%82%D1%80%D0%B5%D1%83%D0%B3%D0%BE%D0%BB%D1%8C %D0%BD%D0%B8%D0%BA-8c892e06-d761-4d40-8e1f-17b33fdcf810 (дата обращения 03.11.2016).
Статья поступила в редакцию 15.03.2017
Ссылку на эту статью просим оформлять следующим образом:
Точилов Л.С. Оптимизация моделирующих стендов для изделий ракетно-космической техники в условиях экономического кризиса. Инженерный журнал: наука и инновации, 2017, вып. 5.
http://dx.doi.org/10.18698/2308-6033-2017-5-1612
Статья подготовлена по материалам доклада, представленного на XLI Академических чтениях по космонавтике, посвященных памяти академика С.П. Королёва и других выдающихся
отечественных ученых — пионеров освоения космического пространства.
Москва, МГТУ им. Н.Э. Баумана, 24-27января 2017 г.
Точилов Леонид Сергеевич родился в 1959 г., окончил МГУ им. М.В. Ломоносова в 1982 г. Канд. физ.-мат. наук, ученый секретарь Научно-технического совета ОАО «ВПК «НПО машиностроения». Автор более 100 научных работ в области информационных технологий и менеджмента. e-mail: tochilov@vpk.npomash.ru
Optimizing the simulators for rocket and space technology products under conditions of economic crisis
© L.S. Tochilov
JSC MIC NPO Mashinostroyenia, Reutov town, Moscow region, 143966, Russia
The article considers the actual problem of reducing rocket and space technology (RST) product development costs using the example of the process of control system workout by performing "electronic launches" in terrestrial conditions on simulators of two types: mathematical modeling stands and semi-natural modeling stands. On the example of a simulator a short history of RCT product control system development is considered as well as a variant of their future state as a desirable optimization option. Risk management issues in optimizing the development of control systems for RST products on the simulator are also discussed. The possibility of developing algorithms of on-board digital computer in C ++ language, opening up new opportunities for reengineering the process of RST product control system workout on a simulator is presented as a key technology for simulator optimization. It is shown that some of the obtained results can be useful in developing an approach to optimizing the RSO, which are more acceptable than attempts to apply the concept of the Toyota production system "Lean Manufacturing" under fundamentally different conditions.
Keywords: rocket and space technology, economic crisis, cost optimization, simulating stands, semi-natural modeling stands, mathematical modeling stands, control system, control system algorithms, on-board digital computer, C ++ language, lean manufacturing, Toyota
REFERENCES
[1] Popov P.D. Pervoocherednye zadachi i prioritety v rabote predpriyatiy OAO "ORKK" i GK "Roskosmos" [Primary objectives and priorities in the work of the enterprises of JSC "ORKK" and SC "Roskosmos"]. II Afanasyevskie chteniya [II Afanasyev Scientific Conference]. Moscow, Tekhnomash Publ., 2016.
[2] Hammer M., Champy J. Reengineering the Corporation. A Manifesto for Business Revolution. New York, Harper Collins Inc. Publ., 1993 [In Russ.: Hammer M., Champy J. Reinzhiniring korporatsii: Manifest revolutsii v biznese. Moscow, Mann, Ivanov i Farber Publ., 2006].
[3] Mezhdunarodnyy standart ISO 9001:2015. Sistemy menedzhmenta kachestva -trebovaniya [International standard ISO 9001:2015. Quality management systems - requirements].
[4] Tochilov L.S., Vanushin V.P., KrechetovA.Yu. Reinzheniring protsessa obrashcheniy konstruktorskoy i tekhnologicheskoy dokumentatsii v raketno-kosmicheskoy organizatsii [Reengineering of the process of circulation of design and technological documentation in the rocket and space organization]. Sbornik dokladov XXXVI Akademicheskikh chteniy po kosmonavtike [Proceedings of the XXXVI Scientific Conference on Cosmonautics]. Moscow, JSC MIC NPO Mashinostroyenia, 2012, pp. 195-201.
[5] Proektnyy treugolnik [Design triangle]. Available at: https://support.office.com/ru-
ru/article/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BD %D1%8B%D0%B9-
%D1%82%D1%80%D0%B5%D1%83%D0%B3%D0%BE%D0%BB%D1%8C %D0%BD%D0%B8%D0%BA-8c892e06-d761-4d40-8e1f-17b33fdcf810 (accessed November 03, 2016).
Tochilov L.S. (b. 1959) graduated from Lomonosov Moscow State University in 1982. Cand. Sc. (Phys.-Mat.), Scientific Secretary of the Scientific and Technical Council of JSC MIC NPO Mashinostroyenia. Author of over 100 research publications in the field of information technologies and management. e-mail: tochilov@vpk.npomash.ru
