Что такое система реального времени

Подтвердите, что Вы не робот

Приносим извинения за неудобства, но Ваш IP-адрес входит в «серый список».

Возможно Вы используете анонимайзеры/прокси/VPN или другие подобные средства (TOR, friGate, ZenMate и т.п.).

Пожалуйста пройдите проверку ReCaptcha ниже для перехода на сайт.

Please confirm you are not a robot

We apologize for the inconvenience, but your IP address is «graylisted».

Probably you are using anonymizers/proxy/VPN or similar tools (TOR, friGate, ZenMate etc.).

Терминологическое введение

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

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

К классу операционных систем общего назначения относят операционные системы, которые могут являться как однопроцессными, так и многопроцессными, как многопользовательскими, так и однопользовательскими. Это операционные системы, которые работают в составе обычных настольных систем. Их основное предназначение состоит в том, чтобы предоставить пользователю системы удобный и понятный механизм управления аппаратными средствами вычислительной системы, обрабатывать запросы пользователя, максимально изолируя его от низкоуровневых операций и интерфейсов. Такие операционные системы ориентируются в первую очередь на простоту применения, поскольку их основными пользователями обычно являются не программисты, а пользователи средней или низкой квалификации. Зачастую такие пользователи могут даже не представлять, что за красивой картинкой анимированных обоев и разнообразием всевозможных красот графических интерфейсов скрывается мощнейший программный комплекс, управляющий всем аппаратным комплексом компьютера. К подобным операционным системам относятся настольные версии операционных систем семейства Windows, Linux, Apple iOS и т.д. Иными словами, это те операционные системы, с которыми пользователь может иметь дело как на работе для выполнения каких-то необходимых задач, так и дома для развлечения.

В противоположность операционным системам общего н назначения ОС специального назначения относительно редко используются в повседневной жизни. Основные пользователи таких операционных систем — квалифицированные разработчики. Подобные операционные системы предназначены для управления ресурсами специальных вычислительных систем. Зачастую такие системы являются встраиваемыми, т.е. системами, которые должны работать, будучи встроенными непосредственно в устройство, которым они управляют. К ним можно отнести такие операционные системы, как Android, iOS, Windows CE и т.д.

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

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

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

Использование операционных систем реального времени позволяет сократить сроки разработки управляющего ПО и повысить предсказуемость его поведения в следующих случаях;

если разработанное управляющее ПО получается достаточно большим по объему;

если в процессе его выполнения требуется нескольких вычисли- тельных потоков;

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

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

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

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

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

В настоящее время существует достаточно большое количество операционных систем реального времени: LynxOS, RTLinux, VxWorks и т.д. Одной из наиболее известных операционных систем реального времени является QNX, которая иногда используется и в качестве настольной. Помимо этих коммерчески распространяемых продуктов существует еще и некоторое количество операционных систем, разработанных самостоятельно компаниями, но не распространяемых на коммерческой основе, а используемых только в составе уже готовых программно-аппаратных комплексов.

Created on Jekyll by
Ruslan Kornev

Данный учебник является частью учебно-метолического комплекта для всех специальностей укрупненной группы «Информатика и вычислительная техника».

Системы реального времени

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

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

Что такое системы реального времени? Системы жесткого и мягкого реального времени.

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

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

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

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

Стандарт POSIX 1003.1 определяет СРВ следующим образом: «Реальное время в операционных системах – это способность операционной системы обеспечить требуемый уровень сервиса в заданный промежуток времени». А стандарт IEEE 610.12 – 1990 говорит, что реальное время «Относится к системе или режиму работы, в котором вычисления проводятся в течение времени, определяемого внешним процессом, с целью управления или мониторинга внешнего процесса по результатам этих вычислений».

Иногда системами реального времени называется системы постоянной готовности (on-line системы), или «интерактивные системы с достаточным временем реакции». Обычно это делают по маркетинговым соображениям. Действительно, если интерактивную программу называют работающей в «реальном времени», то это просто означает, что она успевает обработать запросы от человека, для которого задержка в сотни миллисекунд даже незаметна.

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

Во многих сферах приложения СРВ вводят свои понятия «реального времени». Например, процесс цифровой обработки сигнала называют идущим в «реальном времени», если анализ (при вводе) и/или генерация (при выводе) данных может быть проведен за то же время, что и анализ и/или генерация тех же данных без цифровой обработки сигнала. Например, если при обработке аудио данных требуется 2.01 секунд для анализа 2.00 секунд звука, то это не процесс реального времени. Если же требуется 1.99 секунд, то это процесс реального времени.

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

Это определение означает, что:

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

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

Это определение означает, что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любая система реального масштаба времени может быть описана как состоящая из трех основных подсистем:

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

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

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

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

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

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

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

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

Читать:

Почему немеют руки при езде на велосипеде

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

Системы реального времени должны отвечать на внешние параметры ввода и создавать новые результаты вывода за ограниченное время, как показано на рисунке 1.3. Время ответа должно быть ограничено. Очень длительное время ответа может привести к отказу систем реального времени.

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

Рис. 1.3. Система реального времени должна отвечать на внешние параметры ввода и создавать новые результаты вывода за ограниченное время или система откажет. Время реакции может быть в интервале от 0.5 до 10 мс

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

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

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

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

