Содержание к диссертации
Введение
1. Отказоустойчивые системы управления 9
1.1. Программная составляющая критичных по надежности систем управления 9
1.1.1. Надежностная характеристика программного модуля 14
1.1.2. Обеспечение надежности программ с помощью введения избыточности 19
1.2. Описание объекта исследования и его анализ 25
1.3. Методы повышения надежности программных систем 27
1.3.1. Моноверсионные модели 28
1.3.2. Модели восстанавливающихся блоков 35
1.3.3. Мультиверсионное программирование 37
1.3.4. Мультиверсионное программирование с самопроверкой 48
1.3.5. Модель согласованных восстанавливающихся блоков 50
1.3.6. 1/(п-1)-версионное программирование 51
2. Мультиверсионная среда исполнения оптимизационных алгоритмов: программная реализация 52
2.1. Анализ требований к среде мультиверсионного исполнения 52
2.2. Применение мультиверсионной методологии к системе управления .56
2.3. Выбор способа реализации программных модулей и их взаимодействия со средой исполнения 57
2.3.1. Конструирование программной модели 63
2.4. Реализация общих алгоритмов функционирования среды исполнения 65
2.5. Реализация алгоритма выявления отказов программных модулей 69
2.6. Реализация алгоритмов принятия решения о корректности или ошибочности состояний мультиверсий 69
2.6.1. Алгоритм голосования абсолютным большинством (ГАБ) 70
2.6.2. Алгоритм голосования согласованным большинством (ГСБ) 72
2.6.3. Алгоритм нечеткого голосования согласованным большинством (НГСБ) 74
2.6.4. Медианное голосование 75
3. Программный комплекс среды мультиверсионного исполнения 77
3.1. Теоретическое исследование предельной надежности мультиверсионных моделей проектирования отказоустойчивых систем 77
3.2. Исследование результатов работы реализованной среды исполнения 82
3.2.1. Выводы 94
3.3. Применение методологии мультиверсионного программирования к оптимизационным алгоритмам отказоустойчивых систем 97
3.4. Методология выбора наилучшего алгоритма оптимизации 98
3.4.1. Классы тестовых функций 102
3.5. Анализ результатов 103
Заключение 106
Список использованных источников 107
- Программная составляющая критичных по надежности систем управления
- Надежностная характеристика программного модуля
- Анализ требований к среде мультиверсионного исполнения
- Теоретическое исследование предельной надежности мультиверсионных моделей проектирования отказоустойчивых систем
Введение к работе
Актуальность работы.
Несмотря на то, что концепция «отказоустойчивых вычислений" существует уже достаточно давно, до недавних пор прерогатива отказоустойчивости оставалось за проектировщиками аппаратной части. Аппаратные структуры разрабатываются так, чтобы они могли сохранять работоспособность и соответствовать заданным показателям даже при возникновении отказов — как случайных, так и повторяющихся. Однако отказы аппаратных компонентов являются только одним из источников ненадежности компьютерных систем, который существенно теряет свою значимость как способ повышения надежности по мере увеличения размеров и сложности программных компонентов. Использование аппаратных методов отказоустойчивости предполагает отсутствие ошибок в выбранной модели обеспечения надежности, и применяемые меры исключают только отказы компонент, а не ошибки самой модели. Основная причина этого заключается в том, что очень сложно определить причину возникновения отказа на уровне аппаратной части. Следовательно, очень сложно разработать эффективную модель. Программные отказы, напротив, всегда являются следствием несоответствия модели, и их частота напрямую зависит от логической сложности программной модели.
Модели повышения надежности главным образом связаны с введением избыточности в систему. Поэтому до недавнего времени улучшение программной составляющей критичных по надежности систем управления существенно ограничивалось вычислительными ресурсами применяемых вычислительных устройств. Однако сейчас развитие техники достигло того уровня, когда вычислительная мощность выпускаемых микропроцессоров значительно превосходит требования отдельных задач. Поэтому одной из основных задач разработчиков программного обеспечения становится создание
таких алгоритмов разработки программных систем, которые обеспечивали бы устойчивость системы к программным и аппаратным сбоям.
В связи с этим возникает техническая проблема, заключающаяся в создании программных средств разработки отказоустойчивого программного обеспечения. Это требует развития процедур проектирования отказоустойчивого программного комплекса систем управления, что является актуальной научной проблемой.
Объектом исследования является программный комплекс критичной по надежности системы управления.
Предмет исследования — среда исполнения программного комплекса системы управления.
Целью диссертационного исследования является повышение отказоустойчивости среды исполнения программных комплексов систем управления, за счет применения мультиверсионных моделей.
Основной задачей данной работы является применение методологии проектирования отказоустойчивого программного обеспечения для повышения качества работы алгоритмов в системах управления. Для решения основной задачи требуется разработать программную систему, представляющую собой инструментарий, который позволяет с минимальными временными затратами повысить отказоустойчивость систем управления при решении каждой конкретной задачи.
Для достижения цели требуется решить следующие задачи:
Проанализировать существующие модели проектирования отказоустойчивого программного обеспечения.
Разработать методику применения моделей для реализации программного комплекса системы управления.
Разработать программный инструментарий, представляющий собой универсальную среду мультиверсионного исполнения модулей программного комплекса.
Оценить эффективность различных моделей проектирования отказоустойчивого программного обеспечения и алгоритмов мультиверсионного голосования.
Реализовать и протестировать мультиверсионную среду программного комплекса системы управления.
Методы исследования. Для решения поставленных задач использовались методы теории систем управления, проектирования отказоустойчивых программных систем и системного анализа. Ряд результатов получен на основе имитационного моделирования.
Научная новизна результатов, полученных в диссертации, состоит в следующем:
Разработана универсальная среда мультиверсионного исполнения программных модулей, позволяющая повысить отказоустойчивость программного комплекса систем управления за счет использования мультиверсионных методологий.
Предложены и реализованы модифицированные варианты алгоритмов мультиверсионного голосования, обладающие более высокой устойчивостью к межверсионным ошибкам программных. модулей, по сравнению с не взвешенными аналогами.
Предложена процедура оценки эффективности основных мультиверсионных моделей, позволяющая осуществить выбор модели для реализации в программных комплексах.
Разработан подход к выбору методов мультиверсионного голосования, позволяющий оценить эффективность алгоритмов мультиверсионного голосования по характеристикам системы.
Достоверность полученных результатов подтверждается корректным использованием имитационных моделей при обосновании полученных результатов, выводов, рекомендаций, а также успешным выполнением
компьютерных экспериментов с разработанной средой мультиверсионного исполнения программных модулей.
Практическая ценность. Разработанные в диссертации
инструментальные средства позволяют применить мультиверсионный подход при реализации конкретных программных комплексов сложных систем управления, а также выбрать соответствующую практической задаче мультиверсионную модель и способ мультиверсионного голосования еще на этапе проектирования системы
Реализация результатов работы. В диссертационной работе были разработаны две программные системы, предназначенные для внедрения мультиверсионного подхода при проектировании программного комплекса системы управления. В рамках системы «СМВИ vl.O» предложена методика оценки эффективности мультиверсионных моделей в зависимости от количества мультиверсий, вероятностей их безотказной работы и качества проверочного модуля. Разработанная имитационная система «ИС-СМВИ vl.O» помогает выбрать мультиверсионную модель и наилучший алгоритм мультиверсионного голосования. Программные системы прошли экспертизу и зарегистрированы в Отраслевом фонде алгоритмов и программ (ОФАП), что делает их доступными широкому кругу специалистов в области архитектуры, проектирования и разработки программного обеспечения отказоустойчивых информационно-управляющих систем.
На основе материалов диссертационной работы был разработан учебный курс, читаемый магистрам на кафедре «Системный анализ и исследование операций» Сибирского государственного аэрокосмического университета.
Апробация работы. Основные положения и результаты диссертационной работы прошли апробацию на международных и всероссийских научных конференциях: на всероссийских научных конференциях «Современные телекоммуникационные и информационные технологии» (2006), «Информационно-телекоммуникационные технологии и
электроника» (2007), международных научных конференциях «Решетневские чтения» (2006), «Инновационные технологии» (2008).
Диссертационная работа в целом обсуждалась на научных семинарах Сибирского государственного аэрокосмического университета, а также НИИ Систем управления, волновых процессов и технологий.
Публикации. По материалам диссертации опубликовано 13 работ, включая публикации в журналах по Перечню ВАК РФ.
Структура и объем работы. Диссертация состоит из введения, трех разделов и списка литературы из 121 наименования. Содержание работы изложено на 119 страницах.
Программная составляющая критичных по надежности систем управления
Современные системы управления строятся на базе универсальных или специализированных ЭВМ, при этом сложность процесса и объекта управления определяет сложность программных средств автоматизированной системы. В связи с этим рассмотрим особенности программных средств как сложных систем [9, 10]. Наиболее существенными чертами сложных систем принято считать: ? наличие общей задачи и единой цели функционирования для всей системы; ? большое количество взаимодействующих частей или элементов, составляющих систему; ? возможность расчленения на группы наиболее тесно взаимодействующих элементов — подсистемы, имеющие свое специальное назначение и цель функционирования; ? иерархическую структуру связей подсистем и иерархию критериев качества функционирования всей системы; ? сложность поведения системы, связанную со случайным характером внешних воздействий и большим количеством обратных связей внутри системы; ? устойчивость по отношению к внешним и внутренним помехам и наличие самоорганизации и адаптации к различным возмущениям; ? высокую надежность системы в целом, построенной из не абсолютно надежных компонент. Анализ сложных программных систем базируется на применении понятий "программное средство", "комплекс программ" и "программа для ЭВМ". Программное средство (ПС) - совокупность программ определенного назначения, пригодных для исполнения на ЭВМ, прошедших испытания с зафиксированными показателями качества и снабженных комплектом документации, достаточной для квалифицированной эксплуатации по назначению и использования как продукции производственно-технического назначения. Комплекс программ (КП) - совокупность взаимосвязанных программ для ЭВМ, в основном как объект разработки на различных этапах его создания, однако еще не достигший завершенного состояния, пригодного для тиражирования и эксплуатации с определенными качественными показателями. Поэтому в процессе анализа технологии проектирования преимущественно используется термин "комплекс программ" и только после успешного завершения испытаний — термин "программное средство". В понятие программа включаются тексты любых программ на языке программирования или в объектном коде, пригодном для исполнения на ЭВМ.
Рассматриваемые программные средства реализуются на различных типах ЭВМ, характеристики которых определяются назначением и сложностью ПС. В системах управления в качестве реализующих ЭВМ могут применяться универсальные большие и мини-ЭВМ, а также персональные ЭВМ. Общие принципы технологии проектирования ПС для систем управления достаточно универсальны, и основные особенности проектирования связаны с назначением ПС, с доступными ресурсами применяемых ЭВМ, с соответствием их назначению и сложности решаемых программами задач. Эти факторы влияют на рациональный уровень автоматизации проектирования, на размер и сложность взаимодействия в коллективе разработчиков, на трудоемкость и длительность создания ПС и т.д. Однако принципы и методы проектирования ПС при этом меняются относительно мало.
Программные средства, использующиеся в системах управления, обладают всеми свойствами сложных систем. Они содержат большое количество (сотни и тысячи) компонент — модулей, тесно взаимодействующих в процессе решения общей целевой задачи. КП имеет единую цель функционирования - обработку информации и принятие решений для управления объектами, вплоть до формирования соответствующих управляющих воздействий. Для обеспечения взаимодействия компонент в едином комплексе широко используются иерархические структуры с несколькими уровнями группирования и подчиненности модулей. Каждый модуль имеет свою целевую задачу и специфический частный критерий качества, как правило, не совпадающий с критерием эффективности всего комплекса. Однако частные критерии качества модулей и групп программ играют подчиненную роль относительно критериев качества всего КП и должны способствовать получению их допустимых или экстремальных значений. Иерархическая структура широко используется при анализе критериев качества всего КП и его частей.
Создание сложных систем с заданными характеристиками при ограниченных ресурсах требует проведения определенного комплекса мероприятий для достижения поставленной цели, который получил название проект. Целенаправленное управление проектом предназначено для пропорционального распределения ресурсов между работами по созданию системы на протяжении всего цикла проектирования вплоть до внедрения системы в серийное производство [9, 11].
В общем случае при проектировании необходимо создать в соответствии с принятым критерием эффективности оптимальную систему управления или обработки информации при ограничениях двух типов [12].
Первый тип ограничений характеризует уровень современных знаний теории и методов решения поставленных задач, принципов построения основных функциональных алгоритмов, методов структурного построения сложных систем и технологии их проектирования.
Второй тип ограничений относится в основном к техническим параметрам средств, на которых предполагается реализовать сложную систему, и к ресурсам, которые могут быть выделены на разработку и эксплуатацию системы. При проектировании ПС такими техническими ограничениями прежде всего являются параметры ЭВМ (объемы памяти, быстродействие, характеристики обмена информацией и т.д.), на которых предполагается реализовать КП. Важнейшим ресурсом проектирования являются кадры специалистов соответствующей квалификации, которые могут быть использованы для разработки системы. Кроме того, ресурсами проектирования являются материальные и финансовые затраты, доступные как в процессе создания, так и при последующей эксплуатации системы.
Функционирование программных средств в системах управления имеет следующие основные особенности.
Работа в реальном времени с выдачей управляющей информации объектам - один из наиболее сложных режимов функционирования программного обеспечения. При этом от реального времени зависят не только моменты решения тех или иных задач, но и получаемые в результате данные. Реальное время в таких системах - важнейший параметр, определяющий выходные воздействия и функциональную связь между изменениями состояния реальных управляемых объектов и моделью их состояний в управляющей ЭВМ.. Искажение значений времени может нарушить эту временную связь и привести к полному отказу системы управления. Длительность решения задач и скорость выдачи информации должны выдерживаться в соответствии с режимом работы и текущим состоянием источников информации и управляемых объектов. Это означает, что обработка информации и прогнозирование внешней ситуации должны осуществляться программами с более высокой скоростью, чем скорость реального управляемого процесса, с тем чтобы имелся определенный запас времени для принятия решений и формирования управляющих воздействий. Поэтому одной из важных для организации работы КП является проблема оперативного управления вычислительным процессом в реальном времени.
Надежностная характеристика программного модуля
Надежность технических систем определяется в основном, двумя факторами [13]: надежностью компонент и ошибками в модели системы, допущенными при проектировании или изготовлении. Относительно невысокая надежность компонент, их глубокая взаимозависимость и способность к разрушению, старению или снижению надежности в процессе эксплуатации привели к тому, что этот фактор оказался превалирующим для надежности аппаратуры. Надежность сложных КП определяется теми же двумя факторами. Однако соотношение их влияния иное. Хранение программ на магнитных или иных носителях при отсутствии внешнего вмешательства характеризуется очень высокой надежностью. Доминирующим для надежности КП является второй фактор — ошибки проектирования.
Программа любой сложности и назначения при строго фиксированных исходных данных и абсолютно надежной аппаратуре исполняется по однозначно определенному маршруту и дает на выходе строго определенный результат. Однако случайное изменение исходных данных и накопленной при обработке информации, а также множество условных переходов в программе создают огромное количество различных маршрутов исполнения для каждой программной системе. Такое количество вариантов исполнения программы нельзя проверить полностью из-за ограничений на длительность отладки и приемочных испытаний. Источниками ненадежности являются непроверенные сочетания исходных данных, при которых отлаженный КП дает неверные результаты или отказы. Для последующего изложения следует уточнить фундаментальные понятия теории надежности и особенности их использования для изучения характеристик функционирования программ.
Понятие отказа связано с нарушением работоспособности изделия и его соответствия требованиям технической документации. Отказ при исполнении программ может проявиться как следствие: ? нарушения кодов записи программ в памяти команд; ? стирания или искажения данных в оперативной или долговременной памяти ЭВМ; ? нарушения нормального хода вычислительного процесса.
Во всех случаях программные отказы приводят к прекращению выдачи пользователям информации и управляющих воздействий или к значительному искажению ее содержания и темпа выдачи.
Понятие "сбой " в теории надежности трактуется как самоустраняющийся отказ, не требующий внешнего вмешательства для замены отказавших компонент. Таким образом, понятия сбой и отказ применительно к аппаратуре отличаются степенью физического разрушения компонент и необходимостью их замены. В процессе обработки данных обычно отсутствует физическое разрушение программ и не требуется замена или ремонт каких-либо материальных компонент. Основной принцип классификации сбоев и отказов -разделение по временному показателю длительности восстановления после любого искажения программы, данных или вычислительного процесса. При длительности восстановления, меньшей заданного порога, аномалии при функционировании программ следует относить к сбоям. При восстановлении, превышающем по длительности пороговое значение и нарушающем работоспособность программ, искажения соответствуют отказу. Отсюда возникает задача классификации аномалий при функционировании программ на два типа: достаточные для нарушения работоспособности системы и малые отклонения от требований технической документации, при которых работоспособность сохраняется. Ниже учитываются только значительные искажения программ, данных или вычислительного процесса, достаточные для нарушения работоспособности.
Классификация программных сбоев и отказов по длительности восстановления приводит к необходимости анализа следующих динамических характеристик внешней среды и временных характеристик функционирования программ: ? инерционности объекта, являющегося источником или потребителем информации; ? среднего темпа или периодичности решения задач по обработке информации для данного объекта; ? допустимой длительности ожидания отклика или времени реакции ЭВМ от момента поступления исходных данных до момента выдачи обработанных результатов.
Инерционность объекта управления или потребителя информации, обрабатываемой данными КП, является первичным показателем, используемым для установления необходимого времени реакции программ. Снижение темпа решения задач управления ведет к ухудшению характеристик функционирования, и при некотором низком темпе работоспособность нарушается, что соответствует отказу. Рисунок 1.1. Типы исходных данных, обрабатываемых программой (1 - спецификации, 2 - процесса отладки, 3 - реального функционирования)
Понятие правильной (корректной) программы может рассматриваться статически вне временного функционирования. Степень некорректности программ можно характеризовать вероятностью попадания в область исходных данных, которая предусматривалась требованиями спецификации (1 на рисунке 1.1), однако не была проверена при тестировании и испытаниях (2 на рисунке 1.1). Таким образом, неправильность программы определяется вероятностью совмещения следующих событий: ? попадания исходных данных в область, заданную требованиями спецификации, но не проверенную при отладке и испытаниях, — вероятности Рц и P1V; ? проявления ошибки в программе при обработке таких данных — вероятность Р0.
Правильность программы неопределенна вне области изменения данных, заданной спецификацией, и не зависит от динамики функционирования программ в реальном времени.
Надеоісная программа, прежде всего, должна обеспечивать низкую вероятность отказа в процессе реального функционирования. Быстрое реагирование на искажения программ, данных или вычислительного процесса и восстановление работоспособности за время меньшее, чем порог между сбоем и отказом, позволяют обеспечить высокую надежность программы. При этом неправильная программа может функционировать в принципе абсолютно надежно. Действительно, если при каждом появлении реальных исходных данных (3 на рисунке 1.1), попадающих в области II и IV и стимулирующих неправильные результаты, они не приводят к событиям, соответствующим отказу, то такая программа функционирует безотказно и надежно, хотя и не всегда правильно.
В реальных условиях по различным причинам исходные данные могут попадать в область III, не проверенную при отладке и не соответствующую требованиям спецификации или технического задания. Если восстановление происходит за время меньшее, чем пороговое время между отказом и сбоем, то такие события не влияют на основной показатель надежности - наработку на отказ. Следовательно, отказ при функционировании программы является понятием динамическим и произойдет с вероятностью, определяющейся совмещением следующих событий: ? появление на входе программы реальных данных, попадающих в непроверенные при тестировании и испытаниях области III или IV, - вероятности Рш и PIV; ? проявление ошибки при обработке этих данных, достаточной для вызова отказовой ситуации, - вероятность Р0, ? длительность восстановления после возникновения отказовой ситуации превысила пороговое значение между отказом и сбоем -вероятность Рв.
Анализ требований к среде мультиверсионного исполнения
В рамках решаемых данным исследованием задач, были предъявлены следующие требования к разрабатываемой системе: простота, надежность, производительность, компактность и универсальность.
Требования для обеспечения простоты Простота включает в себя такие требования к СМВИ как: отсутствие избыточных компонентов, четкое разделение функций между модулями и легкость применения системы исполнения под конкретную задачу. Сложность и излишняя разветвленность структуры не только снижают производительность, но также увеличивают вероятность ошибки в самой среде. Удовлетворение этих требований также позволяет снизить материальные и временные затраты на внедрение системы в производственный процесс.
Требования для обеспечения производительности Производительность, в свою очередь, складывается из таких факторов как отсутствие избыточных связей между структурными компонентами системы и минимальные потери процессорного времени, затрачиваемые на работу внутренних алгоритмов самой системы исполнения. Эта группа требований является одной из самых главных, потому что обеспечивает реальность времени программных систем управления основанных на принципах мультиверсионного программирования. Это очень важно, так как чем меньше времени потребляет СМВИ, тем больше его остается программным модулям, выполняющим математический расчет. А мультиверсии требуют больших процессорных мощностей, как за счет собственной сложности, так и за счет количества мультиверсии.
Чтобы удовлетворить данные требования необходимо хорошо проработать программную модель системы и, по возможности, сократить число циклов и разветвлений.
Требования для обеспечения компактности Компактности среды означает низкое количество потребляемой памяти. В свою очередь, требуемый размер памяти складывается из памяти занимаемой самим кодом среды мультиверсионного исполнения и рабочей памяти (или памяти требуемой для хранения внутренних данных).
Эти требования обеспечиваются за счет оптимизации всех циклов и разветвлений исходного кода программы, осуществляемой как на этапе разработки программной модели системы, так и после этапа тестирования и отладки.
Требования для обеспечения надежности Под надежностью среды мультиверсионного исполнения программных модулей понимается способность своевременно выдавать корректный результат вычислений. Эта способность зависит от таких факторов как: ? отсутствие каких-либо ошибок в программном коде самой среды; ? устойчивость СМВИ к ошибкам и отказам модулей; ? корректная обработка любых ошибочных ситуаций (например, когда невозможно принять решение, возникновение внутренней ошибки системы, нехватка ресурсов и т.д.).
Следствием недостаточной надежности могут быть ситуации от выдачи неверного результата решающим алгоритмом, до краха всей системы.
Удовлетворение этим требованиям осуществляется за счет избыточности кода для обработки всех ошибочных ситуаций (там, где они могут возникнуть) и высоким уровнем инкапсуляции и скрытия данных.
Требования для обеспечения универсальности Под универсальностью понимается способность создаваемой среды мультиверсионного исполнения программных модулей исполняться на различных компьютерных системах, а также способной работать с различными типами входных и выходных данных. Для этого требуется, в первую очередь, чтобы программа распространялась не в виде готовых исполняемых модулей, а в виде наборов исходных кодов. Это позволит компилировать программу под конкретную платформу в каждом конкретном случае. Второе требование заключается в том, что все обращения к системным функциям должны быть вынесены в отдельный модуль. Третьим требованием является отсутствие привязки функций СМВИ к внутренней структуре входных, выходных и промежуточных данных мультиверсии. Иными словами, среда должна воспринимать эти данные как буфер определенного размера лишь передавая его от модуля к модули, не извлекая из него никаких данных и не производя в нем никаких изменений. Эти требования позволяют значительно расширить область применимости создаваемой среды.
Идея мультиверсионных методологий заключается во введении программной избыточности за счет использования несколько различных программных модулей эквивалентных по функциональному назначению, но не являющихся отказоустойчивыми. Попробуем изменить схему системы управления (рисунок 1.2). Во всех модулях СУ возникать ошибки, но для упрощения понимания рассмотрим случай только для модуля обработки данных, т.к. применение мультиверсионной методологии к модулям ввода и вывода будет происходить аналогично. Для организации работы обработки данных несколькими методами создадим внутри системы управления Среду МулътиВерсионного Исполнения программных модулей (СМВИ). Эта среда будет исполнять все варианты алгоритмов обработки данных, на основе выбранной мультиверсионной методологии, и выдавать согласованный результат.
Теоретическое исследование предельной надежности мультиверсионных моделей проектирования отказоустойчивых систем
Свойство «корректности» очень важно при разработке отказоустойчивого программного обеспечения. Чем выше его величина, тем надежнее система. Это свойство даже более важное, чем доступность и надежность, т.к. если мы знаем величину «корректности», мы можем с уверенностью сказать, сколько результатов не содержит ошибок и использовать только их, тем самым увеличив точность системы. А чем выше точность системы, тем выше ее доступность и надежность.
При реализации мультиверсионных моделей на практике, возникает вопрос: как много мультиверсий необходимо иметь, чтобы достичь желаемой надежности системы? Чтобы ответить на этот вопрос, необходимо найти соотношение между «корректностью» и количеством мультиверсий. Среди мультиверсионных методологий, существует только два фундаментальных подхода модель восстанавливающихся блоков и мультиверсионное программирование. Найдем данные соотношения для этих двух моделей.
Модель восстанавливающихся блоков МВБ получает «корректный» результат, когда хотя бы одна мультиверсия возвращает «корректный» результат и проверочный модуль принимает правильное решение. Пусть мы имеем п версий, их надежности равны rhr2,...,rn соответственно. Надежность проверочного модуля есть Ъ. Определим соотношение между корректностью выхода системы (Sn) и количеством мультиверсий (п). При использовании методологии мультиверсионного программирования, надежность системы во многом определяется используемым алгоритмом согласования результатов мультиверсий. Из всех алгоритмов голосования, рассмотренных в главе 2.6, оценить все возможные условия, влияющие на выход системы, можно только для голосования абсолютным большинством (см. главу 2.6.1).
Голосование абсолютным большинством получает «корректный» результат, если более половины мультиверсий возвращают «корректный» результат и алгоритм голосования выбирает один из них. Предположим, что все программные модули обладают некоторой средней надежностью г, надежность модуля принятия решения - Ь, а корректность выхода системы - Sn, где п - количество мультиверсий в системе.
Голосование согласованным, нечеткое голосование согласованным большинством, а также взвешенные варианты алгоритмов голосования, служат для того, чтобы приблизить Sn к 1 для того же т. Получить выражения в аналитическом виде для данных алгоритмов не представляется возможным, но оценить предел улучшений данных алгоритмов можно положив, что т достаточно мало (менее 0,5 от п, как в случае с ГАБ).
Эффективность мультиверсионной системы напрямую зависит от используемого алгоритма голосования. В данной главе, мы рассмотрим вопросы реализации моделирующей системы, оценивающей эффективность блока принятия решения. Оценивать эффективность, будем с помощью имитации вероятностных характеристик выдачи ошибочных результатов мультиверсиями.
Для выбора алгоритма принятия решения в каждой конкретной ситуации существенное значение имеет то, какие ошибки превалируют при функционировании системы. Рассмотрим типы ошибок, встречающиеся в мультиверсионных системах управления и обработки информации.
В основе систем, созданных с использованием методологии мультиверсионного программирования, лежит избыточность программных модулей, т.е. наличие нескольких модулей дублирующих функции друг друга (мультиверсий). Такой подход позволяет добиться того, что некоторая особенность программной архитектуры, приводящая к выдаче ошибочного результата или отказу модуля при некотором наборе входных данных, с большой степенью вероятности будет содержаться только лишь в одном из модулей. Это связанно с тем, что вероятность появления одной и той же ошибки сразу в нескольких модулях, созданных с использованием разных подходов и инструментальных средств, очень низка. Данный тип ошибок назовем одиночными ошибками. Такие ошибки содержат все модули, и они проявляются в виде случайных отклонений выходных значений нескольких модулей от остальных.
Если бы все ошибки являлись одиночными, тогда из ситуации, когда несколько мультиверсий произвели вычисления с ошибкой, следовало бы, что их результаты не равны между собой. Однако на практике возникают ситуации, когда несколько модулей возвращают одинаковый неверный результат и, следовательно, содержат одинаковую ошибку в программной архитектуре. Такие ошибки будем называть межверсионными. Следует отметить, что существуют методики и рекомендации по проектированию программных систем, которые позволяют снизить вероятность появления ошибок данного вида, но, как показывает практика, полностью их исключить не удается [22].