Krone menyediakan mesin individual dan lini produksi lengkap kepada pabrik bir, pembotolan minuman, dan produsen makanan di seluruh dunia. Setiap hari, jutaan botol kaca, kaleng, dan wadah PET melewati jalur Krones. Jalur produksi adalah sistem yang kompleks dengan banyak kemungkinan kesalahan yang dapat menghentikan jalur dan menurunkan hasil produksi. Krones ingin mendeteksi kegagalan sedini mungkin (terkadang bahkan sebelum kegagalan terjadi) dan memberi tahu operator lini produksi untuk meningkatkan keandalan dan output. Jadi bagaimana cara mendeteksi kegagalan? Krones melengkapi lini mereka dengan sensor untuk pengumpulan data, yang kemudian dapat dievaluasi berdasarkan aturan. Krones, sebagai produsen lini, serta operator lini mempunyai kemungkinan untuk membuat aturan pemantauan untuk mesin. Oleh karena itu, pembotolan minuman dan operator lain dapat menentukan margin kesalahan mereka sendiri untuk lini tersebut. Di masa lalu, Krones menggunakan sistem berdasarkan database deret waktu. Tantangan utamanya adalah sistem ini sulit untuk di-debug dan juga kueri mewakili status mesin saat ini, namun tidak mewakili transisi status.

Posting ini menunjukkan bagaimana Krones membangun solusi streaming untuk memantau saluran mereka, berdasarkan Amazon Kinesis dan Layanan Terkelola Amazon untuk Apache Flink. Layanan yang dikelola sepenuhnya ini mengurangi kompleksitas pembuatan aplikasi streaming dengan Apache Flink. Layanan Terkelola untuk Apache Flink mengelola komponen dasar Apache Flink yang menyediakan status aplikasi, metrik, log, dan lainnya yang tahan lama, dan Kinesis memungkinkan Anda memproses data streaming dengan hemat biaya pada skala apa pun. Jika Anda ingin memulai dengan aplikasi Apache Flink Anda sendiri, lihat Repositori GitHub untuk sampel menggunakan Java, Python, atau SQL API dari Flink.

Ikhtisar solusi

Pemantauan jalur Krones adalah bagian dari Panduan Lantai Toko Krones sistem. Ini memberikan dukungan dalam pengorganisasian, penentuan prioritas, pengelolaan, dan dokumentasi semua aktivitas di perusahaan. Hal ini memungkinkan mereka memberi tahu operator jika alat berat dihentikan atau material diperlukan, terlepas di mana pun operator berada dalam antrean. Aturan pemantauan kondisi yang terbukti sudah ada di dalamnya tetapi juga dapat ditentukan pengguna melalui antarmuka pengguna. Misalnya, jika titik data tertentu yang dipantau melanggar ambang batas, mungkin terdapat pesan teks atau pemicu perintah pemeliharaan di saluran tersebut.

Sistem pemantauan kondisi dan evaluasi aturan dibangun di AWS, menggunakan layanan analitik AWS. Diagram berikut menggambarkan arsitekturnya.

Hampir setiap aplikasi streaming data terdiri dari lima lapisan: sumber data, penyerapan aliran, penyimpanan aliran, pemrosesan aliran, dan satu atau lebih tujuan. Pada bagian berikut, kita mendalami lebih dalam setiap lapisan dan cara kerja solusi pemantauan jalur, yang dibuat oleh Krones, secara mendetail.

Sumber data

Data dikumpulkan oleh layanan yang berjalan pada perangkat edge yang membaca beberapa protokol seperti Siemens S7 atau OPC/UA. Data mentah diproses terlebih dahulu untuk membuat struktur JSON terpadu, yang membuatnya lebih mudah untuk diproses nanti di mesin aturan. Contoh payload yang dikonversi ke JSON mungkin terlihat seperti berikut:

{
  "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"
  }
}

Aliran penyerapan

Rumput Hijau AWS IoT adalah layanan cloud dan runtime edge Internet of Things (IoT) open source. Hal ini memungkinkan Anda bertindak berdasarkan data secara lokal dan mengumpulkan serta memfilter data perangkat. AWS IoT Greengrass menyediakan komponen bawaan yang dapat diterapkan ke edge. Solusi lini produksi menggunakan komponen pengelola aliran, yang dapat memproses data dan mentransfernya ke tujuan AWS seperti Analisis AWS IoT, Layanan Penyimpanan Sederhana Amazon (Amazon S3), dan Kinesis. Pengelola aliran melakukan buffering dan mengagregasi catatan, lalu mengirimkannya ke aliran data Kinesis.

