- В этой теме 66 ответов, 4 участника, последнее обновление 4 года, 10 месяцев назад сделано
.
-
Сообщения
-
У нас несколько объектов где есть RapidSCADA, мы купили шлюз но не можем использовать по полному. так как каналы пресекается а сам шлюз не дает фильтровать. Можно ли обеспечить уникальность номером канала и объекта. В схеме глобально задаем номер объекта, который наследуется всеми объектами а для конкретных объектов можно было его менять (на практике это маловероятно). Наверно на уровне структуры всего проекта это задача не из лёгких, но есть такая проблема.
По теме шлюза ранее тоже писал, что требуется его доработка.
Необходима вообще настройка каналов, КАКИЕ отправлять, и В КАКИЕ каналы отправлять. Так как подчиненные Scada могут быть однотипные с одинаковыми номерами сигналов.Но скорее всего это будет на коммерческой основе 🙂
Единая среда разработки проектов Rapid SCADA как я понял это покрывает проблему …
По данному вопросу есть 2 пути. Причём в идеале лучше реализовать оба.
1. Настраивать соответствие номеров каналов как группами, так и по одиночке в параметрах модуля Шлюз.
2. С помощью среды разработки, которая сейчас разрабатывается, конфигурировать главный и дочерние объекты в рамках единого проекта, чтобы номера каналов в принципе совпадали.Вопрос к baur: получали ли Вы мой емаил от 5 ноября?
В роде к вашей проблеме это не относится.
2. С помощью среды разработки, которая сейчас разрабатывается, конфигурировать главный и дочерние объекты в рамках единого проекта, чтобы номера каналов в принципе совпадали.
каналы формируется через главный, тогда исключается дублирование.
Идея мне нравится, а может я идею не до конца понимаю. В моем представлении — это когда мы за всех создаем все справочники, каналы (сигналы) и отправляем в филиалы. В таком случае следует учитывать следующие моменты:
1. Это завяжет руки разработчиков, если в каждом филиале свои разработчики
2. Исключает интеграцию систем созданными разными командами (в больших компаниях это не редкость). Мы чуть ли не заставляем работать на центральном сервере, так как все платные модули установлены именно там и руководство заходить через центральный. А так каждый хочет свой уголок и крутить-вертеть как им угодно и это справедливо.А так центральный сервер это всегда актуально, даже сейчас руководству раздражает, если мы на каждый сервер даем отдельную ссылку.
В идеале хочу интегрировать любую систему без риска, независимо с кем создан и какая там версия rapidscada с минимальным вмешательством в личное пространство других команд.
Вариант, когда в шлюзе прописаны соответствие каналов и групп откуда куда желателен при однотипных подключенных объектах. Где Scada накатываешь вместе с системой из образа диска например. Потом просто прописываешь новое имя (объект 1, объект 2 и т.д.) и указываешь В Какие каналы писать не меняя нумерацию самих каналов, логики и т.д.
Делать это в единой среде разработки будет не просто…Вообще подходы должны быть разными. Но то, что шлюз должен позволять исключать часть каналов это точно. Смысл гонять куда-то наверх кучу промежуточных дорассчетных каналов например ?
baur, хорошие замечания, связанные с психологией людей и реальной организацией работы.
По моему мнению, нужно реализовывать оба подхода. Приоритет зависит от конкретного заказчика доработок ))Сервер RS
- Все экземпляры (инстанс) сервера RS работает автономно
- Формальном между ними нет никаких связи. Нет главного и подчиненного, не надо думать об уникальности сигналов даже через маппинг. Просто указал куда и что передать и всё, никаких сложностей.
- при установке указать или автоматический сгенерировать ID экземпляра (уникальный в рамках одной предприятии).
- Все схемы (отчеты, таблицы) унаследует ID экземпляра, если явно указать ID будем считать, что сигнал из другого экземпляра.
Шлюз:
- система гарантированной доставки данных (кстати это требуется и для между коммуникатором с сервером)
- любой сигнал (даже расчетные) передаётся в любой экземпляр.
- выборочная передача данных
- передача данных по триггеру (all, timer, change, condition и т.д.), возможность комбинировать (or, and) различные триггеры. Например, передать сигнал по изменениям или по таймеру, то есть если в течении пять минут данные не меняется, то в любом случае передаётся по таймеру.
Это как вариант, приветствуется и остальные (как главный и подчинённый), но мы бы хотели иметь возможность конфигурировать по предложенному варианту или что-то подобное.
есть планы относительно системы гарантированной доставки данных между коммуникатор и сервер ? Это важно при опросе счетчиков АСКУЭ (коммерческий учет)
Если со счётчиков выкачиваются архивы, то доставка гарантированная. Это означает, что архив выкачивается до тех пор, пока не будет полностью получен и передан Серверу.
Для текущих данных, насколько я понимаю, гарантированная доставка бессмысленна — если данные не переданы, они уже не актуальны.
Чтобы обеспечить гарантированную доставку данных, эти данные должны храниться в том числе в энергонезависимой памяти прибора.
Для коммерческого учёта также возникает вопрос сертификации системы учёта.
Mikhail не обязательно. Видел как энергетик снимал данные со счетчиков Меркурий родным ПО «Конфигуратор», подключаясь к счетчикам по отдельности. само ПО не является сертифицированным для системы учета. Сам счетчик является и его архив, а чем он будет прочитан как-то видимо пофигу.
Сам счетчик является и его архив
Да, этого бывает достаточно. Надо уточнить как в данном конкретном случае.
baur, есть ли у Вас более детальные требования к системе? Что понимается под гарантированностью доставки. Даже не только между Коммуникатором и Сервером, а между приборами и SCADA в целом.
Для коммерческого учёта также возникает вопрос сертификации системы учёта
для технического учета тоже важно, даже важнее чем коммерческий учет. Потому что данные нужны за каждый час чтобы сопоставить другими данными как переработка руды и т.д.
Если со счётчиков выкачиваются архивы, то доставка гарантированная
тут существующие драйверы по счетчикам (меркурий, энергомер …) поддерживает эту функцию, сам еще не пробовал. Скоро начинается это тема, поэтому готовимся
- Вы должны авторизироваться для ответа в этой теме.