Требования к разрабатываемому устройству



Скачать 279.89 Kb.
Pdf просмотр
Дата07.12.2016
Размер279.89 Kb.
Просмотров127
Скачиваний0

Сосуществование Linux и RTOS на единой аппаратной платформе

Требования к разрабатываемому устройству
SCADA для электрических подстанций
Опрос десятков датчиков
Полное резервирование всех узлов и линий связи
Синхронизация времени между всеми территориально разнесёнными узлами с точностью не хуже 1 мкс
Ведение журнала о неисправностях и срабатываний автоматики, запись журнала на встроенный носитель
Десятки программных потоков, ответственных за первичную обработку получаемых данных
Время реагирования и обработки внешнего события не более 1 мс
Поддержка сетевых протоколов: IEC 61850 (MMS,
GOOSE, SV), IEC 62531, IEEE 1588
Графический интерфейс оператора
2

Структурная схема блока сбора и первичной
обработки данных
3
Процессор
Freescale
P1020
Отказ 1
Работа
Eth1
Flash-RAID
8ГБ
RTC
DDR 256МБ
Источник питания
Обмен с АСУТП (MMS)
=12В
Обмен информацией с модулями ввода-вывода
SPI
Обмен информацией с другими модулями процессора
Питание
Локальная шина
PCIe
Обмен с модулем индикации
Eth2
Eth3
Обмен данными по шине процесса
(GOOSE,SV,1588)
Внешняя шина
Контрольная информация
Отказ 2

Проблема выбора ОС
Проблемы Linux:

Не отвечает требованиям жёсткого реального времени (несмотря на наличие RT патчей ядра)

ОС общего назначения => сложная в реализации
=> потенциально менее надёжная
Проблемы RTOS (eCos, FreeRTOS и т.п.):

Неполноценный или отсутствующий сетевой стек

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

Выбранная архитектура: асимметричная
мультипроцессорная обработка данных
5
Task 1: получение данных с датчиков
Task 2: ведение и запись журнала
Task 5: Обмен данными с вспомогательным ядром
Task 3: диагностика, оперативное переключение на резервные модули
Task 6..40: первичная обработка полученных данных
Task 4: управление исполнительными устройствами
Сетевая подсистема
Диагностика
Взаимодействие с основным ядром
Протоколы прикладного уровня
IPC
RTOS
Linux
Первое ядро процессора
Второе ядро процессора
Графический интерфейс с пользователем

Проблемы AMP архитектуры
Разделение аппаратных ресурсов между двумя ОС: память, процессор, устройства ввода-вывода
Варианты решения:

Виртуализация разделяемых устройств

Жёсткая привязка устройств к заданному ядру

Кооперативное использование ресурса
Межпроцессорное взаимодействие
Варианты решения:

Разделяемая область памяти

Аппаратные средства (mailbox, SRIO и т.п.)

Готовые решения от вендоров: MIPC, DSPLINK

Свободные универсальные решения: MCAPI,
RPMsg + virtio
6

MCAPI: API для межпроцессорного
взаимодействия
Разработан и поддерживается The Multicore
Association
Обеспечивает стандартный API для взаимодействия пользовательских приложений, запущенных на разных ядрах AMP системы
7

API разработан для взаимодействия как процессорных ядер в одном чипе, так и для раздельных процессоров
Ключевые цели при реализации:

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

Низкая латентность

Платформонезависимость
Может работать как поверх “голого железа”, так и поверх гипервизора
Позволяет работать с сотнями ядер, обеспечивая эффективную маршрутизацию сообщений между ними
Топология маршрутизации задаётся на этапе компиляции
Поддерживает передачу как сообщений, так и непрерывных байтовых потоков
8
MCAPI: детали реализации и возможности

Практическая реализация
SoC: Freescale P1020 (dual core, 64K L1, 256K L2, 1Gb
DDR)
RTOS: RTEMS 4.11 for PowerPC
Linux: 2.6.35
U-Boot: v2010.12
Измерение временных интервалов при помощи встроенного в SoC таймера, работающего на 10МГц
Тестовые приложения запускаются на обоих ядрах и замеряют:

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

Время на переключение контекста

Время передачи сообщения из Linux в RTOS и обратно
9

Диаграмма загрузки тестового приложения
10
Инициализация аппаратуры: DDR,
MMU, UART
Загрузка uImage, fdt и RTEMS.img в
DDR
Инициализация аппаратуры: DDR,
MMU, UART
Освобождение спинлока на втором ядре
Старт ядра Linux
Старт RTEMS
П
ро ц
ес с З
аг ру зк и
Старт тестового приложения
Старт тестового приложения
0 Core
1 Core

Результаты измерений
Время реакции на прерывание: 0,3мкс
Время переключения контекста: 0,8мкс
Максимальное время передачи сообщения из Linux в RTEMS: 3мкс
Максимальное время передачи сообщения из
RTEMS в Linux: 18мкс
11

Выводы
12
Был продемонстрирован ещё один способ построения hard real time системы на GNU/Linux и других свободных программных компонентах
Кроме AMP архитектуры существуют и другие варианты реализации системы, близкой к жёсткой многозадачности реального времени:

Linux + PREEMPT_RT планировщик:
задачи реального времени в контексте ядра

Linux + Xenomai/RTAI фреймворк:
задачи реального времени в юзер спейсе

RTLinux:
задачи реального времени в контексте RTOS,
Linux запускается как idle задача
Для совместного доступа к аппаратуре в AMP системе можно применить гипервизор, как коммерческий (MontaVista, WindRiver), так и свободный (KVM, XEN)

13
Спасибо!
Dmitriy Gorokh
R&D Dept, Promwad
dmitriy.gorokh@promwad.com

Document Outline

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал