крони надає пивоварням, розливникам напоїв і виробникам харчових продуктів у всьому світі окремі машини та повні виробничі лінії. Щодня мільйони скляних пляшок, банок і ПЕТ-тари проходять через лінію Krones. Виробничі лінії — це складні системи з великою кількістю можливих помилок, які можуть зупинити лінію та знизити вихід продукції. Krones хоче виявити несправність якомога раніше (іноді навіть до того, як вона станеться) і повідомити операторів виробничої лінії, щоб підвищити надійність і продуктивність. Отже, як виявити збій? Krones оснащує свої лінії датчиками для збору даних, які потім можна оцінити за правилами. Krones, як виробник ліній, а також оператор лінії мають можливість створювати правила моніторингу для машин. Тому розливники напоїв та інші оператори можуть визначати власну похибку для лінії. У минулому Krones використовувала систему, засновану на базі даних часових рядів. Основні проблеми полягали в тому, що цю систему було важко налагодити, а також запити відображали поточний стан машин, але не зміни стану.

У цій публікації показано, як компанія Krones створила потокове рішення для моніторингу своїх ліній на основі Амазонський кінезіс та Керована служба Amazon для Apache Flink. Ці повністю керовані служби зменшують складність створення потокових програм за допомогою Apache Flink. Керована служба для Apache Flink керує основними компонентами Apache Flink, які забезпечують надійний стан додатків, показники, журнали тощо, а Kinesis дає змогу економічно ефективно обробляти потокові дані будь-якого масштабу. Якщо ви хочете розпочати роботу з власною програмою Apache Flink, перегляньте GitHub сховище для прикладів використання Java, Python або SQL API Flink.

Огляд рішення

Лінійний моніторинг Krones є частиною Керівництво по цеху Krones система. Він забезпечує підтримку в організації, визначенні пріоритетів, управлінні та документуванні всіх видів діяльності в компанії. Це дозволяє їм повідомляти оператора, якщо машина зупинилася або потрібні матеріали, незалежно від того, де оператор знаходиться в черзі. Перевірені правила моніторингу стану вже вбудовані, але також можуть бути визначені користувачем через інтерфейс користувача. Наприклад, якщо певна точка даних, яка контролюється, порушує порогове значення, у рядку може з’явитися текстове повідомлення або тригер для замовлення на обслуговування.

Система моніторингу умов і оцінки правил побудована на базі AWS з використанням аналітичних сервісів AWS. Наступна схема ілюструє архітектуру.

Майже кожна програма для потокового передавання даних складається з п’яти рівнів: джерело даних, прийом потоку, зберігання потоку, обробка потоку та один або більше місць призначення. У наступних розділах ми глибше зануримося в кожен рівень і детально розглянемо, як працює рішення для моніторингу ліній, створене Krones.

Джерело даних

Дані збирає служба, яка працює на периферійному пристрої, який зчитує кілька протоколів, наприклад Siemens S7 або OPC/UA. Необроблені дані попередньо обробляються, щоб створити уніфіковану структуру JSON, що полегшує подальшу обробку в системі правил. Приклад корисного навантаження, перетвореного на JSON, може виглядати так:

{
  "version": 1,
  "timestamp": 1234,
  "equipmentId": "84068f2f-3f39-4b9c-a995-d2a84d878689",
  "tag": "water_temperature",
  "value": 13.45,
  "quality": "Ok",
  "meta": {      
    "sequenceNumber": 123,
    "flags": ["Fst", "Lst", "Wmk", "Syn", "Ats"],
    "createdAt": 12345690,
    "sourceId": "filling_machine"
  }
}

Завантаження потоку

AWS IoT Greengrass це хмарна служба Інтернету речей (IoT) з відкритим вихідним кодом. Це дозволяє діяти з даними локально, агрегувати та фільтрувати дані пристрою. AWS IoT Greengrass надає готові компоненти, які можна розгорнути на межі. Рішення для виробничої лінії використовує компонент керування потоками, який може обробляти дані та передавати їх до місць призначення AWS, наприклад AWS IoT Analytics, Служба простого зберігання Amazon (Amazon S3) і Kinesis. Менеджер потоку буферизує та об’єднує записи, а потім надсилає їх у потік даних Kinesis.

Потокове зберігання

