Your SlideShare is downloading. ×
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

TMPA-2013 Conference Proceedings

2,080

Published on

On 10-12 October 2013, Kostroma, Russia, will host 2013 International Workshop-Conference “Tools & Methods of Program Analysis” (TMPA-2013). …

On 10-12 October 2013, Kostroma, Russia, will host 2013 International Workshop-Conference “Tools & Methods of Program Analysis” (TMPA-2013).
Its general theme will be one of the most pertinent and important areas of software engineering: the analysis of software quality.
The issues of efficiency and correctness of software are key for the majority of knowledge-intensive industries in modern economy, including IT, financial sector, transportation, medicine, high-technology industries, and many others. The development of new instruments and methods of program analysis, as well as the modification of existing ones, is one of the necessary prerequisites for introducing innovation.
The purpose of the conference is to promote progress in the software development industry and the introduction of the latest achievements in the areas of testing, analysis and verification.
The conference program will include plenary reports and mini-courses delivered by experts; presentations selected by the Program Committee; presentations of on-going projects, short reports about new ideas, research that is still underway or new tools.

The program will include, and won’t be limited to, the following topics:
- software test automation;
static program analysis;
verification;
dynamic methods of program analysis;
testing and analysis of parallel and distributed systems;
testing and analysis of high-load and high-availability systems;
analysis and verification of hardware and software systems;
methods of building quality software;
tools for software analysis, testing and verification.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,080
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Министерство образования и науки РФ Костромской государственный технологический университет Санкт-Петербургский государственный политехнический университет Российская академия наук Институт проблем информатики ООО «Инновационные Трейдинговые Системы» ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ TOOLS & METHODS OF PROGRAM ANALYSIS TMPA-2013 Материалы Международной научно-практической конференции 10—12 октября 2013 Кострома 2013
  • 2. УДК 004.413.5 И726 Печатается по решению научно-технического совета КГТУ Редакционная коллегия: Председатель: Киселев М.В. Члены редколлегии: Захаров В.Н., Ицыксон В.М., Лустгартен Ю.Л., Иткин И.Л., Ходченко А.С., Загоруйко К.В., Аввакумова Е.С., Зверев А.В., Рудовский П.Н И726 Инструменты и методы анализа программ Tools & Methods of Program Analysis TMPA-2013: материалы Международной науч.практ. конф.- Кострома: Из-во Костромского гос. технол. ун-та, 2013. - 348 с. ISBN 978-5-8285-0666-8 В сборнике публикуются доклады участников Международной научно-практической конференции «Инструменты и методы анализа программ / Tools & Methods of Program Analysis (TMPA2013)», состоявшейся 10-12 октября 2013 г. в Костромском государственном технологическом университете. Для широкого круга читателей. ISBN 978-5-8285-0666-8 16+ УДК 004.413.5 © Костромской государственный технологический университет, 2013
  • 3. Содержание: ВЕРИФИКАЦИЯ: • Пакулин Н. Динамическая верификация гибридных систем 19 Институт системного программирования РАН • Подымов В., Попеско У. 36 Верификация программно-конфигурируемых сетей при помощи системы UPPAAL МГУ имени М.В. Ломоносова • Кузьмин Е., Рябухин Д., Шипов А. Построение и верификация ПЛК-программ по LTL-спецификации 48 Ярославский государственный университет им. П.Г. Демидова • Ануреев И. На пути к технологии разработки стредств дедуктивной верификации программ 66 Институт систем информатики имени А.П. Ершова • Лукин М., Шалыто А. Верификация распределенных автоматных программ с использованием инструментального средства Spin 78 СПб НИУ ИТМО АППАРАТНЫЙ ТРЕК: • Иванников В., Камкин А., Чупилко М. Проверка корректности поведения HDL-моделей цифровой аппаратуры на основе динамического сопоставления трасс 94 Институт системного программирования Российской академии наук (ИСП РАН) • Шипин А., Соколов В., Чалый Д. Использование контрольных точек для верификации SystemCпрограмм 106 Ярославский государственный университет 6 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 4. • Френкель С., Захаров В., Ушаков В. Унифицированная высокоуровневая модель программноаппаратной системы для верификации свойств надежности функционирования 118 Институт проблем информатики РАН, Московский гос. университет им. М.В. Ломоносова • Смирнов М., Олоничев В., Староверов Б. Особенности разработки программного обеспечения для Linuxконтроллеров 130 Костромской государственный технологический университет ТЕСТИРОВАНИЕ: • Басок Б., Гречин А. Об усовершенствовании статистического метода оценки полноты тестов программ и устройств 138 Московский государственный технический университет радиотехники, электроники и автоматики • Сартаков В., Тарасиков А. Анализ производительности сетевой подсистемы микроядерного окружения Genode 146 ksys labs • Журавлев М., Полозов В. Подход к верификации корректности миграции данных между СУБД с использованием криптографических хэш-функций 158 Санкт-Петербургский Государственный Университет • Никешин А., Пакулин Н., Шнитман В. Автоматизация тестирования соответствия протокола безопасности транспортного уровня TLS 167 Институт системного программирования РАН Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 7
  • 5. • Сенов А. Применение технологий OLAP и MapReduce для обработки результатов нагрузочного тестирования 179 Костромской государственный технологический университет ТРЕЙДИНГОВЫЕ СИСТЕМЫ: • Матвеева А., Антонов Н., Иткин И. Особенности инструментов для тестирования, применимых при промышленной эксплуатации трейдинговых систем 191 ООО «Инновационные Трейдинговые Системы», Костромской государственный технологический университет, Exactpro Systems LLC • Алексеенко А., Проценко П., Матвеева А., Иткин И., Шаров Д. 203 Тестирование совместимости протокольных подключений клиентов биржевых и брокерских систем ООО «Инновационные Трейдинговые Системы», Exactpro Systems LLC • Буянова О., Булда А, Зверев А. Применение симуляторов рынка ценных бумаг для тестирования систем агрегации и распределения информации о котировках (Ticker Plant) 215 ООО «Инновационные Трейдинговые Системы», Костромской государственный технологический университет, Exactpro Systems LLC • Гурьев Д., Гай М., Иткин И., Терентьев А. Высокопроизводительный генератор нагрузки для тестирования систем автоматизированной торговли 242 ООО «Инновационные Трейдинговые Системы», Саратовский государственный технический университет имени Гагарина Ю.А. 8 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 6. • Прядкина Н., Крюков А. Использование MBT-подхода для верификации систем мониторинга и контроля на фондовых биржах 254 Костромской государственный технологический университет • Бобров И., Зверев А. Тестирование графического интерфейса трейдинговых терминалов в условиях высокочастотной торговли 264 ООО «Инновационные Трейдинговые Системы» АНАЛИЗ ПРОГРАММ: • Цителов Д., Трифанов В. Динамический поиск гонок в Java-программах на основе синхронизационных контрактов 273 Devexperts LLC, СПбГУ • Верт Т., Крикун Т., Глухих М. Обнаружение дефектов работы с указателями в программах С и С++ с использованием статического анализа и логического вывода 286 Санкт-Петербургский государственный политехнический университет, Технический университет Клаусталя • Андрианова А., Ицыксон В. Автоматизированный синтез тестов для Java-программ на основе анализа программ и учета контрактов 298 Санкт-Петербургский государственный политехнический университет • Буй Д., Компан С. Диаграммы классов ООП: формализация и анализ 311 Киевский национальный университет имени Тараса Шевченко Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 9
  • 7. Конференция TMPA-2013 10 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 8. Международная научно-практическая конференция: Tools & Methods of Program Analysis (Инструменты и методы анализа программ, TMPA-2013) 10-12 октября 2013, г. Кострома, РФ Конференция посвящена одному из наиболее актуальных и важных направлений программной инженерии – анализу качества программного обеспечения. Вопросы эффективности и корректности функционирования программного обеспечения являются ключевыми для большинства наукоемких отраслей современной экономики, включая ИТ-индустрию, финансовый сектор, транспорт, медицину, высокотехнологическую промышленность и многие другие. Разработка новых и усовершенствование существующих инструментов и методов анализа программ – одно из необходимых условий внедрения инноваций в этих отраслях. Конференция нацелена на развитие индустрии разработки программного обеспечения и внедрение новейших разработок в области тестирования, анализа и верификации. В рамках конференции планируются пленарные доклады и лекционные мини-курсы экспертов; доклады участников, отобранные программным комитетом из числа поступивших заявок; презентации открытых проектов, короткие сообщения, представляющие новые идеи, незавершенные исследования или новые инструменты. Темы, рассматриваемые на конференции, включают (но не ограничиваются): • автоматизация тестирования программного обеспечения; • статический анализ программ; • верификация; • динамические методы анализа программ; • тестирование и анализ параллельных и распределенных систем; • тестирование и анализ высоконагруженных систем и систем высокой доступности; • анализ и верификация программно-аппаратных систем; • методы создания качественного программного обеспечения; • инструментальные средства анализа, тестирования и верификации Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 11
  • 9. Программный комитет конференции • Захаров Виктор Николаевич, д.т.н., ИПИ РАН, сопредседатель • Ицыксон Владимир Михайлович, к.т.н., доцент кафедры компьютерных систем и программных технологий СПбГПУ, сопредседатель • Лустгартен Юрий Леонидович, к.т.н., декан ФАСТ КГТУ, сопредседатель • Петренко Александр Константинович, д.ф.-м.н., зав. отделом Технологий программирования Института системного программирования РАН, профессор кафедры Системного программирования ВМиК МГУ им. М.В.Ломоносова • Басок Борис Моисеевич, к.т.н., доцент МИРЭА • Глухих Михаил Игоревич, к.т.н., доцент, СПбГПУ, приглашенный исследователь в Clausthal University of Technology • Евтушенко Нина Владимировна, д.т.н., профессор, зав. кафедры Информационных технологий в исследовании дискретных структур, Радиофизический факультет, Национальный исследовательский Томский государственный университет (ТГУ) • Зайцев Дмитрий Анатольевич, д.т.н., профессор, Международный гуманитарный университет, Одесса, Украина • Захаров Владимир Анатольевич, д.ф.-м.н., доцент кафедры МК, зав. лабораторией МПКБ • Иванов Александр Николаевич, к.ф.-м.н., ведущий разработчик ООО «КоФиТе» • Иткин Иосиф Леонидович, компания Exactpro Systems, координатор • Камкин Александр Сергеевич, к.ф.-м.н., с.н.с. ИСП РАН; • Климов Андрей Валентинович, зав. сектором методов анализа и преобразования программ ИПМ им. М.В.Келдыша РАН 12 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 10. • Кириленко Яков Александрович, старший преподаватель, МатМех СПбГУ • Кулямин Виктор Вячеславович, к.ф.-м.н., с.н.с. ИСП РАН, доцент ВМК МГУ • Моисеев Михаил Юрьевич, к.т.н., доцент, СПбГПУ • Пакулин Николай Витальевич, к.ф.-м.н., старший научный сотрудник ИСП РАН • Павлова Елена Анатольевна, к.т.н., координатор программ, Microsoft • Прохоров Сергей Петрович, к.ф.-м.н., ИСП РАН, доцент МФТИ • Соколов Валерий Анатольевич, д.ф.-м.н., проф., зав. каф. теоретической информатики ЯГУ им. П.Г. Демидова • Федосеев Андрей Алексеевич, к.т.н., в.н.с. ИПИ РАН • Филиппов Станислав Александрович, к.т.н., с.н.с. ИПИ РАН • Христочевский Сергей Александрович, к.ф.-м.н., зав. лаб. ИПИ РАН • Цесько Вадим Александрович, старший разработчик, Яндекс Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 13
  • 11. Программа конференции TMPA-2013 14 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 12. 10 октября 8:30 Регистрация 9:30 Открытие 10:15 11:15 Карпов Ю. Верификация параллельных программ: современный этап и перспективы Кофе-брейк ВЕРИФИКАЦИЯ 11:45 Пакулин Н. Динамическая верификация гибридных систем 12:15 Подымов В., Попеско У. Верификация программно-конфигурируемых сетей при помощи системы UPPAAL 12:45 Кузьмин Е., Рябухин Д., Шипов А. Построение и верификация ПЛК-программ по LTL-спецификации 13:15 Ануреев И. На пути к технологии разработки средств дедуктивной верификации программ 13:45 Лукин М., Шалыто А. Верификация распределенных автоматных программ с использованием инструментального средства Spin 14:00 Обед 15:30 Зайцев Д. Эффективная универсальная сеть Слепцова АППАРАТНЫЙ ТРЕК 16:00 Иванников В., Камкин А., Чупилко М. Проверка корректности поведения HDL-моделей цифровой аппаратуры на основе динамического сопоставления трасс 17:00 Шипин А., Соколов В., Чалый Д. Использование контрольных точек для верификации SystemC-программ 17:30 Френкель С., Захаров В., Ушаков В. Унифицированная высокоуровневая модель программно-аппаратной системы для верификации свойств надежности функционирования 17:45 Смирнов М., Олоничев В., Староверов Б. Особенности разработки программного обеспечения для Linuxконтроллеров Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 15
  • 13. 11 октября 8:30 Регистрация 9:30 Петренко А. К. Технические решения и нетехнические проблемы автоматизации тестирования 10:30 ISTQB ТЕСТИРОВАНИЕ 11:00 11:30 Басок Б., Гречин А. Об усовершенствовании статистического метода оценки полноты тестов программ и устройств Кофе-брейк 12:00 Никешин А., Пакулин Н., Шнитман В. Автоматизация тестирования соответствия реализаций стандарту протокола безопасности транспортного уровня TLS 12:30 Сартаков В., Тарасиков А. Анализ производительности сетевой подсистемы микроядерного окружения Genode 13:00 Журавлев М., Полозов В. Подход к верификации корректности миграции данных между СУБД с использованием криптографических хэш-функций 13:15 Сенов А. Применение технологий OLAP и MapReduce для обработки результатов нагрузочного тестирования ТРЕЙДИНГОВЫЕ СИСТЕМЫ 13:30 14:00 15:30 Матвеева А., Антонов Н., Иткин И. Особенности инструментов для тестирования, применимых при промышленной эксплуатации трейдинговых систем Обед Алексеенко А., Проценко П., Матвеева А., Иткин И., Шаров Д. Тестирование совместимости протокольных подключений клиентов биржевых и брокерских систем 15:50 16:10 Гурьев Д., Гай М., Иткин И., Терентьев А. Высокопроизводительный генератор нагрузки для тестирования систем автоматизированной торговли 16:30 16 Буянова О., Булда А, Зверев А. Применение симуляторов рынка ценных бумаг для тестирования систем агрегации и распределения информации о котировках (Ticker Plant) Прядкина Н., Крюков А. Использование MBT-подхода для верификации систем мониторинга и контроля на фондовых биржах Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 14. 11 октября 16:45 Бобров И., Зверев А. Тестирование графического интерфейса трейдинговых терминалов в условиях высокочастотной торговли 17:00 Кофе-брейк 17:30 Круглый стол: Нешаблонные методы тестирования программного обеспечения для электронных торговых платформ 12 октября 9:00 Регистрация 9:30 Захаров В. А. Математические аспекты задачи обфускации программ АНАЛИЗ ПРОГРАММ 10:30 Цителов Д., Трифанов В. Динамический поиск гонок в Java-программах на основе синхронизационных контрактов 11:00 Верт Т., Крикун Т. и Глухих М. Обнаружение дефектов работы с указателями в программах С и С++ с использованием статического анализа и логического вывода 11:30 Кофе-брейк 12:30 Андрианова А., Ицыксон В. Автоматизированный синтез тестов для Java-программ на основе анализа программ и учета контрактов 12:45 Буй Д., Компан С. Диаграммы классов ООП: формализация и анализ 13:00 Круглый стол: Как написать хорошую научную статью 13:30 Закрытие конференции 14:00 Завершающий обед Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 17
  • 15. Cекционные доклады TMPA-2013 18 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 16. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 19
  • 17. 20 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 18. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 21
  • 19. 𝑑𝑑𝑑𝑑 𝑑𝑑𝑑𝑑 = 𝑘𝑘(100 − 𝑇𝑇 ) 𝑘𝑘1 < 𝑑𝑑𝑑𝑑 𝑑𝑑𝑑𝑑 𝑘𝑘 < 𝑘𝑘2 𝑇𝑇 𝑇 70 𝑇𝑇 𝑇 68 22 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 20. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 23
  • 21. 𝑀𝑀 𝐼𝐼 𝑆𝑆 𝐼𝐼 24 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 22. 𝜑𝜑 𝐼𝐼 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝑓𝑓 (𝑥𝑥) 𝑙𝑙 ≤ 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ≤ 𝑚𝑚 𝑙𝑙 𝑚𝑚 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 25
  • 23. 26 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 24. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 27
  • 25. 28 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 26. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 29
  • 27. 30 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 28. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 31
  • 29. 32 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 30. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 33
  • 31. 34 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 32. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 35
  • 33. Верификация программно-конфигурируемых сетей при помощи системы UPPAAL Владислав Подымов, Ульяна Попеско МГУ имени М.В. Ломоносова valdus@yandex.ru, ulya_kiber@mail.ru Аннотация В последние несколько лет активное развитие получили программно-конфигурируемые сети (ПКС) – особый вид компьютерных сетей, в которых все коммутирующие устройства имеют централизованное управление. В статье исследуются задачи формального описания и верификации ПКС. Для описания ПКС используется библиотека элементов UML в редакторе диаграмм Dia. Для верификации ПКС используется программно-инструментальное средство UPPAAL. Основной результат исследований - разработка транслятора, позволяющего по диаграмме сети получить её модель для верификации в виде сети конечных временных автоматов. Корректность алгоритма трансляции строго обоснована. Проведен ряд экспериментов, которые показывают применимость предложенного метода верификации для проверки свойств поведения ПКС, специфицированных посредством формул темпоральной логики реального времени. Keywords: программно-конфигурируемая сеть, верификация, временные автоматы, темпоральная логика, UPPAAL 1 Введение Идея программно-конфигурируемых сетей (ПКС) сформулирована специалистами университетов Стэнфорда и Беркли в 2006 году [1]. В таких сетях уровень управления отделен от устройств передачи данных: коммутаторы не участвуют в определении маршрутов для пакетов, а только реализуют программу контроллера. Наиболее широко применяемым стандартом для построения ПКС является протокол OpenFlow [2]. Сеть OpenFlow состоит из коммутаторов, управляемых централизованным контроллером. Пакет, передаваемый по сети, обрабатывается контроллером существенно медленнее, нежели коммутатором, поэтому одной из основных функций контроллера является организация работы коммутаторов так, чтобы они обрабатывали большую часть пакетов, и лишь в исключительных случаях пакеты обрабатывались бы на контроллере. Организация работы коммутаторов заключается в установке правил в таблицы коммутации (flow tables), определяющих, как будут обрабатываться те или иные пакеты. Правило состоит из шаблона, идентифицирующего вид пакетов, целочисленного приоритета, устраняющего неоднозначность в 36 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 34. 2 Владислав Подымов, Ульяна Попеско случае наложения шаблонов, целочисленного лимита времени, указывающего число секунд до истечения срока активности правила, и списка действий, описывающих обработку пакета. Также для каждого правила в этих таблицах коммутатор содержит счетчики для учета количества и размера обрабатываемых пакетов. Коммутатор обрабатывает приходящий пакет в 3 этапа. Сначала он выбирает правило из своей таблицы коммутации так, чтобы заголовок пакета соответствовал шаблону этого правила. Если такового не найдено, коммутатор отправляет пакет контроллеру для дальнейшей обработки. Иначе выбирается совпадающее по шаблону правило с наибольшим приоритетом. На втором шаге обновляются счетчики для выбранного правила. И наконец, к пакету поочередно применяются все действия, записанные в правиле. К допустимым действиям относятся output(op) и modif y(h,n). По действию output(op) пакет отправляется на порт op. Действие modif y(h,n) предписывает переписать заголовочное поле h на n. Контроллер устанавливает правила в таблицы коммутации, реагируя на события в сети. Такими событиями являются подключение нового коммутатора к сети, удаление ранее действующего коммутатора из сети, события для сбора статистики, истечение лимита времени правила коммутатора. Также контроллер оперирует функциями отправки сообщений коммутаторам: установкой правил в таблицу коммутации, удалением всех правил с заданным шаблоном из таблицы коммутации, отправкой пакета и действия для его обработки коммутатором. В статье исследуется возможность верификации ПКС как распределенных систем реального времени. Для этого потребовалось решить следующие задачи: 1) выбрать адекватное средство для построения сетей; 2) выбрать подходящее средство для верификации сетей как систем реального времени; 3) построить корректный транслятор из выбранного средства построения сетей во входной язык нужной системы верификации; 4) провести экспериментальное исследование возможности применения выбранного средства верификации для проверки спецификаций ПКС. Стандарт OpenFlow включает в себя большое количество свойств и предписаний для коммутации пакетов в сети. Производители компонентов компьютерных сетей используют лишь часть из них. Мы также ограничимся в рассматриваемых вариантах. При моделировании правил таблиц коммутации не будем уделять внимание приоритетам и счетчикам, а из всех допустимых действий будем рассматривать только действия типа output(op). Сбор статистических данных в сети также не будет нас интересовать. С другой стороны, в нашу модель будут добавлены временные характеристики, описывающие работу физических объектов сети. Посредством этого мы будем учитывать не только предписания стандарта OpenFlow, но и технические возможности коммутаторов и каналов. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 37
  • 35. Верификация ПКС при помощи системы UPPAAL 2 3 Схема верификации Для построения ПКС был выбран кроссплатформенный редактор диаграмм Dia1 . Сеть из рассматриваемого нами подкласса описывается с помощью объектов библиотеки элементов UML, предоставляемых редактором, следующим образом (см. рисунок 1). Каждый коммутатор изображается в виде прямоугольника с тремя секциями. В верхней секции обозначается имя коммутатора, в нижней содержатся правила таблицы коммутации, в средней — физические характеристики коммутатора. Каждое правило таблицы коммутации имеет четыре поля: имя порта, на который поступил пакет, заголовок поступившего пакета, лимит времени жизни правила и порт, на который необходимо отправить пакет. Описываются следующие характеристики коммутатора: port — множество портов коммутатора, соединяющих его с другими коммутаторами и внешней средой; rule_imp — задержка поиска и выполнения правила на коммутаторе (временной интервал); rule_def — задержка установки в коммутатор правила от контроллера; rule_ar — интенсивность поступления пакетов из внешней среды; rule_con — задержка доставки необработанного пакета контроллеру; tab — объем таблицы коммутации, то есть максимальное число правил таблицы. Рис. 1. Пример описания ПКС диаграммами Dia. Для отображения топологии сети коммутаторы соединяются линиями, моделирующими дуплексные каналы сети. Каналы также имеют временную характеристику — задержку доставки пакета. Поведение контроллера опре1 38 Руководство пользователя редактора Dia доступно по адресу http://diainstaller.de/doc/en/dia-manual.pdf Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 36. 4 Владислав Подымов, Ульяна Попеско деляется политикой коммутации пакетов в сети, которая для нашего класса задач представима в виде таблицы, отображающей соответствие между заголовком поступившего на контроллер пакета и правилом, которое необходимо установить на коммутатор, приславший этот пакет. Также отдельно описывается множество всех возможных заголовков пакетов. Для проверки спецификаций построенных таким образом ПКС было выбрано программно-инструментальное средство UPPAAL [3], использующее метод проверки свойств на моделях. Данный метод предполагает наличие модели, описывающей систему на определенном уровне абстракции, и позволяет проверить, удовлетворяет ли заданная модель системы формальным спецификациям. В средстве верификации UPPAAL в качестве модели используются сети конечных временных автоматов (параллельные композиции временных автоматов) [4], а формальные спецификации задаются формулами темпоральной логики TCTL [3]. Временные автоматы представляют собой конечные автоматы, работающие в реальном времени и осуществляющие синхронизацию посредством передачи сигналов через каналы связи. Особенностью таких автоматов является возможность использования таймеров. Значения таймеров можно указывать во временных ограничениях условий переходов между состояниями. Показания всех таймеров изменяются на одинаковые величины с течением времени. Для верификации ПКС, описанных в терминах диаграмм Dia, средством UPPAAL, нами предложен алгоритм трансляции диаграмм в сети временных автоматов. Сеть, получаемая при трансляции, состоит из автоматов, моделирующих коммутаторы, контроллер, внешнюю среду и каналы сети. Таким образом, в результате трансляции диаграмм мы получаем сеть, пригодную для верификации средством UPPAAL. Подобный подход к верификации распределенных систем реального времени был применен в работе [5]. 3 Формальный синтаксис ПКС Перед описанием алгоритма трансляции необходимо ввести формальную модель ПКС. С учетом выбранных нами ограничений ПКС может быть описана системой (H, con, Com, Chan), где H — множество заголовков пакетов сети, con — контроллер, Com = (com1 , . . . , comn ) — набор коммутаторов сети и Chan = (c1 , . . . , cm ) — набор каналов сети. Заметим, что во введенной формальной модели ПКС вместо пакетов рассматриваются только их заголовки, при этом содержащиеся в пакетах сообщения опускаются. Для простоты восприятия далее под пакетами в формальной модели будут подразумеваться их заголовки. Коммутатор comi включает в себя множество портов P orti , начальную таблицу коммутации Rulei ⊆ P orti × H × Real × P orti объема tab и временimp def ar con ные характеристики Limp , Ri , Ldef , Ri , Lar , Ri , Lcon , Ri , естественi i i i ным образом соотносящиеся с характеристиками коммутатора, описанными Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 39
  • 37. Верификация ПКС при помощи системы UPPAAL 5 в диаграмме (см., например, рисунок 1). Правило (p, h, x, p ) таблицы коммутации означает, что пакет h, пришедший на порт p, перенаправляется на порт p . При этом x — время жизни правила; если x ≥ 0, то правило назовем активным, иначе истекшим. Шаблоном правила (p, h, x, p ) будем называть пару (p, h). Контроллер con представляет собой множество пар вида (i, r), означающих, что правило r может быть выслано коммутатору comi . Канал c описывается тем, из какого порта какого коммутатора он исходит, в какой порт какого коммутатора он входит и временными характеристиками L, R — минимальное и максимальное время задержки при доставке пакета. Заметим, что в предложенной модели каналы являются однонаправленными. Такое ограничение несущественно, т.к. дуплексный канал моделируется двумя однонаправленными. 4 Формальная семантика ПКС Для доказательства корректности алгоритма трансляции необходимо ввести формальное описание работы ПКС. Данное описание является формализацией поведения ПКС в рамках стандарта OpenFlow с учетом введенных нами ограничений. Состояние ПКС складывается из состояний контроллера и всех коммутаторов и каналов. Для удобства описания предполагаем, что каждый коммутатор comi располагает следующими каналами: канал car входного потока i ar с временными характеристиками L = Lar , R = Ri , ведущий в специально i выделенный под него порт; канал cto con , ведущий в контроллер из другого i con специально выделенного порта, с характеристиками L = Lcon , R = Ri ; i f rom con , ведущий от контроллера в третий специально выделенный канал ci порт коммутатора, с характеристиками L = R = 0. Таким образом, состояние S ПКС включает в себя состояния scon контроллера, scom , . . . , scom комn 1 мутаторов и sch , . . . , sch , sar , . . . , sar , stocon , . . . , stocon , sf romcon , . . . , sf romcon m n n n 1 1 1 1 каналов ch между коммутаторами, ar от входного потока, to con к и f rom con от контроллера соответственно. Коммутатор comi может находиться в состояниях (start, Rule), (select, t, Rule, h, p), (hit, Rule, h, p), (miss, Rule, h, p), (mod, t, Rule). В состоянии start коммутатор прослушивает входящие каналы на предмет поступивших пакетов. В состоянии select коммутатор, получив на порт p пакет h, просматривает таблицу коммутации для принятия решения о перенаправлении пакета. В состоянии hit пакет засылается в канал, исходящий из порта p. В состоянии miss шаблон, состоящий из пакета h и порта p, на который он пришел, засылается в канал к контроллеру. Вообще говоря, коммутатор также должен посылать контроллеру свой идентификатор, однако в построенной формальной модели идентификатор может быть восстановлен по номеру порта, входящего в коммутатор. В состоянии mod происходит запись в таблицу коммутации правила, присланного контроллером. Во всех состояниях 40 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 38. 6 Владислав Подымов, Ульяна Попеско коммутатора Rule — текущая таблица коммутации, t — время нахождения в текущем управляющем состоянии, h и p — хранимые пакет и порт. Каналы могут могут находиться в состояниях (empty), (f ull, t, o) и (sent, o), где o — пакет для обычных и поточных каналов, шаблон для каналов к контроллеру либо правило для каналов от контроллера. Компонента t ∈ Real — время обработки сообщения каналом. Контроллер может находиться только в состояниях (idle) (ожидание запросов от коммутаторов) и (send, i, r) (послать i-му коммутатору новое правило r). Начальное состояние S0 системы строится из начальных состояний коммутаторов, контроллера и каналов. Начальное состояние i-го коммутатора — (start, Rulei ), контроллера — (idle), каналов — (empty). Работа ПКС характеризуется последовательностью состояний, начинающейся в S0 и строящейся по описанным далее правилам. Запись s → s означает, что следующее состояние может быть получено из предыдущего заменой компоненты s на s . Запись s1 , s2 → s1 , s2 означает то же самое для пары компонент. Построение вычисления ПКС происходит по следующим правилам. 1. Получение пакета: scom , sar = (start, Rule), (sent, h) → (select, 0, Rule, i i h, p), (empty). 2. Применение активного правила r = (p, h, x, p ): scom = (select, Rule, t, i imp h, p) → (hit, Rule, h, p ), если t ∈ [Limp , Ri ], r ∈ Rule. i 3. Обработка истекшего правила r = (p, h, x, p ): scom = (select, Rule, t, h, p) i imp → (miss, Rule , h, p), если t ∈ [Limp , Ri ], r ∈ Rule и Rule = Rule {r}. i 4. Сброс пакета: scom = (select, Rule, t, h, p) → (start, Rule), если t ∈ i imp [Limp , Ri ], |Rule| = tabi , все правила из Rule активны и ни одно из i них не имеет шаблона (p, h). 5. Несоответствие шаблонов: scom = (select, Rule, t, h, p) → (miss, Rule , i h, p), где Rule получается из Rule удалением всех истекших правил. 6. Начало перезаписи таблицы: scom , sf rom con = (start, Rule), (sent, rule) i i → (mod, 0, Rule), (sent, rule). 7. Успешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, (p, i i def h, x, p )) → (hit, Rule , h, p ), (empty), если t ∈ [Ldef , Ri ], |Rule| < tabi i и Rule = Rule ∪ {(p, h, x, p )}. 8. Неуспешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, i i def rule) → (start, Rule), (empty), если t ∈ [Ldef , Ri ] и |Rule| = tab. i com ch 9. Пересылка пакета коммутатору: si , sj = (hit, Rule, h, p), (empty) → (start, Rule), (f ull, 0, h), если канал cj исходит из порта p коммутатора i. 10. Пересылка шаблона контроллеру: scom , sto con = (miss, Rule, h, p), (empty) i i → (start, Rule), (f ull, 0, (p, h)). 11. Успешная обработка шаблона контроллером: scon , sto con = (idle), (sent, i (p, h)) → (send, i, r), (empty), если (i, (p, h, x, p )) ∈ con. 12. Неуспешная обработка шаблона контроллером: scon , sto con = (idle), (sent, i / (p, h)) → (idle), (empty), если (i, (p, h, x, p )) ∈ con. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 41
  • 39. Верификация ПКС при помощи системы UPPAAL 7 13. Пересылка правила от контроллера: scon , sf rom con = (send, i, r), (empty) i → (idle), (f ull, 0, r). 14. Появление пакета в сети: sar = (empty) → (f ull, 0, h), если h ∈ H. i 15. Сброс пакета в окружение: scom = (hit, Rule, h, p) → (start, Rule), если i ни один канал cj не исходит из порта p коммутатора comi . 16. Доставка в канале: (f ull, t, o) → (sent, o), если t ∈ [L, R] для характеристик L, R соответствующего канала. 17. Продвижение времени: таймеры всех коммутаторов и каналов увеличиваются на одну и ту же положительную величину d, времена жизни правил уменьшаются на эту же величину, и при этом: – если какой-либо канал находится в состоянии (f ull, t, o), то t + d ≤ R для характеристики R этого канала; imp – если scom = (select, Rule, t, h, p), то t + d ≤ Ri ; i def com – если si = (mod, Rule, t), то t + d ≤ Ri . 5 Алгоритм трансляции Алгоритм Alg переводит ПКС в эквивалентную ей сеть временных автоматов. Понятие эквивалентности обсуждается в следующем разделе. Сеть N , получаемая в результате трансляции ПКС ((com1 , . . . , comn ), con, (c1 , . . . , cm ), H), содержит автоматы Hurry, Env, Stream, Chan, Acon и Ai , i ∈ {1, . . . , n}. Каждый канал ci моделируется булевыми переменными f ull[ci ] (пакет послан), ready[ci ] (пакет доставлен), таймером t[ci ] и переменными для хранения объектов, пересылаемых через канал. Сброс пакетов в окружение моделируется с помощью особого канала cenv . Также в сеть добавляются все каналы car , cto con , cf rom con . i i i Автомат Hurry обеспечивает срочные дуги (т.е. дуги, выполняющиеся немедленно по выполнении их предусловий) и состоит из одной вершины и петли, принимающей сигнал по срочному каналу hurry. К срочным дугам по умолчанию добавляется посылка сигнала по каналу hurry. Автомат Env удаляет пакеты из канала cenv и состоит из одной вершины и срочной петли с записью в переменную f ull[cenv ] значения f alse. Автомат Stream генерирует пакеты, состоит из одной вершины и содержит набор срочных петель, недетерминированно засылающий пакеты в каналы car . i Автомат Chan обеспечивает доставку пакетов каналами, состоит из одной вершины и содержит петлю для каждого канала c, помеченную предусловием f ull[c] && !ready[c] && (t[c] ≥ L(c)) и записью в переменную ready[c] значения true, где L(c) — характеристика L канала c. Сама вершина автомата Chan при этом помечена инвариантом — конъюнкцией неравенств t[c] ≤ R(c). Автомат Acon имеет два обычных состояния — idle и send — и одно срочное состояние l. Срочная дуга idle → l записывает в локальные переменные автомата шаблон, присланный коммутатором, и номер этого коммутатора и в зависимости от наличия отправляемого обратно правила переходит либо 42 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 40. 8 Владислав Подымов, Ульяна Попеско обратно в idle, либо в send. Срочная дуга send → idle присваивает переменной f ull[c] значение true и записывает в переменную канала выбранное правило. Автомат Ai моделирует работу коммутатора comi и состоит из обычных состояний start, select, hit, miss, mod, соединенных через срочные вершины. Срочная дуга start → select записывает в локальные переменные автомата доставленный через канал c пакет и порт, на который он пришел, и записывает в переменную f ull[c] значение f alse. Состояние select, помеченное imp инвариантом t ≤ Ri , имеет одну исходяющую дугу в срочное состояние l, помеченную предусловием t ≥ Limp . Здесь t — локальный таймер комi мутатора. Из состояния l в зависимости от наличия шаблона происходит переход в состояния hit и miss с модификацией таблицы согласно правилам 2-5 семантики ПКС. Удаление многих правил из таблицы коммутации обеспечивается срочной вершиной l с петлей, удаляющей из таблицы истекшие правила, и исходящей дугой, помеченной предусловием, утверждающим, что из таблицы удалены все истекшие правила. Срочная дуга start → mod записывает в локальные переменные автомата правило, доставленное каналом def cf rom con . Состояние mod помечено инвариантом t ≤ Ri , исходящие из него i def дуги — предусловием r ≥ Li . В зависимости от того, заполнена ли таблица коммутации, из состояния mod автомат может либо перейти в состояние start, либо перейти в состояние hit с записью правила в таблицу. 6 Корректность алгоритма трансляции Под корректностью алгоритма Alg понимается равновыполнимость формул, используемых в средстве UPPAAL, для исходной ПКС N и результирующей сети Alg(N ). Ключевым понятием в доказательстве корректности алгоритма Alg является эквивалентность по прореживанию (stuttering equivalence) для систем переходов [6]. Неформально, такая эквивалентность означает, что если в каждом вычислении двух данных систем склеить все одинаковые состояния, то мы получим одинаковые множества вычислений. Одинаковыми полагаются состояния с совпадающими множествами выполнимых формул. В работе [7] сформулирована следующая теорема. Теорема 1 Если системы переходов M1 , M2 эквивалентны по прореживанию и формула Φ логики LT L−X истинна для M1 , то она также истинна для M2 . Следующая теорема позволяет применить только что сформулированную к системам переходов, описывающим поведение ПКС N и сети Alg(N ). Система переходов, описывающая поведение сети временных автоматов, обсуждается, например, в [4]. Пусть T SA — система переходов, описывающая поведение системы A. Теорема 2 Пусть N — произвольная ПКС. Тогда системы переходов T SN и T SAlg(N ) эквивалентны по прореживанию. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 43
  • 41. Верификация ПКС при помощи системы UPPAAL 9 Теорему обосновывают следующие рассуждения. Состояниям контроллера и коммутаторов ставятся в соответствие одноименные состояния получающихся из них автоматов вместе с необходимыми значениями локальных переменных. Состояниям каналов ставятся в соответствие наборы значений переменных f ull, ready и переменных для хранения данных. Одному применению семантических правил 1-17 соответствует последовательность переходов в сети временных автоматов через срочные состояния, и смена значений переменных происходит только в одном месте последовательности. В результате применения правила в ПКС и построенной по нему последовательности переходов в сети соответствующие состояния переводятся в соответствующие. Корректность алгоритма напрямую следует из приведенных теорем с учетом того, что формулы, проверяемые средством UPPAAL, могут быть переформулированы в терминах логики LT L−X . 7 Экспериментальное исследование В приложении приведена сеть автоматов, построенная транслятором по описанию сети на рисунке 1. Ниже приведены проверенные с помощью средства UPPAAL свойства и их запись на языке запросов UPPAAL [3]. 1. В работе системы не возникает блокировки: A[] not deadlock 2. В сеть всегда будут поступать пакеты из внешней среды: A <> f orall(num : int[0, 2]) (channel_h[stream.align[num]]) 3. Допустим сценарий работы сети, в котором коммутатор не принимает ни одного пакета: E[] com1.start 4. При любом сценарии работы сети контроллер обработает хотя бы один пакет: E <> !con.idle 5. Хотя бы один пакет будет успешно перенаправлен коммутатором (т.е. коммутатор выполняет свою главную функцию): E <> com1.hit Свойства 1,2,4,5 соответствуют спецификации сетей OpenFlow, в то время как свойство 3 является недопустимым. Проверка показала, что свойства 1,2,4,5 выполняются, а свойство 3 не выполняется. Это свидетельствует о том, что функционирование полученной сети временных автоматов соответствует нашим ожиданиям и что предложенная схема верификации ПКС 44 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 42. 10 Владислав Подымов, Ульяна Попеско с помощью средства UPPAAL позволяет проверять свойства поведения ПКС как системы реального времени. В ячейках таблицы 1 представлено время проверки описанных темпоральных свойств для некоторых моделей ПКС: 1 – три коммутатора в топологии кольца (рисунок 1); 2 – четыре коммутатора в топологии звезды; 3 – четыре коммутатора в произвольной топологии; 4 – два коммутатора с изначально пустыми таблицами коммутации. Проверка проводилась на вычислительном устройстве со следующими характеристиками: INTEL Core i7 3820/1600 МГц/2Гб DDR3. Первое свойство не было проверено на моделях 1–3 в связи с нехваткой памяти. Таблица 1. Время проверки свойств ПКС. Модель Модель Модель Модель 8 1 2 3 4 1 27 часов 1 1 1 1 2 секунда секунда секунда секунда 1 1 1 1 Свойство номер: 3 4 5 секунда 7 секунд 1 секунда секунда 1 минута 2 секунды 1 минута 25 секунд секунда 1 минута 1 минута 19 секунд секунда 1 секунда 1 секунда Заключение В результате проведенных исследований мы подтвердили практическую осуществимость подхода, предложенного в статье [5], для проверки выполнимости свойств поведения моделей программно-конфигурируемых сетей в реальном времени. Предложенное нами средство анализа поведения ПКС может быть использовано для наглядного описания конфигурации и коммутационной политики сети в виде диаграмм. Разработанный нами алгоритм трансляции преобразует диаграмму в сеть временных автоматов, подаваемую на вход системы верификации UPPAAL. Корректность алгоритма трансляции строго обоснована, транслятор реализован на языке программирования Perl. Получаемая на выходе транслятора сеть временных автоматов позволяет проверять спецификации ПКС с помощью системы UPPAAL. Особенностью такой верификации является возможность учитывать временной аспект поведения ПКС как распределённых систем реального времени. Список литературы 1. Casado M., Garfinkel T., Akella A., Fredman M., Boneh D., McKeown N., Shenker S. SANE: A Protection Architecture for Enterprise Networks // 15-th Usenix Security Symposium, Vancouver, Canada, August 2006. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 45
  • 43. Верификация ПКС при помощи системы UPPAAL 11 2. McKeown N., Anderson T., Balakrishnan H., Parulkar G., Peterson L., Rexford J., Shenker S., Turner J. Openflow: Enabling innovation in campus network // SIGCOMM Computer Communication Review, 2008, v.38, n.2, p.69-74. 3. Behrmann G., David A., Larsen K. A tutorial on Uppaal // Lecture Notes in Computer Science, 2004, v.3185, p.200-236. 4. Alur R., Dill D. Automata for modeling real-time systems // Proc. of Int. Colloquium on Algorithms, Languages, and Programming, LNCS, 1990, v.443, p.322-335. 5. Волканов Д.Ю., Захаров В.А., Зорин Д.А., Коннов И.В., Подымов В.В. Как разработать простое средство верификации систем реального времени // Моделирование и анализ информационных систем, 2012, Том 19, №6, с.45–56. 6. Browne M.C., Clarke E.M., Grumberg O. Characterizing finite Kripke structures in propositional temporal logics // Theor. Comp. Sci., 1988, v.59(1-2), p.115-131. 7. Clarke E.M., Grumberg O., Peled D. Model Checking. The MIT Press. 1999. Приложение Сеть временных автоматов, полученная в результате трансляции из ПКС, изображенной на рисунке 1, приведена на рисунках 2–4. В целях удобочитаемости выражения автоматов написаны в синтаксисе, отличном от синтаксиса UPPAAL и при этом более простом для восприятия. Запись вида (i = 1..3, 5, 7) означает перебор всех i из заданного диапазона и создание копий дуги для каждого значения i. Запись вида (i = 1..3 → Φ) означает “для всех i из заданного диапазона верна формула Φ”. Функция get(c) сохраняет содержимое канала c в локальные переменные (h, p, . . .) и выполняет присваивание c = f alse. Функция send(c, o) копирует o в содержимое канала и выполняет присваивания c = true, c_ready = f alse, c_t = 0. Функция set_rule(i) копирует локальные переменные коммутатора, отвечающие компонентам правила, в i-ю позицию таблицы. Предикат to_deliver(c) описывается как c && !c_ready && (c_t ≥ c_L). Предикат ok(c) описывается как !c || c_ready || (c_t ≤ c_R). Канал c[0] выделен под окружение, каналы c[1], c[2], c[3] — под потоки, прикрепленные к соответствующим коммутаторам. Автоматы A2 , A3 отличаются от автомата A1 только номерами задействованных каналов и константами, определяемыми количеством портов и объемом таблицы, и по этой причие опущены. 46 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 44. 12 Владислав Подымов, Ульяна Попеско (i = 0..2) hurry! idle to_con_ready[i] get(to_con[i]), c = i i = 0..2 -> !hit(rule[i], (c, p, h)) !con_in[c] hurry! send(from_con[c], rule[r]) (i = 0..2) hit(r[i], (c, p, h)) r=i s1 send (i = 1..3, num = 1..3) !c[num] hurry! send(c[num], i) Рис. 2. Автоматы Acon (слева), Stream (справа). from_con[0] hurry! get(from_con[0]), t=0 (i = 0..3) (t >= 2) && !active[i] set_rule(i) rewrite t <= 3 i = 1..3 -> active[i] !c[r] hurry! send(c[r], h) hit start t >= 3 (i = 1,4,5) select c_ready[i] t <= 5 hurry! get(c[i]), p = i, t = 0 (i = 0..3) hit(rule[i]) r=i rule_t[r] < rule_max[r] rule_t[r] >= rule_max[r] active[r] = false miss i = 0..3 -> !hit(rule[i]) i = 0..3 -> !active[i] || (rule_t[i] <= rule_max[i] ) (i = 0..3) active[i] && (rule_t[i] > rule_max[i]) active[i] = false i = 0..3 -> active[i] i = 0..3 !active[i] hurry! send(to_con[0], (p, h)) Рис. 3. Автомат A1 . s1 hurry? c[0] hurry! c[0] = false (i = 0..2) to_deliver(to_con[i]) to_con_ready[i]) s1 (i = 1..9) to_deliver(c[i]) c_ready[i] (i = 0..2 -> ok(to_con[i])) && (i = 1..9 -> ok(c[i])) Рис. 4. Автоматы Hurry (слева), Env (в центре), Chan (справа). Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 47
  • 45. ⋆ ⋆ 48 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 46. P S = (S, s0 , →, L) s0 ∈ S L : S → 2P S →⊆ S × S s0 π = s0 s1 s2 . . . ∀i≥0 si → si+1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 49
  • 47. pi ∈ P ϕ, ψ ::= true | p0 | p1 | . . . | pn | ¬ ϕ | ψ ∧ ϕ | Xϕ | ψ U ϕ | F ϕ | G ϕ. X F G ϕ U Gϕ Xϕ Fϕ ϕ ϕ ψU ϕ ϕ ψ F G F ϕ = true U ϕ G ϕ = ¬F ¬ϕ ∨ ϕ ϕ 50 ⇒ s0 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 48. V V (1) G X( V > V ⇒ OldValCond ∧ FiringCond ∧ V = NewValExpr ) V V V OldValCond FiringCond NewValExpr V V V X FiringCond OldValCond FiringCond V NewValExpr OldValCond V (1) ⇒ OldValCond i ∧ FiringCond i ∧ V = NewValExpr i V G X( V < V ⇒ OldValCond ′ ∧ FiringCond ′ ∧ V = NewValExpr ′ ) (1′ ) Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 51
  • 49. (1) (1′ ) V (2) G X( ¬ V ∧ V ⇒ FiringCond ) V (2′ ) G X( V ∧ ¬V ⇒ FiringCond ′ ) ′ (1) (1 ) V FiringCond = FiringCond ′ = 1 NewValExpr = NewValExpr ′ OldValCond = ( V < NewValExpr ) OldValCond ′ = ( V > NewValExpr ) G X( V > V ⇒ V < NewValExpr ∧ V = NewValExpr ) G X( V < V ⇒ V > NewValExpr ∧ V = NewValExpr ) (3) G X( V = NewValExpr ) (1) V (2) ′ (1 ) (2′ ) (3) V (3) NewValExpr V 52 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 50. (V ) = 1 V V+ (1) OldValCond OldValCond ′ V (1′ ) V− V := NewValExpr V := NewValExpr ′ FiringCond FiringCond ′ V+ V− V OldValCond i ∧ FiringCond i ∧ V = NewValExpr i V V V V + (2) V − (2′ ) V := 1 V := 0 FiringCond FiringCond ′ V+ V− V (3) V := NewValExpr V V V V := V Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 53
  • 51. V V V V =0 V =1 V (1) ∼ (1′ ) V + G( X(V > V ) ⇒ X(OldValCond ) ∧ X(FiringCond ) ∧ X(V = NewValExpr )) V − G( X(V < V ) ⇒ X(OldValCond ′ ) ∧ X(FiringCond ′ ) ∧ X(V = NewValExpr ′ )) X V 54 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 52. OldValCond OldValCond ′ FiringCond FiringCond ′ V ∼V V FiringCond FiringCond ′ (2′ ) (2) (3) V := V NewValExpr NewValExpr ′ V := 1 V := 0 V := V V V V := V := V := V NewValExpr NewValExpr X G( V = NewValExpr ) V = NewValExpr G( V = NewValExpr ) X G( V = NewValExpr ) V V := NewValExpr Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 55
  • 53. 56 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 54. Последний ход: Ход 0 0 4 4 4 4 4 Старт 1 2 3 4 5 Победа 4 6 Игрок ПЛК Игрок ПЛК Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 57
  • 55. Входы Кнопки Кнопка 1 PB1 ПЛК Выходы ход по цифре 1 1 выбрана цифра 1 1 ход по цифре 2 2 Кнопка 2 PB2 выбрана цифра 2 Кнопка 3 PB3 выбрана цифра 3 ход по цифре 3 2 3 ход по цифре 4 4 3 ход по цифре 5 5 Кнопка 4 PB4 выбрана цифра 4 ход по цифре 6 4 6 Лампы Лампа 1 Out1 Лампа 2 Out2 Лампа 3 Out3 Лампа 4 Out4 Лампа 5 Out5 Лампа 6 Out6 выбрана цифра 6 Старт PBStart Ход игрока Ход ПЛК Turn победил игрок выбрана цифра 5 Кнопка 6 PB6 право хода у игрока право хода у ПЛК Кнопка 5 PB5 Игрок ManWin ПЛК PLCWin начать игру заново 5 7 7 6 8 победил ПЛК 7 9 58 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 56. V1 V2 V3 V4 V5 V6 Sum Mv1 Mv2 Mv3 Mv4 Mv5 Mv6 Mv Lck Rst Skp G(¬PLCWin ∨ ¬ManWin) Sum G(Sum ≤ 37) G(Mv1 +Mv2 +Mv3 +Mv4 +Mv5 +Mv6 ≤ 1) PBStart G(PBStart ⇒ V1 = 4∧V2 = 4∧V3 = 4∧V4 = 4∧V5 = 4∧V6 = 4∧¬Mv ∧ ¬Turn ∧ ¬(P LCW in ∨ M anW in) ∧ Sum = 0) G(F(Mv )) ⇒ G(F(PLCWin ∨ManWin ∨PBStart )) PBStart G(F(Mv )) ∧ G(¬PBStart ∧X(PBStart ) ⇒ (PLCWin ∨ManWin)) ⇒ G(PBStart ∧X(¬PBStart ) ⇒ X(¬PBStart U (PLCWin ∨ ManWin))) Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 59
  • 57. G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒ G(Mv3 ∧ Sum = 3 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin)) G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒ G(Mv4 ∧ Sum = 4 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin)) G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒ G(Mv6 ∧ Sum = 6 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin)) G(X(Mv1 ∧ Sum = 1 ∨ Mv2 ∧ Sum = 2 ∨ Mv3 ∧ Sum = 3 ∨ Mv4 ∧ Sum = 4 ∨ Mv5 ∧ Sum = 5 ∨ Mv6 ∧ Sum = 6) ⇒ ¬Turn) 60 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 58. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 61
  • 59. 62 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 60. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 63
  • 61. 64 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 62. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 65
  • 63. На пути к технологии разработки средств дедуктивной верификации программ⋆ Игорь Ануреев Институт систем информатики имени А.П. Ершова anureev@iis.nsk.su Аннотация Статья представляет подход к разработке средств дедуктивной верификации программ. Основой подхода является предметно-ориентированный язык для данной предметной области. Сформулированы требования к такому языку и дано обоснование использования языка спецификации предметно-ориентированных систем переходов Atoment в качестве возможного кандидата. Особенности применения подхода и принципы, на которых он основан, проиллюстрированы на простых примерах. На базе подхода предполагается создать технологию разработки средств дедуктивной верификации программ. Ключевые слова: дедуктивная верификация программ, предметно-ориентированный язык, предметно-ориентированные системы переходов, операционная семантика, аксиоматическая семантика, денотационная семантика, логика безопасности, язык Atoment 1 Введение В статье предлагается предметно-ориентированный подход к разработке средств дедуктивной верификации программ (далее дедуктивных верификаторов). Термин «предметная ориентированность» применительно к подходу может иметь два значения. В первом случае, он означает ориентированность на предметную область, к которой применяется дедуктивная верификация. Во втором случае, он означает ориентированность на саму область разработки средств дедуктивной верификации программ. Мы рассматриваем предметную ориентированность во втором значении. Прежде чем описывать подход, определим необходимые термины этой предметной области и дадим классификацию существующих подходов к разработке средств дедуктивной верификации программ. Дедуктивный верификатор применяется к аннотированной программе на некотором целевом языке программирования. Аннотированная программа на этом языке — это текст, построенный по определенным правилам ⋆ 66 Работа частично поддержана грантом РФФИ 11-01-00028-а и междисциплинарным интеграционным проектом СО РАН № 3 «Принципы построения онтологии на основе концептуализаций средствами логических дескриптивных языков». Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 64. из конструкций целевого языка и аннотаций. Аннотации описывают свойства программы на целевом языке. Аннотированная программа называется корректной, если эти свойства выполняются. Обычно в качестве языка аннотаций используется некоторый логический язык. Задача дедуктивного верификатора — доказать корректность аннотированной программы или указать условия, при которых выполнение этой программы некорректно. Дедуктивный верификатор рассматривает аннотированную программу как формулу некоторого логического исчисления (называемого аксиоматической семантикой в контексте дедуктивной верификации) и преобразует ее в наборы формул некоторого логического языка в соответствии с определенной стратегией логического вывода в этом исчислении таким образом, что из истинности полученных в результате преобразования формул (называемых условиями корректности этой программы) следует корректность самой программы. Для доказательства условий корректности дедуктивный верификатор применяет разного рода средства автоматической поддержки доказательства (универсальные средства автоматического или интерактивного доказательства такие, как, например, PVS или HOL; SAT-решатели, SMT-решатели и др.). Применительно к задаче дедуктивной верификации будем называть эти средства решателями условий корректности. В качестве логического исчисления в дедуктивных верификаторах обычно используется логика Хоара или ее расширения. Инструменты, базирующиеся на логике отделимости (separation logic) и исчислении синонимов (alias calculus), также можно отнести к дедуктивным верификаторам в случае, если эти инструменты базируются на некотором виде аксиоматической семантики. Опишем, как выглядит процесс разработки дедуктивного верификатора. Сначала разрабатывается концепт дедуктивного верификатора. Его разработка включает выбор целевого языка, языка аннотаций, аксиоматической семантики, методов оптимизации условий корректности, решателя условий корректности и т. д. После того, как он разработан, можно выделить три подхода к его реализации. В первом подходе дедуктивный верификатор разрабатывается напрямую на некотором языке программирования общего назначения. Единственным достоинством этого подхода является большая степень свободы в оптимизации разрабатываемого верификатора. Эта степень ограничена только уровнем компетенций разработчика. Отметим недостатки подхода. Во-первых, при этом подходе высока сложность разработки, поскольку снижается уровень абстракции при переходе от концепта к реализации. Во-вторых, по той же причине, обоснование корректности верификатора представляет сложную проблему. В-третьих, верификатор не является гибким, поскольку ориентирован на конкретные целевой язык, язык аннотаций и аксиоматическую семантику. Во втором подходе аннотированная программа транслируется в программу на промежуточном языке, для которого уже имеются дедуктивные веМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 67
  • 65. рификаторы. Дополнительно к разработке транслятора из целевого языка в промежуточный язык, также разрабатываются средства обратной связи, которые интерпретируют результаты, полученные при верификации программы на промежуточном языке, в контексте исходной аннотированной программы. Как и в первом подходе, транслятор и средства обратной связи реализуются на некотором языке программирования общего назначения. Примерами промежуточных языков, ориентированных на дедуктивную верификацию, являются Boogie [1] и WhyML [2]. Этот подход имеет следующие преимущества. При его реализации знания конкретной аксиоматической семантики не требуется или требуется лишь в малой степени на уровне пользования дедуктивными верификаторами, имеющимися для промежуточного языка. Фактически разработка дедуктивного верификатора для целевого языка состоит в разработке транслятора и требует лишь знания операционной семантики целевого и промежуточного языков и (статической) семантики используемого языка аннотаций. Недостатки второго подхода проявляются прежде всего в случае, когда промежуточный язык сильно отличается от целевого языка. Во-первых, обоснование корректности трансляции становится сложной задачей. Во-вторых, усложняется разработка средств обратной связи. В-третьих, при трансляции теряется структурная и семантическая информация, которая могла бы оптимизировать генерацию условий корректности. Эта потеря, например, может быть результатом трансляции структур данных целевого языка в структуры данных промежуточного языка или результатом моделирования конструкций целевого языка конструкциями промежуточного языка. Помимо этого, разрабатываемый верификатор не является гибким, поскольку ориентирован на конкретные целевой язык, язык аннотаций и дедуктивные верификаторы, имеющиеся для промежуточного языка. Формат обратных связей, как правило, также не гибок. В третьем подходе аннотированная программа транслируется в модель или теорию системы машинной поддержки доказательства (далее доказателя). К доказателям, используемым в дедуктивном подходе, относятся PVS, HOL, LCF2 и др. Можно выделить следующие преимущества этого подхода. Во-первых, доказатели, как правило, основаны на логиках высшего порядка, что позволяет использовать выразительные языки аннотаций в дедуктивных верификаторах. Во-вторых, доказатели используют продвинутые техники доказательства для формул этих логик. В-третьих, эти техники можно применять не только к доказательству условий корректности, но и при порождении условий корректности, таким образом оптимизируя их вывод. Отметим недостатки третьего подхода. Во-первых, доказатели сложны в освоении. Во-вторых, разработка модели или теории также сложна. В-третьих, доказательство условий корректности ограничено конкретным доказателем, в который вкладываются аннотированные программы. В-четвертых, возникает непростая проблема доказательства соответствия модели аннотированной программе. В-пятых, модель аннотированной программы, как правило, не использует дополнительную информацию, доступ- 68 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 66. ную при компиляции этой программы, так как учитывание этой информации усложнило бы модель и сделала бы ее непригодной на практике. Предлагаемый нами подход нивелирует недостатки описанных подходов, сохраняя их преимущества, и может быть в дальнейшем развит в технологию разработки дедуктивных верификаторов. Он заключается в использовании предметно-ориентированного языка (далее ПОЯ) для разработки дедуктивных верификаторов. 2 Требования к предметно-ориентированному языку Опишем требования, которые должны выполняться для ПОЯ. Набор этих требований не претендует на полноту и скорее является квинтэссенцией опыта, накопленного авторами в области дедуктивной верификации. Требование 1. ПОЯ должен описывать объекты, которыми обычно оперирует дедуктивный верификатор. К ним относятся аннотированные программы, состояния программ, правила дедуктивного вывода (аксиоматической семантики) и стратегии их применения, условия корректности, интерфейсы к решателям условий корректности. Далее будем называть эти объекты объектами верификации. Требование 2. Форматы описания объектов верификации на ПОЯ должны быть унифицированными для каждого типа объектов, т. е. не зависеть от конкретных используемых в дедуктивном верификаторе языков программ, аннотаций, правил и стратегий дедуктивного вывода, условий корректности и решателей условий корректности. Тем самым, обеспечиваются перечисленные выше преимущества второго и третьего подходов, обусловленные трансляцией. Будем называть результаты трансляции объектов верификации в ПОЯ представлениями или образами этих объектов. Требование 3. Представления объектов верификации на ПОЯ должны быть структурно эквивалентными соответствующим им объектам. Структурная эквивалентность означает существование взаимно-однозначного отображения между объектами и их представлениями на уровне структуры объектов и, соответственно, структуры представлений. Тем самым нивелируются недостатки второго и третьего подходов, обусловленные трансляцией. Во-первых, упрощается разработка транслятора объектов конкретного языка в их представления на ПОЯ. Во-вторых, при такой трансляции не теряется информация. В-третьих, упрощается разработка средств обратной связи (перехода от представлений объектов к самим объектам). Требование 4. Для текстовых объектов верификации (объектов, являющихся текстами) представления объектов на ПОЯ должны быть текстуально близкими к соответствующим им объектам. Текстуальная близость означает, что представления объектов по возможности должны выглядеть похожими на сами объекты. В частности, они должны использовать такие же ключевые слова и размещать их в том же самом порядке. В этом случае достигается читабельность и понимание представлений объектов, сравнимые с читабельностью и пониманием самих текстовых объектов. Это требоМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 69
  • 67. вание конфликтует с требованием 2, поэтому должен быть найден разумный компромисс. Требование 5. Представления объектов верификации на ПОЯ должны быть концептуально близкими к соответствующим им объектам. Концептуальная близость означает, что представления используют ту же самую концептуальную структуру (понятия, атрибуты понятий, отношения между понятиями), что и объекты. Так семантические сущности, описывающие состояния программ на современных языках программирования, имеют сложную концептуальную структуру, которую важно точно отражать на уровне представлений соответствующих объектов. Требование 6. ПОЯ должен описывать средства оперирования с представлениями объектов, сооветствующие средствам, которые дедуктивный верификатор использует для оперирования объектами верификации. Их можно разделить на базовые и дополнительные. К базовым относятся средства, необходимые для выполнения дедуктивной верификации, к дополнительным — средства, которые оптимизируют этот процесс. Базовые средства включают средства взаимодействия с объектами через их представления и средства выполнения правил и стратегий дедуктивного вывода на представлениях объектов. Средства взаимодействия включают трансляторы аннотированных программ конкретных целевых языков в их представления на ПОЯ, средства построения обратных связей, средства взаимодействия с решателями условий корректности и т. д. Средства выполнения (интерпретации) правил и стратегий дедуктивного вывода, задаваемых в унифицированном формате на ПОЯ, позволяют реализовывать дедуктивные верификаторы, для которых эти правила и стратегии являются параметрами. Дополнительные средства оперируют с представлениями объектов, и могут, например, включать средства комбинации дедуктивных верификаторов, средства трансформации аннотированных программ, средства комбинирования решателей условий корректности и средства трансформации условий коректности. Средства трансформации представлений целевых программ позволят комбинировать операционный и аксиоматический подходы к верификации программ. Предварительное преобразование представления (операционный подход) может упростить последующий вывод условий корректности в аксиоматической семантике. В частности, трансформации могут собирать информацию о программе, которая обычно собирается алгоритмами статического анализа или на этапе ее компиляции. Эта информация может быть использована для оптимизации вывода условий корректности. Так как решатели условий корректности — узкое место современных дедуктивных верификаторов, средства трансформации условий корректности повышают возможности таких верификаторов. Эти средства позволяют делать предобработку условий корректности и передавать решателю упрощенные условия корректности. При использовании нескольких решателей, они могут также распределять фрагменты условий корректности наиболее подходящим для их доказательства решателям. Кроме того, такие средства 70 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 68. могут быть использовано непосредственно для реализации простых решателей. Требование 7. ПОЯ должен содержать развитый механизм сопоставления с образцом как на уровне синтаксической структуры (требования 3 и 4), так и на уровне концептуальной структуры (требование 5) представлений объектов. Сопоставление такого рода характерны для большинства средств оперирования представлениями объектов, перечисленных в требовании 6. Требование 8. ПОЯ должен обеспечивать средства описания смысла конструкций целевого языка (операционной семантики целевого языка). Это требование необходимо для формального обоснования корректности разрабатываемого дедуктивного верификатора. 3 Использование языка Atoment в качестве ПОЯ Язык Atoment [3] — результат наших исследований по автоматизации создания операционной и аксиоматической семантик языков программирования. В процессе его разработки возникла концепция предметно-ориентированного подхода к дедуктивной верификации и были сформулированы требования к ПОЯ для этой предметной области. Он не является идеальным кандидатом на роль ПОЯ, но обеспечивает компромиссные показатели по всем требованиям к ПОЯ и при отсутствии на данный момент других подходящих языков мы планируем использовать его для апробации этого подхода. Язык Atoment обеспечивает описание объектов верификации (требование 1). Он использует два унифицированных формата для представлений объектов (требование 2), соответствующих текстовых и нетекстовым объектам. Текстовые объекты представляются выражениями языка Atoment. Выражения — это унифицированная форма записи конструкций языка Atoment, подобная спискам языка Лисп. Выражения строятся из атомов с помощью специальных символов, к которым относятся пробельные символы и круглые скобки. Например, ab и (ab (cd ef) gh) — выражения. Атомом может быть любая последовательность Unicode символов, не содержащая специальных символов и символа кавычек ("). Специальный вид атомов — строки позволяют использовать в атоме специальные символы. Например, ab и "ab ("ss)" — атомы. Требование 3 для текстовых объектов обеспечивается взаимно-однозначным соответствием между их структурой и структурой выражений, представляющих эти объекты. Рассмотрим, как обеспечивается выполнение требования 4 для текстовых объектов на примере представления конструкций целевого языка и языка условий корректности. Ключевые слова целевого языка представляются атомами. Для условного оператора if A then B else C ключевые слова представляются атомами if, then и else. Сам оператор представляется выражением (if A′ then B′ else C′ ), где A′ , B′ , C′ — представления конструкций A, B, C целевого языка. Условия корректности, как и любые другие формулы, также представляются выражениями. Так наиболее близким представлением формулы Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 71
  • 69. ∀x((a ≤ x) ∧ (y ≤ b)) является выражение (∀ x ((a ≤ x) ∧ (y ≤ b))). Обычно для удобства ввода вместо этого выражения используется выражение (forall x ((a <= x) and (x <= b))). Нетекстовые объекты представляются конечными наборами символов языка Atoment, а их (как правило, концептуальная) структура — состояниями в языке Atoment. Символы в языке Atoment — это выражения вида (A), где A — последовательность атомов. Состояние в языке Atoment — это отображение, которое сопоставляет символам их интерпретацию (значение). Значением символа в состоянии являются функции заданной местности, сопоставляющие кортежу элементов элемент (Подобно тому, как атом является наименьшей синтаксической единицей языка Atoment, элемент является его наименьшей семантической единицей. Название Atoment является объединением двух слов — атом и элемент.). Местность этих функций совпадает с числом спецификаторов аргументов, входящих в символ. Спецификатор аргумента — это атом одного из видов +v или -v. Символы позволяют адекватно описывать концептуальную структуру (требование 5) семантических сущностей целевого языка. Например, переменная может быть представлена символами (-v is variable), (value of -v) и (type of -v). При таком представлении s(-v is variable)(x) = true, s(type of -v)(x) = int и s(value of -v)(x) = 2 означает, что переменная с именем x имеет тип int и значение 2 в состоянии s. Средства оперирования с представлениями объектов (требование 6), механизм сопоставления с образцом (требование 7) и средства описания операционной семантики целевого языка (требование 8) реализуются с помощью предметно-ориентированных правил перехода и контекстов их применения. Правило перехода — это выражение вида (if A var B P then C), где A, B, C — последовательности выражений, называемые образцом, спецификацией переменных образца и телом правила, соответственно, необязательная последовательность выражений P обозначает дополнительные параметры правила. Правила перехода суть средства трансформации конфигураций. Конфигурация на языке Atoment — это пара, состоящая из последовательности выражений (далее программы на языке Atoment) и состояния. Правило (if A var B P then C) применимо к конфигурации (D, s), если D имеет вид E A′ F и A′ удовлетворяет образцу A, т. е. получается из A заменой переменных образца из B на некоторые выражения или последовательности выражений (значения переменных образца). Результатом применения правила будет конфигурация (E C′ F, s′ ), где C′ — результат замены в C переменных образца их значениями. Контекст применения определяет, как получается s′ , может дополнительно модифицировать C′ и накладывать дополнительные условие на применимость правила. Контекст определяется видом правил перехода (операционные, дедуктивные, условные, онтологические и т. д.). Так средства выполнения (интерпретации) правил и стратегий дедуктивного вывода применительно к некоторой аннотированной программе описываются дедуктивными правилами перехода, а операционная семантика целевых языков — операционными правилами перехода. Рассмотрим пример применения правила. Операционное правило 72 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 70. (if (jump E) (break) var (+s E) then (jump E)) применимо к программе (jump goto L) (break) (x := 3) и преобразует ее в программу (jump goto L) (x := 3). Состояние при этом не меняется. Спецификатор +s перед переменной образца E, означает, что ее значением может быть (возможно пустая) последовательность выражений. Если бы его не было, значением E могло бы быть только выражение. Предметно-ориентированные системы переходов определяют операционную семантику выражений. Операционная семантика выражения U определяется множеством правил, образец которых включает выражение U′ такое, что U получается из U′ означиванием переменных образца. Таким образом, операционная семантика выражения определяется в контексте окружающих его выражений в программе на языке Atoment. Например, операционная семантика выражения (break) из примера выше определяется в контексте, когда этому выражению предшествует выражение (jump E′ ), где E′ — произвольная последовательность выражений. Комбинирование дедуктивных верификаторов и решателей условий корректности осуществляется за счет предопределенных выражений языка Atoment, описывающих основные структуры управления (последовательное выполнение, разбор случаев, бэктрекинг и др.). Операционная семантика предопределенных выражений задается напрямую, а не определяется правилами перехода. Для спецификации семантики формул (например, условий корректности) используется денотационная семантика выражений. Денотационная семантика выражений — это отображение, которое сопоставляет выражениям их значения, принадлежащие множеству элементов языка Atoment (денотату). Значением атома является сам атом. Значение выражения, отличного от атома, определяется семантикой символа, который является шаблоном для этого выражения. Так символ (+v + +v), интерпретируемый как операция сложения чисел, является шаблоном для выражения (2 + (3 + 4)) относительно сопоставленных аргументам выражений 2 и (3 + 4). Спецификатор аргумента +v означает, что в качестве значения аргумента берется значение сопоставленного выражения. Таким образом, значением выражения (2 + (3 + 4)) будет 9. Спецификатор аргумента -v означает, что в качестве значения аргумента берется само выражение. Этот спецификатор используется, например, в символе (forall -v -v), интерпретируемом как квантор всеобщности. 4 Применение предметно-ориентированного подхода Рассмотрим применение предметно-ориентированного подхода на примере разработки дедуктивного верификатора для целевого языка, включающего простые типовые конструкции языков программирования. Из-за недостатка места мы ограничимся только вопросами разработки операционной семантики и логики безопасности (варианта аксиоматической семантики) для этих конструкций. Несмотря на свою простоту, пример иллюстрирует несколько Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 73
  • 71. ключевых особенностей, лежащих в его основе: инкрементальность разработки, использование вспомогательных конструкций, гибкость разработки, разрешение на месте побочных эффектов при дедуктивном выводе. Будем разрабатывать верификатор сразу для выражений, представляющих конструкции целевого языка, считая, что требования структурной эквивалентности и текстуальной и концептуальной близости удовлетворены. Рассмотрим оператор блока ({ A }), где A — последовательность операторов. Заметим, что такое представление близко к представлению этого оператора на ряде императивных языков программирования. Опишем сначала его операционную семантику. Первую версию семантики зададим правилом (if ({ A }) var (+s A) then A) В соответствии с этой семантикой выполнение оператора ({ A }) сводится к выполнению последовательности операторов A. Предположим теперь, что целевой язык содержит средства передачи управления (операторы посылки исключений, операторы break, continue, return и т. п.). В этом случае, такая семантика уже не подходит, поскольку оператор блока не должен выполняться, если перед ним произошла передача управления. Для описания этой ситуации введем понятие выражения перехода и концепцию просачивания выражения переходов. Выражение перехода имеет вид (jump E), где E — последовательность выражений, которые кодируют информацию о том, какой оператор перехода сработал, и какую информацию он передал. Например, для оператора (break) соответствующее выражение перехода может иметь вид (jump break). Зададим вторую версию семантики блока правилами (if ({ A }) var (+s A) then A) (if (jump E) ({ A }) var (+s E) (+s A) then A) Дополнительное второе правило обеспечивает просачивание выражения перехода через оператор блока. Последовательность выражений E хранит информацию, которая передается при переходе. Таким образом, мы фактически «программируем» операционную семантику конструкций целевого языка на специализированном языке высокого уровня, уточняя ее на каждом шаге итерации. Как будет показано ниже, аналогичным образом «программируются» правила и стратегии дедуктивного вывода. В этом заключается инкрементальность разработки верификатора. Эта версия, однако, не учитывает ситуацию, когда целевой язык включает операторы перехода по метке (goto L) и пустые помеченные операторы (label L), оператор (label L) входит в A и в результате выполнения блока порождается выражение перехода (jump goto L). В этом случае, выполнение должно быть продолжено с оператора (label L) последовательности A, а в соответствии с текущей семантикой блока выражение перехода (jump goto L) будет просачиваться дальше за блок. Третья версия семантики блока определяется правилами (if ({ A }) var (+s A) then A (gotoStop A)) (if (jump E) ({ A }) var (+s E) (+s A) then A) 74 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 72. Вспомогательное выражение (gotoStop A) обрабатывает выражение перехода (jump goto L) в случае, когда оператор (label L) принадлежит A: (if (gotoStop A) var A then) (if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E) (if (jump goto L) var L then (matchCases (A) (if (B (label L) C) var (+s B) (+s C) then C (gotoStop A)) (else (jump E)))) (else (jump E)))) Предопределенное выражение matchCases выполняет разбор случаев в соответствии с образцом. Сначала оно формирует сопоставляемое выражение. В правиле выше это выражения (jump E) и (A) для первого и второго вхождения matchCases, соответственно. Затем для каждой ветви (if U var V then W) оно выполняет сопоставление сформированного выражения с образцом U для спецификации переменных образца V таким же образом, как для правила перехода. Первая подходящая ветвь выполняется таким же образом, как правило перехода. Если ни одна из ветвей не подошла, и matchCases содержит выражение (else W), то выполняется последовательность W. В противном случае, с помощью механизма бектрекинга выполняется откат к предыдущей точке ветвления. Эта версия операционной семантики для оператора блока иллюстрирует использование вспомогательных конструкций. Чтобы адаптировать правила операционной семантики, мы не меняем их, а добавляем вспомогательную конструкцию, которая специфицирует требуемую адаптацию, и для нее описываем операционную семантику. Соответствующие вспомогательные конструкции используются и при описании аксиоматической семантики. Рассмотрим теперь, как с помощью правил перехода описываются правила и стратегии дедуктивного вывода. Особенностью нашего подхода является то, что вместо логики Хоара используется ее расширение — логика безопасности, предложенная в [4]. В логике Хоара ключевыми понятиями являются точки входа и выхода, которым соответствуют пред- и пост-условия. В ряде расширений логики Хоара допускается несколько точек входа и выхода. В логике безопасности точек входа и выхода нет, и, соответственно, нет предусловия и постусловия. Вместо этого ряд точек программы снабжаются так называемыми условиями безопасности. Программа корректна в логике безопасности (безопасна), если при любом исполнении программы, если достигнута точка программы с условием безопасности, то это условие должно быть истинно. Таким образом, логику безопасности можно применять к программам без явных точек входа или выхода, например операционным системам или телекоммуникационным протоколам. Важное свойство нашего подхода, являющееся одним из его преимуществ, заключается в том, что для многих конструкций целевого языка правила логики безопасности структурно не отличаются от правил операционной семантики. Таким образом, разработав операционную семантику Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 75
  • 73. целевого языка, мы автоматически получаем большую часть правил логики безопасности этого языка. Также в силу идентичности правил логики безопасности и операционной семантики доказательство корректности правил логики безопасности становится более простой задачей. Рассмотрим правила логики безопасности для блока, соответствующие последней третьей версии операционной семантики: (if ({ A }) var (+s A) then A (gotoStop A)) (if (jump E) ({ A }) var (+s E) (+s A) then A) Таким образом, правила логики безопасности и операционной семантики для блока совпадают. Однако логика безопасности для вспомогательного выражения (gotoStop A) меняется, поскольку в ней используется, как и в логике Хоара, инвариант метки: (if (gotoStop A) var A then) (if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E) (if (jump goto L) var L then (matchCases (A) (if (B (label L inv I) C) var (+s B) (+s C) I then (assert I)) (else (jump E)))) (else (jump E)))) Выражение I в помеченном операторе (label L inv I) соответствует инварианту метки L, т. е. I — условие безопасности, которое должно быть истинным при любом достижении этого оператора. Предопределенное выражение (assert I) добавляет условие безопасности I в соответствующую точку. Побочные эффекты затрудняют применение логики Хоара. Например, чтобы применить классическое правило логики Хоара к условному оператору (if A then B else C), требуется, чтобы условие A не имело побочных эффектов (не меняло состояние программы). В нашем подходе такой проблемы не возникает и условие A может иметь побочные эффекты, поскольку побочные эффекты не только в операционной семантике, но и в логике безопасности, разрешаются на месте. Правила операционной семантики для условного оператора имеют вид: (if (if A then B else C) var A (+s B) (+s C) then A (cases (if ((val) = true) then B) (else C))) (if (jump E) (if A) var (+s E) (+s A) then (jump E)) Предопределенное выражение cases выполняет разбор случаев. Выполняется первая ветвь (if U then V), для которой значение (денотационная семантика) выражения U равна true. Выполнение ветви заключается в выполнении последовательности выражений V. Если ни одна из ветвей не выполняется и cases содержит выражение (else W), то выполняется последовательность W. В противном случае, с помощью механизма бектрекинга выполняется выполняется откат к предыдущей точке ветвления. 76 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 74. Как видно из первого правила, сначала вычисляется выражение A. Если при его вычислении происходят побочные эффекты, то они описываются правилами для соответствующих подвыражений выражения A. Результат вычисления выражения A сохраняется в нульместном символе (val). Затем выполняется сравнение значения этого символа с true или false. Второе правило просачивает выражение перехода через условный оператор. Правила логики безопасности для условного оператора совпадают с правилами операционной семантики. Однако операционная семантика ряда предопределенных выражений, например cases, отличается для контекстов применения, соответствующих операционным и дедуктивным правилам перехода [3]. 5 Заключение В заключение, ответим на вопрос, зачем разрабатывать универсальный поход к созданию верификаторов, когда существующие дедуктивные верификаторы для конкретных языков программирования нуждаются в существенном улучшении. Во-первых, предлагаемый подход является предметноориентированным, что означает, что он предоставляет средства, позволяющие в полной мере учитывать особенности целевых языков программирования и используемых методов и техник дедуктивной верификации. Вовторых, технология быстрой предметно-ориентированной разработки дедуктивных верификаторов может оказаться востребованной, когда для целевого языка не существует средств дедуктивной верификации. В-третьих, существующие дедуктивные верификаторы представляют собой черные ящики, что не позволяет, например, улучшить реализованную аксиоматическую семантику или стратегию ее применения или скомбинировать операционный, аксиоматический и дедуктивный подходы при генерации условий корректности. В-четвертых, подход может быть применен для апробации новых методов дедуктивной верификации специалистами в этой области. В-пятых, применение подхода к специально разработанным учебным языкам программирования позволяет использовать его в сфере образования. Список литературы 1. Barnett M., Chang B.-Y.E., DeLine R., Jacobs B., Leino K.R.M. Boogie: A modular reusable verifier for object-oriented programs // Proc. of Conf. "Formal Methods for Components and Objects Springer-Verlaf, Berlin, LNCS. 2006. Vol. 4111. P. 364–387. 2. Filliˆtre J.-C., Paskevich A. Why3 – where programs meet provers // Proc. of the a 22nd European Symposium on Programming, Springer-Verlaf, Berlin, LNCS. 2013. Vol. 7792. P. 125–128. 3. Ануреев И.C. Предметно-ориентированные системы переходов: объектная модель и язык // Системная информатика. 2013. № 1. С. 1–34. 4. Ануреев И.С. Дедуктивная верификация телекоммуникационных систем, представленных на языке Си // Моделирование и анализ информационных систем. 2012. Т. 19. № 6. С. 34–44. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 77
  • 75. Верификация распределенных автоматных программ с использованием инструментального средства Spin М. А. Лукин, А. А. Шалыто СПб НИУ ИТМО lukinma@gmail.com, anatoly.shalyto@gmail.com Аннотация. В данной статье рассмотрен комплексный подход к разработке и верификации распределенных автоматных программ, в которых иерархические автоматы могут реализовываться в разных потоках и взаимодействовать друг с другом. Предложен интерактивный подход к верификации распределенных автоматных программ при помощи инструмента Spin, который включает в себя автоматическое построение модели на языке Promela, приведение LTL-формулы в формат, определяемый инструментом Spin и построение контрпримера в терминах автоматов. На основе этого подхода создано инструментальное средство Stater, позволяющее создавать распределенную систему конечных автоматов, генерировать на ее основе программный код на целевых языках программирования и верифицировать ее при помощи верификатора Spin. Автоматы могут быть созданы в инструменте Stater, а также импортированы из Stateflow. Ключевые слова: верификация, системы конечных автоматов, model checking, распределенные автоматные программы, Spin, LTL. 1 Введение Формальные методы набирают все большую популярность при проверке программного обеспечения. При этом они не конкурируют с традиционным тестированием, а гармонично дополняют его. В данной работе рассматривается верификация методом проверки моделей (model checking) [1 – 3] при помощи верификатора Spin [4]. Метод проверки моделей характеризуется высокой степенью автоматизации [1]. По данной теме проводятся исследования в России и за рубежом [5 – 30]. Настоящая работа является продолжением работ [16, 22, 26]. 78 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 76. М. А. Лукин, А. А. Шалыто 2 2 Описание метода 2.1 Описание автоматной модели В методе используется распределенная система взаимодействующих иерархических конечных автоматов [31 – 33]. При этом каждый иерархический автомат в системе работает в отдельном потоке. Под иерархическим автоматом в данной работе понимается система вложенных автоматов. При этом каждый граф переходов задает не конкретный автомат, а тип автоматов (по аналогии с типом данных или классом в ООП). Назовем его автоматным типом. У каждого автоматного типа может быть несколько экземпляров (по аналогии с объектом в ООП). Назовем эти объекты автоматными объектами. Каждый автоматный объект имеет уникальное имя. В дальнейшем, если не указано иное, автоматные объекты будут называться просто автоматами. Переходы автоматов осуществляются по событиям. Также на переходе могут быть охранные условия [34]. Однако что делать, если встретилось событие, по которому нет перехода? Традиционно в теории языков и вычислений детерминированный конечный автомат в таком случае переходит в недопускающее состояние. Но такое поведение не всегда удобно. Альтернативой переходу в недопускающее состояние может быть игнорирование таких событий, которое реализуется как неявное добавление пустых (без выходных воздействий) петель по всем событиям, переходы по которым не были добавлены пользователем. Таким образом, в предлагаемом методе автомат может работать в одном из двух режимов: ─ при появлении события, по которому нет перехода, это событие игнорируется (добавляются пустые петли по всем событиям); ─ при появлении события, по которому нет перехода, автомат переходит в недопускающее состояние. Есть специальное событие «*», которое означает переход по любому событию, кроме тех, которые есть на других переходах из этого состояния (аналог default в блоках switch для C-подобных языков или else в условных конструкциях). Автомат может иметь конечное число переменных целочисленных типов (включая массивы). Для переменных есть следующие модификаторы: ─ volatile – переменная может быть использована в любом месте программы; ─ external – переменная может быть использована другим автоматом; ─ param – переменная является параметром автомата. По умолчанию считается, что переменная не используется нигде, кроме как на диаграмме переходов автомата. Все события общие для всей системы автоматов. Выходные воздействия автомата бывают двух типов: Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 79
  • 77. Верификация распределенных автоматных программ с использованием инструментального средства Spin 3 1. На переходах и в состояниях может быть выполнен любой код. Однако верификатор и генератор кода перенесут его без изменений, поэтому код должен быть допустимым в целевом языке. 2. Запуск на переходах и в состояниях функций, определяемых пользователем на целевом языке программирования (после того, как сгенерирован код). Автомат может иметь вложенные автоматы любого типа, кроме собственного, иначе будет бесконечная рекурсия. Циклическая рекурсия также запрещена. Автомат может запускать поток с новым автоматом любого типа. Задается тип автомата <StateMachine> и имя <concreteStateMachine>. Нельзя запускать несколько автоматов с одним именем. Нельзя запускать автоматы своего типа. Автомат может взаимодействовать с другим автоматом, выступая источником событий для него. Сообщения с событиями отправляются асинхронно. Автомат может использовать отмеченные специальным модификатором переменные другого автомата. Таким образом, в системе могут быть несколько автоматов с одинаковым графом переходов, более того, часть этих автоматов могут быть вложенными, а часть нет. Все запреты проверяются при помощи верификации. 2.2 Описание процесса верификации Для того чтобы провести верификацию программы методом проверки моделей, требуется составить модель программы и формализовать требуемые свойства (спецификацию) на языке темпоральной логики [1]. Так как в данной работе используется верификатор Spin, то языком темпоральной логики является LTL [1]. При этом модель автоматной программы строится автоматически и построение модели описано в разделе «Генерация кода на Promela». Обозначим автоматный тип через AType, автоматный объект через aObject. Пусть состояния AType называются s0, s1 и т. д., в автомат поступают события e0, e1 и т. д., а переменные называются x0, x1 и т. д., внешние воздействия второго типа z0, z1 и т. д. Пусть автоматный тип AType имеет вложенный автомат, назовем его nested. Пусть AType запускает автомат, назовем его fork. Процесс верификации состоит из следующих этапов: 1. Генерация кода на языке Promela [4]. В нашем случае она происходит автоматически. 2. Преобразование LTL-формул (переход от нотации автоматной программы в нотацию Spin). 3. Запуск верификатора Spin. 4. Преобразование контрпримера в термины исходной системы автоматов. В нашем случае преобразование происходит автоматически. 80 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 78. 4 М. А. Лукин, А. А. Шалыто Этапы процесса верификации будут описаны ниже. Эти этапы похожи на этапы ручной верификации при помощи Spin. Основным отличием является их максимальная автоматизированность и большая приближенность модели к реализации, чем при верификации неавтоматных программ. Интерактивность Одна из главных проблем в верификации методом проверки моделей – это размер модели Крипке. Для того чтобы уменьшить модель (отсечь лишние подробности), мы будем ее строить интерактивно. Для обеспечения интерактивности вводится возможность выбирать, какие уровни абстракции автоматной системы входят в модель, а какие нет. Кроме того, модель структурируется понятным для человека образом для того, чтобы пользователь мог самостоятельно модифицировать построенную модель. Переменные Для переменных введем следующие уровни абстракции: 1. Переменные в модели не учитываются. 2. Переменные в модель включены, но модель абстрагируется от их значения. Недетерминированно выбирается, какое охранное условие будет верно. 3. Модель вычисляет значения переменных. При этом переменные могут быть следующих видов: a. Локальные. Эти переменные могут быть изменены только самим конечным автоматом. Все изменения таких переменных находятся только в выходных воздействиях автомата. b. Параметры. Извне изменяются только один раз, при запуске автомата. В остальном они подобны локальным. c. Публичные. Такие переменные могут быть изменены извне автоматной системы. В модели перед каждым переходом автомата таким переменным недетерминированно присваивается произвольное значение. d. Совместно используемые. К таким переменным данного автомата имеют доступ другие автоматы, параллельно работающие с данным. Параметры и публичные переменные могут быть также одновременно и совместно используемыми. Параллелизм Вводятся два уровня: параллелизм включен либо выключен. Если нет, то в модель не вводятся взаимодействия параллельных автоматов. Остаются только взаимодействия по вложенности. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 81
  • 79. Верификация распределенных автоматных программ с использованием инструментального средства Spin 5 Источники событий В качестве источников событий для автоматов в системе могут выступать внешняя среда и другие автоматы. Внешняя среда как источник событий для каждого автомата может работать в одном из трех режимов: ─ внешняя среда не взаимодействует с автоматом (события от внешней среды не приходят); ─ внешняя среда отправляет только те события, которые автомат может в данный момент обработать; ─ внешняя среда отправляет любые события. Другие автоматы как источники событий можно отключить, если отключить параллелизм. Процесс верификации Интерактивность процесса верификации основывается на возможностях верификатора Spin и описана в разделе «Запуск верификатора Spin». Генерация кода на языке Promela Все состояния каждого автоматного типа перенумеровываются и для них создаются константы. Для каждого автоматного типа состояния нумеруются отдельно. Имя константы состоит из имени автоматного типа и имени состояния, разделенных знаком подчеркивания. Это сделано для того, чтобы состояния разных автоматов с одинаковыми именами не конфликтовали друг с другом. Пример: #define AType_s0 0 #define AType_s1 1 Все события перенумеровываются и для них создаются константы. Для событий применяется сквозная нумерация. Пример: #define e0 1 #define e1 1 Все внешние воздействия второго типа (вызываемые функции) перенумеровываются и для них создаются константы аналогично состояниям. Все вызовы вложенных и запуски параллельных автоматов перенумеровываются аналогично состояниям. Для каждого типа автоматов создается структура. Элементы структуры: ─ ─ ─ ─ byte state – номер текущего состояния; byte curEvent – номер последнего пришедшего события; byte ID – номер автомата; byte functionCall – номер последней запущенной функции, если такая есть; ─ byte nestedMachine – номер активного вложенного автомата, если такой есть; ─ byte forkMachine – номер запущенного автомата, если такой есть; 82 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 80. 6 М. А. Лукин, А. А. Шалыто ─ Все переменные автомата. Каждый тип автоматов записывается в inline-функцию переходов, которая моделирует один шаг автомата. Переходы записываются при помощи охранных команд Дейкстры [34]. Эта функция в качестве параметров принимает структуру с данными автомата и событие и имеет следующий вид (листинг 1): Листинг 1. Функция переходов. inline Mnemo(machine, evt) { atomic { printf("machine%d. event_happened: %d n", evt); machine.curevent = evt; } if //Определение текущего состояния. ::(machine.state == AType_s0) -> printf("machine%d.state = AType.state0 n", machine.ID); if //Выбор перехода. ::((evt == e1) && cond_1) -> machine.state = AType_s1; //Действия внутри состояния. ::((evt == e2) && cond_2) -> machine.state = AType_s2; //Действия внутри состояния. //Остальные переходы. :: else -> //Действия в случае, если не найден переход //по событию evt. fi; //Остальные состояния. fi; } Функция состоит из двух условий: внешнего и внутреннего. Внешнее условие определяет состояние, в котором находится автомат. Внутренне условие определяет переход в следующее состояние. Каждый вариант внутреннего условия соответствует одному из переходов из текущего состояния автомата и состоит из двух частей: проверка события и проверка условия на переходе. Условия на переходах в листинге 1 обозначены как cond_1, cond_2 и т. д. Для каждого экземпляра автомата создается экземпляр структуры и канал, по которому происходит передача событий. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 83
  • 81. Верификация распределенных автоматных программ с использованием инструментального средства Spin 7 Для каждого экземпляра автомата, кроме вложенных, создается процесс, который извлекает из канала событие и запускает функцию переходов автомата с этим событием. Для каждого экземпляра автомата, кроме вложенных, создается процесс, который недетерминированно выбирает событие и отправляет его в канал автомата. Этот процесс эмулирует внешнюю среду. В зависимости от уровня абстракции по источникам событий этот процесс выбирает событие из всего списка событий (внешняя среда отправляет любые события), из списка переходов текущего автомата (внешняя среда отправляет только те события, которые автомат может в данный момент обработать) либо не активен и удален из модели (внешняя среда не взаимодействует с автоматом). Для публичных переменных перед каждым шагом автомата вызывается специальная функция, которая эти переменные недетерминированно изменяет. Для переменных-параметров такая функция вызывается один раз – при запуске автомата. Если по данному событию нет перехода, и в текущем состоянии есть вложенный автомат, то запускается вложенный автомат (запускается встраиваемая функция автомата). Если в текущем состоянии автомат запускает другой автомат, то запускается заранее созданный процесс запускаемого автомата, а также . Если автомат отправляет сообщение с событием другому автомату, то он записывает номер события в канал этого автомата. Преобразование LTL-формул Расширим нотацию LTL-формул верификатора Spin. В фигурных скобках будем записывать высказывания в терминах рассматриваемой автоматной модели. Добавим следующие высказывания: 1. aObject.si, которое означает, что автомат aObject перешел в состояние si. 2. aObject.ei, которое означает, что в автомат aObject пришло событие ei. 3. aObject.zi, которое означает, что автомат aObject вызвал функцию (внешнее воздействие) zi. 4. aObject->nested, которое означает, что в автомате aObject управление передано вложенному автомату nested. 5. aObject || fork, которое означает, что автомат aObject запустил автомат fork. 6. Бинарные логические операции с переменными автоматов, например, aObject.x0 >= fork.x0[fork.x1]. Пример LTL-формулы в расширенной нотации: [] ({aObject.x0 <= 5} U {aObject.s1}) (1) Алгоритм преобразования формулы в нотацию Spin следующий: 1. Все высказывания в фигурных скобках перенумеровываются. 84 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 82. 8 М. А. Лукин, А. А. Шалыто 2. Каждое такое высказывание преобразовывается в терминах модели на Promela и записывается в макрос. 3. Макросы подставляются в исходную LTL-формулу. Макросы записываются следующим образом: 1. Автомат aObject перешел в состояние si: (aObject.state == si). 2. В автомат aObject пришло событие ei: (aObject. curEvent == ei). 3. Автомат aObject вызвал функцию (внешнее воздействие) zi: (aObject. functionCall == zi). 4. В автомате aObject управление передано вложенному автомату nested: (aObject. nestedMachine == nested). 5. Автомат aObject запустил автомат fork: (aObject. forkMachine == fork). Формула (1) будет преобразована алгоритмом в следующий вид: #define p0 (aObject.x0 <= 5) #define p1 (aObject.state == AType_s1) ltl f0 {[] (p0 U p1) }} Spin поддерживает несколько LTL-формул в одной модели, поэтому формулы нумеруются f0, f1, и т. д. Запуск верификатора Spin Верификация построенной нами модели при помощи инструмента Spin состоит из следующих этапов: 1. Построение верификатора pan. При запуске к ключом -a по модели на языке Promela Spin генерирует верификатор pan на языке C. 2. Компиляция верификатора pan. При компиляции можно определить константы, которые влияют на то, как в памяти будет храниться модель Крипке [1]. Наиболее компактный вариант задается константой BITSTATE, однако в этом случае происходит аппроксимация, и верификация может быть не точна. 3. Запуск верификатора pan. Верификатор pan также может быть запущен с разными ключами, важнейший из которых является –a (поиск допускающих циклов). 4. Анализ контрпримера. Описан в разделе «Преобразование контрпримера». Интерактивность достигается за счет предоставления пользователю возможности использования вышеперечисленных вариантов работы на этапах верификации. Преобразование контрпримера Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 85
  • 83. Верификация распределенных автоматных программ с использованием инструментального средства Spin 9 Для того чтобы было удобнее понимать контрпример, приведем метод автоматической трансляции контрпримера, который получается на выходе верификатора Spin, в термины используемой автоматной модели. Для каждого действия автомата создается пометка при помощи функции printf. На языке Promela функция printf работает аналогично функции printf из языка C [35]. Во время случайной симуляции [4] она выводит текст на экран, а во время верификации этот текст появляется в контрпримере. Остается его считать и вывести пользователю. Подробнее преобразование контрпримера описано в работе [26]. Корректность построения модели Построенная функция переходов автомата в модели на Promela соответствует его графу переходов, так как содержит в себе ровно все его состояния и ровно все переходы для каждого состояния. Состояние каждого автомата хранится в его поле state, и в модели на Promela это поле не изменяется нигде, кроме функции переходов. Поэтому, атомарные высказывания о состояниях автомата тождественны соответствующим атомарным высказываниям в модели. Номер события передается в функцию переходов в качестве параметра. В функции перехода этот номер присваивается полю curEvent. Других присваиваний полю curEvent нет. Поэтому, атомарные высказывания о событиях, пришедших в автомат, эквивалентны соответствующим атомарным высказываниям в модели. Выходные воздействия второго типа перенумерованы и в момент вызова их номер присваивается полю functionCall. Поэтому, атомарные высказывания о выходных воздействиях второго типа эквивалентны соответствующим атомарным высказываниям в модели. Выходные воздействия первого типа, которые могут являться любым кодом, записываются в модель без изменения за исключением добавления названия структуры автомата. Аналогично с остальными вариантами атомарных высказываний. На основе изложенного можно сделать вывод о том, что LTL спецификация равновыполнима на исходной системе автоматов и в модели на Promela. 2.3 Генерация программного кода Метод разработан для объектно-ориентированных языков, но может быть расширен и для прочих языков. Однако это выходит за рамки данного исследования. В отличие от таких инструментов, как Unimod [36] и Stateflow [37] в данном подходе предлагается генерировать не самостоятельную программу, а подпрограмму. Для объектно-ориентированных языков это набор классов, который пользователь может включить в свою программу. Для того, чтобы обеспечить удобство использования сгенерированного кода, делаются следующие шаги (ограничение на размер статьи не позволяет подробно описать алгоритмы первичной и повторной генерации кода, отметим лишь, что они 86 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 84. М. А. Лукин, А. А. Шалыто 10 используют конечные автоматы и были разработаны при помощи самого инструментального средства Stater): ─ Для каждого автоматного типа генерируется отдельный класс в отдельном файле. Такой класс называется автоматизированным классом [33]. ─ Сгенерированный класс содержит функцию переходов для автомата, перечисление, содержащее события, необходимые переменные для переходов и определения функций (выходных воздействий второго типа), в которые пользователь может дописать собственный код, и этот код не исчезнет при повторной генерации кода. ─ В коде специальными комментариями помечаются места, которые полностью переписываются, и в которые не следует писать пользовательский код. Пользовательский код из остальных мест будет полностью сохранен. ─ Если пользователь добавит новые выходные воздействия второго типа, то их определения будут добавлены к сгенерированному коду. ─ Пользователь может задать пространство имен (или пакет в языке Java), в котором будет находиться сгенерированный код. Если между генерациями кода пространство имен было удалено, то оно будет восстановлено. ─ Если пользователь добавит к автоматизированному классу наследование от базового класса или интерфейса, то повторная генерация кода сохранит это наследование. ─ Генерируются вспомогательные классы, включая менеджер потоков, которые обеспечивают взаимодействие автоматов, находящихся в разных потоках. Если многопоточность не требуется, их генерацию можно отключить. ─ Пользователь может ввести произвольное количество автоматных объектов, которые будут запущены при запуске менеджера потоков. 2.4 Хранение диаграмм При совместной разработке программы несколькими разработчиками существует проблема объединения программного кода, когда один файл редактируется несколькими разработчиками одновременно. Для обычных программ эта проблема решается при помощи систем контроля версий (SVN [38], Git [39], Mercurial [40] и т. д.). Однако системы контроля версий хорошо объединяют только текстовые файлы. Диаграммы графов переходов конечных автоматов у популярных инструментов плохо приспособлены для совместной разработки. Для того чтобы облегчить объединение диаграмм, в данной работе предлагаются следующие свойства, которыми должен обладать формат хранения диаграмм: 1. Формат должен быть текстовым. 2. Каждая диаграмма должна быть в отдельном файле или в отдельном множестве файлов. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 87
  • 85. Верификация распределенных автоматных программ с использованием инструментального средства Spin 11 3. Структура диаграммы хранится в отдельных файлах от информации, которая нужна для отображения диаграммы. 3 Описание инструментального средства Stater Для поддержки предложенного метода было разработано инструментальное средство Stater. Оно позволяет следующее: ─ создавать распределенную систему конечных иерархических автоматов; ─ импортировать конечные автоматы из Stateflow; ─ верифицировать созданную систему конечных автоматов при помощи верификатора Spin; ─ генерировать программный код по созданной системе конечных автоматов. Инструментальное средство Stater использовалось при разработке самого себя, а именно модулей загрузки диаграмм из файла и преобразования LTLформул, а также модуля генерации кода. Ни предложенный метод, ни разработанное на его основе инструментальное средство Stater не претендуют на полноту верификации систем, разработанных в Stateflow. Это связано, в первую очередь, с тем, что спецификация к Stateflow имеет более 1300 страниц [41]. 4 Пример Продемонстрируем работу метода на примере прототипа программы управления гусеничным шасси для робота. В шасси два двигателя: по одному на левую гусеницу и на правую. Прототип программы состоит из двух автоматных типов: AEngine и AManager. Автомат manager типа AManager Два автомата left и right типа AEngine (рис. 1) управляют соответственно левым и правым двигателями. 88 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 86. М. А. Лукин, А. А. Шалыто 12 Рис. 1. Диаграмма переходов автоматного типа AEngine Автомат типа AManager (рис. 2) отправляет команды на управление двигателями в зависимости от команд для шасси. При входе в состояния он отправляет следующие события автоматам AEngine (слева от стрелки написано имя автомата, справа – событие): ─ ─ ─ ─ ─ ─ ─ ─ ─ Stopped: left ← stop, right ← stop. MoveForward: left ← forward, right ← forward. MoveBackward: left ← backward, right ← backward. TurnRight: left ← backward, right ← forward. TurnLeft: left ← forward, right ← backward. ForwardRight: left ← stop, right ← forward. ForwardLeft: left ← forward, right ← stop. BackwardRight: left ← backward, right ← stop. BackwardLeft: left ← stop, right ← backward. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 89
  • 87. Верификация распределенных автоматных программ с использованием инструментального средства Spin 13 Рис. 2. Диаграмма переходов автоматного типа AManager Проверим свойство: «В любой момент если поступила команда «стоп», то будет подана команда остановки левого двигателя». Мы не можем проверить, что остановился, так как это утверждение относится к аппаратной части. Формализуем это свойство. Высказывание «Поступила команда «стоп» означает, что в автомат manager пришло событие stop. В нотации Stater оно записывается следующим образом: {manager.stop}. Высказывание «подана команда остановки левого двигателя» означает, что автомат left вызвал функцию EngineStop. В нотации Stater оно записывается следующим образом: {left.EngineStop}. Поэтому, свойство переписывается так: в любой момент в автомат manager пришло событие stop, следовательно, в будущем автомат left вызовет функцию EngineStop: G ({manager.stop} => (F {left.EngineStop})) (2) В итоге получаем следующий вид: [] ( {manager.stop} -> (<> {left.EngineStop} )) (3) Запускаем верификацию и получаем ответ, который означает, что свойство выполняется в построенной системе: 0. [] ( {manager.stop} -> (<> {left.EngineStop} )) Verification successful! 90 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 88. 14 М. А. Лукин, А. А. Шалыто Источники 1. Кларк Э., Грамберг О., Пелед Д. Верификация моделей программ: Model Checking. М.: МЦНМО, 2002. 2. Вельдер С. Э., Лукин М. А., Шалыто А. А., Яминов Б. Р. Верификация автоматных программ. СПб.: Наука, 2011. 3. Карпов Ю. Г. Model Checking: верификация параллельных и распределенных программных систем. СПб.: БХВ-Петербург, 2010. 4. Официальный сайт инструмента Spin. http://spinroot.com 5. Mikk E., Lakhnech Y., Siegel M. , Holzmann G. J. “Implementing Stateacharts in Promela/SPIN” in Proc. of WIFT'98, 1998 6. Latella D., Majzik I., Massink M. Automatic verification of a behavioral subset UML stetechart diagrams using the SPIN model-checker // Formal Aspects of Computing 11:637–664, 1999. 7. Lilius, J., Paltor I. P. Formalising UML State Machines for Model Checking, in: R. B. France and B. Rumpe, editors, Proc. 2nd Int. Conf. UML, Lect. Notes Comp. Sci. 1723 (1999), pp. 430–445. 8. Eschbah R. A verification approach for distributed abstract state machines. // PSI '02 109-115, 2001. http://dl.acm.org/citation.cfm?id=705973 9. Shaffer T., Knapp A., Merz S. Model checking UML state machines and collaborations. //Electronic notes in theoretical computer science 47:1-13, 2001. 10. Tiwari A.. Formal semantics and analysis methods for Simulink Stateow models. Technical report, SRI International, 2002. http://www.csl.sri.com/~tiwari/~stateflow.html 11. Roux C., Encrenaz E. CTL May Be Ambiguous when Model Checking Moore Machines. UPMC LIP6 ASIM, CHARME, 2003. http://sed.free.fr/cr/charme2003.ps 12. Gnesi S., Mazzanti F. On the fly model checking of communicating UML state machines. 2004. http://fmt.isti.cnr.it/WEBPAPER/onthefly-SERA04.pdf 13. Gnesi S., Mazzanti F. A model checking verification environment for UML statecharts / Proceedings of XLIII Congresso Annuale AICA, 2005. http://fmt.isti.cnr.it/~gnesi/matdid/aica.pdf 14. Виноградов Р. А., Кузьмин Е. В., Соколов В. А. Верификация автоматных программ средствами CPN/Tools // Моделирование и анализ информационных систем. 2006. № 2, с. 4–15. http://is.ifmo.ru/verification/_cpnverif.pdf 15. Васильева К. А., Кузьмин Е. В. Верификация автоматных программ с использованием LTL // Моделирование и анализ информационных систем. 2007. № 1, с. 3–14. http://is.ifmo.ru/verification/_LTL_for_Spin.pdf 16. Лукин М. А. Верификация автоматный программ. Бакалаврская работа. СПбГУ ИТМО, 2007. http://is.ifmo.ru/papers/_lukin_bachelor.pdf 17. Яминов Б. Р. Автоматизация верификации автоматных UniMod-моделей на основе инструментального средства Bogor. Бакалаврская работа. СПбГУ Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 91
  • 89. Верификация распределенных автоматных программ с использованием инструментального средства Spin 15 ИТМО, 2007. http://is.ifmo.ru/papers/_jaminov_bachelor.pdf 18. Ma G. Model checking support for CoreASM: model checking distributed abstract state machines using Spin. 2007. http://summit.sfu.ca/item/8056 19. David A., Moller O., Yi W. Formal Verification of UML Statecharts with Real-time Extensions. / Formal Methods 2006 20. Егоров К. В., Шалыто А. А. Методика верификации автоматных программ // Информационно-управляющие системы. 2008. № 5, с. 15–21. http://is.ifmo.ru/works/_egorov.pdf 21. Курбацкий Е. А. Верификация программ, построенных на основе автоматного подхода с использованием программного средства SMV // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 137–144. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 22. Лукин М. А., Шалыто А. А. Верификация автоматных программ с использованием верификатора SPIN // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 145–162. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 23. Гуров В. С., Яминов Б. Р. Верификация автоматных программ при помощи верификатора UNIMOD.VERIFIER // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 162–176. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 24. Егоров К. В., Шалыто А. А. Разработка верификатора автоматных программ // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 177–188. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 25. Prashanth C.M., Shet K. C. Efficient Algorithms for Verification of UML Statechart Models. // Journal of Software. 2009. Issue 3 pp 175-182. 26. Лукин М. А. Верификация визуальных автоматных программ с использованием инструментального средства SPIN. СПбГУ ИТМО, 2009. http://is.ifmo.ru/papers/_lukin_master.pdf 27. Ремизов А. О., Шалыто А. А. Верификация автоматных программ / Сборник докладов научно-технической конференции «Состояние, проблемы и перспективы создания корабельных информационно-управляющих комплексов. ОАО «Концерн Моринформсистема Агат». М.: 2010, с. 90–98. http://is.ifmo.ru/works/_2010_05_25_verific.pdf 28. Клебанов А. А., Степанов О. Г., Шалыто А. А. Применение шаблонов требований к формальной спецификации и верификации автоматных программ / Труды семинара «Семантика, спецификация и верификация программ: теория и приложения». Казань, 2010, с. 124–130. http://is.ifmo.ru/works/_2010-10-01_klebanov.pdf 29. Вельдер С. Э., Шалыто А. А. Верификация автоматных моделей методом редуцированного графа переходов // Научно-технический вестник 2009. Вып. 6(64), с. 66–77. СПбГУ ИТМО. http://is.ifmo.ru/works/_2010_01_29_velder.pdf 92 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 90. 16 М. А. Лукин, А. А. Шалыто 30. Chen C., Sun J., Liu Y., Dong J., Zheng M. Formal modeling and validation of Stateflow diagrams // International Journal on Software Tools for Technology Transfer. 2012. Issue 6, pp 653 – 671. 31. Шалыто А. А. Switch-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998. http://is.ifmo.ru/books/switch/1 32. I. Cardei, R. Jha, M. Cardei. Hierarchical architecture for real-time adaptive resource management. Secaucus, NJ, USA: Springer-Verlag, 2000. 33. Поликарпова Н. И., Шалыто А. А. Автоматное программирование. СПб.: Питер, 2010. http://is.ifmo.ru/books/_book.pdf 34. Dijkstra E.W. Guarded commands, non-determinacy and formal derivation of programs // CACM. 18. 1975. № 8. 35. Последний черновик спецификации языка C. http://www.openstd.org/jtc1/sc22/wg14/www/docs/n1570.pdf 36. Официальный сайт проекта UniMod. http://unimod.sf.net 37. Официальный сайт продукта Stateflow. http://www.mathworks.com/products/stateflow/ 38. Официальный сайт проекта SVN. http://subversion.apache.org 39. Официальный сайт проекта Git. http://git-scm.com/ 40. Официальный сайт проекта Mercurial. http://mercurial.selenic.com/ 41. The MathWorks. Stateflow and Stateflow coder – User's Guide. 2009. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 93
  • 91. Проверка корректности поведения HDL-моделей цифровой аппаратуры на основе динамического сопоставления трасс В.П. Иванников, А.С. Камкин, М.М. Чупилко Федеральное государственное бюджетное учреждение науки Институт системного программирования Российской академии наук (ИСП РАН), 109004, г. Москва, ул. Александра Солженицына, д. 25. {ivan,kamkin,chupilko}@ispras.ru Аннотация Проверка корректности поведения HDL-моделей является неотъемлемой частью динамической верификации аппаратуры. Как правило, она основана на сравнении поведения HDL-модели с поведением эталонной модели, разработанной на языке программирования. В процессе верификации на обе модели подается одна и та же последовательность стимулов; реакции перехватываются и сравниваются друг с другом. Из-за абстрактности эталонной модели сопоставление трасс не является тривиальной задачей: порядок событий может не совпадать, а некоторые события одной трассы могут отсутствовать в другой. В работе рассматривается метод динамического сопоставления трасс для моделей аппаратуры разного уровня абстракции. Метод был успешно применен в нескольких промышленных проектах по верификации модулей микропроцессоров. 1 Введение Несмотря на развитие формальных методов, динамическая верификация остается основным методом проверки сложной цифровой аппаратуры [1]. Объектом верификации выступают не сами устройства, а их модели, разработанные на специальных языках описания аппаратуры (HDL, Hardware Description Languages), например, на Verilog или VHDL (такие модели называются HDL-моделями) [2]. С одной стороны, HDL-модели представляют основу для автоматизированного производства интегральных схем; с другой стороны, это имитационные модели, поведение которых можно анализировать в специальных средах (симуляторах). Для автоматизации проверки корректности поведения HDL-моделей разрабатываются мониторы, которые перехватывают события на входах и выходах (стимулы и реакции) и проверяют допустимость получаемой трассы [3]. Существует множество подходов к формальному описанию поведения, позволяющих автоматизировать создание мониторов: расширенные регулярные выражения [4], контрактные спецификации [5], системы правил [6], 94 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 92. 2 Проверка корректности поведения HDL-моделей цифровой аппаратуры темпоральные утверждения [7], однако указанные формализмы не покрывают всех потребностей индустрии. Большинство компаний, проектирующих аппаратуру, для оценки проектных решений используют исполнимые модели, разработанные на языках программирования (прежде всего, на C и C++) [8]. Экономически целесообразно использовать эти модели и для верификации создаваемой аппаратуры, в частности, для проверки корректности поведения HDL-моделей. При наличии исполнимой модели применяют следующую схему проверки корректности поведения: эталонная модель (по терминологии тестирования соответствия, спецификация) выполняется совместно с проверяемой HDL-моделью (реализацией); на спецификацию поступает та же последовательность стимулов, что и на реализацию; реакции обеих моделей перехватываются монитором и сравниваются. Основная проблема указанной схемы связана с обобщенным характером спецификации, из-за чего порядок реакций, выдаваемых спецификацией и реализацией, а также их состав могут различаться. Перед тем как использовать эталонную модель для мониторинга, необходимо понять, насколько она абстрактна и насколько можно доверять производимым ею трассам. В работе предлагается способ построения мониторов для HDL-моделей аппаратуры, адаптируемый для эталонных моделей разного уровня абстракции. Рассматриваемый подход может быть формализован на основе модели частично упорядоченных мультимножеств [9]. Поведение спецификации и реализации описывается временн´ ми трассами над общим алфавитом. Свеы дения об абстрактности спецификации позволяют обобщать последовательности выдаваемых реакций в частично упорядоченные мультимножества, в которых для каждой реакции задан допустимый временной интервал. Монитор проверяет, что трасса реализации является линеаризацией обобщенной трассы спецификации (или ее подмножества) и реакции реализации удовлетворяют ограничениям, заданными временными интервалами. ´ Оставшаяся часть статьи организована следующим образом. В разделе 2 вводятся основные понятия и обозначения. Раздел 3 описывает предлагаемый метод динамического сопоставления трасс: в этом разделе определяется отношение соответствия между реализацией и спецификацией и рассматривается устройство монитора, проверяющего соответствие. В разделе 4 описывается опыт использования предлагаемого подхода для верификации модулей микропроцессоров. Раздел 5 содержит краткий обзор работ близких к нашей. В разделе 6 дается заключение и указываются направления дальнейших исследований. 2 Основные понятия и обозначения В дальнейшем будем использовать следующие обозначения: Σ — конечный алфавит событий, T — временн´я область (для определенности, N). Поа следовательности событий называются словами. Σ ∗ обозначает множество всех (конечных) слов над алфавитом Σ. Если u и v — два слова над одним Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 95
  • 93. Проверка корректности поведения HDL-моделей цифровой аппаратуры 3 алфавитом и u конечно, то uv обозначает их конкатенацию. Для w = uv говорят, что w является продолжением u с помощью v. В контексте динамической верификации HDL-моделей удобно структурировать алфавит событий, разбив его на два множества: множество входных событий (стимулов) I и множество выходных событий (реакций) O, а также сопоставив каждому событию его порт: port : Σ → {1, 2, ..., k}. На содержательном уровне стимул представляет собой посылку запроса к устройству, а реакция — выдачу ответа. При этом события на разных портах могут происходить параллельно. Определение 1 (Временн´е слово [10]) Временн´ м словом (timed word) о ы w над алфавитом Σ и временн´й областью T называется последовательо ы ность (a0 , t0 )(a1 , t1 )... временн´ х событий (ai , ti ) ∈ Σ × T, удовлетворяющая следующим ограничениям: 1. для каждого i ≥ 0 выполняется неравенство ti ≤ ti+1 ; 2. для любого T ∈ T найдется i ≥ 0, такой что ti > T (если w бесконечна); 3. для всех i, j ≥ 0, таких что i = j и ti = tj , port(ei ) = port(ej ). В параллельных системах, к которым относится аппаратура, используется концепция независимости событий: два события считаются независимыми, если между ними нет причинно-следственной связи (для таких событий не накладываются ограничения на их относительный порядок). Эта идея лежит в основе двух формальных моделей параллельных вычислений: (1) трасс Мазуркевича (Mazurkiewicz) [11] и (2) частично упорядоченных мультимножеств [9]. В настоящей статье мы будем придерживаться более общей второй модели. Определение 2 (Частично упорядоченное мультимножество [9]) Σразмеченным частичным порядком называется кортеж V, , λ , где V — конечное множество вершин и λ : V → Σ — функция разметки. Два Σразмеченных частичных порядка называются эквивалентными, если они изоморфны относительно и λ (совпадают или отличаются названием вершин). Частично упорядоченным мультимножеством (pomset, partially ordered multiset) над алфавитом Σ называется класс эквивалентности Σразмеченных частичных порядков. Для удобства мы будем использовать конкретного представителя (конкретный размеченный частичный порядок) для обозначения частично упорядоченного мультимножества. Линеаризацией частично упорядоченного мультимножества V, , λ называется размеченный полный порядок V, ≤, λ , где ⊆≤. Определение 3 (Временн´я трасса [12]) Временн´й трассой над алфаа о витом Σ и временн´й областью T называется четверка V, , λ, θ , где о V, , λ — частично упорядоченное мультимножество, а θ : V → T — функция времени, удовлетворяющая следующим условиям: 96 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 94. 4 Проверка корректности поведения HDL-моделей цифровой аппаратуры 1. для всех x, y ∈ V , из x y вытекает θ(x) < θ(y); 2. для любого t ∈ T существует срез C ⊆ V , такой что minx∈C {θ(x)} ≥ t (если V бесконечно). Множество всех трасс над алфавитом Σ и временн´й областью T обознао ´ чается Mθ (Σ, T). Заметим, что временные слова являются частным случаем временных трасс. Для заданной непустой трассы σ = V, , λ, θ введем обо´ значения: begin(σ) = minx∈V {θ(x)} и end(σ) = maxx∈V {θ(x)} (если σ бесконечна, end(σ) = ∞); σ[t,t+∆t] — подтрасса трассы σ, состоящая из тех x ∈ V , для которых θ(x) ∈ [t, t + ∆t]. Пусть TI(T) — множество временных интер´ валов во временн´й области T (то есть TI(T) = {[t, t + ∆t] | t, t + ∆t ∈ T}). о Определение 4 (Интервальная трасса) Интервальной трассой над алфавитом Σ и временн´й областью T называется четверка σ = V, , λ, δ , о где V, , λ — частично упорядоченное мультимножество, а δ : V → TI(T) — функция, ассоциирующая с каждой вершиной временной интервал. Языком интервальной трассы σ является множество L(σ) = { V, , λ, θ ∈ Mθ (Σ, T) | ∀x ∈ V . θ(x) ∈ δ(x)}. Множество всех интервальных трасс над алфавитом Σ и временн´й облао стью T обозначается Mδ (Σ, T). В дальнейшем мы будем иметь дело с парами а трасс σθ , σδ , где σθ — временн´я трасса, а σδ — интервальная трасса, такие что σθ ∈ L(σδ ). Каждая такая пара описывается пятеркой V, , λ, θ, δ и называется расширенной интервальной трассой. Множество всех расширенных интервальных трасс обозначается Mθδ (Σ, T). 3 Динамическая верификация на основе исполнимых моделей Временн´е слово (временн´я трасса с тривиальным частичным порядком) о а описывает конкретное выполнение HDL-модели (реализации), в то время как расширенная интервальная трасса описывает поведение эталонной модели (спецификации). Наша цель — проверить в динамике (on-the-fly), что трасса реализации wI ∈ (Σ × T)∗ соответствует трассе спецификации σS ∈ Mθδ (Σ, T). Поясним, откуда берется расширенная интервальная трасса σS . В процессе выполнения спецификация порождает конкретную трассу wS , описываемую временным словом. Прямое сравнение двух временных слов, wI и ´ ´ wS , на равенство возможно только для потактово точной спецификации. Как правило, спецификация абстрактнее реализации, особенно в отношении временных свойств. Сведения о степени абстрактности спецификации ´ позволяют обобщить конкретное временн´е слово wS до расширенной ино тервальной трассы σS , смягчая тем самым проверку соответствия между реализацией и спецификацией (см. Рисунок 1). Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 97
  • 95. Проверка корректности поведения HDL-моделей цифровой аппаратуры 5 Рис. 1. Схема проверки соответствия между реализацией и спецификацией 3.1 Отношение соответствия В дальнейшем мы будем называть трассы с тривиальным частичным порядком (порядком, заданным отношением равенства) трассами выполнения. Если Σ = I ∪ O, то трассы выполнения над алфавитом I будем называть входными последовательностями, а трассы выполнения над алфавитом O — выходными последовательностями. Отметим, что тривиальный частичный порядок в трассах выполнения отражает тот факт, что реализация рассматривается как “черный ящик”, и причинно-следственные связи между ее событиями если и известны, то не от самой реализации. Множества входных и выходных последовательностей обозначаются Iθ (Σ, T) и Oθ (Σ, T) соответственно. Для краткости будем использовать сокрашенные обозначения: I = Iθ (Σ, T) и O = Oθ (Σ, T). Определение 5 (Поведение) Детерминированным поведением над алфавитом Σ = I ∪ O и временн´й областью T называется (частичное) отобо ражение B : I × T → O, удовлетворяющее следующим ограничениям: - для всех w ∈ I и t ∈ T выполняется неравенство end B(w, t) ≤ t; - для всех w ∈ I и t ∈ T справедливо равенство B(w, t) = B(w[0,t] , t); - для всех w ∈ I и t ∈ T существует wv ∈ I, продолжение w, и ∆t ≥ 0, такие что end B(wv, t + ∆t) ≥ t. Поведение описывает, каким образом входная последовательность преобразуется в выходную последовательность, принимая во внимание момент времени, в которое производится наблюдение. Предположим, что у нас есть исполнимая спецификация. Рассмотрим, как ее можно использовать для динамической проверки поведения реализации. Расширим определение поведения, позволив спецификации возвращать расширенные интервальные трассы, а не конкретные последовательности, как это требуется. Обозначим множество всех таких трасс символом Oθδ . Для заданной выходной трассы V, , λ, θ, δ ∈ Oθδ , определим две функции, ∆t± , такие что для всех x ∈ V , δ(x) = [θ(x)−∆t− (x), θ(x)+∆t+ (x)]. Будем полагать, что функции ∆t± ограничены (существуют константы ∆T ± > 0, такие что |∆t± (x)| ≤ ∆T ± для всех x ∈ V ). Также положим, что значения 98 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 96. 6 Проверка корректности поведения HDL-моделей цифровой аппаратуры ∆t± (x) зависят от события, а не от вершины: ∆t± (x) = ∆t± (λ(x)). Пусть I и S — поведение реализации и поведение спецификации соответственно. Для заданной входной последовательности w ∈ I и момента времени t ∈ T рассмотрим выход реализации и спецификации: I(w, t) = VI , ∅, λI , θI и S(w, t) = VS , S , λS , θS , δS . Введем обозначения: past∆t (w, t) = {y ∈ I(w, t) | θI (y) ≤ t − ∆t− (y) }; I pastI (w, t) = {y ∈ I(w, t) | θI (y) ≤ t}; past∆t (w, t) = {x ∈ S(w, t) | θS (x) ≤ t − ∆t+ (x) }; S pastS (w, t) = {x ∈ S(w, t) | θS (x) ≤ t}; match(x, y) = λI (y) = λS (x) ∧ θI (y) ∈ δS (x) . Определение 6 (Отношение соответствия) Говорят, что поведение реализации I соответствует поведению спецификации S, если domI = domS и для всех w ∈ domS и t ∈ T существует бинарное отношение M(w, t) ⊆ {(x, y) ∈ pastS (w, t)×pastI (w, t) | match(x, y)} (называемое сопоставлением), такое что: 1. M(w, t) взаимно однозначно; 2. для каждой реакции спецификации x ∈ past∆t (w, t) существует реакция S реализации y ∈ pastI (w, t), такая что (x, y) ∈ M(w, t); 3. для каждой реакции реализации y ∈ past∆t (w, t) существует реакция I спецификации x ∈ pastS (w, t), такая что (x, y) ∈ M(w, t); 4. для всех (x, y), (x , y ) ∈ M(w, t) если x x , то θI (y) ≤ θI (y ). Если для некоторых w ∈ I и t ∈ T вышеуказанные свойства нарушаются, то говорят, что I не соответствует S, при этом w[0,t] называется контрпримером. Рисунок 2 иллюстрирует определение отношения соответствия для некоторой входной последовательности (будучи неважной, она на рисунке не показана) и момента времени (t = 4). Верхняя часть рисунка показывает реакции реализации (черные кружки с белыми надписями: b, a и c), нижняя — реакции спецификации (белые кружки с черными надписями: a, b, c и d). Будем обозначать вершины трассы (собственно, кружки) символами yb , ya и yc (для реализации) и xa , xb , xc и xd (для спецификации). Между вершинами реализационной трассы нет причинно-следственных связей. Вершины спецификационной трассы частично упорядочены (предшествование xc , xb xc , xa xd и xb xd ) и пособытий показано стрелками: xa мечены временными интервалами (δ(xa ) = [0, 2], δ(xb ) = [1, 3], δ(xc ) = [0, 4] ´ и δ(xd ) = [1, 5]). Сопоставление реакций отмечено пунктирными линиями ((xa , ya ), (xb , yb ) и (xc , yc )). Легко видеть, что изображенное отношение является сопоставлением (в смысле данного выше определения): (1) оно взаимно однозначно; (2 и 3) оно включает все реакции с истекшим “времеxc и нем жизни”; (4) оно сохраняет спецификационный порядок: (a) xa θ(ya ) = 2 ≤ 3 = θ(yc ); (b) xb xc и θ(yb ) = 1 ≤ 3 = θ(yc ). Безусловно, каждая пара этого отношения удовлетворяет условию сопоставления реакций: (a) λ(xa ) = λ(ya ) = a и θ(ya ) = 2 ∈ [0, 2] = δ(xa ); (b) λ(xb ) = λ(yb ) = b и θ(yb ) = 1 ∈ [1, 3] = δ(xb ); (c) λ(xc ) = λ(yc ) = c и θ(yc ) = 3 ∈ [0, 4] = δ(xc ). Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 99
  • 97. Проверка корректности поведения HDL-моделей цифровой аппаратуры 7 Рис. 2. Соответствие между реализацией и спецификацией 3.2 Динамическое сопоставление трасс Монитор, осуществляющий сопоставление трасс реализации и спецификации, может быть представлен как временной автомат [10] с двумя типами входных портов: (1) порты для получения спецификационных реакций и (2) порты для получения реализационных реакций. Когда автомат обнаруживает расхождение в трассах реализации и спецификации, он переходит в определенное состояние, информируя, тем самым, что реализация не соответствует спецификации. Ниже представлено формальное описание монитора в виде системы действий с условиями (guarded actions). Каждое действие атомарно и выполняется, как только соответствующее условие становится истинным. Действия и условия зависят от внешней переменной t, отражающей текущее время, и реакций, выдаваемых реализацией и спецификацией в ответ на одну и ту же последовательность стимулов (S и I соответственно). Значение t монотонно возрастает в процессе верификации. Запись y ∈ I[t] (x ∈ S[t]) означает, что в момент времени t реализация (спецификация) выдает реакцию y (x). Описание базируется на двух функциях: (1) первичный арбитр (arbiterS ) и (2) вторичный арбитр (arbiterI ), определенных ниже: arbiterS (X) = arbiterI (y, X) = 100 min (X) φ arg minx∈X.match(x,y) {θS (x)} φ если X = ∅, иначе (φ ∈ Σ); / если ∃x ∈ X . match(x, y), иначе. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 98. 8 Проверка корректности поведения HDL-моделей цифровой аппаратуры Действие 1 onSpecOut[x], x ∈ S[t] Если: true Вход: x pastS ⇐ pastS ∪ {x} if x ∈ arbiterS (pastS ) then for all y ∈ pastI [↑ θI (y)] do if x = arbiterI (y, {x}) then pastS ⇐ pastS {x} pastI ⇐ pastI {y} match ⇐ match ∪ { x, y } break end if end for end if Действие 2 onImplOut[y], y ∈ I[t] Если: true Вход: y pastI ⇐ pastI ∪ {y} x ⇐ arbiterI (y, arbiterS (pastS )) if x = φ then pastS ⇐ pastS {x} pastI ⇐ pastI {y} match ⇐ match ∪ { x, y } end if Действие 3 onSpecT ime[x], x ∈ pastS Действие 4 onImplT ime[y], y ∈ pastI ` ´ Если: θS (x) + ∆t+ (x) ≤ t Вход: x pastS ⇐ pastS {x} verdict ⇐ f alse‘ trace(“Missing output”) terminate ` ´ Если: θI (y) + ∆t− (y) ≤ t Вход: y pastI ⇐ pastI {y} verdict ⇐ f alse trace(“Unexpected output”) terminate Действие 5 onInitialize Действие 6 onF inalize Если: t = 0 Вход: ∅ pastS ⇐ ∅ pastI ⇐ ∅ match ⇐ ∅ Если: ` ´ max end(S)+∆T + , end(I)+∆T − ≤ t Вход: ∅ verdict ⇐ true terminate Ниже приведен порядок проверки условий и запуска действий внутри одного временн´го слота t (при несоблюдении этого порядка возможны ложо ные сообщения об ошибках): 1. 2. 3. 4. инициализация (onInitialize); прием реакции (onSpecOut, onImplOut); превышение лимита времени (onSpecT ime, onImplT ime); завершение (onF inalize). Когда говорят, что некоторое свойство ϕ выполняется в момент времени t, имеется в виду, что ϕ выполняется после завершения всех действий, активированных в момент t. Для многопортовых систем (что типично для аппаратуры) монитор можно разбить на слабо связанные компоненты, параллельно обслуживающие отдельные порты. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 101
  • 99. Проверка корректности поведения HDL-моделей цифровой аппаратуры 9 Утверждение 1 (Корректность) Входная последовательность является контрпримером тогда и только тогда, когда монитор завершается с verdict = f alse. На практике встречается аппаратура, в которой операции в некоторых ситуациях отменяют другие операции (конфликтующие с ними и имеющие более низкий приоритет). Например, операция записи может быть отменена другой операцией записи, адресующейся к той же ячейке памяти и запущенной сразу после рассматриваемой операции. Из-за абстрактности спецификации в ее терминах не всегда возможно выразить условия, при которых происходит отмена операций и соответствующие реакции не посылаются наружу. Принимая во внимание вышесказанное, определение спецификационного поведения может быть расширено: каждая спецификационная реакция дополнительно помечается признаком возможной отмены. Предложенный подход к организации мониторов может быть перенесен и на этот случай. Следует, однако, учесть, что если некоторое событие отменяется, то также отменяются все зависимые от него события. 4 Инструментальная поддержка и опыт применения Предложенный метод к проверке корректности поведения HDL-моделей был реализован в инструменте C++TESK [13]. Библиотека инструмента содержит классы и макросы для создания компонентов систем динамической верификации аппаратуры (эталонных моделей, мониторов, генераторов стимулов и других). Возможности C++TESK для разработки эталонных моделей аппаратуры (и, соответственно, мониторов) включают средства для посылки и приема пакетов данных (примитивы send и receive), ветвления и объединения параллельных процессов (f ork и join), моделирования временных задержек (delay) и задания зависимостей между пакетами (depends). ´ Инструмент позволяет создавать модели аппаратуры на разных уровнях абстракции (относительно точности моделирования времени): (1) модели без учета времени (описывающие общие причинно-следственные связи между пакетами данных без моделирования временных задержек между ´ ними: ∆t± = ∞), (2) модели с приближенным учетом времени (частично специфицирующие внутренние схемы арбитража пакетов, но учитывающие время лишь примерно: ∆t± ≤ T , где T имеет значение нескольких десятков тактов) и (3) потактовые модели (реализующие точное или почти точное моделирование времени: ∆t± ≤ 1). Инструмент C++TESK был использован для динамической верификации модулей промышленных микропроцессоров, разрабатываемых в НИИСИ РАН и ЗАО “МЦСТ”. Наш опыт уже был представлен в [14], но с тех пор он был расширен. Последняя информацию о применении инструмента и заложенного в нем метода представлена в Таблице 1. Как видно из таблицы, подход поддерживает верификацию как с помощью абстрактных эталонных моделей (доступных на ранних стадиях проектирования), так и 102 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 100. 10 Проверка корректности поведения HDL-моделей цифровой аппаратуры с помощью потактово точных моделей (доступных на заключительных этапах). Что важно, подход позволяет использовать для верификации C++модели, изначально создаваемые для других целей (в частности, компоненты системного симулятора микропроцессора). Таким способом, например, был проверен модуль поиска по таблице страниц. Название модуля Стадия разработки Точность моделирования от до Буфер трансляции адресов Поздняя / завершающая Приближенная Потактовая Модуль арифметики (FPU) Поздняя / завершающая Без учета времени — Кэш-память 2-ого уровня (L2) Промежуточная / поздняя Приближенная Коммутатор северного моста Промежуточная / завершающая Прилиженная Модуль доступа к памяти Ранняя / промежуточная Без учета времени Потактовая Контроллер прерываний Ранняя / промежуточная Без учета времени Приближенная Модуль поиска по таблице страниц Поздняя Приближенная — Контроллер банка кэш-памяти L2 Поздняя Потактовая — Буфер команд Поздняя / завершающая Потактовая — Кэш-память 3-его уровня (L3) Промежуточная Приближенная — — Потактовая Таблица 1. Опыт применения предложенного метода 5 Обзор существующих работ В работе [15] используется модель автомата с частично упорядоченными входными/выходными событиями (POIOA, Partial Order Input/Output Automaton) для представления поведения спецификации и реализации. В статье предлагается метод построения тестового набора, гарантирующего обнаружение ошибок определенного типа. Если (1) реализация сообщает о приеме неподдерживаемых стимулов, (2) можно установить порядок выдачи реакций, (3) время ответа реализации ограничено, и (4) каждый единичный переход в спецификации соответствует единичному переходу в реализации, можно определить соответствие между реализацией и спецификацией. Реализация соответствует спецификации, если она принимает допускаемые спецификацией стимулы и выдает описываемые спецификацией реакции в допустимом порядке. Определение отношения соответствия, данное в этой статье, близко к используемому нами. Главными отличиями нашего подхода являются поддержка необязательных реакций и контроль временных ´ интервалов. Статья [16] описывает подход к проверке поведения временных систем, ´ основанный на инвариантах трассы. Рассматриваются два типа инварианМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 103
  • 101. Проверка корректности поведения HDL-моделей цифровой аппаратуры 11 тов: (1) инварианты ожидания, выражающие то свойство, что после заданной трассы всегда ожидается определенное событие (в определенном временн´м интервале) и (2) инварианты наблюдения, утверждающие, что межо ду двумя заданными событиями всегда наблюдается определенная последовательность событий. Корректность поведения реализации проверяется в два этапа: (1) проверка соответствия инвариантов спецификации, выраженной в форме временного конечного автомата (TFSM, Timed Finite State Machine); (2) проверка выполнимости инвариантов для трассы реализации. Подход представляет теоретический интерес, однако его промышленное использование может быть затруднено необходимостью постоянного согласования проверяемых инвариантов со спецификацией. В работе [17] рассматривается метод тестирования параллельных систем с помощью неявно заданных асинхронных конечных автоматов (AFSM, Asynchronous Finite State Machines). Поведение реализации проверяется только в стационарных состояниях, в которых не ожидается выдача реакций. Используется следующая процедура: (1) собираются все события и определяется их частичный порядок; (2) строятся и проверяются все возможные линеаризации множества событий (проверка базируется на пред- и постусловиях, определенных для каждого события). Считается, что реализация соответствует спецификации, если допускается хотя бы одна из построенных линеаризаций. Применение подхода возможно только для ограниченного класса входных последовательностей: требуется, чтобы регулярно возникали стационарные состояния. В нашем случае такого ограничения нет. 6 Заключение Работа сфокусирована на использовании исполнимых моделей для динамической верификации HDL-моделей. Проблема не так проста, как кажется на первый взгляд. Проверка того, что реализация и спецификация выдают одинаковые реакции в одинаковые моменты времени в большинстве случаев не является адекватной. Спецификация в силу своей абстрактности может не учитывать многих особенностей реализации, таких как упорядочивание событий и их распределение во времени. В работе предложены механизмы, позволяющие настраивать точность проверки поведения, учитывая степень абстрактности спецификации. К ним относятся: (1) описание отношения зависимости событий, (2) расширение временных меток событий до временных ´ ´ интервалов и (3) пометка некоторых событий как необязательных. Основываясь на предложенных механизмах, разработан метод проверки поведения HDL-моделей. Метод был реализован в инструменте C++TESK и применялся в более чем 10 проектах по верификации модулей микропроцессоров. Наши дальнейшие исследования связаны с диагностикой ошибочного поведения HDL-моделей на основе более глубокого анализа трасс, выполняемого после сеанса верификации. Целью такого анализа является упрощение локализации ошибок путем определения характера расхождений наблюдаемого поведения HDL-модели от эталонного. 104 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 102. 12 Проверка корректности поведения HDL-моделей цифровой аппаратуры Список литературы 1. Wile, B., Goss, J., Roesner, W.: Comprehensive Functional Verification: The Complete Industry Cycle. Morgan Kaufmann (2005) 2. Bergeron, J.: Writing Testbenches: Functional Verification of HDL Models. Kluwer Academic (2000) 3. Glasser, M.: Open Verification Methodology Cookbook. Springer (2009) 4. Sen, K., Rosu, G.: Generating Optimal Monitors for Extended Regular Expressions. Electronic Notes in Theoretical Computer Science 89(2) (2003) 162– 181 5. Ivannikov, V., Kamkin, A., Kossatchev, A., Kuliamin, V., Petrenko, A.: The Use of Contract Specifications for Representing Requirements and for Functional Testing of Hardware Models. Programming and Computer Software 33(5) (2007) 272–282 6. Barringer, H., Rydeheard, D., Havelund, K.: Rule Systems for Run-Time Monitoring: From Eagle to RuleR. In: Proceedings of 7th International Workshop on Runtime Verification. Revised Selected Papers. (2007) 111–125 7. Bauer, A., Leucker, M., Schallhart, C.: Runtime Verification for LTL and TLTL. ACM Transactions on Software Engineering and Methodology 20(4) (2011) 14:1– 14:64 8. Mintz, M., Ekendahl, R.: Hardware Verification with C++: A Practitioner’s Handbook. Springer Science+Business Media, LLC (2006) 9. Pratt, V.: The Pomset Model of Parallel Processes: Unifying the Temporal and the Spatial. In: Seminar on Concurrency. (1984) 180–196 10. Alur, R., Dill, D.: A Theory of Timed Automata. Theoretical Computer Science 126(2) (1994) 183–235 11. Mazurkiewicz, A.: Trace Theory. In: Advances in Petri Nets 1986, Part II on Petri Nets: Applications and Relationships to Other Models of Concurrency, New York, NY, USA, Springer-Verlag New York, Inc. (1987) 279–324 12. Chieu, D., Hung, D.: Timed Traces and Their Applications in Specification and Verification of Distributed Real-time Systems. In: Proceedings of the Third Symposium on Information and Communication Technology. (2012) 31–40 13. ISPRAS: C++TESK Homepage. http://forge.ispras.ru/projects/cpptesk-toolkit/ 14. Chupilko, M., Kamkin, A.: A TLM-Based Approach to Functional Verification of Hardware Components at Different Abstraction Levels. In: Proceedings of the 12th Latin-American Test Workshop. (2011) 1–6 15. von Bochmann, G., S.Haar, C.Jard, Jourdan, G.V.: Testing Systems Specified as Partial Order Input/Output Automata. In: Proceedings of the 20th IFIP TC 6/WG 6.1 International Conference on Testing of Software and Communicating Systems: 8th International Workshop. TestCom ’08 / FATES ’08 (2008) 169–183 16. Andr´s, C., Merayo, M., N´nez, M.: Formal Passive Testing of Timed Systems: e u˜ Theory and Tools. Software Testing, Verification & Reliability 22(6) (2012) 365– 405 17. Kuliamin, V., Petrenko, A., Pakoulin, N., Kossatchev, A., Bourdonov, I.: Integration of Functional and Timed Testing of Real-Time and Concurrent Systems. In: Perspectives of System Informatics. (2003) 450–461 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 105
  • 103. Использование контрольных точек для верификации SystemC-программ А.А. Шипин, В.А. Соколов? , Д.Ю. Чалый?? Ярославский государственный университет 150000, Ярославль, Советская, 14 andrey.shipin@gmail.com, valery-sokolov@yandex.ru, chaly@uniyar.ac.ru Аннотация Верификатор, работающий с использованием метода проверки модели (model checking), должен иметь возможность обхода множества достижимых состояний системы. Для SystemC-моделей генерация этого множества является нетривиальной задачей, так как SystemC представляет собой набор классов, расширяющих язык C++. В результате SystemC-модель системы компилируется в виде исполняемого файла, который позволяет проводить только имитационное моделирование или тестирование. В работе представлен подход, основанный на использовании контрольных точек, реализующий исчерпывающее построение множества достижимых состояний моделируемой системы. Keywords: SystemC, model checking, верификация, контрольная точка 1 Введение SystemC (IEEE Standard 1666-2005) [4,10] открытый промышленный язык для проектирования и верификации моделей системного уровня, реализованный в виде C++-библиотеки с открытым исходным кодом. Основной областью применения языка являются встраиваемые системы, системы на кристалле, где важной является задача обеспечения корректной работы. В библиотеку включено ядро моделирования событий, что позволяет получить исполняемую модель устройства, а при разработке можно использовать все средства языка C/C++. Модель на языке SystemC это набор компонентов и соединений между ними. Многие компоненты аппаратного обеспечения, такие как, например, модули, каналы, сигналы, порты, имеют соответствующие аналоги в SystemC. Язык применяется в основном для построения транзакционных и поведенческих моделей. Поведенческая модель описывает взаимодействие ? ?? 106 работа поддержана грантом РФФИ, проект 11-07-00549-а работа поддержана программой ФЦП ⌧Научные и научно-педагогические кадры инновационной России� на 2009–2013 годы, соглашение №14.B37.21.0392 от 06.08.2012 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 104. 2 компонент системы между собой, информационные процессы в системе, поведение системы. Если функциональная модель позволяет ответить на вопрос что делает система?, то поведенческая модель отвечает на вопрос как система это делает?. В ней фигурируют такие категории как состояние системы, события, переход из одного состояния в другое, условия перехода, последовательность событий. Моделирование на уровне транзакций это подход к моделированию систем, в котором детали связи между модулями отделены от деталей реализации модулей. Механизмы связи моделируются в виде каналов, и используются модулями с помощью специальных интерфейсов. Запрос транзакции начинается с вызова функции интерфейса этих каналов, которая заключает в себе детали обмена информацией. На уровне транзакций обмен информацией более выразителен и понятен [4]. К основным расширениям SystemC, отсутствующим в C++, относятся: понятие модельного времени; возможности описания параллельно выполняющихся вычислений; дополнительные типы данных, отражающие специфику проектирования аппаратуры. SystemC был разработан для достижения возможности использовать единый язык программирования с общим окружением для описания системы от самых высокоуровневых моделей на C++ до структурных синтезируемых моделей уровня RTL (Register Transfer Level). Это позволяет постепенно детализировать описание системы в процессе проектирования. С помощью SystemC можно добиться модели взаимодействия программной и аппаратной частей системы, как если бы это было реальное устройство, но на высоком уровне абстракции. За счет этого можно выявить многие проблемы на ранних стадиях разработки [10]. В [21] отмечается, что средства верификации SystemC-моделей находятся в зачаточном состоянии. Стандартная поставка позволяет лишь проводить имитационное моделирование и тестирование. Там же, в [21], ставится задача разработки средств верификации, в частности таких, которые исчерпывающе исследуют множество достижимых состояний модели. 2 Обзор существующих подходов к верификации SystemC-моделей Основными методами верификации систем являются имитационное моделирование, тестирование, дедуктивный анализ и проверка модели [1]. Обычно SystemC-модели верифицируются с помощью тестирования. Проверяемая модель выполняется в рамках заранее подготовленных сценариев. Тестирование сопровождается созданием контролируемой среды модели, обеспечивающей получение результатов ее работы и измерение различных характеристик, а также оценка этих результатов и характеристик [1]. Испытательный стенд (test bench) это среда, используемая для проверки свойств или проверки на безошибочность системы или ее модели. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 107
  • 105. 3 Стенды, разрабатывающиеся для SystemC-моделей, как правило, содержат проверяемую систему (device under test тестируемое устройство), связующие элементы и элементы, необходимые для проверки (тесты). В таких стендах могут использоваться специальные высокоуровневые модели, предназначенные для различных целей: генерации входных сигналов, постобработки данных, создания эталонных моделей, схем обеспечения безопасности (верификаторов свойств, мониторов, наблюдателей) [10]. Создание хороших стендов довольно трудоемкий процесс, требующий хорошего знания C++. Для верификации SystemC-моделей предусмотрена специальная библиотека SCV (SystemC Verification Library). SCV предоставляет средства, помогающие разработчику эффективно проводить комплексные испытания системы [19]. С помощью SCV создаются испытательные стенды и случайным образом генерируются тесты, которые используются средой в качестве входных данных. Существуют разные виды и приемы генерации тестов. Архитектурой модели назовем набор компонентов и соединение между ними, а также механизмы синхронизации и коммуникации, такие как, например, события, сигналы, запись в порты и чтение из них. Лучшие верификаторы SystemC на данный момент переводят код на SystemC в формальную модель с помощью предварительных обработчиков (front-end). Они формализуют семантику языка так, чтобы можно было использовать полученный код как входную информацию для верификаторов. Так как SystemC является библиотекой C++, все особенности C++ должны поддерживаться предварительным обработчиком. Этого можно достичь, написав свой парсер, удовлетворяющий этим условиям, либо использовать существующий предварительный обработчик для C++ (GCC, LLVM, EDG и т.д.). Обычный предварительный обработчик C++ не в состоянии уловить специфику языка SystemC, поэтому предварительные обработчики SystemC должны уметь определять специфичные конструкции языка и помечать их в промежуточном представлении особым образом. В случае создания предварительного обработчика со своим парсером SystemC воспринимается как язык программирования, а не библиотека для C++. Создание полноценного парсера является сложной задачей, поэтому, как правило, не все конструкции C++ поддерживаются такими предварительными обработчиками. Представителями такого подхода являются: ParSyc [9], KaSCPar [11], sc2v [8], BSSC based [17], SystemPerl [20]. К проектам, использующим существующие предварительные обработчики C++, относятся: SystemCXML [3], Quiny [18], Pinapa [15], PinaVM [13], Scoot [5], Dust [12], SystemCASS [7]. Предварительные обработчики для SystemC делятся на статические, динамические и гибридные. Статический анализ позволяет распознавать конструкции языка. Статическим анализом кода можно построить архитектуру модели, но статический анализ позволяет работать только с моделями с относительно простой архитектурой. К проектам, основанным на статическом подходе, относятся 108 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 106. 4 все проекты со своим собственным парсером языка, а также SystemCXML и Scoot. Динамический подход основан на выполнении откомпилированной программы, в частности на выполнении фазы разработки модели. С помощью ее выполнения также можно получить архитектуру модели. При выполнении программы собираются данные, которые генерируются во время выполнения. Так как некоторым инструментам требуется только архитектура, они могут использовать динамический подход. Такие инструменты позволяют искать информацию в архитектуре, но не знают ничего о поведении процессов. К проектам, основанным на динамическом подходе, относятся Quiny, Dust, SystemCASS. Перед предварительным обработчиком SystemC стоит задача построить архитектуру системы, а также распознать происходящие в архитектуре взаимодействия между модулями и процессами. Причем необходимо организовать связь между архитектурой и этими взаимодействиями. С этой задачей достаточно успешно справляется гибридный подход, являющийся комбинацией статического и динамического подходов. Существуют проприетарные решения, предлагаемые компаниями Synopsys и Semantic Designs. Эти решения основаны на статическом анализе и отлично распознают конструкции языка SystemC. Так как их разработка является закрытой, они здесь не рассматриваются. В [14,13] был проведен сравнительный обзор функциональности нескольких предварительных обработчиков, которые были доступны на тот момент. Сравнение производилось на ряде тестовых примеров. В таблице 1 приведены полученные результаты, которые показывают, что на данный момент не существует универсального средства верификации SystemC-моделей. 3 Предлагаемый подход для верификации SystemC-моделей Как мы уже видели, использование предварительных обработчиков не позволяет учитывать все нюансы SystemC-моделей. Это по-видимому является врожденным недостатком всех методов, которые основаны на парсинге исходного кода SystemC-программы с целью получения формальной модели, пригодной для верификации. Наш подход основывается на методе CMC (C Model Checking) [16], который при помощи внесения изменений, не влияющих на семантику SystemC-программы, позволяет строить эту формальную модель во время ее выполнения. 3.1 Метод верификации CMC Метод CMC [16] позволяет автоматически создавать формальную модель из C/C++ кода, которую можно верифицировать с помощью метода проверки модели (model checking). Так как SystemC это библиотека для языка C++, то можно использовать средства, разработанные для анализа кода на C++. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 109
  • 107. PinaVM Pinapa SystemCXML KaSCPar Quiny Scoot SystemPerl sc2v 5 elab-only elab-easy elab-easy-int elab-easy-uint elab-easy-array elab-easy-sc_stop elab-port-bool elab-pointer elab-instances elab-clock signal event fifo RAM 6 6 6 6 6 6 6 4 6 6 6 6 3 6 6 6 6 6 6 6 6 4 5 3 4 6 0 2 6 6 6 6 0 6 0 0 0 6 0 6 0 6 6 1 1 1 1 1 1 0 1 1 0 1 0 0 5 5 3 3 2 3 2 2 2 3 0 2 0 0 6 6 6 6 1 3 2 0 3 5 5 6 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 2 2 2 0 3 0 0 0 3 0 2 0 0 Таблица 1. Сравнительный анализ функциональности нескольких предварительных обработчиков SystemC-моделей. Обозначения: 6 пример может быть проанализирован; 5 пример может быть проанализирован, но с небольшим изменением теста; 4 пример проанализирован лишь частично; 3 пример не может быть проанализирован, но требуется незначительная доработка проекта; 2 пример не может быть проанализирован и требуется значительная доработка проекта; 1 пример не может быть проанализирован по неизвестной причине; 0 пример не может быть проанализирован из-за ограничений подхода. Так как исходный код Стэндфордской реализации метода CMC является закрытым, нам пришлось написать свою реализацию с учетом специфики SystemC-моделей. Каждая система в CMC моделируется в виде взаимодействующих процессов. Такие процессы выполняют код реализации системы в контексте верификации модели. Программа, реализующая метод CMC и содержащая все процессы, работает в операционной системе как единый процесс. Многопоточные объекты могут моделироваться как процессы, содержащие любое количество потоков выполнения. Поток имеет доступ к глобальным переменным и куче процесса, в котором он выполняется. Процессы могут обмениваться информацией через специальную общую память, выделенную для всех процессов одновременно. Состояние потока состоит из его стека и содержимого регистров процессора. Состояние процесса состоит из копии своих глобальных переменных, содержимого кучи и состояния всех его потоков. Состояние системы это совокупность состояний процессов и общей памяти. 110 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 108. 6 CMC позволяет настраивать график запуска потоков, что, в свою очередь, позволяет получать разное поведение системы. Переход системы это выполнение детерминированного, атомарного шага, который изменяет состояние системы. Переход выполняется с передачи контроля потоку и до вызова специально определенной в CMC функции cmc_yield(), которая внедряется в исходный код исследуемой программы согласно решению разработчика и его пониманию этой программы. Так как переходы являются атомарным шагом, они определяют степень чередования выполнения параллельных потоков, и разработчик должен решить, как должны выполняться потоки, чтобы желаемые свойства были проверены. После того, как реализация будет представлена в виде процессов и потоков и определятся соответствующие системе переходы, в реализацию необходимо добавить модель среды. Под средой здесь подразумеваются все внешние объекты, с которыми взаимодействует система (человек, сеть, файловая система и так далее). Важной частью среды являются входные данные. Обычно система объединяется с другими компонентами в более сложную систему. Чтобы минимизировать затраты на моделирование среды ряд компонентов предлагается сделать универсальными, чтобы использовать в разных задачах. Поведение системы является недетерминированным. Оно может зависеть, например, от следующих факторов среды: порядок получения системой входных данных, различные значения входных данных, порядок запланированного запуска потоков. Чтобы смоделировать недетерминированность поведения, в CMC используется функция cmc_choose(int n), которая внедряется разработчиком в части кода, где есть необходимость проверки недетерминированного поведения. Она возвращает случайное число в диапозоне от 0 до n - 1. Использовать эту функцию можно, предоставив каждому значению возвращаемого значения уникальное поведение системы. При реализации метода CMC каждое из поведений будет рассмотрено. Например, удобно написать функцию динамического выделения памяти, которая будет либо выделять, либо не выделять память в зависимости от значения cmc_choose(). Таким образом, будет рассмотрено оба случая: поведение системы при корректном выделении памяти и поведение системы, при котором происходит ошибка при выделении по каким-либо причинам. Важной причиной недетерминированного поведения является параллельное выполнение процессов в системе (параллельность системы). Выполнение потоков в системе может произвольно чередоваться. CMC реализует этот недетерминизм контролем за расписанием запуска потоков в модели. Многократные чередования CMC исследует, задавая различные расписания запуска потоков. Модель, построенная из реализации системы, вместе с моделью среды доступна для соединения с CMC. CMC начинает контролировать выполнение этой модели, исследуя по мере выполнения состояния на выполнение в них заданной спецификации. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 111
  • 109. 7 СМС это метод верификации модели, который создает пространство состояний посредством прямого исполнения реализации системы (на языке С/С++). СМС генерирует граф достижимых состояний системы при помощи его обхода в глубину или в ширину. Если граф обходится в ширину, интересным развитием алгоритма является эвристический анализ предпочтительности состояний в очереди. Выбирая из очереди наиболее интересные состояния, мы добьемся большей эффективности процесса верификации, особенно если исчерпывающее построение множества достижимых состояний не представляется возможным. Для того чтобы производить обход графа состояний, необходимо уметь сохранять состояния модели и возвращаться к ним. Чтобы выполнять эти действия, необходимо уметь их выполнять со всеми составными частями состояния модели. Во время верификации системы методом CMC граф состояний может начинать экспоненциально расти. Количество состояний может становится чрезмерно большим (или даже являться бесконечным) для обработки. Эта проблема известна как проблема взрыва состояний. Чем больше граф, тем быстрее кончатся ресурсы компьютера, необходимые для процесса верификации. Несмотря на разные подходы к ее решению, она остается довольно серьезной проблемой. СМС использует различные подходы эффективного обхода пространства состояний. CMC может проверять свойства безопасности (safety), но не может проверять свойства живости (liveness). Свойства безопасности составляют большой класс интересных для верификации свойств, к тому же свойства живости в графах с конечным количеством состояний могут быть выражены в виде свойств безопасности. Специализированные свойства отслеживаются с помощью вызовов функции assert(). Разработчик вставляет функции проверки так, чтобы каждое новое состояние было проверено на свойства. 3.2 Верификация SystemC-моделей c использованием метода CMC Модель, написанная на языке SystemC, представляется в CMC в качестве процесса. Если для верификации необходимо взаимодействие нескольких моделей, все они представляются в качестве отдельных процессов. SystemCпроцессы (SC_METHOD и SC_THREAD) выполняют роль CMC-потоков, то есть при обходе графа достижимости они будут выполнять переходы между состояниями. Переходы выполняются с момента передачи управления SystemCпроцессу и до момента его окончания, или, в случае SystemC-потока, до момента его откладывания. Во время фазы инициализации производится формирование начального состояния графа. Далее выполняется алгоритм обхода с начального состояния, пошагово исполняя код программы. Если какая-то из ветвей графа приведет к завершению фазы вычислений, то осуществляется фаза постобработки и завершение выполнения этой ветви. 112 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 110. 8 Состояние графа должно хранить состояние всей модели, в том числе значение времени, состояние SystemC-процессов и состояние других объектов библиотеки. Новые типы CMC сможет сохранять и восстанавливать, потому что эти типы представляют собой обычные классы языка C++. Во время обхода графа для рассматриваемого состояния генерируются его состояния-потомки. В некоторых случаях генерируется только одно состояние: когда состояние системы может лишь детерминировано перейти в другое, используя единственный доступный переход. В остальных случаях генерируется несколько состояний. Это происходит, когда CMC может использовать более одного перехода, а именно: в случаях параллельного выполнения SystemC-процессов, в случаях различного поведения среды модели, в случаях какого-либо иного недетерминированного поведения модели. Среда для SystemC-модели зависит от самой модели и разрабатывается точно так же, как и в случае немодифицированного C/C++ кода. Для нашей реализации метода CMC ключевой задачей является способ сохранения и восстановления состояния SystemC-модели. От этого зависит корректность работы верификатора, скорость его работыа также насколько экономно будут расходоваться ресурсы компьютера. Для сохранения состояния программы можно использовать два способа. Первый способ предполагает сериализацию значений переменных (сохранение состояния) внутри кода модели с последующей десериализацией (восстановление состояния). Второй способ напротив сохраняет снимок состояния модели как программы с помощью сторонних средств. В исходном коде SystemC существует класс sc_simcontext, отвечающий за хранение всех объектов, использующихся в SystemC-модели. Если сохранить и восстановить объект этого класса в момент выполнения модели перед запуском новой итерации фазы вычислений, теоретически можно достигнуть желаемого результата и добиться более быстрой работы, чем при втором способе. Важным моментом является то, что сохранение класса по сути является глубоким копированием: копированием объекта с выделением под него нового участка памяти, а не копированием лишь указателей на переменные. В C++ не существует ни стандартных средств глубокого копирования, ни сторонних библиотек, которые позволили бы выполнить такую операцию. Другой подход к сохранению и восстановлению состояний основан на использовании контрольных точек. Контрольная точка снимок состояния приложения, хранящий всю необходимую информацию для того, чтобы можно было восстановить работу приложения с сохраненного состояния. Чаще всего контрольные точки используются для резервного хранения состояний [6]. Существует ряд проектов для операционной системы Linux, позволяющих создавать контрольные точки приложений. Среди них: BLCR, DMTCP, CRIU, Cryopid, OpenVZ. Нами был выбран DMTCP [2], так как проект стабилен и выполняет все необходимые функции. В частности, в отличие от BLCR, DMTCP поддерживает сокеты (программный интерфейс для обес- Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 113
  • 111. 9 печения информационного обмена между процессами). Это важно, так как разработанный верификатор взаимодействует с исследуемой моделью через сокеты. Программный пакет DMTCP позволяет организовать ⌧прозрачное� создание контрольных точек для многопоточных и распределенных программ. Пакет реализован на уровне системных библиотек операционной системы Linux и не требует модификаций ядра этой ОС. DMTCP позволяет обеспечить формирование контрольных точек и восстановление из них для таких программ, как: OpenMPI, MATLAB, Python, Perl. Он поддерживает различные языки программирования, включая скриптовые языки. Нами было разработано программное средство SCMC (SystemC Model Checker), которое представляет собой программу, позволяющую выполнять SystemC-модель всеми возможными способами и оповещать пользователя о достижении определенных условий при выполнении. Она хранит граф состояний модели и выполняет направляющую роль. Для языка SystemC предусмотрено дополнение, необходимое для указания в модели точек, в которых SCMC будет разветвлять выполнение модели. После запуска SCMC происходит ожидание запуска SystemC-модели. Как только модель запустилась, SCMC ожидает от нее сообщения чтобы начать генерировать граф достижимых состояний. Интерфейс дополнения для SystemC-моделей содержит ряд методов, которые разработчику необходимо внедрить в свою модель. Метод SendCheckpointAndWait отправляет в SCMC сообщение о месте разветвления выполнения. Каждая ветвь определяется целочисленным значением, которое возвращает метод. В зависимости от значения модель осуществляет ту или иную работу, это настраивается вручную сразу после вызова метода. Номер ветви лежит в диапазоне [0, N], где N максимальный номер ветви. Метод принимает аргументы: максимальный номер ветви и аннотацию состояния модели в данный момент в виде строки, которую пользователь формирует по своему усмотрению вручную. Состояние модели представляет из себя строку из значений переменных, совокупность которых точно определяет состояние. Важно учесть все необходимые переменные, иначе может возникнуть ситуация, когда два разных состояния SCMC примет за одинаковые и ошибочно отсечет целую ветку исполнения. После сохранения состояния модель завершает работу. SCMC восстанавливает новое состояние из очереди. SendAssertMessage отправляет в SCMC сообщение о выполнении свойства. Аргументом метода является сопутствующее сообщение, которое будет выведено в файле с результатами. SendExitMessage отправляет в SCMC сообщение о завершении работы модели.Этот метод может быть вызван в конце работы модели, чтобы SCMC мог перейти к рассмотрению следующего в очереди состояния. Для сохранения и восстановления состояния модели используется DMTCP. Физически на жесткий диск состояние сохраняется в момент отправления сообщения о месте разветвления, причем для всего набора добавляемых со- 114 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 112. 10 стояний с разными номерами ветви для восстановления используется один и тот же файл с состоянием программы, что экономит память. В SCMC реализован в целом похожий на CMC алгоритм, граф достижимых состояний обходится в ширину. В принципе реализация не ограничивает работу SCMC исключительно языком SystemC, верификатор также может работать с любой другой программой на языке C++, которая сохраняется и восстанавливается DMTCP. 4 Экспериментальные результаты Эксперименты проводились с моделью, которая распространяется вместе с пакетом SystemC. Она описывает передачу данных от отправителя получателю через канал связи, представленный в виде очереди ограниченной длины. Канал связи допускает только потерю символов. Передаваемая строка задается заранее. Получатель может принимать в один момент времени только один символ, а остальные ожидают в канале. В эксперименте проверяется свойство, может ли получатель последовательно принять два одинаковых символа подряд. Эксперименты проводились на компьютере с процессором Intel Core i3-2310M. В модель с помощью разветвления выполнения модели добавлена возможность потери любого символа при передаче. Метод, сообщающий о разветвлении, срабатывает непосредственно перед передачей символа в канал. В сообщении передается максимальный номер ветви, равный единице, и информация о состоянии, которая включает в себя историю переданных получателю символов, номер следующего символа в очереди канала, список хранящихся в канале символов и оставшаяся для передачи в канал строка на отправителе. Это тот минимальный набор информации, который позволяет идентифицировать состояние модели единственным образом для данной задачи. Так как SystemC ведет себя детерминированно, нет опасности пропустить новые состояния при отсечении повторяющихся состояний. Каждый новый принятый получателем символ сравнивается с предыдущим. Если они совпадают, в SCMC отправляется сообщение о выполнении проверяемого свойства. В результате исследования модели можно заключить, что предложенный метод работоспособен. Каждое состояние модели занимает на жестком диске примерно 2 Мб, сохранение и восстановление занимает порядка 0.5 секунды. Оперативная память на хранение информации о состояниях практически не расходуется. В таблице 2 приведены результаты, показывающие скорость работы с различными входными данными. Длина очереди канала несущественно влияет на подсчет затраченного времени, поэтому для нее во всех тестах установлено значение 10. Время работы может варьироваться на одних и тех же входных данных из-за особенностей DMTCP. Если вернуться к таблице 1 (предпоследняя строка), проверка моделей с очередями плохо поддается верификации среди известных подходов, но с описанным в данной работе методом такая проверка становится возможной. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 115
  • 113. 11 11 Передаваемая строка Кол-во выполненных условий Кол-во состояний Затрачено (сек) Передаваемая строка Кол-во выполненных условий Кол-во состояний Затрачено (сек) aaa 3 14 7 aaa cac 1 3 16 14 7 7 cac abc 0 1 16 16 6 7 abc 0 16 aaaaa 5 26 12 6 aaaaa cabac 5 5 60 26 27 12 cabac abcde 0 5 64 60 28 27 abcde 0 64 aaaaaaa 7 38 19 28 aaaaaaa cababac 29 7 164 38 84 19 cababac 29 164 abcdefg 0 256 121 84 abcdefg aaaaaaaaa 9 0 50 256 28 121 aaaaaaaaa cabababac 69 9 332 50 193 28 cabababac 332 abcdefghi 0 69 1024 480193 abcdefghi 0 1024 480 Таблица 2. Производительность метода SCMC Таблица 2. Производительность метода SCMC 5 5 Заключение Заключение Целью этой работы было создание формального верификатора для SystemCЦелью который позволил бы проверять непосредственно саму SystemCмоделей, этой работы было создание формального верификатора для SystemCмоделей, который позволил бы проверять непосредственно саму SystemCмодель без ее трансляции в язык одного из существующих верификаторов. модель без ее такого верификатора был выбран метод CMC, исследуюДля реализации трансляции в язык одного из существующих верификаторов. Для реализации такого всех возможных выбран выполнения. Метод щий программу переборомверификатора былпутей ее метод CMC, исследующий программу перебором всех возможных путей ее выполнения. Метод предполагает необходимость сохранять и восстанавливать состояние пропредполагает необходимость сохранять и восстанавливать состояние граммы, что в данном случае делается с использованием пакета DMTCP. программы, что в выполнения задачи был суспешно создан желаемый форВ результате данном случае делается использованием пакета DMTCP. В результате выполнения задачи был успешно создан желаемый формальный верификатор, названный SCMC. В отличие от существующих вемальный верификатор, названный SCMC. В отличие от существующих рификаторов SystemC используемый подход позволяет охватить все множе- верификаторов SystemC используемый подход позволяет охватить все множество SystemC-моделей. Для проведения верификации в исследуемой SystemCство должны быть указаны контрольные точки, где производится ветвлемоделиSystemC-моделей. Для проведения верификации в исследуемой SystemCмодели должны быть указаны контрольные точки, где производится выние модели, либо проверяется желаемое свойство. Пользователю будутветвление модели, либо проверяется желаемое свойство. Пользователю будут ведены все случаи выполнения заданного свойства модели, а такжебудут выведены пути исполнения модели, приведшие к выполненному также будут выведены все случаи выполнения заданного свойства модели, асвойству. выведены пути исполнения модели, приведшие к выполненному свойству. Существует проблема взрыва состояний, частично решаемая исключеСуществует проблема взрыва состояний, частично решаемая исключением одинаковых веток графа состояний. Для экономии памяти в будущем нием одинаковых веток графа состояний. контрольных точек SystemCможно будет добавить инкрементное сжатиеДля экономии памяти в будущем можно будет добавить инкрементное ускоряющие его работу. моделей, также разработать алгоритмы, сжатие контрольных точек SystemCмоделей, также разработать алгоритмы, ускоряющие его работу. Список литературы Список литературы 1. Кулямин В.В. Методы верификации программного обеспечения // Всероссийский конкурсный отбор обзорно-аналитических статей по приоритетному на1. Кулямин В.В. Методы верификации программного обеспечения // Всероссийправлению ⌧Информационно-телекоммуникационные системыприоритетному наский конкурсный отбор обзорно-аналитических статей по �, 2008, 117 с. 2. Ansel J., Arya ⌧Информационно-телекоммуникационные системы�, for Clusterс. правлению K., Cooperman G. DMTCP: Transparent Checkpointing 2008, 117 Computations and the Desktop // 23rd IEEE International Parallel and Distributed 2. Ansel J., Arya K., Cooperman G. DMTCP: Transparent Checkpointing for Cluster Processing Symposium (IPDPS’09). Rome, Italy. May, 2009. Parallel and Distributed Computations and the Desktop // 23rd IEEE International Processing Symposium (IPDPS’09). Rome, Italy. May, 2009. 116 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 114. 12 3. Berner D., Talpin J.-P., Patel H., Mathaikutty D.A., Shukla E. SystemCXML: an extensible SystemC front end using XML // Proc. of the Forum on specification and design languages (FDL), 2005. 4. Black D.C., Donovan J. SystemC: from the ground up // Kluwer Academic Publishers 2004. 263 p. 5. Blanc N., Kroening D., Sharygina N. Scoot: A tool for the analysis of SystemC models // Proc. of TACAS, 2008, pp. 467–470 6. Bronevetsky G., Marques D., Pingali K., Szwed P., Schulz M. Application-level Checkpointing for Shared Memory Programs // Proc. of the 11th international conference on Architectural support for programming languages and operating systems, 2004. pp. 235–247.. 7. Buchmann R., Petrot F., Greiner A. Fast cycle accurate simulator to simulate eventdriven behavior // Proc. of Electrical, Electronic and Computer Engineering, 2004. ICEEC ’04. 2004, Cairo, Egypt. pp. 35–38 8. Castillo J., Huerta P., Martinez J.I. An open-source tool for SystemC to Verilog automatic translation // Lat. Am. appl. res. v.37 n.1. 2007. p. 53-58. 9. Fey G., Große D., Cassens T., Genz C., Warode T., Drechsler R. Parsyc: An efficient SystemC parser // Workshop on Synthesis And System Integration of Mixed Information technologies (SASIMI), 2004, pp. 148–154. 10. Grotker T., Liao S., Martin G., Swan S. System design with SystemC // Kluwer Academic Publishers 2002. 219 p. 11. KaSCPar. http://forge.greensocs.com/ja/Projects/KaSCPar 12. Klingauf W., Geffken M. Design structure analysis and transaction recording in SystemC // Proc. of FDL, 2006, pp. 169–177 13. Marquet K., Moy M. PinaVM: a SystemC front-end based on an executable intermediate representation // International Conference on Embedded Software, Scottsdale, USA, 2010. pp. 79–88 14. Marquet K., Moy M., Karkare B. A theoretical and experimental review of SystemC front-ends // Verimag Research Report TR-2010-4. 2010. 14 p. 15. Moy M., Maraninchi F., Maillet-Contoz L. Pinapa: an extraction tool for SystemC descriptions of systems-on-a-chip // EMSOFT ’05: Proceedings of the 5th ACM international conference on Embedded software. New York, NY, USA: ACM, 2005, pp. 317–324. 16. Musuvathi M., D.Y.W. Park, A. Chou, D.R. Engler, D.L. Dill CMC: a pragmatic approach to model checking real code // Proc. of OSDI 02: Fifth Symposium on Operating Systems Design and Implementation, 2002. pp. 75–88 17. Scarpazza D.P., Brandolese C., Pomante L., Felice P.D. Parsing SystemC: an open-source, easy-to-extend parser // IADIS International Conference on Applied Computing, 2006, pp. 25–28 18. Schubert T., Nebel W. The Quiny SystemC front end: self-synthesising designs // Proc. of FDL. ECSI, 2006, pp. 135–143. 19. Singh L., Drucker L., Khan N. Advanced verification techniques: a SystemC based approach for successful tapeout / Kluwer Academic Publishers, 2004. 373 p. 20. SystemPerl. http://www.veripool.org/wiki/systemperl. 21. Vardi M. Formal techniques for SystemC verification // Design Automation Conference (DAC) 2007. San Diego, California. June 4–8, 2007. p. 188–192. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 117
  • 115. Унифицированная высокоуровневая модель программно-аппаратной системы для верификации свойств надежности функционирования 1 С.Л. Френкель1 , В.Н.Захаров1, В.Г. Ушаков2 1 Институт проблем информатики РАН, Вавилова 44, корп. 2, Москва, РФ (fsergei@mail.ru, VZakharov@ipiran.ru) 2 Московский гос. университет им. М.В. Ломоносова, Институт проблем информатики РАН ( Ushakov@akado.ru ). Аннотация. В статье приводятся некоторые результаты исследования и разработки алгоритмов и программ, позволяющих комбинировать решение различных задач функциональной верификации с анализом вероятностей проявления и компенсации сбоев в системе, представленной автоматной моделью, получаемой в результате синтеза системного уровня по ASMспецификации проекта. Ключевые слова: Верификация, отказоустойчивость 1. Введение Разработчику программно-аппаратных систем на ранних этапах проектирования приходится сталкиваться с такими разными задачами как функциональная верификация проекта для проверки возможности реализации системой специфицированных (требуемой исходной спецификацией) функций, помехоустойчивости относительно определенных классов помех, производительности. Все эти задачи требуют различных подходов к их решению, с использованием разных математических моделей и проектных инструментов. В целом эти задачи трудоемки, требуют привлечения высококвалифицированного персонала и дорогостоящих средств проектирования. Ввиду крайне большого объема данных, необходимых для исчерпывающего решения указанных задач через моделирование (simulation) проектируемых объектов, большие усилия прилагаются для использования формальных методов верификации. Общим требованием к формальной модели является ее способность использовать различные уровни абстракции, возможность добавлять постепенно те или иные аспекты реализации (например, микроархитектуру), то есть иметь возможность использовать иерархический стиль проектирования. 1 Работа выполнена при частичной поддержке грантов РФФИ № 12-07-00109 и 13-07-00579. 118 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 116. При этом одним из путей снижения трудовых и финансовых затрат на верификацию может быть интеграция различных подходов и методов, позволяющих использовать одни и те же инструменты и исходные формализованные описания (input) для возможно большего числа задач. В статье излагается возможный интеграционный подход. 2. Унифицирующие свойства моделей цифровых систем С точки зрения унификации подходов к различным задачам верификации для нас представляют интерес два способа описания систем на высоком уровне абстракции, для которых в литературе используют одну и ту же аббревиатуру, но разные названия и смысл, а именно Abstract State Machine [1,2] и Algorithmic State Machine [3]. Для удобства изложения мы будем использовать AbSM в первом случае и ASM во втором. Abstract State Machine, рассматриваемая в настоящее время как унифицированная модель вычислений, представляет собой систему переходов, реализующих конечное множество т.н. правил переходов (transition rules) вида if Condition then Updates, где Condition - некоторый предикат на указанном множестве, Updates - конечное множество операторов (assignments) вида f (t1, . . . , tn) := t, чье выполнение приводит к параллельному изменению значений аргументов функции f и получению ее значения на данном измененном наборе аргументов. Благодаря тому, что AbSM позволяет описывать изменения (переходы) абстрактных данных для произвольных множеств и функций, они могут быть использованы на различных иерархических уровнях описания проектируемой системы, что соответствует различным этапам проектирования. Ввиду возможности задания времени переходов [4], данная модель может быть использована как для функциональной спецификации, так и для получения временных характеристик выполнения задач, т.е. для анализа производительности. Это, очевидно, означает, что AbSM можно рассматривать как соответствующее средство интеграции различных задач проектирования. Однако указанная абстрактность означает необходимость использовать различные конверторы данных для перехода с уровня на уровень. Поэтому в наших работах мы использовали также другой формализм, основанный на “алгоритмических машинах состояний” (ASM) [3]. В самом общем виде ASM можно определить как направленный связанный граф, вершины которого соответствуют операциям, выполняемым на каждом шаге описываемого алгоритма, или условным переходам, а дуги задают последовательности выполнения операций. Пример и все необходимые пояснения приводятся в разделе 3.2. Подробное описание можно найти в [5]. Предложенная нами унификация спецификаций различных аспектов функционирования цифровой системы основана на использовании ASMспецификаций, по которым выполняется высокоуровневый синтез цифровых схем, для более широкого круга задач проектирования. Например, такая спецификация может быть использована для формальной верификации функциональной корректности, для оценки временной корректности на уровне взаимодействий и протоколов, для оценки помехоустойчивости разрабатываемых архитектур. Показано, что ASM-спецификация, при Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 119
  • 117. использовании разработанных в ИПИРАН программ генерации SMV и Spinкодов и программ моделирования цепей Маркова [7], может выполнять интегрирующую (унифицирующую) функцию при высокоуровневом синтезе [7]. Программы SMV (Symbolic Model Verifier) [18] и Spin [19] предназначены для верификации проектов методом Model Checking аппаратных (SMV) и программных (Spin) систем. Эта возможность обеспечивается тем, что для обоих классов задач верификации (функциональной и отказоустойчивости) используются одни и те же автоматные модели [7]. Существенным является также то, что при использовании для трансляции ASM-диаграмм программы синтеза цифровых систем Abelite [3] мы получаем структуру Крипке [5], позволяющую перебирать все возможные варианты работы верифицируемой системы, т.е. описывать недетерминированность ее поведения. Получаемое из ASM автоматное представление моделируемой системы выглядит следующим образом: { am, fms(xi1,,…,xik), as, Y}, (1) где am, as - текущее и следующее состояние автомата, fms(xi1,,…,xik) - функция возбуждения автомата (булевы выражения относительно входных переменных, определяющие условия переходов), и Y - вектор выходов. Это представление совместно со структурой Крипке позволяют осуществлять интерпретацию системных элементов на любых уровнях абстракции [5]. 3. Интеграция моделей и инструментов, предназначенных для решения задач функциональной верификации и оценки помехоустойчивости цифровых систем на ранних этапах проектирования В настоящее время мы имеем определенный опыт использования ASM спецификаций для верификации различных проектируемых объектов, причем не только самих проектируемых систем, но и их верификационных тестов. Например, ASM использовалась для описания тестов верификации (через моделирование) проекта некоторого процессора. Неформально говоря, тесты представляют собой набор некоторых команд и данных, которые могут выполняться либо строго поочередно (очередную операцию можно подавать на выполнение только после того, как полностью завершена предыдущая), либо, в случае конвейерного выполнения операций, операции можно подавать последовательно друг за другом, не дожидаясь завершения предыдущей операции, либо одновременно могут подаваться несколько операций. Так как число операций может быть достаточно велико (несколько сотен), тест должен быть верифицирован на выполнение указанных условий упорядоченности, т.е. тестовое множество должно быть организовано таким образом, чтобы выполняемые операции не вступали в конфликты друг с другом, при том, что возможно взаимное влияние операций (например, ввиду использования одного и того же буфера данных). Очевидно, что если выполнение этих тестов описать как переходы некоторого автомата, или нескольких определенным образом связанных автоматов, то для проверки этих условий хорошо подходит метод Model 120 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 118. Checking [8], состоящий в формальной проверке выполнения логической формулы, выражающей некоторое свойство “правильного” поведения модели системы. Автоматы Мили, необходимые для построения соответствующей модели системы, могут быть получены из ASM диаграмм выполнения множества тестов с использованием свойств декомпозируемости и иерархичности ASM-описаний (из-за ограниченного объема статьи детали здесь не приводятся). В качестве другой задачи, решаемой на основе высокоуровневой ASMспецификации проекта, рассмотрим возможность учета требований помехоустойчивости на ранних этапах проектирования. 3.1 Проблема верификации помехоустойчивости проектируемых цифровых систем на ранних этапах проектирования По сути современное проектирование цифровых систем состоит в поиске компромисса между надежностью выполнения функциональных задач, производительностью и потреблением энергии. Причем существенной составляющей данной проблемы является обеспечение правильной и эффективной работы в условиях действия переходных помех, прямое действие которых ограниченно лишь сравнительно небольшим интервалом времени. Поэтому ошибки функционирования, вызываемые помехами, называются “мягкими” (soft) [8]. Важным примером является воздействие ионизированных частиц, порождаемых космическими лучами. В настоящее время известно много способов защиты цифровых схем от действия различных внешних помех. Однако их применение связано с дополнительными аппаратурными и энергетическими затратами (повышением потребления электроэнергии), а также с возможным снижением производительности, как за счет увеличения суммарных задержек в дополнительных элементах (вентилях, элементах памяти), так и за счет необходимости ограничений скорости работы процессорных элементов. Дело в том, что энергопотребление растет примерно как квадрат частоты переключений, и это может лимитировать объем резервирования, например, изза роста энергозатрат резервирующего оборудования. Все эти обстоятельства делают актуальной задачу выбора минимально необходимого числа элементов, защита (protection) которых необходима для обеспечения требуемого уровня надежности в присутствии т.н. SEU (single event upset, одиночных сбоев, то есть кратковременных событий, представляющих собой ошибочное изменение значения логического сигнала (переменной) в некоторой точке системы), возникающих под действием указанных выше внешних факторов (лучей, частиц и т.д. ). В настоящее время предложен и активно развивается подход к определению критичных к действию помех элементов, которые необходимо обеспечить той или иной аппаратной защитой, с использованием формальных методов, Model Checking прежде всего [8]. Этот метод используется совместно с инжектированием в модель проектируемой системы возможных мутаций внутренних состояний. Этим способом определяют триггеры–защелки [8], Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 121
  • 119. которые могут эффективно влиять на результат вычислений, и которые поэтому следует защищать от ошибок (ошибочного изменения состояний). Преимущества Model Checking по сравнению с просто моделированием (симуляцией) модели устройства в присутствии инжектированных неисправностей состоит в том, что устраняется проблема обеспечения репрезентативности выбираемых входов (команд и данных), которые могут отобразить все возможные рабочие ситуации. Model Checking выполняет исчерпывающий анализ всех состояний системы, начиная с множества возможных начальных состояний. Этот подход рассматривают и пытаются использовать не только как дополнение к известным процедурам формальной верификации функциональных свойств проектов цифровых устройств, но и как средство оценки полноты анализа надежностных свойств, и как средство анализа результатов с точки зрения снижения избыточности при обеспечении помехоустойчивых решений [11]. Хотя указанные выше помехи (лучи, частицы) непосредственно влияют на те или иные элементы оборудования (оперативную память, шины кэш), вызывая SEU, они приводят и к программным ошибкам. С программноаппаратной (архитектурной) точки зрения эти ошибки в программе могут распространяться по управлению (control flow) и данным (data flow). Очевидно, что непосредственную связь указанных аппаратных сбоев реально можно установить (описать) только со сравнительно низкоуровневым представлением программ, например, на уровне машинных кодов или ассемблера. Существенным, однако, является то, что указанные формальные подходы к верификации устойчивости проектируемой системы к конкретному SEU [8] указывают лишь на потенциальную возможность того, что в данной точке может быть нарушено правильное функционирование проектируемого устройства, но реальное нарушение функционирования может зависеть от статистических свойств обрабатываемой информации, например, переменных fms(xi1,,…,xik) в функции, представленной в структуре ASM (1). При этом переходные ошибки, индуцированные SEU на некотором такте работы устройства, не обязательно запоминаются в элементах памяти на следующих тактах, что можно интерпретировать как самовосстановление устройства (selfhealing). Поэтому желательно было бы дополнить формальную верификацию вычислением вероятностей такого самовосстановления. Рассмотрим для этой цели вероятностную модель, предложенную в [6,9], важным свойством которой является возможность ее использования для уточнения выводов о рисках, связанных с SEU для конкретных переменных программы, полученных формальными методами, используя Model Checking [8]. 3.2 Вероятностная модель Разработана следующая модель для вычисления распределения вероятностей времени до самовосстановления после действия SEU. Пусть в начальный момент 0 под действием помехи (разовой) автомат X (называемый исправным, fault-free) переходит в состояние Y0 вместо состояния X0 (при этом предполагается, что действие помехи в выходном сигнале не проявилось). 122 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 120. Будем называть автомат, подвергшийся действию помехи, “неисправным” (faulty), и обозначать его как Y. Неисправный автомат Y действует на тех же входных сигналах с теми же переходами и выходными сигналами в зависимости от текущих состояний и входных сигналов. Так происходит до того момента, когда либо выходной сигнал неисправного автомата окажется отличным от выходного сигнала исправного автомата (проявилось действие помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Считая входные сигналы автоматов независимыми случайными двоичными переменными, на произведении этих автоматов (автомата, состояния которого равны различным парам состояний указанных двух автоматов) определяется Цепь Маркова (ЦМ) Zt=(Xt, Yt), описывающая совместное функционирование ЦМ Xt и Yt до момента, когда либо выходной сигнал неисправного автомата окажется отличным от выходного сигнала исправного автомата (проявилось действие помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Множества состояний S1,2, |S1,2| = n, обеих ЦМ одинаковы, начальные состояния X0, Y0, Y0 ≠ X0 детерминированы. Множество состояний ЦМ Zt представляет собой S = {(i,j), i,j = 1,…,n, j ≠ i}  A0  A1, где состояние (i,j) означает, что исправный автомат находится в состоянии i, а неисправный – в состоянии j (отличном от состояния i исправного автомата), состояние A1 – неправильное функционирование (в результате действия помехи) уже проявилась в выходном сигнале), и A0 – произошло восстановление траектории функционирования автомата до проявления эффекта помехи на выходе. Число состояний этой ЦМ равно n(n – 1) + 2. Состояния A0 и A1 представляют собой поглощающие состояния двумерной цепи Маркова Zt. Матрица P* переходных вероятностей ЦМ Zt вычисляется следующим образом. Пусть Zt находится в состоянии (i1,j1) и поступает входной сигнал x, переводящий ЦМ исправного автомата в состояние i2, а автомата, подвергшегося действию помехи, – в состояние j2, причем выходные сигналы автоматов y0 и y1. Тогда, возможны следующие ситуации: - если выходы y0 и y1 не совпадают, то ЦМ Zt попадает в поглощающее состояние A1; - если выходы y0 и y1 совпадают и совпадают состояния i2 и j2,то ЦМ Zt попадает в поглощающее состояние A0; - если выходные сигналы y0 и y1 совпадают, но не совпадают состояния i2 и j2 (в которые произошел переход обоих автоматом по действием входа x), то ЦМ Zt попадает в (i2,j2). Вероятности переходов вычисляются по известным вероятностям булевых значений независимых входных последовательностей, по известной булевой функции переходов f(xi1,…xin) (1). Подробнее алгоритм вычисления изложен в статье [6]. Введем обозначения: p(1)(t) – вероятность, того, что неисправное поведение автомата Y будет обнаружено (по выходу) не позже t-го шага (при этом до момента обнаружения неисправности автомат не восстановится); Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 123
  • 121. p(0)(t) – вероятность того, что автомат Y восстановит свое правильное поведение не позже t-го шага (до момента восстановления неисправность не проявится по выходу, т.е. выходы обоих автоматов будут полностью совпадать); pi,j(t) – вероятность попадания ЦМ Zt в состояние (i,j) (т.е. исправного автомата X в состояние i, неисправного автомата Y в состояние j ≠ i, при этом до момента t состояния исправного и неисправного автоматов будут различными, но выходные сигналы совпадать). В терминах ЦМ Zt вероятность p(0)(t) представляет собой вероятность нахождения в момент t в поглощающем состоянии A0, вероятность p(1)(t) – в поглощающем состоянии A1, вероятность pi,j(t) - в непоглощающем состоянии (i,j) (j ≠ i). Начальное распределение p(0) определяется начальными состояниями исправного и неисправного автоматов. Если исправный автомат в начальный момент 0 находится в состоянии i0, а неисправный – в состоянии j0 ≠ i0, то p(i0,j0)(0) = 1, а остальные координаты вектора p(0) равны нулю. Распределение ЦМ Zt в момент t может быть вычислено из уравнения: p(t ) p(t  1) P* p(0)( P*)t . Заметим, что мы считаем, что действие помех не приводят к появлению новых состояний в моделирующем автомате. Это предположение используется во многих работах по верификации устойчивости к действию помех [8,10, 11]. Рассмотрим применение данной модели к верификации устойчивости к сбоям конвейеризированного микропроцессора на стадии выборки инструкций из памяти. На рисунке 1 представлена соответствующая ASM-диаграмма режима, представляющая собой направленный граф с начальной вершиной Begin, финальной End, вершинами, соответствующими выполнению операций (прямоугольники) и условными вершинами (ромбы). Заметим, что “серые” вершины соответствуют вложенным ASM. Инструкции считываются в регистры IR1 (короткие инструкции) и IR2 (длинные), адреса инструкций – в PC (Program Counter). Сгенерированный программой Abelite соответствующий данной диаграмме конечный автомат (FSM) в форме Mealy имеет вид таблицы 1, входы, состояния и выходы в которой интерпретируются таблицей 2. Заметим, что строки Logical conditions, относящиеся к условным переходам, определяют входные переменные FSM. 124 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 122. Рис. 1 ASM диаграмма фазы выборки конвейеризированного процессора Таблица 1. Таблица переходов автомата, формирующего операции выборки инструкций am as X(am, as ) Y a1 a1 x8x4 y8 a1 a7 x8~x4 y6 a1 a1 ~x8 -- a2 a1 x1 y5 a2 a1 ~x1 y7 a3 a2 x3 y1 a3 a5 ~x3x2 y4 a3 a1 ~x3~x2x1 y5 a3 a1 ~x3~x2~x1 y7 a4 a3 1 y2 a5 a6 x7x5 y4 a5 a1 x7~x5 -- a5 a6 ~x7x6 y4 a5 a1 a6 a1 a7 a4 ~x7~x6 1 1 -y4 y3 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 125
  • 123. Таблица 2. Структура переменных автомата в терминах микроопераций процессора Micro Operations y1 : Fetch2 y2 : Fetch1 y3 : Int y4 : PCf:=PCf+1 y5 : Fetch2Oper2 y6 : CheckBranch y7 : Fetch2Oper1 y8 : DMACycle Logical Conditions x1 : ShLodInpBran_in_F x2 : bool2std(IR1f(0to3)=1100) x3 : IR1f(5) x4 : DMA x5 : FGO x6 : FGI x7 : IR1f(4) x8 : S : Пусть функциональную верификацию процессора планируется выполнить с помощью Model Checking, сравнивая поведение на уровне инструкций с поведением автомата в терминах микроопераций таблицы 2. Рассмотрим, например, выполнение следующего свойства: всегда, пока выполняется операция с DMA ((DirectMemory Access), фаза выборки ожидает ее окончания, чтобы избежать конфликтов. Как видно из таблиц 1 и 2, эти свойства связаны с выполнениями условий, задаваемых входными переменными x4, x8, и состояниями a1,a2. Тогда опасность (потенциальная возможность) неверного функционирования в результате SEU, приводящего к переключению того или иного бита, соответствующего переходу к неправильному состояния автомата, может быть также верифицирована с использованием стандартных средств верификации (SMV, Spin), задавая свойства, подлежащие верификации на том или ином языке CTL или LTL-типа (подробно этот вопрос рассматривается в [8]). Учитывая что описанный выше алгоритм построения цепи Маркова для переходов автомата под действием SEU использует целочисленное кодирование состояний, присвоим каждому состоянию ak, k=1,2..7, таблицы 2 значение его индекса. Конкретный SEU, приводящий к сбою на время такта, мы можем описать, как указано выше, задавая единичную вероятность в векторе начальных состояний 2-мерной цепи Маркова Zt . Тогда, назначив вероятности единичных значений переменным x1, ... x8, мы можем оценить вероятность перехода в состояние, при котором на начальном такте работы системы (t=0) выполняется операция DMAcycle до команды “S” (Start), представляющей собой начало вычислений. В предложенной выше нотации этот сбой представляется как (1,2). При распределении входных переменных{x1=0.9, x2=0.8, x3=0.45, x4=0.7, x5=0.65, x6=0.5, x7=0.7, x8=0.7)}, модель дает следующие значения вероятностей возвращения к правильному функционированию автомата таблицы 2 за соответствующее число тактов после 126 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 124. прекращения действия причины сбоя: SH = (0.0, 0.034, 0.46, 0.55, 0.64, 0.68). Скажем, через 4 такта вероятность будет 0.64, что, разумеется не позволяет считать этот сбой несущественным. Однако для сбоя (5,2) (ошибка заполнения программного счетчика) получаем SH = (0.00, 0.79, 0.79, 0,85, 0.89, 0.92, 0.93), что в ряде случаев (в зависимости от требований к быстродействию и надежности проектируемой системы) может быть приемлемым. Соответственно, у разработчика есть некоторая свобода выбора - пытаться ли ввести дополнительную аппаратную защиту данных переменных (например, используя Triple Modular Redundancy (TMR –защиту [17]) или же нет. Заметим, что мы используем для верификации те же средства Abelite, что и для синтеза реальных ASIC или FPGA, и поэтому каждый сбой, описанный на высоком уровне (сбой перехода автоматной переменной), можно связать с аппаратным блоком проектируемой системы, реализующим данный переход. 4. Направление дальнейших исследований Выше мы рассмотрели модель оценки помехоустойчивости для одного конкретного сбоя, специфицированного как (i,j) - ошибочный переход автомата в новое состояние j вместо i, определяемого спецификацией системы. Чтобы построить модель учета действия различных сбоев можно рассмотреть семейство марковских цепей с данной матрицей вероятностей переходов P, Zt,F = Pi, F, P для данного списка возможных сбоев F, задаваемых единицей (единичной начальной вероятностью) в ячейке (i,j) в векторе начального распределения вероятностей P0i , i=1,2,..,│F│, тогда как остальные ячейки – нулевые, как это описано в параграфе 3.2. Тогда [9] мы можем, используя формулу полной вероятности [13], выразить вероятность того, что за время t ни один из сбоев не приведет к ошибке функционирования автомата. Эта вероятность представляет собой характеристику устойчивости автомата, моделирующего проектируемое устройство, к указанному классу сбоев. При этом мы неявно предполагаем, что сбои наступают достаточно редко, и к началу некоторого сбоя (i,j), эффект действия предыдущего (k,l) полностью прекратился. Поэтому для учета вероятности (частоты) возникновения сбоев в настоящее время разрабатывается более общая модель. С методологической точки зрения предложенный нами подход представляет собой дополнение формальной верификации функциональных свойств вычислительной вероятностной моделью отказоустойчивости. При этом, хотя оба подхода используют общее входное описание в виде ASM, ряд данных приходится вводить независимо для каждой из моделей, а именно, свойства (property) на LTL или CTL для формальной верификации (хотя и с возможностью использования некоторых языковых конверторов, упрощающих для разработчика описание указанных свойств), и некоторые распределения вероятностей для оценки вероятности самовосстановления (раздел 3.2). Хотя соответствие (интерпретация) переменных автомата и элементов архитектуры проектируемой системы задается таблицами, подобными 1 и 2, для достаточно сложных систем, особенно для систем с конкуренцией вычислений за ресурсы, может возникнуть проблема непротиворечивости обеих Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 127
  • 125. групп описании. В настоящее время предложено несколько формальных языков (моделей) совместного описания задач функциональной верификации и оценки производительности (Performance evaluation) [14,15]. В этих работах предполагается, что работа системы может моделироваться в терминах теории очередей, т.е. поведение проектируемой системы представляется в терминах обработки запросов некоторым сервером (или несколькими серверами) [15]. При этом функциональная спецификация дополняется вероятностным распределением времени обслуживания “заявок”, что представляется в языках типа PCTL (probability computation tree logic) [16]. Однако, для таких аспектов анализа производительности как отказоустойчивость, подобные модели не вполне естественны. Разработка этого вопроса представляется весьма перспективной. 5. Заключение На ранних этапах разработки программно-аппаратных систем перед инженером – разработчиком часто встает проблема выбора наилучшей программной архитектуры (для данной среды), обеспечивающей максимальную вероятность корректного выполнения данного приложения в данной рабочей среде при заданном уровне случайных ошибок (soft-error rate). Мы выражаем отказоустойчивость (fault-tolerance) работы системы в терминах вероятностей переходов в конечном автомате, моделирующем работу системы. Существенно, что описания автоматов могут быть получены из ASM-диаграмм, используемых для спецификации проектируемой системы, что также позволяет сократить суммарную трудоемкость проектирования. Более того, различные аспекты проектирования устройства, такие, как функционально-временная корректность, устойчивость к сбоям (fault toleranсe), и даже оптимизация потребления электроэнергии системой (low power design) могут быть учтены, поскольку все эти задачи требуют использования FSM модели проектируемой системы, и эта модель автоматически строится по ASM-спецификации системы. При этом вычислительная сложность оценки вероятностей самовосстановления O(n4) для рассматриваемой марковской цепи размера n(n1)+2 существенно ниже вычислительной сложности реализации алгоритмов Model Checking [12], что определяется квадратичной вычислительной сложностью решения линейных уравнений Колмогорова-Чапмена. Литература 1. Egon Börger, Abstract State Machines: a unifying view of models of abstract state machines capture sequential algorithms // Annals of Pure and Applied Logic, 133, (2005), p. 149–171. 2. A. Blass, Y. Gurevich, Abstract state machines capture parallel algorithms // ACM Transactions on Computational Logic, 3, (2002). 3. S. Baranov, ASMs in high-level synthesis of EDA tool Abelite // in Proc. DESD’09 Int. IFAC Workshop, Valensia, Spain, 2009, pp. 195-200. Available: http://www.dcud.uz.zgora.pl/shw/dCUD-Baranov.pdf. 128 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 126. 4. Васильев П.К. Расширение языка машин абстрактных состояний Гуревича рациональным временем // Вестник Санкт-Петербургского университета, Серия 10 «Прикладная математика информатика процессы управления», 2007, с. 90100. 5. S.Baranov, S. Frenkel, V.Zakharov, Semi-formal verification for pipelined digital design based on Algorithmic State Machines // Информатика и ее применения, vol. 4, issue 4, 2010, p. 49- 60. 6. S. L. Frenkel, A. V. Pechinkin, Estimation of self-healing time for digital system under transient faults // Информатика и ее применения, vol. 4, issue 3, 2010, p. 2- 8. 7. S. Frenkel, Some probabilistic and formal techniques for fault tolerant design // Proceedings of 5th IEEE International workshop on Impact of Low Power Designs on Test and Reliability, Annecy, France, Jun. 2012, p. 16-17. 8. S.A. Seshia, W. Li, S. Mitra, Verification - guided soft error resilience // Proceedings of the Conference on Design, Automation and Test, DATE07, 2007, p.1442-1447,. 9. S. Frenkel, Some measures of self-repairing ability for fault-tolerant circuits design // Second Workshop on Manufacturable and Dependable Multicore Architectures at Nanoscale (MEDIAN'13), Avignon, France, May 30-31, 2013, p. 57-60. 10. U.Krautz, M. Pflanz, et al, Evaluating coverage of error detection logic for soft errors using formal methods // Proceedings of the Conference on Design, Automation and Test in Europe, vol. 1, 2006, pp. 1–6. 11. Souheib Baarir et al, Complementary Formal Approaches for Dependability Analysis // 24th IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems, 2009. 12. S. Demri, F. Laroussinie, and Ph. Schnoebelen, A parametric analysis of the state explosion problem in model checking // Proc. 19th Ann. Symp. Theoretical Aspects of Computer Science (STACS'2002), vol. 2285 of Lect. Notes in Comp. Sci., Springer, 2002, p. 620-631.. 13. W. Feller, Introduction to Probability Theory and its Applications // vol. 1, Wiley, 1968. 14. Hermanns H., Herzog U., Katoen J.-P. Process algebra for performance evaluation // Theor. Comp. Sci. 274 (2002), p. 43–87. 15. Coste, et al, Quantitative evaluation in embedded system design: Validation of multiprocessor multithreaded architectures // In: DATE. IEEE (2008), p. 88–89. 16. Hansson H. and Jonsson B. A logic for reasoning about time and reliability // Formal Aspects of Comp. 6, 5 (1994), p. 512–535. 17. O. Ruano, J. A. Maestro, P. Reviriego, A fast and efficient technique to apply Selective TMR through optimization // Microelectronics Reliability, 51, 2011, p. 2388–2401. 18. K.L. McMillan, The SMV language // CadenceBerkey Lab, 1998. 19. G.J. Holzmann, The Model checker SPIN // IEEE Transaction on Software Engineering, vol.23, 1997, p. 76-95. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 129
  • 127. Особенности разработки программного обеспечения для Linux-контроллеров М.А. Смирнов, В.В. Олоничев, Б.А. Староверов Костромской государственный технологический университет amt@kstu.edu.ru Аннотация. В статье рассмотрены некоторые особенности разработки программного обеспечения для современных встраиваемых систем, работающих под управлением операционной системы Linux. Описанный подход является альтернативой для средств проектирования стандарта МЭК и предназначен для реализации эффективных алгоритмов цифрового управления технологическими установками. Ключевые слова. Программируемый логический контроллер, операционная система Linux, процессор ARM, кросс-компиляция, toolchain, реализация на языке Си, цифровое адаптивное управление, sshпротокол, научная библиотека GNU GSL, средства межпроцессного взаимодействия. 1 Введение На сегодняшний день ведущие производители промышленных компьютеров (JetBox, Atmel, Techbase и др.) и программируемых логических контроллеров (WAGO, ICP DAS, NPE и др.) предоставляют пользователям возможность реализовывать гибкие и эффективные алгоритмы цифрового управления на языках высокого уровня благодаря поддержке многозадачной операционной системы (ОС) Linux [1]. В современном ядре ОС Linux большинство системных вызовов являются вытесняемыми и имеются таймеры высокого разрешения. Вследствие этого Linux начинает занимать области, ранее принадлежащие классическим ОС реального времени, таким как QNX, OS-9 и VxWorks [2–4]. Поддержка спецификации POSIX данными ОС позволяет сравнительно легко переносить программы между ними. К преимуществам Linux-устройств можно отнести также низкую цену (в своем сегменте средств автоматизации), открытую архитектуру, низкие требования к аппаратным ресурсам [5]. В связи с высокими требованиями, предъявляемыми сегодня к качеству выпускаемой продукции, разработка программного обеспечения (ПО) под описываемые вычислительные системы весьма актуальна [6–8]. В то же время, 130 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 128. как показывает практика работы с Linux-контроллерами отечественного производства (например, ПЛК серии 304/308 фирмы «Овен»), пользователь по причине отсутствия универсальных пошаговых инструкций сталкивается с серьезными не для профессионала проблемами. К ним можно отнести следующие [9]: ─ необходимость модификации и конфигурирования ядра Linux; ─ необходимость поиска и построения инструментального пакета (toolchain); ─ необходимость библиотек; интеграции дополнительных драйверов, приложений, ─ необходимость тестирования, отладки и масштабирования проекта. Указанные причины, по мнению авторов, сдерживают широкое применение Linux-контроллеров и заставляют разработчиков использовать ограниченные возможности языков стандарта МЭК (язык структурированного текста, функциональных блоков, релейных схем и др.). Изложенный далее материал позволяет ликвидировать проблему масштабирования и быстрого реконфигурирования встраиваемого программного обеспечения. Что касается переноса исполняемых файлов с персонального компьютера (ПК) на целевую платформу, то рассмотрено конкретное решение для процессора ARM AT91RM9200 фирмы ATMEL, на базе которого работает большое количество отечественных и зарубежных контроллеров, в частности ПЛК304/308 «ОВЕН». Наиболее важные рекомендации по общему порядку действий даны в работах [9, 10]. 2 Мультипроцессный комплекс управления технологическими установками Для класса апериодических объектов с одной доминирующей постоянной времени, подверженных за технологический цикл девиации параметров в широких пределах, что в свою очередь требует перенастройки коэффициентов регулятора, разработана адаптивная многопроцессная управляющая система, функциональная схема которой представлена на рис. 1 [11]. За основу принята классическая САУ с регулятором состояния и наблюдателем [12]. Идентификатор однократно или в темпе с процессом вычисляет параметры технологического объекта управления, которые в свою очередь используются для расчета коэффициентов настройки динамического регулятора. В состав мультипрограммного продукта входят следующие процессы [13]: «диспетчер», «регулятор состояния», «наблюдатель полного порядка», «адаптатор», «задающее устройство эталонного сигнала», «цифровая модель объекта управления», «связь с реальным объектом», «идентификаторы» («пассивный идентификатор», «идентификатор однократного действия», «идентификатор многократного действия»). Данный комплекс реализован на Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 131
  • 129. языке Си с помощью GNU Scientific Library (GSL) v1.3 – библиотеки для научных расчетов. В качестве средств межпроцессного взаимодействия используется разделяемая память и семафоры System V. Рис. 1. Цифровая адаптивная самонастраивающаяся система управления: ОУ – объект управления; И – идентификатор; А – адаптатор; Н – наблюдатель; РС – регулятор состояния Главное преимущество мультипроцессной организации цифровой системы управления заключается в том, что на основе небольших узкоспециализированных программ можно собирать целые комплексы произвольной конфигурации и теоретически неограниченной сложности (именно такой подход отвечает идеологии ОС UNIX [14]). В частности, в зависимости от требований технологического процесса «идентификаторы» реализованы в трех вариантах: «пассивный идентификатор», «идентификатор однократного действия», «идентификатор многократного действия» [11]. Процесс «диспетчер» призван координировать работу всех остальных программ. При запуске он получает два параметра: первый задает режим работы (0 – асинхронный, 1 – синхронный), второй – имя конфигурационного файла. При асинхронном режиме обмен данными между процессами осуществляется по их готовности и происходит с максимально возможной для данной вычислительной системы скоростью. Данный способ взаимодействия применяется для моделирования поведения системы управления и может быть использован при отладке и тестировании программ на ПК. При синхронном режиме все вычисления и межпроцессная коммуникация происходят по команде от источника синхросигнала, которым является таймер реального времени. Он генерирует импульсы с заданным пользователем периодом квантования. Описанный способ взаимодействия используется для управления работой технологической установки в режиме реального времени. Конфигурационный файл содержит следующую информацию: количество регуляторов в системе управления, количество процессов-участников, не 132 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 130. включая «диспетчер», количество семафоров, а также порядок объекта управления и период квантования. Структурная схема установки, на которой была развернута мультипроцессная система адаптивного управления представлена на рис. 2. Она включает в себя персональный компьютер, сетевой коммутатор, ПЛК308 фирмы «Овен», модуль аналогового ввода МВА8 фирмы «Овен», модуль дискретного ввода-вывода МДВВ фирмы «Овен», твердотельное реле фирмы «Fotek», электрическую печь (объект управления) и датчик температуры. Рис. 2. Структурная схема САУ: 1 – кабель Ethernet; 2 – кабель RS-485; 3 – широтноимпульсный сигнал (ШИМ); 4 – сигнал обратной связи В ходе своей работы программный комплекс считывает по RS-485 c МВА8 сигнал с датчика (датчиков) температуры и выдает в соответствии с заложенным алгоритмом управляющее воздействие в виде процентного изменения мощности на модуль МДВВ, тот в свою очередь формирует на выходе ШИМ сигнал, а твердотельное реле коммутирует нагрузку (электрический нагреватель). Контролируемые параметры могут быть переданы на персональный компьютер или панель оператора. Для этого целесообразно использовать сетевые сокеты. Результаты работы мультипроцессной системы адаптивного управления представлены на рис. 3 на примере решения задачи стабилизации температуры печи при уменьшении напряжения питания с 220 В до 120 В, начиная с 4000 с. Как видно из рис. 3 а, применение традиционного ПИД-регулятора не позволяет оперативно отреагировать на возмущение и приводит к недопустимому снижению температуры, в то время как адаптивная система (рис. 3 б) обеспечивает высокие статические и динамические показатели. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 133
  • 131. а) б) Рис. 3. Исследование работы мультипроцессной системы управления на незагруженной печи при внесении возмущающего воздействия: а) работает неадаптивная система; б) работает адаптивная система 3 Подготовка и запись исполняемых файлов в контроллер Для компиляции и генерации исполняемого кода для целевой платформы (ПЛК308), работающей под управлением процессора ARM9, на ПК с ОС Linux (uCLinux v 2.6), установлен и сконфигурирован набор необходимых программ – toolchain фирмы «Ronetix» – ronetix-arm-linux-uclibc-4.1.2 [15], благодаря которому можно осуществить кросс-компиляцию исходных кодов. Диаграмма развертывания описываемой системы представлена на рис. 4. 134 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 132. Рис. 4. Диаграмма развертывания мультипрограммной системы управления При выборе toolchain необходимо знать процессор целевой платформы. Также следует проверить корректное выполнение собранных вместе со специальными библиотеками программ на ОС, установленной на ПЛК. Для сборки программ можно использовать следующий скрипт, получающий имя исходного файла в качестве параметра командной строки: F=$1 Fo=$F.o Fc=$F.c Fa=$F.arm arm-linux-gcc -I/usr/local/include -o $Fo -c $Fc arm-linux-gcc -o $Fa $Fo Для сборки программы вместе со специальными библиотеками (в нашем случае использовались статические библиотеки gsl) их следует указать явно: Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 135
  • 133. F=$1 Fo=$F.o Fc=$F.c Fa=$F.arm arm-linux-gcc -I/usr/local/include -o $Fo -c $Fc arm-linux-gcc -o $Fa $Fo ./lib/libgsl.a ./lib/libgslcblas.a Для копирования исполняемых файлов на ПЛК можно воспользоваться различными приемами, а именно: ─ Применяем команду scp, использующую безопасный шифрованный протокол ssh. Например: scp ./myprog root@plc308:/home/arm/myprog. При необходимости можно составить пакетный файл, копирующий за один прием несколько файлов. ─ Если важна наглядность, можно использовать консольный файловый менеджер mc, настроив одну из его панелей на удаленное подключение по тому же протоколу ssh: /#sh:root@plc308/home/arm. Представленная технология разработки и способ переноса программ прошли испытание на реально работающем оборудовании и подтвердили свою эффективность. 4 Выводы В статье рассмотрены особенности разработки программного обеспечения для ПЛК-Linux и способ переноса программ на целевую платформу. Описанный подход может быть использован разработчиками программного обеспечения для встраиваемых Unix-систем. Библиографический список 1. Все для автоматизации. Встраиваемые компьютеры, АСУ ТП, коммуникации, http://empc.ru/e-store/compact_pc_ark/ 2. VxWorks, http://www.windriver.com/products/vxworks/ 3. QNX, http://www.qnx.com 4. OS-9, http://www.radisys.com/products/microware-os-9/ 5. Горбунов Н. О выборе встраиваемой ОС для проекта // СТА. – 2011. – №2. – С. 22-28 6. Ицкович Э.Л. Проблемы развития контроллеров российских производителей // Промышленные АСУ и контроллеры. – 2007. – №2 136 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 134. 7. Ицкович Э.Л. Методы совершенствования систем регулирования технологических процессов // Промышленные АСУ и контроллеры. – 2011. – №1. – С. 3-9 8. Колесников А.А. Промышленный компьютер на базе Linux со встроенным GSMмодулем // ИСУП. – 2009. – №1 9. Даммер С. О реальной стоимости «доморощенной» Linux // СТА. – 2010. – №4. – С. 20-26 10. Zimmerly B. Install the GNU ARM toolchain under Linux // EN, developerWorks, May, 2009 11. Староверов Б.А., Олоничев В.В., Смирнов М.А. Реализация законов адаптивного управления технологическими установками на Linux-контроллерах // Промышленные АСУ и контроллеры. – 2012. – №7. – С. 48-53 12. Изерман Р. Цифровые системы управления. М.: Мир, 1984. – 541 с. 13. Олоничев В.В., Смирнов М.А., Староверов Б.А. Мультипроцессный комплекс цифрового управления технологическими установками. Свидетельство о государственной регистрации программы для ЭВМ № 2011611749. © М.: РОСПАТЕНТ, 2011 14. Реймонд Э. Искусство программирования для Unix. – М.: Издательский дом «Вильямс», 2005 15. Toolchain ronetix, http://www.ronetix.at Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 137
  • 135. Об усовершенствовании статистического метода оценки полноты тестов программ и устройств Басок Б. М., Гречин А.А.1 1 Московский государственный технический университет радиотехники, электроники и автоматики, 119454, Россия, г. Москва, Проспект Вернадского, 78 vm_e@mail.ru Aннотация. Рассматривается статистический метод проверки полноты тестов, основывающийся на анализе результатов работы программ и математических моделей дискретных устройств с внесѐнными дефектами. В работе предлагается существенно сократить временные затраты при оценке качества тестов данным методом, с одной стороны, путѐм внесения кратных дефектов, с другой, – путѐм взаимного использования результатов анализа тестов объекта тестирования и отдельных его компонентов. Приводятся экспериментальные данные, подтверждающие эффективность предлагаемых подходов. Ключевые слова: полнота тестов, анализ тестов, кратные отказы, мутации. 1 Введение. Постановка задачи Важнейшей характеристикой тестов программных систем (ПС) и дискретных устройств (ДУ) является их полнота. Под полнотой теста или его проверяющей способностью принято понимать [1,2] выраженное в процентах отношение выявляемых данным тестом отказов заданного класса к общему их числу. От полноты тестов напрямую зависит качество контролируемого объекта. Поэтому задача синтеза тестов высокой полноты является одной из важнейших задач контроля любого продукта на всех этапах его разработки и эксплуатации. При этом следует отметить, что, как правило, тесты ПС и существенная часть тестов ДУ создаются и отлаживаются вручную, и разработка новых дополнительных тестов для повышения полноты контроля требует больших затрат времени и средств. Обычно при проверке полноты функциональных тестов ПС используются методы, основывающиеся на покрытии кода программы или методы, базирующиеся на оценке количества охваченных тестом отдельных функций ПС [3]. Наряду с данными методами для проверки полноты тестов используется метод, основывающийся на анализе результатов выполнения тестов для ПС с искусственно введенными одиночными постоянными дефектами из списка отказов заданного класса и исходной ПС. При этом предполагается, что данный метод применяется после того, когда все собственные дефекты, обнаруженные данными тестами, исправлены, и влияние не обнаруженных ими собственных 138 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 136. дефектов ПС невелико. Указанный метод является некоторым аналогом классического метода, применяемого при анализе тестов ДУ и основывающегося на сравнении результатов моделирования исправной и неисправной ДУ[4]. Известны два подхода при реализации данного метода. Первый из них [5,6] основывается на внесении дефектов непосредственно в объектный код ПС. Такими дефектами могут быть, например, инверсия бита или байта объектного кода программы. Второй подход, получивший название мутационного анализа [7-10], основывается на внесении в исходный текст программы незначительных дефектов (мутантов). По определению [7] мутант – это одиночное синтаксически корректное изменение подлежащей тестированию ПС. Специальные программы – генераторы мутантов - формируют их списки. Мутанты, входящие в список, осуществляют либо замещение констант, либо замещение переменных, либо замещение операторов. Генераторы мутантов строятся на основе синтаксического анализа исходного кода ПС[7]. Первый подход применим, в первую очередь, при анализе тестов ПС, для которых отсутствует доступ к исходному коду.В то же время, для обеспечения безопасности работы эксплуатируемых ПС необходимо убедиться в высокой степени их надежности. Поэтому в любой момент может возникнуть необходимость в оценке качества предоставленных пользователю функциональных тестов, поскольку в редких случаях технологии разработки ПС, применяемые разработчиками включают обязательный этап тестирования безопасности [6]. Второй метод особенно полезен, поскольку с его помощью можно точно установить место внесенного дефекта и разрабатывать дополнительные тесты для выявления дефектов, не обнаруженных анализируемыми тестами. Кроме того, при реализации второго подхода, в отличие от первого, отсутствует опасность того, что внесение искусственного дефекта в ПС исказит операционную среду. Впрочем, данный недостаток можно преодолеть путем запуска ПС в системе виртуальных машин. При этом отказ, внесение которого приводит к искажению операционной среды, можно считать выявляемым. Описанные подходы применимы и при тестировании поведенческой модели ДУ на языке описания аппаратуры HDL, в частности на VHDLи Verilog,и анализе собственно тестов ДУ, представленных этой моделью [9,11].Например, в [9] описаны принципы разработки генератора мутаций для ПС на VHDL. Главным недостатком, как первой, так и второй реализации рассматриваемого метода оценки полноты тестов ПС являются чрезвычайно большие затраты времени, как следствие наличия большого количества мутантов или возможных искажений разрядов объектного кода ПС. Даже при тестировании сравнительно небольших ПС их количество может достигать многих десятков тысяч. При тестировании программ, содержащих несколько тысяч операторов, это число может многократно увеличиться. Например, при тестировании программы, реализующей метод Монте-Карло, генератор выдал более девятисот тысяч мутантов [10]. В некоторых работах [7] были рассмотрены методы сокращения множества Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 139
  • 137. рассматриваемых мутантов путем выделения групп эквивалентных мутантов и при оценке полноты тестов анализировать только одиночных представителей этих групп. Однако, как показано в [7], список анализируемых отказов сокращается не более чем на 8% - 10%. Другой подход, основывается на замене общего списка мутантов некоторой его выборкой, как правило, это некоторая часть общего списка, например, в [7] случайным образом выбирается 10% общего списка дефектов. Тем не менее, выбранный список оказывается достаточно большим. Кроме того в подобных работах отсутствует обоснование размеров выборки. В этом случае обычно полагаются на накопленный в данной области опыт. Для существенного сокращения времени при реализации метода оценки полноты в работе [12] предложен и обоснован способ, известный как статистический. В соответствии с этим способом при анализе тестов используется не полное множество отказов, а некоторая небольшая случайная выборка. Согласно [12] для случайной выборки из 400 отказов заданного класса можно гарантировать, что полнота тестового набора для всей совокупности отказов заданного класса отличается не более чем на 5% от истинного значения с достоверностью 0,95. Величина выборки не зависит от сложности и размеров объекта тестирования. Таким образом, количество модифицированных неисправных копий анализируемого объекта (ПС или ДУ) оказывается фиксированным и сравнительно небольшим. Статистический способ оценки полноты был программно реализован и показал свою эффективность при многолетней эксплуатации программного комплекса моделирования, синтеза и анализа тестов, разработанного в ИНЭУМ и внедренного в ряде организаций, а также при анализе полноты тестов СБИС повышенной сложности с помощью первого в Советском Союзе многопроцессорного программно-аппаратного комплекса-ускорителя логического моделирования, разработанного в ИНЭУМ [13]. В работах [5,11] обсуждаются возможности применения статистического способа оценки полноты при мутационном подходе и искажении объектного кода программы. Однако, несмотря на ряд преимуществ статистического способа проверки полноты абсолютная величина временных затрат при его использовании остается весьма значительной. В первую очередь, это касается затрат времени при анализе тестов программ с невысокой проверяющей способностью. Так при анализе пяти тестов программы размер исполнительного модуля которой составляет 18 кбайт, понадобилось 1708 прогонов данной программы. Если предположить, что время выполнения программы составляет одну минуту, то временные затраты составят более 28 часов. При этом несмотря на то, что имеется такой источник сокращения времени, как возможность распараллеливания процесса оценки полноты, к примеру на нескольких компьютерах, величина временных затрат остается существенной. В данной работе рассматриваются два подхода к сокращению времени оценки статистической полноты тестов. Первый подход основывается на анализе тестов в классе одиночных константных отказов путѐм внесения кратных дефектов из данного класса. Второй подход базируется на совместном 140 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 138. анализе интеграционных тестов объекта контроля и тестов отдельных его частей. 2 Метод внесения кратных отказов В работе одного из авторов данной статьи [14] был предложен метод анализа тестов ДУ, называемый методом моделирования кратных отказов. В соответствии с этим методом процесс проверки полноты тестов можно ускорить, если вносить не одиночные, а кратные отказы. Последние можно получить путѐм случайного разбиения списка невыявленных предыдущими тестами отказов на небольшие непересекающиеся группы одного размера (возможно последняя из групп окажется меньше). Отказы объединяются в группы случайным образом. При этом в соответствии с гипотезой о редкой компенсации кратных отказов [1,11] считается, если тестом не выявляется полученный таким образом кратный отказ, то не выявится и не один из одиночных дефектов, входящих в данную группу. В том случае, если состояния выходов модели объекта тестирования с внесѐнным кратным отказом отличаются от состояний одноименных выходов модели исправного объекта, следует проверить возможность выявления тестом дефектов, образующих кратный отказ по одному. В работе [14] обосновывается близкий к оптимальному размер групп для списка дефектов, оставшихся не выявленными после анализа группы первых тестов и относящихся к классу трудно проверяемых отказов. В соответствии с приводимыми в работе [14] оценками применение указанного метода повысит скорость анализа качества тестов в несколько раз. В докладе применяется подход, использующий, с одной стороны, статистический способ проверки полноты тестов, с другой, – метод кратных отказов. Этот подход применим как для ПС, так и для ДУ. В соответствии с данным подходом не выявленные очередным тестом отказы из выборки [5,12] разбиваются на группы. Размер группы определяется исходя из минимизации математического ожидания случайной величины количества прогонов теста [14]. Общее количество прогонов теста определяется как сумма двух слагаемых: количества прогонов равных количеству полученных групп отказов и количества прогонов равного количеству одиночных дефектов, образующих обнаруженные кратные дефекты. Таким образом, величина группы при анализе полноты теста i может быть определена путем минимизации функции, имеющей следующий вид: F (Gi )  Gi  N  Li 1  j  1  1  1   i  N  j 1   Gi j 1  i  (1) где Li 1 - количество выявленных дефектов на предыдущем (i-1)-ом тесте, Ni – количество дефектов заданного класса, оставшихся невыявленными после анализа предыдущих (i-1) тестов. Размер группы для анализа качества первого теста можно принять равным единице, учитывая тот факт, что первые тесты обычно обладают хорошими Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 141
  • 139. проверяющими свойствами. С другой стороны, как показали эксперименты, эту величину можно увеличить до трѐх. Если очередной тест не выявил ни одного отказа, то переменной в функции (1) можно присвоить не равное нулю значение аналогичной переменной, определенное ранее для ближайшего из предыдущих тестов. Данный подход был апробирован при анализе тестов группы промышленных консольных приложений (консольный тип был выбран для удобства автоматизации процесса проверки полноты), работающих в операционной среде Windows. В качестве моделей отказов использовались постоянные дефекты типа инверсии бита/байта. Результаты анализа тестов методами одиночных и кратных отказов с использованием статистической выборки моделируемых отказов показали, что количество прогонов после первых пяти тестов при реализации метода кратных отказов сокращается в три раза, а при анализе полноты десяти тестов выигрыш во времени может достигнуть одного порядка. В Таблицах 1 и 2 приведены некоторые экспериментальные данные. Испытания проводились для пяти тестов, проверяющих работу программы, исполнительный модуль которой занимает примерно 18 килобайт. Таблица 1. Статистика прогонов тестов для одиночных отказов. Номер теста Кол-во отказов Размер группы Кол-во групп Кол-во выявл. отказов 66 Всего прогонов 400 Кол-во выявл. групп 66 1 400 1 2 334 1 334 5 5 334 3 4 329 1 329 2 2 329 327 1 326 1 1 327 5 318 1 318 9 9 318 400 1708 Итого Таблица 2. Статистика прогонов тестов для кратных отказов. Номер теста Кол-во отказов Размер группы Кол-во групп Кол-во выявл. отказов 66 Всего прогонов 134 Кол-во выявл. групп 55 1 400 3 2 334 3 329 3 112 5 5 127 9 37 2 2 55 4 327 10 33 1 1 43 5 318 10 33 8 9 113 Итого 299 637 Средняя статистическая полнота тестов - 21%. 142 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 140. Увеличение выигрыша во времени от теста к тесту объясняется резким сокращением количества выявляемых отказов и тем, что в списке не выявленных отказов остаются отказы, относящиеся к подмножеству так называемых «трудно проверяемых». Данные, помещенные в Таблицы 1 и 2, наглядно показывают выигрыш во времени при использовании метода кратных отказов по сравнению с методом внесения одиночных отказов примерно в 2,7 раза. Кроме того, проведенные эксперименты продемонстрировали, что эффективность метода кратных отказов тем выше, чем меньше полнота тестов. При этом экспериментально установлено, что существует некоторый порог полноты анализируемого теста (30%-40%), при превышении которого использование кратных отказов нецелесообразно. Однако следует заметить, что, как правило, полнота отдельных тестов в классе рассматриваемых отказов не превышает 25%. Полученные результаты показали, что отказы из случайной выборки, объединенные в группу, мало влияют друг на друга. Это позволяет предполагать, что подобный алгоритм будет особенно полезен при реализации мутационного подхода. 3 Совместный анализ интеграционных контроля и тестов его отдельных частей тестов объекта Как правило, полнота анализируемых тестов не является удовлетворительной, и для выявления не обнаруженных отказов следует разрабатывать дополнительные тесты. Это весьма трудоѐмкий процесс. Поэтому в данной работе предлагается, прежде чем приступить к синтезу дополнительных тестов, использовать для повышения полноты интеграционных тестов системы возможности тестов компонентов, и наоборот: использовать результаты оценки полноты интеграционных тестов для повышения качества проверки отдельных компонентов. Использование такого подхода сократит количество не выявляемых указанными тестами дефектов и, следовательно, сократит время для разработки дополнительных тестов. Следует отметить, что в работе [15] предлагался оригинальный метод компонентного тестирования информационных систем, позволяющий на основе выделения наиболее часто встречающихся типов ошибок в программе выявлять их на уровне компонентов программ. Суть предлагаемого в настоящей работе подхода заключается в следующем. Вначале осуществляется синтез тестов компонентов, поиск и исправление дефектов обнаруженных с их помощью в этих компонентах. После завершения данного этапа контроля аналогичные процедуры выполняются для системы с применением интеграционных тестов системы. Теперь, после выявления и исправления всех обнаруженных тестами компонентов и тестами системы отказов можно приступить к оценке статистической полноты данных тестов в классе одиночных отказов (например, мутантов). Очевидно, что как дефекты, не выявляемые тестами системы, могут Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 143
  • 141. быть выявлены тестами компонентов, так и невыявленные отказы компонентов могут быть обнаружены тестами системы. Поэтому следует проанализировать возможность выявления непроверенных отказов интеграционных тестов системы тестами компонентов, которым эти отказы принадлежат. Для этого предлагается взять список непроверенных отказов после определения статистической полноты и путѐм последовательного внесения этих отказов в соответствующие компоненты определить, выявляют тесты компонентов эти отказы или нет. Аналогичную процедуру можно применить для анализа списка непроверенных отказов компонентов. В этом случае непроверенные отказы компонентов последовательно вносятся в компонент, собирается версия системы и выполняются интеграционные тесты. Как показали эксперименты, интеграционные тесты выявляют не менее 10% из невыявленных тестами компонентов отказов-мутантов. Заключение В работе рассматривался статистический метод оценки полноты тестов ПС и ДУ, обсуждались его достоинства и недостатки. Для модификации данного метода были предложены два подхода. Первый из них основывается на использовании кратных отказов вместо одиночных. Его применение позволит сократить время проверки полноты тестов в несколько раз. При этом показано, что в отличие от предложенного в [14] метода данный подход можно применять, начиная с первого теста. Второй подход использует пересечение множеств отказов контролируемого объекта и его отдельных компонентов. Благодаря этому удается повысить полноту, как интеграционных тестов, так и тестов отдельных компонентов ПС и ДУ и сократить время разработки дополнительных тестов. В качестве дальнейших исследований в области оценки качества тестов нам представляется актуальным продолжать работы в области сокращения временных затрат. Одним из путей здесь видится сокращение выборки из множества отказов за счет некоторой потери точности как это предлагается, например, в [5,16]. Перспективным направлением является применение статистических методов для оценки качества и отказоустойчивости встроенных систем, когда имитация отказов сводится к внесению искусственных неисправностей в программное обеспечение этих систем [17]. Литература 1. Гробман Д.М. Программный контроль и диагностика неисправностей ЦВМ. // Диагностика неисправностей вычислительных машин. М.: Наука. 1965 г. С. 7 – 22. 144 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 142. 2. Скобцов Ю. А., Сперанский Д. В., Скобцов В.Ю.Моделирование, тестирование и диагностика цифровых устройств. // Учебное пособие. М.: ИНТУИТ. 2012 г. 440 с. 3. Синицин С.В., Налютин Н.Ю. Верификация программного обеспечения. // Учебное пособие. М.: Бином. 2008 г. 307 с. 4. Seshu S. On an Improved Diagnosis Program // IEEE Trans. on Elec. Com-puters. 1965. Vol. 12, February, p. 76-79. 5. Корчемный Д.И. Оценка полноты тестирования методом последовательного анализа. // Вопросы радиоэлектроники. Сер. ЭВТ. 1980 г. Вып.17. С. 68 – 74. 6. Благодаренко А.В. Статистический и динамический анализ программного обеспечения без исходных текстов. // Проблемы информационной безопасности в системе высшей школы: труды XIV всероссийской научной конференции.–М.:МИФИ, 2007г. С. 33-34. 7. Mattias Bybro. A Mutation Testing Tool for Java Programs, Ett verktyg för mutationstestning av Javaprogram Examensarbete i Datalogi, 2003, 20p., http://www.nada.kth.se/~karlm/a_mutation_testing_tool_for_java.pdf. 8. Harman M., YueJia, Langdon W.B. A Manifesto for Higher Order Mutation Testing, Software Testing, Verification, and Validation Workshops (ICSTW), 2010 Third International Conference on, 2010, 6-10 April, p.80-89. 9. Lorez C., RiesgoT.,De la Torre E.,Useda J. A method to perform error simulation in VHDL // Desing of Circuits and Integrated Systems Conference. Madrid (Spain), 1998. p. 495-500. 10. Offutt A.J., Untch R.H. Mutation 2000: Uniting the Orthogonal // Mutation Testing in the Twentieth and the Twenty First Centuries San Jose, 2000. p. 45-55. 11. Басок Б.М., Гречин А.А. О едином подходе при анализе тестов дискретных устройств и программ. // Вопросы радиоэлектроники. Сер. ЭВТ. 2010 г. Вып.3. С. 140 – 145. 12. Гробман Д.М. Статистический способ определения полноты тестов. // Тезисы докладов IV Всесоюзного совещания по технической диагностике. Черкассы. 1979 г. С. 9 – 11. 13. Сергеев Б.Г., Басок Б.М., Бродский М.А. Использование аппаратных средств моделирования в САПР СБИС. // Автоматизация логического проектирования средств вычислительной техники: труды первой международной конференции «САПР СВТ 89» Л., 1989 г. С. 25-31. 14. Басок Б.М. Об одном методе оценки качества тестов дискретных компонентов вычислительных сетей. // Автоматика и вычислительная техника. 1985 г. №1. С. 56 – 58. 15. Кораблин Ю.П., Куликова Н.Л., Чумакова Е.В. Компонентное тестирование и его реализация. // Учебное пособие. М.: Союз, 2009 г. 23 с. 16. Рабинович Ю.Г. Ускорение статистического метода проверки полноты теста с использованием специализированных средств моделирования.// Труды Всесоюзного семинара «Специализированные процессоры в САПР». Тез.докл. - Москва, 1989. С. 1718. 17. Thorhuus R. Software Fault Injection Testing. // Master of Science Thesis in Electronic System Design. Stockholm, Sweden: KungligaTekniskaHögskolan, 2000, 58 с. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 145
  • 143. Анализ производительности сетевой подсистемы микроядерного окружения Genode Василий Сартаков and Александр Тарасиков ksys labs Аннотация Микроядерные операционные системы имеют долгую историю развития, однако на сегодняшний день большинство из них остаётся экспериментальными исследовательскими проектами. В данной работе представлен опыт использования микроядра L4 Fiasco.OC и окружения Genode для построения сетевой инфраструктуры, приведен анализ ее производительности, а так же рассмотрены архитектурные особенности микроядра и программного окружения влияющие на пропускную способность сетевой подсистемы. 146 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 144. 2 1 Введение Современное сетевое оборудование обладает большим функционалом, реализация которого уже давно не возможна только на аппаратном уровне. Как следствие, такое оборудование содержит в себе специализированный процессор, на котором исполняется операционная система и прикладное программное обеспечение. Операционная система в сетевом оборудовании несет на себе основную нагрузку по обеспечении безопасности и реализации основного функционала, как следствие, для разработки доверенных решений операционная система должна обладать повышенными средствами защиты от проникновения и отказов. Микроядерные операционные системы - это такие операционные системы, в которых большая часть функциональности ядра реализована в виде отдельных сервисов. Подобные системы находятся в разработке с 1970-х годов; некоторые проекты достигли коммерческого успеха и применяются в промышленности. Однако, особенности архитектуры микроядра могут накладывать ограничения на производительность и границы применимости таких систем [5]. Основные механизмы обеспечения безопасности в микроядерной среде выполнение всех процесов в депривелигированном (пользовательском) режиме и использование системы межпроцессного взаимодействия вместо прямого обращения к памяти другого процесса[6]. Большая часть функциональности, такой как драйвера устройств, файловые системы, управление памятью, реализуется в виде независимых процессов, выполняющихся в пространстве пользователя. Компрометация одной из подсистем ядра не дает атакующему доступ в привелигированный режим, в то время, как в получивших большее распространение монолитных ОС, где все системные компоненты выполняются в пространстве ядра (режиме супервизора), такая угроза есть. В данной статье представлен опыт создания сетевого оборудования на основе экспериментального микроядра Fiasco.OC в окружении Genode. Используемое микроядро, с одной стороны, обладает высоким потенциалом с точки зрения безопасности, поскольку вынесение критического функционала из ядра в пространство пользователя, а так же жесткая изоляция компонентов 1 уменьшают количество векторов атак и повышает отказоустойчивость. С другой стороны, изоляция компонентов ядра приводит к интенсивному межпроцессному обмену, что может негативно влиять на производительность сетевого оборудования. Для оценки производительности такого оборудования был разработан прототип аппаратно-программного комплекса, решающего задачу изоляции сетевый сервисов при помощи паравиртуализации. В качестве гипервизора 1 Под изоляцией подразумевают использование раздельных адресных пространств и использование принципа наименьших привилегий в выделении ресурсов Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 147
  • 145. 3 было использовано экспериментальное микроядро Fiasco.OC, виртуальные машины реализованы на основе паравиртулизированного ядра L4Linux[4]. Результирующие тесты производительности системы показали деградацию пропускной способности сети в сравнении с системами построенными на монолитно-модульном ядре Linux. Для выявления причин деградации был разработан набор программного обеспечения для профилирования ядра и окружения. Этот набор инструментов позволил выявить компоненты программного окружения, вносящие наибольший вклад в падение производительности сетевой подсистемы, а также отличия в поведении микроядра Fiasco.OC на одно- и многопроцессорных системах. Статья имеет следующую структуру: В первой главе представлена архитектура экспериментального аппаратно-программного комплекса, а так же результаты нагрузочного тестирования. Во второй главе описана методология профилирования и ее результаты. В третьей главе представлен анализ профилирования, а в четвертой главе приведены рассуждения о методах повышения производительности. В заключительной, пятой главе, подводятся итоги работы и формулируются планы на дальнейшую работу. 2 2.1 Аппаратано-программный комплекс «Шлюз» Функциональное назначение Гарантированное разделение ресурсов в вычислительных системах - одна из основных задач информационной безопасности. При этом есть необходимость как ограничить доступ к вычислительным ресурсам внутри одной машины, так и контролировать потоки данных между различными сетевыми устройствами. При проектировании корпоративной локальной сети, необходимо изолировать безопасный сегмент сети (сетевое хранилище и автоматизированные рабочие места работников, обрабатывающих внутрикорпоративные документы) и сетевые устройства, имеющие доступ в интернет или другие публичные сети. Возникает задача контроля входящих сетевые соединения для того, чтобы блокировать трафик от недоверенных узлов. Кроме того, требуется производить мониторинг сетевого трафика для обнаружения специальным образом сформированных сетевых пакетов, направленных на повышение привелегий злоумышленника путем эксплуатации уязвимостей в программном и аппаратном обеспечении. Зачастую требуется предоставить доступ к части внутрисетевых ресурсов. Например, внутри безопасной локальной сети пользователям могут быть доступен сервис сетевого хранения данных, реализованный в виде сетевого диска. Если определенные файлы необходимо сделать доступными из внешней сети, может использоваться веб-сервер для выдачи индивидуальных файлов. Помимо возможности проведения дополнительной авторизации пользователей средствами веб-интерфейса, такое решение скрывает от потенциальных злоумышленников физическую топологию внутрикорпоративной сети. 148 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 146. 4 Ряд приложений требует передачи конфиденциальных данных по незащищенному (публичному) каналу. Для организации безопасного обмена данными используются туннели с шифрованием трафика. При этом требуется гарантировать, что ключи, использующиеся для шифрования, не будут скомпрометированы. Поэтому необходим механизм разделения вычислительных процессов внутри узла сети, реализующего туннель. Рассмотренные выше задачи решаются использованием сетевого шлюза, то есть, сетевого устройства, имеющего связь с безопасным и небезопасным сегментами сети, и ограничивающего обмен данными между ними. Схема топологии сети с применением сетевого шлюза приведена на рисунке 1. Далее представлена реализация сетевого шлюза с использованием микроядера Fiasco.OC. Рис. 1. Схема сети с использованием шлюза 2.2 Реализация Рассмотрим одну из возможных реализаций описанного выше сетевого шлюза. В качестве аппаратной части комплекса используется сервер с двумя сетевыми интерфейсами, один из которых обеспечивает связь с безопасными, а другой - с небезопасными сегментами сети. Задачи фильтрации и маршрутизации трафика решаются при помощи виртуальных машин. Для обмена данными между виртуальными машинами может использоваться как виртуальный сетевой интерфейс, так и криптографический сервис, обеспечивающий конфиденциальность передаваемых по незащищенному сегменту сети данных. Программная часть реализована при помощи микроядра Fiasco.OC, программной среды Genode и паравиртуализованного ядра L4Linux. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 149
  • 147. 5 Поскольку стояла задача оценить производительность полностью микроядерного окружения, в котором драйвера сетевой подсистемы реализованы в пространстве пользователя, были исключены решения на базе гибридных ядер ОС. Кроме того, к используемой комбинации ядра ОС и программного окружения предъявлялись следующие требования: – Открытый исходный код, так как предполагалась доработка системы и последующее распространение изменений. – Поддержка микропроцессорной архитектуры X86 и многопроцессорных (SMP) систем. – Поддержка современного оборудования, в частности, наиболее распространённых моделей сетевых карт. Этим требованиям удовлетворяют микроядра семейства L4, такие, как OKL4, Fiasco, Fiasco.OC. Было использовано ядро Fiasco.OC, как наиболее активно развиваемое (новые версии выходят раз в несколько месяцев, в то время как последний публичный релиз OKL4 был несколько лет назад) и официально поддерживаемое окружением Genode. Рис. 2. Архитектура сетевого шлюза с использованием микроядра Программная среда Genode - это набор системных сервисов (драйверов устройств и файловых систем) и библиотек, предназначенных для разработки программного обеспечения для микроядерной ОС. Ряд библиотек реализуют программный интерфейс POSIX, позволяя переносить некоторые приложения из ОС Linux посредством перекомпиляции. Кроме того, Genode содержит библиотеку DDEKit[7], позволяющую использовать ряд драйверов устройств из других ОС (таких, как Linux и iPXE). Одним из сервисов, использующих библиотеку DDEkit, является DDE_ipxe, реализующий функциональность драйвера сетевого интерфейса. Таким образом, драйвер 150 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 148. 6 сетевого интерфейса представляет собой программу, выполняющуюся в пространстве пользователя, тем самым изолированную от других сервисов. В случае, если будет обнаружена уязвимость в этом драйвере, позволяющая злоумышленнику внедрить свой код в сервис, не произойдет компрометации других программ, в частности, приложений, выполняющихся в виртуальных машинах. Виртуальные машины реализованы при помощи L4Linux. L4Linux - это адаптированное ядро Linux для работы в депривилегированном режиме (пространстве пользователя) в качестве сервиса среды Genode. L4Linux позволяет использовать программы для ОС Linux без модификации за счет двоичной совместимости. Помимо сокращения затрат времени на адаптацию программного обеспечения для работы в микроядерной среде, это позволяет использовать программы, которые невозможно адаптировать ввиду отсутствия исходных кодов, например, значительная часть коммерческого программного обеспечения. 2.3 Модель угроз Основной вектор атаки на сетевые устройства под управлением монолитных ОС типа Linux и FreeBSD - это эксплуатация уязвимостей в одном из сервисов, доступных извне (например, HTTP сервер, используемый для конфигурации или вывода информации) для повышения привилегий. Ряд атак позволяет злоумышленнику повысить уровень доступа в пределах одного сервиса, другие направлены на получение полного доступа к ядру ОС (root expoits). Большое количество атак для повышения привилегий использует ошибки в ПО, связанные с переполнением буфера [3]. Атака с переполнением буфера заключается в возможности перезаписи переменных в программе из-за ошибок обработки пользовательского ввода. Данный класс уязвимостей возможен в связи с тем, что для хранения кода программ и пользовательских данных используется одна и та же область памяти. Кроме того, для передачи параметров в системные вызовы зачастую используется разделяемый между пространством ядра и пространством пользователя регион памяти, что позволяет получить доступ к структурам ядра, если в коде обработки системного вызова отсутствуют или некорректно реализованы проверки размера передаваемых данных. В микроядре Fiasco.OC взаимодействие между процессами реализовано через систему обмена сообщениями. Сообщения передаются через специальный регион памяти фиксированного размера (UTCB, Userspace Thread Control Block). При передаче данных от процесса к процессу данные копируются из UTCB первого процесса в UTCB второго, что, с одной стороны, защищает от утечек данных через указатели на структуры ядра, а с другой, может увеличить время затрачиваемое на системные вызовы. Важно заметить, что эта мера поддерживающая целостность данных при осуществлении межпроцессных вызовов, тем самым не позволяя злоумышленнику, получившему контроль над каким-либо сервисом, атаковать сервисы, Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 151
  • 149. 7 связанные с ним, но не гарантируют невозможность проведения атаки на отдельный сервис. Одной из угроз вляется атака через устройства, поддерживающих DMA. Технология DMA (Direct Memory Access) позволяет устройству обращаться к произвольной области физической памяти. Защища от таких атак не зависит от типа ядра и реализуется при помощи IOMMU (Input/Output Memory Management Unit) - аппаратного блока виртулизирующего физическую память с которой работает DMA устройство. Другим типом угроз является атака на драйвер устройства. Выявление и использование уязвимости в сетевой подсистеме не дает доступа злоумышленнику к структурам ядра поскольку сетевая подсистема исполняется в режиме пользователя и изолированная от других компонентов. 2.4 Анализ производительности Ключевой характеристикой аппратно-программного комплекса являлась производительность. Как упоминалось ранее, микроядерная архитектура способствует повышению защищенности системы, но, в то же время, может способствовать деградации производительности. При анализе производительности мы использовали ОС Linux в качестве эталонной, исполняемой на таком же оборудовании без использования гипервизора. Для измерения производительности сети были использованы два компьютера - рабочая станция разработчика (далее - PC Host) и сервер, представляющий собой аппаратную часть разрабатываемого комплекса (далее SRV). Оба компьютера оснащены сетевым контроллером Intel 82579LM с пропускной способностью 1Гб/с. Для проведения тестов использовалась программа netperf [1]. Были проведены тесты приема и передачи данных. В первом случае один экземпляр программы netperf запускался в режиме сервера внутри среды L4Linux, а другой - в режиме клиента на рабочей станции под управлением Linux (на графике данная конфигурация обозначена как «SRV Host PC Client»). Во втором случае («PC Host - SRV Client») в L4Linux netperf запускался в режиме клиента. Для рабочей станции использовался дистрибутив Fedora Linux 18 с версией ядра Linux 3.8; при запуске на сервере в среде Genode использовалось ядро L4Linux версии 3.5, в качестве корневой файловой системы также использовался образ дистрибутива Fedora. Результаты тестирования приведены на графике ниже (Рис. 3). Можно выделить следующие особенности: – Максимальная пропускная способность сети с использованием системы L4Linux в среде Genode в 1.75 раз ниже, чем без использования паравиртуализации – Показатели скорости передачи данных отличаются для входящего и исходящего трафика. Скорость приёма данных почти в 10 раз ниже, чем без использования паравиртуализации. 152 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 150. 8 Скорость передачи (Mbps) 1,000 800 PC Host - SRV Client SRV Host - PC Client 704703 600 402 400 200 89 0 Linux Genode Рис. 3. Сравнение производительности сетевой подсистемы 3 Профилирование сетевого стека Высокая деградация производительности полученной системы говорит о недостатках архитектуры. Дальнейшие эксперименты по анализу производительности системы осуществлялись на одном экземпляре L4Linux который непосредственно обращался к драйверу сетевого адаптера DDE_iPXE. 3.1 Инструментарий профилирования Программная среда Genode не предоставляет средств для профилирования кода. Была рассмотрена возможность портирования инструментов, используемых в других ОС, таких, как gprof или DTrace. Одним из препятствий к портированию данных утилит стало отсутствие в библиотеках, реализующих уровень совместимости со стандартом POSIX, некоторых системных вызовов, например, profil и mcount, необходимых для реализации инструментирующего профилировщика. Кроме того, сложность представляет организация доступа из профилировщика к объектам ядра ОС и аппаратным счётчикам производительности без внесения изменений в конфигурацию сервисов и нарушения принципа изоляции процессов в микроядерном окружении. Ввиду отсутствия средств измерения производительности, в участки кода драйвера сетевого интерфейса были вручную расставлены счетчики тиков системного таймера (получаемых инструкцией rdtsc), затрачиваемых на выполнение интересующей нас процедуры. Сообщения выводились в журнал, который передавался на компьютер разработчика через последовательный порт UART. При использовании пакетов большего размера было обнаружено, что изза низкой скорости вывода данных через UART, добавление отладочных Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 153
  • 151. 9 сообщений замедляет работу исследуемой программы. Для решения этой задачи был реализован сервис, сохраняющий отладочный журнал в оперативную память. Был использован существующий драйвер ram_fs в среде Genode, который реализует файловую систему в оперативной памяти. По окончании тестирования журнал копировался с тестового компьютера через HTTP интерфейс, предоставляемый сервером lighttpd, запущенным в среде Genode. В приведенной ниже таблице 1 представлено среднее время выполнения функций сетевого стека (в тиках процессора). Процедура Количество тиков Файл dde_kit_sem_up dde_kit_sem_down memcpy 13 59 23 lib/nic.c [dde_ipxe] lib/nic.c [dde_ipxe] lib/nic.c [dde_ipxe] get_acked submit_packet packed_descriptor 46 190-160K 10 nic/component.h [Nic] nic/component.h [Nic] nic/component.h [Nic] get_packet acknowledge_packet submit_packet memcpy Таблица 1. Время 3.2 8 lib/l4lx/genode_net.cc [L4Linux] 254 lib/l4lx/genode_net.cc [L4Linux] 65 lib/l4lx/genode_net.cc [L4Linux] 25 lib/l4lx/genode_net.cc [L4Linux] выполнения процедур сетевого стека Анализ результатов профилирования Как следует из таблицы 1, наиболее затратная операция - submit_packet, которая помещает пакет в циклический буфер и делает IPC запрос к другому процессу. При тестировании программой netperf было обнаружено, что при длительной передаче данных время выполнения операции submit_packet спорадически увеличивается на несколько порядков. Было сделано предположение, что причинами такого поведения могут быть как особенности реализации драйверов устройств, так и алгоритмов управления процессами и памятью в ядре ОС. Драйвера устройств Одной из причин несимеетричной производительности сетевой подсистемы при приеме и передаче данных может являться реализация обработки аппаратных прерываний в микроядре Fiasco.OC. В Genode не реализована поддержка прерываний, инициируемых сообщениями (MSI-X) для шины PCI. Это не позволяет назначить обработчик для прерывания, сигнализирующего о наличии входных данных на сетевом интерфейсе, и приходится 154 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 152. 10 использовать прерывание от шины PCI, которое может быть разделено с другими устройствами, что может приводить к увеличению времени обработки входящего трафика. Кроме того, драйвер контроллера прерываний IO APIC на некоторых системах, оставляет контроллер в состоянии, в котором тот остался на момент загрузки, не реализуя включение/выключение источника прерываний, что осложняет отладку программного комплекса. Управление памятью В процессе тестирования программа netperf последовательно увеличивает размер сетевых пакетов. При длительном тестировании наблюдается большой разброс времени выполнения операции submit_packet, в связи с чем было сделано предположение, что драйвер сетевого интерфейса тратит много времени в ожидании выделения памяти для очередного пакета. С целью проверки этого предположения были увеличены в 8 раз размеры буферов для входящих и исходящих данных. Поскольку увеличение размеров буферов не внесло изменений в поведение системы, необходимо было провести исследование поведения алгоритма выделения памяти. Для управления памятью в сетевой подсистеме Genode используется алгоритм SLAB[2], который содержит несколько списков блоков памяти фиксированного размера (1Кб, 2Кб, 16Кб и т.д.). Память для пакетов с данными организована в виде кольцевого буфера, где пакет, освобожденный одним из сервисов (например, драйвером сетевого адаптера DDE_ipxe), попадает в очередь свободных пакетов другого сервиса (драйвер виртуального сетевого интерфейса L4Linux). При передаче региона памяти в процесс другого сервиса выполняется операция освобождения региона (unmap), и операция выделения памяти в новом процессе. При конфигурации микроядра Fiasco.OC для поддержки многопроцессорного режима (SMP), реализация многих алгоритмов и структур данных, в том числе примитивов синхронизации (мьютексов), отличается от однопроцессорной версии. Кроме того, при использовании нескольких процессоров потоки, выполняющие системные функции (обработку прерываний, ввод-вывод) и пользовательские задачи выполняются одновременно. Для определения влияния данных различий на производительность системы, было проведено тестирование в двух режимах: при включении всех ядер процессора поддержки SMP в Fiasco.OC (время выполнения теста составило 24929000 мкс), и при использовании одного ядра и отключения SMP (146000 мкс). При использовании одного ядра процессора, разница между скоростью приема и передачи данных уменьшается. В многопроцессорном режиме планировщик проводит значительную часть времени (до 30%) в режиме простоя (idle thread) вместо того, чтобы передавать управление потокам приложений. Изучение причин такого поведения планировщика и сравнение с другими микроядрами, поддерживаемыми средой Genode является задачей для дальнейших исследований. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 155
  • 153. 11 4 Предлагаемые решения Для минимизации задержек при обработке сетевых данных были предложены несколько способов доработки сетевой подсистемы: – Использовать регион разделяемой памяти (Dataspace в терминологии L4/Genode) вместо буферизации в каждом процессе. Но такое решение противоречит принципам безопасности микроядерных систем, так как в случае компрометаци драйвера сетевого интерфейса злоумышленник потенциально получает доступ к памяти всех процессов, использующих сеть. – Предоставить паравиртуализированным экземплярам L4Linux доступ к физическому сетевому адаптеру. Для обеспечения доступа к памяти и регистрам PCI устройств был реализован драйвер виртуальной PCI шины для L4Linux, однако проблема обработки прерываний в ACPI системах не позволяет провести полноценное тестирование решения. Кроме того, очевидные минусы - невозможность использования одного сетевого интерфейса различными сервисами. – Минимизировать количество потоков выполнения (threads), занимающихся обработкой данных. Синхронизация доступа к критическим секциям может занимать значительную часть времени обработки сетевого пакета, как можно видеть в таблице 1. Некоторые подсистемы среды Genode (в частности, DDE_kit) переделаны для выполнения в однопоточным режиме. Для задач, производительность которых ограничена операциями ввода-вывода, использование многопоточной архитектуры зачастую увеличивает латентность. – Реализовать поддержку прерываний MSI-X и контроллера IO APIC и провести анализ влияния используемого источника прерываний (от устройства посредством MSI-X и через шину PCI) на время обработки входящих данных. 5 Заключение Был разработан рабочий прототип доверенного сервера, обеспечивающего изоляцию приложений при помощи паравиртуализации в среде Genode/L4Linux. В ходе тестирования было обнаружено падение производительности сетевой подсистемы, не позволяющее использовать полученное программное решение в качестве непосредственной замены ОС Linux. Детальный анализ прохождения нагрузочных тестов выявил ряд недостатков в дизайне системы, связанных с драйверами устройств и механизмом выделения памяти в многопроцессорной системе. Дальнейшая работа будет посвящена оптимизации драйверов и реорганизации многозадачности. Список литературы 1. Netperf homepage. http://netperf.org. 156 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 154. 12 2. Jeff Bonwick et al. The slab allocator: An object-caching kernel memory allocator. In USENIX summer, volume 16. Boston, MA, USA, 1994. 3. Crispin COwan. Buffer overflows: Attacks and defenses for the vulnerability of the decade. 2000. 4. TU Dresden. L4linux-running linux on top of l4. 5. Hermann Haertig et al. The performance of u-kernel-based systems. In ACM Simposum on Operating Systems Principles, volume 16. Saint-Malo, France, 1997. 6. Jochen Liedtke. Toward real microkernels. Communications of the ACM, 39(9):70– 77, 1996. 7. Hannes Weisbach. Ddekit approach for linux user space drivers. 2011. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 157
  • 155. Подход к верификации корректности миграции данных между СУБД с использованием криптографических хэш-функций Максим Журавлев, Виктор Полозов Кафедра системного программирования, Санкт-Петербургский государственный университет 24 сентября 2013 г. Аннотация В данной статье описывается автоматизированный подход к сравнению содержимого баз данных в промышленном проекте по миграции БД из СУБД MS SQL Server 2005 в Oracle 11gR2. Целевая БД должна содержать те же данные, что и исходная с точностью до ограничений, налагаемых используемыми СУБД, и быть функционально эквивалентной. Размер данных в исходной базе составляет порядка 6 терабайт, размер кода - 2.5 миллиона строк кода в хранимых процедурах. Разработан метод сравнения содержимого БД независимый от порядка просмотра записей, использующий коммутативные и криптографические хэш-функции. Показана применимость данного метода для практического использования. Ключевые слова - базы данных, миграция данных, тестирование, реинжиниринг, обеспечение качества, хэширование 1. Введение Перед коллективом, в котором имеют честь работать авторы, была поставлена задача произвести миграцию промышленной БД из Microsoft SQL Server 2005 в Oracle Database 11g Release 2. Проект условно можно разделить на следующие части: миграцию кода хранимых процедур, представлений (VIEW) и триггеров, миграция данных и обеспечение качества. При миграции производилась доработка кода с учётом специфики целевой СУБД, новых требований к системе, удалялся мёртвый код, и проводились другие согласованные с заказчиком изменения. При миграции схемы БД проводились такие изменения, как переименование процедур, таблиц и колонок, в основном связанные с ограничением СУБД Oracle в 30 байт на имя, и согласованные изменения в схеме, такие как разбиение по схемам и удаление не используемых объектов. Миграция данных проводилась без наличия прямого подключения между базами, через временные файлы с использованием инструментов Microsoft 158 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 156. SQL Server BCP и Oracle SQL*Plus. Конвертация данных проводилась в три этапа: часть данных конвертировалась при выгрузке, часть при загрузке, оставшиеся конвертации проводились как отдельный шаг после загрузки. В настоящей статье даётся более технически подробное описание реализованного авторами этапа тестирования – верификации корректности миграции путем сравнения набора хэшей. 2. Связанные работы Методологии миграции баз данных описаны в нескольких статьях. В статье [7] представлен пример методологии миграции данных. Процесс миграции между базами данных с отличающимися моделями данных, сопутствующие риски и проблемы описаны в [9] и [1]. Методологии миграции legacy-систем представлены в [15]. Проекты миграции баз данных сталкиваются со специфичными рисками и проблемами. Типичные риски и подходы к тестированию и обеспечению качества описываются в [11]. Разновидности тестирования, применяемые в течение жизненного цикла проекта миграции, рассматриваются в [12]. Общая схема организации обеспечения качества нашего проекта описана в статье [8]. Вопросы хэширования неупорядоченных коллекций (множеств и мультимножеств) рассматриваются в [4]. В этой же работе впервые вводится определение устойчивости хэш-функции множества (мультимножества) к коллизиям. Хэширование неупорядоченных коллекций тесно связано с инкрементальным хэшированием. Результаты с использованием операции XOR получены в работах [10] и [3]. Подход к хэшированию таблиц, использованный в нашем проекте, напоминает MSet-XOR-Hash из статьи [4]. Схожие подходы используются в похожей задаче поддержания консистентности реплицированных баз данных. К таким работам относятся: статьи [5], [6] и доклад [2]. В данных статьях не рассматривается сравнение БД, находящихся под управлением разных СУБД. 3. Требования к методу На этапе планирования проекта было решено, что совпадение данных в исходной и целевой БД должно быть проверено отдельным инструментом. Были сформулированы требования к инструменту: 1. Сравнение БД, находящихся в разных СУБД. Все используемые методы должны быть реализованы в MS SQL Server 2005 и Oracle 11gR2. 2. Настраиваемая процедура сравнения. 3. Независимость результата сравнения от порядка записей в выборках. Это требование связано с тем, что СУБД не гарантируют порядок выдачи результатов для выборки без явной директивы ORDER BY. От добавления явной директивы для упорядочивания отказались по двум причинам: отсутствие первичного ключа или уникального индекса у части таблиц, и существенное увеличение времени работы при упорядочивании без использования индекса. 2 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 159
  • 157. 4. Эффективность работы. Сюда включается возможность достаточно эффективной реализации и возможность распараллеливания в обеих СУБД. Приемлемым считалось время сравнимое со временем работы процедуры перегрузки данных. От требования определения места расхождения было решено отказаться, т.к. основной сценарий предусматривал использование верификации как средства доказательства корректности процедуры перекачки данных, а не как средства диагностики. Обзор как доступных для приобретения, так и бесплатных инструментов не выявил удовлетворяющих всем вышеперечисленным требованиям. 4. Реализация 4.1. Контролируемые параметры Верификация данных выполняется по следующим параметрам: 1. По метаданным  контроль наличия всех необходимых объектов исходной БД в целевой БД и нахождения их в корректном статусе (процедуры успешно откомпилированы, триггеры установлены). 2. Контроль числа строк в таблицах. 3. Хэши столбцов таблиц и таблиц целиком. Первый из вышеперечисленных пунктов реализуется анализом кодов завершения и других записей в log-файлах, описывающих процесс выгрузкизагрузки. Остальные – сравнением результатов выполнения скриптов подсчета хэшей в исходной и целевой БД. 4.2. Этапы верификации миграции 1. Выполнение скриптов расчета хэшей в исходной БД. Хэши сохраняются в новую таблицу исходной БД. 2. Выгрузка таблицы с хэшами в промежуточный файл. 3. Загрузка результатов из промежуточного файла в целевую БД. 4. Выполнение скриптов расчета хэшей в целевой БД. Результаты пополняют таблицу с хэшами исходной БД. 5. Генерация отчета о расхождениях или полном совпадении набора хэшей. Шаги, относящиеся к целевой БД, выполняются до включения в журналирующих триггеров. 160 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 3
  • 158. 4.3. Расчет хэшей Для каждой таблицы вычисляются n+2 хэша, где n – количество столбцов. Первый - количество записей в таблице. Несовпадение количества записей позволяет выявить грубые ошибки перегрузки, но совпадение возможно при искажениях в значениях данных, что является большим недостатком, особенно для таблиц, содержащих типы данных, трансформирующиеся при миграции. Остальные хэши предназначены для устранения этого недостатка. Они рассчитываются следующим образом: записи таблицы обрабатываются одна за одной в произвольном порядке – выполняется запрос SELECT COLU M N1 , COLU M N2 ,· · ·, COLU M NN FROM TABLE. Значение каждого поля преобразуется в массив байтов, например, datetime преобразуется в количество миллисекунд с 01.01.1970 00:00:00 (POSIX time) как bigint. Получившееся число интерпретируется как массив байтов. Массивы конкатенируются. Получившийся массив подается на вход хэш-функции. Может быть использована любая, реализация которой доступна в обеих СУБД. Авторами была выбрана MD5 [13]. Возвращенное значение представляет собой хэш записи. Данная операция может интерпретироваться как создание дополнительного столбца в таблице. Набор хэшей таблицы не должен зависеть от порядка обхода записей, поэтому было принято решение использовать коммутативную операцию XOR (исключающее или) для получения итоговых хэшей из хэшей записей: для каждого столбца, включая “виртуальный” столбец хэшей записей, вычисляется XOR всех элементов. MD5 – криптографическая хэш-функция, поэтому возвращаемое значение можно рассматривать как равномерно распределенную случайную величину из интервала [0; 2128 − 1]. XOR таких величин не меняет распределение, поэтому XOR “виртуального” столбца хэшей записей можно рассматривать как равномерно распределенную случайную величину из интервала [0; 2128 − 1]. В исходной БД количество записей в каждой таблице не превышает 1013 . Вероятность обнаружения не менее одной коллизии не превышает 10−12 [14]. Четное количество идентичных записей из-за свойства XOR(x, x) ≡ 0 может скрыть ошибку в миграции какого-либо типа данных, но отладка метода производилась с использованием таблиц, содержащих уникальные записи. Вероятность же нескольких аппаратных сбоев, не попавших в журнал, и, повлиявших только на четное количество идентичных записей в одной таблице, оценивается как пренебрежимо малая. Таблицу БД с первичным ключом можно рассматривать как множество. Изложенный выше метод отличается от MSet-XOR-Hash [4] для хэширования (мульти)множеств отсутствием рандомизации – хэш-функция фиксирована, а не выбирается из некоторого семейства. Это делает метод уязвимым для целенаправленной атаки. Однако во время разработки он позволил выявить ряд ошибок в процессе перегрузки. Остальные хэши вычисляются не криптографическими хэш-функциями, но на этапе отладки они облегчали процесс поиска источников ошибок. Поскольку данные могут подвергнуться трансформации при перегрузке и представляться разными наборами байтов, вычисление хэш-функции может завершиться с разными результатами в исходной и целевой БД. Для унификации результатов значения полей приводятся к нормальной форме для составления аргумента хэш-функции по правилам, изложенным в 4 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 161
  • 159. таблице 1. 4.4. Генерация скриптов Скрипты, не зависящие от схемы БД, – командные файлы для утилит загрузки-выгрузки данных обеих СУБД, SQL-запросы для создания таблиц с результатами и генерации отчета, вспомогательные функции для хэширования отдельных типов данных в исходной СУБД, Java-функция хэширования в целевой СУБД, написаны вручную. Скрипты, зависящие от схемы, генерируются разработанной утилитой (язык реализации F#) на основании актуальной схемы исходной БД (используется экземпляр класса Server) и дополнительных параметров, перечисленных в конфигурационном файле. Скрипт для исходной БД – код на Transact-SQL определяет три вспомогательных функции: для конвертации DATETIME в BIGINT, вычисления хэша BINARY, вычисления хэша VARCHAR, затем для каждой таблицы вычисляются хэши по схеме, описанной выше. Скрипт для целевой БД – код на PL/SQL создаёт для каждой таблицы объект CURSOR, передаёт его в Java-функцию вычисления хэшей, сохраняет возвращенный результат в таблицу. Данный подход обусловлен недостаточной производительностью хэширования, реализованного средствами PL/SQL. Как сказано выше, в качестве коммутативной операции, обеспечивающей независимость итоговых хэшей от порядка просмотра записей, выбрана операция XOR, которую в данной версии PL/SQL можно выразить только посредством нескольких вызовов встроенных функций. Получившийся объем разработанного кода составил 1,5KLOC на F#, 0,3KLOC на cmd/shell, 0,4KLOC на Java. Объем сгенерированного кода для мигрируемой БД, содержащей 2410 таблиц, – 144КLOC на PL/SQL (8,4Mb) и 215KLOC на T-SQL (18,3Mb). 4.5. Показания производительности Сравнение БД описанным методом требует значительных вычислительных ресурсов. В отличие от загрузки-выгрузки “узким местом” является не производительность системы ввода-вывода, а скорость вычисления хэшей. Затраты времени на сравнение стали сравнимы с временем перегрузки БД, после того как утилита генерации скриптов была доработана для генерации скриптов, вычисляющих наборы хэшей для нескольких таблиц параллельно. Для MS SQL Server 2005 генерируются несколько файлов с кодом на Transact-SQL для обработки набора таблиц сопоставимого суммарного размера. Каждый скрипт передаётся для исполнения экземпляру служебной утилиты Microsoft ® SQL Server Command Line Tool средствами ОС. Для Oracle 11gR2 генерируется один файл с кодом на PL/SQL, использующий пользовательские функции реализованные на встроенном языке Java для обработки переданного ResultSet. Скрипт передаётся для исполнения служебной утилите Oracle SQL*Pus. Средствами СУБД Oracle устанавливается количество потоков, обрабатывающих задания из очереди, заполняется очередь заданий. Каждое задание в очереди обрабатывает одну таблицу или часть таблицы, имеющей численный первичный ключ. 162 5 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 160. Тип в исходной БД BIT TINYINT SMALLINT INT BIGINT FLOAT DECIMAL(n, m), n − m ≤ 18 и m ≤ 18 DECIMAL(n, m), остальные NUMERIC(n, m) MONEY DATETIME Тип в целевой БД NUMBER(1) NUMBER(18) NUMBER(18) NUMBER(18) NUMBER(19) FLOAT NUMBER(n, m) Преобразование 4 байта little-endian 4 байта little-endian 4 байта little-endian 4 байта little-endian 8 байтов little-endian 8 байтов little-endian по 4 байта целой и дробной частей, рассматриваемых как INT, little-endian NUMBER(n, m) SMALLDATETIME DATE BINARY BLOB IMAGE BLOB VARBINARY BLOB CHAR(n), n ≤ 4000 VARCHAR2(n) CHAR(n), пустая строка или NULL VARCHAR2(n) NCHAR(n), n ≤ 4000 SYSNAME VARCHAR(n), n ≤ 4000 NVARCHAR(n), n ≤ 4000 CHAR(n), n 4000 NCHAR(n), n 4000 VARCHAR(n), n 4000; VARCHAR(MAX) NVARCHAR(n), n 4000; NVARCHAR(MAX) TEXT; NTEXT VARCHAR2(n) результат вычисления хэш-функции(MD5) от значения поля, преобразованного в строку аналогично DECIMAL(n, m) аналогично DECIMAL(19, 4) аналогично BIGINT после конвертации в Unix time аналогично BIGINT после конвертации в Unix time результат вычисления хэш-функции (MD5) от значения поля результат вычисления хэш-функции (MD5) от значения поля результат вычисления хэш-функции (MD5) от значения поля удаляются ведущие и замыкающие пробелы, символы переноса строки (при загрузке в целевую БД происходит нормализация); получившаяся строка конвертируется в набор байтов с учетом кодовой страницы; вычисляется значение хэшфункции(MD5) СУБД Oracle рассматривает пустую строку как NULL; набор байтов совпадающий со значением хэш-функции при аргументе – пустой строке аналогично CHAR VARCHAR2(128) VARCHAR2(n) аналогично NCHAR(128) аналогично CHAR VARCHAR2(n) аналогично CHAR CLOB CLOB CLOB аналогично CHAR аналогично CHAR аналогично CHAR CLOB аналогично CHAR CLOB аналогично CHAR NUMBER(n, m) NUMBER(19, 4) DATE Таблица 1: Преобразование полей записей в набор байтов 6 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 163
  • 161. При выборе подхода к реализации были рассмотрены различные подходы к реализации и проведено сравнение их производительности: • Код на Transact-SQL в целом удовлетворял требованиям по производительности. • Реализация хэширования на PL/SQL, – через проход циклом по курсору, с подсчётом хэшей, и их объединение через операцию XOR, реализованную через встроенную функцию BitAND, – проигрывал в производительности TSQL-коду в 5-10 раз. Поэтому было принято решение о его оптимизации. • Реализация на языке Java, встроенном в Oracle, на разных таблицах показала или сходный результат с PL/SQL-реализацией, или улучшение производительности. Дополнительным аргументом, в пользу реализации на Java, так же можно назвать относительною простоту реализации, что позволило быстрее получить как первые, так и окончательные результаты. • Реализация на языке Java, запущенная в несколько потоков, показала почти линейный рост производительности до достижения насыщения. На следующем графике представлены сравнение времени работы различных реализаций хэширования для одной из основных таблиц. В уменьшенной для целей тестирования базе в этой таблице 4 миллиона записей общим объемом порядка 2.5 гигабайт. Тестирование производилось на сервере с 8-ядерным процессором. SQLServer 294 PL/SQL 1 поток Java 1 поток Java 2 потока 615 Java 4 потока 395 Java 8 396 Java 16 1047 1510 2231 0 300 600 900 1200 1500 1800 2100 График 1: влияние реализации на время расчета (сек.) По результатам тестирования для Oracle было принято решение в пользу Java-реализации с запуском несколько потоков. Итоговые составляющие времени перегрузки тестовой базы, содержащей 21Гб в 1.5К не пустых таблицах даны в таблице 2. Таким образом, время хэширования сопоставимо со временем перегрузки, что позволяет утверждать, что поставленные требования были удовлетворены. 5. Результаты Описанным методом сравнивались исходная и целевая БД при каждом ночном тестировании очередной сборки, что позволило выявить и исправить 7 164 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 162. Этап Выгрузка из MSSQL Хэширование в MSSQL Загрузка в Oracle Хэширование в Oracle Время (сек.) 1109 799 2134 2279 Таблица 2: Время этапа миграции тестового набора данных ошибки в процедуре перегрузки и процедуре вычисления хэшей. Для доказательства эквивалентности изменений, совершаемых в исходной и целевой БД, при воспроизведении трасс типичных действий пользователя были сгенерированы журналирующие триггеры, вычисляющие хэши перехваченных наборов записей по описанной выше схеме. 6. Заключение Примененный метод сравнения содержимого баз данных путем подсчёта использующий коммутативные и криптографические хэш-функции позволил успешно решить поставленную перед авторами задачу: было реализовано автоматизированное тестирование корректности миграции данных между различными СУБД путем сравнения набора хэшей, что позволило устранить ряд методических ошибок перегрузки. Разработанный метод возможно переиспользовать, при необходимости пополнив поддержкой типов данных, не встретившихся в схеме исходной БД, и поддержкой СУБД, отличных от MS SQL Server 2005 и Oracle 11gR2. Список литературы [1] Maatuk A. Migrating Relational Databases into Object-Based and XML Databases. Northumbria University, 2009. [2] Ulrich Arndt. How to compare tables between td systems in a dual active environment. In The 2012 Teradata PARTNERS Conference, 2012. [3] Mihir Bellare, Oded Goldreich, and Shafi Goldwasser. Incremental cryptography: The case of hashing and signing. In In CRYPTO, 1994. [4] Dwaine Clarke, Srinivas Devadas, Marten van Dijk, Blaise Gassend, and G. Edward Suh. Incremental multiset hash functions and their application to memory integrity checking. In In Advances in Cryptology - Asiacrypt 2003 Proceedings, volume 2894 of LNCS, pages 188–207. Springer-Verlag, 2003. [5] Fabien Coelho. Remote comparison of database tables technical report a/375/cri, 2006. [6] Fabien Coelho. Remote comparison of database tables. In DBKDA 2011 : The Third International Conference on Advances in Databases, Knowledge, and Data Applications, 2011. 8 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 165
  • 163. [7] Hudicka J. The Complete Data Migration Methodology. Dulcian Inc., 2000. [8] I. Kirilenko and E. Baranov. Automation of QA in the project of DB migration from SQL Server into Oracle. In Proceedings of the 6th Spring/Summer Young Researchers’ Colloquium on Software Engineering (SYRCoSE 2012), pages 178–181. Perm, Russia, May 30-31, 2012. [9] Chang-Yang Lin. Migrating to relational systems: Problems, methods, and strategies. 4(4):369–380, 2008. [10] R. Guerin M. Bellare and P. Rogaway. Xor macs: New methods for message authentication using finite pseudorandom functions. In In CRYPTO, 1994. [11] Haller K. Matthes F., Schulz C. Testing quality assurance in data migration projects. In 2011 27th IEEE International Conference, 2011. [12] Augustinez J. Redlichx A. Lodha S. Vin H. Deshpande A. Gharote M. Mehrotrak A. Patil S., Royy S. Minimizing testing overheads in database migration lifecycle. In The 16th International Conference on Management of Data (COMAD), 2010. [13] Ronald L. Rivest. The md5 message-digest algorithm. Internet RFC 1321, April 1992. [14] Bruce Schneier. Applied Cryptography, Second Edition. John Wiley Sons, 1996. [15] Bisbal J. Grimson J. Wade V. O’Sullivan D. Richardson R. Wu B., Lawless D. Legacy system migration : A legacy data migration engine. In Proccedings of the 17th International Database Conference, pages 129– 138. Springer-Verlag, 1997. 166 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 9
  • 164. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 167
  • 165. 168 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 166. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 169
  • 167. 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶 170 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 168. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 171
  • 169. 172 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 170. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 173
  • 171. 174 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 172. 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 175
  • 173. 176 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 174. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 177
  • 175. 178 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 176. Применение технологий OLAP и MapReduce для обработки результатов нагрузочного тестирования Сенов А.А. Костромской государственный технологический университет г. Кострома, ул. Дзержинского, 17 andrey.senov@gmail.com Аннотация. Современные трейдинговые платформы представляют собой сложные распределённые системы, обслуживающие большое число пользователей по различным протоколам передачи данных. При нагрузочном тестировании таких систем возникает существенный объём информации, которая может быть проанализирована QA-специалистами с целью обнаружения дефектов. Для этого часто требуется выявлять зависимости между значениями показателей, полученными в ходе тестирования, путём проведения многофакторного анализа, что при большом объёме данных является трудоёмкой задачей, требующей специализированного ПО, в частности, систем интерактивной аналитической обработки OLAP. В данной статье описывается оригинальный алгоритм многомерного анализа результатов нагрузочного тестирования на стороне клиента. С помощью технологии MapReduce предложенный алгоритм оптимизирован для работы под управлением многоядерных процессоров. Ключевые слова: OLAP, MapReduce, нагрузочное тестирование, анализ данных 1 Введение Анализ результатов нагрузочного тестирования трейдинговых платформ в большинстве случаев связан с обработкой существенных объёмов информации. Это обусловлено тем, что современные платформы являются сложными распределёнными системами, обрабатывающими свыше 40 тысяч заявок в секунду при среднем времени отклика менее 300 микросекунд. С другой стороны, аппаратная инфраструктура тестовых инструментов по производительности на несколько порядков уступает биржевой. Это неизбежно влечёт необходимость разрабатывать инструменты как можно более простые, не перегруженные функциональностью, для достижения высокой эффективности при решении основных задач[1]. В связи с этим при анализе данных, полученных в ходе нагрузочного тестирования, чтобы быстро ответить на Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 179
  • 177. поставленные вопросы, возникает потребность в использовании специализированного ПО, к какому можно отнести большой класс продуктов бизнес-аналитики BI (англ. Business Intelligence). Среди программных решений BI-класса можно выделить системы интерактивной аналитической обработки OLAP (англ. Online Analytical Processing), предназначенные для построения обобщённой информации на основе данных, имеющих многомерное представление. При нагрузочном тестировании такие системы помогают QAаналитикам (англ. Quality Assurance) качественно осуществить многофакторный анализ зависимостей между значениями показателей, полученными в ходе тестирования, с целью обнаружения дефектов платформы. 2 Существующие Решения В основе любой OLAP-системы лежит многомерная модель данных, называемая многомерным кубом, гиперкубом или просто кубом. По месту нахождения машины, рассчитывающей многомерные кубы, современные OLAP-системы можно разделить на две группы: клиентские и серверные. В случае клиентской системы сервер отправляет клиенту исходные данные, клиент производит расчет многомерных кубов и выдает результат пользователю. В случае серверной системы сервер рассчитывает многомерные кубы и отправляет результат клиенту, клиент выдает результат пользователю[2]. На сегодняшний день обе группы представлены на рынке широким спектром продуктов. Для серверных систем это, например, такие решения, как Microsoft SQL Server Analysis Services[3], OLAP Option to Oracle Database[4] или Palo[5]. Серверные решения являются наиболее быстрыми, надежными и имеют ряд других преимуществ: например, техническую поддержку от производителей. Как следствие, такие системы являются дорогостоящими. Можно принять во внимание наличие open-source версии Palo, но она имеет существенные ограничения по сравнению с коммерческой: например, отсутствие возможности использования более чем одного ядра процессора[6]. Среди клиентских решений популярными остаются электронные таблицы MS Office Excel, позволяющие выполнять многомерный анализ с помощью механизма Pivot table[7]. Pivot table удобно использовать, когда исходные данные изначально заносятся в электронную таблицу, что при серьёзных задачах, таких как нагрузочное тестирование, исключено. Поэтому пользователь обязательно сталкивается со сложностью конфигурации подключения к внешним источникам данных. Факт наличия на рынке разнообразных продуктов, обладающих своими достоинствами и недостатками, говорит о том, что для OLAP, как и для многих сложных задач, до сих пор нет единого решения, одинаково подходящего для всех. В рамках статьи предлагается рассмотреть оригинальный алгоритм многомерного анализа результатов нагрузочного тестирования на стороне клиента. Решение главным образом направлено на сокращение затрат на тестовые и аналитические инструменты. 180 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 178. 3 Предлагаемое Решение В случае тестирования биржевых платформ существует несколько основных источников, из которых можно получить информацию для анализа: 1. Данные, которыми оперируют непосредственно тестовые инструменты; 2. Статистическая информация из внутренней базы данных платформы, а также записи журналов активности её компонентов и пользователей; 3. Независимые данные, полученные напрямую от сетевых устройств, через которые происходит общение клиентов с платформой. Опыт показывает, что наиболее достоверным является источник под номером 3, но для полноты картины поведения тестируемой системы данные обычно собираются изо всех трёх источников и складываются в общую базу. Данные, как правило, представляют собой разнообразные сведения о типах сообщений, значениях полей сообщений, клиентах, разного рода настройках и, конечно, временных отметках. Опираясь на весь этот массив информации, аналитики оценивают такие параметры, как время отклика, количество сообщений, пропускную способность, используемую память, загрузку процессоров и прочее[8]. При создании алгоритма основным принципом служила простота, и вся его суть сводится к выполнению операций над generic-контейнерами в оперативной памяти клиентской машины. Перенос вычислений на сторону клиента обусловлен высокой производительностью современных настольных ПК, сочетающейся с их низкой стоимостью. Так, например, в настоящее время конфигурация среднего рабочего места это: процессор с 2-4 ядрами и 4-8 ГБ оперативной памяти. Такие характеристики в сочетании с гигабитными сетями, использующимися уже повсеместно, позволяют решить задачу многомерного анализа без привлечения дополнительных ресурсов. Алгоритм написан на языке C++ с применением Qt Framework, что даёт такие преимущества, как высокое быстродействие, кроссплатформенность, а также возможность использования настольной реализации технологии MapReduce[9] с целью получения масштабируемого решения для работы под управлением многоядерных процессоров. Как было сказано выше, в основе любой OLAP-системы лежит гиперкуб. И первая проблема, которую необходимо решить, – это представление гиперкуба с точки зрения кода. Для этого сначала необходимо определиться, как информация будет попадать из базы данных в гиперкуб. Ответ очевиден – нужно выполнить SQL-запрос SELECT. Запросы предлагается писать по правилам, которые отражены в листинге 1. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 181
  • 179. Листинг 1. Общий вид SQL-запроса выборки данных; где dimension0 … dimensionN – значения измерений гиперкуба, measure – мера, значение ячейки гиперкуба, образуемое при уникальном сочетании значений измерений. select dimension0, dimension1, dimensionN, measure from … inner join … on … … where condition … dimension2, …, Проще говоря, запросы должны возвращать кортежи, состоящие из различных сочетаний измерений и соответствующие этим сочетаниям числовые значения анализируемой величины. Таким образом, правила помогают подготовить данные и передать их клиенту уже в структурированном виде. Атрибуты кортежей, описывающие значения измерений, могут иметь самые разнообразные типы, а последний атрибут measure в общем случае, является числом с плавающей точкой. Так как на этом этапе задача состоит не только в создании универсального способа хранения данных в ОЗУ, но и обеспечении возможности построения простых и составных ключей по значениям измерений на осях гиперкуба, которые будут необходимы для упорядочивания и поиска информации, все измерения следует привести к одному типу ещё до размещения в ОЗУ. В качестве такого типа подходят строки. Это объясняется тем, что большинство измерений изначально имеют строковые значения: названия протоколов, сообщений, финансовых инструментов, имена пользователей и т.п., а все другие типы при необходимости всегда можно привести к строковому, используя SQL-функцию cast. Что касается дат, то при переводе их в строковый тип они приобретают ISO-формат YYYY-MM-DD, и упорядочивание таких строк напрямую соответствует упорядочиванию дат. Таким образом, кортежи запроса можно описать следующим классом: Листинг 2. Представление кортежей запроса, где поле класса _keys содержит атрибуты, представляющие значения измерений, приведённые к строковому типу; поле _measure – последний атрибут кортежа, представляющий ячейку гиперкуба. class Tuple { public: Tuple(const QStringList keys, double measure); const QStringList keys() const; void setKeys(const QStringList keys); double measure() const; void setMeasure(double measure); private: QStringList _keys; double _measure; }; 182 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 180. Собственно гиперкуб является generic-контейнером QList, содержащим множество экземпляров класса Tuple, описанного в листинге 2, и представляет собой мгновенный снимок данных. Следующая проблема – выбор осей гиперкуба для формирования отчёта и передача этой информации коду, который будет его формировать. Для пользователя естественным представлением осей гиперкуба являются два списка их названий: один для строк отчёта, второй – для столбцов, допускающие множественный выбор и перемещение элементов списка относительно друг друга. С точки зрения кода, названия измерений использовать неудобно, т.к. значения измерений хранятся в QStringList, который позволяет обращаться к элементам по индексам. Когда пользователь меняет измерения местами с целью получения в отчёте необходимой детализации и агрегации, их порядок уже не будет соответствовать тому, который был задан при написании запроса, поэтому для соответствия названий измерений их порядковым индексам предлагается использовать словарь QMapQString, int, в котором в качестве ключей хранятся названия измерений, в качестве значений – их порядковые индексы. Отчёт, который строится алгоритмом, представлен в виде вектора векторов. Для удобства вектор инкапсулирован в класс Projection, который показан в листинге 3. Листинг 3. Представление отчёта, где поле класса _data является вектором векторов: двумерным массивом, содержащим ячейки отчета. class Projection { public: Projection(int width = 0, int height = 0); Projection(const QSize size); void resize(int width, int height); void resize(const QSize size); void clear(); int width(); int height(); QVectorCell operator[](int i); private: QVector QVectorCell _data; }; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 183
  • 181. Листинг 4. Представление ячейки отчёта, где поле _value аккумулирует значения, прибавляемые к ячейке; _min, _max содержат минимальное и максимальное значения ячейки соответственно; _count считает количество слагаемых для расчёта среднего значения ячейки. class Cell { public: Cell(); Cell(int x, int y, double value); double value() const; void setValue(double value); int x() const; void setX(int x); int y() const; void setY(int y); double max() const; double min() const; double avg() const; Cell operator+=(double value); const Cell operator+(const Cell other); bool isEmpty(); void clear(); private: int _x; int _y; double _value; double _max; double _min; int _count; }; В листинге 4 можно увидеть, что алгоритм даёт возможность выбора величин отчёта, которые будут показаны пользователю в конечном счёте: сумма, минимум, максимум, среднее. Формирование самого отчёта выполняется в три этапа: 1. Сканирование гиперкуба (generic-контейнера QList) с целью формирования словарей с полными уникальными ключами (заголовки колонок и строк отчёта); 2. Сканирование полученных словарей с целью задания монотонно возрастающих целочисленных значений с шагом 1 (номера колонок и строк отчёта по порядку); 3. Сканирование гиперкуба с целью восстановления полученных ранее ключей и получения по ним координат ячеек отчёта из сформированных словарей, заполнение отчёта; В первых реализациях все три пункта выполнялись в одном потоке, что при наличии многоядерных процессоров являлось само по себе не эффективным. Поэтому, с целью оптимизации быстродействия алгоритма, было решено 184 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 182. провести распараллеливание с помощью технологии MapReduce. Предварительный анализ затрат времени показал, что на пункты 1 и 3 алгоритма приходится свыше 95% общих затрат времени, поэтому пункт 2 распараллеливать нецелесообразно. Рис. 1. Диаграмма деятельности. Пункты 1 и 3, предложенные к распараллеливанию, не являются потоковобезопасными – в них осуществляется модификация глобальных объектов: словари с полными ключами и ячейки отчёта. Но одним из плюсов MapReduce является возможность абстрагирования от использования низкоуровневых примитивов синхронизации, поэтому приведенные ниже фрагменты кода не содержат ни мьютексов, ни семафоров, ни блокировок на чтение-запись. Так, пункт 1 реализован следующим образом: Листинг 5. Функции Map и Reduce для формирования словарей с полными ключами. QMapQString, int _dimensions; QMapQString, int _xCoordinates, _yCoordinates; QStringList _xDimensions, _yDimensions; QPairQString, QString mapFullKeys(const Tuple tuple) { QPairQString, QString keys; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 185
  • 183. QString key; int i = 0; foreach (const QString dimension, _xDimensions) { i = _dimensions[dimension]; key += tuple.keys()[i]; } keys.first = key; key.clear(); foreach (const QString dimension, _yDimensions) { i = _dimensions[dimension]; key += tuple.keys()[i]; } keys.second = key; return keys; } void reduceFullKeys(int /*i*/, const QPairQString, QString keys) { _xCoordinates[keys.first] = -1; _yCoordinates[keys.second] = -1; } Функция mapFullKeys в листинге 5 вызывается для каждого элемента гиперкуба параллельно. Имена выбранных для отчёта измерений представлены в виде двух списков: _xDimensions, _yDimensions. С помощью словаря _dimensions восстанавливаются индексы измерений и уже по индексам извлекаются их значения. В случае если на строки отчёта отображаются несколько измерений гиперкуба, то ключ будет представлять собой конкатенацию значений измерений. То же самое справедливо и для столбцов. В итоге функция возвращает пару ключей, которая автоматически передается функции reduceFullKeys, которая, в свою очередь, помещает ключи в формируемые словари _xCoordinates и _yCoordinates. В итоге словари будут состоять из уникальных ключей, автоматически отсортированных в порядке возрастания. На втором шаге оба словаря перебираются по порядку и ключам присваиваются возрастающие значения: 0, 1, 2, 3 и т.д. Таким образом, словари в качестве ключей содержат заголовки столбцов и строк будущего отчёта, а в качестве значений – их порядковые индексы. Реализация третьего шага отображена ниже: Листинг 6. Функции Map и Reduce для заполнения отчёта. QMapQString, int _dimensions; QMapQString, int _xCoordinates, _yCoordinates; QStringList _xDimensions, _yDimensions; Projection _projection; Cell mapProjection(const Tuple tuple) { 186 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 184. QString key; foreach (const QString dimension, _xDimensions) { int i = _dimensions[dimension]; key += tuple.keys()[i]; } int x = _xCoordinates[key]; key.clear(); foreach (const QString dimension, _yDimensions) { int i = _dimensions[dimension]; key += tuple.keys()[i]; } int y = _yCoordinates[key]; return Cell(x, y, tuple.measure()); } void reduceProjection(int /*i*/, const Cell cell) { _projection[cell.x()][cell.y()] += cell.value(); } Функция mapProjection в листинге 6 строит уникальные ключи по той же схеме, что и mapFullKeys в листинге 5. По ключам из сформированных ранее словарей _xCoordinates и _yCoordinates извлекаются координаты ячеек отчёта, а из текущего кортежа гиперкуба извлекается величина _measure. Все три значения передаются в функцию reduceProjection в виде экземпляра класса Cell. В свою очередь, reduceProjection по указанным координатам получает ячейку отчёта и к её значению прибавляет величину _measure. После распараллеливания алгоритма была проведена экспериментальная оценка затрат времени на построение отчета по различным сочетаниям измерений гиперкуба. Для того чтобы наглядно убедиться в эффективности MapReduce, описанная выше реализация сравнивается с тестовой реализацией, выполненной по технологии PTHREAD[10] с использованием примитивов синхронизации. Априори известно, что затраты времени зависят от ряда как контролируемых, так и неконтролируемых факторов, таких как: 1. объём выборки из базы данных, т. е. размер гиперкуба; 2. количество и длины полных ключей измерений гиперкуба, выбранных для построения отчёта; 3. количество параллельных потоков; 4. тип процессора: архитектура, количество ядер, частота, объём кэш; 5. объём и частота основной памяти; 6. тип, разрядность и версия операционной системы, частота системного таймера; 7. версия Qt Framework. Из перечисленных факторов, факторы с 4 по 7 являются неконтролируемыми и, более того, все они быстро меняются с течением времени, поэтому их влияние можно оценить только качественно. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 187
  • 185. Первый фактор, пока объём выборки не превышает объем доступной оперативной памяти, соответствует линейной зависимости затрат времени от размера выборки; при этом соотношение затрат времени для различных вариантов реализации параллельного кода должно оставаться постоянным, поэтому в эксперименте рассматривается достаточно малый объём данных: тестовый гиперкуб имеет 9 измерений и состоит из 66 354 кортежей. Для оценки количества и размеров составных ключей предлагается использовать обобщённый параметр K, для определения которого используется следующее соотношение, основанное на том, что среднее время поиска в дереве пропорционально его глубине, а среднее время сравнения двух строк пропорционально их длине[11]: K= log2(N)*L . (1) где: K– обобщённый параметр; N– количество ключей; L– средняя длина ключа. Так как отчёт является двумерным массивом, то результирующий показатель будет равен сумме показателей для колонок и строк: K = Kx + Ky = log2(X)*Lx + log2(Y)*Ly . (2) где: K – результирующий параметр; Kx,y – обобщённые параметры для колонок и строк; X, Y – количество ключей; Lx,y – средние длины ключей. Для проведения экспериментов использовался компьютер с 6-ядерным процессором AMD Phenom II X6 1100T и 4 Гб ОЗУ; операционная система Linux KUbuntu 12.04 LTS 64-bit с версией ядра 3.2; Qt Framework версии 4.8.4. Данные снимались в 10-кратной повторности. Для определения затрат времени на формирование словарей с ключами и заполнение отчёта использовался системный вызов clock_gettime. На рисунке 2 представлены общие затраты времени для сравниваемых технологий: однопоточного варианта, многопоточного варианта на MapReduce и многопоточных вариантов на PTHREAD - в зависимости от значений предлагаемого обобщенного параметра K. 188 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 186. Рис. 2. Затраты времени на формирование ключей и заполнение отчета в зависимости от обобщенного параметра для 6-ядерного процессора AMD Phenom II X6 1100T, частота ядер 3.3 ГГц, кэш 6144 Кб, 64-разрядная ОС Linux 3.2, Qt 4.8.4. Из графиков видно, что гипотеза о линейной зависимости затрат времени от обобщённого параметра K подтвердилась. Общие затраты времени для варианта с 6 потоками PTHREAD и для варианта с использованием MapReduce очень близки между собой. Однако с увеличением значения обобщенного параметра, MapReduce демонстрирует лучшую эффективность. Поскольку для конечного пользователя, QA-специалиста, важны общие затраты времени, а для разработчиков - кроссплатформенность и масштабируемость, MapReduce является верным выбором при оптимизации задачи многофакторного анализа на стороне клиента. 4 Заключение Описанная методика анализа данных, обладая высокой эффективностью, кроссплатформенностью и масштабируемостью, является подходящей альтернативой существующим решениям при обработке результатов нагрузочного тестирования трейдинговых платформ. Алгоритм прост в использовании, т.к. его конфигурация заключается лишь в написании стандартного SQL-запроса выборки SELECT, придерживаясь указанных правил; а применение технологии MapReduce позволяет использовать доступную мощь многоядерных процессоров, которые в настоящее время устанавливаются на абсолютное большинство компьютеров. Данное решение апробируется в ряде проектов по нагрузочному тестированию компании «Exactpro Systems», LLC. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 189
  • 187. Литература 1. Иткин И.Л.: Тестирование биржевых систем в условиях высокочастотного трейдинга // SQA Days #10: [Электронный ресурс]. Режим доступа: http://sqadays.com/talk.sdf/sqadays/11151/talks/12196 2. Каширин И.Ю., Семченков С.Ю.: Интерактивная аналитическая обработка данных в современных OLAP-системах // Бизнес-информатика. 2009. Вып. 2(8). 3. SQL Server Analysis Services - Multidimensional Data // MSDN: [Электронный ресурс]. Режим доступа: http://msdn.microsoft.com/en-us/library/bb522607(v=sql.105).aspx 4. Oracle OLAP // Oracle: [Электронный ресурс]. Режим доступа: http://www.oracle.com/technetwork/database/options/olap/index.html 5. Palo by Jedox // Palo: [Электронный ресурс]. Режим доступа: http://palo.net/ 6. Comparison - Palo (Open Source) / Jedox (Premium) // Palo: [Электронный ресурс]. Режим доступа: http://www.palo.net/index.php?id=13 7. Jelen Bill, Alexander Mike. Pivot table data crunching. Pearson Education: 2011. 8. Alexey Zverev: Technical Testing // EXTENT February 2011: [Электронный ресурс]. Режим доступа: http://www.slideshare.net/IosifItkin/technical-testing-introduction 9. Qt 4.8: Concurrent Programming // Qt Reference Documentation: [Электронный ресурс]. Режим доступа: http://doc-snapshot.qt-project.org/4.8/threads-qtconcurrent.html 10. Blaise Barney: POSIX Threads Programming // Lawrence Livermore National Laboratory: [Электронный ресурс]. Режим доступа: https://computing.llnl.gov/tutorials/pthreads/ 11. Кнут Д. Э.: Искусство программирования, том 3. Сортировка и поиск, 2-е издание. – М.: Издательский дом «Вильямс», 2003. 190 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 188. Особенности инструментов для тестирования, применимых при промышленной эксплуатации трейдинговых систем Aнастасия Матвеева1, Николай Антонов2, Иосиф Иткин3 1 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул. Ленина, 20, Anastasia.Matveeva@exactpro.com 2 Костромской государственный технологический университет, г. Кострома, ул. Дзержинского, 17, Nikolay.Antonov@exactpro.com 3 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Iosif.Itkin@exactpro.com Aннотация. В статье рассматриваются основные требования к инструментам, разработанным для верификации корректной работы электронных трейдинговых систем с использованием методов большого объема автоматизированного тестирования (НiVAT); анализируется применимость подобных инструментов при промышленной эксплуатации трейдинговых систем. Ключевые слова: автоматизация тестирования, трейдинговые системы, HiVAT. 1 Введение Ускоренное развитие технологий, используемых в электронных трейдинговых системах, признается одним из наиболее существенных факторов, влияющих на изменения в структуре и стабильности функционирования международных финансовых рынков [1]. Решения, обеспечивающие качество программных и архитектурных компонентов, становятся все более востребованными участниками рынка и организациями, регулирующими финансовый сектор [2; 3]. С технологической точки зрения трейдинговые системы в большинстве случаев являются сложными адаптивными распределенными программноаппаратными комплексами, осуществляющими параллельное выполнение большого количества транзакций в режиме реального времени [4]. Современные системы обеспечивают время отклика, измеряемое долями миллисекунды, и при своей работе генерируют значительные объемы данных [5]. В связи с возрастающей долей финансовых транзакций, осуществляемых посредством автоматизированных компьютерных систем [6], основные взаимодействия в трейдинговых системах базируются на различных открытых и закрытых сетевых протоколах и программных интерфейсах доступа [7]. Специфика автоматизированных рабочих мест пользователя трейдинговой системы состоит, в частности, в высокой частоте обновления данных о Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 191
  • 189. котировках, статусе выполнения финансовых транзакций, текущих позициях и рисках [8]. Рассмотрим несколько ключевых аспектов обеспечения качества трейдинговых систем:  Как и другие сложные многопоточные системы, трейдинговые платформы предрасположены к появлению в них трудновоспроизводимых сбоев [9], которые проявляются, исключительно когда система находится под нагрузкой. Часто речь идет о функциональных проблемах, не связанных с исчерпанием ресурсов системы, но вызванных ситуацией конфликтующих друг с другом по времени условий (race conditions) при обработке параллельных транзакций или проявлением статистически маловероятных внутренних нарушений целостности [10]. Нахождение таких проблем требует проведения верификации на границе между функциональным и нагрузочным тестированием [11];  Обеспечение полноты покрытия тестами функциональности трейдинговой системы требует большого количества сценариев в библиотеке автоматизированных тестов [12]. Количество нуждающихся в проверке комбинаций особенно велико для производных и составных финансовых инструментов [13]. Даже однократный прогон сценариев такой библиотеки тестов через систему приводит к продолжительному исполнению последовательности автоматических тестов. Многократный запуск позволяет выделить скрытые проблемы с внутренними состояниями системы;  Регулирующие органы, акционеры и участники торгов ожидают высокой устойчивости биржевых и брокерских систем к непредусмотренным внешним воздействиям [3]. В научной литературе детально проработаны методы тестирования устойчивости, основанные на прогоне большого количества случайно созданных данных через систему — фаззинге (fuzzing) [14]. Описанные выше свойства приводят к необходимости отправки большого количества созданных для тестирования сообщений в систему в течение продолжительного периода времени. Для обнаружения дефектов, связанных с обработкой потоков сообщений, необходима доскональная функциональная верификация выходящих сообщений и внутренних состояний системы. Применимые для этого методы известны под аббревиатурой HiVAT – большие объемы автоматизированного тестирования (High Volume Automated Testing) [15; 16; 17]. Эти методы направлены на выявление проблем, которые с большой долей вероятности могут остаться незамеченными при использовании других подходов, требующих ручного создания сценариев для автоматического тестирования и приводящих к статистически недостаточному количеству выходных данных. Опыт авторов показывает, что для высоконагруженных трейдинговых систем использование HiVAT-методов служит не столько возможным способом расширения покрытия тестированием, сколько обязательным методом их тестирования в условиях, приближенных к использованию в режиме промышленной эксплуатации. Продолжительное применение HiVAT-методов позволило выявить основные требования к инструментам тестирования. Эти требования перечисляются во второй части данной статьи. Третья часть посвящена сравнению инструментов тестирования с трейдинговыми системами, используемыми в промышленной 192 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 190. эксплуатации. В последней части приведены возможные расширения созданных средств и направления дальнейших исследований. 2 Требования к инструментам тестирования По влиянию на тестируемую систему инструменты тестирования можно разделить на два типа: пассивные и активные [18]. Пассивное тестирование — это процесс обнаружения неисправностей в тестируемой системе путем исследования ее поведения без оказания воздействий на нормальный процесс работы. Активные инструменты непосредственно воздействуют на трейдинговую систему и используются для обмена сообщениями, анализа полученных от системы откликов, нагрузочного тестирования. 2.1 Пассивные инструменты тестирования Пассивные инструменты тестирования используются для автоматизированного сбора логов, структурирования данных, мониторинга и анализа поведения системы, сертификации пользователей. Инструменты тестирования позволяют оперативно исследовать большой объем данных, реагировать на отклонения в поведении системы от установленных требований, локализировать неполадки. Инструмент тестирования позволяет эффективно решать эти задачи, если выполнены следующие требования:  обеспечена полнота сбора данных обо всех событиях в системе;  минимизировано влияние на систему;  обеспечено оповещение в реальном режиме времени о нестандартных ситуациях;  реализованы гибко настраиваемые критерии распознавания образов;  обеспечено хранение и предоставление доступа к историческим данным;  предоставлена возможность отслеживать последовательность событий и внутренние состояния системы на определенный момент времени. Нахождение первопричины сбоя, произошедшего при использовании HiVATметодов, зачастую является более сложным процессом по сравнению с обычными методиками ручного и автоматизированного тестирования. Эта сложность обусловлена, в основном, двумя факторами: автоматическим созданием сценариев тестирования и большим объемом разнородных данных, пропущенных через систему. Тестировщику необходимы удобные инструменты, информирующие его о возникновении проблем и позволяющие детально исследовать состояние системы до и после возникновения сбоев. Недетерминированный характер входного потока сообщений, являющийся отличительной чертой использования HiVAT-методов, подразумевает необходимость в гибкости сценариев распознавания проблем и предоставление тестировщику возможностей по их настройке. Невозможно обеспечить полноту сбора информации без присутствия эффекта измерения для высоконагруженной системы. Задача инструмента тестирования Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 193
  • 191. состоит в том, чтобы минимизировать влияние самого инструмента на функциональность и производительность тестируемой системы. Инструмент дожен предоставлять доступ к детальным и аггрегированным данным, полученным в результате выполнения текущей и предыдущих итераций тестирования. Диаграмма на рис. 1 показывает компоненты необходимые для реализации перечисленных требований к пассивным инструментам тестирования. Рис. 1. Высокоуровневая схема основных компонентов инструмента для пассивного тестирования трейдинговых систем 2.2 Активные инструменты тестирования Инструмент для активного тестирования должен обладать универсальностью, то есть способностью подключаться к различным тестируемым окружениям, используя разнообразные протоколы. Применение фаззинга для распределенных трейдинговых систем накладывает ограничения на создаваемые сообщения [25] с целью обеспечить их прохождение к ядру и другим внутренним компонентам без блокирования их на внешних шлюзах протокольных подключений или на начальных ступенях защиты модулей контроля рисков. Автоматический характер создания сценариев тестирования и их значительный объем требует сохранения информации об отправленных сообщениях и внутренних состояниях инструмента тестирования, его настройках. При использовании сложных техник необходима также сверка данных между инструментом и тестируемой системой. Использование HiVAT-методов для высоконагруженных трейдинговых систем требует создания масштабной инфраструктуры для тестирования. 194 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 192. Эффективность использования такой инфраструктуры может быть обеспечена только в случае одновременной доступности ее для выполнения различных задач тестирования. Инструменты для тестирования должны позволять выполнять вручную и ставить в расписание прогонов наборы автоматизированных сценариев даже в случаях, когда параллельно многократно выполняются сценарии библиотеки регрессионного тестирования или тесты, основанные на техниках случайной генерации тестов. Для создания полноценных функциональных тестов инструмент должен предоставить удобные программируемые возможности для управления процессом генерации автоматизированных сценариев тестирования. Диаграмма на рис. 2 показывает компоненты, необходимые для реализации перечисленных требований к активным инструментам тестирования. Рис. 2. Высокоуровневая схема основных компонентов инструмента для активного тестирования трейдинговых систем 2.3 Общие требования к инструментам для тестирования трейдинговых систем Следующие характеристики являются обязательными как для пассивных, так и для активных инструментов при использовании HiVAT-методов:  масштабируемость и высокая пропускная способность;  устойчивость;  адаптивность; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 195
  • 193.  удобность и интерактивность. Эти обязательные характеристики совпадают с предъявляемыми к промышленным трейдинговым системам. требованиями, 3 Использование инструментов тестирования промышленной эксплуатации трейдинговых систем в В этой части статьи мы сопоставим требования, предъявляемые к инструментам для тестирования трейдинговых систем с использованием методов HiVAT, с требованиями к трейдинговым системам и системам мониторинга, используемым в промышленной эксплуатации. Таблица 1. Требования к системам мониторинга и контроля финансовых рисков Требование Полнота сбора данных обо всех событиях в системе Минимизация влияния на трейдинговую систему Оповещение в реальном режиме времени о нестандартных ситуациях Использование в промышленной эксплуатации Основная задача системы мониторинга и контроля финансовых рынков — поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций [19]. Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы. Сбор большого объема информации невозможен без масштабируемой мониторинговой инфраструктуры. Наблюдение за рынком исключительно важный процесс, являющийся обязательным в абсолютном большинстве финансовых юрисдикций. Тем не менее, для обеспечения минимальных времен отклика на приходящие в реальном режиме времени сообщения операторы трейдинговых систем стараются избегать негативного влияния эффекта измерения на основную функциональность трейдинговой платформы. Операторы системы должны быть немедленно уведомлены при возникновении технических проблем или подозрительных транзакций. Такие уведомления называются оповещениями системы мониторинга (surveillance alerts). Эффективно работающая система оповещения — ключевой компонент системы мониторинга и контроля рисков. Гибко настраиваемые Очень часто недобросовестные участники рынка пытаются критерии распознавания скрыть злоупотребления и манипуляции рынком под видом образов легитимных финансовых транзакций. Системам мониторинга и контроля рынков приходится делать 196 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 194. аналитические заключения на основе нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов [20]. Хранение и предоставление доступа к историческим данным По запросам аудита или регулирующих органов операторы трейдинговых систем обязаны предоставлять исторические данные и результаты их обработки Возможность отследить последовательность событий и внутренние состояния системы на определенный момент времени Формальные критерии сами по себе не являются достаточным доказательством наличия манипуляции. Операторы системы нуждаются в возможности восстанавливать последовательность событий относящихся к конкретным эпизодам, вызвавшим оповещение о проблеме. Данная функция называется проигрыванием книги заявок (order book replay). Удобная реализация позволяет операторам исследовать большее количество событий и делать выводы о правильности работы механизмов распознания образов. Рис. 3. Высокоуровневая схема основных компонентов системы мониторига и контроля финансовых рисков создаваемой в компании «Exactpro Systems», LLC. Из схемы на рис. 3 видна концептуальная близость системы к инструментам для пассивного тестирования трейдинговых платформ. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 197
  • 195. Таблица 2. Требования к системам выполнения биржевых и алгоритмических заявок Требование Универсальность. Подключение ко множеству других систем и поддержка используемых ими протоколов Использование в промышленной эксплуатации В условиях фрагментации финансовых рынков брокерские системы должны обеспечивать возможность подключения к разным биржевым системам и сторонним брокерам [21]. Высоконагруженная трейдинговая система должна Предоставление одновременного доступа обеспечить одновременный доступ большому количеству участников торгов Возможность выполнения сложных сценариев Хранение информации обо всех отправленных сообщениях и внутренних состояниях. Возможность сверки этих данных с данными, поступающими из внешних систем, включая клиринг и депозитарии 198 Основная функция систем алгоритмической торговли — предоставление пользователям возможности задавать стратегию посылки заявок на выполнение финансовых транзакций в зависимости от состояния рынка, портфеля, параметров риска, информационных сообщений и т.д. Оператор трейдинговой системы, предоставляющий доступ своим клиентам на финансовые рынки, обязан хранить информацию обо всех совершенных финансовых транзакциях [22] и производить сверку этих данных с данными клиентов и контрагентов, а также с информацией из пост-торговых систем. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 196. Рис. 4. Высокоуровневая схема основных компонентов системы выполнения биржевых и алгоритмических заявок, создаваемой в компании «Exactpro Systems», LLC. Из схемы на рис. 4 видна концептуальная близость системы к инструментам для активного тестирования трейдинговых платформ. 4 Направление дальнейших исследований Сравнение требований и концептуальных схем инструментов для тестирования с соответствующими промышленными системами позволяет утверждать, что, начиная с определенного уровня зрелости инструменты для тестирования могут использоваться как подсистема трейдинговой платформы. Но основной задачей тестирования является не нахождение правильно работающих подсистем, а выявление проблем и недостатков в исследуемом приложении. Превращение инструментов для тестирования в промышленные трейдинговые системы может потенциально привести к концентрации взаимодействия на корректно работающих участках, снижению покрытия тестами и избыточному фокусу на позитивных сценариях. Основное направление дальнейшей работы — это нахождение методов преодоления этой тенденции. Если инструменты для тестирования становятся частью промышленной инфраструктуры, то внесение небольших изменений в их код и настройки, является по сути изменением содержащей их трейдинговой платформы. Таким образом, предложенный подход открывает новые возможности по применению методов мутационного тестирования на системном уровне к исследованию Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 199
  • 197. сложных интегрированных трейдинговых систем [23]. Внесенные изменения называются мутациями и основываются на мутационных операторах [24], которые имитируют типичные ошибки или нежелательные воздействия. Мутации также позволяют оценить эффективность существующего набора тестов и качество инструментов для тестирования. Операторами мутации трейдинговой системы для проверки нефункциональных свойств могут стать следующие изменения:  введение случайных задержек во внутренние компоненты, логические алгоритмы и в функционирование внешних подключений;  замена оптимизированных TCP/IP потоков данных на множество параметризованных библиотек на различных языках;  заполнение памяти или дискового пространства на компьютере с исследуемой системой большим количеством логов;  загрузка сети паразитными сообщениями или внедрение ошибок в структуры данных. Второе направление дальнейших исследований - это изучение методов фаззинга, совместимых со структурой и консистентностью промышленных систем [25]. 5 Заключение На основе обобщения опыта по верификации корректной работы высоконагруженных электронных трейдинговых систем с функциональной и нефункциональной точек зрения в статье проанализированы методы обеспечения их качества, основанные на большом объеме автоматизированного тестирования (НiVAT). Практическое использование этих методов авторами позволило определить набор основных требований к инструментам пассивного и активного тестирования, применяемым для верификации подобного рода систем. В статье сделан вывод, что инструмент для тестирования, соответствующий определенному набору требований, является по своей сути системой, применимой при промышленной эксплуатации трейдинговых систем. Полученные авторами результаты обосновали оправданность финансирования создания инструментов для тестирования, основанных на описанных выше методах и принципах. В рамках проектов компании «Exactpro Systems», LLC разрабатываются: система мониторинга и контроля финансовых рынков и система поддержки алгоритмической торговли. Обе системы имеют двойное назначение и могут использоваться и как инструмент для тестирования, и как самостоятельный элемент промышленной трейдинговой инфраструктуры [26]. Выше были рассмотрены также дополнительные возможности по использованию методов мутационного тестирования на системном уровне для анализа и расширения полноты покрытия функциональными и нефункциональными тестами. Указанные возможности открываются при включении инструментов тестирования в состав трейдинговой платформы. 200 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 198. Литература 1. The Future of Computer Trading in Financial Markets. Final Project Report. / Foresight. The Government Office for Science, London. // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computertrading-in-financial-markets-report.pdf 2. Bloomfield,R., Wetherilt,A.: Computer trading and systemic risk: a nuclear perspective. / Foresight. The Government Office for Science, London // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1059dr26-computer-trading-and-systemic-risk-nuclear-perspective.pdf 3. Commission Roundtable on Technology and Trading: Promoting Stability in Today's Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. – Режим доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf 4. Иткин И.Л.: Высоконагруженные трейдинговые системы и их тестирование. / Конференция разработчиков высоконагруженных систем HighLoad++ // [Электронный ресурс]. – Режим доступа http://www.highload.ru/2012/abstracts/388.html 5. Penhaligan,P.: Equity Trading: Performance, Latency Throughput. / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3turquoise-equitytrading2012 6. Avellaneda,M.: Algorithmic and High-frequency trading: an overview / New York University Finance Concepts LLC Quant Congress USA 2011. // [Электронный ресурс]. – Режим доступа http://www.math.nyu.edu/faculty/avellane/QuantCongressUSA2011AlgoTradingLAST.pdf 7. Millennium Exchange Technical Specifications / Официальный сайт London Stock Exhcange // [Электронный ресурс]. – Режим доступа http://www.londonstockexchange.com/products-and-services/technical-library/millenniumexchange-technical-specifications/millennium-exchange-technical-specifications.htm 8. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3exactpro-testingofhftgui-12944204 9. Yu,T.: An observable and controllable testing framework for modern systems. // ICSE '13: Proceedings of the 2013 International Conference on Software Engineering Publisher: IEEE Press, May 2013 10. Netzer,R.H.B, Miller,B.P.: What are race conditions?: Some issues and formalizations // Letters on Programming Languages and Systems (LOPLAS) , Volume 1 Issue 1, March 1992 11. Zverev,A., Bulda,A., Bobrov,I.: Trading Systems: Testing at the Confluence of FTNFT. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent-2013-obninsk-trading-systems-testing-at-theconfluence-of-ft-nft-17082512 12. Heider,W., Rabiser,R., Grünbacher,P., Lettner,D.: Using regression testing to analyze the impact of changes to variability models on products. // SPLC '12: Proceedings of the 16th International Software Product Line Conference - Volume 1, September 2012 13. Eurodollars on CME Globex: Implied Price Functionality // [Электронный ресурс]. – Режим доступа http://www.cmegroup.com/trading/interest-rates/files/Butterflies.pdf 14. Sutton,M., Greene,A., Amini,P.: Fuzzing: Brute Force Vulnerability Discovery. // AddisonWesley Professional, 2007 15. McGee,P., Kaner,C.: Experiments with high volume test automation. // SIGSOFT Software Engineering Notes, September 2004 16. Kaner,C: An Overview of High Volume Automated Testing. // [Электронный ресурс]. – Режим доступа http://kaner.com/?p=278 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 201
  • 199. 17. Teaching High Volume Automated Testing (HiVAT). //12th Workshop on Teaching Software Testing (WTST 2013), January 25-27, 2013, Melbourne, Florida, at the Harris Institute for Assured Information. // [Электронный ресурс]. – Режим доступа http://wtst.org/ 18. Cavalli,R., Montes de Oca,E., Mallouli,W., Lallali,M.: Two Complementary Tools for the Formal Testing of Distributed Systems with Time Constraints. //12th 2008 IEEE/ACM International Symposium on Distributed Simulation and Real-Time Applications. 19. Diaz,D., Zaki,M., Theodoulidis,B., Sampaio,P.: A Systematic Framework for the Analysis and Development of Financial Market Monitoring Systems. // 2011 Annual SRII Global Conference 20. Иткин И., Прядкина Н., Крюков А.: Анализ данных в высоконагруженных трейдинговых системах. / Конференция АИСТ-2013. // [Электронный ресурс]. – Режим доступа http://clubqa.ru/blogs/?p=436 21. Официальный сайт Fidessa Fragmentation Index // [Электронный ресурс]. – Режим доступа http://fragmentation.fidessa.com/ 22. OATS Reporting Technical Specifications. // [Электронный ресурс]. – Режим доступа http://www.finra.org/web/groups/industry/@ip/@comp/@regis/documents/appsupportdocs/ p197473.pdf 23. Mateo,P.R., Usaola,M.P., Alema´n,J.L.F.:Validating Second-Order Mutation at System Level. // IEEE Transactions on softvare engineering, vol. 39, No. 4, April 2013 24. Mateo,P.R., Usaola,M.P., Offutt,J.: Mutation at System and Functional Levels. // Third International Conference on Software Testing, Verification, and Validation Workshops 25. Wang,T., Wei,T., Gu,G., Zou,W.: Checksum-Aware Fuzzing Combined with Dynamic Taint Analysis and Symbolic Execution. // ACM Transactions on Information and System Security, Vol. 14, No. 2, Article 15, Publication date: September 2011 26. Itkin,I., Matveeva,A., Barch,A.: Test Tools evolution. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent2013-obninsk-test-tools-for-trading-systems-evolution-theory-17007184 202 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 200. Тестирование совместимости протокольных подключений клиентов биржевых и брокерских систем Андрей Алексеенко1, Анастасия Матвеева1, Даниил Шаров1, Павел 2 Проценко , Иосиф Иткин3 1 ООО «Инновационные Трейдинговые Системы», Россия, 1156088, г. Москва, 2-й Южнопортовый проезд, 20А/4 Andrey.Alexeenko@exactpro.com, Anastasia.Matveeva@exactpro.com, Daniel.Sharov@exactpro.com 2 Exactpro Systems UK, 10 Paternoster Square, London, EC4M 7LSl, UK Pavel.Protsenko@exactpro.com 3 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Iosif.Itkin@exactpro.com Aннотация. Жизненный цикл разработки биржевого и брокерского программного обеспечения, помимо проверки функциональных и технических характеристик системы, включает в себя обязательный этап интеграционного тестирования, называемый сертификацией клиентов. Этот этап призван обеспечить совместимость систем автоматизированной торговли, подключаемых к бирже или брокеру посредством финансовых протоколов (таких как FIX/FAST, ITCH или специализированные бинарные интерфейсы доступа). В статье представлен оригинальный инструмент, разработанный для проверки совместимости торговых систем. Отличительная особенность разработанного инструмента унифицированный способ поддержки множества протоколов. Приведены примеры его использования при самостоятельной сертификации участников торгов, а также при масштабных миграциях трейдинговых платформ. Ключевые слова: финансовые протоколы, FIX-протокол, тестирование совместимости, самостоятельная сертификация, торговый брокер, биржа. 1 Введение Адаптация новых клиентов к трейдинговой платформе и их поддержка при обновлениях программного обеспечения - это один из ключевых бизнеспроцессов биржевых и брокерских организаций [1; 2; 3]. Существенной составляющей этого процесса служит тестирование, проводимое для выявления проблем с совместимостью трейдинговой платформы с системами, принадлежащими подключаемым к бирже или брокеру участникам торгов, называемое сертификацией клиентов [4]. Сертификация клиентов обязательна для любого оператора биржевой или брокерской платформы, предоставляющей возможность осуществлять финансовые транзакции, и в настоящее время широко используется в Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 203
  • 201. финансовой индустрии [5]. Ссылки на правила сертификации клиентов и соответствующую документацию можно найти на официальных сайтах соответствующих организаций [6; 7; 8; 9]. Программное обеспечение, ранее успешно прошедшее внутреннее интеграционное тестирование, проходит после этого через завершающий тест интеграцию с клиентами (обычно юридическими лицами). Общепринятой практикой является ситуация, когда клиенты и оператор трейдинговой платформы задают временной интервал для выполнения активного тестирования и оценивают его результаты с обеих сторон. В связи с тем, что в процесс сертификационного тестирования вовлечены люди, представляющие разные компании, данный процесс требует значительной степени координации и слаженности работы. Это чрезвычайно важно как с финансовой, так и с репутационной точек зрения. Любой дефект программного обеспечения, обнаруженный на этапе сертификационного тестирования, является достаточно дорогостоящим с точки зрения его устранения, поскольку все стадии жизненного цикла программного обеспечения уже пройдены [10], а любая задержка с обнаружением проблем совместимости вносит существенные дополнительные затраты. К характерным проблемам, с которыми приходится сталкиваться при проведении сертификации клиентов, относятся:  наличие часовых поясов и возникающие в связи с этим сложности в планировании и координации проведения тестирования командами профессионалов, находящимися физически в разных частях земного шара;  производительность: сертификация может требоваться несколькими клиентами одновременно из-за бизнес- или технических событий, таких как выход новых версий программного обеспечения, изменений нормативных или технических требований;  компетентность: специалист по обеспечению качества программного обеспечения, проводящий сертификацию, обязан обладать должным уровнем технических и бизнес-знаний;  покрытие: сертификационные тесты должны быть основаны на типичных сценариях и обеспечивать значимые результаты. В трейдинговой индустрии начинает формироваться понимание того, что одним из способов преодоления этих проблем может стать создание более совершенных решений по автоматизации сертификационного тестирования и анализу его результатов [11]. Несмотря на актуальность автоматизации процесса сертификации биржевых/брокерских клиентов, данная проблематика пока практически не освещена в отечественной и зарубежной научной литературе. На рынке присутствует несколько коммерческих инструментов тестирования, созданных для ускорения процесса сертификации клиентов:  FIX Conductor от компании Lasalletech [12];  FACTS от B2BITS, EPAM Systems [13];  CertiFIX от Greenline [14];  Catalys Studio от Cameron [15]; 204 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 202.  Ignition от FIXFlyer [16];  VegaFABS от Pravega Financial Technologies [17];  Certpoint от Tradepoint Systems [18];  Certification Platform от FixSpec.com [19]. Биржевые платформы используют два основных подхода к сертификации:  Предоставление клиентам специализированного симулятора для проведения сертификации [20; 21; 22]. Клиенты проводят тестирование, используя предоставленный инструмент, и предоставляют логи сертификации;  Предоставление доступа к специализированному тестовому окружению, которое является уменьшенной копией промышленной системы; документирование процедуры; совместное проведение сертификации с клиентом либо использование самостоятельной сертификации [23]; использование пассивных методов, таких как перехват трафика сетевых подключений или данные из лог-файлов, для анализа успешности и полноты проведенной процедуры сертификации. Оба подхода в той или иной степени реализованы в существующих коммерческих решениях. Основное достоинство метода, основанного на использовании симуляторов, это снижение нагрузки на сертифицирующую организацию и клиентов, обеспечиваемое возможностью проводить сертификацию в любое время суток, а не только в период открытого торгового дня. Проблема, специфичная для всех симуляторов, - отсутствие гарантии, что фактическое сообщение, отправленное с его помощью, идентично сообщениям, отправляемым реальным программным обеспечением [24]. Пассивное тестирование является, на наш взгляд, наиболее корректным методом проведения сертификации клиентов. Общая концепция пассивного тестирования и её преимущества описаны в [25], различные алгоритмы пассивного тестирования предложены в [26; 27]. Основным преимуществом пассивного тестирования является то, что инструмент для тестирования не оказывает влияния на тестируемую систему и не приводит к созданию потоков дополнительных сообщений. Данное преимущество, однако, одновременно является и недостатком: для успешного проведения пассивного тестирования необходимые сообщения должны быть кем-то созданы. В случае сертификации клиентов требуется привлекать представителей другой компании для создания входящего потока сообщений. Данная практика неизбежна при первичной сертификации. Однако с целью снижения временных затрат сторонних организаций требуется использовать более эффективные методы: например, предложенный в [28] подход. Используя данные первичной сертификации для автоматизированного создания новых сценариев тестирования, при сохранении неизменной спецификации протокола доступа, оператор трейдинговой платформы получает возможность провести повторную сертификацию клиента самостоятельно. Присутствующие на рынке инструменты для сертификации клиентов обладают следующими ограничениями:  специализация на одном фиксированном протоколе, например FIX [29]; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 205
  • 203. интерактивные инструменты анализа данных и создания новых сценариев малопригодны для обработки действительно больших объемов данных о гетерогенных клиентских подключениях. Авторы принимают участие в разработке и использовании программного решения компании Exactpro Systems LLC, направленного на преодоление указанных ограничений [30; 31]. Созданный инструмент описывается во второй части данной статьи. Третья часть содержит описание практического использования созданного инструмента для самостоятельной сертификации участников биржевых торгов. Четвертая часть описывает использование разработанного инструмента при масштабных миграциях брокерских систем.  2 Многопротокольное решение тестировання трейдинговых систем для пассивного Инструмент для пассивного тестирования сетевых подключений к трейдинговым системам разработан с использованием языка Java и системы управления базами данных MySQL. В основе подхода - унифицированное описание структуры протокольных сообщений - система словарей. Для каждого протокола создается словарь. Для групп протоколов может потребоваться написание специальных модулей, приводящих сетевые потоки данных к унифицированному внутреннему формату на основе словарей. Концепция близка к логике Complex Events Processing [32]. Для создания шаблона словаря был взят и доработан для большей общности шаблон словарей, используемый в системе QuickFIX/J [33]. Разработанный инструмент может получать на входящие данные о перехваченных сетевых сообщениях, полученных с использованием tcpdump [34] или различных прокси-серверов [35]. Пользователю также предоставлена возможность загружать лог-файлы, содержащие массив сообщений, в настраиваемом формате. Основная таблица в базе данных содержит информацию о каждом перехваченном пакете, включая повторную пересылку TCP-данных. Если трейдинговая система находится под нагрузкой, сетевой пакет может содержать несколько сообщений или же сообщение может быть разбито между несколькими TCP-пакетами. Выделив сообщения из сетевых пакетов, инструмент делает попытку конвертации в унифицированный формат на основе словарей. Информация о сетевых пакетах и сообщениях, не прошедших проверку посредством словарей, заносится в отдельную таблицу, по сути содержащую список проблем сертификации первого уровня. Детали перехваченных и успешно обработанных сообщений могут быть сохранены в реляционную базу данных посредством двух основных методов:  использования общей таблицы, содержащей идентификаторы сообщения, имя параметра и его значение;  использования индивидуальной таблицы для каждого типа сообщения, размещая параметры сообщения в соответствующих колонках, с именами, произведенными от имени параметров. 206 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 204. Преимущество первого подхода – это большая общность. Преимущество второго подхода – удобство работы с SQL-запросами к базе данных. В разработанном инструменте используется комбинация обоих подходов: для каждого типа сообщений создана индивидуальная таблица, а данные из повторяющихся групп хранятся в общей таблице. Рисунок 1 содержит схему использования разработанного инструмента для перехвата и хранения сетевых сообщений. Рис.1. Процесс обработки сообщений в инструменте тестирования и сертификации. Перехваченные сообщения декодируются и складываются в базу данных инструмента. Все отчеты по сертификации хранятся в виде SQL запросов. При добавлении нового вида отчетов или иного требования, нет необходимости менять код самого инструмента. С помощью SQL запроса есть возможность найти сообщения по списку и их статус, и выделить их цветом с помощью пользовательского интерфейса для лучшего зрительного восприятия. SQL запросы так же могут быть использованы для нахождения необходимой статистики по сообщениям, количества заходов в приложения, синтаксически непроанализированные сообщения и т.д. Графический интерфейс пользователя разработанного инструмента позволяет аналитику, отвечающему за сертификацию или обеспечение качества трейдинговой платформы, просматривать сообщения и события в реальном режиме времени, включая детали сетевых пакетов, результаты верификации посредством системы словарей, значения индивидуальных полей и исходные бинарные данные. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 207
  • 205. Сертификационные тесты и сверки данных могут быть реализованы посредством обычных SQL-запросов. Инструмент предоставляет возможность подсветки и анализа сообщений, полученных в результате выполнения того или иного запроса. На рисунке 2 представлен пример окна графического интерфейса разработанного инструмента. Рис.2. Графический пользовательский интерфейс инструмента тестирования и сертификации. 3 Самостоятельная сертификация участников биржевых торгов Регулирующие органы требуют от операторов биржевой системы предоставления эквивалентного доступа всем участникам торгов [36]. При внесении изменений в технологическую платформу биржи ее оператор обязан провести сертификацию всех подключенных торговых систем в короткий промежуток времени. Данная особенность процесса создает существенную нагрузку на отделы организации-оператора биржевой площадки, отвечающие за поддержку клиентов. Для снижения этой нагрузки биржевые площадки используют метод самостоятельной сертификации. Клиентам предоставляется доступ к тестовому окружению и сценарий выполнения сертификационных тестов. После выполнения шагов предоставленного сценария клиент высылает логи процесса в сертифицирующую организацию, где они проходят дополнительную проверку. Пассивное тестирование значительно упрощает процесс сертификации для участников торгов. При данном подходе от них требуется только подключиться 208 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 206. к тестовому окружению и отправить заявки, обозначенные в тестовом сценарии. Таким образом, участники торгов избавлены от выполнения любых шагов (таких как установка дополнительного программного обеспечения, сбор логов и т.д.), кроме тех, которые непосредственно необходимы для подключения к технологической платформе биржи. Разработанный инструмент перехватывает все сообщения, переданные от клиента к бирже или в обратную сторону, разбирает структуру и содержимое каждого сообщения и сохраняет всё в реляционную базу данных. Используя SQL-запросы, аналитик сертифицирующей организации может получить статистику по попыткам выполнения шагов тестового сценария и их успешности для каждого из участников торгов. Данные о сетевых пакетах позволяют также обнаружить дополнительные проблемы, такие как разрывы соединений или проблемы с буферизацией сообщений. Приведем пример сертификационного SQL-сценария, проверяющего успешность размещения клиентом агрессивной рыночной заявки, в результате появления которой по исполнении её против заявок, размещенных на противоположной стороне стакана заявок, образовались две и более сделки: insert into t_native_testcases (user,sourceip,sourceport,testcase,timestamp,clordid,orderid, otherid) select distinct n.user, n.sourceip, n.sourceport, 'MEx-012.2 Agg. MO' as testcase, n.timestamp, n.clordid, e.orderid, '' from t_lsenative_neworder n , t_lsenative_executionreport e , t_lsenative_executionreport e2 where n.user=e.user and n.sourceip=e.destinationip and n.sourceport=e.destinationport and n.clordid=e.clordid and n.user=e2.user and n.sourceip=e2.destinationip and n.sourceport=e2.destinationport and n.clordid=e2.clordid and n.ordertype=1 and e.ordstatus=1 and e.tradeliquidityindicator='R' and e2.typeoftrade='2' and e2.ordstatus in (1,2) and e2.tradeliquidityindicator='R' and e2.typeoftrade='2' and e.execid e2.execid order by user, clordid, orderid; Для нескольких биржевых платформ были разработаны совокупности SQLсценариев, покрывающие все требования по сертификации клиентских соединений, опубликованные организатором торгов [9]. 4 Миграция брокерской платформы с большим количеством гетерогенных клиентских подключений В сравнении с биржевыми платформами брокерские системы обычно предоставляют существенно более широкие возможности по настройке Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 209
  • 207. протокола взаимодействия с системами клиентов: например, используя возможности таких систем, как UL Bridge [37]. Один и тот же клиент может использовать одновременно несколько брокеров для получения доступа на биржу. Часто брокеры стараются снизить количество изменений в протоколах коммуникации, которые конкретный клиент вынужден имплементировать со своей стороны. Облегчая взаимодействие с клиентом, этот подход одновременно приводит к появлению большого количесва гетерогенных конфигураций со стороны брокерской трейдинговой платформы. При внутренних изменениях брокерской платформы возникает необходимость в регрессионном тесте на совместимость с клиентскими системами. Разработанный инструмент позволяет обработать имеющиеся данные из тестовых и промышленных окружений и создать необходимый набор активных тестовых сценариев. Выполнив эти сценарии против тестового окружения без привлечения конечных клиентов тестовый инструмент запускает SQL-сценарии, выполняющие сверку ответов брокерской платформы до и после изменений. Особенность созданного авторами инструмента состоит в том, что он позволяет проводить этот процесс одновременно для большого количества клиентов, подключений, рынков и типов сообщений. Гибкость при создании сверяющих SQL-запросов позволяет не только исключить из сравнения поля, про которые заранее известно, что их значения должны различаться (например, sequence numbers, timestamps и другие), но и задать требования по обработке более сложных расхождений. Подход доказал свою жизнеспособность и эффективность при миграции трейдинговой платформы одного из крупнейших международных брокеров, предоставляющего доступ к торговле производными финансовыми инструментами. Последовательность шагов отображена на схеме на рисунке 3. 210 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 208. Рис.3. Схематичный пример реализации предлагаемого решения. Логи из промышленной системы загружаются в базу данных инструмента для тестирования и сертификации. Генератор скриптов использует данную базу для создания совокупности тестовых сценариев, исполняемых активным инструментом для функционального тестирования. Логи выполнения тестовых сценариев загружаются в базу данных для сравнения с данными полученными из промышленной системы. 4 Заключение С ростом объёмов автоматизированной электронной торговли стабильность и устойчивость финансовых рынков будут во все большей степени зависеть от корректной совместной работы платформ, обеспечивающих инфраструктуру рынков, и подключенных к ним автоматизированных трейдинговых систем. Стоимость процессов подключения новых клиентов, их сертификации и сохранения совместимости при регулярно вносимых изменениях существенно влияет на общую стоимость функционирования биржевых и брокерских систем. Представленный в статье инструмент используется с целью повышения эффективности и экономичности указанных процессов. Имеется позитивный опыт его применения в рамках проектов компании Exactpro Systems LLC на заключительных этапах выпуска в промышленную эксплуатацию Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 211
  • 209. крупномасштабных трейдинговых систем для торговли финансовыми инструментами разных классов. В статье описаны используемые в индустрии методы сертификации клиентских подключений и сделаны выводы о преимуществах подхода, основанного на использовании многопротокольного пассивного инструмента, сохраняющего данные в реляционную СУБД. Рассмотрен также вариант использования данного инструмента с целью создания активных тестов и сокращения затрат при масштабных миграциях систем с множеством гетерогенных клиентских подключений. Дальнейшие исследования будут направлены на оптимизацию структуры базы данных: в частности, в вопросе распространения разработанных методов на трейдинговые протоколы, основанные не на сетевых взаимодействиях, а на программных интерфейсах доступа (API). Источники 1. Markit Magazine Issue 10 - Focus: Client Onboarding – Markit.com // [Электронный ресурс]. – Режим доступа http://www.markit.com/assets/en/docs/markit-magazine/issue10/mm10_focus5-onboardingroundtable.pdf 2. Fenergo 2013, Client Onboarding: Solving the Challenges, Maximizing the Opportunities. // [Электронный ресурс]. – Режим доступа http://www.fenergo.com/industryknowledge/whitepapers/client-onboarding-solving-challenges-maximizingopportunities.html 3. Axel Pierron, Anshuman Jaswal: Institutional Client On-Boarding in the Financial Industry Time to Move to the Industrialization Phase. // Celent Report, October 2012 // [Электронный ресурс]. – Режим доступа http://www.celent.com/reports/institutionalclient-boarding-financial-industry 4. Challenges and Solutions to Onboarding Trading Clients. // [Электронный ресурс]. – Режим доступа http://www.trdpnt.com/blog/bid/294222/Challenges-and-Solutions-toOnboarding-Trading-Clients 5. FIA Market Access Risk Management Recommendations April 2010. // [Электронный ресурс]. – Режим доступа http://www.futuresindustry.org/downloads/Market_Access6.pdf 6. Moscow Exchange. // [Электронный ресурс]. – Режим доступа http://fs.moex.com/files/4531 7. BOX Options Exchange. // [Электронный ресурс]. – Режим доступа http://boxexchange.com/what-you-need-to-know/software-certification/ 8. Eris Exchange. // [Электронный ресурс]. – Режим доступа http://www.erisfutures.com/sites/default/files/Electronic_Trading_Certification_Process.pd f 9. TQ 601 - Technical Specification Turquoise Equities Guide to Certification. // [Электронный ресурс]. – Режим доступа http://www.lseg.com/sites/default/files/content/documents/TQ601%20%20Guide%20To%20Application%20Certifcation.pdf 10. Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael Lindvall,Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz: What We Have Learned About Fighting Defects // METRICS '02 Proceedings of the 8th International Symposium on Software Metrics, IEEE Computer Society Washington, DC, USA 2002 212 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 210. 11. Candyce Edelen: Making the Case for Automated FIX Certification. // [Электронный ресурс]. – Режим доступа http://www.advancedtrading.com/high-frequency/making-thecase-for-automated-fix-certif/240155554 12. FIX Conductor™ от компании Lasalletech. // [Электронный ресурс]. – Режим доступа http://www.lasalletech.com/products/fix-automated-onboarding 13. FACTS от B2BITS, EPAM Systems. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/fix_testing_facts.html 14. CertiFIX® от Greenline. // [Электронный ресурс]. – Режим доступа http://www.greenlinetech.com/products/certifix.php 15. Catalys Studio от Cameron. // [Электронный ресурс]. – Режим доступа http://www.camerontec.com/products/catalys/catalys-studio/ 16. Ignition от FIXFlyer. // [Электронный ресурс]. – Режим доступа http://fixflyer.com/materials/software/Ki/FlyerIgnition.pdf 17. VegaFABS от Pravega® Financial Technologies. // [Электронный ресурс]. – Режим доступа http://www.pravegatech.com/index.php?option=com_contentview=articleid=64Itemi d=65 18. Certpoint от Tradepoint Systems. // [Электронный ресурс]. – Режим доступа http://www.trdpnt.com/certpoint/ 19. Certification Platform от FixSpec.com // [Электронный ресурс]. – Режим доступа http://forexmagnates.com/fixspec-launches-innovative-multi-venue-certification-utility-tostreamline-connectivity/ 20. The Stock Exchange of Hong Kong Limited. // [Электронный ресурс]. – Режим доступаhttp://www.hkex.com.hk/eng/market/partcir/sehk/2012/Documents/CTMO06612E. pdf 21. MyCTC (Certification and Testing Center) от BMFBOVESPA. // [Электронный ресурс]. – Режим доступа http://www.bmfbovespa.com.br/enus/services/download/MyCTC-User-Guide.pdf 22. CME Group. // [Электронный ресурс]. – Режим доступа http://www.cmegroup.com/confluence/display/EPICSANDBOX/Client+System+Certificati on 23. The London Stock Exchange. // [Электронный ресурс]. – Режим доступа http://www.lseg.com/areas-expertise/technology/market-connectivity/customercertification-and-testing-services 24. Zverev A., Bulda A.: Exchange Simulators for SOR/Algo Testing: Advantages vs. Shortcomings. / ExTENT conference. // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/IosifItkin/exchange-simulators-for-sor-algo-testing-advantages-vsshortcomings 25. K. M. Brzezinski: Towards the Methodological Harmonisation of Passive Testing Across ICT Communities // Engineering the Computer Science and IT, October 2009 26. David Lee, Dongluo Chen, Ruibing Hao, Raymond E. Miller, Jianping Wu and Xia Yin: Network Protocol System Monitoring – A Formal Approach With Passive Testing // IEEE/ACM Transactions on Networking, Vol. 14, No. 2, April 2006 27. Ana Cavalli, Stephane Maag, Edgardo Montes de Oca: A passive conformance testing approach for a MANET routing protocol // Proceedings of the 2009 ACM symposium on Applied Computing March 2009, SAC '09 28. James Newsome, David Brumley, Jason Franklin, Dawn Song: Replayer: Automatic Protocol Replay by Binary Analysis // CCS '06: Proceedings of the 13th ACM conference on Computer and communications security, October 2006 29. FIX Protocol. // [Электронный ресурс]. – Режим доступа http://fixprotocol.org Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 213
  • 211. 30. Zverev A., Moskaleva O., Kudryavtseva M., Doronichev D., Bulda A.: Four Houses – Test Tools presentation. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-fourhousestesttools2012-1 31. Zaitseva N., Popovchuk N.: Next Step in Reconciliation Testing. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3exactpro-thenextstepinreconciliationtesting 32. G. Cugola and A. Margara: Processing flows of information: From data stream to complex event processing // ACM Computing Surveys, 2011. 33. QuickFIX/J . // [Электронный ресурс]. – Режим доступа http://quickfixj.org 34. Felix Fuentes, Dulal C. Kar: Ethereal vs. Tcpdump: a comparative study on packet sniffing tools for educational purpose // Journal of Computing Sciences in Colleges , Volume 20 Issue 4, April 2005 35. The Grinder TCP Proxy. // [Электронный ресурс]. – Режим доступа http://grinder.sourceforge.net/g3/tcpproxy.html 36. Investment Services Directive – Markets in Financial Instruments Directive (MiFID) 37. UL Bridge. // [Электронный ресурс]. – Режим доступа http://www.ullink.com/fixsolutions.php 214 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 212. Применение симуляторов рынка ценных бумаг для тестирования систем агрегации и распределения информации о котировках (Ticker Plant) Ольга Буянова1, Алёна Булда1, Алексей Зверев2 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул. Ленина, 20 Olga.Buyanova@exactpro.com, Alyona.Bulda@exactpro.com 2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Alexey.Zverev@exactpro.com 1 Aннотация. Системы агрегации и распределения информации о котировках широко применяются в современном трейдинге. Они позволяют собирать в реальном времени котировки с нескольких рынков, представлять данные о них в едином формате и распространять их в электронном виде в зависимости от запросов и целей внешних клиентов, трейдеров. В данной статье рассмотрена возможность применения симуляторов рынка к тестированию таких систем. Проведён анализ основных тестовых сценариев для систем распределения информации о котировках. Выделен набор основных функциональных и нефункциональных сценариев тестирования, необходимых для контроля качества распределения информации о котировках. Произведена сравнительная оценка симуляторов рынка и реальных тестовых площадок. Ключевые слова: система агрегации и распределения информации о котировках (Ticker Plant, Market Data), биржа, тестовая платформа, симулятор рынка, функциональное тестирование, нефункциональное тестирование. 1 Введение Современный электронный трейдинг невозможно представить себе без актуальных сведений о финансовых инструментах, заявках и сделках на них. Высоконагруженные биржевые и брокерские системы предоставляют рыночные данные о торгуемых на них финансовых инструментах через собственные специальные компоненты, называющиеся каналами распространения рыночных данных (или Market Data Feeds). Каждый финансовый инструмент - это значительное количество информации, генерирующейся ежесекундно, поэтому способность распространять весь поток рыночных данных и скорость распространения информации о котировках и финансовых сделках для каждого Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 215
  • 213. финансового инструмента являются основными характеристиками для такого рода компонентов высоконагруженных систем. 1.1 Рыночная информация (Market Data) и ее основные представления Обычно рыночная информация включает в себя следующий набор параметров, специфичных для определённого финансового инструмента: краткое название инструмента (ticker symbol), цена последней сделки (last trade price), текущие лучшие цены спроса и предложения (Best Bid Offer), идентификационный номер инструмента (ISIN), биржа, на которой произошла сделка (exсhange code), время последней сделки (Trade Time), цена сделки при закрытии торговой сессии на инструменте (Close Price). В зависимости от сложности высоконагруженных биржевых систем, рыночная информация о котировках может обрабатываться внутренними компонентами электронных бирж и обогащаться дополнительной информацией: например, об общем объёме сделок в течение биржевого дня (Turnover), о средневзвешенной цене по общему объему и количеству сделок (VWAP), а так же более детальной информацией об акции или деривативе – справочные данные, такие как параметры трейдеров, рынка, торговых сессий, инструментов (или Reference Data). Справочные данные (Reference Data или Static Data) представляют собой информацию об инструменте, которая не меняется в режиме реального времени: например, международный идентификационный код ценной бумаги (ISIN), цена сделки при закрытии трейдинговой сессии за предыдущий день (Close Price), валюта, в которой данный финансовый инструмент торгуется на бирже (Currency), параметры так называемых «прерывателей торгов», которые чаще указываются в процентных соотношениях к цене последней сделки (Dynamic or Static Circuit Breaker Tolerances (%)), и так далее[1]. Для предоставления перечисленной выше информации существует ряд стандартных протоколов распространения котировок (например, FIX/FAST [2]), так называемых протоколов распространенния котировок с фиксированной длинной сообщений (например, ITCH [3]), или кодированные протоколы передачи данных (например, HTTPS (HyperText Transfer Protocol Secure) [4] [5]). Многие электронные биржи распространяют информацию о котировках как через стандартные протоколы, так и через специальные. Трейдеры часто не могут позволить себе дорогостоящую разработку программ, которые бы собирали необходимую им для работы информацию о котировках. Таким образом, возникает необходимость создания систем сбора и агрегации рыночных данных с различных бирж и по различным финансовым протоколам передачи данных. 216 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 214. 1.2 Cистема агрегации информации (Ticker Plant) и ее основные функции Ticker Plant - это система агрегации информации о котировках с различных электронных торговых площадок (или бирж) и её распределения. Данная система предоставляет рыночные данные трейдерам в нормализованном или унифицированном виде [6]. Зачастую Ticker Plant рассчитывает дополнительные параметры на основе предоставленных рыночных данных, то есть обогащает статистическую информацию об акциях и деривативах. Кроме того, для таких систем характерна способность объединять однородные величины распространяемых котировок: ценовые уровни (Price Levels), предоставление котировок согласно запросам клиентов (например, широко распространены такие сервисы, как Level 1, Level 2, Index, TS, News) в режиме реального времени, а так же хранение переданной рыночной информации. Указанные выше типы сервисов по предоставлению рыночной информации достаточно распространены в электронной торговле финансовыми инструментами. Рассмотрим каждый из них подробнее: • Level1 - информация о последних Bid/Ask, OHLC (Open, High, Low, Close), Volume; • Level2 - информация о Level1 + Order Book (5-10 уровней глубины торговой книжки, Bid/Ask PxQty). Level2 может содержать атрибутированные или анонимные заявки), и использовать модели MBO (Market by Order, т.е. индивидуальное отображение всех заявок в пределах отдельно взятого ценового уровня) и MBP (Market by Price, т.е. агрегированное отображение заявок в пределах отдельно взятого ценового уровня). [7]; • Level2 - Total View - более полная информация по сравнению с Level2; • News - последние новости о компании [8]; • Index - данные об индексах [9]. Схематичное представление системы агрегации и распределения информации о котировках (Ticker Plant) показано на рисунке 1. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 217
  • 215. Рис. 1. Схема системы Ticker Plant. 2 Основные требования к системе агрегации и распределения информации о котировках (Ticker Plant) Исходя из описания системы агрегации и распределения информации о котировках (Ticker Plant) и основных её характеристик, выделенных выше, мы определяем набор требований, которым такая система должна соответствовать. При тестировании такой системы мы будем обращаться к этому набору характеристик. Для того, чтобы было удобно оценивать каждую характеристику, мы распределили их на функциональные и нефункциональные. Итак, система агрегации и распределения информации о котировках (Ticker Plant) должна решать следующие задачи: • с функциональной точки зрения: 1. собирать рыночную информацию о котировках из нескольких источников (поставщиков рыночной информации: бирж, банков); 2. обрабатывать справочные данные (reference data), предоставляемые биржами; 3. обрабатывать информацию о котировках, предоставляемую по различным протоколам передачи данных, в режиме реального времени; 4. преобразовывать полученную информацию в один формат; 5. агрегировать данные о котировках согласно различным методам, описанным выше; 218 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 216. 6. обрабатывать эти данные с целью расширить функциональность системы: например, предоставлять статистику (VWAP, Turnover, Trade High/Low, 52 week Trade High/Low); 7. предоставлять данные согласно запросам клиентов: Level1, Level2, TS, News, Index, Option chains и другое; 8. предоставлять записанную историческую информацию о котировках. • с нефункциональной точки зрения: 1. быструю обработку потоков информации о котировках, поступающей в режиме реального времени от электронных бирж; 2. быструю обработку запросов, поступающих от клиентов и предоставление данных о котировках в зависимости от вида запроса клиента (например, отдельно на торгуемый инструмент, или на группу инструментов, или на весь рынок); 3. бесперебойную работоспособность системы; 4. управляемость системой (operability); 5. возможность мониторинга систем (наличие приложений, с помощью которых можно наблюдать за системой или упралять её компонентами); 6. пропускную способность (throughput); 7. временную задержку (latency); 8. отказоустойчивость (fault tolerance). Определив набор функциональных и нефункциональных характеристик системы агрегации и распределения информации о котировках (Ticker Plant), нам необходимо понять, как будет проходить процесс тестирования отдельно взятой характеристики. Очевидными становятся два пути тестирования такого рода систем. Первый - это тестирование с реальными тестовыми площадками (CDS customer development service [10]). Обычно биржи предоставляют своим клиентам тестовые окружения (test environments), аналогичные реальной электронной трейдинговой платформе. Чаще всего это делается с целью пройти сертификационный процесс или предоставить клиентам возможность для отладки своего клиентского программного обеспечения. И второй - это тестирование с помощью симуляторов трейдинговых платформ, разработанных на основе данных о бирже, находящихся в публичном доступе. 3 «Тестовая» биржа: описание и основные возможности “Тестовая” биржа - это своего рода полная копия реальной трейдинговой биржи [11]. Такой аналог трейдинговой биржи должен наиболее полно представлять реальную электронную платформу. Тестовые биржи Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 219
  • 217. предоставляются клиентам, которым необходимо отладить разработанное ими трейдинговое и информационное программное обеспечение [12]. Заявки и сделки в таких тестовых биржах генерируются как следствие взаимодействия самих клиентов, тестирующих собственное программное обеспечение, друг с другом. В идеале тестовая биржа состоит из тех же компонентов и частей, что и реальная биржевая система[13]. Торговые сессии, основные параметры торгуемых инструментов, правила трейдинга, графические приложения для управления настройками справочных данных (reference data) и т.д - все эти характеристики полностью аналогичны компонентам реальной системы. Поэтому такое тестовое окружение (test environment) позволяет проверять программное обеспечение, заведомо ориентируясь на аналогичные настройки в реальной системе. Ниже приведена схема тестирования Ticker Plant с применением тестовой биржи. Рис.2 Тестирование Ticker Plant с помощью тестовой биржи 220 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 218. 4 Симулятор рынка ценных бумаг: описание и основные возможности Симулятор рынка ценных бумаг (или биржевой симулятор) - это интерактивная программа, разработанная для имитации возможностей и свойств реальных моделей рынка[14]. Симулятор рынка должен уметь эмулировать реальные действия, происходящие на бирже: сам трейдинг (размещение заявок, генерацию сделок, изменения статусов инструментов и т.д), симуляцию мониторинга за ходом торгов на рынке и внесение изменений (market operations: отмена/изменение заявок и сделок, остановка торгов, и т.д.), режим работы рынка (переход рынка из одного статуса в другой - открытие рынка (Market Open), аукционы (Opening/Closing/ Periodic Auction Calls), вычисления цен аукционов и публикация цены закрытия, закрытие рынка и т.д. Биржевой симулятор рынка содержит API, аналогичный реальной бирже, с элементами контроля отсылаемых ответов клиенту[15]. Такие симуляторы рынков позволяют иметь более полный контроль над генерируемыми событиями для системы агрегации и распределения информации о котировках (Ticker Plant)[16], таким образом увеличивая покрытие тестирования системы. С помощью симуляторов можно создать необходимую нагрузку, сравнимую с потоками данных, свойственным реальным высоконагруженным биржевым и брокерским системам. Далее представлена схема верификации системы Ticker Plant при помощи симулятора. Рис.3 Схема тестирования Ticker Plant с применением симулятора Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 221
  • 219. 5 Составление библиотеки сценариев и тестов для верификации корректности работы системы агрегации и распределения информации о котировках (Ticker Plant) 5 Составление библиотеки сценариев и Исходя из основных требований к системе Ticker Plant, мытестов для разработали верификации корректности работы системы агрегации и библиотеку сценариев тестирования, которыми можно проверить распределения такой системы. В таблице (Ticker Plant) работоспособность информации о котировках 1 приведены области тестирования системы Ticker Plant и дано их краткое описание. Таблица также Исходя из основных шкалу областей тестирования по приоритетам. показывает оценочную требований к системе Ticker Plant, мы разработали библиотеку которыми Например, еслисценариев той или иной области указан можно напротив тестирования, приоритетпроверить 1, это работоспособность такой системы. В этой области тестируемая система таблице 1 приведены области означает, что при возникновении ошибок в тестирования системы Ticker Plant и дано их краткое описание. Таблица также Ticker Plant не сможет полноценно выполнять свою основную задачу. показывает оценочную шкалу областей в этой области, система может Приоритет 3 означает, что при наличии ошибоктестирования по приоритетам. Например, если напротив той или иной области указан приоритет 1, это выполнять свою основную задачу, но с некоторыми отклонениями. означает, что при возникновении ошибок в этой области тестируемая система Табл. Области тестирования Ticker свою Ticker Plant не сможет1. полноценно выполнять Plant. основную задачу. Приоритет 3 означает, что при наличии ошибок в этой области, система может выполнять свою основную задачу, но с некоторыми отклонениями. Описание Приоритет № Область тестирования (1 - 3) Табл. 1. Области тестирования Ticker Plant. - возможности подключения к основным 1 1 Техническое каналам (primary channel); подключение к Область тестирования - подключение к запасным каналам Описание Приоритет № биржам - поток данных о котировках и (secondary channels); (1 - 3) - отказоустойчивость (fault tolerance); сделках в режиме - тестирование аварийного 1 реального времени Техническое - возможности подключения к основным 1 восстановления данных (disaster (streaming quotes - real подключение к каналам (primary channel); recovery) time) биржам - поток - подключение к запасным каналам  данных(User UDP о котировках и (secondary channels); Datagram Protocol) сделках в режиме - отказоустойчивость (fault tolerance);  реального времени TCP/IP - тестирование аварийного (Transmission Control (streaming quotes - real восстановления данных (disaster Protocol (TCP) и time) recovery) Internet Protocol (IP)  UDP (User  Datagram Protocol) HTTPS (HyperText Transfer Protocol  TCP/IP Secure) (Transmission Control Protocol (TCP) и Internet Protocol (IP)  HTTPS (HyperText Transfer Protocol Secure) 222 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 220. № Область тестирования Описание Приоритет (1 - 3) 2 Техническое подключение к биржам - каналы восстановления данных (Replay/Recovery channels) - возможности подключения к основным каналам (primary channel); - подключение к запасным каналам (secondary channels); - отказоустойчивость (fault tolerance); - тестирование аварийного восстановления данных (disaster recovery) 1 3 Тестирование интерфейса протокола от биржи к системе Ticker Plant (real time + replay/recovery) - проверка административных сообщений, инициируемых Ticker Plant (Administrative messages: Login Request, Replay Request, Snapshot Request, Logout Request); - проверка административных сообщений, инициируемых каналом (Administrative messages): Heartbeat, Login Response, Replay Response, Snapshot Response, Snapshot Complete); - проверка сообщений приложения (Application messages: Time, System Event, Symbol Directory, Symbol Status, Add Order, Add Attributed Order, Order Deleted, Order Modified, Order Book Clear, Order Executed, Order Executed with Price/Size, Trade, Auction Trade, OffBook Trade, Trade Break, Auction Info, Statistics); - проверка обязательных полей (mandatory tags/values) и значений; - проверка необязательный полей и значений (optional tags/values); - проверка всевозможных вариантов и сочетаний значений тагов (Order Type, TIF и т.д); - проверка негативных значений (неподдерживаемые значения, отрицательные значения, специальные символы, и т.д) 1 4 Восстановление потери небольшого количества данных (Replay channel) - возможности подключения к основному каналам (primary channel); - подключение к запасным каналу (secondary channels); - проверка последовательности полученных данных; 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 223
  • 221. № Область тестирования Описание - проверка полученных данных на правильность; - проверка объёма буферизации данных Приоритет (1 - 3) 5 - возможности подключения к основному каналу (primary channel); - подключение к запасным каналам (secondary channels); - проверка последовательности полученных данных; - проверка полученных данных на правильность; - проверка объёма переданных данных 1 6 Проверка справочных данных (Reference Data) - возможность загрузить данные о финансовых инструментах, предоставляемых биржей; - правильность обработки данных; - использование справочных данных для подсчета различных показателей 1 7 Тестирование поведения системы Ticker Plant при отказе компонентов биржи (Failover при потоке данных с биржи) - восстановление данных после отказа основного и/или запасного каналов; - возможность переподключения; - правильная последовательность сообщений; - возможность дальнейшей обработки данных после восстановления 1 8 Тестирование при отказе компонентов системы Ticker Plant (Failover при потоке данных из системы Ticker Plant) - проверка работоспособности компонентов системы Ticker Plant при отказе основного/запасного каналов; - правильная последовательность сообщений; - возможность дальнейшей обработки данных после восстановления 2 9 224 Восстановление потери большого количества данных (Recovery channel) Тестирование полного трейдингового дня (цикла) работы системы Ticker Plant (DLC – Daily Life Cycle) - проверка правильной последовательности старта компонентов системы Ticker Plant; - проверка правильной последовательности выключения компонентов системы Ticker Plant 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 222. № Область тестирования Описание Приоритет (1 - 3) 10 Тестирование полного трейдингового дня (цикла) на бирже (DLC – Daily Life Cycle) - правильность последовательности приходящих сообщений в течение дня; - добавление нового инструмента, изменение его параметров, удаление; - изменение статусов инструментов; - переход заявок из одной трейдинговой фазы в другую; - переход заявок из одного дня в другой 1 11 Проверка всевозможных торговых статусов рынка - проверка на присутствие данных видов статусов внутри системы Ticker Plant: например, Halt, Opening auction call, Premandatory quote period, Continuous trading, End trade reporting, Closing auction call; - проверка обрабатывания переходов из одного статуса инструментов в другое; - проверка правильности обработки сообщений при массовой смене статусов на финансовых инструментах 1 12 Измерение ширины потребляемого канала передачи данных по сети (Bandwidth) - проводятся нагрузочные тесты для измерения объёма передаваемых данных в единицу времени 1 13 Измерение пропускной способности каналов в единицу времени (Throughput) - проводятся нагрузочные тесты для подсчёта среднего количества гарантировано доставленных сообщений через каналы передачи данных 1 14 Измерение задержек (латентности (Latency) системы) - проверка компонентов системы на задержу передачи данных во времени 1 15 Проверка нагрузочной способности системы (Capacity) - нагрузка входным потоком данных - проверка на работоспособность системы Ticker Plant при большом входном потоке данных 2 16 Проверка нагрузочной способности системы (Capacity) - нагрузка - проверка на обработку системой Ticker Plant большого количества запросов 2 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 225
  • 223. № Область тестирования Описание с клиентской стороны системы Ticker Plant Приоритет (1 - 3) 17 - попытки подключения клиента (CompID) с недостаточным кличеством прав; - попытки подключения с несуществующим пользователем; - проверки максимального количества подключений; - проверки максимального количества запросов 1 18 Проверка правильности обработки системой Ticker Plant некорректных сообщений от биржи - отклик на несуществующие сообщения (messages types); - неправильное количество тагов; - неправильный порядок тагов; - неправильная контрольная сумма (checksum) 2 19 Проверка корректности работы системы в целом - от трейдингового клиента до системы Ticker Plant (E2E тестирование) - добавление заявок; - изменение заявок; - удаление заявок; - добавление агрессивных заявок (приводящих к сделке) 1 20 Сложные сценарии на функциональность самой биржи - проверка на то, как система обрабатывает очередность событий (например, многоуровневые сделки с айсберг заявками); - вычисления цены аукциона; - поведение Stop /Stop Limit ордеров в зависимости от фазы трейдингого дня; - проверка поведения GTC ордеров в течение нескольких дней 2 21 226 Проверка системы Ticker Plant при неправильных запросах клиентов и ответная реакция на них для Replay/Recovery каналов Реконсиляционное тестирование - проверка при сравнении потоков, идущих к системе и от системы (детальная проверка на то, что каждое событие, поступившее на вход системы, обработалось и отобразилось на выходном потоке) 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 224. № Область тестирования Описание Приоритет (1 - 3) 22 Тестирование MBO (market by order) и MBP (market by price) сервисов - функциональна проверка сервисов, предоставляемых системой Ticker Plant 1 23 Проверки расчёта индексов - проверка правильности расчетов индексов в зависимости от потока сделок 2 24 Правильность расчёта статистических данных - проверка расчёта VWAP, Turnover, Trade High Low, 52 week Trade High Low и т.д. 2 25 Работа с историческими данными - сбор исторических данных; - сортировка в зависимости от типа данных; - выдача результатов согласно запросам клиентов; - возможность проигрывать записанные исторические данные 2 26 Проверка получения и передачи новостных каналов от бирж - тестирование новостей (News); - тестирование оповещений клиентов (Announcements) 3 27 Проверка действия биржевого оператора - отмена сделок; - изменение параметров сделки 2 28 Проверка сложных запросов клиента - выдача данных для деривативного инструмента (опционные цепочки option chains) на запрашиваемый базовый инструмент 2 29 Мониторинг системы - проверка приложений, с помощью которых можно наблюдать за системой или управлять её компонентами 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 227
  • 225. 6 Методика анализа покрытия тестирования системы агрегации и распределения информации о котировках (Ticker Plant) при помощи инструментов для тестирования Для того, чтобы оценить и проанализировать, насколько полно инструметы тестирования покрывают области функциональности системы Ticker Plant, которую необходимо протестировать, нами была разработана специальная методика. Она основывается на переборе сценариев в процентном отношении к всевозможным сценариям, относящимся к той или иной области. Основываясь на опыте тестирования, полученном в компании Exactpro Systems [17], была определена приоритетность областей системы Ticker Plant, обозначенной в правой колонке таблицы 1. Следующий раздел рассказывает об опыте применения данной методики покрытия тестами для оценки полноты тестирования системы Ticker Plant, как с помощью реальных тестовых площадок, так и с помощью биржевых симуляторов. 6.1 Сравнительная характеристика оценочных данных при тестировании системы агрегации и распределения информации о котировках Ticker Plant с помощью реальной тестовой биржи и симулятора В таблице 2 приведены сравнительные характеристики, включающие в себя оценочные данные, полученные в ходе тестирования системы Ticker Plant с помощью реальной тестовой биржи и симулятора, а так же детальное объяснение полученных данных. Табл. 2. Сравнительные характеристики данных для тестовой биржи и симулятора. № 1 228 Область тестирования Техническое подключение к биржам - поток данных о котировках и торгах в режиме реального времени Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 100 40 Детализация оценочных данных При данной оценке мы исходим из того что симулятор биржи, по своему определению, не способен полноценно воспроизвести все технические детали Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 226. № Область тестирования (streaming quotes real time)  UDP (User Datagram Protocol);  TCP/IP (Transmission Control Protocol (TCP) и Internet Protocol (IP);  HTTPS (Hypertext Transfer Protocol Secure) Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) Детализация оценочных данных соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно на 40%, исходя из набора тестовых сценариев на соединение с биржей 2 Техническое подключение к биржам - каналы восстановления данных (Replay/Recovery channels) 100 40 3 Тестирование интерфейса протокола от биржи к системе Ticker Plant (real time + replay/recovery) 100 100 При данной оценке мы исходим из того, что симулятор не может воспроизвести всех технических деталей соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно с 40% -м покрытием сценариев. Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие набора тестовых сценариев. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 229
  • 227. № Область тестирования Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 4 100 100 5 230 Восстановление потери небольшого количества данных (Replay channel) Восстановление потери большого количества данных (Recovery channel) 75 100 Детализация оценочных данных Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие набора тестовых сценариев. Несмотря на то, что данная функциональность изолирована от биржи, ee проверка требует значительного потока кортировок с биржи. Исходя из нашего опыта, такое возможно не всегда с тестовой биржей, и есть ряд значительных ограничений. Поток данных с тестовых плошадок обычно соответствует ожиданиям, однако его практически невозможно контролировать, чего не скажешь о симуляторе, контроль над которым находится в руках Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 228. № Область тестирования Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 6 Проверка справочных данных (Reference Data) 100 5 7 Тестирование поведения системы Ticker Plant при отказе компонентов биржи (Failover при потоке данных с биржи) 100 10 8 Тестирование при отказе компонентов системы Ticker Plant (Failover при потоке данных из системы Ticker 100 40 Детализация оценочных данных тестировщиков. Данное тестирование сосредоточено на верификации настроек системы, настроек финансовых инструментов и т.д. Необходимо тестировать в связке с реальными рынками. Тестирование с симулятором в данном случае возможно, но значительная часть тестов проверяет соединение между Ticker Plant и биржами. При данной оценке мы исходим из того, что симулятор не может воспроизвести всех технических деталей соединения с биржей. При наличии стандартной спецификации, эмулирование шлюза возможно с 40% -м покрытием сценариев. Возможно тестирование с симулятором, но значительная часть тестов верифицирует соединение между Ticker Plant и рынками. При Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 231
  • 229. № Область тестирования Plant) Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 9 40 100 10 232 Тестирование полного трейдингового дня (цикла) работы системы Ticker Plant (DLC – Daily Life Cycle) Тестирование полного трейдингового дня (цикла) на бирже (DLC – Daily Life Cycle) 100 40 Детализация оценочных данных данной оценке мы исходим из того, что симулятор априори не может воспроизвести всех технических деталей соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно с 40% -м покрытием. Всвязи с большими ограничениями в управлении торговым днем на тестовых площадках, симулятор предоставляет больше возможностей при воспроизведении подобных сценариев тестирования. Не смотря на то, что предыдущее обоснование применимо и в данном случае, в даном сценарии больший вес имеет понятие того, что входящие сообщения создаются при помощи тестового рынка, согласно настройкам справочных данных (Reference Data) самой биржи. При данной оценке мы Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 230. № Область тестирования Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 11 Проверка всевозможных торговых статусов рынка 50 100 12 Измерение ширины потребляемого канала передачи данных по сети (Bandwidth) 75 100 13 Измерение пропускной способности каналов в единицу времени 75 100 Детализация оценочных данных исходим из того, что симулятор априори не может воспроизвести всех технических деталей соединения с полного трейдингового дня (цикла) работы системы (DLC). Поэтому оценка покрытия составляет лишь 40%. В связи с ограничениями в управлении торговым днем на тестовых площадках, симулятор предоставляет больше возможностей при воспроизведении подобных сценариев. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 233
  • 231. № Область тестирования (Throughput) Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 14 75 100 15 Проверка нагрузочной способности системы (Capacity) нагрузка входным потоком данных 75 100 16 234 Измерение задержек (латентности (Latency) системы) Проверка нагрузочной способности системы (Capacity) нагрузка с клиентской стороны системы Ticker Plant 75 100 Детализация оценочных данных зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
  • 232. № Область тестирования Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 17 Проверка системы Ticker Plant при неправильных запросах клиентов и ответная реакция на них для Replay/Recovery каналов 100 100 18 Проверка правильности обработки системой Ticker Plant некорректных сообщений от биржи 25 100 19 Проверка корректности работы системы в целом - от трейдингового клиента до системы Ticker Plant (E2E тестирование) 90 85 Детализация оценочных данных преимущество. Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие. В данном случае симулятор может отправлять на вход Ticker Plant достаточно гибкий набор негативных сценариев тестирования, что обеспечивает большее покрытие. Однако, с другой стороны, абсолютное число сценариев, с технической точки зрения, имея при этом только спецификацию биржи, невозможно воспроизвести. Данное тестирование представляет собой набор всех трейдинговых сценариев тестирования. Это можно обеспечить как симулятором, так и тестовой площадкой. Поэтому Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 235
  • 233. № Область тестирования Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) оценочная характеристика примерно одинаковая. 20 Сложные сценарии на функциональность самой биржи 50 100 21 Реконсиляционное тестирование 100 50 22 236 Детализация оценочных данных Тестирование MBO (market by order) и MBP (market by price) сервисов 100 100 Оба подхода предостовляют равные возможности при эмуляции сложных