Мегаобучалка Главная | О нас | Обратная связь


Операционные системы реального времени



2016-01-26 1241 Обсуждений (0)
Операционные системы реального времени 0.00 из 5.00 0 оценок




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

Пусть, к примеру, автомат подсчитывает количество бутылок на конвейере. Если бутылки появляются напротив датчика с периодом 1 с, а время реакции системы на появление бутылки составляет 0,7 с, то система кажется работоспособной. Однако, если задержка является случайной величиной, то в некоторый момент времени она может оказаться больше 1 с, что приведет к появлению случайной ошибки в количестве бутылок, т.е. к отказу системы. Величина ошибки определяется статистической функцией распределения случайных задержек.

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

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

Стандарт IEEE 1003.1 даёт следующее определение РВ: "Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени". Следовательно, ОС РВ отличаются своим поведением, а не внутренним принципом построения. Поэтому если вероятность появления недопустимо больших задержек достаточно низка для достижения требуемого уровня сервиса (например, если она меньше допустимой вероятности отказа системы), то такая ОС в конкретном применении может рассматриваться как ОС РВ. В частности, в соответствии с определением стандарта POSIX операционная система Windows XP при управлении медленными (тепловыми) процессами может рассматриваться как ОС РВ.

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

Базовыми требованиями для обеспечения режима реального времени являются следующие [Furr]:

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

· должна быть исключена инверсия приоритетов (см. ниже);

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

Инверсией приоритетов называют ситуацию, когда поток с высоким приоритетом требует предоставления ресурса, который уже занят потоком с более низким приоритетом. Получается, что высокоприоритетный поток стоит в очереди, в то время как исполняется низкоприоритетный (происходит "инверсия приоритетов"). Такая ситуация возможна, если имеется поток со средним приоритетом, который блокирует завершение выполнение потока с низшим приоритетом, а поток с высшим приоритетом не может начаться, поскольку захвачен необходимый ему ресурс. Основным методом решения этой проблемы в ОС РВ является наследование приоритетов [Jean J. Labrosse], которое заключается в следующем. Если низкоприоритетный поток блокирует выполнение нескольких высокоприоритетных потоков, то низкоприоритетный поток игнорирует назначенный ему первоначально приоритет и выполняется с приоритетом, который является наивысшим в блоке ожидающих его потоков. После окончания работы поток принимает свой первоначальный приоритет.

Для обеспечения режима реального времени в ОС могут быть реализованы следующие требования [Furr, Jean J. Labrosse]:

· поддержка динамических приоритетов (которые можно менять в процессе выполнения задачи) в многозадачном режиме с вытесняющим ядром (как для процессов, так и для потоков);

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

· возможность вытеснения задач ядром ОС;

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

· выполнение сервисов ОС с приоритетом, который назначается клиентом сервиса.

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

Наиболее распространенными в ПЛК и компьютерах для решения задач автоматизации являются операционные системы Windows CE, QNX Neutrino и OS-9.

Windows CE.NET

Операционная система Windows знакома всем как настольная система. Но это, прежде всего, относится к платформам Windows 3.хх/95, в которых действительно отсутствует поддержка реального времени. Ситуация резко изменилась с появлением Windows NT. Сама по себе Windows NT не является операционной системой реального времени в силу ряда ее особенностей. Система поддерживает аппаратные (а не программные) прерывания, отсутствует приоритетная обработка отложенных процедур и др. Но в конце ХХ века ряд фирм предприняли серьезные попытки превратить Windows NT в ОС жесткого реального времени. И эти попытки увенчались успехом. Компания VenturCom разработала модуль Real Time Extension (RTX) - подсистему реального времени (РВ) для Windows NT. Эта подсистема имеет собственный планировщик со 128 приоритетами прерываний, который не зависит от NT. Максимальное время реакции на прерывание составляет 20-80 мкс вне зависимости от загрузки процессора. Теперь при каждом прерывании от таймера приоритет передается критичным по времени задачам. А в оставшееся от их работы время могут выполняться «медленные» процессы: ввод/вывод, работа с диском, сетью, графическим интерфейсом и т. п.

32-разрядная Windows CE была создана компанией Microsoft для малых компьютеров (калькуляторов), но в силу ряда достоинств стала претендовать на роль стандартной ОС реального времени. К числу этих достоинств относятся:

- открытость и простота стыковки с другими ОС семейства Windows;

- время реакции порядка 500 мкс;

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

А в 1999 году компанией Direct by Koyo ОС Windows CE была впервые установлена на платформу микроPLC.

Многозадачная операционная система жесткого реального времени Windows CE.NET корпорации Microsoft поддерживает микропроцессоры с архитектурой ARM, StrongARM и xScale, MIPS, SH, X86-совместимые и имеет следующие свойства:

· допускает одновременное выполнение до 32 процессов;

