Контролируемая замена версий программного обеспечения бортовой вычислительной системы реального времени

Размещено на http://www.allbest.ru/

АВТОРЕФЕРАТ

Контролируемая замена версий программного обеспечения бортовой вычислительной системы реального времени

Специальность 05.13.15 - Вычислительные машины и системы

Ти Хан

Москва 2008



ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИИ

1. Брехов О. M., Ти Хан. Улучшенный метод контролируемого апгрейда программного обеспечения.// Труды XVI международного научно-технического семинара. Сентябрь 2007г., Алушта. - Тула:Изд-во ТулГУ, 2007, с. 221.

2. Ти Хан. Оценка времени выполнения апгрейда программного обеспечения БВСРВ.//Всероссийская конференция молодых ученых и студентов «Информационные технологии в авиационной и космической технике-2008». 21-24 апреля 2008г.Москва. Тезисы докладов.-М.:Изд-во МАИ-ПРИНТ, 2008. - 124 с.

3. Брехов О. M., Ти Хан. Времея выполнения апгрейда программного обеспечения БВСРВ.// Труды XVII международного научно-технического семинара. Сентябрь 2008г., Алушта. - Редакционно-издательский центр ГУАП, с. 189-190.

4. Брехов О. M., Ти Хан. Аналитическая модель базовой оценки времени проведения апгрейда программного обеспечения удаленной вычислительной системы реального времени// Журнал «Вестник МАИ» 2008г. Т.(15), №(3), с. 147-153.

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Актуальность темы

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

Новая версия программного обеспечения, которая должна изменить старую версию, должна быть протестирована на земле. Однако это программное обеспечение может оказаться неработоспособным на борту во время выполнения полетного задания. В этом случае необходимо прервать замену и продолжить выполнение задания старой версии программного обеспечения. При неудачной замене новая версия программного обеспечения должна быть исправлена и заново протестирована на земле. После этого осуществляется следующая попытка замены. В публикациях A. T. Tai, K. S. Tso, W. H. Sanders, L. Alkalai, и S. N. Chau реализуется такой метод замены версий. контроль программное обеспечение интервал

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

Для жестких и даже мягких систем реального времени такая ситуация не может приемлема.

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

Цель диссертационной работы

Целью работы является разработка методики выполнения контролируемой замены версий для бортовой вычислительной системы в режиме реального времени ее работы.

Для достижения указанной цели в работе должны быть решены следующие научно-исследовательские и практические задачи:

1. Разработана методика выполнения контролируемой замены версий программного обеспечения для бортовой вычислительной системы в режиме реального времени ее работы.

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

2. Разработаны аналитические модели восстановления вычислений при прекращении замены в заданном временном интервале.

3. Разработаны аналитические модели оценки времени выполнения контролируемой замены версий программного обеспечения.

4. Разработаны имитационные модели контролируемой замены версий программного обеспечения на основе системы моделирования GPSS.

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

Методы исследования

При решении поставленных задач в диссертационной работе были использованы методы теории вероятностей и математической статистики, математического и имитационного моделирования, теории графов и теории надежности информационных систем. Математические модели представлены в виде компьютерных программ на языке программирования MatLab и математических расчетов в Exсel. Имитационные модели построены на основе системы моделирования GPSS.

На защиту выносятся следующие положения:

1. Разработана методика выполнения контролируемой замены версий программного обеспечения для бортовой вычислительной системы в режиме реального времени ее работы.

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

3. Разработаны аналитические модели восстановления вычислений при прекращении замены в заданном временном интервале.

4. Разработаны аналитические модели оценки времени выполнения контролируемой замены версий программного обеспечения.

Научная новизна

1. Разработана методика выполнения контролируемой замены версий программного обеспечения для бортовой вычислительной системы в режиме реального времени ее работы.

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

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

4. Разработаны аналитические модели оценки времени выполнения контролируемой замены версий программного обеспечения. Идеальная модель, когда новая версия работает без ошибок, и три модели различной детальности процессов замены. Оптимистическая модель, когда возможно безошибочное выполнение новой версии. Пессимистическая модель, когда новая версия содержит по крайней мере одну ошибку на фазе 1 и Пессимистическая модель, когда новая версия содержит ровно n ошибок

5. Разработаны имитационные модели контролируемой замены версий программного обеспечения на основе системы моделирования GPSS, обеспечивающие оценку аналитического моделирования.

Из экспериментальных результатов, в частности, следует, что при качестве ПО с вероятностью ошибок на фазах 1 и 2 и = н = 0.98 при среднем значении времени корректировки 0.1 от времени выполнения фаз 1 и 2 время завершения апгрейда увеличивается на 5%, но при вероятности ошибок на фазах1 и 2 и = н = 0.95 и одинаковом времени выполнения фаз и корректировки время завершения апгрейда увеличивается на 25%.

