Программные продукты и системы, 2014, № 4 (108)

Научно-исследовательский институт

«Центрпрограммсистем»

Программные

продукты и системы

МЕЖДУНАРОДНЫЙ НАУЧНО-ПРАКТИЧЕСКИЙ ЖУРНАЛ

№ 4 (108), 2014

Главный редактор

С.В. ЕМЕЛЬЯНОВ, академик РАН

Тверь

PROGRAMMNYE PRODUKTY 

I SISTEMY

(SOFTWARE & SYSTEMS)

International research and practice journal

no. 4 (108), 2014

Editor-in-Chief 

S.V. EMELYANOV, Academician of the Russian Academy of Sciences

Tver

Russian Federation

Research Institute CENTERPROGRAMSYSTEM

 ПРОГРАММНЫЕ ПРОДУКТЫ И СИСТЕМЫ
Международное научно-практическое 
приложение к международному журналу 
«ПРОБЛЕМЫ ТЕОРИИ И ПРАКТИКИ УПРАВЛЕНИЯ»

Главный редактор 
С.В. ЕМЕЛЬЯНОВ, академик РАН (г. Москва)
Научные редакторы номера
В.Н. РЕШЕТНИКОВ, д.ф.-м.н., профессор, МАТИ (г. Москва)
В.П. КУПРИЯНОВ, д.э.н., профессор, 
НИИ «Центрпрограммсистем» (г. Тверь)
Рецензенты номера: 
И.З. Батыршин, д.т.н., профессор Мексиканского института нефти 
(г. Мехико, Мексика)
Н.А. Семенов, д.т.н., профессор ТГТУ (г. Тверь)
О.А. Славин, д.т.н., зав. лаб. ИСА РАН (г. Москва)
О.В. Яковлев, д.т.н., с.н.с. ВЦ им. А.А. Дородицына (г. Москва)
А.Н. Аверкин, к.ф.м.н., доцент Института САУ (г. Дубна)
В.Н. Кузнецов, д.т.н., профессор ТГТУ (г. Тверь)
Ю.П. Кораблин, д.т.н., профессор РГСУ (г. Москва)
В.В. Голенков, д.т.н., профессор БГУИР (г. Минск, Беларусь)

Издатель НИИ «Центрпрограммсистем»

(г. Тверь)

Учредители: МНИИПУ (г. Москва),

Главная редакция международного журнала 
«Проблемы теории и практики управления»

(г. Москва),

Закрытое акционерное общество 

«Научно-исследовательский институт 

«Центрпрограммсистем» (г. Тверь)

Журнал зарегистрирован

в Комитете Российской Федерации

по печати 26 июня 1995 г.

Регистрационное

свидетельство № 013831

Подписной индекс в каталоге

Агентства «Роспечать» 70799

ISSN 0236-235X (печатн.)
ISSN 2311-2735 (онлайн)

МЕЖДУНАРОДНАЯ РЕДАКЦИОННАЯ КОЛЛЕГИЯ

