а. Программное обеспечение систем управления

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ

5.1. ПАКЕТ ДЛЯ ПРОЕКТИРОВАНИЯ СКУ ТП RTWin

Разрешите представить разработку российской фирмы “SWD Систем Реального Времени” – пакет RTWin.

RTWin представляет собой мощный и гибкий инструмент для проектирования СКУ технологическими процессами, представляющий разработчику все возможности для создания модульной распределенной и масштабируемой СКУ, функционирующей в реальном масштабе времени. Пакет относится к классу систем автоматизированного проектирования СКУ – по международной классификации Computer Aided Control System Desing (CACSD). RTWin разработан как универсальная система, которая может найти применение в различных отраслях промышленности. Как интегрированный пакет, обеспечивающий полный цикл разработки и функционирования СКУ, RTWin состоит из

· среды разработки, включающей редакторы ресурсов для проектирования СКУ;

· среды исполнения включающей администраторы соответствующих ресурсов и обеспечивающих функционирование СКУ.

Рекомендуемые материалы

1. 5.1.1. Модули RTWin

Концепция RTWin основана на модульной и открытой структуре системы контроля и управления. В общем случае в составе системы контроля и управления технологическим процессом можно выделить функционально-законченные части-модули. Эти модули взаимодействуют между собой путем обмена данными. Таким образом, можно представить СКУ как совокупность модулей, и имеющих входы и выходы и связанных между собой информационными потоками . RTWin исходит именно из такой модели представления СКУ и дает разработчику возможность проектировать, оперируя понятиями модулей системы и потоков данных. Поток данных представляет собой последовательность сообщений определенной длины и структуры. Модули в зависимости от своего функционального назначения могут быть отнесены к одному из следующих типов.

Объект реализует заданный на стадии разработки алгоритм. Это наиболее универсальный тип модуля, он позволяет решить широкий спектр задач, среди которых математические модели процессов, работа с устройствами ввода/вывода и файлами, подготовка данных для отображения, организация связи с другими программами и т.д. каждый объект реализован как самостоятельная загружаемая и исполняемая задача в среде многозадачной ОС QNX. Для каждого объекта генерируется полный исходный текст на языке программирования Си в стандарте ANSI C.

Панель управления реализует графический интерфейс с оператором СКУ. Внешний вид панели управления создается с использованием набора графических примитивов. Каждый графический примитив имеет определенный набор ресурсов (например цвет, координаты, размеры, форму курсора, текстовую строку и т.д.). Любое изменение состояния технологического процесса может быть отображено посредством тех или иных ресурсов. Поступающие на вход панели управления данные можно представить в виде текстовых строк, графиков и диаграмм. Кроме того, могут открываться дополнительные окна, меняться цвет, размер и координаты графических примитивов, что позволяет получить эффект анимации. На панели могут быть размещены различные органы управления: кнопки, сдвижки (слайдеры), линейки прокрутки и т. п. Для каждого органа управления может быть задан в виде числового значения уровень доступа оператора.

Объект – PhAB приложение предназначен для интеграции в состав СКУ произвольного приложения Photon, созданного с помощью построителя приложений Photon Application Builder.

Шлюз предоставляет возможность передавать данные между одновременно работающими СКУ.

Каждый объект и панель управления может иметь несколько копий в рамках одной СКУ. На входах и выходах модулей могут располагаться точки дополнительной обработки данных, которые позволяют одновременно с передачей данных выполнять с ними такие операции, как сохранение в оперативной БД, проверка условий возникновения тревог, просмотр в виде таблиц и графиков.

RTWin предоставляет возможность оперативно выявлять состояния контролируемого процесса, которые требуют немедленного оповещения и реакции со стороны оператора или СКУ. Количество одновременно проверяемых условий для одной точки тревоги не ограничено. При этом для каждого условия может быть заданна индивидуальная обработка.

Создаваемые в RTWin СКУ базируются на принципе «авторизованного» вмешательства. Этот принцип подразумевает принадлежность любого вмешательства в работу СКУ конкретному человеку.

Таким образом, модульная архитектура создаваемых в RTWin СКУ обуславливает такие важные практические свойства, как:

· многозадачность и распределенность – модули СКУ могут быть размещены на различных компьютерах – узлах локальной сети, что дает возможность их параллельного выполнения и позволяет оптимальным образом использовать аппаратные ресурсы в вычислительной системы;

· многопользовательский режим – при распределении панелей управления СКУ по различным узлам сети появляется возможность одновременной работы нескольких операторов (пользователей);

· маштабируемость – с помощью RTWin можно создавать СКУ любой сложности: от простейших, содержащих одну панель управления и один – два объекта и работающих на одном компьютере, до сложных многопользовательских систем, состоящих из десятков модулей, работающих в локальной сети;

· конфигурируемость – RTWin дает возможность легко изменять состав запускаемых модулей и их распределение по узлам локальной сети;

· наращиваемость – используя RTWin, можно создать достаточно сложную СКУ методом поэтапного наращивания выполняемых функций.

      Можно начать с простого, создать «скелет» системы, а затем постепенно добавлять новые модули. Такой способ очень эффективен, так как при этом на каждом шаге есть возможность запустить систему и произвести отладку.

Понятие открытой архитектуры подразумевает:

· доступность расширения функциональных возможностей системы разработчиком – очевидно, что невозможно заранее предусмотреть в CACSD-пакете все функциональные возможности по организации интерфейса с оператором и обработке данных, которые могут когда-либо понадобиться разработчику. Особенно это актуально для универсальной системы, рассчитанной на широкую область применения. Поэтому в RTWin предусмотрены механизмы расширения разработчиком функциональных возможностей по организации интерфейса с оператором(объект-PhAB приложение) и по обработке данных;

· возможность обмена информацией с другими системами – созданная RTWin СКУ имеет возможность обмена информацией как с другими СКУ(используя шлюзы), так и с любыми внешними по отношению к RTWin системами или программами.

2. 5.1.2. Разработка СКУ

Разработка СКУ ведется в режиме визуального проектирования. В среде разработки СКУ представляется в виде модульной схемы, включающей модули и связи между ними, а также точки дополнительной обработки данных. Проектировщик создает СКУ путем поэтапного наращивания.

На первом этапе определяются структуры данных и объекты. Алгоритмы работы объектов задаются в виде совокупности блок-функций.

Следующий этап предусматривает создание панелей управления. Графический редактор RTWin позволяет в короткие сроки нарисовать внешний вид панелей управления за счет использования библиотек графических объектов.

После задания внешнего вида задается функциональность панели управления, т.е. данные, поступающие на входы панели управления, связываются с ресурсами графических элементов.

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

На последнем этапе разработки RTWin генерирует СКУ в виде исходных текстов программ и готовых к запуску модулей.

5.1.3. Возможности RTWin

RTWin позволяет в короткие сроки создавать СКУ любой сложности в режиме визуального проектирования. При этом разработку можно вести одновременно на нескольких рабочих местах. RTWin предоставляет разработчику библиотеки алгоритмов обработки и моделирования данных и элементов графического интерфейса и вместе с тем позволяет создавать собственные библиотеки.

Конфигурация предусматривает любое распределение модулей по узлам QNX-сети непосредственно перед запуском СКУ.

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

RTWin обладает высокопроизводительной оперативной БД, позволяющей сохранять данные с частотой около 1000 записей в секунду на локальном компьютере 486DX4-100.

RTWin имеет драйверы для наиболее распространенных типов оборудования различных производителей.

RTWin позволяет задавать любое количество пользователей СКУ, обладающих соответствующими паролем и уровнем доступа. Доступ к информации и элементам управления осуществляется с учетом индивидуалдного уровня доступа пользователя.

В период работы СКУ с помощью специальной утилиты можно просмотреть данные, проходящие по каналам, в виде таблиц и графиков.

Наличие документации на русском языке обеспечивает простоту в освоении пакета.

RTWin на сегодняшний момент имеет больше десятка применений в различных отраслях промышленности. Среди наиболее крупных предприятий, использующих пакет, - Моллдавский металлургический завод в г. Рыбница, где RTWin установлен и работтает на полутора десятках узлов в рамках СКУ “Ковш-печь”, “Машина напрерывного литья заготовок” и “Печь для нагрева заготовок”. В “АСУ НефтеГаз” в г. Сургут на базе RTWin разработана СКУ удаленнымми терминалами нефтяного поромысла.

5.2. QNX-КОНТРОЛЛЕРЫ

5.2.1. Аппаратная платформа QNX-контроллеров

До последнего времени роль контроллеров в АСУТП в основном выполняли PLC (Programmable Logic Controller) зарубежного и отечественного производства. Среди иностранных наиболее популярны в нашей стране PLC фирм Allen-Bradley, Siemens, ABB, Modicon, а среди отечественных – Ломиконт, Ремиконт, Ш-711, ТКМ51. В связи с бурным ростом производства миниатюрных PC-совместимых компьютеров, наметилась тенденция их использования в качестве контроллеров напрямую связанная с концепцией открытой модульной архитектуры контроллеров – OMAC (Open Modular Architecture Controls) фирмы General Motors, выдвинутая в 1994 г.

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

Другие преимущества РС-контроллеров:

· быстродействие. Процессор Pentium превосходит быстродействие PLC более чем в 20 раз;

· дешевизна: при равных характеритиках РС-контроллеры на 20-30% дешевле PLC;

· объем ОЗУ: РС предоставляют больше памяти – как оперативной, так и энергонезависимой;

· чрезвычайно широкая номенклатура плат ввода-вывода;

· стандартизованные интерфейсы (ISA, PCI, VME и т.д.) протоколы (Profibus, CAN, Modbus), сетевые средства и протоколы (Ethernet, Token Ring; TCP/IP, IPX/SPX);

· разнообразные инструментальные средства программирования для разработки ПО контроллеров (ISAGRAF).

3. 5.2.2. Операционная система для контроллеров

Специфика условий работы контроллеров требует, чтобы ОС отвечала требованиям реального времени (РВ), компактности и возможности работы с ПЗУ.

Среди ОС РВ наилучшим образом подходит для РС-контроллеров ОС QNX. Это связано с тем, что архитектура QNX является открытой, модульной и легко модифицируемой. Она была разработана для компьютеров РС, что позволяет достигать такой эффективности и скорости обработки данных, какие обычно получают на мощных универсальных компьютерах.

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

4. 5.2.3. Средства технологического программирования контроллеров

Специфика работы с контроллерами по сравнению с обычными «офисными» компьютерами состоит не только в ориентации на работу с платами ввода-вывода, но и в преимущественном использовании языков технологического программирования, так как на предприятиях с контроллерами работают не программисты, а технологи, хорошо знающие специфику объектов управления и технологического процесса. Для их описания обычно используют языки релейно-контактных схем, функциональных блоков и другие, теоретические основы которых взяты из теории автоматического управления. Накопленный многими фирмами опыт в 1992 г. был обобщен в виде стандарта IEC 1131-3, в котором определено пять языков программирования: SFC – последовательных функциональных схем, LD – релейных диаграмм, FBD – функциональных блоковых диаграмм, ST – структурированного текста, IL - инструкций.

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

5.2.4. Встраиваемый QNX-контроллер RTP 6800

Котроллер RTP 6800 (производство фирмы Real Time Products) со встроенной ОС QNX спроектирован в соответствии с теми же стандартами, что и другие изделия RTP, которые удовлетворяют высоким требованиям безопасности. В RTP 6800 входят:

· встроенный контроллер для приложений пользователя;

