Операционная система реального времени что это
Перейти к содержимому

Операционная система реального времени что это

  • автор:

Лекция 1. Системы реального времени. Виды ОС РВ. Требования к ОС РВ

Управление автоматическими или автоматизированными комплексами, предъявляющими высокие требования к времени выполнения задач осуществляется операционными системами реального времени. Они обеспечивают гарантированное время реакции на внешние события и минимальные задержки.

Операционная система реального времени, ОС РВ (англ. Real-Time Operating System) — тип операционной системы, как правило, специального назначения. Для этого термина есть различные определения, порой противоречащие друг другу:

  • ОС, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе
  • Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»
  • ОС, реагирующая в предсказуемое время на непредсказуемое появление внешних событий
  • Интерактивные системы постоянной готовности. В категорию ОС РВ их относят исходя из маркетинговых соображений и если интерактивную программу называют «работающей в реальном времени», то это лишь означает, что запросы от пользователя обрабатываются с задержкой, незаметной для человека.
  • Иногда понятие системы реального времени отождествляют с «быстрой системой», но это не всегда правильно, так как важно не время задержки реакции ОС РВ, а то, чтобы этого времени было достаточно для рассматриваемого приложения и оно было гарантированно.
  • Во многих специализированных сферах вводят свои понятия «реального времени». Например, процесс цифровой обработки сигнала называют идущим в реальном времени, если анализ и/или генерация данных может быть произведён за то же время, что и анализ/генерация тех же данных без цифровой обработки сигнала. Например, если при обработке аудио данных требуется 2,01 секунд на анализ 2,00 секунд звука, то это не процесс реального времени. Если же требуется 1,99 секунд, то это процесс реального времени.

Для систем реального времени характерно следующее:

  • гарантированное время реакции на внешние события (например на прерывания от оборудования);
  • жёсткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями);
  • повышенные требования к времени реакции на внешние события или реактивности (задержка вызова обработчика прерывания не более десятков микросекунд, задержка при переключении задач не более сотен микросекунд)

Классическим примером задачи, где требуется ОС РВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется и робот имеет лишь маленький промежуток времени, когда он может её взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он спозиционируется раньше, то деталь ещё не успеет подъехать, и он заблокирует ей путь.

Виды ОС РВ

Динамические свойства программ реального времени принято характеризовать тремя определениями: программы «жесткого» (hard), «мягкого» (soft) и интерактивного («условного») реального времени.

Жесткое реальное время. Предусматривает наличие гарантированного времени отклика системы на конкретное событие, например, аппаратное прерывание, выдачу команды управления и т.п. Абсолютная величина времени отклика большого значения не имеет. Так, если необходимо, чтобы программа отработала некоторую команду за 1 миллисекунду, но она справляется с этим заданием лишь в 95% случаев, а в 5% не укладывается в норматив, такую систему нельзя охарактеризовать как работающую в жестком реальном времени. Если же команду нужно отработать в течение часа, что и происходит в 100% случаев – налицо жесткое реальное время.

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

Мягкое реальное время. В этом случае ожидающееся время отклика системы является величиной скорее индикативной, нежели директивной. Конечно, предполагается что в большинстве случаев (процентов 80 — 90) отклик уложится в заданные пределы. Однако и остальные варианты – в том числе полное отсутствие реакции системы – не должны приводить к плачевным результатам. Обычно считается, что если временной норматив превышен на один порядок, то это еще терпимо .

Интерактивное реальное время. Является скорее психологической, нежели технической характеристикой. Определяет время, в течение которого оператор – человек – способен спокойно, без нервозности, ожидать реакции системы на данные им указания. В качестве примера можно привести весьма популярные сегодня игры из категории «стратегии реального времени» (real-time strategy, см. например квазар на основе Warhammer).

В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.

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

Основные требования к ОС РВ

