Вычисления в реальном времени

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

Вычисления в реальном времени ( RTC ) — это термин в компьютерной науке для аппаратных и программных систем, подверженных «ограничениям реального времени», например, от события до ответа системы . ^[1] Программы реального времени должны гарантировать ответ в пределах определенных временных ограничений, часто называемых «сроками». ^[2]

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

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

Система реального времени описывается как система, которая «контролирует среду, получая данные, обрабатывая их и возвращая результаты достаточно быстро, чтобы повлиять на среду в данный момент». ^[3] Термин «реальное время» используется в системах управления процессами и корпоративных системах для обозначения «без значительной задержки».

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

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

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

Миникомпьютеры, особенно в 1970-х годах и позже, когда они были встроены в специализированные встроенные системы, такие как сканеры DOG ( цифровая экранная графика ), увеличили потребность в приоритетных ответах с малой задержкой для важных взаимодействий с входящими данными, и поэтому операционные системы, такие как RDOS (Real-Time Disk Operating System) и RTOS с фоновым и приоритетным планированием от Data General, а также RT -11 от Digital Equipment Corporation датируются этой эпохой. Фоново-приоритетное планирование позволяло задачам с низким приоритетом использовать процессорное время, когда не требовалось выполнять задачи переднего плана, и давало абсолютный приоритет на переднем плане потокам/задачам с самым высоким приоритетом. Операционные системы реального времени также использовались для многопользовательских задач с разделением времени . Например, Data General Business Basic могла работать на переднем плане или в фоновом режиме RDOS и вводила дополнительные элементы в алгоритм планирования, чтобы сделать его более подходящим для людей, взаимодействующих через немые терминалы .

Ранние персональные компьютеры иногда использовались для вычислений в реальном времени. Возможность деактивации других прерываний позволяла использовать жестко запрограммированные циклы с определенным временем, а низкая задержка прерываний позволяла реализовать операционную систему реального времени, давая пользовательскому интерфейсу и дисковым накопителям более низкий приоритет, чем поток реального времени. По сравнению с ними программируемый контроллер прерываний процессоров Intel (8086..80586) генерирует очень большую задержку, а операционная система Windows не является операционной системой реального времени и не позволяет программе полностью захватить процессор и использовать свой собственный планировщик , не используя собственный машинный язык и, таким образом, обходя весь прерывающий код Windows. Однако существует несколько библиотек кодирования, которые предлагают возможности реального времени на языке высокого уровня в различных операционных системах, например Java Real Time . Более поздние микропроцессоры, такие как Motorola 68000 и последующие члены семейства (68010, 68020, ColdFire и т. д.), также стали популярны у производителей промышленных систем управления. В этой области применения управление в реальном времени обеспечивает реальные преимущества с точки зрения производительности и безопасности процесса. ^{[ необходима цитата ]}

Система называется системой реального времени , если общая правильность операции зависит не только от ее логической правильности, но и от времени, в течение которого она выполняется. ^[5] Системы реального времени, а также их сроки, классифицируются по последствиям пропуска срока: ^[6]

• Сложный  — несоблюдение сроков означает полный сбой системы.
• Фирма  – редкие промахи в сроках допустимы, но могут ухудшить качество обслуживания системы. Полезность результата равна нулю после его крайнего срока.
• Мягкий  – полезность результата снижается после истечения срока его получения, тем самым снижая качество обслуживания системы.

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

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

• Система управления двигателем автомобиля представляет собой жесткую систему реального времени, поскольку задержка сигнала может привести к отказу двигателя или его повреждению.
• Медицинские системы, такие как кардиостимуляторы . Несмотря на то, что задача кардиостимулятора проста, из-за потенциального риска для жизни человека такие медицинские системы, как правило, должны проходить тщательное тестирование и сертификацию, что в свою очередь требует сложных вычислений в реальном времени, чтобы предоставить доказуемые гарантии того, что отказ маловероятен или невозможен.
• Контроллеры промышленных процессов, например, машина на сборочной линии . Если машина задерживается, деталь на сборочной линии может выйти за пределы досягаемости машины (оставив продукт нетронутым), или машина или продукт могут быть повреждены из-за активации робота в неподходящее время. Если неисправность обнаружена, оба случая приведут к остановке сборочной линии, что замедлит производство. Если неисправность не обнаружена, продукт с дефектом может пройти через производство или может вызвать повреждение на более поздних этапах производства.
• Системы жесткого реального времени обычно взаимодействуют на низком уровне с физическим оборудованием во встроенных системах . Ранние игровые системы, такие как Atari 2600 и Cinematronics vector graphics, имели жесткие требования к реальному времени из-за природы графического и синхронизирующего оборудования.
• Программные модемы заменяют аппаратный модем программным обеспечением, работающим на процессоре компьютера . Программное обеспечение должно запускаться каждые несколько миллисекунд для генерации следующих аудиоданных для вывода. Если эти данные запаздывают, принимающий модем потеряет синхронизацию, что приведет к длительному перерыву в восстановлении синхронизации или к полной потере соединения.
• Многие типы принтеров имеют жесткие требования к реальному времени, например, струйные принтеры (чернила должны быть нанесены в правильное время, когда печатающая головка пересекает страницу), лазерные принтеры (лазер должен быть активирован в правильное время, когда луч сканирует вращающийся барабан), матричные и различные типы линейных принтеров (ударное устройство должно быть активировано в правильное время, когда печатающий механизм выравнивается с желаемым выводом). Сбой в любом из них может привести либо к отсутствию вывода, либо к его смещению.

