Приложение 1. Техническое задание на оборудование и эксплуатацию используемых на платной основе парковок (парковочных мест), расположенных на автомобильных дорогах общего пользования местного значения муниципального образования "Город Курск"

Приложение 1
к Порядку
проведения конкурса на право
заключения инвестиционного соглашения
по оборудованию и эксплуатации на платной
основе парковок (парковочных мест),
расположенных на автомобильных дорогах
общего пользования местного значения
муниципального образования "Город Курск"

Техническое задание
на оборудование и эксплуатацию используемых на платной основе парковок (парковочных мест), расположенных на автомобильных дорогах общего пользования местного значения муниципального образования "Город Курск"

Оглавление

Перечень обозначений и сокращений

1. Общие сведения

1.1 Краткая характеристика области выполнения работ

1.2 Наименование предприятий (объединений) Инвестора и Заказчика системы

1.3 Перечень нормативно-технических документов, методических материалов, регламентирующих выполнение работ

1.4 Наименование выполняемых работ

1.1 Цели выполнения работ

2. Этапы и сроки выполнения работ, источники финансирования работ

3. Состав, объем и виды работ, требования к качеству, техническим характеристикам работ

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

3.1.1 Требования к конструктиву и внешнему виду Паркомата и его монтажу на УДС

3.1.2 Требования к форм-фактору комплекса видеофиксации нарушений правил парковки

3.1.3 Требования к Платежному контроллеру Паркомата

3.1.4 Требования к Парковочным картам

3.1.5 Требования к модулю эмиссии

3.1.6 Требования к модулю мониторинга АИС Парковочного пространства

3.1.7 Требования к программному комплексу системы управления парковочным пространством

3.1.8 Требования по диагностированию

3.1.9 Требования к надежности технических средств и программного обеспечения

3.1.10 Перечень аварийных ситуаций

3.1.11 Требования безопасности

3.1.12 Требования к эргономике и технической эстетике

3.1.13 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

3.1.14 Общие положения

3.1.15 Требования к организации услуг по эксплуатации системы

3.1.16 Требования по сохранности информации при авариях

3.1.17 Требования к патентной чистоте

3.1.18 Требования к стандартизации и унификации

3.1.19 Требования к сохранению дорожного покрытия

3.1.20 Требования по сдачи системы в эксплуатацию

5. Испытания и проверка качества

5. Требования соответствия нормативным документам (лицензии, допуски, разрешения, согласования)

6. Гарантийные обязательства

Перечень обозначений и сокращений

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

1. Общие сведения

1.1 Краткая характеристика области выполнения работ.

Обеспечение исполнения функций по контрольно-аналитической, надзорной и распределительной деятельности.

1.2 Наименование предприятий (объединений) Инвестора и Заказчика системы:

Заказчик -.

Инвестор - определяется по результатам конкурсных процедур.

Клиент - юридические и физические лица, использующие на платной основе парковки.

1.3 Перечень нормативно-технических документов, методических материалов, регламентирующих выполнение работ

Оборудование и эксплуатация на платной основе парковок (парковочных мест), расположенных на автомобильных дорогах общего пользования местного значения города Курска разрабатывается на основании следующих документов:

Решение Курского городского собрания от _________ N _____ "Об утверждении Порядка создания и использования, в том числе на платной основе, парковок (парковочных мест), расположенных на автомобильных дорогах общего пользования местного значения городского округа "Город Курск".

Решение Курского городского собрания от _________ N _____ "Об утверждении методики расчета и максимального размера платы за пользование на платной основе парковками (парковочными местами), расположенными на автомобильных дорогах общего пользования местного значения городского округа "Город Курск".

Постановление Администрации города Курска от ____________ N ______ "Об организации платных парковок в городе Курске".

1.4 Наименование выполняемых работ.

Оборудование и эксплуатация используемых на платной основе парковок (парковочных мест), расположенных на автомобильных дорогах общего пользования местного значения муниципального образования "Город Курск".

Цели выполнения работ

В результате выполнения работ будет предоставлена возможность по:

упорядочиванию движения транспортных средств на улично-дорожной сети;

снижению загруженности улично-дорожной сети;

сокращению транспортного потока в центральную часть города, где практически невозможна реконструкция улично-дорожной сети;

повышению приоритета использования городского общественного пассажирского транспорта;

снижению количества нарушений правил остановки (стоянки) транспортных средств;

увеличению средней скорости движения транспортного потока.

2. Этапы и сроки выполнения работ, источники финансирования работ

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

По окончании выполнения работ, должен быть подписан акт, подтверждающий прием выполненных работ Заказчиком.

Источник финансирования: определяется условиями инвестиционного соглашения.

Предельный срок выполнения работ: определяется условиями инвестиционного соглашения.

3. Состав, объем и виды работ, требования к качеству, техническим характеристикам работ

На территории города Курск к сроку, указанному в пункте 2 настоящего Технического задания, должен быть завершен процесс организации программно-аппаратного комплекса, состоящего из АИС Парковочного пространства, 25 Паркоматов с системой мониторинга на 1100 парковочных мест, размещенных на улично-дорожной сети города на территории существующих парковочных мест в рамках красных линий, а также существующих наземных плоскостных парковок.

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

Наземная плоскостная парковка с наименованием объекта "Плоскостная парковка с видеонаблюдением" к данному Техническому заданию, должна быть оборудована системой обзорного видеонаблюдения, а также комплексом видеофиксации для распознавания и хранения ГРН ТС. Для реализации функции передачи потокового видео, а также возможности организации голосовой связи диспетчера Центра управления с пользователями к данной парковки необходимо организовать канал связи с пропускной способностью не менее 10 Мбит/c c возможностью доступа в сеть Интернет. Параметры канала связи определяет Инвестор.

Схема расположения парковочного оборудования на плоскостных парковках выбирается Инвестором самостоятельно, исходя из практических соображений удобства использования конечными пользователями, и согласуется с Заказчиком.

Оплата муниципальных парковок на улично-дорожной сети должна быть реализована с использованием Паркоматов (с функциями приема банковских и парковочных карт, в том числе бесконтактных), а также с помощью SMS платежей и мобильных приложений.

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

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

интернет - портал;

мобильные приложения;

связь с удаленным оператором системы посредством коммуникационного оборудования, установленного в автоматических парковочных кассах (для Наземных плоскостных парковок).

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

На каждой парковке или парковочном кармане должен быть установлен информационный знак дорожного движения 6.4 "Парковка" и знак дополнительной информации дорожного движения 8.8 "Платные услуги" (либо знак 5.27 "Зона с ограничение стоянки" при условии установки в конце парковки (или группы парковок) знака 5.28 "Конец зоны с ограничением стоянки").

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

В состав работ, выполняемых Инвестором по оборудованию Системы, входят:

дорожно-строительные работы по организации парковочного пространства, включая выделение мест для установки паркоматов и прочего оборудования Системы;

нанесение дорожной разметки;

изготовление и монтаж дорожных знаков.

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

Инвестор обязан предоставить Заказчику на срок действия Контракта Комплексный сервис (далее - Сервис) в целях обеспечения возможности использования прикладного функционала Системы. Сервис должен быть реализован и предоставлен Заказчику по принципам модели "Программное обеспечение как сервис" (SaaS).

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

Все данные, накопленные в процессе использования Системы в составе Комплексного сервиса в течение всего периода его предоставления, принадлежат Заказчику. По окончании срока предоставления Сервиса Инвестор обязуется передать Заказчику накопленные данные.

Инвестором с использованием своего серверного оборудования должен быть создан Центр обработки данных, в котором должен быть развернут сервер базы данных с системным и прикладным обеспечением, а также основным и резервным каналами связи.