Семенов Н.А. – д.т.н., профессор Тверского государственного технического университета, заместитель главного 
редактора (г. Тверь, Россия)
Решетников В.Н. – д.ф.-м.н., профессор Российского государственного технологического университета 
им. К.Э. Циолковского, заместитель главного редактора (г. Москва, Россия)
Арефьев И.Б. – д.т.н., профессор Морской академии Польши (г. Щецин, Польша)
Батыршин И.З. – д.т.н., профессор Мексиканского института нефти (г. Мехико, Мексика)
Вагин В.Н. – д.т.н., профессор Московского энергетического института (технического университета) 
(г. Москва, Россия)
Голенков В.В. – д.т.н., профессор Белорусского государственного университета информатики и радиоэлектроники 
(г. Минск, Беларусь)
Еремеев А.П. – д.т.н., профессор Московского энергетического института (технического университета)
(г. Москва, Россия)
Котов А.С. – кандидат наук, ассистент профессора университета Уэйна (штат Мичиган) (г. Детройт, США)
Кузнецов О.П. – д.т.н., профессор Института проблем управления РАН (г. Москва, Россия)
Курейчик В.М. – д.т.н., профессор Технологического института Южного федерального университета 
(г. Таганрог, Россия)
Лисецкий Ю.М. – к.т.н., генеральный директор «S&T Ukraine» (г. Киев, Украина)
Нгуен Тхань Нги – д.ф.-м.н., профессор, проректор Ханойского открытого университета (г. Ханой, Вьетнам)
Николов Р.В. – доктор наук, профессор Университета библиотековедения и информационных технологий Софии
(г. София, Болгария)
Осипов Г.С. – д.ф.-м.н., профессор, заместитель директора Института системного анализа РАН (г. Москва, Россия)
Палюх Б.В. – д.т.н., профессор Тверского государственного технического университета (г. Тверь, Россия)
Попков В.К. – д.ф.-м.н., профессор, академик МАИ (г. Новосибирск, Россия)
Рахманов A.A. – д.т.н., профессор, заместитель генерального директора Концерна «РТИ Системы» (г. Москва, Россия)
Серов В.С. – д.ф.-м.н., профессор Университета прикладных наук Оулу (г. Оулу, Финляндия)
Сотников А.Н. – д.ф.-м.н., профессор, Межведомственный суперкомпьютерный центр РАН (г. Москва, Россия)
Сулейманов Д.Ш. – академик АН Республики Татарстан, д.т.н., профессор Казанского государственного 
технического университета (г. Казань, Республика Татарстан, Россия)
Тарасов В.Б. – к.т.н., Московский государственный технический университет им. Н.Э. Баумана (г. Москва, Россия)
Хорошевский В.Ф. – д.т.н., профессор Московского физико-технического института (технического университета) 
(г. Москва, Россия)
Язенин А.В. – д.ф.-м.н., профессор Тверского государственного университета (г. Тверь, Россия)

АССОЦИИРОВАННЫЕ ЧЛЕНЫ РЕДАКЦИИ

Московский энергетический институт (технический университет), г. Москва, Россия
Технологический институт Южного федерального университета, г. Таганрог, Россия
Тверской государственный технический университет, г. Тверь, Россия
Научно-исследовательский институт «Центрпрограммсистем», г. Тверь, Россия

АДРЕС РЕДАКЦИИ
Россия, 170024, г. Тверь,
пр. 50 лет Октября, 3а
Телефон (482-2) 39-91-49
Факс (482-2) 39-91-00
E-mail: red@cps.tver.ru
www.swsys.ru

Подписано в печать 27.11.2014 г.

Отпечатано ООО ИПП «Фактор и К»

Россия, 170028, г. Тверь, ул. Лукина, д. 4, стр. 1

Заказ № 192

Выпускается один раз в квартал

Год издания двадцать седьмой

Формат 6084 1/8. Объем 268 стр.

Тираж 1000 экз.

Цена 198 руб.

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

 PROGRAMMNYE PRODUKTY I SISTEMY
(SOFTWARE & SYSTEMS)

International research and practice supplement for International magazine 
THEORETICAL AND PRACTICAL ISSUES OF MANAGEMENT
Editor-in-chief 
S.V. Emelyanov, Academician of the Russian Academy of Sciences (Mosсow, Russian Federation)
Science editor of the issue
V.N. Reshetnikov, Dr.Sc. (Physics and Mathematics), Professor, RSTU (MATI) (Mosсow, Russian Federation)
V.P. Kupriyanov, Dr.Sc. (Economics), Professor, Research Institute CENTERPROGRAMSYSTEM
(Tver, Russian Federation)
Reviewers of the issue: 
I.Z. Batyrshin, Dr.Sc. (Engineering), Professor, Mexican Institute of Petroleum (Mexico City, Mexico)
N.A. Semenov, Dr.Sc. (Engineering), Professor, TSTU (Tver, Russian Federation)
O.A. Slavin, Dr.Sc. (Engineering), Head of Laboratory, ISA RAS (Mosсow, Russian Federation)
O.V. Yakovlev, Dr.Sc. (Engineering), Senior Researcher, CC RAS (Mosсow, Russian Federation)
A.N. Averkin, Dr.Sc. (Physics and Mathematics), Associate Professor, Institute of Systems Analysis and Management 
(Dubna, Russian Federation)
V.N. Kuznetsov, Dr.Sc. (Engineering), Professor, TSTU (Tver, Russian Federation)
Yu.P. Korablin, Dr.Sc. (Engineering), Professor, RSSU (Moskow, Russian Federation)
V.V. Golenkov, Dr.Sc. (Engineering), Professor BSUIR (Minsk, Republic of Belarus)