В контексте многозадачных систем политика планирования обычно управляется приоритетами ( упреждающие планировщики). В некоторых ситуациях они могут гарантировать производительность в режиме жесткого реального времени (например, если набор задач и их приоритеты известны заранее). Существуют и другие планировщики жесткого реального времени, такие как rate-monotonic , которые не распространены в системах общего назначения, так как для планирования задачи требуется дополнительная информация: а именно ограниченная или наихудшая оценка того, как долго задача должна выполняться. Существуют специальные алгоритмы для планирования таких задач жесткого реального времени, такие как early deadline first , который, игнорируя накладные расходы на переключение контекста , достаточен для системных нагрузок менее 100%. ^[7] Новые системы планирования наложения, такие как адаптивный планировщик разделов, помогают управлять большими системами со смесью приложений жесткого реального времени и нереального времени.

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

• Машина сборочной линии, описанная ранее как жесткий реальный режим, вместо этого может считаться жестким реальным режимом. Пропущенный срок все равно приводит к ошибке, которую необходимо устранить: может быть оборудование, которое помечает деталь как плохую или выталкивает ее со сборочной линии, или сборочная линия может быть остановлена, чтобы оператор мог исправить проблему. Однако, пока эти ошибки случаются нечасто, их можно терпеть.

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

• Программное обеспечение, которое поддерживает и обновляет планы полетов для коммерческих авиалайнеров . Планы полетов должны поддерживаться в актуальном состоянии, но они могут работать с задержкой в ​​несколько секунд.
• Системы живого аудио-видео обычно также работают в режиме мягкого реального времени. Кадр аудио, который воспроизводится с опозданием, может вызвать кратковременный сбой звука (и может привести к соответствующей задержке всего последующего звука, создавая ощущение, что звук воспроизводится медленнее, чем обычно), но это может быть лучше, чем альтернативы продолжения воспроизведения тишины, статики, предыдущего аудиокадра или предполагаемых данных. Кадр видео, который задерживается, обычно вызывает еще меньше помех для зрителей. Система может продолжать работать, а также восстанавливаться в будущем с помощью прогнозирования рабочей нагрузки и методологий реконфигурации. ^[8]
• Аналогично, видеоигры часто являются мягкими в реальном времени, особенно когда они пытаются достичь целевой частоты кадров . Поскольку следующее изображение не может быть вычислено заранее, поскольку оно зависит от ввода от игрока, доступно только короткое время для выполнения всех вычислений, необходимых для генерации кадра видео, прежде чем этот кадр должен быть отображен. Если крайний срок пропущен, игра может продолжаться с более низкой частотой кадров; в зависимости от игры, это может повлиять только на ее графику (в то время как игровой процесс продолжается с нормальной скоростью), или сам игровой процесс может быть замедлен (что было распространено на старых консолях третьего и четвертого поколения ).

В процессе цифровой обработки сигналов (DSP) в реальном времени анализируемые (входные) и генерируемые (выходные) образцы могут обрабатываться (или генерироваться) непрерывно за время, необходимое для ввода и вывода одного и того же набора образцов, независимо от задержки обработки. ^[9] Это означает, что задержка обработки должна быть ограничена, даже если обработка продолжается неограниченное время. Это означает, что среднее время обработки на образец, включая накладные расходы , не превышает периода выборки, который является обратной величиной частоты выборки . Это критерий того, группируются ли образцы вместе в большие сегменты и обрабатываются как блоки или обрабатываются по отдельности, и есть ли длинные, короткие или несуществующие входные и выходные буферы .

