|
Повідомлення створено: 25. 02. 2015 [09:38]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Добрый день. Есть некоторые соображения по архивации атрибутов параметров (тегов). Как правило теги организованы в группы которые связаны с технологической установкой, а на уровне Openscada технологическая установка отражается в объекте контроллера. Объект контроллера может быть объектом блочного вычислителя или логического контроллера (java). В настоящее время запись тегов в базу данных (БД) например SQLite производиться по принципу 1-н тег=1-на таблица. Т.о. поле (столбец) времени=TM дублируется многократно в группе таблиц в БД. Такое решение понятно - быстрая запись по каждому параметру, удобная привязка/отвязка тегов на архивирование без потери данных (пересоздания таблиц). При таком решении задача связывания тегов в набор конкретной технологической установки уходит на верхний уровень, в своё время при работе с тепловычислителями СПТ961 решал такую задачу, был момент когда на верхний уровень каждый из параметров (тегов) уходил отдельной таблицей. Чтобы склеить её в единый набор приходилось накладывать на эту кучу таблиц индексацию, склеивать Join таблицы по ключевому полю, бороться с дырками в данных. Т.е. на уровне SQL сервера крутилась целевая задача склейки около 100-ни тегов по полям - дата время, эта задача была "тяжёлой" и занимала большую часть процессорного ресурса. Потом разработчики СПТ961 доработали ПО в контроллере и ПО верхнего уровня, данные стали уходить 1-м набором содержащим всего один столбец времени ДАТА + столбцы тегов. Обрабатывать такой набор данных на верхнем уровне стало намного удобнее, не надо было склеивать столбцы, нагрузка на процессор упала раз в 100. Минус такого решения -набор тегов жёстко фиксирован, в случае его модификации - таблицу в БД необходимо создавать с чистого листа.
Собственно говоря мысль такая. Роман, насколько сложно и целесообразно на ваш взгляд сделать в контроллере возможность архивации тегов в 1-ну таблицу, содержащую один столбец с полем времени, а другие столбцы - теги у которых включен атрибут архивации на БД. Т.е. возможность группировки архивируемых тегов в набор, привязанный к контроллеру Openscada. Естественно с возможностью обратного переключения на концепцию - 1-н тег=1 таблица. Понимаю что можно создать свой SQL запрос на формирование такой таблицы, выделить под это дело контроллер и получить результат, но мне кажется что решение данного вопроса на уровне разработчика, с возможность настройки архивации тегов контроллера через GUI , т.е. глобально будет иметь более высокое качество решения задачи. Данный вопрос пожалуй связан с концепцией архивирования и обработкой наборов данных на среднем и верхнем уровне АСУТП, о чём неоднократно писал Алмаз, я его полностью поддерживаю в данном вопросе. Знаю что вы думаете сейчас над доработкой концепции архивирования, надеюсь моё мнение будет учтено.
|
|
Повідомлення створено: 25. 02. 2015 [12:24]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"pentagon128" wrote:
Собственно говоря мысль такая. Роман, насколько сложно и целесообразно на ваш взгляд сделать в контроллере возможность архивации тегов в 1-ну таблицу, содержащую один столбец с полем времени, а другие столбцы - теги у которых включен атрибут архивации на БД. Т.е. возможность группировки архивируемых тегов в набор, привязанный к контроллеру Openscada.
Архивацию осуществляет не контроллер, даже не понятно в каком смысле он тут упомянут, а подсистема архивации.
Что касается архивации в БД с группировкой в одну таблицу, то такая задача давно стоит: http://wiki.oscada.org/HomePageEn/Works/ToDo#h751-17
Только это ни разу не группировка по признаку принадлежности к объекту контроллера или параметра, а сквозная группировка по мере наполнения к лимиту сигналов в одной таблице.
Однако произвольную группировку можно легко сделать созданием разных архиваторов.
"pentagon128" wrote:
Знаю что вы думаете сейчас над доработкой концепции архивирования, надеюсь моё мнение будет учтено.
Конкретно сейчас да и вообще не думал, как минимум по причине того, что всё давно продумано и это вопрос только реализации, которая конкретно сейчас для меня не самая важная и полно других, более приоритетных задач.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 25. 02. 2015 [12:55]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Хорошо. Ситуация понятна. Про существующую подсистему архивации я знаю. Контроллер в контексте упомянул как логическую группу обработки тегов, как правило у меня он привязан к технологическому объекту. Сквозная группировка по мере наполнения к лимиту сигналов в одной таблице тоже хорошее решение, главное это привязка тегов к логическому объекту в БД которая позволит легко с ними работать на среднем и верхнем уровне АСУТП.
|
