ARINC 664P7_rus

СПЕЦИФИКАЦИЯ ARINC 664, ЧАСТЬ 7 СПРАВОЧНЫЙ МАТЕРИАЛ

СПРАВОЧНЫЙ МАТЕРИАЛ Не для перепродажи

ПРЕДИСЛОВИЕ

Стандарты Aeronautical Radio, Inc., the AEEC и ARINC

Компания Aeronautical Radio, Inc. (ARINC) была создана в 1929 году четырьмя новыми авиакомпаниями в США в качестве частной компании для обслуживания систем связи авиапромышленности. В настоящее время все крупные авиакомпании США остаются главными акционерами Компании. Другими акционерами являются несколько неамериканских авиакомпаний и других операторов воздушных судов.

ARINC спонсирует комитеты в авиапромышленности и участвует в соответствующей деятельности в рамках отрасли, которая выгодна авиации в целом, путем предоставления технического лидерства, руководства и управления частотами. Эти виды деятельности непосредственно поддерживают цели авиакомпаний: содействовать безопасности, эффективности, бесперебойности и экономической эффективности воздушных операций.

Комитет по авиационной электронной технике (AEEC) является международным органом технических профессионалов в авиации, который ведет разработку технических стандартов для бортового электронного оборудования, включая авионику и бортовое развлекательное оборудование, используемое на коммерческих, военных и транспортных судах. AEEC создает на основе консенсуса, в добровольной форме стандарты годности, функционирования и интерфейсы, которые публикуются ARINC как Стандарты ARINC. Использование Стандартов ARINC приносит существенную выгоду авиакомпаниям, позволяя обеспечивать взаимозаменяемость и унифицированность авионики и сокращая расходы на авионику путем развития конкуренции.

Существуют три класса Стандартов ARINC:

a) Характеристики ARINC – определяют форму, годность, функции и интерфейсы авионики и другого бортового электронного оборудования. Характеристики ARINC предоставляют перспективным изготовителям бортового электронного оборудования согласованное и скоординированное мнение авиационного технического сообщества в отношении требований к новому оборудованию, включая стандартизированные физические и электрические характеристики, для повышения взаимозаменяемости и конкуренции.

b) Спецификации ARINC – используются главным образом для определения или физической упаковки или монтажа авионики, стандартов обмена данными или компьютерного языка высокого уровня.

c) Отчеты ARINC – содержат указания или общие сведения, которые авиакомпании считают хорошей практикой, часто связанной с техническим обслуживанием и содержанием авионики.

Выпуск Стандарта ARINC не обязывает любую авиакомпанию или ARINC приобретать указанное в нем оборудование, также он не устанавливает признания или наличия требований к эксплуатации такого оборудования, равно как и не составляет одобрения изделия любого изготовителя, разработанного или изготовленного по Стандарту ARINC.

Для облегчения постоянного совершенствования изделия по данному Стандарту ARINC в заключительную часть данной публикации включены два заявления:

Отчет об ошибках просит сообщать о любых изменениях, которые необходимо внести в текст или схемы данного Стандарта ARINC.

Форма ARINC IA по инициации/модификации проекта просит давать любые рекомендации для добавления важной информации к данному документу, которая составит новое Дополнение.



СОДЕРЖАНИЕ

1.1 Цель документа

1.2 Объем документа

1.3 Организация документа

1.3.1 Спецификация ARINC 664, Авиационная сеть передачи данных

1.4 Сопутствующие документы

1.4.1 Отношение данного документа к другим Стандартам ARINC

1.4.2 Отношение к отраслевым стандартам

1.4.3 Документы RTCA и EUROCAE

1.5 Приоритет документов

1.6 Утверждение регулирующего органа

2.0 ОБЩИЕ СВЕДЕНИЯ

2.1 Сравнительная модель

2.2 Коммутируемые сети Ethernet

2.3 Расширяемость

2.4 Порядковая целостность

2.5 Сбои в работе системы

2.6 Коммутация

2.7 Эксплуатационные параметры системы

3.0 СПЕЦИФИКАЦИЯ ОКОНЕЧНОЙ СИСТЕМЫ

3.1 Введение

3.1.1 Определение ОС

3.2 Взаимодействие и детерминизм на уровне протокола управления доступом (MAC)

3.2.1 Виртуальный канал передачи данных

3.2.2 Управление рабочей нагрузкой/трафиком

3.2.3 Распределение времени

3.2.4 Эксплуатационные характеристики оконечной системы

3.2.4.1 Латентность

3.2.4.2 Ограничения MAC

3.2.4.3 Дрожание

3.2.5 Адресация по MAC

3.2.5.1 Адрес назначения по MAC

3.2.5.2 Адрес источника по MAC

3.2.6 Понятие резервирования

3.2.6.1 Порядковые номера и посылающая оконечная система

3.2.6.2 Порядковые номера и принимающая оконечная система

3.2.6.2.1 Проверка целостности

3.2.6.2.2 Управление резервированием

3.3 Взаимодействие на уровне IP и выше



3.3.1 Службы авионики

3.3.1.1 Порты сообщений

3.3.1.1.1 Службы стробирования авионики

3.3.1.1.1.1 При передаче

3.3.1.1.1.2 При приеме

3.3.1.1.2 Служба ожидания авионики



3.3.1.2 Порт SAP

3.3.1.2.1 Службы для соответствующей сети

3.3.1.2.2 Управление ошибками в порту SAP

3.3.1.2.3 Службы передачи файлов

3.3.1.3 Субвиртуальная линия

3.3.2 Типичный пример протокола передачи файлов

3.3.3 Стек сообщений в ОС

3.3.3.1 MAC-профиль ОС

3.3.3.2 IP-профиль ОС

3.4 Взаимодействие на уровне сетей

3.4.1 Адресация

3.4.1.1 Введение

3.4.1.2 Структура кадра AFDX без фрагментации

3.4.1.3 Идентификация сквозной связи

3.4.1.3.1 Связь внутри AFDX

3.4.1.3.2 Связь вне AFDX

3.4.1.4 Формат IP-адресации

3.4.1.4.1 IP-адрес источника

3.4.1.4.2 IP-адрес назначения

3.4.1.5 Порт связи AFDX, SAP и формат адресации UDP/TCP

3.4.1.5.1 Порты связи в AFDX

3.4.1.4.1 Порты в SAP

3.4.1.5.1 Распределение номеров портов связи в SAP и AFDX

4.0 СПЕЦИФИКАЦИЯ КОММУТАТОРА

4.1 Основные понятия

4.1.1 Фильтрация и введения функции определение политики

4.1.1.1 Параметры управления и фильтрации

4.1.1.2 Фильтрация кадров

4.1.1.3 Политика в отношении трафика

4.2 Функция фильтрации и определение политики

4.2.1 Фильтрация кадров



4.2.2 Политика управления трафиком

4.4 Функция коммутации

4.5 Функция оконечной системы коммутатора

4.5.1 Общий обзор

4.5.2 Политика адресации

4.6 Функция мониторинга

4.7 Файлы конфигурации

4.7.1 Введение

4.7.2 Таблица конфигурации по умолчанию

4.7.2.1 Физический порт по умолчанию

4.7.2.2 Конфигурация приема по умолчанию

4.7.2.3 Конфигурация передачи по умолчанию

4.7.3 Таблицы конфигурации, загружаемые в поля: файл конфигурации OPS

4.7.3.1 Таблица конфигурации оконечной системы

4.7.3.2 Таблица фильтрации-управления и конфигурации посылки

4.8 Режимы эксплуатации

4.8.1 Общий обзор

4.8.2 INIT

4.8.2.1 IПоследовательность инициализации

4.8.2.2 Земля_Условия

4.8.3 OPS: Режим эксплуатации

4.8.4 DL: Режим загрузки данных

4.8.5 SHOP (по выбору)

4.8.6 PASSIVE

4.8.7 QUIET

4.9 Загрузка данных

4.9.1 Общие требования к загрузке данных

4.9.2 Идентификация конфигурации

4.9.2.1 Определение конфигурации коммутации

4.9.2.2 Идентификация конфигурации включения коммутации

4.9.3 IP-адрес загрузчика данных

4.10 Программирование выводов

4.10.1 Обработка программирования выводов

4.10.1.1 Когда следует читать программирование выводов

4.10.1.2 Проверка четности и обработка

4.10.2 Список программирования выводов

4.10.2.1 Кодирование позиций

4.11 Эксплуатационные характеристики

4.11.1 Общие характеристики



4.11.2 Характеристики физического уровня

4.11.3 Возможности обработки

5.0 СИСТЕМНЫЕ ВОПРОСЫ

5.1 Производительность

ДОПОЛНЕНИЯ

1 Формат данных

2 Положения по профилям протоколов IP/ICMP, UDP и TCP 94

ПРИЛОЖЕНИЯ

A Пример идентификации ОС

B Инструкции по форматированию из ARINC 429 в AFDX

C Сетевая терминология

D Службы отображения протокола

Стандарт ARINC – Отчет об ошибках

Форма ARINC IA по инициализации/модификации проекта (APIM)



1.0 ВВЕДЕНИЕ

1.1 Цель документа

Цель настоящего документа заключается в том, чтобы определить детерминированную сеть: коммутируемую бортовую сеть Ethernet (AFDX™). AFDX™ является товарным знаком компании Airbus и используется с разрешения. В настоящем документе также описаны дополнительные требования к эксплуатации систем авионики в контексте AFDX.

Данная спецификация позволяет:

• системным интеграторам рассчитывать критические системы полета, используя AFDX;

• разработчикам оборудования определять оборудование, взаимодействующее с AFDX.

1.2 Объем документа

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

• Канал передачи данных: MAC, понятие адресации виртуальной линии связи

• Сеть: IP, ICMP

• Передача: UDP, TCP (по выбору)

• Уровни применения сети: выборка, ожидание, SAP, TFTP и SNMP

Настоящий документ будет ограничен описанием нормативных протоколов, упомянутых выше.

КОММЕНТАРИЙ

Разработчики систем могут добавлять другие протоколы в конкретных случаях (например, FTP на уровне применения сети), но нет гарантии, что ТЭЗ, соответствующий AFDX, примет этот дополнительный протокол.

Физический слой здесь не указывается, но должен быть любым из решений, определенных в ARINC 664, Часть 2.