· имеет 256 уровней приоритетов;

· поддерживает вытесняющую многозадачность;

· обеспечивает карусельное исполнение цепочек с одинаковым приоритетом;

· поддерживает вложенные прерывания;

· имеет среднее время обработки прерывания 2,8 мкс (на Pentium 166 МГц), поддерживает вложенные прерывания;

· обеспечивает время обработки потока прерываний (Interrupt Service Thread, IST), равное 17,9 мкс (на Pentium 166 МГц);

· в минимальной конфигурации может быть установлена при объеме ОЗУ 200 Кб.

Ядро этой ОС принципиально отличается от ядра ОС для настольных компьютеров. В Windows CE.NET объединены все возможности систем реального времени и последние технологии Windows. Планирование выполняется на основе приоритетов, для устранения инверсии используется наследование приоритетов. Несмотря на наличие возможности работы с виртуальной памятью, для обеспечения режима жесткого реального времени ее отключают.

Windows CE .NET поддерживает Microsoft Visual Studio .NET и Microsoft eMbedded Visual C++ с языками программирования Visual C++, Visual C#, and Visual Basic .NET.

Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ). Но наибольшую популярность и распространение получили различные варианты ОС Windows (Windows NT/2000). Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации - рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.

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

Вот несколько основных аргументов в пользу Windows:

- Windows имеет очень широкое распространение в мире, в том числе и в России, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;

- эта ОС имеет множество приложений, обеспечивающих решение различных задач обработки и представления информации;

- ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;

- приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;

- системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при поэтапном росте;

- Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».

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

QNX Neutrino

В 90-х годах широкое распространение получила ОС реального времени QNX. Имеется множество примеров использования QNX на всех уровня иерархической структуры АСУТП (от контроллеров до серверов и рабочих станций). Но в последние годы активность компании на рынке SCADA-систем значительно снизилась, что привело и к снижению числа продаж этого программного продукта. Объясняется это тем, что еще в 1995 году компания QNX Software Systems Ltd. объявила об «уходе» во встроенные системы.

QNX Neutrino корпорации QNX Software Systems является операционной системой реального времени и обеспечивает многозадачный режим с приоритетами [Цилюрик]. Поддерживает микропроцессоры семейств ARM, StrongARM, xScale, x86, MIPS, PowerPC, SH-4.

QNX относится к микроядерным ОС (т.е. реализует только базовые функции ядра - управление адресным пространством ОЗУ и виртуальной памяти, процессами и потоками, обеспечивает межпроцессорную коммуникацию). Состоит из ядра, планировщика процессов и сервисов. Построена на основе сервисов - небольших задач, выполняющих основные функции ОС. Такая структура позволяет отключить любую ненужную функциональность, не изменяя ядро. Каждый драйвер, приложение, протокол или файловая система выполняются вне ядра, в защищенном адресном пространстве.

Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов.

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

Операционная система QNX нашла применение как на нижнем уровне АСУТП (ОС для контроллеров), так и на верхнем уровне (ОС для программного обеспечения SCADA).

 

OS-9

Операционная система OS-9 фирмы Microware System является многозадачной и многопользовательской, работает в режиме мягкого реального времени. Используется во встраиваемых приложениях на платформах ARM, StrongARM, MIPS, PowerPC, Hitachi SuperH, x86, Pentium, XScale, Motorola 68K [Бурдонов]. OS-9 относится к классу Unix-подобных операционных систем реального времени и предлагает многие привычные элементы среды Unix. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули, разработчик может создавать системы с самой разной конфигурацией - от миниатюрных автономных ядер, ориентированных на ПЗУ контроллеров, до полномасштабных многопользовательских систем разработки.

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

VxWorks

Операционная система реального времени VxWorks предназначена для разработки ПО встроенных компьютеров, работающих в системах «жесткого» реального времени. К операционной системе VxWorks прилагается и инструментальная среда Tornado фирмы Wind River Systems со средствами разработки прикладного программного обеспечения. Его разработка ведется на инструментальном компьютере в среде Tornado для последующего исполнения на целевом компьютере (контроллере) под управлением VxWorks.

ОС VxWorks поддерживает целый ряд компьютерных платформ, в том числе Intel 386/486/Pentium, PowerPC, DEC Alpha. К платформам, поддерживаемым инструментальной средой Tornado, относятся Sun (Solaris), HP 9000/400,700, DEC Alpha, PC (Windows 95 и NT) и другие.

 

 

Тема 2. OPC-сервер

Стандарт ОРС разработан международной организацией OPC Foundation, членами которой являются более 400 фирм, работающих в области средств автоматизации и измерительной техники. Основателями организации являются фирмы Fisher-Rosemount, Rockwell Software, Opto 22, Intellution и Intuitive Technology. Первая версия ОРС стандарта была выпущена в 1998 г. [OLE]. В совет директоров OPC Foundation в 2008 году входили представители Siemens AG, Emerson Process Management, Yokogawa, Honeywell, Rockwell Automation, ICONICS.

