کرون به کارخانه های آبجوسازی، بطری های نوشیدنی و تولیدکنندگان مواد غذایی در سراسر جهان ماشین آلات جداگانه و خطوط تولید کامل را ارائه می دهد. هر روز میلیون‌ها بطری شیشه‌ای، قوطی‌ها و ظروف PET از خط کرونز عبور می‌کنند. خطوط تولید سیستم های پیچیده ای با خطاهای احتمالی زیاد هستند که می تواند خط را متوقف کند و بازده تولید را کاهش دهد. Krones می‌خواهد خرابی را در اسرع وقت (گاهی حتی قبل از وقوع آن) تشخیص دهد و اپراتورهای خط تولید را برای افزایش قابلیت اطمینان و خروجی مطلع کند. بنابراین چگونه می توان یک شکست را تشخیص داد؟ Krones خطوط خود را به حسگرهایی برای جمع آوری داده ها مجهز می کند که سپس می تواند بر اساس قوانین ارزیابی شود. کرونز به عنوان سازنده خط و همچنین اپراتور خط امکان ایجاد قوانین نظارتی برای ماشین آلات را دارند. بنابراین، بطری‌کنندگان نوشیدنی و سایر اپراتورها می‌توانند حاشیه خطای خود را برای خط تعریف کنند. در گذشته کرونز از سیستمی مبتنی بر پایگاه داده سری زمانی استفاده می کرد. چالش‌های اصلی این بود که این سیستم به سختی اشکال‌زدایی می‌کرد و همچنین پرس‌وجوها وضعیت فعلی ماشین‌ها را نشان می‌داد، اما انتقال وضعیت را نشان نمی‌داد.

این پست نشان می‌دهد که چگونه Krones یک راه‌حل پخش جریانی برای نظارت بر خطوط خود ساخته است آمازون کینسیس و سرویس مدیریت آمازون برای Apache Flink. این سرویس‌های کاملاً مدیریت شده پیچیدگی ساخت برنامه‌های پخش جریانی با Apache Flink را کاهش می‌دهند. Managed Service for Apache Flink اجزای زیرین Apache Flink را مدیریت می کند که حالت برنامه بادوام، معیارها، گزارش ها و موارد دیگر را ارائه می دهد، و Kinesis شما را قادر می سازد تا داده های جریانی را به طور مقرون به صرفه در هر مقیاسی پردازش کنید. اگر می‌خواهید با برنامه Apache Flink خود شروع کنید، این را بررسی کنید مخزن GitHub برای نمونه هایی که از API های جاوا، پایتون یا SQL Flink استفاده می کنند.

بررسی اجمالی راه حل

نظارت بر خط کرونز بخشی از آن است راهنمای فروشگاه کرونز سیستم. پشتیبانی در سازمان، اولویت بندی، مدیریت و مستندسازی کلیه فعالیت های شرکت را فراهم می کند. این به آنها اجازه می دهد تا در صورت توقف دستگاه یا نیاز به مواد، به اپراتور اطلاع دهند، صرف نظر از اینکه اپراتور در کجای خط است. قوانین نظارت بر شرایط اثبات شده قبلاً تعبیه شده اند، اما می توانند از طریق رابط کاربر نیز تعریف شوند. به عنوان مثال، اگر یک نقطه داده خاص که نظارت می شود یک آستانه را نقض کند، می تواند یک پیام متنی یا ماشه ای برای سفارش تعمیر و نگهداری در خط وجود داشته باشد.

سیستم نظارت بر شرایط و ارزیابی قوانین بر اساس AWS، با استفاده از خدمات تحلیلی AWS ساخته شده است. نمودار زیر معماری را نشان می دهد.

تقریباً هر برنامه پخش جریانی داده از پنج لایه تشکیل شده است: منبع داده، جذب جریان، ذخیره سازی جریان، پردازش جریان، و یک یا چند مقصد. در بخش‌های بعدی، عمیق‌تر به هر لایه و نحوه عملکرد راه‌حل نظارت بر خط ساخته شده توسط Krones می‌پردازیم.

منبع اطلاعات

داده ها توسط سرویسی که روی یک دستگاه لبه اجرا می شود و چندین پروتکل مانند زیمنس 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 S3) و Kinesis. مدیر جریان رکوردها را بافر و جمع می کند، سپس آن را به یک جریان داده Kinesis ارسال می کند.

ذخیره سازی جریان

وظیفه ذخیره‌سازی جریان این است که پیام‌ها را به روشی مقاوم در برابر خطا بافر کند و آن را برای مصرف یک یا چند برنامه مصرف‌کننده در دسترس قرار دهد. برای دستیابی به این امر در AWS، رایج ترین فناوری ها Kinesis و آمازون پخش جریانی را برای آپاچی کافکا مدیریت کرد (Amazon MSK). برای ذخیره داده های حسگر ما از خطوط تولید، Krones Kinesis را انتخاب می کند. Kinesis یک سرویس داده جریان بدون سرور است که در هر مقیاسی با تأخیر کم کار می کند. خرده‌های موجود در یک جریان داده Kinesis یک دنباله شناسایی منحصربه‌فرد از رکوردهای داده هستند که در آن یک جریان از یک یا چند قطعه تشکیل شده است. هر قطعه دارای 2 مگابایت بر ثانیه ظرفیت خواندن و 1 مگابایت بر ثانیه ظرفیت نوشتن (با حداکثر 1,000 رکورد در ثانیه) است. برای جلوگیری از رسیدن به این محدودیت ها، داده ها باید تا حد امکان به طور یکنواخت بین خرده ها توزیع شوند. هر رکوردی که به Kinesis ارسال می‌شود دارای یک کلید پارتیشن است که برای گروه‌بندی داده‌ها در یک قطعه استفاده می‌شود. بنابراین، شما می خواهید تعداد زیادی کلید پارتیشن برای توزیع یکنواخت بار داشته باشید. مدیر جریانی که روی AWS IoT Greengrass اجرا می‌شود، از تخصیص‌های تصادفی کلید پارتیشن پشتیبانی می‌کند، به این معنی که تمام رکوردها به یک قطعه تصادفی ختم می‌شوند و بار به طور مساوی توزیع می‌شود. یک نقطه ضعف تخصیص تصادفی کلید پارتیشن این است که رکوردها به ترتیب در Kinesis ذخیره نمی شوند. نحوه حل این مشکل را در بخش بعدی توضیح می دهیم، جایی که در مورد واترمارک صحبت می کنیم.

متن

A علامت گذاری به عنوان مکانیزمی است که برای ردیابی و اندازه گیری پیشرفت زمان رویداد در یک جریان داده استفاده می شود. زمان رویداد، مُهر زمانی از زمانی است که رویداد در منبع ایجاد شده است. واترمارک پیشرفت به‌موقع برنامه پردازش جریانی را نشان می‌دهد، بنابراین همه رویدادهایی که دارای مهر زمانی قبلی یا برابر هستند، پردازش شده در نظر گرفته می‌شوند. این اطلاعات برای Flink برای پیشبرد زمان رویداد و راه اندازی محاسبات مربوطه، مانند ارزیابی پنجره، ضروری است. تأخیر مجاز بین زمان رویداد و واترمارک را می‌توان برای تعیین مدت زمان انتظار برای داده‌های دیرهنگام قبل از در نظر گرفتن کامل پنجره و پیشبرد واترمارک پیکربندی کرد.

Krones دارای سیستم‌هایی در سراسر جهان است و به دلیل قطع شدن اتصال یا سایر محدودیت‌های شبکه، نیاز به رسیدگی به ورود دیرهنگام دارد. آن‌ها کار خود را با نظارت بر دیر رسیدن و تنظیم پیش‌فرض تاخیر Flink روی حداکثر مقداری که در این معیار مشاهده کردند، شروع کردند. آنها مشکلاتی را در زمینه همگام سازی زمان از دستگاه های لبه تجربه کردند، که آنها را به روش پیچیده تری برای واترمارک هدایت می کند. آنها یک واترمارک جهانی برای همه فرستنده ها ساختند و از کمترین مقدار به عنوان واترمارک استفاده کردند. مهرهای زمانی در HashMap برای همه رویدادهای ورودی ذخیره می‌شوند. هنگامی که واترمارک ها به صورت دوره ای منتشر می شوند، از کوچکترین مقدار این HashMap استفاده می شود. برای جلوگیری از متوقف شدن واترمارک ها با داده های از دست رفته، آنها یک را پیکربندی کردند idleTimeOut پارامتر، که مهرهای زمانی را که قدیمی‌تر از آستانه مشخصی هستند نادیده می‌گیرد. این تأخیر را افزایش می‌دهد اما ثبات داده‌ای قوی می‌دهد.

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

پردازش جریان

پس از جمع‌آوری داده‌ها از حسگرها و وارد شدن به Kinesis، باید توسط یک موتور قانون ارزیابی شود. یک قانون در این سیستم نشان دهنده وضعیت یک متریک واحد (مانند دما) یا مجموعه ای از معیارها است. برای تفسیر یک متریک، بیش از یک نقطه داده استفاده می شود که یک محاسبه حالت است. در این بخش، ما عمیق‌تر به وضعیت کلیدی و وضعیت پخش در Apache Flink و نحوه استفاده از آنها برای ساخت موتور قانون Krones می‌پردازیم.

کنترل جریان و الگوی وضعیت پخش

در آپاچی فلینک، بود به توانایی سیستم برای ذخیره و مدیریت مداوم اطلاعات در طول زمان و عملیات اشاره دارد و پردازش جریان داده را با پشتیبانی از محاسبات حالتی امکان پذیر می کند.

La الگوی وضعیت پخش توزیع یک حالت را به تمام نمونه های موازی یک اپراتور اجازه می دهد. بنابراین، همه اپراتورها حالت یکسانی دارند و داده ها را می توان با استفاده از همین حالت پردازش کرد. این داده‌های فقط خواندنی را می‌توان با استفاده از یک جریان کنترل دریافت کرد. یک جریان کنترلی یک جریان داده معمولی است، اما معمولاً با نرخ داده بسیار پایین تر. این الگو به شما این امکان را می دهد که به صورت پویا وضعیت را در همه اپراتورها به روز کنید و کاربر را قادر می سازد تا وضعیت و رفتار برنامه را بدون نیاز به بازگردانی تغییر دهد. به طور دقیق تر، توزیع حالت با استفاده از یک جریان کنترل انجام می شود. با افزودن یک رکورد جدید به جریان کنترل، همه اپراتورها این به روز رسانی را دریافت کرده و از وضعیت جدید برای پردازش پیام های جدید استفاده می کنند.

این به کاربران برنامه Krones اجازه می دهد تا قوانین جدید را در برنامه Flink بدون راه اندازی مجدد وارد کنند. این کار از خرابی جلوگیری می کند و تجربه ای عالی برای کاربر ایجاد می کند زیرا تغییرات در زمان واقعی اتفاق می افتد. یک قانون یک سناریو را برای تشخیص انحراف فرآیند پوشش می دهد. گاهی اوقات، تفسیر داده های ماشین آنقدرها که در نگاه اول ممکن است آسان نیست. اگر یک سنسور دما مقادیر بالایی را ارسال می کند، ممکن است نشان دهنده یک خطا باشد، اما همچنین اثر یک روش تعمیر و نگهداری مداوم باشد. قرار دادن معیارها در زمینه و فیلتر کردن برخی از مقادیر مهم است. این با مفهومی به نام به دست می آید گروه بندی.

گروه بندی معیارها

گروه بندی داده ها و معیارها به شما این امکان را می دهد که ارتباط داده های دریافتی را تعریف کرده و نتایج دقیقی را تولید کنید. بیایید از طریق مثال در شکل زیر حرکت کنیم.

در مرحله 1 دو گروه شرط تعریف می کنیم. گروه 1 وضعیت ماشین و اینکه کدام محصول از خط عبور می کند را جمع آوری می کند. گروه 2 از مقدار سنسورهای دما و فشار استفاده می کند. یک گروه شرط بسته به مقادیری که دریافت می کند می تواند حالت های مختلفی داشته باشد. در این مثال، گروه 1 داده هایی را دریافت می کند که دستگاه در حال کار است و بطری یک لیتری به عنوان محصول انتخاب می شود. این به این گروه حالت می دهد ACTIVE. گروه 2 دارای معیارهایی برای دما و فشار است. هر دو معیار بیش از 5 دقیقه بالاتر از آستانه خود هستند. این باعث می شود که گروه 2 در الف باشد WARNING حالت. این بدان معناست که گروه 1 گزارش می دهد که همه چیز خوب است و گروه 2 اینطور نیست. در مرحله 2 وزن ها به گروه ها اضافه می شود. این در برخی شرایط مورد نیاز است، زیرا گروه ها ممکن است اطلاعات متناقضی را گزارش کنند. در این سناریو، گروه 1 گزارش می دهد ACTIVE و گزارش های گروه 2 WARNING، بنابراین برای سیستم مشخص نیست که وضعیت خط چگونه است. پس از اضافه کردن وزن ها، حالت ها می توانند رتبه بندی شوند، همانطور که در مرحله 3 نشان داده شده است. در نهایت، همانطور که در مرحله 4 نشان داده شده است، ایالتی که بالاترین رتبه را دارد به عنوان برنده انتخاب می شود.

پس از ارزیابی قوانین و تعریف وضعیت نهایی ماشین، نتایج بیشتر مورد پردازش قرار خواهند گرفت. اقدام انجام شده به پیکربندی قانون بستگی دارد. این می تواند یک اعلان به اپراتور خط برای ذخیره مجدد مواد، انجام برخی تعمیرات، یا فقط یک به روز رسانی بصری در داشبورد باشد. این بخش از سیستم که معیارها و قوانین را ارزیابی می کند و بر اساس نتایج اقدامات انجام می دهد، به عنوان یک موتور قانون.

مقیاس بندی موتور قانون

با اجازه دادن به کاربران برای ایجاد قوانین خود، موتور قانون می‌تواند تعداد زیادی قانون داشته باشد که باید آنها را ارزیابی کند، و برخی از قوانین ممکن است از داده‌های حسگر مشابه با قوانین دیگر استفاده کنند. Flink یک سیستم توزیع شده است که به خوبی به صورت افقی مقیاس می شود. برای توزیع یک جریان داده در چندین کار، می توانید از keyBy() روش. این به شما امکان می دهد یک جریان داده را به روشی منطقی پارتیشن بندی کنید و بخش هایی از داده ها را برای مدیران وظایف مختلف ارسال کنید. این کار اغلب با انتخاب یک کلید دلخواه انجام می شود تا باری به طور یکنواخت توزیع شود. در این مورد، کرونز a را اضافه کرد ruleId به نقطه داده و از آن به عنوان یک کلید استفاده کرد. در غیر این صورت، نقاط داده مورد نیاز توسط کار دیگری پردازش می شوند. جریان داده کلیدی را می توان در همه قوانین درست مانند یک متغیر معمولی استفاده کرد.

مقصدهای

هنگامی که یک قانون حالت خود را تغییر می دهد، اطلاعات به یک جریان Kinesis و سپس از طریق ارسال می شود پل رویداد آمازون به مصرف کنندگان. یکی از مصرف کنندگان یک اعلان از رویداد ایجاد می کند که به خط تولید منتقل می شود و به پرسنل هشدار می دهد که اقدام کنند. برای اینکه بتواند تغییرات حالت قانون را تجزیه و تحلیل کند، سرویس دیگری داده ها را در an می نویسد آمازون DynamoDB جدولی برای دسترسی سریع و یک TTL برای بارگیری تاریخچه طولانی مدت در آمازون S3 برای گزارش بیشتر وجود دارد.

نتیجه

در این پست، ما به شما نشان دادیم که چگونه کرونز یک سیستم نظارت بر خط تولید بلادرنگ بر روی AWS ساخت. خدمات مدیریت شده برای آپاچی فلینک به تیم کرونز اجازه داد تا با تمرکز بر توسعه برنامه به جای زیرساخت، سریعاً شروع به کار کنند. قابلیت‌های بلادرنگ Flink به Krones امکان می‌دهد تا 10% از کار افتادگی دستگاه را کاهش داده و راندمان را تا 5% افزایش دهد.

اگر می‌خواهید برنامه‌های پخش جریانی خود را بسازید، نمونه‌های موجود در آن را بررسی کنید مخزن GitHub. اگر می‌خواهید برنامه Flink خود را با کانکتورهای سفارشی گسترش دهید، ببینید آسان‌تر کردن ساخت رابط‌ها با Apache Flink: معرفی Async Sink. سینک Async در Apache Flink نسخه 1.15.1 و بالاتر موجود است.

درباره نویسنده

فلوریان مایر یک معمار ارشد راه حل و کارشناس جریان داده در AWS است. او یک فناوری است که به مشتریان در اروپا کمک می کند تا با حل چالش های تجاری با استفاده از خدمات AWS Cloud موفق شوند و نوآوری کنند. فلوریان علاوه بر کار به عنوان معمار راه حل، یک کوهنورد پرشور است و برخی از بلندترین کوه های اروپا را صعود کرده است.

امیل دیتل یک رهبر ارشد فنی در Krones است که در مهندسی داده تخصص دارد، با یک زمینه کلیدی در Apache Flink و microservices. کار او اغلب شامل توسعه و نگهداری نرم افزارهای حیاتی است. خارج از زندگی حرفه ای خود، او عمیقاً برای گذراندن زمان با کیفیت با خانواده اش ارزش قائل است.

سایمون پیر یک معمار راه حل در AWS مستقر در سوئیس است. او یک انجام دهنده عملی است و علاقه زیادی به اتصال فناوری و افرادی دارد که از خدمات AWS Cloud استفاده می کنند. تمرکز ویژه برای او جریان داده و اتوماسیون است. علاوه بر کار، سایمون از خانواده، بیرون از منزل و پیاده روی در کوه لذت می برد.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/big-data/krones-real-time-production-line-monitoring-with-amazon-managed-service-for-apache-flink/