1

Приложение №

к договору № ____________ от _______

УТВЕРЖДАЮ

_________________

«___» ______________ 2019

года

УТВЕРЖДАЮ

____________________

«___» _________________ 2019 года

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

на выполнение составной части научно-исследовательской работы

«Проектирование Платформы «Автодата», разработка технического проекта

в части создания макета «Единого ЦАФАП»

СОГЛАСОВАНО

СОГЛАСОВАНО

______________ ______________

2

Оглавление 1. Общие сведения ..................................................................................................................... 4

1.1. Наименование работы .................................................................................................... 4

1.2. Заказчик и Исполнитель работ ...................................................................................... 4

1.3. Основание для проведения работы ............................................................................... 4

1.4. Сроки выполнения работы ............................................................................................. 4

1.5. Порядок оформления и предъявления Заказчику результатов работ ........................ 4

1.6. Перечень принятых терминов и сокращений .............................................................. 5

1.6.1. Перечень сокращений ............................................................................................. 5

2. Назначение и цели создания Макета ................................................................................... 7

2.1. Назначение Макета ......................................................................................................... 7

2.2. Цели создания Макета .................................................................................................... 7

3. Характеристика объекта автоматизации ............................................................................. 8

3.1. Краткие сведения об объекте автоматизации .............................................................. 8

3.1.1. Фиксация административных правонарушений в области безопасности

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

в автоматическом режиме ..................................................................................................... 8

3.1.2. Фиксация всего проходящего потока ТС с целью выполнения задач

оперативного розыска ........................................................................................................... 8

3.2. Сведения об условиях эксплуатации объекта автоматизации и характеристиках

окружающей среды ................................................................................................................... 9

4. Требования к Макету .......................................................................................................... 10

4.1. Требования к Макету в целом ..................................................................................... 10

4.1.1. Требования к структуре Макета ........................................................................... 10

4.1.2. Назначение и функциональные возможности «Центрального сервера

управления» ......................................................................................................................... 11

4.1.3. Архитектура ЦСУ .................................................................................................. 11

4.1.4. Функции ЦСУ ........................................................................................................ 11

4.1.5. Модули ЦСУ .......................................................................................................... 14

4.1.6. Назначение и функциональные возможности «Регионального сегмента» ...... 22

4.2. Требования к комплексу ФВФ, формирующему данные для передачи в Макет ... 44

4.3. Перспективы развития модернизации Макета ........................................................... 44

4.3.1. Требования к численности и квалификации персонала системы и режиму его

работы 44

4.3.2. Требования к надежности Макета ....................................................................... 45

4.3.3. Требования к безопасности .................................................................................. 45

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

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

хранению модулей Макета ................................................................................................. 46

4.3.6. Требования по защите информации от несанкционированного доступа ........ 46

3

4.3.7. Требования к сохранности информации при авариях и защите от влияния

внешних воздействий .......................................................................................................... 47

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

5. Требования к составу работ ................................................................................................ 48

6. Требования к демонстрации Макета ................................................................................. 49

Сценарий демонстрации макета «Единый ЦАФАП» Платформы «Автодата» ................ 49

7. Состав и содержание работ по созданию Макета ............................................................ 55

8. Порядок приемки выполненных работ .............................................................................. 57

9. Требования к Программе и методике испытаний ............................................................ 58

10. Требования к составу и содержанию работ по подготовке объекта автоматизации к

вводу в действие .......................................................................................................................... 59

11. Требования к документированию ................................................................................... 61

4

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

1.1. Наименование работы

Наименование работы: Выполнение составной части научно-

исследовательской работы «Проектирование Платформы «Автодата»,

разработка технического проекта в части создания макета «Единый ЦАФАП».

Полное наименование системы: Макет «Единый ЦАФАП».

Сокращенное наименование системы: Макет.

1.2. Заказчик и Исполнитель работ

Заказчик: Некоммерческое партнерство «Содействие развитию и

использованию навигационных технологий».

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

1.3. Основание для проведения работы

Поручение Президента Российской Федерации В.В. Путина (пункт 1

Перечня поручения Президента Российской Федерации по итогам заседания

наблюдательного совета автономной некоммерческой организации

«Агентство стратегических инициатив по продвижению новых проектов»

8 декабря 2016 г. № Пр-77 от 14 января 2017 г.);

пункт 38 Протокола заседания Межведомственной рабочей группы по

разработке и реализации Национальной технологической инициативы при

Правительственной комиссии по модернизации экономики и инновационному

развитию России от 7 августа 2019 г. № 2.

1.4. Сроки выполнения работы

Дата начала работ - с даты заключения Договора.

Дата окончания работ - 20.12.2019.

1.5. Порядок оформления и предъявления Заказчику результатов

работ

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

на базе комплексов аппаратно-программных средств, предоставляемых

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

основании Акта выполненных работ. Все материалы передаются с

сопроводительными документами Исполнителя.

5

1.6. Перечень принятых терминов и сокращений

1.6.1. Перечень сокращений

В настоящем техническом задании используются следующие

сокращения:

Сокращение или

обозначение Значение

Dbf Database File – специализированный формат хранения

таблиц базы данных

Pdf Portable Document Format — межплатформенный

формат электронных документов

Txt стандартное расширение для текстовых файлов

АИС Автоматическая информационная система

АМТС Авто-мото транспортные средства

АРМ Автоматизированное рабочее место

БИК Банковский идентификационный код

БД База данных

ГУОБДД МВД

РОССИИ

Главное управление обеспечения безопасности

дорожного движения Министерства внутренних дел

Российской Федерации

ГЛОНАСС Глобальная навигационная спутниковая система

ГРЗ Государственный регистрационный знак

«Единый

ЦАФАП»

Центр автоматической фиксации административных

правонарушений в области дорожного движения,

состоящий из одного ЦСУ и неограниченного

количества РС, соответствующий требованиям,

установленным настоящим ТЗ

ИНН Идентификационный номер налогоплательщика

КЛАДР Классификатор адресов России

КоАП Кодекс Российской Федерации об административных

правонарушениях

Макет

Платформы

«Автодата»

Аппаратно-программный комплекс, предназначенный

для уточнения и экспериментальной проверки

требований к получению, обработке данных,

сопряжению и информационному обмену

проектируемой Платформы «Автодата» с внешними

информационными системами

КПП Код причины постановки на учет

НСД Несанкционированный доступ

НДВ Недекларированные возможности

ОКАТО Общероссийский классификатор административно-

территориальных объектов

ПАК Программно-аппаратный комплекс

6

ПДД Правила дорожного движения

ПК Программный комплекс

ПО Программное обеспечение

ПСКЗИ Персональное средство криптографической защиты

информации

ПЭВМ Персональная электронно-вычислительная машина

Средство фото-

видеофиксации

Работающее в автоматическом режиме специальное

техническое средство, имеющее функции фото- и

киносъемки, видеозаписи

Региональный

сегмент (РС)

Аппаратно-программный комплекс

автоматизированной обработки результатов фото-

видеофиксации нарушений Правил дорожного

движения, технические средства которого размещены в

субъекте Российской Федерации, выполняющий

функции, определенные в настоящем ТЗ. При

интеграции с ЦСУ становится функциональной частью

«Единого ЦАФАП».

РБД Распределенная база данных

ТС Транспортное средство

УИН Уникальный идентификатор начисления

ФВФ Фото-видеофиксация

ФГУП Федеральное государственное унитарное предприятие

ФЗ Федеральный закон

ФИС Федеральная информационная система

ФСБ Федеральная служба безопасности Российской

Федерации

ФССП Федеральная служба судебных приставов

ФСТЭК Федеральная служба по техническому и экспортному

контролю

ШПИ Штриховой почтовый идентификатор Почты России

ЭРЖ Электронный регистрационный журнал

ЭП Электронная подпись

Центральный

сервер

управления

(ЦСУ)

Единый аппаратно-программный комплекс

автоматизированной, обеспечивающий сбор

результатов фото-видеофиксации нарушений Правил

дорожного движения, поступающих от средств фото-

видеофиксации, их обработку и передачу результатов

этой обработки в РС, выполняющий функции,

определенные в настоящем ТЗ. При интеграции с РС

становится функциональной частью «Единого

ЦАФАП»

ФНС Федеральная налоговая служба

ИНН Индивидуальный номер налогоплательщика

7

2. Назначение и цели создания Макета

2.1. Назначение Макета

Макет предназначен для:

а) уточнения требований к формированию и составу данных,

передаваемых от Макета в Макет Платформы «Автодата»;

б) уточнения требований к сбору, консолидации и обработке данных

о результатах фиксации нарушений ПДД, зафиксированных комплексами

ФВФ;

в) отработки требований по:

обеспечению независимого контроля целостности и неизменности

данных по нарушениям ПДД, зафиксированных комплексами ФВФ;

исключения возможности несанкционированного изменения и удаления

материалов нарушений ПДД;

обеспечению мер по защите информации с различными статусами

доступа, в том числе о прохождении по территории Российской Федерации

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

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

информации о работе региональных систем ФВФ во всех субъектах

Российской Федерации;

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

«АВТОДАТА».

2.2. Цели создания Макета

Основной целью создания Макета является уточнение и отработка

требований к информационному обмену между Макетом и Макетом

Платформы «Автодата», а также отработка требований к:

а) процессам сбора, обработки, накопления, анализа и

предоставления информации о проезде транспортных средств через зоны

контроля комплексов распознавания регистрационных знаков и фото-

видеофиксации, угнанному (похищенному) транспорту;

б) возможности оперативной проверки транспортного средства и

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

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

водителя просроченных штрафов.

8

3. Характеристика объекта автоматизации

3.1. Краткие сведения об объекте автоматизации

3.1.1. Фиксация административных правонарушений в области

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

технических средств, работающих в автоматическом режиме

Объектом автоматизации являются процессы, связанные с обработкой

материалов, зафиксированными специальными техническими средствами

фото-видеофиксации, работающими в автоматическом режиме (далее по

тексту комплексами ФВФ), а также выполнения комплекса организационно

технических мероприятий по взысканию наложенных штрафов в соответствии

с КоАП РФ. Осуществление задач информационного взаимодействия между

системами ИВД и региональными сервисами, определенными в приказе МВД

России от 3 декабря 2007 г. № 1144 «О системе информационного обеспечения

подразделений Госавтоинспекции».

Учитывая постоянно увеличивающуюся группировку комплексов ФВФ,

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

количество типов нарушений, фиксируемых в автоматическом режиме, вопрос

автоматизации обработки данных материалов принимает все более

актуальный характер. Отсутствие возможности контроля всего жизненного

цикла зафиксированного материала нарушения может привести к

возникновению фактов коррупционной составляющей со стороны

должностных лиц МВД, выразившейся во внесении несанкционированных

изменений в материалы фото-видеофиксации и ведения нелегальных «белых»

списков ГРЗ ТС, не привлекаемых к административной ответственности.

3.1.2. Фиксация всего проходящего потока ТС с целью выполнения

задач оперативного розыска

Объектом автоматизации являются процессы, связанные с проведением

оперативно-розыскных мероприятий с использованием специальных

технических средств, работающих в автоматическом режиме и иных средств

фото-видеофиксации ТС. Учитывая постоянно увеличивающееся количество

приборов, реализующих задачи фото-фиксации ТС, вопрос хранения и

обработки данной информации приобретает все большую актуальность.

Учитывая доступность информации о прохождении ТС в связи привлечением

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

полномочий встает проблема сокрытия перемещения автомобилей

«прикрытия», военных колонн, спец. транспорта, а так же передвижение лиц,

подпадающих под действие Федерального закона от 20.04.1995 № 45-ФЗ

«О государственной защите судей, должностных лиц правоохранительных и

контролирующих органов» и постановления Правительства Российской

Федерации от 14.07.2015 № 705 «О порядке защиты сведений об

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

9

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

сведений о защищаемом лице.

3.2. Сведения об условиях эксплуатации объекта автоматизации и

характеристиках окружающей среды

Макет должен эксплуатироваться в реальных условиях с

использованием комплексов ФВФ.

10

4. Требования к Макету

