|
НовостиСИГМА-группа компанийНаукаПроизводствоСтатьи и публикацииСертификатыЛицензииНаградыОтзывыКонтактыЦентральный офисСеверо-ЗападВакансииЛоготипы
| |
|
| |
|
| |
|
| |
Пользовательский интерфейс:тенденции и критерии выбора
Редакция журнала «Алгоритм безопасности» поднимает тему требований к пользовательским интерфейсам интегрированных систем безопасности.
Под пользовательским интерфейсом в нашем материале мы принимаем именно графическое отражение работы системы. Несмотря на многообразие задач, стоящих перед разными объектами для обеспечения безопасности, список функций операторов и администраторов систем безопасности практически одинаков. А пользовательские интерфейсы программных продуктов разных производителей не повторяют друг друга. Попробуем разобраться! Ведущие специалисты производителей системных продуктов ответили на 7 вопросов редакции.
В круглом столе приняли участие:
Волкинд Яков Григорьевич, директор филиала ITV | AxxonSoft в Санкт-Петербурге
Гинце Алексей Александрович, директор по связям с общественностью ААМ Системз
Горбунова Юлия Сергеевна, старший менеджер по развитию бизнеса (Россия и СНГ) Milestone Systems
Дьячков Дмитрий Ильич, директор по развитию ООО «ПЕТЕРСОФТ»
Желудков Роман Анатольевич, ведущий специалист по продукту департамента «Автоматизация и безопасность зданий» компании «Сименс»
Корноухов Виталий Валерьевич, начальник отдела технической поддержки ООО «ЕС-ПРОМ»
Кузнецова Анна Игоревна, программист ПСЦ «Электроника»
Лёвин Сергей Николаевич, главный конструктор ГК «Сигма»
Орлов Станислав Николаевич, исполнительный директор ООО «НПФ «Полисервис»
Разумков Артем Владимирович, генеральный директор Macroscop
Садов Антон Николаевич, главный технический специалист компания «Девлайн»
1. Какова роль пользовательского интерфейса в принятии заказчиком решения о приобретении системы? На что в первую очередь обращает внимание заказчик? Насколько целесообразно использовать 3й-представления объекта охраны, 3D-walkthrough анимацию и т. п.?
Лёвин С. Н. (ГК «Сигма»)
Часто пользовательский интерфейс, который является лицом программного продукта, играет определяющую роль. При первом знакомстве, на результаты которого интерфейс пользователя имеет наибольшее влияние, программа может сразу понравиться или не понравиться. В последствии, при более глубоком изучении функционала ПО, это первое впечатление всегда имеет большое значение для оценки продукта. 30-представление объекта, 3D-walkthrough анимация - это модные темы, особенно в свете применения BIM-технологий при проектировании зданий, предусматривающих построение информационной модели объекта средствами CAD-систем. Мне видится использование подобных опций для обучения персонала, проведения тренингов и т. д. Однако для эффективного решения службой безопасности оперативных задач в реальном времени это не самые лучшие помощники.
Корноухов В. В. («ЕС-ПРОМ»)
Безусловно, 3D-представление объекта производит большее впечатление на заказчика, особенно это заметно на выставках. В то же время специалисты, сталкивающиеся с пусконаладкой данных систем, отмечают сложность при подготовке такого представления, привязке иконок оборудования, видеокамер и датчиков. Кроме того, часто операторы систем ссылаются на сложность в ориентировании в 3D-представлении объекта. Использование стандартного 2D-представления сокращает время пусконаладки и проще для восприятия операторами.
Разумков А. В. (Macroscop)
Недавно мы провели опрос среди своих пользователей, в котором один из вопросов звучал: «Что, исходя из Вашего фактического опыта, является самым важным для системы видеонаблюдения?» На 2 и 3 место по ценности пользователи поставили простоту установки и обслуживания для администратора и простоту работы для оператора соответственно. С другой стороны, однажды один опытный продакт-менеджер сказал мне такую фразу: «Внутренние продукты обречены быть убогими». Дело в том, что люди, которые работают с ними, и те, кто принимает решение о покупке, - это разные люди. И нередко тому, кто принимает решение, не так важно, насколько будет удобно работать оператору. Система видеонаблюдения в большинстве случаев является внутренним инструментом какого-то предприятия, т. е. как раз внутренним продуктом. Те, кто принимает решения в отношении таких продуктов, чаще руководствуются конечной эффективностью. Конечно, на эту эффективность влияют особенности интерфейса, но вот корреляция ее, например, с простотой и удобством интерфейса для оператора далеко не стопроцентная. 3D-walkthrough анимация и 3D-представление объекта охраны могут быть востребованы, если они несут какую-то реальную полезность при эксплуатации. Также они могут быть востребованы просто как красивая визуализация при презентации того или иного решения, чтобы впечатлить тех, кто принимает решение. Но на практике они редко пригождаются в работе.
Горбунова Ю. С. (Milestone Systems)
Если в принятии решения о приобретении системы участвует служба эксплуатации заказчика, то роль пользовательского интерфейса будет очень высокой. Сотрудники службы эксплуатации находятся на переднем крае, они понимают, насколько сильно зависит оперативность и качество реагирования операторов системы на внештатную ситуацию. Удобство интерфейса также влияет на время освоения системы. На наш взгляд, 3D-анимация в этом случае нецелесообразна, т. к. перегружает интерфейс.
Гиние А. А. (ААМ Системз)
Есть старая поговорка: «Встречают по одежке, а провожают по уму». Безусловно, красивый интерфейс обратит на себя внимание, но только на первом этапе. Если он неудобен для работы, если функциональные возможности бедны, даже неопытный заказчик скорее всего откажется от такой системы.
В конечном счете главным критерием является соответствие возможностей системы и потребностей заказчика, проще говоря - сколько «хотелок» заказчика выполняет система и сколько всего может еще сверх того, что требуется сейчас. Что касается 3D-анимации и прочих современных визуальных эффектов -если они помогают в работе (полезны), целесообразно их использовать, если они мешают и отвлекают, снижая скорость реакции оператора на событие, ответ, думаю, ясен. Честно говоря, пока что не видел ни одного реального продукта, где такой интерфейс сильно помогал бы оператору в работе. Красиво - да, полезно - не уверен.
Садов А. Н. («Девлайн»)
Большинство людей предпочитает простоту и удобство при каждодневном использовании. Когда программа устанавливается на промышленные объекты и ей пользуются в служебных целях, существует некое техническое задание по запросам, выставляемым для программы. Но даже в этом случае требование к простоте интерфейса для быстрого освоения программы сотрудниками остается актуальным. Клиентов обычно интересует, как будет выглядеть взаимодействие между сервером и клиентом, возможность работы с несколькими серверами в едином окне и другими подобными вопросами. А вот функционал по 3D-картам объекта мало востребован в системах видеонаблюдения и больше используется в СКУД-системах.
Волкинд Я. Г (ITV | AxxonSoft)
Безусловно, роль пользовательского интерфейса огромна, ведь это первое, что видит заказчик. А если в продукте оптимально сочетается и красота пользовательского интерфейса, и его юзабилити, то шанс принятия заказчиком решения в пользу такой системы увеличивается в разы. Что касается 3D-представления, мне кажется, его использование нецелесообразно. Во-первых, на это требуются более мощные компьютерные ресурсы и, как следствие, возрастает цена системы; а во-вторых, оно не несет особой ценности в техническом плане. Таким образом, использование 3D может стать дополнительным средством привлечения клиента за счет визуального эффекта, но отнюдь не технических особенностей.
Дьячков Д. И. («ПЕТЕРСОФТ»)
Роль достаточно велика. Предпочтения бывают разными, но, наверное, общее - «кликабельные» изображения извещателей, телекамер и т. п. на планах, т. е. возможность управления системой с плана объекта, быстрый вызов подсистем. 3D-представление объекта выглядит, безусловно, привлекательно. Польза от 3D видна, например, в случае одновременной тревоги на нескольких этажах. В этом случае информативность системы увеличивается. Насколько увеличивается, сложно сказать. Надо проводить исследования.
Орлов С. Н. («Полисервис»)
Все адекватные системы предоставляют адекватный интерфейс. Основная задача интерфейса системы охраны - в случае тревоги или неисправности привлечь внимание оператора и доходчиво отобразить место, где произошло вторжение или поломка. Концепция отображения форм зон ярким цветом на плане объекта была придумана еще до того, как придумали словосочетание «система охраны». В первую очередь заказчик обращает внимание на две вещи: насколько ярким цветом система привлекает внимание неквалифицированного оператора и насколько удобно будет пользоваться журналом событий уже самому заказчику, для удовлетворения своих интересов. С точки зрения охраны совершенно нецелесообразно использовать 3D-представления. Причин две: если система многоуровневая и действительно использует третью координату, то 99% объектов можно разбить на послойные планы - план 1 этажа, план 2 этажа и т. д., при этом для внесения изменений в такие планы достаточно навыков начинающего оператора ПК. Скидывание информации обо всем объекте на один план потребует куда больших навыков от пусконаладчика (нарисовать 3D-план, на котором видны все охраняемые зоны, намного сложнее), от оператора (если, не дай бог, этот план начнет крутиться-вертеться, то привычного «в правом верхнем углу у нас столовая» будет недостаточно - каждый раз придется изучать то, что система отображает в конкретный момент), и в итоге будет постоянная перегрузка оператора графической информацией. Свести на монитор только тревожные этажи и все здание целиком - это две очень разные вещи с точки зрения быстрой оценки ситуации.
Кузнецова А. И. («Электроника»)
Интерфейс играет одну из важных ролей при презентации продукта. Как известно, основной источник получения информации - визуальный, поэтому первичная задача интерфейса - привлечь внимание, заинтересовать. Если интерфейс не «цепляет», тяжело удержать внимание заказчика, а соответственно, предлагать и продавать ПО. Помимо внешнего вида, заказчика интересует функциональность системы, возможность автоматизации определенных задач, адаптации под свой проект. При наличии двух систем, равных по функционалу, предпочтение отдадут системе с удобным и интересным интерфейсом. Для решения задач настройки системы под проект интерфейс должен быть гибким и легко настраиваемым. Среди востребованных функций: наличие встроенных гис-карт, автоматизация телефонии, автоматическое оповещение о тревогах и прочее. 3D-анимация в основном используется под специфические задачи и зачастую не требуется. 3D-анимация и представление объектов увеличивают нагрузку на операторов, которые работают за компьютером по 8/10/12 часов. Оператору проще ориентироваться в схематичном плане помещения, чем в объемном 3D-изображении.
Желудков Р. А. («Сименс»)
Как правило, интегрированная система безопасности является надстройкой для контроля состояния и управления оборудованием. В первую очередь, заказчик выбирает оборудование, исходя при этом из технических возможностей, наличия определенных сертификатов (например, для страхования объекта), стоимости системы, соответствия внешнего вида компонентов системы дизайну и своего прежнего опыта. После принятия такого решения возможность выбора системы управления для организации рабочего места обычно сужается до одного единственного варианта, который предлагается производителем к выбранному оборудованию. Поэтому я склоняюсь к мысли, что внешний вид пользовательского интерфейса в большинстве случаев не является критичным при выборе, гораздо большее внимание обращается на функциональность интегрированных подсистем.
2. Как выбрать золотую середину между демонстрацией всех аспектов работы системы и отображением только тех задач, которые требуют управления оператором? Какой принцип выбора полезности отражения той или иной информации? Нужен ли стандарт на представление информации для операторов систем безопасности?
Лёвин С. Н. (ГК «Сигма»)
Разработчики программного продукта, прежде всего, должны очень хорошо разбираться в прикладной части решаемой задачи. Только знание и понимание всех аспектов работы службы охраны позволит создать пользовательский интерфейс, не перегруженный ненужными деталями и, в то же время, предоставляющий всю необходимую информацию и инструменты управления системой безопасности.
Корноухов В. В. («ЕС-ПРОМ»)
Основным принципом должна быть разумная достаточность отображаемой информации, т. е. оператору нужно выводить только ту информацию, которая необходима для выполнения его обязанностей. Наличие стандарта на предоставление информации операторам систем безопасности позволило бы упростить подготовку операторов путем приведения разнообразия интерфейсов к единому виду. Также наличие стандарта значительно упростило бы и задачу разработчикам, т. к. в настоящее складывается впечатление, что каждый старается сделать интерфейс так, чтобы отличаться от других продуктов.
Горбунова Ю. С. (Milestone Systems)
Нужно определить группы операторов и задачи для каждой группы. Для каждой группы должны отображаться только необходимые элементы интерфейса. Введение единого стандарта скорее невозможно, т. к. требования к безопасности отличаются от объекта к объекту. Важно иметь интерфейс, который гибко настраивается в зависимости от потребностей объекта.
Гинце А. А. (ААМ Системз)
В идеале золотая середина должна определяться самим заказчиком. Алгоритм и принцип выбора стар, как этот мир, - отображаем в первую очередь то, что более важно. Простейший пример - отображение информации о тревоге (ОС), взломе двери (СКУД) будет более важной функцией, чем информация о штатном санкционированном проходе в конкретной точке доступа. В то же время, при интеграции с пожарной сигнализацией, - пожарная тревога будет иметь еще больший приоритет для отображения. Стандарт представления информации был бы полезен только в одном случае: если бы его разрабатывали независимые эксперты с привлечением опытных психологов, специалистов по эргономике и пр., да где ж таких «независимых» найти. Иначе это будет игра в одни ворота, а точнее в ворота той компании, которая обеспечит лоббирование своих интересов среди этих экспертов.
Садов А. Н. («Девлайн»)
У любого разработчика всегда есть концепция, заложенная в начале создания программы, когда принимается цветовая схема, расположение элементов управления и т. д. Впоследствии программа обрастает дополнительными функциями и возможностями, но концепцию внешнего вида редко кто меняет. Ввиду специфики потребностей операторов при работе с камерами разместить компактно и интуитивно понятно компоненты управления не так сложно. Другое дело, что в конкурентной борьбе производители камер предлагают свой эксклюзивный функционал, под который не всегда стоит подстраиваться, интегрировать и выносить в интерфейс программы, работающие с большим количеством производителей и моделей камер. Необходимо учитывать, сколько клиентов будет пользоваться той или иной функцией. В отрасли видеонаблюдения у производителей программного обеспечения нет каких-либо стандартов по представлению информации в программе, все формируется де-факто в процессе работы с камерами, настройкой и каждодневном использовании.
Волкинд Я. Г. (ITV | AxxonSoft)
Интерфейс системы должен быть, прежде всего, удобен и понятен для оператора. Представление отчетов должно быть выполнено не в виде отдельных строк и таблиц, а максимально читабельно для оператора - например, в виде графиков или суммарных отчетов, также в них обязательно должна быть возможность фильтрации. Помимо этого, интерфейс должен иметь внутренние сценарии представления того или иного изображения клиенту.
Кроме графической привлекательности, интерфейс системы должен оптимально использовать рабочее поле монитора. Например, когда цифровые системы только начинали использоваться, очень много места в них занимали красивые кнопочки, эквалайзеры, псевдоджойстики и т. д. Эти элементы, в первую очередь, отвлекали оператора, а во-вторых, не несли никакой оперативной информации. То же самое касается интерфейсов к любым другим системам - в них должна быть только минимально необходимая эргономика, а остальное дополняется необходимыми функциями. И конечно, интерфейс не должен ограничиваться коробочным набором свойств, обязательно должны быть настройки. Безусловно, должен быть минимально необходимый набор, который предоставляется всем. Но при необходимости оператору должна предоставляться возможность (хотя бы в небольшой степени) конфигурировать интерфейс под свои потребности.
Дьячков Д. И. («ПЕТЕРСОФТ»)
Если объект крупный, то целесообразно организовать несколько рабочих мест, на каждом из которых будет отображаться или часть объекта со всеми подсистемами, или, наоборот, на каждом рабочем месте отображается ограниченное количество подсистем всего объекта. В обоих случаях необходимо предусмотреть или рабочее место с отображением всего объекта со всеми подсистемами, или возможность быстрого вывода такой информации на любое рабочее место. Отображение той или иной информации должно быть связано с тем, какое место в иерархии сведений занимают конкретные данные. Что касается стандартизации, я бы разделил передачу информации в некие ситуационные центры и использование данных на конкретном объекте. Что касается второго случая, то правильнее, чтобы у заказчика или группы заказчиков были внутренние стандарты к отображению ситуации на объектах и представления данных в отчетах. Вводить же единый российский стандарт отображения информации нецелесообразно хотя бы по причине разных требований у различных групп заказчиков.
Орлов С. Н. («Полисервис»)
Достаточно понять, что оператору-охраннику нужны только тревоги, неисправности и постановка на охрану, при этом исключительно в дискретном виде - оператор не должен вникать в причину неисправности - он должен знать, что она есть, и вызвать техников. Идеал интерфейса для оператора - это план объекта, журнал событий и одна кнопка, которая позволяет «сделать хорошо». Если система охраны сложнее примитивного «показать оператору/ждать его обработки», то все временные элементы экрана (например, подтверждение вызова тревожной группы или кнопка отмены выполнения автоматического сценария) должны отображаться только во время необходимости. При этом быть крупными, хорошо читаемыми и обязательно дублироваться звуковым оповещением - оператор не всегда сидит за монитором. «Все аспекты» должны быть для инженера - вот ему уже интересны и уровни сигналов и напряжение питания и еще много всего, что совершенно не нужно оператору-охраннику.
Кузнецова А. И. («Электроника»)
Информация считается полезной, если ее наличие/вывод позволяет оператору решать определенные задачи. Например, однозначно определять порядок действий при возникновении нештатных ситуаций. Видео с камеры помогает оператору увидеть картину произошедшего и понять, какие действия необходимо предпринять для устранения инцидента.
3. Что правильнее: создавать единый продукт с выводом информации конкретному пользователю в зависимости от прав доступа или создавать отдельные специализированные АРМ? И что в этом случае представляет собой интерфейс администратора: объединенная и расширенная версия пользовательских интерфейсов или отдельный продукт?
Разумков А. В. (Macroscop)
Конечно, чем точнее система решает те конкретные задачи, которые перед ней стоят, тем лучше. Другое дело, что в массовых коробочных продуктах нет возможности делать доработки под каждого пользователя. На мой взгляд, для массового пользователя надо предоставлять обычный универсальный интерфейс, для крупных систем в узких сегментах - адаптированный под задачи этих сегментов, а в особых случаях, если это действительно необходимо и заказчик готов инвестировать средства, вообще разрабатывать специализированный интерфейс для конкретного заказчика.
Горбунова Ю. С. (Milestone Systems)
С нашей точки зрения правильнее создавать единый продукт для операторов и отдельный продукт для администраторов с возможностью разграничения прав пользователей. А также обязательно должен быть предусмотрен доступ операторам через веб-браузер и смартфон. Современные IP-системы видеонаблюдения основаны на IT-технологиях, и зачастую администратором системы видеонаблюдения является системный администратор, который отвечает за IT-инфраструктуру предприятия в целом. Поэтому с точки зрения безопасности это должны быть две разные системы, чтобы, например, даже если оператор где-то достал пароль к панели администратора, он не смог бы элементарно запустить приложение.
Гинце А. А. (ААМ Системз)
Есть достаточно типовые блоки функций, которые можно объединить исходя из их целевого назначения. Такие блоки можно объединить в «программные приложения», имеющие определенную специализацию. Пример таких «приложений»: «картотека», «дежурный режим», «бюро пропусков», «учет рабочего времени», «генератор отчетов» и пр. Данные приложения можно при необходимости запускать на одном или разных компьютерах. Конкретный вариант решения зависит от исходной задачи, пожеланий заказчика и выделенного бюджета. Получается, продукт (SOFT) - один, а запускаемых приложений несколько, и они объединены единым интерфейсом, исключающим необходимость освоения оператором нескольких «разнокалиберных» продуктов. Интерфейс администратора в этом случае отличается от операторского интерфейса только набором доступных средств управления системой и перечнем назначенных прав. Тут, я думаю, к месту будет вспомнить «Бритву Оккама» - «не следует множить сущности без необходимости!»
Садов А. Н. («Девлайн»)
На наш взгляд правильнее создавать единый продукт. Доступ к отображаемой информации идет на уровне прав конкретного пользователя, которые можно гибко настроить вплоть до полного отсутствия возможности оператору что-либо делать, кроме просмотра камер. Можно даже запретить доступ к операционной системе и возможностям выключения ПК, кроме как по кнопке на системном блоке. Один дистрибутив и под сервер, и под клиентское место. Нет необходимости запоминать, скачивать и держать в актуальном состоянии отдельно серверную и клиентскую часть, нагромождать в системе специальные СУБД и дополнительные компоненты, требующие постоянного обновления, а также администрировать весь комплекс дополнительным программным обеспечением. Все, что необходимо для работы, содержится в едином дистрибутиве размером порядка 30 мегабайт, с драйверами под платы видеозахвата и всем функционалом программы.
Волкинд Я. Г (ITV | AxxonSoft)
По большому счету, это две стороны одной медали. Отдельные специализированные АРМ в любом случае будут существовать для определенных пользователей. Как я уже говорил, система должна позволять конфигурировать интерфейс по желанию оператора и при этом обязательно должна быть связана с логированием и правами доступа. То есть этот вопрос не следует делить. И поэтому нет смысла делать множество отдельных маленьких продуктов. Гораздо проще создать один большой продукт, а затем с помощью прав пользователей ограничить его функционал и интерфейс.
Дьячков Д. И. («ПЕТЕРСОФТ»)
С точки зрения нашей компании, лучше использовать единое информационное пространство, распределяя доступ к данным в зависимости от прав пользователей. Соответственно, если конкретному заказчику потребуется создание специализированного АРМа, то его можно создать, назначив определенные права доступа. Интерфейс администратора: если под этим понимать того, кто имеет доступ к настройке системы и назначению прав, то это лишь некий Сверхпользователь, который в соответствии с иерархией прав доступа имеет «право на все».
Орлов С. Н. («Полисервис»)
Стандарт давно есть - план, журнал и список зон с кнопками управления. Так выглядят 99% интерфейсов охранных систем. В общем случае - отдельный продукт безопаснее (не все администраторы одинаково щепетильны к сложности подбора своего пароля), а единый продукт проще в реализации.
Кузнецова А. И. («Электроника»)
Единый продукт создавать сложнее, поскольку он совмещает в себе функционал и настройку целой системы. Хотя такой продукт более универсален в использовании и имеет больше возможностей при адаптации под определенную задачу. С помощью прав доступа легко настраивать доступ операторов к возможностям системы до начала ее эксплуатации и корректировать настройки в процессе эксплуатации системы. И делается это администратором системы на объекте, без необходимости обращения к разработчикам. Кроме того, один продукт легче поддерживать: при внесении изменений, которые затрагивают всех пользователей, не нужно делать обновления на каждом АРМ, достаточно сделать их один раз в общей базе. При разработке разных АРМ различными разработчиками сложнее выдержать единый дизайн интерфейса. Интерфейс админа в данном случае представляет собой объединенную и расширенную версию пользовательских интерфейсов с инструментами для администрирования.
Желудков Р. А. («Сименс»)
Оба решения имеют свои достоинства и недостатки. Каждая задача требует отдельной проработки и выбор способа реализации в зависимости от приоритетов. На мой взгляд, одна полноценная система управления для интеграции всех подсистем в большинстве случаев является наиболее оптимальным решением, так как предлагает более гибкие стандартные средства по разделению отображаемой информации для операторов без необходимости стыковать различные специализированные АРМ между собой. При этом нужно понимать разницу между системой управления и утилитами для конфигурирования подсистем. Система управления в большей степени предназначена для контроля состояния и управления, но не изменения конфигурации подсистем. Конфигурирование же самой системы управления может осуществляться как с рабочего интерфейса при переходе в инженерный режим, так и при помощи отдельных утилит. Я отдаю предпочтение первому варианту, так как он не прерывает работу системы при изменении ее конфигурации и все изменения подхватываются «на лету», в то время как при использовании отдельных утилит требуется время для компиляции и загрузки проекта. Благодаря этому можно разделять права изменения конфигурации операторам и выполнять конфигурирование удаленно.
4. Какие отчеты о работе системы действительно востребованы для постоянного контроля, какие для разбора происшествий, а какие - лишь бесполезные фантазии заказчиков или разработчиков? Насколько интерфейсы работы с отчетами и архивами должны отличаться от интерфейсов оперативного наблюдения?
Лёвин С. Н. (ГК «Сигма»)
Для решения оперативных задач достаточно иметь «быстрые» отчеты о текущем состоянии объекта охраны, а также ленту событий для понимания динамики происходящего. Для анализа инцидентов, сбора статистики нужна развитая система отчетов с многокритериальными запросами к базе данных протокола событий.
Корноухов В. В. («ЕС-ПРОМ»)
Действительно востребованными отчетами являются отчеты о нарушениях трудовой дисциплины (опоздания и ранние уходы), табель T13 системы учета рабочего времени. Часто востребованы отчеты по количеству выданных за период гостевых пропусков. Отчеты о тревогах и неисправностях востребованы для анализа происшествий.
Горбунова Ю. С. (Milestone Systems)
Все отчеты можно разделить на 2 типа: отчеты по безопасности (для операторов) и отчеты по состоянию самой системы видеонаблюдения (для администраторов). К первой группе относятся отчеты по событиям и тревогам, контроль доступа, видеоаналитика и т. п. Набор отчетов сильно зависит от специфики самого объекта. Вторая группа отчетов более общая для всех объектов - это аудит (кто подключался к системе и действия пользователей), логи неисправностей оборудования (диски, процессоры и т. п.).
Гинце А. А. (ААМ Системз)
Все зависит от характера отчета. Так, отчет по тревогам (причем в режиме реального времени на экране компьютера) предельно важен для дежурного оператора системы безопасности, а отчет по приходу и уходу с работы важен для бухгалтерии и руководства компании. Причем, второй отчет скорее всего будет актуален в конце рабочего дня, а то и в конце недели. Естественно, те отчеты, на которых строится оперативное управление и реакция служб безопасности, должны иметь удобный и понятный интерфейс отображения на экране компьютера. Остальные будут более актуальны в печатном виде (в Word, Excel...). Если говорить о повсеместном переходе на цифровые технологии - для некоторых потребителей удобным будет получение отчета с помощью веб-интерфейса (при наличии такового). Ну и конечно, многими потребителями востребована функция получения ответа по заданному «фильтру» (одному или нескольким заданным условиям).
Садов А. Н. («Девлайн»)
При работе системы самый главный «отчет» - это работает ли она вообще. Востребованной информацией служит визуальное отображение на каждой камере детекции движения, записи, названия камеры и времени. Реже используют звуковые оповещения, e-mail/sms-оповещения или сохранение кадров. Вопрос о бесполезных фантазиях заказчиков или разработчиков актуален и сложен для любого производителя софта. Выделить действительно востребованные функции сложно, так как нужно учесть мнения большинства пользователей, руководствуясь принципом «не навреди». Сложность в основном заключается в том, что обратная связь в большинстве случаев идет по тому, что не работает, работает не так, как ожидал клиент, или «еще чего-то не хватает». Например, просмотреть архив камер можно как через переход из режима наблюдения в режим работы с архивом, так и в отдельной ячейке конкретной камеры во время оперативного наблюдения. Тем самым не нарушается общий контроль за ситуацией на объекте.
Волкинд Я. Г. (ITV | AxxonSoft)
Начнем с того, что для постоянного контроля, если подразумевается рутинная работа оператора онлайн, отчеты не нужны. Отчеты - это уже аналитика постфактум. В этом случае нужны различного вида интерфейсы для предоставления тревог: всплывающие окна, открывающиеся тревожные камеры, открывающиеся карты и планы помещения, указания тревожных датчиков, верификация событий срабатывания датчиков с помощью видеоряда и т. д. Если же говорить именно об отчетах для постоянного контроля, то прежде всего требуются отчеты по надежности системы, по ее неисправностям и статистика по ним. Такие отчеты позволяют, во-первых, вычислить наиболее слабые узлы системы. Во-вторых, увидев закономерность выхода из строя определенного оборудования или устройств от определенного поставщика, сменить марку оборудования или поставщика. И, в-третьих, обнаружив ненадежный элемент на одном из объектов, заблаговременно заменить его на остальных объектах, тем самым не допустив его преждевременного выхода из строя и повысив надежность системы. Также необходима статистика по тревожным событиям - срабатывания сигнализации и т. д. По этой статистике мы можем вычислить наиболее «тревожные» места на объекте и усилить контроль за ними, как аппаратный, так и человеческий. Также должна быть возможность формировать отчеты по объектам, узлам, типам сбоев/ неисправностей/ тревог и выдавать суммарную статистику по системе или по ее отдельным компонентам. Для разбора происшествий должны прежде всего использоваться отчеты с привязкой тревожных событий к файлам видеоархива, чтобы мы могли быстро спозиционироваться в видеоархив по любой из строк отчета. Бесполезных отчетов много, их перечислять я не вижу смысла, однако это не значит, что неназванные мной отчеты являются бесполезными! Интерфейсы работы с отчетами и архивами - это принципиально разные интерфейсы. Например, интерфейс наблюдения оператора видеосистемы - это, в первую очередь, видеокамеры. Интерфейс системы контроля доступа - это планы и схемы помещений с нанесенными на них датчиками. А интерфейс для работы с отчетами и архивами -это, прежде всего, интерфейс доступа к ним, на котором есть специализированная клавиатура просмотра. Одним словом, все это - совершенно разные интерфейсы и смешивать их я считаю противопоказанным.
Дьячков Д. И. («ПЕТЕРСОФТ»)
Думаю, всегда нужны: сообщения о тревогах и неисправностях. При этом важно учитывать еще логику взаимодействия подсистем. Например, что считать при открытии помещения тревогой уровня № 1, уровня № 2 и т. д.: помещение не снято с охраны, но по предъявлении карты дверь была открыта, или помещение снято с охраны, карточка не была предъявлена, но дверь открыта и т. д. Для анализа произошедших событий необходима возможность «перекрестных ссылок» из разных подсистем, увязанных между собой по дате/времени. Бесполезность фантазий заказчиков и разработчиков - вопрос непростой. Иной раз заказчик посмотрит какой-нибудь боевик и начинает требовать, чтобы из двух пикселей ему лицо нарушителя на экран вывели. Иногда наоборот, заказчик может упустить что-то из виду и тут надо ему помогать. Т.е. надо оценивать существующие угрозы, уметь прогнозировать возможные, знать средства противостояния (существующие и разрабатываемые) и уметь кратко описывать все, что является задачей отчетов. При оперативном наблюдении должен быть разумный максимум наглядной информации (видео, планы, всплывающие сообщения), а при работе с отчетами - выбор признаков поиска ситуации, перекрестные ссылки между отчетами и т. п.
Орлов С. Н. («Полисервис»)
Главная статистика в отчете - это количество краж / проникновений на объект с точки зрения системы и фактическая: если фактическая больше, то систему надо менять вне зависимости от прекрасности ее интерфейса. Еще полезно знать, как часто, какие именно и почему элементы системы дают ложные срабатывания, и сколько времени и какие именно элементы объекта находились без охраны из-за ремонтных или профилактических работ. Это три основные цифры, задача любой системы - чтобы они стремились к нулю. Насколько интерфейсы работы с отчетами и архивами должны отличаться от интерфейсов оперативного наблюдения? Ровно настолько, насколько мы ценим заказчика и охраняемое им добро.
Кузнецова А. И. («Электроника»)
Интерфейсы должны иметь общий принцип организации, но визуально отличающиеся рабочие моменты, необходимые для однозначного и четкого понимания, идет ли работа с архивом или в реальном времени.
Желудков Р. А. («Сименс»)
Система управления должна контролировать корректность работы своих компонентов постоянно и отображать эту информацию в пользовательском интерфейсе. Должна быть отдельная панель для отображения текущих событий. Журнал событий должен фиксировать все события в системе и действия оператора, и, конечно, оператор должен четко понимать, какая информация относится к текущему состоянию системы, а какая уже неактуальная. Очень хорошо, если еще поддерживается экспорт этой информации в другие форматы, например, для Microsoft Excel. Это позволит использовать функциональность сторонних приложений для анализа данных. Этого вполне достаточно для работы. Другие дополнительные функции будут специализированными и использоваться в редких случаях.
5. При все более усложняющихся системах как не перегрузить оператора информацией обо всех параметрах в момент нештатной ситуации? Как определить, что действительно нужно для принятия решения? Что собой представляет система поддержки принятия решения на уровне интерфейса оператора?
Лёвин С. Н. (ГК «Сигма»)
Здесь нужно решить одновременно две задачи: сохранять фокус внимания оператора на тревожных объектах, не дать оператору потерять информацию о текущих тревогах и вместе с этим сохранить свободу действий по информационному взаимодействию и управлению системой безопасности...
Корноухов В. В. («ЕС-ПРОМ»)
Здесь был бы уместен подход, заимствованный из систем управлениями рисками, когда для каждой нештатной ситуации (инцидента) создается регламент реагирования с четкой последовательностью действий, которые необходимо выполнить оператору.
Разумков А. В. (Macroscop)
Самое главное - в системе не должно быть автоматически и в быстром темпе возникающих и наслаивающихся друг на друга, либо замещающих друг друга, элементов интерфейса. Например, были такие системы, в которых при большом количестве тревожных событий все превращалось в какую-то бесконечную смену картинок, и разобраться в происходящем было уже невозможно. Должно быть какое-то ограниченное количество элементов в последовательности, при достижении которого новые элементы не поступали бы до тех пор, пока оператор не обработает предыдущие. Исключением может стать только возникновение тревоги более высокой степени важности.
Горбунова Ю. С. (Milestone Systems)
Прежде всего должна быть проведена тщательная подготовительная работа на административном уровне (регламенты, инструкции и т.п). От предварительной проработки подобных процессов в компании зависит корректность работы системы, т. к. система является лишь инструментом и не может полностью заменить человека. В самой же системе при возникновении внештатной ситуации должна быть возможность появления инструкции для оператора, чтобы он не растерялся и точно знал, что делать. Помимо этого, должна быть предусмотрена возможность воспроизведения видео, как в режиме реального времени, так и архива, предшествующего моменту инцидента. Привязка камеры к карте поможет легче сориентироваться, а аудио-оповещение - быстро проинформировать сотрудников. Во время обработки тревоги оператор должен иметь возможность менять статус тревоги, записывать свои действия, менять приоритет тревоги. Если оператор не реагирует на тревогу, она должна быть передана другому оператору или его супервизору. Для принятия коллективного решения или эскалации тревоги, она и видео с соответствующей камеры должны быть выведены на тревожный монитор или видеостену.
Гинце А. А. (ААМ Системз)
Я уже об этом упоминал - надо фильтровать информацию на основе системы приоритетов, - самая важная дается в первую очередь, особенно при нештатной ситуации. В тех случаях, когда автоматизация реакции невозможна или нежелательна (это самый быстрый вариант реакции), когда решение должен принять оператор, можно ему помочь, выведя на экран несколько возможных вариантов реакции системы с пояснениями, какие действия будут при этом выполнены. Это поможет оператору не растеряться при принятии ответственного решения в жестких временных рамках, активировав наиболее подходящий вариант реакции системы.
Садов А. Н. («Девлайн»)
В мире всегда что-то происходит, и отделить ложное срабатывание от реальной опасности современные программы могут только отчасти, более удачно с этим справляются именно операторы. Для принятия решения обычно используется визуальное наблюдение. Другой способ - это звуковое оповещение с указанием источника сигнала. Еще одним удобным инструментом служит так называемый тревожный монитор. Немаловажный функционал - возможности прослушать звук с камеры, а также увеличить кадр или быстро развернуть PTZ-камеру в нужном направлении для более детального просмотра ситуации. Для оптимального контроля лучше комбинировать возможности оператора, системы видеонаблюдения с аппаратно-программными датчиками и интегрированным сторонним софтом, когда визуальный инцидент мы можем подтвердить оповещением с датчика СКУД-системы.
Волкинд Я. Г (ITV | AxxonSoft)
Чтобы не перегрузить оператора информацией в момент нештатной ситуации, во-первых, нужно сгруппировать все нештатные ситуации и визуализировать эти группы. Благодаря этому оператор будет видеть, что одна ситуация возникла в результате обрыва связи и потери соединения, а другая - по срабатыванию видеоаналитики в тревожной зоне. Это позволит оператору сразу понять, что является тревогой первой степени реагирования, а что при наличии других тревог можно отложить. Во-вторых, нужно предоставить оператору тот интерфейс, который для него востребован, поскольку, например, операторам СКУД многооконный интерфейс видеонаблюдения не интересен, а операторам видеонаблюдения - наоборот. В-третьих, нужно устранить человеческий фактор, чтобы оператору не нужно было при наступлении события самостоятельно искать датчик, камеру или зону, в которой что-то сработало. Все это должно предоставляться оператору в автоматическом режиме в виде тревожных окон и т. д. Группировку и категорирование тревожных событий по степени важности должен выполнять заказчик. Он же может настроить иерархию реагирования на события. Она используется, как правило, на больших объектах, где существуют операторы нескольких уровней. При поступлении оператору тревоги, для реагирования на которую у него недостаточно квалификации или полномочий, он эскалирует ее на уровень выше, и так до оператора самого верхнего уровня, как правило, это центральный пост управления системой, который принимает решения только по самым сложным ситуациям. Также поддержкой принятия решения можно назвать предоставление информации в оптимальном для оператора виде, чтобы от него требовалось как можно меньше физических движений и времени на раздумье. Также неплохо помогают наборы элементарных действий, зависящих от ситуации, из которых оператор выбирает свои решения. В критической ситуации подобные подсказки могут играть решающее значение.
Дьячков Д. И. («ПЕТЕРСОФТ»)
Чтобы не перегрузить оператора информацией, надо просто ее разумно дозировать. Представим, что произошел пожар... Нужно знать: где именно возгорание (задача ПС); хотя бы приблизительно, где и сколько находится людей (например, задача СКУД и видео); вывести изображение с телекамер на путях эвакуации и доступен ли проезд для пожарных машин (задача видео). Все остальное, например, информация о лифтах, состоянии дверей и т. п. следует выводить на второстепенный монитор. Система поддержки принятия решения состоит из двух частей: информирование (здесь полезно добавить голосовое оповещение и т. п.) и всплывающие подсказки, созданные при моделировании возможных ситуаций на конкретном объекте.
Орлов С. Н. («Полисервис»)
Одна кнопка «сделать хорошо» достаточна для решения любой проблемы. Чем меньше своей работы программист и инженер-пусконаладчик перекладывают на оператора, тем меньше у оператора кнопок.
Кузнецова А. И. («Электроника»)
Следует придерживаться следующей последовательности: Выводить информацию в соответствии с компетенцией оператора. Вначале выводить только основную информацию: что произошло (название инцидента), где (место происшествия) и когда (дата) произошло, а также уровень тревожности, позволяющий оценить критичность происшествия. Нет необходимости давать оператору полный набор данных сразу же при возникновении нештатной ситуации, так как лишняя информация мешает действовать оперативно. Дополнительная информация должна выводиться по запросу оператора. При этом оператору необходимы удобные инструменты для оперативного получения дополнительной информации и управления ситуацией. Объединять все события, связанные с происшествием, в один инцидент. Когда вся информация о происшествии находится в одном месте, легче искать необходимые данные и решать задачу по устранению инцидента.
Желудков Р. А. («Сименс»)
От человеческого фактора никуда не деться, но и лучше человека никакой компьютер не примет решение, по крайней мере, в настоящее время. Поэтому система управления должна помогать человеку в принятии решений. Это достигается несколькими уровнями отображения информации, например, интерфейс системы управления может иметь обобщенную панель наличия событий по всему объекту, по значкам на графических планах оператор может иметь представление о состоянии каждого отдельного элемента или их группы, включая отдельные этажи или здания. При необходимости оператор может выбрать интересующий его элемент и открыть дополнительную панель с подробными свойствами и командами. Помимо этого существует возможность предварительного создания процедур обработки событий, которые автоматически запускаются при определенных ситуациях и ведут оператора шаг за шагом, исключая совершение им ошибок.
6. Не все нештатные ситуации можно предварительно прописать сценариями. Вывод каких параметров системы для постоянного наблюдения могут дополнительно помочь в оперативном реагировании (технические параметры датчиков, видеоряд, контроль температуры и т.п)?
Лёвин С. Н. (ГК «Сигма»)
Лучший вариант - это дать возможность гибкой настройки визуализации параметров системы. Тогда в каждом конкретном случае можно будет подобрать оптимальный набор данных, необходимых для эффективной работы оператора.
Корноухов В. В. («ЕС-ПРОМ»)
Если ситуация не прописана в сценариях, то рядовой оператор все равно не в состоянии принять решение. Поэтому для таких ситуаций должна быть предусмотрена возможность эскалации инцидентов на уровень выше, интерфейс начальника смены, как правило, отображает больше информации, чем интерфейс оператора, и квалификация начальника должна быть достаточна для принятия решения в ситуации, не прописанной в сценариях.
Горбунова Ю. С. (Milestone Systems)
Это, прежде всего, тревожный монитор или видеостена. Отображение текущего состояния элементов системы на интерактивной карте (камер, датчиков, точек доступа и т. п.), например, с помощью цветовой индикации.
Садов А. Н. («Девлайн»)
В видеонаблюдении главное - наблюдать, что происходит в реальном времени. Первое, что необходимо фиксировать, -это, конечно же, время инцидента, поэтому вывод времени крайне желателен по всем камерам. Причем необходимо учитывать, что оптимальным будет вывод именно времени сервера, а не камеры, которое может отличаться или быть не настроено должным образом. Вторым важным моментом служит оповещение о потери связи с камерой, причем можно выводить как текстовое оповещение на каком-то фоне, так и текстовое оповещение на последнем удачно полученном кадре, по которому можно судить, что происходило до момента потери сигнала. Еще можно отметить функцию реакций системы на превышение уровня микрофона, когда мы видим стандартный видеоряд, а в месте инцидента уже идет разговор на повышенных тонах или началась драка, да и на многих объектах есть мертвые зоны, визуальный просмотр которых недоступен. Что касается датчиков и дополнительных отображаемых компонентов, то это возможно через интеграцию со сторонними программами и, как правило, настраивается под конкретное техническое задание.
Дьячков Д. И. («ПЕТЕРСОФТ»)
Первое, всегда надо сочетать организационные и технические методы предотвращения, обнаружения и реагирования на нештатные ситуации. Второе, можно увеличить информативность системы (если бюджет позволяет) за счет тех или иных решений. Например, в книгохранилищах, торговых центрах было бы разумным использовать аспирационные извещатели дыма с возможностью on-line графиков состояния внутренней атмосферы. В местах массового скопления людей будут полезны средства видеоаналитики (детекция предметов, подсчет количества людей в определенных зонах). И т. д.
Орлов С. Н. («Полисервис»)
Все нештатные ситуации можно описать заранее. Достаточно не надеяться на оператора - тогда он не ошибется в критический момент.
Кузнецова А. И. («Электроника»)
Для каждого конкретного набора оборудования набор параметров варьируется, но лучше всего себя зарекомендовал двойной рубеж контрольных датчиков (с их параметрами) + система видеонаблюдения, отслеживающая подозрительные события на любом из рубежей охраны.
Желудков Р. А. («Сименс»)
Наиболее полную картину происходящего может предоставить система, которая поддерживает интеграцию различных подсистем. Получив подтверждение о происшествии по данным от нескольких различных систем, оператор может быть точно уверен в случившемся. Например, по событиям от систем охранной и пожарной сигнализаций, системе контроля доступа необходимо проверить указанное место, чтобы уточнить обстоятельства и принять оптимальное решение. Для этого требуется как минимум два сотрудника, чтобы один оставался на рабочем месте и продолжал контролировать ситуацию, а второй отправился на место происшествия. При поступлении тревожного события система управления автоматически отобразит «живое» видео с камер, которые направлены на источник события. В считанные секунды оператор может увидеть все происходящее в масштабе реального времени и при необходимости просмотреть архив видеозаписей. Благодаря этому оператор может понять, насколько критична ситуация в плане угрозы жизни и здоровью персонала и сохранности имущества, и принять необходимые меры.
7. Какова перспектива и как происходит развитие интерфейсов в части контроля за действиями оператора и контроля его бдительности? Как вы относитесь к коллективным действиям операторов: взаимный контроль, дублирование/резервирование, перехват и оперативное ограничение полномочий, автоматические реакции на бездействие оператора?
Лёвин С. Н. (ГК «Сигма»)
Для систем безопасности, защищающих важные объекты, все перечисленные тактики работы должны использоваться в полной мере. Если дублирование и резервирование аппаратуры -это нормальная практика на ответственных объектах, то те же самые меры применимы и к персоналу службы безопасности.
Корноухов В. В. («ЕС-ПРОМ»)
В настоящее время я не встречал специальных механизмов on-line контроля бдительности операторов. Анализ проводится постфактум, при помощи модуля отчетов по параметру «время реакции» (время, через которое охранник подтвердил получение тревожного извещения).
Разумков А. В. (Macroscop)
Для простых систем целесообразно использовать какие-то очень простые и понятные вещи, например, периодически всплывающее окошко, на которое оператор должен реагировать тем или иным действием. Для сложных систем создаются более функциональные и профессиональные решения. Например, чат для операторов, возможность одному оператору передать другому сетку с выбранными в ней каналами и т. д. Но такой функционал востребован в малом проценте видеосистем, широкому кругу пользователей он просто не нужен.
Горбунова Ю. С. (Milestone Systems)
Конечно же, контроль за действиями операторов все больше ужесточается. Все действия операторов логируются, некоторые системы имеют возможность записывать то, что происходит на экранах их мониторов. В более серьезных системах, где чрезвычайные ситуации связаны с большими финансовыми потерями (например банки), требуется двойная авторизация для входа в систему. Повысить контроль также позволяет настройка профилей времени, при которой каждый отдельный оператор может войти в систему только в дни и часы, которые заданы в профиле. Это также защищает организацию от злоупотреблений.
Гинце А. А. (ААМ Системз)
Действия операторов в «правильной» системе протоколируются и могут быть подробно рассмотрены (разобраны) руководством в случае разбора любой штатной или нештатной ситуации. Это стандартный функционал нормальной системы. Что касается контроля бдительности, то, например, появление меню подтверждения тревоги с фиксацией времени подтверждения является стандартной функцией для многих систем. Что касается взаимного контроля, дублирования/резервирования, перехвата и оперативного ограничения полномочий, автоматической реакции на бездействие оператора - все это в солидных системах есть. Для реализации данных режимов в «правильных» системах существует развитая иерархическая система прав и встроенный аппарат реакций на программном и аппаратном уровнях.
Садов А. Н. («Девлайн»)
Данное направление слабо развито, но вопросу стоит уделить внимание. Сейчас можно рекомендовать на крупных объектах ставить дополнительную камеру для контроля за деятельностью операторов на рабочем месте. Желательно включить возможность записи данной камеры в отдельное сетевое место, недоступное охранникам. Для дополнительного контроля ситуации на объекте можно воспользоваться функциями сохранения кадров как локально, так и на FTP, e-mail- или sms-уведомления начальнику смены охраны, в том числе, если сервер перестает быть доступным. Вопрос по оперативному реагированию остается открытым и требует дополнительного изучения потребностей заказчиков.
Волкинд Я. Г (ITV | AxxonSoft)
Здесь речь должна идти скорее не об интерфейсах, а о функционале, а это контроль за квитированием событий. То есть, если событие не получило реакции оператора в течение заданного времени, то оно эскалируется либо другому оператору, либо на уровень выше. Также это логирование всех действий оператора. В ряде случаев для наблюдения за оператором устанавливается примитивная камера с датчиком движения, которая подает сигнал тревоги, если не замечает движения в течение заданного времени. Вариантов может быть много. К коллективным действиям операторов я отношусь замечательно. Есть даже такое понятие, как «правило четырех глаз». Это помогает избежать ошибочных действий или пропустить что-то. Но опять же, должен быть принцип разумной достаточности. Разумно применять коллективное действие операторов на стратегически важном объекте, а в системе наблюдения за дворовой территорией у консьержа это, конечно же, не нужно.
Дьячков Д. И. («ПЕТЕРСОФТ»)
Несколько лет назад наблюдал систему: с определенным интервалом времени охранник должен был по сигналу нажимать кнопку - мол на месте и не спит. Идея хорошая, но особым успехом не пользовалась. Почему? Наверное, начальники служб безопасности интуитивно понимали, что нажимание кнопки выключения звукового сигнала несколько раз за смену вряд ли будет способствовать улучшению качества работы операторов. Для начала надо создать нормальные условия работы (длительность смен, количество контролируемого оборудования и т. п.). Затем можно дополнить систему некоторыми техническими решениями: контроль обхода с использованием биометрии, фиксация времени действий операторов, автоматическая тревога в случае отсутствия реакции оператора на нештатные события и т. д.
Орлов С. Н. («Полисервис»)
Дублирование операторов - необходимость, однако это не решение проблемы, а лишь лечение симптомов. Максимальная автоматизация действий и реакций системы - именно то, за что заказчик, в конечном итоге, и платит деньги, ведь все охранные системы начинались с того, что заменяли собой собаку и оператора собаки.
Кузнецова А. И. («Электроника»)
Можно говорить о снижении нагрузки на оператора за счет автоматизации функций программы и интерфейса. Необходимо автоматизировать оповещение ответственных лиц и руководства при возникновении нештатной ситуации. А также повысить достоверность видеоаналитики, тем самым избавив оператора от необходимости просматривать и анализировать видео самостоятельно. Коллективные действия операторов по управлению инцидентом позволяют сократить время реагирования и эффективно решать задачи по отработке инцидента. Особенно, когда обязанности четко распределены между операторами. Один оповещает ответственных лиц и вызывает группы реагирования, другой просматривает видео, третий управляет инцидентом на месте. Все действия операторов регистрируются в системе и доступны (видимы) всем операторам, которые работают над инцидентом.
Желудков Р. А. («Сименс»)
На мой взгляд, оператор выполняет больше контролирующую функцию, так как все алгоритмы прописаны в оборудовании и активируются автоматически. В некоторых случаях требуется вмешательство оператора в работу этих алгоритмов для ускорения или отмены выполняемых действий. У зарубежных производителей оборудования пожарной безопасности предусмотрена поддержка самим оборудованием концепции исключения ложных вызовов пожарных бригад. Это достигается переводом системы в режим присутствия/отсутствия персонала на рабочем месте. Система может автоматически менять режим в заданное время, или его может менять оператор. Разница в том, что в режиме отсутствия при появлении тревожного события сразу осуществляется оповещение пожарной бригады и активация противопожарного управления, в то время как в режиме присутствия запускается программируемый таймер, например, на 1 минуту, в течение которой осуществляется местное оповещение оператора. Если за это время оператор подтверждает событие либо с контрольной панели, либо с системы управления, то запускается второй таймер, например, на 5 минут, для выяснения обстоятельств. Если в течение этого времени случается еще одна тревога или никаких действий оператора не происходит, то активируется общая тревога с выполнением всех противопожарных мероприятий. Если при проверке выявилось, что тревога ложная, то оператор может отменить противопожарный алгоритм.
Архив публикаций
