|
|
Контроллер со встроенным ОРС-сервером |
|
Бывают ли такие? Windows CE? Я так понимаю, что под него от производителя PLC должен быть специальный OPC-сервер именно для Windows CE. Может есть какое-нибудь универсальное решение?
Стоит задача повышения надёжности опроса контроллеров ADAM. |
|
 |
|
|
В CoDeSys есть OPC сервер под WinCE. Другое дело, что для Адамов нет CoDeSys. Технически всунуть его туда очень просто (мы делали для ВинКон), однако это все же некоторые доп. затраты и хлопоты, которые более правильно возложить на изготовителя или поставщика контроллеров.
В принципе же, идея ставить OPC внутрь контроллера очень разумная. В более серьезных контроллерах вовсю применяется. |
|
|
Igor Petrov
|
|
|
|
В каких? |
|
|
|
|
Внутрь OPC ставят компании Lenze Digitec Controls и Bosch Rexroth (см. VEP). Из наших НИЛ АП делает контроллеры NLcon-CE с CoDeSys и WinCE, штатно в них нет OPC, но если они сочтут нужным, то воткнуть его можно за полдня. Однако можно и еще проще. Например, взять контроллер Овен. По последовательным каналам навешать к нему Адамов сколько надо. Далее по Ethernet подключить сколько надо компьютеров и операторских станций. Причем в простых случаях визуализацию (HMI) можно делать прямо в CoDeSys без SCADA и OPC (и дешевле и надежнее). |
|
|
|
А ОРС-сервер будет стоять на другом компьютере? Нам прежде всего нужна надёжность ОРС-сервера. Помимо визуализации нужна архивация на SQL-сервер. Как снимать показания Адамов с Овена? Если он будет работать как сервер последовательных интерфейсов, то одновременно с нескольких ОРС-серверов на разных машинах(подключаться как виртуальный СОМ-порт),с периодом опроса 1 сек(м.б. и меньше) эта схема не будет работать, или я ошибаюсь? |
|
|
|
|
Уже писал в соседнем разделе, повторюсь. Ставим Овен (например ПЛК100) который по последовательному порту (RS-485) опрашивает Адамы (протокол в Овене уже реализован остается только настроить). А затем остается только подключиться к Овену одним из следующих способов: 1) Подключаемся по Ethernet визуализацию рисуем в Codesys HMI (лицензия порядка 200 евроденег, на каждого клиента) обмен идет по протоколу Getway сервера. Но как тут присобачить SQL незнаю. 2) Если машин (верхнего уровня) в сети несколько, то можно поставить на каждую ОРС сервер а SCAD-у настроить на использование своего ОРС-сервера как основного и остатьных серверов в сети как резервных. Например DataWorks в Genesys это реализует. 3) Написать руками протокол обмена используя библиотеку TcpUdp.lib и самомуже реализовать ПО верхнего урорвня. 4) Написать на ПЛК Овен небольшой проектик который перекладывает полученные данные с Адамов на Модбас TCP и опять же по Ethernet к скаде. 5) Тоже что в 4 но по последовательному интерфейсу (RS-232) если клиент один.
|
|
|
|
|
Если говорить о CoDeSys HMI, то надежность обеспечивается тем, что 1) OPC сервера нет вообще 2) данные можно аккумулировать в контроллере. На Овене пишем программку, которая собирает данные с Адамов, объединяет, обсчитывает их как надо, может тут же и в файл архивный записать. Операторский(кие) компьютеры подключаются по Ethernet, причем нет нужды постоянно иметь надежный канал связи. Компьютер может быть спокойно выключен, перезагружен и др. Контроллер тут выполняет роль коммуникационного сервера. Если задача не разовая, то можно самим сделать спец. устройство (или подобрать готовое). Есть такие компьютеры в одной микросхеме Beck IPC@CHIP. Можно использовать OPC либо вообще запустить в этом устройстве web-визуализацию и управлять с любого числа удаленных компьютеров подключенных по ненадежным каналам. |
|
|
|
|
ИМХО несмотря на отсутствие ОРС сервера надежность не повышается ни на чуть ибо остается Getway сервер. А вот вариант с резервированием связки Getway+ОРС вполне приемлем. |
|
|
|
|
Обмен данными через GateWay обеспечивает работу узлов в режиме реального времени. То что НЕ исключаемая задача (сетевого обмена) вынесена в отдельное приложение на надежность влияния не оказывает. По причине ее наличия в том или ином виде, выделенном или интегрированном во всех системах как таковых. В данном случае применен контрактный подход для обеспечения универсальности средств коммуникации не более того. OPC обмен выполняется на базе механизма DCOM и основан на обратном вызове процедур в среде с вытесняющей многозадачностью. Строго говоря не должен рассматриваться как возможная альтернатива GateWay CoDeSys. По поводу внедрения OPC сервера в контролер: ИМХО это не совсем здравая идея, во первых контролер как правило является достаточно важным узлом системы и по сему желательно и иметь заранее определенный фиксированный набор абонентов, что OPC не гарантирует. Это может привести к неконтролируемому изменению нагрузки на контроллер. И второе, контроллер с точки зрения безопасности вещь прозрачная, посему он не должен служить прямым источником данных. Имхо он должен быть загейтован и максимально разгружен от задач предоставления данных клиентам, для этого есть внешние сервера в том числе OPC. Это к вопросу о безопасности и стабильности… |
|
|
|
|
По надежности связка PLC-Gateway-OPC-HMI выигрывает если выбросить из нее OPC. Уходит конфигурирование через файлы и сложный обмен через COM объекты. Чем меньше передаточных звеньев, тем лучше. OPC внутри ПЛК не столь уж плохая идея. Процессоры и память сейчас быстрые и дешевые. Экономить на них сложно. ОС в ПЛК позволяет сделать так, что сервер (даже Web) практически ни на что не влияет. Стратегически было бы очень здорово иметь некий высокоуровневый и стандартный для любого ПЛК протокол доступа к данным. Сейчас мы имеем: (SCADA - OPC - драйвер-шлюз) -- ПЛК. Если скобки расставить иначе: SCADA -- (OPC - драйвер-шлюз - ПЛК), то будет явно техничнее. |
|
|
|
Ответить 
|
Страница 12> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