Мартин Тиммерман (директор компании-разработчика встраиваимых систем Dedicated Systems Experts) сформулировал следующие необходимые требования для ОС РВ:

  • ОС должна быть многозадачной и допускающей вытеснение (preemptable),
  • ОС должна обладать понятием приоритета для потоков,
  • ОС должна поддерживать предсказуемые механизмы синхронизации,
  • ОС должна обеспечивать механизм наследования приоритетов,
  • поведение ОС должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.); это значит, что во всех сценариях рабочей нагрузки системы должно быть определено максимальное время отклика.

Особенности архитектуры ОС РВ

В течение последних 25-30 лет структура операционных систем эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер. Эти решения в той или иной степени нашли применение и при разработке операционных систем реального времени.

Монолитная архитектура представляет систему, состоящую из набора взаимодействующих модулей. Приложения обращаются к системе через API модулей. Изменения одного модуля влияют на другие модули. Чем больше модулей, чем сложнее они связаны между собой, тем тем менее предсказуемо поведение такой системы в процессе эксплуатации. Кроме того, возникают трудности для использования ОС такого типа в распределенной многопроцессорной системе.

Монолитное ядро ОС

Рис.1. Монолитная архитектура ОС РВ

Многослойная архитектура описывает систему, состоящую из нескольких функциональных уровней. Приложение может обращаться к аппаратным ресурсам как через системные вызовы ядра и системные службы, так и через API уровней. Вообще-то, возможность обращения к нижележащим слоям минуя верхние уровни семантически неверно, но для систем реального времени такая организация позволяет увеличить предсказуемость системы и снизить время отклика. Недостатком многослойной архитектуры является то, что изменения одного слоя влияют на соседние слои. Еще один недостаток, свойственный многослойной архитектуре – отсутствие многозадачности. Однако, далеко не всегда и не всем системам реального времени требуется поддержка многозадачности. Например, сложно обосновать необходимость многозадачного режима для встроенной ОС промышленного робота, подающего детали на конвейер.

Многослойная архитектура ОС

Рис.2. Многослойная архитектура ОС РВ

Клиент-серверная архитектура ОС основана на минимизации количества функций, выполняемых ядром (точнее, микроядром) такой системы. Например, на уровне ядра выполняются только планировщик, примитивы синхронизации и служба сообщений. Вся остальная функциональность выносится на пользовательский уровень и реализуется через серверы. Приложения-клиенты обращаются к ним и получают от них ответы путем обмена сообщениям через службу сообщений уровня ядра.

Клиент-серверная архитектура на основе микроядра

Рис.3 Клиент-серверная архитектура ОС РВ

Клиент-серверная архитектура позволяет создавать масштабируемые ОС и упрощает распределение в многопроцессорной системе. При эксплуатации системы замена одного модуля не вызывает эффекта “снежного кома”; кроме того, сбой модуля не всегда влечет за собой отказ системы в целом. Появилась возможность динамической загрузки и выгрузки модулей. Главной проблемой в этой модели является защита памяти, поскольку серверные процессы должны быть защищены. При каждом запросе сервиса система должна переключаться с контекста приложения на контекст сервера. При поддержке защиты памяти время переключения с одного процесса на другой увеличивается.

Контрольные вопросы

  1. Дайте определение операционной системы реального времени
  2. Что такое deadline?
  3. В чем отличие «жесткого» реального времени от «мягкого»
  4. Сформулируйте основные требования к ОС РВ
  5. Укажите основные отличия в требованиях к ОС РВ от универсальных ОС
  6. Опишите модульную архитектуру
  7. Опишите многослойную архитектуру
  8. Опишите клиент-серверную архитектуру

Системы реального времени. Виды ОС РВ. Требования к ОС РВ

ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ Текст научной статьи по специальности «Математика»

Статья посвящена обзору операционных систем реального времени, применимых на микроконтроллерах . Будут рассмотрены основные понятия, методы работы и организации представленных ОС, также уделено особое внимание обобщенной структуры системы.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по математике , автор научной работы — Данченко Д.Г.