Рассмотрим пример аудио DSP ; если процессу требуется 2,01 секунды для анализа , синтеза или обработки 2,00 секунд звука, то он не является процессом реального времени. Однако, если он занимает 1,99 секунды, то он является или может быть преобразован в процесс DSP реального времени.

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

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

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

Задержки при двусторонней связи в режиме реального времени менее 300 мс («задержка в обоих направлениях» или удвоенная задержка при однонаправленной связи) считаются «приемлемыми» для избежания нежелательного «наложения помех» во время разговора.

Вычисления в реальном времени иногда ошибочно принимают за высокопроизводительные вычисления , но это не точная классификация. ^[11] Например, огромный суперкомпьютер , выполняющий научное моделирование, может обеспечивать впечатляющую производительность, но при этом не выполнять вычисления в реальном времени. И наоборот, как только аппаратное и программное обеспечение для антиблокировочной тормозной системы было разработано для соответствия требуемым срокам, дальнейшее повышение производительности не является обязательным или даже полезным. Кроме того, если сетевой сервер сильно загружен сетевым трафиком, его время отклика может быть больше, но (в большинстве случаев) он все равно будет работать до истечения срока ожидания (достижения крайнего срока). Следовательно, такой сетевой сервер не будет считаться системой реального времени: временные сбои (задержки, тайм-ауты и т. д.) обычно невелики и разрозненны (ограничены по эффекту), но не являются катастрофическими сбоями . В системе реального времени, такой как индекс FTSE 100 , замедление сверх пределов часто будет считаться катастрофическим в контексте его применения. Самым важным требованием к системе реального времени является стабильный вывод, а не высокая пропускная способность.

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

Термин «почти в реальном времени» или «почти в реальном времени» (NRT) в телекоммуникациях и вычислениях относится к временной задержке , вводимой автоматизированной обработкой данных или сетевой передачей между возникновением события и использованием обработанных данных, например, для отображения или обратной связи и целей управления. Например, отображение в близком к реальному времени отображает событие или ситуацию, как они существовали в текущий момент времени за вычетом времени обработки, как почти во времени живого события. ^[12]

Различие между терминами «почти в реальном времени» и «в реальном времени» несколько размыто и должно быть определено для данной ситуации. Термин подразумевает, что нет существенных задержек. ^[12] Во многих случаях обработка, описываемая как «в реальном времени», была бы более точно описана как «почти в реальном времени».

Near real-time также относится к отложенной передаче голоса и видео в реальном времени. Позволяет воспроизводить видеоизображения в приблизительно реальном времени, не дожидаясь загрузки целого большого видеофайла. Несовместимые базы данных могут экспортировать/импортировать в общие плоские файлы, которые другая база данных может импортировать/экспортировать по расписанию, чтобы они могли синхронизировать/обмениваться общими данными в «почти реальном времени» друг с другом.

Существует несколько методов, помогающих проектировать системы реального времени, примером которых является MASCOT , старый, но очень успешный метод, который представляет параллельную структуру системы. Другие примеры: HOOD , Real-Time UML, AADL , профиль Ravenscar и Real-Time Java .

• Бернс, Алан; Уэллингс, Энди (2009), Системы реального времени и языки программирования (4-е изд.), Addison-Wesley, ISBN 978-0-321-41745-9
• Буттаццо, Джорджио (2011), Жесткие вычислительные системы реального времени: алгоритмы предсказуемого планирования и приложения, Нью-Йорк, Нью-Йорк: Springer, ISBN 9781461406761– через Google Книги.
• Лю, Джейн WS (2000), Системы реального времени , Аппер Сэддл Ривер, Нью-Джерси: Prentice Hall.
• Международный журнал систем вычислений, критических по времени

• Технический комитет IEEE по системам реального времени
• Технический комитет Euromicro по системам реального времени
• Что, где и почему используется моделирование в реальном времени
• Джонстон, Р. Л. "RTOS — расширение OS/360 для управления космическими полетами в реальном времени" (PDF) . Bitsavers . Получено 24 февраля 2023 г. .
• Coyle, RJ; Stewart, JK (сентябрь 1963 г.). «Проектирование системы программирования в реальном времени». Компьютеры и автоматизация . XII (9). Силвер-Спринг, Мэриленд: Datatrol Corporation: 26–34. [...] набор заметок, которые, как мы надеемся, укажут на проблемные области, которые следует учитывать при проектировании в реальном времени.