4.1. Требования к Макету в целом

4.1.1. Требования к структуре Макета

Макет «Единый ЦАФАП» должен быть создан в следующей

конфигурации (Приложение 1)

единый центральный сервер управления (далее – ЦСУ),

интегрированный с Платформой «Автодата»;

региональные сегменты (далее – РС), обеспечивающие обработку

информации, получаемой от ЦСУ, формируемой с использованием

специальных программно-технических средств различных производителей,

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

стандартами, устанавливающими требования к составу данных, форматам и

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

управления.

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

сопряжения с информационной системой (под информационной системой

понимается Региональный сегмент Макета или любая иная региональная

система ЦАФАП, в которой осуществляется ведение делопроизводства по

зафиксированным материалам нарушения ПДД), находящейся в постоянной

эксплуатации и реализующей функционал ЦАФАП.

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

объемом прав:

Центральный сервер управления (федеральная подсистема):

«Инженер» - пользователю с данной ролью должна быть доступна

возможность управления РС.

«ДСП» - пользователю с данной ролью должна быть доступна

возможность по изменению реестра «закрытых» ГРЗ;

«Аналитик» - пользователю с данной ролью должна быть доступна

функция «анализа фиксации проходящего потока», а также аналитическая и

статистическая информация;

«Администратор» - пользователю с данной ролью должны быть

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

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

Центральный сервер управления (локальная подсистема):

«Администратор» - пользователю с данной ролью должны быть

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

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

«Инженер» - пользователю с данными правами должны быть доступны

функции настройки взаимодействие с федеральной подсистемой ЦСУ и

подключения комплексов ФВФ, эксплуатируемых в регионе

11

4.1.2. Назначение и функциональные возможности «Центрального

сервера управления»

ЦСУ предназначен для:

сбора, обработки и передачи в РС информации о нарушениях Правил

дорожного движения, формируемых средствами фото- видеофиксации

различных производителей;

анализа и хранения метаданных, поступающих от РС и внешних

информационных систем, а также в результате информационного обмена с

Платформой «Автодата».

4.1.3. Архитектура ЦСУ

ЦСУ имеет распределенную архитектуру и состоит из одной

федеральной подсистемы, обеспечивающей анализ и хранение метаданных,

поступающих от РС и внешних информационных систем, в частности от

Макета Платформы «Автодата» и неограниченного количества локальных

подсистем ЦСУ, обеспечивающих сбор, обработку и передачу в РС

информации о нарушениях Правил дорожного движения, формируемых

средствами фото- видеофиксации различных производителей, технические

средства которых расположены в различных субъектах Российской

Федерации.

Взаимодействие федеральной подсистемы ЦСУ и локальных подсистем

ЦСУ осуществляется за счет использования технологии XML WEB-сервисов.

Разработка и описание WEB-сервисов осуществляется в рамках

проектирования Макета.

4.1.4. Функции ЦСУ

4.1.4.1. Функции федеральной подсистемы ЦСУ

Федеральная подсистема ЦСУ должна обеспечивать выполнение

следующих функций:

ведение статистической отчетности по каждому нарушению,

зафиксированному региональными комплексами ФВФ с учетом всех статусов

(загружено в региональный сегмент, вынесено постановление, забраковано и

прочие статусы в соответствии с перечнем этапов делопроизводства,

установленном в приказе МВД России от 3 декабря 2007 г. № 1144 «О системе

информационного обеспечения подразделений Госавтоинспекции»). Каждому

материалу нарушения присваивается уникальный номер в региональном

сегменте (РС) и в ЦСУ передаются статусы материала согласно данной

нумерации;

ведение реестра «закрытых» ГРЗ и передачи данного реестра в

региональные сегменты. Под закрытыми ГРЗ понимается список ГРЗ, доступ

к информации о передвижении которых (и к самому факту нахождения ГРЗ в

12

данном реестре) имеет ограниченный круг лиц (военные колонны,

транспортные средства оперативных служб, транспортные средства,

осуществляющие перевозку категорий лиц, указанных в статьях 16 и

19 Федерального закона от 20.04.1995 № 45-ФЗ «О государственной защите

судей, должностных лиц правоохранительных и контролирующих органов» и

постановлении Правительства Российской Федерации от 14.07.2015 № 705

«О порядке защиты сведений об осуществлении государственной защиты,

предоставления таких сведений и осуществления мер безопасности в виде

обеспечения конфиденциальности сведений о защищаемом лице»), согласно

правам доступа;

ведение реестра комплексов ФВФ, эксплуатируемых на территории

субъекта Российской Федерации, и отображении их дислокации на

электронной карте;

осуществление информационного обмена с Макетом «Платформы

«Автодата».

4.1.4.2. Локальные подсистемы ЦСУ реализуют следующие

функции:

a) получение, обработка и передача в РС информации о нарушениях

Правил дорожного движения, в том числе:

скоростного режима;

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

правил стоянки и остановки транспортных средств;

требований дорожных знаков и разметки;

требований сигналов светофора;

весогабаритного контроля;

проездов перекрестков;

нарушений правил проезда железнодорожных переездов;

нарушение правил пешеходного перехода;

нарушение правил перевозки крупногабаритных грузов,

получаемой от средств фото-видеофиксации, включая, но не

ограничиваясь:

«КРИС С» производства ООО «СИМИКОН» г. Санкт-Петербург;

«КРИС П» производства ООО «СИМИКОН» г. Санкт-Петербург;

«КОРДОН» производства ООО «СИМИКОН» г. Санкт-Петербург;

«КОРДОН М2» производства ООО «СИМИКОН» г. Санкт-Петербург;

«КОРДОН ТЕМП» производства ООО «СИМИКОН» г. Санкт-

Петербург;

«КОРДОН КР» производства ООО «СИМИКОН» г. Санкт-Петербург;

«MultaRadar SD580» производства «Robot Visual Systems GmbH»,

Германия;

«TRAFFISTAR SR590» производства «Robot Visual Systems GmbH»,

Германия;

«Сфинкс-С» производства «Robot Visual Systems GmbH», Германия;

13

«Стрелка-СТ» производства ЗАО «Системы передовых технологий»;

«Амата РД» производства ЗАО «НПП Техноимпорт», г. Москва;

«Амата ВР» производства ЗАО «НПП Техноимпорт», г. Москва;

«Арена» производства ЗАО «Ольвия» г. Санкт-Петербург;

«Кречет» производства ЗАО «Ольвия», г. Санкт-Петербург;

«Скат С» производства ЗАО «Ольвия», г. Санкт-Петербург;

«Скат С(А)» производства ЗАО «Ольвия», г. Санкт-Петербург;

«Скат РИФ» производства ЗАО «Ольвия», г. Санкт-Петербург;

«Скат П» производства ЗАО «Ольвия», г. Санкт-Петербург;

«Скат В» производства ЗАО «Ольвия», г. Санкт-Петербург;

«Птолемей С» производства ООО «Лаборатория цифрового зрения», г.

Санкт-Петербург;

«Птолемей СМ» производства ООО «Лаборатория цифрового

зрения», г. Санкт-Петербург;

«Автоураган» - «Автодория» производства ООО «Автодория» г. Казань;

АПК «Поток С» производства ООО «Росси» г. Москва;

АПК «Поток Д» производства ООО «Росси» г. Москва;

АПК «Поток М» производства ООО «Росси» г. Москва;

АПК «Поток ПДД» производства ООО «Росси» г. Москва;

«Автопатруль Полоса» производства Компании Стилсофт,

г. Ставрополь;

«Автопатруль Стоянка» производства Компании Стилсофт,

г. Ставрополь;

«Автопатруль Скорость» производства Компании Стилсофт,

г. Ставрополь;

«Автопатруль Скорость-П» производства Компании Стилсофт,

г. Ставрополь;

«Автопатруль Пешеход» производства Компании Стилсофт,

г. Ставрополь;

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

«Тайфун» г. Краснодар;

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

«Паркон» производства ООО «СИМИКОН» г. Санкт-Петербург;

Мобильных и стационарных комплексов отслеживания нарушений

режима парковки «Дозор-М и «Дозор-ПС» производства ООО «БИС» г.

Воронеж;

«VOCORD Cyclops» производства ЗАО «Вокорд Телеком» г. Москва;

«ЭЛВИС ПЕРЕКРЁСТОК (Orwell 2k-TraVio)» производства ЭЛВИС

Неотек г. Москва;

«Интегра-КДД» производства ЗАО «Интегра-С» г. Самара;

«Одиссей» - производства ООО «ТЦОБДД» г. Пермь;

«Азимут» - производства ООО «ТЦОБДД» г. Пермь;

«А-Глобал» г. Москва;

«Форсаж» производства ООО «ИКВА» (СТАБКОМ), г. Москва;

14

«Оскон» производства ООО «ИКВА» (СТАБКОМ), г. Москва;

«Тайфун С» производства ООО «МВС», г. Краснодар;

«Тайфун М» производства ООО «МВС», г. Краснодар;

«Паркрайт» производства ЗАО «Технология Распознавания», г. Москва;

«Паркнет» производства ЗАО «Технология Распознавания», г. Москва;

«UnicamWIM» производства ООО «ГИС-эксперт» г. Новосибирск;

ТРАФИК-СКАНЕР-К – производства Группа компаний «ISS» г. Москва;

ТРАФИК-СКАНЕР-СМ –производства Группа компаний «ISS»

г. Москва;

b) При загрузке нарушений с комплексов ФВФ осуществление

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

валидности ЭЦП, которыми данные материалы подписаны.

c) Сравнение ГРЗ транспортных средств, поступающих с комплексов

ФВФ, с реестром «закрытых» ГРЗ, загруженных из федеральной подсистемы

ЦСУ. В случае совпадения данных списков, данные ГРЗ в региональный

сегмент не выгружаются.

d) Присвоение каждому материалу нарушения, выгружаемому в

региональный сегмент, уникального номера. Все метаданные по каждому

нарушению (время фиксации, тип нарушения, тип комплекса ФВФ и его

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

выгружаться в федеральную подсистему ЦСУ.

4.1.5. Модули ЦСУ

В состав ЦСУ должны входить следующие модули:

модуль администрирования;

модуль информационного взаимодействия с «РС»;

модуль сопряжения с комплексами ФВФ;

модуль информационного взаимодействия с внешними информационными

системами;

модуль работы с «закрытыми» ГРЗ;

модуль удаленного мониторинга работы комплексов ФВФ;

модуль фиксации проходящего потока АМТС;

модуль информационного взаимодействия с Макетом Платформы

«Автодата».

4.1.5.1. Модуль администрирования

Для повышения эффективности работы системы ФВФ, должна

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

рабочих мест и серверов.

При конфигурировании ЦСУ пользователю с правами «Администратор»

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

пользователям этих ролей. Администратором можно назначить любого

пользователя путем включения его в соответствующую роль.

15

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

пользователям с правами «Администратора».

Возможность блокировки пользователя администратором, при этом

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

имени пользователя и пароля.

Для целей формирования индивидуального интерфейса,

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

возможность настройки, в пользовательском интерфейсе, размеров и

положения на форме полей, кнопок, а также индивидуальное хранение этих

настроек.

Модуль должен содержать ЭРЖ действий пользователей, в котором

должны отображаться события:

редактирования записей базы данных РС (добавление, удаление,

изменение);

сеанса работы пользователя (начало, окончание);

попытки входа (идентификация, аутентификация);

выполнения операций над объектами (создание, удаление,

редактирование и пр.);

операции управления доступом, изменения прав доступа.

с фиксацией для каждого события:

даты и времени;

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

ip-адреса компьютера;

типа события;

результата операции, описываемой событием.

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

позволяющие осуществлять частичный просмотр ЭРЖ. В частности, должна

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

отбор по периоду;

отбор по событию;

отбор по пользователю.

4.1.5.2. Модуль информационного взаимодействия с «РС»

Модуль взаимодействия с «РС» должен:

а) позволять конфигурировать элементы информационной системы

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

настройка ip адресации региональных сегментов;

выполнение функции аутентификации и верификации при подключении

к региональным сегментам ПО.

