Электронное оборудование для подвижного состава железных дорог. сети поездной связи (TCN). Часть 2-2: испытание поездной шины на соответствие требованиям по проводимости (стр. 17 )

Таблица 52 определяет действия для измерения базового периода.

Установка: TTS1

Конфигурируйте узлы P01 P02 с периодом  узла 0.

Таблица 52  ̶  Тестовая последовательность измерения базового периода

Шаг	Действие	Ожидаемые результаты
1	Power up P01, P02 Включить P01, P02	•  inauguration открытие
2	TNM: Set Strong -> P01 TNM: установить сильное -> P01	•  P01 is master •  New topography •  Use of data logger to measure basic period. Expected value shall be: 25 ms ± 1 ms •  P01  ̶  ведущий задатчик •  Новая топография •  Использование регистратора данных для измерения базового периода.  Ожидаемое значение должно быть: 25 ms ± 1 ms

5.1.7.19 Процедуры канального уровня WTB

Следующая таблица 53 перечисляет процедуры канального уровня WTB, которые используются управлением сети или Mapping Server (сервером отображения) для реализации  тестового приложения.

Таблица 53  ̶  Процедуры канального уровня WTB

Процедура	Подраздел в МЭК 61375-2-1	Используемый в  МЭК-2-1 TNM or Mapping Server
ls_t_Report(...) Отчет	5.6.4.3	Mapping Server (UIC CODE 556) Сервер отображения (идентификация кода 556)
ls_t_Init() Инициализация	5.6.4.4	Mapping Server (UIC CODE 556)
ls_t_Reset() повторно установить	5.6.4.5	8.4.3.2
ls_t_Configure(...) Конфигурировать	5.6.4.6	Mapping Server (UIC CODE 556)
ls_t_SetSlave() установить ведомое	5.6.4.7	8.4.3.2
ls_t_SetWeak() установить слабое	5.6.4.8	8.4.3.2
ls_t_SetStrong() установить сильное	5.6.4.9	8.4.3.2
ls_t_StartNaming() начать называние	5.6.4.10	8.4.3.2
ls_t_Remove() удалить	5.6.4.11	8.4.3.2
ls_t_Inhibit() запретить	5.6.4.12	8.4.3.2
ls_t_Allow() разрешить	5.6.4.13	8.4.3.2
ls_t_SetSleep() установить сон	5.6.4.14	8.4.3.2
ls_t_CancelSleep() отменить сон	5.6.4.15	8.4.3.2
ls_t_GetStatus(...) получить статус - состояние	5.6.4.16	8.4.3.1
ls_t_GetWTBNodes(...) получить узлы WTB	5.6.4.17	8.4.3.3
ls_t_GetTopography(...) получить топографию	5.6.4.18	8.4.3.4
ls_t_ChgNodeDesc(...) изменить дескриптор узла	5.6.4.19	Mapping Server (UIC CODE 556)
ls_t_ChgUserReport(...) изменить отчет пользователя	5.6.4.20	8.4.3.5
ls_t_Chglnauguration_Data(...) изменить открытие	5.6.4.21	Mapping Server (UIC CODE 556)
ls_t_GetStatistics(...) изменить статисику	5.6.4.22	8.4.3.1
ls_t_Getlnaug_Data(...) получить данные открытия	5.6.4.23	Mapping Server (UIC CODE 556)

6 Тестовое соответствие RTP

RTP (протоколы в режиме реального времени) испытываются посредством WTB в тестировании по принципу «черного ящика», который включает использование самих RTP.

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

RTP предназначены для работы с параллельным доступом совместно используемых ресурсов, создающих конфликты. Несоответствие и его проявление в отказе связи не могут появляться или не в состоянии появиться разъединенными. Конфликты и состязания (при передаче данных) могут успешно запускаться в течение длительных периодов времени, или для целого ряда различных исполнений, а затем неудачно завершаются в несколько иной последовательности выполнения. Согласно Хольцманну (см библиографию) "Это практически невозможно исчерпывающе проверить все возможные поведения неизвестной реализации простым зондированием ее и наблюдением за ее откликами (реакциями, ответами). Всегда существует вероятность того, что некоторые не предпринятые последовательности попыток выявили бы новое поведение, которое явилось бы неприемлемым. Особый набор тестов, выбранный для испытаний на соответствие данного типа, зато, всегда является маленьким выбором из бесконечного множества всех возможных наборов тестов". Этот тест на соответствие будет ограничен до ограниченного набора значений.

Основными требованиями для тестирования протокола являются:

а) число возможных типов данных процесса имеет предел;

б) время отклика протокола имеет предел;

в) существуют устойчивые условия, в которых IUT ждет нового входного сигнала;

г) имущественное положение существует: при получении сообщения "Статус", IUT отвечает выходным сообщением, которое однозначно идентифицирует ее текущее состояние.

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

6.1 Порты и Traffic_Store (трафик_ запоминающее устройство)

Смотреть раздел 6.2.2.2.1 МЭК 61375-2-1.

а) Тестируется количество портов для связи Process_Data (Процесс_Данные).

б) Тестируется доступ к порту последовательно в одной нераздельной операции.

в) Тестируются порты, принадлежащие к одному и тому же канальному уровню, принадлежат к одному и тому же Traffic_Store. Хранение трафика

г) Тестируется порт, идентифицированный в пределах Traffic_Store его Port_Address (Порт_Адрес).

д) Тестируется Traffic_Store, идентифицированный в пределах устройства посредством его Traffic_Store_Id.

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

Если IUT проходит эти испытания, она способна воспроизводить поведение, предусмотренное в МЭК 613751-2-1, но IUT останется неизвестной до тех пор, пока может войти в набор состояний, которые производят ошибочное поведение.

6.2 Согласованность набора данных

Смотреть раздел 6.2.2.2.2 МЭК 61375-2-1.

а) Тестируется каждый порт, содержащий ровно один набор данных.

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

в) Тестируется только один порт-источник с заданной Port_Address на шине.

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

6.2.1Обработка ошибки

Смотреть раздел 6.2.2.2.3 МЭК 61375-2-1.

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

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

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

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

Канальный уровень должен переписать весь порт с '0' и проверяется.

6.2.2 Контроль свежести (новизны)

Смотреть раздел 6.2.2.2.4 МЭК 61375-2-1.

а) Каждый порт-приемник Freshness_Timer (Свежесть (Обновление?) - таймер) проверяется.

б) Freshness_Timer, извлеченный в неделимой операции, подвергается тестированию.

в) Разрешение Freshness_Timer, короче или равно 16 м/с, тестируется.

г) Диапазон Freshness_Timer не тестируется.

6.2.3 Набор данных синхронизации

Смотреть раздел 6.2.2.2.5 МЭК 61375-2-1.

Не тестируется.

6.2.4 Набор данных опроса

Смотреть раздел 6.2.2.2.6 МЭК 61375-2-1.

Не тестируется в данном стандарте.

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

Смотреть раздел 6.2.2.2.7.1 МЭК 61375-2-1.

Не тестируется.

6.2.6 Идентификатор Traffic_Store Трафик_Хранение (накопление)

Смотреть раздел 6.2.2.2.7.3 МЭК 61375-2-1.

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

6.3 Port_Address

Смотреть раздел 6.2.2.2.8 МЭК 61375-2-1.

Port_Address является одним из 4096 портов в пределах Traffic_Store, выбранным посредством Traffic_Store_Id. Он ограничен к тестовому адресу, предоставленному IUT, для проверки соответствия и подвергается тестированию.

6.4 Примитивы Link_Process_Data_Interface

Смотреть раздел 6.2.2.3 МЭК 61375-2-1.

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

6.5 Услуги и протоколы сообщений

Смотреть раздел 6.3 МЭК 61375-2-1.

Услуги и протоколы сообщений тестируются.

7 Тестовое соответствие железнодорожного состава, оборудованного WTB

7.1 Общее

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

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