Penyimpanan streaming

Tugas penyimpanan aliran adalah menyangga pesan dengan cara yang toleran terhadap kesalahan dan membuatnya tersedia untuk dikonsumsi oleh satu atau lebih aplikasi konsumen. Untuk mencapai hal ini di AWS, teknologi yang paling umum adalah Kinesis dan Amazon Managed Streaming untuk Apache Kafka (AmazonMSK). Untuk menyimpan data sensor kami dari lini produksi, Krones memilih Kinesis. Kinesis adalah layanan data streaming tanpa server yang berfungsi pada skala apa pun dengan latensi rendah. Pecahan dalam aliran data Kinesis adalah rangkaian rekaman data yang diidentifikasi secara unik, dengan aliran terdiri dari satu atau lebih pecahan. Setiap pecahan memiliki kapasitas baca 2 MB/dtk dan kapasitas tulis 1 MB/dtk (dengan maksimal 1,000 catatan/dtk). Untuk menghindari batas tersebut, data harus didistribusikan ke seluruh pecahan secara merata. Setiap catatan yang dikirim ke Kinesis memiliki kunci partisi, yang digunakan untuk mengelompokkan data ke dalam sebuah pecahan. Oleh karena itu, Anda ingin memiliki kunci partisi dalam jumlah besar untuk mendistribusikan beban secara merata. Manajer pengaliran yang berjalan di AWS IoT Greengrass mendukung penetapan kunci partisi acak, yang berarti bahwa semua catatan berakhir di pecahan acak dan beban didistribusikan secara merata. Kerugian dari penetapan kunci partisi acak adalah catatan tidak disimpan secara berurutan di Kinesis. Kami menjelaskan cara mengatasinya di bagian selanjutnya, di mana kita berbicara tentang tanda air.

Watermarks

A cap air adalah mekanisme yang digunakan untuk melacak dan mengukur kemajuan waktu peristiwa dalam aliran data. Waktu acara adalah stempel waktu sejak acara dibuat di sumbernya. Tanda air menunjukkan kemajuan tepat waktu dari aplikasi pemrosesan aliran, sehingga semua peristiwa dengan stempel waktu yang lebih awal atau sama dianggap telah diproses. Informasi ini penting bagi Flink untuk mempercepat waktu kejadian dan memicu penghitungan yang relevan, seperti evaluasi jendela. Jeda yang diizinkan antara waktu peristiwa dan tanda air dapat dikonfigurasi untuk menentukan berapa lama waktu menunggu data terlambat sebelum mempertimbangkan penyelesaian jendela dan memajukan tanda air.

Krones memiliki sistem di seluruh dunia, dan diperlukan untuk menangani kedatangan yang terlambat karena hilangnya koneksi atau kendala jaringan lainnya. Mereka memulai dengan memantau kedatangan yang terlambat dan mengatur penanganan keterlambatan Flink default ke nilai maksimum yang mereka lihat dalam metrik ini. Mereka mengalami masalah sinkronisasi waktu dari perangkat edge, yang mengarahkan mereka ke cara watermarking yang lebih canggih. Mereka membuat tanda air global untuk semua pengirim dan menggunakan nilai terendah sebagai tanda air. Stempel waktu disimpan dalam HashMap untuk semua acara yang masuk. Ketika tanda air dikeluarkan secara berkala, nilai terkecil dari HashMap ini yang digunakan. Untuk menghindari terhentinya tanda air karena data yang hilang, mereka mengonfigurasi idleTimeOut parameter, yang mengabaikan stempel waktu yang lebih lama dari ambang batas tertentu. Hal ini meningkatkan latensi namun memberikan konsistensi data yang kuat.

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

Pemrosesan arus

Setelah data dikumpulkan dari sensor dan dimasukkan ke dalam Kinesis, data tersebut perlu dievaluasi oleh mesin aturan. Aturan dalam sistem ini mewakili keadaan metrik tunggal (seperti suhu) atau kumpulan metrik. Untuk menafsirkan metrik, digunakan lebih dari satu titik data, yang merupakan penghitungan stateful. Di bagian ini, kita mendalami status kunci dan status siaran di Apache Flink dan cara penggunaannya untuk membangun mesin aturan Krones.