б) осуществлять выгрузку закрытых ГРЗ в региональный сегмент для

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

Выгрузка ГРЗ, подлежащих сокрытию должна осуществляется в виде Хеш-

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

информацию о нахождении данного ГРЗ в реестре «Закрытых» номеров;

16

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

комплексах ФВФ:

наименование;

серийный номер;

дата окончания поверки;

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

координаты дислокации комплекса ФВФ;

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

забраковано и т. д. и т.п.;

г) загружать информацию о статусе и этапах делопроизводства по

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

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

контроля и их передаче в подсистему фиксации проходящего АМТС;

е) загружать информацию о зонах повышенной аварийности и

концентрации ДТП;

ж) загружать информацию о фиксации комплексом ФВФ факта

проезда с нарушением правил ПДД.

4.1.5.3. Модуль сопряжения с комплексами ФВФ

Модуль интеграции с комплексами должен выполнять следующие

функции:

а) Осуществление контроля целостности и неизменности

материалов, поступающих с комплексов ФВФ за счет верификации подписи

ЭЦП и сертификата открытого ключа, загруженного в программу;

б) Осуществление преобразования каждого распознанного ГРЗ в

хэш-функцию и сравнивать с хеш-функциями ГРЗ загруженных из ЦСУ. В

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

в) При загрузке нарушений, программа должна автоматически

проверять наличие действующего сертификата поверки на комплекс ФВФ,

которым зафиксировано данное нарушение. В случае, если срок действия

поверочного сертификата просрочен, все материалы с данного комплекса

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

действия поверочного сертификата».

4.1.5.4. Модуль информационного взаимодействия с внешними

информационными системами

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

сервисами, расположенными в Системе межведомственного электронного

взаимодействия (СМЭВ).

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

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

постановлению Правительства Российской Федерации от 16.11.2018 № 1379

«Об утверждении Правил определения основных параметров дорожного

движения и ведения их учета».

17

4.1.5.5. Модуль работы с закрытыми ГРЗ

В модуле должен быть реализован реестр «закрытых» ГРЗ.

Все ГРЗ, занесенные в данный реестр, должны храниться в закрытом

виде, в форме вычисленной хеш-функции.

4.1.5.6. Модуль удаленного мониторинга работы комплексов ФВФ

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

и программного обеспечения разрабатываемого Макета в режиме реального

времени.

а) Требования к функциональным характеристикам модуля

мониторинга:

проверка активности служб, влияющих на работу поставляемого ПО;

конфигурирование списка контролируемых служб, влияющих на работу

поставляемого ПО;

проверка активности HTTP/WEB сервисов, необходимых для

нормального функционирования поставляемого ПО (конфигурирование

списка контролируемых сервисов);

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

возможность выводить информацию с цветовой индикацией на АРМ

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

б) Программный модуль должен иметь возможность

контролировать:

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

(сверка с адресом материалов, приходящих с комплекса ФВФ)

доступность стационарных комплексов ФВФ (опрос комплексов по IP

адресу и фиксации периодов их недоступности (доступно, недоступно, было

недоступно в период с - по));

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

превышение процента брака по комплексу ФВФ;

срок поверки комплекса ФВФ;

процент отклонения количества зафиксированных нарушений

в) Модуль должен иметь следующие статистические возможности:

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

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

процентное соотношение количества вынесенных постановлений к

количеству зафиксированных нарушений;

г) Возможность просмотра состояния параметров работы на карте:

Должна быть реализована возможность просмотра расположения

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

ФВФ с возможностью просмотра состояние параметров работы конкретного

комплекса непосредственно на карте:

красный – критическое состояние комплекса;

желтый – есть незначительные отклонения в работе;

18

зеленый – комплекс функционирует нормально.

4.1.5.7. Модуль фиксации проходящего потока АМТС

Модуль должен иметь раздел, в котором должны быть отражены все

участники (пользователи).

В данном разделе РС должна быть реализована возможность создания

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

распределения их прав доступа и назначения ролей.

Доступ в данный раздел должен предоставляться посредством

назначения соответствующей роли Администратором. У Администратора

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

редактирования данного раздела любому пользователю.

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

пользователях, зарегистрированных в программе (при условии полного

занесения в ПО соответствующей информации):

ФИО, должность, структурное подразделение пользователя;

Ip адрес устройства (АРМ), с которого у пользователя разрешен вход;

список ролей (разделов РС и возможностей), разрешенных и доступных

пользователю для работы.

Должна быть возможность экспортировать список пользователей в

форматах *.csv и *.xlsx.

Модуль должна позволять Администратору системы принудительно

отключать от макета выбранного пользователя.

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

учета и мониторинга работы пользователей.

Данный раздел должен предоставлять инструмент для просмотра и

анализа действий (активности) всех пользователей системы с возможными

отборами по различным фильтрам.

Должна быть возможность осуществлять регистрацию и учет системных

событий в ЭРЖ, таких как:

попытки идентификации и аутентификации пользователей ПО;

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

(регистрация ошибок, запрос какой-либо информации, предупреждения,

примечания и прочее).

выполнение операций над объектами (создание, удаление,

редактирование и прочее);

операции управления доступом, изменения прав доступа, с фиксацией

для каждого события:

даты и времени;

пользователя, осуществляющего регистрируемое действие;

типа события - действия пользователей в модуле (вход в систему, запрос

информации и прочее);

результата операции - описание действий пользователя (результат

действий пользователей или подробное описание действий пользователей).

19

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

позволяющие осуществлять частичный просмотр ЭРЖ по параметрам:

дата (интервал дат);

имя пользователя;

тип события - действия пользователей в модулях (вход в систему, запрос

информации и прочее);

результат операции - описание действий пользователя (результат

действий пользователей или подробное описание действий пользователей);

ip-адрес, с которого осуществлялись действия пользователей.

Должна быть возможность экспорта ЭРЖ в формате .csv и .xlsx со

следующими полями:

дата (интервал дат);

имя пользователя;

тип события - действия пользователей в модуле (вход в систему, запрос

информации и прочее);

результат операции - описание действий пользователя (результат

действий пользователей или подробное описание действий пользователей);

ip-адрес.

Модуль должен иметь раздел, позволяющий осуществлять поиск

материалов по результатам фиксаций ТС комплексами ФВФ (далее по тексту

КФВФ), а также камерами с оборудованным модулем распознавания в

соответствии с заданными фильтрами.

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

информации о проездах ТС, ГРЗ которых заданы оператором без постановки

ТС в розыск;

Должна быть реализована возможность поиска ГРЗ с осуществлением

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

интервал времени (дата и время);

ГРЗ;

список КФВФ;

направлению движения (при условии отбора по конкретному КФВФ);

скорость ТС (при условии передачи данного параметра КФВФ);

марки/модели, цвету, типу ТС (при условии наличия загруженных в ПО

сведений из федерального реестра зарегистрированных ТС, которые

предоставляются заказчиком или предоставленных комплексом ФВФ).

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

розыска.

Модуль должен, оперируя сведениями о розыске транспортных средств,

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

местности, для осуществления координированного управления по их

перехвату и задержанию.

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

различные списки розыска ТС. Данные списки должны создаваться,

20

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

ему на это прав.

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

выборочно включать/выключать конкретные списки розыска для

срабатывания из имеющихся в доступе списков розыска.

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

или в виде всплывающей экранной формы. Звуковое уведомление должно

срабатывать независимо от того, в каком разделе РС на текущий момент

работает пользователь.

Должен быть функционал оперативного розыска - при загрузке

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

фиксируемого ГРЗ в списках розыска в установленный Администратором

интервал времени в минутах. Если данный ГРЗ находится в розыске –

происходит проверка даты фиксации. Если фиксация ТС произошла в

пределах установленного Администратором интервала времени –

уведомления о срабатывании отправляются всем пользователям,

подписанным на список розыска, по которому произошло срабатывание. Если

фиксация ТС произошла вне предела установленного Администратором

интервала времени, то уведомления не отправляются пользователю, но

сохраняется в архиве срабатывания для последующего просмотра.

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

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

использования значения порога (интервала) времени оперативного розыска по

умолчанию.

Подписка и отписка на определенные списки розыска для каждого

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

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

других пользователей или систему в целом.

Создание списка розыска должно требовать ввода только ГРЗ полного

соответствия без ввода масок.

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

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

вошедшему в систему. Все правила в данном списке видны только

конкретному пользователю.

4.1.5.8. Модуль информационного взаимодействия с Макетом

Платформы «Автодата»

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

Платформы «Автодата».

Взаимодействие с Платформой «Автодата» должно осуществляться за

счет применения использования технологий WEB-сервисов.

21

ЦСУ получает данные от Платформы «Автодата» в виде реестра ГРЗ с

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

данным ГРЗ.

Передача данных от ЦСУ в Платформу «Автодата» должна

осуществляться согласно списка ГРЗ. Данные должны быть переданы в

следующем составе:

государственный регистрационный знак ТС;

дата и время фиксации возможного нарушения;

место фиксации возможного нарушения (город, улица, дорога)

направление движения ТС в момент фиксации возможного нарушения;

тип возможного нарушения;

тип устройства фиксации нарушений.

Кроме того, должна обеспечиваться передача дополнительных данных в

Макет Платформы «Автодата» с целью отработки механизма предоставления

Макетом Платформы «Автодата» информации оператору, оказывающему

собственнику транспортного средства одну или несколько услуг из

следующего перечня:

информирование водителя ТС о приближении к участку дороги с

повышенной степенью аварийности. Информация предоставляется с учетом

типа аварийности;

информирование водителя ТС о приближении к участку дороги

контролируемому стационарными или мобильными комплексами

автоматической фиксации нарушений ПДД Информация может

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

скоростного режима, разметки, проезда на красный свет, нарушение правил

остановки/стоянки и т.д.);

информирование водителя ТС о фиксации нарушений ПДД

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

момента обработки нарушения и вынесения постановления об

административном правонарушении;

предоставление информации о наличии свободных парковочных мест в

заданном районе;

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

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

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

автоплатеж (только в случае применения на территории субъекта Российской

Федерации информационной системы, поддерживающей данные функции);

информирование водителей грузовых ТС об участках дорог с

ограничением/запретом на передвижение по ним грузовых ТС (только в

случае применения на территории субъекта Российской Федерации

информационной системы, поддерживающей данные функции)

информирование водителей грузовых ТС о фиксации нарушений ПДД в

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

22

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

субъекта РФ информационной системы, поддерживающей данные функции);

информирование об эвакуации ТС (только в случае применения на

территории субъекта Российской Федерации информационной системы,

поддерживающей данные функции);

информирование об адресе специализированной стоянки, на которую

эвакуировано ТС (только в случае применения на территории субъекта

Российской Федерации информационной системы, поддерживающей данные

функции);

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

избежать составления постановления об АПН в случае добровольной оплаты

парковки до конца суток (только в случае применения на территории субъекта

Российской Федерации информационной системы, поддерживающей данные

функции);

информирование водителя о вынесении в отношении него

постановления об АПН за неоплату платной парковки (только в случае

применения на территории субъекта Российской Федерации информационной

системы, поддерживающей данные функции);

информирование водителя о вынесении в отношении него

постановления об АПН за нарушения в области правил благоустройства

территории с применением ТС (только в случае применения на территории

субъекта Российской Федерации информационной системы, поддерживающей

данные функции).

4.1.6. Назначение и функциональные возможности «Регионального

сегмента»

Региональных сегмент представляет собой аппаратно-программный

комплекс автоматизированной обработки результатов фото-видеофиксации

нарушений Правил дорожного движения, технические средства которого

размещены в субъекте Российской Федерации, выполняющий функции,

определенные в настоящем ТЗ. При сопряжении с ЦСУ становится

функциональной частью «Единого ЦАФАП».

4.1.6.1. Функции «Регионального сегмента»

Региональный сегмент должен реализовывать следующие функции:

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

комплексов, используемых на территории субъектов Российской Федерации;

контроль качества распознавания ГРЗ ТС по информации, полученной с

помощью специальных технических средств, имеющих функции фото- и

киносъемки, видеозаписи, работающими в автоматическом режиме, в том

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

