Здравейте, Habr!
Днес ще говоря за такова интересно нещо като операционната система в реално време (ORV). Не съм сигурен, че ще бъде интересно за опитни програмисти, но мисля, че ще харесвам начинаещите.

Какво е OSR?

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

Защо се нуждаем от нея?

Това е много причини.
Първо, OSRV поддържа многозадачност, приоритети на семафорните процеси и много други.
Второ, тя е много лесна и почти не изисква ресурси.
Трето, всичко, което можем да получим почти на всяка жлеза (например, Freertos работи дори на 8-битова Atmega).
Е, четвърто: просто играйте себе си и се наслаждавайте.

Преглед на 3 известни OSR.

Внимание: след това отива в моето лично мнение.

Freertos.

Един от най-популярните OSRs днес. Пренесени до огромно количество желязо. Официален сайт.

професионалисти

1) безплатно
2) пренесени до голямо количество желязо
3) Мощна функционалност
4) Има различни библиотеки: графики, интернет и др.
5) добра документация.

Минус

1) доста сложен процес на пренасяне до ново желязо.

Заключение: Това е наистина професионално споделяне с добра документация. Ще бъде добре за начинаещи, ако пристанището вече има пристанище.

Keilrtx.

Доскоро това OSRV беше търговско, но наскоро стана отворено. Работи само на архитектурата на ръцете. Официален сайт.

професионалисти

1) безплатно
2) Лесно пристанища в новото желязо (в рамките на архитектурата на ръцете).
3) Има различни библиотеки: графики, интернет и др.

Минус

1) Работата в Keil е почти нереална
2) малка подрязана функционалност
3) Поддържа се само ръката.
4) (на личен опит) губи много сортове скорост.
Заключение: Идеален за начинаещи и малки проекти.

uC / OS.

Мощно търговско споделяне. Уебсайт.

професионалисти

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

Минус

1) търговска.
2) комплекс в употреба.

Заключение: Можете да го наречете за начинаещ с голям участък.

Други интересни OSRV

Rtlinux OSRVS базирани на обикновения Linux.
QNX OSRV въз основа на UNIX.

Функции за развитие с помощта на OSRV

Е, първо, е необходимо да се разбере следното: DRA не е Windows. Не може да бъде инсталиран. Тази система просто е компирана с вашата програма.
Когато пишете програми с OSR, функциите не се използват в обичайното им разбиране. Вместо функции, се използват процеси (или тестиси). Фактът, че процесите, за разлика от функциите, са безкрайни цикли И никога не свършвайте (ако само някой или той няма да го убие - тоест от паметта).
Ако са включени няколко процеса, OSR ги превключва, издаването на машинно време и ресурси от своя страна. Това е мястото, където възниква концепцията за приоритета на процеса, ако двата процеса се нуждаят от еднократно време на двигателя, OSR ще го даде на този, който има повече приоритет.
В OSRV е специални функции Закъснения - така че напразно да не изчезне по време на забавянето на един процес, вторият се извършва.
Сега нека поговорим за такова нещо като семафоре - това нещо, което контролира достъпа на заявлението към ресурсите за кандидатстване. За всеки ресурс има маркер - когато процесът се нуждае от ресурс - отнема го и използва този ресурс. Ако няма маркер, процесът ще трябва да изчака, докато се върне. Ще дам пример: различни процеси изпращат информация на един UART. Ако нямаше семафор, те ще изпращат байтове от своя страна и ще бъдат объркване. И така, първият процес взе маркер на UART изпрати съобщение и даде втория (и така - на безкрайност).

Допълнителни библиотеки на OSR.

Често OSRV предлага различни библиотеки за работа, например с графики, интернет и др. Те са наистина удобни и не трябва да бъдат принуждавани да ги използват. Въпреки това, не забравяйте, че без OSR, за които са написани, те няма да работят.
Ето примери:
За RTX.

