автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Организация контролируемого выполнения для разнородных распределенных программно-аппаратных комплексов

Московский Государственный Университет им. М.В Ломоносова Научно-исследовательский вычислительный центр

ОРГАНИЗАЦИЯ КОНТРОЛИРУЕМОГО ВЫПОЛНЕНИЯ ДЛЯ РАЗНОРОДНЫХ РАСПРЕДЕЛЕННЫХ ПРОГРАММНО-АППАРАТНЫХ

КОМПЛЕКСОВ

Специальность 05.13.11 - математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

Костюхин Константин Александрович

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата физико-математических наук

Москва -2006

Работа выполнена в научно-исследовательском институте системных исследований Российской Академии Наук

Научные руководители:

Официальные оппоненты:

академик РАН, профессор Бетелин Владимир Борисович,

доктор физико-математических наук Галатенко Владимир Антонович.

доктор технических наук, профессор Кузнецов Сергей Дмитриевич,

Ведущая организация:

кандидат технических наук Волконский Владимир Юрьевич.

Институт прикладной математики им. М.В.Келдыша РАН

Защита состоится « 2. » 2006 г. в часов на заседании

диссертационного совета K501.001.ll при МГУ им. М.В. Ломоносова по адресу 119992, Москва, Ленинские горы, НИВЦ МГУ, конференц-зал.

С диссертацией можно ознакомиться в библиотеке НИВЦ МГУ

Автореферат разослан «2/?» ди^-ЯХ^ 2006 г.

Ученый секретарь диссертационного совета, к.ф.-м.н.

В.В. Суворов

Ц 006/1-1ьчь

Общая характеристика работы

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

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

■ разнородность, наличие узлов, работающих в реальном масштабе времени;

■ часто меняющуюся конфигурацию;

■ внешнюю изолированность и удаленность от разработчика в режиме функционирования.

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

■ ошибочная ситуация сложно воспроизводится;

■ традиционные отладочные средства могут вносить дополнительные

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

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

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

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

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

■ разработать средства, позволяющие контролировать поведение

комплекса не только на стадии разработки, но и в процессе эксплуатации;

ошибки;

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

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

■ интефация средств информационной безопасности, отладки и управления;

■ распространение контролируемого выполнения на все этапы жизненного цикла программно-аппаратных комплексов;

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

Практическая ценность. Реализован инструментальный комплекс «СОМ» (Система Отладки/Мониторинга) для отечественных ЭВМ серии Багет на базе микропроцессоров с архитектурой х86 и 1В578, а также для Программируемого Процессора Сигналов - многопроцессорной ЭВМ на базе цифрового процессора обработки сигналов 1В577. Инструментальный комплекс применяется при отладке и сопровождении программ, созданных для отечественной операционной системы реального времени ос2000, работающей на перечисленных выше аппаратных платформах.

Апробация. Основные положения диссертационной работы докладывались на международной конференции «Параллельные вычисления и задачи управления», Москва, ИПУ РАН 2001, на семинаре «Современные сетевые технологии», МГУ, 2002, на научно-исследовательских семинарах в институте системного программирования РАН и НИИ системных исследований РАН.

Публикации. По теме диссертации опубликовано 10 печатных работ, из них 7 в соавторстве.

Объем и структура работы. Диссертация состоит из введения, шести глав, заключения и двух приложений. Список использованной литературы содержит 159 наименований. Текст диссертации содержит 159 страниц машинописного текста, включая 21 рисунок и 1 таблицу.

Содержание работы

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

Первая глава представляет собой анализ существующих средств и методов отладки распределенных разнородных программно-аппаратных комплексов. Отдельно рассмотрены средства воспроизведения выполнения (BugNet, RECAP, Distributed DejaVU и др.), средства интерактивной отладки (TotalView, Cdbx, VxGdb и др.), средства мониторинга (Vampir NG, WindView, Alamo и др.) и средства самоконтроля (Nana, средства АОП).

Эти средства имеют ряд общих свойств, а именно:

■ Они применяются на этапе разработки.

■ Ориентированы на локализацию уже произошедших ошибок определенного типа в системах с устоявшейся программно-аппаратной архитектурой.

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

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

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

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

ОПРЕДЕЛЕНИЕ. Контролируемое выполнение - это процесс функционирования программно-аппаратного комплекса, при котором комплекс имеет возможность выполнить свою миссию, несмотря на возможное проявление ошибок, атаки и отказы.

Частными случаями контролируемого выполнения являются:

■ применение средств управления информационными системами;

■ интерактивная отладка;

■ мониторинг;

■ самоконтроль;

■ воспроизведение предыдущих сеансов работы комплексов.

Средства управления информационными системами ориентированы на такие крупные сущности, как сети, узлы сетей, хосты, устройства, приложения. Эти средства применяются на этапе эксплуатации систем.

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

■ аппаратные и программные ошибки;

■ сбои и отказы аппаратуры;

■ ошибки пользователей и обслуживающего персонала;

■ нарушение эксплуатационных требований и регламентов;

■ злоумышленные действия

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

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

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

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

Применение средств самоконтроля программ можно рассматривать как распространение объектно-ориентированного подхода на контролируемое

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

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

На основе предложенной концепции сформулированы требования, предъявляемые к средствам контролируемого выполнения.

■ Требования к функциональности

Следование стандартам. Должны поддерживаться все возможности отладки и мониторинга, предусмотренные стандартами НРОБ и РОБШ.

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

■ Технологические требования

Расширяемость. Архитектура комплекса контролируемого выполнения должна допускать естественные способы наращивания функциональности.

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

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

■ Требования к интерфейсу

Развитый, настраиваемый графический интерфейс.

Полноценный командный язык задания сценариев отладки.

В третьей главе описывается архитектура и особенности реализации инструментального комплекса «СОМ» (Система Отладки/Мониторинга), разработанного в соответствии с концепцией контролируемого выполнения.

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