ОБЗОР МОДЕЛЕЙ ОРГАНИЗАЦИИ ВСТРАИВАЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ МЕДИЦИНСКОГО ОБОРУДОВАНИЯ С АВТОНОМНЫМ ПИТАНИЕМ

Реализация операционной системы для микроконтроллеров AVR ATmega32
FreeRTOS — операционная система для микроконтроллеров
FreeRTOS — операционная система для микроконтроллеров
FreeRTOS — операционная система для микроконтроллеров
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

REAL-TIME OPERATING SYSTEMS

The article is devoted to the overview of real-time operating systems, applicable to the MCU. Will examine the basic concepts, methods of work and organization is represented by OS, also highlight the generalized structure of the system.

Текст научной работы на тему «ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ»

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

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

1. Активные и интерактивные образовательные технологии в высшей школе: учебное пособие / сост. Т.Г. Мухина. — Н. Новгород: ННГАСУ. -2013. — 97с.

2. Гуляева В.А. Возможности использования интерактивной доски в преподавании гистологии. // Международный научно-практический журнал «Интеграция наук».-2017.-10(14) — С. 88-90.

3. Панфилова А.П. Инновационные педагогические технологии: Активное обучение: учеб. пособие для студ. высш. учеб. заведений. — М.: Издательский центр «Академия». — 2009. — 192 с.

Данченко Д.Г. студент магистратуры 2 курса факультет «Физико-математический» ФГБОУ ВО «Брянский государственный университет имени

академика И.Г. Петровского» Россия, г. Брянск ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

Статья посвящена обзору операционных систем реального времени, применимых на микроконтроллерах. Будут рассмотрены основные понятия, методы работы и организации представленных ОС, также уделено особое внимание обобщенной структуры системы.

Ключевые слова: операционная система реального времени, ОСРВ, микроконтроллер, STM32, FreeRTOS, многозадачность.

Danchenko, D. G. graduate student 2 course, faculty «physics and mathematics » «Bryansk state University named after academician I. G. Petrovsky»

REAL-TIME OPERATING SYSTEMS

The article is devoted to the overview of real-time operating systems, applicable to the MCU. Will examine the basic concepts, methods of work and

organization is represented by OS, also highlight the generalized structure of the system.

Key words: operating system, real time, RTOS, microcontroller, STM32, FreeRTOS, multitasking.

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

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

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

Операционная система реального времени (ОСРВ, англ. real-time operating system, RTOS) — тип операционной системы, основное назначение которой — предоставление необходимого и достаточного набора функций для работы систем реального времени на конкретном аппаратном оборудовании.

Суть работы такой операционной системы состоит в том, чтобы вся программа была разбита на множества задач, каждая из которых будет отвечать лишь за свою часть работы. Такую задачу в ОСРВ можно рассматривать как подпрограмму всей программы, которая содержит в себе независимый алгоритм. К каждой такой задаче назначается свой приоритет, собственная область стека, набор регистров ЦПУ.

Любая задача может находиться в одном из 4 состояний:

Состояние «Ожидает события». Для выполнения программы необходимо выполнение какого-либо события (завершения операции ввода-вывода, истечение заданного времени, доступность ресурса).

Состояние «Выполняется. Задача запущена и использует ресурсы

Состояние «Готова». Задача может выполняться, но ее приоритет меньше приоритета уже выполняемой на данный момент задачи.

Состояние «Прервана». Задача была прервана и ЦПУ находится в процессе обработки.

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

Так как каждой задаче выделяется область памяти, так называемый стек, то при выполнении задачи ядро сохраняет контекст данной задачи. Это необходимо для быстрого переключения между различными задачами. Механизм переключения задач довольно прост: контекст новой задачи восстанавливается из соответствующей области памяти и возобновляется выполнение кода новой, более приоритетной задачи. Время, которое необходимо для переключения контекста, определяется числом регистров, необходимые для сохранения и восстановления ЦПУ.

