• ОБЯЗАТЕЛЬНО заполнить свой профиль НА РУССКОМ ЯЗЫКЕ КИРИЛЛИЦЕЙ.
  • НЕ НУЖНО писать свой вопрос в первую попавшуюся тему, а вместо этого создать НОВУЮ тему.
  • Дублирование сообщений приравнивается к спаму.
  • Рекламу мы не размещаем ни на каких условиях.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Ответить

Вернуться в «Верхний уровень автоматизации»