Downloadfile

Операционна система за реално време за вградени системи
_______________________________________________________
Съдържание
1. ОПЕРАЦИОННИ СИСТЕМИ ЗА РЕАЛНО ВРЕМЕ ЗА ВГРАДЕНИ СИСТЕМИ..........................................3

1.1. ОБЩ ПРЕГЛЕД.............................................................................................................................................................3
1.1. ПРЕГЛЕД НА СЪВРЕМЕННИТЕ ОСРВ ЗА ВГРАДЕНИ СИСТЕМИ..................................................................................5
1.1.1. OSEK/VDX............................................................................................................................................................5
1.1.2. X51.........................................................................................................................................................................6
1.1.3. FREERTOS.............................................................................................................................................................6
1.2. ОСНОВНИ ЦЕЛИ И ЗАДАЧИ НА НАСТОЯЩАТА РАЗРАБОТКА......................................................................................6
2. РАЗРАБОВАНЕ НА ОПЕРАЦИОННАТА СИСТЕМА ЗА РЕАЛНО ВРЕМЕ..................................................8
2.1. АРХИТЕКТУРА НА ОПЕРАЦИОННАТА СИСТЕМА ЗА РЕАЛНО ВРЕМЕ..........................................................................8
2.2. ДИСПЕЧЕРИЗАЦИЯ НА ЗАДАЧИТЕ..............................................................................................................................8
2.2.1. МЕХАНИЗЪМ НА ПРЕВКЛЮЧВАНЕ НА ЗАДАЧИТЕ..................................................................................................8
2.2.2. ВИДОВЕ ДИСПЕЧЕРИЗАЦИЯ.................................................................................................................................11
2.2.2.1. КООПЕРАТИВНА ДИСПЕЧЕРИЗАЦИЯ................................................................................................................12
1.1.1.1. ДИСПЕЧЕРИЗАЦИЯ С ИЗТЛАСКВАНЕ................................................................................................................13
1.1.1.2. ДИСПЕЧЕРИЗАЦИЯ ОТ СМЕСЕН ТИП................................................................................................................14
1.2. ПОТРЕБИТЕЛСКА ЗАДАЧА........................................................................................................................................14
1.2.1. ГРАФ НА СЪСТОЯНИЯ НА ЗАДАЧИТЕ...................................................................................................................14
1.2.2. БАЗОВА ЗАДАЧА...................................................................................................................................................16
1.2.3. РАЗШИРЕНА ЗАДАЧА............................................................................................................................................16
1.2.3.1. ПРИОРИТИЗАЦИЯ НА ЗАДАЧИТЕ......................................................................................................................17
1.2.4. ТОЧКИ НА ДИСПЕЧЕРИЗАЦИЯ НА ЗАДАЧИТЕ.......................................................................................................17
20.1.1. СИСТЕМЕН ДИСПЕЧЕР..........................................................................................................................................18
20.1.2. АКСЕСОАРИ НА ДИСПЕЧЕР И ПОТРЕБИТЕЛСКИ ЗАДАЧИ.....................................................................................18
21. СИСТЕМНИ ПРЕКЪСВАНИЯ В ОСРВ........................................................................................................................18
21.1. ПРЕКЪСВАНИЯ КАТЕГОРИЯ 1...............................................................................................................................19
21.2. ПРЕКЪСВАНИЯ КАТЕГОРИЯ 2...............................................................................................................................20
22. РЕЖИМИ НА РАБОТА НА ОПЕРАЦИОННАТА СИСТЕМА ЗА РЕАЛНО ВРЕМЕ..............................................................21
22.1. ЦЕЛ НА РЕЖИМИТЕ..............................................................................................................................................21
22.2. СТАРТИРАНЕ НА СИСТЕМАТА..............................................................................................................................21
22.3. ОГРАНИЧЕНИЯ ПРИ ПРЕВКЛЮЧВАНЕ НА ОТДЕЛНИТЕ РЕЖИМИ..........................................................................21
23. МЕХАНИЗЪМ ЗА ОБСЛУЖВАНЕ НА СИСТЕМНИ СЪБИТИЯ........................................................................................21
23.1. КАКВО ПРЕДСТАВЯЛВАТ СЪБИТИЯТА..................................................................................................................21
24. УПРАВЛЕНИЕ НА РЕСУРСИТЕ В ОСРВ....................................................................................................................21
24.1. ЗАЕМАНЕ НА РЕСУРС...........................................................................................................................................22
24.2. ОСВОБОЖДАВАНЕ НА РЕСУРС.............................................................................................................................22
24.3. ОГРАНИЧЕНИЯ ПРИ ЗАЕМАНЕ НА РЕСУРС...........................................................................................................22
24.4. ДИСПЕЧЕРЪТ КАТО РЕСУРС..................................................................................................................................22
24.5. ОСНОВНИ ПРОБЛЕМИ СЪС СИНХРОНИЗАЦИЯТА..................................................................................................22
24.5.1. ИНВЕРСИЯ НА ПРИОРИТЕТА НА ЗАДАЧА.............................................................................................................22
24.5.2. ПРОТОКОЛ ЗА ТАВАНЕН ПРИОРИТЕТ...................................................................................................................23
24.5.3. МЪРТВА ХВАТКА..................................................................................................................................................24
25. АЛАРМИ...................................................................................................................................................................25
25.1. БРОЯЧИ.................................................................................................................................................................25
25.2. УПРАВЛЕНИЕ НА АЛАРМИ...................................................................................................................................25
26. ВЪТРЕШНО-СИСТЕМНА КОМУНИКАЦИЯ..................................................................................................................25
26.1. ОБМЕННА ИНФОРМАЦИЯ В ЗАДАЧИТЕ................................................................................................................25
27. ВЪЗМОЖНОСТТИ ЗА ОПИТМИЗАЦИЯ В ОСРВ.........................................................................................................25
27.1. СПОДЕЛЯНЕ НА СТЕК МЕЖДУ ЗАДАЧИТЕ............................................................................................................26
28. ВЪЗМОЖНОСТТИ ЗА НАСТРОЙКА И ДИАГНОСТИКА В ОСРВ..................................................................................26
28.1. ДИНАМИЧЕН ВРЕМЕВИ АНАЛИЗ В СИСТЕМИТЕ ЗА РЕАЛНО ВРЕМЕ....................................................................29
28.1.1. АЛГОРИТЪМ ЗА ДИСПЕЧЕРИЗАЦИЯ С ФИКСИРАН ПРИОРИТЕТ НА ЗАДАЧИТЕ.....................................................30
28.1.2. ГОРНА ГРАНИЦА НА НАТОВАРВАНЕТО НА ПРОЦЕСОРА ПРИ СИСТЕМИ ЗА РАБОТА В РЕАЛНО ВРЕМЕ...............33
28.1.3. АНАЛИЗ И МЕТОДОЛОГИЯ ЗА ИЗЧИСЛЯВАНЕ НА НАЙ-ЛОШ СЛУЧАЙ ЗА РЕАКЦИЯ НА СИСТЕМАТА..................39
28.2. ДИАГНОСТИЧНИ КУКИ НА ОСРВ........................................................................................................................43
28.3. МОНИТОРИНГ НА СТЕКА......................................................................................................................................44
1 / 58
_______________________________________________________
28.3.1. МЕТОДИ ЗА МОНИТИРАНЕ НА РАЗМЕРА НА СТЕКОВИТЕ ОБЛАСТИ....................................................................44
28.4. АНАЛИЗ НА ВРЕМЕВИТЕ ПАРАМЕТРИ НА ОСРВ.................................................................................................47
28.4.1. МОНИТОРИНГ ДИСПЕЧЕРИЗАЦИЯТА НА ЗАДАЧИТЕ............................................................................................47
28.4.2. АНАЛИЗ И ДЕТЕРМИНИРАНЕ НА МАКСИМАЛНАТА ЧЕСТОТА НА СИСТЕМНИТЕ ПРЕКЪСВАНИЯ........................52
28.4.3. ПРОФИЛИРАНЕ НА ВРЕМЕВИТЕ ПАРАМЕТРИ НА ЗАДАЧИТЕ................................................................................52
28.5. АНАЛИЗ И СТАТИСТИКА НА ИЗПОЛЗВАНИТЕ АПАРАТНИ РЕСУРСИ...................................................................52
28.6. ВИДОВЕ ГРЕШКИ В ОСРВ И ТЯХНОТО ОБСЛУЖВАНЕ........................................................................................52
29. СТАНДАРТИЗАЦИЯНА ИЗПОЛЗВАНИТЕ ТИПОВЕ ПРОМЕНЛИВИ И КОНСТАНТИ В ОСРВ........................................52
29.1. ОБЩИ ТИПОВЕ НА ПРОМЕНЛИВИТЕ.....................................................................................................................52
29.1.1. ДИСПЕЧЕР............................................................................................................................................................52
29.1.2. ЗАДАЧИ.................................................................................................................................................................52
29.1.3. СИСТЕМНИ СЪБИТЯ..............................................................................................................................................52
29.1.4. РЕСУРСИ...............................................................................................................................................................52
29.1.5. АЛАРМИ...............................................................................................................................................................52
29.1.6. СИСТЕМНИ ПРЕКЪСВАНИЯ..................................................................................................................................52
29.1.7. ДИАГНОСТИЧНИ КУКИ.........................................................................................................................................52
30. СТАНДАРТИЗАЦИЯНА СИСТЕМНИТЕ ФУНКЦИИ В ОСРВ........................................................................................52
30.1. СИСТЕМНИ МАКРОСИ..........................................................................................................................................52
30.2. ОГРАНИЧЕНИЯ ПРИ ИЗПОЛЗВАНЕТО НА СИСТЕМНИ ФУНКЦИИ..........................................................................52
31. ПРЕНОСИМОСТ НА ОСРВ........................................................................................................................................52
31.1. ПОДДЪРЖАНИЕ АПАРАТНИ АРХИТЕКТУРИ..........................................................................................................52
31.1.1. TEXAS INSTRUMENTS MSP430............................................................................................................................52
31.1.2. ARM ЯДРА...........................................................................................................................................................52
31.2. КЛАСИФИКАЦИЯ НА ОТДЕЛНИТЕ СТРУКТУРНИ ЕДИНИЦИ В ОСРВ ПО ОТНОШЕНИЕ НА ТЯХНАТА АПАРАТНА
ПРЕНОСИМОСТ.....................................................................................................................................................................52
31.2.1. АПАРАТНО ЗАВИСИМИ ЗВЕНА.............................................................................................................................53
31.2.2. АПАРАТНО НЕЗАВИСИМИ ЗВЕНА.........................................................................................................................53
31.2.3. НЕОБХОДИМИ КОНФИГУРАЦИИ НА АПАРАТНО ЗАВИСИМИТЕ ЗВЕНА................................................................53
31.2.4. ГЕНЕРАЦИЯ НА ОСРВ.........................................................................................................................................53
32. МЕТОДОЛОГИЯ ЗА РАЗРАБОТВАНЕ НА СИСТЕМА ЗА РЕАЛНО ВРЕМЕ НА БАЗАТА НА ОСРВ.................................53
32.1. ОСНОВНИ ПРИНЦИПИ..........................................................................................................................................53
32.1.1. РАБОТА С ПРЕКЪСВАНИЯ И КРИТИЧНИ СЕКЦИИ.................................................................................................53
32.2. ИЗВЕСТНИ ПРОБЛЕМИ И ОГРАНИЧЕНИЯ В НАСТОЯЩАТА РАЗРАБОТКА..............................................................54
32.2.1. ПРЕПОРЪКИ ЗА ЗАОБИКАЛЯНЕ НА ПРОБЛЕМИТЕ.................................................................................................54
32.2.2. ПРЕПОРЪКИ ПО ОТНОШЕНИЕ НА НАЛОЖЕНИТЕ ОТ СИСТЕМАТА ОГРАНИЧЕНИЯ ОГРАНИЧЕНИЯТА..................54
32.3. ФАЙЛОВ СТРУКТУРА НА ОСРВ...........................................................................................................................54
ПРИЛОЖЕНИЕ...................................................................................................................................................................55
ФИГУРИ................................................................................................................................................................................55
ТАБЛИЦИ.............................................................................................................................................................................56
БИБЛИОГРАФИЯ...............................................................................................................................................................56
2 / 58
_______________________________________________________
1. ОПЕРАЦИОННИ СИСТЕМИ ЗА РЕАЛНО ВРЕМЕ ЗА ВГРАДЕНИ СИСТЕМИ
1.1. Общ преглед
Операционната Система за Реално Време (ОСРВ) представлява комплекс от програми,

които са важна съставна част от съврeменната компютърна (изчислителна) система. Нейната
основна задача е адекватно управление на системните ресурси, с цел изготвяне на
необходимата реакция в реално време при настъпване на вътрешно или външно системно
събитие. Системите за работа в реално време (СРВ) служат за следене и управление на обекти
от реалния свят. Te възприемат определено множество от въздействия и изработват съответните
реакции в фиг. 1
фиг. 1 Взаимодействие на ОСРВ с физическата среда
Въздействията върху СРВ са резултат от определени събития {an}, възникващи асинхронно

едно спрямо друго. От своя страна реакциите на системата се възприемат от физическата й
среда също като поява на събития {bm} Преобразуването на въздействията с непрекъснат
характер в дискретна форма, както и на дискретните реакции в непрекъснати, при необ-
ходимост се извършва от съответния хардуер на СРВ. Множеството събития-въздействия А =
{an} и множеството събития-реакции R = {bm} са свързани помежду си със зависимостта :
R=R ( A) 1.1
, която задава алгоритъма на функциониране на OСРВ.

Съществуват три основни категории операционни системи :
- Операционни системи за пакетна обработка – отделните задания се
изпълняват по строго определен на последователност предварително зададена от оператора.
- ОС с времеделене – на всяка една от задачите се предоставя един
квант време, през която тя е активна. Превключването между задачите е явно.
3 / 58
_______________________________________________________
В съответствие с ресурсния принцип трите основни категории ОС служат за управление на
ресурсите на компютърната система, но се различават помежду си по използуваните стратегии
за управление. Управлението им в реално време се формулира по основния принцип: изходната
реакция на системата трябва да се изработва в рамките на строго определен времеви интервал.
Операционните системи за реално време (ОСРВ) като част от СРВ, трябва да гарантират
спазване на изискването за работа в реално време. Тази характерна особеност на СРВ се
илюстрира на фиг. 2.
фиг. 2 Основни моменти в система за реално време
Периодът Тr за определяне на реакцията r ∈ R на въздействието а ∈ А е променлив поради

