Общая информация

Номер извещения: 0174500001124001822

Наименование объекта закупки: На выполнение работ по развитию государственной информационной системы «Аппаратно-программный комплекс «Безопасный город» на территории города Севастополя»

Способ определения поставщика (подрядчика, исполнителя): Открытый конкурс в электронной форме

Конкурс проводится в соответствии с ч. 19 ст. 48 Закона № 44-ФЗ

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РТС-тендер

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: http://www.rts-tender.ru

Размещение осуществляет: Уполномоченный орган ДЕПАРТАМЕНТ УПРАВЛЕНИЯ ДЕЛАМИ ГУБЕРНАТОРА И ПРАВИТЕЛЬСТВА СЕВАСТОПОЛЯ

Контактная информация

Организация, осуществляющая размещение: ДЕПАРТАМЕНТ УПРАВЛЕНИЯ ДЕЛАМИ ГУБЕРНАТОРА И ПРАВИТЕЛЬСТВА СЕВАСТОПОЛЯ

Почтовый адрес: 299011, Г.Севастополь , УЛ. ЛЕНИНА, Д. 2

Место нахождения: 299011, Г.Севастополь , УЛ. ЛЕНИНА, Д. 2

Ответственное должностное лицо: Гагарина В. Л.

Адрес электронной почты: v.gagarina@gs.sev.gov.ru

Номер контактного телефона: 542624-102

Факс: Информация отсутствует

Дополнительная информация: Заказчик : ДЕПАРТАМЕНТ ЦИФРОВОГО РАЗВИТИЯ ГОРОДА СЕВАСТОПОЛЯ Юридический адрес: 299029, г. Севастополь, пр-т Генерала Острякова, д.13. Почтовый адрес: 299011, г. Севастополь, ул. Одесская, д.27 E-mail: dcr@sev.gov.ru Телефон: (8692) 555-990 Ответственное должностное лицо Заказчика: Черноусова Татьяна Романовна

Информация о процедуре закупки

Дата и время окончания срока подачи заявок: 06.05.2024 08:00

Дата рассмотрения и оценки вторых частей заявок на участие в закупке: 08.05.2024

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 13.05.2024

Условия контрактов

Начальная (максимальная) цена контракта: 69115000.00 Российский рубль

Идентификационный код закупки: 242920400386392040100100200016201244

Требования заказчиков

1 ДЕПАРТАМЕНТ ЦИФРОВОГО РАЗВИТИЯ ГОРОДА СЕВАСТОПОЛЯ

Начальная (максимальная) цена контракта: 69115000.00 Российский рубль

Номер принимаемого бюджетного обязательства: 6722005524740000033

Дата принимаемого бюджетного обязательства: 17.04.2024

Информация о сроках исполнения контракта и источниках финансирования

Дата начала исполнения контракта: с даты заключения контракта

Дата окончания исполнения контракта: 28.12.2024

Закупка за счет бюджетных средств: Да

Наименование бюджета: Бюджет города Севастополя

Вид бюджета: Бюджет субъекта Российской Федерации

Код территории муниципального образования: 67000000: Муниципальные образования города федерального значения Севастополя

Закупка за счет собственных средств организации: Нет

Финансовое обеспечение закупки

Всего: - Оплата за 2024 год - Оплата за 2025 год - Оплата за 2026 год - Сумма на последующие годы

69115000.00 - 69115000.00 - 0.00 - 0.00 - 0.00

Этапы исполнения контракта

Финансирование за счет бюджетных средств

Дата начала исполнения этапа - Дата окончания исполнения этапа

с даты заключения контракта - 03.07.2024

Код бюджетной классификации Российской Федерации - Сумма контракта (в валюте контракта)

на 2024 год - на 2025 год - на 2026 год - на 2027 год

840030917101М3912244 - 14615000.00 - 0.00 - 0.00 - 0.00

Итого - 14615000.00 - 0.00 - 0.00 - 0.00

Дата начала исполнения этапа: Дата окончания исполнения этапа

с даты заключения контракта: 03.07.2024

Код бюджетной классификации Российской Федерации: Сумма контракта (в валюте контракта)

Финансирование за счет бюджетных средств

Дата начала исполнения этапа - Дата окончания исполнения этапа

05.06.2024 - 28.12.2024

Код бюджетной классификации Российской Федерации - Сумма контракта (в валюте контракта)

на 2024 год - на 2025 год - на 2026 год - на 2027 год

840030917101М3911244 - 54500000.00 - 0.00 - 0.00 - 0.00

Итого - 54500000.00 - 0.00 - 0.00 - 0.00

Дата начала исполнения этапа: Дата окончания исполнения этапа

05.06.2024: 28.12.2024

Код бюджетной классификации Российской Федерации: Сумма контракта (в валюте контракта)

Место поставки товара, выполнения работы или оказания услуги: г. Севастополь, улица Одесская, д. 27, проспект Генерала Острякова, д. 13 или удаленно, с обеспечением Заказчиком защищенного интернет-канала для доступа к Системе.

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Обеспечение заявки

Требуется обеспечение заявки:

Размер обеспечения заявки: 3455750.00 Российский рубль

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств или независимой гарантии, предусмотренной статьей 45 Федерального закона 44-ФЗ. Выбор способа обеспечения осуществляется участником закупки самостоятельно. Срок действия независимой гарантии должен составлять не менее месяца с даты окончания срока подачи заявок. Участники закупки, являющиеся юридическими лицами, зарегистрированными на территории государства - члена Евразийского экономического союза, за исключением Российской Федерации, или физическими лицами, являющимися гражданами государства - члена Евразийского экономического союза, за исключением Российской Федерации, вправе предоставить обеспечение заявок в виде денежных средств с учетом особенностей, установленных Постановлением Правительства Российской Федерации от 10.04.2023 № 579.

Реквизиты счета для учета операций со средствами, поступающими заказчику

Реквизиты счета для учета операций со средствами, поступающими заказчику: "Номер расчётного счёта"03222643670000007400 "Номер лицевого счёта"05742200550 "Код поступления" Информация отсутствует "БИК"016711001 "Наименование кредитной организации"ОТДЕЛЕНИЕ СЕВАСТОПОЛЬ БАНКА РОССИИ//УФК по г. Севастополю г. Севастополь "Номер корреспондентского счета"40102810045370000056

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации)

ИНН получателя: 9204003863

КПП получателя: 920401001

КБК доходов: 84011610056020000140

ОКТМО: 67312000

Номер единого казначейского счета: 40102810045370000056

Номер казначейского счета: 03100643000000017400

БИК ТОФК: 016711001

Получатель: УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО Г. СЕВАСТОПОЛЮ

Обеспечение исполнения контракта

Требуется обеспечение исполнения контракта:

Размер обеспечения исполнения контракта: 13823000.00 Российский рубль

Порядок обеспечения исполнения контракта, требования к обеспечению: Исполнение контракта может обеспечиваться предоставлением независимой гарантии, соответствующей требованиям статьи 45 Федерального закона 44-ФЗ, или внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику. Способ обеспечения исполнения контракта, срок действия независимой гарантии определяются участником закупки, с которым заключается контракт, самостоятельно. При этом срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии со статьей 95 Федерального закона 44-ФЗ.

Платежные реквизиты: "Номер расчётного счёта"03222643670000007400 "Номер лицевого счёта"05742200550 "Код поступления" Информация отсутствует "БИК"016711001 "Наименование кредитной организации"ОТДЕЛЕНИЕ СЕВАСТОПОЛЬ БАНКА РОССИИ//УФК по г. Севастополю г. Севастополь "Номер корреспондентского счета"40102810045370000056

Обеспечение гарантийных обязательств

Обеспечение гарантийных обязательств не требуется:

Информация о банковском и (или) казначейском сопровождении контракта

Банковское или казначейское сопровождение контракта не требуется

Дополнительная информация: Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Объект закупки

Работы по развитию государственной информационной системы «Аппаратно-программный комплекс «Безопасный город» на территории города Севастополя». Этап 1. Идентификатор: 148746192 - 62.01.11.000 - - - - - Условная единица - 14615000.00 - 14615000.00

