СПОСОБ Я.А. ГОРБАДЕЯ ОБЕСПЕЧЕНИЯ НАДЕЖНОЙ РАБОТЫ ПРОГРАММНОГО ВЫЧИСЛИТЕЛЬНОГО СРЕДСТВА Российский патент 2007 года по МПК G06F11/00 

Область техники, к которой относится изобретение

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

Уровень техники

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

Так, в патенте РФ №2011216 (15.04.1994) описано устройство для контроля управляющей вычислительной машины, в котором при переходе к обработке прерывания контролируется общая для внешних и внутренних прерываний часть временной диаграммы.

В патенте РФ №2050588 (20.12.1995) описан способ контроля и отладки программ реального времени и устройство для его осуществления. В этом способе имеется четыре режима локализации ошибки, в каждом из которых сравнивается адрес некоторой ячейки с адресом, набранном тумблерами.

Патент РФ №2066877 (20.09.1996) описывает устройство для контроля электронной вычислительной машины, в котором обнаруживаются ошибки передачи управления путем сравнения реальных адресов с допустимыми.

Патент РФ №2094842 (27.10.1997) раскрывает другое устройство для контроля управляющей вычислительной машины, в котором контролируется правильность порядка обращения к модулям этой вычислительной машины, правильность порядка включения в работу подпрограмм обслуживания прерываний и правильность перехода на новый линейный участок программы.

В заявке РФ №2001118437 (10.06.2003) описан способ распределения времени центрального процессора между задачами в автоматизированных системах управления технологическими процессами при помощи файла управления планированием. В этом способе, основанном на распределении приоритетов выполнения задач, задают цикл последовательности переключения задач в соответствии с их приоритетностью, определенной еще на этапе проектирования.

В патенте США №5966530 (12.10.1999) раскрыт способ сохранения машинного состояния с командными границами. В этом способе каждой команде в момент ее выдачи присваивается идентификационная метка, которая связывается с местоположением в памяти. Данные в этом местоположении обновляются в ответ на изменения статуса активности команды.

В другом патенте США №6374364 (16.04.2002) описана нечувствительная к ошибкам вычислительная система, использующая счет команд, в которой прерывание наступает после заданного числа выполненных команд.

В заявке США №2002/0178209 (28.11.2002) раскрыт способ для определения загрузки вычислительного элемента, в котором программа разбивается на задачи, и временные интервалы между прерываниями выбираются так, чтобы во время этого интервала начиналась и заканчивалась хоть одна задача.

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

Наиболее близкий к заявленному изобретению аналог описан в патент США №5911040 (08.06.1999). Раскрытая в этом документе вычислительная система нечувствительна к ошибкам вследствие того, что при обнаружении ошибки в ходе выполнения программы производится возврат к предыдущей проверочной точке и перезапуск программы с этой проверочной точки, причем образ проверочных точек сохраняется в памяти процессора. Однако и такой способ не обеспечивает требуемой надежности, т.к. в нем не распознаются типы сбоев (ошибок), а следовательно, нет возможности исправлять эти сбои (ошибки) различным образом в зависимости от их типа.

Сущность изобретения

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

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

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

Краткое описание чертежей

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

Фиг.1 иллюстрирует общий механизм функционирования ПВС и исполняемой программы.

Фиг.2 является блок-схемой алгоритма функционирования ПВС в случае обработки прерываний М-типа.

Фиг.3 является блок-схемой алгоритма функционирования ПВС в случае обработки прерываний С-типа без обращения к подпрограмме.

Фиг.4 является блок-схемой алгоритма функционирования ПВС в случае обработки прерываний С-типа при обращении к подпрограмме.

Фиг.5 является блок-схемой алгоритма функционирования ПВС в случае обработки прерываний Т-типа для системного времени.

Фиг.6 является блок-схемой алгоритма функционирования ПВС в случае обработки прерываний Т-типа для программного времени.

Подробное описание изобретения

Прежде чем перейти к описанию предложенного способа, сделаем некоторые пояснения.

