Изложены основные результаты изучения вопросов о снижении сроков создания новых РЛС ДО. Определен подход по сокращению сроков создания изделия. Проведен функционально-стоимостной анализ процесса отработки. Определены риски методом FMEA внедрения модельно-ориентированного проектирования в процесс разработки.
Ключевые слова: отработка, модельно-ориентированное проектирование (МОП), радиолокационная станция (РЛС) опытно-конструкторская работа (ОКР), функциональное программное обеспечение (ФПО), исходные данные (ИД), риски, функционально-стоимостной анализ (ФСА), системный подход.
ВВЕДЕНИЕ:
При проведении сложного многоэтапного ОКР, например, при разработке радиолокационной станции, работы по проектированию декомпозируются по аппаратному принципу (РЭК1, РЭК2, РЭУ1, РЭУ2, ЭМ0, ЭМ1 и т. д.) [1] или по функциональному принципу (приемная, передающая системы, система синхронизации, система управления и контроля). Второй вариант последнее время более предпочтителен, так как позволяет более проработано сформировать требования и вести верификацию таких требований. Но даже при глубокой проработке процессов формирования требований и верификации, у системы проектирования есть уязвимые места. Самое уязвимое место — это процесс отработки на экспериментальной установке, когда радиолокатор собирается на опытной площадке.
Для окончательно верификации технических требований каждой системы требуется экспериментальная установка (сам радиолокатор), и время на проведение проверок. В то же время из-за большой стоимости экспериментальный опытный образец создается в единичном экземпляре, вследствие чего процесс верификации требований систем на радиолокаторе идет последовательно (см рисунок 1).
Рис. 1. Наглядное представление выстраивания процессов в последовательный вид при переносе работ на объект
На объектовом этапе чаще всего срабатывают риски невыполнения технических требований или невозможности корректного взаимодействия нескольких систем, которые приводят к существенной доработке, что в свою очередь увеличивает сроки вывода образца на предварительные испытания. С другой стороны, скорейшая реализация этих рисков позволяет реактивно реагировать на обнаруженные недостатки и запустить процесс соответствующих доработок.
Для сокращения сроков создания Изделия необходимо либо перенести часть объема верификации систем с объектового этапа на автономный, либо сократить сам объем верификации. Перенос объема верификации на более ранние этапы часто бывает невозможен за счет непредсказуемости последствий такого переноса, основанного на недостаточности экспериментальных и метрологических исследований. Часто перенос на более ранние этапы физически невозможен по причине нехватки времени на этапе автономных и комплексных проверок. Такая ситуация возникает, когда вновь разрабатывается сложный вычислительный модуль, отбирая драгоценное время у разработчиков ФПО. В таком случае неотработанное ФПО отправляется на объект монтажа, и необходимые автономные работы проводятся уже на собранной экспериментальной установке. Такая несвоевременная отработка несет в себе большие технические и финансовые риски, значительное увеличение трудоемкости и чаще всего не приводит к желаемому эффекту сокращения сроков, а скорее наоборот, за счет более сложных условий отработки и более частого изменения условий работы (сборка вновь приходящей аппаратуры, увеличение числа абонентов в сети). Второй способ – сокращение верификации – может значительно увеличить риск ошибок, которые могут очень дорого обойтись в будущем. Чем сложнее разрабатываемая система, тем больше циклов отработки, тем больше станет риск того, что проблемы, обнаруженные на поздних этапах, обойдутся дороже.
Рассмотрим процесс создания системы на примере наиболее длинной цепочки создания приемной системы РЛС ДО. Ее отладка и сопряжение с другими системами РЛС занимает наибольшую часть объектового времени, а значит, она создает наибольший вклад в увеличение срока создания РЛС [2].
Процесс создания приемной системы состоит из создания аппаратной части, автономного создания программно-алгоритмической части и их совместная отработка/отладка. Примерная блок-схема такого процесса для приемной системы представлена на рисунке 2:
Рис. 2. Структурная схема процесса разработки приемной системы
Из рисунка 2 видим, что из общего времени создании в 45 месяцев значительное время занимает процесс отработки аппаратуры с ФПО-18 месяцев, 21 месяц занимает процесс создания образца аппаратуры, процесс автономной разработки ФПО- 15 месяцев, 6 месяцев приходится на контрольные испытания.
Создание радиолокационной станции может быть значительно сокращено за счет макетирования, при условии его инициативного запуска в рамках НИР, но такая практика требует значительных вложений. В то же время такая практика может сократить срок создания ФПО изделия проблематично, так как ФПО пишется под конкретные вычислители, чаще всего, использующие комбинации ПЛИС и процессорных модулей. Поэтому общий срок создания РЛС может быть сокращен в случае предусмотрительного макетирования аппаратуры на 6 месяцев за счет того, что критический путь пойдет по другому пути. Но даже применяя макетирование аппаратуры- срок создания остается значительным- 39 месяцев. Компания-разработчик РЛС не сможет взяться за проект, в котором требуется новая разработка и срок ее создания меньше 39 месяцев, а это условие само по себе снижает количество заказов. Со временем, заказчик хочет все более совершенные локационные системы с новыми возможностями, и за меньший срок, а разработчик не может удовлетворить потребности. Для сокращения сроков необходимо значительно сократить этап разработки ФПО и отработки его на аппаратуре, особенно сокращая процесс объектовой отработки.
Разберем отдельно процесс отработки ПО и его подпроцессы. Сам процесс отработки циклический (см. рисунок 3) на каждом этапе и продолжается до тех пор, пока не будет выполнена проверка. Фактически процесс типовой и повторяемый на разных этапах создания изделия.
Подпроцессы включают в себя следующие этапы (см. рисунок 3):
– запуск ФПО;
– проведение проверок;
– формализация замечаний к ПО и модели алгоритмов;
– корректировка модели;
– корректировка исходных данных (ИД) на доработку ФПО;
–
корректировка ФПО.
Рис. 3. Типовой процесс отработки ПО на аппаратуре
При положительных проверках происходит выход их цикла.
Обратим внимание на процесс отработки, представленный на рисунке 3. На каждом подпроцессе может быть совершена ошибка, приводящая к повторному циклу, которая будет скорее всего выявлена только на операции «проведение проверок»:
– замечания могут быть неправильно трактованы;
– в модели могут быть ошибки, также при корректировке могут возникнуть новые ошибки;
– в ИД из-за человеческого фактора могут быть внесены ошибки;
– при написании программы (из-за человеческого фактора или неверной трактовки ИД).
Значительные замечания, не позволяющие успешно завершить проверку, запускают новый цикл отработки, и на одном этапе отработки происходит 2–3 цикла перед переходом на следующий этап.
На финальных стадиях отработки (в составе Изделия в целом) до проведения положительных испытаний в системе невозможно проводить никакие другие работы с другими системами, так как завершающая отработка выполняется на одной экспериментальной установке — на собранном Изделии.
Для того, чтобы оценить возможность доработки процесса отработки проведем функционально-стоимостной анализ [3] подпроцессов отработки, где значимость функции будет ее польза для процесса верификации требования (в % от общего объема), а стоимость- затраченное на проведение операции время (в % от времени цикла отработки)
А. Выявляем компонентный состав процесса ФПО:
– запуск ФПО;
– проведение проверок;
– формализация замечаний к ФПО и модели;
– корректировка модели;
– корректировка ИД на ФПО;
– корректировка ФПО.
Б. Определяем функции и назначаем значимость
«Запуск ФПО» включает ФПО 10 % F1
«Проведение проверок» оценивает достигнутые изделием характеристики и проводит сбор информации к анализу -40 % F2
«Формализация замечаний к ПО и модели» анализирует данные и позволяет сформировать задачи как достигнуть необходимые характеристики 20 % F3
«Корректировка модели» процесс корректировки и валидации на модели результатов 20 % F4
«Корректировка ИД на ФПО» – процесс разработки и передачи данных от алгоритмиста для работы программиста 5 % F5
«Корректировка ФПО»- процесс переноса алгоритмов в код с компиляцией исполняемых файлов 5 % F6
В. Определяем затраты времени на каждую функцию.
Запуск ФПО F1 12,5 %
Проведение проверок F2 37,5 %
Формализация замечаний к ФПО и модели F3 12,5 %
Корректировка модели F4 12,5 %
Корректировка ИД на ФПО F5 12,5 %
Корректировка ФПО F6 12,5 %
Г. Построим соотношение значимости и стоимости (рисунок 4):
Рис. 4. Значимость процесса к затратам времени
Из рисунка 4 видно, что F5, F6 тратят времени больше, чем значат: корректировка ИД и доработка ПО в процессе отработки являются процессами, которые по сути являются «накладными»: когда на модели выявлена ошибка, процесс оформления корректировки фактически является обязательной рутиной.
Процесс корректировки ИД (F5) и разработки ПО по алгоритмам (F6) можно сократить, применив модельно-ориентированное проектирование (МОП), используя современные средства разработки синтезируемых моделей, в которых непосредственно из модели генерируется исполняемый на микросхемах код [4]. Это улучшение также уменьшит количество циклов отработки за счет уменьшения ошибок, вносимых исключаемыми подпроцессами.
В случае применения технологии модельно-ориентированного проектирования ожидается сокращение каждого этапа отработки с 4 месяцев до 1–2 месяцев, что даст экономию по срокам в проекте 6–9 месяцев. С другой стороны, внедрение данной технологии – инновация, которая сопряжена с рисками [5], но при условии успешного внедрения приведет к значительному выигрышу в сроках.
Применяя системный подход, проведем наглядную оценку рисков методом FMEA [6], возникающих при внедрении процесса разработки с помощью МОП и сравним с рисками, возникающими при классическом подходе. В таблице 1 оценены основные риски при классическом подходе и меры, которые можно предпринять для снижения рисков.
Таблица 1
Риски классического подхода разработки ПО
В таблице 2 расписаны основные риски при МОП-подходе и меры, которые можно предпринять для снижения рисков.
Таблица 2
Риски подхода разработки с применением МОП
Видно, что при применении МОП риск выше (2493 очка против 2322), но при проведении операций по смягчению рисков проект применения МОП становится менее рискованным (921 с применением МОП против 1767 без МОП) за счет двух основных факторов:
– невозможность технической реализации и неготовность компании к инновации может быть проверена на основе пилотного проекта;
– риск срыва сроков реализации может быть снижен за счет привлечения специалистов компании-поставщика продукта, проводящего тренинги и имеющего опыт внедрения.
Внедрение МОП позволяет в значительной мере снизить сроки проектирования для технологических предприятий, занимающихся разработкой, где срок создания является конкурентным преимуществом.
Для принятия решения о целесообразности применения подхода МОП на каждом отдельно взятом предприятии необходимо оценить экономические выгоды от инновации, а также свои внутренние риски от внедрения, в том числе готовность руководства предприятия к поддержке.
Литература:
- ГОСТ Р 52003–2003 Уровни разукрупнения радиоэлектронных средств. Термины и определения
- Foundations of Software Testing ISTQB Certification Rex Black, van Veenendaal Erik, Graham Dorothy, издательство Cengage Learning, 2012г., 3-е издание
- Г. С. Альтшеллер., Б. Л. Злотин, А. В. Зусман, В. И. Филатов «Поиск новых идей- от озарения к технологии»/ Кишинев, Картя Молодовеняске, 1989г.
- Что такое Hardware-in-the-Loop или HIL?. — Текст: электронный // ЦИТМ «Экспонента”: [сайт]. — URL: https://hub.exponenta.ru/post/chto-takoe-hardware-in-the-loop-ili-hil683 (дата обращения: 20.01.2021).
- Климов А. М. Доклад «Анализ необходимости внедрения МОП и смягчение рисков при проектировании РЛС ДО ", VII Всероссийская конференция Технологии разработки и отладки сложных технических систем, 2020 г. / А. М. Климов. — Текст: электронный // ЦИТМ «Экспонента”: [сайт]. — URL: https://exponenta.ru/events/session-radar-rti (дата обращения: 20.01.2021).
- D950–10446–1 Rev. A Systems Engineering Process Manual