Требование к услугам по передаче прав на СПО. ч 1 - Специальное программное обеспечение для видеоанализа (СПО) в модуле видеомониторинга и видеоанализа Системы должно быть реализовано на базе отечественного программного обеспечения (включенного в Единый реестр российских программ для электронных вычислительных машин и баз данных). Требования к СПО распознавания лиц: – СПО распознавания лиц должно содержать функции автоматического анализа цифровых фото- и видеоданных (видеопотоков камер видеонаблюдения и видеофайлов) с детектированием в них образов; – СПО распознавания лиц должно обеспечивать автоматическое детектирование образов при обработке цифровых фотографических изображений, характеристики которых удовлетворяют следующим требованиям: – формат файла: JPEG, PNG; – количество детектируемых объектов, одновременно присутствующих на одном и том же фотоизображении: не более 30; – максимальное перекрытие площади детектируемого объекта на фотоизображении: не менее 50%; – СПО распознавания лиц должно обеспечивать автоматическое детектирование изображения объекта при обработке цифровых видеоданных (видеопотоков камер видеонаблюдения и видеофайлов), характеристики которых удовлетворяют следующим требованиям: – поддерживаемые протоколы вещания потокового видео: RTSP, HTTP(S); – поддерживаемые типы медиаконтейнера: AVI, MKV, MOV, MP4; – поддерживаемые алгоритмы сжатия видеоданных: H.264, H.265, MJPEG; – разрешение кадра: не менее 1920x1080 пикселей; – частота кадров: не менее 25 кадров в секунду; – количество детектируемых объектов, одновременно присутствующих в кадре: не менее 10; – максимальное перекрытие площади детектируемого объекта в кадре: не менее 50%. – Требования к характеристикам видеопотока сформированы на основе технических характеристик видеокамер, имеющихся в распоряжении Заказчика в составе системы видеонаблюдения. - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 2 - – При обработке цифровых видеоданных СПО распознавания лиц должно автоматически отслеживать перемещение (трек) детектируемого образа в кадре и оценивать его интегральный показатель качества с автоматическим выбором и передачей для дальнейшей обработки единственного изображения – наилучшего кадра (кадра видеоряда, в котором детектированное изображения объекта характеризуется наивысшим значением интегрального показателя качества); – СПО распознавания лиц должно предоставлять возможность задания следующих параметров, определяющих построение трека детектируемого изображения объекта: – коэффициента взаимного перекрытия площади изображений объекта, детектированных в рамках одного и того же трека в соседних кадрах цифрового видеоряда; – максимального количества кадров видеоряда для принудительного завершения трека детектируемого изображения объекта; – максимальной допустимой продолжительности прерывания трека детектируемого изображения объекта. – СПО распознавания лиц должно позволять настраивать параметры выбора наилучшего кадра при обработке цифровых видеоданных в соответствии со следующими возможными вариантами: – передача для дальнейшей обработки единственного изображения объекта, характеризующееся наивысшим значением интегрального показателя качества среди всех детектированных в рамках отслеживаемого трека и выбираемое по завершению отслеживаемого трека; – передача для дальнейшей обработки первого детектированного изображения объекта в отслеживаемом треке с последующей передачей нового изображения объекта, детектированного в рамках того же трека по истечении заданного пользователем интервала времени; – передача для дальнейшей обработки первого детектированного изображения объекта в отслеживаемом треке с последующей передачей нового изображения объекта, детектированного в рамках того же трека по истечении заданного пользователем интервала времени и характеризующегося более высоким значением интегрального показателя качества; - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 3 - – При обработке цифровых видеоданных СПО распознавания лиц должно предоставлять возможность настройки следующих параметров, обрабатываемых видеоданных: – минимального и (или) максимального размера детектируемого изображения объекта в кадре; – минимального значения интегрального показателя качества детектированного изображения объекта; – региона интереса – область в кадре, внутри которой детектированные изображения объекта будут оцениваться при выборе наилучшего кадра. – При обработке цифровых видеофайлов СПО распознавания лиц должно автоматически определять фактические дату и время съёмки для каждого детектируемого изображения объекта на основании анализа считываемых из видеофайла метаданных, относящихся к времени формирования видеозаписи, если таковые присутствуют в обрабатываемом файле; – СПО распознавания лиц должно предоставлять возможность явным образом указать дату и время фактического начала съёмки и (или) время смещения фактического начала обрабатываемого видеофайла от начала съёмки и автоматически рассчитывать время регистрации каждого детектируемого изображения объекта на основании введённых пользователем данных; – СПО распознавания лиц должно предоставлять пользователю возможность запроса предобработки цифровых видеоданных: поворота и (или) зеркального отображения изображения; – СПО распознавания лиц должно предоставлять пользователю возможность указать скорость обработки цифрового видеофайла: – с реальной скоростью проигрывания видеоряда; – с повышающим целочисленным коэффициентом относительно реальной скорости проигрывания видеоряда; – с максимально возможной скоростью, определяемой доступными аппаратными ресурсами. – СПО распознавания лиц должно содержать функции автоматического извлечения вектора признаков (построения биометрического шаблона изображения объекта) на основании детектированного на цифровых фото- и видеоданных изображения объекта; - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 4 - – СПО распознавания лиц должно обеспечивать одновременную параллельную обработку цифровых видеоданных (видеопотоков камер видеонаблюдения и видеофайлов); – СПО распознавания лиц должно содержать функции сопоставления двух и более изображений объектов (образов одной и той же природы) на основании сопоставления их биометрических шаблонов с целью исследования их принадлежности одному и тому же объекту. Результатом сопоставления двух образов (векторов признаков) должно быть числовое значение степени схожести, измеряемое на интервале [0, 1] или [0, 100] и возрастающее с подобием: – СПО распознавания лиц должно содержать функцию верификации – сопоставления двух изображений объектов (образов одной и той же природы) с целью исследования их принадлежности одному и тому же объекту; – СПО распознавания лиц должно содержать функцию идентификации – поиска среди некоторого множества изображений объектов (поискового множества) кандидатов, схожих с некоторым контрольным изображением объекта (или множеством контрольных изображений); – При выполнении идентификации СПО распознавания лиц должно позволять ограничивать результирующее множество биометрических кандидатов пороговым значением степени схожести, или количеством элементов результирующего множества, или совокупностью этих показателей. – СПО распознавания лиц должно содержать функцию мониторинга – автоматической идентификации ранг-1 при обработке цифровых видеоданных. К мониторингу предъявляются следующие требования: – СПО распознавания лиц должно предусматривать возможность задания порогового значения степени схожести для отдельной камеры, или для отдельной группы камер, или для отдельного контрольного объекта локальной базы розыска, или для отдельного раздела локальной базы розыска, или для всех обрабатываемых данных локальной базы розыска; - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 5 - – СПО распознавания лиц должно предусматривать возможность уведомления операторов при проведении мониторинга, в том числе с проигрыванием звукового сигнала, при этом должна быть обеспечена возможность включения или отключения звукового сигнала для отдельных контрольных объектов или для отдельного раздела локальной базы розыска; – СПО распознавания лиц должно предусматривать возможность указания определенных контрольных объектов локальной базы розыска, в случае обнаружении совпадения с которыми в результате мониторинга записи базы данных не будут автоматически создаваться при обработке видеоданных. – СПО распознавания лиц должно иметь возможность автоматически группировать объекты при обработке цифровых видеоданных, принадлежащие одному и тому же объекту, зарегистрированные одной и той же группой камер в течение одного прохода (заданного интервала времени в секундах, но не более 5 минут). Должна быть предусмотрена возможность просмотра списка сгруппированных объектов; – СПО распознавания лиц должно предоставлять функцию автоматической кластеризации объектов – аналитической группировки регистрируемых при обработке цифровых видеоданных объектов, предположительно принадлежащих одной и той же сущности, на основе их автоматического сопоставления между собой. Должна быть предусмотрена возможность просмотра списка кластеризации объектов; – СПО распознавания лиц должно обеспечивать возможность подсчета объектов при обработке видеопотоков с камер, одновременно находящихся в заданной зоне наблюдения одной или нескольких камер с заданной периодичностью; – СПО распознавания лиц должно позволять ограничивать наблюдаемую область в кадре путем задания региона интереса. Объекты, подлежащие подсчету, должны учитываться только в случае их нахождения внутри очерченного региона; - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 12 - Лицензиат – город Севастополь в лице Департамента цифрового развития города Севастополя. Права должны передаваться на весь срок действия исключительных прав. Территория действия неисключительных передаваемых прав: территория города Севастополя. - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 7 - – СПО ОС должно обеспечить функцию анализа ближайшего круга потенциальных контактов для выбранного объекта (лица) на основании присутствия в одном кадре в течение N секунд (N 10): – Анализ ближайшего круга контактов должен проводиться как в отношении известного индивида, так и в отношении неизвестного человека; – Для каждого индивида, обнаруженного в круге ближайших контактов исследуемого человека, должна быть предусмотрена возможность исследования его ближайшего круга – вплоть до 2-го уровня контактов от исследуемого индивида. Выполнение требований по передаче цифровых видеоданных и цифровых фотографических изображений находится в зоне ответственности Заказчика и не входит в объём услуг, оказываемых в рамках текущего Технического задания. Требование к СПО распознавания силуэтов: – СПО ОС должно обеспечивать автоматическое детектирование изображения силуэта человека при обработке цифровых фотографических изображений, характеристики которых удовлетворяют следующим требованиям: – минимальный размер детектируемого изображения силуэта человека по горизонтали: не более 30 пикселей; – максимальные отклонения детектируемого изображения силуэта человека от фронтального типа изображения силуэта: не менее 90° в вертикальной плоскости, не менее 45° во фронтальной плоскости, без ограничений в горизонтальной плоскости; – СПО ОС должно обеспечивать автоматическое детектирование изображения силуэта человека при обработке цифровых видеоданных (видеопотоков камер видеонаблюдения и видеофайлов), характеристики которых удовлетворяют следующим требованиям: – минимальный размер детектируемого изображения силуэта человека по горизонтали: не более 30 пикселей; – максимальные отклонения детектируемого изображения силуэта человека от фронтального типа изображения силуэта: не менее 90° в вертикальной плоскости, не менее 45° во фронтальной плоскости, без ограничений в горизонтальной плоскости; - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 8 - – Для каждого детектированного в цифровых видеоданных изображения силуэта человека СПО ОС должно обеспечивать предсказание значений следующих дополнительных атрибутов: – тип головного убора; – тип верха одежды; – вид верха одежды; – цвет верха одежды; – тип низа одежды; – цвет низа одежды. – СПО ОС должно обеспечивать возможность анализа области при обработке видеопотоков с камер, одновременно находящихся в заданной зоне наблюдения одной или нескольких камер. – СПО ОС должно позволять ограничивать наблюдаемую область в кадре путем задания региона интереса. Изображения силуэтов, подлежащие анализу, должны учитываться только в случае их нахождения внутри очерченного региона. – СПО ОС должно предоставлять оператору возможность изучения наблюдаемой зоны, когда количество объектов (изображений силуэтов) в регионе интереса превысило (или уменьшило) некоторое выбранное оператором пороговое значение за заданный период времени. – СПО ОС должно предоставлять оператору возможность изучения наблюдаемой зоны с помощью гибкого настраиваемого расписания с указанием дней недели и времени. Требование к СПО распознавания государственного регистрационного знака транспортных средств (СПО распознавания ГРЗ): – СПО ОС должно обеспечивать автоматическое детектирование изображения ТС при обработке цифровых фотографических изображений, характеристики которых удовлетворяют следующим требованиям: – минимальный размер детектируемого изображения ТС по горизонтали: не более 80 пикселей; – минимальный размер детектируемого изображения государственного регистрационного знака (далее ГРЗ) ТС по горизонтали: не более 100 пикселей; – минимальный размер детектируемого изображения ТС для детектирования государственного регистрационного знака (далее ГРЗ) ТС по горизонтали: не более 340 пикселей; – максимальные отклонения детектируемого изображения ТС от фронтального типа изображения ТС: не менее 45° в вертикальной плоскости, не менее 30° во фронтальной плоскости, без ограничений в горизонтальн.плоск-ти; - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 9 - – СПО ОС должно обеспечивать автоматическое детектирование изображения ТС при обработке цифровых видеоданных (видеопотоков камер видеонаблюдения и видеофайлов), характеристики которых удовлетворяют следующим требованиям: – минимальный размер детектируемого изображения ТС по горизонтали: не более 80 пикселей; – минимальный размер детектируемого изображения государственного регистрационного знака (далее ГРЗ) ТС по горизонтали: не более 100 пикселей; – минимальный размер детектируемого изображения ТС для детектирования государственного регистрационного знака (далее ГРЗ) ТС по горизонтали: не более 340 пикселей; – максимальные отклонения детектируемого изображения ТС от фронтального типа изображения ТС: не менее 45° в вертикальной плоскости, не менее 30° во фронтальной плоскости, без ограничений в горизонтальной плоскости; – Для каждого детектированного в цифровых видеоданных изображения ТС СПО ОС должно обеспечивать предсказание значений следующих дополнительных атрибутов: – ГРЗ с указанием страны и региона; – марка; – модель; – тип кузова; – цвет; – тип для спецтранспорта. В соответствии с постановлением Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд», программное обеспечение должно быть включено в реестр российского программного обеспечения сведений о таких программах для электронных вычислительных машин и базах данных (https://reestr.digital.gov.ru/) или в реестр евразийского программного обеспечения сведений о таких программах для электронных вычислительных машин и базах данных (https://eac-reestr.digital.gov.ru/reestr/). Лицензиат – город Севастополь в лице Департамента цифрового развития города Севастополя. Права должны передаваться на весь срок действия исключительных прав. Территория действия неисключительных передаваемых прав: территория города Севастополя. - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 10 - Объем передаваемых прав: – использование программного обеспечения посредством его воспроизведения; – осуществление действий, в целях нормального функционирования программного обеспечения и получения определенного результата, в соответствии с его назначением; – запись и хранение программного обеспечения в памяти электронно-вычислительных машин; – проведение адаптации программного обеспечения путем настроек, предусмотренных технической документацией па программное обеспечение, в целях обеспечения его работы на конкретных технических средствах и/или в конкретной информационной системе. Передача неисключительных прав в соответствии с настоящим разделом должна быть осуществлена в соответствии с требованиями Гражданского кодекса Российской Федерации. При передаче прав должны быть соблюдены авторские и иные права третьих лиц. Подрядчик (Лицензиар) гарантирует, что обладает всеми правами на передачу Государственному заказчику прав в соответствии с требованиями настоящего раздела. В случае, если к Государственному заказчику по вине Подрядчика (Лицензиара) будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик (Лицензиар) принимает на себя такие претензии и иски и возмещает Государственному заказчику все расходы и весь ущерб, понесенный в связи с ними. Нарушение условий настоящего раздела настоящего Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Государственного контракта (в т.ч. настоящего Технического задания), является нарушением существенных условий Государственного контракта, основанием для отказа в приемке результатов услуг и применении штрафа за ненадлежащее исполнение Государственного контракта. - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 11 - Для обеспечения возможности эффективного применения функциональности СПО в Системе Подрядчиком в рамках первого этапа работ должна быть разработана и передана Заказчику техническая документация (Частное техническое задание на установку и настройку СПО), содержащая описания принятых в Системе протоколов и интерфейсов, и требования к установке и настройке СПО, выполнение которых в рамках второго этапа работ позволит СПО нормально функционировать в операционной и информационной среде Системы. Частное техническое задание согласовывается и утверждается Заказчиком в рамках сроков оказания услуг по первому этапу работ. Требования к установке, настройке и использованию СПО как компоненты Системы должны быть спроектированы и реализованы таким образом, чтобы обеспечивались: – кроссплатформенность - возможность работы в среде операционных систем семейства LINUX; – функциональная полнота – реализация, подлежащих автоматизации функций объектов автоматизации; – возможность адаптации и настройки СПО в Системе с учетом функционала СПО и Системы; – создание и ведение словарей, справочников, классификаторов и унифицированных форм документов, параллельный доступ пользователей к ним; – эргономичность – обеспечение удобства и унификации пользовательского интерфейса Российской Федерации; – защита от ошибочных действий оператора (пользователя). В соответствии с постановлением Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд», программное обеспечение должно быть включено в реестр российского программного обеспечения сведений о таких программах для электронных вычислительных машин и базах данных (https://reestr.digital.gov.ru/) или в реестр евразийского программного обеспечения сведений о таких программах для электронных вычислительных машин и базах данных (https://eac-reestr.digital.gov.ru/reestr/). - - Значение характеристики не может изменяться участником закупки

Требование к услугам по передаче прав на СПО. ч 6 - – Функция подсчета должна предоставлять возможность изучения наблюдаемой зоны в определенные моменты времени, когда количество распознанных объектов в регионе интереса превысило некоторое выбранное оператором пороговое значение; – СПО распознавания лиц должно обеспечивать автоматическое детектирование изображения лица человека при обработке цифровых фотографических изображений, характеристики которых удовлетворяют след.требованиям: – мин.размер детектируемого изображения лица человека по горизонтали: не более 30 пикселей; – макс.отклонения детектируемого изображения лица человека от фронтального типа изображения лица, трактуемого в соответствии с разделом 7 ГОСТ Р ИСО/МЭК 19794–5–2013: не менее 90° в вертикальной плоскости, не менее 30° во фронтальной плоскости, не менее 30° в горизонтальной плоскости; – СПО распознавания лиц должно обеспечивать автоматическое детектирование изображения лица человека при обработке цифровых видеоданных (видеопотоков камер видеонаблюдения и видеофайлов), характеристики которых удовлетворяют следующим требованиям: – минимальный размер детектируемого изображения лица человека по горизонтали: не более 30 пикселей; – максимальные отклонения детектируемого изображения лица человека от фронт.типа изображения лица, трактуемого в соответствии с разделом 7 ГОСТ Р ИСО/МЭК 19794–5–2013: не менее 90° в вертикальной плоскости, не менее 30° во фронтальной плоскости, не менее 30° в горизонтальной плоскости; – Для каждого детектированного в цифровых видеоданных изображения лица человека СПО распознавания лиц должно обеспечивать предсказание значений след. доп.атрибутов: – пол индивида; – возраст индивида; – эмоциональное выражение индивида; – наличие бороды; – наличие очков (с разд. на солнцезащитные и диоптрические); – поворот и наклон головы; – наличие защитной медицинской маски (с разделением на правильно и неправильно надетую); – наличие попытки подлога (т.н. определение «спуфинга» (spoofing), проверка на «живость» или liveness detection). - - Значение характеристики не может изменяться участником закупки

Работы по развитию государственной информационной системы «Аппаратно-программный комплекс «Безопасный город» на территории города Севастополя». Этап 2. Идентификатор: 148746193 - 62.01.11.000 - - - - - Условная единица - 54500000.00 - 54500000.00

Общие требования к результатам выполненных работ - В рамках выполнения Работ по развитию Системы должны быть произведены модернизация и обновление программного обеспечения Системы. При выполнении Работ, не допускается замена программного обеспечения Системы в целом и/или любых ее компонентов, исключительные права на которые принадлежат государственному заказчику по результатам приемки выполненных работ по Государственным контрактам на создание и развитие Системы - от 10.11.2020 № ОК/4 (реестровый номер Государственного контракта в единой информационной системе в сфере закупок https://zakupki.gov.ru - 2920400386320000035) и от 24.11.2021 № ЭА/21_23 (реестровый номер Государственного контракта в единой информационной системе в сфере закупок https://zakupki.gov.ru - 2920400386321000030). Действующие инструкции и руководства администратора АПК «Безопасный город» и инструкции пользователя АПК «Безопасный город» должны быть актуализированы и дополнены в соответствии с обновленным функционалом Системы по итогам выполнения работ по развитию Системы. Заказчик обладает исключительными правами на Систему. - - Значение характеристики не может изменяться участником закупки

Требования к инструктажу - Инструктаж пользователей по работе с обновленными компонентами Системы проводится в соответствии с разработанной Программой инструктажа пользователей и администраторов. Допускается проведение инструктажа в формате вебинара. Инструктаж допустимо проводить в очной форме на рабочем месте пользователя, в групповой форме, удаленно в режиме онлайн-конференции с предоставлением записей вебинаров Заказчику. В ходе проведения инструктажа должны быть проинструктированы все сотрудники, согласно предоставленным Заказчиком спискам. В группы инструктажа должны входить сотрудники, ответственные за работу с обновленными компонентами Системы, администраторы Системы. Организация инструктажа проводится по следующей схеме: – Подрядчик согласовывает с Заказчиком дату и время проведения инструктажа, подготавливает План и программу инструктажа пользователей и администраторов Системы; – Подрядчик передает Заказчику методические материалы по вопросам использования обновленной функциональности Системы; – Заказчик оповещает участников инструктажа, контролирует присутствие на инструктаже ответственных лиц; – По результатам проведенного инструктажа Подрядчик предоставляет Заказчику Отчет о проведении инструктажа. - - Значение характеристики не может изменяться участником закупки

Требования к эргономике и технической эстетике - Графический интерфейс Системы по результатам выполнения работ должен отвечать следующим требованиям и поддерживать функции: – отображение на экране преимущественно необходимой для решения текущей прикладной задачи информации; – максимальная унификация процедур реализации аналогичных функций в различных компонентах Системы; – использование функциональных и «горячих» клавиш, при этом на экране должна находиться подсказка о назначении таких клавиш; – отображение на экране хода длительных процессов обработки; – все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть на русском языке. – Процедуры ввода данных должны отвечать следующим требованиям: – пользователь должен иметь возможность гибко контролировать ввод данных: просматривать введенные данные на мониторе, производить их корректировку или отказаться от ввода; – при вводе должны использоваться справочники для контроля вводимых данных и списки допустимых значений; – корректная обработка ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных, с выводом на экран соответствующего сообщения; – обеспечение возможности ввода значений по умолчанию. - - Значение характеристики не может изменяться участником закупки

Требование к развитию межсистемного взаимодействия - В целях обеспечения эффективного межсистемного и межведомственного взаимодействия ЕДДС, территориальных служб федеральных органов исполнительной власти, региональных органов исполнительной власти города Севастополя должен быть, разработан функционал автоматизированного сопряжения Системы с информационными системами: – автоматизированной информационно-управляющей системой РСЧС (АИУС РСЧС); – системой пожарного мониторинга на социально-значимых объектах - Система передачи извещений «ОКО» (СПИ ОКО); – системой МКА ЖКХ (модуль АИС «Реформа ЖКХ»); Заказчик в течении 5 рабочих дней с даты подписания государственного контракта передает Подрядчику описания протоколов интеграции (API, WSDL, REST). Линии связи и телекоммуникационные сети для обеспечения информационного взаимодействия между Системой и внешними информационными системами организовываются и предоставляются Заказчиком. Предварительные испытания реализованного функционала автоматизированного сопряжения в части информационного взаимодействия проводятся Заказчиком в соответствии с Программой и методикой предварительных испытаний, разработанной Подрядчиком и утвержденной Заказчиком, путем выполнения предусмотренных в программе тестов. При условии невозможности проведения предварительных испытаний созданного функционала Системы с интегрируемой системой, ввиду неготовности сторонней информационной Системы, или отсутствия иной организационно-технической возможности не предусмотренной техническим заданием и государственным контрактом, по согласованию с Заказчиком предварительные испытания могут проводиться с использованием разработанной/предоставленной подрядчиком специального программного обеспечения, имитирующего поведение сопрягаемой сторонней системы (далее – эмулятор), позволяющего в полной мере оценить функционал, описанный в настоящем пункте Технического задания. - - Значение характеристики не может изменяться участником закупки

Требования к проведению интеграционных работ с Автоматизированной информационно-управляющей системой РСЧС (АИУС РСЧС) - Характеристика интегрируемой системы АИУС РСЧС и объем интеграции. Оператор системы -ФГБУ "ИАЦ МЧС России". Функциональные задачи (функции системы): Обеспечение информационного взаимодействия участников информационной системы в цифровом формате (сбор, учет, хранение, обработка, анализ, а также предоставление информации); осуществление мер информационной поддержки органов управления РСЧС для принятия решений в области защиты населения и территорий от последствий чрезвычайных ситуаций. Объем интеграции: Передача данных из АУИС РСЧС в АПК БГ посредством интеграции: - данных о термических точках: появление новой термической точки, изменение статуса существующей термической точки. Передача данных из АПК БГ в АУИС РСЧС посредством интеграции: - об обработке инцидентов по выявленным термическим точкам; - данных о происшествиях; - данных о силах и средствах постоянной готовности, в том числе привлекаемых к ликвидации последствий ЧС (проведению аварийно-восстановительных работ) в городе Севастополе. На этапе проведения аналитического обследования Подрядчиком должен быть разработан и направлен Заказчику на согласование интеграционный профиль для проведения интеграции. Интеграционный профиль должен содержать в себе исчерпывающий перечень данных, подлежащих передаче, форматы и расписание обмена информацией. Интеграционный профиль должен быть согласован и утвержден Заказчиком в течение 14 рабочих дней после получения. - - Значение характеристики не может изменяться участником закупки

Требования к проведению интеграционных работ с системой передачи извещений «ОКО» - Характеристика интегрируемой системы передачи извещений «ОКО» (СПИ ОКО) и объем интеграции: Оператор системы -Общество с ограниченной ответственностью "СРО ВДПО". Функциональные задачи (функции системы): Пожарный мониторинг на социально-значимых объектах города Севастополя. Объем интеграции: Система должна получать и обрабатывать информацию об объектах следующую типа: - Данные устройства; - Срабатывания устройств. Информация об устройствах должна содержать: - наименование; - состояние; - информация об объекте, на котором расположено устройство. Информация о срабатываниях устройств должна содержать: - данные устройства, на котором произошло срабатывание; - дата и время фиксации; - статус (характеристика сигнала) срабатывания. На этапе проведения аналитического обследования Подрядчиком должен быть разработан и направлен Заказчику на согласование интеграционный профиль для проведения интеграции. Интеграционный профиль должен содержать в себе исчерпывающий перечень данных, подлежащих передаче, форматы передачи информации. Интеграционный профиль должен быть согласован и утвержден Заказчиком в течение 14 (четырнадцати) рабочих дней после получения. - - Значение характеристики не может изменяться участником закупки

Требование к развитию межсистемного взаимодействия с МКА ЖКХ (модуль АИС «Реформа ЖКХ»). ч 1 - В рамках проведения работ по развитию межсистемного взаимодействия между АПК БГ города Севастополя и АИС «Реформа ЖКХ» (Система МКА ЖКХ) должен быть реализован метод получения из МКА ЖКХ информации из анкет домов по городу Севастополю. Характеристика Системы МКА ЖКХ (модуль АИС «Реформа ЖКХ») и объем интеграции. Функциональные задачи (функции системы): Назначением Системы МКА ЖКХ является обеспечение ситуационного центра Минстроя России и органов исполнительной власти субъектов Российской Федерации, уполномоченных на осуществление государственной политики, нормативно правового регулирования и надзора в сфере ЖКХ, оперативной, полной и достоверной информацией о возникающих авариях и инцидентах в сфере ЖКХ на территории Российской Федерации, планируемых и реализованных мероприятиях по их устранению. Объем интеграции (какие данные требуется отправлять в АПК БГ):Система МКА ЖКХ должна по запросу АПК БГ передавать следующую информацию (обязательный перечень информации, не ограничиваясь): 1. Адрес дома; 2. ИНН управляющей организации; 3. Дата последнего изменения анкеты; 4. Общая площадь, кв.м; 5. Общая площадь дома, в т.ч. жилых помещений, кв.м; 6. Общая площадь дома, в т.ч. нежилых помещений, кв.м; 7. Общая площадь дома, в т.ч. помещений, входящих в состав общего имущества, кв.м.; 8. Признак аварийности (да/нет); 9. Год ввода в эксплуатацию; 10. Год постройки; 11. Тип дома; 12. Количество этажей, наибольшее; 13. Количество этажей, наименьшее; 14. Количество подъездов; 15. Количество лифтов; 16. Количество помещений; 17. Количество помещений, в том числе, жилых; 18. Количество помещений, в том числе, нежилых, ед.: 19. Тип фундамента; 20. Тип перекрытий; 21. Материал несущих стен; 22. Тип системы электроснабжения; 23. Тип системы теплоснабжения; 24. Тип системы горячего водоснабжения; 25. Тип системы холодного водоснабжения; 26. Тип системы водоотведения; 27. Тип системы газоснабжения; 28. Тип системы вентиляции; 29. Тип системы пожаротушения; 30. Тип системы водостоков; - - Значение характеристики не может изменяться участником закупки

Требование к развитию межсистемного взаимодействия с МКА ЖКХ (модуль АИС «Реформа ЖКХ»). ч 2 - 31. Тип фасада; 32. Тип крыши; 33. Тип кровли. На этапе проведения аналитического обследования Подрядчиком должен быть разработан и направлен Заказчику на согласование интеграционный профиль для развития (обновления) интеграции. Интеграционный профиль должен содержать в себе исчерпывающий перечень данных, подлежащих передаче, форматы передачи информации. Интеграционный профиль должен быть согласован и утвержден Заказчиком в течение 14 (четырнадцати) рабочих дней после получения. Данные, полученные от системы МКА ЖКХ в АПК БГ должны отображаться в карточках объектов. Полный перечень полей карточки объектов, вновь разработанных и доработанных для отображения в системе данных из МКА ЖКХ, должен быть сформирован и согласован с Заказчиком на этапе аналитического обследования. - - Значение характеристики не может изменяться участником закупки

Требования к развитию форм событий, инцидентов, поручений, плановых работ. ч 1 - В рамках работ по развитию должна быть обновлена электронная форма поручения в Системе в части: – Поле «комментарий исполнителя» должно быть обязательным для заполнения (система не должна позволять изменить статус поручения без заполнения поля «комментарий исполнителя»); – Текстовые наименования полей формы должны быть визуально выделены относительно текста, отображаемого в этих полях. В рамках работ по развитию должна быть обновлена форма инцидента в части: – Текстовые наименования полей формы должны быть визуально выделены относительно текста, отображаемого в этих полях. В рамках работ по развитию должны быть обновлены формы инцидента и плановой работы в части: – расширения инструментов для массового добавления зданий в зону действия происшествия: – в метод добавления адреса «Указать на карте» должна быть добавлена возможность указания не только координат, но и полигона для дальнейшего определения по нему списка адресов, попавших под действие инцидента или плановой работы; – должна быть добавлена в метод добавления адреса «Вручную» возможность подбора по названию улицы списка домов, относящихся к указанной улице, с возможностью фильтрации по признаку чётная/ нечётная сторона, а также указания нескольких домов для одной улицы; – для каждого полученного адреса должен быть отправлен запрос в подсистему управления справочниками и классификаторами для получения адреса в формате «ГАР». Полученный список адресов должен отобразиться в таблице с адресами, попавшими в зону действия инцидента или плановой работы. Если соответствующий адрес в формате «ГАР» не был найден, то в таблице должен отобразиться адрес в формате текстовой строки, без привязки к адресной системе; – добавления в таблицу с адресами, попавшими в зону действия инцидента или плановой работы, возможности просмотра характеристик здания при наличии для указанного адреса соответствующей записи в реестре зданий (требования к реестру описаны в п.5.4.4.8); - - Значение характеристики не может изменяться участником закупки

Требования к развитию форм событий, инцидентов, поручений, плановых работ. ч 2 - – отображения на карте в разделе «Местоположение» адресов, попавших в зону действия инцидента или плановой работы. Способ отображения – геометки или линии – должен зависеть от выбранных настроек при добавлении адресов в зону действия, цвета линии или геометок должны зависеть от категории типа инцидента или плановой работы. У пользователя должна быть возможность сохранить скриншот данной карты. В рамках развития Системы с целью оптимизации работы с событиями и происшествиями, в Системе должна быть организована возможность учета критериев информации о чрезвычайных ситуациях природного и техногенного характера при создании и редактировании карточек событий и происшествий. Перечень критериев и типов критерий должен соответствовать Приказу МЧС России от 5 июля 2021 г. № 429 «Об установлении критериев информации о чрезвычайных ситуациях природного и техногенного характера». Полный перечень критериев, адаптированный для использования в Системе должен быть предоставлен заказчиком на этапе аналитического обследования. В формах создания и редактирования карточек событий и происшествий должны быть также добавлены новые признаки «Угроза ЧС» и «ЧС» для обеспечения возможности ранжирования важности происшествий при работе с ними. В личных кабинетах ЦУКС и ЕДДС должна быть обеспечена возможность фильтрации событий и происшествий с установленным признаком «Угроза ЧС» и «ЧС». Также должна быть обеспечена возможность визуального отображения событий и происшествий с установленным признакам «Угроза ЧС» и «ЧС», отличающегося от стандартного отображения событий и происшествий, на картографической подложке. - - Значение характеристики не может изменяться участником закупки

Требования к развитию карточки инцидента для вывода информации о ближайшем ВПО - Для принятия решений по реагированию в случае возникновения ЧС и происшествий, с целью эвакуации или размещению людей в рамках подсистемы поддержки принятия решений в карточку инцидента должен быть добавлен раздел «Ближайшие ВПО». В форме редактирования инцидента, в разделе «Ближайшие ВПО» должен выводится перечень ВПО, в зоне действия которых произошел инцидент. Перечень данных о ВПО должен передаваться в карточку инцидента, посредством подсистемы интеграции данных, из справочника «Временные пункты обогрева» подсистемы справочников и классификаторов. В форме редактирования инцидента раздел «Ближайшие ВПО» должен выводится для заранее настроенного перечня типов КСиП. Полный перечень типов КСиП и соответствующий перечень детализации КСиП, для которого необходимо настроить вывод раздела «Ближайшие ВПО» в карточке инцидента должен быть сформирован на этапе аналитического обследования. - - Значение характеристики не может изменяться участником закупки

Требования к развитию карточки инцидента и поручения для вывода информации о ближайших водоисточниках - Для принятия решений по реагированию в случае возникновения ЧС и происшествий, в рамках подсистемы поддержки принятия решений, в карточку инцидента и поручения должен быть добавлен раздел «Информация о водоисточниках». В форме редактирования инцидента и поручения, в разделе «Информация о водоисточниках» должен выводится перечень водоисточников, которые находятся в радиусе 500 м. от места возникновения ЧС или происшествия. Перечень данных о исправных водоисточниках должен передаваться в карточку инцидента и поручения, посредством подсистемы интеграции данных, из справочника «Водоисточники» подсистемы справочников и классификаторов. В форме редактирования инцидента и поручения раздел «Информация о водоисточниках» должен выводится для заранее настроенного перечня типов КСиП. Полный перечень типов КСиП и соответствующий перечень детализации КСиП, для которого необходимо настроить вывод раздела «Информация о водоисточниках» в карточке инцидента и поручения должен быть определен на этапе аналитического обследования. - - Значение характеристики не может изменяться участником закупки

Требования к развитию работы с реестрами. ч 1 - В разделе «Сводные реестры» должен быть обновлен реестр «События». Реестр «События» должен содержать следующий набор данных (с возможностью сортировки): – Номер события; – Источник; – Тип КСиП; – Адрес КСиП; – Время возникновения КСиП; – Время создания события; – Срочно; – Номер инцидента; – Заявитель; – Оператор; – Состояние; – Причины закрытия. Сортировка реестра по умолчанию должна быть по полю «Время создания события». При нажатии на запись реестра должна открываться Стандартная форма события (с возможностью редактирования событий в соответствие с правами доступа). Записи на странице реестра должны обновляться автоматически каждые 30 секунд, отображая новые созданные в Системе записи, при этом сохраняя заданную пользователем фильтрацию и сортировку. В реестре должна быть реализована возможность выгрузки записей в форматах: xls, xlsx, csv. В разделе «Администрирование» должен быть доработан реестр «План и сценарий реагирования»: 1) В реестре должна быть реализована фильтрация по следующим параметрам: – Тип КСиП (выпадающий список с типами КСиП); – Детализация КСиП (данные в выпадающем списке должны предоставлять возможность выбора значения, относящееся к ранее выбранному значению «Тип КСиП» в соответствие с настройками в справочнике «Детализация КСиП»); – Параметры типов организации (данные для выпадающего списка должны соответствовать атрибуту «Тип организаций» справочника «Параметры типов организаций»); – Тип происшествия (данные для выпадающего списка: Инцидент, Неисправность, Плановая работа, Поручение – набор данных должен быть уточнён на этапе реализации); 2) В реестре должна быть обеспечена возможность фильтрации по нескольким значениям для параметров, указанных в п 1. В разделе «Сводные реестры» в подразделе «События» должна быть обеспечена возможность фильтрации по нескольким значениям для следующих полей: – Состояние события; – Ответственный пользователей; – ФИО заявителя; – Тип КСиП; – Источник. - - Значение характеристики не может изменяться участником закупки

