Реализация сети с отказоустойчивостью для развлечений и смешанного управления трафиком

Аннотация

В этой статье рассматривается интеграция системы управления и развлечений на вагонах поезда. Как контрольные, так и развлекательные нагрузки реализованы на основе Gigabit Ethernet, каждый из которых имеет выделенный контроллер/сервер. Управляющая нагрузка имеет смешанные периоды выборки. Доказано, что эта система может терпеть отказ одного контроллера в одном вагоне. В сценарии с двумя вагонами изучается отказоустойчивость на уровне контроллера, а результаты моделирования показывают, что система может терпеть отказ трех контроллеров. Система успешно встречает сквозную задержку пакета с нулевой потерей пакетов во всех сценариях, связанных с OPNET. Максимально допустимая развлекательная нагрузка определяется для отказоустойчивых сценариев.

Введение

Сетевые системы управления (NCS) – это быстро расширяющееся поле со многими приложениями – от промышленной автоматизации до интеллектуальных транспортных систем [1–6]. Истоки NCS можно проследить, однако в последние несколько десятилетий сеть Ethernet быстро распространилась, введя недетерминированные протоколы в мир NCS [7–9]. Ethernet – это недетерминированный протокол с несколькими источниками случайности из–за использования множественного доступа с множеством несущих столкновений (CSMA / CD) [10]. Такой вероятностный характер нежелателен в реализациях NCS реального времени до тех пор, пока не будут сделаны некоторые модификации для размещения приложений реального времени. Форматы пакетов были изменены, чтобы обеспечить определенный приоритет [11, 12]. Другие модификации могут быть реализованы при помощи Rockwell Automation, ODVA, EtherNet / IP, CIP, TT Ethernet и FTT Ethernet. Некоторые из этих решений находятся в процессе стандартизации [13–19]. Одна известная форма NCS существует в наземных транспортных системах, и исследования по этому вопросу многочисленны и обширны [1, 2, 20, 21]. В недавних исследованиях была изучена конкретная реализация, которая использует протокол Ethernet (IEEE 802.3) в поездах [22–28].

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

Еще одной растущей тенденцией в NCS является включение отказоустойчивости. Ссылка [3] изучала использование Fast и Gigabit Ethernet в современных сетевых системах управления. Было доказано, что использование избыточных узлов управления минимизирует время простоя. В справочнике [29] исследовано влияние сбоев на производительность отказоустойчивых сетевых систем управления при различных нагрузках. Ссылка [30] изучала наличие архитектуры пирамиды в сетевых систем управления. Ссылка [31] также изучала среднее время до отказа (MTTF) отказоустойчивой двухмашинной производственной линии в сетевых системах управления (NCS). Более подробную информацию о отказоустойчивости в NCS можно найти в [32].

В данной статье представлено исследование сети управления поездами с использованием протокола Ethernet без изменений. Он включает в себя все ранее упомянутые проблемы, а именно использование немодифицированного протокола, связывающего приложения реального времени (управления) и не в реальном времени (развлечения). Он также включает аспекты отказоустойчивости. Исследование состоит из нескольких моделей моделирования OPNET Network Modeler [33], которые моделируют два вагона для контрольных и развлекательных нагрузок. Основной вклад этой работы в том, что предлагаемая управляющая нагрузка более реалистична, состоящая из смеси разных периодов выборки для датчиков и исполнительных механизмов [27]. Нагрузка развлечений состоит из потоковой передачи видео и ограниченного доступа к Интернету. Предлагаемая конструкция также включает исследование отказоустойчивости на уровне контроллера. Будет показано, что имитированная модель успешна как в безотказном, так и в отказоустойчивом сценариях.

Остальная часть этой статьи организована следующим образом. В разделе 2 дается резюме предыдущей работы по сетям управления поездом. В разделе 3 будет представлена новая модель. В разделе 4 представлены моделированные сценарии и показаны результаты. В разделе 5 делается вывод об этом.

Предыдущая работа

Было проведено несколько исследований, посвященных моделированию сетей поездов, таких как LonWorks и Train Control Networks (TCN) [25–28, 34]. В последних исследованиях были смоделированы вагоны поездов с использованием коммутируемого Ethernet [22–24, 35]. Исследование вращалось вокруг возможности единой сети с управлением и развлечениями, отказоустойчивостью на уровне контроллера и уровня датчика.