Publisher Research Institute 

CENTERPROGRAMSYSTEM (Tver)

The Founders: International Scientific 

and Research Institute 

for Management Issues (Moscow),

the Chief Editorial Board 

of International Magazine Theoretical 
and practical issues of management

(Moscow),

Research Institute 

CENTERPROGRAMSYSTEM (Tver)

The magazine is on record 

in Russian committee

on press 26th of June 1995

Registration certificate № 013831

ISSN 0236-235X (print)

ISSN 2311-2735 (online)

INTERNATIONAL EDITORIAL BOARD

Semenov N.A. – Dr.Sc. (Engineering), Professor of Tver State Technical University, Deputy Editor-in-Chief
(Tver, Russian Federation)
Reshetnikov V.N. – Dr.Sc. (Physics and Mathematics), Professor of Russian State Technological University (MATI), 
Deputy Editor-in-Chief (Mosсow, Russian Federation)
Arefev I.B. – Dr.Sc. (Engineering), Professor of Poland Szczecin Maritime Academy (Szczecin, Poland)
Batyrshin I.Z. – Dr.Sc. (Engineering), Professor of Mexican Institute of Petroleum (Mexico City, Mexico)
Vagin V.N. – Dr.Sc. (Engineering), Professor of Moscow Power Engineering Institute (Technical University) 
(Mosсow, Russian Federation)
Golenkov V.V. – Dr.Sc. (Engineering), Professor of Belarusian State University of Informatics and Radioelectronics (BSUIR) 
(Minsk, Republic of Belarus)
Eremeev A.P. – Dr.Sc. (Engineering), Professor of Moscow Power Engineering Institute (Technical University) 
(Moscow, Russian Federation)
Kotov A.S. – Ph.D. (Computer Science), Assistant Professor, Wayne State University (Detroit, MI, USA)
Kuznetsov O.P. – Dr.Sc. (Engineering), Professor of the Institute of Control Sciences of the Russian Academy of Sciences
(Moscow, Russian Federation)
Kureichik V.M. – Dr.Sc. (Engineering), Professor of Taganrog Technology Institute at Southern Federal University
(Taganrog, Russian Federation)
Lisetskiy Yu.M. – Ph.D.Tech.Sc., CEO of S&T Ukraine (Kiev, Ukraine)
Nguyen Thanh Nghi – Dr.Sc. (Physics and Mathematics), Professor, Vice-Principal of Hanoi Open University (Hanoi, Vietnam)
Nikolov R.V. – Full Professor of the University of Library Studies and Information Technology (Sofia, Bulgaria)
Osipov G.S. – Dr.Sc. (Physics and Mathematics), Professor, Deputy of the Principal of Institute of Systems Analysis 
of the Russian Academy of Sciences (Mosсow, Russian Federation)
Palyukh B.V. – Dr.Sc. (Engineering), Professor of Tver State Technical University (Tver, Russian Federation)
Popkov V.K. – Dr.Sc. (Physics and Mathematics), Professor, Academician of IIA (Novosibirsk, Russian Federation)
Rakhmanov A.A. – Dr.Sc. (Engineering), Professor, Deputy of the CEO of Concern RTI Systems
(Mosсow, Russian Federation)
Serov V.S. – Dr.Sc. (Physics and Mathematics), Professor of the Oulu University of Applied Sciences (Oulu, Finland)
Sotnikov A.N. – Dr.Sc. (Physics and Mathematics), Professor, Joint Supercomputer Center of the Russian Academy 
of Sciences (Moscow, Russian Federation)
Suleimanov D.Sh. – Academician of TAS, Dr.Sc. (Engineering), Professor of Kazan State Technical University
(Kazan, Republic of Tatarstan, Russian Federation)
Tarassov V.B. – Ph.D. (Engineering), Bauman Moscow State Technical University (Mosсow, Russian Federation)
Khoroshevsky V.F. – Dr.Sc. (Engineering), Professor of Moscow Institute of Physics and Technology
(Moscow, Russian Federation)
Yazenin A.V. – Dr.Sc. (Physics and Mathematics), Professor of Tver State University (Tver, Russian Federation)

