Добавить таблицу состояний для дискретных сигналов (продолжение)

ЛЭРС УЧЁТ Предложения по улучшению
1

Продолжение [13735] Добавить таблицу состояний для дискретных сигналов

Таблица появилась, уже великое дело. Но оказалось, что мы одними и теми же словами описывали разное. Я перечитал тему, и мы успешно договорились и закончили обсуждение с уверенностью, что правильно поняли друг друга :))

Когда я писал, что нужно видеть “все дискретные сигналы”, у меня была картина, что нужно видеть все дискретные сигналы по объекту. В моей вселенной нет сценария, где бы потребовалась единая таблица всех дискретных сигналов, т.е. я даже не думал, что такой вариант возможен.

Но вы поняли меня именно так, как реализовали.

Но то, что есть - уже хорошо.

Но предлагаю сделать следующий шаг и довести до удобства с точки зрения эксплуатации.

А именно, добавить на закладке объектов рядом с таблицей данных, таблицу сигнализации (название не обязательно такое).

В таблице сигнализации показывать два вида информации:

  • текущую таблицу состояний для дискретных сигналов, но только для объекта;

*дискретные данных собранные в архивы, с детализацией по типичных интервалам: час, сутаи, месяц и текущие (если в них происходили изменения)

Было бы здорово, если строку «таблица сигнализации» можно было скрывать, чтобы она приводила к изменению интерфейса, привычному для большинства пользователей.

И все таки нужен параметр для группировки по смыслу, об этом я писал ранее в предыдущей теме по поводу таблицы дискретных сигналов, хотя бы для визуальной группировки и фильтрации

Я бы предложил использовать параметр «описание», либо создать еще один параметр описывающий сигнал.

При использовании параметра «описание» его бы стоило переименовать в «тип» или что-то аналогичное. По моему, параметр «описание» вы добавили недавно, раньше было только «наименование сигнала», и переименование н должно затронуть текущие проекты

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

Что-то вроде такого

image
image691×187 11.6 KB

2

Выяснил, что сейчас таблица “Состояние сигнализации” - по сути аналог справочника оборудование, т.е. показывает данные по оборудованию, а не по объектам.

А изначальная задача была “Нужна таблица с состояниями дискретных сигналов по объекту” - цитата из предыдущей темы

Поясню о чем я.

В свойствах оборудования есть таблица “сухие контакты”, где можно для “себя” добавить информацию о контактах оборудования в 2 параметрах “Наименование” и “Описание”.

image
image1893×500 11.3 KB

Наименование, вроде как, - наименование сухого контакта, “Описание” - описание сухого контакта. Параметры - не обязательные для заполнения.

Использую «вроде как», т.к. в окне нет точного названия, а в документации об этом не нашел упоминания

В объекте же есть таблица “Сигнализация”, где описываются сигналы, используемые для сигнализации на этом объекте, и делается привязка к оборудованию и его контактам. И есть параметр “наименование сигнала”, он значимый, не заполнив его, не сможем описать сигнал

image
image1000×524 26.6 KB

А теперь как все это показывается в таблице “состояние сигнализации”.

image
image1913×862 69.1 KB

Явные неточности

  • Есть колонка “номер сигнала”, но такого параметра нет в ЛЭРСе, есть только номер контакта внутри оборудования. И он и показывается в обсуждаемой таблице.

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

  • Параметр Описание в разрезе объекта вообще не сильно нужен пользователям, да и он же не обязателен к заполнению.

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

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

Я бы предложил все таки добавить параметр для группировки сигналов в объекте. Название этого параметра: тип, группа или на ваш выбор. И при задании этого параметра - группировать сигналы в таблице состояния сигнализации

image
image1126×615 37.5 KB

3

Так в первом сообщении предложения мы игнорируем? Или нет? Можно конкретный список что вы предлагаете? Без лишней информации, только список.

4

Так достаточно?

  1. Нужна таблица с состояниями дискретных сигналов по объекту не по оборудованию

  2. Сигналы внутри объекта должны делиться по группам (выше я назвал параметр для деления: тип или назначение), по сути как точке учета. Иными словами нужно деление сигналов по группам, состав и название которых определяет пользователь

  3. В таблице сигнализации показывать два вида информации:

  • текущую таблицу состояний для дискретных сигналов, но только для объекта;

  • дискретные данных собранные в архивы, с детализацией по типичных интервалам: час, сутаи, месяц и текущие (если в них происходили изменения)

  1. Привести в порядок нейминг, что не так с ним я выше написал.

Вопрос не понял. Если нужен ответ, перефразируйте его.

5

Становится понятнее, кроме вот этого

