Проектирование архитектуры потока данных, БД и развертывания.

Содержание:

  • Архитектура потока данных
  • Хранение данных: диаграмма взаимосвязей сущностей
  • Непрерывное обучение или однократное обучение данных завода?
  • Развертывание
  • Производство в облаке

В предыдущем разделе мы рассмотрели все виды алгоритмов ИИ и способы их применения в наших группах устройств и датчиков. Теперь пришло время перейти к следующему уровню проектирования архитектуры потока данных, БД и развертывания.

Подготовка к производству:

Архитектура потока данных:

Пояснение:

  1. Сервер или система OSI PI хранит данные завода в исторической форме, а также в режиме реального времени.
  2. Data Formatter: эта программа собирает данные из разных источников и передает их в ETL; в случае, если несколько данных хранятся в другом хранилище.
  3. Парсер данных: извлеките данные из OSI PI и обработайте их Jsonify перед подачей в ETL Engine.
  4. ETL Engine: этот блок будет очищать данные и приводить их в надлежащую форму для подачи в модели ML, а также хранить данные в нашей БД (Mngo DB, Dynamo DB, Cosmos DB, Postgress и т. д.).
  5. Backend Engine: этот блок содержит все виды моделей на основе машинного обучения и физики, которые обучаются на основе исторических данных и прогнозируют в реальном времени на основе потоковых данных. Вывод идет в два блока на приведенной выше диаграмме: 1-я БД хранилища и 2-й внешний интерфейс / пользовательский интерфейс (таблица, power BI).

Хранение данных: диаграмма отношений сущностей

Мастер-таблица: все желтые таблицы являются мастер-таблицами, которые содержат ссылки на все активы или оборудование завода.

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

Таблица аварийных сигналов: все таблицы красного цвета представляют собой Таблицы аварийных сигналов, которые содержат данные аварийных сигналов электрооборудования предприятия. каждый актив/аппарат будет содержать одну единственную таблицу аварийных сигналов.

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

Примечание. Всегда храните данные на аппаратном уровне, а не на основе вашего варианта использования или неисправности. Как только вы используете определенные функции в качестве входных данных для моделирования во время прогнозирования или обучения; Объединение и слияние таблиц лучше делать в нашем конвейере ETL.

Хранение данных для данных прогнозов и аномалий:

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

Хранение прогнозируемых результатов в отдельной схеме упрощает управление доступом и разрешениями для данных. Доступ к прогнозируемым результатам может быть ограничен только авторизованным персоналом или приложениями, при этом основная база данных остается доступной для более широкой группы пользователей.

Всякий раз, когда требуется объединение, мы можем легко достичь этого путем объединения с использованием SQL или других методов запросов, таких как SQLAlchemy. Лучшей практикой является сохранение прогнозируемых результатов по АКТИВАМ снова в отдельной схеме.

Непрерывное обучение или однократное обучение данным завода?

Есть несколько причин, по которым однократное обучение может быть предпочтительнее непрерывного автоматизированного обучения модели в контексте обнаружения аномалий для солнечной электростанции:

  1. Использование ресурсов. Непрерывное автоматизированное обучение может потреблять значительные вычислительные ресурсы, включая вычислительную мощность и память, что может повлиять на производительность других приложений, работающих в той же системе. Разовое обучение можно проводить на выделенной системе, высвобождая ресурсы для других задач.
  2. Дрейф данных. Непрерывное автоматизированное обучение предполагает, что входные данные остаются стабильными с течением времени, чего может не быть в случае с солнечной электростанцией, где условия окружающей среды и другие факторы могут быстро меняться. Одноразовое обучение на репрезентативном наборе данных может предоставить базовую модель, которую можно скорректировать или обновить по мере необходимости.
  3. Стабильность модели. Непрерывное автоматизированное обучение может привести к переоснащению или недообучению модели, что приведет к снижению производительности на новых данных. Однократное обучение может помочь убедиться, что модель стабильна и дает согласованные результаты.
  4. Время обучения. Однократное обучение может быть завершено быстрее, чем непрерывное автоматизированное обучение, что может быть важно в ситуациях, когда требуется быстрое обнаружение аномалий.
  5. Стоимость. Непрерывное автоматизированное обучение может быть дороже разового обучения как с точки зрения вычислительных ресурсов, так и времени, необходимого для обучения.