Требования к развитию работы с реестрами. ч 2 - В разделе «Сводные реестры» в подразделе «Поручения» должна быть обеспечена возможность фильтрации по нескольким значениям для следующих полей: – Состояние события; – Организация, создавшая поручение; – Ответственная организация по поручению; – Тип КСиП. В разделе «Сводные реестры» в подразделе «Донесения» должна быть обеспечена возможность фильтрации по нескольким значениям для следующих полей: – Состояние; – Типы донесения. В разделе «Сводные реестры» в подразделе «Режимы функционирования» должна быть обеспечена возможность фильтрации по нескольким значениям для следующих полей: – Состояние; – Тип. В разделе «Сводные реестры» в подразделе «Метеоданные» должна быть обеспечена возможность фильтрации по нескольким значениям для следующих полей: – Облачность; – Вид осадков; – Состояние приземного слоя атмосферы. В рамках развития Системы работы с реестрами должны быть проведены работы по изменению цвета линии прокрутки (справа от реестра) реестров на более тёмный в следующих разделах: – Сводные реестры (все вложенные подразделы); – Справочники (все вложенные справочники). - - Значение характеристики не может изменяться участником закупки

Требования к созданию функционала прогнозирования и оперативного расчета по уничтожения взрывоопасных предметов времён ВОВ. ч 1 - В рамках развития модуля анализа и прогнозирования кризисных ситуаций и происшествий подсистемы поддержки принятия решений в Системе должна быть реализована расчетная задача «Обезвреживание ВОП времен ВОВ», согласно методическим рекомендациям «Временная инструкция по порядку организации и проведения аварийно-спасательных работ при ликвидации чрезвычайных ситуаций, связанных с обнаружением взрывоопасных предметов», и алгоритму расчетной задачи в соответствии с методическими рекомендациями № ДЗ -17-132 ПБ от 05.10.2020 с учётом массы заряда взрывчатого вещества для уничтожения основных типов взрывчатых веществ. Для запуска расчетной задачи должна быть обеспечена возможность ввода следующих начальных данных: – тип грунта: – песчаный; – глинистый; – насыпной/почвенный; – водонасыщенный; – масса взрывчатого вещества, кг; – положение боеприпаса: – "Углубилась в грунт", с возможностью конкретизации: «Углублен на свою высоту» (да/нет); – "Находится на поверхности земли"; – углубление, в м. (при выбранном значении положения боеприпаса, равном "Углубилась в грунт"); – тип взрывчатого вещества: – ФАБ; – АС. После выполнения расчетной задачи, на картографической подложке должна выделяться графическим отображением окружностей опасные зоны: – зона действия сейсмически опасной зоны; – зона поражения УВВ (ударно взрывная волна); – зона разлета осколков. - - Значение характеристики не может изменяться участником закупки