ASSOCIATED EDITORIAL BOARD MEMBERS

Moscow Power Engineering Institute (Technical University), Moscow, Russian Federation
Technology Institute at Southern Federal University, Taganrog, Russian Federation
Tver State Technical University, Tver, Russian Federation
Research Institute CENTERPROGRAMSYSTEM, Tver, Russian Federation

EDITORIAL OFFICE ADDRESS
50 let Octyabrya Ave. 3а,
Tver, 170024, Russian Federation

Phone: (482-2) 39-91-49
Fax: (482-2) 39-91-00
E-mail: red@cps.tver.ru
www.swsys.ru

Passed for printing 27.11.2014

Printed in printing-office “Faktor i K”

Lukina St. 4/1, Tver, 170028, Russian Federation

Prod. order № 192
Published quarterly 

27th year of publication

Format 6084 1/8

Circulation 1000 copies

Wordage 268 pages

Price 198 rub.

Вниманию авторов!

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

Решением Президиума Высшей аттестационной комиссии (ВАК) Министерства образования и науки РФ № 8/13 

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

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

Условия публикации

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

(специализация 05.13.ХХ – Информатика, вычислительная техника и управление) и отвечающие редакционным требованиям.

Работа представляется в электронном виде в формате Word (шрифт Times New Roman, размер 11 пунктов с полу
торным межстрочным интервалом). При обилии сложных формул обязательно наличие статьи и в формате PDF. Формулы должны быть набраны в редакторе формул Word (Microsoft Equation или MathType). Объем статьи вместе с иллюстрациями – не менее 10 000 знаков. Иллюстративный материал присылается в формате tiff или jpeg с разрешением 300 
dpi. Диаграммы, схемы, графики должны быть доступными для редактирования. Все иллюстрации для полиграфического 
воспроизведения представляются в черно-белом варианте. Цветные, тонированные, отсканированные, не подлежащие 
редактированию средствами Word рисунки и экранные формы следует присылать в хорошем качестве для их дополнительного размещения на сайте журнала в макете статьи (с доступом по ссылке). Кроме того, публикация материалов с 
использованием гипертекста, графики, аудио-, видео-, программных средств и др. возможна в нашем новом электронном 
издании «Программные продукты, системы и алгоритмы», сайт www.swsys-web.ru. Заголовок должен быть информативным; сокращения, а также терминологию узкой тематики желательно в нем не использовать. Количество авторов на одну 
статью – не более 4, количество статей одного автора в номере, включая соавторство, – не более 2. Список литературы 
(оформленный в соответствии с ГОСТ Р 7.05–2008), наличие которого обязательно, должен включать не менее 5 пунктов.

Необходимы также аннотация (150–200 слов), ключевые слова (7–10) и индекс УДК. Название статьи, аннотация 

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

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

Порядок рецензирования

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

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

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

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

проводятся раз в месяц в НИИ «Центрпрограммсистем» (г. Тверь), где принимается решение о целесообразности публикации статьи.

Статьи, одобренные редакционным советом, публикуются в течение полугода с момента одобрения, 

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

Редакция международного журнала «Программные продукты и системы» в своей работе руководствуется сводом 

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

Программные продукты и системы / Software & Systems
№ 4 (108), 2014

5

УДК 004.416.2
Дата подачи статьи: 04.07.2014

DOI: 10.15827/0236-235X.108.005-009

ТРАССИРОВКА И САМОЛЕЧЕНИЕ В POSIX-СИСТЕМАХ

А.А. Бомбин, инженер, abombin@niisi.msk.ru; 

В.А. Галатенко, д.ф.-м.н., зав. сектором, galat@niisi.msk.ru; 

