На форуме обязательно:
  1. Заполнить свой профиль НА РУССКОМ ЯЗЫКЕ КИРИЛИЦЕЙ. См. Правила, п.2.d.
  2. Не писать свой вопрос в первую попавшуюся тему, а вместо этого создать свою. См. Правила, п.3.a.

Рекламу мы не размещаем ни на каких условиях.

Дарю разработчикам идею по хранению трендов

SCADA, серверы, АРМ верхнего уровня, диспетчерские
Ответить
Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2789
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 56 раз
Поблагодарили: 41 раз

Дарю разработчикам идею по хранению трендов

Сообщение VADR » 14 ноя 2016, 10:12

Может быть, это уже используется у кого-то, но я не встречал.
Идея в следующем:
1. Создаём таблицу единиц измерений для хранимой величины. Одну из единиц измерения считаем основной (к примеру, ту, которая в СИ стандартная). В таблице прописываем все используемые единицы измерения для этого параметра и формулы перехода от них к основной и обратно. К примеру, для давления стандартной называем Па, и в таблице вводим МПа, кПа, кгс/см2, вплоть до фунтов силы на квадратные дюймы.
2. При создании тренда указываем тип параметра и единицу измерения, в которой приходят данные. Перед сохранением - по формуле из п.1. приводим к основной единице измерения и в этих единицах пишем.
3. При запросе данных указываем тип параметра и единицу измерения, в которой хотим получить данные. При чтении - читаем в основных единицах и по формуле из п.1 переводим в требуемые.
Что это даст:
1. При каких-то переделках технологии или управлении, если вдруг вздумается на каком-то параметре изменить единицы - старые накопленные данные не будут бесполезными и не будет необходимости учитывать то, что когда-то тут были Кельвины, а стали Фаренгейты.
2. Если на предприятии несколько объектов, на которых используются разные единицы измерения:
2.1. Проще делать дополнительные расчёты. Формулы забиваются также, исходя из основных единиц измерения, приведение к нужным производится автоматически.
2.2. Проще сводить балансы. Массовые расходы можно просто сложить, не заморачиваясь тем, что в одном месте килограммы в секунду, а в другом - тонны в час.
Как-то так.

ЗЫ: А если кто-нибудь из разработчиков применит и в ответ захочет подарить мне лицензию на такой продукт - совсем не откажусь :)
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


Romcheg
SCADA+
SCADA+
Сообщения: 547
Зарегистрирован: 05 ноя 2009, 11:18
Имя: Бузинов Роман Анатольевич
Благодарил (а): 6 раз
Поблагодарили: 17 раз

Дарю разработчикам идею по хранению трендов

Сообщение Romcheg » 14 ноя 2016, 11:59

Чтобы зарабатывать на полезной модели - ее надо сначала запатентовать. :-P
Вообще - идея хранения "сырых" данных в архивах не нова. Вот только многих разработчиков смущает именно необходимость преобразования данных перед их отображением, многие, стремясь к повышению скорости обработки, стараются как можно меньше промежуточных шагов делать между выборкой и ее отображением на графике.
По Вашим плюсам:
1) После переделки технологии и ухода на другие единицы - старые данные можно также преобразовать. Это делается 1 раз.
2.1) Именно благодаря понятию первичной обработки данных - переход на другой объект выполняется в проекте банальной сменой множителя, или формулы в настройках параметра.
2.2) Вот тут как-то не совсем понял: как можно сложить кг/с с т/час и не заметить разницы - разве балансы смогут сойтись, если параметры в разных единицах измерения будут? И какой вообще смысл в результате сложения абсолютно разномерных величин?
SCADA+

Аватара пользователя

izhidkov
освоился
освоился
Сообщения: 298
Зарегистрирован: 25 фев 2016, 12:18
Имя: Жидков Игорь Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 7 раз
Контактная информация:

Дарю разработчикам идею по хранению трендов

Сообщение izhidkov » 14 ноя 2016, 13:40