Завдання потокового сховища полягає в тому, щоб буферизувати повідомлення у відмовостійкий спосіб і робити їх доступними для використання одним або декількома додатками-користувачами. Для досягнення цього на AWS найпоширенішими технологіями є Kinesis і Amazon керував потоковим передаванням для Apache Kafka (Amazon MSK). Для зберігання даних наших датчиків із виробничих ліній Krones обирає Kinesis. Kinesis — це безсерверна служба потокового передавання даних, яка працює в будь-якому масштабі з низькою затримкою. Шарди в потоці даних Kinesis — це унікально визначена послідовність записів даних, де потік складається з одного або кількох фрагментів. Кожен шард має ємність читання 2 МБ/с і запису 1 МБ/с (макс. 1,000 записів/с). Щоб уникнути перевищення цих обмежень, дані слід розподіляти між фрагментами якомога рівномірніше. Кожен запис, який надсилається до Kinesis, має ключ розділу, який використовується для групування даних у шард. Тому ви хочете мати велику кількість ключів розділів, щоб рівномірно розподілити навантаження. Менеджер потоків, який працює на AWS IoT Greengrass, підтримує призначення ключів випадкового розділу, що означає, що всі записи потрапляють у випадковий шард, а навантаження розподіляється рівномірно. Недоліком випадкового призначення ключів розділу є те, що записи не зберігаються в порядку в Kinesis. Ми пояснимо, як це вирішити, у наступному розділі, де ми говоримо про водяні знаки.

Водяні знаки

A водяний знак це механізм, який використовується для відстеження та вимірювання прогресу часу події в потоці даних. Час події — це позначка часу, починаючи з моменту створення події в джерелі. Водяний знак вказує на своєчасний прогрес програми обробки потоку, тому всі події з більш ранньою або такою ж позначкою часу вважаються обробленими. Ця інформація є важливою для Flink, щоб прискорити час події та запустити відповідні обчислення, наприклад оцінки вікон. Дозволену затримку між часом події та водяним знаком можна налаштувати, щоб визначити, як довго чекати запізнілих даних, перш ніж вважати вікно завершеним і просувати водяний знак.

Krones має системи по всьому світу, і їм необхідно обробляти пізні прибуття через втрату з’єднання або інші обмеження мережі. Вони почали з моніторингу запізнілих прибуттів і встановлення за замовчуванням обробки запізнень Flink на максимальне значення, яке вони побачили в цьому показнику. У них виникли проблеми із синхронізацією часу на периферійних пристроях, що спонукало їх до більш складного способу водяних знаків. Вони створили глобальний водяний знак для всіх відправників і використали найменше значення як водяний знак. Мітки часу зберігаються в HashMap для всіх вхідних подій. Коли водяні знаки випускаються періодично, використовується найменше значення цього HashMap. Щоб уникнути зупинки водяних знаків через відсутність даних, вони налаштували an idleTimeOut параметр, який ігнорує мітки часу, старші за певний поріг. Це збільшує затримку, але забезпечує надійну послідовність даних.

public class BucketWatermarkGenerator implements WatermarkGenerator<DataPointEvent> {
private HashMap <String, WatermarkAndTimestamp> lastTimestamps;
private Long idleTimeOut;
private long maxOutOfOrderness;
}

Потокова обробка

Після того, як дані зібрані з датчиків і введені в Kinesis, їх потрібно оцінити механізмом правил. Правило в цій системі представляє стан одного показника (наприклад, температури) або набору показників. Для інтерпретації метрики використовується більше ніж одна точка даних, що є обчисленням із збереженням стану. У цьому розділі ми глибше занурюємося в ключовий стан і стан трансляції в Apache Flink і як вони використовуються для створення механізму правил Krones.

Контрольний потік і шаблон стану трансляції

У Apache Flink, були означає здатність системи постійно зберігати інформацію та керувати нею протягом усього часу й операцій, уможливлюючи обробку потокових даних із підтримкою обчислень із збереженням стану.

Команда шаблон стану трансляції дозволяє розподіляти стан на всі паралельні екземпляри оператора. Таким чином, усі оператори мають однаковий стан, і дані можуть оброблятися за допомогою цього самого стану. Ці дані, призначені лише для читання, можна отримати за допомогою потоку керування. Керуючий потік — це звичайний потік даних, але зазвичай із значно нижчою швидкістю передачі даних. Цей шаблон дозволяє динамічно оновлювати стан усіх операторів, дозволяючи користувачеві змінювати стан і поведінку програми без необхідності повторного розгортання. Точніше, розподіл стану здійснюється за допомогою потоку керування. Додаючи новий запис у потік керування, усі оператори отримують це оновлення та використовують новий стан для обробки нових повідомлень.

Це дозволяє користувачам програми Krones вводити нові правила в програму Flink без її перезапуску. Це дозволяє уникнути простоїв і забезпечує чудову взаємодію з користувачем, оскільки зміни відбуваються в реальному часі. Правило охоплює сценарій, щоб виявити відхилення процесу. Іноді машинні дані не так легко інтерпретувати, як може здатися на перший погляд. Якщо датчик температури надсилає високі значення, це може свідчити про помилку, але також бути результатом поточної процедури технічного обслуговування. Важливо помістити показники в контекст і відфільтрувати деякі значення. Це досягається концепцією, яка називається групування.

Групування метрик