видеофиксации, входящих в систему фото-видеофиксации;

проверка ГРЗ ТС по региональным и федеральным базам розыска;

23

идентификация владельцев ТС, совершивших административные

правонарушения в области дорожного движения;

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

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

зафиксированных работающими в автоматическом режиме специальными

техническими средствами, имеющими функции фото- и киносъемки,

видеозаписи, или средствами фото- и киносъемки, видеозаписи;

формирование постановления об административном правонарушении;

формирование уведомлений и реестров для отправки постановлений и

корреспонденции;

проверка информации об оплате штрафов по вынесенным

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

нарушение ПДД с целью выявления неисполненных постановлений;

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

законную силу;

формирование реестров неисполненных постановлений;

формирование протоколов об административных правонарушениях,

выразившихся в неуплате административного штрафа за нарушение Правил

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

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

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

правонарушениях в области дорожного движения для направления в суд

(копии необходимых материалов: постановления, справки о собственнике,

сертификата о поверке Комплекса, фотоматериала, уведомления о вручении

(сведений о невручении);

контроль этапов делопроизводства по материалам, направленным в

Федеральную службу судебных приставов;

создание единой системы отчетности по показателям деятельности

системы фотовидеофиксации и по каждому датчику Средств фото-

видеофиксации отдельно;

ведение электронного журнала действий пользователей РС;

осуществление автоматизированного контроля за сроками ведения

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

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

доставки почтовых отправлений на территории субъекта РФ.

4.1.6.2. Требования к Региональному сегменту

Региональный сегмент должен:

осуществлять взаимодействие пользователей посредством визуального

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

должен быть перегружен графическими элементами и должен обеспечивать

быстрое отображение экранных форм, соответствовать современным

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

функциям и операциям РС. Навигационные элементы должны быть

24

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

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

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

помощью транслитерации в соответствии с требованиями ГОСТ 7.79-2000

«Правила транслитерации кирилловского письма латинским алфавитом»;

идентифицировать и проверять подлинность пользователей при входе в

Программу по идентификатору (логину) и паролю и осуществлять их доступ в

соответствии с ролями. Максимальное количество пользователей, которые

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

не менее 20 с возможностью увеличения количества автоматизированных

рабочих мест и серверов;

вести регистрацию обращений пользователей, их идентификацию и

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

сегмента;

осуществлять регистрацию и учет системных событий в электронном

регистрационном журнале (ЭРЖ):

попытки идентификации и аутентификации;

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

(регистрация ошибок, информации, предупреждение, примечания и т.п.).

выполнение операций над объектами (создание, удаление,

редактирование и пр.);

операции управления доступом, изменения прав доступа.

с фиксацией для каждого события:

даты и времени;

субъекта, осуществляющего регистрируемое действие;

типа события;

результата операции, описываемой событием.

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

позволяющие осуществлять частичный просмотр ЭРЖ.

4.1.6.3. Модули Регионального Сегмента

В состав РС входят следующие модули:

модуль администрирования;

модуль загрузки данных;

модуль обработки данных;

модуль печати;

модуль обмена данными;

модуль делопроизводства;

модуль фиксации проходящего потока АМТС;

модуль отчетов;

модуль удаленного мониторинга работы комплексов ФВФ;

модуль мониторинга проходящего транспорта.

25

4.1.6.4. Модуль администрирования

Для повышения эффективности работы системы фотофиксации должна

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

рабочих мест и серверов.

При конфигурировании РС пользователю с правами «Администратор»

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

пользователям этих ролей. Администратором можно назначить любого

пользователя путем включения его в соответствующую роль.

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

пользователям с правами «Администратора».

Возможность блокировки пользователя администратором РС, при этом,

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

правильном вводе имени пользователя и пароля.

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

транспортного формата. Транспортный формат утвержден приказом МВД

России от 03.12.2007 № 1144 и в дальнейшем может корректироваться при

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

информации, и полей транспортного формата должна быть редактируемой.

Должна быть реализована настройка диапазонов ШПИ, при этом должна

быть реализована возможность формирования различного диапазона ШПИ

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

При использовании базы КЛАДР и необходимости ее обновления

модуль должен осуществлять обновление КЛАДР путем замены имеющейся

базы на последнюю доступную версию.

Модуль должен содержать ЭРЖ действий пользователей, в котором

должны отображаться события:

редактирование записей базы данных РС (добавление, удаление,

изменение);

сеанса работы пользователя (начало, окончание);

попытки входа (идентификация, аутентификация);

выполнение операций над объектами (создание, удаление,

редактирование и пр.);

операции управления доступом, изменения прав доступа.

с фиксацией для каждого события:

даты и времени;

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

ip-адреса компьютера;

типа события;

результата операции, описываемой событием.

26

4.1.6.5. Модуль загрузки данных

Модуль должен осуществлять автоматическую загрузку данных с

комплексов ФВФ, входящих в систему фото- видеофиксации,

обеспечивающего выполнение следующих функций:

Работа с поступившими данными о зафиксированных нарушениях

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

поступления, для подтверждения ГРЗ с использованием не менее двух

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

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

ГРЗ распознан верно и не требует подтверждения оператора (в случае,

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

на фото нет ГРЗ или он не читаем (в случае если все модули

распознавания передали значение, что ГРЗ не распознан);

ГРЗ требует подтверждения оператора (в случае если все модули

распознавания выдали различный результат).

Осуществление проверки правильности фактической дислокации

передвижных комплексов ФВФ согласно заданным исходным данным в

соответствии с ранее утвержденной дислокацией (Если дислокация

комплекса, указанная в данных, загружаемых с комплекса ФВФ отсутствует в

«справочнике дислокаций», то оператор должен выбрать – добавить новую

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

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

«брак дислокации»).

При загрузке нарушений с комплексов ФВФ должна осуществляться

автоматическая проверка на наличие «дублей» зафиксированных нарушений

(«дублем» считать материал о нарушении, который был зафиксирован одним

и тем же комплексом ФВФ, на один и тот же ГРЗ в промежуток времени

менее 3с.).

После определения и подтверждения ГРЗ и до запроса информации о

владельце автоматически должна осуществляться проверка по учетам

ГУОБДД МВД России:

базы данных угнанного (похищенного) транспорта (обмен с БД

происходит в транспортном формате, утвержденном приказом МВД России от

03.12.2007 № 1144);

списка оперативного розыска АМТС;

списка розыска физических лиц.

Без прохождения указанной проверки, записи не должны отправляться

на этап идентификации владельца транспортного средства.

4.1.6.6. Модуль обработки данных

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

по автоматизированным учетам ГУОБДД МВД РОССИИ:

угнанного (похищенного) транспорта;

27

регистрации ТС;

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

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

правонарушения.

Без прохождения указанной проверки, записи не должны отправляться

на этап оформления постановления об АП.

После получения сведений с комплексов ФВФ и идентификации ГРЗ ТС

должно осуществляться направление полученной информации в

региональную и (или) федеральную базы данных ГУОБДД МВД России с

целью установления владельца ТС.

После получения информации о марке-модели автомобиля, фамилии,

имени и отчества владельца, дате его рождения, адресе и дате регистрации

АМТС, почтовом индексе, должна осуществляется проверка установленного

лица на предмет совершения им однородного административного

правонарушения, со дня вступления в законную силу постановления о

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

окончания исполнения данного постановления.

На основании полученных данных должно осуществляться

формирование постановления по делу об административном правонарушении,

и его заверение электронной подписью.

На основании полученных данных должно осуществляться определение

типа ТС (грузовой/грузовой с разрешенной максимальной массой до

3,5т./легковой) для правильной квалификации административного

правонарушения.

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

делопроизводства по статье 20.25 Кодекса Российской Федерации об

административных правонарушениях:

автоматическое определение лиц, не уплативших штраф за нарушения

Правил дорожного движения, зафиксированных средствами фото-

видеофиксации, в установленный законом срок, создание на основании

полученных данных, протокола по статье 20.25 Кодекса Российской

Федерации об административных правонарушениях. При этом программа

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

присутствии нарушителя или без его участия;

требуется наличие возможности формирования писем - извещений о

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

формирования как обычных писем, так и заказных писем с ШПИ и

уведомлениями, а также формирования электронных реестров на отправку

почтовой корреспонденции.

4.1.6.7. Модуль печати

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

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

формата pdf.

28

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

электронную подпись pdf-файла постановления.

Печатные формы постановления по нарушениям скоростного режима

ТС.

Печатные формы постановления по нарушениям правил

остановки/стоянки ТС.

Печатные формы постановления по нарушениям по несоблюдению

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

части дороги.

Печатные формы постановления по нарушениям правил проезда

перекрестков.

В модуле необходимо реализовать функционал для формирования УИН

и осуществлять его печать на постановлении;

В модуле необходимо наличие механизма формирования ШПИ

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

последующей его печатью на постановлении в виде штрих-кода.

Система должна содержать функционал по ведению и печати

дислокаций передвижных и стационарных устройств ФВФ, а также отчет по

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

установки, содержащий количество зафиксированных нарушений и

вынесенным по ним постановлениям.

4.1.6.8. Модуль обмена данными

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

делопроизводства в региональную базу данных ГУОБДД МВД России или

федеральную базу ГУОБДД МВД России ФИС ГИБДД-М.

Необходимо наличие функционала по выгрузке электронных бланков

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

осуществляющих доставку почтовых отправлений.

Для целей сортировки постановлений необходимо реализовать:

функционал для работы со сканерами штрих-кода по считыванию ШПИ

(штрих-кода);

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

В модуле требуется наличие функционала автоматической проверки

статуса доставки письма с использованием Web-сервиса.

В модуле требуется наличие функционала по загрузке информации об

оплаченных постановлениях.

Необходимо наличие функционала по запросу сведений о владельце

АМТС из федеральных баз оперативно-справочного учета ГУОБДД МВД

России (ФИАС). Также необходимо получать информацию о АМТС,

находящихся в розыске.

При получении информации о владельце запрашиваемого АМТС, в

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

нахождение почтового индекса места проживания владельца АМТС,

29

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

базе, либо осуществлять поиск по базе КЛАДР.

В случае, если на запрос информации о владельце ТС пришли не

корректные данные о месте регистрации, которые были откорректированы

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

и в случае повторной фиксации АМТС с данным ГРЗ, в приоритетном порядке

предоставлять оператору, для подтверждения, данные о адресе владельце,

сохраненные в собственной базе данных РС, а не пришедшие из внешних

информационных систем.

В случае, если на один и тот же ГРЗ имеется несколько карточек ТС

(понятие карточки ТС введено приказом МВД России от 3 декабря 2007 г.

№ 1144 «О системе информационного обеспечения подразделений

Госавтоинспекции») с различными статусами (текущая/архивная), программа

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

карточки оператору. При этом, модуль должен ставить на первое место в

списке карточек ТС ту, которая была актуальна (имела статус «текущая») на

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

Все карточки ТС, полученные из информационных баз, должны

логироваться и храниться в базе данных.

4.1.6.9. Модуль отчетов

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

фото- видеофиксации нарушений Правил дорожного движения.

Назначение отчета: Отражение информации об эффективности работы

системы фото- видеофиксации и каждого комплекса ФВФ, входящего в

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

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

фиксации требуется осуществлять в колонки. На пересечении строк и колонок

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

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

вынесенных постановлений по нарушениям.

Выводимые данные:

дата фиксации;

наименование комплекса ФВФ;

количество зафиксированных нарушений;

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

Модуль должен формировать отчет о состоянии постановлений.

Назначение отчета: отражение информации об исполнении

постановлений в разрезе состояний (отправлено, доставлено, оплачено,

передано в ФССП, отменено) с отбором по интервалу дат вынесения

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

состоянию исполнения. Требуется рассчитывать итоговые показатели: общая

сумма штрафов по состоянию исполнения, сумма оплаты.

Выводимые данные:

30

состояние постановления;

нарушитель;

постановление (номер, дата);

размер штрафа;

сумма оплаты.

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

Назначение отчета: отражение информации об эффективности работы

пользователей за определенный период времени.

Выводимые данные:

пользователь;

количество подтвержденных фотоматериалов;

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

время работы пользователя в системе.

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

при обработке данных. Назначение отчета: отражение информации о

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

времени.

Выводимые данные:

комплекс фиксации;

причина брака;

количество забракованных фотоматериалов.

Модуль должен формировать отчет по направленным постановлениям.

Назначение отчета: отражение информации о количестве направленных

постановлений.

Выводимые данные:

статья КоАП;

датчик;

место установки датчика;

количество направленных постановлений;

Сумма штрафа.

Модуль должен формировать отчет о работе датчиков. Назначение

отчета: отражение информации о поступающих с датчиков нарушениях за

определенный период времени.

Выводимые данные:

датчик;

количество загруженных нарушений;

количество забракованных нарушений;

количество подтвержденных на контроле качества;

количество вынесенных постановлений.

Требуется наличие в модуле возможности формирования отчетов с

функциями дополнительных пользовательских настроек:

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

установка произвольных отборов и сортировок;

31

возможность работы с данными, как с древовидными структурами

(объектами);

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

уровня вложенности;

формирование отчета, как в режиме таблицы, так и в режиме

диаграммы;

настройка порядка вывода данных: в строки, либо в колонки;

настройка группировок и промежуточных итогов.

4.1.6.10. Модуль делопроизводства

Модуль делопроизводства предназначен для автоматизации процессов

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

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

трудозатрат по данному направлению работы, уменьшению количества

ошибок, вызванных «человеческим фактором».

Модуль имеет следующий функционал:

автоматическое отслеживание административных сроков по ведению

делопроизводства по жалобам;

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

данных ГУОБДД МВД России в соответствии с приказом МВД России от 3

декабря 2007 г. № 1144 «О системе информационного обеспечения

подразделений госавтоинспекции»;

автоматическое формирование типовых ответов и решений на

поступившие жалобы в соответствии с загруженными шаблонами;

ведение статистической и аналитической отчетности в части

эффективности работы ЦАФАП в части работы с жалобами;

возможность пользователям самостоятельно формировать

неограниченное количество шаблонов ответов без привлечения

разработчиков.

В ходе внедрения модуля осуществляется разработка механизмов

интеграции с региональной базой данных по выгрузке этапов

делопроизводства.

4.1.6.11. Модуль фиксации проходящего АМТС

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

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

транспортном потоке с КФВФ, которые имеют возможность фиксировать

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

работа в модуле должна осуществляться через веб-интерфейс и не

требовать установки специализированного ПО;

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

данных о проходящем транспортном потоке с КФВФ;

модуль должен иметь модуль графической карты региона эксплуатации;

32

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

из:

передвижных комплексов фото- видеофиксации, включая детальные

фотографии и обзорные (при их наличии);

стационарных комплексов ФВФ, включая детальные фотографии и

обзорные (при их наличии);

промежуточных серверов сбора информации с КФВФ (включая

детальные фотографии и обзорные (при их наличии);

камер, оборудованных модулем распознавания ГРЗ.

модуль должен позволять осуществлять хранение информации обо всех

проездах ТС, включая фото и видеоматериалы (при наличии). Сроки хранения

данной информации должны быть настраиваемыми Администратором

системы;

модуль должен осуществлять взаимодействие пользователей

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

понятным и удобным, не должен быть перегружен графическими элементами

и должен обеспечивать быстрое отображение экранных форм, соответствовать

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

основным функциям и операциям РС;

модуль должен иметь возможность добавления (удаления) комплексов

ФВФ без внесения кардинальных изменений в архитектуру и логику

функционирования;

модуль должен иметь возможность увеличения числа пользователей, и

объемов информационных потоков без внесения кардинальных изменений в

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

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

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

ее функционирования;

модуль должен иметь механизм идентификации и проверки

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

(логину) и паролю и осуществлять их доступ в соответствии с заданными

Администратором ПО ролями (правами доступа к функционалу ПО).

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

ФВФ

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

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

обеспечения на программном уровне в режиме реального времени.

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

мониторинга работы комплексов ФВФ:

проверка активности служб, влияющих на работу поставляемого ПО;

проверка активности HTTP/WEB сервисов, необходимых для

нормального функционирования поставляемого ПО (конфигурирование

списка контролируемых сервисов);

33

сверка данных по выгруженным этапам делопроизводства из

поставляемого ПО макета в административную практику;

сверка количества отправленных запросов с количеством полученных

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

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

возможность выводить информацию с цветовой индикацией на АРМ

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

Программный модуль должен иметь возможность контролировать:

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

макета (сверка с адресом материалов, приходящих с комплекса ФВФ);

доступность стационарных комплексов ФВФ (опрос комплексов по IP

адресу и фиксации периодов их недоступности (доступно, недоступно, было

недоступно в период с - по));

корректность текущего времени на комплексах ФВФ, сверка с временем

на сервере для ОС семейства Windows;

скоростной режим, указанный в справочнике поставляемого ПО (сверка

со скоростным режимом материалов приходящих с комплексов ФВФ);

− превышение процента брака по комплексу ФВФ;

− срок поверки комплекса ФВФ;

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

По каждому контролируемому параметру необходимо реализовать

цветовую индикацию:

красный - критическое состояние;

желтый - отклонение от нормы.

Модуль должен позволять просмотр:

для отдельных комплексов типа Cordon просмотр видео с датчиков

онлайн;

для отдельных комплексов типа Cordon просмотр параметров

температуры процессорного бокса, температуры процессора, скорости

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

Модуль должен иметь следующие статистические возможности:

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

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

процентное соотношение количества вынесенных постановлений к

количеству зафиксированных нарушений;

количество нарушений, успешно прошедших дополнительное авто-

распознавание ГРЗ (если имеется функционал Автообработка);

количество нарушений на контроле качества и забракованных.

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

отклонений в работе служб и комплексов ФВФ. По каждой неполадке должна

создаваться карточка инцидента для реагирования операторов. После решения

проблемы должна вводится информация о решении проблемы (причина,

комментарий, ответственный, дата устранения).

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

34

Должная быть реализована возможность просмотра расположения

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

ФВФ с возможностью просмотра состояние параметров работы конкретного

комплекса непосредственно на карте:

красный – критическое состояние комплекса;

желтый – есть незначительные отклонения в работе;

зеленый – комплекс функционирует нормально.

Настраиваемые параметры инцидентов:

использование инцидентов или нет;

автозакрытие инцидентов;

время существования инцидента в часах после исправления ошибки (в

случае если включено автозакрытие);

разрешение создания инцидентов вручную.

Настраиваемые параметры контроля работы системы:

предупреждение о прекращении действия сертификата за настаиваемое

количество дней;

предупреждение о отсутствии материалов с комплекса в течении

заданного времени;

настройка времени, в течении которого устройство может быть

недоступно без возникновения ошибки;

настройка периода отображения статистики;

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

секундах;

допустимый процент брака (настраивается для каждого типа комплекса

отдельно);

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

комплексов отдельно;

возможность задать координаты, допустимый скоростной режим, адрес

установки с функцией заполнения этих данных по последним данным с

комплекса ФВФ;

настройка IP адреса, логина и пароля для доступа к комплексу;

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

материалов с комплексов в разрезе каждого часа суток, с функцией

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

поступивших материалов по каждому часу и заполняется).

4.1.6.13. Функциональные особенности модуля мониторинга

проходящего транспорта РС

Модуль должен иметь раздел, в котором должны быть отражены все

участники (пользователи) ПО.

В данном разделе РС должна быть реализована возможность создания

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

распределения их прав доступа к ПО и назначения ролей.

35

Доступ в данный раздел должен предоставляться посредством

назначения соответствующей роли Администратором ПО. У Администратора

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

редактирования данного раздела любому пользователю ПО.

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

пользователях, зарегистрированных в программе (при условии полного

занесения в ПО соответствующей информации):

ФИО, должность, структурное подразделение пользователя;

Ip адрес устройства (АРМ), с которого у пользователя разрешен вход в

программу;

список ролей (разделов РС и возможностей), разрешенных и доступных

пользователю для работы с модулем.

Должна быть возможность экспортировать список пользователей в

форматах *.csv и *.xlsx.

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

учета и мониторинга работы пользователей в ПО.

Данный раздел должен предоставлять инструмент для просмотра и

анализа действий (активности) всех пользователей системы с возможными

отборами по различным фильтрам;

Модуль должен иметь раздел, позволяющий осуществлять поиск

материалов по результатам фиксаций ТС комплексами ФВФ, а также

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

заданными фильтрами.

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

информации о проездах ТС, ГРЗ которых заданы оператором без постановки

ТС в розыск;

Должна быть реализована возможность поиска ГРЗ с осуществлением

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

интервал времени (дата и время);

ГРЗ;

список КФВФ;

направлению движения (при условии отбора по конкретному КФВФ);

скорость ТС (при условии передачи данного параметра КФВФ);

марки/модели, цвету, типу ТС (при условии наличия загруженных в ПО

сведений из федерального реестра зарегистрированных ТС, которые

предоставляются заказчиком или предоставленных комплексом ФВФ).

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

федерального реестра зарегистрированных ТС, поля которого состоят из ГРЗ,

марка, модель, цвет, тип ТС. Данная загрузка данных должна позволять

осуществлять поиск ТС не только по ГРЗ, но и по марке, модели, цвету, типу

ТС;

Должна быть реализована возможность поиска ТС по сочетанию

признаков:

36

Возможность поиска проездов ТС за временной диапазон, задаваемый

произвольно;

Возможность поиска проездов ТС за временной диапазон, по

конкретному прибору ФВФ или нескольким выбранным;

Возможность поиска проездов ТС, обнаруженных заданными типами

КФВФ (всех типов, включая парковочные);

Возможность поиска проездов ТС в обозначенной пользователем

области на карте одного из городов, в котором Система находится в

постоянной эксплуатации;

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

проездов ТС;

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

фиксации;

Возможность экспорта результатов поиска в формат *.csv, *.docx, *.pdf,

*.xlsx.

Возможность отображения фотографий проездов ТС;

Возможность поиска ТС по КФВФ.

В результате поиска должна быть отражена следующая информация:

Дата загрузки фиксации ТС в ПО;

Дата фиксации ТС;

Место фиксации;

ТС с их установочными данными (ГРЗ, тип ТС, марка, модель, цвет) и

любые другие данные, при условии выполнения п. 4.3.3;

Номер КФВФ, направление движения ТС, скорость (при условии

фиксации и передачи скорости КФВФ);

ссылка на маршрут движения ТС за период времени;

Детальное фото (и обзорное при условии передачи его КФВФ);

Картографическая визуализация места фиксации ТС;

Результат поиска необходимо представлять табличными данными,

выводимыми построчно.

В данных с найденными прохождениями ТС должна быть возможность

открытия детального и обзорного снимка ТС (при их наличии) и

местоположения ТС на картографическом снимке. Должна быть возможность

зуммирования масштаба положения ТС на карте;

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

построения маршрута искомого ТС на картографическом снимке;

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

поиска;

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

по возрастанию\убыванию по столбцам «Дата фиксации» и «Дата загрузки»;

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

в форматы *.csv, *.docx, *.pdf, *.xlsx (п.4.3.4.).

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

материалов согласно заданным фильтрам.

37

Возможности экспорта данных по прохождениям ТС в данном разделе

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

Экспорт данных должен поддерживаться в формате *.xlsx, *.csv с

сохранением детального и обзорного фото (при условии его передачи КФВФ)

в отдельные каталоги;

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

отдельные списки экспорта с применением фильтров:

ГРЗ (с возможностью ручного ввода или загрузки списка из файлов);

Интервал даты и времени;

Список КФВФ (с возможность из выбора в том числе и на карте).

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

розыска.

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

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

карте местности, для осуществления координированного управления по их

перехвату и задержанию;

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

различные списки розыска ТС. Данные списки должны создаваться,

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

предоставленных ему на это прав;

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

выборочно включать/выключать конкретные списки розыска для

срабатывания из имеющихся в доступе списков розыска;

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

или в виде всплывающей экранной формы. Звуковое уведомление должно

срабатывать независимо от того, в каком разделе РС на текущий момент

работает пользователь;

Должен быть реализован функционал оперативного розыска - при

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

фиксируемого ГРЗ в списках розыска в установленный Администратором

интервал времени в минутах. Если данный ГРЗ находится в розыске –

происходит проверка даты фиксации. Если фиксация ТС произошла в

пределах установленного Администратором интервала времени –

уведомления о срабатывании отправляются всем пользователям,

подписанным на список розыска, по которому произошло срабатывание. Если

фиксация ТС произошла вне предела установленного Администратором

интервала времени, то уведомления не отправляются пользователю, но

сохраняется в архиве срабатывания для последующего просмотра;

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

Администратором системы. В ПО должна быть возможность использования

значения порога (интервала) времени оперативного розыска по умолчанию 4.

Подписка и отписка на определенные списки розыска для каждого

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

38

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

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

Создание списка розыска должно требовать ввода только ГРЗ полного

соответствия без ввода масок;

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

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

вошедшему в систему. Все правила в данном списке видны только

конкретному пользователю;

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

включение\отключение звуковых уведомлений при срабатывании

розыска;

включение\отключение всплывающих карточек при срабатывании

розыска;

добавление фильтрации по выбору направления движения ТС

(встречное/попутное);

добавление фильтрации по серийному номеру комплекса при

срабатывании (выбор списка комплексов ФВФ для активации срабатывания).

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

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

определения срабатывания в отдельном информационном окне;

Должна быть предусмотрена область просмотра результатов

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

Каждая строка – отдельная фиксация ГРЗ в розыске;

Должен быть предусмотрен функционал детального просмотра

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

фото. В карточке срабатывания должно отражаться:

Обзорное фото ТС;

Дата фиксации ТС КФВФ;

Дата загрузки фиксации ТС в ПО;

Искомый ГРЗ;

Серийный номер КФВФ;

Направление движения ТС;

Местоположение КФВФ;

Дата и время постановки в розыск;

Комментарий (для данного списка розыска);

Участок карты с местоположением фиксации искомого ТС.

Должно быть предусмотрено добавления одного и того же ГРЗ в разные,

не связанные между собой списки розыска и срабатывания по данному ГРЗ

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

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

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

программе период хранения материалов.

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

срабатывания согласно применяемым фильтрам по:

39

ГРЗ;

интервалу времени поиска;

спискам розыска.

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

выводимые построчно:

ГРЗ;

Дата и время фиксации;

Место фиксации ТС;

Серийный номер КФВФ;

Цвет списка розыска;

Наименование списка розыска.

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

*.csv, *.xlsx.

Должен быть детальный просмотр архивных срабатываний,

позволяющий предоставлять:

детальный снимок ТС с распознанным ГРЗ;

участок карты с выделенным положением зафиксированного ГРЗ, с

возможностью масштабирования карты.

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

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

поиск ТС, следовавших за (либо перед) проверяемым объектом (ТС,

указанного в запросе по ГРЗ), передвигавшихся вместе с исходным ТС в

течение определенного временного периода, зафиксированных на двух и

более КФВФ.

Для осуществления поиска связанных ТС должны быть предоставлены

данные для поиска:

известный ГРЗ в полном формате, без символов заменителей;

интервал времени поиска;

количество секунд до проезда и количество секунд после проезда

исходного ТС;

серийные номера комплексов ФВФ (должен быть выбор из списка

возможных или выбор района на карте).

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

табличные данные, выводимые построчно:

количество фиксаций исходного ГРЗ;

количество связей с исходным ГРЗ (совпадения);

связанные ГРЗ с информацией о:

количестве совпадений;

серийные номера КФВФ, зафиксировавшие второй ГРЗ;

% совпадения.

Должен быть раздел, в котором должны отображаться предполагаемые

дубликаты ГРЗ ТС.

40

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

ТС, то есть фиксировать информацию о ТС «двойниках», которые за короткий

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

При каждой фиксации ТС система должна запоминать время и

координаты первой фиксации ТС (точка А). При следующей фиксации

данного ТС (точка Б) на основании фиксации времени и координат должен

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

точки А (первой фиксации) до точки Б (второй фиксации). Если расчетная

скорость ТС больше, чем установленное значение в настройках ПО -

автомобиль должен считаться дубликатом;

Результатом должны быть представлены табличные данные, где

построчно выводятся:

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

Время первой и второй фиксации ТС;

Местоположение первой и второй фиксации ТС.

Должен быть предусмотрен вывод более подробной информации по

результатам поиска дубликатов:

Два распознающих снимка ТС с датой и местом фиксации;

Интерактивная карта с отображением 2-х мест фиксации ТС КФВФ с

возможностью зуммирования для наглядности просмотра данной

информации.

Должен быть предусмотрен фильтр поиска по ГРЗ ТС, позволяющий

конкретизировать результаты поиска дубликатов ТС.

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

данные.

Должен быть реализован функционал, позволяющий найти ТС,

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

Для осуществления поиска должен быть один или несколько фильтров.

В каждом фильтре требуется указать:

серийный номер КФВФ (выбор из списка или на карте);

интервал времени.

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

выводимые построчно в порядке убывания количества фиксаций ГРЗ:

ГРЗ;

Марка (при наличии загруженной базы федерального реестра

зарегистрированных ТС);

Цвет (при наличии загруженной базы федерального реестра

зарегистрированных ТС);

Тип ТС (при наличии загруженной базы федерального реестра

зарегистрированных ТС).

Должна быть возможность экспорта полученных данных в формате

*.xlsx;

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

текущую информацию по устройствам ФВФ, такую как:

41

Серийный номер КФВФ;

Географические координаты КФВФ;

Местоположение (адрес) КФВФ;

Модель КФВФ;

Даты последней фиксации/загрузки материалов ФВФ.

Группу, к которой относится данный КФВФ.

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

количеству проездов ТС, зафиксированных КФВФ за заданный период

времени;

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

статистику посуточную и почасовую;

Должен быть фильтр введения интервала времени, необходимого для

получения статистических данных;

Результатом данного отчета должны быть табличные данные,

выводимые построчно:

КФВФ;

Местоположение (адрес) КФВФ;

Количество фиксаций ТС по столбцам, где каждый столбец должен

иметь значение часа (при выбранном фильтре «по часам») или значение – день

(при выбранном фильтре «посуточно», п.4.9.7.).

Должна быть возможность экспорта полученных данных в формате

*.xlsx;

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

информацию по несоответствию координат устройства, созданного в

программе Администратором и текущих координат фиксации, получаемых от

КФВФ;

Данный функционал должен позволять осуществлять проверку

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

в метрах;

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

построчно:

серийный номер КФВФ;

Местоположение (адрес) КФВФ;

Отклонение в метрах;

Статус соответствия (правильные координаты, нет координат в КФВФ,

несоответствие координат).

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

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

отражением следующей сравнительной информации по месту фиксации ТС и

по КФВФ:

Серийный номер КФВФ;

Адрес;

Широта;

Долгота;

42

Отклонение в метрах;

Статус соответствия.

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

параметры.

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

параметры очистки записей проездов ТС:

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

удаляться из ПО;

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

проездов ТС в ПО.

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

значений скорости, с которой ТС, теоретически, не может передвигаться по

прямой между КФВФ.

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

будет отображаться карточка с проездом, где ГРЗ ТС внесён в список розыска.

количество точек для построения маршрута движения ТС.

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

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

Должен быть реализован функционал прорисовки графика количества

фиксаций ТС на КФВФ и количества загруженных материалов за последние

24 часа;

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

загрузки данных для каждого типа (модели) КФВФ Администратором;

Должна быть реализована возможность включения / выключения

модулей загрузки данных Администратором;

Должно быть отражено количество работающих / неработающих

модулей загрузки данных;

Информация по модулям загрузки данных должна выводиться

построчно в виде табличных данных:

Номер модуля загрузки данных;

Наименование модулей загрузки данных;

Серийный номер КФВФ, по которому тот закреплен за модулем

загрузки данных;

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

Должна быть возможность просмотра более уточненной информации по

каждому конкретному модулю загрузки данных:

График сравнения количества фиксаций ТС на КФВФ и количества

загруженных материалов за последние 24 часа;

Состояние модулей загрузки данных (включен / выключен);

Учетные данные для доступа к КФВФ, согласно протокола загрузки

данных;

Местоположение КФВФ;

Серийный номер КФВФ;

43

Широта;

Долгота;

Должен быть раздел, отображающий наиболее полную информацию по

КФВФ и загрузок с них материалов.

Информация по КФВФ должна быть отражена посредством прорисовки

графика сравнения количества фиксаций ТС на КФВФ и количества

загруженных материалов за последние 24 часа;

Должна быть возможность просмотра количества работающих /

неработающих КФВФ;

Данный раздел должен предоставлять следующие данные,

представленные в табличной форме, выводимые построчно:

Серийный номер КФВФ;

Модель (марка) КФВФ;

Местоположение КФВФ;

Номер модуля загрузки данных, связанного с этим КФВФ;

Дата и время последней фиксации ТС;

Дата и время загрузки фотоматериала о прохождении ТС в ПО;

Группа, к которой относится КФВФ (определяется Администратором);

Должна быть возможность применения фильтров поиска КФВФ в

программе по следующим критериям:

Серийный номер КФВФ;

Модель (марка) КФВФ;

Местоположение КФВФ;

Номер модуля загрузки данных;

Дата и время последней фиксации ТС;

Дата и время загрузки фотоматериала о похождении ТС в ПО;

Группа, к которой относится КФВФ (определяется Администратором).

Должна быть возможность настройки отображения фильтров в ПО, то

есть включения/выключения их в интерфейсе РС;

Должна быть возможность создания и удаления КФВФ для каждого

типа (модели) комплексов Администратором ПО, а также редактирования

параметров КФВФ;

В данном разделе должна быть возможность включения и отключения

отображения загруженной карты одного из городов, в котором Система

находится в постоянной эксплуатации для раздела, позволяющего

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

(п.4.3.);

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

символов в поле адреса для раздела, позволяющего осуществлять поиск

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

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

фиксации ТС не ограничено.

44

4.2. Требования к комплексу ФВФ, формирующему данные для

передачи в Макет

В ходе выполнения работ Исполнитель должен обеспечить

формирование фотоматериалов и отправку их для обработки в локальный

сегмент ЦСУ программно-аппаратными комплексами, соответствующими

нижеуказанным требованиям.

Программно-аппаратный комплекс должен быть предназначен для

фиксации следующих нарушений ПДД и административных правонарушений:

нарушения в зонах действия знаков «Стоянка запрещена» / «Остановка

запрещена»;

нарушения правил парковки на пешеходных переходах;

нарушения правил парковки на тротуаре;

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

По каждому зафиксированному нарушению программно-аппаратный

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

дальнейшей обработки в локальный сегмент ЦСУ.

Кроме того, ПАК предназначен для решения проблем правовой

защищенности сотрудников ДПС, обеспечения личной безопасности,

осуществления контроля за несением службы, соблюдения законности в

правоприменительной деятельности.

ПАК должен позволять обеспечить полно сменную автономную аудио-

и видеофиксацию окружающей обстановки в зоне несения службы

сотрудником ДПС, а также аудио- и видеозапись: административных

правонарушений, осуществляемых должностными лицами административных

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

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

требований ПДД.

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

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

решения, которые обеспечат дальнейшее развитие Макета без его

кардинальной переработки за счет наращивания его вычислительной

мощности, перехода на использование сетевого оборудования с большей

пропускной способностью и пр.

4.3.1. Требования к численности и квалификации персонала

системы и режиму его работы

Численность технического персонала должна быть достаточной для

обеспечения бесперебойной работы Макета в соответствии с требованиями,

определенными в настоящем техническом задании, а также для

функционирования Макета в штатном режиме, реализующем выполнение всех

45

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

круглосуточном режиме.

Персонал, допущенный к эксплуатации и обслуживанию Макета,

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

функционирования Макета и/или выполнения требований, определенных в

руководствах пользователей Макета.

Режим работы технического персонала должен быть достаточным для

обеспечения бесперебойной работы Макета в соответствии с требованиями,

определенными в настоящем ТЗ, а также для функционирования Макета в

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

4.3.2. Требования к надежности Макета

Проектные решения должны обеспечить функционирование Макета в

режиме 24/7/365.

Макет должен сохранять свою работоспособность в случаях единичных

отказов любого из компонентов или модулей Макета.

Любые виды программных, сетевых, аппаратных сбоев, а также сбоев

операционной системы (в том числе зависание операционной системы,

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

должны оказывать влияние на функционирование Макета после устранения

причин их повлекших.

При проектировании ПО необходимо предусмотреть возможность

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

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

перерывы в работе отдельных модулей ПО не должны влиять на процессы

обработки входных потоков данных.

4.3.3. Требования к безопасности

Используемое оборудование, материалы и ПО не должны допускать

возможности нанесения вреда здоровью или поражения персонала

электрическим током и электромагнитными излучениями согласно

ГОСТ 2.1.019-79 и при условии соблюдения правил эксплуатации

оборудования.

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

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

ИСО/ТО 12100-2-92 (ЕН 292-2-91). Дополнительные требования по

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

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

Для пользовательских интерфейсов должны использоваться только

русифицированные формы.

46

Пользовательские интерфейсы всех АРМ Макета должны удовлетворять

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

цветовое оформление интерфейса должно быть выполнено в едином

графическом стиле;

для обозначения одних и тех же операций должны использоваться

одинаковые графические значки, кнопки и другие управляющие

(навигационные) элементы;

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

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

реакция Макета на действия пользователя (переключение фокуса,

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

теми же графическими элементами, независимо от их расположения на экране;

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

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

системы меню, предоставляющей выбор альтернативных действий.

Пользовательский интерфейс всех АРМ должен быть понятным,

удобным, не перегруженным графическими элементами. Должно быть

обеспечено быстрое отображение экранных форм, навигационные элементы

должны быть выполнены в удобной для пользователя форме. Ввод-вывод

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

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

режимах.

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

вызванных неверными действиями пользователей, неверным форматом или

недопустимыми значениями входных данных. В указанных случаях

пользователю должны выводиться соответствующие сообщения, после чего

должно происходить возвращение в состояние, предшествовавшее неверной

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

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

ремонту и хранению модулей Макета

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

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

проектирования.

4.3.6. Требования по защите информации от несанкционированного

доступа

Перечень защищаемой информации ограниченного доступа,

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

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

При разработке Макета должна быть обеспечена защита информации,

обрабатываемой в Макете и подпадающей под действие Федерального закона

47

от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях

и о защите информации», Федерального закона от 27 июля 2006 г. № 152-ФЗ

«О персональных данных» и Федерального закона от 25 марта 2011 г.

№ 63-Ф3 «Об электронной подписи».

Другие требования по информационной безопасности Макета

обеспечиваются средствами ЦОД, в котором размещается Макет.

4.3.7. Требования к сохранности информации при авариях и защите

от влияния внешних воздействий

При функционировании Макета должна обеспечиваться сохранность

информации при следующих аварийных ситуациях:

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

полный или частичный отказ модулей, включая сбои и отказы

накопителей на жестких магнитных дисках;

сбой ПО Макета;

ошибки в работе пользователей и персонала.

Сохранность информации при авариях должна быть обеспечена

функцией резервного копирования.

Допускается временное (на время технологического перерыва)

снижение производительности Макета.

ПО Макета должно быть разработано таким образом, чтобы его

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

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

В технической документации на ПО Макета должны быть описаны

меры, принимаемые для защиты ПО Макета и данных от случайных или

непреднамеренных изменений.

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

Должна быть обеспечена патентная чистота на все модули Макета и

используемые конструктивные решения.

После выполнения патентных исследований, в зависимости от их

результатов, Исполнитель должен предпринять меры для получения

Заказчиком прав на использование соответствующих патентов.

Макет должен создаваться на основе свободно распространяемого

программного обеспечения. При использовании в Макете программ

(программных комплексов и компонентов), разработанных третьими лицами,

условия, на которых передается право на использование (исполнение) этих

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

использованию макета по его прямому назначению.

48

5. Требования к составу работ

Состав работ, который должен быть реализован:

разработка предложений по структуре и содержанию отраслевых

стандартов, устанавливающих требования к составу данных, форматам и

протоколам информационного обмена РС с единым центральным сервером

управления;

разработка ПО федеральной подсистемы ЦСУ и ПО локальной

подсистемы ЦСУ, технической документации и Программы и методики

испытаний;

выполнение пусконаладочных работ федеральной и локальных

подсистем ЦСУ;

сопряжение локальных подсистем ЦСУ с РС, расположенными в не

менее 2-х субъектах Российской Федерации и комплексами ФВФ,

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

сопряжение федеральной подсистемы ЦСУ с Макетом Платформы

«Автодата»;

проведение демонстрации работы Макета в соответствии со сценариями,

указанными в настоящем Техническом задании. Сценарии могут быть

уточнены Заказчиком в ходе проведения работ.

49

6. Требования к демонстрации Макета

Демонстрация должна проводится с использованием следующих

технических средств:

монитор – 3 шт. На мониторах должны быть открыты АРМ

«Администратора регионального сегмента», АРМ «Аналитика ЦСУ» и

интерфейс мобильного приложения потребителя данных;

ПАК с предустановленным программным обеспечением, реализующим

функции «оперативного розыска».

Сценарий демонстрации макета «Единый ЦАФАП» Платформы

«Автодата»

Демонстрация интерфейса АРМ «Центрального сервера

управления» (федеральной подсистемы) с возможностью перехода в

интерфейса локальной подсистемы ЦСУ.

1. Производится презентация стартового окна ЦСУ с полями для

авторизации, где вводится логин и пароль и производится авторизация

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

2. В открывшемся окне пользователя представлен интерфейс АРМ

«Аналитик», где в списочном порядке представлен перечень субъектов РФ,

где установлена локальная подсистема ПО, с разделением по округам (ЦФО,

ДВФО и т.д. и т.п.).

3. При выборе одного из регионов, открывается форма с

предложение выбора дальнейшего направления работы, а именно работа с

нарушениями или работа со всем проходящим транспортным потоком (При

демонстрации производится открытии не менее двух интерфейсов ПО

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

информационных системах МВД. Данный пункт демонстрирует

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

административной практики в различных информационных системах МВД.).

4. Первоначально выбирается режим работы фиксации всего

проходящего транспортного потока.

Демонстрация реализации задач по ведению Федерального и оперативного

розыска ТС.

5. В режиме фиксации всего проходящего транспортного потока

открывается интерфейсное окно «Поток» с правами администратора, куда

предварительно загружены материалы с комплексов ФВФ. В рамках показа

регионального сегмента представляются следующие функции:

Общий список зафиксированных транспортных средств с их

отображением на геокартографической подоснове;

Возможность розыска по заданному ГРЗ и маске;

Возможность построения маршрута передвижения ТС на

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

50

Демонстрация работы аналитического модуля по розыску

сопутствующих ТС по следующему алгоритму:

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

контролируемый ГРЗ, а так же время контроля и на геоинформационной

подоснове выбирается район контроля. При нажатии на кнопку «Анализ»,

формируется список автомобилей, которые двигались с искомым ГРЗ по

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

определения.

Для определения причастности к совершению однотипных

преступлений в соответствующие поля вносятся районы совершенных

преступлений и время совершения. При нажатии кнопки «анализ»

формируется список ГРЗ, которые находились в каждом из заданных районов

в момент совершения преступления.

Демонстрация возможности работы с розыском:

В разделе розыск, в поле «оперативный розыск», вносится заранее

известный ГРЗ, далее при нажатии кнопки «Ок», демонстрируется факт

постановки ГРЗ в раздел розыска, а так же демонстрируется, что данный ГРЗ

загрузился на прибор фотофиксации «Дозор-МП» (на базе планшетного ПК).

Далее, объектив Дозора-МП направляется на табличку с ГРЗ и

демонстрируется срабатывания уведомления на самом приборе, а так же

оповещения о срабатывания розыска в интерфейсном окне Потока.

Демонстрация отображения статистической информации о работе всех

комплексов ФВФ в регионе на соответствующих графиках и таблицах.

6. Далее осуществляется возврат в АРМ «Аналитика» ЦСУ и

осуществляется выбор режима «Работа с нарушениями».

Демонстрация интерфейса «Регионального Сегмента» и возможности

обработки нарушений разного типа.

7. При нажатии на этот раздел осуществляется открытие окна

Регионального сегмента для работы с нарушениями с правами

«администратора».

8. При демонстрации данного раздела отображается процесс работы

с нарушениями на разных этапах:

Этап «Контроля качества», на данном этапе показывается нарушения,

как их видит инспектор МВД, демонстрируется возможность корректировки

ГРЗ, работа с браком по материалам. Особое внимание обращается на то, что

при загрузке материалов фотофиксации, каждый ГРЗ проверяется на

целостность и неизменность материала, за счет проверки валидности ЭЦП, а

так же проверка номера на наличие в реестре «закрытых ГРЗ». Кроме того,

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

уникальный номер, который далее передается в ЦСУ и на основании которого

отслеживается весь жизненный цикл материала (забракован, вынесено

постановление и т.д. и т.п.).

51

Этап «Идентификации» на котором показывается работа инспектора с

разными типами нарушений (нарушение скоростного режима, проезда

перекрестка, правил парковки и т.д. и т.п.).

Этап «Вынесения постановления». Демонстрируется режим

формирования постановления, его подписания ЭЦП и отправку в почтовую

службу. При этом доставка осуществляется как в виде материала на бумажном

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

кабинета на сервисе «госуслуг».

Демонстрируется раздел по работе с жалобами граждан.

9. На этом пункте завершается показ регионального сегмента и

осуществляется возврат к рабочему окну «Аналитик» ЦСУ.

Демонстрация возможности мониторинга и учета комплексов ФВФ в

регионах эксплуатации.

10. В данном окне запускается раздел «Удаленного мониторинга

комплексов ФВФ». При демонстрации данного раздела отображаются

следующие элементы:

демонстрируется картографическая подоснова, с отображением на ней

всех комплексов ФВФ согласно заданной дислокации.

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

комплексов (доступность, соотношение зафиксированных материалов и

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

окончания очередной поверки и т.д. и т.п.).

11. Далее открывается в АРМ «Аналитика» ЦСУ окно статистической

отчетности, где демонстрируется возможности статистических отчетов в

разрезе времени, региона, типов нарушений и их отображении в графическом

виде. Так же демонстрируется карточка действий по каждому

зафиксированному материалу. Демонстрация производится на основании

ввода в поисковую строку уникального номера материала, полученного из

регионального сегмента.

12. Следующим этапом демонстрации, является показ работы

сотрудника в режиме АРМ «ДСП».

Демонстрация интерфейса АРМ «ДСП» федеральной подсистемы ЦСУ.

13. Осуществляется выход из АРМ «аналитик» ЦСУ и повторная

авторизация под пользователем с правами «ДСП». При демонстрации

слушателям разъясняется, что данный раздел создан, для закрытии и

исключении из обработки материалов, зафиксированных комплексами ФВФ,

которые относятся к автомобилям спец. Служб, военных колон, а так же лиц

подлежащих защите согласно Федерального закона от 20.04.1995 № 45-ФЗ «О

государственной защите судей, должностных лиц правоохранительных и

контролирующих органов» и Постановления правительства от 14.07.2015

№705 «О порядке защиты сведений об осуществлении государственной

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

52

14. В Окне АРМ «ДСП» демонстрируется порядок внесения данного

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

сегменте невозможно получить информацию о наличии ГРЗ в данном реестре,

так как вся информация передается и хранится в зашифрованном виде.

Демонстрация прототипа мобильного приложения конечного

потребителя услуг

15. Далее производится демонстрация мобильного приложения

потребителя информации с сервиса «Автодата»:

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

Возможность регистрации через учетную запись в Госуслугах;

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

Настройка использования сервисов мобильного приложения;

Выбор используемых сервисов;

Настройка уведомлений.

Сервис оповещения о штрафах ГУОБДД МВД России с возможностью

интеграции с навигационными приложениями (Яндекс.Навигатор и др.).

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

фото-видео фиксации;

Оповещение о вероятном факте фиксации с превышением разрешенной

скорости движения;

Уведомление о факте вынесения постановления об АП (штраф ГУОБДД

МВД России);

Ознакомление с фотоматериалами зафиксированного нарушения и

дополнительной информацией о правонарушении.

Возможность обжалования постановления об АП (в случае наличия

оснований) без необходимости визита в ГУОБДД МВД России.

Возможность оплаты штрафа из приложения.

Сервис оповещения о зонах аварийности и опасных участках дорог с

возможностью интеграции с навигационными приложениями (Яндекс.

Навигатор и др.).

Оповещение пользователя о приближении к аварийно-опасному участку

дороги с информированием о типе ДТП (наезд на пешехода, столкновение с

летальным исходом, вылет на обочину и т.д.).

Сервис расчета маршрута грузового транспорта.

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

оси и т.д.

Расчет оптимального маршрута движения (с учетом разрешенных

параметров движения) в соответствие с внесенными параметрами.

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

контроля.

Отображение на карте расположение устройств фото-видео фиксации (в

т.ч. и переносных) и пунктов весогабаритного контроля.

53

Демонстрация интерфейса учета основных параметров дорожного

потока ТС

16. Демонстрируется возможность предоставлении информации

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

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

Российской Федерации от 16.11.2018 № 1379:

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

Возможность регистрации через учетную запись в Госуслугах;

Доступ с различных устройств под одной учетной записью.

Настройка и администрирование системы;

Выбор используемых сервисов;

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

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

Настройка внешних источников данных.

Анализ транспортных потоков на автодорогах и его характеристик

(интенсивность, плотность, средняя скорость и т.д.);

Отображение на карте характеристик транспортных потоков на

автодорогах в режиме реального времени;

Вывод на контрольную панель данных о характеристиках транспортных

потоков с требуемых участков дорог.

Сопровождение эксплуатации объектов дорожной инфраструктуры

(светофоры, метеодатчики, информационные табло и др.).

Ведение учета затрат на эксплуатацию объектов дорожной

инфраструктуры.

Отображение информации об аварийности:

Загрузка данных об аварийности из ГУОБДД МВД России;

Отображение на карте данных об аварийности с детальной информацией

о ДТП;

Отображение на карте ДТП в режиме реального времени.

Аналитическая отчетность с выводом отчетов и диаграмм по различным

параметрам, позволяющая:

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

транспортных потоков;

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

инфраструктуры;

проводить оценку эффективности применяющихся мер для снижения

аварийности на автодорогах;

принимать решения о развитии сети устройств фото-видео фиксации.

Анализ влияния факторов на дорожную обстановку (дорожные работы,

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

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

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

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

Фиксация фактов отклонения в качестве заявок на исполнение.

54

Прогнозирование дорожной обстановки на автодорогах на основе

исторических данных.

Демонстрация прохождения данных с разными параметрами

(нарушенной целостности файла, наличия в реестре «закрытых грз»).

17. Демонстрация прохождения информации и оповещения

пользователей платформы «Автодата»:

Открывается интерфейсное окно, эмулирующие работу комплекса ФВФ

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

материалы фиксации сформированы в формате, поддерживаемыми

несколькими производителями комплексов ФВФ и разных типов нарушения.

Данным пунктом осуществляется демонстрация возможности загрузки

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

материал 1 содержит признаки административного правонарушения, но

его ГРЗ внесен в перечень «закрытых» номеров;

материал 2 содержит признаки административного нарушения и на

данный ГРЗ сформирована подписка в мобильном приложении «Автодата»;

материал 3 содержит признаки административного нарушения;

материал 4 содержит признаки административного нарушения, но в его

структуру внесены изменения и нарушена целостность ЭЦП.

При нажатии кнопки «загрузить», осуществляется загрузка материалов

в региональный сегмент.

Далее демонстрируется следующая информация:

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

материалы, за исключением материала 1 (так как он занесен в реестр закрытых

ГРЗ);

в региональном сегменте работы с нарушениями загрузились все

материалы, за исключением материала 1 и 4. При чем в отношении Материала

4 сформировано оповещение, от том что у него нарушено ЭЦП.

в интерфейсе мобильного приложения демонстрируется,

сформированное оповещение от том, что в отношении этого ГРЗ имеется факт

фиксации комплексом ФВФ с нарушением допустимых параметров движения,

так как данный пользователь имеет подписку на данный ГРЗ.

55

7. Состав и содержание работ по созданию Макета

Состав и содержание работ по созданию Макета приведены в Таблице 1.

Таблица 1 - Состав и содержание работ по созданию Макета №

этапа Наименование работ Результат выполнения работы

1.

Разработка

предложений по

структуре и

содержанию

отраслевых

стандартов,

устанавливающих

требования к составу

данных, форматам и

протоколам

информационного

обмена РС с единым

центральным

сервером управления

Требования к информационному обмену, включая

требования к составу и формату данных,

протоколов и интерфейсов сопряжения между РС

и ЦСУ в форме первой редакции отраслевого

стандарта

2.

Разработка ПО

Федеральной

подсистемы ЦСУ

макета «Единого

ЦАФАП»

ПО Федеральной подсистемы ЦСУ, включая

исходный код

Разработка ПО

локальной

подсистемы ЦСУ

макета «Единого

ЦАФАП»

ПО локальной подсистемы ЦСУ, включая

исходный ход

4.

Разработка

технической

документации на

ЦСУ макета

«Единого ЦАФАП»,

включая ПМИ

Техническая документация ЦСУ, включая ПМИ

56

№

этапа Наименование работ Результат выполнения работы

5.

Выполнение

пусконаладочных

работ макета

«Единого ЦАФАП» в

части федеральной и

локальных подсистем

ЦСУ, сопряжение

локальных подсистем

ЦСУ с РС,

расположенными в не

менее 2-х субъектах

Российской

Федерации и

комплексами ФВФ,

соответствующими

требованиям

настоящего

Технического задания

Работоспособный ЦСУ, сопряженный с РС,

расположенными в не менее 2-х субъектов

Российской Федерации и комплексами ФВФ,

соответствующими требованиям настоящего

Технического задания

6.

Приемочные

испытания макета,

проведение

демонстрации работы

макета

Протокол приемочных испытаний, Акт приемки

макета, Отчет о проведении демонстрации,

включая фото и видео материалы

57

8. Порядок приемки выполненных работ

8.1. Приемка работ осуществляется в соответствии с требованиями

настоящего ТЗ.

8.2. Приемка работ осуществляется в установленном Заказчиком

порядке.

8.3. Приемка работ проводятся приемочной комиссией согласно ПМИ,

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

8.4. В состав приемочной комиссии входят представители

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

Заказчик имеет право, при необходимости, включить в состав своей части

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

8.5. Проверку полноты и качества выполнения функций Макета

необходимо проводить в два этапа. На первом этапе проводят испытания

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

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

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

требований ТЗ к Макету в целом.

8.6. В случае обнаружения недостатков в работе Макета приемочная

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

Исполнитель, и определяет сроки их устранения.

8.7. После успешного завершения приемки работы комиссия

подписывает акт приемки-сдачи работ.

58

9. Требования к Программе и методике испытаний

ПМИ должна содержать следующие разделы:

а) комплектность испытательной системы;

б) место и продолжительность испытаний;

в) этапы испытаний;

г) последовательность проведения испытаний;

д) условия проведения испытаний;

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

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

