Проблемы программной реализации мультиверсионной среды исполнения алгоритмов обработки информации в системах управления

Полный текст

Несмотря на то, что концепция отказоустойчивых вычислений существует уже достаточно давно [1-5], до недавних пор прерогатива отказоустойчивости оставалось за проектировщиками аппаратной части. Аппаратные структуры разрабатываются так, чтобы они могли сохранять работоспособность и соответствовать заданным показателям даже при возникновении отказов, как случайных, так и повторяющихся [6-8]. Однако отказы аппаратных компонентов являются только одним из источников ненадежности компьютерных систем, который существенно теряет свою значимость как способ повышения надежности по мере увеличения размеров и сложности программных компонентов. Использование аппаратных методов отказоустойчивости предполагает отсутствие ошибок в выбранной модели обеспечения надежности, а применяемые меры исключают только отказы компонент, а не ошибки самой модели. Основная причина этого заключается в том, что очень сложно определить причину возникновения отказа на уровне аппаратной части. Следовательно, очень сложно разработать эффективную модель. Программные отказы, напротив, всегда являются следствием несоответствия модели, и их частота напрямую зависит от логической сложности программной модели [9-11]. Модели повышения надежности главным образом связаны с введением избыточности в систему [12-14]. Поэтому до недавнего времени улучшение программной составляющей критичных по надежности систем управления существенно ограничивалось вычислительными ресурсами применяемых вычислительных устройств. Однако сейчас развитие техники достигло того уровня, когда вычислительная мощность выпускаемых микропроцессоров значительно превосходит требования отдельных задач. Поэтому одной из основных задач разработчиков программного обеспечения (ПО) становится создание таких алгоритмов разработки программных систем, которые обеспечивали бы устойчивость системы к программным и аппаратным сбоям [15]. В связи с этим возникает техническая проблема, заключающаяся в создании программных средств разработки отказоустойчивого программного обеспечения. Это требует развития процедур проектирования отказоустойчивого программного комплекса систем управления, что является актуальной научной проблемой. Известны работы, в которых объектом исследования является программный комплекс критичной по надежности системы управления и обработки информации, а предметом исследования - среда исполнения программного комплекса этой системы [16-22]. Причем целью данных исследований является повышение отказоустойчивости среды исполнения программных комплексов систем управления за счет применения мультиверсионных моделей [23-27]. Рассмотрим проблемы применения методологии проектирования отказоустойчивого программного обеспечения для повышения качества работы алгоритмов в системах управления и обработки информации. Для решения основных задач программной реализации мультиверсионной среды исполнения алгоритмов управления и обработки информации требуется разработать программную систему, представляющую собой инструментарий, который позволяет с минимальными временными затратами повысить отказоустойчивость систем управления при решении каждой конкретной задачи. Данный программный инструментарий должен представлять собой универсальную среду мультиверсионного исполнения (СМВИ) модулей программного комплекса. Для это необходимо также оценить эффективность различных моделей проектирования отказоустойчивого программного обеспечения [28-33] и алгоритмов мультиверсионного голосования [27; 34-37]. Анализ требований к среде мультиверсионного исполнения. В рамках решаемых данным исследованием задач предъявляются следующие требования к разрабатываемой системе: простота, надежность, производительность, компактность и универсальность. Простота включает в себя такие требования к СМВИ, как отсутствие избыточных компонентов, четкое разделение функций между модулями и легкость применения системы исполнения под конкретную задачу. Сложность и излишняя разветвленность структуры не только снижают производительность, но также увеличивают вероятность ошибки в самой среде. Удовлетворение этих требований также позволяет снизить материальные и временные затраты на внедрение системы в производственный процесс. Производительность, в свою очередь, складывается из таких факторов, как отсутствие избыточных связей между структурными компонентами системы и минимальные потери процессорного времени, затрачиваемые на работу внутренних алгоритмов самой системы исполнения [3; 6; 35; 38-40]. Эта группа требований является одной из самых главных, потому что обеспечивает реальность времени исполнения программных модулей систем управления, основанных на принципах мультиверсионного программирования [33; 35]. Это очень важно, так как чем меньше времени потребляет СМВИ, тем больше его остается программным модулям, выполняющим математический расчет. А мультиверсии требуют больших процессорных мощностей как за счет собственной сложности, так и за счет количества мультиверсий. Чтобы удовлетворить данные требования, необходимо хорошо проработать программную модель системы и, по возможности, сократить число циклов и разветвлений. Компактность среды означает низкое количество потребляемой памяти. В свою очередь, требуемый размер памяти складывается из памяти, занимаемой самим кодом среды мультиверсионного исполнения, и рабочей памяти (или памяти, требуемой для хранения внутренних данных). Это обеспечивается за счет оптимизации всех циклов и разветвлений исходного кода программы, осуществляемой как на этапе разработки программной модели системы, так и после этапа тестирования и отладки. Под надежностью среды мультиверсионного исполнения программных модулей понимается способность своевременно выдавать корректный результат вычислений [41; 42]. Эта способность зависит от таких факторов, как: 63 Вестник СибГАУ. 2014. N 4(56) - отсутствие каких-либо ошибок в программном коде самой среды; - устойчивость СМВИ к ошибкам и отказам модулей; - корректная обработка любых ошибочных ситуаций (например, когда невозможно принять решение, возникновение внутренней ошибки системы, нехватка ресурсов и т. д.). Следствием недостаточной надежности могут быть ситуации, связанные с выдачей неверного результата решающим алгоритмом, что может привести к краху всей системы. Удовлетворение требованиям надежности осуществляется за счет избыточности кода для обработки всех ошибочных ситуаций (там, где они могут возникнуть) и повышения уровня инкапсуляции и скрытия данных. Под универсальностью понимается способность создаваемой среды мультиверсионного исполнения программных модулей исполняться на различных компьютерных системах, а также способностью СМВИ работать с различными типами входных и выходных данных. Для этого требуется, в первую очередь, чтобы программа распространялась не в виде готовых исполняемых модулей, а в виде наборов исходных кодов. Это позволит компилировать программу под конкретную платформу в каждом конкретном случае. Второе требование заключается в том, что все обращения к системным функциям должны быть вынесены в отдельный модуль. Третьим требованием является отсутствие привязки функций СМВИ к внутренней структуре входных, выходных и промежуточных данных мультиверсий. Иными словами, среда должна воспринимать эти данные как буфер определенного размера, лишь передавая его от модуля к модулю, не извлекая из него никаких данных и не производя в нем никаких изменений. Эти требования позволяют значительно расширить область применимости создаваемой среды. Резюмируя вышеизложенное, можно изобразить все требования так, как представлено на рис. 1. Анализ возможностей применения мультиверсионной методологии к системе управления. Идея мультиверсионных методологий заключается во введении программной избыточности за счет использования нескольких различных программных модулей, эквивалентных по функциональному назначению, но не являющихся отказоустойчивыми. Во всех модулях системы управления (СУ) могут возникать ошибки, но для упрощения понимания рассмотрим случай только для модуля обработки данных, так как применение мультиверсионной методологии к модулям ввода и вывода будет происходить аналогично. Для организации работы обработки данных несколькими методами создадим внутри системы управления среду мультиверсионного исполнения программных модулей. Эта среда будет исполнять все варианты алгоритмов обработки данных на основе выбранной муль-тиверсионной методологии и выдавать согласованный результат. Тогда структура системы управления будет выглядеть так, как изображено на рис. 2. Фактически СМВИ представляет собой мульти-версионную систему управления, к которой подключаются модули ввода/вывода для осуществления связи с объектом управления, т. е. является ядром СУ. Выбор способа реализации программных модулей и их взаимодействия со средой исполнения. Итак, рассмотрев содержание структуры СУ, можно перейти к более сложному вопросу: определение типов связей между модулями системы. Для этого попробуем определить, в каких модулях может произойти непредвиденный отказ, последствия которого нужно предотвратить. Требования к СМВИ Простота Производительность Компактность Надежность Легкость применения сорного времени на механизмы среды Универсальность -• Отсутствие из -• Отсутствие избы -• Минимальный -• Отсутствие оши -• Платформолишних компо точных связей объем кода бок в самой среде независимость нентов -• Четкое разделение Минимальные • Минимальный -• Устойчивость к функции затраты процесразмер рабочей отказам в модулях -• Отсутствие при Корректная обработка ошибочных ситуаций вязки к обрабатываемым данным памяти Рис. 1. Требования к разрабатываемому программному комплексу 64 Математика, механика, информатика СМВИ и ^ э оЗ d ÿ ft о ю Й & л и К Модуль обработки данных (Метод 1) Модуль обработки данных (Метод N) Устройства измерений 1 1 1 і Исполнительные устройства Передача управляющих сигналов ОУ Выяснение основных характеристик ОУ 1 + Модуль ввода Модуль вывода 1 і 1 = = 1 1 1 1 \ / / Ч 1 1 1 j Процесс системы управления Модули процесса Очередь обработки данных Устройства взаимодействия с ОУ Рис. 2. Модель мультиверсионной системы управления с несколькими модулями обработки данных Данные проекта загружаются в начале работы СУ, и (при необходимости) сохраняются при завершении -отказ при хорошей отладке произойти не может. Отказ исполнительного устройства (ИУ) или устройства измерений (УИ) в любом случае приведет к искажению данных и, как следствие, к отказу всей системы, поэтому обеспечить надежность универсальными программными средствами здесь невозможно. Модуль сравнения двух результатов содержит достаточно простой алгоритм, и простым тестированием этого модуля можно свести вероятность отказа в нем к нулю. Следовательно, связь этих модулей со средой исполнения можно реализовать через статическую компоновку или статические или динамические библиотеки. Таким образом, единственное «слабое звено» нашей системы - это мультиверсии [43], так как в них производятся сложные вычислительные операции. Здесь возможно несколько вариантов взаимо действия со средой (ниже они представлены в порядке возрастания потребности в памяти). Статическая компоновка - из исходных кодов либо с использованием статических библиотек. Проект программной системы выглядит как набор исходных текстов (либо объектных кодов) СМВИ, в который требуется поместить под строго заданными именами исходные тексты (либо объектные коды) мультиверсий, ИУ, УИ, а также модуль сравнения двух результатов. После этого вызывается makefile - файл сборки проекта (в данном случае, хранящий данные проекта), и получается исполняемый модуль, готовый к исполнению. Преимущества статической компоновки следующие. 1. Простые механизмы взаимодействия между модулями. Обращение к функции модуля является простым вызовом функции. Это позволяет снизить объем кода, а следовательно, и количество возмож- 65 Вестник СибГАУ. 2014. № 4(56) ных ошибок. К тому же это самый быстрый из всех вариантов взаимодействия. 2. Эта модель обладает самой большой производительностью и самой низкой потребностью в памяти. 3. Данная модель требует от ОС (либо эмулирующего ее модуля) только наличия функций поддержки многопотоковости и объектов синхронизации. К недостаткам отнесем следующее: 1. Общий процесс для всех модулей. Одно необработанное исключение в любом модуле приведет к отказу процесса, а следовательно, и всей системы управления. 2. Общее адресное пространство у версий и среды исполнения. При «зависании» одной из версий, СМВИ вынуждена будет ее перезапустить, т. е. удалить старый поток и создать его заново. Из-за общего адресного пространства операционная система (ОС) заблокирует весь процесс на время удаления потока (что может продлиться от миллисекунд до нескольких секунд), что может оказаться катастрофичным для объекта управления. 3. Накапливаемые утечки памяти. При перезапуске версии неизбежно будут возникать утечки памяти, которые могут привести к неработоспособности (либо отказу) как среды исполнения, так и перезапущенных версий. Бороться с ними можно, либо создав в СМВИ общие механизмы выделения и освобождения памяти и обязать использовать их мультиверсии (что несколько снизит производительность), либо использовать статическую память (что не всегда возможно). 4. Для внесения изменений в любую часть системы необходимо перекомпилировать всю систему и заново производить сборку проекта. При компоновке с использованием динамических библиотек среда мультиверсионного исполнения представлена исполняемым модулем. Файлы с ИУ, УИ, версиями, модулем сравнения двух результатов и файл проекта выполнены в виде динамических библиотек со строго заданными в файле проекта именами. Для запуска такого проекта достаточно поместить все файлы в одну папку и запустить исполняемый модуль. Преимущества при компоновке с использованием динамических библиотек: - простые механизмы взаимодействия между модулями; - данная модель не требует от ОС (либо эмулирующего ее модуля) наличия функций поддержки многопотоковости и объектов синхронизации. Недостатки подхода: - общий процесс для всех модулей; - общее адресное пространство у версий и среды исполнения; - накапливаемые утечки памяти. В случае, когда компоненты выполнены в отдельных исполняемых модулях, для запуска проекта необходимо запустить все эти модули. Делать это вручную нецелесообразно, так как это ставит производительность среды в зависимость от оператора. Поэтому следует создать специальные программы-агенты, следящие за запуском всех модулей и перезапускающие их при необходимости. При использовании такой модели для исполнения всех модулей на одном компьютере агенты могут быть встроены в среду исполнения через дополнительный код в файле проекта. Но при сетевом распределении модулей встроить агентов в среду будет сложно, потому что возникнут трудности с отслеживанием состояния процесса на удаленной машине и его удаленного перезапуска. Данную модель можно разделить на две, отличающиеся видом взаимодействия между исполняемыми модулями. Взаимодействие через общие участки памяти (например, файлы) обладает рядом преимуществ: - нет утечек памяти при рестарте потоков; - утечки памяти некатастрофичны; - необработанное исключение приведет только к отказу одного модуля и, следовательно, безопасно для системы в целом. Недостатки, характерные для данной модели, следующие: 1. Усложнение модулей с целью обеспечения синхронизации доступа к общим участкам памяти и, как следствие, возможное снижение надежности. К тому же могут возникнуть ситуации, способные привести к отказу системы. Например, отказ одного из модулей в момент передачи данных: помещенные в память данные некорректны из-за удаления процесса с модулем, последний уже никогда не сможет сообщить о завершении операции передачи данных среде, а среда не сможет определить, что ОС уничтожила модуль из-за отказа, полагая, что тот производит передачу данных. Именно такие ситуации невозможно предусмотреть, а по статистике более 90 % сбоев и отказов программ связано с некорректной работой памяти. 2. Необходимо написание специальных программ-агентов для рестарта модулей. 3. Данная модель компоновки модулей применима, только если ОС (либо эмулирующий ее модуль) поддерживает динамическое подключение библиотек. Когда компоненты выполнены в отдельных исполняемых модулях и взаимодействие организовано через сетевой протокол, указанный подход также обладает рядом преимуществ: - нет утечек памяти при рестарте потоков; - утечки памяти некатастрофичны; - необработанное исключение приведет только к отказу одного модуля и безопасно для системы в целом; - возможность распределения вычислений по сети. Однако это не исключает запуск и выполнение всех модулей на одной ЭВМ: современные сетевые протоколы позволяют производить соединение с самим собой, что нередко используется при разработке различного ПО. К недостаткам можно отнести: - необходимость написания специальных программ-агентов для рестарта модулей; - возможность применения данной модели компоновки модулей только для ОС (либо эмулирующих ее модулей), поддерживающих работу с сетевыми протоколами. 66 Математика, механика, информатика В ряде работ [22-26; 44-46] были реализованы все рассмотренные варианты взаимодействия модулей со средой исполнения. Важно, что при сборке своего собственного проекта можно указать любой из них через директивы компилятора. Конструирование программной модели. На основе представленной выше функциональной структуры системы мультиверсионного исполнения программных модулей рассмотрим ее программную модель [32]. Для этого распределим функциональные блоки по C++ классам. Тогда программная модель будет выглядеть так, как показано в таблице. Данная модель классов позволяет программно реализовать все рассмотренные ранее модели взаимодействия программных модулей со средой исполнения. При статической компоновке объекты CAlgModule, CInput, COutput, CComparator хранятся в виде исходных кодов либо в статических библиотеках, встраиваемых в исполняемый модуль на этапе компиляции. При компоновке с использованием динамических библиотек CProject загружает внешние библиотеки с требуемыми объектами. Возможен вариант, когда некоторые объекты (например, CInput и COutput) вставляются в проект статически, а остальные - динамически. Для этого необходимо в зависимости от конкретной задачи указать эти сведения в конструкторе объекта CProject. При этом компоненты выполнены в виде отдельных исполняемых модулей. И в этом случае в проект встраиваются вместо самих объектов модули взаимодействия с ними, а сами объекты через программы-агенты исполняются в виде отдельного процесса. Их взаимодействие реализуется посредством сетевого протокола либо общих участков памяти. Реализация общих алгоритмов функционирования среды исполнения. При реализации среды мультиверсионного исполнения существует два момента, которым стоит уделить особое внимание: общий алгоритм функционирования СМВИ и алгоритм синхронизации потоков (одновременного запуска всех мультиверсий). От первого зависит внутренняя структура методов и, как следствие, показатели надежности и производительности. Второй является решающим в определении устойчивости поведения системы при критических нагрузках процессора. При разработке общего алгоритма функционирования следует особое внимание уделить корректной обработке потенциальных ошибок - выделить этапы, которые могут привести к отказу всей системы. Каждый блок представляет собой комплекс мер, реализуемых различными модулями системы. Алгоритм синхронизации потоков системы составлен на основе теории разработки мультизадачных систем [8; 47]. Он использует автоматически сбрасывающиеся сигнальные объекты и функции ожидания сигнала, предоставляемые всеми современными операционными системами. Разработанные алгоритмы приведены на рис. 3 и 4. Структура классов, образующих программную модель СМВИ Класс Функции CProject Класс проекта. Этот класс переопределяется при конструировании системы для задания конкретных функций и характеристик системы: - объект ввода данных; - размер структуры входных данных; - объект вывода данных; - размер структуры выходных данных; - количество алгоритмических модулей; - объекты алгоритмических модулей; - объект сравнения двух результатов; - размер структуры состояния одного модуля. Все остальные классы СМВИ на этапе своей инициализации используют эту информацию CNVPEE Основной объект, он конструирует всю систему и осуществляет связь между объектами CProject, CStatistics и CManager CStatistics Этот объект хранит статистику процесса выполнения расчета, рассчитывает и выдает по требованию других классов вероятность ошибочного результата конкретной версии CManager Играет роль диспетчера всей системы: подготавливает к работе, согласует функционирование всех остальных модулей CInput Отвечает за ввод данных, т. е. считывает показания устройств измерения CLauncher Осуществляет пошаговое выполнение расчета версий, помещение их состояний в статистику и корректирует неверные состояния версий по результатам блока решения CAlgModule Алгоритмический модуль (АМ). Исполняет роль версии расчета CDecision Блок решения. На данном этапе разработки решение принимается простым голосованием без памяти: самая большая группа равных состояний - истинна, а все остальные - ошибочны, независимо от того, как часто каждая версия возвращает ошибочный результат CComparator Сравнение двух состояний COutput Отвечает за вывод данных, т. е. за передачу результатов расчета исполнительным механизмам 67 Вестник СибГАУ. 2014. № 4(56) Рис. 3. Общий алгоритм функционирования СМВИ (у блоков, выделенных пунктиром, имеется обработчик ошибочных ситуаций) Математика, механика, информатика СМВИ подходит к точке выполнения одного этапа обработки данных. Мультиверсии 1, 2 и 3 находятся в режиме ожидания сигнала. СМВИ подает сигнал запуска мультиверсий. Мультиверсии 1, 2 и 3 переходят в режим выполнения обработки данных. 3) Затем СМВИ начинает ожидать сигналы о завершении обработки данных мультиверсиями в течение определенного времени. Мультиверсии ведут обработку данных. Мультиверсии успевают обработать все данные до истечения выделенного периода и сообщают о готовности СМВИ. После этого они переходят в режим ожидания. СМВИ выходит из режима ожидания. 4б) Мультиверсии 1 и 3 успевают обработать данные за выделенный период и сообщить о готовности СМВИ. Состояние мультиверсии 2 считается ошибочным. СМВИ выходит из режима ожидания. ^ Устройство подачи сигнала О Устройство ожидания сигнала I-I Устройство свободно I-і Устройство активно Рис. 4. Алгоритм выполнения одного этапа обработки данных Вестник СибГАУ. 2014. № 4(56) Реализация алгоритмов выявления отказов программных модулей и принятие решения. Во время исполнения программного обеспечения возможны два типа отказов. Первый тип отказа связан с нарушением нормального функционирования программы и возбуждением исключения. Это может произойти в случае попыток обращения по неверному адресу или деления на нуль. За перехват попыток обращения по неверному адресу и деления на нуль отвечает центральный процессор, возбуждающий исключения в ответ на эти ошибки. Исключение, возбужденное процессором, называется аппаратным. Но возбуждать исключения могут и операционная система, и прикладные программы. Такие исключения называются программными. Необработанное исключение в любом случае ведет к уничтожению процесса операционной системой. Второй тип отказа связан с зацикливанием программы. В этом случае программа на протяжении длительного времени не возвращает результат. В системах управления время является критическим показателем, поэтому необходимо ввести в среду исполнения такой параметр, как время отклика. Если программный модуль в течение длительного времени, большего чем заданное время отклика, не возвращает результат, то среда считает этот модуль отказавшим. Выявление отказов именно таким способом позволит нам отбросить часть неверных результатов и не использовать их в решающем алгоритме. Определяющим звеном мультиверсионной системы является блок принятия решения о корректности или ошибочности состояний мультиверсий. Этот блок разделяет результаты (выходы) многочисленных программных версий на корректные и ошибочные [27]. Существует несколько методик подобного разделения [21-28]. Самые общие из них основываются на классификации выходов. Наиболее перспективными из этих методик являются голосование абсолютным большинством, голосование согласованным большинством, а также нечеткое голосование согласованным большинством. В рамках работы [27] предложены улучшения этих методик, а именно взвешенное голосование согласованным большинством и нечеткое взвешенное голосование согласованным большинством. Методики этой группы основаны на сравнении выходов мультиверсий и размещении идентичных из них в одинаковые классы (подмножества). Однако в случаях, когда расчеты выполняются не с целыми числами, определение идентичности выходов является затруднительным. Для разрешения этой проблемы введено понятие соотношения равенства: мы будем говорить, что два числа равны, если они отличаются меньше, чем на некоторое допустимое отклонение. Эти соотношения не требуют выполнения свойства транзитивности. Иными словами, если известно, что \а - Ь\ < є и \b - с\ < є, то отсюда не следует что \а - с\ < є, где а, Ь и c - некоторые числа. Потенциальной проблемой методик данной группы является возможная неверная классификация выходов и, как следствие, неверное принятие решения, что, в конечном счете, способно привести к отказу системы управления. Вторая группа методик принимает решение без классификации выходов. В эту группу входят: медианное голосование и взвешенное медианное голосование. Они выбирают среднее значение из всех выходов как корректное [27]. Заключение. Таким образом, решение проблемы программной реализации СМВИ алгоритмов обработки информации в системах управления заключается в разработке программного инструментария, позволяющего унифицировать применение мультиверсион-ного подхода к различным программным комплексам. Данный подход, в отличие от существующих в настоящее время, позволяет исполнять модули не только с помощью методологии мультиверсионного программирования, но также и с использованием других распространенных мультиверсионных моделей: восстанавливающихся блоков, согласованных восстанавливающихся блоков, і/(и-1)-версионного программирования [31] и мультиверсионного программирования с самопроверкой.

Об авторах

Игорь Владимирович Ковалев

Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева

Email: kovalev.fsu@mail.ru
доктор технических наук, профессор кафедры системного анализа, ректор

Список литературы

Дополнительные файлы