В процессе функционирования любой системы, которая является программным вычислительным средством (ПВС) или в которой используется ПВС (как известно из уровня техники, например, из ближайшего аналога - патента США №5911040), необходимо автоматически и как можно раньше распознавать наступивший сбой вычислительного процесса в такой системе. В противном случае такой нераспознанный сбой за весьма короткое время (не более миллисекунды) и с вероятностью, близкой к 1, приведет к отказу всей системы.

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

- несохранение содержимого памяти (сбой М-типа, от "Memory"), - это, например, аппаратный сбой или отказ ОЗУ, обнаруживаемый блоком контроля четности во время исполнения текущей команды, либо несанкционированная запись в ОЗУ, либо несохранение состояния регистров какого-либо внешнего устройства;

- неверная передача управления в процессоре (сбой С-типа, от "Control"), - это, например, ложное обнаружение или ложный пропуск прерывания от внешнего устройства, либо несанкционированная передача управления в произвольный адрес ОЗУ;

- недопустимое время работы (сбой Т-типа, от "Time"), - это, например, недопустимо быстрый или медленный ответ внешнего устройства, либо зацикливание программы, либо остановка процессора.

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

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

для ОЗУ - постраничная эквивалентность или переместимость программ или данных в пределах сохранения межстраничных связей.

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

Предложенное изобретение основано на использовании указанных избыточных ресурсов, причем это использование занимает несколько процентов времени и памяти процессора ПВС. Условно можно говорить о создании в ПВС М-службы, С-службы и Т-службы надежности.

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

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

Идея С-службы основана на том, чтобы своевременно обнаруживать потерю управления, приводящую к неверной передаче управления в любой адрес ОЗУ, инициируя программно-аппаратное прерывание при исполнении каждой команды передачи управления. Далее рассмотрим исчерпывающий перечень вариантов произвольной передачи управления.

Для обнаружения потери управления, приведшей к передаче управления в неиспользуемую память, нужно записать во все неиспользуемые слова страниц, а также в нулевое и последнее слова используемых страниц команду-ловушку типа CALL LCONT обращения к системной подпрограмме, предназначенной для анализа потери управления. Тогда при случайной передаче управления в такие адреса произойдет обращение к этой системной процедуре с указанием места возможного конфликта. Таким образом, запрещаются непосредственные линейные передачи управления из текущей страницы в следующую.

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

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

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

- часы реального времени микросекундного масштаба (тактовая последовательность ПВС);

- часы миллисекундного масштаба, дающие прерывания, например, каждые 20 мс;

- системные часы секундного масштаба с независимым от электросети батарейным питанием, с ценой единицы младшего разряда 1 с и не менее чем 25-разрядным регистром счетчика секунд (рассчитанный на ≈3,14×10⁷ сек/год).

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

Общим средством преодоления наступившего сбоя после распознавания и регистрации его особенностей должно быть некоторое заранее заданное количество попыток повторить данную ветвь вычислительного процесса, начиная с ближайшей предшествующей контрольной точки, или точки перезапуска, определяемой характером наступившего сбоя (проверочная точка в ближайшем аналоге - патенте США №5911040).

Способ по настоящему изобретению реализуется, как уже сказано, в любой системе с программным вычислительным средством (ПВС). В таком средстве процессор исполняет программы, которые хранятся в ОЗУ этого процессора. На фиг.1 условно показан общий механизм функционирования памяти ПВС. Этот механизм предусматривает, как обычно, загрузку некоторой пользовательской программы в пространство памяти пользователей, запуск этой программы и происходящие в процессе исполнения этой программы прерывания М-типа, С-типа и Т-типа. Каждое из этих прерываний приводит к запуску соответствующих обработок, алгоритмы которых показаны на одной из фиг.2-6. На каждом из этих чертежей имеется разметка, сходная с разметкой шахматной доски, которая облегчает идентификацию соответствующего действия в том или ином алгоритме. Буквенная часть этой разметки (т.е. латинские буквы в обозначении столбцов на чертежах) изменяется от чертежа к чертежу, а цифровая часть (т.е. нумерация строк на чертежах) остается без изменений. При этом некоторые действия на фиг.2-6 обозначены буквами русской азбуки, отличными от латинских букв, в качестве шагов, на которые имеются ссылки в приложенной формуле изобретения. На фиг.2-6 введены следующие сокращения: п/п - подпрограмма, п/у - передача управления, с/ж - системный журнал.

