7.1. Въведение: Особености на операционни системи в реално време

Когато се работи с реални движещи се устройства (какво, всъщност, един робот), ние сме изправени пред необходимостта да се реагира възможно най-бързо на външни събития. За да се реши този проблем има една специализирана клас на операционни системи.

операционна система в реално време (RTOS), предназначена да предостави интерфейс към ресурсите на време критични системи в реално време. Основният проблем в тези системи е своевременна обработка (актуалност) осъществяване на данни.

Тъй като основните изисквания за един RTOS се излагат на изискването да се осигури предвидимост и детерминизъм на поведението на системата при най-лошите условия на околната среда, която е много различна от изискванията за производителност и скорост предназначение OS. Добър RTOS има предвидимо поведение при всякакви сценарии на натоварването на системата (едновременно прекъсване и изпълнение на конци).

Има разлика между системите в реално време и вградени системи. От вградената система не винаги е необходимо да има предвидимо поведение, и в този случай това не е система в реално време. Въпреки това, дори и бегъл поглед върху възможните вградени системи предполага, че по-голямата част на вградените системи изисква предвидимо поведение, поне за някои от функциите, и по този начин, тези системи могат да бъдат приписани на системи в реално време.

Система за разграничаване на мека (мек) и твърд (хард) в реално време. В системи трудно провал в реално време, за да се осигури отговор на всяко събитие в определен период от време води до провал и невъзможност да изпълнява задачата. Повечето от руски език литература, такава система се нарича детерминирани системи от време. В практиката, времето за реакция трябва да бъдат сведени до минимум. Меки системи в реално време, се наричат ​​системи, които не попадат в обхвата на определението за "твърд", защото в литературата на ясно определение за тях все още. Soft система в реално време, не може да има достатъчно време, за да реши проблема, но това не води до изоставянето на системата като цяло. В системи в реално време, за да се въведат някои срокове (на английски език литература - краен срок), в рамките на които трябва задължително (за меки системи в реално време - за предпочитане) за задача да бъдат изпълнени. Този нормативен период се използва като планировчика да възложи задачата приоритет в своята ZAPU СК, както и избора на задачи, за да се изпълни.

• OS трябва да мултитаскинг и позволява изместване (preemptable),
• OS трябва да има концепция за приоритет за потока,
• OS да подкрепят предвидими механизми за синхронизиране,
• OS трябва да осигури механизъм за приоритет наследство,
• поведение OS трябва да се знае и предвидима (латентност боравене прекъсване, за превключване между задачи забавяне, отлагане на драйвери и т.н.); Това означава, че всички системи натовареност сценарии трябва да се определят максимално времето за реакция.

През последните 25-30 години, структурата на операционни системи се разви от монолитна с многослойна структура на операционната система и след това да архитектурата клиент-сървър. При работа с монолитна конструкция се състои от набор от модули, един модул и промени оказват влияние върху останалите модули. Колкото повече единици, толкова по-хаотична експлоатацията на такава система. В допълнение, не е възможно да се разпределят на ОС на многопроцесорни системи. многослойната структура на един промени слой засяга съседните слоеве; В допълнение, лечението през слой невъзможно. За системи в реално време, трябва да се осигури директен призив към всеки слой на операционната система, а понякога и директно към хардуера.

Основната идея на клиент-сървър технология е намаляването на OS базата на операционната система до минимум (и примитивите разписание синхронизация). Останалата част от функционалността е подложено на друго ниво и реализира чрез теми или задачи. Съвкупността от тези сървърни задачи носи отговорност за системни функции. Заявленията са клиенти, които искат услуги чрез системни повиквания.

Клиент-сървър технология ви позволява да създавате мащабируеми операционната система и опростява разпределението на многопроцесорни системи. Когато операционната система подмяна на модул не предизвиква ефекта на "снежната топка"; В допълнение, провал модул не винаги да доведе до повреда на системата като цяло. Сега можете да се зареди динамично и доставка единици. Основният проблем при този модел е опазването на паметта. защото процесите на сървъра трябва да бъдат защитени. На всяка услуга поискване система трябва да премине от контекста на приложението на контекста на сървъра. С подкрепата на паметта време за превключване защита от един процес към другите се увеличава.

