Важнейшей составляющей жизненного цикла программного продукта является этап, предшествующий написанию кода. При этом одна из главных проблем – требования к будущему приложению: ошибки, допускаемые при их выявлении и формализации, имеют, с одной стороны, высокую цену устранения, а с другой – большую частоту встречаемости в реальных проектах [1–3].
В статье рассмотрена работа с регистрируемыми значениями параметров, прямо или косвенно относящихся к описанию динамики полета летательного аппарата (ЛА). Такие данные записываются системами бортовых измерений (СБИ), системами объективного контроля ЛА и некоторыми другими. Результатом записи является таблица, содержащая временные ряды (функцию зависимости от времени) по каждому из параметров.
Автоматизированная обработка табличных временных рядов осуществляется в испытаниях ЛА, летных и полунатурных исследованиях с середины прошлого века.
Многие десятилетия размер исходных данных практически не меняется: ориентировочный объем записи летного эксперимента начала 1960-х гг. (до 100 столбцов и 180 тыс. строк [4]) актуален и в настоящее время. При этом принципиально выросли возможности извлечения полезной информации из экспериментальных данных [5], что обусловлено ростом производительности и памяти вычислительной техники в совокупности с улучшением эргономики компьютеров и их программ.
Сегодня важнейшую роль в обработке данных играют возможности используемой специалистом программной среды. Большинство современных инструментов реализуют идеологию WYSIWYG (сокращение от what you see is what you get, или что ты видишь, то и получаешь). Существуют мощные программные продукты, обеспечивающие простой и удобный для пользователя вызов разнообразных встроенных алгоритмов обработки данных. Эти возможности совмещены с поэлементными настройками отображения данных на графиках, вводом данных из файлов различных форматов и многими другими полезными опциями.
Обработка полетной информации состоит из довольно специфичного набора действий с данными. При всех достоинствах современных сред обработки информации ни одна из них не является хорошим решением для всего перечня задач. Подобная ситуация не уникальна. Существование общей проблемы использования унифицированного ПО в организациях научно-исследовательского профиля отмечено в исследовании специалистов Иркутского национального исследовательского технического университета [6]. В качестве иллюстрации этого тезиса можно рассмотреть пример обработки информации в химико-технологической системе [7]: для решения практической задачи потребовалось использование четырех программных сред – TableCurve 2D, TableCurve 3D, MATLAB и Enterprise Workbench 2k.
Стоит отметить, что большинство отдельно взятых задач обработки полетной информации имеют хорошее решение минимум в одном из существующих приложений.
Идеальная программная среда должна объединять в себе определенные возможности нескольких уже существующих систем. Это важно с точки зрения проблемы формирования требований: наличие готового примера реализации не заменит удачную формулировку желаемых свойств системы, но послужит их наглядной иллюстрацией.
Рассмотрим более детально конкретные задачи обработки полетных данных.
Фильтрация данных таблицы по заданному критерию. Данная задача позволяет определять строки, для которых вектор мгновенного состояния системы (режим полета ЛА) соответствует заданным условиям.
Пример: поиск режимов полета, соответствующих висению вертолета вне зоны влияния земли. Задача решается проверкой составного условия по параметрам, отражающим геометрическую высоту (данные радиовысото- мера) и составляющие вектора скорости (данные внешнетраекторных измерений). Уточ- нение задачи (например, висение вне зоны влияния земли правым боком к ветру с заданным качеством стабилизации) добавляет новые условия фильтрации.
Существующие приложения: MS Excel.
Визуализация динамики процесса на графике зависимости параметра от времени. Пример: построение графика изменения параметров полета ЛА после выведения его из состояния сбалансированного полета импульсным управляющим воздействием. На рисунках 1 и 2 приведены записи режимов «импульс ручкой циклического шага», выполненных на вертолете Ка-52Э в ходе летного эксперимента. Ручка отклонялась летчиком соответственно от себя и на себя (положение ручки характеризуется величиной Хв). Визуализация позволяет оценить поведение вертолета в первые секунды свободного движения. Здесь показаны приборная скорость Vпр и угол тангажа υ. На практике рассматриваются и другие регистрируемые и расчетные параметры.
Существующие приложения: PTC MathCad, Ivan Johansen Graph, Alentum Software Advanced Grapher, FBK Studio Software Grapher.
Добавление производных временных рядов (сглаживающие, интегрирующие, дифференцирующие ряды, ряды расчетных значений физических величин, не регистрировавшихся СБИ или нуждающихся в проверке точности регистрации).
Пример: добавление к данным рисунка 2 расчетных значений угловой скорости движения вертолета в продольном канале (рис. 3).
Существующие приложения: интерполяция и аппроксимация – Systat Software TableCurve 2D, ряды расчетных значений по формулам пользователя – MS Excel.
Визуализация данных на графике зависимости параметра от другого параметра. Пример: проверка корректности регистрируемых значений параметра построением функциональной зависимости регистрируемого и расчетного значений. На рисунке 4 показана проверка регистрации СБИ самолета Да-42Т значений угла атаки (α). Положительный результат проверки соответствует группированию облака точек вблизи линии у = х (значение первого коэффициента уравнения регрессии близко к 1, второго – к 0, коэффициента детерминации – к 1). Очевидно, что представленные данные иллюстрируют некорректную работу СБИ.
Существующие приложения: PTC MathCad, Ivan Johansen Graph, FBK Studio Software Grapher.
Определение значения обобщающего расчетного показателя на основе всей записи или ее фрагмента (режима). Пример: определение балансировочного положения органа управления для заданных условий по данным выполнения режима «площадка». Режим характеризуется постоянством скорости, высоты и углового положения вертолета (все силы и моменты, действующие на вертолет, скомпенсированы). На рисунке 5 приведена одна из балансировочных характеристик вертолета Ка-52Э, построенная по результатам испытаний. Значение параметра Хв для каждой точки графика получено обработкой записи отдельного режима полета.
Существующие приложения: MS Excel, PTC MathCad.
Определение взаимосвязей между параметрами, построение моделей множественной линейной и нелинейной регрессии. Пример: построение модели движения вертолета в продольном канале путем вычисления значений коэффициентов дифференциального уравнения движения вертолета (коэффициенты демпфирования, эффективности управления и устойчивости по скорости).
На рисунке 6 приведены данные для оценки адекватности модели движения вертолета Ка-52Э в продольном канале, полученной на основе множественной линейной регрессии по массиву из нескольких десятков тысяч точек. Очевидно, что исследуемая модель не демонстрирует высокое качество, воспроизводя с высокой точностью лишь первую реакцию на интенсивное возмущение входного сигнала. Для повышения точности модели требуется усложнение ее вида.
Существующие приложения: множественная линейная регрессия для произвольного числа аргументов – Dell Statistica или MS Excel с расширяющим пакетом «Анализ данных», множественная нелинейная регрессия для функции двух аргументов – Systat Software TableCurve 3D, множественная нелинейная регрессия с числом аргументов более двух требует написания дополнительного кода для расширения готовых программных продуктов, например, на языке visual basic for applications для MS Excel.
Приведенный перечень представляет основные функциональные требования к програм- мной среде обработки полетных данных.
Список требований, отталкивающихся от достоинств существующих систем, следует дополнить списком требований, отталкивающихся от их недостатков:
- программная среда должна работать с файлами максимального размера (ограничения приведены выше);
- программная среда должна обеспечивать быстрое (насколько позволяет аппаратная со- ставляющая) выполнение вычислений;
- взаимодействие пользователя с графическим интерфейсом должно быть построено в соответствии с эргономическим принципом «наименьшего удивления».
Важнейшим требованием к создаваемой системе следует считать приспособленность к итерационному наращиванию функционала. Ни один список требований не может считаться исчерпывающим, поскольку в перспективе неизбежно появятся новые потребности, например, по использованию искусственных нейронных сетей. Для обеспечения простоты доработок архитектура системы должна быть модульной. В ее основе следует использовать решения, показавшие эффективность в управлении сложностью кода.
Исходя из имеющегося перечня требований, целесообразно для реализации системы использовать язык программирования C++. Этот язык является одним из лучших по быст- родействию и экономии памяти [8], что имеет важное значение, например, для решения ре- грессионных задач с большими входными данными на компьютерах, не обладающих высокими техническими характеристиками. Кроме того, он поддерживает объектно-ориентированное программирование с его концепциями, обеспечивающими модульность и повторное использование кода [9]. C++ поддерживает применение набора проверенных решений в организации кода – паттернов проектирования. В частности, для создания приложений рассматриваемой категории применяется архитектура «модель–вид–контроллер», реализуемая применением паттернов «наблюдатель», «компоновщик» и «стратегия» [10].
Программное решение для размещения данных (компонента «модель») следует искать прежде всего среди стандартных контейнеров C++. Наиболее подходящим из них представляется vector. Размещением данных каждого ряда внутри своего объекта vector обеспечивает, с одной стороны, гибкость в использовании памяти, а с другой, высокую скорость случайного (произвольного) доступа [11]. Максимальное количество элементов ряда при использовании контейнера vector ограничивается только памятью компьютера.
Сами ряды целесообразно реализовать в виде объектов пользовательского класса, основа которого показана в листинге:
#include //для использования контейнера vector
#include //для использования строк string
class Row
{
public:
//настройка названия ряда:
void setName (string paramName);
//присвоение значения val элементу ряда с номером itemNum:
void setValue (double val, int itemNum);
//добавление нового элемента со значением val в конец ряда:
void addValue (double val);
//функции выдачи названия ряда и значения его элемента по номеру:
string getName ();
double getValue (int numberOfVal);
/*Здесь находятся другие необходимые функции,
в том числе конструкторы и деструктор*/
protected:
string name; //имя ряда данных
vector data; //ряд данных – вещественных чисел
};
Для поля Row::data выбран тип double, поскольку подавляющее большинство регистрируемых параметров имеют вещественный тип. Целочисленные данные, включая логические «0» и «1», встречаются гораздо реже, поэтому случаи неявного приведения типов не окажут существенного влияния на экономию памяти.
Дополнительная открытая функция Row::addValue(), изменяющая поле Row::data, предназначена для вызова внешним кодом при заполнении пустого ряда значениями. Пример такой ситуации – заполнение значениями, считываемыми построчно из файла исходных данных.
Выбор контейнера для размещения самих объектов класса Row в меньшей степени влияет на эффективность программы, поскольку количество этих объектов (столбцов таблицы) обычно на два-три порядка меньше количества элементов поля Row::data (количества строк). Если в случае реализации поля Row::data определяющим фактором является скорость случайного доступа к элементам данных, то для контейнера, вмещающего сами объекты класса Row, может быть важна также скорость вставки и удаления элементов, что делает предпочтительным шаблон list. Окончательное решение должно быть принято по результатам проработки альтернативных вариантов.
Заключение
На основе практического опыта анализа полетной информации сформулированы требования к программной среде автоматизированной обработки полетных данных в терминах предметной области. Задачи создаваемой системы соотнесены с примерами существующих систем, подтвердивших свою практическую применимость.
Составленный список общих задач системы следует использовать для выработки требований в терминах программирования и их реализации в коде проекта. Приведенные рекомендации целесообразно использовать в архитектуре проекта.
Литература
1. Гутгарц Р.Д., Провилков Е.И. О формализации функциональных требований в проектах по созданию информационных систем // Программные продукты и системы. 2019. № 3. С. 349–357. DOI: 10.15827/0236- 235X.127.349-357.
2. Wiegers K., Beatty J. Software Requirements. USA, Microsoft Press, 2013, 637 p.
3. Макконнелл С. Совершенный код. Практическое руководство по разработке программного обеспечения. М., 2010. 896 с.
4. Кантор А.В. Аппаратура и методы измерений при испытаниях ракет. М., 1963. 520 с.
5. Еремин Е.М., Атрошенко А.И., Антошин А.А., Дроздовский А.Ю. Определение пилотажных характеристик модели вертолета авиационного тренажера КТ-8АМТШ // Проблемы безопасности полетов. 2019. № 1. С. 10–17.
6. Гутгарц Р.Д., Полякова П.М. Анализ особенностей формулирования функциональных требований к автоматизированной информационной системе // Программные продукты и системы. 2019. № 3. С. 358–367.
7. Кузнецов А.С., Корнюшко В.Ф. Математические модели реограмм состояния в программах Table Curve 2D/3D как основа интеллектуальной системы управления процессами структурирования многокомпонентных эластомерных композитов // Программные продукты и системы. 2017. № 4. С. 770–777. DOI: 10.15827/0236-235X.120.0.
8. Pereira R., Couto M., Ribeiro F., Rua R., Cunha J., Fernandes J.P., Saraiva J. Energy efficiency across programming languages. How do energy, time, and memory relate. Proc. 10th ACM SIGPLAN Intern. Conf. on SLE, Vancouver, Canada, 2017, pp. 256–267.
9. Спролл А. Думай как программист: креативный подход к созданию кода. C++ версия. М., 2018. 272 с.
10. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Д. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб, 2019. 368 с.
11. Лафоре Р. Объектно-ориентированное программирование в C++. СПб, 2019. 928 с.
References
- Gutgarts R.D., Provilkov E.I. On the formalization of functional requirements in information system projects. Software & Systems, 2019, vol. 32, no. 3, pp. 349–357 (in Russ.). DOI: 10.15827/0236- 235X.127.
349-357.
- Wiegers K., Beatty J. Software Requirements. USA, Microsoft Press, 2013, 637 p.
- McConnell S. Code Complete: A Practical Handbook of Software Construction. USA, Washington:
Microsoft Press, 2004, 960 p. (Russ. ed.: Мoscow, 2010, 896 p.).
- Kantor A.V. Instrumentation and Measurement Methods for Missile Tests. Moscow, 1963, 520 p.
(in Russ.).
- Eremin E.M., Atroshenko A.I., Antoshin A.A., Drozdovsky A.Yu. Determination of flight characteristics of the flight simulator KT-8AMTSH helicopter model. Flights Safety Troubles, 2019, no. 1, pp. 10–17
(in Russ.).
- Gutgarts R.D., Polyakova P.M. Analysis of formulation features of functional requirements to an automated information system. Software & Systems, 2019, vol. 32, no. 3, pp. 358–367 (in Russ.).
- Kuznetsov A.S., Kornyushko V.F. Mathematical models of rheograms of states in Table Curve 2d/3d programs as a basis of the intelligent system for managing structuring processes of multicomponent elastomer composites. Software & Systems, 2017, vol. 30, no. 4, pp. 770–777 (in Russ.). DOI: 10.15827/0236-235X.120.0.
- Pereira R., Couto M., Ribeiro F., Rua R., Cunha J., Fernandes J.P., Saraiva J. Energy efficiency across programming languages. How do energy, time, and memory relate. Proc. 10th ACM SIGPLAN Intern. Conf. on SLE, Vancouver, Canada, 2017, pp. 256–267.
- Spraul A. Think Like a Programmer: An Introduction to Creative Problem Solving. Edwards Brothers Malloy Publ., 2012, 315 p. (Russ. ed.: Мoscow, 2018, 272 p.).
- Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison–Wesley Publ., 1995, 395 p. (Russ. ed.: St. Petersburg, 2019, 368 p.).
- Lafore R. Object-Oriented Programming in C++. Indianapolis, Sams Publ., 2002, 1040 p. (Russ. ed.: St. Petersburg, 2019, 928 p.).