асинхронния характер и непредсказуемото влияние на въздействията върху хода на изчисли
телния процес. Изискването за работа в реално време се свежда до изпълнението на
неравенството:
t r=(T a+ T r )<t d 1.2
където td е крайният срок за изработване на реакциятa r от СРВ. Нарушаването на горното

неравенство е равносилно нa отказ на системата.
Чрез добавянето координата на времето се разширява кръга на проблемите, които трябва да
се решават при проектирането на СРВ. За да се поддържа управляемостта на проекта при тези
условия, се налага придържането към единен, добре структуриран подход. В рамките на ОСРВ
този подход се свежда до осигуряване на многозадачен режим на работа. Многозадачният
режим на работа се съгласува с особеностите на средата, в която функционира СРВ.
Многозадачната система се състои от множество асинхронни задачи
T ={T i } и среда за
комуникация между тях (фиг. 3).
4 / 58
_______________________________________________________
фиг. 3 Структура на СРВ – множество задачи и среда за комуникация помежду им
Всяка задача представлява активен логически обект, извършващ определена работа в

системата. В общия случай всяко събитие е свързано с дадена задача, която отговаря за
работата, породена от събитието. Връзките между задачите се определят от функционалната
зависимост R(А).
Многозадачността е еднакво подходяща както за еднопроцесорни, така и за
многопроцесорни СРВ. Необходимите механизми и в двата случая се осигуряват от ОСРВ и са
прозрачни за приложните задачи.
1.1. Преглед на съвременните ОСРВ за вградени системи
1.1.1. OSEK/VDX
OSEK е съкращение от немския термин” Offene Systeme und deren Schnittstellen für die
Elektronik im Kraftfahrzeug" (б.а.: Отворени системи и сътветните взаимовръзки за електронни
изделия в автомобилната промишленост).”Представлява статична операционна система за
отказо устойчиви вградени системи. Статичността на системата се изразява в това, че системата
не притежава възможност за поддръжка на динамични обекти. Нейната структура е статична и
се дефинира в процеса на създаване на ОСРВ. Тази структура не се променя в последствие.
OSEK операционна система предоставя необходимите услуги за подръжка на разпределени,
отказо-устойчиви, приложения за реално време с висока сигурност - стартиране на системата,
управления на комуникация, обработване на прекъсвания, синхронизация и стратегия за
управление на грешките и проблемите
Операционната система се генерира на базата на потребителски настройки и конфигурации.
Тя не може да бъде модифицирана по време на нейната работа. Което означава, че тя е статична
– и нейния първоначален вид – като използвани ресурси се запазва за целия жизнен цикъл на
продукта без допълнителни модификации. Така специфицираните услуги на ОС предоставят
база за интеграция на софтуерни модули, разработени от различни производители. За
създаването на специфична функционалност в индивидуалните модули за контрол и
управление, е необходимо да се нарави оценка техните характеристика на работа, както и
изисквания за минимална консумация на ресурси
Системните услуги, са основното звено в OSEK. Те взимат участие в изпълнението на задачите,
както и управление на техните преходи, в зависимост от състоянието на цялата система. Те са
5 / 58
_______________________________________________________
отговорни за управлението на ресурсите и събитията, както и обработването на прекъсвания.
Системите услуги се активират при настъпване на някое от следните събития:
- изтичане на системния квант от време;
- явно искане за превключване на задача;
- настъпване на очаквано събитие;
- освобождаване на очакван ресурс;
- настъпване на системно прекъсване.
Основните характеристики са:
- OSEK операционна система е конфигуриуема и статична като изпълнение. Потребителят
може да специфицира броя на задачите, ресурсите, и системинте услуги, които са
необходими.
- Спецификацията на OSEK операционна система разрешава съзадаването на софтуерни
модули, които се изпълняват направо от ROM.
- OSEK операционна система изисква преносимост на приложните задачи, по отношение
на използваната апаратна платформа
- OSEK операционна система предоставя възможност за предсказване и документиране на
поведението, като по този начин реализацията може да осигури покритието на
изисквания към критичните системи за реално време.
- Спецификацията на OSEK операционна система дава възможност за изграждане на
система с ясно заложени изисквания по отношение на времето и ресурсите.
1.1.2. X51
НЕ Е ГОТОВО!
1.1.3. FreeRTOS
НЕ Е ГОТОВО!
1.2. Основни цели и задачи на настоящата разработка
Електронните системи за диагностика в железопътния транспорт се характеризират с

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

използването на операционна система за реално време (ОСРВ). Използването на операционна
6 / 58
_______________________________________________________
система за реално време е доста популярен подход в автомобилната индустрия през последните
10 години. OSEK/VDX стандарта е резултат от стремежа на автомобило-производителите и
техните доставчици за създаване на стадартизирана софтуерна инфраструктура в
автомобилните електронни системи. Основните съображения произтичат от факта за
непрекъснатото увеличаване сложността на различни електронни системи, чието управление е
възможно чрез добре дефинирани модули и връзки между тях.
Отделните програмни функционални блокове се декомпозират на компоненти – най-
малките абстрактни логически единици (фиг. 4)
фиг. 4 Декомпозиция на фукционалностти
Компонента е независим програмен обект, реализращ определена функционалност

независимо. Той се характеризира с определен брой входове и изходи, наречени интерфейс на
компонента. Всеки компонент трябва да притежава два вида интерфейси:
- Системен интерфейс – посредством него, операционната система предоставя достъп до
процесора за изпълнение. Системният интерфейс има еднакъв вид за всички компоненти
в системата.
- Функционален интерфей – посредством него отделните компоненти взаимодействам по
между си.
Отделните компоненти, чийто параметри – събитие за активиране, период на циклично
изпълниение - се групират в така наречените потребителски задачи. Посредством
потребителските задачи, операционната система реализира манипулации върху групираните
компоненти. По този начин се постига:
- Последователно използване на наличните в системата ресурси, като се постига по-
голяма производителност, без необходимост от допълнителни апартни средства;
- Прецизно планиране на изпълниението на отделните задачи, чрез използването на
услугите на опрерационната система.
7 / 58
_______________________________________________________
- Възможност за съвместно псевдо-паралелно изпълнение на бавни, време консумиращи
задачи и бързи критични по отношението на времето задачи задачи.
- Възможност за бърза реакция на системата на събитие, посредством различен набор от
възможности за обработка на системни прекъсвания.
- Възможност за контрол и самодиагностика на времето за изпълнение на отделните
задачи.
- Независимост на програмното осигуряване по отношение на апаратната платформа.
2. РАЗРАБОВАНЕ НА ОПЕРАЦИОННАТА СИСТЕМА ЗА РЕАЛНО ВРЕМЕ
2.1. Архитектура на операционната система за реално време
Неизмено изискване към ОСРВ е възможността за нейната преносимост в определен

набор от микоропроцесорни фамилии. За целта е необходимо изграждане на обощен
архитектурен модел. На базата на този модел, се извършва анализ на отделните звена на
ОСРВ, с цел идентифициране на апаратно зависими/независими звена.
2.2. Диспечеризация на задачите
Създаването на условия за изпълнение на няколко задачи паралелно се нарича много-

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

дефиниран приоритет за всяка една от задачите. Контекстът на изпълняваната в момента
задача, е контекстът на физическия процесор в този момент. Когато в системата задача с
по-висок приоритет получи условия за активиране, тя трябва да бъде стартирана. За
целта контекстът на текущо изпълняваната се запазва в нейния виртуален процесор.
Активирането на по-високо приоритетната задача се изразява в зареждане на нейния
контекст от нейния виртуален процесор в регистрите на физическия процесор - фиг. 5.
8 / 58
_______________________________________________________
фиг. 5 Превключване на контекст на задачи

Възможно е да се направи частична аналогия между превключването на задачите в
ОСРВ и апаратно прекъсване в микроконтролера фиг. 6. В момента t1 настъпва апаратно
прекъсване. Завършва се текущо изпълняваната инструкция. В периода t1 - t2 контекстът
на програмата – текущо състояние (статус регистър) и адрес на следващата за изпълнение
инструкция - се запазва в стека. В момента t3 подпрограмата за обслужване на прекъсване
завършва и е необходимо възстановяване на контекста напрекъснатата програма - t3 - t4.
От t4 на сетне програмата продължава своето изпълнение, от следващата инструкция
преди настъпването на прекъсването. Възстановяването на прекъснатата програма се
извършва посредством инструкцията RETI (б.а. – return from interrupt – MSP430).
Операциите, които извършва тази инструкция са : възстановяване на статус регистъра на
процесора от стека, зареждане на регистъра програмен брояч със следващия адрес на
инструкцията от програмата запазен в стека в периода t1 - t2
фиг. 6 Апаратно прекъсване в микроконтролер
9 / 58
_______________________________________________________
Подебен сценарии се използва и за превключване между задачите. Съществува
компонент в ОСРВ, който управлява превключване на задачите наречен диспечер - фиг. 7.
фиг. 7 Превключване на задачи

Диспечерът се активира в точката на диспечеризация. Тази точка представлява вътрешно
системно събитие за ОСРВ, което води до изменение на състоянието на задачите (1.2.4
Точки на диспечеризация на задачите) или състояние на други компоненти в ОСРВ.
Диспечерът се активира, обслужва смяната на ссътоянието на задачите и активира
задачата, с най-висок приоритет. Моментът to1 е точка на диспечеризация, когато
активната задача 1 е прекъсната и се активира диспечерът. Интервалът to1-tc1, диспечерът
запазва контекста на задача 1. Периодът за обслужване състоянията на компонентите в
ОСРВ е tc1-tr1. Задачата с най-висок приоритет, готова за изпълнение е идентифицирана –
задача 2 и тя е с по-висок приоритет от задача 1. Съдържанието на нейният контекст се
зарежда от виртуалния и процесор във физическия и в момент ts1 тя стартира своето
изпълнение. Когато завърши своето изпълнение, задача 2 предоставя контрол на
изпълнението (точка на диспечеризация) на диспечера – to2. В интервала от време to2- tc2,
диспечерът запазва нейния контекст от физическия процесор в съответния за зада чата
виртуален. Диспечерът извършва обслужване на състоянията на отелните компоненти в
ОСРВ, в резултат на което идентифицира следващата готова за изпълнение - задача 1. В
моментът tr1, той възстановява нейният контекст, запазен в периода to1-tc1. Така задача 1
продължава своето изпълнение, прекъснато в момент to1.
В резултат от разгледаният сценарии за превключване на задачите се установява, че
ОСРВ преминава през едни и същи процедури и харатерни моменти по време на своята
работа:
to – точки на диспечеризация;
ts – точки на стартиране/възстановяване изпълнението на задачите;
to – ts – зазпазване на контекста на изпълняванеата задача (от физически във виртуален
процесор);
tr-ts – извличане и зареждане на контекст за стартиране на задача (от виртуален във
физически процесор).
10 / 58
_______________________________________________________
Превключването на задачите, трябва да бъде съобразено с основното изискване за работа
в реално време - фиг. 2. За изпълняването е необходимо да се спазят следните изисквания,
в съответствие с правило 1.1 :
td ≡ to & (ts – to) < Trmax
2.2.2. Видове диспечеризация
Многозадачното ядро на ОСРВ поддържа отделен виртуален процесор за всяка задача.

Непосредствено след стартирането на системата в нея съществува само един виртуален
процесор, предназначен за системния процес, който ще бъде наричан диспечер. При
създаването на дадена приложна задача диспечерът присъединява към нея виртуален
процесор, на който тя се изпълнява паралелно с останалите задачи. При еднопроцесорните
системи, намиращи се в кръга на нашето внимание, се говори за конкурентен режим на
изпълнение на задачите..
Абстракцията на виртуалните процесори се основава на системните структури данни и
на механизма за разпределение на процесорното време. Регистрите на виртуалния
процесор на задача се съхраняват в областта за контекста на процесора от дескриптора
задачата
В еднопроцесорните системи процесорът е единственият активен ресурс, който се
разпределя от многозадачното ядро. Следователно диспечерът е компонент на ядрото,
разпределящ процесорното време между готовите за изпълнение задачи.
Диспечерът е тази част от ядрото на ОСРВ, която осигурява механизма на виртуалните
процесори, а следователно и многозадачността на системата.
Планирането на процесорното време, особено при пакетните и многопрограмните ОС, е
по-общо понятие, предполагащо няколко йерархични нива. Диспечеризацията, според
горното определение, представлява най-ниското ниво на планиране на процесорното
време. Това ниво е задължително за всяка ОСРВ, докато по-високите нива — не.
Съществуват две основни стратегии на планиране на процесорното време:
- стратегия без прекъсване на обслужването на изпълняваната задача (non-preemptive
dispatching), известна в литературата още като “стратегия без изтласкване” или
„кооперативна стратегия за диспечеризация”
- стратегия с приоритетно прекъсване на активната задача (preemptive dispatching), - като
“стратегия с изтласкване”.
Стратегията без изтласкване се основава на “принципа на хистерезиса” (Hysteresis
Principle) – измененията в системата да се подтискат.
Поради гореспоменатите недостатъци на стратегията за диспечеризация, в
настоящата разработка е възприета стратегията с приоритетно прекъсване на
обслужваната задача. Тази стратегия предоставя на високоприоритетните задачи
предимство при разпределението на процесорното време. Това предимство се изразява не
11 / 58
_______________________________________________________
само в наличието на приоритетни системни опашки. Такива може да има и при
диспечерите без изтласкване. Предимството е в механизма за прекъсване на текущото
обслужване в случай на възникване на заявка с по-висок приоритет. Подобна ситуация е
типична за СРВ, поради което диспечерите с изтласкване са по-подходящи при ОСРВ.
2.2.2.1. Кооперативна диспечеризация
Измененията в системата са свързани с определени системни разходи. Превключването

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

