Предыстория проекта

В 2018 году Министерство промышленности и информационных технологий запустило Национальный проект инноваций и развития по созданию промышленного хаба. обработки данные. China Mobile существуют. Этот проект осуществляется компаниями Edge Collaboration и Сборка. функции, связанные с данными, из исследований и разработок.

требования и проблемы

Требовать

• Собирайте производственные и эксплуатационные данные с завода и отправляйте их в облако.
• Единый контроль в облаке: какие данные собираются и как обрабатываются

испытание

• Только периферия может активно подключаться к облаку. Обратное невозможно (у периферии нет общедоступного IP-адреса).
• Различные типы промышленного оборудования и протоколов не могут поддерживаться одновременно.
• Когда сеть нестабильна, граничные узлы не могут работать автономно.
• Граничные вычисления не поддерживаются при запуске приложений на пограничных узлах.
• Ресурсов потребляется много.

Технологические возможности

Первым решением, которое мы рассмотрели, был EdgeX. EdgeX хорош для сбора данных и управления ими, но у него все еще есть недостатки в таких аспектах, как совместная работа в периферийном облаке. Это больше похоже на автономную архитектуру на периферии и не может быть подключено к облаку. У нас есть некоторые средства правовой защиты. Например, мы могли бы подключить узлы EdgeX к центральному облаку через VPN, но это решение менее масштабируемо.

Второе решение — K3s/K8s. Ни K3s, ни K8s не поддерживают совместную работу в периферийном облаке, а K8s потребляет слишком много ресурсов. Хотя K3 может работать с меньшим количеством ресурсов, он не поддерживает управление устройствами.

Затем мы попробовали OpenNESS, общую структуру. Однако для нас это слишком обычно. Нам нужно написать адаптеры практически для любой необходимой нам платформы, например для базовой Kubernetes. Рабочая нагрузка разработки относительно велика, а управление устройствами не поддерживается.

Когда-то мы хотели использовать OpenYurt, функционал которого аналогичен KubeEdge. Однако на тот момент мы были на полпути к реализации проекта и решили не меняться. Кажется, это правильное решение, тем более что теперь мы видим, что OpenYurt менее зрелый, чем KubeEdge.

Но в конце концов мы решили использовать KubeEdge, поскольку он потребляет меньше ресурсов и обеспечивает совместную работу в периферийном облаке и управление устройствами.

Архитектурный дизайн

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

Глубоко внутри EdgeCore находится Mapper, стандарт управления устройствами и сбора данных. В настоящее время сообщество Mapper предлагает Modbus и Bluetooth. Например, если вы хотите управлять своей собственной камерой, вы можете запрограммировать ее с помощью Mapper. На верхнем уровне вы можете увидеть службы управления, инкапсулированные через Java и Spring Cloud. Если API KubeEdge или Kubernetes доступны пользователям, пользователи могут использовать эти открытые API для выполнения операций, которые могут иметь катастрофические последствия для изоляции данных и их кластеров Kubernetes. Вот почему необходима инкапсуляция.

Мы также разработали торговую площадку промышленных приложений для отдельных разработчиков и поставщиков, позволяющую разрабатывать и публиковать бесплатное или платное приложение KubeEdge Mapper. Пользователь KubeEdge и в то же время Разработчики Mapper приносят реальную пользу.

Сбор данных

Мы внесли следующие улучшения в KubeEdge:

• Поддерживает более широкий спектр промышленных устройств и протоколов.

Вначале мы обнаружили, что KubeEdge поддерживает только Bluetooth и Modbus. Эти протоколы зафиксированы в KubeEdge CRD и не могут быть изменены. Для поддержки различных промышленных протоколов (некоторые из которых являются проприетарными) нам необходимо добавить несколько пользовательских расширений. Один из них — расширить существующие протоколы, такие как Modbus. Различные устройства могут иметь некоторые дополнительные конфигурации. В этом случае вы можете настроить поле, используя недавно добавленное поле CustomizedValue. Другой вариант — использовать CustomizedProtocol вместо протокола сообщества для настройки собственного протокола.

• Упрощенная конфигурация устройства Сбор данных.