В четвертой главе проведено имитационные моделирование замены версий посредством использовании системы моделирования GPSS.

Основные научные и практические результаты диссертационной работы

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

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

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

4. Разработаны аналитические модели оценки времени выполнения контролируемой замены версий программного обеспечения.

5. Разработаны имитационные модели контролируемой замены версий программного обеспечения на основе системы моделирования GPSS.

Достоверность полученных в диссертационой работе результатов подтверждается:

· Корретностью использования адекаватного математического аппратата;

· Достаточной апробацией материалов диссертации;

· Сравнение результатов аналитических и имитационных моделей

Практическая ценность диссертационной работы

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

Тема диссертационной работы связана с договором о сотрудничестве между Российской Федерацией и Союза Мьянмы.

Реализация результатов работы

Результаты диссертационной работы использовались в учебном процессе кафедры «Вычислительные машины, системы и сети» Московского авиационного института (государственного технического университета)

Апробация работы

Основные положения и результаты диссертационного исследования докладывались автором и обсуждались: на XVI международном научно-техническом семинаре (Алушта, 2007г.), на всероссийской конференции молодых ученых и студентов «Информационные технологии в авиационной и космической технике» (Москва, 2008г.), на XVII международном научно-техническом семинаре (Алушта, 2008г.).

Публикации

Основные материалы диссертационной работы опубликованы в 4 печатных работах. В том числе одна работа опубликована в журнале, рекомендуемом ВАК.

Структура и объем работы

Диссертационная работа состоит из введения, четыре глава, заключения и списка используемых источников. Основная часть диссертации содержит 105 страницы машинописного текста, включая 49 рисунок и 9 таблиц. Список литературы включает 50 наименований. Общий объем диссертационной работы составляет 114 страниц.

СОДЕРЖАНИЕ РАБОТЫ

Во введении обосновывается актуальность диссертационной работы, и формулируются основные цели и задачи работы. Рассматриваются методы исследований, раскрывается новизна и практическая ценность работы. Рассматриваются реализация контролируемой замены версий функциональных задач.

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

- потерей функциональности системы в процессе замены;

- возможным простоем системы в период переключения версий программного обеспечения;

- сбоями, вызванными ошибками при разработке тех или иных версий программного обеспечения.

Существует методы реализации замены версии ПО, которые реализуют операцию замены старой версии в две фазы:

1. Фаза проверки работоспособности новой версии

2. Фаза первичного управления системой при выполнении новой версии.

Во время фазы проверки работоспособности новой версии БВСРВ функционирует под управлением старой версии, однако, новая версия выполняется параллельно со старой, результаты ее решения не используются для управления объектом, но проверяются с помощью проверочного теста ПT или путем сравнения с результатами старой версии. На этой фазы в случае возникновения в новой версии ошибки замена прекращается. Выполняется корректировка новой версии.

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

Для жестких (и даже для мягких) систем реального времени такая ситуация не может приемлема.

Состояние ф11- выполняется замена на 1-й фазе, при этом новая версия имеет ошибку. Поэтому новая версия программного обеспечения должна быть исправлена и заново протестирована- переход из состояния ф11 в состояние К. В состоянии Ф10 новая версия работает без ошибок на первой фазе.

Пессимистическая модель, когда новая версия содержит ровно n ошибок

Рис. 9 Модель M4

В данной модели мы предполагаем обнаружение на фазе 1 ровно n ошибок. Поэтому для фазы 1 по сравнению с моделью М2 вводится n +1 состояние.

Состояния Ф13, Ф12, Ф11-соответствуют наличию трех, двух и одной ошибам в новой версии, которые проявляются на фазе 1 замены версий. При возникновении ошибки, новая версия корректируется на земле.

Состояние Ф10 соответствует новой версии, при выполнении которой ошибки не определяются. С вероятностью 1 осуществляется переход из состояния Ф10 в состоянию Ф2 (выполнение второй фазы). При безошибочном выполнении новой версии на фазе 2 замена версий завершается - переход из состояния Ф2 в состояние Н.

Решение для моделей M3 и M4 получено посредством нахождения обратного преобразования Лапласа.

В главе 3 работы приведены экспериментальные результаты решения для моделей.

Сотояние Ф1 соответствует первой фазе. При возникновении ошибки, новая версия исправляется на земле. Поэтому с вероятностью 1-и - переход из состояния Ф1 в состояние К. если Состояние К - состояние, при котором новая версия исправится и тестируется на земле. После коррекции новой версии осуществляется новая попытка замены версии, для этого новая версия ПО отправляется на борт. Если новая версия ещё имеет ошибку, то переход из состояния Ф1 в состояние K.

