Параметры программного обеспечения, оказывающие влияние на надежность обработки телеметрической информации

DOI:

2023 3(4) eISSN: 2782-2818

Идеальное программное обеспечение является недостижимым, поскольку оно служит лишь "структурированным представлением человеческих знаний и их обработки". Поскольку "идеального знания" не существует, не может существовать и идеального программного обеспечения. Эта проблема усугубляется при преобразовании ценных знаний (информации) в формат, пригодный для автоматизированной машинной обработки. Очевидно, что чем сложнее компьютерная задача, тем выше вероятность ошибок и сбоев в работе системы. Наиболее сложным аспектом разработки программного обеспечения является не его перевод на язык программирования и предоставление решений, а то, что Ф.Р. Брукс метко назвал "ядром программной сущности". Сюда входят алгоритмы, структуры данных, функции и их взаимосвязь.

Сложность программного обеспечения включает в себя четыре неотъемлемых свойства (сложность, соответствие, изменяемость и невидимость), которые непосредственно способствуют возникновению ошибок и отказов системы. Концепция надежности систем, включающая в себя такие стратегии, как безотказность и отказоустойчивость, хорошо описана в научной литературе. Несмотря на существование различных подходов, при решении вопросов надежности крайне важно учитывать анализ дискретных систем, особенно в контексте передачи, приема и обработки телеметрической информации (ТМИ), обладающей повышенной чувствительностью. Нормальное функционирование системы в соответствии с установленными алгоритмами предполагает надежность и безопасность. Отклонения от этого баланса в штатных или нештатных условиях (например, отказы или сбои) могут определять надежность системы или качество изделия. При построении системы одним из ключевых моментов является определение той части, которая может быть реализована программно, наряду с аппаратными средствами и реализацией безопасности. В таких случаях безопасность (надежность) системы может быть достигнута с помощью метода N-версий, как на уровне алгоритмов, так и на уровне программ.

Теоретические основы надежности программного обеспечения космических аппаратов изложены в работах [1-4], причем в последней из них предложен перспективный подход, основанный на марковских цепях высокого порядка, который заслуживает дальнейшего развития. Однако применение этого подхода сталкивается с трудностями, связанными с отсутствием соответствующей математической и алгоритмической формализации для цепей высокого порядка. Результаты работы алгоритмов вероятностной проверки моделей строги, их качество зависит только от моделей системы. Однако существует одно серьезное практическое препятствие, все вероятности (или скорости) в марковской модели точно известны априори. Во многих случаях это предположение оказывается слишком жестким. Такие системные величины, как частота отказов компонентов, скорость реакции, коэффициент потери пакетов и т.д., часто не известны или известны в лучшем случае частично.

В известных моделях, основанных на архитектурном подходе, используется теория цепей Маркова первого порядка с предположением о независимости выполнения программных компонентов. Данное предположение не всегда верно в силу сложности архитектуры современного программного обеспечения (ПО) и огромного множества сценариев использования этого предположения. Поэтому для разработки адекватных моделей оценки надежности ПО, которые улучшат процесс тестирования (например, позволят сократить необходимые ресурсы), необходимо рассматривать цепи Маркова высокого порядка, позволяющие учесть взаимозависимость запусков компонентов.

В настоящее время модели оценки надежности ПО на основе архитектурного подхода достаточно хорошо изучены в теоретическом плане, однако существует недостаток работ, описывающих их практическое применение. Разработка моделей высокого порядка для оценки надежности ПО также недостаточно описана в литературе. Таким образом, разработка новых архитектурных моделей оценки надежности ПО, учитывающих зависимости между запусками программных компонентов, а также их применение к реальным данным остается нерешенной задачей.

Существует несколько подходов к решению этой проблемы, включая предотвращение или недопущение ошибок, их устранение, введение отказоустойчивости в систему и реализацию последовательности обходных путей.

ОСНОВНЫЕ ПРИЧИНЫ ПРОГРАММНЫХ СБОЕВ

Для обеспечения надежного функционирования программно-технического комплекса (ПТК) в целом крайне важно обеспечить достаточный уровень отказоустойчивости входящих в него компонентов [5-10]. Поэтому необходимо гарантировать:

• •   надежность программного обеспечения;

• •   надежность сервера;

• •   надежность оборудования;

• •   непрерывность электропитания и соблюдение норм отказоустойчивости и

• п омехозащищенности структурированных кабельных систем; •    достаточную подготовку персонала по использованию ПТК; •    регулярное техническое обслуживание ПТК; •    оперативная квалифицированная техническая поддержка.

Обеспечение надежности программного обеспечения информационных систем является более сложной задачей по сравнению с обеспечением надежности аппаратных средств [11] по следующим причинам (рисунок 1):

