Контакты
Подписка
МЕНЮ
Контакты
Подписка

Система безопасности и АСУ. Как минимизировать риски при интеграции двух систем?

В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Система безопасности и АСУ
Как минимизировать риски при интеграции двух систем?

Системы безопасности и АСУ традиционно существовали отдельно друг от друга. В последние годы, особенно на крупных предприятиях с высокими требованиями к защищенности и режиму, возник заметный интерес к их интеграции
А.В. Скворцов
Начальник отдела исследований и
разработки ООО "ПСЦ "Электроника"

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

В чем польза?

Представьте себе предприятие со штатом 5 тыс. сотрудников. Например, нефтеперерабатывающий завод. Есть промышленная АСУ, где ведется учет и планирование ресурсов. Есть довольно мощная система безопасности (СБ), которая обеспечивает защищенность объекта. И все бы хорошо, если бы людям, работающим с АСУ и с системой безопасности, не требовалось как-то обмениваться данными друг с другом. В АСУ задаются параметры того, как это должно быть. Системой безопасности контролируется соблюдение этих параметров. Практика показывает, что без взаимодействия не обойтись.

Такое взаимодействие касается многих вопросов, в том числе:

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

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


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

Без сомнения, это решит задачу. На этапе практической реализации интеграции СБ и АСУ возникает ряд трудностей: организационных и технологических.

Что мешает?

На большинстве предприятий системы безопасности и АСУ находятся в ведении разных подразделений, на разных ветках оргструктуры. Исключения есть, но не частые. В основном это две независимые или слабосвязанные области. Какие проблемы возникают в связи с таким разделением?

  • При проектировании каждой из систем не всегда учитываются перспективы последующей интеграции. Это касается и общей концепции взаимодействия, и протоколов обмена данными, и баз данных. При эксплуатации расхождения наслаиваются друг на друга, а результатом становится ситуация, когда все, что находится между системами, делается руками – со всеми пагубными влияниями человеческого фактора.
  • Порой не учитываются и вполне объективные интересы другой стороны. Например, распространена ситуация, когда существующая транспортная сеть, созданная, к примеру, для АСУ, не имеет дополнительного ресурса, который может использовать СБ. Бывают и обратные ситуации. В итоге под каждую систему создается своя транспортная сеть. Для предприятия это двойные затраты.
  • При эксплуатации систем возникают конфликты и взаимные претензии, в которых каждая служба видит источник проблемы в коллегах. Особенно в нештатных ситуациях (например, вирус в сети, замедление подготовки отгрузочных документов и т.д.).
  • Ввиду того что системы разные и задачи у подразделений разные, штат каждого из данных подразделений укомплектован специалистами разной специализации. В подразделении, обслуживающем системы безопасности, это зачастую инженеры. В подразделении, обслуживающем АСУ, – программисты. При отсутствии задач, требующих регулярной совместной работы, специалисты не учатся общаться "на одном языке".

Не менее критичны и технологические трудности интеграции:

  • Несовместимость СУБД АСУ и СУБД системы безопасности. Бывает, что на предприятии за стандарт принята СУБД Oracle, а СБ работает на MS SQL или какой-то своей собственной СУБД. Из-за этого возникают существенные затруднения при интеграции систем: сложно формировать запросы к БД, необходимо закупать дополнительные лицензии на СУБД, поддержка двух СУБД создает необходимость держать в штате сотрудников, сопровождающих каждую из них (а чаще всего это разные люди).
  • Конфликт на почве использования разных систем защиты: антивирусное ПО, Firewall и т.д. Одно из основных требований к системе безопасности – быстродействие. А различные средства защиты при установке на серверах и рабочих станциях значительно снижают его. Поэтому производители ПО ССОИ для систем безопасности не рекомендуют ставить средства защиты, и при интеграции систем этот вопрос требует детальной проработки.
  • Разные подходы к фиксации однородной информации. В программных платформах СБ и АСУ, как правило, используются различные правила заполнения полей и форматы данных для фиксации однородной информации. Это затрудняет интеграцию. Простой пример: в АСУ на карточке пользователя Ф.И.О. заводится в разных полях (фамилия, имя, отчество), а в системе безопасности – в одном поле. Подобных примеров довольно много.
  • Технологические ограничения платформ. Например, в АСУ могут гибко задаваться параметры рабочих графиков. При этом далеко не все решения для систем безопасности позволяют реализовать гибкие параметры рабочих графиков или какие-то другие правила с высокой вариабельностью. Таким образом, если на крупном предприятии подразделения работают сменами, по скользящим графикам, то системе безопасности с подобным ограничением будет крайне сложно в автоматическом режиме назначить права доступа и временные интервалы картам доступа на основании данных АСУ. А если такая работа выполняется вручную, то это сложно назвать интеграцией автоматизированных систем.