Софтуерни продукти и системи № 4, 2001 събиране на отпадъци. Технически доклад, Тексас на Тексас в Остин, 1993. 3. Kim T., Chang N., Kim N., Shin H. Планиране на колекционер на боклук за вградени системи в реално време. Технически доклад, Национален университет в Seouul. 4. Спецификацията в реално време за Java. http://www.rtj.org. 5. Спецификация на международни J консорциум. Основни разширения в реално време. www.j-consortium.org. 6. Никифоров V.V., Данилов M.V. Статична обработка на спецификациите на софтуерни системи в реално време. // Софтуерни продукти и системи. - 2000.- №4.- стр.13-18. 7. Henriksson R. Планиране на събиране на боклук в вградени системи. Lund, 1998. 8. Nilsen K., Lee S. Perc API в реално време. Newmonics Inc., 1997. 9. Wilson P.R., Johnstone M.s., Neely N., Boles D. Динамично разпределение на съхранение: проучване и критичен преглед. Технически доклад, Тексас от Университета в Остин, 1995. Международен стандарт OSEK / VDX за операционна система в реално време M.P. Cervin Една от тенденциите за подобряване на проектите на съвременните автомобили е разширяването на вградените компютърни системи. Съответно обемът на производството нараства автомобилни приложения Софтуерни продукти в реално време, които гарантират функционирането на тези системи. Растежът на производството е придружен от затягане на разработването на софтуерни приложения, изискванията за намаляване на тяхната стойност с едновременното подобрение на надеждността, мобилността, пригодността повторно използване При разработването на нови продукти. Изброените фактори стимулират разработването на стандарти, регулиращи архитектурните и технологичните решения, които уточняват софтуера и мрежови интерфейси За автоматично приложения на реално време. Тези стандарти следва да допринесат за разширяването на интеграцията на софтуерните продукти, произведени от различни доставчици на софтуер. Големите автомобилни опасения се интересуват от прилагането на такива стандарти, (Chrysler, BMW, Volkswagen и др.), Като се стремят да създадат конкуренция на пазара на софтуер, които използват, защото конкуренцията ви позволява да придобиете софтуерни продукти, които предлагат най-доброто съотношение цена. / Качество . За да се промени доставчикът, би било необходимо да се обработи значителна част от заявленията, производителите изискват използването на стандарти от всички доставчици на софтуер. Повечето вградени системи, използвани в превозните средства, са твърди приложения в реално време. Обработката на събитията, възникнали в тях, е ограничена до суровата време, като нарушението може да доведе до катастрофални последици. В момента основната технология, използвана за създаване на автомобилни приложения в реално време и по-специално твърди приложения в реално време, става използването на ядрото или операционната система в реално време (OSR). OSR позволява на заявлението на разработчиците да осигурят изпълнението на заявлението по време на цикъла на работа на системата, при условие че задачите приоритети и правилното проектиране на заявлението. Необходимостта от стандартизиране на автомобилните приложения в основата на OSR доведе до създаването на международен комитет през 1995 г., прилагане на проекта OSEK / VDX за създаване на международни стандарти, регулиращи разработването на софтуерни инструменти за компютърни системивградени в автомобили. Проектът OSEK / VDX бе иницииран от група от водещи производители на автомобили (автомобили), повечето от които са разположени в Германия. Ето защо избраното съкращение OSEK е намаляване на германското име "unfeene systeme und dere elektronik im kraftfahrzeug" - "Отворени системи и интерфейси за автомобилната електроника". Намаляването на VDX означава "Изпълнителен директор на превозното средство" - името на друг проект, интеграция, с който се е случил почти едновременно с началото на проекта OSEK. Така дори името на проекта и поредица от стандарти отразява международния характер на развитието с малко господство на немски производители. Като част от проекта OSEK / VDX, се разработват няколко стандарта. 1. OSEK / VDX OS (операционна система) - спецификация на OSR. Спецификацията съдържа описание на архитектурата на OS, дефиниране на интерфейса за програмиране на OS, който трябва да се използва и приложението подробно описание Поведение на операционната система и неговия компонент. Трябва да се отбележи, че стандартът определя същността на архитектурата и функциите на ядрото в реално време, а не пълноправна операционна система, тъй като не съдържа такива съществени компоненти на операционната система, като например входа Подсистема за управление на изхода или подсистемата за разпределение на паметта. 2. OSEK / VDX COM (съобщение) - спецификация на мрежовата подсистема. Спецификацията определя интерфейсите и протоколите за програмиране, предназначени за предаване на данни между продуктите и системите за превозни средства. Модерна кола съдържа до няколко дузина микроконтролери, които обменят информация. Като правило се използват най-малко две подмрежи: високоскоростен - за системата за управление на двигателя, предаването и суспензията и ниска скорост - за електроника на тялото. Интерфейсът на програмата осигурява прозрачно предаване на данни, т.е. за обмен на съобщения и между мрежовите възли. Въпреки че спецификацията като цяло предоставя на потребителите всички необходими средства за създаване на местна мрежа и подкрепя други стандарти, използвани в автомобилната индустрия, въвеждането на продукти за прилагане на OSEK / VDX COM в реални проекти е свързано с някои проблеми. Основното е да се използват големи производители на други (нестандартни) протоколи, което затруднява прехода към OSEK / VDX COM, тъй като е необходимо или да променя сигурността на мрежата във всички веноди на автомобила, или да поддържа и двете стандартни, така и Нестандартно протокол едновременно поне В някои мрежови възли. В допълнение, в тази версия на спецификацията, няма механизъм за предаване на данни с дължина на няколко бита, а именно, данните за такива дължини представляват значителна част от трафика на автомобилни мрежи. Следователно развитието на спецификациите на OSEK / VDX продължава. 3. OSEK / VDX NM (управление на мрежата) - спецификация за управление на мрежата. Спецификацията определя как информация за това текущо състояние Всяка от мрежовите възли се предава на други възли. За тази цел се използва методът за мониторинг, по-специално, два вида разновидности са пряко и непреки. Директен мониторинг се основава на прехвърлянето на специални съобщения от логически пръстен или логическа звезда. Непрякото наблюдение се основава на проследяване на конвенционалните съобщения, предадени от възли. OSEK / VDX NM може да бъде интегриран с други мрежови системи (и не само с OSEK / VDX COM) и следователно се използва сега заедно с нестандартни мрежови системи. 4. OSEK / VDX OIL (Език на изпълнението на OSEK) - спецификация на езика за конфигурация на системата. Спецификацията описва езика, използван за конфигуриране на заявления, изградени върху изпълнението на OSEK / VDX. В вградените системи, използвани в автомобили, всички обекти на приложение са конфигурирани статично на етапа на компилация. Езикът на петрола съдържа проекти, които ви позволяват да опишете свойствата. системни обектинапример имена и приоритети на задачите, параметрите на таймери и съобщения и др. Описание на конфигурацията се обработва специална полезност (генератор на системи), които формират заглавни файлове и изходен код, описващ системните таблици. Понастоящем не всички спецификации са напълно покрити от OSEK / VDX петрол (по-специално липсват № 4, 2001, описанията за OSEK / VDX COM обекти), така че работата по този стандарт продължава. Изброените спецификации се разработват от различни работни групи по много начини независимо един от друг, но на определени етапи се извършва синхронизацията на спецификациите. Синхронизираните версии се записват в спецификацията на връзките - специален документ, съдържащ описание на целия проект и анотация на компонентите на нейните части. В допълнение към посочените спецификации, проектът OSEK / VDX се разработва от системите, контролирани по време (време). Понастоящем обаче развитието все още не е доведено до етап на издаване на официални документи. Спецификация на OSEK / VDX. Последният официално издаден документ е редакционната служба на 1 версия 2.1 от 13 ноември 2000 година. Това издание е резултат от задълбочена обработка на предишното издание 1 версия 2.0, в която са открити няколко сериозни дефекта и стотици малки коментари. Беше установено, че разработчиците всъщност са твърди и приложения. Няколко дефекта бяха толкова сериозни, че бяха невъзможни да създадат валиден работен камион на някои хардуерни платформи. Работната група е изключително отговорна за коригиране на дефекти и коментари. Достатъчно е да се каже това пълен списък Предложените проблеми и решения съдържат повече страници от действителната спецификация. Спецификацията на OSEK / VDX ОС определя интерфейса за програмиране, за да изпълните функциите на OSR. Интерфейсът за програмиране е посочен в езика за програмиране c (използване на стандарта ANSI-C), въпреки че изпълнението на OSR е възможно на други езици за програмиране. Мобилността на приложенията се поддържа на ниво изходния код. Предполага се, че заявлението може просто да бъде прекомпилирано при заместване на изпълнението на OSR. Въпреки това, една сто процента мобилност все още не е гарантирана, а когато прехвърляте приложение от една платформа в друга, могат да се изискват някои промени в изходния код и описанието на конфигурацията. Това се дължи на факта, че в спецификациите дефинирани функции в зависимост от изпълнението и конфигурацията може да включва атрибути, предназначени да оптимизират OSR и приложението за конкретно изпълнение. Въпреки това, усилията за прехвърляне на заявлението все още са значително по-ниски, отколкото при използване на нестандартни OSRS, а прехвърлянето може да се извърши на етапа на интеграция, а всъщност не развива софтуер. Съдържание Спецификации на OSEK / VDX OS. Спецификацията съдържа дялове, регулиращи: OS архитектура, управление на задачите, обработка на задачите, обработка на събития, синхронизация Използване на споделени ресурси, аларми (управление на таймера и броячи), трансфер на съобщения, обработка на грешки ситуации и отстраняване на грешки, описание на системните повиквания. 41 Софтуерни продукти и системи също имат дял, който определя характеристиките на изпълнението на OSR и списъка с промени (контрол на версиите). Трябва да се отбележи, че спецификацията споделя регулаторните изисквания (задължително) и просто описателни части, обясняващи спецификациите на спецификацията. По-долу са основните характеристики на операционната система, съответстваща на спецификацията OSK / VDX. OS архитектура. Строго казано, архитектурата на OSR не е описана в спецификацията, тъй като тя не се различава от традиционно използваната в ядрата, а разделът съдържа общо описание на принципите на работата на ORVD. OSR контролира два вида обекти, които се конкурират за правото да използват процесора, задачите и закъсненията за прекъсване. Задачите се конкурират въз основа на софтуер, определени статични приоритети, т.е. OSRV подкрепя планирането с фиксирани приоритети. Закъсненията за прекъсване имат по-висок приоритет от задачите и са планирани с хардуер. Поради такова разпределение на приоритизирането, всякакъв ключ за задачите, причинен от извършване на системни повиквания в закъснечители на прекъсване, се забавя, докато операторът на прекъсване е завършен или краят на външния манипулатор е завършен по време на обработката на вградени прекъсвания. Съответно два вида конкуриращи се обекти спецификация определят две нива на работа - нивото на задачите и нивото на прекъсванията. Логичното ниво на планировчика също е дефинирано, въпреки че това ниво не се използва в спецификацията и не се вижда на потребителя на URV. Трябва да се отбележи, че въпреки напълно статичното разпределение на приоритетите на задачите и закъсненията за прекъсване, по време на изпълнението на заявлението може да има ситуации, ограничени по време на инверсия на приоритетите. Това се случва, когато задачата с ниска приоритет измества повече приоритетни задачи или задачата забранява изпълнението на закъсненията на прекъсването до определено прагово ниво на прекъсване на хардуера. Появата на такива ситуации се обяснява с помощта на протокола за синхронизация при достъпа до критични раздели и се контролира напълно от приложението. Въпреки това, при никакви обстоятелства не възникват неограничена инверсия на приоритетите, което дава възможност за гарантиране на навременността на изпълнението на задачите с правото статично назначаване на приоритетите. Класове съответствието. Един от основните изисквания за OSEK / VDX OS е възможността за използване на OSR в процесори с различна енергия, започвайки с 8-битови микроконтролери с няколко десетки килобити ROM и няколко килобайта на RAM и завършват с 32-битови процесори, които имат стотици на килобити ROM и RAM. За да изпълним това изискване, спецификацията, по-специално, описва четири класа съответствието. Класовете за съответствие се определят със следните характеристики: а) множество заявки 42 @ 4, 2001. Активиране (разрешено или не в този клас); б) подкрепа за задачи със статут на изчакване, т.е. т.нар. Разширени задачи; в) броя на задачите за едно приоритетно ниво; г) задължителни (минимални) количествени параметри на OSR (например броя на изпълнимите задачи, броя на подкрепяните ресурси за достъп до критични участъци и др.). Спецификацията определя следните класове за съответствие. Основен клас 1 (BCC1 - основен клас 1). Задачите със състоянието на изчакване и многократно искане за активиране не се подкрепят, само една задача на ниво приоритет, т.е. всички задачи имат различен приоритет. Основен клас 2 (BCC2). Същото като основния клас 1, но се подкрепя многократно искане за активиране и няколко задачи за едно ниво на приоритет. Разширено Клас 1 (ECC1 - Разширен клас 1). Същото като основната класа 1, но се поддържат задачи с държавата в режим на готовност. Разширено Клас 2 (ECC2). Същото като ECC1, но се подкрепя многократно искане за активиране за задачи без състояние на изчакване и няколко задачи за едно приоритетно ниво. Претенциите за съответствие помагат както на разработчиците на OSR, така и на потребителите правилно характеризират и използват прилагането на системата. Трябва да се отбележи, че доставчиците на OSK / VDX OS могат да прилагат само няколко класа за съответствие, за да получат сертификат за съответствие със стандарта. Потребителите, особено големи корпорации, обикновено изискват приложения от разработчици само определени класове за съответствие или дори един клас, за да улеснят интеграцията, да намалят изискванията за консумация (например в паметта) и имат гъвкавост при промяна на доставчика OSR. Факт е, че всеки следващ клас, въпреки че не е описан изрично, изисква по-тромаво прилагане, следователно има смисъл да се ограничат изискванията за прилагане с минималния необходимия клас. Например, заявката за многократно активиране изисква осезаеми допълнителни разходи както за памет, така и процесорни цикли, така че няма смисъл да се използват класове, които поддържат множество заявки, ако такава способност не се използва в приложението. Класовете за съответствие осигуряват груба класификация на OSR, която е полезна за прилепване. В същото време доставчиците на OSR имат право да добавят подобрения на класа за изпълнение. Например, в много реализации, няколко задачи се поддържат в едно ниво на приоритет. Дори и за основния клас на съответствие 1. Като цяло, приложения, които изискват висока производителност, като система за контрол на горивото, могат да използват основен клас 1, защото то Осигурява най-бързата превключване на задачите, синхронизирана с ъглите на въртенето на разпределителния вал и отново активира задачата (т.е. активирането на многократното запитване - софтуерните продукти и системи) се считат за рестартиране. За електроника на тялото често се използва разширен клас 1, тъй като използването на задачи със състоянието на изчакване е удобно да се приложи крайната автоматична инсталация. Управление на задачите. OSRV подкрепя задачите за планиране с фиксирани приоритети и три различни методи Изпращане - изместване, разпускане и смесена (диспечерска система, съчетана с планиране, и този термин не се използва отделно). При изместване на изпращането, задачата с по-висок приоритет винаги измества задачата с по-нисък приоритет. Когато има деактивиращо изпращане, такова изместване възниква само ако задачата с ниска приоритет освобождава процесора. С смесено изпращане някои задачи са изместени и някои са неразумни. Трябва да се отбележи, че обработката на прекъсванията се извършва еднакво с всеки метод на изпращане. При планиране на равен бариерски задачи, принципът на първото е планиран - първо се извършва. По правило, приложенията използват изпращане на изпращането, което позволява да се постигне съответствие с времето за изпълнение, като се използват относително прости правила за назначаване на приоритети. Възникващо изпращане може да се използва в приложения със значително ограничен брой задачи и споделени ресурси. Поради факта, че контекстът на нежизнеспособните задачи съдържа по-малко регистри на процесора, контекстът се извършва по-бързо и следователно може да се постигне по-висока производителност при по-ниски разходи за памет. Комбинираното изпращане е полезно в случаите, когато има няколко задачи, които не са много висок приоритет, които се изпълняват толкова бързо, че няма смисъл да се изразходват времето на процесора на тяхното изместване. OSEK / VDX OS определя два вида задачи - основни и разширени. Основните задачи могат да бъдат само в една от трите състояния - неактивни, готови и изпълняващи. Разширените задачи могат да бъдат допълнително в състояние на готовност. Неактивното състояние на задачата е подобно на общата цел на твърдия диск. Предполага се, че въпреки че не е описано, че не използва неактивна задача, използваща RAM. Спецификацията също не налага ограничения за броя на неактивните задачи в приложението, което предполага, че тези задачи могат да бъдат много повече от активирани. Основните задачи подкрепят принципа на еднократното изпълнение, т.е., когато е активирано, задачата отива от неактивно състояние, след което, в зависимост от приоритета и метода на изпращане, той отнема процесора, превръщайки се към състоянието на изпълнение. След завършване на работата, тази задача е завършена и се връща в неактивно състояние. Задачите от този вид никога не се използват в общата цел, но те са ефективни в вградени приложения в реално време. 4, 2001 Разширени задачи могат да отидат в състоянието на очакванията чрез механизма за събития. Ако всички събития, които чакат задачата, не са инсталирани, задачата отива в чакащата държава, докато не бъде създадена поне едно от очакваните събития. Спецификацията не определя как да изпълни една задача от друга или прекъсване на водача. Следователно преходът към неактивно състояние е възможно само от състоянието на изпълнението. С други думи, задачата може да бъде завършена само по ваша собствена инициатива. Вид завършване на задачата е да завършите едновременното активиране на друга задача или нова инстанция на същата задача, която ви позволява да създавате вериги за задачи. Повтарящото се активиране на вече активната задача води до грешка в класовете за съответствие на BCC1 и ECC1. В класовете на BCC2 и ECC2 има искане за многократно активиране, което означава, че по време на завършването на задачата ще бъде активиран новата му инстанция. Трябва да се подчертае, че за многократното искане за активиране се извършва един и същ принцип на планиране на равни права на изравняване: Първото е планирано - първо се извършва. Очевидно в комуникационните приложения могат да бъдат приложени в комуникационни приложения, например, когато съобщенията, идващи от мрежата, се обработват от задача, активирана винаги, когато пристигне ново съобщение. Прекъсване на прекъсвания. Изискването за пребиваване на прекъсването се състои от следните раздели: Закъсненията за прекъсване (например заявки за прекъсване от външни устройства), селективен контрол на източниците на прекъсване, бърз контрол на разпознаването на прекъсване. Закъсненията за прекъсване се активират, когато възникнат заявки за заявка, обикновено от външни устройства или от самия процесор (например за обработка на изключителни ситуации). Спецификацията определя три категории инвалиди за прекъсване. Категория 1 (ISR категория 1). Подложките на тази категория не извършват жалби към OSR. С други думи, те не променят състоянията на задачите и други системни обекти. Обикновено такива манипулатори се извършват на най-високите нива на хардуерни приоритети и са предназначени за преработка на събития с най-кратки срокове и без участието на OSR. Категория 2 (ISR категория 2). За носителя на втората категория OSR автоматично осигурява необходимите условия За възможността за повикване на услуги за OSR. Технически, това се постига чрез използване ключови думи ISR, така че разработчикът на приложения не трябва да се грижи за създаването на контекст, който ви позволява да се обърнете към OSR. Категория 3 (ISR категория 3). Трета категория Подложките са комбинация от товарни лица от първата и втората категория. Ако в процеса на изпълнение на ръководителя трябва да се обърнете към 43 софтуерни продукта и системи на OSR, системното повикване Enterisr () трябва да се изпълни, за да създаде желания контекст и в края на ръководството - Leauitisr ( ) Поканата е да се докладва на системата, която ръководителът е завършен (Handlers на категория 2 имплицитно включва тези предизвикателства). Почти всички предизвикателства, които имат смисъл да причинят прекъсвания, са разрешени в процесорите на втората и третата категория (между циркулацията Enterisr / Leaitisr). Например, задействащите прекъсвания могат да активират задачата, да инсталирате събитие за задача, изпратете съобщение, инсталиране на аларма и др. Инвестициите за прекъсване могат да бъдат инвестирани, т.е. един манипулатор може да прекъсне друг. За това трябва да се създадат подходящи хардуерни условия. При завършване на вградените прекъсвания изпращането се забавя, докато външният манипулатор приключи. Отбелязваме два проблема, свързани с използването на прекъсващи машини. Първият е свързан с потенциалните трудности при използването на локални променливи в ръкохватките, свързани с категория 3. Проблемът е, че компилаторите осигуряват разпределение на паметта за локални променливи на функцията за обработка в самото начало на функцията. Когато се обадите на Enterisr (), стекът може да бъде променен и тези местни променливи стават самостоятелни съдии, т.е. обжалването им след обаждането на Enterisr () ще доведе до погрешно адресиране. За съжаление, тази ситуация може да възникне в случая, когато разработчикът на приложения дори не определя местни променливи изрично. Тъй като компилаторът може да създаде скрити локални променливи за извършване на някои операции (например за извършване на битови операции на 8-битови процесори). Ето защо спецификацията показва наличието на такъв проблем, който може да бъде напълно избегнат само чрез отказ от използването на трета категория. Вторият проблем е свързан с инвестирането на манипулатора от категория 2 или 3 в първия категория процесор. В този случай изпращането е отложено за неопределено време, тъй като не може да се извърши в края на вложения манипулатор (тъй като все още има външен манипулатор), но не е изпълнен в края на външния манипулатор, защото това не го прави ръководител на категория Взаимодействайте с операционната система. За да се избегне появата на такава ситуация, спецификацията препоръчва правилно присвояване на приоритети за прекъсване на ръкохватките. Описанието, включено в описанието на спецификацията на селективните източници на прекъсване, е критикувана поради факта, че приложението интерфейси, които подкрепят забраната или разрешението за признаване на искането за прекъсване от конкретен източник (устройство), не могат да бъдат уточнени в зависима от платформа форма, следователно Преносимостта на приложенията, използващи приложения, не са достигнати. Услуги. Освен това, когато се използват тези услуги, тя може да възникне 44.4, 2001 г. Неограничен с течение на времето за забрана на прекъсванията, водещи до хардуерни грешки. Например, задача с ниска приоритет, която забранява последователно порт байт за кратко време за прекъсване, може да бъде свален от по-приоритетни задачи, а след това "краткото време" ще бъде забавено за неопределен период, който ще доведе до загуба на прием от следните байтове. Работна група, разработване на спецификации, се съгласява с тази критика. Може би селективният контрол на източниците на прекъсване ще бъде изтрит от следните версии на спецификацията. Бързо прекъсване Управление на разпознаването ви позволява да разрешите и забраните всички прекъсвания на процесора или само тези, които влияят на работата на ORVD. Обработка на събития. Събитията позволяват разширена задача да се превърнат в състоянието на изчакване, ако събитието се нулира и преведе задачата на състоянието на готовност, когато събитието е инсталирано. За съжаление, спецификацията наистина не определя показването на световните събития на бита, използвани от задачата, но се предполага, че всяка напреднала задача притежава собствена маска за събития, битовете, които могат да бъдат манипулирани с помощта на системните повиквания на SRR. За вградените приложения, спецификацията, задачите на класовете на ECC1 и класовете ECC2 водят до режийни разходи, свързани с използването на избраната област на RAM за натрупване на всяка задача и манипулиране на битовете за събития. Ето защо разработчиците на приложения трябва да използват разширени задачи с голяма грижа. Синхронизация, използвайки споделени ресурси. Спецификацията използва специален протокол за достъп до ресурси, които защитават критичните кодови раздели. Този протокол се нарича Протокол от OSEK приоритетния таван, въпреки че не описва не действителния протокол за приоритетния таван, но протокол, който има няколко синоними, например протокол за най-висок шкаф или протокол за приоритет (в стандарт POSIX). Протоколът дава възможност за предотвратяване на изключването на импаст и неограничена инверсия на приоритетите. Това се постига поради факта, че приоритетът на задачата, поискащ споделен ресурс, незабавно се увеличава до праговата стойност на приоритета на ресурса, който се изчислява по време на процеса на конфигуриране на системата като най-висок (или по-висок) приоритет на всички задачи с достъп към този ресурс. Ето защо, когато се иска ресурс, е гарантирано, че нито една друга задача, която има достъп до този ресурс, няма да бъде преведена в държавата за изпълнение. Разширяването на този протокол, обикновено се прилага само за задачи, може да се счита за голямо постижение на OSEK / VDX OS, при прекъсване на ръкохватките за защита на критичните участъци от кода, споделяни от задачите и прекъсването на водачите. В същото време се разбира, че приоритетите на инвалидите и задачите и задачите на прекъсването на програмните продукти и системите са ярки за една скала и че OSR може да манипулира забраната и разрешаването на нивата на контролера. Разбира се, такава схема има дегенерален характер, ако оборудването поддържа само едно ниво на прекъсвания, но все още може да се използва в този случай. Но е особено полезно да се използва разширяването на протокола върху микропроцесорите, които имат многостепенна схема за прекъсване, например, Motorola 68K. Аларма (управление на таймера и броячите). Спецификацията определя обобщената обект, наречена аларма, която се използва за активиране на задачите от стойностите на таймерите и броячите, например, измервателни устройства от линейни или ъглови премествания. Всяка аларма имплицитно подсказва подлежащия метър, като преброява стойността на определено количество. Спецификацията не определя софтуерния интерфейс за контрол на измервателите, защото те могат да бъдат напълно изпълнени хардуер, например, като се използват прекъсвания на часовника в реално време. Трябва да се отбележи, че няколко аларми могат да бъдат свързани към един метър. Спецификацията изисква OSR да предостави системен таймер. Всяка аларма е зададена задача или двойка задача за събитие. Когато се задейства аларма, задачата се активира или за него е инсталиран събитие. Тригерът на алармата се случва в момента, когато броячът достигне стойността на инсталацията на алармата. Алармата може да бъде инсталирана както върху абсолютната стойност на измервателния уред и роднина. Можете също да зададете циклична стойност на алармата, като по този начин организирате обработката на периодични събития. Може да се отбележи, че алармите осигуряват много гъвкав и мощен механизъм за обработка на събития. Въпреки това, прилагането на аларми е все още доста тромаво, особено в случай на свързване към метър от няколко аларми. Прехвърляне на съобщения. Спецификацията на OSK / VDX OS не съдържа описания механизмът за съобщения, посочен в спецификацията на OSEK / VDX, в която два класа CCCA и CCCB мрежови конформации (CCC - съкращение Комуникационен клас) са описани специално за локални съобщения. CCCA описва небуферирани съобщения, т.е. съдържанието на което се актуализира, когато се изпраща съобщението. CCCB допълнително определя буферираните съобщения, които са кръгова опашка. Характеристиките на двата типа имат фиксирана дължина (и размера на буферираните съобщения), определени в етапа на конфигуриране на приложения. Когато пристигне съобщение, задачата на приемника може да бъде активирана, да се нарече събитие за задача за приемник или функция на потребителя. За да се удостовери изпълнението на OSEK / VDX OS, доставчикът на OSR е достатъчен, за да приложи класа на Съдържателния клас на CCCA. № 4, 2001 обработване на погрешни ситуации и отстраняване на грешки. За приложения за отстраняване и проследяване, спецификацията описва процедурите за капана и подобрена информация за грешки. Капаните се предоставят от потребителя, но са причинени от самата операционна система. В случай на възникване системна грешка Капанът за грешка се извиква, така че приложението идентифицира причината за грешката и е взела коригиращи действия. Две капани са предназначени да проследяват превключването на контекста на задачата, като по този начин помагат на следата за прилагане. Когато стартирането на OSR стартира, се извиква стартовият капан, в който можете да активирате задачите, инициализиране на приложението и инициализиране на хардуера. В случай на фатална грешка, приложението може да завърши OSR, докато се нарича терминален капана, в който хардуерното нулиране може да бъде нулиране. Осигурена е информация за подобрената грешка. системни услуги OSRV в случай, че системата е статично конфигурирана за това. В описанието на всяка система функцията е посочена, кои грешки могат да бъдат върнати в стандартни и разширени конфигурации. Например, в стандартната конфигурация, активирането на задачите връща само успешен код за изпълнение и в разширената конфигурация съобщава за неправилен идентификатор на задачите и за погрешна многократна заявка за активиране. Предполага се, че разширената конфигурация трябва да се използва от разработчиците на приложения в етапа на отстраняване на грешки и дебпублираното приложение е конфигурирано в стандартен вариантТъй като разширената обработка на грешки води до значителни разходи за надземни разходи, особено по отношение на използването на времето на процесора. Има обаче проблемът, свързан с разликата във времето характеристиките на изпълнението на приложението в стандартни и разширени конфигурации (трябва да се има предвид разработчиците на приложения възможни последици Тази разлика). Стандартът OSK / VDX OS отговаря на почти всички днешни изисквания за разработчиците на автомобилни приложения и се използва от такива опасения като Chrysler и BMW. Спецификацията на успеха се обяснява с близкото партньорство на клиенти и доставчици на ORVD в разработването на спецификация и цялостна работа на части за постигане на баланс функционалност и ефективността на изпълнението, както и за стабилността на вградените системи. Референции 1. Копец H. Системи в реално време. Принцип на дизайна за разпределени вградени приложения. Kluwer академични издатели. MA, 1997. 2. Операционна система OSEK / VDX, версия 2.1 Revision 1, 13. ноември 2000 г. 3. OSEK / VDX комуникация, версия 2.2.2, 18-та придаване на 2000 година.

Представя се преглед на сравнителните характеристики на RV операционната система на руския пазар авиационни системи Контрол.

05.05.2008, Мон, 23:56, МСК

Благодарение на развитието компютърно оборудване в напоследък Стана възможно да се присвои един модул на проблема, извършен по-рано от няколко процесорни модула, като се подобряват характеристиките на бойлера на системата за управление и намаляване на разходите му. Такава тенденция в авиационната техника доведе до появата на концепцията за интегрирана модулна авионика - IMA (интегрирана модулна авионика, IMA).

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

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

Документи, регулиращи изискванията за OSR

Стандартът DO-178 (разглеждане на софтуер във въздушни системи и сертифициране на оборудването) определя изискванията за процеса на разработване на софтуер и внимателността на нейната проверка в зависимост от нивото на критичността. Нивото на критичност се определя въз основа на анализа на тежестта на последиците от отказ. Осигурени са общо пет нива на критичност на софтуера (от А).

Милс (множество независими нива на Secutiry) е специален подход към дизайна на операционната система, която предотвратява разпространението на грешки при прилагането на приложенията по време на изпълнението, както и опростяване на програмата, поради модулността на софтуера. Всички приложения са поставени в така наречените дялове. Разделите са разпределени ресурси (зона на паметта, времето на процесора по време на всеки системен цикъл, достъп до обменни канали и др.). Достъпът до разпределени ресурси е гарантирана операционна система, работеща в режим на надзорник. По този начин, на един модул на процесора, при контролиране на една операционна система, тя може да работи върху различни нива на критичност - ако неуспехът възникне в по-малко критично (и съответно, по-малко доказан) софтуер, той няма да повлияе на работата на други раздели Тъй като опитите за "узурпиране" други хора ще бъдат снабдени с операционната система. Идеите на Милс отекват с IMMA и DO-178B идеи.

