- В этой теме 21 ответ, 3 участника, последнее обновление 4 года, 6 месяцев назад сделано
.
-
Сообщения
-
Михаил, что произойдет, если в SetCurData добавить параметры по умолчанию ?
Интересует SetCurData(Индекс_Тега, Значение, Статус, Тип_Переменной = double)
Сломается ли все, что сделано ранее ?
На счет БД, если добавить столбец в базу, просто пустой для типа переменной на следующий этап. Сломается ли все, что работает с базой сейчас ?
На будущее, оставить 8 байт базы для данных, но в зависимости от типа переменной писать либо полные данные — собственно double, как сейчас. Или писать, начиная с младших байт переменные типа Byte( его же использовать для битовой переменной), word, int16, ushort в два младших байта, int32, UInt32 в 4 младших байта и так далее.
А вот вместо текстовых переменных писать в эти 8 байт идентификатор БД, где эти переменные будут находиться и откуда их выводить.На счет самой БД — зачем писать каждый чих, если переменная долго не меняется ?
Не лучше ли писать по изменению Значения или Статуса с метками времени ?в начале суток 00:00:00 и в конце 23:59:59 сохранять независимо от изменений.
Зная время первой записи и следующей можно построить график.База немного избавится от жирка…
з.ы. чисто мысли вслух…з.ы. продолжаем разговор.
Штатную базу оставить для переменных типа double, DateTime, UInt64, Int64 — в общем для всего 8-ми байтного.
Добавить Базу для 2-х байтовых переменных, ее же использовать для 1-но байтных и Bool переменных
Добавить Базу для 4-х байтных переменных — Float, Int32, UInt32
Добавить базу для Текстовых переменных.
Если сработает с SetCurData(Индекс_Тега, Значение, Статус, Тип_Переменной = double)
То первоначально будет писаться в базу так, как сейчас.
Если в последующем меняем переменную на другой тип. В текущей базе вместо 8 байт данных Значения указывать идентификатор Базы.
Мало того, сделать возможность создания Баз самостоятельно. Например сделали две базы для 4-х байтных переменных. Одну для Int32 например, другую для Float и делим по типу. Если данных не очень много, сделали базу просто для любых 4-х байтных и валим все в кучу, и UInt32 и Float.
В общем по выбору.Подобные изменения в любом случае могут появиться не раньше следующего поколения системы. Таким образом, вопрос совместимости не должен смущать — будут разработаны утилиты для перехода.
Я тоже думал о том, чтобы задавать типы значений для каждого канала. Но пока придерживаюсь мнения о том, что лучше оставить double для всех каналов. С единым типом проще настраивать проект, быстрее скорость работы, т.к. не надо каждый канал преобразовывать по своему.
Однако, пока работа над реализацией следующего поколения даже не начата, вопрос остаётся открытым для обсуждения.
Утилиты не смогут изменить код драйверов однако.
Какие преобразования ? указано тип double — работаем с double
Указан тип Int32 — работаем с Int32Это вот сейчас как раз происходят преобразования, 8 байт в ASCII надо прокрутить туда-сюда, изменить бит в числе надо из double в UInt64 а потом обратно и так далее и так далее.
О каких преобразованиях будет речь, если с самого начала драйвер Серверу скажет что переменная Int32 и она попадет в БД с 4-х байтным полем а в основную базу в эти 8 байт запишется идентификатор базы ?
То есть есть поле данных 8 байт и поле типа переменной. Данные не double — Сервер узнает где она и читает ее так, какова она есть.Так никто не говорит, что будет сложнее, если по умолчанию все останется в double, но стоит указать тип Int32 и само значение в новой базе, а в поле данных основной базы указание где и что лежит…
Так метка времени это просто еще одно поле + к полю типа переменной. Да, еще 8 байт, но если переменные не меняются, это все равно даст экономию..
з.ы. Если сделать настройку — писать переменную всегда, то механизм меток времени остается старый. Если сделать настройку «По изменению» то в новых базах все это и предусмотреть… Если нужно это проделать для переменных double, то ставим переменной «Писать по изменению» и в плюс к БД для inf, float, txt еще база с double с метками времени а в основной ссылка на БД этой переменной как и для других типов.Тут мне кажется больше проблема будет научить остальные приложения работать с этим, Администратор, Графики Про, Модуль автоуправления и так далее.
Единственное, нужна возможность делать базы как по типам переменных, так и по емкости переменных.
БД Float
БД UInt32
БД Int32или одна БД для 4-х байтных..
Но в идеале вообще создавать их по собственному усмотрению, кому как удобно…
Тут мне кажется больше проблема будет научить остальные приложения работать с этим, Администратор, Графики Про, Модуль автоуправления и так далее.
Да, подобные изменения затронут все уровни ПО и большинство модулей.
Ну так можно же плавно начать. Научить драйвер передавать значения, отличные от double. Сервер научить принимать, начать с текстовых и передачи в текстовую базу и одновременно в основную в виде 8 байт ASCII как это можно сделать сейчас драйвером.
Потом научить Web отображать текст из этой базы текстом любой длины.
Потом так же с остальными типами переменных сделать.Отработать механизмы с метками времени ну и что еще вдруг всплывет от пользователей.
Например в Коммуникаторе потом сделать настройку, какие переменные в какие базы писать. Так можно делать однотипные базы но под разные объекты и даже опросы.
Есть похожая реализация, но там в качестве базы используется постгрес. По умолчанию не архивируется ничего, а настраивается для каждой переменной отдельно(по таймеру, по изменению, по обновлению и ещё как-то). Архивных таблиц изначально тоже нет, их создаёшь сам. А также используется строгая типоризация переменных.
Так вот, разработка проекта сложнее и медленнее. В скриптах постоянно нужно следить за типом переменных, чтобы они совпадали. Если пользователь неопытный, то будет очень сложно по сравнению с RapidScada. Один из ее больших плюсов — это простота.
И второй момент — это отсутствие унификации в архивах. Каждый лепит архивы, как он хочет. Если с текущими данными проблем передачи в другие системы нет(тот же OPC), то с архивами будут проблемы.
Мне больше нравится идея Михаила, с различными типами архивов в 6 модели БД RapidScada.ну вот с различными типами архивов я столкнулся на ПЛК Allen Bradley, там файлы разделены на типы integer (Int16), Таймеры (тоже Int16), Счетчики (тоже Int16), Float, Бинарные (но тоже Int16 в виде маски). очень удобно разделение.
Но для Scada мало разделить. Так как Scada ведет еще архив, а от переменных, которые меняются редко архив постепенно растет в размерах, что не есть хорошо к дисковому пространству.Одно из предложений ранее было сделать БД с фиксированным количеством записей на переменную и запись ее по кругу, тоже полезно для некоторых данных. Да и вообще для любой БД кроме поля «Метка времени» нужно поле «действия оператора» — кто сменил переменную, подал команду и т.д.
Вообще предложение связано с тем, что версии 6 еще нет, но на версии 5 можно откатать механизм на Текстовых переменных хотя бы.
Затронет Коммуникатор, Сервер, который одновременно будет писать туда, куда он пишет сейчас и в текстовую БД и собственно Web, чтобы отобразить текст в полном виде вместо 8 байт ASCII.. Все настройки, создание БД, имя это БД можно сделать в ручную и через конфиги.з.ы. я тоже за простоту, хоть и не скажу что RapidScada совсем уж простая.
Вот и надо сейчас выработать концепции, протестировать их и т.д. еще на 5-й версии.
Что должно быть в Администраторе добавлено, как создавать эти базы, если захочется разделить объекты по нескольким БД, где вводить имя БД и т.п. и т.д.Если добавить в Администраторе в основную БД, где мы создаем все каналы столбец — БД
и ее тип + поле имени БД. Эти базы то сильно не вырастут.
Важно продумать что будет в самой новой БД — какие поля…Еще добавлю.
1. Есть сигналы с постоянной записью и 1 мин или 30 сек достаточно за глаза.
2. есть сигналы, которые достаточно сохранять только по изменению
3. А есть сигналы, которые необходимо сохранять с периодом несколько десятков мс. Вот тут еще интереснее. Необходимо чтобы с такой БД Коммуникатор работал напрямую, а Сервер только вычитывал как остальные сигналы для отображения в WEB, но при необходимости посмотреть графики, экспортировать данные WEB должен уметь работать с такой БД тоже напрямую. Ну либо получать данные через Сервер.Изменение работы архивов может появиться не раньше следующего поколения ПО, т.к. изменения слишком значительные, чтобы их можно было сделать в 5 версии.
А есть сигналы, которые необходимо сохранять с периодом несколько десятков мс.
В течение какого периода времени нужно производить замеры с такой частотой? Постоянно или в ограниченный промежуток? Какие примеры таких сигналов?
Ну в основном быстро надо сохранять данные например при диагностике каких либо систем, либо мониторинга качества сети и т.д. как правило как временное решение, но не всегда. Примером вот был форумчанин, у которого 30 счетчиков мониторились, каждый на своей линии связи. Значит это кому-то нужно :).
Для таких каналов на каждый канал нужна своя БД, Сервер же выбирает для отображения на WEB текущее с периодом как у остальных каналов, так же сохраняет часовые данные. Но при выводе графиков или экспорте данных в exel все должно браться из БД самого канала. В идеале чтобы запись в эту БД проводил сам Коммуникатор, а на Сервер передавал как другие каналы. А вот специальным модуль сервера уже тянул все данные на Сервер, если Коммуникатор стоит на удаленной машине.
з.ы. не знаю, сколько сокетов можно открыть на одном порту IP ?
Просто таких каналов может быть и не один…Еще вариант, когда в канале надо отловить импульс, что не всегда возможно при обычном периоде опроса в 1 секунду.
- Вы должны авторизироваться для ответа в этой теме.