Известно, что применение аппаратных прерываний является более эффективным методом взаимодействия с внешним миром, чем метод опроса. Разработчики систем реального времени стараются использовать этот факт в полной мере. При этом можно проследить следующие тенденции:
1. Стремление обеспечить максимально быструю и детерминированную реакцию системы на внешнее событие.
2. Старание добиться минимально возможных периодов времени, когда в системе запрещены прерывания.
3. Подпрограммы обработки прерываний выполняют минимальный объем функций за максимально короткое время. Это обусловлено несколькими причинами. Во-первых, не все ОС РВ обеспечивают возможность «вытеснения» во время обработки подпрограмм прерывания. Во-вторых, приоритеты аппаратных прерываний не всегда соответствуют приоритетам задач, с которыми они связаны. В-третьих, задержки с обработкой прерываний могут привести к потере данных. Как правило, закончив элементарно необходимые действия, подпрограмма обработки прерываний генерирует в той или иной форме сообщение для задачи, с которой это прерывание связано, и немедленно возвращает управление. Если это сообщение перевело задачу в разряд готовых к исполнению, планировщик в зависимости от используемого алгоритма и приоритета задачи принимает решение о том, необходимо или нет немедленно передать управление получившей сообщение задаче. Разумеется, это всего лишь один из возможных сценариев, так как каждая ОС РВ имеет свои особенности при обработке прерываний. Кроме того, свою специфику может накладывать используемая аппаратная платформа.
Синхронизация по времени
Совсем не так давно (лет 20 назад) аппаратные средства, отвечающие в вычислительных системах за службу времени, были совершенно не развиты. В те приснопамятные времена считалось достаточным, если в системе генерировалось прерывание с частотой сети переменного тока. Те же, кто не знал, что частота сети в США 60 Гц, а не 50, как у нас, постоянно удивлялись тому, что системное время в К5Х-11 М никогда не бывает правильным. Программисты для получения задержек по времени часто использовали программные циклы ожидания и, разумеется, пользователи таких программ получали массу сюрпризов при попытке их переноса на следующее поколение компьютеров с более высокими тактовыми частотами. Как правило, в ОС РВ задается эталонный интервал (квант) времени, который иногда называют тиком (Т1ск) и который используется в качестве базовой единицы измерения времени. Размерность этой единицы для разных ОС РВ может быть разной, как, впрочем, разными могут быть набор функций и механизмы взаимодействия с таймером. Функции по работе с таймером используют для приостановки выполнения задачи на какое-то время, для запуска задачи в определенное время, для относительной синхронизации нескольких задач по времени и т. п. Если в программе для ОС РВ вы увидите операнд с dе1ау (50), то, скорее всего, это обозначает, что в этом месте задача должна прерваться (блокироваться), а через 50 мс возобновить свое выполнение, а точнее, перейти в состояние готовности. Все это время процессор не простаивает, а решает другие задачи, если такие имеются. Множество задач одновременно могут запросить сервис таймера, поэтому если для каждого такого запроса используется элемент и таблице временных интервалов, то накладные расходы системы по обработке прерываний от аппаратного таймера растут пропорционально размер! юсти этой таблицы и могут стать недопустимыми. Для решения этой проблемы можно вместо таблицы использовать связный список и алгоритм -так называемого дифференциального таймера, когда во время каждого тика уменьшается только один счетчик интервала времени.
Для точной синхронизации таймера вычислительной системы с астрономическим временем могуг применяться специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, которые позволяют воспользоваться атомными часами на борту орбитальных космических аппаратов, запущенных по программе Nаvstаг.
ТЕСТИРОВАНИЕ
Прежде чем устанавливать нашу систему реального времени на не менее реальном объекте, рекомендуется проверить ее работоспособность с помощью интенсивных тестов. Это особенно важно для сложных динамических систем. Во время такого тестирования желательно смоделировать наиболее неприятные и «тяжелые» режимы работы, аварийные ситуации и т. п. При умозрительном анализе простых систем следует осторожно относиться рекламной информации разработчиков ОС РВ, которые из коммерческих соображений показывают, как правило, параметры для «лучшего случая» Например, если речь идет о максимальном времени обработки прерывания необходимо в первую очередь понять а что, собственно, подразумевается подэтим временем:
а)время от возникновения запроса на прерывание до передачи управления по вектору прерывания;
б)или включая время coxpанения контекста текущей задачи и передачи управления подпрограмме обработки прерывания;
в)или дополнительно к этому еще и время до завершения подпрограммы обработки прерывания и передачи сообщения связанной с прерыванием: задаче;
г)или дополнительно к этому время до момента, когда эта задача наконец получит управление (в предположении, что она является наиболее приоpитетной) и начнет реальную обработку события.
При этом надо помнить:
1)если наряду с разработаными вами программами используется программное обеспечение третьих фирм, вы нe:.застрахованы от того, чго там не встретятся участки кода, где прерывания запрещены;
2)практически любая ОС РВ имеет в своих недрах участки такого кода. Нам остается только надеяться, что разработчики ОС старались делать их как можно меньше;
3)всё ядро ОС РВ или его участки могут быть «невытесняемыми»;
4)интеллектуальные контроллеры ввода/вывода типа SCSI могут инициировать в системе различные служебные операции, которые способны отразиться на ее характеристиках;
5)многое зависит от применяемой системы кэширования.
Поэтому, если ваше событие произошло в «неподходящее» время, реальные показатели быстродействия могут сильно отличаться от рекламируемых
SCADA системы
Осно-ные возможности и средства, присущие всем системам и различающиеся только техническими особенностями реализации:
- автоматизированная разработка, дающая возможность создания ПО системы автоматизации без реального программирования;
- средства сбора первичной информации от устройств нижнего уровня;
- средства управления и регистрации сигналов об аварийных ситуациях;
- средства хранения информации с возможностью ее постобработки (как правило, реализу-ется через интерфейсы к наиболее популярным базам данных);
- средства обработки первичной информации;
- средства визуализации информации в виде графиков, гистограмм и т.п.;
- возможность работы прикладной системы с наборами параметров, рассматриваемых как "единое целое" ("recipe" или "установки").
Основу большинства SCADA-пакетов составляют несколько программных компонентов (ба-за данных реального времени, ввода-вывода, предыстории, аварийных ситуаций) и администрато-ров (доступа, управления, сообщений).
Следует отметить, что в целом технология проектирования систем автоматизации на основе SCADA-систем очень похожа:
- Разработка архитектуры системы автоматизации в целом. На этом этапе определяется функциональное назначение каждого узла системы автоматизации.
- Решение вопросов, связанных с возможной поддержкой распределенной архитектуры, не-обходимостью введения узлов с "горячим резервированием" и т.п.
- Создание прикладной системы управления для каждого узла. На этом этапе специалист в области автоматизируемых процессов наполняет узлы архитектуры алгоритмами, совокуп-ность которых позволяет решать задачи автоматизации.
- Приведение в соответствие параметров прикладной системы с информацией, которой об-мениваются устройства нижнего уровня (например, программируемые логические контрол-леры - PLCs) с внешним миром (датчики температуры, давления и др.)
- Отладка созданной прикладной программы в режиме эмуляции и в реальном режиме.
Перечисленные выше возможности систем SCADA в значительной мере определяют стои-мость и сроки создания ПО, а также сроки ее окупаемости.
Подавляющее большинство SCADA-систем реализовано на MS Windows платформах. Имен-но такие системы предлагают наиболее полные и легко наращиваемые MMI (Man Machine Interface) средства
Для эффективного функционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса. Желательно, чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д.) с использованием стандартных протоколов (NETBIOS, TCP/IP и др.), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т.д.)
Большинство SCADA-систем имеют встроенные языки высокого уровня, VBasic-подобные языки, позволяющие сгенерировать адекватную реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.
Практически все SCADA-системы, в частности, Genesis, InTouch используют ANSI SQL синтаксис, который является независимым от типа базы данных. Таким образом, приложения виртуально изолированы, что позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных.
Функционально графические интерфейсы SCADA-систем весьма похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации.