Поддерживаю. Сильно бесит когда в магазине на кассе заходишь в приложение чтобы по быстрому проверить баланс, а тут эта медленно загружающаяся реклама, которую надо ещё постараться скрыть чтобы ни куда не перейти. Вообще, если говорить про само приложение Альфа Банка, то в нём больше всего мусора отвлекающего от реальных потребностей, как будто попал на сайт в 2000 году без блокировщика рекламы. В приложениях банков Дом.рф, Райфайзен, УБРиР такого нет.
У меня используются бруски шириной 40 мм и различной глубиной 20, 40, 50 и 60 мм. Советую увеличить глубину брусков до хотябы 40, 50, 60 и 80 мм. Бруски расположены случайным образом, чтобы не было никакой периодической последовательности. За брусками каменная вата Роквул Акустик баттс толщиной 10 см (завёрнутая в укрывной материал для грядок спанбонд), за акустикой в углах толшина 15 см.
Вот файл измерений REW (микрофон UMIK-1) этой комнаты https://disk.yandex.ru/d/dpuG59doJT9tqQ NEW - новые панели, OLD - старые, где использовались рейки глубиной 20 мм и было больше открытой ткани.
Необработанный натяжной потолок всё портит - но планирую всё сделать уже после переезда в новую квартиру.
Мне кажется, любая студия должна начинаться с акустической обработки помещения. У меня не студия, а просто комната для прослушивания музыки, но в ней такая самодельная обработка (потолок тоже надо обрабатывать аналогично):
А мы практически в режиме реального времени из SCADA всеми реле управляем, а эти реле управляют всем силовым оборудованием, например, вентиляторами мощностью 8 кВт.
Все алгоритмы логики в SCADA выполняются каждую секунду, если например, будет зафиксирован выход температуры за аварийный предел в течении 5 минут подряд, то в течении следующей секунды на плату реле из SCADA отправится команда на выключение вентиляторов и на закрытие уличных клапанов.
Сейчас посмотрел - у хранилища на 10 секций 250 адресов (каналов) для получения и отправки данных, причём с интервалом опроса всех каждые 250 мсек (4 раза в секунду). Я кстати незнаю зачем такой частый опрос мы у заказчика сделали, похоже тестировали и зыбыли на стандартный 1 раз в секунду поменять)))
Но это не предел - я тестировал на эмуляторе 5000 адресов, я думаю он даже на Raspberry Pi 4 без тормозов работать будет, если не хватит производительности, можно запустить нашу систему на полноценном серверном компьютере (поддерживаются операционные системы Linux и Windows). Я вам по секрету скажу, это ядро по скорости возможно превзойдёт многие DCS сервера в очень больших SCADA системах.
У нас в SCADA реализованы все алгоритмы управления оборудованием и сбора данных с датчиков. Больше на объекте нет никаких контроллеров ПЛК. Этот микрокомпьютер на базе Raspberry Pi 4 с Linux и запущенными сервисами (приложениями) ядра SCADA и Web-UI выступает в роли единственного контроллера и находится прямо на объекте, обычно прямо в шкафу с электроустановочными изделиями (контакторы, реле и т.д.), куда подключено всё силовое электрооборудование. На дверце этого шкафа ещё расположен сенсорный экран - подключен кабелем HDMI напрямую к микрокомпьютеру.
Можете считать это одним контроллером (ПЛК), просто у которого все входы вынесены на отдельные платы и мозги которого общаются с этими платами через Ethernet (там кабель - витая пара длиной 50 сантиметров, т.е. это Ethernet внутри одного электрошкафа, все платы управления реле в нём, вынесены только датчики).
Ядро напрямую общается с устройствами к которым подключены реле и датчики. У плат управления реле есть конфигурируемая настройка, что делать при пропаже связи с ядром, т.е. если ядро их не опрашивает, то что нужно им делать: ничего или всё отключить.
Я сейчас специально перечитал ещё раз определение SCADA и не нашёл противоречий, почему наш софт не может называться SCADA если не общается ещё с какими-то контроллерами.
Честно говоря, никогда не слышал о BACnet. Только что загуглил - у нас на старых устройствах с CAN шиной был похожий протокол - там можно было запросить и построить дерево всех устройств на шине, с описанием каждого устройства (модель, список модулей и датчиков к нему подключенных, с описанием каналов и их единиц измерения).
Сложные устройства и протоколы у нас не прижились.
Но если какому-нибудь заказчику нужен будет BACnet для интеграции - сделаем.
Согласен, очень много чего не доделано и есть много что можно улучшить, особенно в части интерфейса.
Основной упор при разработке системы был сделан на ядро системы и оптимальный алгоритм автоуправления климатом (3 раза практически заново переписывался). Но повторю, все доработки только за счёт новых заказов, а с этим в последнее время проблемы. Также вся разработка ведётся одним человеком в свободное от основной работы время.
Теперь понял про что вы. У меня просто в статье есть главы "1. Верхний уровень – домашняя страница" и "2. Средний уровень – секция".
Тогда верхний и средний уровни из вашего перечня реализованы в сервисе ядра SCADA и сервисе UI (HMI).
Ядро напрямую общается с устройствами к которым подключены реле и датчики. У плат управления реле есть конфигурируемая настройка, что делать при пропаже связи с ядром, т.е. если ядро их не опрашивает, то что нужно им делать: ничего или всё отключить.
Не совсем понял, про какой верхний и средний уровень идёт речь. В статье описана иерархия уровней (экранов, окон) интерфейса пользователя (UI).
Обычно оба сервиса (ядро SCADA и UI) запущены на одном компьютере и общаются между собой по TCP через 127.0.0.1. Ядро опрашивает все устройства обычно 1 раз в секунду и хранит в памяти все текущие значения тегов, а также пишет изменившиеся значения в архив на диск. Если соединение между сервисами прервётся, то сервис UI периодически будет пытаться переподключиться к ядру.
Технически, каждая плитка выступает в роли ссылки и может ссылаться на любой URL где запущен сервис UI, в том числе эти сервисы UI могут быть подключены к своему ядру SCADA. Т.е. за плитками верхней (домашней) страницы может скрываться множество отдельных компьютеров со своими сервисами ядра и UI на разных объектах заказчиков, но обычно все плитки, по которым можно прокликать - это всё таки один объект заказчика (например, овощехранилище, состоящее из нескольких расположенных рядом складов-секций).
Я думаю что мы говорим о разных порядках стоимости внедрения системы. Я о примерно 1-5 млн. руб. за всю автоматику, включая наши устройства, датчики, шкаф с электроустановочными компонентами (автоматы, контакторы, реле), но без учёта силового оборудования (вентиляторы, клапана и т.д.).
Как дела обстоят на практике в интерфейсах с картинками в овощехранилищах, я описал в комментарии выше.
Для технологических линий предприятий да, иногда очень хорошо всё отрисовывают, с множеством экранов для каждого технологического процесса и т.д., но там и бюджет в 10, а скорее в 100 и более раз выше.
Но всё равно, мне ближе подход «взгляду не за что зацепиться» при нормальной работе, описанный в книге «The High Performance HMI Handbook».
Журнал событий и аварий есть, с поддержкой квитирования, просто в данном случае он в интерфейс не выведен, т.к. конкретному заказчику не нужен (настроено SMS оповещение на важные события).
Мы ведём разработку функций только если они нужны какому-нибудь заказчику. К сожалению, нет ресурсов разрабатывать универсальную систему. Само ядро SCADA с тегами универсальное, позволяет описать всё что угодно. Но на его базе нужно создавать оборудование с тегами, логические функции для их работы, компоненты UI. Всё это создаётся когда нехватает уже реализованных компонентов.
Карты (геоподложки) нет - пока никому из заказчиков не было нужно.
Конкретно ваш случай с лифтами - не вижу проблем в реализации на основе плиток. На домашней странице делаем плитки по районам города, в них выводим какую-то сводную информацию, например мы можем сделать расчётные теги, в которых бы выводилось сколько всего лифтов на районе, сколько с проблемами, сколько в аварии, сколько ремонтных бригад выехало на инциденты и т.д. Также рамка плитки может окрашиваться в красный цвет, если внутри иерархии есть аварийный статус тега, а на саму плитку этот тег не выведен.
Я вообще не уверен что в вашем случае с лифтами основой интерфейса должна быть карта города. И плитки наверное ненужны. Диспетчеру достаточно вывести журнал событий с квитированием, в карточке события будет адрес дома и ссылка на карту (Яндекс.Карты, 2 Гис и т.д.), в ней сразу интерфейс назначения ремонтной бригады сделать и т.д. Понятно что придётся написать отдельный модуль такого журнала для максимального удобства, но всё это возможно сделать на базе нашей системы.
Действительно, тема хорошего UI холиварна, как и любого дизайна.
Если для этого нужен силуэт домика(=хранилище), это лучше чем плитки. Картинка вентилятора привлекает внимание легче, чем поиск группы параметров " слева, где-то посередине окно".
Возможно, при условии что кто-то будет каждый раз перерисовывать этот силуэт и картинки под конкретный объект.
На практике, обычно если есть картинки в интерфейсе, то имеются жёсткие ограничения на состав и количество оборудования, например, поддерживается до 6 вентиляторов канала и до 8 датчиков температуры продукта.
Более того, часто в этом случае в интерфейсе показывается даже физически отсутствующее оборудование т.к. оно захардкожено в картинках, т.е. если на объекте вместо 6 вентиляторов только 2, то отображаются 6.
У нас нет никаких ограничений. Возможно где-то приходится чем-то жертвовать, но мы всегда очень стараемся скомпоновать удобный интерфейс под конкретный объект.
Также на мобильных устройствах этими картинками неудобно пользоваться.
Анимация и мигание может как раз служить индикацией нормального состояния системы (watchdog!).
Моя концепция и подход, описанный в книге «The High Performance HMI Handbook» (Hollifield, Oliver, Nimmo, Habibi), прямо противоречит этому)))
Примеры:
Пропала связь со всем оборудованием (в секции 2 уважнитель 1 выведен из работы, поэтому нет рамки):
Пропала связь сервиса UI с сервисом ядра SCADA
Мне кажется это намного нагляднее, чем следить за какой-то анимацией, означающей нормальную работу системы.
И оператор редко пялится в экран круглосуточно.
Да, поэтому обычно настраиваем SMS оповещение о самых важных событиях.
У нас устройства друг за другом цепочкой соединяются, т.е. у каждого устройства есть входной и выходной разъёмы для шины RS-485.
Вот фото цепочки устройств на шине RS-485:
С Ethernet так не получится - либо прямо на платах придётся мини коммутатор (switch) распаивать, либо ставить коммутатор отдельно и от него звездой подключать все устройства, а это огромный перерасход витой пары.
Ещё у Ethernet по витой паре ограничение на длину кабеля 100 метров, для овощехранилищ вообще не подходит - они имеют большую площадь.
Если нужен Ethernet, то такую архитектуру можно собрать на имеющихся у нас устройствах - просто перед каждым устройством (плата датчика, реле и т.д.) поставить шлюз Ethernet-RS485, т.е. за этим шлюзом будет только одно устройство.
С чего вы это взяли? Потому что я привёл код для формирования оборудования объекта? Это отдельный проект, который просто подготавливает список всех необходимых тегов для объекта и сохраняет в файл модели JSON.
Аналогично описываются точки доступа для сбора данных (шлюзы), UI и вся остальная модель объекта.
Можно самому конечно тысячи тегов в JSON создавать копипастом, но мне как-то удобнее объектный подход с билдерами оборудования и всех нужных для него тегов.
Да, функции обработки для разного оборудования, пока не компилируются на лету при запуске, как планировалось, но это только из-за Native AOT компиляции в машинный код. Если компилировать проект стандартно в IL код, никаких проблем с компиляцией функций на C# на лету не будет, я так уже делал.
Вот, у меня даже TODO соответствующий в коде есть. Тут связывается уникальное название функции, которое задаётся у тега, с делегатом (ссылкой на функцию).
У нас нет какой-то принципиальной позиции по Vendor Lock.
Если будет требование от заказчика, выпустим устройства с протоколом Modbus RTU. Но тогда придётся подготовить документацию по регистрам, иначе в этом не будет особого смысла.
Мы можем интегрировать в систему устройства сторонних производителей с любым протоколом или разработать собственные специальные устройства под нужды заказчика. Мы всё это можем сделать, но нам должен быть интересен этот процесс в финансовом плане.
Также и с нашими устройствами или SCADA. В принципе можно опубликовать все исходники, но без документации и сообщества для поддержки разработчиков это не имеет практического смысла.
И сейчас такое время, очень много кто хочет поучаствовать в импортозамещении, ничего фактически не делая. Не хотелось бы чтобы наши разработки выдали за свои и оформили патент и прочее, что в итоге мы сами своими разработками пользоваться не сможем.
В итоге перед тем как что-то выложить в открытый доступ, нужно понимать зачем и кому это нужно, юридически всё оформить, подготовить документацию и прочее. Но если появится партнёр, который готов это профинансировать, чтобы создать какую-то открытую экосистему, то мы не будем против.
Синхронизации часов между устройствами нет - это нам пока не нужно. На устройствах нет часов текущего времени. В протоколе предусмотрена передача времени значения от устройств, но в этом ещё ни разу не было необходимости.
Ядро одно, оно выполняет все команды от пользователей и обработку полученных данных. При получении каких-либо значений, ядро назначает свою метку времени (текущее время операционной системы).
Допустим, пользователь в браузере нажимает кнопку "Вкл", от клиента через сервис UI ядру отправляется команда установить значенияе тега с таким-то ID в "1", ядро при получении команды, проверяет можно ли её выполнить (проверка на соответствие типов данных, ограничений на диапазон, вызывает функцию проверки значений тега если она задана) и задаёт тегу требуемого состояния оборудования значение "1", при этом назначает значению текущее время операционной системы.
Задачу синхронизации данных в интерфейсе между клиентами выполняет фреймворк ASP.NET Core Blazor Server - при подключении клиента (браузера) к серверу (сервис UI) устанавливается подключение WebSocket (SignalR), по нему в бинарном виде передаются все данные. Он сам отслеживает пропажу связи с сервером, пытается переподключиться и т.д. Сервис UI отделён от сервиса ядра, взаимодействие между сервисами через TcpListener/TcpClient.
На самом деле мне не очень нравится использовать Blazor, есть идея переписать на свою связку клиента на JavaScript и сервиса UI, где бы клиент сам периодически опрашивал сервер, есть ли какие-то изменения в данных на отображаемый в текущий момент странице. Можно и тот-же WebSocket использовать для уведомлений от сервера. Т.к. HTML шаблонизатор страниц на беке, то легко реализовать алгоритм, когда бек ведёт список значений отправленных клиенту для отображения и отслеживает изменения, т.е. собирает список изменённых значений, что бы при первом запросе от клиента отправить их ему. Т.к. сервис UI всегда знает какие данные отображаются на клиенте, клиенту не нужно даже перечислять в запросе требуемый список значений (тегов). Но сейчас всё отлично работает на Blazor, поэтому это просто интересная идея на подумать.
Поддерживаю. Сильно бесит когда в магазине на кассе заходишь в приложение чтобы по быстрому проверить баланс, а тут эта медленно загружающаяся реклама, которую надо ещё постараться скрыть чтобы ни куда не перейти.
Вообще, если говорить про само приложение Альфа Банка, то в нём больше всего мусора отвлекающего от реальных потребностей, как будто попал на сайт в 2000 году без блокировщика рекламы. В приложениях банков Дом.рф, Райфайзен, УБРиР такого нет.
Это гибридные панели по мотивам MyRoom (Bogic Petrovic) https://www.dastereo.ru/uploads/short-url/pB7QKJeY71xZTVyUBILvOm75p8G.pdf .
У меня используются бруски шириной 40 мм и различной глубиной 20, 40, 50 и 60 мм. Советую увеличить глубину брусков до хотябы 40, 50, 60 и 80 мм. Бруски расположены случайным образом, чтобы не было никакой периодической последовательности. За брусками каменная вата Роквул Акустик баттс толщиной 10 см (завёрнутая в укрывной материал для грядок спанбонд), за акустикой в углах толшина 15 см.
Вот файл измерений REW (микрофон UMIK-1) этой комнаты https://disk.yandex.ru/d/dpuG59doJT9tqQ NEW - новые панели, OLD - старые, где использовались рейки глубиной 20 мм и было больше открытой ткани.
Необработанный натяжной потолок всё портит - но планирую всё сделать уже после переезда в новую квартиру.
Мне кажется, любая студия должна начинаться с акустической обработки помещения. У меня не студия, а просто комната для прослушивания музыки, но в ней такая самодельная обработка (потолок тоже надо обрабатывать аналогично):
Старые панели https://www.dastereo.ru/t/prodano-prodam-akusticheskie-paneli/143438
Новые https://www.dastereo.ru/t/rasseivayushhie-i-pogloshhayushhie-konstrukczii-dlya-kdp/7212/5230 (процесс сборки https://www.dastereo.ru/t/rasseivayushhie-i-pogloshhayushhie-konstrukczii-dlya-kdp/7212/5145)
Тоже хотели теплицы автоматизировать и собирали требования по функционалу от потенциальных заказчиков.
Наши заказчики хотели так управлять заданиями:
Активация задания - по расписанию (день недели, время) или по какому-то условию (температура выше значения и т.д.).
Прекращение выполнения задания - по продолжительности или по какому-то условию (кол-во вылитых литров, температура и т.д.).
В итоге не стали разрабатывать своё решение из-за совсем скромных бюджетов у заказчиков)))
А мы практически в режиме реального времени из SCADA всеми реле управляем, а эти реле управляют всем силовым оборудованием, например, вентиляторами мощностью 8 кВт.
Все алгоритмы логики в SCADA выполняются каждую секунду, если например, будет зафиксирован выход температуры за аварийный предел в течении 5 минут подряд, то в течении следующей секунды на плату реле из SCADA отправится команда на выключение вентиляторов и на закрытие уличных клапанов.
Можно сказать, что наша SCADA = программа в ПЛК.
Сейчас посмотрел - у хранилища на 10 секций 250 адресов (каналов) для получения и отправки данных, причём с интервалом опроса всех каждые 250 мсек (4 раза в секунду). Я кстати незнаю зачем такой частый опрос мы у заказчика сделали, похоже тестировали и зыбыли на стандартный 1 раз в секунду поменять)))
Но это не предел - я тестировал на эмуляторе 5000 адресов, я думаю он даже на Raspberry Pi 4 без тормозов работать будет, если не хватит производительности, можно запустить нашу систему на полноценном серверном компьютере (поддерживаются операционные системы Linux и Windows). Я вам по секрету скажу, это ядро по скорости возможно превзойдёт многие DCS сервера в очень больших SCADA системах.
У нас в SCADA реализованы все алгоритмы управления оборудованием и сбора данных с датчиков. Больше на объекте нет никаких контроллеров ПЛК. Этот микрокомпьютер на базе Raspberry Pi 4 с Linux и запущенными сервисами (приложениями) ядра SCADA и Web-UI выступает в роли единственного контроллера и находится прямо на объекте, обычно прямо в шкафу с электроустановочными изделиями (контакторы, реле и т.д.), куда подключено всё силовое электрооборудование. На дверце этого шкафа ещё расположен сенсорный экран - подключен кабелем HDMI напрямую к микрокомпьютеру.
Можете считать это одним контроллером (ПЛК), просто у которого все входы вынесены на отдельные платы и мозги которого общаются с этими платами через Ethernet (там кабель - витая пара длиной 50 сантиметров, т.е. это Ethernet внутри одного электрошкафа, все платы управления реле в нём, вынесены только датчики).
Я сейчас специально перечитал ещё раз определение SCADA и не нашёл противоречий, почему наш софт не может называться SCADA если не общается ещё с какими-то контроллерами.
Честно говоря, никогда не слышал о BACnet. Только что загуглил - у нас на старых устройствах с CAN шиной был похожий протокол - там можно было запросить и построить дерево всех устройств на шине, с описанием каждого устройства (модель, список модулей и датчиков к нему подключенных, с описанием каналов и их единиц измерения).
Сложные устройства и протоколы у нас не прижились.
Но если какому-нибудь заказчику нужен будет BACnet для интеграции - сделаем.
Согласен, очень много чего не доделано и есть много что можно улучшить, особенно в части интерфейса.
Основной упор при разработке системы был сделан на ядро системы и оптимальный алгоритм автоуправления климатом (3 раза практически заново переписывался). Но повторю, все доработки только за счёт новых заказов, а с этим в последнее время проблемы. Также вся разработка ведётся одним человеком в свободное от основной работы время.
Теперь понял про что вы. У меня просто в статье есть главы "1. Верхний уровень – домашняя страница" и "2. Средний уровень – секция".
Тогда верхний и средний уровни из вашего перечня реализованы в сервисе ядра SCADA и сервисе UI (HMI).
Ядро напрямую общается с устройствами к которым подключены реле и датчики. У плат управления реле есть конфигурируемая настройка, что делать при пропаже связи с ядром, т.е. если ядро их не опрашивает, то что нужно им делать: ничего или всё отключить.
Не совсем понял, про какой верхний и средний уровень идёт речь. В статье описана иерархия уровней (экранов, окон) интерфейса пользователя (UI).
Обычно оба сервиса (ядро SCADA и UI) запущены на одном компьютере и общаются между собой по TCP через 127.0.0.1. Ядро опрашивает все устройства обычно 1 раз в секунду и хранит в памяти все текущие значения тегов, а также пишет изменившиеся значения в архив на диск. Если соединение между сервисами прервётся, то сервис UI периодически будет пытаться переподключиться к ядру.
Технически, каждая плитка выступает в роли ссылки и может ссылаться на любой URL где запущен сервис UI, в том числе эти сервисы UI могут быть подключены к своему ядру SCADA. Т.е. за плитками верхней (домашней) страницы может скрываться множество отдельных компьютеров со своими сервисами ядра и UI на разных объектах заказчиков, но обычно все плитки, по которым можно прокликать - это всё таки один объект заказчика (например, овощехранилище, состоящее из нескольких расположенных рядом складов-секций).
Архитектура системы (подробнее https://habr.com/ru/articles/1001024/):
Я думаю что мы говорим о разных порядках стоимости внедрения системы. Я о примерно 1-5 млн. руб. за всю автоматику, включая наши устройства, датчики, шкаф с электроустановочными компонентами (автоматы, контакторы, реле), но без учёта силового оборудования (вентиляторы, клапана и т.д.).
Как дела обстоят на практике в интерфейсах с картинками в овощехранилищах, я описал в комментарии выше.
Для технологических линий предприятий да, иногда очень хорошо всё отрисовывают, с множеством экранов для каждого технологического процесса и т.д., но там и бюджет в 10, а скорее в 100 и более раз выше.
Но всё равно, мне ближе подход «взгляду не за что зацепиться» при нормальной работе, описанный в книге «The High Performance HMI Handbook».
Журнал событий и аварий есть, с поддержкой квитирования, просто в данном случае он в интерфейс не выведен, т.к. конкретному заказчику не нужен (настроено SMS оповещение на важные события).
Мы ведём разработку функций только если они нужны какому-нибудь заказчику. К сожалению, нет ресурсов разрабатывать универсальную систему. Само ядро SCADA с тегами универсальное, позволяет описать всё что угодно. Но на его базе нужно создавать оборудование с тегами, логические функции для их работы, компоненты UI. Всё это создаётся когда нехватает уже реализованных компонентов.
Карты (геоподложки) нет - пока никому из заказчиков не было нужно.
Конкретно ваш случай с лифтами - не вижу проблем в реализации на основе плиток. На домашней странице делаем плитки по районам города, в них выводим какую-то сводную информацию, например мы можем сделать расчётные теги, в которых бы выводилось сколько всего лифтов на районе, сколько с проблемами, сколько в аварии, сколько ремонтных бригад выехало на инциденты и т.д. Также рамка плитки может окрашиваться в красный цвет, если внутри иерархии есть аварийный статус тега, а на саму плитку этот тег не выведен.
Я вообще не уверен что в вашем случае с лифтами основой интерфейса должна быть карта города. И плитки наверное ненужны. Диспетчеру достаточно вывести журнал событий с квитированием, в карточке события будет адрес дома и ссылка на карту (Яндекс.Карты, 2 Гис и т.д.), в ней сразу интерфейс назначения ремонтной бригады сделать и т.д. Понятно что придётся написать отдельный модуль такого журнала для максимального удобства, но всё это возможно сделать на базе нашей системы.
Действительно, тема хорошего UI холиварна, как и любого дизайна.
Возможно, при условии что кто-то будет каждый раз перерисовывать этот силуэт и картинки под конкретный объект.
На практике, обычно если есть картинки в интерфейсе, то имеются жёсткие ограничения на состав и количество оборудования, например, поддерживается до 6 вентиляторов канала и до 8 датчиков температуры продукта.
Более того, часто в этом случае в интерфейсе показывается даже физически отсутствующее оборудование т.к. оно захардкожено в картинках, т.е. если на объекте вместо 6 вентиляторов только 2, то отображаются 6.
У нас нет никаких ограничений. Возможно где-то приходится чем-то жертвовать, но мы всегда очень стараемся скомпоновать удобный интерфейс под конкретный объект.
Также на мобильных устройствах этими картинками неудобно пользоваться.
Моя концепция и подход, описанный в книге «The High Performance HMI Handbook» (Hollifield, Oliver, Nimmo, Habibi), прямо противоречит этому)))
Примеры:
Пропала связь со всем оборудованием (в секции 2 уважнитель 1 выведен из работы, поэтому нет рамки):
Пропала связь сервиса UI с сервисом ядра SCADA
Мне кажется это намного нагляднее, чем следить за какой-то анимацией, означающей нормальную работу системы.
Да, поэтому обычно настраиваем SMS оповещение о самых важных событиях.
У нас устройства друг за другом цепочкой соединяются, т.е. у каждого устройства есть входной и выходной разъёмы для шины RS-485.
Вот фото цепочки устройств на шине RS-485:
С Ethernet так не получится - либо прямо на платах придётся мини коммутатор (switch) распаивать, либо ставить коммутатор отдельно и от него звездой подключать все устройства, а это огромный перерасход витой пары.
Ещё у Ethernet по витой паре ограничение на длину кабеля 100 метров, для овощехранилищ вообще не подходит - они имеют большую площадь.
Если нужен Ethernet, то такую архитектуру можно собрать на имеющихся у нас устройствах - просто перед каждым устройством (плата датчика, реле и т.д.) поставить шлюз Ethernet-RS485, т.е. за этим шлюзом будет только одно устройство.
С чего вы это взяли? Потому что я привёл код для формирования оборудования объекта? Это отдельный проект, который просто подготавливает список всех необходимых тегов для объекта и сохраняет в файл модели JSON.
Аналогично описываются точки доступа для сбора данных (шлюзы), UI и вся остальная модель объекта.
Можно самому конечно тысячи тегов в JSON создавать копипастом, но мне как-то удобнее объектный подход с билдерами оборудования и всех нужных для него тегов.
Да, функции обработки для разного оборудования, пока не компилируются на лету при запуске, как планировалось, но это только из-за Native AOT компиляции в машинный код. Если компилировать проект стандартно в IL код, никаких проблем с компиляцией функций на C# на лету не будет, я так уже делал.
Вот, у меня даже TODO соответствующий в коде есть. Тут связывается уникальное название функции, которое задаётся у тега, с делегатом (ссылкой на функцию).
У нас нет какой-то принципиальной позиции по Vendor Lock.
Если будет требование от заказчика, выпустим устройства с протоколом Modbus RTU. Но тогда придётся подготовить документацию по регистрам, иначе в этом не будет особого смысла.
Мы можем интегрировать в систему устройства сторонних производителей с любым протоколом или разработать собственные специальные устройства под нужды заказчика. Мы всё это можем сделать, но нам должен быть интересен этот процесс в финансовом плане.
Также и с нашими устройствами или SCADA. В принципе можно опубликовать все исходники, но без документации и сообщества для поддержки разработчиков это не имеет практического смысла.
И сейчас такое время, очень много кто хочет поучаствовать в импортозамещении, ничего фактически не делая. Не хотелось бы чтобы наши разработки выдали за свои и оформили патент и прочее, что в итоге мы сами своими разработками пользоваться не сможем.
В итоге перед тем как что-то выложить в открытый доступ, нужно понимать зачем и кому это нужно, юридически всё оформить, подготовить документацию и прочее. Но если появится партнёр, который готов это профинансировать, чтобы создать какую-то открытую экосистему, то мы не будем против.
Верно, используется время операционной системы. При настройке указываем часовой пояс, дальше операционка сама следит за временем.
Синхронизации часов между устройствами нет - это нам пока не нужно. На устройствах нет часов текущего времени. В протоколе предусмотрена передача времени значения от устройств, но в этом ещё ни разу не было необходимости.
Ядро одно, оно выполняет все команды от пользователей и обработку полученных данных. При получении каких-либо значений, ядро назначает свою метку времени (текущее время операционной системы).
Допустим, пользователь в браузере нажимает кнопку "Вкл", от клиента через сервис UI ядру отправляется команда установить значенияе тега с таким-то ID в "1", ядро при получении команды, проверяет можно ли её выполнить (проверка на соответствие типов данных, ограничений на диапазон, вызывает функцию проверки значений тега если она задана) и задаёт тегу требуемого состояния оборудования значение "1", при этом назначает значению текущее время операционной системы.
Задачу синхронизации данных в интерфейсе между клиентами выполняет фреймворк ASP.NET Core Blazor Server - при подключении клиента (браузера) к серверу (сервис UI) устанавливается подключение WebSocket (SignalR), по нему в бинарном виде передаются все данные. Он сам отслеживает пропажу связи с сервером, пытается переподключиться и т.д. Сервис UI отделён от сервиса ядра, взаимодействие между сервисами через TcpListener/TcpClient.
На самом деле мне не очень нравится использовать Blazor, есть идея переписать на свою связку клиента на JavaScript и сервиса UI, где бы клиент сам периодически опрашивал сервер, есть ли какие-то изменения в данных на отображаемый в текущий момент странице. Можно и тот-же WebSocket использовать для уведомлений от сервера. Т.к. HTML шаблонизатор страниц на беке, то легко реализовать алгоритм, когда бек ведёт список значений отправленных клиенту для отображения и отслеживает изменения, т.е. собирает список изменённых значений, что бы при первом запросе от клиента отправить их ему. Т.к. сервис UI всегда знает какие данные отображаются на клиенте, клиенту не нужно даже перечислять в запросе требуемый список значений (тегов). Но сейчас всё отлично работает на Blazor, поэтому это просто интересная идея на подумать.