Тогда все таки не совсем ясно, чем "обычная интеграция" отличается от "управляемого коннектора"
Оч круто будет, если напишите статью. Тема очень интересная.
Я не так глубоко погружен в тех процесс ТЭС, но полагаю, что он достаточно зарегулирован в плане "температуры на выходе" и за отклонения за диапазон наверняка от потребителей следуют штрафы(по крайней мере РСО в сторону конечников их платит). Так же думаю, что базово регулирование происходит в автоматическом режиме, скорее всего оператор может влиять лишь на изменение состава технологического оборудования в случае аварий. В таком случае КПЭ для оператора скорее должен выглядеть как "не более Ч превышений времени изменения состава оборудования в месяц", но тогда и на экран выводить его не нужно. Звиняйте за скептецизм, но "вытащить уставку на экран" выглядит притянутым за уши или я недоконца понял ваш посыл.
Что подразумевается под "управляемыми коннекторами"?
Цифровой двойник позволяет до воздействия на реальную систему посмотреть как она будет себя вести при изменении каких-либо параметров(например, уставок)?
Сможете привести реальный кейс, когда оператор технологической линии принимает решения на основе в том числе "kpi"?
"в растениеводстве на 25%, а в животноводстве — на 13% к 2025 году." Опечатка?
Есть ли у вас опыт сравнение по стоимости: внедрение на текущей инфраструктуре(теплицы, грядки в них и тд), которая адаптирована для человека, и создание новой, изначально адаптированной для роботов и ИИ?
Вы несколько раз отметили выгоду внедрения ИИ. Вот, хороший пример с трактористом, который стал "оператором с планшетом". В расчетах учитывается, что ФОТ вырос? Учитывается ли создание ИТ-инфраструктуры и КБ-инфраструктуры? Если да, то поделитесь, пожалуйста, источниками расчетов.
Коллеги, извините за оффтоп, но это же в целом человеческое: кто-то же из "айтишников" насилует людей через навязчивую рекламу в приложениях. Деньги в целом не пахнут для людей, Это факт.
Взгляд в будущее показывает, что оно за специализированными решениями, а через абзац декларируется преимущство одного универсального.
Лирика, теперь по делу.
Какую нагрузку в RPS выдерживает железка? Сколько парметров(тегов) способна переварить всего? Есть ли deadband? Планируется ли поддержка opcua? Умеет ли буферизировать?
Несколько мыслей и вопросов. 1. Какой QoS у вас использовался? 2. EMQX тоже поддерживает кластеризацию. Почему решили не юзать 3. На EMQX Community через рулсы можно настроить правила отброса клиентов. Уберегли бы инфру хотябы. В EMQX Enterprise можно это сделать специальным сервисом.
Интересно было бы почитать про опыт массовой поддержки таких устройств. С однйо стороны, да, мы можем сэкономить на траффике и времени реакции, с другой стороны - эту "армию автономных Edge AI девайсов" нужно мониторить, доставлять обновления самого ПО и моделей.
Было бы интересно увидеть сравнение в цифрах всех расходов.
Приветствую, земляк! На текущий момент насколько я понял некого "диспетчериского пункта" не существует? Есть мысли его организовать? Что планируешь использовать в качестве условной SCADA?
1. Технологическая функция IoT-системы/устройства. В примере с комбайном - это собственно его основные задачи: зарядка, отправка на поле, сбор пшеницы, возврат в док-станцию. В данном случае его "действия", равно как и его месторасположение, должны в первую очередь иметь прикладную функции и попадать в основную эксплуатируемую систему(Система Диспетчеризация Зерноуборочного Оборудования).
2. Собственно мониторинг состояния самих гаджетов управления IoT(контроллеров/edge-устойств и тд). В данном случае, описанные выше подходы целесообразно использовать на этапе разработки и/или опытной эксплуатации. Использование инструментов наблюдаемости в процессе уже промышленной эксплуатации однозначно увеличит нагрузку на IoT-железки и канал связи.
Статья выглядит поверхностной 1. Не часто сталкивался с применением МастерСкады в энергетике 2. При этом куда-то делились ОИК Диспетчера, СК-11 3. Тиббо? Текон? Это только из известных 4. Какие использовались критерии для оценки указанных характеристик?
Присоединяюсь к вопросу. В прикладном плане.
BMS с 3D моделью здания и интеграцией с системой бронирования - это уже цифровой двойник или еще нет?
Тогда все таки не совсем ясно, чем "обычная интеграция" отличается от "управляемого коннектора"
Оч круто будет, если напишите статью. Тема очень интересная.
Я не так глубоко погружен в тех процесс ТЭС, но полагаю, что он достаточно зарегулирован в плане "температуры на выходе" и за отклонения за диапазон наверняка от потребителей следуют штрафы(по крайней мере РСО в сторону конечников их платит). Так же думаю, что базово регулирование происходит в автоматическом режиме, скорее всего оператор может влиять лишь на изменение состава технологического оборудования в случае аварий. В таком случае КПЭ для оператора скорее должен выглядеть как "не более Ч превышений времени изменения состава оборудования в месяц", но тогда и на экран выводить его не нужно. Звиняйте за скептецизм, но "вытащить уставку на экран" выглядит притянутым за уши или я недоконца понял ваш посыл.
А часто вы в РФ сталкивались с применением Sparkplug?
Что подразумевается под "управляемыми коннекторами"?
Цифровой двойник позволяет до воздействия на реальную систему посмотреть как она будет себя вести при изменении каких-либо параметров(например, уставок)?
Сможете привести реальный кейс, когда оператор технологической линии принимает решения на основе в том числе "kpi"?
Несбыточный, но весьма продаваемый идеал.
А что за датасеты собираетесь продавать? Данные с датчиков? Каких с привязкой к расположению?
Идея интересная!
А может выложишь исходники на гит? Многие бы захотели свой прокси поднять.
Расскажите про кейс подробнее, пожалуйста
Тут самое главное ответить на вопрос - а зачем оно в "автоматизации инженерки".
"в растениеводстве на 25%, а в животноводстве — на 13% к 2025 году."
Опечатка?
Есть ли у вас опыт сравнение по стоимости: внедрение на текущей инфраструктуре(теплицы, грядки в них и тд), которая адаптирована для человека, и создание новой, изначально адаптированной для роботов и ИИ?
Вы несколько раз отметили выгоду внедрения ИИ. Вот, хороший пример с трактористом, который стал "оператором с планшетом". В расчетах учитывается, что ФОТ вырос? Учитывается ли создание ИТ-инфраструктуры и КБ-инфраструктуры? Если да, то поделитесь, пожалуйста, источниками расчетов.
Коллеги, извините за оффтоп, но это же в целом человеческое: кто-то же из "айтишников" насилует людей через навязчивую рекламу в приложениях.
Деньги в целом не пахнут для людей, Это факт.
Взгляд в будущее показывает, что оно за специализированными решениями, а через абзац декларируется преимущство одного универсального.
Лирика, теперь по делу.
Какую нагрузку в RPS выдерживает железка?
Сколько парметров(тегов) способна переварить всего?
Есть ли deadband?
Планируется ли поддержка opcua?
Умеет ли буферизировать?
Сервис судя по всему еще предоставляется, но пока с главной страницы ведет на 404ю.
Несколько мыслей и вопросов.
1. Какой QoS у вас использовался?
2. EMQX тоже поддерживает кластеризацию. Почему решили не юзать
3. На EMQX Community через рулсы можно настроить правила отброса клиентов. Уберегли бы инфру хотябы. В EMQX Enterprise можно это сделать специальным сервисом.
Хочется понять откуда взялись 16% и за счет чего происходит экономия.
Дмитрий, раскажите как используете RIC в данном проекте? Просто вывод информации? Отдается в MES/ERP заказчика?
Интересно было бы почитать про опыт массовой поддержки таких устройств. С однйо стороны, да, мы можем сэкономить на траффике и времени реакции, с другой стороны - эту "армию автономных Edge AI девайсов" нужно мониторить, доставлять обновления самого ПО и моделей.
Было бы интересно увидеть сравнение в цифрах всех расходов.
Приветствую, земляк!
На текущий момент насколько я понял некого "диспетчериского пункта" не существует? Есть мысли его организовать? Что планируешь использовать в качестве условной SCADA?
Мне кажется, что следует разделять 2 сущности.
1. Технологическая функция IoT-системы/устройства. В примере с комбайном - это собственно его основные задачи: зарядка, отправка на поле, сбор пшеницы, возврат в док-станцию. В данном случае его "действия", равно как и его месторасположение, должны в первую очередь иметь прикладную функции и попадать в основную эксплуатируемую систему(Система Диспетчеризация Зерноуборочного Оборудования).
2. Собственно мониторинг состояния самих гаджетов управления IoT(контроллеров/edge-устойств и тд). В данном случае, описанные выше подходы целесообразно использовать на этапе разработки и/или опытной эксплуатации. Использование инструментов наблюдаемости в процессе уже промышленной эксплуатации однозначно увеличит нагрузку на IoT-железки и канал связи.
Статья выглядит поверхностной
1. Не часто сталкивался с применением МастерСкады в энергетике
2. При этом куда-то делились ОИК Диспетчера, СК-11
3. Тиббо? Текон? Это только из известных
4. Какие использовались критерии для оценки указанных характеристик?