управления. Данная реализация выполнена в объектной среде Bonobo на основе архитектуры CORBA (Common Object Request Broker Architecture).

Рассмотрим основные компоненты комплекса, которые изображены на рис. 1.

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

Инструментальная ЭВМ

Управляющая оболочка

компонент интерактивной отладки

Компонент мониторинга

Компонент контроля выполнения на основе высокоуровневого описания

База данных отладочной информации о программе

Внешний компонент

Управляющие компоненты сред выполнения

Среда Среда Среда

выполнения 1 выполнения 2 выполнения 3

\

3

Целевые ЭВМЛ

Агенты управления

I Средства самоконтроля

Средства

воспроизведения

выполнения

Рис. 1 Компоненты инструментального комплекса

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

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

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

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

Компонент отображения информации о среде выполнения - отображает свойства и текущее состояние среды выполнения (целевой ЭВМ) в целом, множество потоков управления в ней и их состояние.

Компонент интерактивной отладки реализует команды традиционной интерактивной отладки.

Компонент мониторинга отображает происходящие в целевом комплексе события, управляет режимом мониторинга.

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

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

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

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

Накладные расходы на трассировку и использование средств самоконтроля в системе ос2000 составляют 4%.

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

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

Компонент управления модулями реализует за]рузку выполняемых модулей с инструментальной ЭВМ на целевые, отображает множество модулей, загруженных в данный момент на целевые ЭВМ.

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

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

Множество состояний Б таких автоматов состоит из некоторых логических состояний целевого комплекса; входным алфавитом X является множество событий целевого комплекса; выходным алфавитом У - множество управляющих действий (в настоящее время в качестве таких действий поддерживаются останов системы, выдача сообщения пользователю, продолжение потока, остановленного на точке слежения). В качестве начального состояния всегда используется точка активизации шаблона. Шаблон может быть активизирован вручную или автоматически при возникновении некоторой последовательности событий (сигнатуры).

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

Применение шаблонов поведения проще всего проиллюстрировать на примере (рис. 2).

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

Поток данных

№1

Ф

Ф

141

Основной узел

Ы2

Резервный узел

Рис. 2 Пример целевого комплекса

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

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

Представленная структура инструментального комплекса обладает свойством динамической настраиваемое™ на архитектуру целевого комплекса и на спектр используемых средств контролируемого выполнения. Объектно-компонентная среда выполняет функции регистрации создаваемых объектов и предоставления информации о них. Важной чертой архитектуры комплекса является также разграничение универсальных и платформно-специфичных компонентов.

Компонентная организация комплекса сама по себе обеспечивает повышение надежности комплекса - при отказе отдельных компонентов оставшиеся могут продолжать функционирование. Архитектура С011ВА поддерживает механизмы отслеживания нештатных ситуаций и состояния компонентов.

Тмдаа Tool* Object Hrip

* ® • о /

t> Contents »wtf It]

t Thread« state

^ Signal« ¿Efirr

& Manor) alloc

f> Functions ret

t> Tlirrart* rn-uv t> ids u mm

f ScTOJ^Jhore» i v M«»exe» man Mutest dele Miaex UiMa prim Miucx prtoi Miitrx lock Attempt

Miitrx ink1

t- Condition var

> Meitze que v. t> Timor» tracm, t> System Inpvtt C- S) stoii funco'

> OS innwkte ?

> User dcfnfd t PPS on M2 ß0c2000 nn t42 t> U,1

—. Flow control

в

Flow control I

Рис. 3 Шаблоны поведения целевого комплекса

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

Технология СОЮЗА поддерживает разделение функций компонентов несколькими пользователями. Поэтому с управляющими компонентами сред выполнения могут работать одновременно несколько пользователей. Механизм событий также позволяет получать уведомления о событиях на целевой стороне одновременно нескольким пользователям.

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

В четвертой главе описываются средства контроля программ, реализованные в инструментальном комплексе «СОМ» и включающие механизмы внешнего и внутреннего контроля.

Внешний контроль реализован путем интеграции инструментального комплекса с системой управления OpenNMS и предназначен для контроля целостности на уровне совокупное! и компонентов распределенного приложения. Внутренний контроль представляет собой инструмент самоконтроля программ, реализованный в виде библиотеки специальных функций и макросов. В настоящее время эта библиотека реализована для 1 целевых платформ под управлением ОС Linux и ос2000. Встраивая в код

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

Оба средства контроля оказывают минимальное воздействие на работу приложения и могут использоваться как автономно, так и в сочетании с другими средствами инструментального комплекса «СОМ». Поддерживается возможность автоматического вызова средств контролируемого выполнения при обнаружении сбоя в работе программы.

В настоящее время средствами самоконтроля реализован контроль следующих аспектов поведения программ:

■ изменение хода выполнения программы в результате некорректных значений внутренних переменных программы и входных параметров вызываемых функций;

■ выполнение некоторых участков кода за определенное время;

• использование динамически выделяемой памяти.

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

Ниже приведен пример применения средств самоконтроля.

UEL_SENSOR_CHECK_MEMORYjNTEGRITY (START); С strl = (char *) UEL_malloc (25);

UEL_LOG_MEMORY ();

UEL_SENSOR_GUARD (START, 1000); 1 do calcs (); /* Некоторые вычисления должны закончиться в течение 1 секунды */

UEL_SENSOR_GUARD (STOP);

UEL_ACTUATOR (UEL_GOOD ==

UEL_SENSOR_CHECK_MEMORY_ACCESS (CODE, (void *) 0x100000), handl, "CODE access to 0x100000", 1, DONT_CALCULATE);

UEL_free (stri); Г Повторный вызов free. */

Г В результате выполнения повторного вызова free в протокол будет помещено следующее сообщение:

'FREE' CALL ASSERT (MAY BE A BUG): [UELexample.c:94] 7

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

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

Пятая глава посвящена разработанному в рамках комплекса «СОМ» средству детерминированного воспроизведения распределенных программ, в архитектурах без общей памяти. В существующей реализации предполагается, что процессы взаимодействуют путем обмена сообщениями (рис. 4).

Процессы обмениваются сообщениями *

Рис. 4 Система воспроизведения выполнения

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

недетерминированным. Наконец, следует учитывать возможность утраты сообщений.

Отметим, что помимо указанных, другие источники недетерминированности в приложении отсутствуют.

В контексте системы воспроизведения различают первичное выполнение ' приложения и его воспроизведение. При первичном выполнении записывается

последовательность событий, произошедших в каждом из процессов; при воспроизведении записанного ранее первичного выполнения производится повторение тех же последовательностей событий в каждом процессе. \ Был выбран метод воспроизведения по синхронизации событий с

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

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

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

■ TYPE(e) - тип события е, который может принимать одно из 2 значений: SEND (отправка сообщения), RECEIVE (прием сообщения).

■ RESULT(e) - значение, характеризующее успешность завершения операции отправки или приема сообщения в событии е. Это значение, которое вернула бы стандартная функция отправки или получения сообщения, используемая в исходном приложении (до его инструментовки). Введем также функцию successful:RESULT(e)->{TRUE|FALSE}, при помощи которой по значению RESULT(e) можно определить, успешно ли завершилась операция в событии е.

■ ERR(e) - код ошибки в случае неуспешного завершения операции в событии е.

■ Т(е) - логическое векторное время (временная метка) события е.

* В главе дается детальное описание алгоритма воспроизведения. Идея

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

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

В шестой главе производится анализ инструментального комплекса в соответствии с таксономией средств мониторинга. Затем рассматриваются примеры применения инструментального комплекса «СОМ» при сопровождении распределенных приложений, выполняющихся под управлением Программируемого Процессора Сигналов и системы реального I

времени ос2000. Приведенные примеры носят методологический характер и основаны на реальных проблемах, с которыми сталкиваются разработчики и пользователи программно-аппаратных комплексов, использующихся в НИИСИ РАН.

Кроме того, в этой главе формулируется методология применения разработанных средств контролируемого выполнения:

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

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

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

В заключении приводятся результаты работы.

В приложении А приведены фрагменты файлов настройки инструментального комплекса «СОМ».

Приложение Б содержит описание структуры инструментального комплекса «СОМ» на языке ЦМЬ.

Основные результаты

В диссертационной работе получены следующие результаты:

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

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

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

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

Личный вклад. Все результаты исследований, составляющие основное содержание диссертации, получены лично автором. Ему принадлежат основные идеи, лежащие в основе концепции контролируемого выполнения для разнородных распределенных программно-аппаратных комплексов. Им реализованы основные компоненты инструментального комплекса «СОМ», а также средства самоконтроля и средства воспроизведения выполнения, и произведена интеграция с системой управления ОрепИМБ.

По теме диссертации опубликованы следующие работы:

1. Костюхин К.А. Отладка систем реального времени. Обзор. - Вопросы кибернетики / под ред. В.Б. Бетелина. - М.: НИИСИ РАН, 1999 - с. 46-75.

2. Галатснко В.А., Костюхин К.А. Отладка и мониторинг распределенных разнородных систем. - Вопросы кибернетики / под ред. В.Б. Бетелина. - М.: НИИСИ РАН, 2001 - с. 27-48.

3. Галатенко В.А., Костюхин К.А. Отладка и мониторинг распределенных разнородных систем. - Труды международной конференции «Параллельные вычисления и задачи управления». - М.: ИПУ РАН, 2001 - с. 90-106.

4. Галатенко В.А., Костюхин К.А. Отладка и мониторинг распределенных разнородных систем. - «Программирование», 2002, № 1 - с. 27-37.

5. Костюхин К.А. Обзор средств и методов отладки распределенных систем. -М.: НИИСИ РАН, 2004 - с. 76-119.

6. Костюхин К.А. Средства самоконтроля программ и их применение при отладке систем со сложной архитектурой. - М.: НИИСИ РАН, 2004 - с. 151160.

7. Вьюкова Н.И., Галатенко В.А., Костюхин К.А., Шмырев Н.В. Организация отладочного комплекса для целевых систем со сложной архитектурой. - М.: НИИСИ РАН, 2004 - с. 120-150.

8. Вьюкова Н.И., Галатенко В.А., Костюхин К.А., Самборский C.B. Средства отладки систем со сложной архитектурой (обзор). - М.: НИИСИ РАН, 2005 -с. 5-43.

9. Вьюкова Н.И., Галатенко В.А., Костюхин КА. Средства внешнего и I внутреннего контроля программ. - М.: НИИСИ РАН, 2005 - с. 44-57.

Ю.Вьюкова Н.И., Галатенко В.А., Костюхин К.А., Шмырев Н.В. Детерминированное повторное выполнение распределенных программ. - М.: НИИСИ РАН, 2005 - с. 58-71.

Отпечатано в копицентре «СТ ПРИНТ» Москва, Ленинские горы, МГУ, 1 Гуманитарный корпус www stprint ni e-mail zakaz@stprint ш тел ■ 939-33-38 Тираж 100 экз Подписано в печать 21 04 2006 г

féVb

p- 86 И

Введение

1 Обзор средств и методов отладки распределенных систем

1.1 Постановка задачи и основные понятия.

1.2 Средства и методы отладки

1.2.1 Детерминированное воспроизведение и интерактивная отладка распределенных программ.

1.2.2 Мониторинг

1.2.3 Средства самоконтроля программ.

1.2.4 Средства и методы, ориентированные на отладку сложных систем.