Основой всей операционной системы является ядро. Ядро отвечает непосредственно за управление многозадачностью (иными словами за управление временем ЦПУ) и связью между задачами. Основная роль ядра -переключение контекста. Как было сказано выше, использование ОСРВ позволяет упростить проект путем разбиения всей программы на индивидуальные подпрограммы со своим алгоритмом. Именно ядро ОСРВ отвечает за лучшую оптимизацию ЦПУ под заданные задачи в лице написанных программ.

Также в состав ядра входит планировщик (или так называемый диспетчер), который отвечает за очередность следования задач. Как правило, большинство ядер ОСРВ являются приоритетными. К каждой поставленной задаче присваивается приоритет на основе ее важности во всей программе. В таком ядре управление ЦПУ будет всегда отдаваться более приоритетной готовой задаче. На этой основе выделяют два типа ядер, которые основаны на приоритете: неприоритетные и приоритетные.

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

приоритетную задачу, но при этом она всегда вернется к первичной задачи.

гжопрч юригаиш ■мщачя

Подпрограмма прсры ваш и

Подпр о грамма прермван! м делает высокогр Iор!ггетную

‘ЯЭДЛчу ГОТОВОЙ К ВЫПОЛНЕН ]Ю

ВыСОКОПр! ЮрЦГеТНая чадачл

Ннзксщиюр петая задача передает чпра в лет к

цемтриш.ным процессором »ысокоцяюр! гтешоп задаче

Рисунок 1. График неприоритетного ядра

На рисунке 1 показан алгоритм работы неприоритетного ядра: во время выполнения низкоприоритетной задачи (1) происходит прерывание (2). Подпрограмма прерывания обрабатывает событие (3) и делает высокоприоритетную задачу готовой к исполнению. После окончания подпрограммы прерывания выполняется задача возврата из прерывания (4). Затем начинает выполняться прерванная задача (5). После выполнения задачи (5), вызывается сервис ядра для передачи управления ЦПУ другой высокоприоритетной задачи. Итог является выполнение задачи (7).

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

В отличии от неприоритетного ядра, приоритетное же используется тогда, когда важна реакция системы на событие (рис.2).

Подпрограмм цмрывшыя делает высокого юр] цедоую задачу готовой к выпотенпю

Рисунок 2. График приоритетного ядра

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

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

Теперь необходимо определить минимальные требования к микроконтроллерам для работы операционной системы реального времени. Первое, к чему необходимо обратить внимание, это объем ПЗУ для ядра системы. В зависимости от задач, архитектуры, функциональности ядра, размер занимаемого пространства варьируется от 1 до 100 Кб. К примеру, ядро 8-битного микроконтроллера, которое производить только планирование задач, переключение контекста, управление задержками и тайм-аутами, занимает около 1-3 Кб.

Так как задачи выполняются независимо друг от друга, то каждая задача должна обладать собственной областью стека (ОЗУ). Перед разработчиком стоит задача в определении требований к стеку для каждой задачи в программе. Размер стека не должен рассчитываться только исходя из требований задач, а должен также рассчитываться на максимальное число вложений прерываний. В зависимости от применяемого микроконтроллера и ядра, может использоваться отдельный стек для обработки всего кода уровня прерывания. Данная рекомендация необходима, так как требования к стеку для каждой задачи может быть существенно уменьшены.

Еще одна желательная особенность — способность определить размер стека индивидуально для каждой отдельной задачи. Так как некоторые требуют, чтобы стеки всех задач были одинаковыми по размеру. Абсолютно

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

Таким образом можно заключить, что многозадачная система требует большого количества пространства для кода (ПЗУ) и пространства для данных (ОЗУ). Непосредственно количество дополнительного объема постоянной памяти зависит от размера ядра системы, а количество оперативной памяти зависит лишь от числа поставленных задач в разрабатываемой системе. Но, как правило, современные микроконтроллеры обладают достаточным объемом памяти для разработки собственного проекта на базе ОСРВ. Существует ряд контроллеров, у которых присутствует возможность расширить объем памяти путем добавления внешних схем энергонезависимой памяти.