К.А. Костюхин, к.ф.-м.н., старший научный сотрудник, kost@niisi.msk.ru

(Научно-исследовательский институт системных исследований РАН (НИИСИ РАН), 

Нахимовский просп., 36, к.1, г. Москва, 117218, Россия)

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

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

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

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

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

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

Дается краткий обзор механизма трассировки, описанного в POSIX-2001, предлагается методика самолечения 

программных систем, основанная на этом механизме и интегрированная в концепцию контролируемого выполнения.

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

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

Ключевые слова: POSIX, самолечение, трассировка, отладка, контролируемое выполнение.

Под контролируемым выполнением [1, 2] по
нимается специально организованный процесс 
функционирования аппаратно-программной системы, цель которого – выполнение системой своих 
задач несмотря на наличие ошибок, атак и отказов.

Основные положения концепции контроли
руемого выполнения:

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

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

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

Частными случаями контролируемого выпол
нения являются применение средств управления 
информационными системами, интерактивная отладка [4], мониторинг систем, их самоконтроль 
[5], воспроизведение предыдущих сеансов работы 
систем [6], моделирование, сбор и анализ количественных характеристик их функционирования 
[7], самолечение систем [8, 9].

В данной работе в контексте контролируемого 

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

Трассировка в POSIX-системах

В 2001 году департамент стандартов IEEE 

включил в очередную редакцию POSIX рекомендации по трассировке программно реализуемых 
процессов с целью унификации интерфейса 
средств сбора и анализа данных об их выполнении [10].

Стандарт фиксирует минимальную функцио
нальность средств трассировки, которые должна 
предоставлять POSIX-совместимая операционная 
система. В стандарте POSIX-2001 под трассировкой понимаются порождение, накопление и ана

Программные продукты и системы / Software & Systems
№ 4 (108), 2014

6

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

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

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

Трассируемый процесс должен 

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

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

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

Одно из главных требований к 

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

Стандарт определяет два способа анализа трас
сы: в ходе сбора событий (online analysis) и после 
сбора событий (offline analysis). В первом случае 
анализирующий процесс читает данные из потока 
событий, во втором – из журнала. Оба способа 
представлены на рисунках 1 и 2 соответственно.

Трассирующий и анализирующий процессы

Создание потока трассировки

…

Запуск сбора событий

…

Получение очередного события

Фильтрация, обработка

…

Останов сбора событий

...

Управление
трассировкой

Поток

трассировки

…

Точка трассировки

…

Точка трассировки

Трассируемый процесс

Сбор

отфильтрованных

событий

Визуализация,

сохранение,

отсылка,

дальнейшая обработка

Рис. 1. Анализ трассы в ходе сбора событий

Fig. 1. Tracing during events collection 

Трассирующий процесс

Создание журнала трассировки
Создание потока трассировки

...

Запуск сбора событий

...

Останов сбора событий

Поток

трассировки

Управление
трассировкой

Трассируемый процесс

...

Точка трассировки

...

Точка трассировки

...

Сбор отфильтрованных

событий

Журнал

трассировки

Копирование

событий

В ходе сбора событий

После сбора событий

Процесс анализа трассы

Открытие журнала трассировки

...

Получение очередного события

Фильтрация, обработка

...

Закрытие журнала трассировки

Визуализация,

сохранение,

отсылка,

дальнейшая

обработка

Рис. 2. Анализ трассы после сбора событий

Fig. 2. Tracing after events collection 

Программные продукты и системы / Software & Systems
№ 4 (108), 2014

7

Программный интерфейс трассировки POSIX 

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

–
параллельная трассировка системных и 

пользовательских событий;

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

–
управление трассировкой некоторого про
цесса как потоками управления этого процесса, 
так и внешними процессами;

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

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

–
каждый вновь порождаемый поток трасси
руемого процесса по умолчанию тоже является 
трассируемым;

–
независимо разрабатываемый код может 

подвергаться трассировке без дополнительных настроек и без конфликтов;

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

–
формат потока и журнала трассировки не 

определяется;

–
должна быть возможность поддержки не
скольких потоков трассировки в системе.

Всю необходимую дополнительную информа
цию можно получить из [2].

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

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