На фиг. 8 е показан примерен сценарий при изпълнение на две задачи при кооперативна
диспечеризация. Задача 1 притежава по-висок приоритет – 50 от задача 2, чийто приоритет е 10.
В началото на разглеждането, момент t0, задача 2 е текущо активна в системата. В момент t1,
12 / 58
_______________________________________________________
условията в системата се променят, което налага стартирането на задача 1. Стартирането на
задача се изразява от последователно преминаване от спряно състояние (SUSPENDED) в
готовност за стартиране (READY) и след като започне изпълнението на задачата в процесора,
тя преминава в активно състояние (RUNNING) – разгледано в детаили в §1.2.1. В този момент
задача 1 не може да бъде активирана, поради непрекъсваемия характер на диспечеризация за
задача 2. Задача 1 престоява известно време в състояние готовност за стартиране (READY) –
време известно в литературните източници като „латентно време”. Латентното време трябва да
бъде съобразено с правило 1.1. На задача 1 се предоставя процесорно време в момента t2,
когато задача 1 завършва своето изпълнение.
1.1.1.1. Диспечеризация с изтласкване
Стратегията за диспечеризация с изтласкване се основава на идеата, че изпъняваната

задача може да бъде прекъсната във всяка една инструкция от своя код, при установяване на
необходимите за това условия от операционната система. Тези характерни моменти в
операционната система са известни като „точки на диспечеризация” и са разгледани в §1.2.4. По
този начин прекъснатата задача ще бъде поставена в състояние готовност за стартиране
(READY) в момент t1, до завършване изпълнението на по-високо приоритетните задачи t3,
готови за изпълнение към този момент – фиг. 9
фиг. 9 Стратегия на диспечеризация с изтласкване

Периодът от време между t1 и t2 се използва от диспечера. През това време, се запазва
контекстът на прекъснатата задача 2, променя се състоянието на готовата за изпъление задача 1
в READY, след коетоконтекстът от нейният виртуален процесор се зарежда във физическия.
Това напрактика е и латентното време на системата, свързано със системните разходи на време.
13 / 58
_______________________________________________________
1.1.1.2. Диспечеризация от смесен тип
След направеният обзор на двете основни стратегий за диспечеризация лесно може да се

направи оценка техните предимства и недостатъци. При кооперативната стратегия за
изтласкване, системните разходи за превключване на задачите са сведени до минимум. От друга
страна беше показано (фиг. 8), че съществува изостването на реакцията на системата при
натъпване на по-високо приоритетно събитие. Това закъснение може да бъде неприемливо за
една система за работа в реално време, като наруши правило 1.1. При диспечеризацията с
изтласкване този проблем е решен за сметка на увеличаване на системните разходи за
диспечеризация - фиг. 9. Следователно решение кой принцип е по-добър не може да бъде взет
еднозначно.
Настоящата разработка предоствя възможност за едновремено използване на двата типа
диспечеризация. В точките на диспчеризация, ОСРВ използва една от двете стратегий, в
зависимост от типа на задачите, подлежащи на диспечеризация. По време на разработка на
система за реално време е необходим предварителен анализ и оценка на задачите включени в
тази система. За задачите с продължителност на изпълнение по-малък от системния квант от
време е препоръчилтено да бъдат с непрекъсваем харакетер. Задачите изикващи по-дълго
изпълнение от системния квант, трябва да бъдат с прекъсваем характер на изпълниение. По
този начин се постига необходимата реакция в съответствие с правило 1.1 - фиг. 2, и разумен
разход на системни ресурси.
1.2. Потребителска задача
Процесът представлява активен обект за декомпозиране на системата, който служи за

базова логическа единица. Именно такъв е и смисълът, който се влага в думата “задача”, като
част от системата за реално време. Програмното осигуряване се разделя на отделни части - фиг.
4, в зависимост от изискванията към тях по отношение на работата в реално време. Тези части
се реализират посредством потребителските задачи.
1.2.1. Граф на състояния на задачите
По време на своето съществуване процесите в една система за реално могат да се

намират в различни състояние. Смяната на състоянията на отделните процеси се извършва от
системното ядро. Тази смяна е свързана със системни загуби – време, заемани ресурси и др. От
друга страна е необходимо да се извърши точно структуриране на приложните задачи, по
отношение нуждите им и системата като цяло. Целта на това структуриране е създаване на
точни правила за обслужване на задачите от ядрото. На е показан граф на състоянията на
приложните задачи в системата за реално време - фиг. 10. Процесорът може да изпълни една
единствена инструкция от кода на задача в даден момент. Задачите променят своето състояние,
конкурирайки се за процесорно време.
14 / 58
_______________________________________________________
фиг. 10 Граф на състоянията и преходите за базова и разширена задача.

Преходите, между състоянията са строго дефинирани и се обслужват от диспечера на
операционната система – Таблица 1
Предишно
Преход Ново състояние Обяснение
състояние
Задачата притежава всички необходими

готовност SUSPENDED READY условия за изпълнение с изключение
напроцесора
активиране READY RUNNING Задачата започва своето изпълнение
Диспечерът прекъсва изпълнение на задачата

прекъсване RUNNING READY
поради наличие на по-високо приоритетна.
Задачата е завършила своето изпълнение и чрез

терминиране RUNNING SUSPENDED обръщение към диспечера е посикала
терминиране.
Изпълняваната в момента задача изчаква

изчакване RUNNING WAITING* дадено събитие. До момента на настъпване на
събитието, тя ще запази новото си състояние
Изчакваното събитие, от задачата е настъпило

освобождаване WAITING* READY
и тя има готовност за изпълнение
Таблица 1 Възможни преходи между състоянията на задачите
*
Състоянието WAITING е възможно само за разширен тип задачи.
15 / 58
_______________________________________________________
1.2.2. Базова задача
Базовите задачи могат да прекратят своето изпълнение само в следните случай:
- те се само-терминират посредством предоствен интерфейс от ОСРВ;
- базовата задача, изпълнявана в момента е с прекъсвама диспечеризация, и съществува

друга задача с по-висок приоритет от нея;
- натъпване на апаратно прекъсване от процесора и се преминава към изпълнение на

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

WAITING. Този механизъм се използва за синхронизация изпълнението на задачата с
определно събитие в ОСРВ (системните събития са описани в §23 Механизъм за
обслужване на системни събития)
фиг. 11 Изчакване на събитие от разширена задача.

На фиг. 11 е показан примерен сценарий за изпълнение на разширена задача. В момент
t0 е активна задача 1 – от разширен тип. По време на своето изпълнение е необходимо тя да
16 / 58
_______________________________________________________
бъде синхронизирана по системно събитие. Поради тази причина в момент t1 тя прекрътява
своето изпълнение чрез явно обръщение към диспечера (WaitEvent). Диспечерът я поставя в
състояние WAITING и стртира прекъсваемата задача 2 в момент t2. В момент t3 настъпва
очакваното събитие от задача 1, което кара диспечерът да промени нейното състояние в
READY. Поради факта, че в момента задача 1 е с най-висок приоритет, диспечерът стартира
задачата в t4. След като завърши своята работа, задача 1 прави обръщение към диспечера за
терминиране (TerminateTask) – t5. В последствие прекъснатата задача 2 бива стартирана от
диспечера 2 момент t6.
Разширените задачи са подходящи за използване при необходимост от междинно
синхронно изпълнение с предварително дефинирано вътрешно системно в ОСРВ събитие. По
този начин се постига бърза реакция при настъпването на събитието. От друга страна
механизмът позволява уплътняване на процесорното време до настъпване на събитието чрез
стартиране на по-ниско приоритетни задачи. На лице е баланс между бързина на реакцията и
оптимизация на системните ресурси.
1.2.3.1. Приоритизация на задачите
Диспечерът на базата на съответния приоритет на задачите решава, коя от опашката на готовите

задачи в състояние READY, да бъде стартирана – състояние RUNNING. Приоритет е
количествената характеристика на задачата по отношение на нейната важност. По високо число
записано в полето приоритет, отговаря на по-висок приоритет. С цел увеличаванена
ефективността на системата, динамичният приоритет не се поддържа от ОСРВ. Приоритет е
дефиниран статично и не може да бъде променян от потребителя, по време на работа на
системата. Съществуват някой частни случай, когато ОСРВ третира задача с по-висок от
първоначално дефинирания приоритет. Този механизъм за промяна на приоритета на задачите е
известен като „Протокол за горна граница на приоритета” (Priority Ceiling Protocol) или „Таван
на приоритета”.
1.2.4. Точки на диспечеризация на задачите
2. Activation of the scheduler

3. ● full preemptive tasks
4. ● activation when the
5. running task
6. – is terminated
7. – enters the waiting state
8. – releases a resource
17 / 58
_______________________________________________________
9. ● if other tasks are

10. – activated
11. – released from waiting
12. state
13. ● if an ISR finishes
14. ● non preemptive tasks
15. ● activation when the
16. running task
17. – is terminated
18. – enters the waiting state
19. ● if the scheduler is explicitly
20. called
20.1.1. Системен диспечер
20.1.2. Аксесоари на диспечер и потребителски задачи
21. Системни прекъсвания в ОСРВ
Системните прекъсвания представляват апаратно реализируема функционалност за бързо

регистриране на вътрешни или външни събития. Несъмнено това е функционалност
предоставяща възможност за обслужване на събития в реално време и е неизменен компонент
на системата за реално време. Необходимо е създаване на среда за обслужване на системните
прекъсвания в под управлянието на операционната система за реално време, а от друга страна
да се спазят изискванията за зарбота в реално време – реакцията да не надвишаване на крайния
срок на реакцията. Управлението на системните прекъсвания от операционната система за
реално време би добавила допълнителни разходи на процесорно време. Това би довело до
допълнително забавяне на изготвянето на резултатната реакацията на системното прекъсване. В
някой случай, това може да се окаже недопустимо – натоварване на система до степен, в която
изискванията за работа в реално време са нарушени. Поради този факт е необходимо системата
да предостави възможност за автономно облужване на системните прекъсвания без въвличане
на операционната система за реално време.
18 / 58
_______________________________________________________
От друга страна, е възможно реакцията, изготвена от системата да бъде композирана от няколко
отделни задачи на операционната система. Следователно операционната система за реално
време трябва да предостави възможност за обслужване на системни прекъсвания с пряко нейно
участие.
На базата на преставените аргументи по-горе, са синтезирани два метода за обслужване на
системните прекъсвания :
- Прекъсвания категория 1 – използват се за бързо обслужване на системни прекъсвания

без участие на операционната система за реално време.
- Прекъсвания категория 2 – обслужване на прекъсвания с участие на операционната

система.
21.1. Прекъсвания категория 1
Този метод за обработка на прекъсвания използва съответната апаратна база за регистриране и

облужванена прекъсването. От гледна точка на операционната система за реално време, от
моментът на настъпване на събитието пораждащо системното прекъсване до завършване на
подрпограмата за изпълнението му остава невидим. През това време опрационната система не
извършва никакви манипулаций върху текущия контекст. По този начин се избягват системните
разходи на процесорно време и реакцията се изготвя максимално бързо.
Наред с предимствата при използването на този метод за обслужване на прекъсване, са налице
и някои неудобства. Те са свързани с контекста на изпълнението на подпрограмата за
обслужване на прекъсването. Поради факта, че операционната система не променя текущия
контекст, то подпрограмата се изпълнява в рамките на текущия. Следователно всички
обръщения към операционната система от подпрограмата за обрабока на прекъсването, ще
бъдат възприето от операционната система като заявки от обекта, в чийто контекст се обработва
прекъсването - фиг. 12. Това би довело до погрешно отразяване на тези заявки от
операционната система – източникът на заявка е недостоверен. Следователно методът за
обработка на прекъсвания – Категория 1, няма възможност за обръщения към операционната
система.
Контекст задача Контекст диспечер

Контекст
Прек. Кат. 1 Прек. Кат. 1
Задачи Задача Y Задача Y Задача N
Диспечер Диспечер Диспечер Диспечер
t1 t2 t3 t4 t
фиг. 12 Изпълнение на подпрограма за обрабока на прекъсване Категория 1
21.2. Прекъсвания категория 2
19 / 58
_______________________________________________________
В практиката възникават изисквания за създавне на комплексни реакций на базата на вътрешно
или външно схемно събитие. Комплексността на тази реакция най-често се изразява в
активирането наняколко потребителски задачи, очакващи това събитие. Тези операции са не
възможни без явно участие на сервизите предоставени от операционната система. За използване
на системните сервизи на операционната система е необходимо те да бъдат извършени
отобекти със собствен контекст в операционната система. Поради тази причина е необходимо
създаване на собствен контекст за подпрограмите за обработка на прекъсвания (ISR) от
Категория 2. За целта е необходимо въвличане на диспечерът в обработката на прекъсванията
от Категория 2 - фиг. 13.
act Обслужване на системно прекъсване Категория 2
Контекст Задача Y Контекст Диспечер Контекст прекъсване Категория 2
Зареждане на [Обръщение към ОС] Запазване на Зареждане на

вектор на контекст Y контекст X
прекъсване
[Стартиране на ISR]
INT X
«flow» [Използване на сис темен с ервиз]
Системно
Изпълнение на Системен
прекъсване X
подпрограма за сервиз
обслужване на X
[Завършване на ISR]
Изпълнение на
Превключване
Задача Y контекст X->Y
[Възс тановяване на прекъс натата задача]
фиг. 13 Обслужване на прекъсване Категория 2 (UML – activity diagram)