Переход из состояния Ф1 в состояние Ф2 соответствует безошибочному выполнению новой версии ПО на фазе Ф1 и переходу к выполнению новой версии ПО на фазе Ф2. При возникновении ошибки в новой версии ПО на фазе Ф2, происходит переход из состояния Ф2 в состояние К. Если нет ошибок, то замена завершается - переход из состояния Ф2 в состояние З.

В этом случае введено дополнительное состояние - K, связанное с проведением работ по коррекции Новой версии ПО в резидентном месте и вероятность p_к пребывания системы в этом состоянии K. Время выполнения работ по коррекции предполагается случайным с экспоненциальной функцией распределения с показателем м.

Решение системы может быть получено посредством нахождения обратного преобразования Лапласа:

.

где s - корни характеристического уравнения .

Пессимистическая модель M3 по крайней мере с одной ошибкой на фазе 1

Рис. 8 Модель M3

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

В заключение главы на основе проведенного анализа показано, существующие методы замены версий не обеспечивают при прекращении замены версий восстановление работоспособности БВС в заданном временном интервале.

С целью обеспечения работоспособности БВС при проведении замены версий необходимо разработать:

· методику выполнения замены версий программного обеспечения для бортовой вычислительной системы в режиме реального времени ее работы.

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

· аналитические модели восстановления вычислений при прекращении замены в заданном временном интервале.

· аналитические модели оценки времени выполнения контролируемой замены версий программного обеспечения.

· имитационные модели контролируемой замены версий программного обеспечения на основе системы моделирования GPSS.

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

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

протокол замены с дополнительными котрольными точками - ПЗД.

Интервал возможного отката обусловлен начальной точкой интервала - моментом времени поступления внутреннего сообщения в программы неизменяемой части программного обеспечения НП от новой версии НВ и конечной точкой интервала - моментом времени неуспешного выполнения последующего проверочного теста, инициируемого при посылке внешнего сообщения на ИУ от программы НП, или старой версии СВ или новой версии НВ. Внутри этого интервала могу быть дополнительные поступления внутренних сообщений от программы НП и от новой версии НВ. см. рис. 1.

НП -----+---------------------- + Контрольная точка

СВ ----------+-------------------

НП, (СВ), (НВ) ------------------------*---- * Проверочный тест

Интервал +----------------------+

Интервал +-----------------+

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

Протокол выполнения фазы 1 апгрейда должен обеспечить сбор информации об интервалах возможного отката в случае неудачной попытки апгрейда на фазе 2. Для этого на фазе Ф1 формируется архив записей интервалов возможных откатов. Моменты поступления последующих внутренних сообщений также фиксируются в архиве записей для каждого интервала.

При замене версии на фазе Ф1 может быть три ситуации в зависимости от обнаружения, не обнаружения ошибки или завершения фазы 1:

1. фаза 1 продолжается (Ф1-Ф1),

2. фаза 1 прекращается с переходом к фазе 2 (Ф1-ФП),

3. фаза 1 прекращается с прекращением попытки замены (Ф1- Ф3).

Алгоритм фазы Ф1 - Ф1 приведен на Рис. 10

Здесь введены обозначения:

t - текущее время замены версий на фазе Ф1, начальное значение t = 0; начальные значения i = 0, j = 0, k = 0, l = 0, s = 0, r = 0.

Массивы записей времени поступления внутренних сообщений и выполнения проверочных тестов:

СВ [i , 0], СВ [i , 1], ………, СВ [i , n_i] - интервалов для версии СВ

НВ [i , 0], НВ [i , 1],……… , НВ [i , n_j] - интервалов для версии НВ

ПС[k, 0], ПС[k, 1],…………, ПС[k, n_r] - интервалов для программ НП

ПН[l, 0], ПН[l, 0],……….., ПН[l, n_j] - интервалов для программ НП

служат для определения интервалов возможных откатов.

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

При решении этих моделей получены вероятности p_з (t) завершения замены версий за время t.

Для идеальной модели M1 имеем

. при л ? с

при л = с

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

Рис. 7 Модель M2

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

Если время отката не превышает заданного времени восстановления работоспсобности системы реального сремени, то следует воспользоваться схемой (а).

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

Особенностью методики выполнения контролируемой замены версий для бортовой вычислительной системы в режиме реального времени ее работы с использованием дополнительной промежуточной фазы является:

1.На первой фазы проверки работоспособности новой версии собирается информация об интервалах между соседними контрольными точками.

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

3.Во время выполнения второй фазы контроль новой версии осуществляется, если это выявлено на промежуточной фазы, более часто с помощью дополнительных ПT.

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

Записи СВ [i , 0] и СВ [i , n_i] задают соответственно первый (первое внутреннее сообщение) и последний элемент (проверочный тест) i -й записи, i = 0, 1,..