Промышленное упражнение иногда ассоциируется с обычным IT Развитие другое. Обычно мы определяем шаблоны перед определением экземпляров. Однако в промышленном существовании имеет смысл сначала определить экземпляр, а затем скопировать и изменить содержимое экземпляра. Например, 10 Однотипные датчики температуры подключаются к одной промышленной шине. За исключением того, что они Modbus Помимо смещения, они имеют одинаковые свойства. В этом случае вам просто нужно изменить смещение в экземпляре, мы сделали это, переместив PropertyVisitor в модели устройства в DeviceInstance. чтобы добиться этого. Мы также сделали настройку более гибкой. Например, вы можете настроить устройство так, чтобы оно сообщало данные о температуре один раз в час, а данные об использовании энергии — один раз в день. Задействованные элементы конфигурации, такие как CollectCycle, добавьте в PropertyVisitor, добавьте последовательный порт и TCP Конфигурация извлекается в общедоступную конфигурацию.

• Оптимизируйте передачу двойных атрибутов.
• Поддерживает настройку обходных данных.

Обход обработки данных

KubeEdge предоставляет правила очистки Kuiper. Сторонние приложения получают данные непосредственно с периферийных устройств MQTT.

мониторинг состояния

мониторинг Состояние очень важно для коммерческих продуктов. Кубе Эдж предоставляет файл с именем Cloud Stream канал. Этот канал можно использовать с MetricServer или Prometheus используются вместе. Но вам нужно настроить iptables на перехват трафика. Если вы это сделаете, то весь трафик будет перехватываться.

Поэтому мы разработали другое решение. Мы запускаем контейнер заданий cron на граничном узле, например, каждые 5 секунд, чтобы получать данные из NodeExporter на граничном узле, а затем передаем их в PushGateway, официальный компонент Prometheus. PushGateway развертывается в облаке. Таким образом, мы можем использовать облако для мониторинга всех пограничных узлов.

Другие возникшие проблемы

Совместное использование нескольких арендаторов

Kubernetes 允许Совместное использование нескольких арендаторов。но,существовать KubeEdge , разные устройства не могут быть развернуты в разных пространствах имен. Нам нужно пометить устройства и отфильтровать их по тегам. Пограничные рабочие узлы также не могут принадлежать определенному пространству имен. Он принадлежит арендатору и предназначен только для использования арендатором. В этом случае узлу необходимо инкапсулировать саму службу верхнего уровня.

Ограничения по IP-адресу

Обычно арендаторы подключают свои пограничные узлы к кластерам Kubernetes в облаке. Таким образом, кластеру требуются общедоступные IP-адреса, но в вашем проекте может не хватить IP-ресурсов. Например, у вас есть 200 общедоступных IP-адресов, но у вас 1000 клиентов. Как вы будете назначать IP-адреса своим кластерам клиентов?

IPv6 — лучшее решение. KubeEdge поддерживает IPv6, но мы его еще не пробовали.

Повторное использование портов

KubeEdge использует всего несколько портов, максимум 4 или 5. Порт по умолчанию — 10003, а общедоступный IP-адрес может повторно использоваться несколькими экземплярами KubeEdge.

Решение высокой доступности

KubeEdge повторно использует службы, развертывания и проверки состояния Kubernetes, чтобы обеспечить высокую доступность служб.

упражняться

Случай 1: сбор и обработка данных OPC-UA

После того, как пользователь подпишется на картограф OPC-UA, он будет доставлен на периферийный шлюз и работать с периферийным промышленным оборудованием после настройки. Например:

Сопоставитель OPC-UA собирает данные о температуре.

Приложение сигнализации краевого узла получает данные непосредственно от краевого узла.

Превышение порогового значения вызовет сигнал тревоги и устройство будет приостановлено.

KubeEdge регулирует порог.

Кейс 2: Промышленное видеонаблюдение

Это приложение работает автономно после доставки на периферию. Вывод ИИ выполняется на границе. Облако и периферия объединены, и модель можно обучить в облаке, а затем передать на периферию через KubeEdge.

KubeEdge управляет конфигурацией приложений видеонаблюдения на пограничных узлах.

Приложения видеонаблюдения работают автономно на периферийных узлах.

Собирайте видеопотоки с камер для вывода ИИ.

Проверьте защитные каски и рабочую одежду.

Обнаружение несанкционированного доступа.

обобщать

на основе KubeEdge из ПРОМЫШЛЕННОСТЬ Сбор данных

• Различные типы промышленных протоколов могут поддерживаться с помощью CustomizedProtocol и CustomizedValue.
• Используйте ConfigMaps для управления приложениями периферийных данных (Mapper) в облаке.
• Обход данных (Spec/Data) упрощает обработку данных временных рядов.

Развертывание KubeEdge в реальном производстве

• Мультиарендное решение
• Различные решения для мониторинга
• Решение высокой доступности
• Решение для повторного использования IP-адреса

связанный KubeEdge Для получения более подробной информации посетите

Github：https://github.com/kubeedge/kubeedge

веб-сайт：https://kubeedge.io/en/