Есть ли разница между системой реального времени и детерминированной?

Question

На работе мы обсуждаем дизайн новой платформы и один из верхних типов управления, который сказал, что нужно запустить нашу текущую базу кода (C на Linux), но быть в режиме реального времени, потому что ей нужно было ответить менее чем за секунду до различные входы. Я указал, что:

1. Эта точка не означает, что она должна быть «в реальном времени» только что ему нужно быстрее часов и более рационализацию в обработке прерываний
2. Одним из ключевых моментов, чтобы рассмотреть ОС, которая используется. Они хотели придерживаться встроенного Linux, я указал, что нам нужна RTOS. Использование Linux предотвратит «реальное время» из-за разрыва памяти ядра/пользователя, поэтому ввод-вывод выполняется через файлы и сокеты, которые вводят задержку.
3. Нам действительно нужно определить, нужно ли это детерминировать (необходимо ответьте на ввод в < 200 мс 90% времени, например).

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

Я чувствовал уверенность в ответе, но потом я думал об этом позже ... Что думают другие? Я на правильном пути здесь или я чего-то не хватает?

Есть ли какая-то разница в том, что мне не хватает системы «реального времени» и «детерминированной»? И, кроме RTC и RTOS, я пропускаю что-то важное, что требуется для выполнения реальной системы реального времени?

С нетерпением жду некоторых замечательных отзывов!

EDIT:

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

1. Моя компания продает единицы в десяти тысячах, поэтому я не хочу идти за убийством по цене
2. Обычно мы продаем основную плату процессора и независимый дисплей. Также есть подключенная сеть других CAN-устройств.
3. Плата (в настоящее время) управляет устройствами, а также выступает в качестве веб-сервера отправки основные документы XML на дисплей для конечных пользователей

Требования приходят сюда, где руководство хочет дисплей будет обновляться «быстро» (< 1s), однако true Ограничения IMO исходят от устройств, которые можно подключить через CAN. Эти устройства часто являются управляемыми двигателем устройствами с требованиями, в том числе «должны отвечать менее чем за 200 мс».

Answer 1

Вы должны различать:

• Hard реальном времени: есть абсолютный предел по времени отклика, которое не должно быть нарушено (засчитывается как отказ) - например, это целесообразно, например, когда вы управляете роботизированными двигателями или медицинские устройствами, где несоблюдение срока может быть катастрофическим
• Soft в реальное время: есть требования, чтобы быстро реагировать большую часть времени (возможно 99,99% +) , но приемлемо, чтобы время, которое время от времени было нарушено, обеспечивало бы, чтобы реакция в среднем была очень быстрой. например это целесообразно при выполнении в режиме реального времени анимации в компьютерной игре - отсутствует срок может привести к пропущенным кадр, но принципиально не испортить игровой опыт

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

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

Важно отметить, что большинство бизнес-приложений не требуют ни: в частности, я думаю, что нацеливание времени отклика на < 1сок является далеко от того, что большинство людей считают «в реальное время» требование. Сказав это, если время ответа явно указано в требованиях, тогда вы можете рассматривать его как мягкое реальное время с довольно свободным сроком.

Answer 2

Из определения real-time тега:

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

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

система реального времени не нужно быть детерминированным: если время отклика случайным образом изменяется между 50мс и 150ms, но время отклика никогда не превышает 150 мс, то система не является детерминированным, но он по-прежнему в режиме реального времени.

Answer 3

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

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

Answer 4

Возможно, вы могли бы попытаться использовать RTLinux или RTAI, если у вас есть достаточно времени для экспериментов. При этом вы можете хранить приложения реального времени в Linux, но приложения realtime будут перемещены в часть RTOS. В этом случае вы сможете (возможно) достичь < 1сек. Времени отклика.

Преимущества -

• Большой объем кода может быть использована повторно
• Вы можете вручную разбить в реальном времени и не в реальном времени задачи и попытаться достичь ОТКЛИКА < 1s, как вы хотите.
• Я думаю, что время миграция не будет очень высокой, так как большая часть кода будет в Linux

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

Следующая архитектура RTLinux может помочь вам понять, как это возможно.