Это означает, что любой ПЗФ, соответствующий AFDX (включая коммутатор), может быть подсоединен к любой сети AFDX, так как должны соблюдаться требования к форме и пригодности (конкретные для системы и не указанные в настоящем документе. КОММЕНТАРИЙ

Взаимозаменяемый коммутатором AFDX может быть определен в Спецификации ARINC серии 700 или 900.

1.3 Организация документа

1.3.1 Спецификация ARINC 664 на бортовую сеть передачи данных

Спецификация ARINC 664 определяет для установки на воздушные суда сеть передачи данных Ethernet. Она разработана несколькими частями, перечисленными ниже:

Часть 1 - Понятия и общий обзор систем Concepts and Overview

Часть 2 - Физические спецификации и спецификации канальных уровней Ethernet

Часть 3 - Протоколы и службы Internet

Часть 4 - Структуры адресов и присваиваемые номера Internet

Часть 5 - Службы и функциональные элементы взаимосвязи между сетями

Часть 6 - Резервируется

Часть 7 - Бортовая коммутируемая дуплексная сеть Ethernet (AFDX) Часть 8 - Службы верхних уровней

1.4 Сопутствующие документы

1.4.1 Отношение данного документа к другим Стандартам ARINC



При разработке стандартов для систем и подсистем авионики, в которых используются возможности, предоставляемые данной спецификацией, они должны учитывать положения данной спецификации путем ссылки. Ссылки на данную спецификацию должны предполагать применение наиболее свежей версии данной Спецификации. Перечень других документов ARINC, которые относятся к данной спецификации, приведен ниже.

Спецификация ARINC 653: Стандарт на прикладные программы для авионики

Спецификация ARINC 615A: Устройство загрузки данных с использованием интерфейсов Ethernet

Спецификация ARINC 665: Стандарты на загружаемое программное обеспечение

1.4.2 Отношение к отраслевым стандартам

Стандарт IEEE Standard 802.3, Выпуск 2000, считается неотъемлемой частью настоящей спецификации и его необходимо изучить. В настоящем документе при ссылке на этот стандарт его название сокращается до "IEEE 802.3."

1.4.3 Документы RTCA и EUROCAE

RTCA и EUROCAE разрабатывают Стандарты минимальных эксплуатационных параметров (MOPS), которые применяются к бортовому электронному оборудованию, системам и процессам. К данной Спецификации относятся последние версии следующих документов RTCA и EUROCAE: RTCA DO-160/EUROCAE ED-14: Окружающие условия и порядок испытаний бортового оборудования. В данном документе при ссылке на этот стандарт его название сокращается до "DO-160."

RTCA DO-254: Руководство по проектным гарантиям на бортовое электронное оборудование.

RTCA DO-178B: Руководство по проектным гарантиям на бортовое программное обеспечение.


Особые уровни производительности, установленные в документах RTCA/EUROCAE, определяются интегратором бортовых систем в соответствии с применением.

1.5 Приоритет документов

Данная Спецификация основана на стандарте IEEE 802.3. Главной целью данной Спецификации является определение изменений в положениях IEEE 802.3 в тех случаях, когда аэронавигационное оборудование или пользователь входит в конфликт с положениями IEEE 802.3, или когда необходимо устранить непонятные моменты путем ограничения элементов, доступных инженерам. Содержание данной Спецификации ограничено описанием таких изменений и ограничений элементов. В случае противоречия между данной Спецификацией и действующими стандартами ISO и IEEE данная Спецификация имеет приоритет. 1.6 Утверждение регулирующего органа

Применение данного стандарта должно соответствовать всем применимым регулирующим требованиям. Изготовителям настоятельно рекомендуется получить всю необходимую информацию для такого утверждения регулирующим органом. Такая информация в данной Спецификации не содержится, и от ARINC ее получить нельзя.



2.0 ОБЩИЕ СВЕДЕНИЯ

Бортовая сеть передачи данных описана в данном стандарте в качестве профилированной версии сети Ethernet по стандарту IEEE 802.3 с использованием IP-протоколов адресации и соответственной передачи. В Части 7 описана часть этой системы для случаев, когда самую большую важность имеет качество обслуживания, включая своевременную доставку.

Рис. 2-1 – Иерархия сетей

AFDX является специальным случаем профилированной сети. Детерминированная сеть может сообщаться в более широкой профилированной сетью и путем вмешательства с соответствующей сетью через маршрутизатор или шлюзы. На Рис. 2-1 показана эта иерархия сетей. Более подробная информация о протоколах, используемых сетевыми службами, содержится в Приложении C. Системы управления, в общем, и системы авионики в частности основаны на своевременной и полной доставке данных от источника к получателю. Для безопасности необходимы каналы связи «в реальном времени» критических систем. 2.1 Сравнительная модель

В качестве сравнения вопросов синхронизации полезно сравнить сеть Ethernet с обычной бортовой шиной передачи данных. Примеры, показанные на рис. 2-2, подразумевают последовательные сообщения без ошибок/повторных попыток.

Рис. 2-2 – Шина 429 ARINC

Детерминированные сети Соответствующие

сети (IEEE802.3 и IP)

Профилированные сети



Параметрами в данном примере являются:

Ts = латентность доставки через оконечную систему источника

Tm = синхронизация сообщения (длина -s- пропускная способность)

Tr = латентность доставки через оконечную систему получателя

и совокупная латентность, L, равна:

L = Ts + Tm + Tr

Так как пропускная способность фиксированная, конфликтов не существует, и латентность оконечной системы постоянная, время, необходимое для передачи сообщения по сети от отправителя получателю постоянное. Оконечные системы других получателей могут принять то же сообщение, не воздействуя на его синхронизацию, тогда как второй источник, соединенный с LRU c, будет эффективно принят независимой оконечной системой.

Эта сеть с двухточечным соединением является почти идеально детерминированной. Время доставки сообщения может быть вычислено и является постоянным. Увеличение пропускной способности приводит к сокращению синхронизации сообщений. Надежность может быть определена путем анализа или испытаний на месте, и может использоваться резервная система.

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

2.2 Коммутируемые сети Ethernet

В системе с многими оконечными станциями последовательный монтаж проводов является крупной проблемой. Сети Ethernet обладают значительными преимуществами, и подходящую модель детерминированной сети можно получить посредством эмуляции прямых соединений. Раздел сети Ethernet, коммутируемой по топологии звезда, которая обеспечивает такие же возможности соединения как и ARINC 429 показан на Рис. 2-3.

Время задержки в таких узлах не устанавливается только задержками в аппаратуре; существует переменная величина – дрожание , которая вызывается конфликтами данных в сети. Обычно сеть анализируется на аккумулируемую латентность (включая аппаратные задержки и эффекты дрожания) и пропускную способность канала связи. Синхронизация компонентов Ethernet показана на Рис. 2-3.

Рис 2-3 – Синхронизация в сети Ethernet

В данном простом примере передатчики двух оконечных систем (ES a и ES b) предлагают данные для использования приемником ES c, кадры передаются через коммутатор SWa. Одновременный прием кадров от ESa и ESb коммутатором осуществляется очередностью двух кадров для дальнейшей передачи ES c, причем максимальное дрожание зависит от длины сообщения:

Tj = (8 x M) / Nbw + Tmin_gap (предполагаются кадры одинакового размера).



где: Tj = время дрожания M = размер кадра в октетах Nbw = пропускная способность среды в битах в секунду Tmin_gap = минимальный промежуток между кадрами, в секундах

Латентность для первого кадра:

La = Ts + Tm1 + Tsw + ( 8 x M )/Nbw + Tm2 + Tr

где: Tsw = латентность аппаратуры при коммутировании, в секундах Tm/ = синхронизация сообщения (длина / пропускная способность) Латентность для

задержанного кадра:

Lb = La + Tj

Отсюда, если Tw является суммарной латентностью в коммутаторе, в секундах (Tsw + латентность выходного буфера), то Tw, относимая на порт выхода, зависит от потока трафика в этом порте выхода. В асинхронной сети для любого конкретного потока данных Tw будет изменяться со временем.

КОММЕНТАРИЙ Конфликт в коммутаторе и возможности хранения и направления приводят к необходимости буферизировать полные кадры.

Отсюда, задержка кадра, (8 x M)/Nbw, дважды появляется в выражении для Lb.

КОММЕНТАРИЙ Понятие дрожания, указанное здесь, является лишь вводной информацией. Читатель должен обратиться к Главам 3 и 4 за подробным определением дрожания в сети AFDX.

При нормальной работе система остается детерминированной для обоих каналов данных (a - c) и (b - c) с латентностью, содержащей такое дрожание. Для поддержания максимальной целостности системы в случае отказа ESa или ESb, определение «качества обслуживания» (КО) может включать продолжение передачи данных из исправного узла. Это подразумевает характеристики фильтрации в коммутаторе, которые обычно в товарных коммутаторах не применяются, и являются одним методом определения неисправности, который может обеспечить детерминированное соединение между двумя исправными оконечными системами.

В типичной сети Ethernet анализ предполагает, что передающие оконечные системы не синхронизированы, и что передача кадра происходит путем произвольного распределения прибытия. Это подразумевает распределение эмиссии по Пуассону, и хотя в среднем пропускная способность известна, в произвольный короткий период времени пропускная способность будет неограниченной. Поэтому, распределение латентности на каждом соединении в сети соответствует распределению, которое также будет неограниченным. Это приведет к вероятностному описанию латентности в сети. Кроме того, в типичной сети Ethernet не существует метода ограничить фактическое распределение прибытия данных из любой одной оконечной системы с распределением Пуассона по произвольно малому интервалу времени. Поэтому невозможно ограничить эффект выхода за параметры пропускной способности оконечной системы.

В сети AFDX анализ также предполагает, что передающие оконечные системы не синхронизированы, но что доставка кадров соответствует распределению ограниченного прибытия. Такое ограниченное прибытие подразумевает управление точной пропускной способностью регулируемого трафика. Поэтому, распределение латентности на каждом соединении в сети соответствует распределению, которое ограничено. Это приводит к вычисляемой максимальной латентности в сети, а не к вероятностной латентности. Использование управления регулируемым трафиком при точной пропускной способности возможно для ограничения использования пропускной способности в произвольно малый интервал времени. Поэтому, возможно ограничивать эффект выхода за параметры пропускной способности оконечной системы.

Чтобы продолжить аналогию с ARINC 429, каждый проводной канал передачи данных между двумя точками может быть заменен в детерминированной сети Ethernet «виртуальным каналом передачи» (VL). Характеристики каждого VL могут быть определены путем анализа, предполагая управление регулируемым трафиком при точной пропускной способности, как показано на Рис. 2-4. Это достигается путем ограничения, как пропускной способности, так и интервала доставки кадра для



каждого VL.

Figure 2-4 – Управление регулируемым трафиком

Максимальной пропускной способностью для этого VL будет: Lmax/TGAP.

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

2.3 Расширяемость Выбор топологии сети также будет влиять на расширяемость конструкции любой системы. Для системы AFDX использовалась топология каскадной звезды из-за ее легкой расширяемости.

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

2.4 Порядковая целостность Профилированные сети не дают гарантии поддержания порядковой целостности кадров в сети.

Бортовые сети часто содержат данные, для которых порядок имеет большое значение. Если существует связь между последовательными кадрами, должна поддерживаться порядковая целостность. По этой причине система AFDX требует порядковой целостности кадров в виртуальном канале передачи.

2.5 Работа при сбое В топологии сети Ethernet нельзя рассматривать каждый канал передачи данных по отдельности для цели анализа параметров. Необходим механизм, обеспечивающий, чтобы если один канал передачи данных выходит из строя, детерминированные характеристики остальной сети сохранялись. Система AFDX предусматривает такой механизм в ее функциональных блоках.

2.6 Коммутация В товарном коммутаторе пути соединения создаются посредством использования алгоритма «учись и набирайся опыта». Создание пути для нового или известного источника данных приведет к неизвестной латентности.

2.7 Эксплуатационные параметры системы Детерминированные характеристики сети с асинхронными оконечными устройствами можно оценить, только проанализировав топологию данной сети. Для каждого потока данных можно получить максимальную латентность как гарантию производительности.

Время



3.0 СПЕЦИФИКАЦИЯ ОКОНЕЧНОЙ СИСТЕМЫ

3.1 Введение

Главная функция оконечной системы (ОС) является предоставление служб, которые гарантируют защищенный и надежный обмен данными для частей программного обеспечения.

Качество обслуживания (КО) обеспечивает метод категоризации трафика и обеспечения того, чтобы конкретные категории трафика всегда проходили по сети на том уровне обслуживания, к которому они относятся, независимо от конфликтующих требований.

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

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

Поэтому гарантированное обслуживание обеспечивает и ограниченную по верхнему пределу задержку и постоянную пропускную способность, что ведет к логически открытому соединению между одним передающим узлом и одним или несколькими принимающими узлами. Кадры, относящиеся к одному соединению, образуют поток.

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

• гарантируются пропускная способность и ограниченная латентность;

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

Описание аппаратных средств оконечной системы показано на Рис. 3-1:

Рис. 3-1 – Уровни протоколов оконечной системы

Avionics Application = Применение в авионике File Tranfer TFTP = Протокол передачи файлов TFTP



Maintenance Application = Применение в техническом обслуживании Data loading = Загрузка данных TFTP Protocol = Протокол TFTP SNMP agent = Агент SNMP SNMP Protocol = Протокол SNMP Port Sampling = Выборка портом Port Queing = Формирование очередей портом APPLICATION = ПРИМЕНЕНИЕ PRESENTATION = ПРЕДСТАВЛЕНИЕ SESSION = СЕАНС TRANSPORT = ПЕРЕДАЧА NETWORK = СЕТЬ LINK = КАНАЛ ПЕРЕДАЧИ PHYSICAL = ФИЗИЧЕСКИЙ УРОВЕНЬ Option =Элемент Virtual Link = Виртуальный канал передачи Management Information Base = База с информацией об управлении Уровень сети (Детерминированные характеристики) ETHERNET PHY (ARINC 664 Part2)

3.1.1 Идентификация ОС

Системному интегратору необходимы не большее 16 бит для идентификации ОС. Пример идентификации ОС с использованием 12 бит приведен в Приложении B.

3.2 Взаимодействие и детерминизм на уровне протокола управления доступом (MAC)

3.2.1 Виртуальный канал связи

Описание концепции «виртуального канала связи» представлено на Рис. 3-2, так как она широко используется в данном документе.

Оконечная система может быть разработана только для приема VL, но не для передачи VL, или наоборот; поэтому ОС может являться источником передачи или приема нулевых VL. Оконечные системы обмениваются Ethernet-кадрами через VL. Только одна оконечная система в бортовой сети должна являться источником любого одного VL.

Виртуальный канал является концептуальным коммуникационным объектом, который имеет следующим свойства:

• виртуальный канал определяет логическую однонаправленную связь от одной оконечной системы – источника до другой или нескольких оконечных систем - назначения, что показано на Рис. 3-2.

Рис. 3-2 – Виртуальный канал = Путь

End-system = Оконечная система

• Каждый виртуальный канал имеет выделенную максимальную полосу пропускания. Эта полосу определяет системный интегратор.

ОС должна обеспечить логическое отделение в отношении доступной пропускной способности среди виртуальных каналов, которые она поддерживает. Независимо от попытки использования VL одним разделом на доступную пропускную способность любого другого VL это не влияет.



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


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

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

3.2.2 Управление потоком/трафиком

На выходе оконечной системы поток кадров, относящийся к конкретному виртуальному каналу, характеризуется двумя параметрами: интервалом в распределенной пропускной способности (BAG) и ДРОЖАНИЕМ.

Если кадры не испытывают дрожания от планировщика (см. Раздел 3.2.3 «Планирование»), BAG представляет минимальный интервал времени между первыми битами двух последовательных кадров из одного VL, как показано на Рис. 3-3 и 3-4.

jitter = Дрожание

Рис. 3-3 - BAG в VL при потоке данных в максимальной пропускной способностью

jitter = Дрожание

Рис. 3-4 - BAG в VL при потоке данных при не максимальной пропускной способности


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

Для того, чтобы гарантировать BAG для каждого VL, поток кадров регулируется так, как показано на Рис. 3-5.

Unregulated Flow = Нерегулируемый поток Flow at the output of the regulator (single VL) = Поток на выходе регулятора (одного VL)

Рис. 3-5 – Регулирование потока в виртуальном канале

3.2.3 Планирование

В передающей оконечной системе с несколькими VL планировщик мультиплексирует различные потоки, исходящие от регуляторов, как показано на Рис. 3-6.



Unregulated flows of Post fragmented packets = Нерегулируемые потоки пакетов после фрагментации Traffic Regulator = Регулятор трафика Regulated flows = Регулируемые потоки Jitter = Дрожание Scheduler MUX = Планировщик - мультиплексор Single multiplex flow = Единый мультиплексный поток

Рис. 3-6 – Модель механизма планируемого управления потоками

На выходе планировщика кадры для любого заданного виртуального канала могут появляться с ограниченным интервалом времени. Этот интервал определяется как максимально допустимое дрожание. Это дрожание вводится планировщиком, а не самим потоком трафика, что показано на Рис. 3-7.

Max. Jitter = Максимальное дрожание Frame = Кадр

Рис. 3-7 – Влияние дрожания на максимальную пропускную способность потока данных

Оконечная система регулирует передаваемые данные на основе VL, так как эта функция формирования трафика (точное знание характеристик потока) является основой анализа детерминизма.

На основе отдельных VL регулятор трафика (функция формирования трафика) должен формировать поток так, чтобы не посылать больше одного кадра в каждый интервал BAG в миллисекундах.


Цель функции формирования трафика заключается в ограничении мгновенной скорости кадров в виртуальных каналах путем введения интервалов между кадрами. Регулятор должен управлять пропускной способностью, данной виртуальному каналу согласно BAG.

Максимально используемая пропускная способность каждого VL характеризуется его BAG и его разрешенным Lmax (максимальный размер кадра VL). Максимально используемая пропускная способность = Lmax / BAG в килобайтах в секунду.

Оконечная система должна вмещать VL кадры до размера 1518 байт, как при передаче, так и при приеме.

Для каждого VL оконечная система должна иметь одно значение BAG, выбранное из таблицы конфигурации оконечной системы.




Оконечная система конфигурируется с использованием файла таблицы конфигурации. Подробная информация об этой таблице не входит в рамки данного документа.

Функция формирования трафика ОС должна быть способна обрабатывать значения BAG в диапазоне от 1 мс до 128 мс. Эти значения должны удовлетворять следующему условию: BAG=2k [в мс], (k = целое число от 0 до 7).


Если раздел должен передавать данные менее часто, чем через 128 мс, будет использоваться значение BAG 128. Значения BAG ограничены степенями 2 для того, чтобы упростить конструкцию ОС.

3.2.4 Эксплуатационные характеристики оконечной системы

Главная цель системного интегратора заключается в том, чтобы обеспечивать возможность использования оконечной системы AFDX детерминистским образом. Создавая меру производительности ОС, AFDX предлагает системному интегратору уменьшенную нагрузку сертификации и гибкое решение с четко определенными ограничениями.

3.2.4.1 Латентность

Латентность при передаче определяется как продолжительность между следующими точками измерения, как показано на Рис. 3-8.

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

• Конец – последний бит соответствующего кадра Ethernet передается по физической среде

Измерения технологической латентности осуществляются при пустых буферах, без ресурсов, конфликтующих из-за доступа и без IP фрагментации, как показано на Рис. 3.8.



Applications = Виды применения Application Programming Interface = Интерфейс программирования применения API Interface = Интерфейс программирования применения End-System Driver = Драйвер оконечной системы End-System Mailbox = Почтовый ящик оконечной системы Communications Services = Коммуникационные службы AFDX com port = Коммуникационный порт AFDX Sampling = Выборка Queuing = Формирование очередей SAP = Протокол извещения о службах UDP IP = Протокол датаграмм пользователя /Протокол Интернета Other VLs = Другие VL Scheduler = Планировщик Redundаncy Management = Управление резервированием Physical Layer = Физический слой Latency in Transmission = Латентность при передаче End System Dedicated Interface = Выделенный интерфейс оконечной системы Host Processor Sequencer = Секвенсер главного процессора AFDX End-System Hardware = Аппаратное обеспечение оконечной системы ADFX

Рис. 3-8 – Точки Tx измерения производительности

Технологическая латентность оконечной системы при передаче должна ограничиваться и быть меньше 150 пс + задержка кадра.


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

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

«Задержка кадра» добавляется для того, чтобы учесть время, требуемое для доставки кадра к физическому слою.

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

• Начало – последний бит кадра Ethernet получен на физическом медиа носителе.

• Конец – последний бит соответствующих данных доступен для принимаемого раздела оконечной системы.

Измерения технологической латентности осуществляются при пустых буферах, без ресурсов, конфликтующих из-за доступа, как показано на Рис. 3-9.

Applications = Виды применения Application Programming Interface = Интерфейс программирования применения API Interface = Интерфейс программирования применения End-System Driver = Драйвер оконечной системы End-System Mailbox = Почтовый ящик оконечной системы Communications Services = Коммуникационные службы AFDX com port = Коммуникационный порт AFDX Sampling = Выборка Queuing = Формирование очередей SAP = Протокол извещения о службах UDP IP = Протокол датаграмм пользователя /Протокол Интернета Other VLs = Другие VL Scheduler = Планировщик Redundаncy Management = Управление резервированием Physical Layer = Физический слой Latency in Transmission = Латентность при передаче End System Dedicated Interface = Выделенный интерфейс оконечной системы Host Processor Sequencer = Секвенсер главного процессора



AFDX End-System Hardware = Аппаратное обеспечение оконечной системы ADFX

Рис. 3-9 – Точки Rx измерения производительности

Технологическая латентность оконечной системы при приеме должна ограничиваться и быть меньше 150 мкс.

3.2.4.2 Ограничения протокола MAC (управления доступом к среде)

Для того чтобы избежать потерь входящих кадров во время приема пакета и зафиксировать интервал между кадрами (IFG) при передаче, уровень MAC оконечной системы должен быть способен:

• обрабатывать получаемые кадры на максимальной скорости среды и предоставлять соответствующие (выбранные) кадры разделу максимальной кадровой скорости среды;

• передавать кадры туда и обратно.

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

64 байта (кадр) + 12 байтов (IFG) + 7 байтов (заголовок) + 1 байт (SFD – ограничитель начального кадра) = 84 байта должно быть передано со скоростью 100 Мбит/с.

Это эквивалентно продолжительности 6,72 мкс на кадр (примерно148 800 кадров в секунду).


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

Это требование более строгое в смысле возможностей обработки самого короткого кадра (64 октета) при минимальном интервале между кадрами (12 октетов).

3.2.4.3 Дрожание



При передаче максимально допустимое дрожание в каждом VL на выходе оконечной системы должно соответствовать обоим следующим условиям:

Примечание: максимальное дрожание выражается в микросекундах (мкс); Nbw является средней пропускной способностью в бит/с; Lmax выражается в октетах, 40 мкс является типичным минимальным фиксируемым технологическим дрожанием.

Согласно вышеприведенной формуле максимально допустимое дрожание будет ниже для оконечных систем, имеющих мало виртуальных каналов и обрабатывающих кадры небольшого размера. Во всех случаях дрожание ограничивается 500 мкс для ограничения воздействия на детерминизм всей сети.


Для ОС с большой нагрузкой (при передаче) оптимизированное планирование при передаче может дать возможность соответствовать второй формуле. Системный интегратор должен определить, что для выбранной конфигурации и выполнения оконечной системы предел 500 мкс не превышен.

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

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

В первом случае предполагается, что разделы-хозяева передают на определенный VL равномерно распределенные данные (без пакетов) и что данные не нуждаются в фрагментации. Тогда, если оконечная система не имеет других данных для обработки на этом виртуальном канале, суммарная допустимая латентность для данного VL составит:

MAX_Latencyi ≤ BAGi + Max_jitter + Технологическая_латентность_при_передаче

Второй случай применяется, когда принимаемый раздел передает пакеты данных или длинные сообщения, требующие фрагментации. В этом случае, если оконечная система имеет другие данные для обработки на этом виртуальном канале, передача следующих данных будет задержана. Для данного VL при передаче и если обрабатываются кадры (p-1), максимальная латентность кадра с номером р должна быть ограничена по следующей формуле:

MAX_Latencyi (кадр р) ≤ р * BAGi + Max_jitter + Технологическая_латентность_при_передаче

Передача будет задержана согласно ограничению пропускной способности VL (формирование трафика).


Некоторые конфигурации могут давать оптимизированное решение в отношении латентности конфигурации. Во всех случаях указанные выше значения должны соблюдаться.

3.2.5 Адресация по МАС

3.2.5.1 Адрес назначения по МАС

Виртуальный канал должен определяться адресом назначения по протоколу МАС только так, как показано на Рис. 3-10, и исходный адрес кадров AFDX исходного адреса по МАС должен являться однонаправленным адресом по МАС, используемым для идентификации физического интерфейса Ethernet.

Адрес назначения по MAC в кадре AFDX должен являться групповым и локально администрируемым адресом и должен соответствовать следующему формату.

48 бит

Постоянное поле 32 бит Идентификатор виртуального канала 16 бит



XXXX XX11 XXXX XXXX XXXX XXXX XXXX XXXX

Рис. 3-10 – Формат многонаправленной адресации по МАС

Каждая ОС должна получить значения «постоянного поля» и «Идентификатора виртуального канала от системного интегратора. Эти значения в ARINC 664 не определены.

Постоянное поле должно быть одинаковым для каждой ОС в любой сети AFDX. Самый младший бит первого байта указывает адрес группы (всегда =1).

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

Второй после младшего бит первого байта указывает локально администрируемый адрес (всегда = 1).


Даже если на уровне MAC могут использоваться только адреса групп, однонаправленная связь может рассматриваться на уровне IP путем использования адреса однонаправленного назначения IP.

3.2.5.2 Адрес источника по MAC

Адрес источника по МАС должен быть индивидуальным и локально администрируемым адресом, соответствующим IEEE 802.3. Структура адреса определена в последующих параграфах.


Нельзя рекомендовать какой-либо конкретный алгоритм построения адреса источника по МАС. Поэтому для оконечных систем AFDX необходимо иметь средство определения алгоритма построения адресов для использования в сети, куда они помещаются. Например, в качестве средства указания, какое правило построения адреса использовать, можно использовать программирование выводов.

Идентификация контроллера МАС для Ethernet (48-битного) Постоянное поле: 24-

битное Имя, определяемое

пользователем (16-битное) Имя интерфейса, 3-

битное Постоянное поле: 5-

битное "0000 0010 0000 0000

0000 0000" "nnnn nnnn nnnn nnnn" mmm "0 0000"

Рис. 3-11 – Формат адресации источников по MAC

Постоянное поле устанавливается на "0000 0010 0000 0000 0000 0000", как показано на Рис. 3-11.

Младший бит первого байта указывает индивидуальный адрес = 0.

Следующий после младшего бита первого байта указывает локально администрируемый адрес = 1.

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

Имя интерфейса, определенное на Рис. 3-12, указывает, с какой резервной сетью AFDX соединен контроллер Ethernet MAC.

Имя интерфейса Значение 000 Не используется001 Контроллер Ethernet MAC соединен с сетью A010 Контроллер Ethernet MAC соединен с сетью В011 Не используется100 Не используется101 Не используется110 Не используется111 Не используется

Рис. 3-12 – Определение имени интерфейса

3.2.6 Понятие резервирования

Оконечные системы сообщаются по многим независимым и резервным сетям, так чтобы потоки



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

Per VL End System Transmit = Передача оконечной системы по VL B Network = Сеть В A Network = Сеть А Per VL End System Receive = Прием оконечной системы по VL

Рис. 3-13 – Понятие резервирования сети

На Рис. 3-13 показано базовое понятие резервирования сети. Схема резервирования работает на основе по виртуальному каналу. Передающая оконечная система и принимающая оконечная система сообщаются по конкретному виртуальному каналу следующим образом.

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

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

Как показывает поток кадров на Рис. 3-14, RM (управление резервированием) помещено после IC (проверка целостности). При бесперебойной работе сети IC только пропускает дальше кадры, которые она получила из сети, к RM. Функция управления резервированием AFDX заключается просто в том, чтобы устранить кадры, которые являются резервными копиями кадров, уже пропущенных в раздел.

A Network =Сеть А B Network = Сеть В MAC Layer = Уровень МАС End System = Оконечная система Integrity Checking = Проверка целостности



Detect and eliminate invalid frames = Выявление и устранение недействительных кадров Redundancy Management = Управление резервированием Eliminate redundant frames = Устранение резервных кадров IP, UDP/TCP layers = Уровни протоколов IP, UDP/TCP Application = Применение Netw. Mgmt = Управление сетью

Рис. 3-14 – Проверка целостности и управление резервированием в оконечной системе

Ожидаемые характеристики показаны на Рис. 3-15 - 3-18. Линия "RMA" относится к кадрам, переданным в раздел по алгоритму управления резервированием (алгоритм RMA).

Пример 1: Кадр, переданный с нарушением

Transmission = Передача Time of Transmission = Время передачи Reception Network A = Прием сетью А Time of Arrival = Время прибытия Reception Network B = Прием сетью В Integrity Checking Network A = Проверка целостности сетью А Integrity Checking Network B = Проверка целостности сетью В

Рис. 3-15 – Сеть B передает кадр с нарушением

Результат управления резервированием: кадр с нарушением не направляется в раздел.

Пример 2: Потеря кадра

Transmission = Передача Time of Transmission = Время передачи Reception Network A = Прием сетью А



Time of Arrival = Время прибытия Reception Network B = Прием сетью В Integrity Checking Network A = Проверка целостности сетью А Integrity Checking Network B = Проверка целостности сетью В

Рис. 3-16 – Кадр потерян в сети А

Из-за ошибки в разряде кадр «А4» потерян.

Результат управления резервированием: кадр поступивший в сеть В, принят.

Пример 3: Установка передатчика в исходное состояние

Transmission = Передача Time of Transmission = Время передачи Reception Network A = Прием сетью А Time of Arrival = Время прибытия Reception Network B = Прием сетью В Integrity Checking Network A = Проверка целостности сетью А Integrity Checking Network B = Проверка целостности сетью В reset of the transmitting equipment = установка передающего оборудования в исходное состояние

Рис. 3-17 – Установка передающей оконечной системы в исходное состояние

Потери кадра нет.

Пример 4: Многословие коммутатора (кадр застрял)

Transmission = Передача Time of Transmission = Время передачи



Reception Network A = Прием сетью А Time of Arrival = Время прибытия Reception Network B = Прием сетью В Integrity Checking Network A = Проверка целостности сетью А Integrity Checking Network B = Проверка целостности сетью В

Рис. 3-18 – Многословие в сети В

В примере 4 управление резервированием приводит к тому, что кадры не направляются на уровень протокола IP из-за проверки целостности.

3.2.6.1 Порядковые номера и передающая оконечная система

Для каждого VL оконечная система должна добавить порядковый номер для каждого переданного кадра в сети AFDX.

Порядковый номер кадра должен быть на один октет длиннее в диапазоне 0 - 255.


Достаточно трудно выявить резервные кадры при нормальной работе, но все же возможно. Например, в худшем случае, когда BAG = 1 мс, SkewMax = 5 мс, максимальный сдвиг между порядковыми номерами двух принятых кадров будет:

.,128,72 возвратучитыватьчтобыменьшенамногочтоBAG

SkewMaxInt

Для каждого VL порядковый номер должен быть первоначально установлен на 0. Порядковому номеру всегда присваивается это исходное значение после установки передающей ОС в исходное состояние.

Порядковый номер кадра должен увеличиваться на единицу для каждого следующего кадра того же VL и возвращаться к 1 после значения 255.


Увеличение на единицу делает возможным обнаружение недостающих кадров. Циклический возврат к 1 позволяет использовать максимальный диапазон порядковых номеров, резервируя при этом порядковый номер SN=0 для условия возврата в исходное состояние. Это улучшает проверку целостности (см. Раздел 3.2.6.2).

Порядковый номер кадра должен быть помещен сразу же полем MAC CRC, как часть полезной нагрузки MAC, как показано на Рис. 3-19.

bytes = Количество байт minimum Ethernet frame length = Минимальная длина кадра в Ethernet Preamble = Заголовок Start Frame Delimiter = Разделитель начального кадра Destination Address = Адрес назначения Source Address = Адрес источника Structure = Структура Payload = Полезная нагрузка Padding = Заполнение пробелами SN = Порядковый номер Frame Check Seq = Последовательность проверки кадра



Inter Frame Gap = Интервал между кадрами maximum Ethernet frame length = Максимальная длина кадра в Ethernet

Рис. 3-19 – Расположение порядкового номера в кадрах для минимальной и максимальной длины

Для упрощения алгоритма на принимающей оконечной системе резервные копии кадра должны посылаться с максимальной разницей во времени 0,5 мс.

На основе каждого VL ОС должна быть способна посылать сообщения в любую или обе сети. Это свойство должно быть конфигурируемым.


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

3.2.6.2 Порядковые номера и принимающая оконечная система

3.2.6.2.1 Проверка целостности

При бесперебойной работе сети проверка целостности просто пропускает кадры, которые она получает, к управлению резервированием, по отдельности для каждой сети. Если существуют сбои (основанные на порядковом номере), проверка целостности должна устранить недействительные кадры и информировать об этом управление сетью. Использование порядковых номеров смотрите в Разделе 3.2.6 «Понятие резервирования».

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

[PSN"+"1,PSN"+"2]

Где предыдущий порядковый номер (PSN) является порядковым номером полученного (но необязательно отправленного) предыдущего кадра на этом VL.

Оператор "+" учитывает циклический возврат порядковых номеров. Так, например, если PSN = 254, то PSN"+"1= 255 и PSN"+"2 = 1.


Эта функция увеличивает устойчивость целостности путем, например, устранения застрявших кадров или одиночных кадров с нарушением и уменьшения воздействия коммутатора многословия. Потеря одного одиночного кадра считается нормальным событием из-за не нулевой частоты появления ошибочных битов.

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

• полученный порядковый номер (RSN) равен 0;

• кадр является первым кадром, полученным после установки ОС в исходное состояние.

Кадры, которые не соответствуют этим условиям отбрасываются.


Эти особые случаи, в частности, улучшают целостность периодических данных. В ином случае происходили бы систематические потери кадров после установки в исходное состояние передающей ОС или принимающей ОС.

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

Должна иметься возможность на базе отдельных VL отключать проверку целостности на обеих сетях через таблицу конфигурации. Отключение проверки целостности позволяет получателю принимать все кадры от обеих сетей – А и В.

3.2.6.2.2 Управление резервированием

Управление резервированием (RM) предполагает, что сеть работает надлежащим образом и, в



частности, детерминированные свойства проверены.

Конфигурация RM обычно основана на параметре SkewMax: т.е. максимальном времени между приемом двух избыточных кадров. Это значение зависит от топологии сети (количества коммутаторов, пересекаемых кадрами) и должно предоставляться интегратором сети. Значение SkewMax (выраженное в мс) задается конфигурацией для каждого VL.

Определения:

• Избыточный VL означает, что через обе сети – А и В – проходят одни и те же кадры

• Не избыточный VL означает, что (возможно разные) кадры проходят через сети А или В

На основе каждого VL ОС должна быть способна принимать:

• избыточный VL и доставлять в раздел одни из избыточных данных (RM активно);

• избыточный VL и доставлять в раздел оба набора избыточных данных (RM не активно)

• не избыточный VL на любом интерфейсе м представлять данные в него в раздел (в этом случае RM может быть активно или не активно).

Эта функция RM должна быть конфигурируемой.

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

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


Время установки аппаратного обеспечения в исходное состояние предполагается большим, чем SkewMax. Это предотвращает алгоритм RM от нарушения кадрами, направляемыми в сеть ОС до установки в исходное состояние, когда кадры, направленные после этого события поступают в ОС.

Алгоритм управления резервированием должен использовать только RSN кадра в качестве критерия для отказа или приема. Проверка целостности является отдельной задачей, которая выполняется даже при отключенном резервировании.

Для каждого VL на принимающей ОС функция управления резервированием (RM) должна обеспечивать, чтобы кадры направлялись в возрастающем порядке приемных порядковых номеров (RSN). Это будет применяться и в случаях установки в исходное состояние или случайных потерь кадров. Если SkewMax будет превышен после приема кадра, RM будет принимать следующий кадр независимо от его порядкового номера.

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

Например, на Рис. 3-20 кадр "A2" потерян в сети А, и кадр "A3" поступает в эту сеть до того, как копия "B2" утерянного кадра поступит в сеть В. В этом случае копия В2 не будет направляться в раздел, несмотря на то, был ли получен первый кадр № 2.



Transmission = Передача Time of Transmission = Время передачи Reception Network A = Прием сетью А Time of Arrival = Время прибытия Reception Network B = Прием сетью В Integrity Checking Network A = Проверка целостности сетью А Integrity Checking Network B = Проверка целостности сетью В

Рис. 3-20 – Потеря кадра

3.3 Взаимодействие на IP-уровне и выше


Стандартного преобразования данных между портами раздела (портами программ) и портами ОС нет. Эти требования будут записаны в спецификации на конкретное оборудование.

Тем не менее, наличие двух потребителей данных на СОМ-порте AFDX или в пунктах доступа к обслуживанию (SAP) может привести к потере данных, как показано на Рис. 3-21.

Appli Port = Порт программы AFDX communication port = Связной порт AFDX or SAP port = или SAP-порт Risk of loss of data = Риск потери данных sampling/SAP for z = выборка/SAP на 0 No risk of loss of data = Отсутствие риска потери данных

Рис 3-21 – Разделение СОМ-портов AFDX при приеме

Наличие двух источников данных на одном СОМ-порту AFDX или SAP-порту может также приводить к потере данных, как показано на Рис. 3-22.



Appli Port = Порт программы AFDX communication port = Связной порт AFDX or SAP port = или SAP-порт Risk of loss of data = Риск потери данных sampling/SAP for z = выборка/SAP на 0 No risk of loss of data = Отсутствие риска потери данных

Рис. 3-22 – При передаче порты не разделяются

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

3.3.1 Службы авионики

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

1. Связной порт: режимы выборки или формирования очередей (например, ARINC 653)

2. SAP-порты: используются для передач по протоколу TFTP и связи с соответствующими сетями.

Partition = Раздел Communication port = Связной порт Layer = Уровень Unicast reception = Однонаправленный прием Multicast reception = Многонаправленный прием Legend = Условные обозначения



input port = входной порт output port = выходной порт

Figure 3-23 - Interface Between Partition and End System

На Рис. 3-23 показано оборудование, которое имеет два раздела (например, ARINC 653 для определения раздела) и оконечную систему. Каждый раздел имеет IP-адрес. Для сообщения с разделом оконечная система использует порты двух типов: связной порт и SAP-порт.

3.3.1.1 Связные порты

ОС обеспечивает два типа служб через связные порты: выборку и формирование очередей. Протокол UDP был выбран для обеих служб из-за его относительной эффективности.

3.3.1.1.1 Службы выборки авионики

Оконечная система должна обеспечивать службы выборки согласно определению в ARINC 653 (Раздел 2.3.5.6.1).

3.3.1.1.1.1. При передаче

СОМ-порты для выборки не должны использовать IP-фрагментацию, поэтому размер каждого сообщения о выборке должен быть меньше или равен размеру полезной нагрузки соответствующего виртуального канала.

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

Служба выборки простая без соединения и подтверждения. Она не добавляет контроля ошибок в передаваемых данных и не требует контроля потока в дополнение к контролю потока VL. Этот тип передачи аналогичен службам, обеспечиваемым типичными каналами связи ARINC 429.

3.3.1.1.1.2. При приеме

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

С каждым портом выборки должно быть ассоциировано указание свежести. Это указание свежести должно быть доступно каждому разделу, читающему сообщение.

3.3.1.1.2 Служба формирования очередей авионики

Оконечная система должна обеспечивать службы формирования очередей для раздела авионики, как определено в ARINC 653 (Раздел 2.3.5.6.2).

Служба формирования очередей простая, без соединения и подтверждения.

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

Для того, чтобы гарантировать последовательность сообщений, служба формирования очередей должна обрабатывать сообщения по принципу «первым прибыл – первым обслужен» при передаче и приеме.

В каждом случае служба формирования очередей должна быть способна обрабатывать до 8 килооктет данных программ (таким образом, требуется IP-фрагментация).


Служба формирования очередей без установления соединения и без подтверждения приемлема для различных типов связи из-за низкой вероятности потери кадров в избыточной сети AFDX.


При использовании фрагментации фрагменты должны передаваться по порядку в сеть AFDX.

В случае переполнения буфера при передаче, сообщение об ошибке должно направляться передающему разделу, и кадр должен быть сброшен, как показано на Рис. 3-24.



Error indication = Сообщение об ошибке If the queue is full = Если очередь заполнена Queue = Очередь

Рис. 3-24 – Сообщение об ошибке при переполнении буфера TX


В случае фрагментации данные в раздел не представляются из службы формирования очередей «первым прибыл – первым обслужен» до тех пор, пока не будет ассемблировано полное сообщение.

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

3.3.1.2 Порт-SAP

3.3.1.2.1 Службы для соответствующих сетей

ОС может являться точкой доступа к службе при следующих характеристиках.

• Порты SAP могут использоваться для обмена сообщениями в сети AFDX.

• Доступ к соответствующей сети может осуществляться через шлюз или через маршрутизатор, как часть конструкции ОС.

• ОС должна обеспечивать службы по UDP-протоколу для связи с соответствующей сетью.

• В каждом случае точка доступа к службе UDP должна обрабатывать до 8 килооктет.

• В качестве варианта может использоваться протокол TCP путем прямого доступа к IP-уровню через соответственно конфигурированный SAP-порт.

Для связи с соответствующей сетью передающая ОС способна определять адрес назначения: IP-адрес и номер порта. По этой причине эти адреса предоставляются, когда ОС получает запрос от соответствующей сети.

3.3.1.2.2 Управление ошибками в SAP-порте

Ухудшение качества обслуживания в SAP-порте контролируется на приемном устройстве. При переполнении буфера приемного устройства сообщение об ошибке направляется принимающему разделу, и кадр сбрасывается.

3.3.1.2.3 Службы передачи файлов

Для передачи файлов используется упрощенный протокол передачи файлов (TFTP). Спецификация TFTP определена в запросах на комментарии (RFC), определенных в таблице 3-1.

Таблица 3-1 – Определения RFC для TFTP

RFC Название Категория 783 Протокол TFTP (Версия 2) Стандартный, обновлен RFC 1350 1123 Требования к программам Интернет-хостов и поддержке Стандартный 1350 Протокол TFTP (Версия 2) Стандартный 2347 Доп. расширение TFTP Тракт стандартов, обновлен 1350 2348 Вариант размера блока TFTP Тракт стандартов, обновлен 1350



2349 Вариант TFTP с интервалом простоя и размера передачи Тракт стандартов, обновлен 1350 1785 Анализ переговоров о вариантах TFTP Информационный, обновлен 1350 В каждом случае служба передачи файлов должна быть способна обрабатывать блоки до 8 килооктет.

3.3.1.3 Виртуальный субканал

VL может содержать ряд виртуальных субканалов, как показано на Рис. 3-25 - 3-27, и в таком случае VL состоит только из этих суб-VL.

Каждый суб-VL имеет выделенную очередь «первым прибыл – первым обслужен» (FIFO), и очереди FIFO для суб-VL считываются по круговой системе главной очередью FIFO VL. Эта функция кругового считывания осуществляется на основе MAC-кадра, поэтому IP-фрагментация (если таковая используется) должна осуществляться до загрузки очередей суб-VL.


Введение суб-VL является дополнительной функцией, которая не оказывает влияния на детерминизм сети. Она может использоваться для оптимизации использования пропускной способности VL.

Sub VL FIFO Queue = Очередь FIFO для суб-VL VL FIFO Queue = Очередь FIFO для VL

Рис. 3-25 – Очередь FIFO суб-VL

Рис. 3-26 – 1-й пример трафика на VL

In the VL you will have = В этом VL будет следующее



Рис. 3-27 – 2-й пример трафика на VL

In the VL you will have = В этом VL будет следующее

Очередь FIFO VL должна быть способна обрабатывать самое большее четыре очереди FIFO суб-VL.

Очередь FIFO каждого суб-VL должна считываться в круговом режиме, что, чтобы если в любой очереди FIFO суб-VL есть трафик, один кадр из каждого интервала распределения пропускной способности (BAG) направляется в главный VL. После посылки кадра последовательность приостанавливается до тех пор, пока BAG закончится, и затем последовательность начинается повторно для очереди FIFO следующего суб-VL.

Очередь FIFO суб-VL должна считываться только очередью FIFO одного VL. IP-фрагментация должна осуществляться на IP-уровне, если это необходимо. Это поможет избежать, например, задержки коротких сообщений о выборке длинными сообщениями. Круговое считывание продолжается в присутствии IP-фрагментации, таким образом один фрагмент берется из одного суб-VL и затем кадр или фрагмент берется из следующего суб-VL.

Все суб-VL расположены ниже IP-уровня.

3.3.2 Пример упрощенного протокола передачи файлов

Этот пример описывает использование TFTP для посылки файла от LRU 1 в LRU 2, как показано на Рис. 3-28. Для этого определяются два VL:: VL1 и VL2.

VL1: от LRU1 LRU2; VL2: от LRU2 LRU1

На этапе инициализации:

1. Передача инициируется LRU 1, который посылает запрос из порта-источника 45000 на порт назначения 69, выделенный для TFTP в LRU2.

2. LRU 2 активирует сеанс TFTP, который реагирует на этот запрос, посылая сообщение на порт 45000 LRU 1. В нем указывается порт, выбранный для приема передачи (порт 47 000).

3. В данный момент устанавливается связь. LRU 1 может послать файл в пакетах данных. Сообщение от LRU 1 LRU 2 использует порт-источник 45 000 и порт назначения 47 000.

4. Подтверждение каждого пакета данных посылается LRU2, который использует порт-источник 47 000, для порта назначения 45 000.



Partition = Раздел Layer = Уровень Communication port = Связной порт SWITCH = КОММУТАТОР

Рис. 3-28 – Пример сообщения TFTP в сети AFDX

3.3.3 Связной стек ОС

На Рис. 3-29 показан связной стек ОС.

Avionics Application = Применение в авионике File Tranfer TFTP = Протокол передачи файлов TFTP Maintenance Application = Применение в техническом обслуживании Data loading = Загрузка данных TFTP Protocol = Протокол TFTP SNMP agent = Агент SNMP SNMP Protocol = Протокол SNMP Port Sampling = Выборка портом Port Queing = Формирование очередей портом APPLICATION = ПРИМЕНЕНИЕ



PRESENTATION = ПРЕДСТАВЛЕНИЕ SESSION = СЕАНС TRANSPORT = ПЕРЕДАЧА NETWORK = СЕТЬ LINK = КАНАЛ ПЕРЕДАЧИ PHYSICAL = ФИЗИЧЕСКИЙ УРОВЕНЬ Option =Элемент Virtual Link = Виртуальный канал передачи Management Information Base = База с информацией об управлении

Figure 3-29 - ES Stack

3.3.3.1 Профиль MAC ОС

Уровень канала передачи данных ОС должен быть основан на использовании дуплексных каналов Ethernet по определению стандарта IEEE 802.3.

Любой Ethernet-кадр, генерируемый оконечной системой, должен соответствовать стандарту IEEE 802.3.

Все выходные интерфейсы продолжают передачу даже в случае отказа канала на физическом уровне.


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

Максимальная длина кадра AFDX fдолжна определяться для каждого VL.

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

3.3.3.2 IP-профиль ОС

Структура пакета должна относиться к версии IPv4.

Структура пакета версии IPv4 должна соответствовать Рис. 3-30.

4 бита 4 бита

8 бит 16 бит 16 бит 3 бита 13 бит 8 бит 8 бит 16 бит 32 бита 32 бита 1-1479 байт

Версия IHL Тип службы

Общая длина

Идентификация фрагмента

Управляющий флаг

Сдвиг фрагмента

Время существования

Протокол Контрольная сумма заголовка

IP –адрес источника

IP-адрес назначения

IP-полезная нагрузка

Рис. 3-30 – Структура пакета по версии IPv4

Обычно в структуре пакета версии IPv4 поле «Общая длина» должно находиться в диапазоне от 21 до 1500 байт. В AFDX этот диапазон составляет от 21 до 1499 из-за порядкового номера (см. Раздел 3.2.6.2.2 «Функция управления резервированием»).


Поле «Общая длина» не учитывает порядковый номер.

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

3.4 Взаимодействие на уровне сетей

3.4.1 Адресация

3.4.1.1 Введение

Поток данных уникально идентифицируется в сети AFDX совокупностью порта назначения UDP/TCP, адреса назначения IP, адреса назначения MAC и физическим соединением Ethernet принимающей ОС.

Фильтрация на основе кадров осуществляется так, чтобы принимающая оконечная система направляла только действительные кадры на связный порт или SAP-порт. Действительный кадр определяется анализом адресов назначения (TCP/UDP, IP, MAC) и физическими соединениями



Ethernet.

3.4.1.2 Структура кадра AFDX без фрагментации

На Рис. 3-31 показана структура кадра AFDX. Показаны минимальный и максимальный кадры.

bytes = Количество байт minimum Ethernet frame length = Минимальная длина кадра в Ethernet Preamble = Заголовок Start Frame Delimiter = Разделитель начального кадра Destination Address = Адрес назначения Source Address = Адрес источника Structure = Структура Payload = Полезная нагрузка Padding = Заполнение пробелами SN = Порядковый номер Frame Check Seq = Последовательность проверки кадра Inter Frame Gap = Интервал между кадрами maximum Ethernet frame length = Максимальная длина кадра в Ethernet

Figure 3-31 - Structure of an AFDX Frame

Пример принципа адресации показан на Рис. 3-33.

На Рис. 3-32 оконечная система 1 имеет три виртуальных канала: VL1, VL2 and VL3.

Раздел 1 оконечной системы 1 имеет доступ к одному виртуальному каналу: VL1

Раздел 2 оконечной системы 1 имеет доступ к двум виртуальным каналам: VL2 and VL3.



Partition = Раздел Port = Порт Source AFDX communication port = Связной порт-источник AFDX Source UDP port = Порт-источник UDP source IP address = IP-адрес источника Source MAC address = MAC-адрес источника End system = Оконечная система Dest MAC address = МАС-адрес назначения Dest UDP port + dest IP address = UDP-порт назначения + IP-адрес назначения Dest AFDX communication port = Связной порт AFDX назначения

Рис. 3-32 – Пример адресации

Следующие таблицы содержат таблицы адресов для каждой ОС: Таблица передачи оконечной системы 1:

Связной порт-источник

Раздел-источник

ИсточникUDP

ИсточникIP

ИсточникMAC

Назначение UDP

Назначение IP

Назначение MAC

AFDX Порт 1 Раздел 1 UDP1 IP10 MAC10 UDP1 IP1 MAC1 (VL1)AFDX Порт 2 Раздел 1 UDP2 IP10 MACK) UDP2 IP1 MAC1 (VL1)AFDX Порт 3 Раздел 2 UDP1 IP20 MACK) UDP1 IP3 MAC3 (VL3)AFDX Порт 4 Раздел 2 UDP2 IP20 MAC10 UDP2 IP3 MAC3 (VL3)AFDX Порт 5 Раздел 2 UDP3 IP20 MAC10 UDP1 IP2 MAC2 (VL2)Таблица приема оконечной системы 2:

Связной порт(ы) назначения

Раздел(ы) назначения

Источник UDP

Источник IP

Источник MAC




AFDX Порт 1 Раздел 1 UDP1 IP10 MAC10 UDP1 IP1 MAC1 AFDX Порт 4 Раздел 2 UDP2 IP10 MAC10 UDP2 IP1 MAC1 AFDX Порт 2 Разделы 1 и UDP1 IP20 MAC10 UDP1 IP3 MAC3



AFDX Порт 3 Раздел 2 UDP2 IP20 MAC10 UDP2 IP3 MAC3 Таблица приема оконечной системы 3:

Связной порт(ы) назначения

Раздел(ы) назначения

Источник UDP

Источник IP

Источник MAC




AFDX Порт 2 Раздел 1 UDP1 IP20 MAC10 UDP1 IP3 MAC3 AFDX Порт 3 Раздел 2 UDP2 IP20 MAC10 UDP2 IP3 MAC3 AFDX Порт 1 Разделы 1 и UDP3 IP20 MAC10 UDP1 IP2 MAC2 КОММЕНТАРИЙ

На приемном устройстве демультиплексирование основано только на адресе назначения MAC, IP, UDP.

На Рис. 3-33 показана физическая топология для этого примера:

End system = Оконечная система Tx Pair = Передающая пара Rx Pair = Приемная пара Cable = Кабель Ethernet Controller = Контроллер Ethernet Tx MAC port = Передающий МАС-порт Rx MAC port = Приемный МАС-порт Switch output port = Выходной порт коммутатора Switch input port = Входной порт коммутатора Port = Порт Switch = Коммутатор Коммутатор продвижения данных определен в таблице 3-2.

