модуль ara::tsync — Time Synchronization

Функциональный кластер Time Synchronization предоставляет платформе AUTOSAR Adaptive Platform согласованные и синхронизированные в масштабе всей сети временные базы (AUTOSAR_AP_SWS_TimeSynchronization с. 16). Через стандартизированные интерфейсы адаптивные приложения опрашивают атомарные состояния времени или передают в общую систему новые коррекции времени и скорости в качестве активных источников времени. В то же время зарегистрированные функции обратного вызова нотификаторов непрерывно отслеживают смены состояний и скачки времени базовых часов ([SWS_TS_01009]). Расширенные механизмы валидации данных измерений и значений актуальности защищают временную целостность от ошибок передачи и манипуляций.

больше ›

Функциональный кластер Time Synchronization (tsync) предоставляет на платформе AUTOSAR Adaptive Platform согласованные и синхронизированные в масштабе всей сети временные базы (AUTOSAR_AP_SWS_TimeSynchronization с. 16). В качестве фоновой службы на базе демона он абстрагирует специфичные для аппаратного обеспечения и шин механизмы синхронизации (такие как IEEE 802.1AS gPTP) и обслуживает основные кластеры, такие как Log and Trace, Intrusion Detection System Manager (IdsM), а также службы обновления через стандартизированные интерфейсы (AUTOSAR_AP_EXP_SWArchitecture с. 83).

Контекстная диаграмма: встраивание кластера Time Synchronization на базе демона в AUTOSAR Adaptive Platform и его связи по интерфейсам с потребляющими кластерами и приложениями. Источники: AUTOSAR_AP_SWS_TimeSynchronization с. 16, AUTOSAR_AP_EXP_SWArchitecture с. 83, AUTOSAR_AP_EXP_SWArchitecture с. 83

Для доступа на чтение приложения используют интерфейс SynchronizedTimeBaseConsumer ([SWS_TS_01001]). Метод GetTimeWithStatus() возвращает атомарный снимок типа SynchronizedTimeBaseStatus, из которого можно запросить глобальное время, локальное монотонное время создания, состояние синхронизации, а также полученные UserData ([SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176]). Во избежание поллинга приложения регистрируются через функции обратного вызова нотификаторов для отслеживания смены статуса и скачков времени ([SWS_TS_01010], [SWS_TS_01014]).

Диаграмма последовательности: процесс синхронного запроса времени через интерфейс потребителя и считывание свойств атомарного снимка. Источники: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture с. 225

Задающие время приложения управляют поведением системы через SynchronizedTimeBaseProvider: SetTime() инициирует немедленные передачи по шине, тогда как UpdateTime() сначала корректирует часы локально ([SWS_TS_01101], [SWS_TS_01107], [SWS_TS_01108]). Сопутствующие механизмы, такие как Time Validation ([SWS_TS_00420], [SWS_TS_00421]) и нативное управление значениями актуальности (FVM), защищают от ошибок дрейфа и повторного воспроизведения ([SWS_TS_14198]). В случае ошибки коды TsyncErrc (например, kDaemonConnectionLost) сигнализируют об обрывах соединения, тогда как отсутствие сообщений синхронизации отображается как kTimeOut в объекте статуса ([SWS_TS_00901], [SWS_TS_01050]).

больше ›

Функциональный кластер Time Synchronization (tsync) предоставляет на платформе AUTOSAR Adaptive Platform скоординированные, синхронизированные в масштабе всей сети временные базы и изолирует применяющие процессы от протоколов синхронизации времени, специфичных для аппаратного обеспечения и шин (AUTOSAR_AP_SWS_TimeSynchronization с. 16). Система формирует информационно-технологический фундамент для распределенных систем, в которых необходимо гарантировать согласованные последовательности событий, воспроизводимые протоколы трассировки и детерминированные вычислительные циклы поверх границ блоков управления (AUTOSAR_AP_EXP_SWArchitecture с. 83).

Контекстная диаграмма: встраивание кластера Time Synchronization на базе демона в AUTOSAR Adaptive Platform и его связи по интерфейсам с потребляющими кластерами и приложениями. Источники: AUTOSAR_AP_SWS_TimeSynchronization с. 16, AUTOSAR_AP_EXP_SWArchitecture с. 83, AUTOSAR_AP_EXP_SWArchitecture с. 83

Границы системы и роль кластера Time Synchronization на базе демона

Функциональная архитектура Time Synchronization реализована в виде кластера на базе демона (daemon-based), который функционирует в фоновом режиме в качестве центральной службы платформы (AUTOSAR_AP_SWS_TimeSynchronization с. 16). Этот демон напрямую взаимодействует с интерфейсами базовой операционной системы и обрабатывает сетевые данные синхронизации времени, такие как gPTP (IEEE 802.1AS) или классические протоколы синхронизации времени по шине (AUTOSAR_FO_PRS_TimeSyncProtocol с. 68). Для контекста приложения кластер полностью инкапсулирует математическую компенсацию дрейфа и смещения аппаратных часов.

Многие функциональные основные кластеры Adaptive Platform обращаются к tsync через стандартизированные сервисные интерфейсы (AUTOSAR_AP_EXP_SWArchitecture с. 83). Например, Log and Trace опирается на синхронизированную временную базу, чтобы снабжать общесистемные события журналов и DLT надежными глобальными временными метками (AUTOSAR_AP_EXP_SWArchitecture с. 59; AUTOSAR_AP_SWS_LogAndTrace с. 15). Связанные с безопасностью модули, такие как Intrusion Detection System Manager (IdsM), а также службы обновления (UCM и Vehicle UCM) также обязательно используют интерфейс C++ из SynchronizedTimeBaseConsumer для управления достоверными с точки зрения криминалистического анализа отчетами и согласованными транзакциями обновления поверх границ блоков управления (AUTOSAR_AP_EXP_SWArchitecture с. 125; AUTOSAR_AP_SWS_UpdateAndConfigurationManagement с. 16; AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement с. 11).

Потребляющие интерфейсы и запросы времени с сохранением состояния

Для доступа на чтение к синхронизированной временной базе приложения используют класс интерфейса SynchronizedTimeBaseConsumer ([SWS_TS_01001]). Этот класс реализует семантику перемещения ([SWS_TS_01003], [SWS_TS_01004]), но явно исключает любое копирование ([SWS_TS_01005], [SWS_TS_01006]). Во время выполнения GetRateDeviation() позволяет напрямую считывать текущее отклонение частоты часов ([SWS_TS_01008]).

Центральным элементом каждого синхронного запроса является операция GetTimeWithStatus() ([SWS_TS_01009]). Вместо возврата изолированных необработанных значений времени метод генерирует внутренне согласованный снимок типа SynchronizedTimeBaseStatus (EXP_SWArchitecture с. 81). Этот снимок фиксирует точный момент создания в глобальном времени ([SWS_TS_01055]), а также в локальном монотонном времени через GetCreationLocalTime() ([SWS_TS_14176]). При этом моменты времени представляются в стандартизированном типе C++ Chrono Timestamp с наносекундным разрешением на основе std::int64_t ([SWS_TS_01251], [SWS_TS_01261], [SWS_TS_01262]).

Из снимка, помимо времени, можно также определить состояние связи и синхронизации через GetSynchronizationStatus() ([SWS_TS_01053]), возможный скачок времени через GetLeapJump() ([SWS_TS_01054]), а также специфичные для приложения пользовательские данные через GetUserData() ([SWS_TS_01056]). Конструктора по умолчанию для объекта статуса не существует ([SWS_TS_01061]), тогда как конструкторы перемещения и копирования обеспечивают его потокобезопасную передачу вызывающим процедурам приложения ([SWS_TS_01057], [SWS_TS_01058]).

Диаграмма последовательности: процесс синхронного запроса времени через интерфейс потребителя и считывание свойств атомарного снимка. Источники: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture с. 225

Событийные оповещения и мониторинг синхронизации

Во избежание циклов опроса (polling) SynchronizedTimeBaseConsumer предоставляет управляемый событиями паттерн «Наблюдатель» (Observer) на основе функций обратного вызова Notifier (AUTOSAR_AP_EXP_SWArchitecture с. 226). Приложения регистрируются с типобезопасными callback-функциями для отслеживания конкретных изменений состояния ([SWS_TS_14221], [SWS_TS_14222]). При каждой повторной регистрации новый Notifier перезаписывает ранее зарегистрированный обработчик ([SWS_TS_01010]).

Для агрегированных изменений состояния предусмотрен RegisterStatusChangeNotifier() ([SWS_TS_01010]), дополняемый UnregisterStatusChangeNotifier() ([SWS_TS_01011]). Если приложение реагирует преимущественно на смену статуса синхронизации (например, потерю связи с Grandmaster), используется RegisterSynchronizationStateChangeNotifier() ([SWS_TS_01012]). Скачки времени в будущее (kTimeLeapFuture) или прошлое (kTimeLeapPast), превышающие сконфигурированное пороговое значение, передаются через RegisterTimeLeapNotifier() ([SWS_TS_01014], [SWS_TS_01051]).

Для мехатронных высокоточных приложений дополнительно доступен RegisterTimePrecisionMeasurementNotifier() ([SWS_TS_01018]). Callback-функция передает структуру TimePrecisionMeasurement, содержащую точные значения секунд и наносекунд непосредственно перед синхронизацией (locSeconds, locNanoSeconds) и после нее (glbSeconds, glbNanoSeconds), вычисленную задержку на тракте pathDelay, а также битовую маску timeBaseStatus ([SWS_TS_01401], [SWS_TS_01403], [SWS_TS_01406], [SWS_TS_01408]). Кластер Time Synchronization при этом не выполняет управления очередями (Queuing); буферизация при необходимости должна реализовываться внутри callback-функции приложения ([SWS_TS_01018]).