· ОС QNX 4 и QNX TCP/IP;

· процессор 80486 DX;

· расширяемая память от 4 до 16 Мбайт;

· статическая память 512 Кбайт для приложений;

· встроенный контроллер Ethernet;

· аппаратура поддержки сети TCP/IP;

· два последовательных порта;

· аналоговые, цифровые и другие платы специального назначения.

5.2.5. QNX-контроллеры в стандарте VME.

В качестве примера можно привести котроллер VM5 фирмы OR. Это контроллер в формате 6U с процессором от Pentium-75 до Pentium-180, памятью 2...128 Мбайт EDO DRAM, FLASH-диском до 16 Мбайт, VGA адаптером, флоппи и IDE интерфейсом, Fast Ethernet-контроллером, двумя последовательными и двумя параллельными каналами, шиной PCI (до 132 Мбайт/с).

5.2.6. QNX-контроллер в стандарте ISA или PCI

Существует множество фирм, поставляющих QNX-контроллеры на базе ISA или PCI-шины (VNS0686 фирмы AdAstra Systems, VIPer807 фирмы Teknor Industrial Computers). В качестве примера рассмотрим две фирмы: ComputerBoards, поставляющую платы ввода-вывода, и Allen-Breadley, как фирму, традиционно ориентирующуюся на PLC.

Среди большого разнообразия плат ввода-вывода фирмы ComputerBoards выделим DAS08, DAS16 и семейство цифрового ввода-вывода. Семейство DAS08 включает в себя большой набор дешевых восьмиканальных плат сбора данных, предназначенных для решения широкого спектра такого рода задач. Семейство содержит платы с программируемым диапазоном, цифровым вводом-выводом и программируемыми таймерами. Многие из этих возможностей используются на одной плате для достижения максимальной эффективности и максимальной экономии в стоимости. Платы расширения обеспечивают аналоговое мультиплексирование, сигналы состояний, изоляцию, термоэлементы, клеммные соединения и лабораторное экспериментирование.

Семейство DAS16 включает в себя дешевые платы расширения для 16-канального аналогового ввода. Платы этой серии поддерживают скорости обмена в диапазоне от 100 кГц до 1 мГц. Мультифункциональные платы имеют аналоговые входы, цифровой ввод-вывод, аналоговый выход и три 16-битных счетчика на одной плате. Семейство цифрового ввода-вывода объединяет дешевые платы расширения цифрового ввода-вывода с шиной ISA. Цифровые платы обеспечивают ввод-вывод, специальные конфигурации входов или выходов до 192 линий. Для защиты от резких колебаний электропитания, ComputerBoards предлагает модули цифрового ввода-вывода с изоляцией на твердотельных реле. Монтажный каркас связывает эти отдельные модули с цифровыми платами. Для подключения средней нагрузки, которая не требует изоляции, оригинальные платы ComputerBoards с прямым управлением являются идеальным недорогим решением. Имеются конфигурации плат счетчика таймера с 5, 10 и 20 каналами, обеспечивающие экономичный подсчет событий, измерение частоты, один счетный или частотный выход. Для программирования плат ввода-вывода ComputerBoards можно использовать ISAGRAF с целевой задачей, поставляемой фирмой «Науцилус».

Allen-Breadley вместе с традиционными для этой фирмы PLC сейчас предлагает новое семейство контроллеров под названием 1747-ОС (Open Controller). Процессорный модуль этого контроллера включает в себя Cyrix 586/100 Мгц CPU, таймер, встроенные часы, watchdog-таймер, до 32 Мбайт RAM, 4,10, 20 или 60 Мбайт IDE с FLASH-памятью, слотами расширения PCI. Поставляется QNX API и QNX-драйвер для 1747-ОС.

4.2.7. Применение операционной системы QNX.

Основное применение ОС РВ (Операционная система реального времени) QNX находит в области промышленной автоматизации, где требуется применение «жесткого» РВ а также в таких областях как банковское дело, торговля, информационные системы, в которых нужно «мягкое» РВ.

Рассмотрим систему исполнения для встраиваемых приложений ISAGRAF для QNX, которая обеспечивает поддержку всех пяти языков стандарта IEC 1131-3 и позволяет создавать программное обеспечение для интеллектуальных контроллеров.

Система ISAGRAF состоит из двух подсистем: разработки (ISAGRAF Workbench) и исполнения (ISAGRAF Target). Программы на ISAGRAF может быть загружена и исполнена на компьютере IBM PC под управлением MS-DOS, Windows NT, Windows 95-98, QNX, LINX, и др. систем. Система разработки компилирует проект в системно-независимый код, который загружается в целевую машину для исполнения. Система исполнения либо загружается либо прожигается в ПЗУ целевой машины. Она включает в себя ядро ISAGRAF и набор модулей связи. Вместе со SCADA-системами под управлением ОС QNX получается функционально-законченное решение для АСУТП (рис.5.1.).

Рисунок 5.1. Взаимодействие компонентов АСУТП под управлением ОС QNX

Программирование логики ISAGRAF ведется с использованием графических языков программирования (SFC, LD, FBD), текстовых языков программирования (IL, ST), дополнительных интерактивных редакторов для описания переменных и конфигураций ввода-вывода.

Язык SFC дает возможность описать логику программы на уровне чередующихся функциональных блоков и условных переходов. Инструкции могут быть написаны на одном из четырех языков. Язык LD используется для описания различных логических выражений и реализует такие элементы, как открытый и закрытый контакты, функции и функциональные блоки. Язык FBD позволяет строить комплексную процедуру, состоящую из различных функциональных блоков библиотеки ISAGRAF. Язык ST относится к языкам высокого уровня и по мнемонике похож на PASCAL. Он служит для создания процедур со сложной логикой. Язык IL принадлежит к классу языков низкого уровня и позволяет создавать высокоэффективные функции.