Блок-схема алгоритма функционирования ПВС в случае обработки прерываний М-типа показана на фиг.2. Обработка прерывания М-типа начинается с определения контекста сбоя М-типа (блок А1). После этого на шаге Б) проверяется сохранность контекста исполняемой программы (блок А2). Результат этой проверки (блок A3) фиксируют в системном журнале (блок А4 в случае, если контекст цел, блок В1 в случае, если контекст не сохранен). Если в шаге Б) контекст исполняемой программы сохранен, то после фиксации в системном журнале характеристик наступившего сбоя (блок А4) проверяют, происходил ли этот сбой ранее (блок А5). Если наступивший сбой ранее не происходил, на шаге Г) определяют контекстную точку перезапуска исполняемой программы (блок А6), после чего осуществляют повторное выполнение (перезапуск) исполняемой программы, начиная с найденной на шаге Г) точки перезапуска.

Если контекст исполняемой программы сохранен, а случившийся сбой происходил ранее, то после фиксации этого факта в системном журнале как отказа ПВС в данной конфигурации (блок В4) проверяют на шаге Д), происходил ли такой отказ ранее (блок В5). Если такого отказа ранее не происходило, изменяют конфигурацию ПВС для исполняемой программы (блок В6) и переходят к упомянутому шагу Г), т.е. к блоку А6, для определения контекстной точки перезапуска и для перезапуска исполняемой программы.

Если на шаге Б) выявлено, что контекст исполняемой программы не сохранен, то после фиксации в системном журнале характеристик наступившего сбоя М-типа (блок В1) на шаге Ж) проверяют, происходил ли такой сбой ранее (блок В2). Если такой сбой ранее не происходил, восстанавливают контекст исполняемой программы (блок В3) и переходят к упомянутому шагу Г), т.е. к блоку А6, для определения контекстной точки перезапуска и для перезапуска исполняемой программы.

Если на шаге Д) или на шаге Ж) выявлено, что соответствующий отказ или сбой уже происходил ранее, то фиксируют в системном журнале характеристики наступившего системного сбоя (блок С1) и проверяют на шаге З) сохранность контекста операционной системы ПВС (блок С3). Если контекст упомянутой операционной системы сохранен (блок С4), то фиксируют этот факт в системном журнале как возможный сбой в работе ПВС (блок С5) и проверяют на шаге И), происходил ли такой сбой ранее (блок С6). Если такой сбой ранее не происходил, переходят к упомянутому шагу Г). Если же на шаге 3) выявлено, что контекст упомянутой операционной системы не сохранен (блок С4), либо на шаге И) выявлено, что такой сбой в работе ПВС уже происходил ранее (блок С6), аварийно завершают на шаге Л) все работающие в ПВС программы (блок D3), после чего восстанавливают тело упомянутой операционной системы (блок D4), фиксируют в системном журнале системный сбой (блок D5) и перезапускают упомянутую операционную систему (блок D6).

Следует особо отметить, что действия в столбцах А и В фиг.2 относятся к программному сбою, а действия в столбцах С и D - к системному сбою.

Блок-схема алгоритма функционирования ПВС для обработки прерываний С-типа в случае передачи управления показана на фиг.3, а в случае обращения к подпрограмме - на фиг.4. Обработка прерывания С-типа начинается с определения того, какое прерывание С-типа произошло. При этом определяют контекст наступившего прерывания С-типа (блок Е1 на фиг.3) либо контекст обращения к подпрограмме (блок Е5 на фиг.4) в зависимости от того, произошла передача управления в выполняемой программе или произошло обращение к подпрограмме.

В случае передачи управления (см. фиг.3, блок Е1) проверяют, является ли эта передача управления предусмотренной передачей управления (блок F1). Если данная передача управления является предусмотренной, находят точку выполнения исполняемой программы на ее временной диаграмме (блок Е2) и проверяют, допустимо ли текущее время (блок F2). Если найденная точка исполнения соответствует допустимому текущему времени, продолжают выполнение исполняемой программы (блок Е3). Если найденная точка выполнения не соответствует допустимому текущему времени, фиксируют этот факт в системном журнале как сбой Т-типа (блок G3) и проверяют, происходил ли такой сбой ранее (блок Н2). Если такой сбой ранее не происходил, переходят к шагу Б) (см. фиг.2), а если такой сбой происходил ранее, переходят к шагу Д) (см. фиг.2).