Диаграмма последовательности: регистрация и асинхронный поток уведомлений при изменениях синхронизации и скачках времени. Источники: [SWS_TS_01010], [SWS_TS_01012], [SWS_TS_01014], AUTOSAR_AP_EXP_SWArchitecture с. 226

Диаграмма состояний: жизненный цикл статуса синхронизации временной базы согласно SWS_TS_01050. Источники: [SWS_TS_01050], AUTOSAR_SWS_TimeSync с. 25

Предоставление временных баз и подстройка частоты поставщиками (Provider)

Если Adaptive Application выступает в качестве активного источника времени (Time Master) — например, благодаря подключению к GNSS-приемнику или внешним эталонным часам, — оно использует класс SynchronizedTimeBaseProvider ([SWS_TS_01101]). Интерфейс позволяет явно задавать новые значения времени с помощью двух различных семантик: SetTime() и UpdateTime() (EXP_SWArchitecture с. 80).

Вызов SetTime() не только сбрасывает внутреннее показание часов, но и принудительно инициирует немедленную отправку обновленных сообщений синхронизации по автомобильной шине ([SWS_TS_01107]). В противоположность этому UpdateTime() сначала обновляет время исключительно локально; передача на шину осуществляется с задержкой в регулярном последующем цикле протокола передачи времени ([SWS_TS_01108]). Оба метода принимают, помимо метки времени, структурированные UserData для распространения сопутствующей синхронизации дополнительной информации по всей сети ([SWS_TS_01112], [SWS_TS_01113]).

Для точной подстройки кварцевых генераторов и предотвращения резких фазовых скачков SetRateCorrection() позволяет задавать относительный коэффициент коррекции частоты ([SWS_TS_01110]). В дополнение к этому GetRateDeviation() возвращает текущее отклонение тактовой частоты ([SWS_TS_01111]), в то время как GetCurrentTime() считывает абсолютное значение времени часов независимо от текущего статуса синхронизации ([SWS_TS_01109]).

Обеспечение целостности с помощью Time Validation и Freshness Value Management

В критически важных для безопасности и высокоавтоматизированных средах вождения простого применения значений времени недостаточно: корректность и защищенность меток времени от манипуляций должны непрерывно валидироваться (AUTOSAR_AP_SWS_TimeSynchronization с. 38). Для этого tsync предоставляет callback-интерфейсы для Time Validation: потребители регистрируются через RegisterTimeValidationNotification() ([SWS_TS_01016]), поставщики — аналогично через специфичный для провайдера метод ([SWS_TS_01114]).

Интерфейсы валидации ConsumerTimeBaseValidationNotification и ProviderTimeBaseValidationNotification передают детализированные наборы данных измерений специализированным приложениям мониторинга ([SWS_TS_01300], [SWS_TS_01301]). На ведущей станции (Master) SetMasterTimingData() выдает метку времени отправки (Egress) (syncEgressTimestamp) и порядковый номер (sequenceId) переданных кадров синхронизации Sync ([SWS_TS_00421], [SWS_TS_14141], [SWS_TS_14142]). На уровне ведомого узла (Slave) SetSlaveTimingData() передает соответствующие метки времени приема (Ingress) (syncIngressTimestamp), полученное поле коррекции (correctionField), а также измеренную задержку на тракте (pDelay) ([SWS_TS_00420], [SWS_TS_14152], [SWS_TS_14153], [SWS_TS_14155]). Для измерений задержки по схеме Peer-to-Peer интерфейсы SetPdelayInitiatorData() и SetPdelayResponderData() полностью предоставляют моменты времени входа и выхода пакетов запроса и ответа ([SWS_TS_00422], [SWS_TS_00423], [SWS_TS_14160], [SWS_TS_14170]).

Для защиты от атак повторного воспроизведения (Replay) и для обеспечения безопасности передаваемых сообщений времени платформа интегрирует Freshness Value Management (FVM) через нативные интерфейсы в пространстве имен apext::tsync ([SWS_TS_14198], EXP_SWArchitecture с. 83). При запуске Initialize() инициализирует соответствующий плагин FVM ([SWS_TS_14200]). Перед отправкой стек вызывает GetTxFreshness() для получения свежих значений счетчика ([SWS_TS_14199]), тогда как при приеме для верификации и аутентификации привлекается GetRxFreshness() ([SWS_TS_14198]). Данные при этом передаются через стандартизированный FVContainer ([SWS_TS_14195], [SWS_TS_14196]).

