Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати. Для цього режиму працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.
Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати. Для цього режиму працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.
−
−
== {{Anch|TimeStamp|Мітка часу джерела даних}} ==
−
Фактично всі джерела даних, які підтримуються OpenSCADA, у якості мітки часу оперативних-потокових даних використовують час комп'ютера де працює OpenSCADA та здійснюється опитування цих джерела даних, навіть у випадку можливості отримання часу серверу або джерела у джерела даних, і часто навіть у випадку коли таким джерелом виступає інша станція-ПЛК з OpenSCADA.
−
−
Такий підхід визначено з декількох причин, а саме:
−
* розрізнення та виокремлення відмінності часу оперативних значень джерела даних та ПК збору даних не має жодної практичної мети окрім діагностичної з виявлення самого розходження часу, оскільки поточні дані архівуються у архів періодичних значень, де мітка часу так чи інакше притягується та округляється до цієї періодичності, тобто частина часу точніша за період даних архіву втрачається;
−
* рідко яке джерело даних взагалі має годинник реального часу, а коли і має то до нього одразу ставиться вимога синхронізації часу із зовнішнім джерелом зразкового часу, що у свою чергу вимагає вирішення складнощів із прямим підключенням GPS приймача або доступом до NTP-серверу у інтернет або локальній мережі; за визначеним-же підходом зразковим часом стає час ПК збору даних, навіть коли він сам не синхронізований, оскільки він один;
−
* мітка часу джерела даних може змінюватися з власною періодичністю або це оновлення взагалі може бути аперіодичним, що у випадку використання цієї мітки при опитувані призведе до прогалин у архіві, та навіть коли періодичності опитування-архівування та оновлення мітки часу джерела однакові такі прогалини будуть мати місце через відсутність синхронності, що доведеться компенсувати зменшенням періодичності опитування та, відповідно, збільшенням навантаження на мережу та джерело; відтак це зробить архів мало корисним, хоча наразі і надається можливість вважати такі прогалини (прохідні) не фактом відсутності або помилковістю даних;
−
−
Наразі відомо один метод, коли від мітки часу джерела даних є практична цінність, це робота з історією-архівом на боці джерела даних, коли за виявленням прогалин у даних, наприклад, на час відсутності зв'язку, замість поточних-оперативних даних запитується ділянка історії-архіву, що відповідає цій прогалині. Та цей метод реалізовано у модулі [[Special:MyLanguage/Modules/DAQGate|DAQ.DAQGate]], при роботі OpenSCADA на боці джерела даних або ПЛК.
Revision as of 19:52, 27 January 2019
Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати. Для цього режиму працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.