CC BY
64
правильную интерпретацию которых несет прикладной программист. Концептуальная недоработка заключается в том, что особой функции, вызов которой порождал бы событие ClientMessage, в X Window не предусмотрено, это событие наступает в результате вызова функции-имитатора событий XSendEvent.
Обмен данными между клиентскими программами. Одна из типичных задач интерактивной графики - копирование данных, отображенных в окне. Копирование может осуществляться в пределах одного и того же окна или из одного окна в другое, причем данные в этих окнах могут отображаться разными клиентскими программами. Будем считать, что выполняется копирование текста из окна одного текстового редактора в окно другого. Для решения подобных задач в X Window предусмотрены события SelectionRequest («выдан запрос на копирование выделенных данных»), SelectionNotify («выделенные данные скопированы») и SelectionClear («отмена выделения данных, подлежащих копированию»). При копировании фрагмента текста события могут развиваться по следующему сценарию.
1. Манипулируя клавиатурой и/или мышью, оператор выделяет фрагмент текста, подлежащий копированию. Информировать систему о желании скопировать выделенный текст он может, например, одновременным нажатием клавиш CNTRL и C.
2. Зафиксировав событие KeyPress, сервер направляет извещения тем клиентским программам, которые заказали его для окна отправки (среди этих программ должна быть, очевидно, программа-отправитель, то есть первый текстовый редактор).
3. Программа-отправитель, получив извещение о событии KeyPress и выяснив, что нажаты клавиши CNTRL и C, вызывает функцию XSetSelectionOwner.
4. Сервер интерпретирует запрос XSetSelection-Owner как сигнал о том, что имеются данные, подлежащие копированию, и запоминает этот факт. Примечание. Запрос XSetSelectionOwner может оказаться повторным. Это может произойти в том случае, если оператор передумал и решил копировать другой фрагмент текста, возможно, даже в другом окне и относящемся к другой клиентской программе, то есть выделил другой фрагмент и снова нажал на клавиши CNTRL и C. Этот второй запрос сервер интерпретирует как сигнал о том, что имеются другой подлежащий копированию фрагмент, а копирование первого нужно отменить. Отмена копирования фиксируется как событие SelectionClear.
5. Оператор переводит курсор в другое окно, а информировать систему о своем желании скопировать в него выделенный фрагмент он может, например, одновременным нажатием клавиш CNTRL и V.
6. Зафиксировав событие KeyPress, сервер направляет извещения тем клиентским программам, которые заказали его для окна приема (среди этих программ должна быть, очевидно, программа получатель, то есть второй текстовый редактор).
7. Программа-получатель, получив извещение о событии KeyPress и выяснив, что нажаты клавиши СМТЯЬ и V, вызывает особую функцию XConvert-Selection.
8. Сервер интерпретирует вызов XConvert-Selection как запрос на копирование данных, то есть наступление события SelectionRequest, и направляет извещение о нем программе-отправителю (то есть первому редактору).
9. По событию SelectionRequest программа-отправитель выполняет копирование данных, после чего вызывает функцию XSendEvent, указав в качестве аргумента тип события SelectionNotify.
10. Сервер интерпретирует вызов XSendEvent как сигнал о завершении пересылки данных, то есть о наступлении события SelectionNotify, и направляет извещение о нем программе-отправителю.
Концептуальная погрешность заключается в том, что событие SelectionNotifУ, свидетельствующее о завершении копирования данных, может наступить только в результате вызова функции-имитатора XSendEvent, а не специально предназначенной для этого функции (по аналогии с XSetSelection-Owner и XConvertSelection). Эта погрешность наглядно демонстрируется таблицей, в которой приведены типы событий, соответствующие им типы структур данных, передаваемых в составе извещения, и функции, вызов которых порождает эти события.
Таблица
Событие Извещение (тип структры) Функция
SelectionClear XSelectionClearEvent XSetSelectionOwer
SelectionRequest XSelectionRequestEvent XConvertSelection
SelectionNotify XSelectionEvent XSendEvent
ClientMessage XClientMessageEvent XSendEvent
В статье приведены примеры концептуальных недоработок в классической системе интерактивной машинной графики X Window. Вопрос о том, как они влияют на характеристики системы или что было бы, если бы их не было, не обсуждается - это была бы другая система. Важно, что указанные концептуальные недоработки служат источником недоразумений, что затрудняет не только изучение и освоение, но и эксплуатацию, модернизацию, а также развитие системы. Ясное их осознание должно помочь в преодолении этих трудностей.
СРЕДСТВА ПРОТОКОЛИРОВАНИЯ В OC2000
А.Н. Годунов, к.ф.-м.н., Л.В. Жихарский, П.Е. Назаров, Ф.Н. Чемерев (Москва)
Системы реального времени (СРВ) - это программно-аппаратные комплексы, функционирование
которых связано с временными ограничениями. Для некоторых из них фиксировано критическое время
отклика на событие: ситуация, в которой вычисления не были завершены в заданные сроки, считается программной ошибкой (ошибкой реального времени (РВ)). Такие системы принято называть системами жесткого РВ.
Основными методами отладки СРВ являются: интерактивная отладка, допускающая вмешательство пользователя в работу отлаживаемой программы; сбор данных о работе отлаживаемой системы в сочетании с их оперативным или отложенным анализом (мониторинг); использование средств самоконтроля программ (см.: Tsai J., Bi Y., Yang S., Smith R., Distributed real-time systems. Monitoring, visualization, debugging, and analysis - Wiley-Interscience Publication, 1996).
Практика показывает, что возможностей средств интерактивной отладки оказывается недостаточно при локализации и установлении причин ошибок РВ (нарушение сроков) и обычных ошибок (логических, утечки ресурсов, ошибок указателей) в системах с длительным периодом функционирования (редко встречающихся ошибок, а также ошибок, которые могут проявиться по прошествии нескольких часов после того, как программа выполнила некорректные действия).
Решение этих проблем требует порождения и накопления информации о событиях, происходящих в СРВ. Когда же ее оперативный анализ затруднен (например, в системах управления быстропротекаю-щими процессами), анализ событий после сбора данных является основным средством отладки. Порождение, накопление и анализ данных о событиях называется трассировкой (см.: The Open Group Base Specifications Issue 6, IEEE Std 1003.1-2001).
Средствами трассировки оснащены популярные операционные системы РВ (ОС РВ). В среде ОС QNX 4, например, таким средством является утилита monitor. Она перехватывает события микроядра и протоколирует их в заданный файл. Чтение журнала осуществляется с помощью утилиты msgprint, преобразующей результаты протоколирования в текст. Для анализа протокола может быть использован пакет DejaView, работающий в графической оболочке Photon. С его помощью события микроядра представляются в виде временных диаграмм (см.: Н. Горбунов, http://www.osp.ru/os/2000/05-06/025. htm).
В VxWorks трассировку системных событий, таких как переключения задач, запись в очередь сообщений, установка семафора, позволяет вести динамический анализатор WindView (см.: Wind River Systems, WindView User's Guide 1.0.1, October, 1995). Пользователю предоставляется возможность определения (и генерации) собственных событий. Монитор данных StethoScope (см.: Wind River Systems, StethoScope User's Manual, Release 4.1, March, 1992) позволяет анализировать характер изменения пользовательских и системных переменных и включает в себя также профилировщик процедур ScopeProfile.
Протоколирование в ос2000
Система протоколирования ОС РВ ос2000 предназначена для отладки прикладных программ реального времени, и получения их временных характери-
стик (см.: В.Л. Безруков, А.Н. Годунов, П.Е. Назаров, В.А. Солдатов, И.И. Хоменков. Введение в oc2000. //Вопросы кибернетики. М.: НИИСИРАН. 1999). Результатом протоколирования является протокол событий -файл, характеризующий поведение однопроцессорной целевой ЭВМ. Его записи содержат сведения как о событиях ОС, так и о событиях прикладной программы.
Интерфейс с системой протоколирования базируется на стандарте POSIX 1003.1 (см.: The Open Group Base Specifications Issue 6, IEEE Std 1003.1-2001). В частности, в соответствии с требованиями стандарта реализован механизм фильтрации событий и управления процессом протоколирования. События, связанные с управлением процессом протоколирования (запуск и останов протоколирования, установка фильтра протоколируемых событий и т.д.), также регистрируются в протоколе.
Наличие стандартного интерфейса с системой протоколирования позволяет пользователю создавать собственные программы мониторинга, в котором существенная роль отводится оперативному анализу. Примером такого решения является отладочный комплекс для целевых ЭВМ со сложной архитектурой, разработанный в НИИСИ РАН (см.: Н.И. Вьюко-ва, В.А. Галатенко, К.А. Костюхин, Н.В. Шмырев. Организация отладочного комплекса для целевых систем со сложной архитектурой. М.: НИИСИ РАН. 2004).
Вместе с тем система предоставляет ряд дополнительных возможностей, таких как протоколирование имен объектов ОС и значений пользовательских переменных в момент совершения событий любого типа.
Разработка прикладной программы (кросс-разработка) ведется с применением инструментальной ЭВМ, тогда как выполняется она на целевой ЭВМ. На инструментальной ЭВМ производится предварительная обработка файла протокола, полученного с помощью системы протоколирования ос2000, после чего он может быть просмотрен c помощью интерактивной программы «Трассировщик ОС РВ» (далее - Трассировщик).
Протокол событий отображается в виде таблицы. В процессе просмотра обеспечивается поиск и фильтрация записей протокола, удовлетворяющих заданным условиям. При обработке протокола, собирается статистика, отражающая распределение событий по контекстам (потокам управления и прерываниям) и участвующим в событии объектам ОС (семафорам, мьютексам и т.п.).
По запросу пользователя Трассировщик строит трассу состояний (временную диаграмму) процессора. Здесь под состоянием процессора понимается либо выполнение потока управления, либо обработка прерывания, либо простой. Трасса состояний содержит информацию о времени пребывания процессора в каждом состоянии и позволяет судить об использовании процессорного времени различными потоками управления. Соответствующие временные характеристики являются точными, а не усредненными, как в случае использования традиционных профилировщиков.
Временные диаграммы могут быть построены и для объектов ОС - потоков управления, семафоров, мьютексов, условных переменных, очередей сообщений.
Запись о событии. Запись протокола ос2000 содержит тип события, информацию о времени, когда событие произошло, идентификатор, соответствующий контексту (потоку управления или вектору прерывания), и идентификаторы объектов трассировки, участвовавших в этом событии (например, идентификатор семафора в случае попытки его захвата). Кроме того, записи протокола могут содержать дополнительные данные, характеризующие текущие состояния участников события (например, значение счетчика семафора).
Записи протокола сначала помещаются в буфер протокола. Перенос данных из буфера в файл может производиться автоматически по мере заполнения буфера или по явному требованию (ро$1х_1гасе_ Атк()).
Действия при переполнении буфера и файла протокола определяются атрибутами протокола. В частности, возможен останов протоколирования при переполнении буфера или файла протокола. Имеется также возможность циклической записи, когда при достижении конца буфера или файла запись продолжается в начало буфера или файла соответственно. В последнем случае новые записи замещают наиболее старые.
События ОС. Протоколирование событий ОС производится при условии, что режим протоколирования включен, а само событие удовлетворяет текущим условиям, определяющим круг протоколируемых в данный момент событий.
События ОС объединены в группы прерывания, исключительных ситуаций, переключения потоков, изменения состояния потоков, порождения и доставки сигналов, ожидания сигналов, распределения памяти, инициализации ОС и группы функций управления потоками, семафорами, мьютексами, условными переменными, очередями сообщений.
Разбиение на группы используется при задании фильтра событий как в процессе протоколирования, так и при его просмотре.
События прикладной программы выделены в отдельную группу. Их протоколирование производится посредством вызова функции posix_trace_ еуеиЦ). Примерами использования событий прикладной программы могут служить:
- периодическая регистрация значений переменных прикладной программы, в том числе параметров состояния реального объекта (температура, давление, расходы, скорость);
- события, возникающие при наступлении определенных условий как на реальном объекте (результаты срабатывания элементов автоматики), так и в самой программе (их можно ассоциировать с точками входа в функции и отдельными ветвями алгоритма, в частности, они могут генерироваться средствами самоконтроля программ (см.: К.А. Костюхин. Средства самоконтроля программ и их применение при отладке систем со сложной архитектурой. // Инфор-
мационная безопасность. Микропроцессоры. Отладка сложных систем М.: НИИСИРАН. 2004)).
Управление протоколированием. В ос2000 задать параметры, определяющие характер протоколирования, можно двумя способами: посредством вызова функций управления трассировкой непосредственно из прикладной программы и с помощью средств конфигурирования без модификации кода прикладной программы. Возможна комбинация обоих способов.
Конфигуратор позволяет:
- включить в приложение средства протоколирования, назначить размер кольцевого буфера для потока трассировки, задать политику вывода записей в поток трассировки, задать политику вывода записей в файл протокола, запросить сохранение в файле содержимое буфера протокола от предыдущей сессии;
- задать маску (фильтр) событий, подлежащих протоколированию;
- указать потоки управления, в контексте которых следует или не следует производить протоколирование, указать объекты ОС, действия над которыми нужно протоколировать, назначить протоколирование переменных и объектов ОС.
Наряду с возможностями, предоставляемыми средствами конфигурирования, функциями управления трассировкой можно воспользоваться непосредственно (например, для изменения текущего состояния фильтра). В oc2000 эти функции базируются на стандарте POSIX:
- протоколирование событий прикладной программы: posix_trace_event.
- запуск и останов протоколирования: posix_ trace_start, posix_trace_stop.
- опрос и изменение текущего состояния фильтра событий: posix_trace_get_filter, posix_trace_ eventset_fill, posix_trace_eventset_del, posix_trace_set_ filter.
Наряду с функциями стандарта POSIX в oc2000 имеются функции, с помощью которых можно как запросить протоколирование переменной, так и отменить такой запрос. При запросе протоколирования указывается адрес, тип, размер и имя переменной, а также маска событий, аналогичная фильтру событий, что позволяет дополнительно сузить круг событий, при возникновении которых значение переменной следует протоколировать.
Пользователь также может использовать собственные функции протоколирования, вызываемые при наступлении указанных им событий. Они могут применяться, в частности, для проверки корректности каких-либо данных или для протоколирования значений переменных, которые не имеют фиксированного адреса.
Снижение влияния протоколирования на временные характеристики системы обеспечивается тем, что информация из структур, описывающих текущее состояние объектов ОС, переносится в буфер протокола без каких-либо преобразований.
Перенос данных из буфера в файл выполняет специальный поток управления, имеющий наимень-
Рис. 1. Представление протокола событий
ший приоритет. Системы жесткого РВ обычно имеют некий запас времени, в течение которого процессор простаивает. В такие периоды и осуществляется перенос данных из буфера протокола в файл.
Чередование вызовов функций запуска и останова протоколирования позволяет исключить промежутки времени, в течение которых ничего существенного с точки зрения задач анализа не происходит. Изменение текущего состояния фильтров протоколирования событий и переменных позволяет регистрировать в протоколе только необходимую информацию.
Просмотр и анализ протокола событий
Анализ протоколов событий, полученных с помощью системы протоколирования ос2000, выполняется с помощью Трассировщика - интерактивной программы, исполняемой на инструментальной ЭВМ. Средствами Трассировщика обеспечивается:
- просмотр протокола событий, отображаемого в виде таблицы;
- поиск и фильтрация записей протокола событий, удовлетворяющих заданным условиям;
- статистическая обработка данных, зафиксированных в протоколе, результаты которой отражают распределение событий по группам, контекстам и по участвующим в событии объектам ОС.
По требованию пользователя, в процессе анализа протокола событий могут быть сформированы трассы состояний объектов ОС, обеспечивающие:
- представление трасс состояний в виде таблиц и графиков (временных диаграмм);
- поиск и фильтрация записей трасс состояний, удовлетворяющих заданным условиям;
- статистическая обработка состояний, в ходе которой по всем реализациям для каждого состояния рассчитываются минимальное, максимальное и общее время пребывания в нем объекта;
- представление гистограмм, характеризующих распределение реализаций заданного состояния по значениям его длительности, в виде графиков.
Реализация пользовательского интерфейса. Протокол событий и трассы состояний отображаются на соответствующих страницах блокнота трасс, занимающего основную часть пространства главного окна Трассировщика (рис. 1). Содержимое протокола событий отображается на первой странице блокнота. Новые страницы добавляются в процессе работы, например, при формировании трасс состояний.
Слева от блокнота трасс расположено окно «Статистика событий» - один из основных органов
управления работой Трассировщика.
Записи протокола событий содержат как однородную информацию (время, тип события, контекст), присутствующую во всех записях, так и данные, характерные только для событий определенного типа. Однородная информация представлена таблицей протокола событий, расположенной в верхней части страницы блокнота. В нижней части расположены два окна, содержимое которых дополняет и уточняет информацию о текущем событии (отображаемом в текущей строке основной таблицы) - «Дополнительные данные» и «Переменные».
В таблице «Переменные» представлены значения переменных, зарегистрированных вместе с текущим событием. Каждой переменной соответствует одна строка, в которой отображаются ее имя, тип, адрес, размер и собственно значение в формате, соответствующем типу.
Фильтрация и поиск событий, удовлетворяющих заданным условиям. В основе представления информации о событии лежат три его характеристики: тип события; контекст, в котором оно произошло; объект, участвующий в событии. Такие тройки назовем расширенным типом события. Одним из результатов обработки протокола являются статистические данные о событиях - распределение реализаций событий по их расширенным типам. Всего может быть шесть вариантов такого распределения, каждый из которых отражает одну из шести классификаций расширенных типов - по числу перестановок элементов множества {«События», «Объекты», «Контексты»}. Определенному варианту соответствует свое дерево. В каждый момент времени используется только одна иерархия, но пользователь всегда может сменить ее на любую другую.
Дерево событий используется для задания условий фильтрации и поиска записей протокола. Любая из его вершин может быть помечена знаком «+» или «-». Знак «+» означает, что записи протокола событий, соответствующие поддереву помеченной вершины, следует включить в результат отбора, а знак «-» - исключить из него.
Условия отбора могут быть заданы одновременно для разных иерархий расширенных типов собы-
тий, их сводят в таблицу «Общие условия отбора»: каждой ее строке соответствует одна из помеченных пользователем вершин дерева событий.
Если дерево событий предназначено для формирования перечня условий отбора, то таблица «Общие условия отбора» может быть использована для их временной коррекции - с целью расширения или, наоборот, сужения множества событий.
Заданные пользователем условия отбора можно использовать в зависимости от режима просмотра -обычного или с фильтром. В обычном режиме в окне просмотра трассы отображаются все записи протокола. При этом обеспечивается быстрый переход от одной записи, удовлетворяющей условиям отбора, к другой (следующей или предыдущей). В режиме с фильтром отображаются лишь те записи, которые удовлетворяют условиям отбора. При переключении с одного из этих режимов на другой положение текущей записи трассы сохраняется.
Трассы состояний. Для анализа временных характеристик СРВ, выявления критических участков ее работы, оценки ресурсов, доступных приложению в наиболее ответственные моменты его функционирования, наряду с информацией о происходящих в системе событиях удобно оперировать данными, характеризующими состояние системы:
- состояние процессора (простой, обработка прерываний, выполнение потока управления);
- состояние потоков управления (выполняется, готов к выполнению, не готов);
- состояние семафоров, мьютексов, условных переменных, очередей сообщений;
- состояние пулов памяти (характеризуются количеством блоков, выделенным из пула и их общим объемом);
- состояние переменных.
Состояния объекта могут быть объединены в группы по некоторому общему признаку. Этим группам соответствуют «укрупненные» состояния объекта. Например, состояние процессора «работа» является обобщением любых состояний, в которых выполнялся либо поток управления, либо обработчик прерывания.
Формирование трассы состояний объекта ОС производится по требованию пользователя параллельно текущей работе с протоколом событий (в фоновом режиме). Результат представляется в виде таблицы (рис. 2), а при необходимости - и в виде графика:
На графике временная диаграмма представляется в
виде последовательности прямоугольников. Различным состояниям объекта соответствуют прямоугольники разной высоты. В частности, на диаграмме процессора прямоугольники, соответствующие прерываниям, имеют максимальную высоту, тогда как высоты прямоугольников, соответствующих потокам, пропорциональны их приоритетам. Ширина прямоугольников пропорциональна периодам пребывания объекта в соответствующих состояниях. При просмотре графиков имеется возможность менять масштаб (сужать и расширять поле обзора графика).
Различные уровни детализации состояний объекта порождают иерархию, которая может быть использована для задания условий отбора. Например, для процессора могут быть отобраны все состояния, соответствующие обработке любых прерываний. В качестве условия отбора может быть использован диапазон искомых значений длительности состояния.
В процессе формирования трассы состояния рассчитываются максимальные и общие длительности для всех состояний объекта ОС. Результаты такой обработки по всем объектам, для которых строилась трасса состояний, отображаются в дереве статистики состояний (дереве состояний) на странице «Статистика состояний» блокнота трасс. Более подробно распределение реализаций некоторого состояния по его длительностям представляется в виде гистограммы (рис. 2).
На записи трассы состояний какого-либо объекта ОС могут быть наложены условия отбора - как на типы состояний (для любого уровня детализации), так и на их длительности. Чтобы отобрать одно или несколько состояний объекта достаточно пометить знаком «+» или «-» одну или несколько вершин дерева состояний. При задании диапазона длительностей состояния используется его гистограмма.
Записи трассы состояний можно отфильтровать либо в режиме поиска перемещаться от одной записи, удовлетворяющей условиям отбора, к другой.
Рис. 2. Трасса состояний процессора и гистограмма состояний -1-
Выявление утечек памяти. Записи трассы состояния пула содержат данные об участках памяти, которые были получены программой, но не освобождены к данному моменту. Эти данные меняются всякий раз, когда в основном протоколе фиксируются успешные попытки получения либо освобождения памяти. В трассу состояния включаются также записи, соответствующие случаям, когда вызов функций освобождения памяти приводил к ошибке. Наконец, фиксируются все случаи получения памяти, которая в дальнейшем не была освобождена (в каждом таком случае в поле дополнительной информации указывается поток, запросивший память, и ее размер).
Трассе состояния пула памяти соответствует ветвь в дереве статистики, содержащая информацию об общем количестве памяти (в байтах и блоках), которая не была освобождена. Эта ветвь отражает распределение памяти по потокам управления и по размерам запрашиваемых блоков. И поток, и размер выделенного при выполнении этого потока буфера могут использоваться при задании фильтра трассы состояний.
Если в момент регистрации событий выделения памяти производилось протоколирование содержимого программного стека, то каждый такой случай будет характеризоваться соответствующей цепочкой вызовов функций.
Анализ использования процессорного времени. В ходе формирования трассы состояний процессора вычисляются (и отображаются в дереве состояний) следующие характеристики:
- общее время простоя процессора;
- общее время, затраченное на обработку прерываний; на выполнение потоков управления; на выполнение каждой функции обработки прерываний; на выполнение каждого потока управления;
- максимальное время простоя процессора;
- максимальное время, затраченное на обработку прерываний; на выполнение потоков управления; на выполнение каждой функции обработки прерываний; на выполнение каждого потока управления.
Перечисленные характеристики позволяют судить о том, в какой степени СРВ справляется с возложенными на нее задачами.
Использование гистограмм, построенных для состояний, соответствующих выполнению наиболее критичных потоков управления и обработчиков прерывания, позволяет выявить наличие узких мест реализации, а использование фильтров, задаваемых с помощью гистограмм, - уточнить, в какие моменты времени отмечены отклонения временных характеристик системы от проектных значений. Анализ событий (записей основной трассы) в окрестностях этих моментов и состояния объектов ОС позволяют установить причины такого поведения системы.
Временные характеристики средств протоколирования oc2000
Как показывают результаты измерений, выполненных на целевой ЭВМ с микропроцессором RM7000 с тактовой частотой 400 МГц, затраты времени на протоколирование события прикладной программы не превышают 1.5 мкс. Затраты, связанные с протоколированием системных событий, зависят от их типа. Например, затраты на протоколирование захвата или освобождения семафора (без переключения контекста) составляют около 1 мкс.
Время, необходимое для построения индекса и формирования дерева статистики событий, для протокола объемом 1128 Мб не превышает 1 минуты (приводятся временные характеристики Трассировщика при его работе с протоколом событий на ЭВМ Intel Pentium 4 HT 3.00GHz RAM DDR 1 GB в среде ОС Linux Fedora Core3, ядро 2.6.9-1.667smp.).
Время, необходимое для отбора в трассе объемом свыше 1Гб записей, удовлетворяющих заданным условиям, практически не зависит от сложности запроса и немногим превышает 1 секунду.
Скорость прокрутки таблицы, в которой отображается протокол событий, не зависит от объема протокола и не уступает аналогичным характеристикам существующих текстовых редакторов.
АНАЛИЗ КРИТИЧЕСКИХ ТОЧЕК ОТКАЗОУСТОЙЧИВОСТИ ВЫЧИСЛИТЕЛЬНОЙ СРЕДЫ ПЛАНЕТАРНОГО ТИПА
(Работа выполнена при поддержке РФФИ, проект № 04-01-00363) А.В. Коганов, к.ф.-м.н., А.Н. Сазонов (Москва)
В современном обществе быстро возрастает значение распределенных систем информационного и вычислительного назначения. С увеличением сложности и объема этих систем растет влияние аварийных факторов на их функционирование. В правильно разработанной системе выход из строя относительно малого числа функциональных элементов не приводит к остановке системы, а только увеличивает нагрузку на оставшиеся элементы. Это позволяет осуществить частичный или полный ремонт отказавших узлов, продлив время безотказной работы системы в
целом. Возникает задача обеспечения достаточно малой вероятности выхода системы из строя за предполагаемый срок эксплуатации. Поскольку выход узлов системы их строя обычно обусловлен неконтролируемыми факторами, для решения указанной задачи надо подбирать подходящую интенсивность ремонтных работ и систему переназначения задач на исправных элементах. Решение этой задачи для реальных систем требует построения соответствующих математических моделей и машинного эксперимента. Разработке соответствующего программного