Диаграмма последовательности: поток валидации данных измерений тайминга между Master, Slave и внешним приложением-валидатором. Источники: [SWS_TS_00420], [SWS_TS_00421], AUTOSAR_AP_SWS_TimeSynchronization с. 38

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

Размещение и функциональная привязка кластера выполняются декларативно в манифестах моделей AUTOSAR (AUTOSAR_AP_TPS_ManifestSpecification с. 590). В Machine Manifest демон платформы инстанцируется с помощью элемента метамодели TimeSyncModuleInstantiation на конкретной Machine и управляет на ней физическими, а также виртуальными объектами TimeBaseResource (AUTOSAR_AP_TPS_ManifestSpecification с. 590).

На уровне приложений процессы объявляют свою потребность во временных базах через прототипы портов (RPortPrototype для Consumer или PPortPrototype для Provider) (AUTOSAR_AP_TPS_ManifestSpecification с. 599). Конструкция метамодели TimeSyncPortPrototypeToTimeBaseMapping связывает эти порты индивидуально для каждого процесса с временными базами, определенными на машине (TPS_ManifestSpecification с. 599; AUTOSAR_AP_TPS_ManifestSpecification с. 600). Во время выполнения инстанцирование в коде осуществляется через типобезопасный ara::core::InstanceSpecifier, благодаря чему стек связывает корректную сконфигурированную временную базу ([SWS_TS_01001], [SWS_TS_01101]).

Поведение при ошибке

Ошибочные ситуации в кластере Time Synchronization сигнализируются через стандартизированную модель ошибок Adaptive Platform (ara::core::Result и ara::core::ErrorCode) ([SWS_TS_00910]). Для стандартных операций с временными базами перечисление TsyncErrc определяет коды ошибок ([SWS_TS_00901]). Если, к примеру, прерывается межпроцессное взаимодействие с демоном платформы, возвращается код ошибки kDaemonConnectionLost ([SWS_TS_00901]).

Через глобальный домен ошибок TsyncErrorDomain коды ошибок могут инспектироваться ([SWS_TS_00905], [SWS_TS_00906], [SWS_TS_00907]) либо, при включенных исключениях C++, генерироваться через ThrowAsException() в виде TsyncException ([SWS_TS_00903], [SWS_TS_00908], [SWS_TS_00909]). Для Freshness Value Management существует отдельный домен ошибок TsyncFvmErrorDomain с перечислением TsyncFvmErrc ([SWS_TS_14201], [SWS_TS_14202]). Если инициализация завершается неудачей, Initialize() возвращает ошибку kFVInitializeFailed ([SWS_TS_14200]), тогда как при недоступности счетчиков для проверок аутентификации сообщается kFVNotAvailable ([SWS_TS_14202]).

На функциональном уровне кластер сигнализирует потерю сообщений времени не обязательно через синхронные ошибки API, а помечает временную базу в объекте состояния коммуникационным статусом kTimeOut ([SWS_TS_01050]) либо устанавливает соответствующий бит в timeBaseStatus ([SWS_TS_01403]). Интерпретация: таким образом, приложение, вероятно, всегда обязано активно проверять статус действительности снапшота после GetTimeWithStatus(), прежде чем использовать измеренные значения для критически важных для безопасности контуров регулирования. Вопрос Q-0cd9bb48452ae3db (открытый)

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

Основные требования и пункты спецификации модуля tsync можно распределить по следующим ключевым направлениям:

• Интерфейсы времени выполнения для Consumer и Provider: операции жизненного цикла и выборки данных базируются на [SWS_TS_01001]–[SWS_TS_01019], а также функциях провайдера [SWS_TS_01101]–[SWS_TS_01115] (EXP_SWArchitecture с. 80, EXP_SWArchitecture с. 81).
• Структуры состояния и представление времени: определение SynchronizedTimeBaseStatus, SynchronizationStatus и LeapJump согласно [SWS_TS_01050]–[SWS_TS_01062], а также стандартных типов chrono согласно [SWS_TS_01251]–[SWS_TS_01265].
• Time Validation и сбор данных измерений: определение структур измерений и уведомительных callback-функций согласно [SWS_TS_00420]–[SWS_TS_00423], а также [SWS_TS_14140]–[SWS_TS_14174] (AUTOSAR_AP_SWS_TimeSynchronization с. 38).
• Расширение безопасности FVM: аутентификация и проверка свежести через интерфейсы [SWS_TS_14195]–[SWS_TS_14213] (AUTOSAR_AP_EXP_SWArchitecture с. 83).
• Манифестное моделирование: декларативная конфигурация и сопоставление процессов и прототипов портов с временными базами согласно AUTOSAR_AP_TPS_ManifestSpecification с. 590 и AUTOSAR_AP_TPS_ManifestSpecification с. 599.