з) порядок привлечения экспертов;

и) требования к персоналу;

к) отчетность;

л) иные разделы, поясняющие порядок проведения испытаний.

В приложении к ПМИ должны быть описаны испытания,

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

а) требование ТЗ;

б) наименование испытания;

в) предусловие;

г) шаги;

д) ожидаемый результат.

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

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

подробно для исполнения тестировщиком.

ПМИ должна содержать Приложение, описывающее формат протокола

проведения испытаний.

59

10. Требования к составу и содержанию работ по подготовке

объекта автоматизации к вводу в действие

10.1. Приемочные испытания Макета проводить на функционирующем

объекте.

10.2. Испытания Макета выполнять после проведения

разработчиком/исполнителем отладки и тестирования поставляемых

программных и технических средств макетов и представления им

соответствующих документов о их готовности к испытаниям, а также после

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

10.3. Программа и методика испытаний Макета должны устанавливать

необходимый и достаточный объем испытаний, обеспечивающий заданную

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

включаться тесты (контрольные примеры).

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

включать проверку:

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

критических значениях параметров объекта автоматизации и в других

условиях функционирования Макета, указанных в ТЗ;

реакции Макета на некорректную информацию и аварийные ситуации;

выполнения каждого требования, относящегося к интерфейсу Макета;

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