Грешка 404. не може да намери страница.

Може би това се случи по една от тези причини:

- Грешка при въвеждане на адреси на страницата (URL)
- Преход от "НДНТ" (неработна, неправилна) връзка
- исканите страници никога не са били на площадката или е била премахната

Можеш:

- Върнете се, използвайки бутона на браузъра обратно (обратно)
- Проверете коректността на писането на адреса на страницата (URL)
- Възползвайте се от картата на сайта или отидете на главната страница

Arinc-653 Стандарт (стандартен интерфейс за приложения на Avionics) Задава софтуерния интерфейс на Apex, който поддържа концепцията за раздели в духа на Милс. Този интерфейс Включва функции за управление на дял, процеси, разделяне на времето, комуникации между прегради и в раздела, наблюдение на състоянието на системата. Трябва да се отбележи, че стандартът Arinc-653 описва общоприет подход към изпълнението на идеите на МИЛ за IMA, въпреки че може да има други изпълнения. OSRV на авиацията, съответстваща на Arinc-653, има предимства този стандарт Следователно, добре познат и разбираем от международни сертифициращи органи, построен на този стандарт, е по-лесно да се получи сертификат за съответствие на DO-178B.

Стандартни софтуерни компоненти за многократна употреба. В съответствие с DO-178B софтуерът на конкретно авиационно приложение изпълнява напълно процедурата за сертифициране, дори ако използва модулите (компонентите), които вече са сертифицирани по-рано в състава на друга система. Една от най-новите инициативи на FAA (Федерална агенция за гражданско въздухоплаване, САЩ) е да се определят критерии за възможността за повторна употреба без повторно сертифициране. Компонентите, които могат да бъдат многократно сертифицирани, се наричат \u200b\u200bRSC (компоненти на редуалната софтуер). За да получите сертификат за RSC, трябва да похарчите повече усилия, но тогава RSC дава сериозни спестявания.