Требования к созданию функционала прогнозирования и оперативного расчета по уничтожения взрывоопасных предметов времён ВОВ. ч 2 - По результатам выполнения расчётной задачи в Системе должны быть доступны для просмотра следующие данные: – количество домов: – в зоне действия сейсмически опасной зоны; – в зоне поражения УВВ (ударно взрывная волна); – в зоне разлета осколков; – суммарное количество домов в опасной зоне; – количество важных объектов: – в зоне действия сейсмически опасной зоны; – в зоне поражения УВВ (ударно взрывная волна); – в зоне разлета осколков; – суммарное количество важных объектов в опасной зоне; – количество населения: – в зоне действия сейсмически опасной зоны; – в зоне поражения УВВ (ударно взрывная волна); – в зоне разлета осколков; – суммарное количество населения в опасной зоне. В Системе должна быть реализована возможность выгрузки на локальное рабочее место пользователя в формате .xls, отчета с результатами выполнения расчётной задачи. На этапе проведения аналитического обследования Подрядчиком должен разработать и направить Заказчику на согласование перечень данных отображаемых в системе по результатам выполнения расчетной задачи и форму отчета. Документ с данными должен быть согласован и утвержден Заказчиком в течение 14 (четырнадцати) рабочих дней после получения. Для использования данных в расчете, Подрядчиком должна быть обеспечена возможность, посредством подсистемы интеграции данных, получать данные с интегрированной системы начисления и ведение паспортного стола (при обеспечении организационной и технической возможностей) для дальнейшего вывода количества населения в пределах опасной зоны по результатам выполнения расчётной задачи «Обезвреживание ВОП времен ВОВ». - - Значение характеристики не может изменяться участником закупки