Може да се отбележи, че системните разходи при използването на метод за обслужване на
прекъсвания Категория 2 са съществени и превъзхождат по време тези от Категория 1 - фиг. 14.
Необходимо е да се обърне внимание на факта, че изпълненнието на подрпрограмата за
обслужване на прекъсване може да съвпадне с изпълнение на потебитеска задача. Това води до
изместване напред във времето момента на завършване изпълнението на прекъснатата задача.
Този ефект може да доведе до нарушаване на изискванията за работа в реално време за задачата
и като краен ефект да се получи системен ресет, предизивикан от монитиращата
функционалност (виж. §28.4.1Мониторинг диспечеризацията на задачите).
Като обощение на представените по-горе факти, трябва да се отбележат основните препоръки за
използване на двата вида методи за облсужване на прекъсвания. Категория 1 са подходящи за
използване при кратки подпрограми за обслужване на прекъсвания. Те са препоръчителни при
висока честота на поява на системните прекъсвания относно системния времеви квант – честота
по-голяма от пет системни кванта. В противен случай се повишава латентността на системата и
е възможно нарушаване на изискванията за работа в реално време.
Използването на Категория 2 се препоръчва при асинхронни прекъсвания с честота по малка от
пет системни времеви кванта. От друга страна, Категория 2 предоставя възможност за
обръщения към системните сервизи на операционната система, функционалност недостъпна
при Категория 1.
По време на разработване на система за реално време, е необходимо изборът на метод за
облужване на прекъсвания да се базира на динамичните характеристики разгледани в § 28.1
20 / 58
_______________________________________________________
Динамичен времеви анализ в системите за реално време.
Прекъсванията се представят като задачи,
чиято цикличност представлява минималния очакван период на активиране напрекъсването.
Контекст
Категория 1
ISR Кат. 1
Задачи Задача Y Задача Y
Диспечер
t
Време за завършване
Контекст
на Задача Y
Категория 2
ISR Кат. 2
ISR
Задачи Задача Y Задача Y
Диспечер Диспечер Диспечер
t
Време за завършване
на Задача Y
фиг. 14 Влияние на прекъсвания Категория 1 и Категория 2 върху потребителски задачи
22. Режими на работа на операционната система за реално време
22.1. Цел на режимите
22.2. Стартиране на системата
22.3. Ограничения при превключване на отделните режими
23. Механизъм за обслужване на системни събития
23.1. Какво представялват събитията
24. Управление на ресурсите в ОСРВ
21 / 58
_______________________________________________________
24.1. Заемане на ресурс
24.2. Освобождаване на ресурс
24.3. Ограничения при заемане на ресурс
24.4. Диспечерът като ресурс
24.5. Основни проблеми със синхронизацията
24.5.1. Инверсия на приоритета на задача
Често срещан проблем е този със синхронизацията, чрез използване на семафори.

Ефектът се изразява в забавяне изпълнението на високо-приоритетни задачи поради
изпълнение на по-ниско приоритетни задачи.
фиг. 15 Инверсия приоритета на задача очакваща ресурс

На фиг. 15 е показан случай на работа на четири задачи – Задач 1 с най-висок приоритет
и съответно Задача 4 с най-нисък приоритет. По време на своята работа, Задача 4 заема
семафор 1 в момент от време t1. В момента t2, настъпва събитие в ОСРВ, което води до
редеспечеризация и задачи 1,2,3, преминават в състояние READY. Задача 4 е прекъсната по
време на заеман семафор 1 и сътветно преминава в състояние READY. След завършване на
работата на системния диспечер – интервал от време t2-t3, се стартира Задача 4, която е с
най висок приоритет от всички в състояние READY. По време на своето изпълнение, тя има
нужда от използване на семафор 1 – t3. В същото време, семафор 1 е зает от прекъсната
Задача 4. Поради невъзможност за продължаване своята работа, Задача 1 преминава в
състояние на изчакване (WAITING) на семафор 1, в момент t4. Последователно за
изпълняват задачите 2,3 и 4 в сътветствие с техния приоритет. По време на своето
изпълнение, Задача 4 освобождава семафор 1 в момент t5, което води до настъпване на
очакваното от Задача 1 събитие, редеспечеризация, и активиране на задача 1. Както се
вижда от фиг. 15, Задача 1 изчаква определно време (t3-t5), изпълнението на по-ниско
приоритетни задача (2 и 3), преди да може да завърши своята работа ОСРВ. Като резултат се
получава инверсия на приоритета на задача 4 – задачи с по нисък приоритет (Задачи 2 и 3)
22 / 58
_______________________________________________________
се изпълняват приоритетно преди задача с по-висок приоритет (Задача 4). Това е в
противоречие с приоритетния принцип на организация на операционната система за реално
време и е нежелан ефект, който трябва да бъде отстранен. За целта е въведен т.н. „Протокол
за таванен приоритет”.
24.5.2. Протокол за таванен приоритет
Целта на мехънизма „протокол за таване приоритет” е премахване на ефекта на „инверсия

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

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

преминават в състояние „RUNNING”, поради факта, че техния приоритет е еднакъв или
по-нисък с активната в момента задача. Като резултат тук се установява, че не е
възможно използването на „принцип за циклична дисциплина при превключвнане на
задачите на Дейкстра!!!”
- В случай, че ресурс заеман от активната задача бъде освободен, то друга задача може да
премине в активно състояние (RUNNING), с цел използване на ресурса. Следователно
освобождаването на ресурс се явява точка на диспечеризация.
Всяка приложна задача на ОСРВ има статично зададен приоритет по време на генерацията
на ОСРВ. Допълнително към основния приоритет, се добавя и допълнителен – таванен
приоритет. Таваният приоритет се асоциира с ресурс, който ще бъде достъпван от
определена група задачи, асициирани с него преди момента на генерация на ОСРВ.
Неговата стойност се определя от най-високия приоритет от всички задачи асоциирани с
този ресурс. Когато задача от асоциираната група с ресурса се активира, нейният основен
приоритет се замества с таванния приоритет, дефиниран за тази група. По този начин, се
гарантира, че задачата няма да бъде изтласкана от друга задача ползваща асоциирания
ресурс. Активната задача не трябва да се самотерминра, да влиза в състояние на изчакване
или в друга точка на редеспечеризация, докато заема съответния ресурс. Когато активната
задача освобождава заемания от нея ресурс, нейният приоритет се намалява до най-високия
таванен приоритет, асоцииран със заеманите от нея в момента ресурси. Ако задачата не
заема други ресурси, то нейният приоритет се връща към основния – дефиниран по време на
генерацията на ОСРВ. По този начин, се опростява резултатния приоритет на активната
потребителската задача в моментите на редеспечеризация. В резултат на въвеждането на
този протокол, времето на забавяне се ограничава до времето на заемане на асоциирания
ресурс от по-нископриоритетна задача.
На фиг. 16 е показана аналогична ситуация, която беше разгледана на фиг. 15, при
използване на протокола за таванен приоритет. В момент t0 на заемане на семафор 1 от
23 / 58
_______________________________________________________
Задача 4, нейният приоритет се повишава до таванния и тя продължава своето изпълнение.
В t1, в системата се появява точка на деспечеризация и Задача 4 е изтласкана от Задача 1,
поради факта, че Задача 1 притежава по-висок приоритет от Задача 4. По време на
изпълнението си Задача 1 има нужда от използването на семафор 1, който е заключен от
прекъснатата Задача 4. Поради невъзможност за продължаване на своята работа, Задача 1
преминава в състояние на изчакване (WAITING) в момент t3. Задача 1 остава в състояние на
изчакване, до момента t4, в който активаната Задача 4, освобождава семафор 1. Този момент
се явява точка на деспечеризация, поради освобождавнето на ресурса семафор 1. Като
резултат се стартира Задача 1, която вече е в състояние да използва семафор 1. Както може
да се забележи момента на изчакване на високо-приоритетната Задача 4 за освобождаване е
по-кратко при използване на принципа на таванният приоритет (фиг. 16), за разлика от
ситуацията, където той не е изполван (фиг. 15). Времето на изчакване за ресурса на високо-
приоритетната Задача 1 е ограничено до времето на използване на ресурс от Задача 4 (фиг.
16). При липса на принципа на таванния приоритет, времето за изчакване се увеличава с
времето за изпълнение на междинните задачи 2 и 3 (фиг. 15).
Време
на Заемане на
изчакване семафор С1
деспечеризация Освобождаване на
Неуспешен опит за
семафор С1
заемане на семафор С1
READY
Задача
1
SUSPENDED RUNNING WAITING RUNNING SUSPENDED
Таванен
RUNNING READY RUNNING
Приоритет
приоритет 4
Задача
2
SUSPENDED READY RUNNING SUSPENDED
Задача
3
SUSPENDED READY RUNNING SUSPENDED
Задача
4
RUNNING READY RUNNING
t0 t1 t2 t3 t4 t5 t
Заемане на
семафор С1
фиг. 16 Работа при използване на протокол за таванен приоритет
24.5.3. Мъртва хватка
Ефектът „Мъртвата хватка” е друг проблем свързан в механизма на синхронизация в

ОСРВ. Той се изразява в невъзможност за изпълнение на потребителска задача, поради
безкрайно очакване на взаимно заети ресурси. За допълно изясняване на проблема е
разгледан следния сценарии по време на работа на ОСРВ – фиг. 17
24 / 58
_______________________________________________________
фиг. 17 Изпадане в състояние „мъртва хватка”

Първоначално се изпълнява Задача 1, като по време на своята работа тя заема Ресурс А. За
по-нататъшното изпълнение на Задача 1 е необходимо наличието на дадено системно
събите. В този момент t0, това събитие все още не е настъпило и Задача 1 преминава в
състояние на изчакването му. Моментут t0 се явява точка на диспечеризация и като
резултат се стартира Задача 2. По време на своето изпълнение, тя заема Ресурс В. В
момент t1 настъпва очакваното събитие от Задача 1 и след диспечеризация в системата,
Задача 1 започва своето изпълнение. Задача 2 е прекъсната със зает Ресурс В. След
възстановяване изпълнението на Задача 1, тя има необходимост от използването на Ресурс
В. В този момент желаният от Задача 1 ресурс е зает от прекъснатата Задача 2 и тя
преустановява своето изпълнение в очакване освобождаване на нужния Ресурс В – момент
t2. Аналогично след стартирането си, Задача 2 се опитва да заеме Ресурс А, който е вече
зает от Задача 1. В резултат двете задачи преминават състояние на очакване
освобождаване на необходим ресурс. Нито една от двете задачи не е освободила
задържания при нея ресурс. Това води до очакване на събитие, което никога няма да
настъпи. Като краен резултат работата на двете задачи е блокирана и те никога няма да
могат да излязат от това състояние, а реализираната функционалност от тези задачи е
спряна.
Това е ефект, който трябва да бъде предотвратен при работата на ОСРВ. Това е възможно,
единствено ако всяка една от задачите не влиза в състояние на изчакване, без да освободи
заемания от нея ресурс.
25. Аларми
25.1. Броячи
25.2. Управление на аларми
26. Вътрешно-системна комуникация
26.1. Обменна информация в задачите
27. Възможностти за опитмизация в ОСРВ
27.1. Споделяне на стек между задачите

25 / 58
_______________________________________________________
28. Възможностти за настройка и диагностика в ОСРВ
Разработката на приложения с ОСРВ изисква няколко итерации на настройка до

достигането на първоначално заложените изисквания към електронната система. Тези
изиксвания обикновено са с противоречив харакетер – едно спрямо друго. От една страна
се цели работа в реално време в съответствие с (1.1). От друга страна, поради силната
ограниченост на системните ресурси е необходимо извършването на определено ниво на
оптимизация на ресурсите. За целта е необходимо създаването на методология за настойка
и диагностика в ОСРВ, която да спомага за адекватната настойка на системата.
Когато се става въпрос за системни за реално време, главната задача е спазването на
дефинираните времеви условия и ограничения към разработваните функционалностти.
Примерена алгоритъм за работа с ОСРВ е представен на фиг. 18.
26 / 58
_______________________________________________________
фиг. 18 Етапи при разработка на система с ОСРВ

Етапът на настройка и диагностика е позициониран в края на етапа на разработката. Целта
е да се проверят всички изисквания зададени в техническата спецификация на
електронната система. За целта обикновено се използва допълнително оборудване –
емулатори, допълнителен диагностичен интерфейс за връзка с персонален компютър.
Много важен етап е стъпката „План на необходимите системни ресурси”. Тук се прави
първоначалната оценка на отделните програмни компоненти и техните изисквания към
системни ресусрси, времеви изисквания и ограничения. На базата на времевите параметри
на отделните компоненти се съставя и план, на необходимите потребителски задачи –
времева цикличност, тип, необходимо стеково пространство. Функционалните изисквания
от спецификацията се допълват с технически изисквания, който ще бъдат физичски
реализирани в системата. На базата на направения план на системните ресурси, се
подготвя и план за настойка, диагностика и системни тестове – кои са системните
параметри който ше бъдат проверени за съответсвие. Най-често това са времевите
27 / 58
_______________________________________________________
параметри на потребителските задачи и използваните от тях ресурси – памет. За
времевите параметри се създава т.н. „Времева карта на задачите”, която служи за
визуализация и анализ на синхронните събития в ОСРВ. Това е и разпределението на
задачите във времето, което ще се използва като входна информция за Мониторинг
диспечеризацията на задачите (§ 28.4.1) и „Профилиране на времевите параметри на
задачите.”( § 28.4.3).
фиг. 19 Примерна времева карта на задачите
На фиг. 19 са показани две времеви карти на система съдържаща четири потребитески

задачи. Първоначално в времевата картата на системата се вкарва задачата с най-висок
приоритет – Задача 1. Последователно се поставят заеманите от нея времеви областти в картата.
Първоначално, времената за изпълнението се базират на субективна оценка на потребителя за
времето на изпълнение на задачите. След като системата е готова за стартиране, е необходимо
да се направи реално оценка на времената чрез профилиране на системата описано в
Профилиране на времевите параметри на задачите.(§28.4.3). В конкретния пример са
разгледани задачи с еднаква стойност на времето за изпълнение - 500µs, с цел опростяване на
примера. Въвеждат се и останалите задачи по нисходящ ред на техния приоритет.
Първоначално, стойностите на алармите, активиращи задачите се залагат с отместване (offset -
O) равно на нула. В определени случай се вижда, че задачата не се активира веднага след
настъпване на нейната аларма. Тя престоява определено време в състояние „READY”, показано
на картата с пунктир. Това се получава от съвпадение на момента на активация – преход
SUSPENDED-READY-RUN, за няколко задачи с различен приоритет. Необходмио е тези
времена да бъдат премахнати, или поне намалени. Това се постига, чрез промяна на началното
отместване за стартиране на времевите аларми, служещи за стартиране на задачите – настройка
алармите на потребителските задачи.
Настойка алармите на потребителските задачи се осъществява отново на базата на
„Времевите карти на задачите”. По аналогичен начин се започва от най-високо приоритетната
задача. След което, се преминава към следващата Задача 2. Започва се преброяването на
необхоимите за стартирането и времеви системни кванти – в конкретния пример 5=5ms. Както
се вижда от времевата карта, по време на петия системен квант, процесорът е зает от по-високо
приоритетната Задача 1, която има непрекъсваем характер на диспечеризация. Следователно
28 / 58
_______________________________________________________
Задача 2 се поставя във следващият свободен системен квант от време – 6. Съответно нейното
първоначално отместване трябва да бъде корегирано. Стойността и се получава като от
текущата позиция се извади стойността на цикъла на задачата (О=6-5=1). Може да се забележи,
че все пак припокриването не може да бъде избегнато напълно – шести квант.
При първоначалния вариант на времевата карта, се забелязва голямо презастъпване в
началния момент на стартиране. Това се избягва, посредством поствяне на начално отместване
на алармите за стартиране на задачите.
28.1. Динамичен времеви анализ в системите за реално време
Системите за реално време постоянно повишават своят размер и сложност.