В этом случае может быть путаница с характеристиками каналов. Кроме этого каждый производитель возьмет разный параметр за "образцовый", т.о. передача параметров будет затруднительная.
Компилятор - лучший друг человека!

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2789
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 56 раз
Поблагодарили: 41 раз

Дарю разработчикам идею по хранению трендов

Сообщение VADR » 14 ноя 2016, 16:45

Romcheg писал(а): После переделки технологии и ухода на другие единицы - старые данные можно также преобразовать. Это делается 1 раз.
При этом остаётся старый тренд в старых единицах. Если придётся просматривать историю "до того, как" - как-то надо будет иметь в виду, что там надо делать пересчёт. Можно, конечно, скриптом базу обработать и привести к сегодняшним размерностям. А если данные уже не в базе, а в архиве, записаны на ленты и убраны в шкаф? Такие резервные копии тоже существуют и используются.
Romcheg писал(а): Вот тут как-то не совсем понял: как можно сложить кг/с с т/час и не заметить разницы - разве балансы смогут сойтись, если параметры в разных единицах измерения будут? И какой вообще смысл в результате сложения абсолютно разномерных величин?
Один участок выдаёт сырьё, измеряя его массовый расход в тоннах в час. На другом - несколько потребителей измеряют его в килограммах в секунду. Для расчёта баланса прописывается несложная арифметика, каждая цифра перед использованием в формуле автоматически приводится к базовой единице, после расчёта выдаёт в требуемой.
izhidkov писал(а): В этом случае может быть путаница с характеристиками каналов. Кроме этого каждый производитель возьмет разный параметр за "образцовый", т.о. передача параметров будет затруднительная.
Передача параметров настраивается один раз, после чего одна система запрашивает данные в нужных её единицах, вторая - выдаёт в соответствии с требованиями. Если может :). Либо в запрашивающей системе настраивается то, в каких единицах данные придут. Опять же - настройка делается один раз.
Romcheg писал(а): Вот только многих разработчиков смущает именно необходимость преобразования данных перед их отображением, многие, стремясь к повышению скорости обработки, стараются как можно меньше промежуточных шагов делать между выборкой и ее отображением на графике.
В последнее время частенько встречал упоминания об использовании обычных реляционных баз данных для хранения трендов. Представляете, какой там объём пред- и постобработки, а также накладные расходы при выборке?
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


SaNNy
осмотрелся
осмотрелся
Сообщения: 135
Зарегистрирован: 01 фев 2010, 10:37
Имя: Ананьев А.А.
Благодарил (а): 3 раза
Поблагодарили: 1 раз

Дарю разработчикам идею по хранению трендов

Сообщение SaNNy » 14 ноя 2016, 16:54

Хранить данные нужно всегда в одной единице измерения. А в какой единице измерения выводить тренд - решается при отображении пользователем. Это как-бы очевидные вещи.
Если это кому-то не очевидно, то о компетенции такого человека стоит задуматься.

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2789
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 56 раз
Поблагодарили: 41 раз

Дарю разработчикам идею по хранению трендов

Сообщение VADR » 14 ноя 2016, 20:50

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


krapsv
здесь недавно
здесь недавно
Сообщения: 16
Зарегистрирован: 14 апр 2015, 06:57
Имя: Крапивин Сергей Васильевич

Дарю разработчикам идею по хранению трендов

Сообщение krapsv » 24 окт 2017, 14:38

В моей системе есть понятие "расчетных" каналов. Код расчета находится в DLL.
Глобальный подход таков, что много-много формул всевозможных расчетов оформляются в одну общую DLL. Под конкретный проект пишется небольшой файл, указывающий где находится сила тока, где расход и т.п. Тогда можно просто по ходу просмотра менять формулу и смотреть, что есть, и что было. При расчете также легко указать, что до определенного момента была одна формула, а после - другая.

Правда, у меня пока не строятся чисто расчетные графики. В планах такое есть.

И хоть немного другим путем, но имеем ли мы то, что вам нужно?

Ответить