Требования к созданию реестра расчетных задач. ч 1 - Для обеспечения возможности быстрого запуска расчетных задач, реализованных в Системе, без привязки к инциденту, а также обеспечения возможности повторного обращения к результатам ранее выполненных расчетных задач, в Системе должен быть реализован сводный реестр «Расчетные задачи». Страница реестра должна содержать перечень запускаемых пользователем расчетных задач модуля анализа и прогнозирования кризисных ситуаций и происшествий подсистемы поддержки принятия решений. На странице реестра по каждой расчетной задаче должны отображаться как минимум следующие данные: – риск для прогнозирования; – наименование расчетной задачи; – дата запуска. На странице реестра должна быть обеспечена возможность запуска следующих расчетных задач: – авария на химически опасном объекте (задача реализована в Системе); – разрушение химически опасного объекта (задача реализована в Системе); – время подхода облака АХОВ к заданной точке (задача реализована в Системе); – оценка последствий лесных пожаров (задача реализована в Системе); – оценка последствий техногенных пожаров: площадь техногенного пожара/ расстояние, пройденное фронтом пожара (задача реализована в Системе); – обезвреживание ВОП времен ВОВ (задача должна быть реализована в соответствие с требованиями настоящего Технического задания). Состав полей формы создания расчетной задачи должен меняться в зависимости от значения риска для прогнозирования и выбранной расчетной задачи. - -

Требования к созданию реестра расчетных задач. ч 2 - Запись расчетной задачи должна обладать следующими возможностями: – просмотр начальных данных для выполнения расчетной задачи, введенные в форме создания, без возможности редактирования; – просмотр результатов расчетной задачи; – возможность скачивания отчета, сформированного по результатам выполнения расчетной задачи; – возможность перехода к форме инцидента, привязанного к расчетной задаче (при условии наличия такой связи). На странице реестра должен быть обеспечена возможность фильтрации данных по записям реестра по следующим параметрам: – риск для прогнозирования; – наименование расчетной задачи; – дата запуска. Перечень запускаемых пользователем расчетных задач, а также возможность запустить расчетную задачу без привязки к инциденту, должны быть доступны в личном кабинете ЦУКС на рабочем столе оператора. При работе с записями расчетных задач через личный кабинет ЦУКС должна быть обеспечена возможность фильтрации записей по наименованию расчетной задачи и дате запуска и возможность просмотра детальной карточки расчетной задачи с начальными данными и результатами выполнения. Визуализация результатов выполнения расчетной задачи должна отображаться на картографической подложке. В Системе должна быть обеспечена возможность настройки отображения данных о результатах конкретных расчетных задач в Личном кабинете ЕДДС. Данные должны быть доступны для просмотра сотрудникам ЕДДС как на странице реестра, так и в карточках инцидентов, для которых будет выполнятся расчетные задачи. - - Значение характеристики не может изменяться участником закупки

Требования к разграничению прав на просмотр сформированных системных отчетов - В рамках развития отчетно-аналитического модуля в Системе должна быть доработана фильтрация реестра с отчётами. Существующая логика фильтрации пользовательских отчётов (по пользователю или организации пользователя, сформировавшего отчёт) должна быть дополнена фильтрацией системных отчётов согласно иерархии организации пользователя: – Пользователь должен видеть в реестре все системные отчёты, сформированные пользователями его организации; – Пользователь должен видеть в реестре все системные отчёты, сформированные пользователями организаций, у которых организация текущего пользователя является головной. Изменение иерархии организаций должно вызывать соответствующее изменение фильтрации системных отчётов. - - Значение характеристики не может изменяться участником закупки

Требование к развитию работы донесениями 1-5/ЧС - В рамка работ по развитию Системы должна быть обновлена логика работы с донесениями 1-5/ЧС в части: – Система должна обеспечивать возможность настройки списка организаций – получателей донесений администратором Системы. Система должна обеспечивать возможность настройки списка организаций в зависимости от типа донесений (1-5ЧС); – Система должна обеспечивать возможность отправки сформированного донесений организациям в соответствие с настройками организаций получателей. - - Значение характеристики не может изменяться участником закупки

Требования к созданию реестра «Состав сил и средств ТПСГ» - Для автоматизации работы Федеральной противопожарной службы г. Севастополя, в подсистеме поддержки принятия решений, должен быть реализован реестр «Состав сил и средств ТПСГ». Реестр «Состав сил и средств ТПСГ» должен обладать следующими возможностями: – просмотр и редактирование данных о составе сил и средств Федеральной противопожарной службы (далее ФПС) и Аварийно-спасательных формирований (далее АСФ) г. Севастополя; – передача данных о составе сил и средств ТПСГ г. Севастополя в реестр «Сил и средств», содержащий данные о составе сил и средств РСЧС; – на странице реестра должна быть по умолчанию включена фильтрация данных о составе сил и средств ТПСГ г. Севастополя на текущую дату пользователя; – данные по силам и средствам СПТ за прошлый период должны быть недоступны для редактирования; – автоматическое создание записей о составе сил и средств ТПСГ г. Севастополя, с возможностью предзаполнения данными за прошлые дежурные сутки (дежурную смену). Система должна обеспечивать возможность создания, просмотра и редактирования записи реестра в соответствие с правами доступными роли пользователей системы. Запись о составе сил и средств ТПСГ г. Севастополя должна содержать следующий минимальный набор данных: – дата заполнения; – гарнизон – г. Севастополь (по умолчанию); – подразделение; – тип подразделения; – адрес подразделения; – ФИО руководителя подразделения; – ФИО ответственного по подразделению; – ФИО начальника караула; – ФИО диспетчера подразделения; – количество личного состава подразделения; – состав и количество пожарной техники подразделения. Система должна обеспечивать возможность автоматического заполнения данных о составе и количестве пожарной техники на основании данных справочника «Транспортные средства». Для записей реестра в Системе должен быть настроен жизненный цикл, который должен позволять пользователю менять и отслеживать следующие статусы заполнения данных о составе сил и средств ТПСГ г. Севастополя: –новый; –проверка; –доработка; –принято. - - Значение характеристики не может изменяться участником закупки

Требования к созданию справочника «Гарнизоны» - Для обеспечения возможности заполнения данных составе сил и средств ТПСГ г. Севастополя в реестре «Состав сил и средств ТПСГ», в подсистеме управления справочниками и классификаторами должен быть реализован вспомогательный справочник «Гарнизоны». Запись справочника должна содержать информацию о наименовании гарнизона Федеральной противопожарной службы. Система должна обеспечивать возможность использования данных справочника в реестре «Состав сил и средств ТПСГ». Для поддержания справочника в актуальном состоянии Система должна позволять создавать, просматривать, редактировать и удалять записи. - - Значение характеристики не может изменяться участником закупки

Требования к созданию справочника «Транспортные средства» - Для обеспечения возможности заполнения данных о составе сил и средств ТПСГ г. Севастополя в реестре «Состав сил и средств ТПСГ», а также возможности ведения данных о транспортных средствах, стоящих на вооружении в пожарных частях противопожарной службы, в подсистеме управления справочниками и классификаторами должен быть реализован вспомогательный справочник «Транспортные средства». Запись справочника должна содержать следующую информацию: – гос. номер; – марка; – модель; – подразделение, к которому относится транспортное средство; – класс пожарной техники; – вариант пожарной техники; – состояние транспортного средства; – причины нахождения техники не в расчете. Для поддержания справочника в актуальном состоянии Система должна обеспечивать возможность создавать, просматривать, редактировать и удалять записи в соответствие с правами доступными роли пользователей системы. Для возможности оперативного поиска информации по данным справочника в Системе должен быть реализован полнотекстовый поиск. В справочнике должна быть реализована возможность фильтрации данных по следующим параметрам: – марка; – модель; – подразделение. Система должна обеспечивать возможность использования данных справочника в реестре «Состав сил и средств ТПСГ». - - Значение характеристики не может изменяться участником закупки

Требования к развитию модуля силы и средства - В рамках развития модуля силы и средства подсистемы поддержки принятия решений, для обеспечения возможности создания записи в реестре «Состав сил и средств» на будущие несколько суток, в Системе должна быть реализована возможность указания даты создания записи о составе сил и средств вручную пользователем. Возможность указать дату должна быть доступна согласно ограничению прав пользователей системы. - - Значение характеристики не может изменяться участником закупки

Требования к развитию взаимодействия с государственным адресным реестром - В рамках развития Системы должно быть реализовано использование адресов из Федеральной информационной адресной системы в формате «ГАР». Адрес в формате «ГАР» включает в себя как минимум следующий набор характеристик: – Регион; – Муниципальное образование; – Населенный пункт; – Улица; – Номер дома; – Корпус; – Строение; – Координаты; – Этажность здания. - - Значение характеристики не может изменяться участником закупки

Требования к созданию справочника «Причалы» - Для принятия решений по реагированию в случае возникновения ЧС и происшествий, с целью эвакуации или размещению людей, в подсистеме справочников и классификаторов должен быть реализован справочник «Причалы». Справочник должен обеспечивать возможность ведения реестра причалов г. Севастополя. Запись справочника должна содержать следующую информацию: – номер причала – наименование сооружения; – местоположение; – координаты причала; – кадастровый номер ГСТ; – параметры и характеристики сооружения: – длина, м; – ширина, м; – высота, м; – примечание. Для поддержания справочника в актуальном состоянии Система должна обеспечивать возможность создавать, просматривать, редактировать и удалять записи в соответствие с правами доступными роли пользователей системы. Для возможности оперативного поиска информации по данным справочника в Системе должен быть реализован полнотекстовый поиск. В справочнике должна быть реализована возможность фильтрации данных по району и активности. Система должна обеспечивать возможность использования данных справочника в геоинформационной подсистеме (посредством подсистемы интеграции данных), для возможности вывода слоя «Причалы» на картографической подложке. - - Значение характеристики не может изменяться участником закупки

Требования к созданию справочника «Временные пункты обогрева» - Для принятия решений по реагированию в случае возникновения ЧС и происшествий, с целью эвакуации или размещению людей, в подсистеме справочников и классификаторов должен быть реализован справочник «Временные пункты обогрева». Справочник должен содержать список временных пунктов обогрева (далее ВПО) г. Севастополя. Запись справочника должна содержать следующую информацию: – наименование; – адрес; – координаты, – вместимости, – количества персонала на объекте, – наличие оборудования. Для поддержания справочника в актуальном состоянии Система должна позволять создавать, просматривать, редактировать и удалять записи в соответствие с правами доступными роли пользователей системы. В записи справочника должна быть реализована возможность указания зоны действия ВПО. Для возможности оперативного поиска информации по данным справочника в Системе должен быть реализован полнотекстовый поиск. В справочнике должна быть реализована возможность фильтрации данных по району, вместимости и наличию оборудования. Система должна обеспечивать возможность использования данных справочника в геоинформационной подсистеме (посредством подсистемы интеграции данных), для возможности вывода слоя «ВПО» на картографической подложке. - - Значение характеристики не может изменяться участником закупки

Требования к созданию справочника «Водоисточники» - Для обеспечения реагирующих служб г. Севастополя информацией об источниках противопожарного водоснабжения (далее – водоисточники) и их актуальном состоянии, в подсистеме управления справочниками и классификаторами должен быть реализован справочник «Водоисточники». Запись справочника должна содержать следующую информацию: – наименование водоисточника; – месторасположение водоисточника на местности с возможностью прикрепления фотоматериала с расположением объекта; – адрес водоисточника; – координаты расположения водоисточника; – тип водоисточника; – диаметр сети; – вид водопровода: – кольцевой; – тупиковый; – состояние гидранта (исправен/не исправен); – обслуживающая организация; – дата последней проверки; – дата следующей плановой проверки; – описание. Для поддержания справочника в актуальном состоянии Система должна позволять создавать, просматривать, редактировать и удалять записи в соответствие с правами доступными роли пользователей системы. Для возможности оперативного поиска информации по данным справочника в Системе должен быть реализован полнотекстовый поиск. В справочнике должна быть реализована возможность фильтрации данных по следующим параметрам: – тип водоисточника; – состояние гидранта; – активность; – дата обнаружения неисправности; – дата последней проверки. Система должна обеспечивать данными о водоисточниках (посредством подсистемы интеграции данных) следующие подсистемы: – подсистему поддержки принятия решений, в части предоставления информации о ближайшем к объекту с возгоранием водоисточнике с целью определения оптимального расстояния подачи огнетушащих средств для ликвидации ЧС; – геоинформационную подсистему для отображения на картографической подложке мест расположения водоисточников. - - Значение характеристики не может изменяться участником закупки

Требования к развитию справочника «Важные объекты» - В рамках развития подсистемы управления справочниками и классификаторами в формы создания/редактирования/просмотра записи справочника «Важные объекты» должны быть добавлены следующий дополнительный набор параметров: – Этажность; – Геометрические размеры объекта (длина, ширина, высота в метрах); – Общая площадь здания, комплекса зданий, кв. м; – Признак, что является объектом с круглосуточным пребыванием людей (да/нет); – Ранг пожара; – Признак, что важный объект расположен в безводном участке; – Вместимость объекта; – Количество рабочих мест, единиц; – Степень огнестойкости; – Категория объекта, оказывающего негативное воздействие на окружающую среду; – Класс опасности объекта в зависимости от уровня потенциальной опасности; – Класс по конструктивной пожарной опасности; – Класс функциональной пожарной опасности; – Класс опасности объекта в соответствии с санитарной классификацией; – Назначение объекта. Полный перечень дополнительных атрибутов должен быть уточнен у Заказчика на этапе реализации. Итоговый перечень дополнительных атрибутов должен быть определен на этапе аналитического обследования. - - Значение характеристики не может изменяться участником закупки

Требования к реализации справочника безводных участков - В рамках развития подсистемы управления справочниками и классификаторами, для обеспечения должностных лиц оперативно-тактической информацией о важных объектах и зданиях, входящих в состав безводных участков, должен быть реализован справочник «Безводные участки». Справочник должен содержать следующую информацию: – подразделение службы пожаротушения; – тип участка; – наименование участка; – краткое наименование; – адрес участка; – район; – координаты; – муниципальное образование; – наиболее пожароопасный объект в рамках безводного участка; – требуемый фактический расход огнетушащих веществ; – расстояние до ближайшего водоисточника; – тип ближайшего водоисточника; – комментарий. Для поддержания справочника в актуальном состоянии Система должна позволять создавать, просматривать, редактировать и удалять записи. Для возможности оперативного поиска информации по данным справочника в системе должен быть реализован полнотекстовый поиск. В справочнике должна быть реализована возможность фильтрации данных по следующим параметрам: – район; – муниципальное образование; – тип ближайшего водоисточника; – ближайший водоисточник. - - Значение характеристики не может изменяться участником закупки

Требования к реализации справочника населенных пунктов, подверженных угрозе лесных пожаров - В рамках развития подсистемы управления справочниками и классификаторами, для обеспечения должностных лиц оперативно-тактической информацией о зданиях, которые относятся к населенным пунктам, подверженным угрозе лесных пожаров, должен быть реализован справочник «Населенные пункты, подверженные угрозе лесных пожаров». Справочник должен содержать следующую информацию: – муниципальное образование; – район; – наименование населенного пункта; – вид объекта; – адрес пункта; – координаты; – площадь; – характеристика домов/строений; – количество зарегистрированного населения; – расстояние до ближайшего водоисточника; – тип ближайшего водоисточника; – комментарий. Для поддержания справочника в актуальном состоянии Система должна позволять создавать, просматривать, редактировать и удалять записи. Для возможности оперативного поиска информации по данным реестра в системе должен быть реализован полнотекстовый поиск. В справочнике должна быть реализована возможность фильтрации данных по следующим параметрам: – район; – муниципальное образование; – вид объекта. - - Значение характеристики не может изменяться участником закупки

Требования к реализации реестра зданий - В рамках развития подсистемы управления справочниками и классификаторами должен быть реализован реестр зданий города Севастополя. В реестре должна отображаться информация о: – местоположении здания: адрес в формате ГАР, координаты; – геометрических размерах здания (длина, ширина, высота в метрах); – характеристиках здания (набор полей соответствует набору данных, получаемых от интегрированной Системы МКА ЖКХ, и описан в п. 5.4.1.3); – зарегистрированных жителях, с возможностью отображать данные от интегрированной системы начисления и ведение паспортного стола; – наличии по указанному адресу важных объектов и организаций; – организации, в зоне реагирования которых находится указанный адрес; – объекты мониторинга ЖКХ, к которым относится указанный адрес; – признаке, что здание относится: – к безводному участку; – населённому пункту, подверженному угрозе лесных пожаров; – зданиям повышенной этажности. В реестре должна быть возможность внести информацию вручную, а также заблокировать редактирование полей при наличии возможности их обновления данными из интегрированных систем. Система должна обеспечивать данными из реестра зданий: – геоинформационную подсистему для отображения информации о здании; – подсистему приёма и обработки сообщений для отображения информации о здании в формах событий и происшествий при указании пользователем адреса, для которого есть соответствующая запись в реестре зданий. - - Значение характеристики не может изменяться участником закупки

Требования к развитию справочника «Организации» - В разделе «Принадлежность адресов» должна быть реализована возможность блокировки добавления или удаления адресов обслуживаемых домов при автоматическом наполнении таблицы данными, получаемыми от АИС «Реформа ЖКХ» (Система МКА ЖКХ) - - Значение характеристики не может изменяться участником закупки

Требования к созданию семантического слоя «Причалы» - Для визуализации данных о расположении причалов на территории г. Севастополя на картографической подложке, в геоинформационной подсистеме должен быть реализован семантический слой «Причалы». В Системе должна быть реализована возможность настройки параметров пиктограмм (иконка, цвет иконки, рамки, цвет и форма маркера) для идентификации на картографической подложке семантического слоя «Причалы». При клике на пиктограмму должна отображаться форма просмотра основной информации о причале. Форма просмотра информации о причале на картографической подложке должна содержать информацию, согласно перечню атрибутов, содержащихся в записи причала в справочнике «Причалы». - - Значение характеристики не может изменяться участником закупки

Требования к созданию семантического слоя «ВПО» - Для визуализации данных о расположении временных пунктов обогрева на территории г. Севастополя на картографической подложке, в геоинформационной подсистеме должен быть реализован семантический слой «ВПО». В Системе должна быть реализована возможность настройки параметров пиктограмм (иконка, цвет иконки, рамки, цвет и форма маркера) для идентификации на картографической подложке семантического слоя «ВПО». При клике на пиктограмму должна отображаться форма просмотра основной информации о ВПО и зона действия ВПО. Форма просмотра информации о ВПО на картографической подложке должна содержать информацию, согласно перечню атрибутов, содержащихся в записи справочника «Временные пункты обогрева». - - Значение характеристики не может изменяться участником закупки

Требования к созданию семантического слоя «Водоисточники» - Для визуализации данных о расположении водоисточников на территории г. Севастополя на картографической подложке, в геоинформационной подсистеме должен быть реализован семантический слой «Водоисточники». В Системе должна быть реализована возможность настройки параметров пиктограмм (иконка, цвет иконки, рамки, цвет и форма маркера) для идентификации на картографической подложке семантического слоя «Водоисточники». При клике на пиктограмму должна отображаться форма просмотра краткой информации о водоисточнике. Краткая информация о неисправности должна содержать как минимум следующую информацию: – наименование водоисточника; – тип водоисточника; – описание; – состояние; – адрес; – координаты; – дата последней проверки. В форме просмотра краткой информации о водоисточнике должна быть обеспечена возможность перейти в полную форму просмотра данных о неисправности. - - Значение характеристики не может изменяться участником закупки

Требование к развитию модуля видеомониторинга и видеоанализа - В рамках развития модуля видеомониторинга и видеоанализа должны быть проведены работы по развитию ЛК Силовых структур и оказаны услуги по поставке (передача неисключительных прав) и настройка СПО видеоанализа для решения задач распознавания лиц, распознавание силуэтов, ГРЗ, обеспечивающего функциями видеоаналитики камеры, расположенные на территории города Севастополя и подключенные к Системе. Поставляемое программное обеспечение видеоанализа должно быть интегрировано с Системой. - - Значение характеристики не может изменяться участником закупки

Требования к интеграции с поставляемым СПО. ч 1 - В рамках развития подсистемы комплексного мониторинга Система должна быть интегрирована с поставляемым СПО (требования к СПО описаны в п. 5.3) в следующем объёме: – передача из АПК БГ города Севастополя и актуализация данных по списку видеокамер-источников для проведения видеоаналитики; – передача из АПК БГ города Севастополя и актуализация данных по группам камер; – передача из АПК БГ города Севастополя и актуализация данных по спискам наблюдения; – в части СПО распознавания лиц: – передача из АПК БГ города Севастополя и актуализация локальной базы розыска; – получение от СПО распознавания лиц информации о лицах, попавших в зону действия видеокамеры с включенной видеоаналитикой «Распознавание лиц» (далее – обнаруженные лица); – получение от СПО распознавания лиц информации о выявлении совпадений обнаруженных лиц с локальной базой розыска при анализе: – видеопотока в режиме реального времени; – видеоархива; – в части СПО распознавания государственного регистрационного знака транспортных средств: – получение от СПО распознавания лиц информации о транспортных средствах, попавших в зону действия видеокамеры с включенной видеоаналитикой «Распознавание ГРЗ» (далее – распознанные ГРЗ); – в части СПО распознавания силуэтов: – получение от СПО распознавания силуэтов информации об обнаруженных силуэтах, попавших в зону действия видеокамеры с включенной видеоаналитикой «Распознавание силуэтов» (далее – обнаруженные силуэты). Обмен информации должен производиться посредством подсистемы интеграции данных. Информация, полученная от СПО, должна быть сохранена в соответствующие реестры: – в части СПО распознавания лиц: в существующий реестр «Сводный реестр обнаруженных лиц»; – в части СПО распознавания ГРЗ транспортных средств: в существующий реестр «Сводный реестр распознанных ГРЗ»; – в части СПО распознавания силуэтов: в новый реестр обнаруженных силуэтов. - - Значение характеристики не может изменяться участником закупки

Требования к интеграции с поставляемым СПО. ч 2 - Информация, полученная от поставляемого СПО распознавания силуэтов, должна содержать следующие характеристики: – видеокамера, зафиксировавшая силуэт; – дата и время фиксации; – фотоизображение момента фиксации; – пол обнаруженного силуэта; – тип головного убора; – тип верха одежды; – вид верха одежды; – цвет верха одежды; – тип низа одежды; – цвет низа одежды. При получении от поставляемого СПО распознавания лиц информации о выявлении совпадений обнаруженного лица с записями реестра разыскиваемых лиц, а также при получении от поставляемого СПО распознавания ГРЗ информации о выявлении совпадений распознанного ГРЗ транспортного средства с записями реестра разыскиваемых ГРЗ Системой должны автоматически создаваться событие и инцидент с соответствующим типом. При создании инцидента должен автоматически формироваться план реагирования на основании загруженного ранее шаблона. Если у разыскиваемого лица стоял признак «Срочно», то автоматически аналогичный признак должен быть установлен у созданных события и инцидента. В созданном инциденте по событию распознавания лиц Система должна отображать поле с указанием значения совпадения обнаруженного лица с разыскиваемым лицом в процентном соотношении. В Системе должна быть предусмотрена настройка, включающая логику объединения срабатываний от поставляемых СПО распознавания лиц и СПО распознавания ГРЗ в рамках одного инцидента. При получении информации о срабатывании видеоаналитики от модуля видеомониторинга и видеоанализа подсистемы комплексного мониторинга должен запускаться алгоритм проверки наличия открытого инцидента по разыскиваемому лицу или транспортному средству, на основании которого произошло срабатывание в СПО. Если подобный инцидент найден, то созданное событие должно быть «привязано» к существующему инциденту. - - Значение характеристики не может изменяться участником закупки