Същевременно с това е крайно наложително наличието на методи и инструменти за
управлението на тези времеви параметри, през целия жизнен цикъл на системата, започващ от
техническа спецификация, разработка, настойка и диагностика. Имено поради тази причина е
необходимио създаване на методология и теория, която да бъде използвана оценка на
времевите качества в съвременната система за реално време. По специално теорията на
системите за реално време с фиксиран приоритет предоставя възможност за изграждане на
методология за времеви анализ в системите такива системи. Теоритичната постановка за аналис
на системи за реално време с фиксиран приоритет за залегнали в научните трудове на Liu и
Layland. В тяхната теория за първи път се въвежда понятието „Алгоритъм за монотонна
приоритетна диспечеризация” (б.а. „rate monotonic priority assignment scheduling algorithm”) [1].
За синтезиране на аналитични резултати относно програмно поведение в система за реално
време, е необходимо предварително задаване на някой допускания относно средата в която
работи системата. Тези преположения са абсолютно необходими, като е необходим
допълнителен анализ на ефектите от тях.
Допускания:
(А1) Активирането на всички потребителски задачи, за които съществуват крайни срокове за
изпълнение са периодични, с постоянен период на активиране.
(А2) Крайните срокове се обуславят единствено от времето на изпълнение на задачата –
задачата трябва да приключи своето изпълнение преди нейното следващо активиране.
(А3) Отделните задачи са взаимно независими – активирането на дадена задача не зависи от
активация, инициализация или състоянието на друга задача.
(А4) Времето за изпълнение на дадена потребителска задача е постоянно и не се променя във
времето. За задачи със нелинейна структура, това време е най-дългото възможно време за
изпълние от процесора, без да бъде прекъсвана.
(А5) Всяка непериодочна задача в сустемата има специален характер – задача за инициализация
на определена функционалност или така за възстановяване след настъпване на грешка в
системата. За тези задачи няма зададени изисквания за краен срок на изпълнение.
Алогиттъмът за диспечеризация е набор от правила, които определят точния момент за
изпълнение на дадена задача. Алоритъмът за работа в реално време, в настоящата разработка е
базиран на стратегията за диспечеризация с изтласкване и приоритетна диспечеризация. Това
означава, че в случай на активация на задача с по-висок приоритет от текущо изпълняваната, то
активната задача в момента се прекъсва, и по-високо приоритетната се активира. Алгоритъм за
диспечеризация се казва, че е статичен, ако приоритетите на задачите са твърдо зададени преди
старта на системата и не се променят по време на работа на системата. Този алгоритъм е
известен още и като „Алгоритъм за диспечеризация с фиксиран приоритет на задачите”[1].
Алгоритъм за диспечеризация, който допуска смяна на приоритета на една задача в две
последователни нейни активирания се нарича „алгоритъм за диспечеризция от смесен тип”[1].
29 / 58
_______________________________________________________
28.1.1. Алгоритъм за диспечеризация с фиксиран приоритет на
задачите
В тази глава се синтезират правила за задаване на приоритет, с цел опитмално натоварване на

система работеща под управлението на статичен алгоритъм за диспечеризация. Важен момент в
синтеза е т.н. „критична инстанция”[1] на потребителската задача. Крайният срок за изпълнение
на задача се дефинира като самият период на активация на задачата. „Презастъпване на
изпълнението на задачи”[1], е на лице, когато задачата не може да бъде изпълнена поради
текуща активност на нейна предишна инстанция. Съответно, системата за реално време може да
бъде реализируема ако в нея няма презастъпване на изпълнението на отделните задачи.[1]
Време за отговор на задача се измерва от момента на нейното активиране до момента на
завършване изпълнението и – Tr ( фиг. 2). Критична инстанция на задача представлява тази
инстация, при която времето за отговор е най-голямо[1]. Критична времева зона за дадена
задача представлява времевия интервал между критичната инстанция на задачата и края на
нейното изпълнение, за съответна инстация на задачата.
Както беше споменат по-горе, целта на анализа е синтез на определени правила, за дефиниране
на подходящ приоритет за задачите, с цел оптимална диспечеризация по отношението на
времевите характеристики на системата за реално време.
ТЕОРЕМА 1: Критичната инстанция на дадена задача се получава, когато задачата
е активирана едновременно с всички по-високо приоритетни задачи от нея.
Доказателство: Нека τ 1 , τ 2 , … τ m , е множество от задачи, подредени по приоритетен признак, като

τ m е задачата с най-нисък приоритет, цикличен период на активация T m и време за изпълнение
на задачата C m. Aктивацията на τ m се случва в момент t 1. Ако предположим, че между t 1 и
t 1+Т m, времето през, което следващата активация на задачата на задачата τ m настъпва,
активация за задача τ i , i< m настъпва в момент t 2, t 2+T i , t 2+ 2T i ,… ,t 2+ k T i , както е показано на
фиг. 20. Изтласкването изпълнението на τ m от τ i поражда определно закъснение на завършване
изпълнението на τ m, в момент t 1, освен ако активацията на τ m е завършила преди t 2. На фиг. 20,
се вижда също така, че придвижване напред момента на активация t 2, не би могло да ускори
изпълнението на τ m. Времето за завършване на τ m остава или не променено или забавено от
такава промяна на момента на активация. Следователно най-голямо закъснение на завършване
изпълнението на τ m, е когато t 1 и t 2 съвпадат!
фиг. 20 Изпълнение на τ i между активации на τ m

Като резултат се доказва, че една директна калкулация може да определи дали дадена
съвкупност от приоритизирани задачи може да бъде диспечеризирана или не в съответствие със
съответните и изисквания за реално време. От където може да се заключи - ако активацийте на
всички задачи в една система, съвпаднат с техните критични инстанций, и съответните им
30 / 58
_______________________________________________________
изисквания по отношение на работата в реално време са осигурени, то алгоритъма за тяхната
диспечеризация в реално време е осъществим.
Като пример може да се разгледа система с две задачи τ 1 и τ 2, с циклични периоди T 1=2, T 2=5,
времена за изпълнение C 1=1 и C 2=1. Ако τ 1 е най-високо приоритетната задача, от фиг. 21 а),
се вижда, че диспечеризация с така дефинираните приоритети е реализируема. Освен това е
възможно времето за изпълнение C 2 да бъде увеличено до два пъти, без това да води до
нарушаване на изискваният за работа в реално време - фиг. 21 б). От друга страна повишаване
приоритета на τ 2 над този на τ 1 би довело до ситуация, в която не е възможно увеличаването на
нито едно от двете времена за изпълнение на задачите C 1 и C 2 над 1 - фиг. 21 в).
фиг. 21 Изпълнение на две задачаи
Като резултат от Теорема 1, налице е и условие за задаване на оптималния приоритет на

задачите. Необходимо е генерализиране на резултатите от диспечеризация на две
потребителски задачи по отношение на техните параметри за работа в реално време – (С, Т и
приоритет). Нека Т 1 и Т 2 са съответните циклични периоди за активация на две потребителски
задачи τ 1 и τ 2, като Т 1<Т 2. Ако τ 1 е по-високо приоритетната задача, използвайки Теорема 1, е
необходимо следното неравенство да бъде спазено:
Т2
Т1‖.C 1+ C2 ≤T 2 1.3 †‡
†
Условието е необходимо, но не и достатъчно диспечеризацията в реално време да бъде
реализируема.
‡
(а)‖ – е представяне за най-голямото цяло число по-малко или равно на „а”, ‖(а) - е представяне за
най-малкото цяло число по-голямо от „а”.
31 / 58
_______________________________________________________
Ci
, където е времето за което задачата – i се изпълнява в един нейн цикличен период T i, a
Ti
Тj
Тi‖ . Ci е времето за изпълнение i-та задача с цикличност на активация T i, в рамките на период
T j , като T j >T i.
В случай, че τ 1 е по-високо приоритетната задача, то следното неравенство трябва да бъде
вярно:
C 1+C 2 ≤T 1 1.4
Като умножим двете страни с неотрицателния множител

Т2
Т1‖, се получава:
Т2
Т1‖.C 1+
Т2
Т1 ‖
. C2≤
Т2
Т1
.T1
‖
От друга страна като се има в предвид че:
Т2
Т1 ‖
.T 1 ≤ T 2
, тогава:
Т2
Т1‖.C 1+
Т2
Т1 ‖
. C2≤
Т2
Т1 ‖
. T 1≤ T2
1.1
С други думи когато Т 1<Т 2, τ 2 е по-високо приоритетна задача от τ 1 и C 1 и C 2 имат такива

стойностти, при които диспечеризация на τ 2 и τ 1 е реализируема в реално време, то когато τ 1 е
по-високо приоритетна задача, системата притежава реализируем алгоритъм за диспечеризация
в реално време. Но обратното твърдение не е вярно! Поради тази причина е необходимо
задаването на по-висок приоритет на τ 1 в сравнение с τ 2. Следователно твърдението, че трябва
задачите с по-висока честота на активация да имат по-висок приоритет, независимо от времето
им за изпълнение е основателно! Това условие за задаване на приоритета на задачите в
системите за реално време е известно като „Честотно-монотонно задаване на приоритета” [1].
Може да се заключи, че ако една дадено множество от потребителски задачи с честотно-
монотонно задаване на приоритета не може да бъде диспечеризирано в реално време, то не
съществува друг алгоритъм, който да направи диспечеризацията в реално време на това
множество от задачи реализируемо.
ТЕОРЕМА 2 : Ако за дадено множество от потребителски задачи, съществува такова
задаване на приоритета им, така че системата е диспечеризируема в реално време, то
честотно-монотонно задаване на приоритета е също реализируемо за това множество.
Доказателство: Нека τ 1 , τ 2 , … τ m , е множество от m-на брой задачи с зададени приоритети така,

че системата може да се диспечеризира в реално време. Нека двойката задачи τ i и τ j са с два
съседни приоритета в това множество, като τ i е по-високо приоритетната от двете.
Предполагаме също, че T i> T j. Ако след това разменим приоритетите, се вижда, че резултатното
32 / 58
_______________________________________________________
множество е диспечечизуемо в реално време. Това се получава от факта, че честотно-
монотонно задаване на приоритета може да бъде получено чрез последователно пренареждане
на приоритета на всяка съседна двойка от множеството задачи (както беше показано
математически по-горе)[1].
28.1.2. Горна граница на натоварването на процесора при системи за

работа в реално време
Факторът на натоварване на процесора представлява частта от цялото процесорно време

изразходвано в изпълнение на потребителски задачи. По друг начин,той представлява единица
минус времето в което няма активиране, респективно изпълнение на потребителска задача.
След като C i /T i e частта от процесорното време за изпълнение на i-задача, то за m на брой
задачи имаме следното равенство:
m
Ci
U =∑ 1.2
i=1 Ti
Въпреки, че е възможно факторът на натоварване на процесора да бъде повишен, посредством
увеличаване на стойностите на C i или намаляване на T i, горната граница на този фактор е
ограничена от изискването за работа в реално време – времето за отговор на всяка задача да не
надвишава предварително дефинираното, когато задачата се намира в своя критична инстанция.
Въпросът – какъв е максималният праг на натоварване на процесорът остава актуален.
Необходимо е прецизиране на задачата. За едно множество от задачи се казва, че то напълно
използва предоставеното процесорно време, ако зададените приоритети на задачите в това
множество позволяват неговата диспечеризация в реално време и допълнително увеличаване на
времето за изпълнение на някоя от задачите прави това множество не диспечеризуемо в реално
време. Тази граница, при която системата е диспечеризируема в реално време се нарича граница
на оползотворяване на процесора. За всички множества от задачи, за които тяхната граница на
оползотворяване на процесора е под тази граница, съществува алгоритъм на диспечеризация в
реално време.
След като алгоритъмът на диспечеризация с монотонно зададени приоритети е оптималния
алгоритъм, то факторът на оползотворяване на процесора при него е по-голям или равен на
всеки друг алгоритъм с различно задаване на приоритетите. Следователно, използването на
фактора за оползотворяване на процесора при алгоритъм с монотонно задаване на приоритета
като референтна стойност при анализ е аргументирано.
Първоначално, това правило ще бъде разгледано за две задачи, след което то ще бъде
генерализирано за по-голям брой задачи:
ТЕОРЕМА 2 : За множество от две задачи с фиксиран приоритет, границата на
оползотворяване на процесора, без да бъдат нарушени изискванията за диспечеризация в реално
1
време е U =2(2 2 −1).
Доказателство: Нека τ 1 и τ 2 са две задачи, с период на активация съответно Т 1 и Т 2, а

съответните им времена за изпълнение са C 1 и C 2. Предполагаме, че Т 1<Т 2. В съответствие с
изискванията на алгоритъма на монотонно зададените приоритети τ 1 притежава по-висок
приоритет от τ 2. В критично-времевата зона на τ 2, съществуват
‖Т 2 /Т 1 искания за активация на τ 1 от диспечера в системата. Нека C 2 има такава стойност, че
33 / 58
_______________________________________________________
оползотворяването на процесора е пълно по време на критичната времева зона. Като следствие
са възможни са два случая:
Случай 1: Времето за изпълнение на задача τ 1 - C 1 е достатъчно кратко, за да може всички