· Система ISAGRAF включает в себя программы:

· Qisaker – целевая задача;

· Qisatst – задача связи с системой разработки через последовательный порт;

· Qisanet – то же, через Ethernet TCP/IP;

· Qisarfl – доступ к базе данных ISAGRAF из SCADA-пакетов.

Для повышения времени реакции, система ISAGRAF для QNX разделена на два процесса: программу связи (Qisatst, Qisanet или Qisarfl) и прикладную целевую задачу (Qisaker). Такая архитектура позволяет запускать до четырех задач с одной и той же целевой задачей или до четырех задач с одной и той же задачей связи. Это обеспечивает работу через один и тот же порт с четырьмя целевыми задачами, выполняющий разные программы.

Целевая задача (Qisaker) и задача связи (Qisanet или Qisarfl) не зависят друг от друга. Единственное требование состоит в том, чтобы задача Qisaker была запущена первой так, чтобы она смогла инициализировать систему, а задача связи – связаться с ней. Система ISAGRAF не нарушает работу фоновых процессов и программ обработки прерываний; ПО системы исполнения строится вокруг целевой задачи, выполняющей пять языков стандарта IEC 1131-3 и обращающейся к библиотеке плат ввода/вывода, функциям пользователя и системному интерфейсу.

Задача доступа к БД Qisarfl обеспечивает возможность доступа к данным ISAGRAF из SCADA-систем (Realflex), считывая значения переменных из БД ISAGRAF и передавая их в сканер Realflex по сети QNX. Информация в Realflex приходит в результате периодических запросов, которые сканер Realflex передает программе Qisarfl. Каждой переменной приложения в процессе разработки может быть поставлен в соответствие уникальный адрес. Для этого имеется специальная опция в системе разработки. После того, как программа скомпилирована и загружена в контроллер, этот адрес можно задействовать для идентификации переменной при обращении к БД ISAGRAF. Программа Qisarfl обращается к БД ISAGRAF через разделяемую память, используя библиотеку вызовов системы ISAGRAF. В отношении БД Realflex переменные ISAGRAF – это точки определенного типа, смещение которыз в БД Realflex определено равным адресу переменной в БД ISAGRAF. Для любого типа контроллеров с ISAGRAF годится один и тот же сканер.

Система ISAGRAF допускает интеграцию собственных модулей пользователя ввода/вывода в среду ISAGRAF. Для системы разработаны драйверы ввода/вывода плат контроллера RTP 6800, промышленных компьютеров ComputerBoards. Для того, чтобы пользователь мог самостоятельно подключать собственные драйверы устройств ввода/вывода к ядру ISAGRAF, предлагается библиотека разработки драйверов ввода/вывода. При переносе уже написанной программы с одного типа контроллера на другой ничего не надо перепрограммировать, достаточно переопределить модули ввода/вывода с помошью специальной опции в системе разработки.

5. 5.3. ПРОГРАММНЫЕ СРЕДСТВА АСУ ТП МIК$Sys

Инструментальный комплекс ПО М1К$Sys предназначен для малых, средних и больших распределенных систем контроля технологических процессов и управления ими, построенных на базе IВМ РС - совместимых ПЭВМ и их сетей. Комплекс создан на основе многолетнего опыта работы группы управления кафедры автоматики МИФИ по созданию АСУТП различных производств, в том числе экологически опасных, и построению специальных программных тренажеров и математических моделей комплексов оборудования.

6.

7. 5.3.1. Программные средства построения АСУТП

В функции АСУТП на базе М1К$Sys входят:

· взаимодействие с контроллерами, их сетями и ПЭВМ в локальной и удаленных сетях по получению информации от датчиков, выдаче управляющих воздействий и централизованным / распределенным расчетам в реальном масштабе времени (РМВ);

· централизованный и децентрализованный контроль состояния программно-аппаратного обеспечения АСУТП и действий операторов как для контроллеров, так и для ПЭВМ сети;

· получение результатов опроса датчиков, первичная и специальная обработка данных, расчеты, выработка и выдача управляющих воздействий, что осуществляется с высокой скоростью в РМВ с тактом до 55 мс;

· ведение и предоставление для просмотра с возможностью анализа разнородных архивов информации: графиков параметров, записываемых с частотой 55 мс…ч (мгновенные измерения и усредненные данные) и событийных архивов (возможно, совмещенных со сбором графиков по пред- и постыстории развития ситуации), запись в которые происходит по факту нарушения технологического регламента или в результате действий оператора;

· ведение баз данных (БД) списков сигналов АСУТП и алгоритмов их обработки в простой и наглядной табличной форме, включая также элементы метрологической аттестации каналов измерений;

· предоставление информации в виде графических цветных мнемосхем со всевозможными способами отображения значений параметров (имитацией приборов и самописцев, анимацией, мерцанием, звуком);

· расчет технико-экономических показателей (ТЭП) и выдача документов о накопленной архивной информации.

8. Программно-аппаратное обеспечение комплекса позволяет:

· связывать элементы технологической цепочки, где функционируют разные АСУТП, объединенные сетью в единое целое, в том числе использовать данные одних систем для контроля других и управления ими;

· иметь данные опросов от нескольких АСУТП и управлять оборудованием как по месту, так и централизованно;

· получать на отдельных ПЭВМ сети от нескольких АСУТП все или наиболее важные характеристики производства по результатам текущих измерений, информацию архивную, отчетную и о выполнении показателей производства за любой отчетный период.

9. Комплекс ориентирован на применение следующих контроллеров:

· DEP (одноплатных малогабаритных контроллеров, объединяемых в локальные сети протяженностью до десятков километров с выходом на модемные телефонные и радиоканалы и возможностью комплексирования ПЭВМ по этим каналам), используемых в распределенных информационно-управляющих системах;

· Ломиконт, Ремиконт, применяемых для решения задач контроля и управления цехового масштаба;