Производство

Развертывание:

Типы развертывания объясняются ниже.

  1. Облачное развертывание: включает развертывание модели на облачной платформе, такой как Amazon Web Services (AWS), Microsoft Azure или Google Cloud Platform (GCP). Эти платформы предоставляют инфраструктуру для размещения и масштабирования приложений, упрощая развертывание моделей.
  2. Локальное развертывание: в этом методе модель развертывается на локальных серверах или компьютерах в инфраструктуре организации. Этот метод обеспечивает больший контроль над средой развертывания, но требует больше ресурсов для обслуживания и масштабируемости.
  3. Контейнеризация. Контейнеризация включает упаковку модели и ее зависимостей в контейнер, который можно запускать на любой платформе, поддерживающей контейнеры. Этот метод упрощает развертывание, обеспечивая согласованную среду на разных платформах.
  4. Бессерверное развертывание: этот подход включает развертывание модели на бессерверной вычислительной платформе, такой как AWS Lambda или Azure Functions. Бессерверные вычисления позволяют разработчикам запускать код без управления серверами, что упрощает быстрое развертывание моделей.
  5. Пограничное развертывание: включает развертывание модели на устройстве на границе сети, например на смартфоне или устройстве IoT. Этот метод полезен, когда требуется анализ в реальном времени, и может помочь уменьшить задержку в сети.
  6. Развертывание SOC: при развертывании SOC модель обычно реализуется с использованием специализированного оборудования, такого как FPGA (программируемая пользователем вентильная матрица) или ASIC (специализированная интегральная схема), для достижения высокой производительности и низкого энергопотребления.

Развертывание модели машинного обучения в SOC может быть затруднено из-за ограниченности доступных ресурсов, таких как память и вычислительная мощность. Следовательно, могут потребоваться методы оптимизации модели, такие как квантование и сокращение, чтобы уменьшить размер и сложность модели при сохранении точности. В этом случае требуется периодическое переобучение и обновление модели, чтобы избежать дрейфа модели.

Примечание. Обычно мы используем библиотеку встраивания C++, например Boost.Python или Pybind11, для создания автономного исполняемого файла, включающего как интерпретатор Python, так и ваш код Python. Это позволяет запускать код Python на чипе, не требуя отдельной установки Python для развертывания SOC.

Производство в облаке:

Создание конвейера CI/CD на основе AWS Sagemaker:

  1. Обучите и проверьте свою модель
  2. Упакуйте свою модель как контейнер Docker
  3. Храните свой контейнер Docker в Amazon ECR
  4. Создайте конфигурацию конечной точки Amazon SageMaker.
  5. Создание конечной точки Amazon SageMaker

Среды:

  1. Разработка: на этом этапе модель разрабатывается и тестируется на локальном компьютере или сервере разработки.
  2. Тестирование. После разработки модели она тестируется в тестовой среде, чтобы убедиться, что она соответствует требованиям к производительности и дает точные результаты. Этот этап может включать тестирование как точности, так и скорости модели.
  3. Подготовка: после тестирования модель развертывается в тестовой среде, где она тестируется с использованием данных в реальном времени и контролируется на предмет производительности и точности. Этот этап помогает выявить любые потенциальные проблемы или аномалии, которые могут возникнуть в производственной среде.
  4. Производство: после того, как модель прошла все предыдущие этапы и соответствует требованиям к производительности, она развертывается в производственной среде для обнаружения аномалий в реальном времени.

Примечание 1. BentoML — это платформа с открытым исходным кодом для более быстрого производства модели, если вы используете все пользовательские службы или можете также включить свои облачные службы. Я нашел это очень полезным для разработки Python.

Примечание 2. Нам необходимо проверить, что обнаруженные аномалии не планируют техническое обслуживание с отделом эксплуатации и технического обслуживания во время подготовки, чтобы соответствовать UAT (приемочное тестирование пользователем).

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

Следующая часть здесь.