Если же (блок F1) передача управления не предусмотрена, проверяют, является ли данная передача управления командой-ловушкой (блок G1), т.е. командой передачи управления по заранее заданному вектору, которой при запуске ПВС заполняют всю неиспользуемую исполняемыми программами оперативную память. В зависимости от того, является или не является данная передача управления командой-ловушкой, фиксируют в системном журнале соответственно либо характеристики потери управления (блок H1), либо характеристики сбоя С-типа (блок G2), после чего в обоих случаях проверяют, происходило ли такое событие ранее (блок Н2). Если такое событие ранее не происходило, переходят к шагу Б) (см. фиг.2), а если происходило - к шагу Д) (см. фиг.2).

В случае обращения к подпрограмме (см. фиг.4, блок Е5) проверяют, является ли это обращение правильным (блок F5), и если да, то осуществляют это обращение, а при возврате из данной подпрограммы проверяют, является ли этот возврат правильным (блок G6), и если да, возвращаются в исполняемую программу. Если же проверка правильности обращения к подпрограмме (блок F5) или проверка правильности возврата из подпрограммы (блок G6) дает отрицательный результат, то фиксируют в системном журнале сбой С-типа при обращении к данной подпрограмме (блок G5) и проверяют, происходил ли такой сбой ранее (блок Н5). Если такой сбой ранее не происходил, переходят к шагу Б) (см. фиг.2), а если происходил - к шагу Д) (см. фиг.2).

На фиг.5 и 6 показаны блок-схемы алгоритмов функционирования ПВС для обработки прерываний Т-типа для системного времени и для программного времени, соответственно. Конкретный вид обработки прерываний Т-типа для системного времени зависит от того, по вектору каких часов происходит это прерывание. Эти часы, т.е. по меньшей мере три независимые последовательности временных тактов разного масштаба, генерируются входящими в ПВС генераторами последовательностей временных интервалов. Первая из этих последовательностей, именуемая далее часами ТМ (от time micro), является тактовой последовательностью ПВС, т.е. имеет временные промежутки порядка микросекунд и даже менее (в зависимости от тактовой частоты используемого процессора), вторая из этих последовательностей, именуемая далее часами ТС (от time centi), имеет временные промежутки порядка миллисекунд, а третья последовательность, именуемая далее часами ТН (от time hour), имеет временные промежутки порядка секунд или минут, как описано выше в общих принципах способа по настоящему изобретению. Конкретные величины временных промежутков всех трех указанных часов определяются как конструктивными особенностями используемого ПВС, так и особенностями программного обеспечения, применяемого в этом ПВС.

Для обработки прерываний системного времени (фиг.5) при наступлении прерывания по вектору часов ТМ сначала считывают значения часов ТМ и часов ТС (блок I1), после чего проверяют, совпадают ли значения часов ТМ и часов ТС (блок J1), и при совпадении значений часов ТМ и часов ТС осуществляют перезапуск часов ТМ (блок I2). В отсутствие же совпадения значений часов ТМ и часов ТС считывают значения часов ТН (блок К1) и проверяют совпадение значений часов ТС и часов ТН (блок К2). Если на этом шаге значения часов ТС и часов ТН совпадают, фиксируют в системном журнале сбой часов ТМ (блок J2) и проверяют на шаге П), происходил ли такой сбой ранее (блок J3). Если такой сбой ранее не происходил, осуществляют перезапуск часов ТМ (блок J4), после чего переходят к шагу З) (см. фиг.2), а если такой сбой происходил ранее, переходят к шагу Л) (см. фиг.2).