Руски документи, определящи изискванията за софтуер (и включително OSR):

• Gost R ISO / IEC 51904-2002 ("на вградени системи. Общи изисквания към разработването и документацията ") - аналог на до-178б за военна авиация;
• KT-178A ("Изисквания за квалификации, част 178а") - аналог на до-178б за гражданско въздухоплаване;
• Gost R ISO / IEC 12207-99 ("Информационни технологии. Процеси кръговат на живота софтуер ").

Сравнението на OS RV е извършено в 13 параметъра, които вземат предвид техническите критерии, лекотата на развитие и икономически параметри.

Временни параметри OS.

Едно от основните изисквания за OS RV е минималното време за забавяне на обработката на конкретно събитие. На практика това означава, че следните параметри трябва да са малки:

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

За съжаление, обективно сравнете посочените параметри на различните RV OS не е лесно, тъй като тези параметри зависят не само от качеството на операционната система, но и върху възможностите на използваната хардуерна платформа. В идеалния случай, всички сравнени OS трябва да бъдат инсталирани на една и съща хардуерна платформа, след което трябва да се направят съответните измервания. Но дори и тези измервания не дават обективен резултат, защото различните OSS могат да бъдат повече или по-малко адаптирани към конкретен хардуер.

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

Източници обективни данни могат да се считат за резултатите, получени от експерти от специализираното системно списание, което извършва тестване и практическо сравнение на QNX RTOS 6.1, VxWorks AE 1.1 и Windows CE.NET на платформата X86. Въпреки че днес тези данни са остарели, авторите на този член не успяват да намерят повече от свеж материал. В раздела. 2 показва селективни данни за работата на QNX Neutrino 6.1, VxWorks AE 1.1. В специалния доклад на системите, предпочитанията от гледна точка на скоростта е дадена на QNX и съотношението на точките е зададено като 9: 5 (QNX: Vxworks), защото по време на тестването в Vxworks са открити две грешки, корекцията на които трябваше да се свърже с услугата за поддръжка.

В раздела. 3 показва данните за характеристиките на Lynxos. Съставът на използваните тестове не е посочен. Като данни за характеристиките на Lynxos, четвъртата колона е интересна (тестване на платформата X86). В сравнение с Vxworks и QNX, Lynxos RV OS показва огромно забавяне в реакцията на прекъсване (повече от 5 пъти). Време за превключване на контекста (което означава времето за превключване между две нишки в един процес) е същото и с QNX и по-малко от около 1,5 пъти, отколкото в VxWorks.

Стабилност на временните параметри

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

Въз основа на специална система, списание QNX е пред този критерий Vxworks, за да се разпространи характеристиките в серия от обекти от същия тип тестове (съотношението на максималното време със средната стойност е значително по-малко) и с увеличаване на товара (превключване на поток Време с увеличаване на броя на потоците 2 ... 128 единици. QNX е нараснал само 1,65 пъти, докато Vxworks е 2.24 пъти).

Според данните, получени в компанията RTSoft, е известно, че Lynxos има приблизително същите характеристики, които vxworks.

Контрол на ресурсния достъп

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

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

Задачата на процесите е:

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

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

