CC BY
19
Key words: antenna-feeder devices, electromagnetic equipment, radio frequency resource, radio relay communication.
Antropov Dmitry Alekseevich, сandidat of technical science, docent, professor, vnkantropov@mail. ru, Russia, Moscow, The Academy of military Sciences
УДК 681.3.068
DOI: 10.24412/2071-6168-2022-9-143-148
ПРЕДЛОЖЕНИЕ ПО ОПРЕДЕЛЕНИЮ ЭКСПЛУАТАЦИОННОЙ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СЛОЖНЫХ ТЕХНИЧЕСКИХ СИСТЕМ
А.С. Белов, М.М. Добрышин, А.А. Горшков, Д.Е. Шугуров
Увеличение роли аппаратно-программных комплексов при управлении сложными процессами требует оценки надежности применяемого программного обеспечения. В работе на основании анализа основных причин возникновения отказов и сбоев программного обеспечения уточнен подход оценки ее работоспособности. Сформулированный подход позволяет производить оценку появления ошибок в программном обеспечении вызванных как ошибками программирования, так и ошибками совместимости с другими программами и их обновлениями.
Ключевые слова: надежность, эксплуатационные отказы и сбои, программное обеспечение.
Современный этап развития сложных технических систем (СТС) свидетельствует о том, что значительную часть из них занимают аппаратно-программные комплексы (АПК), которые выполняют функциональные задачи во многих сферах деятельности современного общества. Применение АПК обусловлено, в том числе стремлением исключить человеческий фактор из процесса принятия решений при обработке большого объема данных, в условиях неопределенности или риска. От надежности работы данных комплексов зависит устойчивое функционирование критических областей инфраструктуры (финансовый сектор экономики, энергетика, связь и др.) [1]. Как следствие требования к надежности этих средств также повышаются.
Анализ распределения эксплуатационных отказов и сбоев современных АПК показывает, что их целесообразно разделить на отказы и сбои аппаратной части и программного обеспечения (ПО). Причем статистические данные и практический опыт показывают, что значительную часть занимают сбои и отказы, вызванные некорректной работой ПО. В отличии от СТС, для ПО классифицируются по времени восстановления работоспособности. Если время восстановления меньше требуемого, что принято считать, что произошел сбой, в противном случае - отказ. Причем время восстановления работоспособности определяется требованиями слуг связи, которые предоставляются абонентам или пользователям ЭВМ [2]. Сущность понятия надежности ПО, и параметры его характеризующие отличается от понятия принятых при оценке СТС. Снижение надежности технической системы вызвано физическими процессами при ее функционировании (разрушение, старение, стирание, деградация и тд.) [3]. Основой причиной снижения надежности ПО является ошибки в программном коде. В качестве основных причин сбоев или некорректной работы ПО можно выделить три основные группы [4-7]:
1. Ошибки и упущения при разработке (программировании) ПО.
- ошибки программирования;
- упущения при программировании и некорректная постановка задачи на разработку ПО;
- увеличение сложности разрабатываемого ПО;
- несовершенство среды программирования.
2. Ошибки в ходе эксплуатации ПО.
- неправильная установка ПО и его обновлений;
- несовершенство операционных систем;
- некорректная работа ПО совместно с другим ПО;
- некорректно введенные исходные данные или измененные форматы файлов (библиотеки) к которым обращается ПО при функционировании;
- отсутствие требуемых вычислительных ресурсов;
- злонамеренное изменение или модификация ПО (вирусы и т.п.);
3. Ошибки, вызванные сбоями и отказами в аппаратной части.
- сбои аппаратной части АПК;
- конфликтные ситуации из-за несовместимости отдельных аппаратных средств;
- ограничения аппаратной части или операционной системы.
Представленный список, можно расширить и дополнить другими причинами некорректной работы ПО.
Актуальность исследований в предметной области, также определяется стремлением ГГ-отрасли Российской Федерации обеспечить российским ПО до 90 % от общего количества к 2024 г. Также исследуя предметную область можно сделать вывод о том, что надежность ПО является одной из составляющих элементов информационной безопасности, т.к. наличие ошибок программирования и нестабильность работы определяют уязвимости АПК.
Оценка надежности разрабатываемого ПО осуществляется с применением трех основных групп [5-8]:
1. Модели и методы проектной оценки надежности, до начала отладки и эксплуатации программ:
- эмпирическая модель надежности по алгоритму ПО (модели сложности, римская модель, фазовая модель);
- эмпирическая методы оценки надежности по листингу программы (методы на основе обнаружения дефектов, дефекты на путях выполнения программы).
В качестве исходных данных используются структурная схема функционального ПО по каждой самостоятельной операции, а также статистические данные о работе аналогичного ПО, разработанного и эксплуатируемого ранее.
Достоинства
- позволяют дать приблизительную оценку значений показателей надежности разработанного ПО при использовании минимальных вычислительных ресурсов и временных затрат.
Недостатки
- не учитывают или учитывают не в полной мере условия эксплуатации ПО, что не позволяет прогнозировать возможное состояние с требуемой достоверностью и точностью.
2. Модели статистической оценки надежности, основанные на результатах отладки ПО и эксплуатации АПК:
а) статические модели надежности:
- по области ошибок (модели Миллса, Липова, Коркорэна);
- по области данных (модель Нельсона);
б) динамические модели надежности:
- дискретные (модели Шумана, La Padula, переходных вероятностей);
- непрерывные (модели Джелинского-Моранды, Шика-Волвертона, Муса).
Статические модели отличаются от динамических тем, что в них не учитывается время появления ошибок в процессе тестирования и не формируют предположений о поведении функции риска X (/).
Достоверность результатов оценки статистических методов зависит от обоснованности выборки исходных данных и детализации структуры изучаемого ПО.
Достоинства
- позволяют получать численные значения показателей надежности;
- позволяет осуществлять прогнозирование изменения значений показателей надежности в течении заданного времени и давать численные оценки;
- применяемый математический аппарат апробирован для оценки надежности в смежных областях, что позволяет судить о точности результатов;
Недостатки
- результаты оценки зависят от выбранной оценочной модели;
- высокая трудоемкость сбора исходной информации;
- использование упрощающих предположений о взаимных влияниях программных ошибок снижает достоверность результатов оценки;
- сильная зависимость точности прогнозов от качества и объема исходной информации.
3. Методы и методики тестирования надежности и безопасности функционирования программных продуктов в реальном времени:
а) тестирование в лабораторных условиях с применением действующих образцов или виртуальных машин:
- сценарный подход;
- подход динамических тестов.
б) эксплуатация пользователями ПО и АПК.
Опыт ведущих компаний в предметной области показывает, что ПО передается в эксплуатацию, если выявляется 0,002-0,005 дефектов в день. В качестве эталонных значений надежности ПО принята интенсивность обнаружения ошибок ниже 0,001 ошибок в день. Относительная трудоемкость и длительность при испытаниях различных классов программных продуктов приблизительно одинаковая и составляет 8-10% от совокупных затрат на производство [10].
Достоинства
- методы тестирования позволяют выявить большинство ошибок, условия их возникновения и набрать статистические данные.
Недостатки
- непосредственное тестирование не позволяет осуществлять оценку значений параметров надежности и прогнозировать их изменения в течении заданного времени;
- для достижения заданной точности и достоверности оценки значений параметров надежности требуются существенные временные, финансовые затраты и вычислительные ресурсы;
-тестирование ПО непосредственно пользователями, приводит к тому, что в начальный момент времени надежность ПО достаточно низкая.
В развитии элементов теории надежности ПО, была выявлена схожесть результатов расчетов вероятности безотказной работы ПО, с применением модели Джелинского-Моранды и модели оценки количества ошибок от объема ПО (табл. 1) [11].
Основываясь на результатах сравнения достоинств и недостатков представленных методов оценки надежности, а также сущности основных этапов жизненного цикла ПО [12], предлагается комплексная модель, позволяющая прогнозировать изменения работоспособность ПО в течении заданного времени эксплуатации.
Сущность процесса прогнозирования заключается в поэтапном выполнении следующих действий:
На первом этапе в использованием статистических данных о потоке отказов с использованием модели Джелинского-Моранды рассчитывают вероятность безотказной работы (РПО (()), разработанного ПО:
Р (I ) =
у-Ко1
апо = Акр Кк К Ки,
(1) (2)
где А - интенсивности отказов разработанного ПО (табл. 2, 3);
Кр
- коэффициент, отражающий влияние времени работы ПО (табл. 4); Кк - коэффициент, отражающий качество разработанного ПО (табл. 5); Кз - коэффициент, отражающий ремонтопригодность и частоту модернизаций разработанного ПО
(табл. 5); К и - коэффициент, отражающий загруженность и пользовательские изменения разработанного ПО (табл. 5) [11].
Таблица 1
Количественные значения результатов оценки интенсивности потока отказов и количества оши-
Объем ПО, Мб Интенсивность отказов А*10-6 (модель Джелинского-Моранды) Объем ПО, Мб Коэффициент количества ошибок ПО, р (модель оценки количества ошибок от объема ПО) Отклонение
0,25-1,0 0,1 1 0,08 20
1,0-4,0 0,375 2 0,33 12
4,0-16 1,5 16 1,32 12
16-64 6,25 64 5,29 15,4
64-256 25 256 21 16
Таблица2
Исходные данные для определения условий разработанного ПО_
Тип процессора М (малый) С (средний) Б (большой)
Число ИМС (интегральная микросхема) 1000 10 000 20 000
Число команд в секунду 250 250-1500 1500-4000
Таблица 3
Статистические показатели интенсивности отказов ПО (А)__
Тип управляющего ПО Размер процессора Объем ПО, Мб А*10-6
Элементарная управляющая программа С 0,25-1,0 0,4
Базовая управляющая программа С 1,4-4,0 1,5
Расширенная управляющая программа С 4,0-16 6
Базовая операционная система С 16-64 25
Расширенная операционная система С 64-256 100
Управляющая программа М 4,0-16 6
Операционная система (ОС) с малыми возможностями М/С 16-64 25
ОС со средними возможностями С 64-256 100
Универсальная ОС С/Б 64-256 100
На втором этапе формируют марковскую модель этапа применения, разработанного ПО. Вершинами графа являются отказы и сбои, вызванные ошибками в работе ПО из-за изменения конфигурации ЭВМ (установлено новое ПО или его обновление, установлены новые аппаратные элементы ЭВМ) на которой установлено исследуемое ПО.
Учитывая, тот факт, что в разработанном ПО имеются ошибки, которые способны привести к нарушению работоспособности, в начальный момент времени эксплуатации (¿0) вероятность безотказной работы равна РПО (() (выражение 1).
Таблица 4
Коэффициент, отражающий влияние времени работы программы_
Время работы Кр
0 2
1 1
2 0,2
3 0,1
4 0,05
5 0,03
6 0,02
Более 6 0,01
Таблица 5
Начальное качество ПО Кк Ремонтопригодность и частота изменений К Уровень загруженности и пользовательские изменения Ки
Низкое 2 Низкое 2 Очень низкое 0,25
Среднее 1 Среднее 1 Низкое 0,5
Довольно высокое 0,5 Довольно высокое 0,5 Среднее 1
Высокое 0,25 Высокое 0,25 Высокое 2
Очень высокое 4
Переход из одного состояния в следующее определяется согласно выражению: Р(Г) = 1 -(1 -РоПО (Г))(1 -Рош (Г)) ,
(3)
где Р0ПО () - вероятность безотказной работы разработанного ПО; Р.°ш (?) - вероятность возникновения ошибок в ПО вызванных изменением конфигурации ЭВМ, на котором установлено ПО; t = (0, Т]; г -интервал оценки (г = 1,2,...I).
Рош (t) = 1 - е
п
функц
(4)
^Обн =
обн
t„
побн - количество обновлений ПО установленного на ЭВМ с которыми осуществляет взаимодействие исследуемое ПО; £1 - поправочный коэффициент, учитывающий количество ошибок на одно обновление; - время квазистационарного состояния (время в течении которого ЭВМ не изменяет своей конфигурации).
I
^ \ tKCC ^ункц . г=1
Графики вероятности безотказной работы ПО (учитывающие ошибки программирования и вызванные изменением конфигурации установленного ПО) показаны на рис. 2.
т 1
4 // /
/У/
О 4Х103 И/ 1х104
а б
Рис. 2. График вероятности отказа разработанного ПО: а - для различного количества изменений конфигурации ЭВМ; б - для различного количества
ошибок при установке обновления. 146
Проведенный анализ сравнения результатов прогнозирования количества сбоев и отказов ПО сформулированного предложения и известных решений [13-17], свидетельствует о повышении достоверности на 12-15 %. Предложение возможно использовать как при разработке нового ПО и АПК (в том числе средств и систем обеспечения информационной безопасности), так и при оценки возникновения новых уязвимостей в АПК и компьютерных сетях связи, в которых они применяются.
Список литературы:
1. Белов А.С., Добрышин М.М., Шугуров Д.Е., Свечников Д.А. Предложение по контролю безопасности программного обеспечения при периодических обновлениях // Известия Тульского государственного университета. Технические науки. 2022. Вып. 2. С. 133-137.
2. Липаев В.В. Проектирование и производство сложных заказных программных продуктов. М.: СИНТЕГ, 2011. 408 с.
3. Черушева Т.В. Проектирование программного обеспечения: учеб. пособие. Пенза: Изд-во ПГУ, 2014. 172 с.
4. Белик А.Г., Цыганенко В.Н. Проектирование и архитектура программных систем: учеб. Пособие. Минобрнауки России, ОмГТУ. Омск : Изд-во ОмГТУ, 2016. 96 с.
5. Майерс Г. Надежность программного обеспечения: пер. с англ. М.: Мир, 1980. 360 с.
6. Назаров С.В. Архитектуры и проектирование программных систем: монография. М.: ИНФРА-М, 2013. 413 с.
7. Иванова Г.С., Ничушкина Т.Н., Пугачев Е.К. Объектно-ориентированное программирование. М: Из-во МГТУ им. Баумана, 2001. 319 с.
8. Крылов Е.В., Острейковский В.А., Типикин Н.Г. Техника разработки программ: в 2 кн. Кн. 2. Технология, надежность и качество программного обеспечения. М.: Высшая шк., 2008. 469 с.
9. Иванова Г.С. Технология программирования. М.: Из-во МГТУ им. Баумана, 2002. 320 с.
10. Глазачев А. Надёжность программного обеспечения. Введение / Areliability.com [Электронный ресурс] URL: https:// areliabilitv.com/nadyozhnost-programmnogo-obespecheniya/?ysdid=l7ydtzc1e 6 2 0 1371795 (дата обращения: 10.09.2022).
11. Чернов В.Ю., Никитин В.Г., Иванов Ю.П. Надежность авиационных приборов и измерительно-вычислительных комплексов: учебное пособие. СПб., СПбГУАП, 2004. 96 с.
12. Белов А.С., Добрышин М.М., Борзова Н.Ю. Формирование модели угроз информационной безопасности на среднесрочный период // Приборы и системы. Управление, контроль, диагностика. 2021. № 7. С. 41-48.
13. ГОСТ Р 51904-2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию. Москва: Стандартинформ, 2005. 62 с.
14. Полонников Р.И., Никандров А.В. Методы оценки надежности программного обеспечения. Санкт-Петербург: Политехника, 1992. 80 с.
15. Громов Ю.Ю., Елисеев А.И., Дидрих В.Е., Уланов А.О. Математическое обеспечение системы контроля состояния надёжности и безопасности сетецентрической информационной системы / Информация и безопасность. 2015. Т. 18. № 4. С. 602-607.
16. Громов Ю.Ю., Карасев П.И., Титов М.Ю. Вероятностные методы нахождения оценок в высоконадежных системах // Промышленные АСУ и контроллеры. 2021. № 12. С. 10-14.
17. Анисимов В. Г. Эффективность обеспечения живучести подсистемы управления сложной организационно-технической системы / В. Г. Анисимов и др. // Телекоммуникации. 2020. № 11. С. 41-47.
Белов Андрей Сергеевич д-р техн. наук, доцент, сотрудник, andrei2442016@yandex.ru, Россия, Орёл, Академия ФСО России,
Добрышин Михаил Михайлович, канд. техн. наук, сотрудник, Dobrithin@ya.ru, Россия, Орёл, Академия ФСО России,
Горшков Алексей Николаевич, канд. техн. наук, сотрудник, Россия, Орёл, Академия ФСО
России,
Шугуров Дмитрий Евгеньевич, канд. техн. наук, сотрудник, sde33@,academ. msk. rsnet.ru, Россия, Орёл, Академия ФСО России
PROPOSAL FOR DETERMINING THE OPERATIONAL RELIABILITY OF SOFTWARE COMPLEX
TECHNICAL SYSTEMS
A.S. Belov, M.M. Dobrynin, A.A. Gorshkov, D.E. Shugurov
Increasing the role of hardware and software complexes in managing complex processes requires an assessment of the reliability of the software used. In the work, based on the analysis of the main causes of fail-
147
ures and failures of the software, the approach to assessing its operability is clarified. The formulated approach makes it possible to assess the occurrence of errors in the software caused by both programming errors and compatibility errors with other programs and their updates.
Key words: reliability, operational failures and failures, software.
Belov Andrey Sergeevich doctor of technical sciences, docent, andrej2442016@yandex.ru, Russia, Orel, Academy of the FSO of Russia,
Dobryshin Mikhail Mikhailovich, candidate of technical sciences, employee, Dobrithin@ya.ru, Russia, Orel, Academy of the FSO of Russia,
Gorshkov Alexey Nikolaevich, candidate of technical sciences, employee, Russia, Orel, Academy of the FSO of Russia,
Shugurov Dmitry Evgenievich, candidate of technical sciences, employee, sde33@academ.msk.rsnet.ru, Russia, Oryol, The Academy of FSO of Russia
УДК 004.43
DOI: 10.24412/2071-6168-2022-9-148-151 ИСПОЛЬЗОВАНИЕ СИСТЕМЫ ТИПОВ В РЕСУРСОЗАВИСИМОМ ПРОГРАММИРОВАНИИ
М.С. Горбунов, Р.В. Дурнов, С.И. Толоконников
Системы типов предоставляют разработчикам программного обеспечения немедленную обратную связь о подмножестве свойств корректности их программ. Интеграции с IDE часто используют преимущества систем типов для отображения ошибок, предложений дополнений и даже улучшения навигации. С другой стороны, понимание затрат времени и энергии на выполнение программы требует ручного тестирования. В этой статье мы описываем существующую работу по использованию систем типов для энергосбережения и определяем требования к практическому подходу, которые существующие подходы не учитывают полностью. Кроме того, мы также обсудим, как существующие системы типов могут помочь обобщить рефакторинг для повышения энергоэффективности в ресурсозависимом программировании.
Ключевые слова: энергопотребление, ресурсо-зависимое программирование, программирование, системы типов, рефакторинг, системы.
Манифест Karlskrona повысил осведомленность об устойчивости процесса разработки программного обеспечения. Разработчики должны осознавать устойчивое влияние своих решений на каждом этапе жизненного цикла разработки программного обеспечения. Одной из основных проблем, связанных с устойчивостью, является потребление энергии. Ожидается, что к 2025 году на вычисления и связь будет приходиться 20% мирового энергопотребления. Энергоэффективность важна для пользователей как на макро, так и на микроуровне. На центры обработки данных приходится 3% глобальных выбросов, и они представляют собой значительные эксплуатационные расходы для поставщиков онлайн-услуг. При оценке новых серверов ежемесячные затраты на электроэнергию более важны, чем первоначальные затраты на оборудование. На другом уровне пользователи обеспокоены временем автономной работы своих компьютеров, планшетов, телефонов и носимых устройств. Манифест программного обеспечения с учетом энергопотребления утверждает, что разработчики программного обеспечения должны учитывать энергопотребление на всех этапах разработки программного обеспечения. Кроме того, разработчики должны быть оснащены необходимыми инструментами. Тщательный обзор состояния энергоэффективности в разработке программного обеспечения показывает, что большинство инструментов оценки производительности ориентированы на низкоуровневое, а не на высокоуровневое программирование, над которым работают разработчики приложений. Методы и инструменты рефакторинга программного обеспечения для обнаружения и автоматического устранения неэффективности энергопотребления, непосредственно влияющие на энергопотребление, остались в прошлом. Однако эти инструменты применяются в основном для разработки мобильных приложений, области, которая напрямую влияет на конечных пользователей. Исследование также делает вывод, что существует явная нехватка знаний в написании, обслуживании и развитии энергоэффективных программных систем [1].
SEEP — это инфраструктура, которая использует профили энергопотребления для конкретных платформ и символическое выполнение для определения энергопотребления полной программы, используя композиционный подход поверх низкоуровневого профилирования. Этот подход показал небольшие ошибки, порядка 0,09 мДж. Кроме того, статический анализ масштабируется для обнаружения ошибок
148