1.2.5 Отладка в жизненном цикле программы. Интегрированное использование средств отладки, тестирования, контроля выполнения.

1.3 Вопросы архитектуры и реализации средств отладки.

1.3.1 Архитектура средств отладки.

1.3.2 Функциональность агентов и псевдо-агентов отладки

1.3.3 Взаимодействие менеджера и агента.

1.3.4 Аппаратная поддержка отладки.

1.3.5 Стратегии передачи данных трассировки.

1.3.6 Настраиваемость и масштабируемость.

1.4 Выводы.3G

2 Контролируемое выполнение, ассоциированные понятия и требования

2.1 Контролируемое выполнение и ассоциированные понятия

2.2 Роль контролируемого выполнения и его составляющих

2.3 Требования к средствам контролируемого выполнения и их реализации

2.4 Интеграция средств отладки и управления.

2.5 Выводы.

3 Организация инструментального комплекса "СОМ"

3.1 Пример применения комплекса

3.2 Организация инструментального комплекса.

3.2.1 Архитектура.

3.2.2 Взаимодействие со средами выполнения.

3.3 Функциональные возможности комплекса и вопросы реализации

3.3.1 Инициализация системы.

3.3.2 Интерактивная отладка.

3.3.3 События

3.3.4 Контроль целостности и отказоустойчивость комплекса. Многопользовательская работа.

3.4 Выводы.

4 Средства внешнего и внутреннего контроля программ

4.1 Библиотека средств самоконтроля.

4.2 Связь инструментального комплекса "СОМ" с системой управления OpenNMS.

4.3 Выводы.

5 Средства детерминированного воспроизведения распределенных программ

5.1 Постановка задачи.

5.2 Реализация системы воспроизведения.

5.2.1 Архитектурные и технические решения.

5.2.2 События и векторное время в распределенном приложении

5.2.3 Первичное выполнение и воспроизведение распределен

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

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

• разнородность, наличие узлов, работающих в реальном масштабе времени;

• часто меняющуюся конфигурацию;

• внешнюю изолированность и удаленность от разработчика в режиме функционирования.

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

• ошибочная ситуация сложно воспроизводится;

• традиционные отладочные средства могут вносить дополнительные ошибки;

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

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

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

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

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

• разработать средства, позволяющие контролировать поведение комплекса не только на стадии разработки, но и в процессе эксплуатации;

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

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

• интеграция средств информационной безопасности, отладки и управления;

• распространение контролируемого выполнения на все этапы жизненного цикла программно-аппаратных комплексов;

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

Практическая ценность. Реализован инструментальный комплекс "СОМ" (Система Отладки/Мониторинга) для отечественных ЭВМ серии Багет на базе микропроцессоров с архитектурой х86 и 1В578, а также для Программируемого Процессора Сигналов - многопроцессорной ЭВМ на базе цифрового процессора обработки сигналов 1В577. Инструментальный комплекс применяется при отладке и сопровождении программ, созданных для отечественной операционной системы реального времени ос2000, работающей на перечисленных выше аппаратных платформах.

Апробация. Основные положения диссертационной работы докладывались на международной конференции "Параллельные вычисления и задачи управления", Москва, ИПУ РАН 2001, на семинаре "Современные сетевые технологии", МГУ, 2002, на научно-исследовательских семинарах в институте системного программирования РАН и НИИ системных исследований РАН.

Публикации. По теме диссертации опубликовано 10 печатных работ: [16], [8], [17], [18], [6], [9], [10], [5], [4], [7], из них 7 в соавторстве.

Объем и структура работы. Диссертация состоит из введения, 6 глав, заключения, списка литературы и 2 приложений.

4.3 Выводы

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

Библиотека средств самоконтроля использует механизм трассировки, описанный в стандарте POSIX ( [82]), благодаря чему может быть использована при отладке многих posix-совместимых приложений. Оказывая в целом незначительное влияние (см. таблицу 4.1) на работу системы, БСС является эффективным инструментом при отладке приложений реального времени, а

Заключение

В диссертационной работе получены следующие основные результаты:

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

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

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

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

1. Бетелин В. Б., Галатенко В. А. ЭСКОРТ - инструментальная среда программирования // Юбилейный сборник трудов институтов Отделения информатики РАН. — 1993.— Т. 1..

2. Брюхов Д., Задорожный В. и др. Интероперабельные информационные системы: архитектуры и технологии // Системы Управления Базами Данных. — 1995.— № 4.

3. Быков О. Диагностические средства MFC // RSDN.— 2001. —Апрель. — http://www.rsdn.ru/archive/vc/issues/pvc039.htm.

4. Въюкова Н. И., Галатенко В. А., Костюхин К. А. Средства внешнего и внутреннего контроля программ // Информационная безопасность. Микропроцессоры. Отладка сложных систем / Под ред. Бетелина. — М.: НИИСИ РАН, 2005.

5. Въюкова Н. И., Галатенко В. А., Костюхин К. А., Самборский С. В. Средства отладки систем со сложной архитектурой (обзор) // Информационная безопасность. Микропроцессоры. Отладка сложных систем / Под ред. Бетелина. — М.: НИИСИ РАН, 2005.

6. Въюкова Н. И., Галатенко В. А., Костюхин К. А., Шмырев Н. В. Детерминированное повторное выполнение распределенных программ //

7. Информационная безопасность. Микропроцессоры. Отладка сложных систем / Под ред. Бетелина. — М.: НИИСИ РАН, 2005.

8. Галатенко В. А., Костюхии К. А. Отладка и мониторинг распределенных разнородных систем // Информационная безопасность. Инструментальные средства программирования. Базы данных / Под ред. Бетелина,- М.: НИИСИ РАН, 2001.

9. Галатенко В., Костюхин К. Отладка и мониторинг распределенных разнородных систем // Труды международной конференции "Параллельные вычисления и задачи управления". — Москва, ИПУ РАН: 2001.