Kontrol aliran dan pola status siaran

Di Apache Flink, negara mengacu pada kemampuan sistem untuk menyimpan dan mengelola informasi secara terus-menerus sepanjang waktu dan operasi, memungkinkan pemrosesan data streaming dengan dukungan komputasi stateful.

Grafik pola status siaran memungkinkan distribusi suatu keadaan ke semua instance paralel dari suatu operator. Oleh karena itu, semua operator memiliki status yang sama dan data dapat diproses menggunakan status yang sama. Data hanya baca ini dapat diserap dengan menggunakan aliran kontrol. Aliran kontrol adalah aliran data biasa, tetapi biasanya dengan kecepatan data yang jauh lebih rendah. Pola ini memungkinkan Anda memperbarui status secara dinamis pada semua operator, memungkinkan pengguna mengubah status dan perilaku aplikasi tanpa memerlukan penerapan ulang. Lebih tepatnya, distribusi negara dilakukan dengan menggunakan aliran kendali. Dengan menambahkan catatan baru ke aliran kontrol, semua operator menerima pembaruan ini dan menggunakan status baru untuk memproses pesan baru.

Hal ini memungkinkan pengguna aplikasi Krones untuk memasukkan aturan baru ke dalam aplikasi Flink tanpa memulai ulang. Hal ini menghindari downtime dan memberikan pengalaman pengguna yang luar biasa saat perubahan terjadi secara real-time. Aturan mencakup skenario untuk mendeteksi penyimpangan proses. Terkadang, interpretasi data mesin tidak semudah yang terlihat pada pandangan pertama. Jika sensor suhu mengirimkan nilai tinggi, ini mungkin menunjukkan kesalahan, namun juga merupakan efek dari prosedur pemeliharaan yang sedang berlangsung. Penting untuk menempatkan metrik dalam konteks dan memfilter beberapa nilai. Hal ini dicapai dengan konsep yang disebut pengelompokan.

Pengelompokan metrik

Pengelompokan data dan metrik memungkinkan Anda menentukan relevansi data yang masuk dan memberikan hasil yang akurat. Mari kita lihat contoh pada gambar berikut.

Pada Langkah 1, kami mendefinisikan dua kelompok kondisi. Grup 1 mengumpulkan status mesin dan produk mana yang melewati jalur tersebut. Kelompok 2 menggunakan nilai sensor suhu dan tekanan. Grup kondisi dapat memiliki status berbeda bergantung pada nilai yang diterimanya. Dalam contoh ini, kelompok 1 menerima data bahwa mesin sedang berjalan, dan botol satu liter dipilih sebagai produk; ini memberi kelompok ini negara ACTIVE. Grup 2 memiliki metrik suhu dan tekanan; kedua metrik berada di atas ambang batasnya selama lebih dari 5 menit. Hal ini menyebabkan kelompok 2 berada di a WARNING negara. Artinya kelompok 1 melaporkan semuanya baik-baik saja dan kelompok 2 tidak. Pada Langkah 2, bobot ditambahkan ke grup. Hal ini diperlukan dalam beberapa situasi, karena kelompok mungkin melaporkan informasi yang bertentangan. Dalam skenario ini, kelompok 1 melaporkan ACTIVE dan laporan kelompok 2 WARNING, jadi tidak jelas bagi sistem bagaimana keadaan salurannya. Setelah menjumlahkan bobot, negara bagian dapat diberi peringkat, seperti yang ditunjukkan pada langkah 3. Terakhir, negara bagian dengan peringkat tertinggi dipilih sebagai pemenang, seperti yang ditunjukkan pada Langkah 4.

Setelah aturan dievaluasi dan status mesin akhir ditentukan, hasilnya akan diproses lebih lanjut. Tindakan yang diambil bergantung pada konfigurasi aturan; ini bisa berupa pemberitahuan kepada operator lini untuk mengisi kembali material, melakukan pemeliharaan, atau sekadar pembaruan visual di dasbor. Bagian dari sistem ini, yang mengevaluasi metrik dan aturan serta mengambil tindakan berdasarkan hasil, disebut sebagai a mesin aturan.

Menskalakan mesin aturan

Dengan membiarkan pengguna membuat aturannya sendiri, mesin aturan dapat memiliki banyak aturan yang perlu dievaluasi, dan beberapa aturan mungkin menggunakan data sensor yang sama dengan aturan lainnya. Flink adalah sistem terdistribusi yang berskala horizontal dengan sangat baik. Untuk mendistribusikan aliran data ke beberapa tugas, Anda dapat menggunakan keyBy() metode. Hal ini memungkinkan Anda mempartisi aliran data dengan cara yang logis dan mengirim sebagian data ke pengelola tugas yang berbeda. Hal ini sering dilakukan dengan memilih kunci sembarang sehingga Anda mendapatkan beban yang merata. Dalam hal ini, Krones menambahkan a ruleId ke titik data dan menggunakannya sebagai kunci. Jika tidak, titik data yang diperlukan akan diproses oleh tugas lain. Aliran data yang dikunci dapat digunakan di semua aturan seperti variabel biasa.

Tujuan

Saat aturan mengubah statusnya, informasi dikirim ke aliran Kinesis dan kemudian melalui Jembatan Acara Amazon kepada konsumen. Salah satu konsumen membuat pemberitahuan dari peristiwa yang dikirimkan ke jalur produksi dan memperingatkan personel untuk bertindak. Untuk dapat menganalisis perubahan status aturan, layanan lain menulis data ke Amazon DynamoDB tabel untuk akses cepat dan TTL tersedia untuk memindahkan riwayat jangka panjang ke Amazon S3 untuk pelaporan lebih lanjut.

Kesimpulan

Dalam postingan ini, kami menunjukkan kepada Anda bagaimana Krones membangun sistem pemantauan lini produksi real-time di AWS. Layanan Terkelola untuk Apache Flink memungkinkan tim Krones memulai dengan cepat dengan berfokus pada pengembangan aplikasi daripada infrastruktur. Kemampuan Flink secara real-time memungkinkan Krones mengurangi waktu henti alat berat sebesar 10% dan meningkatkan efisiensi hingga 5%.

Jika Anda ingin membuat aplikasi streaming Anda sendiri, lihat contoh yang tersedia di Repositori GitHub. Jika Anda ingin memperluas aplikasi Flink Anda dengan konektor khusus, lihat Mempermudah Pembuatan Konektor dengan Apache Flink: Memperkenalkan Async Sink. Async Sink tersedia di Apache Flink versi 1.15.1 dan yang lebih baru.

Tentang Penulis

Florian Mair adalah Arsitek Solusi Senior dan pakar streaming data di AWS. Dia adalah seorang teknolog yang membantu pelanggan di Eropa sukses dan berinovasi dengan memecahkan tantangan bisnis menggunakan layanan AWS Cloud. Selain bekerja sebagai Arsitek Solusi, Florian adalah seorang pendaki gunung yang bersemangat, dan telah mendaki beberapa gunung tertinggi di Eropa.

Emil Dietl adalah Pimpinan Teknologi Senior di Krones yang berspesialisasi dalam rekayasa data, dengan bidang utama dalam Apache Flink dan layanan mikro. Pekerjaannya sering kali melibatkan pengembangan dan pemeliharaan perangkat lunak yang sangat penting. Di luar kehidupan profesionalnya, dia sangat menghargai menghabiskan waktu berkualitas bersama keluarganya.

Simon Peyer adalah Arsitek Solusi di AWS yang berbasis di Swiss. Dia adalah orang yang praktis dan bersemangat dalam menghubungkan teknologi dan orang-orang yang menggunakan layanan AWS Cloud. Fokus khusus baginya adalah streaming data dan otomatisasi. Selain bekerja, Simon menikmati keluarganya, alam bebas, dan hiking di pegunungan.

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• PlatoData.Jaringan Vertikal Generatif Ai. Berdayakan Diri Anda. Akses Di Sini.
• PlatoAiStream. Intelijen Web3. Pengetahuan Diperkuat. Akses Di Sini.
• PlatoESG. Karbon, teknologi bersih, energi, Lingkungan Hidup, Tenaga surya, Penanganan limbah. Akses Di Sini.
• PlatoHealth. Kecerdasan Uji Coba Biotek dan Klinis. Akses Di Sini.
• Sumber: https://aws.amazon.com/blogs/big-data/krones-real-time-production-line-monitoring-with-amazon-managed-service-for-apache-flink/