В отсутствие совпадения значений часов ТС и часов ТН считывают значения мировых астрономических часов, именуемых далее часами TW (от time world) (блок L1) и проверяют совпадение значений часов ТН и часов TW (блок L2). Если на этом шаге значения часов ТН и часов TW совпадают, фиксируют в системном журнале сбой часов ТС (блок L3) и часов ТМ и проверяют на шаге Ф), происходил ли такой сбой ранее (блок К3). Если такой сбой не происходил ранее, осуществляют перезапуск часов ТС (блок К4), затем перезапуск часов ТМ (блок J4), после чего переходят к шагу З) (см. фиг.2). Если же при проверке на шаге Ф) (блок К3) выявляют, что такой сбой происходил ранее, переходят к шагу Л) (см. фиг.2).

При наступлении прерывания по вектору часов ТС сначала считывают значения часов ТС и часов ТН (блок 14), после чего проверяют, совпадают ли значения часов ТС и часов ТН (блок J5), и при совпадении значений часов ТС и часов ТН осуществляют перезапуск часов ТС (блок 15). В отсутствие же совпадения значений часов ТС и часов ТН считывают значения часов TW (блок К5) и проверяют совпадение значений часов ТН и часов TW (блок L5). Если на этом шаге значения часов ТН и часов TW совпадают, фиксируют в системном журнале сбой часов ТС (блок L3) и переходят к шагу Ф).

Если же значения часов ТН и часов TW не совпадают (блок L5), то после фиксации в системном журнале факта сбоя часов ТН (блок Кб) проверяют на шаге Ц), происходил ли такой сбой ранее (блок L6). Если такой сбой не происходил ранее, переходят к шагу З) (см. фиг.2), а если происходил - к шагу Л) (см. фиг.2).

При наступлении прерывания по вектору часов ТН сначала считывают значения часов ТН и часов TW (блок 16), после чего проверяют, совпадают ли значения часов ТН и часов TW (блок J6), и при совпадении значений часов ТН и часов TW осуществляют перезапуск часов ТН (блок 17). Если же значения часов ТН и часов TW не совпадают, фиксируют в системном журнале факт сбоя часов ТН (блок К6) и переходят к шагу Ц) (блок L6).

В процессе реальной работы пользовательских прикладных программ с временными событиями могут быть два способа привязки временных диаграмм событий к текущему времени. Для управляемых пользовательской программой временных процессов они могут быть привязаны к относительному программному времени, а для неуправляемых, но запрашиваемых программой событий, - к абсолютному системному времени. Эти варианты показаны на фиг.6а и 6в соответственно.

Для относительного программного события (фиг.6а, блок M1) проверяют правильность момента наступления этого события (блок N1), и если этот момент правильный, осуществляют возврат в исполняемую программу. Если же момент наступления упомянутого события неправильный, определяют программный контекст ошибки времени (блок О1) и после фиксации в системном журнале наступившего Т-сбоя (блок Р1) переходят к шагу Б) (см. фиг.2).

Для абсолютного программного события (фиг.6и, блок М3) определяют факт наступления этого события (блок М4), и если это событие наступило, осуществляют возврат в исполняемую программу. Если же это событие не наступило, определяют контекст исполняемой программы (блок N3) и после фиксации в системном журнале характеристик данного сбоя (блок О3) проверяют сохранность контекста исполняемой программы (блок Р3). При сохранности контекста исполняемой программы (блок Р4) осуществляют возврат в исполняемую программу, а если контекст исполняемой программы не сохранен, переходят к шагу Ж) (см. фиг.2).

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

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

Литература

1. Кнут Д. Искусство программирования для ЭВМ, М.: Мир, с.388, 1976.

2. Вирт Н. Систематическое программирование. М.: Мир, 1977.

Изобретение относится к области вычислительной техники. Технический результат изобретения заключается в возможности своевременно распознавать сбои, возникающие в процессе функционирования программного вычислительного средства, и реагировать на сбой каждого типа соответственно. Технический результат достигается за счет того, что заранее определяют состояния исполняемой программы, отличные от ее начального и конечного состояний, именуемые точками перезапуска, для возобновления работы исполняемой программы после сбоя в процессе ее выполнения; при наступлении прерывания вследствие соответствующего контроля выявляют следующие сбои: а) ошибка сохранения содержимого оперативной памяти - путем контроля соответствующей части содержимого оперативной памяти, б) передача управления ненадлежащей команде - путем контроля правильности каждой передачи управления в процессоре, и в) различные прерывания по времени - путем контроля продолжительности работы соответствующей части исполняемой программы и самой заданной операционной системы; при обработке соответствующего прерывания и наступлении любого из распознаваемых сбоев при допустимых условиях продолжения работы перезапускают выполнение исполняемой программы, начиная с ближайшей предшествующей данному прерыванию точки перезапуска. 1 н. и 4 з.п. ф-лы, 7 ил.

