Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Аппаратное обеспечение управления ТП





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

Внешнее Аппаратное Обеспечение

In Touch осуществляет взаимодействие с технологическими машинами посредством программируемого логического контроллера через Wonderware OPCLink и Merz OPC Simatic MPI Server.

OPCLink обнаруживает Merz OPC- Сервер.

OPCLink соединяется с серверами Merz OPC, конвертирует клиентские команды в OPC протокол и возвращает данные клиентам, использующим DDE, FastDDE, или SuiteLink.

 

Аппаратное Обеспечение АРМ

Для работы In Touch рекомендуется следующее аппаратное и программное обеспечение:

- любой совместимый с ОС Microsoft процессор;

- не менее 5 Гб свободного места на жестком диске;

- не менее 2 Гб оперативной памяти (RAM);

- адаптер дисплея SVGA и новее;

- манипуляторное устройство (мышь, сенсорный экран, трекбол);

- операционная система Microsoft Windows.

Сетевая архитектура

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

Автономное приложение

Автономными называются приложения, использующие по одному интерфейсу оператора на каждый контролируемый процесс. Такое приложение работает на одиночном не подключенном в сеть персональном компьютере (ПК), который выступает в роли первичного интерфейса оператора (ИО). Этот компьютер соединяется с производственным процессом через прямое подключение, например, с помощью кабеля последовательного порта или Ethernet.

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

Преимущества:

• простота обслуживания.

Недостатки:

• ограниченность одним узлом.

Рисунок 1– Автономное приложение

Архитектура на базе клиента

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

уникальной копии одного приложения InTouch на каждом компьютере, где

работает WindowViewer и NetDDE (узел просмотра). Приложение может быть

установлено на каждом таком компьютере или в отдельном каталоге на сетевом

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

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

ввода/вывода, базы данных SQL, файлы DOS и т.д. При работе с центральным

источником данных, например, совместно используемым сервером ввода/вывода,

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

сервером, что может приводить к повышенному сетевому трафику. Чтобы этого

избежать, можно разместить отдельные серверы ввода /вывода на каждом узле.

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

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

узел просмотра приходится локально останавливать, копировать на него

обновленное приложение, затем снова запускать узел.

 

Рисунок 2 – Архитектура ведущий/ведомый

 

Преимущества:

• неограниченные возможности разработки приложения;

• неотъемлемая избыточность, поскольку каждый узел является

самодостаточным;

• неограниченное количество узлов просмотра.

Недостатки:

• распределение приложений – непростая задача;

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

Архитектура на базе сервера

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

приложение в программе InTouch.

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

Размещение источников данных можно настроить с помощью комбинации

сценариев, изменив путь к каждому источнику данных в зависимости от имени

узла. " Более подробную информацию можно найти в разделе «Настройка InTouch

для работы с общими источниками данных».

 

Рисунок 3 – Архитектура на базе сервера

 

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

Преимущества:

• поддержка только одного приложения;

• узлы просмотра автоматически обновляются при изменении приложения.

Недостатки

• ограниченные возможности разработки приложения;

• отсутствие избыточности в случае отказа станции разработки;

• все узлы должны использовать одинаковое разрешение дисплея.

Примечание. Данная архитектура теперь заменена на архитектуру NAD, о

которой подробно говорится далее в этой главе. Приводимое здесь описание

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

Архитектура ведущий/ведомый

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

Рисунок 4 – Архитектура ведущий/ведомый

Разработка приложения в архитектуре ведущий/ведомый требует определенного планирования, поскольку все тэги должны относиться к разряду внешних тэгов. Каждый такой тэг должен использовать полностью совместимую с NetDDE ссылку на "ведущий" узел. Например, Node = Master7, App = View, Topic =tagname. При выполнении такого приложения на "ведущем" узле ссылки будут указывать на локальные ресурсы; при выполнении на "ведомом" узле они будут указывать на удаленные источники "ведущего" узла. Для упрощения процедуры распределения приложений клиенты могут оповещаться об изменениях с помощью системного тэга $ApplicationVersion. Тэг $ApplicationVersion отражает текущий номер версии приложения, который возрастает при каждом изменении на "ведущем" узле. $ApplicationVersion может отслеживаться для оповещения "ведомых" узлов о произошедших изменениях. Для снижения сетевого трафика внешние тэги на ведущем узле, как правило, ссылаются на сервер ввода/вывода, подключенный к процессу. Однако ведомые узлы ссылаются на WindowViewer ведущего узла. Это означает, что словари тэгов ведущего узла и ведомых узлов не являются идентичными. Поэтому необходимо учитывать факторы синхронизации тэгов различных приложений InTouch.

Преимущества:

• предотвращается перегрузка сетевого трафика за счет концентрации потоков передачи данных в одном источнике (ведущем узле);

• автоматическое оповещение об изменении приложения с помощью

$ApplicationVersion.

Недостатки:

• распределение приложений – непростая задача;

• единственный источник разработки приложения — отсутствие избыточности может вызвать проблемы при отказе ведущего узла;

• базы данных на ведущем и ведомых узлах, как правило, не идентичны.







ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычис­лить, когда этот...

Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.