Теоретический вопрос №2. Обзор ChorusOS

Автор работы: Пользователь скрыл имя, 19 Июня 2013 в 10:59, контрольная работа

Описание работы

SCADA-система TRACE MODE содержит средства разработки операторского интерфейса (SCADA/HMI), программирования контроллеров (Softlogic), управления основными фондами (EAM), персоналом (HRM) и производственными процессами (MES).
Все программы, входящие в TRACE MODE, подразделяются на две группы:
инструментальную систему разработки
исполнительные модули (runtime).

Содержание работы

1 Теоретический вопрос №1. Характеристика и архитектура системы Trace Mode. 2
2 Теоретический вопрос №2. Обзор ChorusOS7
2.1 Название СРВ и стандарты 7
2.2 Назначение и область применения ChorusOS 7
2.3 Выполняемы функции. Функциональная архитектура 7
2.4 Архитектура ChorusOS 9
2.5. Технические характеристики 10
2.6 Характеристики ChorusOS 11
2.7 Сведения об использование 11
2.8 Электронная документация 12
3 Практическое задание 13
Список используемой литературы: 24

Файлы: 1 файл

контрольная.docx

— 482.77 Кб (Скачать файл)

Понятие “актор” в ChorusOS определяется как единица загрузки для приложения. Оно также служит единицей инкапсуляции для того, чтобы сопоставить все системные ресурсы, используемые приложением, и потоки, выполняющиеся внутри актора. Примерами таких ресурсов являются потоки, регионы памяти и конечные точки взаимодействия.

Необязательные компоненты ОС ChorusOS 5.0 разбиваются в соответствии с функциональностью:

  • Управление деятельностью (Actor management) включает поддержку расширения режима пользователя, динамические библиотеки, управление сжатыми файлами;
  • Планирование (Scheduling) включает планирование в стиле FIFO (first-in-first-out), разностильное планирование (multi-class scheduling), циклическое планирование (round-robin), планирование в режиме реального времени;
  • Управление памятью включает, кроме распределения памяти, поддержки аппаратной защиты и подкачки, еще и статистику микроядра, события системы Solaris, метрики операционной системы;
  • Работоспособность (High Availability) включает горячий рестарт, сторожевой таймер (Watchdog timer), черный ящик, дамп системы;
  • Синхронизация потоков включает семафоры, наборы флагов событий, мьютексы, монопольные блокировки, обеспечивающие отсутствие инверсии приоритетов;
  • Управление временем включает периодические таймеры, потоковый виртуальный таймер, дата и время, датчик реального времени, переменные окружения;
  • Взаимодействие потоков включает независимое от местонахождения взаимодействие, поддержку удаленного взаимодействия, механизм взаимодействия через почтовые ящики, синхронизацию между потоками, приватные данные потока, а также такие средства взаимодействия системы POSIX, как семафоры, сокеты, потоки, таймеры, очереди сообщений, объекты разделяемой памяти, сигналы реального времени;
  • Инструментальная поддержка включает системную журнализацию, регистрацию ошибок, поддержку профилирования и контрольных точек, мониторинг системы, отладку системы, дамп ядра;
  • Поддержка языка C включает командный интерпретатор на целевом компьютере, удаленный shell;
  • Поддержка файловой системы включает именованные каналы, NFS-клиент, NFS-сервер, файловые системы MS-DOS, PDE, /proc, UFS, ISO9000;
  • Управление вводом/выводом включает поддержку драйверов некоторых устройств;
  • Сетевая поддержка включает поддержку некоторых сетевых протоколов.

2.4 Архитектура ChorusOS

Архитектура ОС ChorusOS является многослойной, основанной на компонентах (component-based). Микроядро содержит минимальный набор компонентов, необходимых для функционирования ОС

  • kern — реализует интерфейс микроядра и содержит актор KERN, вспомогательную библиотеку и заголовочные файлы,
  • менеджер приватных данных (pd) реализует интерфейс между подсистемами микроядра,
  • менеджер постоянной памяти (pmm) реализует интерфейс постоянной памяти,
  • core executive обеспечивает существенную часть поддержки реального времени.

 

2.5. Технические  характеристики

Разработчик - Chorus Systèmes / Sun Microsystems

Семейство ОС - ОС РВ

Последняя версия  - 5.1 —

Поддерживаемые платформы - x86/68k/PPC/SPARC/ARM/MIPS

Тип ядра – микроядро

2.6 Характеристики ChorusOS

Модель - процессы/акторы/потоки

Политики планирования - FIFO с приоритетами, циклическое, планирование реального времени, опция одновремен. выполнения различных политик планирования, возможность создания собственного планировщика

Механизмы синхронизации/ взаимодейст - мьютексы, мьютексы реального времени, семафоры, флаги событий, LAP (Local Access Point), IPC (Inter-Process Communication) – сообщения, порты, группы портов, MIPC (почтовые. ящики), разделяемая память, очереди сообщений