Обзор стандарта ОРС

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

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

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

ОРС сервер как средство взаимодействия с техническим устройством может быть использован при разработке заказных программ на C++, Visual Basic, VBA и т. п. В этих задачах ОРС сервер используется как Microsoft DCOM объект, от которого он отличается только стандартизацией обозначений и специфическими терминами из области промышленной автоматизации. Применение ОРС сервера при разработке заказных программ позволяет скрыть от разработчика всю сложность общения с аппаратурой, представляя простой и удобный метод доступа к аппаратуре через интерфейсы СОМ-объекта.

Стандарт ОРС состоит из нескольких частей:

· ОРС DA (OPC Data Access) - спецификация для обмена данными между клиентом (например SCADA) и аппаратурой (контроллерами, модулями ввода-ввода и др.) в реальном времени;

· OPC Alarms & Events (A&E) - спецификация для уведомления клиента о событиях и сигналах тревоги, которые посылаются клиенту по мере их возникновения. Этот сервер пересылает аварийные сигналы, действия оператора, информационные сообщения, результаты контроля состояния системы;

· OPC HDA (Historical Data Access) - спецификация для доступа к предыстории процесса (к сохраненным в архиве данным). Сервер обеспечивает унифицированный способ доступа с помощью DCOM технологии. Обеспечивает чтение, запись и изменение данных;

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

· OPC Data eXchange - спецификация для обмена данными между двумя ОРС DA серверами через сеть Ethernet;

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

· OPC XML-DA - набор гибких, согласующихся друг с другом правил и форматов для представления первичных данных с помощью языка XML, веб технологий и сообщений SOAP (см. раздел "Архитектура автоматизированной системы".);

· OPC Complex Data - дополнительные спецификации к OPC DA и XML-DA, которые позволяют серверам работать со сложными типами данных, такими как бинарные структуры и XML-документы;

· OPC Commands - набор программных интерфейсов, который позволяет ОРС клиентам и серверам идентифицировать, посылать и контролировать команды, исполняемые в техническом устройстве (в контроллере, модуле ввода-вывода);

· OPC Unified Architecture - принципиально новый набор спецификаций, который уже не базируется на DСОМ технологии, подробнее см. раздел "Спецификация OPC UA".

Из перечисленных спецификаций в России широко используются только две: ОРС DA и реже - OPC HDA.

ОРС DA сервер

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

Существует четыре стандартных режима чтения данных из ОРС сервера:

· синхронный режим: клиент посылает запрос серверу и ждет от него ответ;

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

· режим подписки: клиент сообщает серверу список тегов, значения которых сервер должен отправлять клиенту только в случае их изменения. Для того, чтобы шум данных не был принят за их изменение, вводится понятие "мертвой зоны", которая слегка превышает максимально возможный размах помехи;

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

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

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

Рис. 2.1. Пример диалогового окна ОРС сервера NLopc фирмы НИЛ АП

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

· поиск подключенного к промышленной сети оборудования;

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

· создавать иерархическое представление имен тегов;

· наблюдать значения тегов;

· управлять правами доступа к ОРС серверу.

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

На рис. 2.1 показано диалоговое окно ОРС сервера NLopc (подробнее см. описание, pdf, 900 Кб) . Сервер позволяет выполнить поиск физических устройств, подключенных к СОМ-порту компьютера. На рис. 2.1 окно сервера слева показывает, что к компьютеру подключены три модуля ввода: NL16HV, NL8TI и NL8AI. Для удобства представления измеряемых величин (тегов) на объекте автоматизации имена тегов могут быть составными и путь к тегу может быть представлен в виде дерева, как показано на рис. 9.1. Имя выделенного на рисунке тега выглядит как "NL8TI.Laboratory32.Top.Vin4". Все имена и их структура задаются с помощью средств окна ОРС сервера.

Рис. 2.2. Пример диалогового окна навигатора тегов ОРС клиента

При использовании ОРС клиента (например, SCADA), имена тегов, доступные через ОРС сервер, представляются в аналогичной форме в окне навигатора тегов (рис. 9.2). Клиент показывает все ОРС серверы, установленные на компьютерах, доступных по сети Ethernet, и позволяет использовать все теги этих серверов.

Пример архитектуры систем, включающих ОРС серверы и ОРС клиенты, показаны на рис. 2.3 и рис. 2.4. В качестве ОРС клиента может выступать программа на языке С++ (например, SCADA-пакет) или программа на языке Visual Basic, VBA, Delphi или любая другая программа, поддерживающая внедрение СОМ-объектов (рис. 2.3). Программа на языке С++ взаимодействует с ОРС сервером через интерфейс OPC Custom, а программа на Visual Basic, VBA, Delphi - через интерфейс автоматизации OPC Automation. ОРС сервер и ОРС клиенты могут работать только на компьютерах и контроллерах с операционными системами, поддерживающими технологию DCOM (например, Windows XP и Windows CE).

