Приложение 1 – Перечень типовых объектов массового пребывания*
Типовые обьекты массового пребывания людей:
Учреждения культуры и парки отдыха: музеи, театры, городские парки и т.д.;
Учреждения образования: школы, техникумы и т.д.;
Учреждения здравоохранения: поликлиники, больницы и т.д;
Учреждения торговли: торговые центры, рынки и т.д.;
Объекты транспортной инфраструктуры: автовокзал, железнодорожный вокзал и т.д.;
* - данный перечень подлежит уточнению проектирующей организацией в соответствии с распоряжениями, утвержденными в муниципальном образовании (пилотных муниципальных образованиях) на этапе создания технического проекта.
Приложение 2 - Требования по созданию опытного образца (стенда)
Требования по созданию опытного образца (стенда)
-
По результатам проектирования для практической отработки решений, принятых в проектной документации, Подрядчиком должен быть создан опытный образец (стенд) РИП АПК «Безопасный город» (далее - Стенд). В состав Стенда должны входить:
Опытный образец программно-аппаратного комплекса автоматизации деятельности ЕЦОР, ЭОС и ДДС (далее – КСА ЕЦОР);
Подсистема интеграции данных;
2 (две) проинтегрированные системы, которые должны быть определены по результатам Обследования.
-
Стенд должен обеспечивать следующие функциональные возможности и характеристики:
КСА ЕЦОР в составе стенда АПК «Безопасный город» должен поддерживать следующую функциональность:
2.1.1. иметь пользовательские интерфейсы на русском языке и удовлетворять следующим требованиям:
– обеспечивать работу пользователей системы с учетом их количества, определяемого организационно-штатной структурой ЭОС;
– обладать свойствами модульности, масштабируемости и возможности адаптации к различным организационным и техническим условиям в соответствии с используемыми техническими средствами;
– обеспечивать возможность тиражирования, внедрения, сопровождения и развития на протяжении всего жизненного цикла;
– обеспечивать безопасность входа в интерфейс КСА ЕЦОР через аутентификацию и авторизацию пользователей;
– интегрироваться с системой безопасности операционных систем (не требовать дополнительного ввода имени или пароля для аутентифицированного в операционной системе пользователя);
– обеспечивать разграничение прав пользователей в соответствии с функциональными ролями и задачами;
– обеспечивать взаимодействие с подсистемой интеграции данных, в том числе обмен данными и доступ к функциональности интегрированных систем;
– использовать стандартные протоколы обмена данными для обеспечения информационного взаимодействия с внешними системами.
2.1.2. КСА ЕЦОР должен предоставлять следующие функции управления происшествиями:
- организацию приема сообщений о происшествии по каналам голосовой связи и от различных систем ситуационного мониторинга;
– организацию голосовых конференций между персоналом, а также с участием внешних абонентов (заявителей, служб, внештатного персонала, должностных лиц на выезде и т.п.);
– организацию специальных голосовых конференций, когда ведущий конференцию сотрудник слышит всех участников разговора, в том числе подключенные службы и внешних абонентов, а заявитель слышит только этого ведущего;
– распределение поступающих сообщений о происшествии между пользователями должно основываться на системе задач, объединенных в роли и далее рабочие задания, которые назначаются конкретным пользователям, а не на системе телефонной нумерации или именах пользователей;
– указание для пользователя основных и дополнительных заданий так, чтобы сообщения о происшествиях сначала направлялись тем, для кого соответствующее задание является основным, а при недоступности таковых — дополнительным;
– настройка схем распределения для разных типов сообщений о происшествии (телефонный вызов, аварийный сигнал, SMS, электронная почта);
– поиск пользователя по заданным квалификационным признакам (например, по знанию языка), имени, текущей роли;
– распределение сообщений о происшествии между операторами в соответствии с их загрузкой (выбор наименее загруженного оператора);
– установка специального периода для завершения операторами работы над сообщением о происшествии перед передачей ему нового сообщения;
– создание нескольких очередей для разных типов (внутренних, внешних, от подсистемы мониторинга) сообщений о происшествии;
– постановка разных типов сообщений о происшествии в общую очередь;
– обновление данных на экранах остальных операторов при ответе оператором на сообщение о происшествии;
2.1.3. КСА ЕЦОР должен предоставлять следующие функции организации совместной работы:
– подключение любого количества служб (участников) к происшествию;
– возможность подключения новых участников до завершения обработки предыдущим с немедленным предоставлением введенных данных и немедленным отображением изменений (параллельная работа оператора ЕДДС и диспетчера ЭОС);
– автоматическое немедленное обновление на экранах нескольких операторов информации о вызове, при изменении такой информации одним из операторов, в том числе на уровне изменения отдельных полей данных без ручного подтверждения или принудительной отправки изменений;
– обеспечение участникам работы по происшествию возможности прослушивания записи вызовов, относящихся к происшествию;
– агрегирование в одной записи о происшествии информации, поступающей от разных служб;
– однократное введение информации (поля данных) используемой в представлениях для нескольких служб;
– прикрепление к карточке происшествия любых документов в электронном виде произвольного формата;
– раскрытие или ограничения доступа к информации служб на основе системы разграничения доступа;
– запрет закрытия происшествия, пока все назначенные ресурсы не завершили реагирование, и пока не выполнены все обязательные процедуры (планы).
2.1.4. КСА ЕЦОР должен предоставлять следующие дополнительные функции поддержки принятия решений:
– подсказки (предложения) оператору о привязке поступившего сообщения о происшествии к ранее зарегистрированному (и не завершенному) сообщению о происшествии на основании совпадения телефонного номера заявителя, места происшествия и т. д.;
– автоматизированная и автоматическая классификация (разнесение) зарегистрированных сообщений о происшествии на основе справочников для категорий, видов и статусов происшествий с возможностью актуализации справочников;
– не менее 3-х уровней в иерархическом классификаторе происшествий;
– возможность создания собственных классификаторов для каждого вида ДДС;
– формирование перечня вопросов для интервью заявителя и/или регистрации информации по реагированию в зависимости от иерархического классификатора типов происшествий;
– автоматическое изменение перечня вопросов интервью в зависимости от ответов на предыдущие вопросы;
– автоматическое изменение классификации происшествия в результате использования ответов на вопросы интервью;
– формирование подсказок для действий оператора по результатам интервью;
– автоматическое определение ДДС, к зоне ответственности (географической и функциональной) которой (которых) относится данное происшествие;
– автоматическое определение перечня объектов повышенного риска, находящихся в зоне происшествия;
– автоматизированный поиск свободных сил и средств ЭОС, находящихся в районе происшествия для реагирования и способных выполнить план (задание) реагирования в зависимости от имеющегося оборудования и навыков экипажей;
– создание типовых сценариев реагирования операторов, диспетчеров на происшествие, экстренную или чрезвычайную ситуацию;
– автоматический выбор сценария реагирования в зависимости от классификации происшествия, результатов интервью, места происшествия, номера абонента;
– создание специальных сценариев реагирования, привязанных к объекту повышенного риска, для ликвидации происшествий в зоне этого объекта;
– указание для планов реагирования времени применимости (например, только в рабочие дни с 8 до 12 часов);
– создание шаблонов (частей) планов, для последующего включения в несколько планов;
– при применимости к происшествию нескольких планов, комбинация их в общий план;
– создание автоматически выполняющихся планов реагирования;
– автоматизированную (по решению авторизованного лица) реализацию планов реагирования;
– механизм оценки готовности к реагированию.
2.1.5. КСА ЕЦОР должен предоставлять следующие геоинформационные функции:
– автоматическое присоединение к происшествию «снимка» карты с районом происшествия;
– выбор сил и средств на карте (выбор символа ресурса на карте и назначение через контекстное меню задачи на реагирование на происшествие);
– перемещение ресурсов по карте вручную;
– отображение местоположения ресурсов по карте вручную;
– создание дополнительных окон для отслеживания местоположения и состояния ресурса (плавающее окно с частью карты, центрированное на выбранном ресурсе);
– атрибутивный поиск на карте объектов классифицированных типов;
– поиск свободных сил и средств в районе происшествия;
– отображение статуса сил и средств;
– нанесение информации на карту и обмен информацией с другими операторами в реальном времени (в режиме онлайн);
– возможность добавить/изменить/удалить знаки/символы на карту;
– отображение камер видеонаблюдения в зоне происшествия с переходом к изображению с камеры (при поддержке такой функции системой видеонаблюдения).
2.1.6. Функционал АРМ оператора ЕЦОР и диспетчера ДДС (ЭОС) должен реализовываться единым приложением без использования веб-интерфейса. Доступный через это приложение функционал должен определяться правами и обязанностями лица и (возможно) выбранным рабочим заданием.
2.1.7. КСА ЕЦОР должен предоставлять возможности «свободного» расположения операторов, т. е. функциональные возможности всех АРМ, входящих в ЕЦОР, и выполняемые задачи должны определяться исключительно параметрами входа пользователя в систему, а не местом расположения АРМ.
2.1.8. Программное обеспечение КСА ЕЦОР должно иметь возможность неограниченного масштабирования на количество прикладных систем и пользователей, подключаемых к ЕЦОР.
2.1.9. КСА ЕЦОР должен поддерживать функции обучения на рабочем месте. Средства обучения должны обеспечивать выполнение следующих основных функций:
– запуск АРМ оператора (диспетчера) в режиме обучения, в котором вводимые данные не попадают в основную базу данных ЕЦОР;
– запись скриптов (сценариев) обучения, представляющих собой последовательность шагов, каждый из которых характеризуется временем на этом шаге, выполненными в системе действиями, информацией о голосовых записях;
– выполнение записанных скриптов в следующих режимах:
а) режим проигрывания — пользователь может только наблюдать за действиями, прослушивать голосовые записи, видеть подсказки;
б) режим сценария — пользователь должен выполнять действия, положенные его роли;
в) режим тестирования — аналогично сценарию, но с регистрацией и оценкой результатов;
г) режим эмуляции — действия сценария вносят изменения в базу данных, создают вызовы и т. д.
– создание обучающих курсов, состоящих из серии уроков, состоящих из скриптов;
– оценка прогресса выполнения курсов отдельными пользователями.
2.1.10. КСА ЕЦОР должен иметь в своем составе подсистему управления силами и средствами ЭОС со следующей функциональностью:
– указание пунктов (станций) базирования ресурсов;
– указание оборудования на пунктах базирования;
– указание автомобилей, находящихся на станциях базирования или в управлении ДДС;
– указание оборудования на автомобиле;
– указание состава экипажа автомобиля;
– указание должностей и квалификационных признаков персонала реагирования;
– указание графиков дежурства ресурсов;
– поиск сил и средств по навыкам и доступности;
– отображение местоположения и статуса ресурсов на карте;
– назначение ресурсам нескольких заданий (происшествий для реагирования), контроль выполнения заданий.
2.1.11. Программное обеспечение КСА ЕЦОР реализующее функционал, описанный в подпунктах №№ 2.1.1. – 2.1.10. должно соответствовать (иметь сертификат соответствия) требованиям руководящего документа ФСТЭК России (утвержден решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. № 114) «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» по 4 уровню контроля (программное обеспечение, используемое при обработке конфиденциальной информации).
Подсистема интеграции данных должна иметь в своем составе:
а) модуль ведения реестра КСА (мастер-система);
б) модуль управления данными (интеграционная шина).
2.2.1. Модуль ведения реестра внешних КСА АПК «Безопасный город» подсистемы интеграции данных должен обеспечивать следующие функции:
- ведение, хранение и резервное копирование информации о муниципальных, региональных КСА, включая информацию о всех ИС, входящих в состав соответствующих КСА и адресах веб-сервисов этих ИС (либо их адаптеров), реализующих обмен в формате единого унифицированного протокола обмена данными;
- обеспечение целостности данных, передаваемых между интегрируемыми ИС, путём контроля изменений в ИС-источниках и синхронизации этих изменений по всем ИС-потребителям, входящим в состав КСА;
- обеспечение авторизованного доступа к данным для муниципальных ИС и операторов по установленным регламентам доступа и взаимодействия;
- ведение журнала операций информационного обмена.
Модуль ведения реестра внешних КСА АПК «Безопасный город подсистемы интеграции данных должен осуществлять централизованное хранение и распространение общевостребованных данных между Информационными системами – участниками информационного обмена. Данный функционал должен обеспечиваться посредством ведения в модуле набора справочников, доступ к которым на чтение, либо изменение для подсистем должен быть настраиваемым. Поддержка рассылки изменений в ИС- участниками информационного обмена соответствующих справочников должна настраиваться на основе подписок.
Обмен данными между интегрируемыми ИС должен осуществляться посредством единого унифицированного протокола обмена данными, Модулем должен поддерживаться синхронный и асинхронный режим обмена данными. В случаях, когда обмен данными по единому унифицированному протоколу с какой-либо ИС невозможен, для соответствующей ИС должен быть разработан адаптер, представляющий собой отдельное приложение, берущее на себя взаимодействие с модулем ведения реестра и другими муниципальными/региональными ИС в формате единого протокола и взаимодействующий с собственной ИС посредством имеющихся у неё сервисов, интерфейсов, либо посредством прямого подключения к базе данных ИС.
Пересылаемые в рамках информационного взаимодействия между муниципальными ИС пакеты данных должны регистрироваться в журнале, с указанием даты и времени поступления пакетов, типа операции (чтение, создание, изменение, удаление и т.д.), кодов ИС-источника и ИС-получателя, уникального идентификатора пакета и переданного XML-документа, содержащего набор изменяемых данных. Журнал должен обеспечивать возможность детального просмотра информации о каждом пакете и записи справочника, а также предоставлять набор инструментов для поиска пакетов по различным параметрам.
Модуль должен обеспечивать авторизованный доступ операторов для выполнения настройки новых ИС для включения их в информационное взаимодействие с другими КСА, входящих в состав АПК «Безопасный город». Для всех ИС должна обеспечиваться возможность настройки оператором прав доступа к имеющимся в подсистеме интеграции данных справочникам, а также настройки подписок на справочники для ИС, входящих в состав муниципальных и региональных КСА.
Пользовательский интерфейс модуля должен реализовываться на русском языке и должен быть оформлен в едином стиле. Взаимодействие оператора с модулем ведения реестра не должно требовать установки дополнительного ПО на рабочем месте оператора.
Разработка прикладного ПО модуля должна вестись на языках высокого уровня. Используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах.
Выбранная исполнителем платформа разработки должна поддерживать большинство наиболее распространенных СУБД (MySQL или PostgreSQL и пр.).
Дальнейшая поддержка, доработка и расширение модуля должны обеспечиваться путём автоматизированной генерации непосредственно из пользовательского интерфейса документации для разработчиков, учитывающей текущее состояние модуля.
2.2.3. Модуль управления данными подсистемы интеграции данных должен обеспечивать:
- организацию маршрутизации, ведение очередей и гарантированную доставку информации, передаваемой между муниципальными/региональными КСА АПК «Безопасный город» и КСА ЕЦОР;
- преобразование различных форматов и протоколов обмена к виду единого унифицированного протокола;
- формирование базы мета-данных по интегрированным в единую информационную среду КСА сегментов АПК «Безопасный город».
В качестве модуля управления данными должно использоваться программное обеспечение интеграционной шины с открытым исходным кодом.
-
В рамках создания стенда АПК «Безопасный город» должна быть проведена интеграция не менее двух существующих ИС муниципального или регионального уровней с КСА ЕЦОР. Состав интегрируемых ИС и требования к интеграции уточняются на этапе проектирования и согласовываются с Заказчиком.
Способ размещения стенда (в облачном (стороннем) центре обработки данных либо центре обработке данных Заказчика) определяется по итогам обследования и согласовывается с Заказчиком в письменном виде.
|