Как их можно объединять в часы и сутки не понимаю. Просто разворачивать суточную метку времени и в ней будут отображаться все срабатывания за эти сутки? Или какой-то другой алгоритм?

6

Далее, хочу уточнить, пробовали ли вы воспользоваться штатными средствами группировки? Общий список сухих контактов можно сгруппировать сначала по колонке “Объект”, а потом по колонке “Описание”. Можно переименовать её в “Тип”, сути это не изменит. Таблица в этом случае будет выглядеть следующим образом.

image
image1085×353 7.86 KB

Вот он ваш список сигналов по объекту, сгруппированный по типу.

7

да именно так, чтобы можно было быстро находить нужные данные

8

Какая версия содержит то, что вы описали? У меня на сервере, где дискретные сигналы обрабатываются, установлена версия 3.57.3, и я не понимаю, как в ней можно группировать данные.

9

В любой версии есть группировка на всех списках. Группировать можно по нескольким колонкам подряд, чтобы получилось то, что я показал.

10

Я попробовал. Как временное решение, до внесения изменений, это облегчит работу с дискретными сигналами. Однако:

• Таблица состояния сигнализации отображает не сигналы, описывающие объект, а все возможные сигналы, которые можно получить с используемого оборудования. Это принципиально разные понятия.
• Это настройка пользовательского интерфейса, то есть её должен выполнять (и, следовательно, хорошо понимать) каждый пользователь, а не просто просматривать состояние сигналов и историю их изменения. К тому же, эта настройка не сохраняется.

11

Для этого есть колонка “Связан с НС”, можно по ней отфильтровать и получить состояние именно настроенных в объекте сигналов.

Сделать сохранение и настройки по умолчанию это как раз не проблема.

12

Эта фраза теперь стала еще более точно описывать ситуацию - “В качестве временного решения, до внесения изменений, это облегчит работу с дискретными сигналами.”

Однако, только если настройки отображения в таблице сигнализации сохранятся.

Т.е. как временное решение – приемлемо.

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

13

Тут вообще не понял почему подходы разные? И что значит “данные учёта” и “телеметрия”?

Если вы про настройки объекта, то там задаётся именно привязка дискретных входов к нештатным ситуациям. В обсуждаемом списке отображаются все возможные дискретные входы, чтобы была видна по ним полная раскладка. Как эти окна вообще могут быть одинаковыми?

Мне кажется, что такая группировка полностью закрыла ваши вопросы, кроме отображения исторических архивов. Что я, кстати, считаю отдельной задачей, так как эти данные сейчас довольно тяжело собрать и понять как их показывать. Почему вы пишете про временное решение? Только из-за отсутствия возможности сохранить отображение? Ну давайте добавим кнопку “Группировать по объектам”, которая настроит заданные режимы и сохранит их.

14

“Разные” - это о том, как вы представляете дискретные данные и данные, описывающие потребление ресурсов

Данные учета (они же данные с приборов учета, в РЭ на ЛЭРС Учет называются просто “данные”) вы показываете по точкам учета и по объектам. Нельзя посмотреть данные по конкретному прибору, хотя информация о нем может быть частью параметров, описывающих данные. Прибор используется только при настройке системы как источник данных.

Я неправильно использовал слово “телеметрия”, это был сленг клиента. Я имел в виду дискретные данные.

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

То есть, коротко:

• Пользователи привыкли видеть данные с приборов по объектам и точкам учета.
• При переходе к дискретным данным вы предлагаете фильтровать огромную таблицу всех дискретных сигналов от всех приборов, даже не привязанных к объектам.
• При этом данные привязаны не к объектам, а к приборам – источникам дискретных данных.
• Такая таблица сложна для использования, поэтому вы предлагаете сохранять настройки фильтрации.
• Пользователи хорошо ориентируются в объектах и назначении сигналов, но часто не знают и не запоминают названия контроллеров, собирающих дискретные сигналы. Т.е. дискретные данные программа группирует по непонятным для большинства пользователей параметрам. Это как если если бы ЛЭРС выдавал данные по СПТ, ТЭКОНам, ВКТ, а не по теплоснабжению, подпитке и ГВС.

С моей точки зрения, дискретные сигналы нужно показывать так же, как данные с приборов учета, в той же таблице данных по объектам (или в отдельной, это на ваше усмотрение). Нужно показывать дискретные данные в табличном виде, чтобы пользователи могли видеть текущее состояние и историю изменения сигналов, аналогично отображению текущих и архивных данных в “таблице данных”.

Об этом я и писал в начале обсуждения.

Сейчас я понятно описал?

15

Вообще не закрыла. Только как временное решение. Выше я описал причины.

Вы предлагаете это выделить в отдельную тему?

16

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