По окончании срока предоставления Сервиса Инвестором должен быть обеспечен перенос базы данных с системным и прикладным обеспечением Системы (с необходимыми пусконаладочными и тестовыми работами) в Центр обработки данных Заказчика. Затраты на обеспечение переноса в Центр обработки данных Заказчика (уполномоченному им лицу) полностью несет Инвестор.

Требования к техническим характеристикам товаров (материалам и конструкциям), которые должны применяться при производстве работ, а также максимальные и/или минимальные значения показателей и показатели, значения которых не могут изменяться, определяющие качество товара, используемого при выполнении работ по предмету конкурса в электронной форме, его технические, функциональные и иные характеристики установлены настоящим техническим заданием, а также в части не противоречащей настоящему техническому заданию:

нормативно-техническими документами в составе настоящей документации о конкурсе в электронной форме, требования на соответствие товаров которой определены в настоящем техническом задании;

проектной документацией.

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

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

При выполнении работ должны применяться материалы, предназначенные для применения в дорожно-климатической зоне - II.

3.1.1 Требования к конструктиву и внешнему виду Паркомата и его монтажу на УДС

Для обустройства автоматизированной системы парковки должны быть установлены аппараты, обеспечивающие прием безналичной оплаты за услуги по паркованию автотранспорта на улично-дорожной сети (далее Паркоматы). Паркоматы должны обеспечивать прием банковских и парковочных (транспортных) карт.

Конструктивно, Паркомат должен быть выполнен из корпуса, лицевой панели и основания и светового короба. Корпус Паркомата должен являться основным несущим элементом конструкции. На лицевой панели должны быть расположены элементы управления и взаимодействия клиента с Системой - вандалозащищенный монитор с сенсорным экраном, клавиатуры, картридера, а также отверстия под выход чеков из термопринтера.

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

Световой короб высотой не менее 1250 мм должен быть установлен на верхней плоскости корпуса паркомата.

Корпус и лицевая панель должны быть закреплены на основании Паркомата, который должен иметь специальные отверстия для крепления Паркомата с помощью анкерных болтов.

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

Паркомат должен сохранять работоспособность при прямом попадании на него атмосферных осадков.

Система вентиляции должна обеспечивать создание избыточного давления в корпусе Паркомата через крупноячеистый фильтр.

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

На корпусе Паркомата должна быть предусмотрена установка опциональной батареи солнечных элементов и возможностью ориентации по солнцу (при установке на объекте). Внутри корпуса должно быть предусмотрено место для установки опциональной аккумуляторной батареи для буферизации батареи солнечных элементов (с соответствующим зарядным контроллером). Контроллер питания Паркомата должен предусматривать приоритетный выбор питания от ИБП или от опциональной системы питания на солнечных элементах.

Корпус Паркомата должен быть вандалостойким и являться основным несущим элементом конструкции. Нижняя часть корпуса (не менее 1/3) должна быть выполнена из нержавеющей стали. Внутренние элементы конструкции, изготавливаемые без применения сварных соединений, должны быть выполнены из стали тонколистовой оцинкованной, для холодной штамповки нормальной или глубокой вытяжки, первого или второго класса цинкового покрытия по ГОСТ 14918 - 80 "Сталь тонколистовая оцинкованная с непрерывных линий". Дверь Паркомата должна быть оснащена замком с ригельной системой запирания. В основании должны быть четыре отверстия для крепления Паркомата к полу с помощью анкерных болтов.

Терминал должен быть окрашен порошковой краской в стилистике и цветовой гамме, согласованной с Заказчиком. Применяемая порошковая краска должна поддерживать функцию "антиграффити" (малая адгезия с наносимыми на корпус красками для легкой отчистки корпуса устройства от краски).

3.1.1.1 Функциональные требования к комплектующим Паркомата и ПО Паркомата

На квитанции термопринтера должны отражаться сведения о произведенной оплате парковки - время оплаты, способ оплаты, сумма списания, время окончания оплаченной парковки, информация об администраторе дохода с платных муниципальных парковок, уникальный номер операции, номер Паркомата, номер ГРН и номер парковочной зоны.

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

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

3.1.2 Требования к форм-фактору комплекса видеофиксации нарушений правил парковки

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

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

Интерфейсы управления и логика управления устройствами видеофиксации должен быть стандартизированы вне зависимости от форм-фактора исполнения.

3.1.2.1 Функциональные возможности устройства видеофиксации

Блок видеофиксатора должен обеспечивать получение видеоматериала, привязанного к географическим координатам.

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

Комплекс должен обеспечивать в автоматическом режиме:

видеорегистрацию нарушений правил парковки;

запись видеоматериала, содержащего видеозапись общего плана и увеличенное изображение номерного знака, достаточное для его распознавания;

привязку видеоматериала к географическим координатам;

распознавание номерного знака, в том числе в темное время суток;

определение процента текущей занятости парковки;

отправку результатов обработки в АИС Парковочного пространства в онлайн режиме с использованием беспроводных каналов связи.

Данные о нарушении должны включать:

не менее одной цифровой фотографии транспортного средства;

распознанный номер ГРЗ;

дату и время нарушения;

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

информацию о приборе (название и серийный номер).

3.1.3 Требования к Платежному контроллеру Паркомата

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

Общие требования

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

3.1.3.1 Требования к приему Банковских карт

Платёжный контроллер должен иметь возможность принимать к обслуживанию карты международных платежных систем (как минимум карты VISA и MasterCard).

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

При выполнении операции оплаты через контактный интерфейс банковской карты, ПО Платежного контроллера должно предложить Клиенту набрать ПИН-код карты для осуществления операции аутентификации держателя карты. По окончанию проведения процедур аутентификации, Платежный контроллер должен выполнить соединение с хостовой системой банка эквайера и провести выполнение операции в режиме on-line. По успешному окончанию выполнения операции оплаты произвести печать чека Клиенту с указанием реквизитов проведенной операции оплаты для обеспечения предоставления возможности Клиенту предъявить претензию по совершенной операции оплаты парковки банку эмитенту своей карты. При выполнении операции оплаты через бесконтактный интерфейс, Платежный контроллер должен обеспечить проведение оплаты согласно лимитов и правил, заданных эмитентом карты в режиме off-line. В случае отсутствия необходимого лимита на карте, Платежный контроллер должен выполнить оплату в режиме on-line.

3.1.3.2 Требования к программно-аппаратному комплексу (ПАК) для приема оплаты по банковской карте

Программно-аппаратный комплекс (ПАК) для приема оплаты по банковской карте должен полностью соответствовать требованиям по безопасности PCIPED (PCIPTS), а также требованиям EMVCo.

ПАК должен соответствовать требованиям, как минимум, одного из международных стандартов по безопасности:

Payment Card Industry (PCI) Unattended Payment Terminal (UPT) Security Requirements Version 1.х.

Payment Card Industry (PCI) POS PIN Entry Device Security Requirements Version 2.х.

Point of Interaction (POI) Modular Security Requirements v3.х.

ПАК должен включать в себя EFT терминал для работы с банковскими картами.

EFT терминал должен состоять из клавиатуры для ввода PIN, дисплея подсказок для взаимодействия с пользователем, отображающего ход ввода PIN, процессора и памяти для обработки PIN, в комплекте с сертифицированным FW. Все три составные части EFT терминала могут быть выполнены:

в одном интегрированном модуле, сертифицированном по стандарту PCIPED v2.0 и выше;

в виде совокупности отдельных модулей имеющих общий сертификат PCIPED v2.0 и выше;

в виде отдельных модулей, имеющих независимый сертификат PCIPTS 3.0 и выше на каждый модуль.

Считыватель пластиковых карт (контактных и с магнитной полосой).

Считыватель для работы с бесконтактными банковскими картами по технологиям EMV (PayPass и PayWave). Считыватель должен иметь возможность одновременной работы с картами не менее 3х различных типов и картами по стандарту EMV. Считыватель должен обеспечивать переключение режимов работы с одного типа карт на другой не более чем за 20 мс в рамках одной сессии работы с картой без выключения поля и сброса карты.

Программную библиотеку, имеющую сертификат EMV Level 2 для используемого в EFT терминале процессора и операционной системы.

Для работы с банковским процессингом обработки транзакций, ПАК должен иметь в своем составе ПО обеспечивающее взаимодействие не менее чем с двумя поставщиками процессинговых решений, работающих на рынке РФ (необходимо приложить письмо или сертификат от поставщика процессингового решения об успешном прохождении испытаний).

ПАК должен поддерживать верификацию/проверку PIN в режиме Online (OnlinePIN Verification) для всех типов карт.

ПАК должен поддерживать возможность off-line обработки платежа без ввода PIN на суммы до 1000 рублей включительно для бесконтактных EMV карт.

3.1.3.3 Требования по обновлению конфигурационных данных Платежного контроллера

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

3.1.3.4 Требования к состоянию работы Платежного контроллера

Платежный контроллер должен обеспечивать возможность находится в двух устойчивых состояниях - "режим обслуживания" (in-service) и "режим сервисного обслуживания" (out-service). В режиме in-service Парковочный контроллер может выполнять рабочий цикл и принимать оплату парковки от Клиента.

Перевод Парковочного контроллера в режим out-service вызывает прекращение возможности приема платежей и предназначен для проведения технологических работ.

Факт перехода из состояния "режим обслуживания" (in-service) в состояние "режим сервисного обслуживания" (out-service) и обратно должен передаваться в систему технического мониторинга паркоматов, являющуюся составной частью АИС Парковочного пространства.

3.1.3.5 Требования к бизнес-логике проведения оплаты парковки

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

Ожидание начала оплаты парковки.

Цикл ввода информации о парковке.

Оплата парковки.

Печать чека о выполненной оплате парковки, выгрузка информации о проведенном платеже в АИС Парковочного пространства.

Переход в цикл ожидания начала оплаты парковки.

3.1.3.6 Требования к обеспечению безопасности проведения платежей

Для обеспечения безопасности проведения платежей, Платежный Контроллер должен:

Иметь аппаратный блок хранения ключей (далее - HSM), необходимых для проведения платежа по Банковской карте или парковочной карте;

Поддерживать возможность ввода в HSM мастер ключа, под которым зашифрованы все рабочие симметричные ключи Платежного Контроллера;

Поддерживать возможность приема от АИС Парковочного пространства новых рабочих ключей с идентификацией их по индексу рабочего ключа;

Поддерживать работу стоп-листа (по Банковским и парковочным картам).

3.1.4 Требования к Парковочным картам

Парковочная (или транспортная) карта - безналичное платежное средство, обеспечивающее возможность Клиенту осуществить регистрацию и повременную оплату парковки автотранспорта в зоне действия платной парковки через установленные Паркоматы. Парковочная карта не имеет предустановленного номинала. Парковочная карта выпускается с различным Мапингом, защищенным различными видами ключевой информации на различных физических носителях (разных типах бесконтактных карт).

Парковочная карта может быть выпущена на одном из следующих физических носителей:

MifareClassic 1k (или эквивалент), MifareClassic 4k (или эквивалент);

MifareUltralight (или эквивалент); MifareUltralight CMifareUltralight (или эквивалент);

MifarePlus (или эквивалент); Семейство MifarePlus (или эквивалент).

Эмуляция MifareClassic1k (или эквивалент).

Каждая из реализаций эмуляции MifareClassic 1k (или эквивалента) имеет свои особенности, которые должны быть учтены при размещении на данном типе физического носителя.

Минимальный требуемый набор элементов данных парковочных карт и их назначение

Идентификация

Идентификационный номер парковочной карты предназначен для однозначной идентификации при проведении операции с его использованием.

Срок действия парковочной карты устанавливается при персонализации.

Указывается срок действия в днях с момента её активизации. В течение срока действия незаблокированная парковочная карта является действительной для совершения операций с её использованием.

Версия мастер-ключа: элемент данных парковочной карты, представляющий собой указание на значение версии мастер-ключа, использовавшегося при генерации индивидуального ключа карты.

Версия Мапинга парковочной карты определяет состав, значение и организацию элементов данных в памяти карты, и предназначена для корректной обработки структуры данных в Паркоматах.

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

Платежи парковочной картой

Дата/время последней операции оплаты: значение элемента данных, содержащее локального значения даты/времени Паркомата, в котором была произведена последняя операция оплаты парковки.

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

Стоимость парковки: элемент данных, содержащий количество Тарифных единиц, потраченных при выполнении последней операции.

Время парковки: элемент данных, содержащий информацию о количестве минут оплаченных при последней операции.

Льготы

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

Срок действия права на льготу: элемент данных парковочной карты, определяющий начальный и конечный срок действия права на льготу по оплате парковки, либо периода предоставления льгот (в зависимости от версии Мапинга).

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

3.1.4.1 Требования к приему Парковочных карт

Платежный контроллер, после проведения Клиентом ввода реквизитов автотранспортного средства и времени стоянки и перехода к процедурам проведения оплаты, должен:

Считать из своей защищенной памяти ключи доступа к парковочной карте;

Из блока параметров считать номера секторов и типы физических носителей парковочной карты;

Провести попытки прочитать сектора данных парковочной карты, используя доступные ключи доступа;

При первом успешном предоставления доступа к сектору, содержащего номер версии Мапинга, считать версию с парковочной карты, считать из своей памяти параметрический блок работы для этой версией Мапинга;

Провести идентификацию карты, проверку статуса, проверку защитного блока карты и др. проверки, необходимые для этой версии Мапинга ПБ;

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

3.1.5 Требования к модулю эмиссии

Эмиссия парковочной карты: процедура выпуска, учета и подготовки информации по изготовленным парковочным картам. Процедура возможна только при условии подключения аппаратного устройства безопасного хранения ключевой информации (HSM), содержащего ключи инициализации памяти парковочной карты и Мапинга карты. Эмиссия должна происходить отдельными партиями (выпусками), каждому из которых должно присваиваться уникальный идентификатор и группа параметров, определяющих параметры этого выпуска. Параметры, на основе которых происходит выпуск карты, должен быть сохранены в аппаратной системе безопасного хранения данных.

Пополнение баланса парковочной карты: процедура установки баланса парковочной карты. Процедура производится при первичной продаже карты Клиенту, либо в течении жизненного цикла парковочной карты.

Процедура пополнения баланса парковочной карты выполняется оператором автоматизированного рабочего места (АРМ) при помощи специализированного программного обеспечения.

3.1.6 Требования к модулю мониторинга АИС Парковочного пространства

Модуль мониторинга АИС Парковочного пространства должна взаимодействовать с Платежным Контроллером Паркомата, обмениваясь блоками информации, достаточными для получения от Паркомата информации о его техническом состоянии и о проведенных на Паркомате оплат парковки и достаточной для Паркомата информации о режиме его работы (передача параметрического блока, передача команд управления и т.д.).

Минимальный требуемый набор компонентов для мониторинга технического состояния Паркомата:

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

Техническое состояние всех аппаратных устройств Платежного контроллера-чекового принтера, кард ридера, клавиатуры и т.д.

Техническое состояние всех датчиков Паркомата - датчик положения Паркомата, датчик температуры, состояния двери и т.д.