Групування даних і показників дозволяє визначити релевантність вхідних даних і отримати точні результати. Давайте розглянемо приклад на наступному малюнку.

На кроці 1 ми визначаємо дві групи умов. Група 1 збирає інформацію про стан машини та про те, який продукт проходить через лінію. Група 2 використовує значення датчиків температури і тиску. Група умов може мати різні стани залежно від значень, які вона отримує. У цьому прикладі група 1 отримує дані про те, що машина працює, а як продукт вибрано літрову пляшку; це дає цій групі стан ACTIVE. Група 2 має показники температури та тиску; обидва показники перевищують свої порогові значення більше 5 хвилин. Це призводить до того, що група 2 знаходиться в a WARNING стан. Це означає, що група 1 повідомляє, що все добре, а група 2 ні. На кроці 2 до груп додаються ваги. Це необхідно в деяких ситуаціях, оскільки групи можуть повідомляти суперечливу інформацію. У цьому сценарії звітує група 1 ACTIVE та звіти 2 групи WARNING, тому системі незрозуміло, який стан лінії. Після додавання ваг штати можна ранжувати, як показано на кроці 3. Нарешті, штат з найвищим рейтингом вибирається як переможець, як показано на кроці 4.

Після оцінки правил і визначення остаточного стану машини результати будуть додатково оброблені. Виконана дія залежить від конфігурації правила; це може бути сповіщення для оператора лінії про поповнення запасів матеріалів, проведення певного технічного обслуговування або просто візуальне оновлення на інформаційній панелі. Ця частина системи, яка оцінює показники та правила та виконує дії на основі результатів, називається двигун правила.

Масштабування механізму правил

Дозволяючи користувачам створювати власні правила, механізм правил може мати велику кількість правил, які потрібно оцінити, і деякі правила можуть використовувати ті самі дані датчика, що й інші правила. Flink — це розподілена система, яка дуже добре масштабується по горизонталі. Щоб розподілити потік даних на кілька завдань, можна скористатися keyBy() метод. Це дозволяє розділити потік даних логічним чином і надсилати частини даних до різних диспетчерів завдань. Це часто робиться шляхом вибору довільного ключа, щоб отримати рівномірно розподілене навантаження. У цьому випадку Krones додав a ruleId до точки даних і використав її як ключ. В іншому випадку необхідні точки даних обробляються іншим завданням. Ключовий потік даних можна використовувати в усіх правилах так само, як і звичайну змінну.

напрями

Коли правило змінює свій стан, інформація надсилається в потік Kinesis, а потім через Amazon EventBridge до споживачів. Один із споживачів створює сповіщення про подію, яке передається на виробничу лінію та сповіщає персонал про необхідність діяти. Щоб мати можливість аналізувати зміни стану правила, інший сервіс записує дані в Amazon DynamoDB таблицю для швидкого доступу та TTL для перевантаження довгострокової історії в Amazon S3 для подальшого звітування.

Висновок

У цій публікації ми показали вам, як компанія Krones створила систему моніторингу виробничої лінії в режимі реального часу на AWS. Керована служба для Apache Flink дозволила команді Krones швидко розпочати роботу, зосередившись на розробці програм, а не на інфраструктурі. Можливості Flink у режимі реального часу дозволили Krones скоротити час простою машини на 10% і підвищити ефективність до 5%.

Якщо ви хочете створювати власні потокові програми, перегляньте доступні зразки на GitHub сховище. Якщо ви хочете розширити свою програму Flink за допомогою спеціальних з’єднувачів, див Полегшення створення конекторів за допомогою Apache Flink: представлення асинхронного приймача. Async Sink доступний у Apache Flink версії 1.15.1 і новіших.

Про авторів

Флоріан Майр є старшим архітектором рішень і експертом з потокового передавання даних в AWS. Він технолог, який допомагає клієнтам у Європі досягати успіху та впроваджувати інновації, вирішуючи бізнес-завдання за допомогою хмарних сервісів AWS. Окрім роботи архітектором рішень, Флоріан є пристрасним альпіністом і піднявся на деякі з найвищих гір Європи.

Еміль Дітль є старшим технічним керівником у Krones, який спеціалізується на інженерії даних, з ключовою сферою діяльності в Apache Flink і мікросервісах. Його робота часто включає розробку та підтримку критично важливого програмного забезпечення. Поза професійним життям він дуже цінує якісне проведення часу з родиною.

Саймон Пеєр є архітектором рішень у компанії AWS у Швейцарії. Він практичний діяч і захоплюється об’єднанням технологій і людей за допомогою хмарних сервісів AWS. Особливу увагу він приділяє потокам даних і автоматизації. Окрім роботи, Саймон любить сім’ю, відпочинок на природі та походи в гори.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/big-data/krones-real-time-production-line-monitoring-with-amazon-managed-service-for-apache-flink/