Содержание к диссертации
Введение
Глава 1. Методы исследования интегрированных систем безопасности 17
1.1. Методы исследования операций при моделировании сложных систем 17
1.2. Классификация средств имитационного моделирования 20
1.3. Параметры сравнения средств имитационного моделирования 22
1.4. Сравнение систем имитационного моделирования 25
1.4.1. Событийно-ориентированные СИМ 26
1.4.2. Процессно-ориентированные СИМ 30 ,
1.5. Использование нотации Хоара при построении имитационных моделей программных систем 39
Основные выводы 45
Глава 2. Конструирование имитационной модели интегрированной системы безопасности 47
2.1. Описание интегрированной системы безопасности на основе комплекса «Бастион» 47
2.1.1. Сравнительные характеристики ИСБ 47
2.1.2. Архитектура сети ИСБ «Бастион» 51
2.1.3. Основные классы программной системы 53
2.2. Установка соответствий между реальными объектами и объектами модели 57
2.2.1. Функциональное описание процесса обработки событий 57
2.2.2. Определение моделируемых классов системы 60
2.3. Создание формальной модели процесса обработки событий в нотации Хоара 62
2.4. Создание MS-модели ИСБ «Бастион» 65
2.4.1. Моделирование программной логики 65
2.4.2. Моделирование управления квазипараллельными процессами 73
Основные выводы и результаты 79
ГЛАВА 3. Оценка возможностей масштабирования ИСБ на имитационной модели 81
3.1. Методика оценки применимости комплекса «Бастион» на объекте охраны с известными параметрами 81
3.2. Оценка влияния параметров компьютерной сети на производительность системы обработки событий 87
3.2.1. Определение зависимости параметров системы от числа рабочих мест 88
3.2.2. Изменение скорости обработки событий при распределении нагрузки между серверами системы 91
3.2.3. Оценка влияния производительности процессоров на скорость обработки событий 95
3.3. Определение эффективного алгоритма визуализации событий 98
3.3.1. Формулировка задачи и подготовка эксперимента 98
3.3.2. Проведение эксперимента и анализ результатов 101
Основные выводы и результаты 103
Глава 4. Оптимизация имитационной модели 105
4.1. Структурная оптимизация имитационной модели ИСБ «Бастион»... 105
4.1.1. Определение необходимых изменений в имитационной модели . 105
4.1.2. Проведение сравнительного эксперимента и анализ результатов 109
4.1.3. Переход к программным конструкциям 112
4.2. Методы и алгоритмы поиска численного оптимума на имитационных моделях 114
4.2.1. Основные подходы к задачам оптимизации имитационных моделей 114
4.2.2. Реализация оптимизатора OptQuest для Micro Saint 117
4.3. Параметрическая оптимизация имитационной модели 121
4.3.1. Постановка задачи и систематизация параметров оптимизации.. 121
4.3.2. Проведение оптимизационного эксперимента и анализ результатов 127
Основные выводы и результаты 130
Заключение 131
Список использованных источников 135
Приложения 145
- Методы исследования операций при моделировании сложных систем
- Сравнительные характеристики ИСБ
- Методика оценки применимости комплекса «Бастион» на объекте охраны с известными параметрами
- Определение необходимых изменений в имитационной модели
Введение к работе
Обеспечение безопасности собственной деятельности во все времена оставалось одной из наиболее приоритетных задач любой организации. С развитием технических средств системы обеспечения безопасности постоянно усложнялись вместе с появлением новых видов угроз.
Период 70-90 годов характеризуется бурным ростом средств и технологических решений в мировой индустрии безопасности. Сформировались и структурно оформились классы систем, отражающих конкретные виды угроз безопасности объектов. Развитие информационных технологий и микропроцессорных средств стимулировало внедрение более интеллектуальных датчиков и исполнительных устройств в системах безопасности. Появилось понятие интегральной безопасности, что означает обеспечение таких условий функционирования организации, при которых она надёжно защищена от всех возможных угроз в ходе всего непрерывного процесса своей деятельности [1]. Обеспечение такого уровня безопасности является конечной целью развития всей индустрии безопасности.
Всё перечисленное открыло путь к объединению специализированных подсистем в интегрированные системы безопасности (ИСБ). ИСБ традиционно является системой физической защиты объектов. Прочие аспекты обеспечения безопасности (информационный, юридический и т.д.) обеспечиваются другими средствами и, как правило, другими службами организаций.
Набор технических средств ИСБ, как правило, включает в себя охранно-пожарную и тревожную сигнализацию (ОПС), систему контроля и управления доступом (СКУД), телевизионную систему наблюдения (ТСН) и систему оповещения. Каждая из этих подсистем обеспечивает защиту от определенных видов угроз и может использоваться отдельно.
До настоящего времени рассматриваемая предметная область характеризуется не устоявшейся терминологией, о чём свидетельствует как наличие неоднозначных определений собственно ИСБ [1, 10-13, 21, 28], так и отсутствие стандартов на подобные системы. В данной работе будет принято определение, данное председателем комитета «Технические средства охраны» Госстандарта России Вишняковым СМ. [10]: «ИСБ представляет собой набор взаимодействующих технических и программных средств, обладающих технической, программной, информационной и эксплуатационной совместимостью и предназначенных для обеспечения физической безопасности объекта». Таким образом, вопросы, связанные с организационной стороной обеспечения безопасности, остаются за пределами нашего рассмотрения.
Перечисленные требования совместимости предполагают наличие единых способов регистрации, хранения и отображения информации, возможность информационного обмена между отдельными подсистемами. В полном объёме и с достаточной степенью гибкости эти задачи может решать только компьютерная сетевая программная система. Развитие интегрированных систем подтверждает этот тезис.
В США и Западной Европе внедрение ИСБ в практику обеспечения безопасности оборонных, правительственных и индустриальных объектов начинается со второй половины 80-х годов. В России этот процесс начался только в середине 90-х годов благодаря усилиям предприятий-интеграторов. В настоящее время такие системы стали фактическим стандартом при построении комплексов охраны средних и крупных объектов, таких как промышленные предприятия, музеи, гостиницы, банки.
Можно выделить несколько этапов развития ИСБ. Самые первые системы строились на базе простых проводных соединений, либо соединений дискретных входов и выходов различного оборудования. Позднее производители стали оснащать свои продукты стандартными интерфейсами для взаимодействия с компьютером (RS-232, RS-485). Параллельно существовала так называемая «дикая» интеграция с организацией не предусмотренных для этого коммуникационных каналов, взломом внутренних протоколов информационных линий, эмуляцией аппаратных терминалов управления оборудованием при помощи ЭВМ и прочими нестандартными решениями. При этом механизм реагирования на события реализовывался уже в интегрирующем программном обеспечении.
На сегодняшний день можно говорить о двух основных концепциях построения ИСБ: системах с открытой и закрытой архитектурой. Первый вариант допускает использование произвольного набора оборудования в составе ИСБ, в том числе и от разных производителей. Второй вариант, как правило, реализуется компаниями, ориентированными на работу только с техникой собственной разработки. Среди закрытых систем также можно выделить 2 варианта организации - с интеграцией на основе компьютерного ПО и полностью аппаратной интеграцией. Последний вариант представляется наиболее надёжным, но в то же время самым дорогим, требующим для реализации больших технических и технологических ресурсов. Существуют и комбинированные комплексы - с основой на несколько собственных аппаратных разработок и открытой архитектурой [А1,АЗ].
Сервер базы данных Рабочие места службы безопасности
Другой аспект интеграции связан с тем, что современная ИСБ всё теснее внедряется в информационную инфраструктуру организаций, реализуя такие вспомогательные функции, как: учёт рабочего времени сотрудников, автоматизация работы бюро пропусков, отдела кадров, управление системами жизнеобеспечения зданий и т.д. Обобщённая структура ИСБ (с точки зрения максимума функциональных возможностей) представлена на Рис. 1 [A3].
Очевидно, что главная цель работы СБ в целом - минимизация рисков нанесения ущерба организации. При этом, необходимо учитывать тот факт, что затраты на службу безопасности должны быть минимальными при требуемом уровне безопасности (то есть, защите, от заданного набора угроз). Таким образом, основная цель создания программного обеспечения для ИСБ - повышение эффективности работы сотрудников службы безопасности и смежных служб за счет введения дополнительных сервисных возможностей. Это, в конечном итоге, должно привести к снижению требований к количеству сотрудников СБ, а следовательно - и к снижению ее стоимости [A3].
Исходя из этого, критериями оценки эффективности работы интегрированной системы можно считать следующие параметры:
1. Уровень формализации системы принятия решений. При внедрении ИСБ функции принятия решений, которые могут быть формализованы, должны выполняться без участия операторов. Другими словами, чем более совершенна система принятия решений с помощью программно-аппаратных средств, тем эффективнее ИСБ в целом.
2. Время принятия решений системой в нештатных ситуациях. Данный параметр индивидуален для каждой системы - допустимое время принятия решения может варьироваться от долей секунды до нескольких минут.
3. Способность системы к прогнозированию развития ситуации на объекте охраны. ИСБ будет более эффективной, если ее операторы будут получать предупреждения о возможном развитии событий. Кроме того, в случае, если система будет содержать аналитические средства, задача выявления наиболее уязвимых компонент системы для руководства СБ будет значительно облегчена.
4. Эргономические показатели интерфейса комплекса.
5. Уровень автоматизации вспомогательных задач, таких как учет пропусков и учет рабочего времени сотрудников.
6. Уровень защиты программного обеспечения комплекса от несанкционированных внешних воздействий.
Следует заметить, что далеко не все из перечисленных показателей подлежат формализации: например, сложно говорить о числовом выражении «уровня эргономики интерфейса». Из этого, однако, не следует, что данные критерии являются менее значимыми. Для оценки этих параметров требуются другие методы, такие как метод экспертных оценок.
В силу постоянно увеличивающихся требований к системам данного класса, появления нового оборудования, все большей степени интеграции ИСБ в информационную среду организаций, возникает задача анализа подходов к построению программного обеспечения ИСБ, его оптимизации и повышения надежности.
Применение подобных комплексов на крупных объектах, с несколькими тысячами и даже десятками тысяч сотрудников, распределенной инфраструктурой, большим количеством пользователей, ставит перед разработчиками ИСБ целый ряд вопросов. Главные из них:
1. Как обеспечить допустимое время реакции системы на нештатные (тревожные) сообщения в условиях высокой интенсивности их поступления?
2. Как обеспечить достаточную пропускную способность системы обработки событий в целом?
3. Как распределить потоки информации между различными частями программного комплекса?
Кроме того, зачастую невозможно заранее определить, будет ли комплекс работоспособен (с точки зрения скорости обработки событий) при использовании на заданном объекте. Будет ли он сохранять работоспособность при росте масштабов объекта (масштабируемость) или увеличении интенсивности информационных потоков?
Всё сказанное показывает, что интегрированная система безопасности как объект исследования представляет интерес прежде всего с точки зрения оптимизации и эффективного управления информационными потоками. Создание эффективного программного обеспечения ИСБ представляет на сегодняшний день весьма непростую задачу, связанную как с архитектурной сложностью системы, так и с отсутствием возможности верификации правильности принимаемых решений на этапе проектирования.
Результаты исследования должны служить основой для решения следующих проблем:
1. Создание эффективной системы обработки сообщений. Определение критериев последовательности обработки сообщений, необходимости и вида оповещения о различных событиях. Определение возможностей и эффективности использования технологий параллельной обработки в работе системы обработки сообщений.
2. Определение оптимальной архитектуры программного обеспечения ИСБ с точки зрения скорости обработки сообщений.
3. Определение параметров, влияющих на требования к скоростным характеристикам информационной системы. Определение требований к конфигурации информационной системы применительно к заданному объекту.
Целью диссертационной работы является анализ и оптимизация архитектуры программного обеспечения интегрированной системы безопасности, для достижения гарантированно-высоких показателей времени реакции на события, высокой степени масштабируемости и открытости, снижения информационной нагрузки на операторов службы безопасности, а также создание методики оптимизации структуры сети ИСБ применительно к объекту охраны с заданными параметрами.
Для решения перечисленных задач требуется пройти по пути создания и изучения некоторой модели на основе имеющегося функционального описания системы. Такая модель может быть получена либо с помощью формального математического описания объекта (аналитическое моделирование), либо путем создания имитационной модели системы.
В соответствии с поставленной целью в диссертационной работе решаются следующие задачи исследования:
1. Анализ имеющихся средств и методов моделирования сложных систем.
2. Создание метода формального перехода от программных конструкций к формализмам модели и обратно.
3. Разработка имитационной модели интегрированной системы безопасности на основе существующего функционального описания.
4. Формулировка критериев эффективности работы программного обеспечения интегрированной системы безопасности.
5. Оценка масштабируемости существующей архитектуры и определение основных её недостатков и преимуществ.
6. Проведение оптимизации полученной модели с учётом выявленных недостатков.
7. Экспериментальная проверка эффективности оптимизированной архитектуры.
8. Создание методики определения оптимальной структуры сети для ИСБ при использовании на заданном объекте.
Методы исследования. В диссертационной работе используются методы имитационного моделирования дискретных систем, формального описания взаимодействующих процессов, оптимизации на имитационных моделях.
Научная новизна. В результате проведённых исследований был получен ряд новых научных результатов:
1. Предложен способ моделирования интегрированных систем безопасности, позволяющий оценить большое число их параметров.
2. Предложена модель эффективной архитектуры программного обеспечения интегрированной системы безопасности.
3. Предложен метод формального перехода от имитационной модели к конструкциям программы и наоборот.
4. Разработана методика оптимизации конфигурации сети ИСБ для объекта охраны с заданными параметрами.
На защиту выносятся:
- способ моделирования интегрированных систем безопасности;
- архитектура интегрированной системы безопасности;
- метод формального перехода от имитационной модели к конструкциям программы;
- методика оптимизации структуры сети ИСБ.
Практическая ценность работы заключается в оптимизации алгоритмов обработки событий в ИСБ, результаты которой были внедрены в программное обеспечение управления ИСБ «Бастион», а также в создании методики оптимизации конфигурации сети ИСБ «Бастион» для объекта охраны с заданными параметрами. Оптимизированная структура ИСБ позволила существенно повысить масштабируемость комплекса «Бастион», а разработанная методика - проводить наглядную оценку эффективности той или иной конфигурации с высокой точностью ещё на этапе проектирования структуры ИСБ объекта.
Практическая ценность подтверждена актами использования результатов диссертации. Программное обеспечение управления ИСБ «Бастион» с оптимизированной архитектурой установлено в нескольких десятках организаций и предприятий Самарской области, Москвы и других регионах России. Методика подбора конфигурации сети ИСБ для заданного объекта внедрена в технологический процесс департамента инсталляции ассоциации «Электронные системы», г. Самара. Результаты работы использованы в учебном процессе Самарского государственного аэрокосмического университета при разработке лабораторной базы курса «Имитационное моделирование экономических процессов».
Апробация работы. Основные положения диссертационной работы, научные и практические результаты докладывались на 4 всероссийских конференциях: Всероссийской молодёжной научной конференции «XXV Гагаринские чтения» (Москва, 1999); II Всероссийской научно-практической конференции «Технические средства охраны, комплексы охранной сигнализации и системы управления доступом» (Заречный, 1999); VI Всероссийской научно-технической конференции «Новые информационные технологии в научных исследованиях и образовании» (Рязань, 2001); VIII Российской научной конференции профессорско-преподавательского состава, научных сотрудников и аспирантов ПГАТИ (Самара, 2001).
Публикации. Всего по теме диссертации опубликовано 8 печатных работ. Список опубликованных работ приведён в заключении.
Структура и краткое содержание диссертации:
Диссертация состоит из основной части и приложений. Основная часть содержит введение, четыре главы, заключение, список использованных источников. Приложения содержат акты внедрения, общие сравнительные характеристики ряда систем имитационного моделирования, краткое описание системы Micro Saint.
Во введении показана актуальность темы диссертации, дана общая характеристика работы, определены цели и задачи исследования. Приведены структура и краткое содержание диссертации, основные положения, выносимые на защиту.
В первой главе проводится анализ средств и методов моделирования сложных систем; приводится классификация систем имитационного моделирования; рассматриваются параметры выбора средства моделирования; с учетом предложенных параметров рассматриваются достоинства и недостатки различных систем имитационного моделирования; рассматриваются методы формального представления взаимодействующих процессов.
Во второй главе даётся описание архитектурных особенностей комплекса «Бастион»; выполняется формальное описание процесса обработки событий с использованием расширенной нотации Хоара; на основе полученного формального описания разрабатывается имитационная модель системы в формате Micro Saint.
В третьей главе предлагается методика оценки применимости комплекса «Бастион» на объектах охраны с заданными параметрами; выполняется ряд имитационных экспериментов с целью оценки масштабируемости системы и выполняется анализ полученных результатов; выявляются основные достоинства и недостатки имеющейся архитектуры программного обеспечения; предлагается усовершенствованный алгоритм визуализации событий и даётся экспериментальная оценка его эффективности.
В четвёртой главе выполняется структурная оптимизация полученной модели; проводится обзор методов оптимизации на имитационных моделях; рассматриваются основные принципы работы метаэвристических алгоритмов оптимизации и даётся описание особенностей работы оптимизатора Micro Saint моделей - OptQuest; определяются целевая функция, ограничения и прочие параметры оптимизации; проводится оптимизационный эксперимент с разработанной моделью ИСБ; формулируются основные этапы методики оптимизации структуры сети комплекса «Бастион».
В заключении обобщаются результаты проведенного исследования, а также приводится список опубликованных работ.
Методы исследования операций при моделировании сложных систем
Постановка задачи оптимизации информационных потоков в ИСБ предполагает использование одного из методов исследования операций, а следовательно, и аппарата моделирования. Это ставит вопрос о методе создания модели - возможно ли получить математически точное описание объекта, и, таким образом, создать аналитическую модель системы, или же более эффективным в данном случае будет применение методов имитационного моделирования?
ИСБ как объект моделирования следует относить к классу сложных систем, так как им присущи все их основные признаки [6, 7]: наличие большого количества взаимосвязанных и взаимодействующих элементов, сложность выполняемой системой функции, возможность разбиения на подсистемы, наличие разветвлённой информационной сети и интенсивных потоков информации.
Классический метод построения аналитических моделей - линейное программирование - предназначен, в основном, для решения частных задач (транспортная задача, минимизация сети и т.д.) и не может быть использован для анализа сложных систем напрямую.
Динамическое (или многоэтапное) программирование предусматривает декомпозицию общей задачи на относительно небольшие и менее сложные подзадачи, с каждой из которых ассоциируется 1 управляемая переменная. Получение допустимого оптимального решения достигается при помощи набора рекуррентных процедур, связывающих отдельные этапы [48]. Однако, для анализа сложных информационных систем такой подход мало применим в силу того, что получаемые модели не обладают достаточной гибкостью и слишком сложны для анализа. Наиболее развитыми аналитическими методами для исследования информационных систем можно считать методы теории массового обслуживания, изложенные, например, в работах [25, 48]. Однако при практическом их применении также возникает ряд трудностей, обусловленных тем, что лишь в редких случаях обслуживающие системы, которые встречаются в реальных ситуациях, удовлетворяют условиям, заложенным в математические модели.
Эти трудности можно рассматривать с двух точек зрения: 1) степень сложности математического описания той или иной обслуживающей системы (наличие сетей, нестационарных распределений, детерминированных и вероятностных обратных связей); 2) гибкости математических моделей. В первом случае затрагивается вопрос о степени применимости математических моделей в конкретных системах массового обслуживания (СМО), тогда как во втором - речь идет о возможностях использования стандартных моделей для аппроксимации сложных обслуживающих систем [48].
Еще одной сложностью, характерной для всех аналитических моделей, является то, что они определяются на множестве элементов, не являющихся прямыми аналогами элементов исследуемой системы [54]. Так, модели теории массового обслуживания оперируют понятиями интенсивности входного потока, интенсивности обслуживания, однако в них нет прямых аналогов заявок и каналов СМО. Всё это создаёт дополнительные сложности для исследования, что делает этот аспект аналитического моделирования его явным недостатком.
В целом, можно сказать, что аналитическое моделирование больше нацелено на решение теоретических задач, получения упрощенного, абстрагированного представления исследуемой системы или явления. В том же случае, когда основной целью моделирования является именно более полный учет большого количества факторов, в том числе и носящих случайный характер, применение подобных методов едва ли является оправданным.
При имитационном моделировании реализующий модель алгоритм воспроизводит процесс функционирования исследуемой системы во времени, причем имитируются элементарные явления, составляющие процесс, с сохранением их логической структуры и последовательности протекания во времени, что позволяет по исходным данным получить сведения о состояниях процесса в определенные моменты, дающие возможность оценить характеристики исследуемой системы.
Все имитационные модели представляют собой модели типа «черного ящика». Это означает, что они обеспечивают выдачу выходного сигнала системы, если на ее взаимодействующие подсистемы поступает входной сигнал. Поэтому для получения необходимой информации необходимо осуществлять «прогон» имитационных моделей, а не «решать» их. Имитационные модели не способны формировать свое собственное решение в том виде, как это имеет место в аналитических моделях, а могут лишь служить в качестве средства для анализа поведения системы в условиях, определяемых экспериментатором [56].
В большинстве работ, где рассматриваются преимущества и недостатки имитационного моделирования [47, 49, 54, 56], отмечается, что основным его достоинством является возможность анализа более сложных систем без их значительного упрощения.
Сравнительные характеристики ИСБ
В рамках данной работы основой для построения имитационной модели будет выступать программный комплекс управления интегрированной системой безопасности «Бастион», созданный отделом разработки ассоциации «Электронные системы» (г. Самара) в 1997-2002 годах [А6, А7, А8].
Рассмотрим основные архитектурные особенности данной системы в контексте сравнения с несколькими продуктами других производителей. Для сравнения будут использоваться наиболее известные на российском рынке системы, по которым доступно наибольшее количество информации. К ним относятся отечественные системы «Inspector+» (ISS) [17], «Apacs» (ААМ Systems) [34, 36], «Кодос» (НІЖ «СоюзСпецАвтоматика») [18], а также комплекс ЕВІ западной компании Honeywell [69, 76].
Все перечисленные продукты относятся к классу открытых систем, то есть допускает использование произвольного набора оборудования систем безопасности при наличии для него специальной управляющей программы -драйвера, реализующего протокол сетевого обмена компьютера со специализированной подсистемой. Такая открытость, однако, поддерживается на разном уровне. В системах отечественной разработки (в том числе и в «Бастионе») предлагаются уникальные, специализированные интерфейсы для подключения драйверов, в то время как пакет Honeywell EBI, также обладая собственным интерфейсом, допускает использование и систем со стандартизованными протоколами взаимодействия (ОРС, AdvanceDDE, BACnet, Lon Works [69]). Отечественные продукты зачастую строятся вокруг некоторой базовой подсистемы - так, Apacs построен вокруг системы контроля доступа Apollo и не допускает использования сторонних СКУД. «Бастион» лишён такого недостатка.
Все перечисленные пакеты являются сетевыми приложениями, и работают в среде Windows 98/NT/2000/XP. Организация сетевых взаимодействий в отечественных продуктах также, как правило, строится на использовании закрытых технологий и протоколов. В продуктах же иностранного производства чаще встречаются концепции открытых протоколов на основе технологий промежуточного ПО, такого как DCOM [32, 40] или CORBA [45, 46, 101].
Концепция интеграции различается в разных продуктах. Системы «Бастион», «Inpector+», Honeywell EBI предоставляют возможности как программной, так и аппаратной интеграции. В первом случае взаимодействия между различными подсистемами формируются на программном уровне. Создание же аппаратной интеграции требует использования достаточно интеллектуальных сетей СКУД или ОПС, при этом аппаратные взаимодействия реализуются только внутри отдельной подсистемы. Пакеты «Apacs» и «Кодос» полагаются только на использование аппаратных средств, что ограничивает их возможности.
Принципиально важным свойством всех без исключения систем является то, что выполнение базовых функций реализуется только с использованием аппаратных средств и не зависит от того, работает ли в данный момент времени программное обеспечение. Набор функций, реализуемых программными системами в реальном режиме времени, примерно одинаков:
Во-первых, мониторинг событий системы. При этом предоставляются возможности как слежения за текущим трафиком событий (при помощи текстовых и голосовых сообщений), так и за состоянием объекта охраны в целом. Последняя функция реализуется при помощи графического представления планов территории объекта с размещёнными на ней обозначениями оборудования. В большинстве систем такие обозначения представляют собой пиктограммы, обладающие атрибутом «текущее состояние», которое отображается соответствующим цветом (в пакете «Бастион» - в соответствии с требованиями, изложенными в [53]). Следует заметить, что текущее состояние устройства часто зависит не только от последнего события, а от нескольких предыдущих событий (причём, необязательно последних) - то есть, для корректного отображения текущего состояния устройства необходимо анализировать предысторию. Планы территории могут быть растровыми («Бастион»), векторными (EBI Honeywell, «Кодос»), либо комбинировать два этих подхода («Apacs», «Inspector »).
Во-вторых, управление устройствами системы. Управление осуществляется с помощью контекстных меню пиктограмм или при помощи специальных панелей управления, реализуемых драйверами подсистем. В-третьих, аппарат взаимодействий между различным оборудованием или аппарат реакций на события. О различиях было сказано выше. И наконец, отличительной особенностью продуктов «Бастион» и Honeywell EBI является механизм анализа ситуаций, позволяющий при возникновении определённых условий сгенерировать дополнительное событие, которое, в свою очередь может вызвать цепь реакций в системе. В «Бастионе» все перечисленные функции выполняются ядром системы. К сожалению, информация о внутренней структуре систем других производителей не разглашается.
Методика оценки применимости комплекса «Бастион» на объекте охраны с известными параметрами
Рассмотренные в предыдущем параграфе примеры демонстрируют общий подход к анализу применимости моделируемой системы. Однако, для простоты в этих примерах весь цикл обработки событий выполнялся одним компьютером. Таким образом, остался неосвещённым вопрос о степени влияния конфигурации компьютерной сети комплекса на его производительность.
Опыт установки подобных систем говорит о том, что использование выделенных серверов для драйверов СКУД с большим количеством оборудования, а также для базы данных, увеличивает в итоге скорость обработки сообщений. Тем не менее, дать количественную оценку выигрыша от использования того или иного дополнительного оборудования можно только с использованием имитационной модели. Определение зависимости параметров системы от числа рабочих мест
Рассмотрим систему с теми же параметрами, что и в предыдущем параграфе, но со следующими изменениями: в сеть комплекса объединены несколько компьютеров, один из которых выполняет роль сервера базы данных и всех драйверов. Отображение ситуации на данном рабочем месте не ведётся. Остальные компьютеры используются в качестве мест наблюдения. Будем считать, что производительность всех процессоров одинакова. Проведём серию экспериментов, изменяя общее число рабочих мест в системе от 2 до 16.
СИМ Micro Saint обладает возможностью планирования серии экспериментов, выполняя ряд прогонов модели. Для каждого прогона можно задать свои параметры. В данном случае удобно число используемых компьютеров изменять в соответствии с номером прогона. Для этого в пользовательской функции SetModelParm необходимо установить число используемых компьютеров как: inProcCount:=run+l; (run - встроенная переменная (см. Прил. 2)). Для запрета отображения событий на сервере системы изменим условия в блоке принятия решений 51 (См. Рис. 13) следующим образом:
Зависимости минимального, среднего и максимального времени обработки событий, а также его среднеквадратичного отклонения, от числа рабочих мест в сети представлено на графике (Рис. 19). Диаграммы для наиболее загруженной очереди (перед блоком 31) в случае максимального
Как видно из приведённых результатов, время обработки сообщений резко сокращается при использовании нескольких компьютеров, что является прогнозируемым результатом, так как в этом случае используются элементы параллельной обработки. Наиболее существенные изменения наблюдаются при сравнении систем с 1 и 2 рабочими местами - среднее время обработки события при этом сокращается более, чем в 2,5 раза. Следует также заметить, что наблюдается некоторый рост этого времени с дальнейшим увеличением числа рабочих мест. Данный факт можно объяснить возрастающей нагрузкой на сервер базы данных, так как обращения к нему исходят от каждого клиента (при визуализации, см. Рис. 13).
Это также подтверждается графиком зависимости времени простоя процессора сервера базы данных от числа рабочих мест (Рис. 21).
Всё сказанное позволяет сделать вывод о том, что система обладает существенным запасом масштабируемости, выражающимся в способности использовать предоставляемые дополнительные ресурсы. Для систем с большим числом оборудования рекомендуется использование выделенного сервера базы данных и драйверов, не используемого для наблюдения.
Так как основная нагрузка в исследуемом процессе ложится на сервер базы данных, логично предположить, что использование в этих целях более производительного компьютера может положительно сказаться на скорости работы системы в целом. В то же время, согласно полученным результатам, использование процессоров клиентских компьютеров в обработке событий составляет не более 35%, что позволяет сделать вывод о возможности использования в этих целях менее мощных процессоров.
Определение необходимых изменений в имитационной модели
Недостатки в архитектуре системы, выявленные на этапе проведения имитационных экспериментов, могут служить основой для выработки оптимизированной структуры, в большей степени отвечающей предъявляемым к ней требованиям.
Основные выявленные недостатки связаны прежде всего с алгоритмом функционирования очередей в системе - это отсутствие зависимости времени обработки событий от их приоритета и отсутствие защиты от бесконечного роста длины очередей.
В существующем тракте обработки событий на всех этапах применяются очереди FIFO, что приводит к неоправданным задержкам в обработке высокоприоритетных сообщений. Очевидно, что использование приоритетных (сортированных) очередей может решить данную проблему. Однако, выявление приоритета того или иного события в рассматриваемом алгоритме происходит только после выполнения начального запроса к базе данных. Проведённые же в предыдущей главе эксперименты показали, что именно очередь перед этой задачей быстрее всего растёт при повышении трафика событий. Естественно, что окончательное значения приоритета может быть получено только таким способом, так как эти значения задаются инсталлятором системы на этапе первичной настройки. Поэтому, важной задачей является раннее выявление категории события (штатное, низкоприоритетная тревога, высокоприоритетная тревога). В большинстве случаев такое разделение возможно уже после синтаксического разбора сообщения драйвером.
Кроме учёта непосредственно приоритета события, необходимо принимать во внимание и его статус (онлайновое или устаревшее). Любое событие реального времени должно иметь приоритет в обработке по сравнению с устаревшим. В соответствии с таким подходом, можно записать выражение для определения приоритета элементов очереди сообщений в следующем виде: Так как данные вычисления будут использоваться многократно, удобнее оформить их в виде пользовательской функции GetPriority. Также, необходимо моделирование алгоритма начального разделения событий по категориям и последующего определения их точного приоритета. Следует заметить, что результаты запроса к БД может как повысить, так и понизить категорию события. Для моделирования данного алгоритма необходимо создать функцию SetTagCat (установка категории события), вызываемую в Ending Effect задачи 21: SYNTAX (См. Рис. 11), а также изменить функцию определения приоритета SetTagPrior. При 20%-ной вероятности изменения категории события в ту или другую сторону, что соответствует статистическим данным, и сохранении соотношений между событиями каждой категории, указанные функции примут следующий вид: Выражения Priority для всех очередей в модели, за исключением будут записываться как GetPriority;. Для очереди порядок выборки определяется категорией сообщения: Для реализации механизма защиты от неконтролируемого роста очередей, также необходим специальный алгоритм, так как простой отказ от обработки событий в рамках исследуемой системы является недопустимым. Наиболее оптимальным представляется создание механизма сокращённой обработки событий, применяемого в случае роста очереди. Такой механизм должен предусматривать для штатных событий выполнение минимума действий, избегая при этом потери информации о событиях. С такой позиции единственным необходимым действием в такой ситуации остаётся запись события в журнал и оповещение оператора о переходе на сокращённый режим обработки с возможностью, при снижении нагрузки, просмотреть необработанные сообщения. Дополнительно, так как основная нагрузка приходится на сервер БД, адекватным представляется изменение алгоритма записи журнала событий с серверного на локальный для всех событий. Реализация сброса локально сохранённых данных на сервер может использовать либо стратегию переноса данных по запросу пользователя, либо автоматизированный перенос при снижении нагрузки на сервер. Данный алгоритм находится за пределами рассматриваемой проблемы. С точки зрения структуры имитационной модели предложенный алгоритм ведёт к созданию дополнительных блоков в подсети MAIN_PROC. Результирующий вид сетевой структуры представлен на Рис. 31. Блок принятия решения задачи 310: Check DB Qsize отвечает за определение, по какому алгоритму должно быть обработано событие. В случае, если размер очереди 31 достиг порогового значения, применяется сокращённый алгоритм. Фиктивный блок 311 устанавливает специальный флаг (tagSkipped[tag]:=l), обеспечивающий корректную обработку события моделью.