Ссылка [22] проверила производительность единой инфраструктуры Ethernet, поддерживающей как систему управления, так и развлекательную систему в вагонах поезда. Используя OPNET, были смоделированы несколько сценариев с разными настройками. СА были настроены на использование единого периода выборки для всей модели. В зависимости от сценария, некоторые факты моделировались с использованием периода выборки 1 мс, а другие – с использованием 16 мс, каждый из которых имитировался независимо. Результаты исследования гарантировали, что сквозная задержка пакета всегда находится в пределах ограничений максимально допустимой задержки.

Ссылка [23] успешно применила отказоустойчивость на уровне контроллера к системе, предложенной в [22]. В последующем исследовании была введена отказоустойчивость на уровне датчика с использованием Triple Modular Redundancy (TMR), концепция, описанная в [36, 37], для достижения успешных результатов [35].

Предлагаемая модель

В предлагаемой модели используется инфраструктура 1 Gigabit Ethernet без изменений, основанная на стандарте IEEE 802.3 для всей сети, и следует правилам, описанным в МЭК 61375 [27]. В стандарте упоминалось несколько периодов выборки, касающихся СА, однако наиболее распространенными значениями были 1 мс (наименьший период выборки) и 16 мс. Ссылки [22,23] изучали эти значения раздельно. Однако предлагаемая в настоящее время модель включает оба периода выборки в одной сети управления, представляющие различные возможные применения СА. Типичное количество СА на одном вагоне для поезда составляет около 250 с периодами выборки 1 мс (меньшинство) и 16 мс (большинство) [27]. Они будут разбиты на 3 группы. Группа 1 (G1) состоит из 30 датчиков и 30 приводов (соотношение 1:1), работающих с самым требовательным периодом выборки 1 мс. Группа 2 (G2) состоит из 100 датчиков и 50 приводов (соотношение 2:1), работающих в период выборки 16 мс. Наконец, группа 3 (G3), также работающая с периодом выборки 16 мс, состоит из 30 датчиков и 10 приводов (соотношение 3:1). Распределение показано на рисунке 1. Эта конструкция минимизирует количество коммутаторов, используя стандартные 128–портовые коммутаторы, которые доступны на рынке. Также обратите внимание, что местоположения СА были выбраны для увеличения расстояния между коммутаторами и контроллером, максимизируя расстояние поездки, чтобы имитировать худший сценарий. Основной коммутатор (обозначенный MS1) использует скорость пересылки 6,6 Мбит / с, что намного ниже, чем тарифы, доступные в таких моделях, как коммутаторы Cisco Catalyst 3560 Gigabit Ethernet [38].

Весовую нагрузку в модели поезда можно описать с точки зрения количества потоков, качества видеоэкранов, а также количества узлов WiFi и количества приложений на узел. В худшем случае, в большом вагоне на 60 мест [25], поддерживается 60 различных и одновременно воспроизводящихся видеопотоков качества DVD (по одному на каждое место) [39], а также один пользователь WiFi на каждое место. Каждый пользователь WiFi запускает несколько одновременных приложений: доступ к базе данных, отправку/получение электронной почты, просмотр веб-страниц и передачу файлов. Это дает в общей сложности 60 видеопотоков и 60 пользователей WiFi, каждый из которых работает с 4 одновременными приложениями, требующими доступа к сети. Эти приложения WiFi моделируются с использованием общих встроенных приложений большой нагрузки OPNET. Эта загрузка WiFi требует максимальной пропускной способности 6 Мбит / с, поэтому для трафика WiFi выделяется только 6 Мбит / с. Доступ WiFi предоставляется через точку доступа (AP) в середине вагона, максимизируя зону покрытия. Наконец, модель имеет 2 специализированных контроллера на вагон. Наличие двух контроллеров позволяет исключить неисправность на уровне контроллера, как объяснено далее. Вагон 1 имеет K1 и E1, где K1 является контроллером, под контролем только управляющей нагрузкой, а E1 – сервером развлечений. То же самое применимо для Вагона 2.

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