Реализация механизма самолечения 

в POSIX-системах

Для начала введем еще одно понятие. Система 

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

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

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

Кроме того, при разработке системы необхо
димо 
зарезервировать 
определенные 
ресурсы 

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

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

Для реализации механизма самостабилизации 

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

Код сервера:

while (1){

sleep(10);    /* Искусственная задержка */
bytesRead = recvfrom(sock, recvData, 1024, 0, (struct 

sockaddr *)&clientAddr, &addrLen);  /* Попытка получить сообщение */

if(bytesRead == -1){
printf("Server receving error!!!\n");
close(sock);
return 7;
}

Программные продукты и системы / Software & Systems
№ 4 (108), 2014

8

recvData[bytesRead] = '\0';
posix_trace_event(serverRecEvent, recvData, strlen(recv
Data)); /* Отсылка в протокол информации о том, что 
сервер успешно получил информацию */

posix_trace_event(serverSendEvent, answer, strlen(ans
wer));    /* Отправка в протокол информации о посылке 
сообщения */

outCode = sendto(sock, answer, strlen(answer), 0, (struct 

sockaddr 
*)&clientAddr, 
sizeof(struct 
sockaddr));    

/*Попытка отправить сообщение */

if(outCode == -1){
printf("Server sending error!!!\n");
close(sock);
return 8;
}
sched_yield();

}

Код клиента аналогичен и вначале отправляет 

сообщение, а потом пытается получить ответ от 
сервера.

