Автор работы: Пользователь скрыл имя, 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
Понятие “актор” в ChorusOS определяется как единица загрузки для приложения. Оно также служит единицей инкапсуляции для того, чтобы сопоставить все системные ресурсы, используемые приложением, и потоки, выполняющиеся внутри актора. Примерами таких ресурсов являются потоки, регионы памяти и конечные точки взаимодействия.
Необязательные компоненты ОС ChorusOS 5.0 разбиваются в соответствии с функциональностью:
Архитектура ОС ChorusOS является многослойной, основанной на компонентах (component-based). Микроядро содержит минимальный набор компонентов, необходимых для функционирования ОС
Разработчик - Chorus Systèmes / Sun Microsystems
Семейство ОС - ОС РВ
Последняя версия - 5.1 —
Поддерживаемые платформы - x86/68k/PPC/SPARC/ARM/MIPS
Тип ядра – микроядро
Модель - процессы/акторы/потоки
Политики планирования - 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
ОС ChorusOS 5.0 лежит в основе операционной среды Solaris и поддерживает следующие целевые платформы:
Система управления ВПЧА имеет
иерархическую структуру и
Для взаимодействия головной станции с модулями разработаны протоколы обмена данными между блоками СУ. Головная станция (HOST) соединена с модулями по кольцевой топологии, где данные передаются последовательно в одном направлении от одного модуля другому. Промышленный компьютер инициирует любую передачу данных, а модули явля- ются ведомыми и не могут самостоятельно инициировать обмен, за исключением дейта- грамм об ошибках.
Рис.1. Схема соединения модулей
Все модули оснащены микроконтроллером (МК) и взаимодействуют с каналом пере- дачи данных посредством модуля UART. Для обеспечения связанности в кольце в станции имеются кроме модуля UART, два дополнительных буфера. Данные буферы производят фи- зическую коммутацию канала передачи данных, осуществляя подключение передатчика UART МК к каналу передачи данных, или поддержание связанности кольца.
Промышленный компьютер,
выполняющий функции головной станции
управления преобразователем, построен
на одноядерном чипсете Mobile Intel 945 с
использованием 2ГБ оперативной памяти.
Обмен информацией с
Операционная система реального времени должна гарантировать успешность работы любой программы в зависимости не только от её логической правильности, но и от времени, за которое она выполнила заданные функции. Если система не может удовлетворить времен- ным ограничениям, должен быть зафиксирован сбой в её работе. Заданные условия времен- ной обработки массива параметров, поступающих с датчиков системы управления ВПЧА по восьми 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 и подтвердила соответствие
программных обновлений соответствующим
классам защиты. В новой версии
добавлена поддержка
Система QNX состоит из небольшого ядра (микроядра) и набора взаимодействующих процессов. Как показано на рис. 1, система не имеет иерархической структуры, ее организация скорее напоминает "спортивную команду", в которой игроки (процессы), имеющие равную значимость, взаимодействуют друг с другом и со своим "ведущим игроком" (ядром).
Рис. 2. Микроядро системы
QNX координирует работусистемных
Ядро является "сердцем" любой операционной системы. В некоторых системах на ядро возложено такое количество функций, что, по сути дела, оно само является полной операционной системой. В системе QNX ядро является действительно ядром и имеет небольшой размер, менее 8 Кбайт. На ядро системы QNX возложено выполнение только двух основных функций:
передача сообщений (ядро реализует передачу всех сообщений между всеми процессами во всей системе);
планирование (планировщик является частью ядра и подключается каждый раз, когда процесс меняет свое состояние в результате появления сообщения или прерывания).
В отличие от процессов само ядро никогда не планируется к выполнению. Управление передается ядру только в результате прямого вызова ядра либо из процесса, либо по аппаратному прерыванию.
Все функции, выполняемые операционной системой QNX, за исключением функций ядра, реализуются стандартными процессами. В типичной конфигурации системы QNX имеются следующие системные процессы:
Администратор процессов (Proc);
Администратор файловой системы (Fsys);
Администратор устройств (Dev);
Сетевой администратор (Net).
Системные процессы и процессы пользователя
Системные процессы практически ничем не отличаются от любого процесса пользователя: у них нет специального или скрытого интерфейса, недоступного процессу пользователя.
Именно такая архитектура обеспечивает системе QNX неограниченную расширяемость. Поскольку большинство функций QNX выполняется стандартными системными процессами, то расширить операционную систему совсем не сложно: достаточно написать и включить в системупрограмму, реализующую новую функцию ОС.
Действительно, грань между операционной системой и прикладными программами весьма условна. Единственным принципиальным отличием системных процессов от прикладных является то, что системные процессы управляют ресурсами системы, предоставляя их прикладным процессам.
Драйверы устройств - это процессы, которые избавляют операционную систему от необходимости иметь дело со всеми особенностями работы аппаратного обеспечения.