1. Способ обеспечения надежной работы программного вычислительного средства (ПВС), включающего в себя по меньшей мере:

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

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

генераторы последовательностей временных интервалов;

заключающийся в том, что:

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

- в процессе выполнения исполняемой программы в упомянутом ПВС при наступлении прерывания вследствие соответствующего контроля выявляют следующие сбои в работе упомянутого ПВС: а) ошибка сохранения содержимого оперативной памяти, далее именуемая прерыванием М-типа - путем контроля соответствующей части содержимого упомянутой оперативной памяти, б) передача управления ненадлежащей команде, далее именуемая прерыванием С-типа - путем контроля правильности каждой передачи управления в упомянутом процессоре, и в) различные прерывания по времени, далее именуемые прерываниями Т-типа - путем контроля продолжительности работы соответствующей части упомянутой исполняемой программы и самой заданной операционной системы;

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

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

- проверяют на шаге Б) сохранность контекста упомянутой исполняемой программы с фиксацией результата этой проверки в системном журнале;

- если в шаге Б) контекст исполняемой программы сохранен, то после фиксации в системном журнале характеристик наступившего сбоя проверяют, происходил ли этот сбой ранее;

- если наступивший сбой ранее не происходил, выполняют шаг Г) по определению контекстной точки перезапуска исполняемой программы, после чего и осуществляют упомянутое повторное выполнение исполняемой программы;

- если контекст исполняемой программы сохранен, а случившийся сбой происходил ранее, то фиксируют на шаге Д) этот факт в системном журнале как отказ ПВС в данной конфигурации и проверяют, происходил ли такой отказ ранее;

- если такого отказа ранее не происходило, изменяют конфигурацию ПВС для исполняемой программы и переходят к упомянутому шагу Г);

- если на шаге Б) выявлено, что контекст исполняемой программы не сохранен, то фиксируют на шаге Ж) в системном журнале характеристики наступившего сбоя М-типа и проверяют, происходил ли такой сбой ранее;

- если такой сбой ранее не происходил, восстанавливают контекст исполняемой программы и переходят к упомянутому шагу Г);

- если на шаге Д) или на шаге Ж) выявлено, что соответствующий отказ или сбой уже происходил ранее, то фиксируют в системном журнале характеристики наступившего системного сбоя и проверяют на шаге 3) сохранность контекста операционной системы ПВС;

- если контекст упомянутой операционной системы сохранен, то фиксируют этот факт в системном журнале как возможный сбой в работе ПВС и проверяют на шаге И), происходил ли такой сбой ранее;

- если такой сбой ранее не происходил, переходят к упомянутому шагу Г);

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

- определяют контекст наступившего прерывания М-типа, после чего выполняют упомянутый шаг Б).

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

в случае передачи управления:

- проверяют, является ли эта передача управления предусмотренной передачей управления;

- если данная передача управления является предусмотренной, находят точку выполнения упомянутой исполняемой программы на ее временной диаграмме и проверяют, допустимо ли текущее время;

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

- если найденная точка выполнения не соответствует допустимому текущему времени, фиксируют этот факт в системном журнале как сбой Т-типа и проверяют, происходил ли такой сбой ранее;

- если такой сбой ранее не происходил, переходят к упомянутому шагу Б);

- если такой сбой происходил ранее, переходят к упомянутому шагу Д);

- если упомянутая передача управления не предусмотрена, проверяют, является ли данная передача управления командой передачи управления по заранее заданному вектору, именуемой далее командой-ловушкой, которой при запуске ПВС заполняют всю неиспользуемую исполняемыми программами оперативную память;

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

- если такое событие ранее не происходило, переходят к упомянутому шагу Б), а если происходило - к упомянутому шагу Д);

в случае обращения к подпрограмме:

- проверяют, является ли это обращение правильным, и если да, то осуществляют это обращение, а при возврате из данной подпрограммы проверяют, является ли этот возврат правильным, и если да, возвращаются в упомянутую выполняемую программу;

- если проверка правильности обращения к подпрограмме или проверка правильности возврата из подпрограммы дает отрицательный результат, то после фиксации в системном журнале сбоя С-типа при обращении к данной подпрограмме проверяют, происходил ли такой сбой ранее;

- если такой сбой ранее не происходил, переходят к упомянутому шагу Б), а если происходил - к упомянутому шагу Д).

для системного времени:

при наступлении прерывания по вектору часов ТМ:

- проверяют совпадение значений часов ТМ и часов ТС;

- при совпадении значений часов ТМ и часов ТС осуществляют перезапуск часов ТМ;

- в отсутствие совпадения значений часов ТМ и часов ТС проверяют совпадение значений часов ТС и часов ТН;

- при совпадении на этом шаге значений часов ТС и часов ТН фиксируют в системном журнале сбой часов ТМ и проверяют на шаге П), происходил ли такой сбой ранее;

- если такой сбой ранее не происходил, осуществляют перезапуск часов ТМ, после чего переходят к упомянутому шагу 3);

- если такой сбой происходил ранее, переходят к упомянутому шагу Л);

- в отсутствие совпадения значений часов ТС и часов ТН проверяют совпадение значений часов ТН и мировых астрономических часов, именуемых далее часами TW;

- при совпадении на этом шаге значений часов ТН и часов TW фиксируют в системном журнале сбой часов ТС и часов ТМ и проверяют на шаге Ф), происходил ли такой сбой ранее;

- если такой сбой не происходил ранее, осуществляют перезапуск часов ТС, затем перезапуск часов ТМ, после чего переходят к упомянутому шагу 3);

- если при проверке на упомянутом шаге Ф) выявляют, что такой сбой происходил ранее, переходят к упомянутому шагу Л);

при наступлении прерывания по вектору часов ТС:

- проверяют совпадение значений часов ТС и часов ТН;

- при совпадении значений часов ТС и часов ТН осуществляют перезапуск часов ТС;

- в отсутствие совпадения значений часов ТС и часов ТН проверяют совпадение значений часов ТН и часов TW;

- при совпадении на этом шаге значений часов ТН и часов TW фиксируют в системном журнале факт сбоя часов ТС и переходят к упомянутому шагу Ф);

- в отсутствие совпадения значений часов ТН и часов TW фиксируют в системном журнале факт сбоя часов ТН проверяют на шаге Ц), происходил ли такой сбой ранее;

- при совпадении значений часов ТН и часов TW после фиксации в системном журнале факта сбоя часов ТС проверяют на шаге Ф), происходил ли такой сбой ранее;

- если такой сбой не происходил ранее, переходят к упомянутому шагу 3), а если происходил - к упомянутому шагу Л);

при наступлении прерывания по вектору часов ТН:

- проверяют совпадение значений часов ТН и значений часов TW;

- при совпадении значений часов ТН и часов TW осуществляют перезапуск часов ТН;

- в отсутствие совпадения значений часов ТН и часов TW фиксируют в системном журнале факт сбоя часов ТН и переходят к упомянутому шагу Ц);

для программного времени:

для относительного программного события:

- проверяют правильность момента наступления этого события, и если этот момент правильный, осуществляют возврат в упомянутую исполняемую программу;

- если же момент наступления упомянутого события неправильный, определяют программный контекст ошибки времени и после фиксации в системном журнале наступившего Т-сбоя переходят к упомянутому шагу Б);

для абсолютного программного события:

- определяют факт наступления упомянутого события, и если это событие наступило, осуществляют возврат в упомянутую исполняемую программу;

- если же упомянутое событие не наступило, определяют контекст упомянутой исполняемой программы и после фиксации в системном журнале характеристик данного сбоя проверяют сохранность контекста исполняемой программы;

- при сохранности контекста исполняемой программы осуществляют возврат в упомянутую исполняемую программу;

- если контекст исполняемой программы не сохранен, переходят к упомянутому шагу Ж).