Моделированные сценарии и результаты

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

Первый набор симуляций выполняется для одной модели вагона с 60 видеопотоками и 60 пользователями WiFi. Первый сценарий имитирует безошибочный случай, когда оба контроллера полностью функциональны; K1, обрабатывающий все управляющие данные и E1, обрабатывающие развлекательную нагрузку. Во втором сценарии (отказоустойчивый) один из двух контроллеров выключен, имитируя отказ. Контрольные и развлекательные нагрузки обрабатываются оставшимся контроллером. Затем делается попытка максимизировать количество видеопотоков и пользователей WiFi без ущерба для управляющей нагрузки.

Второй набор симуляций выполняется на одним шагом, объединяя два идентичных вагона и проводя главный выключатель каждого вагона к другому. Модификации сделаны таким образом, что все датчики отправят свои данные на все 4 контроллера, а не только на их соответствующие вагоны. Другие методы коммуникации можно найти в [40]. Общее количество видеопотоков и пользователей WiFi теперь удваивается. Опять же, первый сценарий имитирует безошибочный случай, когда все 4 контроллера полностью работоспособны. Следующий сценарий (faulttolerant) моделирует крайний случай, когда 3 из 4 контроллеров потерпели неудачу, и теперь только один контроллер должен нести контрольную и развлекательную нагрузку обоих вагонов. Цель снова состоит в том, чтобы максимизировать количество видеопотоков и пользователей Wi-Fi, без нагрузки на управление.

Чтобы оценить производительность системы, необходимо контролировать задержку и потерю пакетов. Во всех симуляциях наблюдается нулевая потеря пакетов (без падений или отложенных пакетов), а общие сквозные задержки по всем SA находятся в пределах их соответствующих ограничений [41]. Для всех результатов применяется доверительный анализ на 95%. На рисунках 2-5 показаны примеры результатов из разных сценариев. На всех рисунках ось x представляет собой время моделирования в минутах и секундах, а ось y показывает задержку в секундах. На рисунках показана задержка, измеренная на приводе из одной из трех групп (как указано в заголовке: например, G1). Эти задержки представляют собой время, затрачиваемое на перемещение пакета из K в A, а в случаях, подобных рис. 3 и 4, задержки пакетов колеблются между несколькими значениями в зависимости от уровня перегруженности сети.

Со всеми видеопотоками по качеству DVD и всеми пользователями WiFi, которые работают с полной загрузкой приложений, описанных в предыдущем разделе, максимальная общая сквозная задержка (с доверием 95%) для каждой группы SA показана в таблице 1. максимальное количество потоков и пользователей WiFi, которые будут поддерживаться в каждом смоделированном сценарии, показаны в таблице 2. Эти результаты гарантируют, что все SA, работающие с периодом выборки 1 мс, имеют сквозную задержку менее 1 мс, а те, которые работают в 16 мс имеют сквозную задержку менее 16 мс (с доверием 95%). Важно отметить, что накладные расходы, понесенные в сети узлами WiFi, незначительны по сравнению с контролем и потоками видеопотока. Поскольку эта нагрузка чрезвычайно мала, независимо от того, в каком состоянии находится сеть, сеть WiFi не будет затронута (как видно из Таблицы 2). Это также можно объяснить тем, что пропускная способность, выделяемая пользователям WiFi, ограничена до 6 Мбит / с.

Выводы

Реализация Ethernet для сетевых систем управления (NCS) является растущей областью. Ранее были изучены сети поездов с использованием Ethernet, которые несут как развлекательную нагрузку, так и управляющую нагрузку в одной сети. В этой статье изучался отказоустойчивый поезд NCS, использующий коммутируемый Ethernet, с развлекательной нагрузкой видеопотоков и WiFi-доступом. Модель была успешно смоделирована, демонстрируя правильную передачу и прием пакетов, с нулевыми потерями. Модели с одним вагоном и двумя вагонами моделировались в безошибочных и ошибочных сценариях, показывающих нулевую потерю пакетов и задержки в ограничениях периодов выборки сети управления. Однако, когда нагрузка увеличивается на одном контроллере из-за сбоя, максимальное количество поддерживаемых потоков уменьшается. Это не уменьшает количество пассажиров с возможностью просмотра видео, просто ограничивает количество одновременно воспроизводимых видео в любой момент времени.

