Rapid SCADA 6.х

Просмотр 15 сообщений - с 1 по 15 (из 140 всего)
  • Автор
    Сообщения
  • #14318
    baur
    Участник

    Добрый день,
    давайте здесь обсудим перспективы развития Rapid SCADA (условно 6.х) и озвучим функционалы которые мы уже отчаялись увидеть в Rapid SCADA 5.х

    1. Быстрый архив (быстрый обмен данными)
    2. Отказ от жесткой привязки к номеру канала (переход в символьные теги)
    3. Продвинутый экспорт данных (не только текущие данные, а также из архива)
    4. Горизонтальное меню (к сожалению не везде широкие экраны)

    • Эта тема была изменена 4 года, 3 месяца назад от Mikhail.
    #14319
    Romiros
    Участник

    1. Не понятно, можете подробнее
    2. Согласен, вещь жизненно необходимая для дальнейшего развития системы.
    3. Какой экспорт имеете ввиду? Через модуль экспорта и архивы и события экспортируются.
    4. Развернуть дерево горизонтально? Может на малых экранах отказаться от бокового меню, а использовать навигацию по ссылкам? Просто добавить возможность вставки ссылки в таблицы.

    От себя добавлю
    5. Добавить дополнительные типы архивов, существующих двух не хватает.

    #14321
    manjey73
    Участник

    Горизонтальное меню это как в программах
    Файл, Меню, Вид, Помощь и т.д. с выпадающим списком подпунктов.

    Да, было бы неплохо. Для форматов экранов 4:3 было бы актуально, так же для широких мнемосхем.

    5. край как не хватает, двух видов, с постоянной записью и с циклической записью (например отводить на переменную всего 12 записей и переписывать их по принципу стека с меткой времени и т.д.)

    Многим переменным такого способа было бы за глаза. Например месячные срезы из счетчиков на 3 года. 36 переменных всего.

    #14323
    Romiros
    Участник

    На самом деле для каждого канала нужна настройка архивации, это вроде как закладывается в 6.0.
    У нас в системе в настройке архивации я указываю, что хочу архивировать данный тег допустим раз в день, месяц и год. А также указываю из какого архивного среза отправлять данные в БД реального времени (текущий срез в RapidScada). Таким образом у меня тег не пишется в секундные и минутные срезы, но при этом доступен на схемах и формулах.

    #14324
    Mikhail
    Модератор

    Добрый день!

    озвучим функционалы которые мы уже отчаялись увидеть в Rapid SCADA 5.х

    База конфигурации Rapid SCADA 5.x имеет определённые ограничения. Накопившиеся пожелания, которые затрагивают довольно глобальные механизмы работы ПО, нужно делать на новой базе конфигурации, соответственно, в рамках нового поколения системы.

    1. Нужно уточнить, что под этим подразумевается.
    2. Да, это будет закладываться.
    3. Наверное этот вопрос лучше вынести в отдельную тему, если такая тема ещё не заведена здесь на форуме. Потому что экспорт реализуется отдельными модулями, которые не зависят от поколения системы.
    4. Это можно реализовать и сейчас, но скорее всего, как заказную разработку. Непонятно, как при этом выбирать представления из большого дерева? В рамках данного топика лучше сосредоточиться на фундаментальных основах работы Rapid SCADA, т.к. интерфейс в принципе можно сделать любым. В первую очередь будет меняться движок.
    5. Да, это будет закладываться.

    #14325
    Mikhail
    Модератор

    По пункту 1, если я правильно его понял, есть проект новой структуры данных архива, которая должна существенно ускорить выборку трендов по заданным каналам за нужный период времени.

    #14326
    Mikhail
    Модератор

    Что нового в поколении 6, как я это вижу на текущий момент:
    1. Архивы данных:
    — Ускорение работы
    — Возможность вести множество архивов: месячные, суточные, часовые, минутные, архивы с произвольной периодичностью записи
    — Возможность для канала указать, в какие архивы он пишется
    — Убрать ограничение на 65535 каналов
    2. Архивы событий:
    — Добавить поля: приоритет (severity), время квитирования, признак необходимости квитирования
    3. Сервер:
    — Вероятно, работа с типами данных с сохранением существующей простоты. Возможность записывать в архив строки и массивы фиксированной длины.
    — Улучшение возможностей форматирования значений и их цветов
    — Мёртвая зона (гистерезис) в границах каналов
    — Иерархическая структура объектов
    — Коды объектов, КП, каналов
    — Права доступа не на представления, а на объекты

    С точки зрения технологий разработки:
    Постепенный переход с классического .NET на .NET Core для улучшения кроссплатформенности.

    • Этот ответ был изменен 4 года, 3 месяца назад от Mikhail.
    #14327
    Mikhail
    Модератор

    По поводу возможностей экспорта, различных интеграций, нового веб-интерфейса — это скорее всего заказные разработки.

    #14328
    Romiros
    Участник

    Спасибо за подробное описание, такого поста не хватало. А то бы мы тут долго гадали. По п.1 полностью согласен, было бы гораздо удобнее.

    #14330
    Mikhail
    Модератор

    Пока идёт подготовительная работа, всё обсуждаемо.

    #14332
    baur
    Участник

    1. Не понятно, можете подробнее
    1. Нужно уточнить, что под этим подразумевается.

    Имел ввиду ускорение работы по обмену данными при
    — Формировании отчетов
    — Показ событии
    — Показ графика (если брать чуть больше периода система уже зависает, причем вся система не только плагин)
    на текущий момент есть какая то ограничение на это.

    Как то раз мы случайно поставили галочку события на быстро меняющийся канал, через некоторое время система упал, об этом мы писали здесь

    Насчет отчета, при форматировании отчета по часовым данным наблюдается задержка.
    Как я понял, тут требуется глобальное изменения.

    3. Какой экспорт имеете ввиду? Через модуль экспорта и архивы и события экспортируются.

    я имел ввиду существующий архив Rapid SCADA

    #14333
    manjey73
    Участник

    з.ы. не знаю на сколько это реализуемо…

    БД, может писать не саму переменную, а факт ее изменения. То есть если в БД есть такое понятие как метка времени, а мы читаем точку, либо строим график на промежутке, где переменная НЕ менялась. Просто находится время, ближайшая по времени в начале и конечная, где она поменялась и просто вычитывается ее значение и банальным мат расчетом происходит построение графика.

    Если будет такой принцип записи БД, то она довольно таки сократится.

    А не щелкать каждую минуту все переменные, даже если они не менялись.

    #14334
    Romiros
    Участник

    Я вообще не вижу проблемы писать хоть каждую минуту. График ограничен интервалом в 32 дня, если не ошибаюсь. Разве мало? Анализировать минутный график за 4 года какой смысл? Для этого должен быть суточный или часовой.
    Либо делать ленивую погрузку данных. Я так делал для журнала событий. Отображаются первые 100 событий на странице, остальные дни подгружаются в фоне и не тормозят интерфейс. Фильтрация по ключевым фразам тоже в фоне происходит, довольно быстро. А вот если эти тысячи событий вывалить в одну страницу, конечно идут тормоза.

    #14335
    manjey73
    Участник

    Да график тут ни при чем, хотя и он при чем, его построение должно стать быстрее при полностью повторяющихся данных.
    Место занимаемое базами сократится.

    То есть есть сигналы, которые надо писать часто, можно оставить существующий механизм (почти), а то, что меняется редко, просто другой тип БД, как описал, отталкиваться от времени, а не от данных.

    #14336
    manjey73
    Участник

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

Просмотр 15 сообщений - с 1 по 15 (из 140 всего)
  • Вы должны авторизироваться для ответа в этой теме.