Lynxos и QNX поддържат модела на процесите и сегментацията. Vxworks OS има сегментален механизъм, но не поддържа модела на процеса. Като цяло, тя е допустима, защото сегментацията осигурява разделянето на адресни пространства. Но липсата на процеси носят някои неудобства. Обикновено разделянето на сегменти се извършва въз основа на целевата дестинация на софтуера и нейната критичност. Например, някои сегменти могат да съдържат чрез контролиране на пилонов навигационен комплекс с високо ниво на критичност. Но този софтуер също е достатъчен комплекс комплекскоето би било логично разделено на независими (памет) модули. Vxworks OS не предоставя такава възможност, т.е. сегментът ще се състои от споделени потоци, което усложнява организацията на паралелното развитие и в крайна сметка намалява надеждността на софтуера.

Поддръжка за многопроцесорни и разпределени системи

Разходите за многопроцесорни модули наскоро са намалели значително и затова те все повече се използват в вградени системи. Разбира се, OS RV трябва да осигури подкрепа за такива такси.

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

OS RV QNX предлага поддръжка за многопроцесорни дъски. За Vxworks такава поддръжка се обявява само. Lynxos авиационна версия с подкрепа за многопроцесорни дъски все още не съществува.

Що се отнася до подкрепата на мрежовите протоколи, трябва да се отбележи, че лингсосите, Vxworks и QNX и QNX са приблизително равни (и широки) възможности. Допълнително предимство на QNX RV OS е неговата специална мрежова подсистемна архитектура, предоставяща мрежа "Прозрачност" на приложни програми: Всеки процес може да доведе до друг процес на отдалечен модул, както и процеса на локалния модул.

Поддръжка на файлова система

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

В раздела. 4 показва поддръжка за файлови системи всяка от разглежданата операционна система.

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

Качество на документацията

Качеството на документацията на RV Lynxos, Vxworks, QNX е доста висока. Съществуват и жалби за документацията:

• QNX е отлично описание на архитектурата и принципите на строителство, но недостатъчно описание на интерфейса за програмиране на приложения (описанието не е всички параметри, има несъответствия);
• Vxworks - Няма обяснение на принципите на работа и недостатъчно описание на процеса на конфигуриране на комплекса.

Въпреки това, компаниите оперират с качеството на материала. Документация сегашна версия QNX (6.3.2) е значително разширен, има обработени от някои части.

Качество техническа поддръжка

Според официалната техническа подкрепа безспорният лидер е линсос. Lynuxworks обещава да отговори на всеки технически въпрос в рамките на 4 часа от датата на искането. Линсос се простира на територията на Русия RTSoft, която има голям персонал, способен да визуализира квалифицирана помощ. Липсата на линсос е, че операционната система не е много често срещана в Русия, съответно, няма сформирана общност от потребители и дори няма руско-говорещ форум.

QSS (производител на QNX) предлага и качествена техническа поддръжка, но отговорът не е гарантиран. За разлика от Lynxos, QNX RV OS има добре организирана потребителска общност както в чужбина, така и в Русия. Отговорите на повечето въпроси могат да бъдат намерени в тези форуми. QNX в нашата страна се разпространява от компанията "SVD вградени системи", чиито служители са способни да предоставят компетентна техническа поддръжка и да отговарят на работата по адаптирането на операционната система в определени процесорни дъски. Освен това компанията има директни контакти с QSS и може да получава консултации по сложни въпроси от разработчика на RV QNX.

Windriver, разработчикът на Vxworks, традиционно се придържа към затворена техническа политика, т.е. информация за принципите на операционната операционна система е доста трудна. Руско-говорящият форум няма руски форум. Нашите Vxworks OS в нашата страна се разпространява от AVD системи, която се занимава главно с продажби на готови софтуерни и хардуерни решения на чуждестранна продукция.

Откритост на изходните кодове

Open OS RV има най-малко три предимства:

• приложените разработчици на софтуер могат да разберат сложни проблеми без участието на техническа поддръжка;
• по-лесно е да се удостовери (за липсата на отметки и т.н.);
• динамично развитие, тъй като системата RV често често идва не само за искания за корекции на грешки, но и за премахване на грешките, подобряване на системата. Разработчиците на разработчиците на отворената OS RV, като правило, стават много по-бързо, са по-добре организирани. Независимите експерти изглежда подпомагат решаването на услугите за техническа поддръжка и участие в развитието, отстраняването и тестването на системата.

От септември 2007 г. QSS е отворил изходни кодове QNX ядки (включително адаптивна разделяне на разделянето, висок пакет за висока наличност). Малко по-късно бяха отворени изходните кодове на подсистемата на мрежата. Понастоящем на официалния сайт е на разположение за изтегляне на бета версия 6.4.0.

Трябва да се отбележи, че днес не всички QNx модули са отворени (например, няма кодове за графични и файлови системи), а лицензът налага ограничение за използването на "източници": само за нетърговска употреба. Въпреки това потребителят QNX получава горепосочените обезщетения безплатно.

Изходни кодове Lynxos и Vxworks са достъпни в продажба. Цената на такъв продукт е по договаряне.

Инструменти

Наличието на добри инструменти до голяма степен определя качеството и скоростта на разработване на програми за прилагане в една или друга операционна система. Трябва да се отбележи, че Lynxos, Vxworks и QNX в момента предоставят добре качествени инструменти, които включват интегрирана среда за развитие (ПИС) и софтуер за отстраняване на грешки, програми за профилиране (за откриване " тесни седалки"По отношение на изпълнението, паметта и т.н.). Ергономия ПИС за данни RV като цяло не е по-ниско от разработените инструменти за развитие за обичайната операционна система (например MS Windows).

Преносимост на прилаганите от

Поносимостта на приложния софтуер осигурява възможността за използване в другата операционна система (включително не-RV OS). Преносимостта дава определена независимост на разработчика на приложен софтуер от RV: Ако е необходимо, можете да превключите на друга операционна система с ниски разходи.

Възможността за писане на преносим софтуер се определя в този момент Спазване на стандарта POSIX. Всички разглеждани OS RV поддържат стандарта POSIX 1003.1. Предимството е Lynxos - тази OS има двоична съвместимост с Linux OS. I.e. приложения Linux. Може да бъде пуснат под лингсос, без да се прекомпилира. И напротив, приложенията на Lynxos могат да бъдат пуснати в Linux (версия 2.4.x с библиотека на Si Glibs версия 2.2.2).

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

Поддръжка за обработващи архитектури

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

Съответствие с стандартите за авиация

В отвъдморските практически софтуер за авионични системи трябва да има сертификат за съответствие с стандарта DO-178B. Ако на различни нива на критичност се извършва на един модул на процесора, тогава приложената OSR трябва да поддържа концепцията за секции. (В противен случай е почти невъзможно да се докаже неразпространението на грешката). Както вече споменахме, по-добре е, че интерфейсът на програмиране на OSR съответства на стандарта Arinc-653, тъй като стандартът е добре известен на чуждестранни органи за сертифициране.

Линсос по отношение на стандартите за съответствие е лидер. Той поддържа Arinc-653, има достатъчно примери за системи, сертифицирани от DO-178B, построени на нейната основа. Ключовият момент е, че Lynuxworks предлага набор от RSC (въпреки че авторите на статията не са запознати с цената).

Vxworks отговаря на стандарта Arinc-653, а системите, изградени върху него, могат да бъдат сертифицирани от DO-178B (съществува голям номер примери).

QNX не съответства на Arinc-653 и досега няма системи, базирани на сертифицираните DO-178B.

Трябва да се отбележи, че QNX системите могат да бъдат фундаментално използвани за изграждане на IM, тъй като QNX поддържа метода си за предоставяне на концепция за дялове, която е много добра алтернатива на Arinc-653 и освен това спестява време на процесора.

По отношение на подобни руски стандарти за военна авиация (Gost R ISO / IEC 51904-2002), няма нито един пример за сертифицирана система, въпреки че е фундаментално въз основа на която и да е от разглежданата операционна система, тази система може да бъде разработена. В момента QNX системата е в ход, за да подготви основните операционни модули към сертифициране.

Развитие на системата за обучение на специалисти

