м даних для якої буде змінна% MW100 на PLC2. Для конфігурування OFS-сервера вікорістовується утіліта OFS Configuration Tool.
Дані визначаються Наступний чином (рис. 4):
створюється псевдонім, Який буде вказуваті на адресою конкретного пристрою, з яким может обмінюватісь ОРС-сервер. У нашому випадка псевдонім пристрою має ім я PLC2);
для створеня псевдоніму вказується драйвер зв язку, адреси пристрою та додаткові параметри, что уточнюють Місцезнаходження его в мережі; в нашому випадка в результате конфігурування створі адреси: MODBUS01: 1/T;
для створеня псевдоніму пристрою вказаті файл, в якому будут знаходітісь сімвольні імена та відповідні Їм змінні контролера. У нашому випадка Вибраний файл PLC2.CSV, в якому сформованому запису:
% MW100 PRESSURE
Відповідно до правил іменування змінніх в OFS, Ідентифікатор потрібної змінної буде формуватіся Наступний чином:=Ім я_псевдоніму_прістрою! Ім я_змінної
У нашому випадка Ідентифікатор змінної буде? PLC2! PRESSURE.
Рис. 3 Схема обміну данім SCADA Citect з використанн ОРС
Рис. 4 Конфігурування ОFS
Рис. 5 Конфігурування VIPA-OPC
Рис. 6 Створення в Citect IODevices, прив язаних до OPC-серверів
Рис. 7 Створення в Citect Variable Tags
Клієнт-серверна модель. ОРС DA технологія базується на клієнт-серверній архітектурі. ОРС-клієнт корістується услуг ОРС-сервера, вікорістовуючі СОМ-інтерфейси его про єктів. У наведенні на рис. 8 прікладі, ОРС-Клієнтом є SCADA-программа, задачею якої є відображення чотірьох змінніх (% MW100-% MW103) які знаходяться на ПЛК. OPC-Сервер отрімує необхідні дані через драйвер зв язку и зберігає їх у своїй базі даних реального годині. Для того щоб доступітіся до даних ОРС-сервера, ОРС-клієнт створює для себе ОРС-Group (Group1, Group2), в якіх створює ОРС-Item (Item1, Item2), что посілаються на ЦІ дані.
ОРС-клієнт ( OPC Client ) - прикладна програма, яка Вміє користуватись про єктами OPC-сервера помощью ОРС-інтерфейсів (підмножіна СОМ-інтерфейсів).
ОРС-сервер ( OPC Server ) - прикладна програма, яка надає доступ до визначених в Специфікації ОРС СОМ-об єктів помощью ОРС-інтерфейсів.
З одним ОРС-сервером могут з єднатіся декілька ОРС-КЛІЄНТІВ. З Іншого боці, одна и та сама програма ОРС-клієнт, может одночасно користуватись услуг декількох ОРС-серверів. Тобто ОРС технологія є мультіклієнтною и мультисерверного.
Так як ОРС-сервер - це СОМ-сервер, ВІН реєструється на комп ютері унікальнім числові ідентіфікатором (GUID) та має Унікальний Строковий програмний Ідентифікатор ( ProgID ). Тобто, для того щоб для ОРС-клієнта візначіті з Яким ОРС-сервером на тому самому ПК Йому необходимо з єднатіся, достаточно вказаті его ProgID.
Про єкт ОРС-Item надає доступ до джерела даних (надалі тег ) в межах ОРС-сервера, Пожалуйста ідентіфікується унікальнім в межах сервера ідентіфікатором ItemID . Тому при створенні ОРС-Item а, вказується ItemID необхідного тега. Правила ідентіфікації даних залежався від реализации ОРС-сервера, а Механізм визначення їх джерел (например адреси пристрою та змінної в ПЛК) як правило реалізується в конфігураторі цього сервера. У прікладі ми Вже розглянулі дві варіанта формирование ItemID, нижчих більш детально розгялнуті Способи ідентіфікації тегів. Тут только зазначімо, что весь список ItemID может мати деревоподібних ієрархічну структуру, что дозволяє зручніше використовуват цею Механізм в проектах з великою кількістю даних. Для навігації по списку/дереву ідентіфікаторів ОРС-сервер, як правило, має про єкт OPC Browser .
ОРС-Item Належить Клієнту, Який его Створив и того его НЕ могут використовуват декілька Клієнтів. Тім НЕ менше Є можливість посілатіся на одні и ті ж дані. На рис. 8 дві Клієнта одночасно Використовують дані з% MW100 та% MW102, однак створюють для цього Різні OPC-Item. Слід відмітіті, что Джерелом даних НЕ обов язково є змінна на зовнішньому Пристрої, це могут буті внутрішні дані самого Серверу.
З шкірних ОРС-Item'ом асоціюється Пліній значення ( Value ), Відмітка годині ( Time Stamp ) та якість (
