Архітектури операційних систем реального часу

↑

▷ Содержание

⇐ ПредыдущаяСтр 7 из 7

9.Опис

Операці́йна систе́ма реа́льного ча́су, ОСРЧ (англ. Real-Time Operating System) — один із типів операційної системи. Є багато визначеннь терміну, які іноді суперечать одне одному.

Найбільш розповсюдженими визначеннями операційної системи реального часу є:

· ОС, в якої успішність роботи будь-якої програми залежить не тільки від її логічної правильності, але і від часу, за який вона отримала цей результат. Якщо система не може задовольнити часовим обмеженням, повинен бути зафіксований збій в її роботі

· Стандарт POSIX 1003.1 дає визначення «Реальний час в операційних системах — це здатність операційної системи забезпечити рівень сервісу, який вимагається за визначений проміжок часу»

· ОС, яка реагує за передбачуваний час на непередбачувану появу зовнішніх подій

· Інтерактивні системи постійної готовності. До категорії ОСРЧ їх відносять виходячи з маркетингових міркувань і якщо інтерактивну програму називають «працюючою в реальному часі», то це означає лиш те, що запити від користувача обробляються із затримкою, непомітною для людини.

· Іноді поняття системи реального часу ототожнюють зі «швидкою системою», але це не завжди правильно, оскільки важливий не час затримки реакції ОСРЧ, а те, щоб цього часу було достатньо для прикладної програми, яка розглядається і щоб його було гарантовано.

· В багатьох спеціалізованих сферах вводять свої поняття «реального часу». Наприклад, процес цифрової обробки сигналу називають таким, що відбувається в реальному часі, якщо аналіз та/або генерація даних можуть бути проведені в той же час, що і аналіз/генерація тих самих даних без цифрової обробки сигналу. Наприклад, якщо при обробці аудіо даних необхідно 2.01 секунд на аналіз 2.00 секунд звуку, то це не процес реального часу. Якщо потрібно 1.99 секунд, то це процес реального часу.

Класичним прикладом задачі, де необхідна ОСРЧ є керування роботом, який бере деталь зі стрічки конвеєра. Деталь рухається і робот має лише маленький проміжок часу, коли він може її взяти. Якщо він запізниться, то деталь не буде вже на потрібній ділянці конвеєра, а отже, робота не буде виконана, незважаючи на те, що робот знаходиться в правильному положенні. Якщо він позиціонується раніше, то деталь ще не встигне під'їхати і він заблокує її шлях.

10) Класифікація

Іноді розрізняють системи «жорсткого» та «м'якого» реального часу. ОС «жорсткого» реального часу гарантує виконання деяких дій в заданий інтервал часу, ОС «м'якого» реального часу, як правило, встигають виконати дії за заданий проміжок часу, але повністю не гарантують це. Більшість програмного забезпечення орієнтовано на «м'який» реальний час.

Для подібних систем характерно:

· гарантований час реакції на зовнішні події (переривання від обладнання);

· жорстка підсистема планування процесів (високопріорітетні задачі не повинні бути витісненими низькопріоритетними, за деяким виключенням);

· підвищення вимог до часу реакції на зовнішні події чи реактивності (затримка виклику обробника переривання не більш ніж десяток мілісекунд, затримка при перемиканні задач не більш ніж сотні мілісекунд)

Відкриті:

• eCos
• Fiasco (клон L4) [1]
• FreeRTOS
• KURT (KU Real Time Linux) — ОС м'якого РЧ на основі Linux
• Phoenix-RTOS
• Nut/OS [2]
• Prex
• RTAI
• RTEMS — ОС з відкритими вихідними кодами, розроблена в DARPA МО США
• RTLinux — ОС жорсткого РЧ Linux
• scmRTOS — Single-Chip Microcontroller RTOS [3]
• SHaRK [4]
• TRON
• Xenomai [5]
• ОС2000 — ОС РВ розроблена НДІСІ РАН на замовлення МО РФ

Пропрієтарні:

• Ardence RTX
• BeOS
• ChorusOS
• DNIX
• DMERT
• DSOS
• embOS (Segger)
• HP-1000/RTE [6]
• INTEGRITY
• ITRON
• LynxOS
• MERT
• MicroC/OS-II
• MQX RTOS [7]
• Nucleus
• OS-9
• OSE
• OSEK/VDX
• OSEKtime

• PDOS
• Phar Lap ETS
• PikeOS
• Portos[8]
• pSOS
• QNX/Neutrino
• REX
• RMX
• RSX-11
• RT-11
• RTOS-32 — ОС з відкритим вихідним кодом
• RTOS-UH
• RTXC
• Salvo RTOS[9]
• SINTRAN III
• Symbian OS
• ThreadX
• VRTX
• VxWorks/Tornado
• Windows CE
• µnOS
• UNIX-RTR
• Virtuoso — ОС РЧ для сигнальних процесорів DSP

RTEMS

RTEMS (англ. Real-Time Executive for Multiprocessor Systems, рос. Виконавець реального часу для мультипроцесорних систем) - вільна операційна система реального часу з відкритим вихідним кодом, розроблена для вбудованих систем.