Основываясь на вышесказанном, можно выделить особенности построения операционных систем реального времени. Для этого введем такое понятие как функционирование в реальном времени — это способность ОС обеспечить задачу всеми необходимыми ресурсами за определенный период времени. Так как строение ОСРВ довольно сложна, то существуют различные нюансы, которые стоит соблюдать при разработке ОС для микроконтроллеров.

Первое, что необходимо учитывать — это разработка ОС не только под конкретный микроконтроллер с определенной производительностью. ОСРВ должна обладать гибкими параметрами для беспроблемной смены контроллера. То есть, если ОС работает на одном конкретном контроллере и хорошо справляется с поставленными задачами, то при смене контроллера на менее производительный должна остаться такая же хорошая работа с задачами, как и на более производительном микроконтроллере. Второе — в некоторых случаях нельзя использовать тот или иной тип ОС. К примеру, на контроллерах, у которых реализован аппаратный стек, нельзя использовать вытесняющую ОС, так как такая ОС предъявляет высокие требования к памяти контроллера.

Именно на этих основах реализованы операционные системы реального времени. В настоящее время существуют более 80 различных ОС, которые поддерживают 8-, 16-, 32-разрядные микроконтроллеры. Как было сказано ранее, многие проекты ОС являются законченными релизами с ядром, менеджером ввода-вывода, системой управления выводом информации, файловую систему, работу с сетью, отладчиками и компиляторами. Стоимость таких ОС варьируется от нескольких десятков до сотен тысяч долларов США. Но также существуют некоммерческие проекты с открытым исходным кодом.

Рассмотрим основные известные операционные системы реального времени:

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

Основные достоинства данной системы:

— Обладает мощным функционалом

— Портирована на большое количество контроллеров

— Имеются различные библиотеки

Недостатки предложенного продукта:

— Довольно сложный процесс портирования на новые семейства микроконтроллеров

Данная операционная система предназначена для промышленного применения и обладает самым широким диапазоном ресурсов, от 8-битных контроллеров с 16 Кб ПЗУ и 2 Кб ОЗУ до 32-битных контроллеров. Такая система поддерживает неограниченное количество задач, приоритетов.

Основные достоинства системы:

— Огромное количество библиотек и функций

— Широкая поддержка различных видов и семейств микроконтроллеров

Недостатки предложенного продукта:

— Сложна в использовании

Простая операционная система, которая написана на языке C++. Обладает только планировщиком и базовыми механизмами взаимодействия между процессами. В данной ОС планировщик вытесняющей

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

Основные достоинства системы:

— Очень простая система в качестве освоения

— Работает на контроллерах с малым объемом RAM — от 512 байт

— Открытый исходный код

Недостатки предложенного продукта:

— Планировщик только с вытесняющей многозадачностью

— Имеет малый набор инструментов для более удобной работы

Данный список операционных систем можно продолжать бесконечно

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

1. FreeRTOS [Электронный ресурс]: официальный сайт системы реального времени FreeRTOS. — Режим доступа: https://freertos.org/ (дата обращения: 20.12.2017)

2. Wikipedia [Электронный ресурс]: электронная свободная энциклопедия. — Режим доступа: https://ru.wikipedia.org/ (дата обращения: 20.12.2017)

Даскалеску А.А. магистрант группы 61/1 БУ научный руководитель: Лукьянова Е.Ю., к.э.н.

кафедра экономики и финансов Гуманитарно-педагогическая академия (филиал) ФГАОУ ВО «КФУ им. В. И. Вернадского»

Крым, г. Ялта ОСОБЕННОСТИ ПРИМЕНЕНИЯ ПРОГРАММНОГО КОМПЛЕКСА «ИНТАЛЕВ: КОРПОРАТИВНЫЙ МЕНЕДЖМЕНТ» В КОММЕРЧЕСКИХ ОРГАНИЗАЦИЯХ