Требования к интеграции с поставляемым СПО. ч 3 - При обработке срабатываний от поставляемых СПО распознавания лиц и СПО распознавания ГРЗ должно быть обеспечено разграничение информационного пространства организаций, работающих с результатами работы СПО. События и инциденты должны быть созданы только в той организации, которая добавила в локальную базу розыска лицо или транспортное средство. В Системе должна быть реализована возможность настройки расписания для работы поставляемого СПО распознавания лиц, ГРЗ и силуэтов на видеокамерах. Должны быть реализованы следующие функциональные возможности: – реестр с расписанием (табличная форма, формы просмотра, создания, редактирования); – включение видеоаналитики в заданный период; – отключение видеоаналитики в заданный период; – создание повторяющихся сценариев включения/отключения видеоаналитики: суточный, недельный; – группирование видеокамер для назначения одного расписания всей группе. - - Значение характеристики не может изменяться участником закупки

Требования к развитию реестра обнаруженных лиц - В рамках развития подсистемы комплексного мониторинга должен быть доработан сводный реестр обнаруженных лиц. В таблице записей реестра должен быть добавлен дополнительный перечень атрибутов, заполняемых в случае получения данной информации от СПО распознавания лиц: – головной убор; – наличие очков; – наличие маски; – эмоции; – возраст. Полный перечень дополнительных атрибутов должен быть определен на этапе аналитического обследования. Перечень параметров фильтрации реестра должен быть расширен указанными атрибутами. - - Значение характеристики не может изменяться участником закупки

Требования к развитию реестра разыскиваемых лиц. ч 1 - В рамках развития подсистемы комплексного мониторинга должен быть доработан сводный реестр разыскиваемых лиц. В таблице записей реестра должен быть добавлен дополнительный перечень атрибутов: – псевдоним; – пол; – причина розыска; – признак «Срочно»; – ответственный сотрудник и его контактные данные (телефон, электронная почта); – дата постановки на контроль; – дата снятия с контроля; – текущий статус розыска: – «На контроле»; – «Снят с контроля»; – списки наблюдения, которым доступна работа с досье и результатами работы СПО распознавания лиц по данному досье; – результат контроля. В реестре должны быть предусмотрены массовые операции: – снять с контроля; – поставить на контроль; – изменить ответственного пользователя и его контактные данные. В реестре должна быть реализована возможность продления периода контроля для досье с указанием новой даты окончания или возобновление контроля разыскиваемого лица без необходимости повторно загружать файл с фотографией и заполнять поля записи реестра. В реестре должно быть реализовано разграничение видимости записей по следующим критериям: – запись видит пользователь, создавший её; – запись видят пользователи, входящие в списки наблюдения, в которые запись добавлена. - - Значение характеристики не может изменяться участником закупки

Требования к развитию реестра разыскиваемых лиц. ч 2 - В реестре должна быть реализована возможность импорта файлов с фотоизображениями разыскиваемых лиц. Перед началом импорта файлов должна быть обеспечена возможность внесения информации о загруженных фотоизображениях в составе: – ответственный пользователь; – телефон, электронная почта ответственного пользователя; – списки наблюдения, которым доступны загруженные фото; – способ формирования псевдонима: по имени файла или автоматически. При импорте файлов на каждое загруженное фото должна создаваться запись в сводном реестре разыскиваемых лиц с автоматическим заполнением следующих полей: – эталонное фотоизображение разыскиваемого лица; – псевдоним в зависимости от выбранного пользователем способа формирования: – по имени файла: в псевдоним должно сохраняться имя загруженного файла без учета расширения; – автоматически: в псевдоним должно сохраняться значение, автоматически сгенерированное по следующему принципу: маска «Объект контроля_» + дата и время создания записи в реестре; – списки наблюдения (в случае указания пользователем перед запуском импорта); – ФИО ответственного сотрудника (в случае указания пользователем перед запуском импорта); – телефон, электронная почта ответственного сотрудника (в случае указания пользователем перед запуском импорта); – дата постановки на контроль (должна заполняться датой и временем создания записи в реестре); – статус розыска (должен заполняться значением «На контроле»). - - Значение характеристики не может изменяться участником закупки

Требования к развитию реестра разыскиваемых лиц. ч 3 - В модуле видеомониторинга и видеоанализа должна быть реализована функция поиска лиц, контактирующих с разыскиваемым лицом. Пользователь должен иметь возможность из досье разыскиваемого лица запускать автоматизированный поиск лиц, наиболее часто встречающихся с ним. На основании выявленных СПО распознавания лиц связей разыскиваемого лица формируется список его контактов. Из каждого найденного контакта должна быть возможность создавать новые досье. Результат поиска контактов должен содержать как минимум следующую информацию: – фотоизображение предполагаемого контакта (обнаруженного лица); – дата и время момента фиксации; – название видеокамеры, обнаружившей лицо; – местоположение камеры, обнаружившей лицо. Для каждой записи результата установления контактов должна быть предусмотрена возможность запросить и воспроизвести видеофрагмент момента фиксации взаимодействия разыскиваемого лица с предполагаемым контактом. - - Значение характеристики не может изменяться участником закупки

Требования к созданию функционала поиска разыскиваемого лица в архиве обнаруженных лиц. ч 1 - В рамках развития подсистемы комплексного мониторинга в Системе должен быть создан функционал поиска разыскиваемого лица в архиве обнаруженных лиц посредством создания запроса на поиск лица в архиве обнаруженных лиц. Возможность создания запроса на поиск лица в архиве обнаруженных лиц должна быть предусмотрена в следующих разделах Системы: – запись сводного реестра разыскиваемых лиц; – запись сводного реестра обнаруженных лиц. Форма создания поискового запроса должна содержать следующие компоненты: – фотоизображение разыскиваемого лица; – настраиваемый коэффициент сходства (со значением не менее 0,75); – временной период поиска; – перечень видеокамер. Для организации работы нескольких пользователей с данным функционалом должна быть реализована единая очередь из запросов на поиск в архиве. У пользователя должна быть возможность просмотра очереди запросов, к которым у него есть доступ. У запроса, поставленного в очередь, должна отображаться как минимум следующая информация: – дата и время начала запуска; – статус; – ФИО пользователя, запустившего поиск; – перечень видеокамер, в архиве которых производится поиск; – временной период поиска в архиве; – дата и время окончания запуска. - - Значение характеристики не может изменяться участником закупки

Требования к созданию функционала поиска разыскиваемого лица в архиве обнаруженных лиц. ч 2 - После окончания поиска должна быть обеспечена возможность получения от поставляемого СПО распознавания лиц (требования к СПО описаны в п. 5.3) списка записей из сводного реестра обнаруженных лиц, соответствующих лицу на фотоизображении, загруженном для поиска. Запись с результатом поиска должна содержать как минимум следующую информацию: – фотография обнаруженного лица; – дата и время фиксации лица; – название видеокамеры, зафиксировавшей лицо; – место установки видеокамеры; – инцидент, созданный при обнаружении данного лица (если ранее лицо находилось на контроле и СПО фиксировало его). Для просмотра всей информации у пользователя должна быть возможность перехода в форму просмотра найденных инцидентов. Кроме этого в записи с результатом поиска должны быть реализованы следующие возможности: – верифицировать результаты поиска и удалить ложные записи; – создать досье разыскиваемого лица (если поиск запускался из сводного реестра обнаруженных лиц); – на основании результатов поиска отобразить на карте последовательность видеокамер, зафиксировавших лицо из поиска. Доступ к записям очереди должен быть предоставлен в соответствии со следующими ограничениями: – пользователь видит записи, которые создал сам; – пользователь видит записи, которые относятся к досье из списка наблюдения, к которому есть доступ; – пользователь видит все записи. - - Значение характеристики не может изменяться участником закупки

Требования к созданию сводного реестра обнаруженных силуэтов - Для накопления и хранения информации об обнаруженных силуэтах (силуэтах, попавших в зону действия видеокамеры с включенной видеоаналитикой «Распознавание силуэтов») в рамках развития модуля видеомониторинга и видеоанализа в Системе должен быть создан сводный реестр «Сводный реестр обнаруженных силуэтов». Сводный реестр обнаруженных силуэтов должен содержать информацию: – дата и время фиксации; – наименование видеокамеры, зафиксировавшей силуэт; – координаты видеокамеры, зафиксировавшей силуэт; – место установки видеокамеры, зафиксировавшей силуэт; – фотоизображение момента фиксации; – видеофрагмент момента фиксации; – пол обнаруженного силуэта; – тип головного убора; – характеристика верха одежды: – тип верха одежды; – вид верха одежды; – цвет верха одежды; – характеристика низа одежды: – тип низа одежды; – цвет низа одежды. В реестре должна быть реализована возможность фильтрации записей как минимум по времени фиксации силуэта, видеокамере и полу обнаруженного силуэта. В реестре должна быть реализована возможность настройки ограничения срока хранения записей реестра с обнаруженными силуэтами. У пользователя должна быть возможность указать количество дней, через которое запись реестра (фотоизображение и данные) будет удалена. Поиск записей для последующего удаления должен: – производиться в автоматическом режиме; – запускаться вручную пользователем из формы работы с реестром обнаруженных силуэтов. - - Значение характеристики не может изменяться участником закупки

Требования к развитию реестра распознанных ГРЗ транспортных средств - В рамках развития подсистемы комплексного мониторинга должны быть внесены изменения в сводный реестр распознанных ГРЗ. Записям реестра должен быть добавлен дополнительный перечень атрибутов, заполняемых в случае получения данной информации от СПО распознавания ГРЗ: – цвет; – марка; – модель. Полный перечень дополнительных атрибутов должен быть уточнен у Заказчика на этапе реализации и прописан в Аналитической записке. Перечень параметров фильтрации реестра должен быть расширен указанными атрибутами. На основании распознанных ГРЗ в Системе должна быть реализована возможность построения предполагаемых маршрутов движения транспортного средства. - - Значение характеристики не может изменяться участником закупки

Требования к развитию реестра разыскиваемых транспортных средств - В рамках развития подсистемы комплексного мониторинга должны быть внесены изменения в сводный реестр разыскиваемых транспортных средств. В таблице записей реестра должен быть добавлен дополнительный перечень атрибутов: – дата постановки на контроль; – дата снятия с контроля; – текущий статус розыска: – «На контроле»; – «Снят с контроля»; – результат контроля; – электронная почта ответственного сотрудника; – списки наблюдения, которым доступна работа с записью и результатами работы СПО распознавания ГРЗ по данной записи. В реестре должны быть предусмотрены массовые операции: – снять с контроля; – поставить на контроль; – изменить ответственного пользователя и его контактные данные. В реестре должна быть реализована возможность продления периода контроля для записи с указанием новой даты окончания или возобновление контроля разыскиваемого ГРЗ без необходимости повторно заполнять поля записи реестра. В реестре должно быть реализовано разграничение видимости записей по следующим критериям: – запись видит пользователь, создавший её; – запись видят пользователи, входящие в списки наблюдения, в которые запись добавлена. - - Значение характеристики не может изменяться участником закупки

Требование к функциональности мониторинга интеграций - Для оценки эффективности процесса межсистемного взаимодействия между АПК БГ и сторонними системами, в подсистеме комплексного мониторинга должен быть реализован функционал мониторинга доступности интегрируемых систем. Функционал мониторинга доступности интегрируемых систем должен обладать следующими возможностями: – отображение перечня внешних систем, интегрируемых с Системой в части передачи данных; – отображение атрибутов и индикация статуса доступности внешних интегрируемых систем; – возможность принудительно запросить статус доступности у интегрируемых подсистем; – поиск по атрибутам среди интегрируемых внешних систем; – экспорт существующих записей в файлы форматов xls, xlsx, csv. Результаты мониторинга доступности интегрируемых систем должны выводится на отдельной странице раздела «Взаимодействие с внешними ИС» Системы. Записи страницы должны содержать как минимум следующий перечень атрибутов: – наименование внешней интегрируемой системы; – дата обновления данных; – активность внешней интегрируемой системы; – статус; – период обновления данных. При обнаружении сбоев межсистемного взаимодействия между АПК БГ и сторонними системами посредством мониторинга доступности интегрируемых систем, в Системе должна быть реализована возможность вывода пуш-уведомлений и отправки почтовых уведомлений с информацией о сбоях для пользователей, обладающих правами администратора. - - Значение характеристики не может изменяться участником закупки

