CC BY
10
4. Описание протокола NMEA-0183 [Электронный ресурс]. URL: https://wiki.iarduino.ru/page/NMEA-0183 (дата обращения: 16.05.2023).
5. Силкин, А. А. Автоматизированная система управления БПЛА в пределах локальной системы позиционирования / А. А. Силкин, А. Н. Ивановский, С. Г. Черный // Состояние и перспективы развития современной науки по направлению "Робототехника" : Сборник статей IV Всероссийской научно-технической конференции, Анапа, 20-21 июля 2022 года. Анапа: Федеральное государственное автономное учреждение "Военный инновационный технополис "ЭРА", 2022. С. 224-235. EDN WTLPIU.
Дурманов Максим Анатольевич, канд. техн. наук, доцент, madurmanov@sevsu. ru, Россия, Севастополь, Севастопольский государственный университет,
Сметанина Ольга Николаевна, канд.пед.наук, доцент, scorpion19.11@yandex.ru, Россия, Керчь, Керченский государственный морской технологический университет
INCREASING THE ACCURACY OF POSITIONING ON THE BASIS OF CORRECTION OF GEODATA
M.A. Durmanov, O.N. Smetanina
The article ways to improve positioning accuracy through a number of measures for filtering for the received navigation signal are considered. To improve positioning accuracy, a station for calculating correction factors is being introduced, the principle of operation of which is based on the differential positioning method. Based on the results of experimental, a decrease in the positioning error from 10 m (with standard settings of the satellite navigation module) to 1 m is shown.
Key words: error, positioning, global satellite navigation system, filtering, environmental monitoring.
Durmanov Maksim Anatol'evich, candidate of technical sciences, docent, madurmanov@sevsu. ru, Russia, Sevastopol, Sevastopol State University,
Smetanina Olga Nikolaevna, candidate of technical sciences, docent, scorpion19.11@yandex. ru, Russia, Kerch, Kerch State Marine Technological University
УДК 004
DOI: 10.24412/2071-6168-2023-5-100-101
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ОТРАБОТКИ НАВЫКОВ РАБОТЫ С СОВРЕМЕННЫМИ УСТРОЙСТВАМИ КОММУТАЦИИ И ЦИФРОВЫМИ СИСТЕМАМИ
ОБРАБОТКИ СИГНАЛОВ
З.В. Лященко, О.В. Игнатьева, А.М. Лященко, Д.В. Глазунов
В статье разработано программное обеспечение для отработки навыков работы с современными устройствами коммутации. Предложены исходные данные расчетов метрик, определены значения коэффициентов регулировки сложности программного обеспечения. Выявлены пять основных характеристик FP метрики: внутренний логический файл (ILF, Internal Logical File), внешний интерфейсный файл (EIF, External Interface File), внешние вводы (EI, External Input) и (EO, External Output), внешний запрос (EQ, External Inquiry). Определена общая характеристика масштабных факторов Wi. Рассчитаны формирователи затрат для раннего этапа проектирования. Разработанное программное обеспечение предназначено для студентов учебных учреждений, изучающих дисциплины, связанные с телекоммуникационными системами и сетями.
Ключевые слова: программное обеспечение, компьютерный тренажер, метрика, ввод, вывод, цифровые системы, масштабные факторы, автоматизация.
В современном мире вопрос разработки программного обеспечения имеет большое значение, так как все больше растет потребность в создании новых инструментов, направленных на автоматизацию деятельности предприятий, улучшение эффективности работы бизнес-проектов, повышение производительности труда или обучения. При этом часто необходимо, чтобы разрабатываемый продукт выполнял ряд определенных, специфических задач и функций, которые недоступны в большинстве стандартизированных программ.
Разработка программных средств направлена не только на внедрение в различные организации. Существует необходимость использования компьютерных технологий в образовательной сфере для проведения учебных занятий. С их помощью возможно наглядно продемонстрировать, как работает тот или иной процесс, произвести над моделью изучаемого объекта некоторые действия, обучить определенным навыкам, необходимым для дальнейшей работы уже с настоящим оборудованием.
100
Компьютерные тренажеры различного рода повсеместно применяются во многих крупных организациях и учебных заведениях. В данной выпускной квалификационной работе произведена разработка симулятора АТС-станции, который может использоваться в процессе обучения для выполнения лабораторных, практических, графических работ и контроля знаний.
Целью данной работы является разработка программного обеспечения лабораторного комплекса для отработки навыков работы с современными устройствами коммутации и цифровыми системами обработки сигналов. Приложение реализуется на основе готовой 3D-модели IP-АТС Panasonic NSP500, созданной в программе Blender, и предназначено оно для студентов образовательных учреждений.
При создании любого продукта важной составляющей является предварительная оценка стоимости его разработки. Как правило, это происходит на этапе проектирования системы, что позволяет клиенту дать представление о количестве времени и финансов, которые будут затрачены на заказ.
В разработке программных средств для подобных расчетов применяются различные методики, называемые метриками программного обеспечения. Это мера характеристик, которые поддаются измерению или подсчету и отражают спектр свойств будущей программы. Данные показатели являются мощным инструментом для управления процесса разработки, обеспечивая количественную и объективную основу для принятия технологических решений. Они ценны по многим причинам, в том числе для измерения производительности разрабатываемого ПО, планирования рабочих моментов и многих других целей.
Наиболее часто используемыми являются размерно-ориентированные (LOC) и функционально-ориентированные (FP) метрики.
Размерно-ориентированные (LOC, Line of code) метрики направлены на измерение характеристик программы в зависимости от ее объема, а именно от количества строк исполняемого кода. Данная метрика довольно проста в вычислениях, однако не является точной и обрабатывается по-разному в различных организациях. Проблема также заключается в том, что нет точного соглашения, какие строки считать, а какие нет. В частности, это касается подсчета строк комментариев, необходимых для документации. Программисты могут написать гораздо больше строк, чем необходимо, таким образом повысив свою производительность. Однако, если не учитывать строки комментариев, общая стоимость и стоимость обслуживания увеличится из-за отсутствия документации. Кроме того, количество комментариев варьируется в зависимости от стиля программирования разработчиков, правил документации организации и используемого языка. [5]
Функциональные точки (FP, Function Points) дают оценку размера программной системы путем измерения функциональных возможностей, которые система предлагает пользователю. Этот показатель применим как в начале процесса разработки, на этапах требований или спецификаций, так и в конце процесса, после внедрения. Важность FP заключается в том, что их можно использовать для оценки стоимости проекта разработки ПО с учетом требований или спецификации, поскольку данная методика сильно коррелируют с рабочим временем. Основная проблема с FP заключается в том, что они не полностью независимы от человека, выполняющего подсчет. [6]
Результат, полученный при использовании FP метрик, может быть переведён в LOC оценку и наоборот. B виду отсутствия большого опыта разработки приложений, логично использовать на начальном этапе FP метрику. B этом случае учитываются пять основных характеристик:
1 Внутренний логический файл (ILF, Internal Logical File). Это группа связанных данных, находящихся в базе или файловой системе, поддерживаются вводом извне.
2 Внешний интерфейсный файл (EIF, External Interface File). Это группа связанных данных, находящихся вне границ приложения и являющихся внутренним логическим файлом для другого приложения.
3 Внешний ввод (EI, External Input). Это транзакция, которая обеспечивает перемещение данных в систему извне (из другого приложения или пользовательский ввод).
4 Внешний вывод (EO, External Output). Это транзакция, которая обеспечивает перемещение данных из системы (пользователю или другому приложению). В общем случае это результаты каких-то вычислений, выполненные приложением.
5 Внешний запрос (EQ, External Inquiry) — транзакция, обеспечивающая одновременный ввод и вывод. В результате информация возвращается из одного или более внутреннего и внешнего файла. При этом внешний интерфейсный файл не содержит производных данных, а внутренний логический файл не обновляется.
В данном случае внутренних логических файлов, внешних интерфейсных файлов, внешних выводов и внешних запросов нет. Что касается внешних вводов, к ним можно отнести:
— ввод номера на странице набора номера (1 поле);
— задание количества цифр в номере во вкладке «Конфигурация АТС» (1 поле);
— задание префикса станции во вкладке «Конфигурация АТС» (1 поле);
— задание номера коммутатора во вкладке «Конфигурация АТС» (1 поле);
— задание первой цифры выхода на спецслужбы во вкладке «Конфигурация АТС» (1 поле);
— задание бесплатных спецслужб во вкладке «Конфигурация АТС» (2 поля).
Исходные данные расчетов метрик представлены в таблице 1.
Таблица 1
Исходные данные расчетов метрик_
Наименование параметра Ранг, сложность, количество
Низкий Средний Высокий Итого
Внешние вводы (Е1) 7*3 0 0 21
Внешние выводы (ЕО) 0 0 0 0
Внешние запросы (EQ) 0 0 0 0
Внутренние логические файлы (ШБ) 0 0 0 0
Внешние логические файлы (Е1Б) 0 0 0 0
Основное уравнение для расчета функциональных точек FP имеет вид:
РР = Общее количество • (0,65 + 0,01 • ^^р.), (!)
где - коэффициенты регулирования сложности.
Коэффициенты сложности могут принимать следующие значения:
0 (нет влияния);
1 (случайное влияние);
2 (небольшое влияние);
3 (среднее влияние);
4 (важное влияние);
5 (основное влияние).
Значения коэффициентов регулировки сложности представлены в таблице 2.
Таблица 2
Значения коэффициентов регулировки сложности__
№ Системный параметр Описание Коэффициент
1 Передачи данных Сколько средств связи требуется для передачи или обмена информацией с приложением или системой? 2
2 Распределённая обработка данных Как обрабатываются распределенные данные и функции обработки? 0
3 Производительность Нуждается ли пользователь в фиксации времени ответа или производительности? 0
4 Распространённость используемой конфигурации Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? 0
5 Скорость транзакции Как часто выполняются транзакции? 3
6 Оперативный ввод данных Какой процент информации надо вводить в режиме онлайн? 1
7 Эффективность работы конечного пользователя Приложение проектировалось для обеспечения эффективной работы конечного пользователя? 5
8 Оперативное обновление Как много внутренних файлов обновляется в онлайновой транзакции? 0
9 Сложность обработки Выполняет ли приложение интенсивную логическую или математическую обработку? 2
10 Повторная используемость Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? 0
11 Лёгкость инсталляции Насколько трудны преобразование и инсталляция приложения? 0
12 Лёгкость эксплуатации Насколько эффективны и/или автоматизированы процедуры запуска, резервирования, восстановления? 0
13 Разнообразные условия размещения Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? 2
14 Простота изменений Была ли спроектирована, разработана и поддержана в приложении простота изменений? 0
14 1' = 15
Расчет в соответствии с формулой 1:
FP = 21 • (0,65 + 0,01 • 15) = 16,8. Так как количество функциональных указателей не может быть дробным, округляем и получаем РР = 17.
Далее вычислим количество строк кода в соответствии с формулой 2:
LO = РР • к, (2)
где к — коэффициент перевода.
В таблице 3 приведено количество операторов на один РР для разных языков программирования.
Так как в таблице нет данных для языка С#, возьмем значение для объектно-ориентированного языка Java, равное 53. Тогда в соответствии с формулой 2.
ЮС = 17 * 53 = 901.
Согласно данным вычислениям, количество строк кода в программном продукте равно 901.
Таблица 3
Количество операторов на один FP_
Язык программирования Количество операторов на один FP
Ассемблер 320
C 128
Кобол 106
Фортран 106
Паскаль 90
C++ 64
Java 53
Ada 95 49
Visual Basic 32
Visual C++ 34
Delphi 29
HTML3 15
Prolog 54
Перейдем к расчету затрат согласно формуле 3:
ЗАТРАТЫ = А • Ме • РАЗМЕР®, (3)
где А - масштабный коэффициент, имеет значение 2,5; РАЗМЕР - размер ПО, выраженный в тысячах LOC; Ме - множитель поправки, зависит от 7 формирователей затрат, характеризующих продукт, процесс и персонал; В - отражает нелинейную зависимость затрат от размера проекта.
Показатель степени В зависит от пяти масштабных факторов и вычисляется по формуле 4.
ВВ = 1,01 + 0,012^=1 Ш. (4)
Общая характеристика масштабных факторов Wi приведена в таблице 4.
Таблица 4
Характеристика масштабных факторов__
№ Масштабный фактор Пояснение Щ
1 Предсказуемость, наличие прецедентов (PREC) Отражает предыдущий опыт организации в реализации проектов этого типа. Очень низкий (=5) показывает отсутствие опыта. Сверхвысокий (=0) показывает, что организация полностью знакома с данной областью 5 (отсутствие опыта)
2 Гибкость разработки (FLEX) Отражает степень гибкости процесса разработки. Очень низкий (=5) значит, что используется заданный процесс. Сверхвысокий (=0) значит, что клиент установил только общие цели 0 (клиент установил только общие цели)
3 Разрешение рисков в архитектуре (RESL) Отражает степень выполняемого анализа риска. Очень низкий (=5) значит малый анализ. Сверхвысокий (=0) значит полный и сквозной анализ риска 4(низкое)
4 Связность группы (TEAM) Отражает, насколько хорошо разработчики группы знают друг друга и насколько удачно они совместно работают. Очень низкий (=5) означает очень трудные взаимодействия. Сверхвысокий, (=0) означает интегрированную группу, без проблем взаимодействия 0 (выполняет один человек)
5 Зрелость процесса (РМАТ) Отражает зрелость процесса в организации 4 (низкое)
5 = 13 i=1
Расчет в соответствии с формулой 4.
В = 1,01 + 0,01 • 13 = 1,14 Параметр множитель поправки Ме зависит от набора формирователей затрат ЕМЬ представленных в таблице 5.
Таблица5
Формирователи затрат для раннего этапа проектирования_
Обозначение Название ЯМ,-
1 2 3
PERS (Personnel Capability) Возможности (способности) персонала Средние способности = 1
RCPX (Product Reliability and Complexity) Надёжность и сложность продукта Несложный продукт = 0,5
RUSE (Required Reuse) Требуемое повторное использование Среднее = 1
PDIF (Platform Difficulty) Трудность (сложность) платформы Средняя платформа = 1
PREX (Personnel Experience) Опытность персонала Мало опытный (студент) = 1,5
FCIL (Facilities) Средства поддержки Среднее = 1
SCED (Schedule) Сроки Сроки средние = 1
7 Me = ^ ЯМ; = 1 • 0,5 • 1 • 1 • 1,5 • 1 • 1 = 0,75
Тогда в соответствии с формулой 3.
ЗАТРАТЫ = 2,5 • 0,75 • 0,901х'14 = 1,7
Таким образом, один человек может выполнить поставленную задачу примерно за 1,7 месяца.
В результате разработано программное обеспечение лабораторного комплекса для отработки навыков работы с современными устройствами коммутации и цифровыми системами обработки сигналов. Созданное программное средство относится к обучающим симуляторам. Данная разработка предназначена для студентов учебных учреждений, изучающих дисциплины, связанные с телекоммуникационными системами и сетями, и позволяет исследовать систему устройств, обеспечивающих автоматическое соединение и поддержание телефонной связи между абонентами.
В процессе разработки приложения были получены следующие результаты:
- произведен анализ предметной области, позволивший выявить преимущества и недостатки разработки индивидуального программного обеспечения, а также сферы применения симуляторов для обучения;
- составлено техническое задание на разработку системы, в котором отражены требования к программе и ее функционал;
- произведен анализ и сравнение существующих программных средств, используемых в разработке, что позволило обосновать выбор этих средств для дальнейшей реализации приложения;
- произведена оценка рисков при разработке программного обеспечения на основе FP и LOC-
метрик;
- определены необходимые требования с использованием модели прецедентов, построена UML-диаграмма прецедентов;
- реализованы системные операции приложения и на их основе построена UML-диаграмма последовательности;
- описана структура программы, приведено описание всех окон, рассмотрен их функционал;
- поэтапно описан процесс программной реализации в среде Unity;
- детально описано руководство для пользователя.
При последующем дополнении возможно добиться более подробной симуляции рабочего процесса, расширить функционал программы, а именно: расширить список доступных устройств, используемых в IP-телефонии, обеспечить возможность перемещения элементов в пределах рабочей области и подключения между собой различными способами, добавить модуль проверки полученных знаний, например, на основе тестирования.
Список литературы
1. Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения. СПб.: Питер, 2012. 608 с.
2. Маккарти Д., Маккарти М. Правила разработки программного обеспечения = Dynamic of Software Development: практ. рук. : пер. с англ. М.: Русская ред.; М.; СПб.: Питер, 2007. 220 с.
3. Доманский В.В. Инженерия программного обеспечения: учеб. пособие. Ростов н/Д: РГУПС,
2019. 69 с.
4. Максименкова О.В. Симуляторы и тренажеры в профессиональном образовании: педагогические и технологические аспекты / О.В. Максименкова, Ф.Ф. Дудырев Ф.Ф. // Вопросы образования.
2020. С. 255-276.
5. Черткова Е.А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО. М.: Издательство Юрайт, 2019. 147 с.
6. Маран М.М. Программная инженерия: учебное пособие для вузов. 2-е изд., стер. Санкт-Петербург: Лань, 2021. 196 с.
7. Буч Г. Язык UML. Руководство пользователя : пер. с англ. / Г. Буч, Д. Рамбо, А. Джекобсон. М.: ДМК, 2000. 429 с.
8. Ферроне Х. Изучаем C# через разработку игр на Unity. 5-е издание. СПб.: Питер, Пер. с английского - А. Павлов, 2022. 400 с.
9. Денисов Д.В. Разработка игры в Unity. С нуля и до реализации. «ЛитРес: Самиздат», 2021.
195 с.
10. Построение графика. Математическая визуализация [Электронный документ] URL: https://vangogih.github.io/iekyll/update/2018/03/18/Building-Graph.html (дата обращения: 10.05.2023).
Лященко Зоя Владимировна, канд. техн. наук, доцент, izv_ui@rgups.ru, Россия, Ростов-на-Дону, Ростовский государственный университет путей сообщения,
Игнатьева Олеся Владимировна, канд. техн. наук, доцент, lesiaignateva@rambler.ru, Россия, Ростов-на-Дону, Ростовский государственный университет путей сообщения,
Лященко Алексей Михайлович, канд. техн. наук, доцент, lam75@mail.ru, Россия, Ростов-на-Дону, Ростовский государственный университет путей сообщения,
Глазунов Дмитрий Владимирович, канд. техн. наук, доцент, glazunovdm@yandex.ru, Россия, Ростов-на-Дону, Ростовский государственный университет путей сообщения
SOFTWARE FOR WORKING SKILLS WITH MODERN SWITCHING DEVICES AND DIGITAL SIGNAL
PROCESSING SYSTEMS
Z.V. Lyashchenko, O.V. Ignatieva, A.M. Lyashchenko, D.V. Glazunov
The article has developed software for developing skills in working with modern switching devices. The initial data for metric calculations are proposed, the values of the software complexity adjustment coefficients are determined. Five main characteristics of the FP metric are identified: internal logical file (ILF, Internal Logical File), external interface file (EIF, External Interface File), external inputs (EI, External Input) and (EO, External Output), external query (EQ, External Inquiry). The general characteristic of the scale factors Wi is determined. Cost generators for the early stage of design are calculated. The developed software is intended for students of educational institutions studying disciplines related to telecommunication systems and networks.
Key words: software, computer simulator, metrics, input, output, digital systems, scaling factors, automation.
Lyashchenko Zoya Vladimirovna, candidate of technical sciences, docent, izv_ui@rgups.ru, Russia, Rostov-on-Don, Rostov State University of Railway Transport,
Ignatieva Olesya Vladimirovna, candidate of technical sciences, docent, lesjaignateva@rambler.ru, Russia, Rostov-on-Don, Rostov State University of Railway Transport,
Alexey Mikhailovich Lyashenko, candidate of technical sciences, docent, lam75@mail.ru, Russia, Rostov-on-Don, Rostov State University of Railway Transport,
Dmitry Vladimirovich Glazunov, candidate of technical sciences, docent, glazunovdm@yandex.ru, Russia, Rostov-on-Don, Rostov State University of Railway Transport
УДК 629.764
DOI: 10.24412/2071-6168-2023-5-105-106
МОДЕЛЬ КОНТРОЛЯ ТЕХНИЧЕСКОГО СОСТОЯНИЯ БОРТОВЫХ СИСТЕМ КОСМИЧЕСКИХ СРЕДСТВ НА ОСНОВЕ УЧЕТА БЫСТРОМЕНЯЮЩИХСЯ ПАРАМЕТРОВ
Д.О. Зайцев, Л.А. Богорева
В статье рассмотрена существующая модель контроля технического состояния бортовых систем космических средств, определены ее недостатки и предлагается направление ее совершенствования. Совершенствование существующей модели контроля осуществляется за счет формирования и внедрения новых диагностических признаков, формируемых на основе быстроменяющихся телеметри-руемых параметров, которые характеризуют поведение вибрационных процессов ракеты-носителя на всем ее жизненном цикле. Определены основные показатели и критерии для формирования нового дополнительного набора диагностических признаков. Обозначены направления дальнейших исследований.
Ключевые слова: техническое состояние, модель контроля, бортовые системы космических средств, быстроменяющиеся параметры, реальный масштаб времени.
В настоящее время космическая отрасль характеризуется увеличением объема и скорости обмена информацией между различными потребителями. Это обусловлено сложностью и важностью решаемых стратегических задач [1], что безусловно ведет к усложнению космических средств (КСр) и повышению требований к их надежности на фоне тенденции к микроминиатюризации [2]. Обеспечение надежности КСр становится ещё более актуальной в современных условиях, характеризующихся тем, что сроки восполнения орбитальной группировки (ОГ) космических аппаратов (КА) не удовлетворяют существующим требованиям, не говоря уже о сроках решения задачи наращивания [3]. В связи с этим возникает необходимость проведения целого комплекса мероприятий, направленных на повышение надежности применяемых КСр. Основным из них является анализ технического состояния (ТС) бортовых систем (БС) КСр.
