Реферат: Основные понятия и программное обеспечение систем реального времени
Из приведенных определений следует несколько интересных выводов.
Во-первых, практически все системы промышленной автоматизации являются системами реального времени.
Во-вторых, принадлежность системы к классу систем реального времени никак не связана с ее быстродействием. Например, если ваша система предназначена для контроля уровня грунтовых вод, то даже выполняя измерения с периодичностью один раз за полчаса, она будет работать в реальном времени.
Исходные требования к времени реакции системы и другим временным параметрам определяются или техническим заданием на систему, или просто логикой ее функционирования. Например, шахматная программа, думающая над каждым ходом более года, работает явно не в реальном времени, так как шахматист скорее всего не доживет до конца партии. Однако точное определение «приемлемого времени реакции» не всегда является простой задачей, а в системах, где одним из звеньев служит человек, подвержено влиянию субъективных факторов. Впрочем, человек – это своеобразная вычислительная машина, а мы договорились многопроцессорных конфигураций не рассматривать.
Интуитивно понятно, что быстродействие системы реального времени должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления. Чтобы оценить необходимое быстродействие для систем, имеющих дело со стационарными процессами, часто используют теорему Котельникова, из которой следует, что частота дискретизации сигналов должна быть как минимум в 2 раза выше граничной частоты их спектра.
При работе с широкополосными по своей природе переходными процессами (транзиент-анализ) часто применяют быстродействующие АЦП с буферной памятью, куда с необходимой скоростью записывается реализация сигнала, которая затем анализируется и/или регистрируется вычислительной системой. При этом требуется закончить всю необходимую обработку до следующего переходного процесса, иначе информация будет потеряна. Подобные системы иногда называют системами квази-реального времени.
2. Классификация систем реального времени
Принято различать системы «жесткого» и «мягкого» реального времени.
1. Системой «жесткого» реального времени называется система, где неспособность обеспечить реакцию на какие-либо события в заданное время является отказом и ведет к невозможности решения поставленной задачи. Последствия таких отказов могут быть разные, от пролива драгоценной влаги на линии по розливу алкогольных напитков до более крупных неприятностей, если, например, вовремя не сработала система аварийных блокировок атомного реактора. Многие теоретики ставят здесь точку, из чего следует, что время реакции в «жестких» системах может составлять и секунды, и часы, и недели. Однако большинство практиков считают, что время реакции в системах «жесткого» реального времени должно быть все-таки минимальным. Идя на поводу у практиков, так и будем считать. Разумеется, однозначного мнения о том, какое время реакции свойственно «жестким» системам, нет. Более того, с увеличением быстродействия микропроцессоров это время имеет тенденцию к уменьшению, и если раньше в качестве границы называлось значение 1 мс, то сейчас, как правило, называется время порядка 100 мкс.
2. Точного определения для «мягкого» реального времени не существует, поэтому будем считать, что сюда относятся все системы реального времени, не попадающие в категорию «жестких». Так как система «мягкого» реального времени может не успевать ВСЁ делать ВСЕГДА в заданное время, возникает проблема определения критериев успешности (нормальности) ее функционирования. Вопрос этот совсем не простой, так как в зависимости от функций системы это может быть максимальная задержка в выполнении каких-либо операций, средняя своевременность отработки событий и т. п. Более того, эти критерии влияют на то, какой алгоритм планирования задач является оптимальным. Вообще говоря, системы «мягкого» реального времени проработаны теоретически далеко не до конца.
3. Ядра и операционные системы реального времени
Чтобы быстрее перейти к делу, примем как очевидные следующие моменты:
1. Когда-то операционных систем совсем не было.
2. Через некоторое время после их появления возникло направление ОС РВ.
3. Все ОС РВ являются многозадачными операционными системами. Задачи делят между собой ресурсы вычислительной системы, в том числе и процессорное время.
Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возможностей. Ядра предоставляют пользователю такие базовые функции, как планирование и синхронизация задач, межзадачная коммуникация, управление памятью и т. п. Операционные системы в дополнение к этому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня.
По своей внутренней архитектуре ОС РВ можно условно разделить на монолитные ОС, ОС на основе микроядра и объектно-ориентированные ОС. Графически различия в этих подходах иллюстрируются рисунками 1, 2, 3. Преимущества и недостатки различных архитектур достаточно очевидны, поэтому подробно мы на них останавливаться не будем.
Пользователь, напуганный перспективой изучать новую операционную систему, может здесь вполне резонно спросить: «А нельзя ли вообще обойтись без всех этих заумных вещей?»
Если отвечать на этот вопрос односложно, то да, МОЖНО. Однако ответ на вопрос о том, когда это НУЖНО делать, остается, конечно, за пользователем. Материалы этого реферата, возможно, дадут некоторую пищу к размышлениям на эту тему.
3.1. Задачи, процессы, потоки
Существуют различные определения термина «задача» для многозадачной ОС РВ. Мы будем считать задачей набор операций (машинных инструкций), предназначенный для выполнения логически законченной функции системы. При этом задача конкурирует с другими задачами за получение контроля над ресурсами вычислительной системы. Принято различать две разновидности задач: процессы и потоки. Процесс представляет собой отдельный загружаемый программный модуль (файл), который, как правило, во время исполнения имеет в памяти свои независимые области для кода и данных. В отличие от этого потоки могут пользоваться общими участками кода и данных в рамках единого программного модуля.
Хорошим примером многопоточной программы является редактор текста WORD, где в рамках одного приложения может одновременно происходить и набор текста, и проверка правописания.
3.1.1. Преимущества потоков
1. Так как множество потоков способно размещаться внутри одного ЕХЕ модуля, это позволяет экономить ресурсы как внешней, так и внутренней памяти.
2. Использование потоками общей области памяти позволяет эффективно организовать межзадачный обмен сообщениями (достаточно передать указатель на сообщение). Процессы не имеют общей области памяти, поэтому ОС должна либо целиком скопировать сообщение из области памяти одной задачи в область памяти другой (что для больших сообщений весьма накладно), либо предусмотреть специальные механизмы, которые позволили бы одной задаче получить доступ к сообщению из области памяти другой задачи.
3. Как правило, контекст потоков меньше, чем контекст процессов, а значит, время переключения между задачами-потоками меньше, чем между задачами-процессами.
4. Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕмодуле, значительно упрощается использование программ-отладчиков (debugger).