كرونز تزود مصانع الجعة وتعبئة المشروبات ومنتجي المواد الغذائية في جميع أنحاء العالم بآلات فردية وخطوط إنتاج كاملة. كل يوم، تمر الملايين من الزجاجات والعلب والحاويات المصنوعة من مادة PET عبر خط إنتاج شركة Krones. خطوط الإنتاج هي أنظمة معقدة بها الكثير من الأخطاء المحتملة التي قد تؤدي إلى توقف الخط وتقليل إنتاجية المنتج. يريد Krones اكتشاف الفشل في أقرب وقت ممكن (أحيانًا حتى قبل حدوثه) وإخطار مشغلي خطوط الإنتاج لزيادة الموثوقية والإنتاج. فكيف للكشف عن الفشل؟ تزود شركة Krones خطوطها بأجهزة استشعار لجمع البيانات، والتي يمكن بعد ذلك تقييمها وفقًا للقواعد. تتمتع شركة Krones، بصفتها الشركة المصنعة للخط، وكذلك مشغل الخط، بإمكانية إنشاء قواعد مراقبة للآلات. لذلك، يمكن لشركات تعبئة المشروبات والمشغلين الآخرين تحديد هامش الخطأ الخاص بهم للخط. في الماضي، استخدم كرونس نظامًا يعتمد على قاعدة بيانات السلاسل الزمنية. كانت التحديات الرئيسية هي صعوبة تصحيح أخطاء هذا النظام، كما تمثل الاستعلامات الحالة الحالية للأجهزة ولكن ليس تحولات الحالة.

يوضح هذا المنشور كيف قامت Krones ببناء حل تدفق لمراقبة خطوطها، بناءً على ذلك أمازون كينسيس و خدمة أمازون المُدارة لـ Apache Flink. تعمل هذه الخدمات المُدارة بالكامل على تقليل تعقيد إنشاء تطبيقات البث باستخدام Apache Flink. تدير الخدمة المُدارة لـ Apache Flink مكونات Apache Flink الأساسية التي توفر حالة تطبيق متينة ومقاييس وسجلات والمزيد، كما يمكّنك Kinesis من معالجة بيانات التدفق على نحو فعال من حيث التكلفة على أي نطاق. إذا كنت تريد البدء باستخدام تطبيق Apache Flink الخاص بك، فاطلع على مستودع جيثب للعينات التي تستخدم واجهات برمجة تطبيقات Java أو Python أو SQL الخاصة بـ Flink.

نظرة عامة على الحل

تعد مراقبة خط Krones جزءًا من إرشادات Krones Shopfloor نظام. ويقدم الدعم في التنظيم وتحديد الأولويات والإدارة والتوثيق لجميع الأنشطة في الشركة. فهو يسمح لهم بإخطار المشغل إذا تم إيقاف الماكينة أو كانت هناك حاجة إلى مواد، بغض النظر عن مكان وجود المشغل في الصف. إن قواعد مراقبة الحالة المثبتة مدمجة بالفعل ولكن يمكن أيضًا تحديدها بواسطة المستخدم عبر واجهة المستخدم. على سبيل المثال، إذا كانت نقطة بيانات معينة يتم مراقبتها تنتهك حدًا ما، فمن الممكن أن تكون هناك رسالة نصية أو مشغل لأمر صيانة على السطر.

تم بناء نظام مراقبة الحالة وتقييم القواعد على 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 تقنيات عمليات Greengrass هي خدمة إنترنت الأشياء (IoT) مفتوحة المصدر ووقت التشغيل والخدمة السحابية. يتيح لك ذلك التعامل مع البيانات محليًا وتجميع بيانات الجهاز وتصفيتها. يوفر AWS IoT Greengrass مكونات تم إنشاؤها مسبقًا ويمكن نشرها على الحافة. يستخدم حل خط الإنتاج مكون مدير التدفق، الذي يمكنه معالجة البيانات ونقلها إلى وجهات AWS مثل تحليلات AWS لإنترنت الأشياء, خدمة تخزين أمازون البسيطة (أمازون إس 3)، وكينيسيس. يقوم مدير الدفق بتخزين السجلات مؤقتًا وتجميعها، ثم يرسلها إلى دفق بيانات Kinesis.

تخزين الدفق

تتمثل مهمة تخزين الدفق في تخزين الرسائل مؤقتًا بطريقة متسامحة مع الأخطاء وإتاحتها للاستهلاك لواحد أو أكثر من تطبيقات المستهلك. ولتحقيق ذلك على AWS، فإن التقنيات الأكثر شيوعًا هي Kinesis و Amazon Managed Streaming لأباتشي كافكا (أمازون إم إس كيه). لتخزين بيانات المستشعر الخاصة بنا من خطوط الإنتاج، تختار 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.

التحكم في الدفق ونمط حالة البث

في Apache Flink ، حالة يشير إلى قدرة النظام على تخزين وإدارة المعلومات بشكل مستمر عبر الوقت والعمليات، مما يتيح معالجة البيانات المتدفقة مع دعم الحسابات ذات الحالة.

• نمط حالة البث يسمح بتوزيع الحالة على جميع المثيلات المتوازية للمشغل. لذلك، جميع العوامل لها نفس الحالة ويمكن معالجة البيانات باستخدام هذه الحالة نفسها. يمكن استيعاب هذه البيانات للقراءة فقط باستخدام دفق التحكم. دفق التحكم هو دفق بيانات عادي، ولكن عادةً بمعدل بيانات أقل بكثير. يتيح لك هذا النمط تحديث الحالة ديناميكيًا على جميع عوامل التشغيل، مما يمكّن المستخدم من تغيير حالة التطبيق وسلوكه دون الحاجة إلى إعادة النشر. بتعبير أدق، يتم توزيع الحالة عن طريق استخدام تيار التحكم. من خلال إضافة سجل جديد إلى تدفق التحكم، يتلقى كافة المشغلين هذا التحديث ويستخدمون الحالة الجديدة لمعالجة الرسائل الجديدة.

يتيح ذلك لمستخدمي تطبيق Krones استيعاب قواعد جديدة في تطبيق Flink دون إعادة تشغيله. يؤدي ذلك إلى تجنب التوقف عن العمل وتوفير تجربة رائعة للمستخدم مع حدوث التغييرات في الوقت الفعلي. تغطي القاعدة سيناريو من أجل اكتشاف انحراف العملية. في بعض الأحيان، لا يكون من السهل تفسير بيانات الجهاز كما قد تبدو للوهلة الأولى. إذا أرسل مستشعر درجة الحرارة قيمًا عالية، فقد يشير ذلك إلى وجود خطأ، ولكنه أيضًا نتيجة لإجراءات الصيانة المستمرة. من المهم وضع المقاييس في السياق وتصفية بعض القيم. ويتم تحقيق ذلك من خلال مفهوم يسمى تجميع.

تجميع المقاييس

يتيح لك تجميع البيانات والمقاييس تحديد مدى أهمية البيانات الواردة وتحقيق نتائج دقيقة. دعونا نسير عبر المثال في الشكل التالي.

في الخطوة 1، نحدد مجموعتين من الشروط. تجمع المجموعة 1 حالة الجهاز والمنتج الذي يمر عبر الخط. تستخدم المجموعة 2 قيمة أجهزة استشعار درجة الحرارة والضغط. يمكن أن تحتوي مجموعة الشروط على حالات مختلفة اعتمادًا على القيم التي تتلقاها. في هذا المثال، تتلقى المجموعة 1 بيانات تفيد بأن الجهاز قيد التشغيل، ويتم تحديد الزجاجة سعة لتر واحد كمنتج؛ وهذا يعطي هذه المجموعة الدولة ACTIVE. المجموعة 2 لديها مقاييس لدرجة الحرارة والضغط؛ كلا المقياسين أعلى من عتبتهما لأكثر من 5 دقائق. ينتج عن هذا وجود المجموعة 2 في أ WARNING ولاية. وهذا يعني أن المجموعة 1 تفيد بأن كل شيء على ما يرام وأن المجموعة 2 لا تفعل ذلك. في الخطوة 2، تتم إضافة الأوزان إلى المجموعات. وهذا ضروري في بعض المواقف، لأن المجموعات قد تبلغ عن معلومات متضاربة. في هذا السيناريو، تقارير المجموعة 1 ACTIVE وتقارير المجموعة 2 WARNING، لذلك ليس من الواضح للنظام ما هي حالة الخط. بعد إضافة الأوزان، يمكن ترتيب الولايات، كما هو موضح في الخطوة 3. وأخيرًا، يتم اختيار الولاية الأعلى تصنيفًا لتكون الولاية الفائزة، كما هو موضح في الخطوة 4.

بعد تقييم القواعد وتحديد الحالة النهائية للجهاز، ستتم معالجة النتائج بشكل أكبر. يعتمد الإجراء المتخذ على تكوين القاعدة؛ يمكن أن يكون هذا بمثابة إشعار لمشغل الخط لإعادة تخزين المواد، أو القيام ببعض أعمال الصيانة، أو مجرد تحديث مرئي على لوحة القيادة. يُشار إلى هذا الجزء من النظام، الذي يقيم المقاييس والقواعد ويتخذ الإجراءات بناءً على النتائج، باسم محرك القاعدة.

تحجيم محرك القاعدة

من خلال السماح للمستخدمين بإنشاء قواعدهم الخاصة، يمكن أن يحتوي محرك القواعد على عدد كبير من القواعد التي يحتاج إلى تقييمها، وقد تستخدم بعض القواعد نفس بيانات الاستشعار مثل القواعد الأخرى. Flink هو نظام موزع يتوسع بشكل جيد جدًا أفقيًا. لتوزيع دفق البيانات على عدة مهام، يمكنك استخدام keyBy() طريقة. يتيح لك ذلك تقسيم دفق البيانات بطريقة منطقية وإرسال أجزاء من البيانات إلى مديري المهام المختلفين. يتم ذلك غالبًا عن طريق اختيار مفتاح عشوائي حتى تحصل على حمل موزع بالتساوي. في هذه الحالة، أضاف كرونس أ ruleId إلى نقطة البيانات واستخدامها كمفتاح. وبخلاف ذلك، تتم معالجة نقاط البيانات المطلوبة بواسطة مهمة أخرى. يمكن استخدام دفق البيانات ذات المفاتيح عبر جميع القواعد تمامًا مثل المتغير العادي.

وجهات

عندما تغير القاعدة حالتها، يتم إرسال المعلومات إلى تدفق Kinesis ثم عبر أمازون إيفينت بريدج للمستهلكين. يقوم أحد المستهلكين بإنشاء إشعار بالحدث يتم إرساله إلى خط الإنتاج وينبه الموظفين إلى التصرف. لتتمكن من تحليل التغييرات في حالة القاعدة، تقوم خدمة أخرى بكتابة البيانات إلى ملف الأمازون DynamoDB جدول للوصول السريع وتم وضع TTL لتفريغ السجل طويل المدى إلى Amazon S3 لمزيد من التقارير.

وفي الختام

في هذا المنشور، أوضحنا لك كيف قامت Krones ببناء نظام مراقبة خط الإنتاج في الوقت الفعلي على AWS. أتاحت الخدمة المُدارة لـ Apache Flink لفريق Krones البدء بسرعة من خلال التركيز على تطوير التطبيقات بدلاً من البنية التحتية. مكنت إمكانات Flink في الوقت الفعلي شركة Krones من تقليل وقت توقف الماكينة بنسبة 10% وزيادة الكفاءة بما يصل إلى 5%.

إذا كنت ترغب في إنشاء تطبيقات البث الخاصة بك، فاطلع على العينات المتاحة على مستودع جيثب. إذا كنت تريد توسيع تطبيق Flink الخاص بك بموصلات مخصصة، فراجع تسهيل إنشاء الموصلات باستخدام Apache Flink: تقديم حوض Async. يتوفر Async Sink في الإصدار 1.15.1 من Apache Flink والإصدارات الأحدث.

حول المؤلف

فلوريان ماير هو أحد كبار مهندسي الحلول وخبير في تدفق البيانات في AWS. وهو تقني يساعد العملاء في أوروبا على النجاح والابتكار من خلال حل تحديات الأعمال باستخدام خدمات AWS السحابية. إلى جانب العمل كمهندس للحلول، فإن فلوريان هو متسلق جبال متحمس، وقد تسلق بعضًا من أعلى الجبال في جميع أنحاء أوروبا.

إميل ديتل هو قائد تقني أول في Krones متخصص في هندسة البيانات، مع مجال رئيسي في Apache Flink والخدمات الصغيرة. غالبًا ما يتضمن عمله تطوير وصيانة البرامج ذات المهام الحرجة. خارج حياته المهنية، فهو يقدر بشدة قضاء وقت ممتع مع عائلته.

سيمون باير هو مهندس الحلول في AWS ومقرها في سويسرا. إنه فاعل عملي ومتحمس لربط التكنولوجيا والأشخاص الذين يستخدمون خدمات AWS السحابية. التركيز بشكل خاص بالنسبة له هو تدفق البيانات والأتمتة. إلى جانب العمل، يستمتع سيمون بعائلته والهواء الطلق والمشي لمسافات طويلة في الجبال.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/big-data/krones-real-time-production-line-monitoring-with-amazon-managed-service-for-apache-flink/