· СМ-9107, предназначенный для работы в информационном и управляющем в производствах любого масштаба.

 Комплекс также ориентирован на использование любых иных контроллеров, включаемых в обслуживание по специальному программному интерфейсу, и для построения сетевых распределенных АСУТП, в которые в качестве контроллеров могут входить ЭВМ разнородной архитектуры, в том числе стандарта MicroPC.

10.

11. 5.3.2. Операционная среда

Система функционирует в операционных средах MS-DOS версии не ниже 5.00, Windows’95, в DOS-сессии Windows NT, проверена совместимость MIC$Sys с Linux . Система использует обычный режим работы процессора, но после ядра системы может быть запущена задача, использующая защищенный режим.

12.

13. 5.3.3. Компоненты системы

В состав системы входят следующие компоненты:

· драйверы контроллеров и сетевого обеспечения, принудительного свопинга задач (SWAP) и системы измерения временных характеристик выполнения асинхронных процессов (DCAP);

· резидентное ядро системы (Resident);

· задача организации ведения БД, отображения оперативной и архивной информации, управления системой и организации интерфейса оператора с использованием мнемосхем (Mikrob), что является основной оболочкой отображения для пользователя MIK$Sys;

· задачи для ПЭВМ в режиме “черного ящика” (BlackBox) и организации просмотра архивов (трендов) в виде графиков с элементами математического анализа (GFX);

· конструктор мнемосхем системы отображения информации и управления ею (MSX);

· программы расчета ТЭП и генерации отчетов (ТЕР), а также ведения БД ремонта и отключения оборудования (Equip);

· программа создания и ведения системных БД (NSI);

· вспомогательное ПО.

14.

15. 5.3.4. Опросы, управление и обработка параметров

Опросы и управление ведутся по подготовленным базам данных сигналов. Минимальный такт опроса составляет 55 мс. Взаимодействие с драйверами контроллеров осуществляется по принципу использования общей памяти и выдачи требований через коммуникационный вектор прерываний.

В результате опросов:

· анализируются достоверность параметров, работоспособность контроллера и выход параметров за технологические уставки;

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

16.

17. 5.3.5. Ведение и предоставление архивов

Включение параметра в архив осуществляется в задаче Mikrob при коррекции БД сигналов. Архивы, или тренды, создаются и ведутся задачей Resident на диске (своем или на сервере сети) и могут быть следующими:

· секундными (графики параметров с тактом работы задачи);

· минутными (графики среднеминутных значений за 5 с…10 мин);

· часовыми (графики среднечасовых значений за каждые 30 мин или 1 ч) ;

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

· сетевым трендом отклонений (событийный архив, служащий для фиксации действий операторов всех ПЭВМ сети, на которых функционирует MIK$Sys, а также отказы ПЭВМ сети).

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

18.

19. 5.3.6. Оперативные и неоперативные расчеты

Оперативные расчеты, в том числе по управляющим параметрам, выполняются в рамках задачи Resident. Предоставляется набор функций, необходимых для работы с памятью, файлами, временем и т. п. В расчете может использоваться любой параметр БД.

20. 5.3.7. Интерфейс оператора

Система конструирования и поддержки графического интерфейса оператора MSX является средством создания и обслуживания графических экранов для отображения информации и управления технологическими процессами, тренажерами, расчетными задачами оптимизации, задачами управления, ведения БД и т. д. в простой и наглядной, удобной для оператора-технолога форме в РМВ.

Основной принцип построения мнемосхемы (рисунок) - наложение динамики на статическую часть рисунка, подготовленного в любом стандартном редакторе. В MSX отсутствуют стандартные элементы отображения и их библиотеки, поскольку пользователь не ограничен никакими рамками стандартизации и может использовать любую мнемосхему как библиотеку стандартных элементов. В системе применяются растровые изображения и шрифты для достижения высокой скорости смены изображений. Статические изображения и их отдельные фрагменты могут компрессироваться в специальный формат; предусмотрены средства тиражирования типовых объектов, позволяющие сокращать время разработки.

21.

22. 5.3.8. Специальные функции

23. К числу основных специальных функций системы относятся:

· защита ресурсов системы и информации от несанкционированного доступа, в том числе регистрация пользователей по пародированному доступу и ведение журнала в сетевом тренде отклонений;

· синхронизация таймеров сети по контрольным ПЭВМ;

· резервирование нескольких ПЭВМ, объединенных сетью;

· организация распределенных АСУТП средствами поддержки протоколов IРХ/SРХ, в том числе дистанционное управление и получение любых параметров БД с любой ПЭВМ сети;

· восстановление архивов по контрольным ПЭВМ (серверам сети);

· дистанционная перезагрузка удаленных ПЭВМ сети;

· синхронизация версий программ и БД в сетевой АСУТП;

· сетевая файловая электронная почта по протоколам IРХ;

· сетевые серверы печати по IРХ;

24.

25. 5.3.9. Особенности MIK$Sys

Отличительные черты MIK$Sys от аналогичных систем построения АСУТП:

· применение языка программирования FORTRAN как наиболее эффективного для расчетных задач АСУТП (применяется FORTRAN-77 версии 5.00 Microsoft);

· использование специально разработанной FORTRAN-ориентированной БД, записями которой являются элементы языка (переменные, векторы и массивы), поэтому доступ к данным осуществляется со скоростью выполнения стандартной операции присвоения или вычисления адреса как для обычной переменной программы;

· векторная обработка данных, более эффективная, чем ссылочная;

· системно-ориентированный подход к построению компонентов и алгоритмов в противовес менее эффективному в АСУТП объектному;

· жесткое тактирование выполнения функций резидентной задачей вместо событийной ориентации вызывающей перегрузку системы при массовых изменениях;

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

· работа с контроллерами, их драйверами и взаимодействие компонентов системы, каждый из которых функционирует асинхронно, осуществляемое через общую память, а не по специальным запросам;

· поддержка протоколов IРХ/SРХ для построения сетевой АСУТП вместо сетевого ПО верхнего уровня;

· использование тактированных широковещательных пакетов при построении сетевых АСУТП для доставки результатов опросов и расчетов, что значительно эффективнее общепринятой дисциплины клиент-сервер, особенно при большом числе ПЭВМ;

· возможность получения в сетевой АСУТП данных как из локальной сети, так и через мост(ы) или маршрутизатор(ы) из других сетей, что относится и к дистанционному управлению;

· использование в сетевой АСУТП ЭВМ разнородных архитектур при соблюдении протоколов обмена данными;

· применение графической библиотеки собственной разработки;

· использование растровой графики и матричных фонтов, благодаря чему в системе поддерживаются высокие скорость и качество отображения;

· отсутствие библиотеки графических примитивов и каких-либо ограничений, любая мнемосхема(ы) может использоваться как библиотека;

· наличие средств тиражирования для типовых объектов автоматизации.

Новые версии М1К$5у5 полностью поддерживают предыдущие. В настоящее время ведутся работы по созданию операционно независимой версии для защищенного режима процессора, в качестве базовой системы программирования используется Fortran Power Station v.1.00 (v.4) в рамках DOS (Phar Lap DOS-Extender), Windows’95, Windows’98, Windows NT.

В настоящее время комплекс MIK$Sys широко применяется на многих предприятиях страны, среди которых можно назвать Северную водопроводную станцию в Москве, насосные артезианские скважины в Красногорске, Новолипецкий металлургический комбинат, комплекс вспомогательных цехов и производств, ВНИИ неорганических материалов в Москве и др.

26. 5.4. СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

27.

28. 5.4.1. Операционные системы

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

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

5.4.2. Определение реального времени

Если попытаться дать короткое определение, то

1. Система называется системой реального времени, если правильность её функционирования зависит не только от логической корректности вычислений, но и от времени, за которое эти вычисления производятся. То есть для событий, происходящих в такой системе, то, КОГДА эти события происходят, так же важно, как логическая корректность самих событий.

2. Говорят, что система работает в реальном времени, если ее быстродействие адекватно скорости протекания физических процессов на объектах контроля или управления. То есть система управления должна собрать данные, произвести их обработку в соответствии с заданными алгоритмами и выдать управляющие воздействия за такой промежуток времени, который обеспечивает успешное решение поставленных перед системой задач.

Из приведенных определений следует несколько интересных выводов.

Во-первых, практически все системы промышленной автоматизации являются системами реального времени.

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

Принято различать системы «жесткого» и «мягкого» реального времени.

1. Системой «жесткого» реального времени называется система, где неспособность обеспечить реакцию на какие-либо события в заданное время является отказом и ведет к невозможности решения поставленной задачи.

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

2. Точного определения для «мягкого» реального времени не существует, поэтому будем считать, что сюда относятся все системы реальною времени, не попадающие в категорию «жестких».

Так как система «мягкого» реального времени может не успевать ВСЁ делать ВСЕГДА в заданное время, возникает проблема определения критериев успешности (нормальности) ее функционирования. Вопрос этот совсем не простой, так как и зависимости от функций системы это может быть максимальная задержка в выполнении каких-либо операции, средняя своевременность отработки событий и т. п. Более того, эти критерии влияют на то, какой алгоритм планирования задач является оптимальным. Вообще говоря, системы «мягкого» реального времени проработаны теоретически далеко не до конца.

5.4.3. Ядра и операционные системы РВ

Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возможностей. Ядра предоставляют пользователю такие базовые функции, как планирование и синхронизация задач, межзадачная коммуникация, управление памятью и т. п. Операционные системы в дополнение к этому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня.

По своей внутренней архитектуре ОС РВ можно условно разделить, на монолитные ОС, ОС на основе микроядра и объектно-ориентированные ОС. Графически различия в этих подходах иллюстрируются рисунками 5.2, 5.3, 5.4. Преимущества и недостатки различных архитектур достаточно очевидны, поэтому подробно мы на них останавливаться не будем.

Рисунок 5.2. ОС РВ с монолитной архитектурой

5.4.4. Задачи, процессы, потоки

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

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

Хорошим примером многопоточной программы является редактор текста WORD, где в рамках одного приложения может одновременно происходить и набор текста, и проверка правописания.

5.4.5. Преимущества потоков

1. Так как множество потоков способно размещаться внутри одного ЕХЕ-модуля, это позволяет экономить ресурсы как внешней, так и внутренней памяти.

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

3. Как правило, контекст потоков меньше, чем контекст процессов, а значит, время переключения между задачами-потоками меньше, чем между задачами-процессами.

4. Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ-модуле, значительно упрощается использование программ-отладчиков (debugger).

Рисунок 5.3. ОС РВ на основе микроядра

5.4.6. Недостатки потоков

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

2. То, что потоки имеют доступ к областям данных друг друга, может привести к ситуации, когда некорректно работающий поток способен испортить данные другого потока. В отличие от этого процессы защищены от взаимного влияния, а попытка записи в не свою» память приводит, как правило, к возникновению специального прерывания по обработке "исключительных ситуации". Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаимодействия определяются конкретным ПО РВ.

Рисунок 5.4. Объектно-ориентированная ОС РВ

5.4.7. Основные свойства задач

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

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

Контекст задачи - это набор данных, содержащий всю необходимую информацию для возобновления выполнения задачи с того места, где она была ранее прервана. Часто контекст хранится в TCB и включает в себя такие данные, как счетчик команд, указатель стека, регистры CPU и FPU и т. п. Планировщик задач в случае необходимости сохраняет контекст текущей активной задачи и восстанавливает контекст задачи, назначенной к исполнению. Такое переключение контекстов и является, по сути, основным механизмом ОС РВ при переходе от выполнения одной задачи к выполнению другой.

Состояние (статус) задачи.

Практически в любой ОС РВ загруженная на выполнение задача может находиться, по крайней мере, в трех состояниях.

1. Активная задача — это задача, выполняемая системой в текущей момент времени.

2. Готовая задача - это задача, готовая к выполнению и ожидающая у планировщика своей «очереди».

3. Блокированная задача - это задача, выполнение которой приостановлено до наступления определённых событий.

Такими событиями могут быть освобождение необходимого задаче ресурса, поступление ожидаемого сообщении, завершение интервала ожидания и т. п. Пустая задача (Idle Task) - это задача, запускаемая самой операционной системой в момент инициализации и выполняемая только тогда, когда в системе нет других готовых для выполнения задач. Пустая задача запускается с самым низким приоритетом и, как правило, представляет собой бесконечный цикл «ничего не делать». Наличие пустой задачи предоставляет операционной системе удобный механизм отработки ситуаций, когда нет ни одной готовой к выполнению задачи.

Реентерабельность (повторная входимость) означает возможность без негативных последствий временно прервать выполнение какой-либо функции или подпрограммы, а затем вызвать эту функцию или подпрограмму снова. Частным проявлением реентерабельности является рекурсия, когда тело подпрограммы содержит вызов самой себя. Классическим примером нереентерабельной системы является DOS, а типичной причиной нереентерабельности служит использование глобальных переменных.

5.4.8. Планирование задач

Важной частью любой ОС РВ является планировщик задач. Несмотря на то, что в разных источниках он может называться по-разному (диспетчер задач, супервизор и т. п.), его функции остаются теми же: определить, какая из задач должна выполняться в системе в каждый конкретный момент времени. Самым простым методом планирования, не требующим никакого специального ПО и планировщика как такового, является использование циклического алгоритма.

Каждая «задача», представляющая собой отдельную подпрограмму, выполняется циклически. При этом надо придерживаться следующих правил:

1. Подпрограммы не должны содержать циклов ожидания.

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

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

Можно отметить следующие преимущества циклического алгоритма.

1. Простота использования и прозрачность для понимания.

2. Если исключить из рассмотрения прерывания, система полностью детерминирована.

3. Минимальные размеры кода и данных. Кроме того, в отличие от алгоритмов с вытеснением, для всех задач необходим только один стек. 4. Отсутствуют ошибки, обусловленные «гонками».

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

Перейдем теперь к другому широко используемому алгоритму планирования. Речь пойдет о режиме разделения времени. Как правило, алгоритм реализуется следующим образом: каждой задаче отводится определенное количество квантов времени (обычно кратно 1 мс), в течение которых задача может монопольно занимать процессорное время. После того как заданный интервал времени истекает, управление передается следующей готовой к выполнению задаче, имеющей наивысший приоритет. Низкоприоритетные задачи в этом случае могут никогда не получить управление, так как три высокоприоритетные задачи будут делить все процессорное время между собой. Единственную возможность для низкоприоритетных задач получить управление предоставляет ситуация, когда все высокоприоритетные задачи находятся в блокированном состоянии.

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

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

В общем случае алгоритмы планирования должны соответствовать критериям оптимальности функционирования системы. Однако, если для систем «жесткого» реального времени такой критерий очевиден: «ВСЕГДА и всё делать вовремя», то для систем «мягкого» реального времени это может быть, например, минимальное «максимальное запаздывание» или средневзвешенная своевременность завершения операций.

Не стоит особо увлекаться приоритетами. Если система нормально работает, когда все задачи имеют одинаковый приоритет, то и слава Богу. Если нет, то можно присвоить высокий приоритет «критической» задаче, и низкий приоритет всем остальным. Если у вас больше одной «критической» задачи, при недостаточном быстродействии системы имеет смысл рассмотреть многопроцессорную конфигурацию или, отказавшись от ПО РВ, перейти к простому циклическому алгоритму.

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

5.4.9. Синхронизация задач

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

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

2. Необходимо упорядочить доступ нескольких задач к разделяемому ресурсу.

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

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

Давайте рассмотрим все четыре случая более подробно.

5.4.10. Связанные задачи

Взаимное согласование задач с помощью сообщений является одним из важнейших принципов операционных систем реального времени.

Объем информации, передаваемой в сообщениях, может меняться от 1 бита до всей свободной емкости памяти вашей системы. Во многих ОС РВ компоненты операционной системы, так же как и пользовательские задачи, способны принимать и передавать сообщения. Сообщения могут быть асинхронными и синхронными. В первом случае доставка сообщений задаче производится после того, как она в плановом порядке получит управление, я во втором случае циркуляция сообщений оказывает непосредственное влияние на планирование задач.

Иногда сообщения передаются через отведенный для этого буфер определенного размера («почтовый ящик»). При этом, как правило, новое сообщение затирает старое, даже если последнее не было обработано.

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

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

5.4.11. Общие ресурсы

Ресурс - это общий термин, описывающий физическое устройство или область памяти, которые могут одновременно использоваться только одной задачей. Процессорное время тоже представляет собой своеобразный конкурентно используемый ресурс вычислительной системы. Примером физических устройств могут служить клавиатура, дисплей, дисковый накопитель, принтер и т. п. В качестве примера рассмотрим ситуацию, когда в бортовом компьютере мирно летящего самолета МИГ-29 среди прочих работают две задачи. Одна из них, взаимодействуя с радиолокационной системой, выдает удаление и направление до цели, а другая задача использует эти данные для пуска ракет класса «воздух-воздух». Не исключено, что первая задача, записав в глобальную структуру данных удаление до цели, будет прервана второй задачей, не успев записать туда направление до цели. В результате вторая задача считает из этой структуры ошибочные данные, что может привести к неудачному пуску со всеми вытекающими отсюда неприятными последствиями. Прервись первая задача чуть позже, и все было бы нормально. Упомянутые здесь проблемы обусловлены времязависимыми ошибками (time dependent error), или «гонками» и характерны для многозадачных ОС, применяющих алгоритмы планирования с вытеснением (кстати, системы с разделением времени также относятся к категории «вытесняющих»).

Приведенный пример показывает, что ошибки, обусловленные «гонками», а) характерны для работы с любыми ресурсами, доступ к которым имеют несколько задач, и б) происходят только в результате совпадения определенных условий, а потому с трудом обнаруживаются на этапе отладки.

Вот возможные пути решения проблемы.

1.He использовать алгоритмы планирования задач с вытеснением. Это решение, правда, не всегда приемлемо.

2. Использовать специальный сервер ресурса, то есть задачу, ответственную за упорядочивание доступа к ресурсу.

3. Запретить прерывания на время доступа к разделяемым данным Кардинальное решение, которое, впрочем, не приветствуется в системах реального времени.

4. Использовать для упорядочивания доступа к глобальным данным семафоры. Наиболее часто применяемое решение, которое, впрочем, может привести в некоторых случаях к «инверсии приоритетов».

Семафор - это как раз то средство, которое часто используется для синхронизации доступа к ресурсам. В простейшем случае семафор представляет собой байтовую переменную, принимающую значение 0 или 1. Задача, перед тем как использовать ресурс, захватывает семафор, после чего остальные задачи, желающие использовать тот же ресурс, должны ждать, пока семафор (ресурс) освободится. Существуют также так называемые счетные семафоры, где семафор представляет собой счетчик. Пусть к системе подключено три принтера. Семафор, отвечающий за доступ к функциям печати, инициализируется со значением 3, а затем каждый раз, когда какая-либо задача запрашивает семафор для осуществления печати, его значение уменьшается на 1. После завершения печати задача освобождает семафор, в результате чего значение последнего увеличивается на 1. Если текущее значение семафора равно 0, то ресурс считается недоступным, и задачи, запрашивающие печать, должны ждать, пока не освободится хотя бы один принтер.

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

Смертельный захват (Deadlock).

 В народе побочные проявления этой ситуации называются более прозаично - «зацикливание» или «зависание». А причина этого может быть достаточно проста - «задачи не поделили ресурсы», Пусть, например. Задача А захватила ресурс клавиатуры и ждет, когда освободится ресурс дисплея, а в это время Задача В также хочет пообщаться с пользователем и, успев захватить ресурс дисплея, ждет теперь, когда освободится клавиатура. В таких случаях рекомендуется придерживаться тактики «или все, или ничего». Другими словами, если задача не смогла получить все необходимые для дальнейшей работы ресурсы, она должна освободить всё, что уже захвачено, и, как говорится, «зайти через полчаса». Другим решением, которое уже упоминалось, является использование серверов ресурсов.

5.4.12. Синхронизация с внешними событиями

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

1. Стремление обеспечить максимально быструю и детерминированную реакцию системы на внешнее событие.

2. Старание добиться минимально возможных периодов времени, когда в системе запрещены прерывания.

 3. Подпрограммы обработки прерываний выполняют минимальный объем функций за максимально короткое время. Задержки с обработкой прерываний могут привести к потере данных.

5.4.13. Синхронизация по времени

Как правило, в ОС РВ задается эталонный интервал (квант) времени, который иногда называют тиком (Tick) и который используется в качестве базовой единицы измерения времени. Размерность этой единицы для разных ОС РВ может быть разной, как, впрочем, разными могут быть набор функций и механизмы взаимодействия с таймером. Функции по работе с таймером используют для приостановки выполнения задачи на какое-то время, для запуска задачи в определенное время, для относительной синхронизации нескольких задач по времени и т. п.

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

5.4.14. Тестирование

Прежде чем устанавливать вашу систему реального времени на не менее реальном объекте, рекомендуется проверить ее работоспособность с помощью интенсивных тестов. Это особенно важно для сложных динамических систем. Во время такого тестирования желательно смоделировать наиболее неприятные и «тяжелые» режимы работы, аварийные ситуации и т. п. При умозрительном анализе простых систем следует осторожно относиться к рекламной информации разработчиков ОС РВ, которые из коммерческих соображений показывают, как правило, параметры для «лучшего случая».

В связи с этим всегда необходимо помнить, что

1)если наряду с разработанными вами программами используется программное обеспечение третьих фирм, вы не застрахованы от того, что там не встретятся участки кода, где прерывания запрещены;

2)практически любая ОС РВ имеет в своих недрах участки такого кода. Нам остается только надеяться, что разработчики ОС старались делать их как можно меньше;

3)всё ядро ОС РВ или его участки могут быть «невытесняемыми»;

4)интеллектуальные контроллеры ввода/вывода типа SCSI могут инициировать в системе различные служебные операции, которые способны отразиться на ее характеристиках;

Информация в лекции "Лекция 6" поможет Вам.

5)многое зависит от применяемой системы кэширования.

Поэтому, если ваше событие произошло в «неподходящее» время, реальные показатели быстродействия могут сильно отличаться от рекламируемых.

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

В общем случае решение о применении какого-либо коммерческого ПО реального времени зависит от множества факторов, в том числе и от таких, как время, отпущенное на разработку, наличие и квалификация специалистов, объемы финансирования проекта и т. п.

Хотя, как мы увидели, ОС РВ предоставляют много полезных и удобных средств для написания программ, основной груз ответственности лежит на плечах рядового труженика-программиста. Ведь стоит ему переместить переменную из категории локальных в категорию глобальных и забыть над лежащим образом оформить критические секции, как станут падать космические корабли, взрываться нефтеперерабатывающие заводы, источать радиоактивность атомные станции.