отказов;

комплектности и качества эксплуатационной документации.

10.5. Приемка работ должна осуществляться на основании

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

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

10.6. Тестирование должно проводиться в соответствии с

разработанной ПМИ.

10.7. Результаты проведения тестирования Макета фиксируются в

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

10.8. В программе испытаний необходимо указать:

перечень объектов, подлежащих испытаниям;

описание проверяемых взаимосвязей Макета с внешними ИС;

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

результатов;

очередность испытаний компонентов Макета, порядок и методы

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

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

стенды/оборудование (генераторы);

критерии приемки по результатам испытаний.

10.9. К программе испытаний следует приложить график проведения

испытаний.

60

10.10. Подготовленные и согласованные тесты (контрольные примеры)

на этапе испытаний должны обеспечить:

полную проверку функций и процедур по перечню, согласованному с

Заказчиком;

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

и технических средств.

10.11. В качестве исходной информации для теста необходимо

использовать фрагмент реальной информации от внешних ИС в объеме,

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

10.12. В случае, если проведенные испытания будут признаны

недостаточными, либо будет выявлено нарушение требований

регламентирующих документов по составу или содержанию документации,

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

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

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

10.14. Проверка средств восстановления работоспособности Макета

после отказов должна включать:

проверку наличия в эксплуатационной документации рекомендаций по