Обикновено, най-модерните RTOS изградени на базата микрокърнъла (ядро или ядро), което осигурява задачи по планиране и график, и осъществява взаимодействието им. Въпреки намаляването до минимум в ядрото абстракции OS микрокърнъла все още трябва да бъде наясно с процеса на абстракция. Всичко друга операционна система концептуално абстракция поставен извън ядрото, наречен по заявка и работи като приложение.

Помислете концептуалната черпене на операционната система през призмата на изискванията за системи в реално време.

7.2. Процеси, конци, задачи

Така че, в системи за реално време, процесът се разпада на задачи или нишки. Във всеки случай, всеки процес се разглежда като добавка. Между тези приложения, които не трябва да са прекалено много взаимодействие, и в повечето случаи те имат различен характер - трудно в реално време, мека в реално време, а не реално време.

7.3. Планиране, приоритети

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

Поради проблеми с планирането на RTOS проучени и разработени два подхода - статични алгоритми (RMS - Оцени Монотонно Насрочване) и динамични алгоритми (ЕФР - ранният Срок първо).

RMS се използва за официални доказателства предвидимост на състоянието на системата. За реализирането на тази теория трябва да планира въз основа на приоритетите на прекъсване обслужване (изпреварващ график с приоритет). Приоритетът на RMS теория определя предварително на всеки процес. Процесите трябва да отговарят на следните условия:

• процес трябва да приключи преди изтичането на своя,
• процеси, които не са независими един от друг,
• всеки процес изисква едновременно за всеки интервал обработка,
• в непериодични процеси няма строг краен срок,
• процес прекъсне настъпва за ограничен период от време.

Процесите се извършват в съответствие с приоритетите. При планиране на референтната държава-членка, се отдава предпочитание задачи с най-краткото време на провеждане.

Приоритетът на EDF се определя динамично, а най-висок приоритет е настроен процес, който продължава да бъде най-ниското тече времето. Под натоварване на системата в EDF има предимства пред референтната държава-членка.

Тя изисква политика планиране във всички реално време системи. контролиран срок (срок от mPer график). Въпреки това, този подход е все още в процес на разработване.

Обикновено се използва приоритети RTOS график, прекъсвайки услуга, която се основава на RMS. Превантивните действия (присвояване) е неразделна част от RTOS, защото в реално време система, трябва да има гаранции, че с висок приоритет събитие, за да бъдат обработени, преди по-нисък приоритет събитие. Всичко това води до факта, че RTOS нуждае не само в механизма на основата на приоритетите, прекъсване на услуги, но също така и в съответното прекъсване механизъм боравене. Освен това, RTOS трябва да бъде в състояние да забраните прекъсва, когато трябва да се извърши критичен код, който не може да бъде прекъснат. Продължителността на обработка на прекъсване трябва да бъде сведено до минимум.

RTOS трябва да има разработена система от приоритети. На първо място, това е необходимо, тъй като самата система може да се разглежда като съвкупност от сървър-базирани приложения, които могат да бъдат разделени на потоци, както и няколко приоритети на високо равнище следва да се разпределят системните процеси и нишки. На второ място, в предизвикателни приложения трябва всичко живо да се поставят на различни нива на приоритет и потоци не са в реално време да се сложи на същото ниво (по-ниска, отколкото някой от потоците в реално време). Когато този поток не е възможно да се обработват в реално време в кръгла Робин режим график (RRS - кръгла Робин график), където всеки процес осигурява квант процесорно време, а когато кванта завършва контекста на процеса се записва и се поставя в опашката. Много RTOS за планирането на задачи по едно и също ниво, използвано от RRS. Приоритет ниво 0 обикновено се използва в режим на готовност.

При планиране на базата на приоритетите, необходими за решаване на два проблема:

• гарантира прилагането на процеса с най-висок приоритет,
• предотврати приоритет инверсия, когато висок приоритет задача чака ресурси, заловени от задачи с по-ниски приоритети.

За да се справят с приоритет инверсия често се използва в приоритет RTOS механизъм наследство, но той трябва да се откаже въз основа на RMS за планиране. като приоритетни стават динамични.