Контролирующий поток создает потоки клиен
та и сервера, затем начинает обработку приходящих событий:
while (limit > 0){

curTime = time (NULL);
const struct timespec timeout = {curTime, 500000};
if(posix_trace_timedgetnext_event(testTrace, 
&event, 

recvData, 1024, &bytesRead, &outCode, &timeout)!= 0 || 
outCode != 0){  /*Попытка взять следующее событие из 
протокола */

printf("Can't read events!!!\n");
return 5;
}
if(event.posix_event_id == clientSendEvent && state == 

0){

printf("Client sent message\n");
state++;  /*Состояние, показывающее, какое событие 

ожидается дальше */

importantTime = time (NULL); /*Время с прошлого по
лучения ожидаемого события */

}
else if(event.posix_event_id == serverRecEvent && state 

== 1){

printf("Server received message\n");
state++;
importantTime = time (NULL);
}
else if(event.posix_event_id == serverSendEvent && state 

== 2){

printf("Server sent message\n");
state++;
importantTime = time (NULL);
}
else if(event.posix_event_id == clientRecEvent && state 

== 3){

printf("Client received message\n");
state = 0;
importantTime = time (NULL);
}
curTime = time(NULL);
dif = difftime(curTime, importantTime);
if(dif > 15){  /*Если ожидаемое событие не было полу
чено в течение 15 секунд, рестарт системы */

printf("Restarting system\n");

outCode = pthread_create(&clientThread, &attributes, 

client, 0);

if(0 != outCode){
printf("Can't create new client thread!!! Error code : 

%d\n", outCode);

return 6;

}
outCode = pthread_create(&serverThread, &attributes, 

server, 0);

if(0 != outCode){
printf("Can't create new server thread!!! Error code : 

%d\n", outCode);

return 7;

}
importantTime = time(NULL);
state = 0;
limit --;
}
sched_yield();

}

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

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

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

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

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

если система демонстрирует поведение, соответствующее 
предварительно 
сформулированным 

требованиям.

В данной работе в контексте контролируемого 

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

Литература

1.
Бетелин В.Б., Галатенко В.А., Костюхин К.А. Основные 

понятия контролируемого выполнения сложных систем // Прилож. к журн. «Информационные технологии». 2013. № 3. 32 с.

2.
Галатенко В.А., Костюхин К.А. Отладка и мониторинг 

распределенных разнородных систем // Информационная безопасность. Инструментальные средства программирования. Базы 
данных; [под ред. В.Б. Бетелина]. М.: Изд-во НИИСИ РАН, 2001. 
С. 27–48.

3.
Jackson D. A Direct Path to Dependable Software. 

Communications of the ACM, vol. 52, April, 2009, pp. 78–88.

4.
Тэллес М., Хсих Ю. Наука отладки. М.: КУДИЦ
ОБРАЗ, 2003.

5.
Andersson J., de Lemos R., Malek S., Weyns D. 

Reflecting on Self-Adaptive Software Systems. Proc. Intern. Conf. 
SEAMS'09. 2009, pp. 38–47.

Программные продукты и системы / Software & Systems
№ 4 (108), 2014

9

6.
Andrzejak A. Generic Self-Healing via Rejuvenation: 

Challenges, Status Quo and Solutions. Proc. 4th IEEE Intern. Conf. 
on Self-Adaptive and Self-Organazing Systems Workshop, 2010, 
pp. 239–242.

7.
Khalid A., Haye M.A., Khan M.J., Shamail S. Survey of 

Frameworks, 
Architectures 
and Techniques 
in 
Autonomic 

Computing. Proc. 5th Intern. Conf. on Autonomic and Autonomous 
Systems. 2009, pp. 220–225.

8.
Jung G., Margaria T., Wagner C., Bakera M. Formalizing 

a Methodology for Design- and Runtime Self-Healing. Proc. 7th 
IEEE Intern. Conf. and Workshop on Engineering of Autonomic 
and Autonomous Systems. 2010, pp. 106–115.

9.
Michiels S., Desmet L., Joosen W., Verbaeten P. The 

DiPS+ Software Architecture for Self-healing Protocol Stacks. 
Proc. 4th Working IEEE/IFIP Conf. on Software Architecture 
(WICSA'04). 2004, pp. 233–242.

10. The Open Group Base Specifications. IEEE Std 1003.1, 

2001, iss. 6.

DOI: 10.15827/0236-235X.108.005-009
Received 04.07.2014

TRACING AND SELFHEALING IN POSIX-SYSTEMS

Bombin A.A., Engineer, abombin@niisi.msk.ru; 

Galatenko V.A., Dr.Sc. (Physics and Mathematics), Head of Sector, galat@niisi.msk.ru;
Kostyukhin K.A., Ph.D. (Physics and Mathematics), Senior Researcher, kost@niisi.msk.ru 

(Scientific Research Institute for System Studies of the Russian Academy of Sciences (SRISA RAS), 

Nakhimovskiy Ave. 36/1, Moscow, 117218, Russian Federation)

Abstract. This paper formulates a definition of the controlled execution original concept and motivates the 

importance of this concept when creating complex systems. Controlled execution is a specially organized process of 
hardware and software system functioning. This system is intended to perform its tasks despite errors, attacks and 
failures.

The basics of controlled concept execution are: integration of information security, debugging and management 

tools; distribution of controlled execution for all phases of system life cycle; integrity of the controlled execution tools,
differing in an impact degree on the target system, the possibility of interactions between these tools.

Special cases of controlled execution are: information systems controlling; interactive debugging; system 

monitoring; system self-control; playback the previous sessions of the systems; modeling, collection and analysis of 
quantitative characteristics of systems; system selfhealing.

Taking in the context of controlled execution, the authors propose a POSIX-systems selfhealing technique based 

on the POSIX trace mechanism.

There is a brief review of a trace mechanism described in POSIX-2001. The paper proposes a technique of 

software systems selfhealing based on this mechanism and integrated into controlled execution concept.

POSIX-2001 fixes the minimum functionality of tracing tools, which should be provided by a POSIX-compliant 

operating system. POSIX-2001 standard refers tracing as collection, accumulation and analysis of data on the events 
that took place in the user application operation.

The work includes an example which can be useful in the practical application of selfhealing methods.
Keywords: POSIX, selfhealing, tracing, debugging, controlled execution.

References

1. Betelin V.B., Galatenko V.A., Kostyukhin K.A. The main concepts of the complex systems controlled 

execution paradigm. Informatsionnye tekhnologii [Information Technologies]. Additional issue, no. 3, 2013 (in Russ.).

2. Galatenko V.A., Kostyukhin K.A. Debugging and monitoring of distributed heterogeneous systems. 

Informatsionnaya bezopasnost. Instrumentalnye sredstva programmirovaniya. Bazy dannykh [Information Security. 
Software Programming Tools. Databases]. Moscow, SRISA RAS Publ., 2001, pp. 27–48 (in Russ.).

3. Jackson D. A direct path to dependable software. Communications of the ACM. 2009, vol. 52, pp. 78–88.
4. Telles M., Hsieh Y. The Science of Debugging. Scottsdale AZ, USA, Coriolis Group Books, 2001.
5. Andersson J., de Lemos R., Malek S., Weyns D. Reflecting on self-adaptive software systems. Proc. 

SEAMS'09. 2009, pp. 38–47.

6. Andrzejak A. Generic Self-Healing via Rejuvenation: Challenges, Status Quo and Solutions. Proc. 4th IEEE 

Int. Conf. on Self-Adaptive and Self-Organazing Systems Workshop. 2010, pp. 239–242.

7. Khalid A., Haye M.A., Khan M.J., Shamail S. Survey of Frameworks, Architectures and Techniques in 

Autonomic Computing. Proc. 5th Int. Conf. On Autonomic and Autonomous Systems. 2009, pp. 220–225.

8. Jung G., Margaria T., Wagner C., Bakera M. Formalizing a Methodology for Design- and Runtime Self
Healing. Proc. 7th IEEE Int. Conf. and Workshop on Engineering of Autonomic and Autonomous Systems. 2010, 
pp. 106–115.

9. Michiels S., Desmet L., Joosen W., Verbaeten P. The DiPS+ Software Architecture for Self-healing Protocol 

Stacks. Proc. 4th Working IEEE/IFIP Conf. on Software Architecture (WICSA'04). 2004, pp. 233–242.

10. The Open Group Base Specifications. Iss. 6. IEEE Std 1003.1, 2001.

Программные продукты и системы / Software & Systems
№ 4 (108), 2014

10

УДК 004.942
Дата подачи статьи: 04.07.2014

DOI: 10.15827/0236-235X.108.010-015

ВИЗУАЛЬНЫЙ РЕДАКТОР И МОДУЛЬ РАСЧЕТА 

ФУНКЦИОНАЛЬНЫХ СХЕМ 

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

(Исследования выполнены при поддержке РФФИ, грант № 13-07-00708)

М.В. Михайлюк, д.ф.-м.н., профессор, зав. отделом, mix@niisi.ras.ru; 

М.А. Торгашев, к.ф.-м.н., зав. сектором, mtorg@mail.ru

(НИИСИ РАН, Нахимовский просп., 36, корп. 1, г. Москва, 117218, Россия)

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

Ключевые слова: системы управления, функциональные схемы, имитационно-тренажерные комплексы, вирту
альное моделирование.

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

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

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

в виде функциональной схемы, элементы которой 
называются 
функциональными 
звеньями 
или 

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

В области моделирования систем управления 

на основе функциональных схем существует 
большое количество разработок, например программные
пакеты
Simulink, 
Scicos, 
Dymola, 

LabView. Рассмотрим их возможности и особенности. 

Пакет Simulink [1] предназначен для проекти
рования систем управления и коммутации, цифровой обработки и моделирования динамических 
систем на основе блочных схем. Он является составной частью программного комплекса Mathlab, 
с которым тесно интегрирован. Пакет обладает 
широкими возможностями и имеет модульную 
структуру с возможностью дополнительного расширения функциональности. Этот программный 
пакет широко используется по всему миру и фактически является отраслевым стандартом в области моделирования систем управления. Это коммерческий продукт, цена которого довольно значительна. Недорогие лицензии предлагаются лишь 
для научного и некоммерческого использования. 
Из недостатков пакета можно отметить его сложность и громоздкость. 

Аналогом программного продукта Simulink яв
ляется Scicos [2] – инструмент для редактирования 
блочных диаграмм и симуляции, входящий в пакет Scilab. Этот программный продукт предоставляет схожую с Simulink функциональность, но является при этом некоммерческим opensource-проектом. 

Еще один аналог Simulink – программный па
кет Dymolа [3]. Это коммерческий продукт компании Dassault Systems, предназначенный для мо