Требование к мониторингу вызовов на линию 1563. ч 1 - Для оценки эффективности процесса приема звонков от населения сотрудниками ЕДДС, в подсистеме комплексного мониторинга должен быть реализован функционал мониторинга приема звонков. С целью осуществления мониторинга работы операторов ЕДДС по г. Севастополю и уменьшения количества проводимых операций в Подсистеме приема и обработки сообщений ЛК ЕДДС, необходимо доработать функциональность изменения статуса работы оператора ЕДДС по нажатию дополнительных быстрых клавиш «Перерыв/окончание перерыва» (отдельно для регламентированных и не регламентированных перерывов). Процесс приема звонков операторами ЕДДС по результатам доработки должен быть организован согласно схеме, приведенной в Приложении №1 к настоящему ТЗ. В отчетно-аналитическом модуле ЛК ЕДДС должна быть реализована следующая функциональность: – формирование отчета по работе ЕДДС с указанием периодов пребывания операторов в режимах перерыва в формате часы, минуты, секунды; – формирование отчета «Статистика по вызовам» с разбивкой по часам за сутки с отображением следующих атрибутов: – Час; – Всего (кол-во); – отвеченных (кол-во, %); – не отвеченных (кол-во, %); – занятых (кол-во, %); – среднее время ответа; – максимальное время ответа; – формирование реестра всех вызовов на линию 1563 с отображением следующих атрибутов: – Тип вызова; – Номер телефона Заявителя; – ФИО Оператора; – ФИО Заявителя; – Номер телефона Оператора; – Дата и время начала разговора; – Длительность ожидания ответа; – Длительность разговора; – Статус ответа; – Событие: хранится/не хранится; – Запись. - - Значение характеристики не может изменяться участником закупки

Требование к мониторингу вызовов на линию 1563. ч 2 - Для возможности оперативного поиска информации по данным реестра вызовов должна быть реализована сортировка по дате и времени начала разговора и фильтрация данных по заданным атрибутам: – по типу вызова: входящий/исходящий; – по номеру телефона звонящего; – по ФИО Заявителя; – по дате и времени начала разговора; – по статусу ответа; – по признаку хранения события. В подсистеме комплексного мониторинга в разделе «Телефония» реализовать страницу с мониторингом вызов в ЕДДС. На странице в режиме реального времени должны отображаться текущие результаты мониторинга приема звонков в виде индексов количественных показателей: – количество ожидающих в очереди граждан; – количество активных операторов на линии; – количество операторов в нерабочем статусе. - - Значение характеристики не может изменяться участником закупки

Требования к развитию справочника «Пользователи» - Для обеспечения возможности рассылки уведомлений пользователям Системы, в рамках развития подсистемы управления справочниками и классификаторами, в форму справочника «Пользователи» должен быть добавлен чек-бокс согласия на рассылку. Возможность активации или деактивации чек-бокса в справочнике «Пользователи» должна быть доступна только администраторам Системы. - - Значение характеристики не может изменяться участником закупки

Требования к развитию информационной карточки пользователя - Для обеспечения возможности редактирования информации о пользователе самим пользователем, без привлечения администратора Системы, в информационную карточку пользователя, доступ к которой возможен через навигационное меню Системы, должны быть добавлены следующие параметры: – чек-бокс согласия на рассылку; – адрес электронной почты. При изменении пользователем параметров в информационной карточке пользователя, данные должны также сохранится в справочнике «Пользователи». - - Значение характеристики не может изменяться участником закупки

Требования к развитию справочника «Уведомления» - В рамках развития подсистемы комплексного информирования и оповещения, в Системе должен быть реализован новый вид уведомления - рассылка на электронную почту. Почтовый сервер и необходимые настройки для отправки уведомлений на электронную почту предоставляется Заказчиком Уведомления должны отправляться на электронную почту пользователя, которая указана в записи справочника «Пользователи», в случае, если выполнено одно из условий: – пришло уведомление по наступлению события (в зависимости от источника поступления информации); – у инцидента активирован признак «На контроле ЦУКС»; – создано поручение на организацию; – истекает срок выполнения поручения; – срок выполнения поручения закончился; – выявлен и зафиксирован в журнале «Мониторинг интеграций» сбой в процессе интеграции АПК БГ с внешней Системой. Должна быть обеспечена возможность настройки параметров рассылки на электронную почту, в т.ч. время, за которое должно быть отправлено уведомление об истечении срока выполнения поручения. В Системе должна быть обеспечена возможность настройки шаблонов текста почтового уведомления. Данная возможность должна быть доступна только для администраторов Системы. - - Значение характеристики не может изменяться участником закупки

Требования к развитию подсистемы административного управления. Расширение функций механизма авторизации - Расширение функций механизма авторизации должно обеспечивать улучшение мер информационной безопасности по закрытию уязвимостей в процессе авторизации. Должна быть произведена доработка авторизационных cookie-данных. Авторизационные cookie-данные с наименованием «token» должны становиться недействительными в следующих случаях: – при завершении сессии (по нажатию кнопки выхода из аккаунта); – по истечению времени с момента авторизации (по умолчанию по истечению периода - через одни сутки). Должна быть исключена возможность авторизации пользователя путем вставки через средства браузера данных, скопированных до выхода из предыдущей сессии. - - Значение характеристики не может изменяться участником закупки

Требования к развитию подсистемы административного управления. Обновление механизма аутентификации (ЕСИА). ч 1 - В Системе (в закрытой части и интернет-портале) должна быть обеспечена аутентификация пользователей по средствам единой системы идентификации и аутентификации (ЕСИА) с использованием механизма аутентификации пользователей, основанного на спецификациях протокола авторизации OAuth 2.0 и расширении OpenID Connect 1.0, разработанного в соответствии с методическими рекомендациями по использованию ЕСИА https://digital.gov.ru/ru/documents/6186/. Механизм аутентификации пользователей при взаимодействии с ЕСИА должен обеспечивать следующие функциональные возможности: 1) Система должна обеспечивать возможность взаимодействия с Единой системой идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме (ЕСИА) в части аутентификации пользователей Системы; 2) Аутентификация пользователя Системы должна происходить в общем случае в соответствии с приведенным ниже примерным сценарием. Сценарий включает следующие шаги (схема представлена на Рисунке 1): 1) Пользователь нажимает на веб-странице системы-клиента кнопку «Войти через ЕСИА». 2) Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа. 3) ЕСИА осуществляет аутентификацию пользователя одним из доступных способов. Если пользователь еще не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации. 4) Когда пользователь аутентифицирован, ЕСИА сообщает пользователю, что система-клиент запрашивает данные о нем в целях проведения идентификации и аутентификации, предоставляя перечень запрашиваемых системой-клиентом сведений. 5) Если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код. - - Значение характеристики не может изменяться участником закупки

Требования к развитию подсистемы административного управления. Обновление механизма аутентификации (ЕСИА). ч 2 - 6) Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код. 7) ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации. 8) Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным. Обращение участников информационного взаимодействия к ЕСИА должно происходить только по протоколу HTTPS (использовать протокол HTTP запрещено) и только с использованием протокола защиты TLS версии 1.2. Интеграционное взаимодействие Системы с внешними системами осуществляется посредством инфраструктуры и сети передачи данных Заказчика. Использование механизмов, сертифицированных Российских криптографических средств защиты информации, при взаимодействии с ЕСИА обеспечивает Заказчик. - - Значение характеристики не может изменяться участником закупки

Требования к функциональности обновления пароля учетных записей - доступа для пользователей АПК «Безопасный город» города Севастополя в Подсистеме административного управления должна быть реализована функциональность автоматического уведомления пользователей о необходимости смены пароля и обновления пароля пользователями самостоятельно, с обязательным сохранением данных о факте проведения смены пароля пользователем в Системе. Необходимо реализовать функциональность автоматического уведомления пользователей по электронной почте о необходимости смены пароля. Рассылка уведомлений должна производиться ежедневно для пользователей Системы, у которых с момента последней смены пароля прошло от 80 до 90 дней. Содержание уведомления должно быть согласовано с Заказчиком на этапе аналитического обследования. Почтовый сервер для осуществления рассылки предоставляется Заказчиком. В разделе «Администрирование» в подразделе «Пользователи» необходимо добавить в реестре столбец с наименованием «Дата смены пароля» и создать функционал автоматического внесения в него даты по факту смены пароля пользователем и добавление записи в журнале изменений, что пароль был обновлен пользователем. Для самостоятельного обновления пароля пользователями необходимо на странице авторизации добавить кнопку «Сменить пароль». При самостоятельной смене пароля пользователю на странице авторизации должна быть доступна функциональность генерации надежных паролей без перехода на внешние ресурсы. В Системе должно быть обеспечено блокирование неактивных (неиспользуемых) учетных записей пользователей через период времени неиспользования 90 дней. В случае достижения максимального количества неуспешных попыток аутентификации (ввода неправильного пароля) и/или ввода пользователем пароля, срок действия которого составляет более 90 дней, Система должна обеспечивать уведомление пользователя о неуспешной авторизации и блокировать учетную запись пользователя на время от 10 до 30 мин. - - Значение характеристики не может изменяться участником закупки

Требования к установке обновлений Системы - В рамках выполнения работ Подрядчик обеспечивает разработку, доработку и тестирование программного кода на собственных программно-аппаратных средствах. Заказчик обеспечивает предоставление промышленной площадки – основного программно-аппаратного комплекса, на котором располагается версия Системы, находящаяся в режиме постоянной эксплуатации. Установка обновлений Системы должна осуществляться Подрядчиком предварительно на тестовом стенде, который разворачивается на программно-аппаратных средствах Подрядчика. По результатам успешного тестирования модернизированной версии ПО Системы на тестовом стенде Подрядчик выполняет перенос новой версии/обновление ПО Системы на промышленную площадку Заказчика, с предварительным согласованием с Заказчиков времени переноса, или обновления ПО. - - Значение характеристики не может изменяться участником закупки

Требования к работоспособности Системы - Целевое назначение Системы должно сохраняться на протяжении всего срока ее эксплуатации. Срок эксплуатации Системы определяется сроком устойчивой работы аппаратных средств вычислительных комплексов, своевременным проведением работ по замене (обновлении) аппаратных средств, по сопровождению программного обеспечения Системы и его модернизации. Технологические решения по модернизируемым функциям (задачам) Системы должны обеспечивать выполнение следующих требований: – вероятность потери вызова – не более 0,1%; – устойчивость к сетевым перегрузкам; – возможность дальнейшего развития системы в направлении расширения функциональности, производительности, масштабируемости существующих служб и возможности реализации новых служб. Специальные требования к вероятностно-временным характеристикам, при которых сохраняется целевое назначение Системы, не предъявляются. - - Значение характеристики не может изменяться участником закупки

Критерии оценки заявок

Цена контракта

Значимость критерия оценки: 30.00%

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

Значимость критерия оценки: 70.00%

Порядок оценки: Лучшим условием исполнения контракта по критерию оценки является наибольшее значение критерия

Показатели критерия оценки:

1 Наличие у участников закупки опыта поставки товара, выполнения работы, оказания услуги, связанного с предметом контракта

Значимость показателя: 100.00%

Порядок оценки по показателю :

1 Детализирующий показатель: Наибольшая цена одного из исполненных участником закупки договоров

Значимость детализирующего показателя: 80.00%

Порядок оценки по детализирующему показателю: Лучшим является наибольшее значение характеристики объекта закупки

2 Детализирующий показатель: Общее количество исполненных участником закупки договоров

Значимость детализирующего показателя: 20.00%

Порядок оценки по детализирующему показателю: Лучшим является наибольшее значение характеристики объекта закупки и установлено предельное максимальное значение характеристики объекта закупки

Предельное максимальное значение: 20.00

Перечень прикрепленных документов

Обоснование начальной (максимальной) цены контракта

1 Обоснование НМЦК - развитие АПК БГ.docx

Проект контракта

1 Проект ГК - развитие АПК БГ.docx

Описание объекта закупки

1 ТЗ_АПК_БГ_Развитие.docx

Требования к содержанию, составу заявки на участие в закупке

1 Требования к заявке на участие в закупке и инструкция по её заполнению 2024.005632.docx

Порядок рассмотрения и оценки заявок на участие в конкурсах

1 Порядок_рассмотрения_и_оценки_заявок_БГ.docx

Дополнительная информация и документы

Ссылки

Общая информация

Документы

Журнал событий