Записи НВ [i , 0], и НВ [i , n_j] задают соответственно первый (первое внутреннее сообщение) и последний элемент (проверочный тест) i -й записи, i = 0, 1,..

Записи ПС[k, 0], и ПС[k, n_r] задают соответственно первый (первое внутреннее сообщение) и последний элемент (проверочный тест) k -й записи, k = 0, 1,..

Записи ПН[l, 0], и ПН[l, n_j] задают соответственно первый (первое внутреннее сообщение) и последний элемент (проверочный тест) l -й записи, l = 0, 1,..

Рис. 2 Блок ситуации Ф1-Ф1

Ниже приведена оценка для четвертой (г) схемы восстановления имеем.

Пусть:

t / k - время выполнения вычислительного процесса на одном подинтервале,

k - число подинтервалов выполнения вычислительного процесса,

n - число интервалов выполнения вычислительного процесса,

р (t / k) - вероятность возникновения сбоя в процессе за время t / k выполнения вычислительного процесса,

t _кт - время, необходимое для образования контрольной точки ,

t _ср - время выполнения сравнения соответствующих внутренних сообщений или искусственного проверочного теста ИКТ,

t _отк - время, необходимое для обеспечения отката назад - возврат к старой версии.

Время накладных расходов при выполнении вычислительного процесса на одном интервале равно:

i * t _ср + t _кт + t _отк с вероятностью р ^i-1 (t / k ) (1- р (t / k ) ) при i = 1, k-1

k * t _ср + t _кт + t _отк с вероятностью р ^k (t / k).

Тогда среднее время накладных расходов при выполнении вычислительного процесса для n интервалов равно:

Полагая, что функция распределения вероятностей появления сбоя подчиняется экспоненциальному распределению:

,

имеем среднее время накладных расходов:



Время потери управления объектом при прекращении замены на одном интервале равно:

i * t + t _ср + t _отк с вероятностью р ^i-1 (t / k ) (1- р (t / k ) ) при i = 1, k-1.

Время потери управления объектом при прекращении замены:

Рис. 6 Четыре способа обеспечения восстановления

Для количественной оценки эффективности схем восстановления естественно использовать 1).время накладных расходов при выполнении задания и 2).время потери управления объектом при прекращении замены (на второй фазы) из-за сбоя в новой программной версии (и возврате к старой версии).

В работе проведена оценка качества схем восстановления для всех четырех схем восстановления.

Алгоритм фазы Ф1 - Ф3 в случае не удачной попытки замещения версий протокола ПЗП приведен на Рис.3.

Рис. 3 Ситуация Ф1- Ф3 (Не успешное завершение замены)

Алгоритм перехода от фазы Ф1к промежуточной фазе ФП приведен на

Рис. 4.

Рис. 4 Переход от фаза Ф1 к фазе ФП

Алгоритм перехода от промежуточной фазы ФП к фазе Ф2 приведен на Рис. 5.

Рис. 5 Переход от фазы ФП к фазе Ф2

Алгоритм протокола фазы Ф2 развивается в зависимости от обнаружения или не обнаружения ошибки:

1. фаза 2 продолжается (Ф2 - Ф2),

2. фаза 2 прекращается в связи с неудачной попыткой замены (Ф2 - Ф3)

3. фаза 2 прекращается в связи с удачным завершением замены (Ф2 - Ф0).

Алгоритм фазы Ф2 - Ф3, Ф2 - Ф0 и Ф2 - Ф2 приведены в главе 2 работы.

Алгоритм выполнения промежуточной фазе ФП базируется на основе способов обеспечения восстановления и оценки их эффективности.

В работе предлагаются четыре способа восстановления на интервале отката:

а) - использование контроля в конце интервала и отката в начало интервала. Контрольные точки сохраняются в соответствии с базовым алгоритмом протокола. Если старая версия СВ или новая версия НВ, или программа НП не проходит проверочный тест ПТ, то происходит откат назад; если проверочный тест ПТ проходит, то система функционирует, используя новую версию НВ, см. рис.6 а.

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

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

г) использование контроля в конце подинтервала и отката на интервал. Интервал вычислительного процесса (от времени образования контрольной точки до времени выполнения проверочного теста ПТ) делится на поинтервалы. В конце каждого подинтервала выполняется сравнение полученных для программы НП внутренних сообщений от новой НП и старой СВ версий или проводится искусственный проверочный тест ИПТ, время наступления которых определяется на основе информации, полученной на первой фазы успешной замены. Если процесс не проходит сравнение или проверочный тест ИПТ, то происходит откат назад в начало интервала; если сравнение или проверочный тест ИПТ проходит, то новая контрольная точка не образуется, см. рис.6 г. На рис.6 неправилное выполнение программ из-за ошибки в новой версии НВ обнаружено в конце подинтервала 3.

Размещено на Allbest.ru