восстановлению работоспособности и полноту их описания;

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

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

(при их наличии).

10.15. Проверку комплектности и качества эксплуатационной

документации следует проводить путем анализа документации на

соответствие требованиям нормативно-технических документов и ТЗ.

10.16. Результаты испытаний Макета, предусмотренных программой,

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

назначение испытаний и номер раздела требований ТЗ на макет, по

которому проводят испытание;

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

испытаниях;

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

обработка и оценка результатов;

условия проведения испытаний и характеристики исходных данных;

обобщенные результаты испытаний;

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

ТЗ.

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

по согласованию с Заказчиком.

61

11. Требования к документированию

1. Документация должна соответствовать имеющимся на момент ее

подготовки действующим нормативным документам.

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

MS Word и представлена в 2-х экземплярах на бумажном носителе и в 2-х

экземплярах в электронном виде на CD (по одному экземпляру для Заказчика

и Исполнителя).

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

комплекса государственных стандартов и руководящих документов:

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

ГОСТ 34.003-90 «Автоматизированные системы. Термины и

определения»;

ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при

создании автоматизированных систем»;

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной

системы»;

РД 50-34.698-90 «Автоматизированные системы. Требования к

содержанию документов».

Требования к составу технической документации:

пояснительная записка (схема алгоритма, общее описание алгоритма и

функционирования программы, а также обоснование принятых технических

решений),

структурная схема Макета;

руководство пользователя,

руководство администратора;

программа и методики испытаний Макета.

62

Приложение № 1

Структурная схема Макета

Макет «Единый ЦАФАП»

ЦСУ

Федеральная

подсистема

Комплекс ФВФ

Региональный сегмент

ЦАФАП

ИС

«Эвакуаторов»

ИС «ВГК» ИС «Платных

парковок» Данные по аварийности

ФИС ГИБДД-М

ФССП

ГИС ГМП

ФНС

Платформа

«Автодата»

нформации

Локальная

подсистема

Потребители

информации

Региональный сегмент

ЦАФАП

63