своєму розпорядженні три роки для розробки першого варіанту OS-9).
Одна з їхніх особливостей - високий ступінь масштабованості. На базі цих ОС можна побудувати як компактні системи реального часу, так і великі системи серверного класу.
Як правило, ядра реального часу мають два типи систем розробки - кросову і резидентную.
Системи цього класу, як правило, модульні, добре структуровані, мають найбільш розвинений набір специфічних механізмів реального часу, компактні і передбачувані. Найбільш популярні системи цього класу: OS9, QNX.
1.3.1.3. UNIX'и реального часу
Історично системи реального часу створювалися в епоху розквіту і буму UNIX'а і тому багато з них містять ті чи інші запозичення з цієї красивої концепції операційний системи (користувальницький інтерфейс, концепція процесів і т.д.).
Частина розробників операційних систем реального часу спробувала просто переписати ядро ​​UNIX, зберігши при цьому інтерфейс користувача процесів з системою, наскільки це було можливо. Реалізація цієї ідеї не була занадто складною, оскільки не було перешкоди в доступі до вихідним текстам ядра, а результат виявився чудовим. Отримали і реальне час, і відразу весь набір користувальницьких додатків - компілятори, пакети, різні інструментальні системи.
У цьому сенсі творцям систем перших двох класів довелося потрудитися не тільки при створенні ядра реального часу, а й просунутих систем розробки.
Однак Unix'и реального часу не позбавлені наступних недоліків: системи реального часу виходять досить великими і реактивність їх нижче, ніж реактивність систем перших двох класів.
Найбільш популярним представником систем цього класу є операційна система реального часу LynxOS.
1.3.2. Класифікація за програмному середовищі. p> Стає очевидним те, що завдання реального часу необхідно реалізовувати в рамках специфічної системної програмної середовища. У Відповідно до [12] системи реального часу можна розділити на 4 класи.
1.3.2.1. Програмування на рівні мікропроцесорів. p> У даному випадку програми для програмованих мікропроцесорів, вбудованих в різні пристрої, дуже невеликі і зазвичай написані на мові низького рівня типу асемблера або PLM. Внутрісхемние емулятори придатні для налагодження, але високорівневі засоби розробки та налагодження програм не застосовні. Операційне середовище зазвичай недоступна. p> 1.3.2.2. Мінімальна ядро ​​системи реального часу. p> На більш високому рівні знаходяться системи реального часу, щоб забезпечити мінімальну середу виконання. Передбачені лише основні функції, а управління пам'яттю і диспетчер часто недоступні. Ядро являє собою набір програм, що виконують типові, необхідні для вбудованих систем низького рівня функції, такі, як операції з плаваючою коми і мінімальний сервіс введення/виведення. Прикладна програма розробляється в інструментальному середовищі, а виконується, як правило, на вбудованих системах.
1.3.2.3. Ядро системи реального часу і інструментальне середовище. p> Цей клас систем має багатьма рисами ОС з повним сервісом. Розробка ведеться в інструментальної середовищі, а виконання - на цільових системах. Цей тип систем забезпечує набагато більш високий рівень сервісу для розробника прикладної програми. Сюди включені такі кошти, як дистанційний символьний відладчик, протокол помилок і інші засоби. Часто доступно паралельне виконання програм.
1.3.2.4. ОС з повним сервісом. p> Такі ОС можуть бути застосовані для будь-яких додатків реального часу. Розробка і виконання прикладних програм ведуться в рамках однієї і тієї ж системи.
Системи 2 і 3 класів прийнято називати системами "Жорсткого" реального часу, а 4 класу - "м'якого". Очевидно, це можна пояснити тим, що в першому випадку до системи пред'являються жорсткіші вимоги за часом реакції і необхідного обсягу пам'яті, ніж у другому. Як ми бачимо, середовище розробки та середовище виконання в системах реального часу можуть бути розділені, а вимоги, які пред'являються до них, досить різні. Розглянемо їх більш докладно. p> 1.3.3. Технічні характеристики ОС РВ. p> 1.3.3.1. Час реакції системи. p> Майже всі виробники систем реального часу наводять такий параметр, як час реакції системи на переривання (interrupt latency).
Справді, якщо головним для системи реального часу є її здатність вчасно відреагувати на зовнішні події, то такий параметр, як час реакції системи є ключовим. Однак у даний момент немає, на жаль, загальноприйнятих методологій вимірювання цього параметра, тому він є полем битви маркетингових служб виробників систем реального часу. Є надія, що незабаром становище зміниться, так як уже стартував проект порівняння операційних системах реального часу, який включає в себе в тому числі і розробку методології тестування.
Події, що відбуваються на об'єкті, реєструються датчиками, дані з датчиків передаються в модулі вводу-виводу (інтер...