активации на τ 1 в времевата критична зона на T 2 завършват преди следващата активация на τ 2 -
фиг. 22:
фиг. 22 Изпълнение на τ 1 и τ 2 - случай 1
C 1 ≤ T 2−T 1.
T2
T1 ‖
Следователно, най-голямата стойност за C 2 е:
C 2=T 2−C1.
‖ T2
T1
Съответният фактор на оползотворяване на процесора е:
T 2−C 1.
‖ T2
T1
[ ‖ ]
2
Ci C1 C2 C1 1 1 T2
U =∑ = + = + =1+ C1. . − .
i=1 Ti T 1 T 2 T 1 T2 T1 T2 T 1
В този случай, U е монотонно намаляващо с C 1, заради отрицателния му множител.
Случай 2: Изпълнението на ‖ T2
T1
-та заявка за изпълнение наτ 1 се презастъпва със следващата
заявка за изпълнение на τ 2 , поради повишено изпълнение на τ 1 - фиг. 23
фиг. 23 Изпълнение на τ 1 и τ 2 - случай 1

В този случай имаме условиято за случай 2:
34 / 58
_______________________________________________________
C 1 ≥ T 2 −T 1.
T2
T1 ‖
Следователно най-голямата възможна стойност на C 2 е:
C 2=T 1.
T2
T1 ‖
−C1.
T2
T1 ‖
Съответният фактор на оползотворяване на процесора е :
T 1.
T2
−C 1.
‖T2
‖
T1 T1
‖ [ ‖]
2
Ci C1 C2 C1 T1 T2 1 1 T
U =∑ = + = + = . +C 1 − . 2
i=1 Ti T 1 T 2 T 1 T2 T2 T1 T1 T2 T1
Минималната стойност на U, се получава на границата между тези случая:
C 1=T 2 −Т 1.
T2
T1 ‖
, от където се получава:
U =1−
Т1
Т2 [‖ T2 Т 2 Т 2 T 2
− −
T1 Т 1 Т 1 T 1 ][ ‖] 1.3
Полагаме
A=
T2
T1 ‖и дробната част на
Т2
Т1
Т2 T 2
както следва B = −
Т1 T 1
: ‖
U =1−B ( 1−B
A +B )
Поради факта, че U е монотонно нарастващо с A, то минимумът на функцията се постига при

най-малката възможна стойност на А (положително цяло число)=1. Необходимо е да намерим
минимума на функцията :
U =1−B ( 1−B
1+B )
Първата производна на U e U’:

2
' B + B+1
U= 2
B + 2 B+1
, от където следва че за решенията на квадратното уравнение, функцията U има локални
ексремуми:
2
B +B+ 1=0
След изследване на функцията U се установява, че при B=√ 2−1 функцията U има минимум:
35 / 58
_______________________________________________________
U =2 (2 −1) ≈ 0 , 83
1
2
С което теорема 2 е доказана.

Интересно е да се отбележи, че факторът на заемане на процесорът може да достигне стойност
1 – 100% заемане на процесора
U =1=1−B ( 1−B
1+ B )
, когато B = 0, или
Т2 T 2
−
Т1 T 1 ‖
=0 , т.е. по-продължителният период T 2 кратен на по-краткия T 1.
ТЕОРЕМА 3 : За дадено множество от m-задачи с фиксиран ред на приоритета, и отношение

между периодите на всеки две от тях по-малко от две, то горната граница на заемане на
процесора е U =m ( 21 /m −1 )
Доказателство: Нека τ 1 , τ 2 , τ 3 , … τ m е множеството от m-на брой задачи. Нека C 1 , C 2, C 3 , …C m са

времената за изпълнение на съотвените задачи, които замат напълно процесорното време.
Приемаме, че Т m >T m−1, >…>T 2 >T 1. Крайната цел е да се покаже, че :
C 1=T 2 −Т 1
фиг. 24 Максимална продължителност на задача

, т.е. изпълнението на дадена задача не се презастъпва с изпълнението на следващата
активирана - фиг. 24.
Ако предположим, че
C 1=T 2 −Т 1 +∆ , ∆>0
То нека
'
C 1=T 2 −Т 1
36 / 58
_______________________________________________________
'
C 2=C2 + ∆
'
C 3=C 3
…
'
C m−1=C m−1
'
C m=C m
Очевидно е, че множеството C '1 , C '2 , C'3 , … , C'm −1 , C'm също заема цялото процесорно време. Ако
съответният фактор на заемане на процесора е U’, се получава:
U −U ' = ( )( )
∆
T1
−
∆
T2
>0
Ако алтернативно се предположи, че

C 1=T 2 −Т 1−∆ , ∆> 0
Нека
''
C 1 =T 2−Т 1
''
C 2 =C 2−2 ∆
''
C 3 =C 3
…
''
C m−1=C m−1
''
C m=C m
И отново множеството C ''1 ,C '2' , C'3' ,… ,C 'm−1

' ''
,C m също заема цялото процесорно време, а U’’ е
съответният фактор на заемане на процесора, се получава:
''
U −U =−
( T∆ )+( 2T∆ )> 0
1 2
Ето защо, ако U минималния фактор на заемане на процесора, тогава:

C 1=T 2 −Т 1
По подобен начин може да се докаже, че

C 2=T 3 −Т 2
C 3=T 4−Т 3
…
C m−1=T m−Т m−1
37 / 58
_______________________________________________________
Като следствие се получава:
C m=T m−2(C 1 +C 2+ …+Cm −1 )
Ако се положи gi=( T m −T i ) /T i, i=1,2,…,(m-1) следва:
C i=T i+1−T i=gi .T i−gi +1 . T i+1 ,i=1 , 2 ,3 , … (m−1)
C m=T m−2 g1 .T 1
От където се получава:
[ ( )] ( )
m
C i m−1 T T
U =∑ =∑ gi−g i+1 i +1 +1−¿ 2 g1 1 ¿ =
i=1 T i i=1 Ti Tm
[ ) ]
gi +1 ( g i+1 )
[ ]
m−1
g1
= ∑ gi − +1−2 =¿
i=1 ( gi +1+ 1 g1 +1
¿ 1+
g 1 (g 1−1) m−1
g1 +1
+ ∑ gi .
i=1 [
( g i−gi−1 )
( gi +1 ) ] 1.4
Аналогично на предишния случай, с двете задачаи, факторът получава стойност равна на

единица ако gi = 0, за всички i. За да се намери границата на фактора на заемане на процесора,
уравнението 1.4, трябва да има минимална стойност. В конкретния случай, това може да се
постигне чрез заместване в първата производна на U, като се има в предвид, че gi=0 за всяко i,
решавайки следното диференциално уравнение:
∂ U ( g i + 2 gi −g i−1)
2
g
= − i+1 =0 ,
∂ gi ( gi +1 )
2
g i+1 +1 1.5
i=1 , 2 ,3 , … ,(m−1)
Дефиницията g0=1, е възориета за удобство:
( m−i
m ) 1.6
gi=2 −1 , i=0 , 1 ,2 , … ,(m−1)
От където следва, че:
U =m(2 ¿ ¿ ( m1 )−1)¿
, което предствлява и връзката, която искахме да докажем
38 / 58
_______________________________________________________
За две задачи се получава:
( )
1
1
U m =2 =m(2 ¿ ¿ −1)=2(2 2 −1)¿
m
, което вече доказахме.

За голям брой от задачи се получава:
lim U = lim ¿ ¿
m→∞ m →∞
Ограничението, което беше наложено в Теорема 4 – отношението между периодите на

активация между кои да е две задачи да не надвишава 2, може да бъде премахнато.
Теорема 5: За множество от задачи, с фиксиран ред на приоритета, най-малката горна граница
на заемане на процесора се дава от формулата :
U =m(2 ¿ ¿ ( m1 )−1)¿
Доказателство: Нека τ 1 , τ 2 , τ 3 , … τ m е множество от задачи, които заемат напълно неговото
процесорно време – с фактор U. Допуска се, че за всяко i ,

Tm
Ti ‖
>1. И по точно нека
Т m=q Т i +r , q>1 и r ≥ 0
Нека заместим задача τ i със задача τ 'i , така че, Т 'i=q . T i и C 'i=Ci , а C m заеме такава стойност, с
която процесорното време е напълно заето. Това увеличение е най-осезаемо в C i (q−1) –
времето на критичната времева зона τ m, заето от τ i , но не от τ 'i . За изчислението на фактора на
заемане на процесора се получава:
'
U <U +
[ Tm ]
C i .(q−1) C i C i
+ '−
Ti Ti
Или
U ' <U +C i . (q−1)

[ 1
−
1
q . T i +r q . T i ]
1 1 '
От както q-1>0 и − ≤ 0 ,то U <U .
q . T i +r q . T i
28.1.3. Анализ и методология за изчисляване на най-лош случай за

реакция на системата
Времето за реакция на системата е основе параметър на системата за реално време. Както е

показано на фиг. 2, това време t d не трябва да бъде надвишено при изготвяне на реакциата на
39 / 58
_______________________________________________________
системата. В противен случай, системата губи свойта основна характеристика – работа в реално
време.
Поради тази причина е необходимо провеждането на анализ в ранен етап от проектирането на
системата, като тази характеристика се поддържа през целия жизнен цикъл на системата. За
целта е необходимо синтезиране на методология, с чиято помощ дабъдат изчислени времевите
параметри на системата и на тяхна база да се проведе необходимия динамичен анализ.
По време на анализа, се използват най-лошите възможни времеви характеристики на системата.
По този начин се гарантира работа на системата вреално време, при екстремални условия.
Поради факта, че системата е изградена от потребителски задачи, то първият необходим
параметър е най-дългата реакция на всяка една задача в системата - Ri , където i е съответния
номерна задачата. Времето за реакция на една задача включва времето от момента на
активиране на задачата – преход към сустояние RUN - фиг. 10, до момента на завършванена
нейното изпълнение. Отделните преходи между състоянията на задачите са показани на фиг. 25.
Показани са двата възможни прехода към състояние READY, съответно WAINTING – READY
за расширените задачи и SUSPENDED-READY за базовите задачи. Моментът t r - е така
нареченият момент на освобождаване на задачата – настъпване на условието за активиране на
задачата. Това може да е изтичане на аларма за активация на задача, при периодични задачи
или настъпване на очаквано събитие за апериодични (асинхронни) задачи. В този момент
задачата се добавя в опашката на задачите готови за изпълнение, на позиция, съответстваща на
нейния приоритет в системата. Следващият момент в рамките на периода за реакция на
задачата, това е t a - стартиране на задачата. В този момент, задачата започва своето изпълнение
– изготвяне на нейната реакция в системата. Всяка една задача се характеризира с параметър –
максимално време, необходимо за изготвяне на реакцията C i – известно още като „максимално
време за изпълнение на задачата” [1]. След края на своето изпълнение, задчата преминава в
пасивно състояние “SUSPENDED”, до настъпването на следващата и активация.
фиг. 25 Време за реакция на потребителска задача
Времето от t r до t d, характеризира максималното време за изготвяне на реакция от

потребителска задача – параметърът, обект на настоящия анализ. Друг параметър използван по
време на анализа, това е времето на изчакване за активиране на задачата - Ri между двата
момента t r и t a.
40 / 58
_______________________________________________________
По време на анализът, времето за диспечеризация – смяна на състоянието на задачите е
пренебрегнато, с цел улесняване на анализа. От друга страна, това време е съизмеримо малко с
останалите времена използвани в анализа, като допълнителен аргумент за пренебрегването му.
На база на фиг. 25 и изложеното до момента, може да се запише следното уравнение за
максималното време за реакция на потребителска задача в система за реално време:
Ri=W i+ Ci 1.7
Тук е удачно да се направи междинен анализ на отделните членове на равенстовото, по
отношение на вида диспечеризация в системата (виж. §2.2.2 Видове диспечеризация), както и
типа на задачите изграждащи системата за реално време (виж. §1.2 Потребителска задача).
Първоначално се разглежда параметърът W i . Този параметър характеризира времето, през
което, задачата има всички необходими ресурси за стартиране в системата, с изключение на
процесора. Тя е в състояние READY (виж. §1.2.1 Граф на състояния на задачите), намира се в
опашката на готовите за изпълнение задачи и се конкурира за процесорно време с останалите в
опашката задачи. Конкурирането за процесорно време е единствено на база приоритет на
задачата. Следователно типът на задачата – базова или разширена, не оказва влияние върху W i .
Също така трябва да се отбележи, че типът на диспечеризацията (виж. §2.2.2 Видове
диспечеризация), също не влияе върху W i , поради факта, че диспечеризацията влияе само върху
времето за изпълнение на задачата, когато тя е активна – състояние READY. От друга страна, в
случайте, когато разглежданата задача преминава в състояние READY, но точно преди този
преход е активирана задача с по нисък приоритет, е възможно увеличаване на Ri ако тази задача
е от непрекъсваем тип. Следователно параметърът Ri е инвариантен от типа на задачата – базова
или разширена, но зависи от типа на диспечеризация на по-ниско приоритетните задачи от
текущо анализираната задача. На фиг. 26 са показани двата възможни случай:
случай 1: предварително активираната по-ниско приоритетна задача е с непрекъсваем характер
на диспечеризация;
случай 2: предварително активираната по-ниско приоритетна задача с прекъсваем характер на
диспечеризация.
41 / 58
_______________________________________________________
фиг. 26 Влияние на ниско приоритетните задачи върху високо приоритетните задачи

Следователно анализът за най-продължително време за реакция на потребитеска задача трябва
да вземе в предвид двата възможни варианта.
Вторият член на уравнението е C i – максимално време за изпълнение на потребителската
задача. Този параметър може да бъде повлиян от конкретната реализация на алгоритъма за
диспечеризация на съответната задача – прекъсваем или непрекъсваем от една страна. В случай
на прекъсваем характер, е възможно неколко кратно прекъсване на задачата от по-високо
приоритетни задачи, което води до увеличаване на C i, а от там и на Ri - фиг. 27. Като резултат е
възможно нарушаване на параметрите на системата за реално време, а към времето за реакция
на задача 2 се добавя и времето за изпълнение на по-восоко приоритетната задача 1 - фиг. 27.
' ''
R2=C 2 +C 2 +C1
42 / 58
_______________________________________________________
фиг. 27 Влияние на високо приоритетни задачи при прексваем характер на диспечеризация

В релузтат на направените – по-горе разсъждения, е нобходимо отчитането на факторите на
влияние както на по ниско приоритетните задачи, така и на по високо приоритетните задачи
при прекъсваем характер. Формулат 1.7, се преобразува в следния вид:
Ri=C i + Bi+ I i 1.8
, където - C i - е физическото време за изпълнение на i-та задача, Bi отразява влиянието на по
ниско приоритетните задачи върху времето на реакция на i-тата задача - фиг. 26, а I i е
влиянието на по-високо приоритетните задачи върхи времето на реакция на i-тата задача.
Членът Bi на равенството (1.8) представлява най дългото времето за изпълнение на по-ниско
приоритетна задача. За множество от задачи τ n, n>0, подредени във възходящ ред на свойте
приоритети, и разглеждана задача T i, където 0<i<n, подмножестовто от задачи lp(i) на по-
ниско приоритетнио от T i обуславят параметъра Bi:
Bi=max (C l) 1.9
l ∈lp(i)
,т.е. Bi предствлява най-дългото време за изпълнение на задача с по-нисък приоритет от T i

Подмножеството от задачи hp (i) - с по-висок приоритет от i-тата задача обулсвят параметъра I i,
при диспечеризация с прекъсване на T i. С други думи, това са всички задачи от подмножество
hp (i), с по-висок приоритет от T i , които могат да прекъсват, а от и даувеличават времето за
реакция на T i за период от време Ri :
‖
hp (i)
Ri
I i= ∑ .C 1.10
j=i +1 Tj j
След заместване на (1.9) и (1.10) в (1.8), се получава:
‖
hp (i)
Ri
Ri=C i + max (C j)+ ∑ .C 1.11
j ∈lp(i) j =i +1 Tj j
43 / 58
_______________________________________________________
Решението на уравнението (1.11) се получава посредством рекурсивен алгоритъм – най-малкото
Ri решение на (1.11) е най-дългото време за реакция на T i. За рекурсивното уравнение се
запосват последователностите:
0
mi =C i
‖
hp(i) n
mi
=Ci + max (C l)+ ∑
n+1
m i .C 1.12
l ∈lp(i) j=i+1 Tj j
Реркурсивният алгоритъмът представен посрдством псевдо-код:

for i∈1 … N
n ≔0
n
mi =C i
loop
n+1
Изчисляване на нов mi от уравнението
n +1 n
if mi =mi then
n
Ri :=mi
exit {намерена стойност за Ri }
end if
n +1
if mi >T i
exit { не е намерена стойност за Ri }
end if
n ≔n+1
end loop
end loop
Редът (1.12) е монотонно увеличаващ се. Ако mn+1i = mni , то това е и най-малкото неотрицателно
решение на (1.11) - Ri=mni . Съответно ако Ri > Di , където Di е крайният срок за изготвяне на
реакцията на задачата T i, условията заработа в реално време на T i са нарушение и казваме, че
системата не е диспечеризуема в реално време!
28.2. Диагностични куки на ОСРВ
Диагностичните куки в ОСРВ, представляват интерфейсни функции, които служат за

времеизмерване на определени фрагменти от операционната система за реално време.
Предстартовата кука (б.а. PRETASKHOOK) представлява епилогът при стартиране на задачата
от системния диспечер. Тя представлява функция, която се извиква преди физическото
стартиране на потребителската задача. Чрез нея потребителят има възможността за отбелязване
началото на всяка една задача в системата.
44 / 58
_______________________________________________________
28.3. Мониторинг на стека
28.3.1. Методи за монитиране на размера на стековите области
Настоящата разработка притежава възможност за мониторинг на стековите пространства

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

Изпълняваният обект презаписва част от следващата стекова област (стек 3) със свой
данни (от Стек 2 ), което е предпоставка за недифинирано поведение на притежателя на
стек 3. Необходимо разширяването на стекова област 2, за да е възможно съвместната
работа на двата обекта (потребителски задачи), притежаващи респективно Стек 2 и Стек
3. Неизбежно възникава и друг въпрос – „Колко трябва да бъде заделената стекова област,
зада може да бъде избегнато презастъпването на стековите области, като това неводи до
заделяне на ненужно голяма стекова област?” - фиг. 29. Този въпрос е съвсем резонен, с
оглед на ограничените ресурси на вградените системи и в от функционални изисквания
към тях. Както е показано на фиг. 29 в възможно и ненужно „разхищение” на памет,
поради заделяне на ненужно голям масив от стекова памет – т.н. „Мъртъв стеков
сегмент”.
45 / 58
_______________________________________________________
фиг. 29 Неизползване на стеков масив

За анализиране на двата споменати по-горе проблема, разработената система притежава
възможност за мониторинг на размера на стековите области. Методът се изразява в
предварително маркиране на стековия масив с предварително задеден шаблон – байт 0xA5
- фиг. 30.
фиг. 30 Мониторинг на стека посредством байтов шаблон

След първоначалното установяване на системата – ресет, като част от
инициализационните процедури на ОСРВ, стековите области се запълват с предварително
зададен байтов шаблон (0xA5). По време на работа на ОСРВ, сътветният обект, ползващ
стека записва данни в него. Във всеки един момент, е възможно да се разбере колко е
максималното количество памет, реално използвано в заделения стек. Областта
съдържаща първоначално записания шаблон до края на стека се третира като
нейзползвана.
46 / 58
_______________________________________________________
Анализът на стековото пространство обикновено се извършва на базата на силно
натоварващ тест (б.р. eng “Stress test”). Целта на теста е навлизане на максимална
дъбочина на изпълнявания обект, което води и до максимлна големина на използвания
стек. За една силно асинхронна среда е трудно да се конструира тест напълно натоварващ
сътвения обект на ОСРВ. Следователно не винаги е възможно да се получи реална
информация за максималния размер на използваня стек. С цел постигане на максимална
сигурност, посредством елиминиране на възможността за презастъпване на стековото
пространство, в настоящата разработка има създаден и допълнителен предпазен
механизъм. Той се състои от добавяне на допълнителни шаблони на границата на
стековото пространство - фиг. 31 а).
фиг. 31 Маркиране край на стека посредством „воден знак”