ОРС сервер подключается к физическим устройствам любым способом; эти способы стандартом не предусмотрены. Например, сервер NLopc фирмы НИЛ АП использует для каждого физического устройства свой драйвер (рис. 2.3).

Клиентская программа и ОРС сервер могут быть установлены на одном и том же компьютере, как показано на рис. 2.3, или на разных компьютерах сети Ethernet (рис. 2.4). При наличии нескольких компьютеров каждый из них может содержать ОРС сервер и подключенные к нему физические устройства. В такой системе любой ОРС клиент с любого компьютера может обращаться к любому ОРС серверу, в том числе к расположенному на другом компьютере сети. Это достигается благодаря технологии DCOM, использующей удаленный вызов процедур (RPC - Remote Procedure Call). Например, SCADA на рис. 2.4 может обратиться за данными к модулю ввода-вывода по пути, указанному на рис. 2.4 штриховой линией. Обратим внимание, что компьютеры и контроллеры в такой архитектуре могут работать с разными промышленными сетями. Обмен данными с ПЛК, работающими с ОС Windows CE, выполняется точно так, как с компьютерами.

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

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

OPC HDA сервер

Целью OPC HDA сервера [OPC] (сервера предыстории процесса) является предоставление клиентской программе единого интерфейса для обмена данными с любыми хранилищами данных, в качестве которых может выступать нестандартный файл с данными, стандартная СУБД, OPC DA сервер или другой ОРС HDA сервер. Стандарт распространяется только на интерфейсы для взаимодействия HDA сервера с клиентскими программами и не устанавливает способов получения или хранения данных.

Спецификация OPC HDA устанавливает стандарт на интерфейсы СОМ объекта и методы его использования. Структура сервера и методы взаимодействия с клиентами полностью аналогичны общей идеологии ОРС и описанному выше OPC DA в частности. Например, ОРС клиент может подсоединяться к нескольким OPC HDA серверам разных производителей и быть установлен на разных компьютерах в сети Ethernet.

Существует два типа HDA серверов:

· простой сервер данных предыстории для построения графиков (трендов);

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

Работа с данными заключается в чтении, записи или изменении данных.

Рис. 2.4. Пример применения ОРС технологии для сетевого доступа к данным в системах автоматизации

Спецификация OPC UA

Несмотря на огромный успех и всеобщее признание, практика выявила следующие недостатки ОРС технологии [Wikipedia, Lange]:

· доступность только на операционных системах семейства Microsoft Windows;

· связь c технологией DCOM, исходные коды которой являются закрытыми. Это не позволяет решать вопросы надежности ПО, а также выявлять и устранять возникающие программные отказы;

· бывают проблемы конфигурирования, связанные с DCOM;

· неточные сообщения DCOM о прерываниях связи;

· неприспособленность DCOM для обмена данными через интернет;

· неприспособленность DCOM для обеспечения информационной безопасности.

В связи с этим в 2006 году OPC Foundation предложил новую стандартную спецификацию для обмена данными в системах промышленной автоматизации [OPC], получившую название "ОРС Unified Architecture" - "ОРС с унифицированной архитектурой", которая рассматривается как ОРС стандарт нового поколения.

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

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

OPC UA использует несколько различных форматов данных, основными из которых являются бинарные структуры и XML документы. Формат данных может быть определен поставщиком ОРС сервера или стандартом. Для работы с произвольными форматами клиент может запросить у сервера информацию об описании этого формата. Во многих случаях используется автоматическое распознавание формата данных во время их передачи.

OPC UA обладает высокой робастностью* данных и уведомлений о событиях. Робастность обеспечивается механизмом быстрого обнаружения ошибок коммуникации и восстановления данных.

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



2016-01-26 1241 Обсуждений (0)
Операционные системы реального времени 0.00 из 5.00 0 оценок









Обсуждение в статье: Операционные системы реального времени

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

Популярное:
Генезис конфликтологии как науки в древней Греции: Для уяснения предыстории конфликтологии существенное значение имеет обращение к античной...
Как распознать напряжение: Говоря о мышечном напряжении, мы в первую очередь имеем в виду мускулы, прикрепленные к костям ...
Почему двоичная система счисления так распространена?: Каждая цифра должна быть как-то представлена на физическом носителе...
Модели организации как закрытой, открытой, частично открытой системы: Закрытая система имеет жесткие фиксированные границы, ее действия относительно независимы...



©2015-2020 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (1241)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.015 сек.)