Это лишь некоторые примеры узких мест, которые могут возникать при интеграции СБ и АСУ. Однако это вовсе не означает, что задача невыполнима.

Варианты решения

Теоретически идеальным вариантом интеграции является полное, 100%-ное объединение систем на основе единой базы данных. А точнее их исходное неразделение. Тогда и технические проблемы снимаются, и организационные трудности разрешаются без усилий. Но очевидно, что это сегодня исключительно теоретический вариант. АСУ не касается вопросов инженерно-технической безопасности и не поддерживает оборудование и другие элементы систем безопасности.


Кроме того, АСУ не обеспечивает необходимой производительности в реальном времени. А это одна из основных характеристик системы безопасности. Есть препятствующие факторы и со стороны разработчиков систем безопасности.


Вполне эффективным и достаточным для реальной работы на объекте является вариант частичной интеграции систем. Задачи здесь такие:

  • обеспечить синхронность данных о лицах, автомобилях, материальных ценностях и присвоенных им идентификаторах системы безопасности;
  • обеспечить корректное присвоение пропускам системы безопасности прав доступа и временных интервалов, заданных в АСУ (для физических лиц и автомобилей);
  • обеспечить корректный сбор данных и передачу их в АСУ для формирования табелей, отчетов, зарплатных ведомостей, отгрузочных ведомостей и путевых листов автотранспорта;
  • гарантировать корректную передачу данных о параметрах рабочих графиков, путевых листов и маршрутов от АСУ в систему безопасности (а точнее, в СКУД).

Каким образом этого можно добиться, принимая во внимание интеграционные сложности, рассмотренные выше?

  1. Во-первых, за счет активной совместной работы служб на уровне руководителей и исполнителей (хотя бы на этапе проектирования), а также за счет увеличения совместных горизонтов планирования работ по развитию систем и инфраструктуры.
  2. Во-вторых, обе системы необходимо проектировать и строить в рамках единой ИТ-инфра-структуры, учитывая технологические интересы обеих служб (ИТ/АСУ и безопасности). Прежде всего при выборе СУБД, формулировании требований к транспортной сети, к защите данных.
  3. В-третьих, системы должны быть объединены в рамках единой сети, но разделены логическими сегментами. Или можно разделить системы физически, но объединить каналом на уровне одного-двух серверов. Первый вариант экономичнее, второй – надежнее.
  4. В-четвертых, необходимо выбрать одну СУБД, на которой будут работать обе системы. Это существенно снизит стоимость владения системами за счет сокращения затрат на лицензии и на сопровождение систем.
  5. В-пятых, следует обеспечить взаимоувязку операций в АСУ и в системе безопасности. С синхронизацией записей, чтобы исключить дублирование операций и двойной ввод данных. С возможностью корректировок в ручном режиме (с персонализацией) для обеспечения достоверности данных (например, данных по учету рабочего времени).

Залог успешной интеграции

Несмотря на то что условий успешной интеграции обозначено немного, каждое из них требует и от разработчика и от заказчика объективной оценки ситуации, внимательного учета всех рисков и стратегического подхода в постановке задач для совместного проекта. Результатом такой интеграции будет надежное и устойчивое решение, которое не только обеспечит эффективное взаимодействие двух крупных систем, но и поможет объединить в одну команду профессионалов разного профиля – как в сфере систем безопасности, так и в области ИТ/АСУ. В итоге выиграют все.

Таков опыт нашей компании и наших уважаемых заказчиков.

Опубликовано: Журнал "Системы безопасности" #2, 2011
Посещений: 9413

  Автор

Скворцов А. В.

Скворцов А. В.

Начальник отдела исследований и
разработки ООО "ПСЦ "Электроника"

Всего статей:  8

В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик  |  К списку авторов  |  К списку публикаций