Скоростта и качеството на обучението на персонала, работещи с RV OS и различни инструменти за разработване и отстраняване на грешки, пряко поради степента на развитие на софтуера и нейното качество. Водещи компании в областта на вградения и систематичен софтуер, като Windriver, Lynuxworks, QSS, провеждат мащабен курс на курсове и обучения за проучване на използването на продуктите на компанията, включително OS RV.

Сравнете резултатите

OSRV QNX неутрино е най-идеалната операционна система от техническа гледна точка, добър комплект Инструменти, има относително ниска цена. Микродната архитектура осигурява висока надеждност и разработени модулни системи. Допълнително предимство е кодът с отворен код. Но има и "лъжица глухи": в момента QNX практически не се използва в авиацията, а на този параметър тази операционна система губи на конкурентите (Lynxos и Vxworks). Допълнителен минус QNX: неспазване на стандарта Arinc-653.

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

Работата по подготовката за QNX неутрино сертифициране съгласно изискванията на местните стандарти за въздухоплавателни средства в момента се извършва от SWD софтуер.

OSRV Lynxos-178, напротив, има всички необходими сертификати в чужбина, въпреки че в много други критерии изглежда по-малко за предпочитане от QNX Neutrino. Трябва да се отбележи, че за използване в руската авиационна промишленост Lynxos-178 също трябва да бъде сертифициран за домашна ГОСТ.

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

Експертна група / R & D.Cnews

Печат

Отличителни черти на OSR от общо предназначение

Общата цел, особено мултиплейър, като UNIX, са фокусирани върху оптималното разпределение на компютърните ресурси между потребители и задачи. В операционните системи в реално време, такава задача се премества на фона - всичко отстъпва преди основната задача - да има време да реагира на събития, които се случват в обекта. Другата разлика - използването на операционната система в реално време винаги е свързана с оборудване, с обект, със събития, които се срещат в съоръжението. Операционната система в реално време е фокусирана върху обработката на външни събития. Операционната система на реално време може да бъде като потребителски интерфейс На операционна система с общо предназначение тя работи напълно по различен начин. Освен това използването на операционни системи в реално време винаги е конкретно. Ако общата цел обикновено се възприема от потребителите (не разработчиците), както вече готов комплект Приложения, операционната система на реално време служи само на инструмента за създаване на специфичен хардуер и софтуерния комплекс от реално време. И следователно най-много широк клас Потребителите на операционни системи в реално време са разработчици на комплекси в реално време, проекти за проектиране и събиране на данни. Проектиране и развитие специфична система В реално време, програмист винаги знае точно какви събития могат да възникнат в съоръжението, знае критичните крайни срокове за услугата на всяко от тези събития. Системата RV трябва да има време да реагира на събитие, което е настъпило на обекта по време на критиката за това събитие. Мащабът на критичното време за всяко събитие се определя от обекта и самата събития и може да бъде различна, но времето за реакция на системата трябва да бъде предвидено (изчислено) при създаване на система. Липсата на реакция в предвиденото време се счита за грешка за системи в реално време. Системата трябва да има време да реагира на едновременно срещащи се събития. Дори ако се появят две или повече външни събития едновременно, системата трябва да има време да реагира на всеки от тях по време на интервалите, които са критични за тези събития.

	Операционна система в реално време	С общо предназначение
Основната задача	Имам време да реагирате на събитията, които се случват на оборудването	Оптимално разпределят компютърните ресурси между потребители и задачи
Какво е ориентирано	Обработка на външни събития	Обработка на потребителски действия
Както е разположено	Инструмент за създаване на специфичен хардуер и софтуерен пакет от реално време	Възприемани от потребителя като набор от приложения, готови за употреба
Който е предназначен	Квалифициран разработчик	Потребител вторична квалификация

Твърди и меки системи в реално време

Има два вида системи в реално време - твърди системи в реално време и мека система в реално време.

Твърдите системи в реално време не позволяват никакви системи за реакция на системата при никакви обстоятелства като:

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

• цената на забавянето може да бъде безкрайно голяма.

Примери за твърди системи в реално време - странични системи управление, системи за аварийна защита, аварийни рекордери.

Меките системи в реално време се характеризират с факта, че реакционното закъснение не е критично, въпреки че може да доведе до увеличаване на цената на резултатите и намаляването на работата на системата като цяло. Например - работата на мрежата . Ако системата не е имала време да обработи следващия получен пакет, това ще доведе до изчакване на предаващата страна и да изпрати отново (в зависимост от протокола, разбира се). Данните не се губят, но изпълнението на мрежата намалява. Източникът между твърдите и меките системи в реално време може да бъде изразен така: твърдата система в реално време никога не е закъсняла с реакцията на събитие, системата на мекото в реално време - не трябва да закъснява с реакцията на събитието

Ядро на операционната система

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

Монолитно ядро

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

Достоверност: Скорост на работа, опростено развитие на модула.

Недостатъци: Тъй като ядрото работи в едно адресно пространство, повреда в един от компонентите може да наруши работата на цялата система.

Някои стари монолитни ядра, особено Unix / Linux класови системи, изисква се прекомпилиране, ако е оборудван с състав на оборудването. Повечето модерни сърцевини ви позволяват да зареждате модули по време на работа, които извършват част от функциите на ядрото. В този случай компонентите на операционната система не са независими модулиИ компонентите на една голяма програма, наречена монолитно ядро \u200b\u200b(монолитно ядро), което е набор от процедури, всеки от които може да причини всяка. Всички процедури работят в привилегирован режим.

Микрооар

Микроник предоставя само функции за управление на елементарните процеси и минимален набор от абстракции за работа с оборудване. По-голямата част от работата се извършва с помощта на специални потребителски процеси, наречени услуги. Решаващият критерий за "микроордидуд" е поставянето на всички или почти всички драйвери и модули в процесите на обслужване.

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

Недостатъци: Предаването на данни между процесите изисква режийни.

Изпълнение в сряда

Изисквания за средата за изпълнение на системата в реално време:

• малка памет на системата - за възможността за вграждане;
• системата трябва да бъде напълно пребиваваща в паметта, за да се избегне подмяна на страници или суапове за памет;
• системата трябва да бъде многозадачност - за да се осигури максимум ефективна употреба всички ресурси на системата;
• ядро с приоритет за прекъсване на услугата. Приоритет за прекъсване означава, че процесът готов за пускане, който има известен приоритет, задължително има предимство в опашката с по-нисък приоритет процес, бързо замества последното и пристига. Ядрото завършва всяка работа, веднага щом бъде получена задачата с най-висок приоритет. Това осигурява предвидимостта на системата;
• приоритетен диспечер - дава възможност за разработване на програма за кандидатстване за присвояване на приоритет на всеки модул за зареждане, без повреда. Приоритетните задачи се използват за определяне на реда за стартиране на програми, готови за изпълнение. Алтернатива на такъв тип диспечер е контролиращ тип "въртележка", в който всеки е готов да продължи програмата, е даден равен шанс за стартиране. Когато използвате този метод, няма контрол над каква програма и кога ще бъде изпълнена. В средата в реално време тя е неприемлива. Изпращането, което се основава на принципа на приоритетното задание и наличието на ядро \u200b\u200bс приоритет за прекъсване, позволяват на разработчика на програма за кандидатстване да следи напълно системата. Ако дадено събитие възникне с най-висок приоритет, системата спира да обработва задачата с по-ниския приоритет и отговаря на новоотговорената заявка.

Комбинацията от описаните по-горе свойства създава мощна и ефективна среда в реално време.

В допълнение към свойствата на изпълнението на околната среда, също така е необходимо да се разгледа услугата, предоставена от ядрото в реално време. Основата на всяка среда в реално време е ядро \u200b\u200bили диспечер. Ядрото управлява хардуера на целевия компютър: централен процесор, памет и входни / изходни устройства; Контролира работата на всички други системи и приложен софтуер. В системата в реално време, диспечерът се извършва между хардуера на целевия компютър и се прилага софтуер. Осигурява специална услуганеобходими за експлоатацията на приложения в реално време. Услугата, предоставена от ядрото, предоставя приложения за достъп до такива ресурси на системата, като например памет или входни / изходни устройства.

Ядрото може да предостави услуга от различни видове:

• Междупрограма. Често е необходимо да се гарантира прехвърлянето на данни между програмите в рамките на една и съща система в допълнение, в много приложения е необходимо да си взаимодействат с други системи чрез мрежата. Вътрешната комуникация може да бъде извършена чрез системата за прехвърляне на съобщения. Външна комуникация. Можете да организирате или чрез дейтаграма (най-добрият начин за изпращане) или чрез линии на връзката (гарантирана доставка). Изборът на този или този метод зависи от протокола за комуникация.
• Разделяне на данни. В приложните програми, работещи в реално време, най-дългата е събирането на данни. Често са необходими данни за работа на други програми или се нуждаят от система за извършване на някоя от нейните функции. Много системи осигуряват достъп до споделени участъци в паметта. Организацията на опашката за данни е широко разпространена. Използват се много опашки, всеки от които има свои собствени предимства.
• Обработка на искания за външни устройства. Всяка приложна програма в реално време е свързана с външно устройство. дефиниран тип. Ядрото трябва да предостави I / O услуги, които позволяват приложения да четат от тези устройства и да записват върху тях. За приложения в реално време, наличието на конкретен това приложение външно устройство. Ядрото трябва да предостави услуга, която улеснява работата с драйвери на устройства. Например, дайте възможност за записване на езици високо ниво - като Si или Pascal.
• Обработка на специални ситуации. Специална ситуация е събитие, което се случва по време на програмата. Тя може да бъде синхронна, ако възникването му е предсказуемо, както например, разделяйки нула. И може би асинхронни, ако се случи непредсказуемо, като например спад на напрежението. Осигуряването на способността да се справя с събития от този тип, позволява бързо и предсказуемо приложения за прилагане на вътрешни и външни събития. Има два метода за обработка на специални ситуации - използването на държавни стойности за откриване на погрешни условия и използване на специални ситуации, за да се прекъснат погрешни условия и да ги регулират.

Преглед на архитектурите ORVV

За своята история архитектурата на операционните системи е претърпяла значително развитие. Един от първите принципи на строителство, монолитнаOS (Фигура 1) е включена в OS View като набор от модули, взаимодействащи помежду си по различни начини в системата на системата и предоставяне на приложения входни интерфейси за достъп до оборудване.

ниво на ниво (фигура 2). Например, такава операционна система е добра известна система MS-DOS. В този клас системи, приложените приложения могат да имат достъп до оборудването не само чрез системното ядро \u200b\u200bили резидентни услуги, но и директно. Според този принцип ORRV е построен в продължение на много години. В сравнение с монолитна операционна система, такава архитектура осигурява значително по-голяма степен на предсказуемост на системните реакции и също така ви позволява бързо достъп до приложените приложения към оборудването. Недостатък

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

Фигура 2. ОС на ниво архитектура

Една от най-ефективните архитектури за изграждане на операционни системи в реално време е архитектурата на клиента-сървър. Цялостната схема на операционния софтуер за тази технология е представена на фигура 3. Основният принцип на такава архитектура е да се правят услуги на OS под формата на сървъри до потребителското ниво, а микрохернелът изпълнява функциите на диспечера на съобщенията между клиента потребителски програми и сървъри - системни услуги. Такава архитектура дава много предимства от гледна точка на изискванията за OSR и вградени системи. Сред тези предимства може да се отбележи:

1. Надеждността се увеличава, защото Всяка услуга е всъщност независимо приложение и е по-лесно да се отстранят грешките.

2. Такава система е по-добре мащабирана, тъй като ненужните услуги могат да бъдат изключени от системата, без да се засяга нейното изпълнение.

3. Толерантността на неизправността на системата се увеличава, защото "Ходи" услуга може да бъде рестартирана без

рестартирайте системата.

Фигура 3. Изградете операционна система с помощта на архитектурата на клиента-сървър

За съжаление, днес не толкова операционна система се изпълняват на принципа на клиентския сървър. Сред известните OSRs прилагат архитектурата на микро линията, OS9 и QNX могат да бъдат отбелязани.

Списък на препратките:

1) http://ru.wikipedia.org/wiki/operative_system_ravi_termenie.

2) http://www.asutp.ru/?p\u003d600591.

3) http://www.mka.ru/?p\u003d40774.

4) http://www.4stud.info/rtos/lecture1.html.

5) http://www.ozon.ru/contextext/detail/id/3092042/

операционна система реално време

1. Въведение: характеристики на операционните системи в реално време

1.1. Процеси, потоци, задачи

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

1.3. Памет

1.4. Прекъсвания

1.5. Часовник и таймери

1.6. Стандарти за OSR

1.6.1. Позикс.

1.6.2. DO-178B.

1.6.3. Arinc-653.

1.6.4. OSEK.

1.6.5. Стандарти за сигурност

1.7. Персонализиране на операционните системи

2. Кратки характеристики на най-често срещания OSR

2.1. Vxworks.

2.2. Qnx neutrino rtos.

2.3. Rtems.

2.4. Чорусо.

2.5. Разширения в реално време за Windows NT

2.5.1. RTX.за Windows Nt.

2.5.2. На време.

2.5.3. Microsoft Windows Embedded.

2.6. Tinyos.

2.7. OSEK / VDX.

2.8. OSE RTOS.

2.9. Contiki.

2.10. psos.

2.11. Интегритет.

2.12. Линсос.

2.13. Микровю OS-9

2.14. Грейс-операционна система.

2.15. C изпълнителна власт

2.16. Cmx-rtx.

2.16.1. Cmx-tiny +

2.17. Inferno.

3. OS, проектирана специално за преносими устройства

3.1. Itron.

3.2. Windows CE.

3.3. Яваос.

3.4. Дж.

3.5. Ядрото rtos.

3.6. Изумруди.

3.7. Кортекс

3.8. Делта.

3.9. Palm OS.

3.10. Symbian OS (EPOC)

4. Персонализиране на операционните системи

4.1. Изкуствена адаптация

4.1.1. Статична адаптация инициирана от дизайнера

4.1.2. Динамична адаптация инициирана от администратора

4.2. Адаптация, инициирана от заявлението

4.2.1. Адаптация от нивото на приложението

4.2.2. Адаптация на нивото на ядрото

4.3. Автоматична адаптация

5. Обобщени характеристики на таблицата на OSR

Приложение А. Списък на съкращенията

Допълнение Б. Терминология

Литература

Списък на OSRS, споменати в този текст, печат и онлайн

1. Въведение: характеристики на операционните системи в реално време

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

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

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

Обичайно е да се разграничат системите на мек (мек) и твърд (твърд) в реално време. В твърди системи Невъзможност за реално време да се гарантира реакцията на всички събития в определено време води до неуспехи и невъзможност за изпълнение на задачата. В повечето руско-езикова литература такива системи се наричат \u200b\u200bсистеми с детерминист. В практическо приложение времето за реакция трябва да бъде минимално. Системите с леко в реално време се наричат \u200b\u200bсистеми, които не попадат под определението "трудно", защото В литературата няма ясна дефиниция. Меките системи в реално време може да нямат време за решаване на задачата, но това не води до неуспех на системата като цяло. В системите в реално време е необходимо да се въведе някакъв политически термин (на литературата на английски език - срок), преди изтичането на която трябва задължително да се изпълни задачата (за меки системи в реално време - желателно) да бъде изпълнено. Този предел период се използва от планировчика задача, за да зададе приоритет на задачата, когато е стартиран и при избора на задача за изпълнение.

Мартин Тиммерман формулира следните необходими изисквания за OSR:

Операционната система трябва да бъде многозадачност и допустима (предупредима),

OS трябва да има концепция за приоритет за потоците,

OS трябва да поддържа предвидими механизми за синхронизация,

Операционната система следва да гарантира механизма на наследяване на приоритетите,

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

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

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

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

По правило повечето от съвременните OSRs са изградени на базата на микрокер (ядро или ядро), което осигурява планиране и изпращане на задачи и също ги изпълнява. Въпреки минимизирането в ядрото на абстракциите на операционната система, микрохерна все още трябва да има представа за абстракцията на процеса. Всички други концептуални резюма на операционните системи се депозират извън ядрото, се наричат \u200b\u200bискане и изпълнени като приложения.

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