содержание .. 3 4 5 6 ..
Техническое задание. Разработка фрагмента Информационной системы межоператорского взаимодействия (2016 год) - часть 5
12 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ
12.1 Этап
1. Техническое проектировани
, разработка фрагмента СМВ и
проведение опытной эксплуатации.
Выработка и согласование технических решений для функций,
автоматизируемых в ИСМВ, в частности, должны быть детально
проработаны решения для Интеграционной шины;
Выработка и согласование решений для комплекса технических
средств ИСМВ;
Выработка и согласование решений, связанных с программным
обеспечением, на базе которого будет реализована ИСМВ;
Разработка даталогической модели базы данных ИСМВ;
Выработка и согласование дизайн-макета для web-интерфейсов
Личного кабинета ИСМВ;
Разработка и утверждение решений для структуры EFC-приложения,
которое
необходимо
разработать
для
обеспечения
интероперабельности транспондеров;
Выработка и согласование решений для системы кодирования ПВП,
участков дорог и других кодов, используемых СМВ.
Разработка компонентов ИСМВ;
Разработка и согласование программы и методики проведения
предварительных испытаний Системы;
Разработка проектов рабочей документации
(технологических
инструкций, руководства пользователя, инструкция по формированию
и ведению базы данных);
Развёртывание и базовая настройка ИСМВ в тестовой среде;
Проведение предварительных испытаний Системы и выработка
решения о передаче Системы в опытную эксплуатацию;
Опытная эксплуатация Системы и техническая поддержка в период
опытной эксплуатации;
160
Анализ результатов проведения опытной эксплуатации Системы и
согласование перечня доработок, которые должны быть выполнены для
приёмки Системы в промышленную эксплуатацию;
Доработка Системы по результатам проведения опытной эксплуатации;
Разработка и согласование программы и методики приемо-сдаточных
испытаний;
Проведение приемо-сдаточных испытаний и выработка решения о
передаче Системы в промышленную эксплуатацию;
Доработка рабочей документации
(технологических инструкций,
руководства пользователя, инструкция по формированию и ведению
базы данных);
разработка требований и плана работ по подготовке объекта
автоматизации к вводу системы в промышленную эксплуатацию.
Результаты этапа 1 должны быть отражены в следующих документах:
ведомость покупных изделий;
пояснительная записка к Техническому проекту;
схема структурная комплекса технических средств;
проекты технологических инструкций;
проект руководства пользователя ИСМВ;
инструкция по формированию и ведению базы данных;
программа и методики проведения предварительных испытаний
Системы;
программа и методики приемо-сдаточных испытаний Системы;
протокол предварительных испытаний;
акт приемки в опытную эксплуатацию;
протокол приемо-сдаточных испытаний;
журнал приемо-сдаточных испытаний;
акт о завершении опытной эксплуатации;
161
технологические инструкции;
руководство пользователя ИСМВ;
инструкция по формированию и ведению базы данных.
план работ по вводу системы в промышленную эксплуатацию.
12.2 Этап 2. Передача фрагмента Системы в промышленную эксплуатацию
На данном этапе проводится передача Системы в промышленную
эксплуатацию и производится выработка решений по дальнейшей технической
поддержке. Должны быть решены следующие основные задачи этапа:
Развёртывание и базовая настройка ИСМВ в промышленной среде;
Обучение пользователей (при необходимости);
Разработка предложений и согласование решений по технической
поддержки Системы в период ее промышленной эксплуатации.
Результаты этапа 2 должны быть отражены в следующих документах:
акт о готовности фрагмента СМВ к вводу в промышленную
эксплуатацию;
162
13 ПРЕДЛОЖЕНИЯ ПО ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ ИСМВ В ПЕРИОД
ПРОМЫШЛЕННОЙ ЭКСПЛУАТАЦИИ.ПОРЯДОК КОНТРОЛЯ И
ПРИЕМКИ СИСТЕМЫ
Испытания ИСМВ проводят с целью проверки соответствия ИСМВ и ее
компонентов требованиям из настоящего документа.
Испытания представляют собой процесс проверки выполнения заданных
функций ИСМВ, определения и проверки соответствия требованиям настоящего
ТЗ количественных и/или качественных характеристик, выявления с последующим
устранением недостатков в работе ИСМВ, а также в разработанной документации.
13.1 Виды испытаний и общие требования к приемке работ
Виды испытаний
Для приемки Системы устанавливаются следующие виды испытаний:
предварительные испытания;
опытная эксплуатация;
приемо-сдаточные испытания.
Требования к приемке работ
Приемка работ на этапах должна осуществляться поэтапно в соответствии с
договором на проведение работ по предъявлению Исполнителем комплекта
документов, разрабатываемых на данном этапе, и завершаться оформлением актов
выполнения работ, подписанного Исполнителем и утвержденного Заказчиком.
Испытания Системы должны представлять собой процесс проверки
выполнения функций Системы на соответствие требованиям настоящего ТЗ и
дополнений к нему, выявления и устранения недостатков в действиях Системы, в
разработанной документации.
163
Все виды испытаний должны проводиться совместно Исполнителем и
Заказчиком по соответствующим программам и методикам испытаний
Исполнителя, утвержденным Заказчиком.
По результатам предварительных испытаний должны оформляться
следующие документы:
- Акт проведения предварительных испытаний;
- Акт о вводе в опытную эксплуатацию.
Приемку работ должна осуществлять комиссия, назначенная приказом
Заказчика.
По результатам опытной эксплуатации и приемо-сдаточных испытаний
должны оформляться следующие документы:
- Акт о завершении опытной эксплуатации СМВ;
- Акт приемо-сдаточных испытаний СМВ;
- Акт о готовности фрагмента СМВ к вводу в промышленную
эксплуатацию СМВ.
13.2 Общие требования к приемке работ по этапам
Состав испытаний
Испытания прикладного программного обеспечения
(функциональных
модулей) Системы должны проводиться в соответствии с
«Программами и
методиками испытанийª, с использованием тестов, подготовленных Исполнителем
и утвержденных Заказчиком.
Опытная эксплуатация должна проводиться в реальном режиме работы всех
подразделений организации Заказчика, охватываемых Системой. Все функции
персонала, автоматизация которых предусмотрена в Системе, должны выполняться
с использованием разработанной Системы.
Во время опытной эксплуатации на всех объектах автоматизации должны
вестись рабочие журналы, в которые должны заноситься сведения о
164
продолжительности функционирования Системы, отказах, сбоях, аварийных
ситуациях, изменениях параметров объекта автоматизации, проводимых
корректировках документации и программных средств, наладке технических
средств.
Место проведения испытаний
Все виды испытаний должны проводиться на объекте автоматизации
Заказчика.
165
14 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ
ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ
СИСТЕМЫ В ДЕЙСТВИЕ
Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу Системы в действие будут определены на Этапе
2
«Передача Системы в промышленную эксплуатациюª.
166
15 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
15.1 Требования к форме представления документации
Документация должна удовлетворять требованиям комплекса стандартов и
руководящих документов на автоматизированные системы (ГОСТ 34.201-89, ГОСТ
34.601-90; ГОСТ 34.602-89, РД
0-34.698-90, ГОСТ 19.ххх).
Документация должна выпускаться на бумажных и электронных носителях
(формат Microsoft Word, Microsoft Visio, Microsoft Excel, Adobe Acrobat).
Документация должна быть представлена в сброшюрованном виде в 2-х
экземплярах и 1 экземпляр в электронном виде. Все материалы должны быть
оформлены отдельными томами.
15.2 Требования к составу документации
Состав и комплектность проектной документации, разрабатываемой в
соответствии с требованиями настоящего технического задания, должна
соответствовать требованиям ГОСТ
34.201-89. Содержание и оформление
документов техно-рабочего проекта должны соответствовать РД
0-34.698.
В состав техно-рабочего проекта должны входить следующие документы:
по общесистемным решениям:
пояснительная записка к Техническому проекту (П2);
o ведомость покупных изделий (ВП);
o схема структурная комплекса технических средств (С1);
o программа и методика испытаний (ПМ);
по организационному обеспечению:
o руководство пользователя (И3);
o инструкция по формированию и ведению базы данных (И4);
o технологические инструкции
(И2),
включая протокол
корректировки транзакций, протокол заведения нового оператора
в ИСМВ, регламент технического обслуживания.
167
Комплект подписываемых документов на стадии ввода в действие должен
включать в себя:
протоколы испытаний;
журнал приемо-сдаточных испытаний;
акт приемки в опытную эксплуатацию;
акт о завершении опытной эксплуатации;
акт приемки в промышленную эксплуатацию.
168
16 ИСТОЧНИКИ РАЗРАБОТКИ
При разработке документов должны соблюдаться требования
соответствующих стандартов и руководящих документов:
1. ГОСТ
19.404-79 ЕСПД.
«Пояснительная записка. Требования к
содержанию и оформлениюª;
2. ГОСТ 19.402-78 ЕСПД. «Описание программыª;
3. ГОСТ 19. 07-79 ЕСПД. «Ведомость эксплуатационных документовª;
4. ГОСТ 19. 01-78 ЕСПД.
«Формуляр. Требования к содержанию и
оформлениюª;
5. ГОСТ 19. 02-78 ЕСПД.
«Описание применения. Требования к
содержанию и оформлениюª;
6. ГОСТ 19. 03-79 ЕСПД.
«Руководство системного программиста.
Требования к содержанию и оформлениюª;
7. ГОСТ 19. 0 -79 ЕСПД.
«Руководство оператора. Требования к
содержанию и оформлениюª;
8. ГОСТ 19. 04-79 ЕСПД. «Руководство программиста. Требования к
содержанию и оформлениюª;
9. ГОСТ 19. 08-79 ЕСПД.
«Руководство
по
техническому
обслуживанию. Требования к содержанию и оформлениюª;
10. ГОСТ 24.104-8
«Автоматизированные системы управленияª;
11. ГОСТ 24. 01-82
«Автоматизированные
системы
управления
дорожным движениемª;
12. ГОСТ 24.701-86
«Единая система стандартов автоматизированных
систем управления. Надежность автоматизированных систем управления.
Основные положенияª;
13. ГОСТ 34.003-90
«Автоматизированные системы. Термины и
определенияª;
169
14. ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов
на автоматизированные системы. Виды, комплектность и обозначения
документов при создании автоматизированных системª;
15. ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов
на автоматизированные системы. Автоматизированные системы. Стадии
созданияª;
16. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов
на автоматизированные системы. Техническое задание на создание
автоматизированной системыª;
17. ГОСТ
34.603-92
«Информационная технология. Виды испытаний
автоматизированных системª;
18. РД
0-34.698-90
«Автоматизированные системы. Требования к
содержанию документовª;
19. ГОСТ Р
127 -2006
«Защита
информации.
Объект
информатизации. Факторы, воздействующие на информацию. Общие
положенияª;
20. Специальные требования и рекомендации по технической защите
конфиденциальной информации
(СТР-К)
(утверждено.
Приказом
Гостехкомиссии России от 30.08.02 № 282)
21. Руководящий документ.
«Автоматизированные системы. Защита от
несанкционированного
доступа
к
информации.
Классификация
автоматизированных систем и требования по защите информацииª
(утверждено решением председателя Государственной технической комиссии
при Президенте Российской Федерации от 30 марта 1992 г.).
170
17 ПРИЛОЖЕНИЯ
17.1 Приложение 1. Форматы обмена данными
Содержание
1 Введение
173
1.1 Цель документа
173
1.2 Презентация документа
175
2 Основные принципы и общие требования
176
3 Требования к интерфейсам от Эмитентов к Поставщикам услуги - Списки ЭСРП
180
3.1 Сервис: receiveChangedOBUList
183
3.2 Сервис: requestOBUList
193
3.3 Сервис: heartBeat
194
4 Требования к интерфейсам от Поставщиков услуги к Эмитентам
195
4.1 Сервис: receiveTransactionList
197
4.2 Сервис: heartBeat
205
5 Требования к интерфейсам для корректировки и сверки
206
5.1 Сервис: receiveTransactionAdjustmentList
209
5.2 Сервис: receiveTransactionAdjustmentStatusList
218
5.3 Сервис: receiveTransactionAdjustmentReconciliationConfirm
220
5.4 Сервис: receiveReconciliationInfo
223
5.5 Сервис: receiveReconciliationConfirm
225
6
Требования к интерфейсам по Информации о ПВП
227
6.1. Сервис: receivePlazaConfiguration
227
7
Требования к интерфейсам для передачи Интересующей транзакции
232
7.1
Сервис: requestTransactionofInterestInfo
232
7.2
Service: responseTransactionofInterestInfo
235
8 Требования к интерфейсам: особые правила и детали
237
8.1 Определение параметра
238
8.2
Требования к обеспечению безопасности
238
8.3
Требования к обработке ошибок
238
171
8.4 Определение параметра
240
8. Планирование обмена информацией
241
172
1 Введение
1.1 Цель документа
Настоящий
документ
разработан
для
определения
интерфейсов/взаимодействий
между различными участниками схемы
межоператорского взаимодействия в Российской Федерации.
Спецификации ориентированы на информационные потоки между
Поставщиками услуги и Эмитентами, согласно иллюстрации ниже:
Информация по ЭСРП (обозначена здесь на иллюстрации как Списки ЭСРП)
которая позволяет Поставщикам услуги идентифицировать ЭСРП, для которого
может быть предоставлена Услуга по межоператорскому взаимодействию со
стороны всех Эмитентов.
Информация о транзакции
(обозначена здесь на иллюстрации как
транзакция) которая заключается в предоставлении необходимой информации о
проездах, произведенных Пользователями на дорогах Поставщиков услуги для
выставления счетов Пользователям Эмитентами.
Информация о корректировках, которая может быть выдана Поставщиком
услуги или Эмитентом в момент, когда необходимо сделать корректировку
существующей транзакции, в результате которой создается дополнительная
транзакция, привязанная к изначальной скорректированной транзакции. Данная
информация также является частью информационного потока по “транзакциям”, в
соответствии с иллюстрацией, представленной ниже, даже если она передается от
Поставщика услуги или Эмитента друг другу.
Информация о сверке, является информацией необходимой для обмена в
период инвойсирования Услуги по межоператорскому взаимодействию
-
информация о счетах, выставляемых между Поставщиком услуги и Эмитентом за
услуги оказанные друг другу - для оценки точной суммы транзакций, включая
согласованные корректировки за последний период.
173
Настоящее приложение ориентировано только на передачу данных и не
предназначено для определения средств и процессов инвойсирования и платежей,
которые полностью определены в рамках Соглашения о межоператорском
взаимодействии.
Система информационного обмена основана на следующей архитектуре (см.
Схему информационного обмена между Сторонами ниже):
Обмен информацией между Сторонами осуществляется с помощью
платформы ИСМВ. ИСМВ развёрнута на кластере из нескольких первичных узлов
каждый из которых содержит полную копию всей информации передаваемой через
ИСМВ.
Выбор оптимального узла для взаимодействия осуществляется
автоматически, «прозрачноª для информационных систем Сторон.
В случае выхода первичного узла из строя использующие его ИС Оператора
дороги автоматически переключаются на работоспособный узел. В случае выхода
из строя канала связи между первичными узлами обмен информацией
осуществляется по работоспособным маршрутам.
174
Схема информационного обмена между Сторонами
1.2 Презентация документа
Приложение разделено на несколько разделов, включая:
Раздел 1 - Введение. Настоящий раздел представляет краткое описание
Информационной системы межоператорского взаимодействия (ИСМВ).
Раздел 2 - Справочная документация. В этом разделе даются ссылки на
стандарты и руководства или другие документы, которые следует рассматривать
вместе с настоящим документом или использовать в качестве ссылки в рамках
настоящего документа.
Раздел 3 - Требования к интерфейсам от Эмитентов к Поставщикам
услуги. В этом разделе перечислены требования, подлежащие выполнению в
отношениях между Эмитентами и Поставщиками услуги, с тем чтобы Поставщики
услуги имели возможность управлять транзакциями на своих полосах проезда и,
таким образом, принимать транзакцию и разрешать Пользователю проезжать по их
175
полосам проезда или нет, информировать Пользователя о состоянии его ЭСРП и
балансе счета.
Раздел
4
- Требования к интерфейсам от Поставщиков услуги к
Эмитентам. В этом разделе перечислены требования, подлежащие выполнению в
отношениях между Поставщиками услуги и Эмитентами, с тем чтобы Эмитенты
имели возможность оформить транзакции, соответствующие транзакциям,
успешно записанным на полосах проезда Поставщика услуги с использованием
ЭСРП, выданных Эмитентом.
Раздел 5 - Требования к интерфейсам для Сверки расчетов. В этом
разделе устанавливается список требований в отношении интерфейсов между
Эмитентами и Поставщиками услуги для решения вопросов, которые могут
возникнуть в результате управления транзакциями, с тем чтобы обмениваться
соответствующими данными для корректировки транзакций, включая, но не
ограничиваясь, возможные ошибочные классификации на полосах проезда.
Раздел 6
- Требования к интерфейсам Конфигурация ПВП. В этом
разделе определена конкретная информация, предоставляемая Поставщиками
услуги всем Эмитентам для идентификации полос проезда и ПВП, которые
используются в контексте интероперабельности.
Раздел 7
-
Требования к интерфейсам по передаче Интересующей
транзакции. В этом разделе указывается формат запроса, когда Эмитенту
требуется дополнительная информация по конкретным транзакциям, такая как
видео или фото записи от Поставщика услуги.
Раздел 8 - Требования к интерфейсам Особые правила и детали. В этом
разделе описываются некоторые специальные правила, применяемые в контексте
ИСМВ.
2 Основные принципы и общие требования
ИСМВ используется между Эмитентами и Поставщиками услуги для
обеспечения проезда Пользователя, имеющего действующий ЭСРП, который
привязан к действующему Агентскому договору с Эмитентом, по платной полосе
176
проезда Поставщиков услуги, с тем, чтобы последние получили плату за свои
услуги.
ИСМВ предназначена для обмена следующей информацией:
Эмитент предоставляет Поставщикам услуги список ЭСРП. Поставщик
услуги учитывают информацию для управления транзакцией на своих полосах
проезда.
Поставщики услуги направляют зарегистрированные транзакции,
осуществленные Пользователями при помощи действующих ЭСРП,
соответствующим Эмитентам. Эмитент инвойсирует и взимает соответствующую
плату с Пользователя и перечисляет денежные средства Поставщику услуги за
произведенную транзакцию.
Поставщик услуги и Эмитент
(Стороны Соглашения) обмениваются
дальнейшей информацией, чтобы убедиться, что они имеют всю достаточную
информацию для правильного выставления счета Пользователю и оплаты Услуги
по межоператорскому взаимодействию между собой, включая возможные
корректировки, которые необходимо сделать по уже существующим транзакциям и
информацию по окончательной сверке. Обмен корректировками производится с
целью обеспечения уточнения между Поставщиком услуги и соответствующим
Эмитентом в отношении конкретной существующей транзакции. Сверочная
информация аккумулирует за определенный период все транзакции и информацию
по возможным корректировкам соответствующих транзакций для одной пары,
состоящей из одного Поставщика услуги и одного Эмитента.
Примечание: В следующем тексте корректировка транзакции является
дополнительной информацией, связанной с существующей транзакцией и может
дополнить информацию о транзакции, но ни при каких обстоятельствах она не
должна изменять переделывать или заменяет любую существующую транзакцию,
а может лишь дополнить её.
Для достижения цели интероперабельности ИСМВ должна обеспечивать
надлежащий обмен следующей информацией:
177
Список ЭСРП. Этим списком необходимо обмениваться в регулярные
промежутки времени, он формируется каждым Эмитентом и рассылается каждому
Поставщику услуги. Для того чтобы гарантировать, что вся информация
предоставляется в должный срок, полный список должен предоставляться в
регулярные интервалы времени
(см. раздел
8, ниже) и дельты, которыми
обмениваются всякий раз, когда Эмитент считает это необходимым, чтобы принять
во внимание изменение статуса ЭСРП (например, с Низкого на Плохой или с
Хорошего на Удален/Украден/Потерян). ИСМВ обеспечивает доставку списков
Поставщику услуги каждый раз, когда Эмитент его отправляет (Полный или
Дельта список).
Список общих типов ЭСРП. Данный список предоставляется Эмитентом
Поставщику услуги через ИСМВ и предназначен для определения атрибутов ЭСРП
и механизмов безопасности необходимых для обработки ЭСРП от Эмитента на
полосах проезда Поставщика услуги. Связанный с обработкой ЭСРП, данный
список обменивается через регулярные промежутки времени в рамках процесса
обмена Списками ЭСРП.
Список транзакций ЭСРП. Этот список обменивается в регулярный
интервал времени, он формируется Поставщиком услуги и направляется Эмитенту,
которому принадлежит транзакция
(транзакции, осуществленные с помощью
ЭСРП, выданных Эмитентом). Этот список должен быть передан от Поставщика
услуги соответствующему Эмитенту каждый раз, когда Сторона, формирующая
список транзакций (любой Поставщик услуги) передает такой список в ИСМВ.
Список сверки транзакций. Этот список — совокупность всех транзакций,
зарегистрированных Поставщиком услуги за данный период
(период может
корректироваться в зависимости от соглашения между Сторонами, но должен быть
к примеру на ежедневной основе или еженедельной основе) по отношению к
каждому Эмитенту. Один файл адресуется Эмитенту. ИСМВ обеспечивает
доставку соответствующему Эмитенту данных файлов каждый раз, когда
Поставщик услуги отправляет такой файл в ИСМВ.
178
Список корректировок транзакций. Этот список — совокупность всех
корректировок произведенных Поставщиком услуги, привязанных в предыдущем
периоде
(без учета корректировок уже обработанных или согласованных) к
первоначальной транзакции (уже существующей в рамках Списка транзакций,
указанного выше). Этот список регулярно обменивается и каждый раз Поставщик
услуги рассматривает необходимость выдачи такого списка соответствующему
Эмитенту. В особых случаях, Эмитент может также выдать запрос на
корректировку в адрес Поставщика услуги, привязанную к конкретной транзакции.
Такой же процесс применяется в обоих случаях. ИСМВ обеспечивает доставку
надлежащего списка соответствующему Эмитенту каждый раз при его отправвке в
ИСМВ.
Список сверки корректировок транзакций. Этот список - совокупность
всех корректировок, выданных Поставщиком услуги в течение определенного
периода (период может корректироваться в зависимости от соглашения между
Сторонами, но должен быть к примеру на ежедневной основе или еженедельной
основе) по отношению к другой Стороне. Один файл адресуется одной Стороне.
ИСМВ обеспечивает доставку соответствующей Стороне данных файлов каждый
раз, когда друга Сторона выпускает отправляет такой файл в ИСМВ.
Список ПВП. Данный список содержит всю информацию в отношении
кодификации всех ПВП и полос проезда на сети дорог Поставщика услуги,
который может использоваться в рамках Соглашения. Такой список выдаётся
каждым Поставщиком услуги каждому Эмитенту, если происходит какое-либо
изменение в списке его ПВП. ИСМВ обеспечивает доставку данных файлов всем
Эмитентам каждый раз, когда Поставщик услуги отправляет такой файл в ИСМВ.
Общие требования:
Ни одна из рассматриваемых здесь услуг
(сервисов) не должна
ухудшать функционирование и работу внутренних систем
Поставщиков услуги или Эмитентов.
179
Каждая услуга может рассматриваться отдельно или в сочетании с
другими
(например, одновременно) без ухудшения качества
предоставления названных услуг.
Эксплуатационные качества каждой услуги должны быть
протестированы в отдельности и под нагрузкой, включая, но не
ограничивается, по количеству одновременных транзакций, количеству
ЭСРП, изменений ЭСРП.
Эксплуатационные качества каждой услуги должны быть
протестированы в отдельности и в режимах ограниченной
функциональности и продемонстрировать свою способность
восстанавливаться в течение заданного времени, включая, но не
ограничиваясь, сети связи сверху вниз.
Каким бы ни было решение по реализации ИСМВ как Эмитент, так и
Поставщик услуги должны всегда иметь информацию о том, что они
отправили в ИСМВ и что они получили от ИСМВ, а ИСМВ также
должна хранить такую информацию для сравнения.
3 Требования к интерфейсам от Эмитентов к Поставщикам услуги - Списки
ЭСРП
Следующий текст является спецификацией обмена информацией от
Эмитента к Поставщику услуги по статусу ЭСРП Эмитента.
Следующие спецификации должны, таким образом, рассматриваться как
строгий минимум, подлежащий реализации и являющийся обязательным.
Указанные далее спецификации разработаны на основе реализации веб-
сервиса, так как это считается самым современным принципом реализации.
Однако, любое другое решение, которое обеспечивает аналогичные или лучшие
характеристики, может быть рассмотрено после надлежащей предварительной
демонстрации того, что оно точно учитывает все требования при надлежащих
показателях (доступность, надежность и конфиденциальность).
180
В следующей таблице перечислены сервисы, которые должны быть
реализованы в рамках ИСМВ:
Имя сервиса
Входные
Возвращаемое
Описание
параметры
значение
receiveChangedOBUList
ChangedOBUList
OBUListStatusResult
Этот
сервис
вызывается
от
Эмитента с целью
информирования
Поставщика услуги об
изменении
статуса
ЭСРП за последний
период. Этот сервис
может быть вызван
для
получения
полного списка или
дельты списка ЭСРП.
requestOBUList
TollChargerId
StatusResult
Этот
сервис
ServiceProviderId
вызывается
от
Поставщика услуги,
когда ему необходимо
восстановить
из
списка
ЭСРП
состояние
ошибки
(например,
соединение вниз для
длительного периода
времени) и когда
просит полный список
из ИСМВ, которая
передает
запрос
Эмитенту.
181
Имя сервиса
Входные
Возвращаемое
Описание
параметры
значение
heartBeat
Нет сведений
StatusResult
Этот
сервис
вызывается от одной
из Сторон (Эмитент /
Поставщик услуги)
для
того,
чтобы
проверить, работает
ли ИСМВ должным
образом.
182
3.1 Сервис: receiveChangedOBUList
Этот сервис вызывается через ИСМВ от Эмитента с целью информирования
Поставщика услуги об изменении статуса ЭСРП за последний период. Этот сервис
должен вызываться для получения Полного списка или Дельта cписка ЭСРП.
Для того, чтобы Эмитенту не приходилось составлять один список ЭСРП для
каждого отдельного участка Поставщика услуги, все списки ЭСРП сливаются в
один единственный список, который включает различные статусы ЭСРП для
каждого участка Платных дорог.
Следующий текст включает входные и выходные параметры и определяет
некоторые подробные типы атрибутов, которые должны использоваться в рамках
ИСМВ.
Входные параметры
Сервис receiveChangedOBUList имеет один входной параметр,
ChangedOBUList, который содержит список элементов типов данных OBUType .
В следующей таблице указаны атрибуты ChangedOBUList:
Атрибуты
Тип данных
Описание
Timestamp/MsgTS
ДатаВремя
Время
отправки
сообщения
отправителем
(в данном случае
Эмитентом).
(Формат UTC)
Никогда не меняется и не
изменяется от отправителя к
получателю.
183
Атрибуты
Тип данных
Описание
ETSProviderId
Строка
Эмитент,
который
является
владельцем
всех
ЭСРП,
включенных в список.
Используемый формат кодировки:
Номер IIN страны
- Кодировка страны согласно ISO
3166-1 643 для России
- Номер IIN: Кодировка согласно
ISO 3
4 и 2894
ResentFlag
Целое цисло
Устанавливается на один, когда
список пересылается ИСМВ по
запросу Поставщика услуги.
OBUListBatchId/TableVersion
Объемный
Определяет список обмениваемых
ЭСРП. Когда новый полный список
передается
это
значение
увеличивается на единицу.
OBUListBundleNumber
Объемный
Это порядковый номер, который
увеличивается на один при каждом
частичном
обновлении
(используется
для различения
обновления ЭСРП принадлежащих
к тому же полному списку ЭСРП
(OBUBatchListId/TableVersion)
Когда отправляется новый полный
список ЭСРП последовательность
инициализируется к одному (1).
Previous
Объемный
То же, что и выше, позволяет
OBUlistBundleNumber
обнаруживать
недостающее
сообщение.
OBUListQty
Объемный
Количество переданных обновлений
ЭСРП.
184
Атрибуты
Тип данных
Описание
OBUListType
Строка
Допустимыми
значениями
являются:
FL, указывает, что полный список
OBUtype передается.
DL, указывает, что Дельта список
OBUtype передается.
EF,
указывает,
что
список
OBUGenericType передается.
Примечание:
Значение
«FLª
подразумевает следующее:
Значение
OBUListBatchId
увеличивается на единицу по
сравнению
с
предыдущим
значением.
Значение
OBUUpdateListNumberустановлено
на единицу (1).
ChangedOBU или Full OBU
Список элементов OBUType
Список ЭСРП, для которых статус
(1-xxxx)
был изменен за последний период
для принятия в расчет (начиная с
последнего выданного списка) для
дельта списка или для всех полных
списков.
Присутствует только для типа
Списка FL или DL
OBUGenricType
Список
элементов
Список Общих типов, которые
OBUGenricType (1-xxxx)
Поставщики услуги
должны
учитывать для целей обработки (на
полосах оплаты) конкретных ЭСРП
или пакетов ЭСРП от Эмитента
Присутствует только для типа
Списка EF
185
Тип данных OBUType должен включать следующую минимальную и
обязательную информацию представленную ниже:
Атрибут
Тип данных
Описание
OBUChangeDT
Дата последнего обновления для этого
особого ЭСРП в базе данных Эмитента
(местное время).
Устанавливается на ноль, когда не
используется.
EFCContextMark
Таблица
Конкретные значения и описание
кодификации ЭСРП
указаны в таблице: Кодификация ЭСРП,
идентификатор атрибута 0
PAN
Таблица
Конкретные значения и описание
кодификации ЭСРП
указаны таблице: Кодификация ЭСРП,
идентификатор атрибута 32
Expirydate
ДатаВремя
Дата истечения срока действия PA
,
когда данные от Paymentmeans не
должны приниматься во внимание (час
не приводится к нулю по местному
времени)
Устанавливается на ноль, когда не
используется
186
VehicleClass/ClassAlowed
Таблица
Список классов
(1 бит для одного
кодификации ЭСРП
класса):
xxxx xxx1: Class 1
xxxx xx1x: Class 2
xxxx x1xx: Class 3
xxxx 1xxx: Class 4
или NULL, если Control of vehicle class
= '00'
В случае проверки класса через PAN,
значение OBUGenericType принимается
за 00
ObuMediaType
Октет
2 - CLC, 4 - ЭСРП
Запас для будущего использования
StatusInvalid(2)
Octet Октет
Данный
октет
определяет
действительность ЭСРП следующим
образом:
0 = Действительный
1 = Недействительный Черный Украден
2 = Недействительный Черный Украден
4 = Недействительный Черный другое
= Не действителен для дальнейшего
использования Для того, чтобы ЭСРП
было принято для транзакции, код 0
должен быть считан по крайней мере в
StatusInvalid.
Status
Список элементов
Списко SectionColor как определено
SectionColor (1-xxxx)
далее.
Когда StatusInvalid отличается от
0
(нуля) данный список SectionColor
является пустым.
(1) Атрибут
“VehicleClass” может также использоваться Поставщиком
Услуги под свою полную ответственность в качестве средства
187
определение класса транспортного средства в случае режима
ограниченной функциональности, при котором Поставщик услуги не
имеет других средств автоматического безопасного определения
транспортного средства на своей полосе.
(2) Когда это значение отличается от (нуля) они будут такими же для
ВСЕХ участков, а список SectionColor пустым
Типы данных SectionColor должны включать минимальную и обязательную
информацию представленную ниже:
Атрибут
Тип данных
Описание
188
StatusSection (2)
Строка
Это соотвествует PlazagrouprID как
определено в главе (6)
Код
ПВП
в
формате
“БДДДSSGGККККН”. где “Б” - первый
символ кода Платной дороги. “ДДД” -
номер
кода
Платной
дороги
дополненный нулем слева до трех
символов. Например, формат “ДБББ”
для M-4 будет следующим; М004.
“SS” - Участок Платной дороги, 0 если
не используется
“GG” - Номер ПВП
“КККК” - Километр Платной дороги,
где расположен ПВП. Он дополняется
нулем с левой стороны
(например; 14
км в формате
“KKKK” выглядит
следующим образом: 0014). 0000 когда
не используется
“Н” - код направления (0 - направление
к 0 км, 1 - направление к последнему км,
2 - для ПВП имеющих полосы для двух
или более направлений). Для кольцевых
дорог “0” это направление, где ближе
нулевой
километр
(он
также
последний).
Противоположное
направление указывается кодом.
Когда применяется статус ко всему
участку
(секции),
значение кода
участка будет БДДДSS0000000
189
StatusColor
Статус ПАН, применимый для выше
указанной секции
1 - Оранжевый / НИЗКИЙ
2 - Серый / ПЛОХОЙ
ЭСРП со статусом StatusColor 2, не
должно
приниматься
на
соответствующем StatusSection
(1) В закрытых системах, статусы будут одинаковыми для всех ПВП, как
въездных и выездных и GGККККН устанавливаются на 0000000.
Вышеуказанный список включает только действительные ЭСРП со статусом
оранжевый или серый.
Все действительные ЭСРП (StatusInvalid=0) где StatusSection отсутствует в
списке считаются ХОРОШИМИ (включенными в белый список) для данной
секции/участка.
ЭСРП, которое имеет StatusSection 8 (НИЗКИЙ) для определенного участка
Платной дороги, считается действительным на данном участке. ЭСРП, имеющее
статус ХОРОШИЙ или НИЗКИЙ для определенного участка/секции считается
действительным на данном участке, в зависимости от правильности определения
класса транспортного средства и начисления тарифа.
Эмитент, таким образом, несет ответственность перед Поставщиком услуги
за оплату Транзакций, произведенных всеми его Пользователями, имеющими
ЭСРП со статусом ХОРОШИЙ или НИЗКИЙ, как определено выше для полос
Поставщика услуги.
Атрибут
Тип данных
Описание
Product label
Строка
Имя продукта, если имеется
EFCContextMark
Таблица
Конкретные значения и описание
кодификации ЭСРП
указаны таблице: Кодификация ЭСРП,
идентификатор атрибута 0
190
Атрибут
Тип данных
Описание
EquipmentClass
Целое число
См.
Стандарт
ISO-14906.
Идентификатор изготовителя ЭСРП - 0
если не используется
ManufacturerID
Целое число
См.
Стандарт
ISO-14906.
Идентификатор изготовителя ЭСРП - 0
если не используется
RndOBU
Целое число
Указывает
когда RndOBU не
представлен в VST и должен
запрашиваться через GetNonce
AC_CR Needed
Булево выражение
Указывает, требуется ли AC CR для
доступа к атрибутам
AC_CRKeyReference
Целое число
Используется
ссылка на Ключ
аутентификации доступа.
0
если
аутентификация доступа не требуется.
PaymentMeansExpiryDate
Булево выражение
Определяет, какая дата истечения срока
действия должна приниматься во
внимание
0: не контролируется
1: дата истечения срока действия от
средств
оплаты
должна
контролироваться
Issuer authenticator treatment
Булево выражение
Определяет, требуется ли запрашивать
аутентификатор Эмитента
Issuer authenticator Key
Целое число
111 - 114
Issuer authenticator attribut
Целое число
Идентификация
атрибута
для
аутентификации Эмитента
Operator authenticator treatment
Булево выражение
(Да/Нет)
Operator authenticator Key
Целое число
115
-
118, Количества ключей для
использования, когда требуется расчет
аутентификатора оператора. 0 если не
используется
OperatorKey 1 ref
Строка
Связан с производным ключом 11
191
Атрибут
Тип данных
Описание
OperatorKey 2 ref
Строка
Связан с производным ключом 116
OperatorKey 3 ref
Строка
Связан с производным ключом 117
OperatorKey 4 ref
Строка
Связан с производным ключом 118
Class Control needed
Булево выражение
Когда требуется контроль класса для
всех ЭСРП этого типа
Class list
Целое число
Список классов (1 бит на класс):
xxxx xxx1: Класс 1
xxxx xx1x: Класс 2
xxxx x1xx: Класс 3
xxxx 1xxx: Класс 4
или НОЛЬ если контроль класса
транспортного средства = '00'
Если значение отличается от списка
класса 00 PA в OBUType список не
будет контролироваться
Equipment status
Булево выражение
НЕТ в случае, когда не требуется
обработка Equipment status на уровне
полосы проезда,
ДА в случае, когда требуется обработка
Equipment status на уровне полосы
проезда
VehicleLicencePlateNumbe
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
VehicleClass
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
VehicleDimensions
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
VehicleAxles
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
VehicleWeightLimits
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
VehicleSpecificCharacteristics
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
192
Атрибут
Тип данных
Описание
Contract authenticator
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
Receiptdata authenticator
Булево выражение
Опциональный атрибут для чтения и
передачи, 0 - если не используется
Выходные параметры
Сервис
receiveChangedOBUList
должен
возвращать
данные
OBUListStatusResult . Следующая информация описывает OBUListStatusResult:
Атрибут
Тип данных
Описание
Timestamp/MsgTS
ДатаВремя
Время
отправки
сообщения
отправителем.
(Формат UTC)
Данный атрибут никогда не
меняется
от
отправителя
к
получателю
ResultCode/ResponseCode
Целое число
Код результата состояния:
«1ª: Успех
nnnn: Номер ошибки см. раздел 8.3
ниже
ResultDescription/Message
Строка
Описание кода результата. Может
содержать
более
подробное
объяснение ошибки (при наличии):
Текст ошибки
3.2 Сервис: requestOBUList
Этот сервис вызывается от Поставщика услуги, когда необходимо
восстановить Список ЭСРП из-за ошибки (например, когда соединение прервалось
на определенный период), который запрашивает полный список у Эмитента через
ИСМВ, которая возвращает запрашиваемый список.
193
Данный запрос может быть сделан только один раз между двумя Полными
списками OBUlists (см. раздел 8. ).
Запрос направляется Поставщиком услуги с использованием ИСМВ.
После получения запроса ИСМВ:
ИСМВ использует последний обновленный список, включающий все
обновления дельта списка, и перенаправляет его отправителю запроса.
ИСМВ направляет уведомление Эмитенту, с указанием требования
Поставщика услуги и включающее последние OBUListBatchId/TableVersion и
OBUlistBundle umber. (формат уведомления будет определен)
После получения уведомления Эмитент может решать, ждать или нет выдачи
нового полного списка.
Следующий текст включает входные и выходные параметры и определяет
некоторые подробные типы атрибутов, которые должны использоваться в рамках
ИСМВ.
Входные параметры
Сервис requestOBUList принимает два параметра:
1. TollChargerId для определения, какой Поставщик услуги запрашивает
полный список; и
2. ETSProviderId для определения Эмитента, у которого Поставщик услуги
просит полный список.
Выходные параметры
Сервис
RequestOBUList
возвращает
одноименный
элемент
requestOBUListResponse, который инкапсулирует элемент StatusResult типа данных
StatusResult.
Используя этот сервис, Поставщик услуги может запросить полный список
от Эмитента.
Следующие данные рассматриваются в StatusResult:
Атрибут
Тип данных
Описание
194
Timestamp/MsgTS
Datetime
Время
отправки
эмитирующей
стороной сообщения. (формат UTC).
Никогда не меняется от отправителя к
получателю
ResultCode/ResponseCode
Целое число
Код результата состояния:
«1ª: Успех
nnnn: Номер ошибки см. раздел
Ошибка! Источник ссылки не
найден.
ResultDescription/Message
Строка
Описание кода результата. Может
содержать более подробное объяснение
ошибки (при наличии): Текст ошибки
3.3 Сервис: heartBeat
Этот сервис вызывается от одной из Сторон (Эмитента / Поставщик услуги)
для того, чтобы проверить, работает ли ИСМВ в настоящее время должным
образом (в том числе сети связи).
Следующий текст включает входные и выходные параметры и определяет
некоторые подробные типы атрибутов, которые должны использоваться в рамках
ИСМВ.
Входные параметры
Сервис heartBeat не имеет входных параметров.
Выходные параметры
Сервис heartBeat возвращает в результате одноименный элемент
heartBeatResponse, который инкапсулирует элемент StatusResult типа данных
StatusResult.
StatusResult содержит следующую информацию:
Атрибут
Тип данных
Описание
ResultCode
Целое число
Код результата состояния:
195
«1ª: Успех
nnnn: Номер ошибки см. раздел
8.3
ResultDescription
Строка
Описание кода результата.
Может содержать
более
подробное объяснение ошибки
(при наличии)
4 Требования к интерфейсам от Поставщиков услуги к Эмитентам
Следующий текст является спецификацией обмена информацией от
Поставщика услуги к Эмитентам, направленной на управление транзакциями.
Последующий раздел нацелен на спецификации управления интерфейсом
возможных корректировок к транзакциям.
Указанная ниже информация разработана на основе реализации веб-сервиса,
так как это считается самым современным принципом реализации. Любое другое
решение, которое обеспечивает аналогичные или лучшие характеристики, может
быть рассмотрено после надлежащей предварительной демонстрации того, что оно
точно учитывает все требования при надлежащих показателях
(доступность,
надежность и конфиденциальность).
Имя сервиса
Входные
Возвращаемое
Описание
параметры
значение
receiveTransactionList
OBUTransactionList
TransactionStatusResult
Этот
сервис
вызывается
от
Поставщика услуги,
когда
ЭСРП
пользуется на его
дороге, для того
чтобы
проинформиро-вать
Эмитента, который
выдал ЭСРП.
196
Имя сервиса
Входные
Возвращаемое
Описание
параметры
значение
Receive Reconciliation
Этот
сервис
Info
вызывается
от
Поставщика услуги,
когда
ЭСРП
используется для
услуги на его сети
дорог для того,
чтобы
проинформиро-вать
Эмитента,
выпустившего
ЭСРП.
heartbeat
Нет сведений
StatusResult
Этот
сервис
вызывается
от
одной из Сторон
(Эмитент/
Поставщик услуги)
для того, чтобы
проверить, работает
ли ИСМВ должным
образом.
4.1 Сервис: receiveTransactionList
Этот сервис вызывается через ИСМВ от Поставщика услуги, когда ЭСРП
используется на Платной дороге Поставщика услуги, для того чтобы
проинформировать Эмитента, выпустившего ЭСРП.
Следующий текст включает входные и выходные параметры и определяет
некоторые подробные типы атрибутов, которые должны использоваться в рамках
ИСМВ.
Входные параметры
197
Услуга
receiveTransactionList
имеет
один входной параметр,
OBUTransactionList, который представляет собой список элементов типа данных
OBUTransactionType .
Следующая информация должна быть включена в OBUTransactionList:
Атрибут
Тип
Описание
Timestamp/MsgTS
ДатаВремя
Время отправки сообщения
отправителем.
(Формат UTC)
Данный атрибут никогда не
меняется от отправителя к
получателю
TollChargerId
Строка
Определяет Сторону
(код
страны
+ идентификатор
Поставщика услуги), которая
отправляет транзакции
ServiceProviderId
Строка
Определяет Сторону
(код
страны
+ ИНН эмитента),
которая получает транзакцию.
TrxBatchId
Объемный
Идентифицирует
передаваемый в рамках обмена
список транзакций для каждого
пакета.
198
Атрибут
Тип
Описание
TrxBundleNumber
Объемный
Порядковый номер, который
идентифицирует
каждую
передачу транзакций при том
же
«TrxBatchIdª.
Использование этого элемента
позволяет
Эмитенту
обнаруживать
факт
неполучения передачи от
Поставщика услуги.
Когда необходимо отправить
одновременно
несколько
транзакций,
они
будут
разделены на разные пакеты.
Примечание:
В
конце
определенного периода для
сверки
последовательность
инициализируется к одному (1).
Предыдущий
Объемный
То же, что выше, позволяет
TrxBundleNumber
обнаруживать недостающее
сообщение
TransactionQty
Целое число
Количество
транзакций,
которые
включены
в
сообщение.
OBUTransaction
Список
Список транзакций, по ЭСРП,
элементов
выданным другими Сторонами
OBUTransacti
за последний период.
onType
(1-
xxxx)
199
содержание .. 3 4 5 6 ..