10. Галатенко В., Костюхин К. Отладка и мониторинг распределенных разнородных систем // Программирование. — 2002. — по. 1.

11. Годунов А. Н. и др. Введение в ос2000 // Вопросы кибернетики / Под ред. Бетелина.-М.: НИИСИ РАН, 1999.

12. Ерохин А., Корпев Н. TMN: надежда и реальность альтернативных подходов // Вестник связи. — 2001. — № 4.

13. Жуклинец И. А., Хотимский Д. А. Логическое время в распределенных программных системах // Программирование. — 2000. — № 6.

14. Калдин А. Отладчики микроконтроллеров и их применение в разработке микроконтроллерных приложений // Мир Компьютерной Автоматизации,— 2001.— № 5.

15. Калинов А. Я., Карганов К. А., Хоренко К. В. Подход к разработке отладчиков, использующих семантику конструкций параллельной программы // Программирование. — 2005. — Январь-Февраль.

16. Костюхин К. А. Отладка систем реального времени, обзор // Вопросы кибернетики / Под ред. Бетелина. — М.: НИИСИ РАН, 1999.

17. Костюхин К. А. Обзор средств и методов отладки распределенных систем // Информационная безопасность. Микропроцессоры. Отладка сложных систем / Под ред. Бетелина. — М.: НИИСИ РАН, 2004.

18. Костюхин К. А. Средства самоконтроля программ n их применение при отладке систем со сложной архитектурой // Информационная безопасность. Микропроцессоры. Отладка сложных систем / Под ред. Бе-телина. М.: НИИСИ РАН, 2004.

19. Липаев В. В. Функциональная безопасность программных средств. — М.: СИНТЕГ, 2004.

20. Пуха Ю. Объектные технологии построения распределенных информационных систем // Системы Управления Базами Данных. — 1997. — № 3.

21. Робачевский А. Операционная система UNIX. — С.-П.: БХВ-Петербург, 1997.

22. Роббинс Д. Отладка приложений. — Спб.: БХВ-Петербург, 2001.

23. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. — Спб.: Питер, 2003.

24. Тэллес М., Хсих Ю. Наука отладки. — М.: Кудиц-образ, 2003.

25. Эммерих В. Конструирование распределенных объектов.— М.: Мир, 2002.

26. Akgul Т., Kuacharoen P. et al. A debugger RTOS for embedded systems // School of Electrical and Computer Engineering, Georgia Institute of Technology. — 2002.

27. Akgul Т., Mooney V. Instruction-level reverse execution for debugging // ACM PASTE'02. 2002. - November 18-19.

28. Albertsson L. Simulation-based debugging of soft real-time applications // Proceedings of the seventh IEEE real-time technology and applications symposium (RTAS'01). IEEE, 2001.

29. Al-ladan M. A survey and a taxonomy of approaches for testing parallel and distributed programs // Proceedings of the ACS/IEEE International Conference on Computer Systems and Applications (AICCSA '01). — 2001.

30. A. Gadkari and S. Ramesh. Automated Synthesis of Assertion Monitors using Visual Specifications // Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05). — 2005.

31. A. Gates and S. Roach and 0. Mondragon and N. Delgado. DynaMICs: Comprehensive Support for Run-Time Monitoring // Proc. First Workshop Runtime Verification (RV '01). — 2001. —July.

32. A. J. Ко and B. A. Myers. — Designing the Whyline: A Debugging Interface for Asking Questions about Program Behavior, 2004.

33. A. Kniiupfer, Holger Brunst, Wolfgang E. Nagel. High Performance Event Trace Visualization // Proceedings of the 13th Euromicro Conference on Parallel, Distributed and Network-Based Processing (Euromicro-PDP'05). — 2005.

34. A. Phalgune. Testing and Debugging Web Applications: An End-User Perspective // Proceedings of the 2004 IEEE Symposium on Visual Languages and Human Centric Computing (VLHCC'04). — 2004.

35. A. Searle and J. Gough and D. Abramson. Automating Relative Debugging // Proceedings of 18th IEEE International Conference on Automated Software Engineering (ASE'3). 2003.

36. A. Tarafdar and V.K. Garg. Debugging in a Distributed World: Observation and Control // Proceedings IEEE Workshop on Application-Specific Software Engineering and Technology (ASSET'98). — Dallas, Texas: IEEE, 1998.-March.

37. A. Tarafdar and V. K. Garg. Predicate Control for Active Debugging of Distributed Programs // Proc. of the IEEE 9th Symposium on Parallel and Distributed Processing (SPDP). 1998.-April.

38. A. Tarafdar and V. K. Garg. Low-Overhead Interactive Debugging via Dynamic Instrumentation with DISE // Proceedings of the 11th Int'l Symposium on High-Performance Computer Architecture (HPCA-11 2005).-2005.-April.

39. Baulig M. — The Mono Debugger, 2002.— http://www.go-mono.com.

40. B.P. Miller and J. Choi. Breakpoints and Halting in Distributed Programs // Proceedings of the 8th International Conference on Distributed Computing Systems. — San Jose, CA: IEEE, 1988.— July.

41. Brown J., Zosel M., Williams A. ASCI Debugging Requirements // White paper. — 1998. — March.

42. B. Bruegge and T. Gottschalk and B. Luo. A Framework for Dynamic Program Analyzers // Proceedings of the 8th Ann. Conf. Object-Oriented Programming Systems, Languages, and Applications. — 1993. — Pp. 65-82.

43. B. Pekilis and R. Seviora. Detection of Response Time Failures of RealTime Software // Proceedings of the 8th International Symposium on Software Reliability Engineering (ISSRE'97. — IEEE, 1997.

44. Case J., Fedor M. et al. — Simple Network Management Protocol (SNMP). NWG, 1989. - April. - RFC 1098.