Рис. 3-33 – Пример физической топологии

Таблица 3-2 – Коммутатор продвижения данных

Входной порт Поле назначения МАС принятых кадров Выходные порты

1 MAC1 (VL1) 2 1 MAC2 (VL2) 3 1 MAC3 (VL3) 2 и 3


MAC-адрес должен пониматься как потенциально однонаправленный или многонаправленный адрес Ethernet.

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

Передачи между равноправными узлами в сети определяются в каждом кадре Портом-источником UDP + IP-источником + МАС-назначением (идентификация виртуального канала) + IP-назначением + Портом назначения UDP, как показано на Рис. 3-34.

В сети AFDX эта пятерка обеспечивает уникальную идентификацию каждого сообщения.



UDP source port = Порт-источник UDP Source IP = IP-источник MAC Destination (VL identification) = МАС-назначение (идентификация VL) Destination IP = IP-назначение UDP Destination port = Порт назначения UDP

Рис. 3-34 – Понятие идентификации сообщения

Для IP-источника должны существовать несколько UDP/TCP-портов-источников. Для IP-назначения должны существовать несколько UDPfTCP-портов назначения.

На Рис. 3-35 показаны 3 сообщения, определяемыми 3 тройками.

Сообщение 1 => UDP-порт х источник + IP-источник + Mac-назначение + IP-назначение + UDP-порт n назначения

Сообщение 2 => UDP-порт у источник + IP-источник + Mac-назначение + IP-назначение + UDP-порт m назначения

Сообщение 3 => UDP-порт z источник + IP-источник + Mac-назначение + IP-назначение + UDP-порт v назначения

Назначения

Рис. 3-35 – Уникальная идентификация сообщения в одном виртуальном канал

3.4.1.3.1 Связь внутри AFDX

Сквозные сообщения, которые остаются в сети AFDX, могут рассматриваться как AFDX-внутренние.

Главной характеристикой связи внутри AFDX является то, что для каждого сообщения адрес определяется статически.

При однонаправленных сообщениях:

• связные порты AFDX определяются через порты UDP. Такие порты могут являться передатчиками или приемниками.

• связные порты AFDX характеризуются службами выборки и определения очередей.

При двунаправленных сообщениях:

Documents

ARINC 664P7_rus