Модель защиты – без защиты, защищённая память, защита виртуальной памяти.

Поддержка MMU - да или нет (зависит от конфигурации)

Виртуаль-ная память

Подкачка

Вызов стр. по запросу

POSIX - POSIX-сигналы, сигналы реального времени, потоки, таймеры, очереди сообщений, семафоры. сокеты, разделяемая память

Целевые платформы - UltraSPARC II (CP1500 и CP20x0), Intel x86, Pentium, Motorola PowerPC 750 и 74x0 (mpc7xx), Motorola PowerQUICC I (mpc8xx) и PowerQUICC II (mpc8260)

Распределенная обработка - Прозрачный доступ к удаленным ресурсам

Сетевые протоколы - IPv4, IPv6, PPP, NTP, BFP, DHCP NFS, RPC, LDAP, FTP, Telnet

Файловые системы - UFS, FIFOFS, NFS, MSDOSFS, ISOFS, PROCFS, PDEVFS

2.7 Сведения об  использование

ОС ChorusOS 5.0 лежит в основе операционной среды Solaris и поддерживает следующие целевые платформы:

  • UltraSPARC II (CP1500 и CP20x0),
  • Intel x86, Pentium,
  • Motorola PowerPC 750 и семейство процессоров 74x0 (mpc7xx),
  • Motorola PowerQUICC I (mpc8xx) и PowerQUICC II (mpc8260) (микроконтроллеры).

2.8 Электронная документация

    • http://ru.wikipedia.org/wiki/ChorusOS
    • http://www.citforum.idknet.com/operating_systems/rtos/13.shtml
    • http://www.studfiles.ru/dir/cat32/subj1451/file16334/view156454/page4.html

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Практическое задание

Система управления ВПЧА имеет  иерархическую структуру и предназначена  для сбо- ра, обработки и отображения  данных, получаемых с подчиненных  модулей. Система управ- ления состоит  из Головной станции управления преобразователем – промышленного компь- ютера  с ОС реального времени. В его  задачи входит задание режимов работы всех подчи- ненных модулей ЦСУ: модуля управления инвертором, модулями управления трехфазного тиристорного выпрямителя, измерительными модулями, модулями защиты; обеспечение ре- гулирования технологических  параметров нагрузки, сбор и хранение диагностических дан- ных, связь  с более высокими уровнями, например, через Интернет или по специальным  ли- ниям связи;отображение данных в  удобной для оператора форме.

Для взаимодействия головной станции с модулями разработаны  протоколы обмена данными между  блоками СУ. Головная станция (HOST) соединена  с модулями по кольцевой топологии, где данные передаются последовательно  в одном направлении от одного модуля другому. Промышленный компьютер  инициирует любую передачу данных, а модули явля- ются ведомыми и не могут самостоятельно инициировать обмен, за исключением дейта- грамм  об ошибках.

Рис.1. Схема соединения модулей

Все модули оснащены микроконтроллером (МК) и взаимодействуют с каналом  пере- дачи данных посредством модуля UART. Для обеспечения связанности  в кольце в станции имеются  кроме модуля UART, два дополнительных буфера. Данные буферы производят фи- зическую коммутацию канала передачи данных, осуществляя  подключение передатчика UART МК к  каналу передачи данных, или поддержание  связанности кольца.

Промышленный компьютер, выполняющий функции головной станции  управления преобразователем, построен на одноядерном чипсете Mobile Intel 945 с  использованием 2ГБ оперативной памяти. Обмен информацией с регистрирующими  и измеряющими модулями выполняется  по 8-ми последовательным портам, имеющим  каждый FIFO-буффер емкостью в 512 байт. Параметры  с контроллеров модулей измерений  на входе и выходе выпрямителя передаются в головную станцию через 10 мс на последовательные порты, работающие с битовой скоростью 19 200 bit/s. Модули управления вентильным блоком выпрямителя и инвер- тора взаимодействуют с промышленным компьютером на скорости в 57 600 bit/s.

Операционная система  реального времени должна гарантировать  успешность работы любой программы  в зависимости не только от её логической правильности, но и от времени, за которое  она выполнила заданные функции. Если система не может удовлетворить  времен- ным ограничениям, должен быть зафиксирован сбой в её работе. Заданные условия времен- ной обработки  массива параметров, поступающих  с датчиков системы управления ВПЧА по восьми COM – портам в промышленный компьютер, предъявляют повышенные требования к выбору операционной системы  реального времени.

По стандарту POSIX 1003.1 ОСРВ определяется как: «Реальное время  в операционных системах — это  способность операционной системы  обеспечить требуемый уровень сервиса  в определённый промежуток времени». Существуют операционные системы мягкого  и жест- кого реального времени, однако система аппаратного управления должна работать с операционной системой жесткого реального времени. Она  характеризуется минимальными задержками реакции на событие и выполняет  заданные процессом задачи функции  в строго указанное время. Жесткие  системы не допускают задержек, так  как они могут привести к не- предсказуемым последствиям, потери результатов, авариям или большим  финансовым потерям. В них предусмотрена  обработка критических ситуаций, позволяющая прерывать или блокировать  медленные процессы, реализуя выполнение требований надежности и готовности остальной части системы.