Процедурата по поставяне на „водния знак” (0xFE) се извършва аналогично на тази с
шаблона (0xA5). По време на работа на система, е възможно „водният знак”:
- да не бъде презаписан (фиг. 31 б)) – стойността на „водния знак” съвпада с очакваната

стойност (0xFE), стековият масив не се препълва по време на изпълнение на съответния
обект;
- е презаписан (фиг. 31 в))– стойността на „водния знак” е презаписана (0xFE ≠ 0xF1),

стековият масив е препълнен по време на работа на сътветния обект и има опастност от
презастъпване.
Удачно решение при детектиране на препълване на стека, ОСРВ да извърши определена
реакция, с цел не позволяване на изпълнение на обкта, с презастъпен стек. Реализацията в
текущата ОСРВ е представена на фиг. 32 с хронологична диаграма.
47 / 58
_______________________________________________________
sd StackCheck
Дис печер Задача 1 Задача N
Активаране на задача()
Изпълнение на задачата()
Терминиране на задачата()
alt Проверка на стека
[воден знак == 0xFE] Активиране на задача()
[else]
Запис на грешка()
Сис темен рес ет()
фиг. 32 Хронологична диаграма – проверка на „воден знак”

След завършването изпълнението на задача, диспечерът проверява коректността на нейния
воден знак. В случай, че той е некоректен, диспечерът генрерира ресет на системата.
28.4. Анализ на времевите параметри на ОСРВ
28.4.1. Мониторинг диспечеризацията на задачите
Системата за реално време е тази ситема, чи ято реакция, по отношение на външно

или вътрешно системно събитие е изготвена и изпълнена в рамките на дефиниран период от
време - фиг. 2. Поради тази причина е необходимо наличието на механизъм за мониторинг
изпълнението на потребителските задачи в системата. Този мониторинг има за цел да
установи навременното активиране на задачите в системата. Ако някоя от задачите от тип
непрекъсвама (с кооперативно диспечеризиране), отнеме прекалено дълго време засвоето
изпълнение, това неминуемо, ще доведе до закъснение при стартирането на следващата
готова за изпълнение. Подобен случай е показан на фиг. 33. В разгледания времеви прозорец
се изпълняват два вида задачи, с непрекъсваем характер, с цикличност на изпълнение
съотвенто 2 и 5 ms. Времето t d, представлява времето за реакция на задачата, или това е
времето за преминаване от състояние SUSPENDED в активно състояние RUN. Както може
да се види на фиг. 33. Второто изпълнение на 2ms задачата продължава по-дълго от
обикновеното. По време на това изпълнения на 2ms задача, изтича и аларма с период 5ms,
която трябва да активира 5ms задача. Поради непрекъсваемият характера на 2ms задача, 5ms
задачата не може да бъде активирана и тя изчаква в състояние READY.
48 / 58
_______________________________________________________
фиг. 33 Нарушаване на времето за реакция - td

Престояване на задачата в състояния READY по-дълго от предварително дефинирано,
говори за загуба на възможността за работа на системата в реално време и е необходимо
да бъде предовратено. Поради тази причина, в настоящата разработка има модул наречен
TimeScheduleManager, отговарящ за мониторинга на изпълнение на задачите, както и за
поведението на цялата система при установяване на закъснение. По своята същност
TimeScheduleManager преставлява потребителска задача с най-висок приориотет - фиг. 34.
49 / 58
_______________________________________________________
sd TimeScheduleManager
Сис темен Дис печер Задача 1 Задача 2 TimeScheduleManager

Час овник
Аларма 1()
Активиране на задача()
Изпълнение()
Рапорт за край()
Терминиране()
Аларма 2()
Изпълнение()
Рапорт на край()
Мониторна Аларма()
Проверка на времената()
alt Проверка на времената

[td<trmax]
[else]
Реакция при закъснение()
фиг. 34 Работа на времевия монитор – TimeScheduleManager
След като завърши изпълнението си потребителската задача докладва на

TimeScheduleManager. Този рапорт се изразява в манипулация на броячи, представени
като променливи в TimeScheduleManager. За задачите, които цикличният период на
изпълнение е по-голям от този на TimeScheduleManager доклада се изразява в
инкрементиране на съотвения за задачата брояч. За тези задачи с по-малък цикличен
период от този на TimeScheduleManager доклада представлява декрементиране на брояч.
От своя страна TimeScheduleManager притежава рефернта константа таблица, с която
сравнява резултатите получени по време на изпълнение. Когато се получи разминаване
между очаквани и получени резултати от броячите е налице закъснение на някоя от
задачите, и работата на системата в реално време не е гарантирана.
50 / 58
_______________________________________________________
Цикличен период
Референтна
Задача Брояч на акривираща Обяснение
стойност
аларма
За 6 активации на монитора
Задача 1 Инкрементиращ 50ms 6 се очаква един доклад от
задачата.
Между две активации на

Задача 2 Декрементиращ 2ms -4 монитора се очакват 4
доклада от задачата
За 3 активации на монитора
Задача 3 Инкрементиращ 20ms 3 се очаква един доклад от
задачата.
TimeScheduleManager - 10ms - -
Таблица 2 Примерна конфигурация за TSM
Времевият мониторинг на потребителски задачи е възможен за всички от тях, за които се

знае, че трябва да бъдат активирани на през точно определени периоди от време. За
разширените задаичи (Extended), мониторингът не е възможен поради причината, че тяхното
активиране се осъществява от непериодично асинхронно събитие.
С цел допълнителна сигурност на системата е необходимо да се осигури и мониторинг на
самия TimeScheduleManager. Това се осъществява на базата на допълнителна аларма. Тя сслужи
за рефернтно време в TimeScheduleManager и има за цел да провери дали самият той не изоства.
При всяко активиране на алармата се нотифицира TSM, посредством вдигане на вътрешен флаг.
Когот TSM се активира, съотно той нулира флага. В случай че между две нотификаций на
системния часовник, флагът е вдигнат, следва, че TSM е закъснял със своето изпълнение и е
необходимо да бъде извършена съответната реакция.
51 / 58
_______________________________________________________
sd Мониторинг на TSM
Системен Диспечер TimeScheduleManager

Часовник
Времева
нотификация()
Аларма TSM()
Период, през който Има забавяне на изпълнението
TSM трябва да бъде на TSM - две последователни
активиран поне нотификации от системния
веднъж. Изпълнение() часовник, без активиране на
TSM.
Нулиране на флага()
Времева нотификация()
alt Проверка по време

[Активен флаг]
Реакция поради закъснение()
[else]
фиг. 35 Само-мониторинг на TimeScheduleManager
Както беше вече споменато, при наличие на закъснение изпълнението на потребителска

задача или времевия моноторен компонен – TSM, необходимо системата да извърши
определена реакция. В настоящата разработка, реакцията е реализирана на базата на Watch Dog
Timer (WDT). TSM е централизираният компонент за нулиране на WDT - фиг. 36.
фиг. 36 Защитен механизъм на ОСРВ с WDT
52 / 58
_______________________________________________________
WDT се нулира единствено ако задачите и TSM се изпълняват без закъснение. В
противен случай, WDT спира да се нулира, което от своя страна води до ресет на
системата. От гледна точка на ОСРВ, TSM може да се разглежда като съвкупност от
няколко виртуални WDT. Всеки един от тези виртуални WDM притежава възможност за
индивидуална настройка на периода на препълване, в съответствие с наложените времеви
изисквания към отделните задача. От архитектурна гледна точка облужването на WDT от
един централизиран компонент е правило и не трябва да бъде нарушавано. Следователно
недопустимо е, потребителските задачи да извършват манипулации върху WDT
28.4.2. Анализ и детерминиране на максималната честота на

системните прекъсвания
28.4.3. Профилиране на времевите параметри на задачите.
28.5. Анализ и статистика на използваните апаратни ресурси
28.6. Видове грешки в ОСРВ и тяхното обслужване
29. Стандартизацияна използваните типове променливи и константи в ОСРВ
29.1. Общи типове на променливите
29.1.1. Диспечер
29.1.2. Задачи
29.1.3. Системни събитя
29.1.4. Ресурси
29.1.5. Аларми
29.1.6. Системни прекъсвания
29.1.7. Диагностични куки
30. Стандартизацияна системните функции в ОСРВ
30.1. Системни макроси
30.2. Ограничения при използването на системни функции
31. Преносимост на ОСРВ
31.1. Поддържание апаратни архитектури
31.1.1. Texas Instruments MSP430
31.1.2. ARM ядра
31.2. Класификация на отделните структурни единици в ОСРВ по