Акронім RTEMS походить від слів Виконавець реального часу для ракетних систем (англ. Real-Time Executive for Missile Systems (пізніше словосполучення «ракетних систем» замінили на «військових систем», англ. Military Systems)

  Розробка велася з кінця 1980-х під управлінням OAR Corporation, спільно з Керуючим Комітетом RTEMS, в який входили представники основних користувачів системи. Доступ до нових версій по FTP організований з початку 1993 року.

Цільові платформи

• ARM
• Blackfin
• Freescale ColdFire
• цифровые сигнальные процессоры Texas Instruments серій C3x/C4x
• Hitachi H8/300
• i386, Pentium и старші
• Motorola 68000
• MIPS
• Nios II
• PowerPC
• SuperH
• SPARC

підтримка стандартів

RTEMS розроблялася з урахуванням різних відкритих стандартів, включаючи   POSIX      і         uITRON.

  Програмний інтерфейс додатків (API, він же Classic RTEMS API) спочатку грунтувався на специфікаціях визначення виконавчого інтерфейсу реального часу (англ. Real-Time Interface Executive Definition, англ. RTEID). Також RTEMS включає в себе порт TCP / IP-стека ОС FreeBSD і підтримку файлових систем, включаючи NFS і FAT.

  RTEMS не передбачає будь-яких форм управління пам'яттю процесів, що, в термінології POSIX, говорить про те, що система підтримує тільки єдине, однонітевиє, багатопотікове оточення. Це відображається у тому факті, що RTEMS забезпечує майже всі сервіси POSIX, крім відносяться до розподілу пам'яті,  розгалуження процесів і загального поля пам'яті. RTEMS на сьогоднішній день повністю відповідає POSIX Profile 52, що означає «один процес, багато потоків, файлова система»

застосування

  Впровадженням RTEMS в багатьох областях відає співтовариство EPICS, що включає безліч активних розробників RTEMS.

  RTEMS стала популярна в аерокосмічній сфері з початком своєї підтримки різних мікропроцесорів, що використовуються в цій галузі, таких як, наприклад, SPARC ERC32 і LEON, а також мікропроцесорів архітектури MIPS (Mongoose-V), архітектур Coldfire і PowerPC у військово-космічному виконанні. Сьогодні RTEMS використовується на борту Mars Reconnaissance Orbiter, як керуюча радіомодулем «Electra».

RTLinux

RTLinux - мікроядерна операційна система жорсткого реального часу, яка виконує Linux як повністю витісняється процес.

Особливості  реалізації

  Розробники RTLinux пішли по тому шляху, який передбачає запуск з наноядра реального часу ядра Linux як завдання з найменшим пріоритетом. В RTLinux все переривання обробляються ядром реального часу, який включає власний планувальник завдань, обробник переривань і бібліотечний код. У разі відсутності обробника реального часу для якогось переривання, воно передається в Linux. Фактично Linux є простоює (idle) завданням ОСРВ, запускається тільки в тому випадку, якщо жодна задача не виконується в реальному часі. При цьому на Linux-задачу накладаються деякі обмеження, які, втім, прозорі для  програміста.Linux не може виконувати наступні операції:блокувати апаратні переривання; оберігати себе від витіснення іншим завданням.

  Ключ до реалізації даної системи - емулює систему управління переривань драйвер, до якого звертається Linux при спробі блокувати переривання. В цьому випадку драйвер перехоплює запит, зберігає його і повертає управління Linux.

  Всі апаратні переривання перехоплюються ядром ОСРВ. Коли відбувається переривання, ядро ​​RTLinux вирішує, що робити. Якщо це переривання повинно бути оброблено обробником реального часу, то ядро ​​викликає відповідний обробник. В іншому випадку або якщо обробник реального часу каже, що хоче розділяти це переривання з Linux, обробникові присвоюється стан очікування (pending). Якщо Linux зажадав дозволити переривання, то переривання, які знаходяться в стані очікування, емулюються.

  Ядро RTLinux спроектовано таким чином, що ядро ​​реального часу ніколи не потребує очікуванні звільнення ресурсу, зайнятого Linux-процесом.
  Для обміну даними між ОСРВ і Linux передбачені наступні засоби:
  Ключовий принцип побудови RTLinux - як можна більше використовувати Linux і якомога менше RTLinux. Дійсно, Linux піклується про ініціалізації системи та пристроїв, а також про динамічний виділення ресурсів. На RTLinux лягає тільки планування завдань реального часу і обробка переривань.       Процеси реального часу реалізовані у вигляді завантажуваних модулів Linux для простоти запуску в контексті ядра, збереження модульності і розширюваності системи.

  Додаток реального часу з RTLinux, як правило, складається з двох незалежних частин: процесу, виконуваного ядром RTLinux, і звичайного Linux-додатки.
 
  Такий модульний підхід до написання програм притаманний багатьом розширень реального часу для багатоцільових систем, де завдання реального часу працює незалежно від ОС.   Розробники вже прийняли схему, за якою критичні до часу реакції завдання програмуються за допомогою API-інтерфейсів, передбачених розширенням реального часу, а всі функції сервісу та інтерфейсу з користувачем покладається на міць операційної системи. При використанні даного підходу, програмісту потрібно вивчити тільки API-інтерфейс обробника подій реального часу.

                  Недоліки реалізації RTLinux

Програми реального часу виконуються в просторі ядра, отже вони можуть переписати          частину пам'яті ядра і зламати систему
Взаємодія між RT-підсистемою і Linux може бути тільки Ядро Linux виконується в бекграунді, отже завдання Linux можуть відчувати великі затримки.Неможливо використовувати          драйвери Linux в задачах реального часу, отже розробники додатків реального часу змушені переписувати драйвери пристроїв поверх RT-підсистеми

ОС 2000

  ОС2000 (також «ОС РВ Багет» і «Багет 2.0») - операційна система реального часу (ОСРВ), розроблена НИИС РАН для ЕОМ серії «Багет» [1] на мікропроцесорах MIPS і Intel.

  ос2000 призначена для розробки програмного забезпечення для систем (програмно-апаратних комплексів), що працюють в режимі            реального       часу.

відповідність стандартам

При розробці операційної системи використовувалися наступні міжнародні  стандарти:
POSIX 1003.1, стандарт на мобільні операційні системи (програмний інтерфейс);стандарт С, описує мова та бібліотеки мови Сі.графічна підсистема X Window System (клієнт-сервер).

  мобільність
  Мається на увазі принципова можливість роботи системи на різному устаткуванні. Для досягнення мобільності система

  Частина, яка не залежить від устаткування, написана на C, у зв'язку з цим, її перенесення на інші платформи вважається нескладним. Залежна від устаткування частина, написана на C і Асемблері, в неї входять функції запам'ятовування і відновлення контексту, пролог і епілог диспетчера переривань. Пакет підтримки модуля (ЕОМ), містить драйвери пристроїв конкретної ЕОМ і сам диспетчер переривань.

  Внесення змін до драйвери, а також розробка нових драйверів і включення їх в операційну систему проводиться шляхом внесення змін до вихідні тексти ППМ. При цьому немає необхідності вносити зміни в ядро операційної системи.

  Крос-розробка

  Для розробки програмного забезпечення під операційну систему, потрібно використання двох ЕОМ, тобто програми для ос2000 розробляються на інструментальної ЕОМ з UNIX-подібної операційної системою. Друга ЕОМ є цільовою, по суті це і є машина, на якій встановлена ​​ос2000 для якої розробляється програмне забезпечення.
  Засоби розробки дозволяють відтранслювати програму, написану на мовах С і Асемблер, а також налагоджувати програму, завантажену в цільову машину.

Symbian

Symbian — це операційна система для смартфонів.

Історія

  Система від початку розроблялася консорціумом Symbian Ltd. Консорціум було засновано у червні 1998 року компаніями Psion, Nokia, Ericsson та Motorola. Пізніше до косорціуму приєдналися компанії Sony-Ericsson, Siemens, Panasonic, Fujitsu, Samsung, Sony та Sanyo. У 2008 сформовано некомерційну організацію Symbian Foundation, яка продовжила розробку операційної системи. З осені 2010 розробкою Symbian займається компанія Nokia, в той час як Symbian Foundation опікується лише юридичними питаннями, зокрема ліцензуванням платформи.

  Symbian OS є спадкоємцем операційної системи EPOC32, котра була розроблена компанією Psion для своїх кишенькових комп'ютерів. У 1998-2000 роках значану частину системи було переписано з метою оптимізації коду для подальшої роботи на пристроях з обмеженими ресурсами. Розробникам вдалося досягти значної економії пам'яті, покращення кешування коду та, як наслідок, прискорення роботи програм, при знижених вимогах до енерговитрати. З точки зору розробки, виключною особливістю системи є повністю об'єктно-орієнтована архітектура (на рівні API). Починаючи з версій системи 9.х з'явився серйозний механізм захисту — розмежування API відповідно до прав (англ. capabilities) застосунків. Основна мова розробки застосунків — С++, є підтримка Java.

На 2010 рік найбільш розповсюдженою (за кількістю пристроїв) версією є Symbian OS Series 60 2nd Edition^{[Джерело?]}. У 2005 році вийшла Symbian OS Series 60 3rd Edition, що призвело до порушення зворотньої сумісності з програмами, розробленими для попередніх версій.

Хронологія

· У 1998 компаніями Ericsson, Nokia, Motorola та Psion була заснована компанія Symbian Ltd.

· У 1999 компанією Psion випущена операційна система EPOC Release 5, що отримала іншу назву Symbian OS v5. Вона використовувалась в комп'ютерах Psion Series 5mx, Psion Series 7, Psion Revo, Psion Netbook, netPad, Ericsson MC218.

· У 2000 з'явилась операційна система EPOC5u (Symbian OS v5.1, u = Unicode). Першим смартфоном з її використанням став Ericsson R380.

· Symbian OS v6.0 та v6.1 (іноді називають ER6). Перший повноцінний Symbian-смартфон Nokia 9210, працював саме на Symbian OS v6.0.

· У 2003 розробники випустили Symbian OS v7.0 та v7.0s. Ця система підтримувала платформи UIQ (Sony Ericsson P800, P900, P910, Motorola A925, A1000), Series 80 (Nokia 9300, 9500), Series 60 (Nokia 6600), а також FOMA.

· У жовтні 2003 компанія Motorola вийшла з консорціуму, та продала свою частку компаніям Nokia та Psion.

· У 2004 компанія Psion продала свою частку в Symbian.

· У тому ж 2004 зявився перший вірус для операційної системи Symbian — Комп'ютерний хробак Cabir, що вмів самостійно розсилати себе через Bluetooth.

· Symbian OS v8.0 з'явилась в 2004, особливістю якої була можливість вибору між двома різними ядрами (EKA1 чи EKA2). EKA2 не використовується аж до виходу SymbianOS v8.1b.

· Symbian OS v8.1 — поліпшена версія 8.0 з підтримкою ядер EKA1 та EKA2.

· У 2004 вийшла Symbian OS v9.0. З цією версією зупинилось використання ядра EKA1. Однак перші телефони, що використовували нову операційну систему, з'явилась на ринку лиш на початку 2006 року.

· На початку 2005 з'явилась Symbian OS v9.1.

· У першому кварталі 2006 з'явилась Symbian OS v9.2 з підтримкою Bluetooth 2.0 та OMA Device Management 1.2.

· 12 липня 2006 — офіційна дата виходу наступної версії Symbian OS v9.3. Відрізняється підтримкою HSDPA та в'єтнамської мови.

· 16 листопада 2006 був проданий 100 мільйонний смартфон під керуванням Symbian OS.

· Symbian OS v9.5 з'явилась у березні 2007 року. З нововведень слід відзначити зниження енергоспоживання на 20-30 %, зменшення до 75 % часу запуску застосунків, покращену підтримку VoIP, а також підтримку цифрового телебачення (DVB-H, ISDB-T).

· 24 червня 2008 — до 10-ти річчя Symbian Ltd. було анонсоване створення нової, вільної Symbian.

· 2 грудня 2008 — Nokia повідомила про завершення придбання акцій Symbian Ltd. Споівробітники Symbian Ltd стали співробітниками Nokia з 1 лютого 2009 року.

· У 2009 році співробітниками організації S60 On Symbian Customer Operations ОС Symbian була портована з платформи S60 на x86-процесори. В якості тестового ПК була використана система на базі Intel Atom.

· 4 лютого 2010 Symbian Foundation оголосила, що ОС Symbian стає повністю відкритою (Open Source) і безкоштовною (Freeware).

· 27 квітня 2010 Nokia офіційно представила свій смартфон Nokia N8, який працює на новій операційній системі Symbian^3. Також було оголошено, що Nokia N8 стане останнім апаратом N-серії, який працює на Symbian.^[5]

Symbian Foundation

Фонд розробників Symbian Foundation був сформований 2008 року компаніями Nokia, AT&T, LG Electronics, Samsung Electronics, STMicroelectronics, Texas Instruments і Vodafone. Члени організації розраховують, що відкриття кодів Symbian OS дозволить підняти популярність програмної платформи серед виробників мобільних пристроїв і привернути до створення ОС нових розробників.

Першим відкритим компонентом Symbian OS, випущеним під ліцензією Eclipse Public Licence (EPL), став пакет безпеки ОС (OS Security Package). В жовтні 2009 Symbian Foundation повідомила про відкриття початкових кодів ключового компоненту операційної системи Symbian OS — мікроядра EKA2.

Ініціатива відкриття Symbian була запущена в червні 2008 року, коли Nokia оголосила, що викупить частину коду в інших вендорів і переведе управління платформою під егіду некомерційного об'єднання Symbian Foundation. В лютому 2010 код операційної системи було відкрито^[6]. Вихідний код Symbian буде проходити за умовами Eclipse Public License (EPL), але код, що надходить від компаній, може відноситися до інших ліцензій. EPL не передбачає надання спільноті того коду, який був створений поверх основного, відкритого всім, хоча організація і рекомендує це робити.

Код Symbian^3, включаючи програми, проміжний шар і ядро, можна було завантажити з сайту Symbian Foundation^[7]. На момент відкриття були відкриті 108 пакетів, що охопили 40 млн рядків коду. Надано та інструменти розробки — Symbian Developer Kit і Product Development Kit.

Symbian поміг Nokia зайняти значну частку ринку телефонів і смартфонів. Проте з появою нових гравців на ринку, таких як BlackBerry OS, Apple iPhoneOS/iOS та Google Android системі від Nokia було важко відповісти на нові виклики, і Nokia стала відчувати поступове, але виразне сповільнення продажів продукції компанії. У 4 кварталі 2010 року смартфони Symbian виробництва Nokia поступилися Android за часткою ринку, хоча з урахуванням інших виробників пристроїв, Symbian все ще посідає перше місце^[8][9]. Станом на 2010 рік Symbian-телефони, яких всього налічується більше 330 млн, випускають Nokia, Samsung, Sony Ericsson, Fujitsu і Sharp.

Восени 2010 компанія Nokia ухвалила рішення про зміну стратегії розробки відкритої мобільної платформи Symbian, відповідно до якої Nokia візьме на себе розвиток і розробку платформи^[10]. Штат Symbian Foundation був серйозно скорочений, а діяльність звелася до вирішення питань, пов'язаних з ліцензуванням програмного забезпечення і розпорядженням інтелектуальною власністю, такою як торгова марка Symbian. Оголошено про закриття сайту фонду Symbian.org. Оскільки заснування незалежного фонду не виправдало себе, Nokia вирішила надати власні ресурси для розробки Symbian і продовжити постачання і створення нових моделей телефонів на базі цієї платформи. Основний фокус у розробці Symbian зосереджений на розвитку відкритої кодової бази і використанні Qt в якості основного фреймворку для створення мобільних застосунків.

Наприкінці березня 2011 р.^[12] Nokia змінила умови доступу до коду Symbian, за якими його можуть отримати лише для партнери Nokia. Нова ліцензія Nokia Symbian License 1.0^[4], за якою тепер розповсюджується код Symbian, містить обмеження, згідно з якими операційна система є пропрієтарним програмним забезпеченням

Платформи

Телефони під управлінням операційної системи Symbian малють різні інтерфейси користувача, що також виступають у ролі програмних платформ. Їх перелік^[2][16][17]:

· Nokia Belle (попередня версія називалася Symbian Anna, до цього — Symbian^3). Є результатом об'єднання S60, UIQ та MOAP(S). Зворотньо сумісна з S60. Запланована підтримка до 2016 р.

· Symbian^2 — наступник платформи MOAP(S).

· Symbian^1, також відома як S60 (попередня назва — Series 60, кодова назва — Pearl). Вже випущені моделі пристроїв на цій платформі досі продаються та підтримуються, хоча для нових пристроїв використовується Nokia Belle.

· MOAP(S). У 2010 році платформа замінена на Symbian^2.

· UIQ, кодова назва — Quartz. Підтримка платформи припинена у 2009 році.

· Series 80, кодова назва — Crystal. Підтримка платформи припинена у 2007 році.

· Series 90, кодова назва — Hildon. Підтримка платформи припинена у 2006 році.

Назви Symbian^2, Symbian^3 та Symbian Anna паралельно були назвами самої операційної системи. У грудні 2011 року компанія Nokia прийняла рішення про повторне розділення, за якого для операційної системи і надалі буде використовуватися назва Symbian, а для позначення інтерфейсу використано бренд Nokia

Статистика

Порівняння смартфонів з різними операційними системами. Лютий 2010

Платформа

4 кв. 2009

4 кв. 2008

4 кв. 2007

3 кв. 2006

3 кв. 2005

Symbian

47,2 %

52,4 %

62,3 %

72,8 %

59,7 %

RIM (BlackBerry)

20,8 %

16,5 %

10,9 %

2,8 %

1,5 %

Apple (iPhone OS)

15,1 %

9,6 %

5,2 %

-

-

Microsoft (Windows Mobile)

8,8 %

13,9 %

11,9 %

5,6 %

2,2 %

Google (Android)

4,7 %

0,5 %

-

-

-

Інші (Linux, PalmOS)

3,4 %

7,2 %

9,6 %

18,8

36,6 %

За даними Gartner, станом на 4 квартал 2010 р. Symbian має найбільшу частку ринку смартфорнів (32,6 %) та займає друге місце після Android за кількістю проданих пристроїв (32,6 млн)^[9].

Сертифікати в Symbian OS

З розвитком операційної системи, з'явилась необхідність створення сертифікатів безпеки. Операційна система Symbian на базі платформи S60 3rd Edition жорстко обмежує можливість звернення програми до різних функцій API (системні функції операційної системи та смартфона), що, на думку розробників^{[Джерело?]}, можуть мати критичне значення для роботоздатності всієї системи.

Існує чотири типи сертифікатів для Symbian OS: Self-Signed, Symbian Signed, Basic Devcert, Phone Manufactured devcert.

· Self-Signed — сертифікат з обмеженим доступом до API, доступно приблизно 60% базових функцій.

· Symbian Signed — сертифікат видається розробнику після повного тестування та підпису компанією Symbian та программу підписану данним сертифікатом можна встановити на будь-який мобільний пристрій. Якщо продукт є коммерційним, то компанія розробник оплачує отримання даного сертифікату, для не комерційних продуктів — сертифікат видається безкоштовно.

· Phone Manufactured DevCert — найбільш повний сертифікат, що забезпечує доступ до всіх API функцій, даний сертифікат доступний тільки виробникам мобільних пристроїв.

· Developer Certificate (DevCert) — сертифікат розробника, що призначений для тестування программ на конкретному апараті перед відправкою на підпис в компацію Symbian. Для установки та функціонування программ достатньо мати даний вид сертифікату, він дає можливість встановити підписанну программу на смартфон з одним номером IMEI та отримати доступ до більшої кількості функцій API.

Нещодавно розробники змінили систему підпису сертифікатів: замість DevCert та SymbianSigned тепер зявиться 3 види підпису: Open Signed (відкритий — замість DevCert), Express Signed, Certified Signed (аналог SymbianSigned , тільки з чотирма додатковими можливостями: CommDD, MultimediaDD, NetworkControl, DiskAdmin).

Основні зміни: Open Signed, на відміну від DevCert (без Publisher ID) буде розповсюджуватись безкоштовно на 3 роки. Але тепер программу можна буде підписати тільки он-лайн на спеціальному порталі.

Express Signed — це нововведення, що дає доступ до всіх можливостей, що раніше давав Symbian Singed. Потребує Publisher ID.

Certified Signed — також потрібен Publisher ID, аккаунт на Symbian Signed з валідною електронною поштою, щорічний взнос (Publisher ID). Дає доступ до всіх можливостей, окрім: DRM, AllFiles, TCB (потрібно дозвіл виробника телефону).

QNX

QNX — комерційна POSIX-сумісна операційна система реального часу. QNX призначена в першу чергу для вбудованих систем. Вважається однією з найкращих реалізацій концепції мікроядерних операційних систем.

Розробника системи «QNX Software Systems» у 2004 придбав «Harman International»^[1], а в 2010 він був проданий канадській компанії Research In Motion (RIM)^[2] Платформа RIM BlackBerry Tablet OS базується на технологіях компанії QNX Software Systems.

Опис

QNX базується на ідеї роботи основної частини своїх компонентів (сервіси) поза ядром. Це відрізняє її від традиційних монолітних ядер, в яких ядро операційної системи — це одна велика програма, яка складається з багатьох «частин». Використання мікроядра в QNX дозволяє відключати будь-яку непотрібну в поточній ситуації функціональність без зміни ядра.

Система в мінімальній конфігурації вміщується на одну дискету, разом з тим вона вважається дуже швидкою і надійною.

QNX Neutrino, випущена в 2001 році, перенесена на багато платформ, і зараз здатна працювати на практично всіх сучасних процесорах — x86, MIPS, PowerPC, а також спеціалізованих процесорах, таких, як SH-4, ARM, StrongARM та xScale.

Версія для некомерційного використання доступна для скачування на веб-сайті розробника.

 АрхітектуриОСРВ

У своєму розвитку ОСРВ будувалися на основі наступних архітектур.
Монолітна архітектура. ОС визначається як набір модулів, взаємодіючих між собою всередині ядра системи і надають прикладному ПО вхідні інтерфейси для звернень до апаратури. Основний недолік цього принципу побудови ОС полягає в поганій передбачуваності її поведінки, викликаної складною взаємодією модулів між собою.
Рівнева (шарова) архітектура. Прикладне ПО має можливість отримати доступ до апаратури не тільки через ядро ​​системи та її сервіси, а й безпосередньо. У порівнянні з монолітною така архітектура забезпечує значно більший ступінь передбачуваності реакцій системи, а також дозволяє здійснювати швидкий доступ прикладних програм до апаратури. Головним недоліком таких систем є відсутність багатозадачності.
Архітектура "клієнт-сервер». Основний її принцип полягає у винесенні сервісів ОС у вигляді серверів на рівень користувача та виконанні мікроядром функцій диспетчера повідомлень між клієнтськими користувацькими програмами і серверами - системними сервісами.Переваги     такої архітектури:

Підвищена надійність, так як кожен сервіс є, по суті, самостійним додатком і його легше налагодити і відстежити помилки;
Покращена масштабованість, оскільки непотрібні сервіси можуть бути виключені з системи без збитку до її працездатності;
Підвищена відмовостійкість, так як «зависло» сервіс може бути перезапущений без перезавантаження системи.

монолітна архітектура

Рівнева (шарова) архітектура

Управління завданнями. Найголовніша група сервісів. Дозволяє розробникам додатків проектувати програмні продукти у вигляді наборів окремих програмних фрагментів, кожен з яких може відноситися до своєї тематичної області, виконувати окрему функцію і мати свій власний квант часу, відведений йому для роботи. Кожен такий фрагмент називається завданням. Сервіси у розглянутій групі мають здатність запускати завдання і присвоювати їм пріоритети. Основний сервіс тут - планувальник завдань. Він здійснює контроль за виконанням поточних завдань, запускає нові у відповідний період часу і стежить за режимом їх роботи.
Динамічний розподіл пам'яті. Багато хто (але не всі) ядра ОСРВ підтримують цю групу сервісів. Вона дозволяє завданням запозичувати області оперативної пам'яті для тимчасового використання в роботі додатків. Часто ці області згодом переходять від завдання до завдання, і за допомогою цього здійснюється швидка передача великої кількості даних між ними. Деякі дуже малі за розміром ядра ОСРВ, які передбачається використовувати в апаратних середовищах з суворим обмеженням на обсяг використовуваної пам'яті, не підтримують сервіси динамічного розподілу пам'яті.
Управління таймерами. Так як вбудовані системи пред'являють жорсткі вимоги до тимчасових рамок виконання завдань, до складу ядра ОСРВ включається група сервісів, що забезпечують керування таймерами для відстеження ліміту часу, протягом якого повинна виконуватися задача. Ці сервіси вимірюють і задають різні проміжки часу (від 1 мкс і вище), генерують переривання після закінчення тимчасових інтервалів і створюють разові і циклічні будильники.
Взаємодія між завданнями і синхронізація. Сервіси цієї групи дозволяють завданням обмінюватися інформацією та забезпечують її збереження. Вони так само дають можливість програмним фрагментами погоджувати між собою свою роботу для підвищення ефективності. Якщо виключити ці сервіси зі складу ядра ОСРВ, то завдання почнуть обмінюватися спотвореною інформацією і можуть стати перешкодою для роботи сусідніх завдань.
Контроль пристрої введення / виведення. Сервіси цієї групи забезпечують роботу єдиного програмного інтерфейсу, що взаємодіє з усім безліччю драйверів пристроїв, які є типовими для більшості вбудованих систем.

  На додаток до сервісів ядра, багато ОСРВ пропонують лінійки додаткових компонентів для організації таких високорівневих понять, як файлова система, мережеве взаємодія, управління мережею, управління базою даних, графічний користувальницький інтерфейс і т. д. Хоча багато з цих компонентів набагато більше і складніше, ніж саме ядро ​​ОСРВ, вони, тим не менш, грунтуються на його сервісах. Кожен з таких компонентів включається у вбудовану систему, тільки якщо її сервіси необхідні для виконання вбудованого програми і тільки для того, щоб звести витрата пам'яті до мінімуму.
Відмінності від операційних систем загального призначення

  Багато операційні системи загального призначення також підтримують зазначені вище сервіси. Проте ключовою відмінністю сервісів ядра ОСРВ є детермінований, заснований на суворому контролі часу, характер їх роботи. В даному випадку під детермінованістю розуміється те, що для виконання одного сервісу операційної системи потрібно часовий інтервал завідомо відомою тривалості. Теоретично цей час може бути обчислено за математичними формулами, які повинні бути строго алгебраїчними і не повинні включати ніяких часових параметрів випадкового характеру. Будь випадкова величина, що визначає час виконання завдання в ОСРВ, може викликати небажану затримку в роботі програми, тоді наступна задача не вкладеться в свій квант часу, що послужить        причиною       для    помилки.                                                                          

  У цьому сенсі операційні системи загального призначення не є детермінованими. Їх сервіси можуть допускати випадкові затримки в своїй роботі, що може привести до уповільнення реакції програми на дії користувача в завідомо невідомий момент часу. При проектуванні звичайних операційних систем розробники не акцентують свою увагу на математичному апараті обчислення часу виконання конкретного завдання і сервісу. Це не є критичним для подібного роду систем. [8]

Планування завдань

Робота    планувальника
Основна стаття:

Планувальник завдань (сервіс)

  Більшість ОСРВ виконують планування завдань, керуючись наступною схемою. Кожній задачі в додатку ставиться у відповідність деякий пріоритет. Чим більше пріоритет, тим вище повинна бути реактивність завдання. Висока реактивність досягається шляхом реалізації підходу пріоритетного витісняє планування (preemptive priority scheduling), суть якого полягає в тому, що планувальником дозволяється зупиняти виконання будь-якої задачі в довільний момент часу, якщо встановлено, що інша задача повинна бути         запущена        негайно.

  Описана схема працює за наступним правилом: якщо два завдання одночасно готові до запуску, але перша має високий пріоритетом, а друга низьким, то планувальник віддасть перевагу першій. Друге завдання буде запущена тільки після того, як завершить свою роботу перша.

  Можлива ситуація, коли завдання з низьким пріоритетом вже запущена, а планувальник отримує повідомлення, що інша задача з більш високим пріоритетом готова до запуску. Причиною цьому може послужити небудь зовнішній вплив (переривання від обладнання), як, наприклад, зміна стану перемикача пристрою, керованого ОСРВ. У такій ситуації планувальник завдань поведеться згідно підходу пріоритетного витісняє планування наступним чином. Задачі з низьким пріоритетом буде дозволено виконати до кінця поточну асемблерних команду (але не команду, описану в исходнике програми мовою високого рівня), після чого виконання завдання зупиняється. [8] Далі запускається завдання з високим пріоритетом. Після того, як вона опрацьовує, планувальник запускає перервану перше завдання з асемблерній команди, наступної за останньою виконаною.

  Кожен раз, коли планувальник завдань отримує сигнал про настання деякої зовнішньої події (тригер), причина якого може бути як апаратна, так і програмна, він діє за наступним алгоритмом.

  Визначає, чи повинна поточна виконувана завдання продовжувати працювати.Встановлює, яке завдання повинна запускатися наступної.Зберігає контекст зупиненої завдання (щоб вона потім відновила роботу з місця зупинки)
Встановлює контекст для наступного завдання Запускає цю задачу.

  Велику частину часу основна маса завдань заблокована. Тільки одне завдання може виконуватися на центральному процесорі в поточний момент часу. У примітивних ОСРВ список готових до виконання завдань, як правило, дуже короткий, він може складатися не більше ніж з двох-трьох найменувань.

  Основна функція адміністратора ОСРВ полягає в складанні такого            планувальника завдань.

  Якщо в списку готових до виконання завдань останніх є не більше двох-трьох, то передбачається, що всі завдання розташовані в оптимальному порядку. Якщо ж трапляються такі ситуації, що число завдань у списку перевищує допустимий ліміт, то завдання сортуються         в         порядку           пріоритету.
Алгоритми планування

  В даний час для вирішення задачі ефективного планування в ОСРВ найбільш інтенсивно розвиваються два підходи.

Статичні алгоритми планування (RMS, Rate Monotonic Scheduling). Використовують пріоритетне витісняють планування. Пріоритет надається кожній задачі до того, як вона почала виконуватися. Перевага віддається завданням із самими короткими періодами виконання.
Динамічні алгоритми планування (EDF, Earliest Deadline First Scheduling). Пріоритет завданням присвоюється динамічно, причому перевага віддається завданням з найбільш раннім граничним часом початку (завершення) виконання.

  При великих завантаженнях системи EDF більш ефективний, ніж RMS.
Взаємодія між завданнями і поділ ресурсів

  Багатозадачним системам необхідно розподіляти доступ до ресурсів. Одночасний доступ двох і більше процесів до будь-якої області пам'яті або інших ресурсів представляє певну загрозу.
  ОСРВ зазвичай не використовують перший спосіб, тому що для користувача додаток не може контролювати процесор стільки, скільки хоче. Однак, у багатьох вбудованих системах і ОСРВ дозволяється запускати додатки в режимі ядра для доступу до системних викликів і дається контроль над оточенням виконання без втручання ОС.

  На однопроцесорних системах найкращим рішенням є додаток запущене в режимі ядра, якому дозволено блокування переривань. Поки переривання заблоковано, додаток використовує ресурси процесу одноосібно і ніяка інша задача або переривання не може виконуватися. Таким чином захищаються всі критичні ресурси. Після того як додаток завершить критичні дії, воно повинно розблокувати переривання, якщо такі є. Тимчасове блокування переривання дозволено тільки тоді, коли самий довгий проміжок виконання критичної секції менше, ніж допустимий час реакції на переривання. Зазвичай цей метод захисту використовується тільки коли довжина критичного коду не перевищує декількох рядків і не містить циклів. Цей метод ідеально підходить для захисту регістрів.

Коли довжина критичного ділянки більше максимальної або містить цикли, програміст повинен використовувати механізми ідентичні або імітують поведінку систем загального призначення.

Наступним проблемам виділення пам'яті в ОСРВ приділяється більше уваги, ніж в операційних системах загального призначення.

По-перше, швидкості виділення пам'яті. Стандартна схема виділення пам'яті передбачає сканування списку невизначеної довжини для знаходження вільної області пам'яті заданого розміру, а це неприйнятно, тому що в ОСРВ виділення пам'яті має відбуватися за фіксований час.

По-друге, пам'ять може стати фрагментованою в разі поділу вільних її ділянок уже запущеними процесами. Це може привести до зупинки програми через її нездатність задіяти нову ділянку пам'яті. Алгоритм виділення пам'яті, поступово збільшує фрагментованість пам'яті, може успішно працювати на настільних системах, якщо ті перезавантажуються не рідше одного разу на місяць, але є неприйнятним для вбудованих систем, які працюють роками      без     перезавантаження.

Простий алгоритм з фіксованою довжиною ділянок пам'яті дуже добре працює в нескладних вбудованих системах.

Також цей алгоритм відмінно функціонує і в настільних системах, особливо тоді, коли під час обробки ділянки пам'яті одним ядром наступну ділянку пам'яті обробляється іншим ядром. Такі оптимізовані для настільних систем ОСРВ, як Unison Operating System або DSPnano RTOS, надають зазначену можливість.

Відповіді на контрольні питання

2.Життєві цикли програмного забезпечення?

це безперервний процес, який починається з моменту прийняття рішення про необхідність створення ПЗ і закінчується в момент його повного вилучення з експлуатації.

Існує декілька підходів при визначенні фаз та робіт життєвого циклу програмного забезпечення (ЖЦПО), кроків процесу програмування, каскадна і спіральна моделі. Але всі вони містять загальні основні компоненти: постановка завдання, проектування рішення, реалізація, обслуговування.

Найбільш відомою і повної, мабуть, є структура ЖЦПО по Боемі, що включає вісім фаз. Вона і буде представлена ​​надалі найбільш детально.

Одним з можливих варіантів може послужити опис верхнього рівня з Леману, що включає три основні фази і що представляє опис ЖЦПО в самому загальному випадку.

І, для різноманітності, - наведемо кроки процесу програмування, представлені Д. Райлі в книзі «Використання мови Модула-2». Це подання, по-моєму, є досить простим і звичним, з нього і почнемо.

4.Типи вимог до ПЗ?

Види вимог за характером

Функціональний характер — вимоги до поведінки системи

Бізнес-вимоги

Вимоги користувача

Функціональні вимоги

Нефункціональний характер — вимоги до характеру поведінки системи

Бізнес-правила — визначають обмеження, о витікають з предметної області.

Системні вимоги — вимоги до програмних інтерфейсів, надійності, обладнанню.

Атрибути якості

Зовнішні системи та інтерфейси

Обмеження

11.Які є функціональні вимоги?

Функціональні вимоги пояснюють що має бути зроблено ідентифікацією необхідної задачі, дії, чи діяльності які мають виконуватись. Аналіз функціональних вимог буде використаний в функціях верхніх рівнів для функціонального аналізу

12.Які є нефункціональні вимоги?

Нефункціональні вимоги - це вимоги що задають критерій для оцінки операцій системи, замість її поведінки.

13.Що визначає синтаксис?

Синтаксис (також синтакса, складня, грец. σύνταξις — «розкладання по полицях») — розділ граматики, що вивчає словосполучення та речення, їх будову, типи й об'єднання в надфразні одиниці, роль і значення частин мови та граматичних форм у реченні в синхронному й діахронному (історичному) перекрої.

Синтаксис • граматична будова речень та словосполучень у мові та закономірності їхнього функціонування в мовленні; • галузь мовознавства, розділ граматики, що вивчає закономірності сполучення слів і предикативних одиниць у реченні, будову, ознаки й типи речень і висловлень. Розмежовують: синтаксис словосполучень, який установлює синтаксичні властивості окремих слів як частин мови, тобто правила їхньої сполучуваності з іншими словами; синтаксис речень, спрямований на дослідження типів, ознак речень, зв'язків слів і сполук у складі речення і висловлення.

14.Що визначає семантика

Сема́нтика мовна (давніше семасіологія) — розділ мовознавства, пов'язаний з лексикологією; вивчає значення (теж у діяхронному, іст. перекрої) слів і їх складових частин, словосполук і фразеологізмів. Слово походить від грецького слова σημαντικός (семантікос), «значимий», з σημαίνω (семаіно), «значити, вказувати» та також від σήμα (сема), «знак, позначка, символ».

Походить від семантики пов`язаної з визначенням символізму знаків (символи, зображення, ієрогліфи, клинописні знаки, кодові знаки та символьні зображення в астрономії, правилах дорожнього руху, значки в інтернеті).

Слова за звуковою формою і взаємопов'язанням значеннєвих піль поділяються на полісемні (ручка, гатити) й моносемні (кисень — в узагальненому чи словниковому й конкретному вживанні); виділяються гомоніми (омоніми) (пара), пароніми (рибалка, рибак), антоніми (білий, чорний) й синоніми (блакитний, голубий), за емоційним забарвленням на чуттєвоневтральні з номінативно-комунікативною функцією (назви конкретних речей: побутовізми, технічні професіоналізми й наукові термінологізми та абстрактизми — димар, шило, вуглець, доброта) й чуттєво-забарвлені, що виявляють ще й ставлення мовця до називаної речі чи дії (пейоративізми, в тому числі аротизми й сленґізми — ножище, ходуля, куля, каліка 'нога', пестливі — ніж(еч)ка, евфемізми й табуїзми — нічний метелик, дівчина легких звичаїв 'повія', лихий 'чорт' урочисті й поетизми — правиця, десниця, рам'я 'рука', що за походженням можуть бути спершу історичними — архаїзми й неологізми — чи географічними алотопізмами — етранжизми, діалектизми). Їх функційне застосування вивчає стилістика. Систематичного викладу української семантики нема.

Питання семантики переважно висвітлювалися в працях нормативно-стилістичного характеру і в працях про мову окремих письменників або жанрів (М. Левицький, Іван Огієнко, В. Сімович, М. Сулима, М. Гладкий, І. Троян, Б. Ткаченко, В. Ващенко, І. Чередниченко, І. Білодід, Алла Коваль та ін.). Матеріали з семантики окремих слів і груп слів містили журнали, насамперед «Рідна мова» (ред. Іван Огієнко, 1933–1939) і «Питання мовної культури» (редактор М. Жовтобрюх, потім Й. Багмут, пізніше Віталій Русанівський, 1967 і далі; від 1971 п. н. «Рідне слово»).

15.Що визначає прагматика?

Прагма́тика (грец. pragma: справа, дія) — розділ семіотики, що висвітлює стосунки між учасниками комунікації, адресантом та адресатом, мовцем і слухачем, відмінний від семантики, яка вивчає відношення означника до означуваного, та синтактики, що досліджує зв'язки між знаками.

Прагматика стала методом філософії мови, відмежовується від широкого розуміння тексту, тлумачить його як механізм спілкування та риторичного структурування у відповідному, зокрема художньому, контексті.

Познавательные статьи:



Техника прыжка в длину с разбега

Тактические действия в защите

История Олимпийских игр

История развития права интеллектуальной собственности