События (alarm) состояния Паркомата.

При наличии угрозы отключения Паркомата по причине отсутствия электропитания и низкого заряда батарей модуль АИС Парковочного пространства должен выдавать предупреждение о подобном событии для учетной записи ответственного оператора и администратора Системы.

В процессе работы Паркомата, в его техническом состоянии могут происходить изменения, которые должны подразделяться на 4 состояния:

рабочее состояние;

некритический сбой;

критический сбой;

выключено.

К предупреждающим сообщениям (некритический сбой) должно быть отнесено:

переход в режим питания от аккумуляторной батареи;

предложен к оплате незарегистрированный ПБ или ПБ, находящийся в стоп листе;

переход в рабочий режим обслуживания (in-service);

переход в технологический режим (out-service);

заканчивается лента в принтере.

К числу аварийных событий (критический сбой) должно быть отнесено:

не проходит тест с устройством (код устройства);

окончилась бумага в принтере;

неисправность ридера карт (ПБ или Банковской карты);

ошибки в системе оплаты;

срабатывание датчика открытие двери, изменения состояния датчика выше допустимого (превышение температуры, перегрев блока питания и т.д.).

При некоторых аварийных ситуациях, Платежный контроллер должен автоматически (при фиксации этого события) переводить режим работы из in-service в out-service. Условие перехода должно задаваться в параметрическом блоке работы Платежного контроллера (например, неисправность чекового принтера, неисправность ридера приема карт, неисправность клавиатуры, открытие двери, превышение допустимой температуры и т.д.

3.1.7 Требования к программному комплексу системы управления парковочным пространством

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

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

3.1.7.1 Требования к организации платежей в системе

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

Уникальным идентификатором пользователя при платеже с использованием паркомата должен считаться ГРН ТС. В этом случае платежи не проходят через парковочный счет пользователя и не отображаются в истории оплат личного кабинета пользователя;

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

В последнем случае должна быть выполнена следующая последовательность:

1. Списание денежных средств с мобильного телефона/банковской карты или других способов оплаты;

2. Зачисление денежных средств на парковочный счет пользователя (либо анонимный счет) в Системе;

3. Списание необходимого для оплаты услуг объема денежных средств с парковочного счета, привязанного к данному уникальному идентификатору.

В случае платежей внутри Системы (оплата через мобильное приложение, SMS или личный кабинет) в первую очередь должны быть списаны деньги с парковочного счета пользователя, а запрос на пополнение счета выбранным пользователем способом должен приходить в недостающем объеме денежных средств.

3.1.7.2 Требования к бизнес-логике SMS платежей

Система должна быть настроена на взаимодействие со шлюзом оператора единого виртуального короткого номера, который предоставляет сервис мобильных платежей (далее Сервис оператора короткого номера).

Сервис SMS-платежей позволяет производить оплату за услуги платных муниципальных парковок с лицевого счета абонента сотового оператора при помощи SMS сообщений.

Система должна предоставлять возможность проводить акцептные и безакцептные платежи:

Акцептный платеж - списание денежных средств с лицевого счета абонента оператора сотовой связи в счет оплаты Услуги в момент подтверждения Клиентом Платежа с помощью отправки повторного (непустого) SMS сообщения.

Безакцептный платеж - списание денежных средств с парковочного счета Клиента в Системе организации парковочного пространства города в счет оплаты Услуги в момент отправки Клиентом SMS сообщения определенного вида.

Различия двух видов платежей заключатся в источнике денежных средств, с которого осуществляется оплата Услуги. При превышении суммы Платежа Парковочного счета Клиента должно происходить совмещение двух видов платежей с проведением Акцептного платежа в части недостающей суммы.

Взаимодействие должно осуществляться по протоколу HTTP.

Сервис SMS-платежей должен позволять получать автоматические оповещения о результатах Платежа, а также получать их по запросу.

Проведение акцептного платежа

Акцептный платеж позволяет списать денежные средства в лицевого счета абонента сотового оператора (далее Лицевой счет АОСС). Данный тип платежа используется в случае, если сумма Платежа превышает сумму Парковочного счета. Акцептный платеж производится только в части Платежа, превышающую сумму Парковочного счета.

Бизнес-логика при проведении акцептного платежа выглядит следующим образом:

1. Клиент отправляет SMS в заданном формате.

2. Сервис оператора короткого номера инициирует Платеж, отправляя запрос на адрес Системы.

3. Система обрабатывает запрос, проводит проверку корректности запроса.

4. Система сравнивает значения суммы Платежа с суммой Парковочного счета, формирует значение суммы Акцептного платежа.

5. Система отправляет ответ со статусом запроса.

6. Система отправляет запрос на адрес Сервис оператора короткого номера на списание суммы Акцептного платежа с Лицевого счета АОСС.

7. Сервис оператора короткого номера отправляет ответ со статусом запроса.

8. С короткого сервисного номера оператор сотовой связи отправляет SMS сообщение Клиенту для подтверждения Платежа с указанием суммы Акцептного Платежа.

9. Клиент отправляет непустое SMS сообщение с произвольным текстом для подтверждения Платежа.

10. Сервис оператора короткого номера отправляет запрос на адрес Системы с результатом списания.

11. Система пополняет Парковочный счет Клиента на сумму Акцептного платежа.

12. Система проводит Безакцептный платеж с Парковочного счета Клиента в счет оплаты Услуги.

13. Система отправляет ответ со статусом запроса.

14. Сервис оператора короткого номера отправляет SMS Клиенту с подтверждением успешного завершения Платежа.

Проведение безакцептного платежа

В случае если сумма Платежа меньше Парковочного счета пользователя, Система не запрашивает Сервис оператора короткого номера о проведении Акцептного платежа. Таким образом, полный процесс оплаты при акцептном платеже выглядит следующим образом:

1. Клиент отправляет SMS в заданном формате.

2. Сервис оператора короткого номера инициирует Платеж, отправляя запрос на адрес Системы.

3. Система обрабатывает запрос, проводит проверку корректности запроса.

4. Система обрабатывает запрос, сравнивает значения суммы Платежа с суммой Парковочного счета.

5. Система проводит Безакцептный платеж с Парковочного счета Клиента в счет оплаты Услуги.

6. Система отправляет ответ со статусом запроса.

7. Сервис оператора короткого номера отправляет SMS Клиенту с подтверждением успешного завершения Платежа.

То есть, Платеж является совокупностью Акцептного и Безакцептного платежа при невозможности завершения Безакцептного платежа ввиду недостаточной суммы Парковочного счета Клиента.

Статусы ответа

Основной характеристикой в процессе проведения Платежа является статус HTTP-ответа на запрос, который может быть дополнен сообщением, которое передается Сервисом оператора короткого номера Клиенту. Статус определяет текущий и следующий шаги процесса обработки Платежа.

HTTP-ответ со статусом 200

Означает успешное выполнение запроса с необходимостью отправки Клиенту SMS сообщения с текстом, указанным в теле (body) HTTP-ответа.

Кодировка сообщения UTF-8.

HTTP-ответ со статусом 204

Означает успешное выполнение запроса без необходимости отправки Клиенту SMS сообщения.

HTTP-ответ с иным статусом

Означает ошибку выполнения запроса и остановку выполнение Платежа с занесением информации о ходе выполнения в журнал ошибок Системы.

Досрочная остановка парковочной сессии

Досрочная остановка парковочной сессии должна производится при отправке Клиентом SMS сообщения установленного формата. При этом Система должна произвести перерасчет на основании фактического времени использования платного парковочного места, с момента проведения Платежа до момента обработки запроса об отмене Платежа (прекращении пользования Услугой).

Платеж, уменьшенный на сумму, соответствующую оплате времени фактического использования Услуги, должен поступать на Парковочный счет Клиента.

3.1.7.3 Требования к формату взаимодействия Системы с Клиентом и сервисом оператора коротких номеров при проведении SMS-платежей

3.1.7.3.1 Протокол взаимодействия

Система должна взаимодействовать с Сервисом оператора короткого номера по HTTPS, Сервис оператора короткого номера должен взаимодействовать с Системой по протоколу HTTPS. Вызов операции представляет собой HTTP-GET запрос. Все значения параметров должны быть в кодировке UTF-8.

В ответ на этот вызов должен обрабатываться HTTP-ответ с кодом 200 или 204 в случае успешного выполнения операции, любой другой код в теле ответа означает ошибку выполнения запроса.

Все значения возвращаются в кодировке UTF-8.

3.1.7.3.2 Требования к обработке входящих сообщений

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

В случае, если для проведения Платежа достаточно средств Парковочного счета Клиента, Система должна вернуть результат с кодом 200 с подтверждением проведения платежа в теле ответа.

Описание требуемых форматов SMS сообщения;

Логическая операция	Формат данных	Пример
Оплата парковочной сессии	p+код_регионаномер_зоныномер_ТС*кол-во_часов	P46101A001AA46*2
Продление парковочной сессии	p+код_регионаxкол-во_часов	P46x3
Остановка парковочной сессии	p+код_региона*c	P46*с

Возможные типы и формат данных SMS сообщения:

Поле	Тип данных	Описание
Код региона	Двух- или трехзначное число	Один из выделенных государственных кодов автотранспортных средств, зарегистрированных в регионе.
Номер зоны	Трех или четырехзначное число	Номер парковочной зоны, в которой находится ТС Клиента (определяется при первичной инсталляции Системы)
Номер ТС	SDDDSSDD(D),где: S-символ, D-цифра	Установленный формат государственных номеров ТС.

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

3.1.7.4 Требования к модулю управления льготами и тарифами

Модули управления льготами и тарифами должны быть интегрированы с модулем интеграции с системами видеофиксации посредством внутренних программных интерфейсов АИС Парковочного пространства.

Модуль управления тарифами должен обеспечивать возможность расчета стоимости парковки с учетом:

различных зон;

дней недели;

времени суток.

Необходимо обеспечить возможность ценовых предложений согласно динамического ценообразования на основании информации о загруженности парковочных мест в парковочной зоне за предыдущие периоды (3 месяца).

Модуль управления льготами должен корректировать тарифы для определенных категорий граждан (резиденты зоны платных парковок, инвалиды, ветераны и т.д.). Льготы назначаются конкретным гражданам или категориям граждан с уточнением по зоне/дате/времени/дню недели и действуют на указанные в парковочном разрешении номера ТС.

Типы льгот:

Бесплатная парковка;

Снижение стоимости парковки на заданный процент;

Фиксированная стоимость парковки;

Составной тариф:

Бесплатная парковка с ограничением по времени;

Ограничение дневной суммарной стоимости парковки.

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

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

3.1.7.5 Требования к модулю интеграции с системами видеофиксации

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

Задачи в рамках модуля интеграции с системами видеофиксации:

Должна существовать возможность единовременного анализа нескольких файлов с данными видеофиксации;

Необходимо предусмотреть льготный период для оплаты парковочных мест;

Необходимо реализовать функционал постоплаты в заданный период в случае возникновения у пользователя необходимости оплатить парковку позже (критическая ситуация, нет средств на телефоне и т.д.);

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

3.1.7.6 Требования к модулю отчетности

Система должна давать возможность предоставления статистической информации о загруженности парковочного пространства на УДС в разрезе времени (в фиксированный момент, а также за периоды: N часов, N суток, N недель, N месяцев, год) в разрезе парковочных зон в виде таблиц, графиков и CSV файлов:

Количество сессий;

Оборачиваемость парковочных мест;

Средняя длина парковочной сессий (всех или долее 15 минут);

Загрузка;

Свободные места;

Распределение в % соотношении парковочных сессий (а) до 15 минут, (б) от 15 до 30 минут, (в) от 30 минут до 1 часа, (г) от 1 часа до 3 часов, (д) долее 3 часов;

Интенсивность использования.

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

В рамках настоящего Технического задания Заказчик имеет право потребовать доработки конкретных отчетных форм, содержащих типовые сведения о работе парковочного пространства, в количестве не более 5-ти. Детальные формы отчетов для разработки по требованию предоставляются Заказчиком.

3.1.7.7 Комплекс специализированного ПО для пользователей парковочного пространства

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

Комплекс специализированного ПО должен включать в себя:

интернет-портал с интерактивной картой парковочного пространства, актуальной информацией по работе с УДС и возможностью интеграции с третьими сервисами (например, штрафстоянки);

отображение интернет-портала должно быть адаптировано под просмотр как на стационарных, так и на мобильных устройствах;

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

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

3.1.7.8 Требования к интернет-порталу

На интернет-портале должны быть реализованы пользовательские интерфейсы, обеспечивающие получение информации о состоянии парковочных зон, правилах пользования парковками, правилах оплаты, личных данным пользователя, а также оплату парковочных сессий.

На интернет-портале должно быть реализовано отображение парковок и других объектов парковочного пространства (информационное табло, пункты оплаты и др.) на картографической подложке. Отображение объектов на карте должно иметь возможность настройки администратором вебсайта: создание/редактирование объектов и их категорий.

При выборе парковки с карты должны быть представлены адрес парковки, а также общее количество мест на парковке и количество свободных мест в этой парковочной зоне. На карте должна быть реализована автоматическая цветовая градация парковок в зависимости от их занятости автомобилями. Данные о занятости генерируются с помощью системы биллинга или на базе внешнего источника (агрегатор сигналов с датчиков наличия места).

На сайте должны быть предусмотрены следующие редактируемые с помощью системы администрирования разделы:

"О проекте" - для публикации общей информации о проекте;

"Вопрос-ответ" с возможностью отправки вопросов пользователями и публикацией связки "вопрос-ответ" администратором вебсайта;

"Обратная связь" для отправки вопросов и жалоб оператору службы поддержки.

Пользователи интернет-портала должны иметь возможность доступа к личным кабинетам, в которых должны быть реализованы механизмы пополнения парковочного счета пользователя в Системе при помощи SMS-сообщений и банковских карт. В личном кабинете должны отображаться личные данные пользователя, информация о его транспортных средствах, льготах, резидентных соглашениях и необходимых для получения услуг документах. Необходимо предоставить доступ пользователю к архиву произведенных операций.

3.1.7.9 Требования к мобильным приложениям

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

В мобильных приложениях должно быть реализовано отображение парковок на картографической подложке. При выборе парковки с карты должны быть представлены адрес парковки, а также общее количество мест на парковке и наличие на них свободных мест. Также должны быть представлены правила пользования для парковок в части въезда/выезда, правил размещения и оплаты парковки.

Мобильные приложения должны предоставлять пользователю возможность оплаты использования парковочных мест, а именно пополнения личного счета в системе посредством SMS сообщений (мобильная коммерция) или банковской карты.

Мобильное приложение должно использовать единый с вебсайтом источник данных.

Мобильное приложение должно предоставлять информацию о ближайшем свободном парковочном месте для пользователя.

3.1.7.10 Требования к аналитическому модулю

Ключевые задачи аналитического модуля:

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

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

выявление трендов и предпочтений пользователей по использованию парковочной инфраструктуры;

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

формирование рекомендаций по корректировке стоимости парковочных мест, форматированию зон и динамическому ценообразованию.

Аналитический модуль должен функционировать на базе собранных в рамках проекта данных. Время сбора требуемых данных для запуска аналитического модуля: не более 3 месяцев. Все данные аналитического модуля должны быть доступны в форме соответствующих отчетов.

3.1.7.11 Требования к модулю сверки данных банковского процессинга

Для контроля целостности транзакций и соответствия данных БД и процессингов банков всех видов платежей ПО Системы должно обладать инструментами сверки по каждому из используемых видов платежей.

Модуль сверки поступающих данных о платежах по банковским платежным картам должен быть настроен на импорт и обработку файлов формата Excel (или csv), в формате, согласованном с банком-эквайером, соответствующего вида платежа. Формат взаимодействия и механизма сверки Инвестор согласовывает самостоятельно.

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

3.1.7.12 Требования к модулю управления объектами инфраструктуры

Должна быть реализована система справочных данных, хранящая информацию об объектах парковочной инфраструктуры:

Зоны платной парковки;

Парковки (придорожные, закрытые, перехватывающие);

Пункты приема оплаты;

Паркоматы;

и другие.

Необходимо реализовать возможность добавления произвольного количества объектов и их групп с привязкой к конкретному месту карты, а также назначение им идентификатора для отображения на интернет-портале и мобильных приложениях.

3.1.7.13 Требования к модулю технического мониторинга

Модуль технического мониторинга должен предоставлять информацию о состоянии оборудования и других доступных объектов инфраструктуры, например платежных каналов.

В техническом мониторинге должна отображаться информация о Паркоматах:

Регистрационные данные Паркоматов;

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

Журналы проведенных операций Паркоматами;

Текущее состояние Паркоматов, режим работы Паркомата, состояние устройств Паркомата;

Историю технического состояния Паркомата.

Номер и адрес Паркомата;

Статус;

Данные о платежных и других устройствах с последним зафиксированным событием;

Время последнего контакта и время последнего успешного контакта с Паркоматом.

В техническом мониторинге должна отображаться информация о состоянии платежных шлюзов:

Поставщик услуги оплаты;

Канал (в случае мобильной коммерции, один из операторов);

Количество ошибок на канале за указанный период времени;

Время последнего отклика и время последней успешной транзакции.

Должна быть возможность выбрать имя или номер объекта, после чего должна быть представлена более детальная информация о нем. Если оператор находится в режиме просмотра детальной информации - у него должна быть возможность редактирования информации или оставления комментария по оборудованию.

3.1.7.14 Требования к модулю управления заявками

Модуль управления является автономной подсистемой системы администрирования. В нем должна быть реализована возможность регистрации сотрудников сервисной службы: инженеров, менеджеров и администраторов.

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

После успешной авторизации оператору должны быть отображены данные по заявкам, актуальным работам и состоянию оборудования.

Администратор должен иметь возможность создания/редактирования следующих элементов:

Категории заявок;

Статусы заявок;

Виды сервиса;

Уровни сервиса;

Объекты парковочной инфраструктуры.

Должна быть реализована возможность оповещения посредством SMS и Email, в том числе и редактирования шаблонов соответствующих сообщений.

У оператора обработки заявок в меню "Запросы" должна быть возможность создать новый запрос, так же просмотреть список уже существующих запросов и историю запросов.

Модуль должен отвечать следующим требованиям:

Соответствие стандартам ITIL;

Регистрация и обработка заявок и инцидентов пользователей;

Автоматизированное изменение статусов заявок в соответствии с метриками SLA;

Автоматизированный прием заявок по E-mail;

Возможность прикрепления файлов и скриншотов к заявке;

E-mail и SMS уведомления о статусе заявки;

Возможность авторизации на основе учетных записей Active Directory;

Отчеты по заявкам в разрезе заявителя и исполнителя за определенный период;

Регистрация и классификация инцидентов в инфраструктуре;

Возможность автоматического сохранения записи в базе знаний по решению инцидента;

Возможность прикрепления файлов и скриншотов к инциденту;

Отчеты об инцидентах в разрезе оборудования и объектов инфраструктуры;

Логирование истории изменения инцидентов;

Возможность экспорта отчетов в Microsoft Excel;

Каталог сервисов с метриками SLA;

База знаний с категориями, для хранения информации о решении инцидентов или документации;

База объектов инфраструктуры с привязкой составных частей оборудования и соответствием возникших инцидентов;

История изменений объектов и связанного оборудования;

Конструктор типов оборудование с настраиваемым набором полей;

Печать и экспорт в PDF-карточки объекта и связанного оборудования;

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

3.1.7.15 Прочие требования

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

система автоматического тестирования;

система нагрузочного тестирования;

интерфейсы для интеграции с программными комплексами парковочного пространства.

3.1.7.16 Требования к режимам функционирования

Система должна функционировать 24 часа в сутки, 7 дней в неделю.

Для обновления Системы не должна требоваться остановка работы и приведение базы данных к определенному состоянию. Исключением может быть только переход с одной версии программного обеспечения на другую.

3.1.8 Требования по диагностированию

Диагностирование осуществляется путем анализа записей в системных журналах СУБД, веб-сервера и операционной системы.

Диагностированию подлежат:

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

случаи нарушений целостности баз данных и файловой системы;

сбои при выполнении регламентных операций резервного копирования.

3.1.9 Требования к надежности технических средств и программного обеспечения

Надежность Системы должна обеспечиваться:

использованием технических средств повышенной отказоустойчивости и их структурным резервированием;

защитой технических средств по электропитанию путем использования источников бесперебойного питания;

дублированием носителей информационных массивов.

Назначенные сроки службы, среднее время наработки на отказ не устанавливаются, а определяются в соответствии с заявленными производителями характеристиками выбранных технических средств.

3.1.10 Перечень аварийных ситуаций

При разработке Системы необходимо учитывать возможность возникновения следующих аварийных ситуаций:

сбой общего или специального ПО сервера;

выход из строя части технических средств;

сбои или выход из строя активного накопителя на жестком магнитном диске;

ошибки обслуживающего персонала при работе с Системой;

импульсные помехи, сбои или прекращение электропитания.

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

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

3.1.11 Требования безопасности

Программно-аппаратные средства АРМ с установленной Системой должны обеспечивать безопасность обслуживающего персонала при эксплуатации, техническом обслуживании и ремонте с учетом требований ГОСТ 21552 - 84, ГОСТ 25861 - 83.

Электробезопасность должна соответствовать требованиям ГОСТ 12.1.030 - 81, ГОСТ 12.2.003 - 91, ГОСТ 12.2.007.0 - 75.

Силовые кабельные комплекса технических средств модуля должны отвечать требованиям "Правил устройств электроустановок" (ПУЭ).

Технические средства должны отвечать действующей системе государственных стандартов безопасности труда и иметь сертификаты по электробезопасности и электромагнитной безопасности.

3.1.12 Требования к эргономике и технической эстетике

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

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

3.1.13 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

Система не должна предъявлять дополнительных требований к техническому обслуживанию используемых технических средств.

Регламент технического обслуживания сервера и рабочих станций и регламент резервного копирования БД должны быть согласованы на этапе опытной эксплуатации.

3.1.14 Общие положения

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

"Вычислительная среда";

"Среда хранения";

"Среда исполнения";

"Резервное копирование и восстановление данных".

3.1.15 Требования к организации услуг по эксплуатации системы

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

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

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

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

Время приема обращения - круглосуточно, включая выходные и праздничные дни;

Время реакции - не более 2 часов;

Время восстановления - не позже следующего рабочего дня после приема обращения.

Уровень поддержки на все программное обеспечение, используемое для реализации Сервиса в рамках настоящего технического задания должен удовлетворять следующим требованиям:

Время приема обращения - круглосуточно, включая выходные и праздничные дни.

Время реакции - не более 1 часа.

Время восстановления - не более 12 часов.

3.1.15.1 Описание услуги "Вычислительная среда"

Оказание услуги "Вычислительная среда" заключается в предоставлении и дальнейшей поддержке среды вычислений.

Среда вычислений - это совокупность, образованная микроархитектурой, микропрограммой управления ядром микропроцессора и архитектурой набора команд на аппаратной базе конкретных микросхем процессора, набора микросхем оперативной памяти, контроллеров, шин и других компонентов для реализации вычислений.

Услуга предоставляется на базе физических или виртуальных ресурсов серверного оборудования.

Для обеспечения отказоустойчивости Инвестор должен предусмотреть избыточность на уровне компонентов комплекса, на базе которого реализуется услуга.

В рамках предоставления услуги "Вычислительная среда" должны выполняться:

Настройка и оптимизация компонентов среды

Установка исправлений и обновлений программных средств и микрокодов

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

Мониторинг и контроль работоспособности компонентов среды

Мониторинг параметров состояния среды

Мониторинг утилизации среды

Действия по предупреждению сбоев компонентов среды

Восстановление среды после сбоев

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

3.1.15.2 Описание услуги "Среда хранения"

Оказание услуги "Среда хранения" заключается в предоставлении и дальнейшей поддержке среды хранения.

Среда хранения - это совокупность аппаратных и программных средств, систем хранения, сконфигурированных в соответствии с заданными параметрами, предназначенными для записи, хранения данных и предоставления доступа к ним для чтения и изменения.

Основными параметрами Услуги являются объем полезного пространства, количество, тип, производительность носителей информации, а также тип организации избыточности.

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

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

В рамках предоставления услуги "Среда хранения" должны выполняться:

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

Установка исправлений и обновлений программных средств и микрокодов

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

Мониторинг и контроль работоспособности всех компонентов среды

Мониторинг параметров состояния

Мониторинг утилизации

Действия, по предупреждению сбоев

Управление доступом к компонентам среды

Восстановление после сбоев

3.1.15.3 Описание услуги "Среда исполнения"

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

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

Услуга организуется на базе программного обеспечения и лицензий Инвестора.

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

В рамках предоставления услуги "Среда исполнения" должны выполняться:

Инсталляция компонентов среды исполнения приложений.

Настройка компонентов среды исполнения приложений.

Установка исправлений и обновлений компонентов среды исполнения приложений в рамках проведения регламентных технологических перерывов.

Управление доступом к компонентам среды исполнения приложений.

Мониторинг и контроль работоспособности всех компонентов среды исполнения приложений.

Мониторинг параметров состояния среды исполнения приложений.

Действия, по предупреждению сбоев компонентов.

Восстановление среды исполнения приложений после сбоев.

Настройка средств обеспечения доступности и отказоустойчивости.

Оптимизация компонентов среды.

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

3.1.15.4 Описание услуги "Резервное копирование и восстановление данных"

Оказание услуги "Резервное копирование и восстановление данных" заключается в организации создания резервных копий на отделяемые носители информации, а также восстановления данных в соответствии с политиками резервного копирования.

Услуга оказывается на базе среды резервного копирования и восстановления данных.

Среда резервного копирования и восстановления данных - это совокупность программных и аппаратных средств, позволяющая обеспечить создание резервных копий, данных на отделяемом носителе (магнитной ленте, жёстком диске, дискете и пр.), предназначенных для последующего хранения и восстановления.

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

Среда резервного копирования и восстановления данных подключается к Вычислительным средам, средам хранения и средам исполнения посредством, как локальной вычислительной сети, так и посредством сети хранения.

Среда резервного копирования и восстановления данных должна удовлетворять следующим требованиям:

Обеспечивать масштабируемость по объему и производительности

Поддерживать гетерогенные среды исполнения приложений и вычислительные среды

Поддерживать программное обеспечение корпоративного уровня (системы управления базами данных, серверы приложений, почтовые серверы, порталы и т.д.)

Обеспечивать резервное копирование данных без их остановки

Поддерживать создание резервных копий через сеть хранения данных

Обеспечивать возможность восстановления данных вне рамок оказания Услуги "Резервное копирование и восстановление данных"

Поддерживать разделение и ограничение доступа к ресурсам управления для администраторов с учетом зон их ответственности

Поддерживать возможность монопольного выделения ресурсов (ленты, приводы) для резервного копирования

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

В рамках оказания Услуги должны выполняться:

Установка и настройка компонентов среды резервного копирования и восстановления данных.

Настройка параметров создания резервных копий и восстановления данных.

Установка исправлений и обновлений компонентов среды резервного копирования и восстановления данных.

Осуществление планового и внепланового резервного копирования и/или восстановления данных в случае аварии и/или по требованию Заказчика

Осуществление восстановления отдельных файлов, записей или объектов по требованию Заказчика.

3.1.15.5 Требования к взаимодействию Заказчика и Инвестора

Взаимодействие Заказчика и Инвестора осуществляется в соответствии с Регламентом взаимодействия Инвестора и Заказчика, разрабатываемым Инвестором и утверждаемым сторонами Инвестора и Заказчика.

Регламент взаимодействия Инвестора и Заказчика должен описывать порядок взаимодействия в следующих ситуациях:

Возникновение сервисного события.

Проведение технологических перерывов.

Обращение в службу технической поддержки.

Процесс эскалации.

Регламент взаимодействия Инвестора и Заказчика должен содержать:

Параметры качества работы технической поддержки.

Порядок получения и использования удаленного доступа для администрирования приложений Заказчика.

Порядок взаимодействия представителей Инвестора Заказчика со службой технической поддержки.

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

3.1.15.6 Требования к обеспечению качества предоставления Сервиса

Любой сбой, в результате которого произошло прекращение действия Сервиса или нарушение параметров предоставления Сервиса считается сервисным событием.

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

Инвестор вправе проводить регламентные технологические перерывы. При этом он должен действовать в соответствии с Регламентом взаимодействия Инвестора и Заказчика.

Во время регламентного технологического перерыва все случаи недоступности Сервиса не считаются сервисным событием, при условии, что Заказчик заранее согласовал с Инвестором технологический перерыв в соответствии с Регламентом взаимодействия Инвестора и Заказчика.

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

Каждому сервисному событию присваивается соответствующий приоритет, зависящий от степени воздействия сервисного события на Сервис.

Приоритет сервисного события определяется по трехуровневой шкале Низкий/Средний/Высокий.

Приоритет сервисного события устанавливается в соответствии с разделом 3.1.13.9.

ГАРАНТ:

По-видимому, в предыдущем абзаце допущена опечатка. Имеется в виду "раздел 3.1.15.9"

При наличии обходного решения, по согласованию с Заказчиком, приоритет сервисного события может быть понижен.

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

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

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

Инвестор должен уведомить Ответственных лиц Заказчика о факте регистрации сервисного события.

Инвестор должен обеспечить сохранение и предоставить Заказчику возможность просмотра состояния зарегистрированных сервисных событий.

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

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

Для обеспечения контроля доступности Сервиса Инвестор должен обеспечить возможность мониторинга параметров Сервиса.

Система мониторинга Инвестора должна обеспечивать возможность:

предоставления Заказчику интерфейса для просмотра состояния среды и ИС;

упреждающего мониторинга, обеспечивающего технический персонал информацией о приближающемся критическом состоянии компонентов сред и ИС, задолго до наступления сервисного события;

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

Для обеспечения качества предоставления Услуги в критических ситуациях Инвестор обязан иметь утвержденный документ "План по обеспечению непрерывности деятельности предприятия и предоставлению услуг".

3.1.15.7 Приоритеты сервисных событий

	Сервисное событие	Приоритет
1	Выход из строя компонента среды или ИС, повлекший за собой отказ в предоставлении услуги	Высокий
2	Выход из строя компонента среды или ИС, повлекший за собой снижение качества предоставляемой услуги	Средний
3	Выход из строя компонента среды или ИС, повлекший за собой снижение надежности предоставляемой услуги	Низкий
4	Внешнее воздействие, повлекшее за собой отказ в предоставлении услуги	Высокий
5	Внешнее воздействие, повлекшее за собой снижение качества предоставляемой услуги	Средний
6	Внешнее воздействие, повлекшее за собой снижение надежности предоставляемой услуги	Низкий

3.1.15.8 Требования к Службе технической поддержки Инвестора

Для обеспечения бесперебойной и эффективной работы АИС Парковочного пространства Инвестор должен организовать функционирование Службы технической поддержки.

Инвестор должен обеспечить возможность контроля хода работ по устранению сервисных событий Ответственному лицу Заказчика.

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

Служба технической поддержки Инвестора должна быть доступна для обращения специалистов Заказчика c 9.00 до 23.00, 7 (Семь) дней в неделю, 365 дней в году.

Инвестор должен обеспечить присутствие дежурной смены инженеров в ЦОД круглосуточно без перерывов 24 (Двадцать четыре) часа в сутки, 7 (Семь) дней в неделю, 365 дней в году.

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

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

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

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

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

При взаимодействии в рамках обращения Заказчика в службу технической поддержки Инвестором должны быть обеспечены параметры качества в соответствии с разделом 3.1.13.11.

3.1.15.9 Параметры качества службы поддержки Инвестора

N	Наименование параметра оценки	Максимальное допустимое значение (не более чем)
N	Наименование параметра оценки	Низкий	Средний	Высокий
1	Доступность службы технической поддержки Инвестора по e-mail - время получения, минут	10	10	10
2	Доступность службы технической поддержки Инвестора по телефону - время, в течение которого осуществляется 80% успешных дозвонов (сек.)	60	60	60
3	Время реакции службы технической поддержки (регистрация сервисного события и уведомления о регистрации), минут	60	30	10
4	Время реакции службы технической поддержки на запрос Заказчика (предоставление развернутого ответа), минут	60	30	10
5	Время устранения сервисного события (время, прошедшее с момента возникновения сервисного события до момента восстановления работоспособности Сервиса), часы	24	4	1
6	Доля заявок, решенных с опозданием (%)	10	5	3
7	Частота появления однотипных сервисных событий за отчетный период (Однотипные сервисные события - повторяющиеся в течение отчетного периода отклонения от штатного режима функционирования, касающиеся одного и того же, или смежных компонентов)	8	4	1

Инвестор должен обеспечить функционирование информационно-справочной службы - Контакт-центра. Контакт-центр должен принимать и обрабатывать все входящие телефонные звонки пользователей парковочного пространства. Время работы Контакт-центра c 9.00 до 23.00, 7 (Семь) дней в неделю, 365 дней в году.

Количество входящих линий должно позволять достаточно быстро дозвониться до оператора Контакт-центра в любое рабочее время. Время ожидания ответа оператора не должно превышать 1 минуты.

Оператор Контакт-центра должен максимально доброжелательно и компетентно предоставить пользователю парковочного пространства необходимую информацию.

3.1.16 Требования по сохранности информации при авариях

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

При этом, должно быть обеспечено восстановление данных в БД и восстановление файлов с данными на серверах по состоянию на момент времени, не превышающий более чем 10 часов от момента сбоя или аварии технических и программных средств, обеспечивающих хранение этих данных.

Для обеспечения сохранности пользовательских данных архитектурой построения Системы должно быть предусмотрено хранение информации исключительно на серверах.

3.1.17 Требования к патентной чистоте

Патентная чистота Системы должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации.

Реализация технических, программных, организационных и иных решений, предусмотренных проектом создания Системы не должна приводить к нарушению авторских и смежных прав третьих лиц.

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

3.1.18 Требования к стандартизации и унификации

Проводимые работы должны соответствовать следующим требованиям:

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

Проектные решения разрабатываемой Системы при выполнении различных функций программы должны обеспечивать:

соблюдение единых правил организации интерфейса с пользователем;

единообразную реакцию на неверные действия пользователей;

использование фиксированного перечня терминов и определений при организации диалога и формировании экранов;

типовой подход к разграничению прав доступа пользователей к информации;

должно быть предусмотрено использование единой системы справочников.

3.1.18.1 Требования к выполнению дорожных работ

Все дорожные работы должны быть выполнены в соответствии с действующими нормативными документами:

ГОСТ Р 52290 - 2004 "Технические средства организации дорожного движения. Знаки дорожные. Общие технические требования";

ГОСТ Р 52289 - 2004 "Технические средства организации дорожного движения. Правила применения дорожных знаков, разметки, светофоров, дорожных ограждений и направляющих устройств".

ГОСТ Р 50597 - 93 "Автомобильные дороги и улицы. Требования к эксплуатационному состоянию, допустимому по условиям обеспечения безопасности дорожного движения".

Работы проводить в соответствии с ВСН 37 - 84 "Инструкция по организации движения и ограждению мест производства дорожных работ".

На корпусе знака или специальной табличке, прикрепленной к знаку, должна быть нанесена маркировка в соответствии с требованием п. 5.7.1 ГОСТ Р 52290 - 2004.

На использованные материалы Инвестором должны быть представлены сертификаты качества.

3.1.19 Требования к сохранению дорожного покрытия

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

3.1.20 Требования по сдачи системы в эксплуатацию

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

Испытания развертываемой Системы должны проводиться с целью определения её готовности к вводу в постоянную эксплуатацию.

Система должна пройти испытания (не менее 14 дней) в условиях города Курск и доказать свою надежность в реальных городских условиях, в независимости от климатических изменений. Образцы оборудования системы должны иметь подтвержденный опыт эксплуатации в городах России либо других странах с аналогичными климатическими условиями при температурах ниже минус 25 градусов.

4. Испытания и проверка качества

Испытания должны проводиться приемочной комиссией Заказчика, с привлечением представителей Заказчика и Инвестора. Комиссия в своей работе должна руководствоваться положениями приёмо-сдаточных испытаний, технической документации на систему.

По результатам выполнения проверок комиссией должен быть составлен Акт проведения приемочных испытаний, являющийся основанием для передачи системы в постоянную эксплуатацию.

5. Требования соответствия нормативным документам (лицензии, допуска, разрешения согласования)

Не требуются.

6. Гарантийные обязательства

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

Выполненные работы должны отвечать всем требованиям гарантий по качеству и безопасности в соответствии с действующими нормами и стандартами, установленными для данного вида работ на территории Российской Федерации.

Все документы должны быть заверены надлежащим образом.

Гарантийный срок на выполняемые по настоящему контракту работы, составляет 1 (один) год с момента подписания акта приемки выполненных работ, а на использованные материалы, механизмы и конструкции - на срок эксплуатации, указанный в сертификате на соответствующее изделие.

<< Приложение 1. Порядок проведения конкурса на право заключения инвестиционного соглашения по оборудованию и эксплуатации на платной основе...		Приложение 2. >> Инвестиционное соглашение по оборудованию и эксплуатации на платной основе парковок (парковочных мест), расположенных на автомобильных...
	Содержание Постановление Администрации г. Курска от 1 сентября 2015 г. N 2581 "Об утверждении порядка проведения конкурса на право...

ГАРАНТ:

Вы можете открыть актуальную версию документа прямо сейчас.