• •    программные компоненты не разрушаются в течение длительного времени эксплуатации;

• •    использование программного обеспечения имеет большую вариативность, чем использование аппаратных средств;

• •    внесение исправлений и дополнений в программное обеспечение относительно проще, чем в аппаратные средства, но может привести к появлению дополнительных ошибок.

Рисунок 1. Организационная схема обеспечения информационной надежности.

Figure 1. Organizational scheme for ensuring information reliability.

Программное обеспечение считается имеющим ошибку, если [12]:

• •    его поведение отклоняется от спецификации, что может произойти из-за ошибок в процессе разработки спецификации;

• •    его поведение выходит за пределы, установленные в процессе разработки, даже если оно соответствует спецификации;

• •    его поведение отличается от официальной документации и пользовательских спецификаций.

Программа не может работать в соответствии с первоначальной спецификацией и требованиями пользователя из-за неполноты или двусмысленности требований. В заключение можно сказать, что ошибка в программном обеспечении возникает тогда, когда оно не соответствует разумным ожиданиям пользователя. Сбой программного обеспечения — это проявление ошибки в программном обеспечении. Термины "ошибка", "сбой" и "дефект" часто используются как взаимозаменяемые [13]. Дефект в ПО приводит к сбою во время выполнения кода, а сбой — это отклонение выходных данных системы от желаемых во время выполнения кода. Уровень тестируемости дефекта определяется как вероятность обнаружения сбоя на случайно выбранном выходе.

МУЛЬТИВЕРСИОННЫЙ ПОДХОД ПРИ СОЗДАНИИ ОТКАЗОУСТОЙЧИВОГОПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Среди существующих подходов, направленных на создание отказоустойчивого ПО, выделяются следующие:

• •    внедрение временной, информационной или программной избыточности [7];

• •    резервирование ПО, в том числе временное резервирование (повторное выполнение программ) [8];

• •    использование отказоустойчивой архитектуры, в том числе мультиверсионного программирования (МВП) [9].

В настоящее время существует широкий спектр оборудования для обработки информации, в котором может быть развернуто программное обеспечение системы управления информацией.

В последнее время, отмечается новый виток интереса к применению МВП подхода для повышения надежности ПО, причем утверждается, что данные метод является одним из наиболее эффективных (рисунок 2).

Рисунок 2. Архитектура N-версии.

Figure 2. N-version architecture.

Подход к программированию N-версии пытается применить концепцию повышения надежности за счет параллельной функциональной избыточности от аппаратного к программному обеспечению.

При допущении независимости от отказов вероятность возникновения отказов для одного и того же входа очень мала. Предположение подразумевает второй аспект для программного обеспечения: если две версии выходят из строя, нет особой вероятности того, что неправильные выходные значения идентичны (для небулевых значений). Если выходное значение имеет большой диапазон, маловероятно, что две неудачные версии не будут работать с одним и тем же значением. С математической точки зрения ожидается экспоненциальное увеличение надежности с дополнительными параллельными версиями при допущении независимости поведения отказа (возникновения и значения).

ЗАКЛЮЧЕНИЕ

К сожалению, эту концепцию нельзя применить к программному обеспечению один к одному. Важным отличием является то, что программное обеспечение обычно выходит из строя из-за ошибок проектирования, а аппаратное обеспечение, напротив, обычно выходит из строя из-за порчи или других физических эффектов. Надежность аппаратных систем можно повысить за счет использования идентичных параллельных аппаратных каналов. Напротив, идентичные параллельные версии программного обеспечения (копии) обычно дают сбой вместе для одного и того же ввода — параллельные копии могут допускать только сбои, связанные с оборудованием, такие как битовые сдвиги в памяти.

Независимость различных версий от сбоев программного обеспечения нельзя рассматривать как реалистичное предположение. Более того, важно четко понимать, что целью является достижение как можно большего разнообразия в поведении при сбоях отдельных версий.

Основная стратегия подхода N-версий для достижения разнообразия отказов заключается в использовании различных версий, являющихся продуктом различных разработок программного обеспечения. Анализ возможного достижимого уровня разнообразия программистов, их опыта, используемых инструментов и языков программирования выходит далеко за рамки данной статьи, но опыт и эмпирические исследования позволяют полагать, что даже в «независимых» разработки программного обеспечения, программисты склонны создавать подобные ошибки. Целесообразность использования различных команд программистов, а также алгоритмов отмечена в. Только некоторые простые виды ошибок, такие как опечатки, относительно случайны, но в любом случае это не такая уж большая проблема, потому что их, как правило, легче найти, чем те, которые связаны с непониманием сложной абстрактной проблемы.