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

Эффективная СКУД на крупном НПЗ. Опыт завода "Славнефть-ЯНОС" (Ярославль)

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

Эффективная СКУД на крупном НПЗ
Опыт завода "Славнефть-ЯНОС" (Ярославль)

Организация СКУД на крупных НПЗ и вообще режимных объектах - задача комплексная. Есть множество технологий, множество подходов и способов ее решения. Но опыт и практика, как известно, расставляют все по своим местам. О практике построения СКУД с точки зрения заказчика мы поговорили с Михаилом Румянцевым, начальником отделения технических средств управления защиты ресурсов ОАО "Славнефть-ЯНОС", одного из крупнейших российских НПЗ
М.Н. Румянцев
Начальник отделения технических средств,
управление защиты ресурсов ОАО
"Славнефть-Ярославнефтеоргсинтез"

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

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

– С вашей точки зрения, какие задачи должна решать эффективная СКУД?
– Самая основная задача СКУД – опознавание по критерию "свой/чужой". Это чаще всего и востребовано на большинстве предприятий в = первую очередь. На первый взгляд, простая задача. Но вы представьте себе предприятие со штатом в несколько тысяч сотрудников, транспортным парком, производственными территориями, посменными и скользящими рабочими графиками, несколькими десятками, а то и сотнями подрядных организаций, у которых есть свой транспорт. Все это структурировать и взять под контроль, но не мешать работать – вот основная задача.

А дальше уже идет следующий шаг: насколько менеджмент предприятия готов использовать данный инструмент в управлении производством, персоналом, смотреть и сравнивать эффективность при разных вариантах организации потоков людей и транспорта. Здесь уже начинается так называемый этап красивостей СКУД: возможности гибкой и оперативной переконфигурации прав доступа в масштабе предприятия, работа со сменными и скользящими графиками, автоматизация подготовки и выдачи пропусков, интеграция с АСУ и обмен данными по учету рабочего времени и т.д. Но первичная задача – это опознавание "свой/чужой".

– Необходимый набор СКУД современного режимного предприятия – что сюда входит? Без чего обойтись нельзя?
– Необходимого набора нет. Если вы имеете в виду оборудование, турникеты, шлагбаумы, считыватели – это, на самом деле, вопрос второй. Бывает оборудование хорошее, бывает не очень – смотря под какую задачу. Но суть в том, что набор оборудования – это еще далеко не система. Установкой оборудования задача не решается. Можно поставить красивые турникеты, хорошие шлагбаумы. Но если решение о пропуске принимается тем же человеком, который делал заявку на пропуск, и который не обладает необходимой информацией о том, кого пропускать можно, а кого нельзя, то такая система ничем не отличается от охранника на КПП, которому предъявляли бумажный носитель. Человеческий фактор здесь никак не исключен.

Поэтому необходимый набор СКУД – это прежде всего идеология, понимание того, как все должно работать. И первым пунктом в ней – алгоритм выдачи пропуска. У нас на предприятии в этом вопросе следующий подход: во-первых, работник службы безопасности не знает и не может знать в силу объемности предприятия, кто необходим на объекте, кого нужно пропускать. Но работник службы безопасности знает, кто не должен появляться на заводе. Во-вторых, должно быть разделение полномочий – люди, которые создают заявку на пропуск и являются инициаторами, не могут единолично принимать решение о пропуске. Это решение принимают два человека – инициатор заявки, к которому идет посетитель, и руководитель службы безопасности, который проверяет данного человека и данную организацию на совершение каких-то неправомерных действий в прошлом на территории этого предприятия, и затем утверждает поступившую заявку в электронном виде.

Это один из примеров того, каким образом идеология определяет параметры и характеристики системы. Определитесь с этим – остальное не составит труда.

– А что касается обработки событий на точках доступа, на КПП, допустим, при пропуске человека или автомобиля?
– Это в общем-то уже частности, потому что на данном этапе ключевые решения уже приняты. Но все-таки обработка событий крайне важна. При построении СКУД необходимо теоретически учитывать возможность любых ситуаций. И на практике надо создать такой инструмент, который бы этим представлениям удовлетворил. Могут быть такие ситуации, когда человек приложил пропуск, но отказался от прохода. Или, например, машина подъехала, ее номер высветился в качестве идентификатора и дано право на проезд, а водитель решил не заезжать. То есть инструмент должен подразумевать различные ситуации, даже такую, когда нужно пропустить человека без идентификатора, в том числе по решению охранника, должностного лица. Если все эти ситуации учтены, тогда из СКУД можно будет получить максимум информации: кто, когда проходил, кто инициировал проход – и видеофрагмент посмотреть или весь путь по объекту проследить. А то ведь бывает по-разному. До смешного. Мы видели и такие системы, когда стоял волшебный турникет со считывателем, с рабочим местом охранника на КПП, с программным обеспечением, а рядом с турникетом была цепочка, преграждающая проход, и тех, у кого не было пропуска, охранник пропускал через эту цепочку. Вот вам и идеология, и алгоритмы обработки событий.

– Распространенная ситуация: на разных объектах предприятия уже есть несколько разных СКУД, построенных в разное время. Они не взаимодействуют друг с другом. Если в результате все-таки хочется выйти на единое решение с единым бюро пропусков, стоит ли их интегрировать как-то или оптимальнее перестроить все под какую-то одну систему?
– Если работает несколько разных СКУД и есть задача объединить их в единое решение, то надо определиться с несколькими моментами.

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

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

– Как устроена СКУД на вашем объекте?
– Структурно наша СКУД состоит из трех уровней. Нижний – это уровень турникетов, шлагбаумов, исполнительных механизмов и контроллеров, которые ими управляют. Средний – это сервер ССОИ, который обрабатывает информацию, визирует ее, держит базу данных по пропускам и обеспечивает передачу информации на верхний уровень в АСУ. А верхний – это бюро пропусков, откуда формируются права доступа, рабочие графики и куда поступает информация по учету рабочего времени и нарушений. Физически на заводе несколько десятков контрольно-пропускных пунктов – как пешеходных, так и транспортных, которые входят в интегрированную систему безопасности. В СКУД все точки доступа синхронизированы, на автомобильных КПП реализовано распознавание номеров а/м и другие полезные возможности. ССОИ решает все задачи по управлению работой КПП, обмену информацией, аналитике и интеграции с другими подсистемами. В 2008 г. наша система была награждена Премией ЗУБР как лучшее решение в классе крупных интегрированных систем безопасности.

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

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

Следующая система, с которой необходимо интегрировать СКУД, – видеонаблюдение. Это позволит привязать факт прохода к видеоархиву и соответственно поднимать видеособытие не по времени прохода (когда это было?), а по факту прохода и поднесению пропуска. Что существенно упрощает поиск и работу с информацией.

Еще возможна интеграция с системами ОПС, когда в СКУД при пожаре или возгорании приходит команда открыть турникеты, проезды – режим "антипаника". Это основные вещи. И все это программируется, если позволяет функциональность отдельных подсистем и главным образом функциональность ССОИ. Мы интеграцию активно используем и наращиваем.

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

Что касается транспорта, то тут задача немного сложнее. У нас идентификатором является государственный номер автомобиля, который распознается при подъезде к КПП. Предварительно на машину должна быть оформлена заявка, прошедшая утверждение, а также иметься путевой лист с указанием фамилий водителей, которые могут посменно на ней ездить. Когда машина приезжает на предприятие, водитель берет путевой лист, свои права и идет в бюро пропусков, где работник в системе отмечает, кто сегодня за рулем, и проверяет права доступа а/м. Дальше на КПП все по процедуре: машина подъезжает, номер распознается, в СКУД по этому номеру поднимается карточка а/м, в которой указана марка, тип, название организации, которой принадлежит автомобиль, и фотография с момента первого въезда ее на территорию для того, чтобы нельзя было подменить номер. Ну, и права доступа. Затем охранник получает на рабочем месте информацию о правах доступа автомобиля и водителя, который за рулем, и проводит досмотр транспорта и документов, удостоверяющих личность. Это для ситуаций, когда автомобиль редко приезжает
на предприятие. Для регулярного транспорта действуют постоянные пропуска на автомобиль с такой же процедурой на КПП. Не первый год такие подходы работают и показали свою эффективность.

– А как вы относитесь к биометрии? Есть ли на сегодняшний день резон в том, чтобы применять на крупных объектах эту технологию?
– Нужно исходить из целесообразности. Сколько времени требуется, чтобы, например, корректно считать сетчатку глаза или отпечаток пальца, учитывая, что руки могут быть грязными, температура может быть низкой и т.д. И сколько времени необходимо, чтобы карточку приложить? А если нужна высокая пропускная способность, как у нас, например? Ответ простой – применение биометрии пока что не очень оправдано, по крайней мере на предприятиях нашего профиля. Или же это должна быть крайне отточенная и отработанная технология. А то мы слышали и о таких случаях, когда поставили биометрический считыватель на режимную зону, и потом туда сотрудники не могли попасть по 15–20 минут, потому что зимой руки мерзнут и пока не отогреешь, система не распознает ничего. Это не означает, что в перспективе технологии не станут более зрелыми. Но на сегодня сфера применения этих технологий довольно узкая.

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

– Ну, и наконец вопрос, который интересует многих заказчиков. Каким образом можно снизить зависимость заказчика от разработчика? Какой подход или тактика здесь эффективны?
– Подход очень простой. Надо самому быть активным постановщиком задач. То есть заказчик не должен отдавать на откуп разработчику такие вещи, как техническое задание, алгоритмы прохода и т.д. Идеологию, в общем. Идеально будет работать та система, которая заказчику понятна и которая удовлетворяет всем его внутренним документам. А для этого ему необходимо самому построить концепцию – пусть и совместно с разработчиком, но самому. Тогда получается эффективная работа. Если же заказчик сам не знает, что ему нужно, а точнее, как все должно быть в результате, то не стоит надеяться, что кто-то выполнит эту часть работы за него. В общем, позиция заказчика должна быть активной, тогда и результат будет соответствовать ожиданиям.

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

  Автор

Румянцев М. Н.

Румянцев М. Н.

Начальник отделения технических средств, управление защиты ресурсов ОАО "Славнефть-Ярославнефтеоргсинтез"

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

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