Аннотация. В данной статье описывается вариант применения ERP и ВРМ-систем в системах с большим объемом данных и с множеством сквозных процессов. В частности, рассматриваются особенности использования программно-методического комплекса «Инталев: Корпоративный менеджмент» и особенности его функционирования в коммерческих организациях.

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

Dascalescu A.A. Magistracy student group 61/1 «Accounting» Academy of the Humanities and Pedagogics (branch) of V.I. Vernadsky Crimean Federal University, Yalta, Crimea

Scientific adviser: Lukyanova Ye. Yu.

Philosophy Doctor in Economic Science Docent of Economics and Finance Department Academy of the Humanities and Pedagogics (branch) of V.I. Vernadsky Crimean Federal University, Yalta, Crimea

Операционные системы реального времени для начинающих

Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.

Что такое ОСРВ?

Если мы посмотрим в Википедию, то увидим аж 4 определения.
Если же говорить вкратце — то ОСРВ — это операционная система, реагирующая на внешние события в определенный промежуток времени. Отсюда мы и можем понять основное предназначение ОСРВ — приборы, в которых необходима быстрая реакция на события (однако ни в коем случае не путайте работу ОСРВ с прерываниями).

Зачем она нам нужна?

На то есть довольно много причин.
Во-первых ОСРВ поддерживает многозадачность, приоритеты процессов семафоры и многое другое.
Во-вторых она очень легкая и почти не требует ресурсов.
В-третьих все вышесказанное мы можем получить практически на любом железе (например, FreeRTOS запускается даже на 8-битных AtMega).
Ну и в-четвертых: просто поиграться и получить удовольствие.

Обзор 3 известных ОСРВ.

Внимание: дальше идет мое личное мнение.

FreeRTOS

Одна из самых популярных ОСРВ на сегодняшний день. Портирована на огромное количество железа. Оффициальный сайт.

Плюсы

1) Бесплатная
2) Портирована на большое количество железа
3) Мощный функционал
4) Есть различные библиотеки: графика, интернет и другое.
5) Хорошая документация.

Минусы

1)Довольно-таки сложный процесс портирования на новое железо.

Вывод: Это действительно профессиональная ОСРВ с хорошей документацией. Будет хороша для новичка, если на его железо уже есть порт.

KeilRTX

До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт.

Плюсы

1)Бесплатная
2)Легко портируется на новое железо( в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.

Минусы

1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.

uc/os

Мощная коммерческая ОСРВ. Сайт.

Плюсы

1) Огромное количество функций и библиотек.
2) Поддерживает много железа

Минусы

1)Коммерческая.
2) Сложна в использовании.

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.