отношение на тяхната апаратна преносимост
53 / 58
_______________________________________________________
31.2.1. Апаратно зависими звена
31.2.2. Апаратно независими звена
31.2.3. Необходими конфигурации на апаратно зависимите звена
31.2.4. Генерация на ОСРВ
32. Методология за разработване на система за реално време на базата на ОСРВ
32.1. Основни принципи
32.1.1. Работа с прекъсвания и критични секции
Основен проблем при работата с операционна система е контролорането на прекъсванията

и критичните секции. Проблемите се изразяват конктретно в разрешаване и забраняване на
апаратни прекъсваният, както и респективно влизане и излизане в критична секция в система с
висока дълбочина на вложеност на изпълнението. По време на работа на операционната
система е възможно определена задача да забрани определено апаратно прекъсване, след което
да бъде прекъсната от по-високо приоритетна задача. Активираната задача може да притежава
част от код, който последователно забранява и разрешава същото прекъсване фиг. 37. Като
резултат се получава вложеност на манипулациите по разрешаване/забраняване на съответното
прекъсване. Този ефект води до по-ранно несъзнателно разрешаване напрекъсването в
системата, което в повечето случай е нежелан ефект.
фиг. 37 Ефект на вложеност при работа с прекъсвания

В случай, че задача 1 не беше прекъсната от задача 2, реално разрешаване на прекъсването
би било в момент t4. В разгледания пример, разрешаването на прекъсването се получава в
момент t3. По този начин задача 1 не получава възможност за изпълнение при забранено
съответното прекъсване.
54 / 58
_______________________________________________________
За предотвратяване на този проблем е необходимо да се използват предоставените примитиви
от системата за разрешаване/забрана на прекъсванията EnableAllInterrupts()
DisableAllInterrupts()
#define DisableAllInterrupts() \
NetstedInterrupts++; \
_DI()
#define EnableAllInterrupts() \
if(0 < NetstedInterrupts) \
if(0 == -- NetstedInterrupts) \
_EI()
НЕДОВЪРШЕНО!!!
32.2. Известни проблеми и ограничения в настоящата разработка
32.2.1. Препоръки за заобикаляне на проблемите
32.2.2. Препоръки по отношение на наложените от системата

ограничения ограниченията
32.3. Файлов структура на ОСРВ
55 / 58
_______________________________________________________
ПРИЛОЖЕНИЕ
ФИГУРИ
фиг. 1 Взаимодействие на ОСРВ с физическата среда...........................................................................................3
фиг. 2 Основни моменти в система за реално време............................................................................................... 4
фиг. 3 Структура на СРВ – множество задачи и среда за комуникация помежду им.............................................5
фиг. 4 Декомпозиция на фукционалностти............................................................................................................. 7
фиг. 5 Превключване на контекст на задачи........................................................................................................... 9
фиг. 6 Апаратно прекъсване в микроконтролер...................................................................................................... 9
фиг. 7 Превключване на задачи............................................................................................................................. 10
фиг. 8 Стратегия на кооперативна диспечеризация............................................................................................. 12
фиг. 9 Стратегия на диспечеризация с изтласкване............................................................................................. 13
фиг. 10 Граф на състоянията и преходите за базова и разширена задача.............................................................15
фиг. 11 Изчакване на събитие от разширена задача.............................................................................................16
фиг. 12 Изпълнение на подпрограма за обрабока на прекъсване Категория 1........................................................19
фиг. 13 Обслужване на прекъсване Категория 2 (UML – activity diagram).............................................................20
фиг. 14 Влияние на прекъсвания Категория 1 и Категория 2 върху потребителски задачи....................................21
фиг. 15 Инверсия приоритета на задача очакваща ресурс....................................................................................22
фиг. 16 Работа при използване на протокол за таванен приоритет.....................................................................24
фиг. 17 Изпадане в състояние „мъртва хватка”.................................................................................................. 25
фиг. 18 Етапи при разработка на система с ОСРВ.............................................................................................. 27
фиг. 19 Примерна времева карта на задачите...................................................................................................... 28
фиг. 20 Изпълнение на τ i между активации на τ m ............................................................................................... 30
фиг. 21 Изпълнение на две задачаи........................................................................................................................ 31
фиг. 22 Изпълнение на τ 1 и τ 2 - случай 1............................................................................................................ 34
фиг. 23 Изпълнение на τ 1 и τ 2 - случай 1............................................................................................................ 34
фиг. 24 Максимална продължителност на задача.................................................................................................. 36
фиг. 25 Време за реакция на потребителска задача.............................................................................................. 40
фиг. 26 Влияние на ниско приоритетните задачи върху високо приоритетните задачи........................................41
фиг. 27 Влияние на високо приоритетни задачи при прексваем характер на диспечеризация................................42
фиг. 28 Припокриване на стекови облсти............................................................................................................. 44
фиг. 29 Неизползване на стеков масив.................................................................................................................. 45
фиг. 30 Мониторинг на стека посредством байтов шаблон.................................................................................45
фиг. 31 Маркиране край на стека посредством „воден знак”...............................................................................46
фиг. 32 Хронологична диаграма – проверка на „воден знак”..................................................................................47
фиг. 33 Нарушаване на времето за реакция - td.................................................................................................... 48
фиг. 34 Работа на времевия монитор – TimeScheduleManager..............................................................................49
фиг. 35 Само-мониторинг на TimeScheduleManager.............................................................................................. 51
56 / 58
_______________________________________________________
фиг. 36 Защитен механизъм на ОСРВ с WDT........................................................................................................ 51
фиг. 37 Ефект на вложеност при работа с прекъсвания......................................................................................53
ТАБЛИЦИ
Таблица 1 Възможни преходи между състоянията на задачите..........................................................................15

Таблица 2 Примерна конфигурация за TSM........................................................................................................... 50
БИБЛИОГРАФИЯ
1. Liu, C.L. и Layland, J.W. Scheduling Algorithms for Multi-Programming in a Hard Real-Time. н.м. : Journal
of the Association for Computing Machinery Vol. 20, 1 (January 1973), pp. 46-61., 1973.
2. Wellings, A. Burns and A.J. Restricted Tasking Models. н.м. : Real-Time Systems Research Group,
University of York, UK.
3. Michael, G., Harbour. Timing Analysis for Fixed Priority Scheduling of Hard Real-Time Systems. н.м. : Naval
Ocean Systems Center under contract N66001-87-C-0155,.
4. Reinder J. Bril, Johan J. Lukkien. Worst-case response time analysis of real-time tasks.
5. Lehoczky, John, Sha, Lui и Ding, Ye. The Rate Monotonic Scheduling Algorithm: Exact Characterization
And Average Case Behaviour. н.м. : Department of ComputerScience - Carnegie Mellon University.
6. A hyperbolic bound for the rate monotonic algorithm. Enrico Bini, Giorgio Buttazzo, and Giuseppe
Buttazzo. н.м. : In Proceedings of the IEEE Euromicro Conference on Real-Time Systems, 2001.
7. Sensitivity analysis for fixed-priority real-time systems. Bini, Enrico, Di Natale, Marco и Buttazzo, Giorgio.
н.м. : Springer Science+Business Media, LLC 2007, 2008. DOI 10.1007/s11241-006-9010-1.
8. Somoza, R. Early Use of Reversed Rate Monotonic Analysis for Estimation of Required Computing Power in
Hard Real-Time Systems. Madrid : Support Analysis of Software Manager Aircraft Construction, 2005.
9. Wang, Yun и Saksena, Manas. Scheduling Fixed-Priority Tasks with Preemption Threshold. Pittsburgh, PA
15260, USA : Department of Computer Science, 2006.
10. consortium, AUTOSAR. AUTOSAR OS Specification. AUTOSAR. [Онлайн] AUTOSAR, 2010 r.
http://portal.osek-vdx.org/index.php?option=com_content&task=view&id=9&Itemid=13. os223.pdf.
11. Sangiovanni-Vincentelli, Alberto и Di Natale, Marco. Embedded System Design for Automotive
Applications. Berkeley : University of California, 2008.
12. L. Sha, R. Rajkumar, and J.P. Lehoczky. Priority Inheritance Protocols: An Approach to Real-Time
Synchronization. н.м. : IEEE Trans. Computers, 1990. vol. 39, no. 9, 1990, pp. 1175-1185..
13. Scheduling Fixed-Priority Tasks with Preemption Threshold. н.м. : Proc. IEEE Int’l Conf. Real-Time
Computing Systems and Applications, IEEE Press, 1999.
14. Joseph, M. и Pandya, P. K. Finding Response Times in a Real-Time System. н.м. : The Computer J., vol.
29, no. 5, 1986.
15. C. Pinello, L. Carloni, and A. Sangiovanni-Vincentelli. Fault-Tolerant Deployment of Embedded Software
for Cost-Sensitive Real-Time Feedback-Control Applications. н.м. : Proc. DATE Conf., IEEE CS Press, 2004,
pp. 1164-1169., 2002.
16. Zheng, W. Synthesis of Task and Message Activation Models in Real-Time Distributed Automotive
Systems. н.м. : Proc. IEEE/ACM DATE Conf., IEEE Press, 2007, pp. 93-98., 2007.
57 / 58
_______________________________________________________
17. Lehoczky, John P. Fixed Priority Scheduling of Periodic Task Sets with Arbitrary Deadlines. Pittsburg PA
15213 : Carnegie Mellon University, 2000.
18. Fidge, C. J. Real-Time Schedulability Tests for Preemptive Multitasking. Queensland 4072, Australia :
Software Verification Research Centre, School of Information Technology, The University of Queensland, 2006.
19. Harbour, Michael Gonzalez, Mark, Klein H. и Lehoczky, John P. Timing Analysis for Fixed Priority
Scheduling of Hard Real-Time Systems. Pittsburgh, PA 15213 : Software Engineering Institute - Carnegie
Mellon University, 2005.
58 / 58

Downloadfile

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Downloadfile

Uploaded by

Copyright:

Available Formats

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

1. ОПЕРАЦИОННИ СИСТЕМИ ЗА РЕАЛНО ВРЕМЕ ЗА ВГРАДЕНИ СИСТЕМИ..........................................3

1. ОПЕРАЦИОННИ СИСТЕМИ ЗА РЕАЛНО ВРЕМЕ ЗА ВГРАДЕНИ СИСТЕМИ

1.1. Общ преглед

Операционната Система за Реално Време (ОСРВ) представлява комплекс от програми,

фиг. 1 Взаимодействие на ОСРВ с физическата среда

Въздействията върху СРВ са резултат от определени събития {an}, възникващи асинхронно

, която задава алгоритъма на функциониране на OСРВ.

фиг. 2 Основни моменти в система за реално време

Периодът Тr за определяне на реакцията r ∈ R на въздействието а ∈ А е променлив поради

t r=(T a+ T r )<t d 1.2

където td е крайният срок за изработване на реакциятa r от СРВ. Нарушаването на горното

фиг. 3 Структура на СРВ – множество задачи и среда за комуникация помежду им

Всяка задача представлява активен логически обект, извършващ определена работа в

1.1. Преглед на съвременните ОСРВ за вградени системи

1.2. Основни цели и задачи на настоящата разработка

Електронните системи за диагностика в железопътния транспорт се характеризират с

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

фиг. 4 Декомпозиция на фукционалностти

Компонента е независим програмен обект, реализращ определена функционалност

2. РАЗРАБОВАНЕ НА ОПЕРАЦИОННАТА СИСТЕМА ЗА РЕАЛНО ВРЕМЕ

2.1. Архитектура на операционната система за реално време

Неизмено изискване към ОСРВ е възможността за нейната преносимост в определен

2.2. Диспечеризация на задачите

Създаването на условия за изпълнение на няколко задачи паралелно се нарича много-

2.2.1. Механизъм на превключване на задачите

Изпълнението на задачите се извършва на конкурентен принцип, базиран на

фиг. 5 Превключване на контекст на задачи

фиг. 6 Апаратно прекъсване в микроконтролер

фиг. 7 Превключване на задачи

td ≡ to & (ts – to) < Trmax

2.2.2. Видове диспечеризация

Многозадачното ядро на ОСРВ поддържа отделен виртуален процесор за всяка задача.

2.2.2.1. Кооперативна диспечеризация

Измененията в системата са свързани с определени системни разходи. Превключването

фиг. 8 Стратегия на кооперативна диспечеризация

1.1.1.1. Диспечеризация с изтласкване

Стратегията за диспечеризация с изтласкване се основава на идеата, че изпъняваната

фиг. 9 Стратегия на диспечеризация с изтласкване

След направеният обзор на двете основни стратегий за диспечеризация лесно може да се

1.2. Потребителска задача

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

1.2.1. Граф на състояния на задачите

По време на своето съществуване процесите в една система за реално могат да се

фиг. 10 Граф на състоянията и преходите за базова и разширена задача.

Задачата притежава всички необходими

активиране READY RUNNING Задачата започва своето изпълнение

Диспечерът прекъсва изпълнение на задачата

Задачата е завършила своето изпълнение и чрез

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

Изчакваното събитие, от задачата е настъпило

Таблица 1 Възможни преходи между състоянията на задачите

Базовите задачи могат да прекратят своето изпълнение само в следните случай:

- те се само-терминират посредством предоствен интерфейс от ОСРВ;

- базовата задача, изпълнявана в момента е с прекъсвама диспечеризация, и съществува

- натъпване на апаратно прекъсване от процесора и се преминава към изпълнение на

1.2.3. Разширена задача

Разширените задачи се различават от базовите по възможността за заемане на състовяние

фиг. 11 Изчакване на събитие от разширена задача.

1.2.3.1. Приоритизация на задачите

Диспечерът на базата на съответния приоритет на задачите решава, коя от опашката на готовите

1.2.4. Точки на диспечеризация на задачите

2. Activation of the scheduler