ГОСТ Р ИСО 17573-2014. Национальный стандарт Российской Федерации. Электронный сбор платежей. Архитектура систем для взимания платы за проезд транспортных средств
Актуально на 01.11.2026.
Как цитировать: "ГОСТ Р ИСО 17573-2014. Национальный стандарт Российской Федерации. Электронный сбор платежей. Архитектура систем для взимания платы за проезд транспортных средств". ГОСТ Р ИСО 17573-2014. https://bukva.ai/docs/standart-gost-r-iso-17573-2014
(утв. и введен в действие Приказом Росстандарта от 11.11.2014 № 1578-ст)
Примечание
Документ введен в действие с 1 июня 2015 года.
Утвержден и введен в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 11 ноября 2014 г. № 1578-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
АРХИТЕКТУРА СИСТЕМ ДЛЯ ВЗИМАНИЯ ПЛАТЫ
ЗА ПРОЕЗД ТРАНСПОРТНЫХ СРЕДСТВ
Electronic fee collection. Systems
architecture for vehicle-related tolling
ISO 17573:2010
Electronic fee collection — Systems
architecture for vehicle-related tolling
(IDT)
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным бюджетным образовательным учреждением высшего профессионального образования «Московский автомобильно-дорожный государственный технический университет (МАДИ)» (МАДИ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 11 ноября 2014 г. № 1578-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 17573:2010 «Электронный сбор платежей. Архитектура систем для взимания платы за проезд транспортных средств» (ISO 17573:2010 «Electronic fee collection — Systems architecture for vehicle-related tolling»).
Следует обратить внимание на то, что некоторые из элементов настоящего документа могут быть предметом патентования прав.
ИСО 17573 был подготовлен Техническим комитетом ИСО/ТК 204 «Интеллектуальные транспортные системы в сотрудничестве с Техническим комитетом СЕН/ТК 278 „Дорожный транспорт и транспортная телематика“.»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации и межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Широкое использование платы требует обеспечения пользователей транспортных средств (далее — ТС), которые проезжают через различные платные участки улично-дорожной сети. Пользователям должен быть предложен единый договор для управления ТС на различных платных участках улично-дорожной сети, и эти ТС требуют наличия бортового оборудования («on-board equipment — OBE»), совместимого с системой сбора платы на различных платных участках улично-дорожной сети. В Европе, например, эта потребность была официально признана и законодательство о совместимости уже принято (см. Директиву 2004/52/EC). Существует коммерческое и экономическое обоснование в отношении OBE и систем сбора платы для стандартов, способствующих совместимости.
Также существует необходимость в разработке архитектуры системы, которая:
- обеспечивает архитектурный «зонтик» для других стандартов EFC в сфере общего определения терминов и понятий, функциональности и структуры основной системы;
- обеспечивает общую терминологию, которая позволяет своим пользователям:
- улучшить качество спецификаций, которые будут использоваться на международном рынке;
- уменьшить риск появления различных интерпретаций спецификаций (покупатель) и описаний (поставщик);
- упростить взаимодействие между экспертами из разных стран;
- увеличить потенциальное использование других EFC стандартов;
- определяет общую структуру, которая позволяет:
- выявлять деятельность потенциально подлежащую стандартизации;
- поддерживать единый, непротиворечивый взгляд на всю сферу;
- определяет границы между EFC и внешней средой;
- выявляет все объекты архитектуры, которые находятся в границах EFC;
- предоставляет базовое понимание предложенных понятий EFC, EFC совместимости и услуги EFC.
Предыдущее издание настоящего международного стандарта было основано на концептуальной модели, определенной в ИСО/ТУ 14904. С тех пор идеи о концептуальных моделях развились в ряде региональных проектов и реализациях, например в Японии и Европе. Эти новые модели были детализированы для их дальнейшего раскрытия по сравнению с ИСО/ТУ 17573:2003 и стали ближе к реализации в реальной жизни. Настоящий стандарт основан на этих новых концептуальных моделях и использует соответствующие термины и определения. Сравнение между ИСО/ТУ 17573:2003 с настоящим стандартом приведено в приложении B.
Хотя существует много различий, сбор платы с ТС может быть в некоторой степени сравним со сбором платы на общественном транспорте. Гармонизация архитектуры для сбора платы и тарифов может быть описана в стандартах и с точки зрения пользователя. В прошлом ИСО 24014-1 (подготовлен СЕН/ТК 278, рабочая группа 3 «Общественный транспорт») использовал ИСО/ТУ 17573:2003 в качестве отправной точки для их работы.
В настоящем стандарте учтено лучшее из последнего и также приняты во внимание требования ИСО 24014-1.
В настоящем стандарте для описания архитектуры используется стандарт на открытую распределенную обработку («open distributed processing — ODP»), который дает инструменты терминологии и моделирования для того, чтобы рассматривать архитектуру системы в различной перспективе (с разных точек зрения), чтобы покрыть, например, аппаратные компоненты, сетевые протоколы или интерфейсы, или роли и правила стратегии самой системы. Это достигается с помощью различных наборов понятий и терминов, каждый из которых выражается с точки зрения языка. Полное описание реальной системы может быть достигнуто только тогда, когда разработаны всевозможные модели точек зрения. Это позволяет четкое разделение отношений и более простой способ определения системы. Краткое описание концепции ODP приведено в приложение A.
Настоящий стандарт дает описание архитектуры среды систем сбора платы с точки зрения предприятий. Кроме того, настоящий стандарт определяет точку зрения основы информации посредством определения информационного взаимодействия и общих информационных объектов и дает основание для вычисления путем выявления необходимых вычислительных объектов и их интерфейсов.
1 Область применения
Настоящий стандарт определяет архитектуру системной среды взимания платы за проезд, в которой пользователь одной системы конкретного производителя сможет использовать весь набор имеющихся систем любого оператора на различных участках улично-дорожной сети.
Системы взимания платы, включенные в настоящий стандарт, могут использоваться для различных целей: взимание платы за проезд через определенные участки улично-дорожной сети, взимание платы за проезд через мост, тоннель, за перевозки на пароме, за доступ и парковочные места. С технической точки зрения данные системы реализуются за счет использования электронного бортового оборудования.
С организационной точки зрения описание архитектуры включает в себя определение стоимости платы за проезд и всех связанных с этим регулятивных мер. Сам процесс взимания платы не приводится.
По уровню детализации архитектуры настоящий стандарт определен с точки зрения общего обзора, общей терминологии, выявления необходимости разработки других стандартов и проектов этих стандартов.
В настоящий стандарт включены:
- структурный подход к архитектуре, направленный на основную цель, определение предметной области и нормативно-правовой базы;
- термины и определения предметной области;
- декомпозиция предметной области;
- обязательства главных участвующих сторон;
- установление связей между составными элементами;
- выявление основных информационных потоков;
- структурные диаграммы, отображающие взаимодействие между главными участвующими сторонами.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ИСО/МЭК 7498-1 Информационная технология — Взаимосвязь открытых систем — Базовая эталонная модель. Часть 1. Базовая модель (ISO/IEC 7498-1 Information Technology — Open systems interconnection reference model — Basic Reference Model: The Basic Model (ITU-T Recommendation X.200, 1994)
ИСО/МЭК 10746-2 Информационная технология — Открытая распределенная обработка — Эталонная модель: Принципы (ISO/IEC 10746-2 Information technology — Open distributed processing — Reference model: Foundations (ITU-T Recommendation X.902)
ИСО/МЭК 10746-3 Информационная технология — Открытая распределенная обработка — Эталонная модель: Архитектура (ISO/IEC 10746-3 Information technology — Open distributed processing — Reference model: Architecture (ITU-T Recommendation X.903)
ИСО/МЭК 15414 Информационная технология — Открытая распределенная обработка — Эталонная модель: Корпоративный язык (ISO/IEC 15414 Information technology — Open distributed processing — Reference model: Enterprise language (ITU-T Recommendation X.911)
3 Термины и определения
В настоящем стандарте использованы термины и определения из ИСО/МЭК 7498-1, ИСО/МЭК 10746-2, ИСО/МЭК 10746-3, ИСО/МЭК 15414, а также следующие:
3.1 контекстные данные (context data): Информация, предоставляемая ответственным оператором, необходимая для установления стоимости платежа за проезд через определенный участок улично-дорожной сети и проведения платежной операции.
3.2 пользователь (системы взимания платы) (customer (of a Toll Service Provider)): Физическое или юридическое лицо, пользующееся сервисами, предоставляемыми системой взимания платы за проезд.
Примечание - В зависимости от местной ситуации пользователь может быть владельцем, арендатором, хранителем, перевозчиком, обладателем свидетельства о регистрации ТС, водителем транспортного средства или любым другим третьим лицом.
3.3 водитель (driver): Человек, управляющий ТС.
Примечание - Предполагается, что водитель приводит в действие OBE (использует/обслуживает) (например, устанавливает число осей).
3.4 электронный сбор платежей (electronic fee collection); EFC: Взимание платы, осуществляемое за счет бортового электронного оборудования.
Примечание - Фактическая оплата (сбор платы) может иметь место вне системы оплаты.
3.5 взыскание (принудительное) (enforcement): Процесс принуждения к соблюдению законов и предписанных мер.
Примечание - В этом контексте «взыскание» представляет собой процесс принуждения к соблюдению платного режима.
3.6 совместимость оборудования (унификация) (equipment interoperability): Возможность смежной работы двух или более единиц оборудования.
3.7 совместимость (унификация) (interoperability): Возможность систем обеспечивать своими сервисами другие системы и наоборот, а также использовать сервисы так, чтобы добиться максимальной суммарной эффективности.
Пример - Эксплуатационная совместимость при использовании систем взимания платы за проезд позволяет пользователю бортового оборудования одной системы конкретного производителя осуществлять оплату на различных участках улично-дорожной сети.
3.8 уточнение позиционирования (localization augmention): Данные, посылаемые с дорожного оборудования бортовому оборудованию с целью вычисления более точного позиционирования транспортного средства.
3.9 бортовое оборудование (on-board equipment); OBE: Оборудование, установленное на транспортном средстве (внутри или снаружи), в том числе которое используется для осуществления электронной оплаты за проезд.
Примечание - OBE не нужно включать в платежные средства.
3.10 плательщик взносов (one liable for toll): Физическое или юридическое лицо, обязанное платить взносы, определенные для участка улично-дорожной сети.
Примечание - Платный режим может назначить более одного человека, чтобы нести ответственность (солидарную) за оплату проезда.
3.11 точка наблюдения (point of observation): Интерфейс, или идентифицируемый доступ к системе, где соответствие может быть проверено и утверждено.
3.12 придорожное оборудование (roadside equipment): Оборудование, расположенное вдоль сети автомобильных дорог в целях взаимодействия и обмена данными с бортовым оборудованием транспортных средств.
3.13 роль (role): Набор обязанностей.
3.14 тарифная схема (tariff scheme): Набор правил для определения стоимости сбора с транспортного средства на платном участке улично-дорожной сети для различных дней и времени.
Пример - Таблица, показывающая стоимость сбора для различных классов ТС.
3.15 сбор (toll): Цена за проезд, налог и иная плата в рамках взаимодействия транспортного средства с участком улично-дорожной сети.
Примечание - Данное определение является обобщением классического понятия сбора как «цена, налог или плата за разрешение проезда по участку улично-дорожной сети и т.д.», а также включает в себя взносы, расцененные как административное обязательство, например налоговый сбор.
3.16 оператор системы сбора платы (Toll Charger): Юридическое лицо, взимающее сбор с ТС на платных участках улично-дорожной сети.
Примечание - В других документах может использоваться как термин «оператор», так и термин «оператор сбора» (toll operator).
3.17 подтверждение платежа (toll declaration): Официальный отчет оператора, подтверждающий, что владелец транспортного средства на платном участке улично-дорожной сети произвел оплату в форме, согласованной оператором и поставщиком услуг.
Примечание - Правомерное подтверждение платежа должно выполнять формальные требования, включая требования к защите информации, согласованные между поставщиком услуг и оператором.
3.18 платный участок улично-дорожной сети (toll domain): Область или часть дорожной сети, где применен режим проезда на платной основе.
3.19 пункт сбора платы за проезд (toll point): Постройка внутри платного участка улично-дорожной сети, где производятся подтверждения платежа на платном участке улично-дорожной сети.
Пример - Пункт электронного сбора платы за проезд.
3.20 платный режим (toll regime): Свод правовых документов, включая требования, управляющий сбором денежных средств за проезд на платных участках улично-дорожной сети.
3.21 схема сбора платы за проезд (toll schema): Общее понятие, используемое для платного режима и/или платного участка улично-дорожной сети и/или системы сбора платы за проезд в зависимости от контекста.
3.22 сервис сбора платы за проезд (toll service): Сервис, позволяющий пользователям использовать только одни условия и один набор бортового оборудования сбора платы за проезд на одном и более платных участках улично-дорожной сети.
3.23 поставщик платных услуг (Toll Service Provider): Юридическое лицо, предоставляющее потребителям услуги сбора платы за проезд на одном и более платных участках улично-дорожной сети для одного или более классов ТС.
1 Поставщик платных услуг может поставлять как только бортовое оборудование, так и только магнитную и/или электронную карты, которые будут использоваться совместно с бортовым оборудованием третьей стороны (например, мобильный телефон и SIM-карта могут быть приобретены у других поставщиков услуг).
2 Поставщик платных услуг несет ответственность за работу (функционирование) бортового оборудования взимания денежных средств.
3 Поставщик платных услуг несет ответственность за операции (функционирование) OBE по взиманию платы.
3.24 система сбора платы (toll system): Оборудование дорожной инфраструктуры, используемое поставщиком сбора платы за проезд для сбора платы с владельцев транспортных средств.
1 OBE исключается из определения.
2 Оплата может производиться и вне системы сбора платы за проезд.
3.25 управление сбором платы за проезд (toll systems environment management): Действия, направленные на контроль над средой систем сбора платы за проезд.
Примечание - Управление средой сбора платы за проезд может охватывать несколько различных сфер, например политическую/законодательную, регулирующую, частного сектора, стандартизации и т.д.
3.26 участок взимания платы за проезд (tolled object): Отдельный участок платного участка улично-дорожной сети, для которого применяются различные тарифные схемы.
Пример - Дороги общего пользования, мосты и отдельные участки дорог.
3.27 транспортный сервис (transport service): Сервис, используемый транспортным средством, находящийся под ответственностью оператора сбора платы за проезд.
3.28 объект доверия (trust object): Информационный объект, которым обмениваются участники сбора платы за проезд для подтверждения подлинности.
Пример - Электронная подпись или электронный сертификат.
3.29 пользователь (user): Покупатель или потенциальный покупатель платных услуг, владелец транспортного средства, водитель и т.д.
Примечание - Понятие «пользователь» является общим обозначением, которое зависит от контекста.
4 Сокращения и символы
4.1 Сокращения
В настоящем стандарте применяются следующие сокращения:
CE — центральное оборудование (Central Equipment);
CRM — управление отношениями заказчика (Customer Relationship Management);
DSRC — специализированная связь на коротких расстояниях (Dedicated Short-Range Communication);
EETS — европейская система электронной оплаты (European Electronic Toll System);
EFC — электронный сбор платы за проезд (Electronic Fee Collection);
GNSS — глобальные спутниковые навигационные системы (Global Navigation Satellite Systems);
ID — идентификационные данные (Identity);
IFMSA — архитектура системы обеспечения совместимости (Interoperable Fare Management System Architecture);
OBU — бортовое оборудование (On-board Unit);
ODP — открытый процесс распределения (Open Distributed Processing);
RSE — оборудование дорожной архитектуры (Roadside Equipment);
SLA — соглашения об уровне обслуживания (Service Level Agreements);
TMS — система управления дорожным движением (Traffic Management System);
TTP — третья доверительная сторона (Trusted Third Party);
UML — унифицированный язык моделирования (Unified Modelling Language).
4.2 Символы
В настоящем стандарте на рисунках используются следующие условные обозначения:
- прямоугольник со скругленными углами обозначает задачи и соответствующую деятельность субъектов;
- горизонтальные стрелки показывают информационный обмен между субъектами, действия, проводимые в рамках задач;
- вертикальные стрелки показывают шаги выполнения в рамках той или иной деятельности;
- закрашенные круги обозначают начало диаграммы действий;
- частично закрашенные круги обозначают окончание диаграммы действий;
- полностью закрашенный прямоугольник означает принятие решения.
5 Состав системы электронного сбора платы (EFC): цели и задачи
5.1 Общие положения
a) набор всех объектов, установленных для осуществления различных сопутствующих задач;
b) специальное оборудование системы сбора платы за проезд;
c) бортовые системы сбора платы за проезд.
Внешними объектами являются объекты, включенные в состав системы сбора платы за проезд, но непосредственно не выполняющие задачи сбора платы за проезд, например спутниковые системы позиционирования и органы по стандартизации.
Множество систем сбора платежей представлено в виде среды и взаимодействующих с ней объектов, которые вместе играют роль платформы, построенной с целью сбора электронных платежей с ТС. Платформа по сбору платежей представляет собой объекты предпринимательской деятельности во всем их множестве, которые рассматриваются с точки зрения их ролей в общей политике системы. Данные объекты предпринимательской деятельности вовлечены в процесс сбора платы за проезд.
На рисунке 1 показаны внешние объекты предпринимательской деятельности и их взаимодействие, определяющие среду настоящего стандарта. Показанные объекты являются главными объектами, несмотря на то что могут быть и другие, напрямую или косвенно включенные в систему сбора платы за проезд. Также могут существовать интерфейсы между средой оператора и другими подсистемами интеллектуальной транспортной системы (далее — ИТС), например транспортными информационными системами.
Рисунок 1 — Объекты предпринимательской
деятельности в составе EFC
Линии между объектами обозначают главные взаимодействия между объектами предпринимательской деятельности. В то время как интерфейсы в среде оператора являются внутренними интерфейсами, интерфейсы между средой оператора и другими объектами в составе EFC являются внешними интерфейсами.
5.2 Среда оператора системы сбора платы
Роль среды оператора заключается в электронном сборе денежных средств при обеспечении безопасности процесса без остановки ТС в пункте сбора.
5.3 Внешние объекты
5.3.1 Финансовые системы, например банки и информационные центры
Финансовые системы должны обеспечить финансовые услуги, которых требует среда оператора. Данные службы главным образом будут представлять собой трансфер денежных средств между объектами в среде оператора, включая пользователей. Важно отметить, что среда оператора обрабатывает данные, в то время как финансовая система обрабатывает платежную информацию («деньги»). Взаимодействия между средой оператора и финансовой системой основываются на основе заключенных между ними договоров.
Настоящий национальный стандарт делает строгое различие между финансовым доменом, поддерживающим среду оператора, и доменом сбора платы за проезд в самой среде оператора. Настоящий национальный стандарт включает требования только к домену сбора платы за проезд.
5.3.2 Телекоммуникационные системы
Телекоммуникационные системы должны предоставлять телекоммуникационные услуги, которых требует среда оператора.
Пример - Кабельная сеть для передачи данных между средой оператора и сетью беспроводной связи для передачи данных между оборудованием системы сбора платы и бортовыми устройствами.
Взаимодействия между средой оператора и телекоммуникационной системой основываются на основе заключенных между ними договоров.
5.3.3 Системы позиционирования
Системы позиционирования должны предоставить услуги по определению месторасположения ТС, подвергающихся процедуре сбора денежных средств.
<1> В Российской Федерации применяется отечественная глобальная навигационная спутниковая система (ГЛОНАСС).
Также может использоваться инфраструктура DSRC для позиционирования ТС, но в этом случае она будет частью среды оператора, поскольку не выполняет других задач вне системы сбора платы. Взаимодействия между средой оператора и системой позиционирования основываются на заключенных между ними договорах.
5.3.4 Датчики транспортных средств и базы данных
Среда оператора может использовать информацию от датчиков ТС и баз данных, интегрированных в ТС, основные цели которых не связаны с EFC. Информация, получаемая от датчиков и баз данных, используется для вычисления информации, связанной со сбором платы. Например, датчики GNSS (например, в устройствах, используемых для навигации и управления дорожным движением), тахографы, метки, датчики остановки, а также информация, хранящаяся в модуле безопасности ТС. Базы данных могут быть размещены в ТС или в другом месте, например, компьютер, установленный на платном участке улично-дорожной сети.
5.3.5 Внешние датчики и другие интеллектуальные транспортные системы
Среда оператора может использовать данные от внешних датчиков, например измерения загрязнения, для вычисления стоимости сбора. Данные от других ИТС, например системы организации дорожного движения, могут также использоваться для вычисления стоимости сбора. Динамическая схема сборов платы за проезд может, например, использовать и измерения загрязнения от экологических датчиков и данные на потоках трафика и скоростях от систем управления дорожным движением.
5.3.6 Поставщики оборудования EFC
Поставщики оборудования EFC должны обеспечить оборудование EFC для среды оператора, например бортовые устройства или оборудование дорожной инфраструктуры. Взаимодействия между поставщиками оборудования EFC и средой оператора основываются на контрактах между ними. Основная роль среды оператора — обеспечить системные требования, в то время как основная роль поставщиков оборудования EFC — предоставить оборудование в соответствии с предъявляемыми требованиями.
5.3.7 Органы по сертификации
Органы по сертификации должны сертифицировать объекты в среде оператора. Сертификация может охватывать требования как к оборудованию, так и к функциям и ролям элементов в среде оператора.
Сертификация ролей является очень важной в условиях множества различных операторов.
5.3.8 Органы стандартизации
Органы стандартизации должны обеспечить разработку стандартов EFC и других стандартов или спецификаций, необходимых для среды оператора. Существует взаимодействие среды оператора с объектом стандартизации EFC, которое обеспечивает сбор информации для разработки проектов стандартов.
5.3.9 Органы государственной власти
Органы государственной власти должны определять законодательную основу, в рамках которой должна работать среда оператора. Законодательная основа определяется органами государственной власти, составляющими законы и постановления, мандаты, ограничения и требования. Различные государственные структуры определяют различные полномочия:
- Дорог и транспортного управления, например Министерство транспорта, которое может определять требования к типам, доступности, надежности и качеству транспортной службы для сбора платы. Органы государственной власти в данной сфере в сотрудничестве с финансовыми структурами могут также определять политику тарификации на платных участках улично-дорожной сети, политику структуры и иерархии объектов предпринимательской деятельности EFC, а также законодательной основы. Например, определение оснований для заключения договоров между субъектом, издавшим соглашение EFC, и оператором системы сбора платы за проезд.
- Телекоммуникационного обеспечения. Данные органы государственной власти могут определять политику использования телекоммуникационных систем, например частоты беспроводных стандартов связи.
- Органы государственной власти в финансовой сфере могут определять политику среды оператора и финансовой среды, например, является ли сбор налогом или платой. Они могут также определить применимые типы платежных средств между средой оператора системы и финансовой системой.
- Органы государственной власти в сфере защиты данных могут определять политику безопасности и конфиденциальности в среде оператора системы сбора платы за проезд.
- Органы по сертификации могут выпускать открытые сертификаты.
Взаимодействие с органами государственной власти также обеспечивает доступ к дополнительной информации, например к регистрационным номерам ТС.
6 Роли в среде оператора системы сбора платы за проезд
6.1 Общие положения
Поскольку роль является совокупностью ответственностей в отношении определенных задач или функций, настоящий национальный стандарт описывает различные роли в среде оператора системы сбора платы за проезд как определенные совокупности ответственностей в области применения EFC. Роли описываются в общих чертах, как наборы обязанностей, где каждый набор включает обязанности для каждого субъекта. Данные роли подразделяют на:
- роль использования сервиса сбора платы;
- роль управления среды оператора системы сбора платы. Обязанностью является обеспечение совместимости различных платных участков улично-дорожной сети и субъектов системы сбора платы.
Общая картина основных задач субъектов среды оператора системы сбора платы и их взаимодействие представлены на рисунке 2. Двухсторонние стрелки между ролями предназначаются для указания на наборы взаимодействий. Стрелки взаимодействия к/от роли управления являются информационными потоками управления, в то время как взаимодействия между тремя другими ролями являются операционными информационными потоками эксплуатационной роли системы сбора платы, т.е. информационными потоками, присутствующими во время ежедневной работы.
Рисунок 2 — Роли субъектов среды оператора системы сбора платы
Необходимо отметить, что настоящий национальный стандарт не указывает все возможные роли и их особенности и обязанности. Предъявление требований к обязанностям конкретных ролей субъектов является задачей базовых стандартов, основывающихся на описанной в настоящем стандарте архитектуре.
6.2 Роль обеспечения сервиса сбора платы
Роль обеспечения сервиса сбора платы заключается в обеспечении EFC систем оборудованием, механизмами, разработке организационной структуры, и инструментами передачи информации, необходимых для функционирования системы EFC.
- поставка бортового оборудования;
- гарантия оплаты труда;
- разработка режима оплаты пользователями или принятие уже существующего;
- сбор денежных средств с участников соглашения с EFC;
- управление взаимоотношениями с клиентами по вопросам информации, требований, помощи клиентам, ошибок систем и финансов;
- контроль политики безопасности и конфиденциальности;
- текущий контроль качества в соответствии с требованиями SLA;
- документооборот, включая:
- предложение проектов соглашений с определенными условиями заинтересованным пользователям и заключение соглашений;
- обеспечение и управление контрактами EFC;
- ведение отчетной документации:
- включая контроль безопасности передаваемой информации;
- обеспечение единой системы данных:
- включая обеспечение совместимости данных, полученных от внешних информационных систем;
- настройка OBE:
- включая настройку OBE в безопасном режиме;
- эксплуатация бортовых устройств:
- включая поддерживание функциональности бортовых устройств.
6.3 Роль использования сервиса сбора платы
Транспортный сервис связан с использованием или присутствием ТС на платных участках улично-дорожной сети. Платный участок может охватить дорожную сеть, определенный участок дороги (например, мост, туннель или паромное сообщение) или определенную область, предлагающую услугу (например, автостоянка или доступ к защищенной области в городе). Это может также быть любая служба, связанная с использованием ТС в транспортной системе, например бензозаправочная станция, позволяющая водителю расплатиться с помощью EFC.
Роль определяется из условий использования платных участков улично-дорожной сети. Внедрение системы сбора платы за проезд на различных участках улично-дорожной сети определяет субъекты, к которым относятся водитель, пользователь и заказчик.
Данная роль включает в себя следующие обязанности:
- следование до пункта оплаты:
- использование бортового оборудования для выполнения операций оплаты;
- взаимодействие с бортовым оборудованием;
- поведение согласно правилам определенной системы оплаты, например выполнение предписаний дорожных знаков;
- владение или работа ТС, включая:
- соблюдение платного режима для платного участка улично-дорожной сети;
- заключение соглашений с поставщиком платных услуг;
- заключение соглашений с издателем договоров EFC и выполнение обязательств по использованию системы сбора платы;
- приобретение бортового оборудования;
- установку и утилизацию бортового оборудования;
- завершение договорных отношений с поставщиком платных услуг;
- формирование требований;
- сбор денежных средств;
- хранение и защиту данных соглашений и платежных средств, например соглашения поставщика услуг для разрешения проблем, связанных с договорными отношениями;
- взаимодействие с CRM поставщика услуг для разъяснения спорных вопросов договорными отношениями.
6.4 Роль эксплуатации системы сбора платы
Роль эксплуатации системы сбора платы включает всех участников, кто определяет платный режим, управляет системой сбора платы за проезд и может предоставить транспортные услуги. Роль включает дорожную инфраструктуру и аппарат управления системы сбора платы за проезд. Правоохранительные органы также осуществляют эти функции.
Роль эксплуатации системы сбора платы включает в себя следующие обязанности:
- основное поддержание, включая:
- предоставление транспортной услуги, например доступа к дорожной сети, автостоянке или паромному сообщению;
- определение принципов взимания платы, например принципов тарификации для платной дороги или зоны;
- расчет сбора, включая:
- передачу отчетов о проведении платежной операции пользователю системы;
- передачу данных в безопасном режиме между участниками и бортовым оборудованием;
- формирование данных EFC, включая:
- информирование водителя ТС о доступности EFC, например, через знаки и сообщения или непосредственно через OBE;
- взаимодействие с движущимися ТС, включая ситуации, когда ТС не оборудовано электронными средствами взаимодействия:
- обеспечение, если возможно, географическими деталями платного участка с целью автоматизации системы. Этот процесс также известен как уточнение геопозиции;
- обнаружение ТС;
- сбор характеристик ТС, включая тип ТС. Информация может собираться непосредственно с бортового оборудования или с датчиков и баз данных дорожной инфраструктуры;
- передача данных с бортовым оборудованием ТС;
- принятие сервисных правил, хранящихся в базе данных бортовых устройств;
- сбор информации, позволяющей идентифицировать ТС, например распознаванием регистрационного знака. Роль осуществляется без использования бортового оборудования;
- управление взиманием штрафов, включая:
- обнаружение, запись и обработку фактов прохождения ТС (включая противодействие попыткам мошенничества);
- защита прав на конфиденциальность при взимании штрафов;
- защита конфиденциальности и безопасности.
6.5 Роль управления среды оператора системы сбора платы
Существует также потребность в управлении всей системой сбора платы, организующей ежедневный сбор платы.
К обязанностям этой роли относятся:
- устанавливание правил, включая:
- организацию безопасности и политики конфиденциальности для системы EFC;
- разработку и поддерживание схем ID для того, чтобы генерировать уникальные идентификаторы для приложений EFC и сообщений;
- сертификация составляющих EFC, включая:
- определение требований сертификации для участников и оборудования, используемых в системе EFC;
- разрешение споров, включая:
- определение операционных процедур среди операторов;
- управление спорами среди операторов.
6.6 Структуризация среды оператора системы сбора платы
6.6.1 Общие положения
Настоящий национальный стандарт описывает, как роли, описанные в пунктах 6.1 - 6.5, распределены по четырем различным типам доменов в среде оператора системы сбора платы:
a) домен поставщика платных услуг покрывает все роли, описанные в 6.2.
b) пользовательский домен покрывает все роли, описанные в 6.3.
c) домен оператора системы сбора платы покрывает все роли, описанные в 6.4.
d) домен среды оператора системы сбора платы покрывает все роли, описанные в 6.5.
Каждый домен может быть описан объектами на следующих трех уровнях:
e) организационный уровень, где различные объекты описывают агентов, присвоенных различным ролям в том домене;
f) уровень оборудования, где объекты описывают технические элементы, например бортовое оборудование, используемое агентами для выполнения их ролей;
g) уровень транспортной службы, где объекты описывают тип связанных с ТС услуг, предложенных в домене.
6.6.2 Домен поставщика платных услуг
6.6.2.1 Общие положения
Этот подпункт определяет объекты, включенные в состав роли обеспечения системы сбора платы (см. рисунок 3, примечание). Доменом поставщика платных услуг управляет поставщик платных услуг.
Рисунок 3 — Домен поставщика платных услуг
Примечание — Автомобили не принадлежат к сфере поставщика услуг.
6.6.2.2 Организационный уровень
Поставщик платных услуг является юридическим лицом, предоставляющим клиентам (пользователям) услуги в одной или нескольких сферах (см. 6.6.4) для одного или более классов автомобилей. Платный сервис является сервисом, предполагающим одно соглашение для нескольких платных сфер, а также один комплект оборудования в автомобиле.
Поставщик платных услуг может купить сервисы у других юридических лиц и/или организаций, предоставляя услуги от их имени. Эти организации часто имеют названия, отражающие ответственность, которую они взяли на себя, например провайдер OBE и провайдер контракта. Однако любое различие между поставщиком платных услуг и объектами, действующими от их имени, за пределами контекста настоящего стандарта.
Поставщик платных услуг может также действовать как организация по взиманию платы для одной или более платных сфер.
Поставщик платных услуг управляет OBE и ответственен за его работу (функционирование).
1 OBE не должен включать платежные средства.
2 Поставщик платных услуг может поставлять OBE или только магнитную карту, или смарт-карту, которая будет использоваться с OBE, поставленным третьей стороной (также как мобильный телефон, SIM-карта может быть получена из различных операторов сотовой связи).
6.6.2.3 Уровень оборудования
Стационарное оборудование, используемое поставщиком платных услуг для того, чтобы предоставить платные услуги, называют центральным оборудованием (Central equipment — CE, см. рисунок 4). CE может быть разделено на различные типы оборудования в зависимости от предусмотренных в организационном уровне поставщика платных услуг ролей.
Рисунок 4 — Бортовые устройства и внешние датчики
OBE устанавливается и обслуживается поставщиком платных услуг.
OBE может быть соединено с одним или более внешними датчиками, например с датчиком GNSS, тахографом, одометром, и др.
6.6.2.4 Уровень транспортных сервисов
OBE может быть подключен с определенным автомобилем (имеющим определенные атрибуты), который используется на уровне транспортной службы. Автомобиль может использоваться в одной или нескольких сферах, предусмотренных контрактом EFC.
6.6.3 Домен пользователя
6.6.3.1 Общие положения
Этот подпункт определяет объекты, включая взимание платы и уровень транспортных сервисов (рисунок 5).
Рисунок 5 — Пользовательский домен
6.6.3.2 Организационный уровень
«Покупатель» является клиентом службы поставки платных услуг (рисунок 5).
Лицо, обязанное произвести оплату, обязано произвести оплату в соответствии с местными законами и правилами.
Пример — Водитель, владелец автомобиля или коммерческая фирма перевозок могут совместно или раздельно нести ответственность по оплате.
1 Выбор способа оплаты является частным вопросом. Это должно упростить осуществление оплаты, но выходит за рамки настоящего национального стандарта.
2 Клиент может, но не обязан отвечать за платеж сбора согласно правилам оплаты. Водитель является тем, кто управляет автомобилем, для которого рассчитывается сбор.
Предполагается, что водитель настраивает OBE (например, устанавливает параметры, такие, как число осей).
6.6.3.3 Уровень оборудования
Внешнее оборудование, используемое клиентом для оплаты, также называют CE, например CE менеджера автопарка предприятия, имеющего несколько контрактов EFC. Бортовое оборудование является частью обязанностей по предоставлению услуг.
6.6.3.4 Уровень транспортного обслуживания
Транспортное средство находится под управлением водителя и, таким образом, является частью домена водителя.
6.6.4 Домен оператора
6.6.4.1 Общее
Этот подпункт определяет объекты, задействованные в выполнении роли операторов (рисунок 6).
Рисунок 6 — Домен оператора взимания платы
6.6.4.2 Организационный уровень
Оператор взимания платы — юридическое лицо, ответственное за сбор платежей в одном или более доменах платежей, например, области (части) или дорожная сеть, где платежи собраны согласно некоторому режиму оплаты.
Оператор взимания платы может купить услуги других юридических лиц и/или организаций, работающих от их имени. Эти организации часто имеют названия, которые отражают ответственность, которую они взяли на себя, например оператор EFC и оператор применения.
Оператор взимания платы управляет доменом платежей, и для каждого домена платежей есть только один оператор, который им управляет.
1 Какое именно юридическое лицо будет действовать в качестве оператора в реальной ситуации, выходит за рамки данного международного стандарта. Это может быть, например, правительство, или это может быть делегировано концессионеру (например, оператор взимания платы). Настоящий национальный стандарт только предполагает, что для каждого домена платежей существует одно юридическое лицо, которое действует как оператор взимания платы.
2 Любые различия между оператором взимания платы и предприятиями, действующими от их имени, выходят за рамки данного национального стандарта. Например, операторы применения, которые действуют от имени оператора взимания платы, поэтому их не рассматривают отдельно (но можно рассмотреть отдельно в стандартах, рассматривающих проблемы более подробно).
6.6.4.3 Уровень оборудования
Внешнее оборудование и возможные другие устройства, используемые оператором сбора платы для сбора платежей с транспортных средств, называются системой сбора оператором платы.
1 Бортовое оборудование исключается из описания.
2 Внешнее оборудование считывается относительно транспортного средства, с которого взимается плата. Однако оно может включать в себя мобильное оборудование.
3 Фактическая оплата (сбор платежей) может располагаться вне системы сбора платежей.
В зависимости от местоположения оборудования система сбора платы может разделяться на:
- RSE, включая мобильное оборудование и оборудование, устанавливаемое над дорожным полотном или встроенное в него;
- CE, используемое в офисах.
Система сбора платежей может использовать данные от других внешних датчиков или систем расчета платы, например датчиков уровня загрязнения, скоростемеров и датчиков объема.
6.6.4.4 Уровень транспортного обслуживания
Домен платы — область или часть дорожной сети, где введен платный режим, могут быть предложены одна или более транспортных услуг. Платный режим состоит из ряда правил, включая правила применения, управляя сбором платежей в домене платы.
Примечание - В зависимости от платного режима домен платы может включать частные дороги, территории и инфраструктуру, расположенные вне дорог.
Домен платы может состоять из одного или более платных объектов (обеспечение транспортной службы), будучи отдельной частью домена платы, для которого применяются одна или более тарифных схем.
1 Платный объект может включать в себя, например, регион, все автомобильные дороги в регионе, мосты, зоны или участки дорог (сети дорог).
2 Для одного платного объекта может применяться как национальная, так и местная тарифная схема.
6.6.5 Домен управления средой оператора сбора платы
6.6.5.1 Общие положения
Этот подпункт определяет объекты, вовлеченные в выполнение управляющих ролей, задач, операций с оборудованием, сфер оплаты и совместимости (рисунок 7).
Рисунок 7 — Домен управляющего операторами сбора платы
6.6.5.2 Организационный уровень
Управляющая организация по сбору платежей является юридическим лицом, ответственным за управление средой сбора платежей относительно сотрудничества поставщиков услуг и организаций по непосредственному сбору платежей. Так же как существует ряд управляющих правил для междугородного домена, существует ряд управляющих правил для всех объектов в сфере сбора платежей. Управляющая организация по сбору платежей ответственна за жизненный цикл этих правил, принимая во внимание ограничения и требования от внешних объектов в сообществе EFC, а также ограничения и требования от поставщиков услуг, организаций по сбору платежей и пользователей. Управляющие правила охватывают коммерческие, функциональные и технические проблемы, необходимые для сотрудничества и функциональной совместимости.
Управляющая организация по сбору платежей может приобретать сервисы от других юридических лиц и/или организаций, работая от их имени. Эти организации часто именуются, отражая их ответственность, например объект сертификации, регистратор.
6.6.5.3 Уровень оборудования
Не существует специфического для конкретного поставщика платных услуг бортового оборудования или инфраструктурного оборудования, относящегося к конкретной среде.
6.6.5.4 Уровень транспортного обслуживания
7 Поведение системы электронного сбора платежей
7.1 Общее
Обязанности, связанные с ролями, подразумевают определенное поведение согласно разделу 6. Подробное описание всех поведений, которые протекают во внутренних пределах роли, выходит за рамки настоящего национального стандарта. Однако некоторые поведения могут подразумевать взаимодействия среди различных участников, которые играют роль, взяв на себя ответственность. В этих случаях могут быть привлечены независимые организации, которые могут нуждаться в стандартизированном наборе информационного взаимодействия. Эти поведения детализированы в настоящем пункте, в частности затронуто информационное взаимодействие.
7.2 Роли, обязанности и актеры
В разделе 6 определены обязанности ролей в архитектуре EFC. Эти обязанности могут выполняться многими участниками, которые могут играть одну роль частично/полностью либо более одной роли.
Как обозначено на рисунке 8, у управления, взимания платы и ролей эксплуатации и обеспечения есть различные обязанности, которые реализуются строго определенными субъектами. С другой стороны, для роли обеспечения системы один субъект может выполнять следующие обязанности, которые могут группироваться как принадлежащие основной роли обеспечения:
- управление финансовым процессом покупки — главная задача поставщика услуг. Оно охватывает процесс передачи прав использования прямо от оператора сбора платы пользователю при условии оплаты услуг пользователем. Это может быть осуществлено или посредством процесса покупки и перепродажи, когда сбор платежей — это частный платеж, или действием агента от имени пользователя, если сбор средств является налогом;
- управление выставлением счетов пользователям, включая выписку и отправку счета клиентам;
- обеспечение работы с клиентами с точки зрения пользователя — это ответственность держателя контракта и с частью основной роли обеспечения;
- держатель пользовательского контракта определяет юридически заверенную копию пользователя и обязательства обеих сторон;
- управление доверительными отношениями — фоновая задача создания и обмена объектами доверия, чтобы сделать возможным техническое обеспечение работы системы.
Рисунок 8 — Обязанности и их взаимосвязи
Оставшиеся обязанности роли обеспечения могут быть четко распределены тому же самому актеру, играющему основную роль обеспечения, или различным актерам (например, другие организации). Эти обязанности и их взаимодействие упомянуты в диаграммах взаимодействия в следующих разделах, чтобы облегчить условия на открытом рынке для актеров, выполняющих эти роли для более чем одного поставщика. Они включают в себя следующее:
- предоставление объявления о сборе средств. Эта ответственность, особенно в автономных системах EFC, включает в себя расписку платежных сообщений транспортных средствах;
- предоставление (не создание) данных о контексте EFC, за которые в некоторых случаях участник может нести ответственность, также играющего роль поставщика услуг. Это возможно, если форматы данных и процедуры загрузки используются, например, для оптимизации. Возможны также случаи, когда поставщики услуг действуют как поставщики данных о контексте EFC, когда, например, сочтено необходимым передать эту ответственность и сгруппировать ее с другими поставщиками услуг. В этом случае поставщики услуг должны договориться о стандартных форматах и интерфейсах, которые должны принять все участвующие стороны. В других случаях, когда используются стандартизированные форматы и процедуры загрузки, эта ответственность может быть принята актером, также играющим роль оператора, чтобы уменьшить рабочую нагрузку группы поставщиков услуг. Кроме этого, поставщики цифровых карт для автомобильных навигационных систем могут взять эту ответственность в качестве независимого третьего лица. В дорожных системах, основанных на инфраструктуре, эта ответственность, когда это применимо, сводится к обеспечению пограничного режима, чтобы позволить бортовому оборудованию указывать водителю на статус его бортового оборудования относительно данного режима сбора платежей прежде, чем дорожная инфраструктура произведет сбор средств;
- выступление в качестве контрактного агента можно рассматривать как отдельную ответственность, которая требуется, когда оперативные действия, связанные с новым клиентом и соглашением с ним на условия договора, произведены субъектом, специализированным на этой задаче. Такие специализированные субъекты могут быть автомобильными клубами или просто зонами отдыха на автомобильных дорогах, но только за пределами платной зоны. Также оператор может действовать как контрактный агент, если невзаимодействующие схемы EFC обеспечивают дальнейшее использование бортового оборудования для других режимов оплаты в соответствии с отдельным контрактом;
- настройка бортового оборудования является ответственностью, которая может быть возложена или на сторону, устанавливающую бортовое оборудование, или на предприятие, производящее и обслуживающее бортовое оборудование. Также оператор может повторно настроить бортовое оборудование, если невзаимодействующие схемы EFC обеспечивают дальнейшее использование бортового оборудования для других режимов оплаты в соответствии с отдельным контрактом;
- поддержка бортового оборудования включает в себя программное обеспечение и администрирование системы безопасности, контроль за достигнутым SLA не входит в рамки данного международного стандарта. Однако чтобы понять полное распределение действий с полученной общей функции, требуется выделить ответственность за обновления программного обеспечения. Это будет иметь принудительный характер, когда настройка бортового оборудования потребует изменений в программном обеспечении. Эта ответственность будет скорее всего возложена на актера, играющего роль обеспечения. Однако в будущих внедрениях эта ответственность может также быть возложена на автомобильную промышленность, если бортовое оборудование станет частью штатной электроники транспортного средства. Также оператор может выступать в роли поставщика услуг по поддержке оборудования, если невзаимодействующие схемы EFC обеспечивают дальнейшее использование бортового оборудования для других режимов оплаты в соответствии с отдельным контрактом;
- предоставление учетных записей выставления счетов включает передачу данных между поставщиком услуг и пользователем, которая реализована как взаимодействие водителя с бортовым оборудованием через его HMI (интерфейс человек — устройство). Так как это взаимодействие не будет стандартизировано в будущем, настоящий стандарт им не занимается и только ссылается здесь для полноты понимания.
1 Если операторы системы сбора платы вместе организовываются в кластере и все отношения с поставщиком услуг управляются кластером в отличие от ситуаций, когда операторы организовываются по отдельности, тогда с точки зрения каждого поставщика услуг кластер участвует в том же действии, которое предполагается от индивидуального оператора системы сбора платежей.
2 Если поставщики услуг вместе организовываются в кластер и все отношения с операторами системы сбора платежей управляются кластером в отличие от ситуаций, когда поставщики услуг организовываются по отдельности, тогда с точки зрения каждого оператора кластер участвует в том же действии, которое предполагается от индивидуального поставщика услуг.
Основная цель архитектуры заключается в выявлении тех поведений, которые приводят к взаимодействиям, которые должны быть стандартизированы, а именно:
- взаимодействия между различными обязанностями в рамках ролей, когда объекты, осуществляющие эти обязанности, могут быть разными (например, принадлежать отдельным организациям).
Необходимо учесть, что реальной системе сбора платы, реализующей эту архитектуру, не нужно реализовать все роли и обязанности, которые подробно представлены на рисунке 8. Реальная система сбора платы может осуществлять столько ролей и обязанностей, определенных в настоящем стандарте, сколько необходимо, при этом обязательным является то, что реализуемые взаимодействия между ролями и обменом информацией будут совместимыми с настоящим описанием, чтобы достичь совместимости между системами, принадлежащими к различным организациям, или реализациями различных поставщиков.
7.3 Матрицы и схемы взаимодействия
Таблица 1 объединяет в себе те сценарии, при реализации которых происходит взаимодействие между субъектами. Следующие пункты показывают схему взаимодействия для каждого из идентифицированных сценариев. Каждый выполняемый сценарий, обозначенный в первом столбце таблицы, может инициировать взаимодействие среди ролей, обозначенных в остальных столбцах. Для каждого действительного пересечения дана ссылка на пункт, содержащий схему их взаимодействия.
Взаимодействия и задействованные роли
| Обеспечение | |||||||||||
| Управление | Пользователь | Агент | Основной поставщик | Поставщик системы сбора платы | Поставщик EFC окружения | Настройка бортового оборудования | Настройка используемой информации | Обслуживание бортового оборудования | Оператор | ||
| Добавление новых операторов 7.1.3 + | |||||||||||
| - | - | + | - | - | - | - | - | + | Добавление новых провайдеров | 7.3.2 | + |
| - | - | + | - | - | - | - | - | + | Добавление или модификация режима взимания платы | 7.3.3 | + |
| + | - | + | - | + | + | - | - | + | Определение правил и контроль операций | 7.3.4 | + |
| - | - | + | - | - | - | - | - | + | Взаимодействие субъектов при привлечении новых пользователей EFC | 7.3.5 | - |
| + | + | + | - | - | + | - | + | - | Сбор информации об оплате — тарификация оплаты пользователя | 7.3.6 | - |
| + | + | + | - | - | - | - | - | + | Сбор транзитной информации (система DSRC) | 7.3.7 | - |
| + | - | - | - | - | - | - | - | + | Сбор информации об оплате (автономные системы) | 7.3.8 | - |
| + | - | + | + | + | - | - | - | + | Утверждение платежей | 7.3.9 | + |
| - | - | + | - | - | - | - | - | - | Обеспечение работы с клиентами | 7.3.10 | - |
| + | - | + | - | - | - | - | - | - | Обнаружение исключений | 7.3.11 | - |
| + | - | - | - | - | - | - | - | + | Каждая схема фокусируется на информационных обменах между сценариями. Это означает, что детали выполнения действий, только включающих действия в сценариях, не показаны, за исключением целей разъяснения, и при этом они не подвергаются стандартизации. | В каждой схеме ячейки с закругленными углами указывают на обязанности или действия. Названия в этих полях могут немного отличаться от названий на рисунке 8, чтобы лучше указывать на тип выполняемого действия. Стрелки в схемах показывают направление информационных потоков от инициатора информационного обмена к информационному получателю. Маркировка стрелок указывает на информационные объекты, которые обмениваются данными. | |
Логические схемы представлены для того, чтобы определить, когда поведение может быть объектом принятия решения. Данные логические элементы указывают на существование нескольких возможных способов продолжения обработки информации или данный процесс останавливается. Однако на данных схемах представлены не все возможные варианты продолжения; это упрощение сделано в целях избежания сверхспецификации. Данные схемы предназначены для наглядного показа процесса взаимодействия и обмена информацией между субъектами.
В то же время процесс в целом не зависит от технологии сбора платы; существует ограниченный набор случаев, где это не истинно. Действия, проведение которых зависит от технологии сбора платы, строго идентифицированы и описаны в отдельных пунктах.
7.3.1 Добавление новых операторов
Добавление хотя бы одного оператора является подготовительным условием для начала нового эксплуатационного процесса. Далее оператор запрашивает инициализацию на получение сертификата у управляющего органа. Если сертификацию предоставляют, она должна быть передана всем поставщикам, чтобы начать согласовывать двусторонние соглашения по общим операциям. На рисунке 9 показана схема взаимодействия данных субъектов.
Рисунок 9 — Добавление новых операторов
В случае исключения оператора схема взаимодействия будет следовать той же логической последовательности.
7.3.2 Добавление новых провайдеров
Добавление хотя бы одного провайдера является подготовительным условием для начала нового эксплуатационного процесса. Далее оператор просит инициализацию на получение сертификата у управляющего органа. Если сертификацию предоставляют, она передается всем поставщикам, чтобы начать согласовывать двусторонние соглашения по общим операциям (рисунок 10).
Рисунок 10 — Добавление новых провайдеров
В случае исключения провайдера схема взаимодействия будет следовать той же логической последовательности.
7.3.3 Добавление или модификация режима взимания платы
Добавление хотя бы одной модификации режима взимания платы является подготовительным условием для начала нового эксплуатационного процесса. Добавление такой модификации инициируется оператором и сообщается субъекту управления, с целью получения разрешения на запуск новой системы EFC. Субъект управления включает новые режимы в список участвующих схем EFC и сообщает всем провайдерам, предоставляющим данные услуги. Если новые режимы будут добавлены согласно основным договорным соглашениям между пользователем и поставщиком, то агент, настраивая бортовое оборудование, имеет право подключать новые сервисы к бортовому оборудованию пользователя. Если данные условия обеспечены, бортовое оборудование готово работать согласно новой схеме EFC.
Рисунок 11 иллюстрирует диаграмму действий.
Рисунок 11 — Добавление или модификация
режима взимания платы
Следует обратить внимание на то, что на рисунке изображены некоторые действия, которые совершаются внутри роли и соответствующих обменов информации. Это происходит потому, что такие действия могут быть воспроизведены различными субъектами, так что соответствующий обмен информацией может нуждаться в стандартизации.
Закрывая ранее включенную оплату, режим будет следовать той же логической последовательности, начиная с запроса актера оплаты.
7.3.4 Определение правил и контроль операций
Основной ролью управления является определение правил для EFC сообщества, чтобы распределить их поставщиков и операторов и для того, чтобы осуществлять мониторинг работы EFC системы. На рисунках 12 и 13 показаны схемы взаимодействия управления, поставщиков и операторов. Прогнозирующий субъект соответствует базовым требованиям прогнозирования.
Рисунок 12 — Определение правил
Рисунок 13 — Мониторинг операций
7.3.5 Взаимодействие субъектов при привлечении новых пользователей EFC
Для подписания нового контракта EFC требуется, чтобы поставщик определил его условия, предложил необходимые для будущего пользователя услуги и обеспечил его всей необходимой информацией. Пользователь должен будет связаться с объектом прогнозирования, который проверит, соблюдает ли пользователь условия, на которых будет подписан контракт. При соблюдении всех условий пользователю производится установка и настройка бортового оборудования. В дальнейшем в бортовое оборудование загружают необходимое программное обеспечение, после чего оно будет готово к работе (рисунок 14).
Рисунок 14 — Схема взаимодействия при подписании
нового пользователя EFC сообщества
Из представленной выше схемы виден обмен информацией и порядок действий между субъектами, взаимодействующими в ходе проведения данной работы. Это необходимо для стандартизации действий между субъектами и увеличения скорости и эффективности проводимой работы.
В случае если пользователь отказывается от услуг, предоставляемых EFC сервисами, то порядок отмены контракта происходит в схожей последовательности.
7.3.6 Сбор информации об оплате — тарификация оплаты пользователя
Сбор данных об оплате производится путем последовательной серии взаимодействий между поставщиком и пользователем. Также данные взаимодействия могут включать в себя обмен данными между поставщиком и оператором системы сбора платы в тех случаях, когда пользователь отказывается оплачивать оговоренную сумму или бортовое оборудование пользователя внесено в «черный список». Данная информация необходима для обнаружения недоброкачественных пользователей, а также предостережения других представителей поставщика от подписания с ними новых контрактов. Описанная выше схема взаимодействия показана на рисунке 15.
Рисунок 15 — Сбор информации об оплате -
тарификация оплаты пользователя
7.3.7 Сбор транзитной информации (система DSRC)
Взимание транзитной информации выполняется оператором различными способами, которые могут как включать, так и не включать взаимодействие с пользователем.
На рисунке 16 показана схема взаимодействия между оператором и поставщиком в DSRC системе. На данном рисунке показан общий случай, а именно обмен взаимно индикационной информацией.
Рисунок 16 — Сбор транзитной информации (система DSRC)
7.3.8 Сбор информации об оплате (автономные системы)
Основной ролью бортового оборудования является сбор информации об оплате. Бортовое оборудование получает данные из окружения EFC от источника данных (при необходимости) и работает согласно местному законодательству. При распознавании объекта оплаты данные о нем передаются агенту, составляющему декларации об оплате при помощи окружения EFC.
Основной задачей агента является приравнять полученные данные к действующей тарификации и передать их основному оператору. Детали тарификации зависят от соглашений, заключенных между поставщиком и оператором. В некоторых случаях поставщик может самостоятельно проверять кредитную историю своих пользователей и с помощью оператора оповещает об этом через бортовое оборудование. В случае банкротства пользователя он может быть помещен в «черный список», вследствие чего соответствующая информация будет передана посредством списка исключения. На рисунке 17 показана соответствующая схема взаимодействия.
Рисунок 17 — Диаграмма действий: сбор информации
для проведения платежа (автономные системы)
7.3.9 Инструментарий разрешения претензий
На рисунке 18 представлена диаграмма действий инструментов взыскания. Среди вовлеченных субъектов отмечены субъект взимания платы и деклараций услуг оплаты. Сторона, выступающая в роли поставщика услуг, играет роль, выполняющую базовые требования по предоставлению услуг. Если одна из сторон предъявляет претензию другой стороне в том, что эта сторона не выполняет обязательства, указанные в сертификате, то управление будет призвано для разрешения такого рода конфликта.
Рисунок 18 — Инструментарий разрешения претензий
7.3.10 Предоставление заботы о пользователях
Взаимодействие с целью заботы о пользователях включает все запросы для получения помощи, претензии пользователям к поставщикам. Сторона, играющая роль поставщика, выполняет базовые требования по предоставлению. На рисунке 19 показана соответствующая диаграмма действия.
Рисунок 19 — Поддержка пользователей системы
Информация, переданная пользователем к поставщику, включает все типы запросов и претензий, включая те, которые впоследствии взаимодействуют с другими субъектами. Примерами этих последних событий являются отчеты относительно украденного или потерянного бортового оборудования, которые могут вынудить поставщика передать остальным субъектам списки исключений, чтобы заблокировать бортовое оборудование, которое утратило допуск.
7.3.11 Обнаружение исключений — пользователь и проверка соответствия OBE
Обнаружение исключений является взаимодействием между пользователем и службой взимания платежей, инициирующимся, когда устройство пользователя распознает объект взимания платежей. Различные действия могут быть выполнены устройством взимания платы для обнаружения исключений, включающих в себя сбор собственных данных (например, от датчиков) или взаимодействие с пользовательским OBE для получения данных. На рисунке 20 показана схема, где выполняются оба действия.
Рисунок 20 — Обнаружение исключений
7.4 Результирующее взаимодействие между субъектами
Схемы действия, представленные на рисунках в предыдущих пунктах, позволяют получать взаимодействия, показанные в таблице 2. В таблице 2 отмечены все соответствующие объекты обменов информацией. Взаимодействия в таблице 2 отдельно идентифицированы для обоих направлений. В некоторых случаях информационный обмен может включать несколько транзакций. Стандарты, полученные из этой архитектуры, могут определить детали элементов данных, включенных в эти транзакции, а также протоколы связи, передающие информацию.
8 Информационная схема и базовые информационные типы
8.1 Статическая схема
В следующей таблице сведена информация, которой обмениваются главные субъекты взимания платы, как это поясняется на рисунке 21. Объекты обмена в общем случае представляют собой классы объектов, которые должны быть описаны в специальных стандартах. Другие виды обмена информацией (например, для пресечения нарушений) не представлены в этом пункте.
Рисунок 21 — Обнаружение исключений
Для каждого допустимого пересечения обозначаются названия классов информации, которыми обмениваются субъекты. Нужно отметить, что тот же класс, которым обмениваются субъекты, не обязательно представляет идентичный физический информационный обмен, например «транзитная информация», которая обменивается между пользователем и устройством сбора оплаты, принадлежит тому же классу «транзитной информации», которая обменивается между устройством сбора оплаты и поставщиком услуг несмотря на то, что фактические данные подтверждения могут отличаться (например, еще более подробные, чем другие). Информационные классы и их специализации описаны ниже по тексту настоящего национального стандарта.
Статическая схема, представленная в таблице 3, представлена и на рисунке (рисунок 21).
Соответствующие информационные объекты, которыми должны обменяться субъекты, идентифицированы в следующих пунктах.
8.2 Объекты основной информации
Среди ролей происходит обмен информацией в области классов объектов, которые представляют обобщения и абстракции реального обмена информацией.
С точки зрения обмененных информационных объектов, которые являются единственными информационными объектами в рамках настоящего национального стандарта, идентифицированы четыре основных класса:
a) Правила EFC, как класс, содержащий полномочия и обязательства для ролей в системе EFC, а также условия платежа и идентификатор пользователя. Данный информационный класс включает договорные данные между пользователем и провайдером, но не ограничивается ими.
b) Транзитная информация, как класс, представляющий все информационные объекты, важные для междугородного вычисления.
c) Операционная информация, как класс, представляющий все информационные объекты, важные для управления системой EFC.
d) Платежная информация, как класс, представляющий все информационные объекты, важные для передачи финансовых данных.
8.2.1 Правила EFC
Ассоциация среди различных ролей системы EFC выражена как правила EFC, удовлетворяющие требованиям и целям, определенным в спецификации предприятия. В правилах EFC установлены правила для преобразований информации, включая информационные обмены. EFC определяет не только объекты, являющиеся релевантной информацией в системе EFC, но также и правила для того, чтобы управлять ими. Поскольку могут быть предусмотрены различные типы правил, атрибут ассоциации фактически является классом, представляющим все возможные наборы. Рисунок 22 иллюстрирует понятие ассоциации, которое фактически является одним типом корреспонденции между информационными спецификациями.
- четырехсторонняя ассоциация; 
- атрибуты ассоциации
Рисунок 22 — Обнаружение исключений
Правила EFC также определяют инвариантную схему в системе EFC, т.е. информацию, не изменяющуюся во время работы системы. При функционировании системы это промежуток времени, в течение которого данному пользователю, с данным контрактом, разрешают использовать данную систему EFC. Если различные ряды правил доступны между пользователями и провайдерами, много различных инвариантных схем можно рассмотреть для той же реальной системы.
Информационные объекты в EFC правилах классов
8.2.2 Транзитная информация
Объекты в транзитной информации представлены в таблице 5.
Информационные объекты в классе транзитной информации
8.2.3 Операционная информация
Объекты операционной информации представлены в таблице 6.
Информационные объекты в операционной информации
8.2.4 Платежная информация
Объекты в классе платежной информации представлены в таблице 7.
Объекты в классе платежной информации
8.3 Динамическая схема
Информационные объекты, идентифицированные ранее как не инвариантные (т.е. не перечисленные в таблице 4), могут варьироваться своевременно согласно выполняющимся операциям. Динамическая схема для идентифицированных информационных объектов имеет два аспекта. Во-первых, оказываемый на объект эффект и, во-вторых, условия, при которых могут быть вызваны операции. Таблица 8 синтезирует динамическую схему для EFC. Более усовершенствованные и формальные описания содержатся в других стандартах на информационный обмен.
9 Интерфейсы и вычислительные объекты
9.1 Общие положения
С вычислительной точки зрения система EFC представляет собой набор интерфейсов, предоставляющих доступ к службам вычислительных объектов, входящий в эту систему. Настоящий раздел описывает субъекты, приведенные в разделе 7, как вычислительные объекты и их интерфейсы, независимо от того, какое количество вычислительных объектов (приложения) содержит агент при его реализации в реальной системе. Некоторые интерфейсы, приведенные в настоящем разделе, не являются обязательными к применению в реальных информационных системах, но описаны для полноты картины. Кроме того, в настоящем разделе интерфейсы изложены только в общих чертах с целью описания их функционала. Количество параметров, наименование и синтаксис интерфейсов в реальных системах могут отличаться от описанных в настоящем разделе. Также в данном пункте предъявляются возможные требования к функциям защиты данных для каждого интерфейса и каждому типу данных. При этом данные требования к защите зависят от политики безопасности, определяемой ролью «управления» или двусторонним соглашением обоюдного пользования системой, поэтому в настоящем разделе только приведены рекомендации того, какой объект может быть субъектом какой-то функции безопасности, или какая политика безопасности может быть описана каким-то типом взаимодействия.
Более полное описание архитектуры безопасности в системах сбора платы должно быть представлено в соответствующем национальном стандарте.
Функции обеспечения безопасности
9.2 Интерфейсы объекта управления
9.2.1 Общие положения
Объект управления содержит два интерфейса со следующими объектами:
- распределять общее описание системы EFC;
- распределять правила EFC;
- принимать и предоставлять сертификат на управление;
- принимать отчет о функционировании;
Помимо этого интерфейс с объектом оплаты должен принимать новые EFC-схемы.
9.2.2 Требования к безопасности
Функции безопасности представлены в таблице 10. Они могут потребоваться при передаче данных через интерфейсы объекта управления согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта управления
9.3 Интерфейсы объекта оплаты
9.3.1 Общие положения
Объект оплаты содержит интерфейсы со следующими объектами:
- основного обеспечения;
- обеспечения контекстных данных EFC;
- обеспечения заявления об оплате;
- сбора пользовательских данных.
9.3.2 Интерфейс управления сбором
Интерфейс управления сбором должен:
- принимать общее описание системы и правила EFC;
- запрашивать сертификат и принимать связанные с этим ответы;
- доставлять отчеты о функционировании;
- доставлять схемы EFC;
- доставлять рекламации.
9.3.3 Интерфейс обеспечения
9.3.4 Интерфейс обеспечения контекстных данных EFC
Интерфейс оплата-обеспечение контекстных данных EFC должен:
9.3.5 Интерфейс обеспечения заявления об оплате
Интерфейс оплата-обеспечение заявления об оплате должен принимать данные о тарификации.
9.3.6 Интерфейс сбора пользовательских данных
Интерфейс сбора пользовательских данных должен:
- запрашивать идентификацию пользования и принимать связанные с этим ответы;
- доставлять идентификацию оператора;
- доставлять информацию о наблюдении оператора;
- запрашивать данные о соответствии параметров бортового оборудования и принимать соответствующие ответы.
9.3.7 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 11, могут потребоваться при передаче данных через интерфейсы объекта оплаты согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта оплаты
9.4 Интерфейсы объекта основного обеспечения
9.4.1 Общие положения
Объект основного обеспечения содержит интерфейсы со следующими объектами:
- оплаты;
- настройки бортового оборудования;
- действия в качестве агента;
- обеспечения заявления об оплате;
- использования.
9.4.2 Интерфейс основное обеспечение — управление
Интерфейс основное обеспечение — управление должен:
- принимать общее описание системы и правила EFC;
- запрашивать сертификацию и получать связанные с этим ответы;
- доставлять отчеты о функционировании;
- доставлять рекламации.
9.4.3 Интерфейс основного обеспечения
Интерфейс основного обеспечения должен:
9.4.4 Интерфейс основного обеспечения бортового оборудования
Интерфейс основного обеспечения бортового оборудования должен доставлять информацию о настройках.
9.4.5 Интерфейс основного обеспечения в качестве агента
Интерфейс основного обеспечения в качестве агента должен:
- доставлять договорные условия;
- принимать заверенные контракты;
- доставлять пользовательские счета;
- доставлять списки исключения.
9.4.6 Интерфейс обеспечения заявлений об оплате
Интерфейс основного обеспечения заявлений об оплате должен принимать данные о тарификации и ответы о проверки на наличие денежных средств.
9.4.7 Интерфейс хранения и использования данных
Интерфейс хранения и использования данных должен:
- обмениваться финансовыми объектами;
- принимать запросы о справочной и общей информации и рекламации, а также доставлять связанные с этим ответы.
9.4.8 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 12, могут потребоваться при передаче данных через интерфейсы объекта основного обеспечения согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта основного обеспечения
9.5 Интерфейсы объекта поддержки бортового оборудования
9.5.1 Общие положения
Объект поддержки бортового оборудования содержит интерфейсы со следующими объектами:
- настройки бортового оборудования;
9.5.2 Установка OBE — интерфейс подгонки OBE
Установка OBE — интерфейс подгонки OBE должен:
9.5.3 Установка OBE — интерфейс сбора пользовательских данных
Установка OBE — интерфейс сбора пользовательских данных должен:
9.5.4 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 13, могут потребоваться при передаче данных через интерфейсы объекта поддержки бортового оборудования согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта поддержки бортового оборудования
| Тип данных | Конфиденциальность | Подлинность | Целостность | Безотказность | Доступность |
|---|---|---|---|---|---|
| Подстраиваемая под пользователей информация | + | + | + | + | + |
| Статус бортового оборудования | + | + | + | - | + |
9.6 Интерфейсы объекта настройки бортового оборудования
9.6.1 Общие положения
Объект настройки бортового оборудования содержит интерфейсы со следующими объектами:
9.6.2 Подгонка OBE — интерфейс основного обеспечения
Подгонка OBE — интерфейс основного обеспечения должен принимать подстраиваемую под пользователей информацию.
9.6.3 Подгонка OBE — интерфейс установки OBE
Подгонка OBE — интерфейс установки OBE должен доставлять подстраиваемую под пользователей информацию.
9.6.4 Интерфейс действий бортового оборудования в рамках контракта
Интерфейс действий бортового оборудования в рамках контракта должен принимать заверенные контракты.
9.6.5 Подгонка OBE — интерфейс сбора пользовательских данных
Подгонка OBE — интерфейс сбора пользовательских данных должен доставлять подстраиваемую под пользователей информацию.
9.6.6 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 14, могут потребоваться при передаче данных через интерфейсы объекта настройки бортового оборудования согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта настройки бортового оборудования
| Тип данных | Конфиденциальность | Подлинность | Целостность | Безотказность | Доступность |
|---|---|---|---|---|---|
| Подстраиваемая под пользователей информация | + | + | + | + | + |
| Заверенные контракты | + | + | + | + | + |
9.7 Интерфейсы объекта действия в качестве агента
9.7.1 Общие положения
Объект действия в качестве агента содержит интерфейсы со следующими объектами:
9.7.2 Действие в качестве агента контракта — интерфейс основного обеспечения
Действие в качестве агента контракта — интерфейс основного обеспечения должен:
- принимать договорные условия;
- доставлять заверенные контракты;
- принимать пользовательские счета;
- принимать списки исключения.
9.7.3 Действие в качестве агента контракта — интерфейс установки OBE
Действие в качестве агента контракта — интерфейс установки OBE должен доставлять подстраиваемую под пользователей информацию.
9.7.4 Действие в качестве агента контракта — интерфейс подгонки OBE
Действие в качестве агента контракта — интерфейс подгонки OBE должен доставлять заверенные контракты.
9.7.5 Действие в качестве агента контракта — интерфейс оплаты
Интерфейс действий в качестве агента-оплата должен принимать договорные условия.
9.7.6 Действие в качестве агента контракта — пользовательский интерфейс
Действие в качестве агента контракта — пользовательский интерфейс должен:
9.7.7 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 15, могут потребоваться при передаче данных через интерфейсы объекта действия в качестве агента согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта действия в качестве агента
9.8 Интерфейсы объекта обеспечения контекстных данных EFC
9.8.1 Общие положения
Объект обеспечения контекстных данных EFC содержит интерфейсы со следующими объектами:
9.8.2 Контекстные данные обеспечения EFC — интерфейс оплаты
Контекстные данные обеспечения EFC — интерфейс оплаты должен:
9.8.3 Контекстные данные обеспечения EFC — интерфейс сбора пользовательских данных
Интерфейс обеспечения контекстных данных EFC по сбору пользовательских данных должен:
9.8.4 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 16, могут потребоваться при передаче данных через интерфейсы объекта обеспечения контекстных данных EFC согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта обеспечения контекстных данных EFC
| Тип данных | Конфиденциальность | Подлинность | Целостность | Безотказность | Доступность |
|---|---|---|---|---|---|
| Контекстные данные | + | + | + | + | - |
| Данные о местоположении | - | - | - | - | + |
9.9 Интерфейсы объекта обеспечения заявлений об оплате
9.9.1 Общие положения
Объект обеспечения заявлений об оплате содержит интерфейсы со следующими объектами:
9.9.2 Декларация обеспечения оплаты — интерфейс основного обеспечения
Интерфейс обеспечение заявления об оплате должен доставлять данные тарификации и принимать связанные с этим данные о проверке на наличие денежных средств.
9.9.3 Декларация обеспечения оплаты — интерфейс оплаты
Декларация обеспечения оплаты — интерфейс оплаты должен:
9.9.4 Декларация обеспечения оплаты — интерфейс сбора пользовательских данных
Декларация обеспечения оплаты — интерфейс сбора пользовательских данных должен:
9.9.5 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 17, могут потребоваться при передаче данных через интерфейсы объекта обеспечения заявления об оплате согласно принятой политике безопасности.
Требования к защите данных, передаваемых через интерфейсы объекта обеспечения заявления об оплате
9.10 Интерфейсы объекта сбора пользовательских данных
9.10.1 Общие положения
Объект сбора пользовательских данных содержит интерфейсы со следующими объектами:
- обеспечения заявления об оплате;
- обеспечения контекстных данных EFC;
- поддержки бортового оборудования;
- настройки бортового оборудования;
- оплаты.
9.10.2 Сбор пользовательских данных — интерфейс обеспечения платежной декларации
Сбор пользовательских данных — интерфейс обеспечения платежной декларации должен:
9.10.3 Сбор пользовательских данных — интерфейс контекстных данных обеспечения EFC
Сбор пользовательских данных — интерфейс контекстных данных обеспечения EFC должен:
9.10.4 Сбор пользовательских данных — интерфейс подгонки OBE
Сбор пользовательских данных — интерфейс подгонки OBE должен принимать информацию по настройке.
9.10.5 Сбор пользовательских данных — интерфейс установки OBE
Сбор пользовательских данных — интерфейс установки OBE должен:
9.10.6 Сбор пользовательских данных — интерфейс оплаты
Сбор пользовательских данных — интерфейс оплаты должен:
- принимать данные по идентификации оператора и информацию по взиманию платежей;
- принимать запросы по характеристикам бортового оборудования и идентификации пользователя, доставлять ответы.
9.10.7 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 18, могут потребоваться при передаче данных через интерфейсы объекта сбора пользовательских данных.
9.11 Интерфейсы объекта использования
9.11.1 Общие положения
Объект использования содержит интерфейсы со следующими объектами:
9.11.2 Использование — интерфейс основного обеспечения
Использование — интерфейс основного обеспечения должен:
- обмениваться финансовыми объектами;
- доставлять запросы о получении справочной и общей информации и о рекламациях, а также принятие соответствующих ответов.
9.11.3 Использование — интерфейс действия в качестве агента контракта
Использование — интерфейс действия в качестве агента контракта должен:
9.11.4 Требования к обеспечению безопасности
Функции безопасности, представленные в таблице 19, могут потребоваться при передаче данных через интерфейсы объекта использования согласно принятой политике безопасности.
10 Согласование точек зрения
10.1 Точки зрения
С точки зрения предприятия согласование должно быть определено в точках взаимодействия, определенных в разделе 8, с точки зрения информационных объектов, которыми обмениваются в соответствующих вычислительных интерфейсах, рассмотренных в разделе 9.
10.2 Согласование между информационной точкой зрения и точкой зрения предприятия
Архитектура с точки зрения предприятия, описанная в настоящем стандарте, выявляет в разделе 6 роли и взаимодействиях среди ролей. Взаимодействия идентифицируют информационные объекты, которые описаны в других стандартах. Корреспонденция между точкой зрения предприятия и информационной точкой зрения описаны в рамках взаимодействия объектов и ролей.
10.3 Согласование между точкой зрения предприятия и вычислительной точкой зрения
Каждое взаимодействие, указанное в 7.3, выполняется в вычислительном интерфейсе так, чтобы корреспонденции между предприятием и вычислительными описаниями были определены путем идентификации взаимодействия. Точный список согласований зависит от подробного вычислительного описания, выходящего за рамки данного национального стандарта.
Полная спецификация любой нетривиальной распределенной системы включает очень большое количество информации. Попытка получить все аспекты проекта в единственном описании обычно неосуществима. Большинство методологий проекта стремится устанавливать скоординированный, взаимосвязанный набор моделей, каждый из которых нацелен на получение одного аспекта проекта, удовлетворяя требования, которые должны обеспечиваться определенной группы, вовлеченной в процесс проектирования.
Цель ODP состоит в том, чтобы позволить определению стандартов архитектуры упрощать проектирование и анализ распределенных неоднородных систем и определять стандарты компонентов и функций инфраструктуры для разработки приложений в распределенных неоднородных средах.
Модель ODP определяет архитектуру, сформированную из концепций, определений и правил, которые могут использоваться в качестве платформы для определения любой системы.
В соответствии с данным аспектом OPO может быть рассмотрена как комплект инструментальных средств, не налагающий структурирования на систему или на ее спецификацию, а скорее дающий полный и когерентный набор определений и понятий.
Одним из основных и самых полезных понятий эталонной модели OPO является понятие точки зрения, основывающейся на предположении, что спецификация полной системы сделана из сложного набора типов информации, который является не поддающимся описанию с помощью универсальной модели или при помощи универсального языка.
Можно привести пример как одна точка зрения описывает систему с точки зрения своих аппаратных и программных компонентов, абсолютно другая точка зрения описывает ту же систему с точки зрения своих целей. Вышеупомянутое является тремя различными моделями одной системы, требующими трех различных языков, которые должны быть выражены.
Одновременно, существует очевидная потребность найти способ коррелировать эти различные описания, чтобы обеспечить их достоверность.
В ODP это разделение проблем установлено путем идентификации пяти точек зрения, каждой со связанным языком, выражающим понятия и правила определенной проблемной области, с точки зрения которой части системы могут быть описаны. OPO определяет скоординированный и когерентный набор моделей посредством его пяти перспектив (точек зрения).
Точки зрения весьма зависимы друг от друга. Каждая точка зрения выражает частичное мнение о спецификации полной системы, как изображено на рисунке A.1.
Стандарт ODP определяет пять точек зрения, в целом, допускающих спецификацию полной системы. Каждая точка зрения использует определенный язык.
- Точка зрения предприятия. Модель предприятия системы просматривает роли различных агентов (объекты), определенных в системе и среде «вокруг» системы. Это описано в правилах, которые применены к различным ролям и действиям, выполняющимся системой. Для архитектуры систем сбора платы за проезд модель предприятия полностью использована в настоящем национальном стандарте.
- Информационная точка зрения. Информационная точка зрения имеет дело с информационными объектами и их схемами. В действительности информационная спецификация будет видеть систему с точки зрения информационного определения (какая часть является инвариантной, какой частью обмениваются в среде системных компонентов, в каком пути и какой информацией потоков обмениваются).
- Вычислительная точка зрения. Вычислительная точка зрения является представлением системной архитектуры в рамках прикладного программного обеспечения. Здесь, система представлена как совокупность взаимодействующих объектов, выполняющих функции путем обмена информацией в интерфейсах. Детали взаимодействия (механизмы, методы кодирования, системные функции, использующиеся для выполнения взаимодействий) не рассматриваются в рамках данной точкой зрения, таким же образом как дисковые драйверы доступа являются невидимыми для программистов приложений.
- Техническая точка зрения. Техническая точка зрения является системной перспективой инженера системы. Здесь, детали операционной системы и поддерживающие функции и протоколы рассматриваются как безопасность, передача данных, физическое распределение приложений и т.п. Эта точка зрения является типичной перспективой внедрения реальной системы, и менее вероятная модель, которая будет рассматриваться в стандарте.
- Технологическая точка зрения. Технологическая точка зрения описывает физические объекты в системе с точки зрения их характеристик. Это включает, например, стандарты, использующиеся для реализации системы.
Общим основанием ко всем точкам зрения является использование понятий, полученных из объектно-ориентированных методологий.
С точки зрения языков, используемых в каждой точке зрения, архитектура ODP не налагает ограничениями.
- Спецификация с точки зрения предприятия системы ODP является моделью системы и среды, с которой взаимодействует система. Это покрывает роль системы в бизнес-сегменте, роли пользователей системы и деловые отношения, связанные с системой.
- Информационная спецификация системы ODP является моделью информации, которую содержит система, и обработки информации, которую она производит. Информационная модель извлечена из индивидуальных компонентов, и она обеспечивает согласованный общий взгляд, на который могут сослаться спецификации источников и приемников информации и информационных потоков между ними.
- Вычислительная спецификация системы ODP является моделью системы с точки зрения индивидуальных, логических компонентов, которые являются источниками и приемниками информации. Используя вычислительный язык, вычислительные спецификации могут выразить требования полного спектра распределенных систем, обеспечивая максимальный потенциал для мобильности и взаимодействия и включения определению ограничений на распределение, не определяя подробные спецификации участвующих механизмов.
- Техническая спецификация системы ODP определяет сетевую вычислительную инфраструктуру, поддерживающую системную структуру, определенную в вычислительной спецификации и обеспечивающую информационную открытость распределения, которую определяет данная спецификация. Она описывает механизмы, соответствующие элементам модели программирования, эффективно определяя абстрактную машину, которая может выполнять вычисления и обеспечивать информационную открытость распределения.
- Технологическая спецификация определяет, как система структурирована с точки зрения аппаратных и программных компонентов.
Нужно отметить, что спецификации с точки зрения предприятия и информационные спецификации включают в себя распределение только тогда, когда проблемы распределения являются результатом требований предприятия (например, от географического распространения точек доступа к системным службам). Однако, эти спецификации, возможно, должны принять во внимание ограничения, являющиеся результатом вариантов распределения, сделанного в вычислительной, технической и технологической спецификациях.
Точки зрения весьма зависимы. Спецификации системы с каждой точки зрения являются частичными представлениями полной системы и существуют ограничения между различными спецификациями точки зрения, являющимися результатом отношений между реальными объектами, представленными в различных спецификациях и фактом, что те же объекты могут быть представлены в нескольких спецификациях.
Настоящий национальный стандарт использует определения ODP и понятия для определения архитектуры EFC с точки зрения агентов, ролей и политик, путем использования понятия точки зрения предприятия эталонной модели ODP.
B.1 Предыдущая модель системы сбора платы за проезд
Рисунок B.1 показывает модель системы сбора платы за проезд для сервисов, в соответствии с ИСО/ТУ 17573:2003. Модель была сформирована полным набором объектов, необходимых для эксплуатации системы. Определения объектов даны ниже.
Оператор обработки данных — организация, собирающая и приводящая в соответствие транзакции от одного или более сервис провайдеров для доставки эмитентам. Оператор обработки данных может также налаживать взаимодействие между сервис провайдерами. В финансовом мире эквивалентом оператора является покупатель.
Агент сбора платы — организация, ответственная за продажу, перезапуск или доставку от пользователя, инициированную эмитентом. Агент сбора платы может также собирать специализированные пользовательские данные от пользователя. Агент набора также называется ретейлером.
Оператор взыскания штрафов — организация, ответственная за взыскание штрафов.
Эмитент — организация, ответственная за платежную систему и за издание платежных средств для пользователя.
Сервис провайдер — человек, компания, органы власти или абстрактная организация, предлагающая транспортный сервис пользователю.
Третья сторона — организация, которая может быть ответственной за мониторинг эксплуатации, системы и оценки безопасности.
Пользователь (клиент, заказчик, потребитель) — тот, кто пользуется сервисом, предоставленным провайдером в соответствии с условиями соглашения.
Объекты в модели составляют абстрактные объекты и организации.
Концептуальная модель не подразумевает и не передает под мандат/требование того, чтобы всегда была отдельная организация для каждого абстрактного объекта в любой реальной системе. В зависимости от определенных деловых соглашений и получающихся организационных моделей, абстрактный объект может иметь или может не иметь прямых дубликатов в реальном мире.
Эта модель является одной моделью, которая в состоянии полностью поддерживать транспортную систему, будучи совместимой с моделями, используемыми в финансовом мире (банковским деле). В рамках настоящего национального стандарта никакие предположения не должны быть сделаны относительно присутствия или отсутствия конкурирующих организаций, стремящихся занять какие-либо роли. Следовательно, эмитент мог бы действовать как эмитент для одной или более систем сбор платы за проезд, например, нескольких или всех систем на национальном уровне. Точно также одна или несколько организаций могут действовать как провайдеры сервисов или агентов сбора платы за проезд. Однако, вероятно, будет меньше операторов очистки, чем системы EFC.
Внутренняя цепочка потоков в рисунке B.1 (против часовой стрелки) соответствует потоку данных, внешний круг (по часовой стрелке) — потоку службы и денежному потоку.
B.2 Согласование между настоящей и предыдущей концептуальными моделями
В то время как новая модель системы, описанная в настоящем стандарте, является функциональной моделью, предыдущая модель EFC была моделью, описанной с организационной точки зрения. Однако предыдущая модель объекта также имела некоторые описательные роли, и сравнение между двумя моделями EFC основывается на ролевых описаниях этих двух моделей.
Обеспечение сервиса оплаты касается ролей, выделенных объектам «эмитент» и «агент сбора платы» в предыдущей модели системы.
Использование сервиса сбора платы за проезд покрывает роли, выделенные объекту «пользователь».
Взимание платы покрывает роли, выделенные объектам «сервис провайдер» и «оператор взыскания штрафов».
Управление средой взимания платы покрывает роли, выделенные объекту «третья сторона». Это также покрывает несколько других ролей, не определенных в предыдущей модели. Следовательно, новая функциональная модель дает более корректное и обновленное изображение среды взимания платы.
У «оператора обработки данных» в предыдущей модели есть роль, не определенная в новой функциональной модели. Причина этого состоит в том, что роль, как находят, является лишней. В некоторых случаях несколько операторов могут реализовать оборудование, которое собирает, сортирует, инициирует и распределяет файлы транзакции и списки исключения между междугородным поставщиком услуг и междугородными операторами взимания платы, при этом это является операционным и техническим решением для передачи данных между операторами.
Сравнение ролей показано на рисунке B.2.
C.1 Введение: среда IFM
ИСО 24014-1 определяет роли электронных систем в среде интегрированной оплаты за проезд на общественном транспорте. Система может управляться единственной транспортной службой, транспортным управлением, ассоциацией акционерных обществ и частной компанией или другими группами.
Рисунок C.1 показывает концептуальную среду данных систем, где группы ролей были названы согласно основным функциям. Определения групп ролей даны ниже.
Владелец приложения — владеет контрактом приложения для предоставления использования клиенту.
Продавец приложения — промежуточное финансовое звено между системой и клиентом.
Сбор и передача — обмен данными, сбор и передача данных
Пользователь — приобретает приложения с целью их использования на транспорте.
Обслуживание клиентов — согласно коммерческим соглашениям может обеспечить «горячую линию» и любые подобные средства, включая украденную и поврежденную потребительскую замену «носителя» и последовательную переустановку продукта.
Менеджер системы — устанавливает и управляет системы. Эти политики встроены в ряд правил. Данные стратегии представляют собой определенный свод правил.
Владелец продукта — несет ответственность за свою продукцию и определяет использование, стоимость и коммерческие правила продукции.
Продавец продукции — промежуточное финансовое звено между системой и клиентом в отношении продаваемой продукции.
Регистратор — ответственен за выпуск уникальных регистрационных кодов, идентификаторов и сводов правил для компонентов системы.
Менеджер по безопасности — ответственен за установление и координирование политики безопасности (сертификация, аудиторская проверка организаций, мониторинг системы, управление секретными ключами).
Оператор — ответственен за обеспечение пользователя сервисом.
C.2 Согласование между системой сбора платы за проезд и системой интегрированной оплаты за проезд на общественном транспорте
Термин «продукт» очень важен в общественном транспорте и в среде электронной покупки билетов. «Продукт» описан рядом правил, как продукт мог использоваться (правила использования), как клиент должен заплатить за него (оценивающие правила) и как проезд, за который оплатил клиент, должен быть разделен на участвующие стороны (коммерческие правила), например, между владельцем продукта, продавцом продукта и оператором. Одно из основных различий между предметной областью междугородного сбора платы и предметной областью общественного транспорта связано с терминами «продукт» и «транспортный сервис».
Продукт обычно описывает право перемещения пользователя добраться от точки «A» до точки «B» с одним или более видами транспорта с помощью соответствующей транспортной инфраструктуры, например, автобус на улично-дорожной сети или поезд на железнодорожной сети.
Транспортный сервис обычно описывает доступ ТС к участку улично-дорожной сети, например, дорожной сети, мосту, туннелю или паромной переправе.
Следовательно, проезд, оплаченный пользователем для продукта, связан с транспортом клиента и с различными видами общественного транспорта в разных транспортных инфраструктурах. Это подразумевает, что «продукт» может быть независимым от способов передвижения, выбранных пользователем, где несколько способов транспортировки и транспортных инфраструктур предоставляют базовую услугу, которая является транспортировкой клиента от точки к точке.
Различия между продуктом и транспортным сервисом являются причинами того, что невозможно полностью согласовать между собой систему сбора платы за проезд и систему интегрированной оплаты за проезд на общественном транспорте.
Сравнение между этими двумя моделями основываются на ролевых описаниях двух моделей.
Владелец приложения и продавец приложения сопоставимы с некоторыми обязанностями ролей обеспечение сервиса оплаты.
Роли обслуживания клиентов сопоставимы с некоторыми обязанностями роли обеспечение сервиса оплаты.
Владелец «продукта» — роли частично сопоставимы с некоторыми обязанностями роли обеспечение сервиса оплаты и частично сопоставимы с некоторыми обязанностями роли оператор. Владелец «продукта» определяет продукт с помощью его использования, стоимости и коммерческих правил, в то время как оператор делает то же самое путем предоставления сервисов и определения соответствующих тарифов. С другой стороны, у владельца продукта есть также некоторые обязанности, касающиеся формирования отчетности.
Продавец продукта — роли частично сопоставимы с некоторыми обязанностями роли обеспечение сервиса оплаты. Разница заключается в наличии носителей соответствующей информации.
Роли оператора системы сбора платы на общественном транспорте сопоставимы с большинством ролей обеспечения сервиса платы за проезд. Разница заключается в том, что оператор в случае систем электронного сбора платы за проезд не определяет принципы взимания платы.
Роли пользователя сопоставимы с большинством обязанностей роли систем электронного сбора платы за проезд «использование сервисов».
Роли сбора и передачи несопоставимы ни с одной из ролей систем электронного сбора платы за проезд.
Роли «IFM менеджер», включая «менеджер по безопасности», «менеджер системы» и «менеджер регистратор» сопоставимы с ролями управления средой сбора платы за проезд.
Сравнение ролей показано на рисунке C.2.
D.1 Термины
Термины, используемые в настоящем стандарте, соответствуют терминам, определенным в ИСО/ТУ 17573:2003, а также терминам, используемым комиссией Евросоюза:
D.2 Ролевая модель EETS
Роли и обязанности, определенные в настоящем стандарте, сопоставимы с ролями и обязанностями, определенными в концептуальном описании EETS, поставленном европейским проектом R&D CESARE IV. Рисунок D.1 показывает термины, использованные при определении ролей в EETS. Нужно отметить, что термин «управление совместимостью» (Interoperability Management (IM) не использован в ИСО/МЭК 10746-1 или ее решениях. Следовательно, ролевое управление эксплуатационным взаимодействием, как указано в этом приложении, охватывает такие термины как государства-члены, органы урегулирования, и т.д., выполняя полностью или частично функции IM, определенных в настоящем стандарте.
Рисунок D.1 — Распределение ролей в EETS
На основе обязанностей, описанных в разделе 7, рисунок 8 и архитектуре, представленной в европейском исследовательском проекте Road Charging Interoperability (RCI), которая показана на рисунке D.2. отношения между ролями EETS, основанными на настоящем стандарте и интерфейсах RCI, показаны на рисунке D.3.
Рисунок D.3 — Подробная ролевая схема EETS
- Интерфейс 1: Сервисный Интерфейс. Этот интерфейс обеспечивает точку доступа в транспортных средствах для обслуживания и эксплуатации бортового оборудования, учитывающего стоимость дороги. Интерфейс не позиционируется как важный для эксплуатационной совместимости.
- Интерфейс 2: Интерфейс интеграции транспортного средства. Этот интерфейс описывает взаимодействие между бортовым оборудованием и транспортным средством. Некоторые данные могут собираться с транспортного средства и использоваться для вычисления платы. Интерфейс не позиционируется как важный для эксплуатационной совместимости.
- Интерфейс 3: Интерфейс человек — устройство. Этот интерфейс обеспечивает доступ к бортовому оборудованию для взаимодействия с человеком. Интерфейс не считают важным для эксплуатационной совместимости, но настоятельно рекомендуется гармонизация.
- Интерфейс 4: Обмен данными о плате/объявление о плате. Этот интерфейс был разделен на следующие интерфейсы:
- 4: Загрузка данных (автономные системы) определена в ИСО 12855 с учетом описаний, данных в ИСО 17575-1;
- 4а: Загрузка данных (системы, основанные на DSRC) определена в EN 15509;
- 4б: Поддержка локализации.
- Интерфейс 5: Публикация контекстных данных платы. Этот интерфейс позволяет обмениваться техническими требованиями, которые определяют спецификацию операторов облагаемой пошлиной инфраструктуры и ожидаемое поведение систем поставщиков EETS во время передачи данных. Интерфейс также размещает операции оформления документов между оператором и поставщиком услуг EETS (интерфейс разделяется на две стрелки на рисунке D.3).
- Интерфейс 6: Применение. Этот интерфейс позволяет оператору проводить проведения контрольно-надзорную проверку операций с бортовым оборудованием.
ПРИМЕР ЯПОНСКОЙ СИСТЕМЫ ЭЛЕКТРОННОГО СБОРА ПЛАТЕЖЕЙ
E.1 Обновленная предыдущая диаграмма классов для систем EFC
Рисунок E.1 показывает пример диаграммы классов уведомления UML для системы EFC, обновленной в ИСО/ТУ 17573:2003, приложение B. Диаграмма состоит из 19 классов. Обновленная диаграмма класса отражает актуальную систему ETC (Electronic toll collection system), функционирующую в Японии с 2000 года.
уведомления UML для сбора платежей
Некоторые классы — принятое обращение внимания информации систем EFC. Понятие <> введено, чтобы выразить информационный класс соответствующего субъекта:
Другие классы — принятое обращение внимания информации, которая важна для выражения систем. Они являются информационными классами:
- информация контракта абонента EFC;
- информация по способу оплаты контракта;
- выдача информации OBE;
- информация о пользователе оплаты;
- передача информации;
- тариф;
- негативный перечень;
- негативная информация;
- пункт оплаты.
Классы представлены блоками, разделенными на секторы. У каждого класса есть название в верхнем секторе. У среднего прямоугольника есть свои признаки или информация, которую влечет за собой класс. У более низкого сектора есть операции, которые выполняет класс.
E.2 Обращение с новой моделью
Диаграмма классов описывает отношение актеров и информационных классов для модели сбора платежей, в то время как новая модель EFC, описанная в этом международном стандарте, является функциональной моделью. У диаграммы класса есть некоторые функциональные актеры, и каждый актер может быть спроектирован в новую модель, показанную на рисунке E.2.
Рисунок E.2 — Роли актеров UML в новой модели
Хотя есть различия в примечании, между диаграммой класса и новой функциональной моделью сохранена последовательность.
Обеспечение функционирования систем сбора платежей охватывает роли, распределенные по классам «роли эмитента бортового оборудования» и «роли эмитента методов оплаты» в диаграмме классов UML.
Использование служб сбора платежей охватывает роли, распределенные по классам «роли пользователей» и «роли транспортных средств» и «роли бортового оборудования» в диаграмме классов UML.
Службы сбора платежей охватывает роли, распределенные по классам «роли поставщика услуг» и «роли оператора исполнения» в диаграмме классов UML.
Управление окружающей средой служб сбора платежей охватывает роли, распределенные по классу «роли доверенной третьей стороны» в диаграмме классов UML.
(обязательное)
СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ ССЫЛОЧНЫМ НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ
| Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
| ИСО/МЭК 7498-1 | IDT | ГОСТ Р ИСО/МЭК 7498-1-99 «Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель» |
| ИСО/МЭК 10746-2 | IDT | ГОСТ Р ИСО/МЭК 10746-2-2000 «Информационная технология. Взаимосвязь открытых систем управления данными и открытая распределенная обработка. Часть 2. Базовая модель» |
| ИСО/МЭК 10746-3 | IDT | ГОСТ Р ИСО/МЭК 10746-3-2001 «Информационная технология. Взаимосвязь открытых систем. Управление данными и открытая распределенная обработка. Часть 3. Архитектура» |
| ИСО/МЭК 15414 | - | <*> |
| <*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание — В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов: - IDT — идентичные стандарты. | ||