45. Case J., McCloghrie K. et al.— Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).— NWG, 1996.— January. RFC 1903.

46. Cheon Y. A Runtime Assertion Checker for the Java Modeling Language: Tech. Rep. 03-09: Dept. of Computer Science, Iowa State Univ., Ames, 2003.

47. Choi J.-D., Miller В., Netzer R. Techniques for debugging parallel programs with flowback analysis // ACM Transactions on Programming Languages and Systems. — 1991. — October. — Vol. 13, no. 4.— Pp. 491— 530.

48. Cifuentes C. et al. Computer Security Analysis through Decompilation and High-Level Debugging // Proceedings of the Eighth Working Conference On Reverse Engineering (WCRE'01). IEEE, 2002.

49. Convex Computer Corporation.— Convex CXdb User's Guide, Second Edition, 1993. —October.

50. Cray Research, Inc.— UNICOS Symbolic Debugger Reference Manual, 1991.-June.

51. C. Fidge. Fundamentals of Distributed System Observation // IEEE Transactions on Software Engineering. — 1996. — November. — no. 11.

52. C. Valot. Characterizing the accuracy of distributed timestamps // Proceedings of the sixth IFIP/ICCC conference on information network and data communication. — 1993. — May.

53. Digital Equipment Corporation. — Ladebug Debugger Manual, Version 4.0, 1996. —March.

54. Dolphin Interconnect Solutions, Inc. (now Etnus, Inc.).— TotalView Multiprocess Debugger User's Guide, Version 3.7.7, 1997. — September.

55. D.Z. Pan and M.A. Linton. Supporting reverse execution of parallel programs // Proceedings of the ACM SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging. — ACM SIGPLAN Notices, 1989. -January.

56. D. Bartetzko. Jass — Java with Assertions // Proc. First Workshop Runtime Verification (RV '01).- 2001.-July.

57. D. Drusinsky. Time-Rover. — Cupertino, Calif., personal comm., 2002.

58. D. Kranzlmueller and V. Volkert. NOPE: A Nondeterministic Program Evaluator 11 Proceedings ACPC99. — 1999. — February.

59. D. Luckham and W. Mann and S. Meldal and D. Helmbold. An Overview of Ann Specification Language for Ada // IEEE Software.— 1988.— Vol. 20. Pp. 9-23.

60. D. Rosenblum. A Practical Approach to Programming with Assertions // IEEE Transactions on Software Engineering.— 1995. —January. — Vol. 21, no. 1.-Pp. 19-31.

61. Francioni J., Albright L., Jackson J. Debugging parallel programs using sound // Journal of the ACM. — 1991.

62. Free Software Foundation, Inc.— Debugging with DDD Data Display Debugger, version 3.2, 2003.

63. F. Chen and G. Rosu. Towards Monitoring-Oriented Programming: A Paradigm Combining Specification and Implementation // Electronic Notes in Theoretical Computer Science. — 2003.— Vol. 89, no. 2.

64. Gal A. et al. — On Aspect-Orientation in Distributed Real-time Dependable Systems. — University of Magdeburg, 2001. —November.

65. Gramlich W. Debugging methodology // Journal of the ACM. — 1983.

66. Griswold V. Core Algorithms for autonomous Monitoring of Distributed Systems // ACM SIGPLAN Notices. 1991. - December. - no. 12.

67. G. Eisenhauer. Falcon.— Georgia Inst, of Technology, Atlanta, Ga., personal comm., 2002.

68. G. Liu H. L. S., Edgecombe К. E. A data identification scheme for automatic relative debugging // Proceedings of the 2004 International Conference on Parallel Processing Workshops (ICPPW'04). — 2004.

69. G. Matthews and R. Hood and S. Johnson and P. Leggett. Backtracking and Re-execution in the Automatic Debugging of Parallelized Programs // Proceedings of 11th IEEE International Symposium on High Performance Distributed Computing (HPDC'02). 2002.

70. Hanson D., Raghavachari M. A machine-independent debugger // Software Practice and Experience. — 1996. — Vol. 26(11).— Pp. 1277-1299.

71. Hansson H., Sjodin M. — An offline scheduler and system simulator for the Basement distributed real-time system, 1995.

72. Hewlett Packard Company.— HP/DDE Debugger User's Guide, First Edition, 1996. —July.

73. High Perfomance Debugging Forum. Review of HPDF standart. — http: / / www.ptools.org/hpdf/article.html.

74. Hood R. The P2D2 Project: Building a Portable Distributed Debugger // Proceedings of the SIG METRICS Symposium on Parallel and Distributed Tools. — Philadelphia: 1996. —May.

75. Ho A., Hand S., Harris T. Pdb: Pervasive debugging with xen // Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing (GRID'04). — 2004.

76. Hubart N. — Monitoring and Debugging a Hard Real-Time Distributed Computer for Aircraft Industry, 1996.

77. Huss S. A., Hastono P.— Internal communication methods and requirements in embedded systems, 2004.

78. H. Thane and H. Hansson. Towards Systematic Testing of Distributed Real-Time Systems // Proceedings of the 29th IEEE Real-Time Systems Symposium (RTSS'99), Phoenix, Arizona. — 1999. —December.

79. Я. Thane and H. Hansson. Using Deterministic Replay for Debugging Distributed Real-Time Systems // ieee. — 2000. — no. 0-7695-0734-4.

80. IBM Corporation.— IBM AIX Parallel Environment: Programming Primer, Release 2.0, 1994, —June.

81. Institute of Electrical and Electronic Engineers. The Open Group Base Specifications Issue 6. — IEEE Std 1003.1, 2001.

82. Intel Corporation.— Paragon Interactive Parallel Debugger Reference Manual, 1993. —October.84. i Tech Software GmbH. — Definition and application of the second generation logging systems, 2003.— May. — http://www.itech-software.de.