Операционные системы часто классифицируют по их характеристикам реального времени. Операционная система реального времени должна быть тщательно спроектирована, чтобы поддерживать приложения реального времени. Недавнее исследование приходит к выводу, что 95% приложений реального времени требуют ограниченного времени ответа в диапазоне от 0.5 до 10 мсек. Только 10% отклонение (колебание от 50 микросекунд до 1 мсек) во времени ответа может быть допустимо. Согласно таким требованиям большинство операционных систем общего назначения не являются системами реального времени. Согласно этим критериям встроенная ОС, такая как WindowsEmbedded CE, квалифицируется как операционная система реального времени (ОС РВ) (Основывается на определении и оценках времени принятых рабочей группой Open, Modular, ArchitectureControl (OMAC):Жесткой системой реального времени является система, которая отказывает, если ее требования по времени не удовлетворяются; мягкая система реального времени может допускать значительные вариации при предоставлении служб операционной системы, таких как прерывания, таймеры, и планирование).

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

Вся правда об ОСРВ от Колина Уоллса

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

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

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

Ниже список тем, которые мы рассмотрим в ближайшее время:

Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – Nucleus SE.

Вся правда об ОСРВ. Статья #2

ОСРВ: Структура и режим реального времени
Структура программы и режим реального времени

Эта серия статей о встраиваемых системах и, в частности, о программном обеспечении, работающем во встраиваемых системах. Начнем с определения. Что же такое встраиваемая система? В 1986 году, когда я писал первую книгу на эту тему, такого термина еще не существовало. Использовались понятия «выделенная система» или «микросистема», но они, конечно, не отражали всей сути. Через несколько лет в обиход вошло слово «встраиваемая», и все специалисты стали активно его использовать.

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

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

Зачем вообще использовать операционную систему?

Давайте разберемся, почему операционные системы применяются в принципе. Существует много объяснений, некоторые из них зависят как от человеческого фактора, так и от технических характеристик. Помню историю. В одном из наших офисов был кухонный уголок, где можно было сварить кофе. На двери висела табличка с надписью: «Пожалуйста, не закрывайте дверь». Под ней кто-то написал: «Почему нет?», на что кто-то другой ответил: «Потому что». Очень укороченный вариант фразы «потому что мы говорим вам поступать именно таким образом». По тем же соображениям операционные системы применяются в некоторых системах, просто потому что так нужно делать.

Другое объяснение кроется в использовании десктопных приложений. С чего вы начнете, если будете писать программное обеспечение для ПК или Mac? Вы включите компьютер, запустите Windows/Linux или macOS и начнете программировать. Наличие операционной системы – это заданное условие, и оно предоставляет ряд полезных сервисов. Навряд ли вы вздумаете начать с нуля, программируя «голое» железо. Поэтому неудивительно, если инженер, у которого есть опыт написания ПО, но для которого встроенное ПО в новинку, будет рассчитывать на наличие операционной системы в разрабатываемой им системе.

Стоит отметить ключевой аспект десктопной ОС, о котором знают пользователи, — пользовательский интерфейс (англ. User Interface, UI). Спросите у кого-нибудь, что такое Windows, и вам ответят, что это окна, меню, диалоговые окна, иконки, но вряд ли упомянут файловую систему, межпрограммную коммуникацию и способность взаимодействовать с другими системами. В этом основное отличие десктопной от встраиваемой системы: в последней может и не быть пользовательского интерфейса, а если он и есть, то он достаточно незамысловатый. Это первое из многих ключевых отличий:

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

Во-первых, существует выполнение программ в стиле DOS, когда программы выполняются поочередно.

Каждая программа запускается, реализуется и завершается. Мы используем, скажем, программу 1, затем программу 2, затем, возможно, сделаем перерыв, обратимся к программе 3, а потом снова вернемся к программе 2. Второе использование программы 2 начинается заново: запуск не начинается с того места, где мы остановились до этого (кроме тех случаев, когда приложение само не предоставляет такую возможность).

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

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

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

Программы запускаются поочередно, но их состояние автоматически сохраняется, чтобы можно было продолжить с этого же места при закрытии. Например, запускается программа 1, затем приостанавливается для использования программы 2, затем, например, устройство на какое-то время выключается. При возобновлении загружается программа 3 (состояние программы 2 сохранилось автоматически), а потом пользователь возвращается к программе 2, продолжая работу в ней. Я понимаю, что модель выполнения iOS приложения гораздо сложнее, чем описанное выше, тем не менее, это описание — лишь краткое изложение первичного восприятия пользователя.

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

Модели встраиваемых программ

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

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

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

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

Если требуется что-то посложнее, можно попробовать разместить некритичную по времени часть кода в основном цикле, а чувствительную ко времени — в обработчике прерываний (англ. Interrupt Service Routines, ISR). Действия обработчика прерываний в основном достаточно короткие, выполняющие только критически важные задачи и отмечающие участки основного цикла для завершения работы при первой же возможности. Трудности могут возникнуть, когда понадобится распределять работу между основным циклом и обработчиком прерываний (а также между несколькими разработчиками).

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

Что такое реальное время?

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

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

Если не выполняются временные ограничения системы, считается, что произошел системный сбой».

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

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

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

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

Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.