Zephyrnet Logosu

Apache Flink için Amazon Yönetilen Hizmeti ile Krones'un gerçek zamanlı üretim hattı izlemesi | Amazon Web Hizmetleri

Tarih:

kron dünyanın her yerindeki bira fabrikalarına, içecek şişeleyicilerine ve gıda üreticilerine bireysel makineler ve komple üretim hatları sağlar. Her gün milyonlarca cam şişe, kutu ve PET kap Krones hattından geçiyor. Üretim hatları, hattı durdurabilecek ve üretim verimini düşürebilecek birçok olası hata içeren karmaşık sistemlerdir. Krones, arızayı mümkün olduğu kadar erken tespit etmek (hatta bazen gerçekleşmeden önce) ve güvenilirliği ve verimi artırmak için üretim hattı operatörlerini bilgilendirmek istiyor. Peki bir arıza nasıl tespit edilir? Krones, veri toplama amacıyla hatlarını sensörlerle donatıyor ve bu veriler daha sonra kurallara göre değerlendirilebiliyor. Hat üreticisi ve hat operatörü olarak Krones, makineler için izleme kuralları oluşturma olanağına sahiptir. Bu nedenle içecek şişeleyicileri ve diğer operatörler hat için kendi hata marjlarını tanımlayabilirler. Geçmişte Krones, zaman serisi veritabanını temel alan bir sistem kullanıyordu. Ana zorluklar, bu sistemin hata ayıklamasının zor olması ve ayrıca sorguların durum geçişlerini değil, makinelerin mevcut durumunu temsil etmesiydi.

Bu gönderi, Krones'un hatlarını izlemek için nasıl bir akış çözümü geliştirdiğini gösteriyor. Amazon Kinesis ve Apache Flink için Amazon Yönetilen Hizmeti. Tamamen yönetilen bu hizmetler, Apache Flink ile akış uygulamaları oluşturmanın karmaşıklığını azaltır. Apache Flink için Yönetilen Hizmet, dayanıklı uygulama durumu, ölçümler, günlükler ve daha fazlasını sağlayan temel Apache Flink bileşenlerini yönetir ve Kinesis, akış verilerini her ölçekte uygun maliyetli bir şekilde işlemenizi sağlar. Kendi Apache Flink uygulamanızı kullanmaya başlamak istiyorsanız şuraya göz atın: GitHub deposu Flink'in Java, Python veya SQL API'lerini kullanan örnekler için.

Çözüme genel bakış

Krones'un hat izlemesi, Krones Üretim Yeri Kılavuzu sistem. Şirketteki tüm faaliyetlerin organizasyonu, önceliklendirilmesi, yönetilmesi ve belgelenmesi konularında destek sağlar. Operatörün hattın neresinde olduğuna bakılmaksızın, makine durdurulduğunda veya malzemeye ihtiyaç duyulduğunda operatöre bildirimde bulunmalarına olanak tanır. Kanıtlanmış durum izleme kuralları zaten yerleşiktir ancak kullanıcı arayüzü aracılığıyla da kullanıcı tarafından tanımlanabilir. Örneğin, izlenen belirli bir veri noktası bir eşiği ihlal ederse, hatta bir kısa mesaj veya bakım emri tetikleyicisi bulunabilir.

Durum izleme ve kural değerlendirme sistemi, AWS analiz hizmetleri kullanılarak AWS üzerinde oluşturulmuştur. Aşağıdaki diyagram mimariyi göstermektedir.

Krones Üretim Hattı İzleme Mimari Şeması

Hemen hemen her veri akışı uygulaması beş katmandan oluşur: veri kaynağı, akış alımı, akış depolama, akış işleme ve bir veya daha fazla hedef. Aşağıdaki bölümlerde her katmanı daha derinlemesine inceleyeceğiz ve Krones tarafından geliştirilen hat izleme çözümünün nasıl çalıştığını ayrıntılı olarak ele alacağız.

Veri kaynağı

Veriler, Siemens S7 veya OPC/UA gibi çeşitli protokolleri okuyan bir uç cihaz üzerinde çalışan bir hizmet tarafından toplanır. Ham veriler, birleşik bir JSON yapısı oluşturmak için önceden işlenir; bu, daha sonra kural motorunda işlenmesini kolaylaştırır. JSON'a dönüştürülen örnek bir veri aşağıdaki gibi görünebilir:

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

Akış besleme

AWS IoT Greengrass açık kaynaklı bir Nesnelerin İnterneti (IoT) uç çalışma zamanı ve bulut hizmetidir. Bu, veriler üzerinde yerel olarak işlem yapmanıza ve cihaz verilerini toplamanıza ve filtrelemenize olanak tanır. AWS IoT Greengrass, uca dağıtılabilen önceden oluşturulmuş bileşenler sağlar. Üretim hattı çözümü, verileri işleyebilen ve bunları aşağıdaki gibi AWS hedeflerine aktarabilen akış yöneticisi bileşenini kullanır: AWS IoT Analizi, Amazon Basit Depolama Hizmeti (Amazon S3) ve Kinesis. Akış yöneticisi kayıtları ara belleğe alır ve toplar, ardından bunu bir Kinesis veri akışına gönderir.

Akış depolama

Akış depolamanın görevi, mesajları hataya dayanıklı bir şekilde arabelleğe almak ve bir veya daha fazla tüketici uygulamasının kullanımına sunmaktır. AWS'de bunu başarmak için en yaygın teknolojiler Kinesis ve Apache Kafka için Amazon Tarafından Yönetilen Akış (Amazon MSK'da). Üretim hatlarından gelen sensör verilerimizi depolamak için Krones, Kinesis'i tercih ediyor. Kinesis, her ölçekte düşük gecikmeyle çalışan, sunucusuz bir veri akışı hizmetidir. Kinesis veri akışı içindeki parçalar, bir akışın bir veya daha fazla parçadan oluştuğu, benzersiz şekilde tanımlanmış bir veri kaydı dizisidir. Her parçanın 2 MB/sn okuma kapasitesi ve 1 MB/sn yazma kapasitesi vardır (maksimum 1,000 kayıt/sn). Bu sınırlara ulaşmamak için verilerin parçalar arasında mümkün olduğunca eşit şekilde dağıtılması gerekir. Kinesis'e gönderilen her kaydın, verileri bir parça halinde gruplamak için kullanılan bir bölüm anahtarı vardır. Bu nedenle yükü eşit şekilde dağıtmak için çok sayıda bölüm anahtarına sahip olmak istiyorsunuz. AWS IoT Greengrass üzerinde çalışan akış yöneticisi, rastgele bölüm anahtarı atamalarını destekler; bu, tüm kayıtların rastgele bir parçada yer aldığı ve yükün eşit şekilde dağıtıldığı anlamına gelir. Rastgele bölüm anahtarı atamalarının bir dezavantajı, kayıtların Kinesis'te sırayla saklanmamasıdır. Filigranlardan bahsedeceğimiz bir sonraki bölümde bunu nasıl çözeceğimizi açıklıyoruz.

Filigran

A filigran bir veri akışındaki olay süresinin ilerlemesini izlemek ve ölçmek için kullanılan bir mekanizmadır. Etkinlik zamanı, etkinliğin kaynakta oluşturulduğu andan itibaren zaman damgasıdır. Filigran, akış işleme uygulamasının zamanında ilerleyişini gösterir; dolayısıyla daha erken veya eşit zaman damgasına sahip tüm olaylar işlenmiş olarak kabul edilir. Bu bilgi, Flink'in olay süresini ilerletmesi ve pencere değerlendirmeleri gibi ilgili hesaplamaları tetiklemesi için gereklidir. Olay zamanı ile filigran arasında izin verilen gecikme, bir pencerenin tamamlanması ve filigranın ilerletilmesinden önce geç verilerin ne kadar süre bekleneceğini belirlemek üzere yapılandırılabilir.

Krones'un dünyanın her yerinde sistemleri var ve bağlantı kayıpları veya diğer ağ kısıtlamaları nedeniyle geç varışlarla ilgilenmesi gerekiyordu. Geç varışları izleyerek ve varsayılan Flink geç yönetimini bu ölçümde gördükleri maksimum değere ayarlayarak başladılar. Uç cihazlarda zaman senkronizasyonu konusunda sorunlar yaşadılar ve bu da onları daha gelişmiş bir filigranlama yöntemine yönlendirdi. Tüm gönderenler için genel bir filigran oluşturdular ve filigran olarak en düşük değeri kullandılar. Zaman damgaları, gelen tüm etkinlikler için bir HashMap'te saklanır. Filigranlar periyodik olarak yayınlandığında bu HashMap'in en küçük değeri kullanılır. Eksik veriler nedeniyle filigranların durdurulmasını önlemek için bir idleTimeOut Belirli bir eşikten daha eski zaman damgalarını yok sayan parametre. Bu, gecikmeyi artırır ancak güçlü veri tutarlılığı sağlar.

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

Akış işleme

Veriler sensörlerden toplanıp Kinesis'e aktarıldıktan sonra bir kural motoru tarafından değerlendirilmesi gerekiyor. Bu sistemdeki bir kural, tek bir ölçümün (sıcaklık gibi) veya bir ölçüm koleksiyonunun durumunu temsil eder. Bir ölçümü yorumlamak için birden fazla veri noktası kullanılır; bu, durum bilgisi olan bir hesaplamadır. Bu bölümde Apache Flink'teki anahtarlı durum ve yayın durumuna ve bunların Krones kural motorunu oluşturmak için nasıl kullanıldığına daha derinlemesine bakacağız.

Kontrol akışı ve yayın durumu modeli

Apache Flink'te, belirtmek, bildirmek sistemin, bilgileri zaman ve işlemler boyunca kalıcı olarak depolama ve yönetme yeteneğini ifade eder ve durum bilgisi olan hesaplamalar desteğiyle akış verilerinin işlenmesini sağlar.

The yayın durumu modeli Bir durumun, bir operatörün tüm paralel örneklerine dağıtılmasına izin verir. Dolayısıyla tüm operatörler aynı duruma sahiptir ve veriler aynı durum kullanılarak işlenebilir. Bu salt okunur veriler bir kontrol akışı kullanılarak alınabilir. Kontrol akışı normal bir veri akışıdır ancak genellikle çok daha düşük bir veri hızına sahiptir. Bu model, tüm operatörlerdeki durumu dinamik olarak güncellemenize olanak tanıyarak kullanıcının, yeniden konuşlandırmaya gerek kalmadan uygulamanın durumunu ve davranışını değiştirmesine olanak tanır. Daha doğrusu, durumun dağıtımı bir kontrol akışı kullanılarak yapılır. Kontrol akışına yeni bir kayıt eklendiğinde, tüm operatörler bu güncellemeyi alır ve yeni mesajların işlenmesi için yeni durumu kullanır.

Bu, Krones uygulaması kullanıcılarının Flink uygulamasını yeniden başlatmadan yeni kuralları almasına olanak tanır. Bu, kesinti süresini önler ve değişiklikler gerçek zamanlı olarak gerçekleştiğinden harika bir kullanıcı deneyimi sunar. Kural, süreç sapmasını tespit etmek için bir senaryoyu kapsar. Bazen makine verilerinin yorumlanması ilk bakışta göründüğü kadar kolay olmayabilir. Bir sıcaklık sensörü yüksek değerler gönderiyorsa, bu bir hataya işaret edebilir ancak aynı zamanda devam eden bir bakım prosedürünün de etkisi olabilir. Metrikleri bağlama yerleştirmek ve bazı değerleri filtrelemek önemlidir. Bu, adı verilen bir kavramla elde edilir. gruplama.

Metriklerin gruplandırılması

Verilerin ve metriklerin gruplandırılması, gelen verilerin alaka düzeyini tanımlamanıza ve doğru sonuçlar üretmenize olanak tanır. Aşağıdaki şekildeki örneği inceleyelim.

Metriklerin gruplandırılması

1. Adımda iki durum grubu tanımlıyoruz. Grup 1 makinenin durumunu ve hattan hangi ürünün geçtiğini toplar. Grup 2 sıcaklık ve basınç sensörlerinin değerini kullanır. Bir koşul grubu, aldığı değerlere bağlı olarak farklı durumlara sahip olabilir. Bu örnekte grup 1 makinenin çalıştığına dair veri alıyor ve ürün olarak XNUMX litrelik şişe seçiliyor; bu, bu gruba durumu verir ACTIVE. Grup 2'de sıcaklık ve basınç ölçümleri bulunur; her iki ölçüm de 5 dakikadan uzun süredir eşik değerlerinin üzerindedir. Bu, grup 2'nin bir WARNING durum. Bu, grup 1'in her şeyin yolunda olduğunu bildirdiği, grup 2'nin ise her şeyin yolunda olmadığını bildirdiği anlamına gelir. Adım 2'de ağırlıklar gruplara eklenir. Bazı durumlarda buna ihtiyaç duyulur çünkü gruplar çelişkili bilgiler rapor edebilir. Bu senaryoda grup 1 raporları ACTIVE ve grup 2 raporları WARNING, dolayısıyla hattın durumunun ne olduğu sistem açısından net değil. Ağırlıklar eklendikten sonra eyaletler 3. adımda gösterildiği gibi sıralanabilir. Son olarak, 4. Adımda gösterildiği gibi en yüksek sıradaki eyalet kazanan olarak seçilir.

Kurallar değerlendirildikten ve makinenin son durumu tanımlandıktan sonra sonuçlar daha fazla işlenecektir. Gerçekleştirilen eylem kural yapılandırmasına bağlıdır; bu, hat operatörüne malzemeleri yeniden stoklaması, bakım yapması için bir bildirim veya yalnızca gösterge panosunda görsel bir güncelleme olabilir. Sistemin metrikleri ve kuralları değerlendirip sonuçlara göre aksiyonlar alan bu kısmına denir. kural motoru.

Kural motorunu ölçeklendirme

Kullanıcıların kendi kurallarını oluşturmasına izin verildiğinde kural motoru, değerlendirmesi gereken çok sayıda kurala sahip olabilir ve bazı kurallar, diğer kurallarla aynı sensör verilerini kullanabilir. Flink yatay olarak çok iyi ölçeklenen dağıtılmış bir sistemdir. Bir veri akışını birden fazla göreve dağıtmak için keyBy() yöntem. Bu, bir veri akışını mantıksal bir şekilde bölümlendirmenize ve verilerin bazı kısımlarını farklı görev yöneticilerine göndermenize olanak tanır. Bu genellikle rastgele bir anahtar seçilerek yapılır, böylece eşit olarak dağıtılmış bir yük elde edersiniz. Bu durumda Krones şunları ekledi: ruleId veri noktasına gitti ve onu anahtar olarak kullandı. Aksi takdirde ihtiyaç duyulan veri noktaları başka bir görev tarafından işlenir. Anahtarlı veri akışı, normal bir değişken gibi tüm kurallarda kullanılabilir.

En Popüler

Bir kuralın durumu değiştiğinde bilgi bir Kinesis akışına ve ardından aracılığıyla gönderilir. Amazon EventBridge tüketicilere. Tüketicilerden biri olaydan üretim hattına iletilen bir bildirim oluşturarak personeli harekete geçmesi konusunda uyarır. Kural durumu değişikliklerini analiz edebilmek için başka bir hizmet, verileri bir Amazon DinamoDB hızlı erişim için bir tablo ve daha fazla raporlama için uzun vadeli geçmişi Amazon S3'e aktarmak üzere bir TTL mevcuttur.

Sonuç

Bu yazıda size Krones'un AWS üzerinde nasıl gerçek zamanlı bir üretim hattı izleme sistemi kurduğunu gösterdik. Apache Flink için Yönetilen Hizmet, Krones ekibinin altyapı yerine uygulama geliştirmeye odaklanarak hızlı bir şekilde çalışmaya başlamasına olanak sağladı. Flink'in gerçek zamanlı yetenekleri, Krones'un makine aksama süresini %10 oranında azaltmasına ve verimliliği %5'e kadar artırmasına olanak sağladı.

Kendi akış uygulamalarınızı oluşturmak istiyorsanız, şu adresteki mevcut örneklere göz atın: GitHub deposu. Flink uygulamanızı özel bağlayıcılarla genişletmek istiyorsanız bkz. Apache Flink ile Bağlayıcı Oluşturmayı Kolaylaştırma: Async Sink'e Giriş. Eşzamansız Havuz, Apache Flink sürüm 1.15.1 ve sonrasında mevcuttur.


Yazarlar Hakkında

Florian Mair AWS'de Kıdemli Çözüm Mimarı ve veri akışı uzmanıdır. Kendisi, AWS Bulut hizmetlerini kullanarak iş zorluklarını çözerek Avrupa'daki müşterilerin başarılı olmasına ve yenilik yapmasına yardımcı olan bir teknoloji uzmanıdır. Florian, Çözüm Mimarı olarak çalışmanın yanı sıra tutkulu bir dağcıdır ve Avrupa'nın en yüksek dağlarından bazılarına tırmanmıştır.

Emil Dietl Krones'te veri mühendisliği konusunda uzmanlaşmış, Apache Flink ve mikro hizmetlerde önemli bir alana sahip Kıdemli Teknoloji Lideridir. Çalışmaları genellikle kritik görev yazılımlarının geliştirilmesini ve bakımını içerir. Mesleki yaşamının dışında ailesiyle kaliteli zaman geçirmeye çok değer veriyor.

Simon Peyer İsviçre merkezli AWS'de Çözüm Mimarıdır. Kendisi pratik bir kişidir ve teknoloji ile insanları AWS Bulut hizmetlerini kullanarak birbirine bağlama konusunda tutkuludur. Onun için özel bir odak noktası veri akışı ve otomasyonlardır. Simon, işinin yanı sıra ailesinden, açık havada olmaktan ve dağlarda yürüyüş yapmaktan hoşlanıyor.

spot_img

En Son İstihbarat

spot_img