03 августа 2006
А. Омельянчук. Стандарты на интегрированные системы безопасности - взгляд разработчика. Часть 1.
А. Омельянчук
Системы безопасности №6, 2005
В настоящее время создание интегрированных систем безопасности (ИТСБ) довольно проблематично. Необходима разработка специальных стандартов, которые облегчат интеграцию разнородных систем, установят соответствующие интерфейсы взаимодействия оборудования и определят способы интеграции подсистем.
Стандартизация интегрированных систем безопасности, особенно после введения в действие Федерального закона "О техническом регулировании", вызывает много разных суждений.
Я хотел бы обратить внимание на то, что Закон разделил понятия стандартов на защищающие интересы государства и общества Технические регламенты, требования которых обязательны к выполнению, и стандарты (национальные и организаций), требования которых являются добровольными, что облегчает хозяйственную деятельность промышленных предприятий.
В применении к интересующим нас интегрированным системам безопасности технические регламенты, как и подобает документам уровня федерального закона, будут накладывать обязательные требования, гарантирующие минимально необходимую эффективность таких систем. В то же время, чтобы не препятствовать развитию технологий, технические регламенты не накладывают каких-либо ограничений на детали реализации. А потому для практических задач создания комплексных систем безопасности представляется насущной разработка ряда стандартов, облегчающих интеграцию разнородного оборудования и устанавливающих взаимоприемлемые интерфейсы взаимодействия, способы интеграции подсистем.
Производителю комплексных систем безопасности для облегчения повседневной работы необходимы стандарты, обеспечивающие требования по совместимости и взаимозаменяемости различных подсистем различных производителей.
Существующая ситуация
В настоящее время при наличии обоснованной необходимости интеграции некоторых подсистем (например, с целью уменьшить объем ежедневной рутинной работы сотрудников служб безопасности и соответственно уменьшить вероятность их ошибок) для конкретного объекта составляется задание на интеграцию конкретных подсистем, которое реализуется на данном конкретном объекте путем дорогостоящих длительных опытно-конструкторских работ, без гарантии успеха. Как правило, для других объектов это решение бесполезно, если только там не используется идентичный набор подсистем. Даже отличие версии подсистемы или состава оборудования в подсистеме может затруднить, если не сделать невозможным, перенос однажды полученного решения на другие объекты.
Обновление или замена одной из интегрированных подсистем делает проведенную работу бесполезной, вследствие чего возникает необходимость проводить разработки снова и снова.
Проблема: каждое решение по интеграции является уникальным.
Решение: стандарт на интерфейс взаимодействия подсистем должен освободить заказчика от необходимости каждый раз заново оплачивать проведение изыскательских работ и значительно облегчить перенос функциональных решений, отработанных на одном объекте, на другие аналогичные.
В настоящее время выбор оборудования для оснащения объектов регламентируется рядом ведомственных документов, требованиями общей или специальной (ведомственной) сертификации, а также поставленной оперативной задачей.
Проблема: существующими нормами не затрагивается "интегрируемость", то есть способность выбранных подсистем работать совместно.
Решение: стандарт на интерфейс взаимодействия должен освободить генподрядчика от необходимости тщательного анализа совместимости тех или иных подсистем, перенести вопрос о совместимости на этап предварительной сертификации.
В настоящее время генподрядчиком по оснащению объекта интегрированной технической системой безопасности (ИТСБ) неизбежно выбирается разработчик наиболее информативной технической подсистемы, автоматизированные рабочие места (АРМ) которой предполагается использовать как основные, ибо только разработчик реально сможет обеспечить необходимую интеграцию других подсистем в единую систему.
Проблема: заказчик ограничен в выборе генподрядчика, причем неизбежным следствием его выбора является согласие с предлагаемыми им решениями по выбору подсистем.
Решение: стандарт на интерфейс подсистем должен освободить заказчика от необходимости увязывать принятие решения о выборе основных АРМ с решением о выборе генподрядчика.
Кроме того, интеграция технических подсистем (ТПС), выполненная в результате отдельной опытно-конструкторской разработки, решает лишь наиболее насущные (поставленные в ТЗ) задачи и всегда отстает от жизни, от новых потребностей заказчика.
Предлагаемый стандарт должен обеспечить возможность широкой интеграции, превосходящей текущие потребности. Тогда новые идеи и решения будут легко доступны на каждом объекте.
Что предлагается стандартизовать
В состав ИТСБ, как правило, входят несколько ТПС, таких, как СКУД (система контроля и управления доступом), СОС (система охранной сигнализации), СОТ (система охранная телевизионная) и другие, причем технических подсистем каждой категории может быть несколько -разных версий или видов.
Основными задачами интеграции являются:
- обеспечение взаимодействия подсистем между собой по заранее принятым правилам;
- облегчение работы операторов за счет исключения случаев повторного ввода данных, дублирования команд на разных подсистемах, облегчения восприятия и анализа данных, единообразно отображаемых в едином месте.
В целях анализа можно выделить следующие элементы ИТСБ:
- АРМ оператора;
- сервер автоматизации (обеспечивающий генерацию управляющих команд для одной ТПС после получения сообщения о событии в другой);
- отдельные технические подсистемы.
С точки зрения взаимодействия с ТПС остальные компоненты (и АРМ оператора, и сервер автоматизации) выглядят одинаково - получают сообщения о событиях и иногда выдают управляющие команды. Поэтому мы относим их к общей категории УПС (управляющих подсистем).
Таким образом, выявляется объект стандартизации - интерфейс между всеми ТПС и УПС.
В настоящее время в качестве УПС выступают, как правило, некоторые функциональные модули одной из подсистем. Вполне возможна ситуация, когда в разных обстоятельствах разные ТПС выполняют функции УПС, принимают сообщения о событиях от других ТПС и выдают им управляющие команды. Тем не менее в любом взаимодействии ТПС всегда можно проследить четко выраженные особенности - одна ТПС выполняет функции УПС, обеспечивая принятие решений или взаимодействие с оператором-человеком, принимающим решения.
При таком подходе подсистемы предполагаются достаточно самостоятельными, способными к автономной работоспособности (что требуется нормативными документами некоторых ведомств).
В терминологии, введенной Systems Integration Industry Group, такие подсистемы называются не интегрированными, а взаимодействующими. Заодно отметим, что данное SIIG определение интегрированных систем (критерием "интеграции" считается использование единой базы данных) по опыту работы с ИТСБ нам кажется неуместным. Даже в автономных (неинтегрированных) подсистемах нередко используются несколько разных бах данных - на уровне АРМ-конфигуратора, на уровне сервера автоматизации, на уровне отдельного контроллера.
Это оправдано не только требованиями повышения живучести (для чего должно отсутствовать единое центральное звено, выход из строя которого нарушает работу всей системы), но и общими принципами объектно-ориентированного проектирования (инкапсуляция данных внутри объекта, непосредственно работающего с этими данными).
УПС (управляющая подсистема) ИТСБ
В этом разделе более подробно описываются функции и состав УПС, не с целью выдвижения каких-то требований к реализации УПС, а лишь с целью описать ее функции, работу и впоследствии постараться описать требования к предполагаемому стандарту на интерфейс взаимодействия УПС-ТПС.
Итак, еще раз: УПС ИТСБ - это аппаратно-программный комплекс средств интеграции нескольких отдельных ТПС. В состав УПС входит комплекс вычислительной техники, программного обеспечения, сети передачи данных и вспомогательного оборудования, предназначенный для распределенного управления ИТСБ как автоматического, так и с участием операторов.
Существенными составными частями УПС являются АРМ операторов, особенно АРМ оперативного управления - основные АРМ ежедневного (как правило, круглосуточного) обслуживания. В составе ИТСБ может находиться несколько УПС различного назначения, хотя для облегчения работы операторов и другого персонала службы безопасности рекомендуется использовать однотипные АРМ для всех рабочих мест сходного назначения.
На УПС ИТСБ возлагается реализация следующих двух основных функций:
1. Обеспечение единого пользовательского интерфейса основных АРМ (АРМ дежурного оператора, АРМ бюро пропусков). Это означает, что данные АРМ в идеале должны иметь один основной экран и, хотя иногда и могут состоять из нескольких компьютеров, обязательно должны иметь согласованный сходный пользовательский интерфейс. Перенесение отдельных функциональных задач АРМ на несколько мониторов в составе АРМ может быть обусловлено лишь задачами оптимизации эргономических характеристик рабочего места, но никак не ограничениями, накладываемыми разнородными ПО.
2. Автоматизация функций управления ТПС. Это означает, что ПО УПС ИК СФЗ должно обеспечивать возможность настройки и автоматического выполнения алгоритмов реакций на события, происходящие в любой ТПС. При этом в процессе выполнения алгоритмов могут осуществляться воздействия на любую другую ТПС. Типичный частный случай процесса автоматизации взаимосвязи - так называемый "глобальный антипассбэк", то есть извещение системы СКУД внутренней зоны о том, что тот или иной человек вошел или вышел с территории через СКУД внешнего периметра.
АРМ оперативного управления
АРМ, обеспечивающее функции оперативного контроля и управления системой или ее частью (как правило, территориально и/или функционально выделенной, например, в рамках отдельного здания либо в отношении внешнего периметра всего объекта). К числу АРМ данной категории относятся, в том числе АРМ дежурного оператора, АРМ начальника Службы безопасности, АРМ дежурного КПП.
Основными требованиями к АРМ данной категории являются:
- обеспечение оперативного отображения всех предназначенных для данного оператора событий в удобном для оператора виде, как правило, на графическом плане объекта с возможностью выдачи оператору подсказок по его дальнейшим действиям и регистрации реакции оператора (как минимум, восприятия оператором события);
- обеспечение возможности оперативно вмешиваться в работу системы (в том числе менять настройки системы) в целях устранения предполагаемых нештатных ситуаций, в том числе связанных с поломками аппаратуры, некорректным поведением персонала или изменениями режима работы объекта по внешним (технологическим) причинам.
К АРМ дежурного оператора иногда предъявляются особые требования по защите информации, поскольку отличающиеся по настройкам или по конфигурации АРМ этой категории могут устанавливаться на пультах дежурных инспекторов КПП, на пультах управления (основном и резервном) войсковой части (или военизированной охраны), на пультах управления (основном и резервном) службы безопасности. При этом полномочия различных операторов в отношении получения информации и управления системой существенно различаются.
Рис. 1. Система "одна УПС - много ТПС"
Рис. 2. Использование в качестве УПС одной из ТПС
Кроме того, АРМ категории "АРМ дежурного оператора" должны иметь варианты исполнения (настройки), позволяющие оптимизировать те или иные функции в зависимости от конкретного назначения АРМ, например функции контроля прохода персонала через КПП или функции общего контроля системы.
АРМ бюро пропусков АРМ
АРМ бюро пропусков АРМ, обеспечивающие функции ввода, редактирования и хранения списка (электронных) пропусков; ввода, редактирования и хранения персональных идентификационных сведений о физических лицах - абонентах ИК СФЗ (сотрудников, посетителей, представителей подрядчиков и др.); ввода идентификационных параметров о единицах техники - абонентах ИК СФЗ (автотранспорт, железнодорожный транспорт и др.); определения полномочий абонентов системы в рамках СКУД. В число функций АРМ данной категории входит ввод первичных данных, регистрация биометрических данных, подготовка (печать) и выдача пропусков, присвоение отдельным лицам категорий по полномочиям.
Существенным дополнительным требованием является многоуровневая процедура согласования полномочий. Хотя на практике вполне допускается проведение процедуры согласований в рамках бумажного документооборота (без автоматизации средствами УПС ИТСБ).
Сервер автоматизации
Функциональный компонент УПС, обеспечивающий передачу в реальном времени управляющих сигналов для некоторых ТПС, предварительно настроенных на определенные события в этих или других ТПС.
Такой сервер должен гибко настраиваться на этапе конфигурирования, причем обеспечивать прием, анализ и выдачу специфических для любой ТПС сообщений. Для задания алгоритмов работы такого сервера могут применяться простейшие табличные формы (это наиболее распространено в автономных подсистемах).
Иногда для задания алгоритмов функционирования сервера автоматизации допускается писать развернутые программы на одном из простых языков программирования: Visual-Basic, JavaScript и т.д.
В то же время следует отметить, что в мире (в смежных областях) существуют и широко применяются стандартные скриптовые языки описания, а именно ФБД (язык функциональных блоковых диаграмм) и смежные языки серии IECI131, применяемой для описания процессов автоматизации производства, а также язык BPEL4WS и сходные с ним, используемые в системах автоматизации управления предприятием.
Особенности УПС в отличие от ТПС
На объекте, как правило, устанавливается несколько ТПС различных производителей, обеспечивающих защиту различных участков объекта. Как правило, объективные технические и экономические причины заставляют потребителей выбирать разное оборудование для оснащения периметра объекта и внутренних помещений, для больших и для малых зданий и, конечно, разное оборудование для систем СКУД, СОС, СОТ или СУДОС (система управления доступом и охранной сигнализации). При этом каждая подсистема имеет собственную ССОИ (систему сбора и обработки информации), несовместимую с другими.
В то же время в целях унификации пользовательского интерфейса предпочтительно на всех основных рабочих местах операторов использовать одинаковые АРМ одной УПС. Поэтому распространенным сценарием является "одна УПС- много ТПС".
Вообще, различных ТПС, пригодных для применения на объектах, достаточно много (даже при условии жесткого ведомственного отбора необходимо иметь выбор из минимум 2-3 вариантов ТПС каждого типа: СКУД, СОС помещений, СОС периметра, СОТ). Дополнительно в качестве отдельных ТПС имеет смысл рассматривать вспомогательные подсистемы, например подсистемы бесперебойного электроснабжения, связи, оповещения, компьютерное сетевое оборудование, систему освещения и т.д. При этом в качестве УПС также достаточно 2-3 вариантов разных производителей.
Таким образом, общее количество ТПС значительно превышает общее количество УПС. Кроме того, разработками УПС занимаются, как правило, специалисты по компьютерному ПО, организации, имеющие мощный штат таких специалистов и использущие ПО УПС на мощных компьютерах общего назначения.
В то же время ТПС, как правило, производят организации, специализирующиеся в области специальных разделов техники (например, в области технологий датчиков обнаружения) и имеющие штат специалистов, ориентированный на разработку встроенных электронных устройств. Программное обеспечение ТПС большей частью исполняется на встроенных микропроцессорах (микроконтроллерах) с невысокой вычислительной мощностью, расположенных в контроллерах сбора и обработки информации, пригодных для работы в жестких внешних условиях, для монтажа в ограниченном пространстве, для долгой необслуживаемой работы в труднодоступных местах.
В целом указанные особенности УПС и ТПС приводят к рекомендации при разработке стандарта по возможности снижать требования к ТПС пусть даже ценой усложнения и повышения требований к УПС.
Использование в качестве УПС одной из ТПС
Фактически в качестве УПС ныне используется одна из ТПС, действующих на объекте, как правило, это СКУД или СУДОС, имеющая наиболее развитые АРМ и средства автоматизации. Ее АРМ используются в качестве основных органов контроля и управления. При этом возможна ситуация, когда на разных функциональных рабочих местах в качестве основных АРМ используются различные ТПС.
Такое положение не только приемлемо, но и вполне разумно в будущем - вероятно, УПС нередко будут разрабатываться и выпускаться с ориентацией на конкретные ТПС и поставляться в комплекте с соответствующей ТПС.
При этом различные производители, вероятно, будут лучше реализовывать различные функции УПС и соответственно пользователи предпочтут на разных рабочих местах АРМ УПС разных производителей.
Таким образом, следует предусматривать возможность совместной работы нескольких УПС, а также осознавать, что весьма вероятна поставка УПС совместно с ТПС, в том числе неразрывно, в виде единой системы, реализующей как функции УПС, так и функции ТПС. При этом возможно, что взаимодействие между УПС-компонентом и ТПС-компонентом такого комплекса не будет ограничиваться средствами, описанными в стандарте (не будет происходить исключительно через интерфейс УПС и интерфейс ТПС, предоставленные для внешнего использования).
Кроме того, следует подчеркнуть, что возможна и "взаимная интеграция" двух ТПС, когда каждая из них выступает для другой в качестве УПС. Ввиду функциональной изолированности двух сторон интерфейса управления такой вариант вполне описывается ситуацией "двух независимых интерфейсов". Следует только отметить, что во избежание образования замкнутых колец управления такие ТПС должны иметь возможность (желательно настраиваемую) не предоставлять "импортированные из управляемой ТПС" ресурсы в качестве доступных для управления извне.
Интерфейс взаимодействия ТПС и УПС
Следует подчеркнуть, что интерфейс взаимодействия УПС и ТПС включает в себя форматы данных и процессы обмена данными как во время совместной работы, так и во время первоначального установления взаимодействия, включая форматы и способы представления данных, описывающих ТПС.
Дело в том, что не представляется возможным жестко стандартизовать форматы и способы передачи данных, пригодные для всех видов ТПС. Иначе стандарт немедленно стал бы тормозом для развития технологий, препятствием для появления новых понятий. Именно поэтому в понятие "стандарт на интерфейс взаимодействия ТПС и УПС" предлагается в первую очередь включать формализованные, стандартизованные способы описания особенностей конкретной ТПС.
Уровни реализации интерфейса ТПС-УПС
В большинстве практических случаев невозможно требовать, чтобы все производители в равной степени следовали одному стандарту. Для кого-то требования стандарта будут невыносимо сложными (реализовать требования стандарта окажется слишком дорого), а для кого-то - слишком простыми (в рамках стандарта не удастся реализовать многие полезные особенности данной подсистемы).
Вероятно, следует рассматривать понятие "уровни реализации интерфейса" - наборы требований, при выполнении которых можно утверждать, что ТПС соответствует соответствующему уровню.
Уровни подразделяются на:
- базовый, предназначенный для работы с любой УПС и позволяющий реализовать все основные функции;
- пониженные, не позволяющие реализовать некоторые функции без применения дополнительных промежуточных средств от сторонних разработчиков.
Например, базовый уровень может требовать поддержку шифрования канала передачи сообщений, а один из сниженных может не требовать. В таком случае для реализации защиты канала связи УПС - ТПС придется непосредственно рядом с сервером ТПС установить дополнительное устройство, шифрующее весь трафик. Повышенные (дополнительные) функции -описанные в стандарте требования, необязательные к выполнению, удовлетворение которым в некоторых случаях может повысить эффективность работы системы в целом.
Например, создатели ТПС могут реализовать управление распределением полномочий операторов средствами ТПС, поскольку данная подсистема может более корректно разобрать семантику отдельных команд, хотя базовый уровень предполагает, что задача распределения прав операторов - внутренняя задача УПС. Следует отметить, что не всякая УПС сможет воспользоваться дополнительными функциями ТПС.
В любом случае предполагается сначала установить базовый уровень, а потом уже разработать возможные пониженные или повышенные уровни. Непосредственно предложения по стандартизации требований будут изложены в следующем номере журнала.
Об авторе: А.М. Омельянчук, технический директор ЗАО "Компания Безопасность"
Источник: Системы безопасности