ОСРВ строятся по монолитной, уровневой (слоевой) и клиент-серверной  архитектурам. Монолитная архитектура  обладает плохой предсказуемостью взаимодействия модулей сложного ядра в работе с  аппаратурой системы. Уровневая  архитектура позволяет работать с аппаратурой не только через  ядро, но и обращаться напрямую. Архитектура  «клиент-сервер» выносит сервисы  ОС в виде серверов на уровень пользователя и выполняет микроядром функции  диспетчера сообщений между клиентскими  пользовательскими программами  и сер- верами – системными сервисами. Такая архитектура позволяет  повысить надежность, обеспечить хорошую  масштабируемость и повышенную отказоустойчивость.

В настоящий момент широкое  распространение получили QNX, RTX для Windows и RTKernel для DOS.

QNX — коммерческая POSIX-совместимая  операционная система реального  времени, предназначенная преимущественно  для встраиваемых систем. Считается  одной из лучших реализаций  концепции микроядерныхоперационных  систем.

Это юниксоподобная, POSIX-совместимая, многозадачная, многопользовательская, многопоточная, встраиваемая, легко  и гибко масштабируемая операционная система реального времени и  в отличие от Linux и BSD не требует  пересборки ядра - любые модули могут  подключаться и отключаться на лету. Кроме того, ее производительность высока, несмотря на то, что в ней  используется защищенная модель памяти, а не принцип единого адресного  пространства, характерный для ОСРВ. Есть открытая версия GNU GPL аналогичной  операционной системы реального  времени под названием ChorusOS (возможно, что QNX является подражанием Chorus) разработанная  фирмами Sun Microsystems, Alcatel и ABB. Гостехкомиссия сертифицировала защищенную операционную систему реального времени QNX 4.25 как изделие КПДА.00002-01 по 3 классу защиты от несанкционированного доступа (НСД) и 2 уровню контроля отсутствия не декларированных возможностей (НДВ) за № 906 ФСТЭК России. В сертификате  изделие определено как защищённое средством вычислительной техники (СВТ), которое может быть использовано при создании автоматизированных систем (АС), имеющих класс защищённости до 1Б включительно. В настоящее  время ФСТЭК Рос- сии продлила действие сертификата соответствия № 906 до 30.05.2013 и подтвердила соответствие программных обновлений соответствующим  классам защиты. В новой версии добавлена поддержка графических  приложений Photon и в состав изделия  включены модули Photon Runtime, а так же средства поддержки русского языка SWD CyrPack и Photon Cyrillic Supplement. С 2005 года стартовал  процесс сертификации следующей  ЗОСРВ на базе технологий QNX6 "Нейтрино" и завершился утверждением изделия  КПДА.10964-01, с определением соответствия 3 классу защиты от несанкционированного доступа (НСД3).

Система QNX состоит из небольшого ядра (микроядра) и набора взаимодействующих  процессов. Как показано на рис. 1, система  не имеет иерархической структуры, ее организация скорее напоминает "спортивную команду", в которой игроки (процессы), имеющие равную значимость, взаимодействуют  друг с другом и со своим "ведущим  игроком" (ядром).

Рис. 2. Микроядро системы QNX координирует работусистемных администраторов.

 

Ядро является "сердцем" любой операционной системы. В некоторых  системах на ядро возложено такое  количество функций, что, по сути дела, оно само является полной операционной системой. В системе QNX ядро является действительно ядром и имеет  небольшой размер, менее 8 Кбайт. На ядро системы QNX возложено выполнение только двух основных функций:

передача сообщений (ядро реализует передачу всех сообщений  между всеми процессами во всей системе);

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

 

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

Все функции, выполняемые  операционной системой QNX, за исключением  функций ядра, реализуются стандартными процессами. В типичной конфигурации системы QNX имеются следующие системные  процессы:

Администратор процессов (Proc);

Администратор файловой системы (Fsys);

Администратор устройств (Dev);

Сетевой администратор (Net).

Системные процессы и процессы пользователя

Системные процессы практически  ничем не отличаются от любого процесса пользователя: у них нет специального или скрытого интерфейса, недоступного процессу пользователя.

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

Действительно, грань между  операционной системой и прикладными  программами весьма условна. Единственным принципиальным отличием системных  процессов от прикладных является то, что системные процессы управляют  ресурсами системы, предоставляя их прикладным процессам.

Драйверы устройств - это  процессы, которые избавляют операционную систему от необходимости иметь  дело со всеми особенностями работы аппаратного обеспечения.

Информация о работе Теоретический вопрос №2. Обзор ChorusOS