Список использованной литературы

1. N. Navet, Y. Song, F. Simonot-Lion and C. Wilwert, “Trends in Automotive Communication Systems,” Proceedings of the IEEE, Vol. 93, No. 6, 2005, pp. 1204- 1223. doi:10.1109/JPROC.2005.849725.
2. R. M. Daoud and H. H. Amer, “Fast Ethernet Implementation of Cost Effective Vehicle On-Board Networks,” In: S. Pennacchio, Eds., Emerging Technologies, Robotics and Control Systems, Ass. Internationalsar, Bologna, 2007, pp. 81-85.
3. R. M. Daoud, H. M. Elsayed and H. H. Amer, “Gigabit Ethernet for Redundant Networked Control Systems,” Proceedings of the IEEE International Conference on Industrial Technology ICIT, Vol. 2, Hammamet, 8-10 December 2004, pp. 869-873.
4. J. D. Decotignie, “Ethernet-Based Real-Time and Industrial Communications,” Proceedings of the IEEE, Vol. 93, No. 6, 2005, pp. 1102-1117.
5. F. L. Lian, J. R. Moyne and D. M. Tilbury, “Performance Evaluation of Control Networks: Ethernet, ControlNet, and DeviceNet,” IEEE Control Systems, Vol. 21, No. 1, 2001, pp. 66-83.
6. M. Tabbara, A. Rantzer and D. Nesic, “On Controller & Capacity Allocation Co-Design for Networked Control Systems,” Systems & Control Letters, Vol. 58, No. 9, 2009, pp. 672-676.
7. Bosch, “CAN in Passenger and Cargo Trains. CAN in Automation,” 2011. http://www.can-cia.org/ .
8. PI, “PROFIBUS & PROFINET,” 2011. http://www.profibus.com/ .
9. T. Skeie, S. Johannessen and C. Brunner, “Ethernet in Substation Automation,” IEEE Control Systems, Vol. 22, No. 3, 2002, pp. 43-51.
10. IEEE 802.3 Standard. http://standards.ieee.org/about/get/802/802.3.html .
11. S. H. Lee and K. H. Cho, “Congestion Control of High-Speed Gigabit-Ethernet Networks for Industrial Applications,” Proceedings of the IEEE International Symposium on Industrial Electronics ISIE, Vol. 1, Pusan, 12-16 June 2001, pp. 260-265.
12. J. S. Meditch and C. T. A. Lea, “Stability and Optimization of the CSMA and CSMA/CD Channels,” IEEE Transactions on Communications, Vol. 31, No. 6, 1983, pp. 763-774.
13. ODVA, “EtherNet/IP Adaptation on CIP,” CIP Common. http://www.odva.org/ .
14. Allen-Bradley, “EtherNet/IP Performance and Application Guide,” Rockwell Automation Application Solution, 2003. http://ab.rockwellautomation.com/networks-and-communications/ethernet-ip-network .
15. IEC 61784-1. www.iec.ch.
16. IEC 61784-2. www.iec.ch.
17. J. Ferreira, P. Pedreiras, L. Almeida and J. Fonseca, “Achieving Fault-Tolerance in FTT-CAN,” Proceedings of the 4th IEEE International Workshop on Factory Communication Systems WFCS, Vasteras, August 2002, pp. 125-132.
18. P. Pedreiras, L. Almeida and P. Gai, “The FTT-Ethernet Protocol: Merging Flexibility, Timeliness and Efficiency,” Proceedings of the IEEE Euromicro Conference on RealTime Systems ECRTS, Vienna, 19-21 June 2002, pp. 134- 142.
19. K. Steinhammer and A. Ademaj, “Hardware Implementation of the Time-Triggered Ethernet Controller,” Embedded System Design: Topics, Techniques and Trends, Vol. 231, Springer, Boston, 2007, pp. 325-338.
20. Vector CANtech Inc., “Overview of Current Automotive Protocols,” 2003. www.vector-cantech.com.