Особенности разработки с использованием ОСРВ

Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.
При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы( или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет — то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер — когда процессу нужен ресурс — он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму( и так — до бесконечности).

Дополнительные библиотеки ОСРВ.

Часто ОСРВ предлагают различные библиотеки для работы, например, с графикой, интернетом и т.д. Они действительно удобны и не стоит брезгать их использовать. Однако, помните, что без ОСРВ, для которой они написаны, они работать не будут.
Вот примеры:
Для RTX графика интернет Файловая система

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

Операционные системы реального времени

Термины “реальное время”, “работа в реальном масштабе времени”, “операционные системы реального времени” известны всем, но толкуются они часто по-разному и спектр этих толкований очень широк. Количество иллюзий и мифов в мире реального времени велико. Часто путают такие понятия, как реальное время и скорость. Иногда полагают, что применение операционной системы реального времени (ОСРВ) автоматически разрешит все проблемы надежности предсказуемости. Порой, наоборот, считают, что системы реального времени — занятие для теоретиков, а практически любую задачу реального времени можно решить с помощью популярных ОС общего назначения: достаточно быть просто хорошим программистом и знать архитектуру компьютера. Так ли это?

Чем принципиально отличаются операционные системы реального времени от операционных систем общего назначения?

ОС общего назначения, особенно многопользовательские вроде UNIX, ориентированы на оптимальное распределение ресурсов компьютера между пользователями и выполняемыми процессами (системы разделения времени). В ОСРВ подобная задача отходит на второй план, все отступает перед главной целью — успеть среагировать на события, происходящие на объекте.

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

Рис. 1. Системы разработки ОСРВ

Применение ОСРВ всегда конкретно. Если ОС общего назначения обычно воспринимается пользователями (не разработчиками) как уже готовый набор приложений, то ОСРВ служит только иструментом для создания того или иного аппаратно-программного комплекса реального времени. И поэтому наиболее широкий класс пользователей ОСРВ составляют разработчики таких комплексов — люди, проектирующие системы управления и сбора данных. Проектируя и разрабатывая конкретную систему реального времени, программист всегда знает точно, какие события могут произойти на объекте, знает критические сроки обработки каждого из этих событий.

Назовем системой реального времени (СРВ) аппаратно-программный комплекс, реагирующий в течение предсказуемого времени на непредсказуемый поток внешних событий.

Это определение означает следующее.

Во-первых, система должна успеть отреагировать на событие, произошедшее на объекте, в течение времени, критического для этого события (meet deadline). Критическое время для каждого события определяется объектом и самим событием и, естественно, может быть разным, но время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие реакции в течение предсказанного времени считается ошибкой для СРВ.

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

Различают системы реального времени двух типов — системы жесткого реального времени и системы мягкого реального времени.

Системы жесткого реального времени не допускают никаких задержек реакции системы ни при каких условиях:

— в случае опоздания результаты окажутся бесполезными;

— в случае задержки реакции может произойти катастрофа;

— стоимость опоздания может оказаться бесконечно велика.

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

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

Примером может служить работа сети. Если система не успеет обработать очередной принятый пакет, это приведет к вынужденному перерыву на передающей стороне и, например, повторной посылке. Данные при этом не теряются, но производительность сети снижается.

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

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

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

Свойства операционных систем реального времени

Параметры ОСРВ. Выбирая ОС общего назначения, вы учитываете ее распространенность, удобство систем разработки, состав и возможности инструментария сетей, баз данных, офисных пакетов и пр.

А что важно для ОСРВ? Какова структура этих продуктов?

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

Большинство современных ведущих ОСРВ поддерживают целый спектр аппаратных архитектур, на которых работают системы исполнения (Intel, Motorola, RISC, MIPS, PowerPC и др.). Дело в том, что набор аппаратных средств является частью комплекса реального времени и аппаратура должна быть также адекватна решаемой задаче; поэтому ведущие ОСРВ, удовлетворяя самым разным требованиям по части аппаратуры, перекрывают целый ряд наиболее популярных архитектур. Систему исполнения ОСРВ вместе с компьютером, на котором она исполняется, называют целевой (target) системой.

В систему разработки входит набор средств, обеспечивающих создание и отладку приложения реального времени. Эти инструменты (компиляторы, отладчики и всевозможные вспомогательные средства) работают, как правило, в популярных и распространенных ОС, таких, как UNIX и Windows. Кроме того, многие ОСРВ имеют и так называемые резидентные средства разработки, исполняющиеся в среде само/й операционной системы реального времени, — особенно это относится к ОСРВ с ядром реального времени (об этом речь пойдет ниже).

Заметим, что функционально системы разработки ОСРВ отличаются от привычных — таких, например, как Developers Studio, TaskBuilder, поскольку они часто содержат средства дистанционной отладки, профилирования (измерение времени выполнения отдельных участков кода), эмуляции целевого процессора, специальные средства отладки взаимодействующих задач, а иногда и средства моделирования.

Время реакции системы. Почти все производители ОСРВ приводят такой параметр, как время реакции системы на прерывание (interrupt latency).

В самом деле, если главным для системы реального времени является ее способность вовремя отреагировать на внешние события, то время ее реакции является основополагающим параметром. Однако что это за время и как следует его рассматривать?

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

Как быть в этой ситуации?

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

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

Интервал от события на объекте до выполнения первой инструкции в программе его обработки и является временем реакции системы на событие. Проектируя комплекс ОСРВ, разработчики должны уметь вычислять этот интервал. Из чего он складывается?

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

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

Время реакции на прерывание, характерное для некоторых ОСРВ, представлено на рис. 2.

Рис. 2. Время реакции различных систем на прерывание

Время переключения контекста. В операционные системы реального времени заложен параллелизм — возможность одновременной обработки нескольких событий, поэтому все ОСРВ являются многозадачными. Для того, чтобы уметь оценивать накладные расходы системы при обработке параллельных событий, необходимо знать время, которое система затрачивает на передачу управления от процесса к процессу (от задачи к задаче, от нити к нити), т. е. время переключения контекста (рис. 3).

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

Размеры системы. Для ОСРВ важным параметром является размер системы исполнения — суммарный объем минимально необходимого для работы приложения системного набора (ядро, системные модули, драйверы и т. д.). Хотя надо признать, что постепенно значимость этого параметра уменьшается, тем не менее он остается важным и производители ОСРВ стремятся к тому, чтобы размеры ядра и обслуживающих модулей были невелики.

Например, размер ядра ОСРВ OS9 на микропроцессорах МС68xxx составляет 22 Кб, VxWorks — 16 Кб.

Возможность исполнения системы из ПЗУ. Это одно из базовых свойств ОСРВ. Оно позволяет создавать компактные встроенные СРВ повышенной надежности, с ограниченным энергопотреблением, без внешних накопителей.

Механизмы реального времени

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

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

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

Какие же механизмы в операционных системах реального времени делают СРВ предсказуемой?

Система приоритетов и алгоритмы диспетчеризации. Базовыми инструментами разработки сценария для системы являются система приоритетов процессов (задач) и алгоритмы планирования (диспетчеризации) ОСРВ.

В многозадачных ОС общего назначения используются, как правило, различные модификации алгоритма круговой диспетчеризации, основанные на понятии непрерывного кванта времени (time slice), которое предоставляется для исполнения данного процесса. Планировщик по истечении каждого кванта времени просматривает очередь активных процессов и принимает решение, какому из них передать управление, основываясь на приоритетах. Приоритеты могут быть фиксированными или меняться со временем — это зависит от алгоритмов планирования в данной ОС, но рано или поздно процессорное время получат все процессы в системе.

Алгоритмы круговой диспетчеризации в чистом виде в ОСРВ неприменимы. Основным их недостатком является то, что в течение непрерывного кванта времени процессором владеет только один процесс. Планировщики же ОСРВ имеют возможность сменить процесс до истечения time slice, если в этом возникла необходимость. Один из возможных алгоритмов планирования при этом — приоритетный с вытеснением. Мир ОСРВ отличается богатством различных алгоритмов планирования: динамические, приоритетные, монотонные, адаптивные и пр., цель же всегда преследуется одна — предоставить инструмент, позволяющий в нужный момент времени исполнять именно тот процесс, который необходим.

Механизмы межзадачного взаимодействия. Другой набор механизмов реального времени относится к средствам синхронизации процессов и передачи данных между ними. В него входят семафоры, мьютексы (mutex), события, сигналы, средства для работы с разделяемой памятью, каналы данных (pipes), очереди сообщений. В ОСРВ эти механизмы очень развиты. Многие из них используются и в ОС общего назначения, но их реализация в ОСРВ имеет свои особенности: время исполнения системных вызовов почти не зависит от состояния системы, и в каждой ОСРВ есть по крайней мере один быстрый механизм передачи данных от процесса к процессу.

Средства для работы с таймерами. Такие инструменты, как средства работы с таймерами, необходимы для систем с жестким временны/м регламентом, поэтому они являются необходимым атрибутом ОСРВ. Эти средства, как правило, позволяют:

— измерять и задавать различные промежутки времени (от 1 мкс и выше);

— генерировать прерывания по истечении временны/х интервалов;

— создавать разовые и циклические будильники.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *