19501

Аппаратная реализация связи с устройствами ввода/вывода

Доклад

Информатика, кибернетика и программирование

Аппаратная реализация связи с устройствами ввода/вывода. Для организации взаимодействия с контроллерами могут быть использованы следующие аппаратные средства: COM порты. В этом случае контроллер или объединенные сетью контроллеры подключаются по протоколам RS...

Русский

2013-07-12

167.5 KB

9 чел.

Аппаратная реализация связи с устройствами ввода/вывода.

Для организации взаимодействия с контроллерами могут быть использованы следующие аппаратные средства:

  •  COM - порты. В этом случае контроллер или объединенные сетью контроллеры подключаются по протоколам RS-232, RS-422, RS-485.
  •  Сетевые платы. Использование такой аппаратной поддержки возможно, если соответствующие контроллеры снабжены интерфейсным выходом на Ethernet.
  •  Вставные платы. В этом случае протокол взаимодействия определяется платой и может быть уникальным. В настоящее время предлагаются реализации в стандартах ISA, PCI, CompactPCI.

Описание межпрограммного протокола – DDE

Развитие механизмов взаимодействия приложений друг с другом протекало постепенно. В первых версиях операционной системы Windows для организации обмена данными между потоками различных приложений использовался механизм DDE (Dynamic Data Exchange – динамический обмен данными). Протокол DDE применялся также в первых человеко-машинных интерфейсах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК.

Механизм DDE основан на пересылке данных через буфер обмена Windows.

Буфер обмена – это область памяти, предоставляемая операционной системой для обмена данными между приложениями. В Windows существуют специальные средства для работы с этим буфером. К ним относятся:

- функции помещения данных в буфер и извлечения данных из буфера;

- функции проверки наличия данных в буфере;

- предусмотрены 25 встроенных в операционную систему форматов данных (изображение, фрагмент текста, звук и т.д.);

- имеется возможность создания своих типов данных;

- имеется возможность обмениваться командами.

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

К недостаткам DDE относятся:

- низкая скорость обмена данными;

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

До последнего времени DDE оставался основным механизмом, используемым для связи с внешним миром в открытых программных системах, в частности, в ИСПиУ. Но он не совсем пригоден для обмена информацией в реальном масштабе времени из-за своих ограничений по производительности и надежности.

Для преодоления недостатков DDE, прежде всего для повышения скорости обмена, разработчики предложили свои собственные протоколы, такие как AdvancedDDE и FastDDE. В основе этих протоколов лежит пакетирование информации, что позволяет ускорить обмен данными. Но такие частные решения приводят к ряду проблем:

- для каждой программной системы необходим свой собственный драйвер для поставляемого на рынок оборудования;

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

Взамен семейства протоколов обмена, основанных на DDE, компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами – OLE.

Описание типового интерфейса общения программ – OLE

OLE - Object Linking and Embedding (связывание и внедрение объектов). Данная, разработанная Microsoft технология позволяет в среде Windows обмениваться объектами (программами) между программой-поставщиком (сервером OLE) и программой-получателем (клиентом OLE). Яркими примерами OLE – взаимодействий являются вставка рисунка Paint в документ Word, вставка электронной таблицы Excel в документ Word.

На рисунке 11 показана схема OLE-взаимодействия приложений.

Рис. 11. Схема OLE-взаимодействия приложений.

В рамках технологии OLE базовым является понятие «документ». Документ – это «базовый» объект, с которым происходит связывание или в который происходит внедрение других объектов.

Связывание объекта (Linking) действие, при котором объект не переходит к клиенту, а последний хранит о нем визуальное представление и его адрес в сервере. Если в сервере объект изменился, то и клиент будет его иметь в измененном виде.

Внедрение объекта (Embedding)действие, при котором объект переходит к клиенту, а последний запоминает сервер и при необходимости редактировать объект он обращается к серверу для проведения этого действия;

Копирование объекта  одномоментное действие, при котором объект теряет связь с сервером и переходит к клиенту;

OLE–объект – это часть данных, которая совместно используется несколькими приложениями.

OLE-контейнер – приложение, в которое может быть встроен OLE-объект.

OLE-сервер – приложение, которое способно создавать и обслуживать OLE-объекты.

В настоящее время OLE функционирует на базе использования COM-технологии. Современная версия OLE, основанная на COM, называется OLE 2.0.

Особенности OLE 2.0:

- наличие идентификаторов (уникальных номеров) объектов;

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

К достоинствам OLE относятся:

- стандартность;

- открытость;

- более высокое, по сравнению с DDE, быстродействие;

- более высокая надежность.

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

Недостатки OLE:

- нет принципиальных ограничений на действия встраиваемых объектов;

- отсутствуют стандартные механизмы информирования о событиях.

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

Описание технологии – COM/DCOM

COM (Component Object Model – модель многокомпонентных объектов) - технология. Для инструментальных систем и систем управления, реализованных на платформе Windows, фирмой Microsoft предложена архитектура компонентных объектов.

Компонент – это готовый к использованию двоичный код, содержащийся либо в динамической библиотеке (DLL), либо в EXE-файле, который может быть при необходимости загружен в память и стандартным образом динамически подключен к приложению. Две основные черты компонентов:

- динамическое связывание – означает, что связь компонента и приложения (т.е. связь между вызовом функции в приложении и ее кодом в теле компонента) осуществляется не на этапе компоновки приложения, а непосредственно во время его выполнения;

- скрытая внутренняя реализация (инкапсуляция) – означает, что для приложения не важно, и приложение не знает, как именно реализован компонент внутри, а только знает, как вызывать его функции.

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

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

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

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

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

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

Таким образом, COM - это спецификация, указывающая, как создавать динамически взаимозаменяемые компоненты. COM определяет стандарт, которому должны следовать компоненты и клиенты, чтобы гарантировать возможность совместной работы. Компоненты COM состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек (DLL) или EXE-файлов Win32. Но сама по себе динамическая компоновка не обеспечивает компонентной архитектуры. Компоненты COM объявляют о своем присутствии стандартным способом. Используя схему объявлений COM, клиенты могут динамически находить нужные компоненты. Отметим, что реализация этой возможности возложена на операционную систему.

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

Рис. 12. Интерфейс COM.

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

DCOM (Distributed Component Object Model – модель распределенных компонентных объектов) - программная архитектура, разработанная компанией Microsoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одной из машин может использовать DCOM для передачи сообщения (его называют удаленным вызовом процедуры) компоненту на другой машине. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленного компонента. В принципе, в случае использования технологии DCOM не важно, находятся клиентская часть приложения и компонент (сервер) на разных ЭВМ или на одной. На рисунке 13 показана схема взаимодействия приложения и компонента при помощи интерфейса DCOM.

Рис. 13. Взаимодействие через интерфейс DCOM.

Распределенная компонентная архитектура DCOM поддерживает множество распространенных сетевых протоколов: TCP/IP, UDP, IPX/SPX, NetBIOS и др., поэтому программы, использующие технологию DCOM, могут работать в различных типах сетей.

Описание ОРС

Основная цель OPC стандарта (OLE for Process Control) заключается в определении механизма доступа к данным с любого устройства из приложений. OPC позволяет производителям оборудования поставлять программные компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК.

Стандарт ОРС разрабатывался специально для использования в промышленной автоматизации, и он имеет проблемно-ориентированную модель взаимодействия, которая реализована через совокупность COM/DCOM - интерфейсов.

Стандарт состоит из трех основных спецификаций:

1) доступ к данным РВ (Data Access);

2) обработка тревог и событий (Alarms & Events);

3) доступ к историческим данным (Historical Data Access).

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

Центральное место среди спецификаций ОРС занимает доступ к данным РВ (Data Access). Базовым понятием этой спецификации является элемент данных (Item). Каждый элемент данных (т. е. фактически - параметр технологического процесса) имеет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа (булево, целое, с плавающей точкой и т.п.) или строкой (на самом деле это так называемый OLE VARIANT). Время представляется с 100-наносекундной точностью (на самом деле это FILETIME Win32 API). Качество - это код, содержащий в себе грубую оценку достоверности параметра -UNCERTAIN, GOOD и BAD (не определено, хорошее и плохое), а на случай плохой оценки - еще и расшифровку, например, QUAL_SENSOR_FAILURE -неисправность датчика.

К этому типу взаимодействия можно отнести следующие SCADA - системы: InTouch фирмы Wonderware, iFix фирмы Intellution, Genesis фирмы Iconics и др.

Описание языка запросов к реляционным СУБД - SQL

SQL - Structured Query Language (реляционный структурированный язык запросов). Это международный стандарт, первая версия которого была утверждена в 1989 г. В настоящее время он поддерживается подавляющим большинством СУБД, которые имеют для этого компилятор запросов языка SQL. В целом, язык SQL является универсальным средством общения пользователей и их прикладных программ с СУБД.

Язык SQL строится как логическое условие выборки определенных данных из одной или ряда таблиц (файлов) СУБД; он базируется на широком использовании различных предикатов и кванторов.

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

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

Описание обмена программ с СУБД на базе драйвера ODBC

ODBC - Open DataBase Connectivity (открытое взаимодействие баз данных). Стандарт Microsoft - ODBC позволяет взаимодействовать приложениям (программам), работающим в среде Windows, посредством операторов языка SQL с различными СУБД, функционирующими под различными операционными системами. Фактически, ODBC это интерфейс, обеспечивающий взаимную совместимость серверных и клиентских компонентов доступа пользователя к данным.

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


 

А также другие работы, которые могут Вас заинтересовать

50685. Определение отношения Сp/Cv воздуха методом Клемана и Дезорма 22 KB
  Тема: Определение отношения Сp Cv воздуха методом Клемана и Дезорма. Цель работы: определение отношения Сp Cv.
50686. Моделирование дискретной случайной величины 267 KB
  Цель работы. Практическое освоение алгоритма программной генерации дискретной случайной величины и методов статистической проверки разработанного генератора.
50687. Форматирование таблицы с использованием встроенных форматов 120 KB
  Упражнение Отметим что к этой таблице уже был применен автоформат с именем Классический 1. После применения автоформата можно изменить форматирование некоторых ячеек таблицы. Примените к ячейке B1 следующий формат: диалоговое окно Формат ячеек закладка Число категория Денежный число десятичных знаков – 0 обозначение денежной единицы – р.
50689. Построtybt графf состояний СМО 293.5 KB
  Также построить имитационную модель и исследовать ее (разработать алгоритм и написать имитирующую программу, предусматривающую сбор и статистическую обработку данных для получения оценок заданных характеристик СМО). Распределение интервалов времени между заявками во входном потоке и интервалов времени обслуживания – геометрическое с соответствующим параметром...
50690. Моделирование потока Пуассона 158 KB
  Практическое освоение алгоритма программной генерации стационарного потока Пуассона и методов статистической проверки разработанного генератора.