83. Jahanian F. Run-Time Monitoring of Real-Time Systems, Chapter 18.

84. Jeffery C. The alamo execution monitor architecture // Electronic Notes in Theoretical Computer Science. — 2000. — no. 4. — http://www.elsevier.nl/locate/entcs / volume30.html.

85. Jeffery C. et al. A lightweight architecture for program execution monitoring // ACM SIGPLAN.- 1993.- July.

86. J. Borkowski. Parallel Program Control Based on Hierarchically Detected Consistent Global States // Proceedings of the International Conference on Parallel Computing in Electrical Engineering (PARELEC'04). — IEEE, 2004.

87. J. Sharnowski and B. Chengt. A Visualization-based Environment for Top-down Debugging of Parallel Programs // Proceedings of the 9th International Parallel Processing Symposium (IPPS '95). — IEEE, 1995.

88. Kiczales G. et al. An overview of AspectJ // Proceedings of the European Conference on Object-Oriented Programming (ECOOP).— Springer-Verlag, 2001. June. - LNCS 2072.

89. Kiczales G., Lamping J. et al. Aspect-oriented programming // Proceedings of the European Conference on Object-Oriented Programming (ECOOP). Finland: Springer-Verlag, 1997. - June. - LNCS 1241.

90. Kim M., Viswanathan M. MaC: A Framework for Run-Time Correctness Assurance of Real-Time Systems: Tech. Rep. MS-CIS-98-37: Dept. of Computer and Information Sciences, Univ. of Pennsylvania, 1998.— December.

91. K.M. Chandy and . Lamport. Distributed Snapshots: Determining Global States of Distributed Systems // ACM Transactions on Computing Systems. — 1985. —February. — no. 3(1).

92. Knuth D. E. Literate programming. — CSLI, 1992.9G. Kolawa A. Techniques for preventing and detecting errors in embedded systems // Dedicated Systems Magazine. — 2001.— no. 1.

93. K. Audenaert. Clock Trees: Logical Clocks for Programs with Nested Parallelism // IEEE Transactions on Software Engineering.— 1997. — October. — no. 10.

94. K. De Bosschere and M. Ronsse. Clock Snooping and its Application Detection in on-the-fly Data Race // Proceedings of 1997 International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN'97).- 1997.

95. K. Havelund and G. Rosu. Monitoring Java Programs with Java PathExplorer // Proc. First Workshop Runtime Verification (RV '01).— 2001.-July.

96. Lamport L. Time, Clocks, and the Ordering of Events in a Distributed System // Communications of the A CM. — 1978. — July. — Vol. 21, no. 7. — Pp. 558-565.

97. Lamport L. Concurrent Reading and Writing of Clocks // ACM Transactions on Programming Languages and Systems. — 1990. — November. — Vol. 8, no. 4. — Pp. 305-310.

98. Lewis В., Ducarse M. Demos: using events to debug Java programs backwards in time // Companion of the 18th annual ACM SIGPLAN conference on object-oriented programming, systems, languages and applications. — 2003. — October.

99. LynuxWorks, Inc. — SpyKer Pro v 2.0 manual, 2003.

100. Maker P. GNU Nana, Version 2.4, 1999.-April.

101. MasPar, Inc. — MasPar Programming Environment (MPPE) User Guide, Version 2.1, 1991.-July.

102. McCloghrie K., Rose M. — Management Information Base for Network Management of TCP/IP-based internets. — NWG, 1988. — August. — RFC 1066.

103. McCloghrie K., Rose M. — Management Information Base for Network Management of TCP/IP-based internets: MIB-II.- NWG, 1991. — March. RFC 1213.

104. M. Eisenstadt. My Hairiest Bug War Stories // Communications of the ACM. 1997. - April. - no. 4.

105. M. Frumkin and R. Hood and L. Lopez.— Trace-Driven Debugging of Message Passing Programs, 1997. — http://www.nas.nasa.gov/Tools/p2d2.

106. M. Moller. Java Runtime Timing-Constraint Monitor.— Univ. of Oldenburg, Oldenburg, Germany, personal comm., 2002.

107. M. Ronsse and K. De Bosschere. Execution replay and debugging // Communications of the ACM. — 2000. — November.

108. N. Delgado and A. Gates and S. Roach. A Taxonomy and Catalog of Runtime Software-Fault Monitoring Tools // IEEE Transactions on Software Engineering. — 2004. — December. — Vol. 30, no. 12.

109. N. Mittal and V.K. Garg. Debugging Distributed Programs Using Controlled Re-execution // ieee.— 2000.

110. Owens H. D., Womack B. F., Gonzalez M. J. Software error classification using purify // Proceedings of the 1996 International Conference on Software Maintenance (ICSM'96).— 1996.

111. Pankake C., Francioni J. High Perfomance Debugging Forum. HPD Version 1 Standard: Command Interface for Parallel Debuggers: Tech. Rep. CSTR-97: Dept. of Computer Science, Oregon State University, 1997.— http://www.ptools.org/hpdf.

112. Parasoft Corporation. — nCUBE 2 Programmer's Guide, Rev. 2.0, 1990.— December.

113. Pras A. et al. Introduction to TMN: Tech. Rep. CTIT-99-09: University of Twente, Netherlands, 1999. —April.— http://www.snmp.cs.utwente.nl/tutorials/tinn.

114. P.R. Wilson and T.G. Moher. Demonic Memory for Process Histories // Communications of the ACM. — 1989.

115. P.S. Dodd and C.V. Ravishankar. Monitoring and Debugging Distributed Realtime Programs // Software Practice and Experience.— 1992.— October. — no. 10.

116. P. Mork.— Techniques for Debugging Parallel Programs, 1995.

117. Q. Zheng and G. Chen and L. Huang. Optimal Record and Replay for Debugging of Nondeterministic MPI/PVM Programs // Proceedings of the Fourth International Conference/Exhibition on High Performance Computing in Asia-Pacific Region. — IEEE, 2000.

118. Rai S., Sampath D., Srivathsa N. Implementation of ddarc: Software architecture for debugging distributed programs // Proceedings of the ACS/IEEE International Conference on Computer Systems and Applications (AICCSA '01).-2001.

119. Ramsey N., Hanson D. A retargetable debugger // Proceedings of the SIGPLAN'92 Conference on Programming Language Design and Implementation. Vol. 27(7). — SIGPLAN Notices, 1992.- Pp. 22-31.

120. R.H.B. Netzer and J. Xu. Necessary and Sufficient Conditions for Consistent Global Snapshots // IEEE Transactions on Parallel and Distributed Systems. — 1995. — February. — no. 2.

121. R.S. Side and G.C. Shoja. A Debugger for Distributed Programs // Software Practice and Experience. — 1994.— May. — no. 24(5).

122. R. Baldoni. Fundamentals of Distributed Computing: A Practical Tour of Vector Clock Systems // IEEE Distributed Systems Online. — 2002.

123. R. Borgeest and C. Rodel. Trace Analysis with a Relational Database System // Proceedings of the 4th Euroinicro Workshop on Parallel and Distributed Processing (PDP '96). — 1996.

124. R. Curtis and L. Wittie. BugNet: A debugging system for parallel programming environments // Proceedings of the Third International Conference on Distributed Computing Systems. — 1982.

125. R. Konuru and H. Srinivasan and J.-D. Choi and T.J. Watson. Deterministic Replay of Distributed Java Applications // ieee. — 2000.

126. Silicon Graphics, Inc. — CASEVision/Workshop User's Guide, Volumes I and II, 1992. — April.

127. Simmons S. Causal Distributed Assert Statements: Ph.D. thesis / The College of William and Mary. — 2000. — October.

128. Spinczyk 0., Gal A., Schroder-Preikschat W. AspectC++: An Aspect-Oriented Extension to С++ // Proceedings of the 40th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS Pacific 2002). Sydney, Australia: 2002.

129. Srinivasan R. — RPC: Remote Procedure Call Protocol Specification Version 2. NWG, 1995. - August. - RFC 1831.

130. Stallman R. Using the GNU compiler collection. — Free Software Foundation, Inc, 2003. — April.

131. Stallman R., Pesch R., Shebs S. Debugging with GDB. — Free Software Foundation, Inc, 2003.

132. Sun Microsystems, Inc. — Solaris Dynamic Tracing Guide, Beta, 2003.

133. S. Andrei and A.M.K. Cheng and W. Chin and M. Lupu. Systematic Debugging of Real-Time Systems based on Incremental Satisfiability Counting // Proceedings of the 11th IEEE Real Time and Embedded Technology and Applications Symposium (RTAS'05).— 2005.

134. S. Chodrow and M. Gouda. Implementation of the Sentry System // Software Practice and Experience. — 1995. — Vol. 25, no. 4. — Pp. 73-87.

135. S. Grabner and D. Kranzlmiiller and J. Volkert. Debugging of Concurrent Processes // Proceedings of the 3rd Euromicro Workshop on Parallel and Distributed Processing (PDP '95).- IEEE, 1995.

136. S. Kanduri and S. Elbaum. An Empirical Study of Tracing Techniques from a Failure Analysis Perspective // Proceedings of the 13th International Symposiumon Software Reliability Engineering. — IEEE, 2002.

137. S. Sankar and M. Mandal. Concurrent Runtime Monitoring of Formally Specified Programs // Computer.— 1993.— March. — Vol. 26, no. 3.— Pp. 32-41.

138. S. Xu and V. Rajlich. Cognitive Process during Program Debugging // Proceedings of the Third IEEE International Conference on Cognitive Informatics (ICCI'04). IEEE, 2004.

139. The OpenNMS Group, Inc. Система управления OpenNMS.— www.opennms.com.

140. Thinking Machines Corporation.— Prism User's Guide, Version 1.2, 1993.-March.

141. Timmerman M., Gielen F., Lambrix P. High level tools for the debugging of real-time multiprocessor systems // Journal of the ACM. — 1993.

142. Tsai J. et al. A noninterference monitoring and replay mechanism for realtime software testing and debugging // IEEE Transactions on Software Engineering. — 1990.— August. — Vol. 16, no. 8.

143. Tsai J. et al. Distributed real-time systems. Monitoring, visualization, debugging, and analysis. — Wiley-Interscience Publication, 1996.

144. Vickers P., Alty J. A game experience in every application: Siren songs and swan songs, debugging with music // Communications of the ACM. — 2003.-July.-Vol. 46, no. 7.

145. V. K. Garg. Observation and Control for Debugging Distributed Computations // Proc. Third International Workshop on Automated Debugging (AADEBUG'97).- 1997.-May.

146. Watson G. The design and implementation of a parallel relative debugger: Ph.D. thesis / Monash University. — 2000. — October.

147. Wind River Systems. — StethoScope User's Manual, Release 4.1, 1992.— March.

148. Wind River Systems. VxGDB User's Guide 2.0, 1993.

149. Wind River Systems. — WindView User's Guide 1.0.1, 1995. — October.

150. W.N. Robinson. Monitoring Software Requirements Using Instrumented Code // Proc. Hawaii Int'l Conf. System Sciences.— Vol. 9.— 2002.— January. — Pp. 276-287.

151. Ximian, Inc. Обзор объектной компонентной среды Bonobo. — www.ximian.com.

152. Y. Liao and D. Cohen. A Specificational Approach to High Level Program Monitoring and Measuring // IEEE Transactions on Software Engineering.— 1992.— November. — Vol. 18, no. 11. — Pp. 969-978.