Bu, Matarat'tan Moulham Zahabi ile birlikte yazılan bir konuk gönderisidir.

Muhtemelen herkes uçarken bagajını kontrol etmiş ve çantalarının atlıkarıncada görünmesini endişeyle beklemiştir. Çantalarınızın başarılı ve zamanında teslimi, bagaj taşıma sistemi (BHS) adı verilen devasa bir altyapıya bağlıdır. Bu altyapı, başarılı havalimanı operasyonlarının temel işlevlerinden biridir. Giden ve gelen uçuşlar için bagaj ve kargonun başarılı bir şekilde taşınması, müşteri memnuniyetini sağlamak ve havalimanı operasyonel mükemmelliği sağlamak için kritik öneme sahiptir. Bu işlev, büyük ölçüde BHS'nin sürekli çalışmasına ve bakım işlemlerinin etkinliğine bağlıdır. Havalimanlarının can damarı olan bir BHS, yılda 34,000 milyondan fazla bagajı elleçleyen (tek bir havaalanı için) 70 metreyi aşan doğrusal bir varlıktır ve bu da onu en karmaşık otomatik sistemlerden biri ve havaalanı operasyonlarının hayati bir bileşeni haline getirir.

Konveyör bandı, atlıkarınca veya tasnif ünitesi gibi bir bagaj taşıma sisteminin planlanmamış arıza süresi, havalimanı operasyonlarını kesintiye uğratabilir. Bu tür aksamalar, tatsız bir yolcu deneyimi yaratmaya ve muhtemelen havalimanı hizmet sağlayıcılarına cezalar vermeye mahkumdur.

Bir bagaj taşıma sisteminin sürdürülmesindeki yaygın zorluk, 7,000'den fazla varlık ve bir milyondan fazla ayar noktasından oluşan entegre bir sistemin sürekli olarak nasıl çalıştırılacağıdır. Bu sistemler ayrıca farklı şekil ve boyutlarda milyonlarca torbayı da işler. Bagaj taşıma sistemlerinin hataya açık olduğunu varsaymak güvenlidir. Elemanlar kapalı bir döngüde çalıştığından, bir eleman bozulursa tüm hattı etkiler. Geleneksel bakım faaliyetleri, operasyonel bir arıza durumunda operatörler tarafından gönderilen BHS boyunca kilit konumlara dağıtılan oldukça büyük bir iş gücüne dayanır. Bakım ekipleri ayrıca önleyici bakım için arıza süresini planlamak için büyük ölçüde tedarikçi tavsiyelerine güvenir. Önleyici bakım faaliyetlerinin düzgün bir şekilde uygulanıp uygulanmadığını belirlemek veya bu tür bir varlığın performansını izlemek güvenilir olmayabilir ve beklenmedik arıza süresi riskini azaltmaz.

Yedek parça yönetimi, küresel tedarik zinciri kesintileri nedeniyle teslim süreleri arttığından, ancak envanter yenileme kararları tarihsel eğilimlere dayandığından ek bir zorluktur. Ek olarak, bu eğilimler, yaşlandıkça BHS varlıklarının işletilmesinin değişken dinamik ortamını içermemektedir. Bu zorlukların üstesinden gelmek için, bakım stratejilerinde reaktif bir zihniyetten proaktif bir zihniyete geçerek sismik bir değişim olması gerekir. Bu değişim, operatörlerin bakım faaliyetlerini kolaylaştırmak, operasyonları optimize etmek ve işletme giderlerini en aza indirmek için en son teknolojiyi kullanmasını gerektiriyor.

Bu gönderide, AWS Çözüm Ortağı Airis Solutions'ın nasıl kullandığını açıklıyoruz Ekipman için Amazon Gözetleme, AWS Nesnelerin İnterneti (IoT) hizmetleri ve BulutRay Bu zorlukların üstesinden gelmek için son teknoloji ürünü bir çözüm sağlamak için sensör teknolojileri.

Bagaj taşıma sistemine genel bakış

Aşağıdaki diyagram ve tablo, Riyad'daki King Khalid Uluslararası Havaalanında tipik bir atlı karıncadan alınan ölçümleri göstermektedir.

Veriler, şemada gösterilen farklı konumlarda toplanır.

Aşağıdaki resimler, çeşitli ölçümler için ortamı ve izleme ekipmanını göstermektedir.

Konveyör motorlarından birine monte edilmiş titreşim sensörü	Karusel hızını ölçen yakınlık probu
Bagaj taşıma sayacının görüş hattı (bir mesafe sensörü kullanılarak)		Konveyör motorlarından birinin termal görüntüsü

Çözüme genel bakış

Bagaj taşıma sistemleri için kestirimci bakım sistemi (PdMS), planlanmamış arıza sürelerini iyileştirmede kolaylaştırıcı olarak veriye sahip olma yolculuklarında havalimanı bakım operatörlerine yardımcı olan bir referans mimarisidir. Bağlı sensörlerin ve hizmetlerin geliştirilmesini ve dağıtımını hızlandırmak için yapı taşları içerir. PdMS, uç bilgi işlem cihazlarının ve BHS varlıklarının yaşam döngüsünü güvenli bir şekilde yönetmek için AWS hizmetlerini, bulutta veri alımını, depolamayı, makine öğrenimi (ML) çıkarım modellerini ve bulutta proaktif ekipman bakımına güç sağlamak için iş mantığını içerir.

Bu mimari, birkaç yıl boyunca havalimanı operasyonlarında çalışırken öğrenilen derslerden oluşturulmuştur. Önerilen çözüm, bir AWS Premier İş Ortağı olan Northbay Solutions'ın desteğiyle geliştirildi ve 90 gün içinde her boyutta ve ölçekteki havaalanlarında binlerce bağlı cihaza kurulabilir.

Aşağıdaki mimari şeması, kestirimci bakım çözümünü oluşturmak için kullanılan temel bileşenleri gösterir:

Mimarimizi bir araya getirmek için aşağıdaki hizmetleri kullanıyoruz:

• CloudRail.DMC, Alman IoT uzmanı CloudRail GmbH tarafından sunulan bir hizmet olarak yazılım (SaaS) çözümüdür. Bu kuruluş, küresel olarak dağıtılmış uç ağ geçitlerinin filolarını yönetir. Bu hizmet ile endüstriyel sensörler, akıllı sayaçlar ve OPC UA sunucuları yalnızca birkaç tıklamayla bir AWS veri gölüne bağlanabilir.
• AWS IoT Çekirdeği altyapıyı yönetmeden milyarlarca IoT cihazını bağlamanıza ve trilyonlarca mesajı AWS hizmetlerine yönlendirmenize olanak tanır. Tüm IoT cihazlarınıza ve uygulamalarınıza düşük gecikme süresi ve yüksek verimlilikle güvenli bir şekilde mesaj iletir. CloudRail sensörlerine bağlanmak ve ölçümlerini AWS Cloud'a iletmek için AWS IoT Core kullanıyoruz.
• AWS IoT Analizi genellikle bir IoT analitik platformu oluşturmak için gereken maliyet ve karmaşıklık konusunda endişelenmenize gerek kalmadan, çok büyük hacimli IoT verileri üzerinde karmaşık analitiği çalıştırmayı ve faaliyete geçirmeyi kolaylaştıran, tam olarak yönetilen bir hizmettir. Doğru içgörüler elde etmek için IoT verilerinde analitik çalıştırmanın kolay bir yoludur.
• Ekipman için Amazon Gözetleme Varlığa özel verilere dayalı olarak ekipmanınız için otomatik olarak bir makine öğrenimi modeli oluşturmak üzere ekipman sensörlerinden gelen verileri analiz eder; veri bilimi becerisi gerekmez. Lookout for Equipment, gelen sensör verilerini gerçek zamanlı olarak analiz eder ve beklenmedik arıza sürelerine yol açabilecek erken uyarı sinyallerini doğru bir şekilde belirler.
• Amazon QuickSight doğal dilde sorular sorarak, bilgileri etkileşimli panolar aracılığıyla görselleştirerek ve makine öğrenimi tarafından desteklenen kalıpları ve aykırı değerleri otomatik olarak arayarak kuruluştaki herkesin verileri anlamasına olanak tanır.

Aşağıdaki şemada gösterildiği gibi, bu mimari, sensör verilerinin operasyonel içgörülere akmasını sağlar.

Veri noktaları, IO-Link sensörleri kullanılarak toplanır: IO-Link, bir endüstriyel varlığın kontrol seviyesinden (bizim durumumuzda, bagaj taşıma sistemi) sensör seviyesine kadar kesintisiz iletişim sağlamak için standartlaştırılmış bir arayüzdür. Bu protokol, sensör verilerini bir CloudRail uç ağ geçidine beslemek ve AWS IoT Core'a yüklemek için kullanılır. İkincisi, gereksiz maliyetlere yol açmadan varlık bakımı veya değiştirme için en uygun zamanlamayı belirlemek üzere kullanılabilecek operasyonel ve ekipman sorunlarını belirlemek için makine öğrenimi modellerine ekipman verileri sağlar.

Bilgi toplama

Mevcut varlıkları ve kontrol sistemlerini buluta uyarlamak, ekipman operatörleri için zorlu bir yaklaşım olmaya devam ediyor. İkincil sensörlerin eklenmesi, mevcut sistemlere müdahale etmeden gerekli verileri elde etmenin hızlı ve güvenli bir yolunu sağlar. Bu nedenle, bir makinenin PLC'lerinin doğrudan bağlanmasına kıyasla daha kolay, daha hızlı ve non-invazivdir. Ek olarak, belirli arıza modları için gereken veri noktalarını hassas bir şekilde ölçmek için sonradan takılan sensörler seçilebilir.

CloudRail ile her endüstriyel IO-Link sensörü, AWS IoT Core gibi AWS hizmetlerine bağlanabilir. AWS IoT SiteWiseya da AWS IoT Greengrass bulut tabanlı bir cihaz yönetimi portalı (CloudRail.DMC) aracılığıyla birkaç saniye içinde. Bu, IoT uzmanlarının merkezileştirilmiş konumlardan ve küresel olarak dağıtılmış yerleşik fiziksel sistemlerden çalışmasını sağlar. Çözüm, kolay bir tak ve çalıştır mekanizması aracılığıyla kestirimci bakım sistemleri için veri bağlantısı zorluklarını çözer.

Ağ geçidi, ekipman (OT) ve bulut hizmeti (IT) arasında Endüstriyel Askerden Arındırılmış Bölge (IDMZ) görevi görür. Entegre bir filo yönetimi uygulaması aracılığıyla CloudRail, en son güvenlik yamalarının binlerce kuruluma otomatik olarak dağıtılmasını sağlar.

Aşağıdaki resimde bir IO-Link sensörü ve CloudRail uç ağ geçidi (turuncu renkte) gösterilmektedir:

Anormallik algılama modeli eğitimi

Çoğu endüstriyel segmentten kuruluş, modern bakım stratejilerinin arızaya kadar çalışan, reaktif yaklaşımlardan uzaklaştığını ve daha tahmine dayalı yöntemlere doğru ilerlediğini görüyor. Bununla birlikte, duruma dayalı veya kestirimci bakım yaklaşımına geçiş, tesisler genelinde kurulu sensörlerden toplanan verileri gerektirir. Analitik ile birlikte bu sensörler tarafından yakalanan geçmiş verilerinin kullanılması, bakım personelinin arızadan önce buna göre hareket etmesini sağlayan ekipman arızalarının öncüllerinin belirlenmesine yardımcı olur.

Kestirimci bakım sistemleri, arızaların ne zaman meydana gelebileceğini belirleme yeteneğine güvenir. Ekipman OEM'leri genellikle ekipmanları için veri sayfaları sağlar ve mükemmele yakın koşullara dayalı olarak belirli operasyonel ölçümlerin izlenmesini önerir. Ancak varlığın doğal aşınması, içinde çalıştığı çevresel koşullar, geçmişteki bakım geçmişi veya iş sonuçlarınızı elde etmek için onu çalıştırma şekliniz nedeniyle bu koşullar nadiren gerçekçidir. Örneğin, bu kavram kanıtı için aynı karusele iki özdeş motor (marka, model, üretim tarihi) yerleştirildi. Bu motorlar, farklı hava koşullarına maruz kalma nedeniyle farklı sıcaklık aralıklarında çalıştı (konveyör bandının bir kısmı havaalanı terminalinin içinde ve diğer kısmı dışında).

Motor 1, 32–35°C aralığında bir sıcaklıkta çalıştırıldı. Titreşim hızı RMS, motor yorgunluğu nedeniyle değişebilir (örneğin, hizalama hataları veya dengesizlik sorunları). Aşağıdaki şekilde gösterildiği gibi, bu motor 2'da bazı tepe noktaları ile 6-9 arasında değişen yorgunluk seviyeleri gösterir.

Motor 2, sıcaklığın 20–25°C arasında değiştiği daha soğuk bir ortamda çalıştırılmıştır. Bu bağlamda, motor 2, 4'da bazı zirveler ile 8-10 arasında yorgunluk seviyeleri gösterir:

Çoğu makine öğrenimi yaklaşımı, her bir varlığı çalıştırma ve bakımını yapma şeklinizden (örneğin, arıza bozulma modelleri) çıkarılması gereken çok özel alan bilgisi ve bilgileri (elde edilmesi genellikle zor) bekler. Bu çalışmanın, yeni bir varlığı her izlemek istediğinizde veya varlık koşulları önemli ölçüde değiştiğinde (bir parçayı değiştirdiğinizde olduğu gibi) gerçekleştirilmesi gerekir. Bu, prototip oluşturma aşamasında teslim edilen harika bir modelin, diğer varlıklar üzerinde kullanıma sunulduğunda büyük olasılıkla bir performans düşüşü göreceği, sistemin doğruluğunu büyük ölçüde azaltacağı ve sonunda son kullanıcıların güvenini kaybedeceği anlamına gelir. Bu aynı zamanda birçok yanlış pozitife neden olabilir ve tüm gürültüde geçerli sinyallerinizi bulmak için gerekli becerilere ihtiyacınız olacaktır.

Lookout for Equipment, sinyalleriniz arasındaki normal ilişkileri öğrenmek için yalnızca zaman serisi verilerinizi analiz eder. Ardından, bu ilişkiler normal çalışma koşullarından (eğitim durumunda yakalanan) sapmaya başladığında, hizmet anormalliği işaretleyecektir. Her varlık için geçmiş verileri kesin olarak kullanmanın, belirli bir varlığa tam da içinde çalıştığı ortamda benzersiz olacak çalışma koşullarını öğrenebilen teknolojilere odaklanmanıza olanak tanıdığını bulduk. Bu, kök neden analizi ve kestirimci bakım uygulamalarını destekleyen tahminler sunmanıza olanak tanır. ayrıntılı, varlık başına düzeyde ve makro düzeyde (aynı anda birden çok varlığa genel bir bakış elde etmenizi sağlamak için uygun panoyu bir araya getirerek). Benimsediğimiz yaklaşım ve Lookout for Equipment'ı kullanmaya karar vermemizin nedeni budur.

Antrenman stratejisi: Soğuk başlatma zorluğunun ele alınması

Hedeflediğimiz BHS ilk başta enstrümantal değildi. Sistemimizden yeni ölçümler toplamaya başlamak için CloudRail sensörleri kurduk, ancak bu, makine öğrenimi modelimizi eğitmek için yalnızca sınırlı bir tarihsel derinliğe sahip olduğumuz anlamına geliyordu. Sürekli gelişen bir sistem oluşturduğumuzun farkına vararak bu durumda soğuk başlatma sorununu ele aldık. Sensörler kurulduktan sonra, bir saatlik veri topladık ve bu bilgileri, Lookout for Equipment'ı mümkün olan en kısa sürede kullanmaya başlamak ve genel boru hattımızı test etmek için çoğalttık.

Beklendiği gibi, makine öğrenimi modeli çok kısa bir işlem süresine maruz kaldığı için ilk sonuçlar oldukça istikrarsızdı. Bu, ilk saat içinde görülmeyen herhangi bir yeni davranışın işaretleneceği anlamına geliyordu. En üst düzey sensörlere bakıldığında, motorlardan birindeki sıcaklık ana şüpheli gibi görünüyordu (T2_MUC_ES_MTRL_TMP aşağıdaki şekilde turuncu renkte). İlk veri yakalama çok dar olduğundan (1 saat), gün boyunca ana değişiklik sıcaklık değerlerinden geliyordu (o andaki çevre koşullarıyla tutarlıydı).

Bunu, bu özel taşıma bandının etrafındaki ortam koşullarıyla eşleştirirken, dış sıcaklığın ciddi şekilde arttığını ve bunun da bu sensör tarafından ölçülen sıcaklığı artırdığını doğruladık. Bu durumda, yeni veriler (dış sıcaklık artışını hesaba katan) eğitim veri setine dahil edildikten sonra, Lookout for Equipment tarafından yakalandığı şekliyle normal davranışın bir parçası olacak ve gelecekte benzer davranışların herhangi bir artışı artırma olasılığı daha düşük olacaktır. olaylar.

5 gün sonra model yeniden eğitildi ve yanlış pozitif oranları hemen büyük ölçüde düştü:

Bu soğuk başlatma sorunu, eyleme geçirilebilir içgörüler elde etmek için ilk zorluk olsa da, bu fırsatı son kullanıcının kolayca tetikleyebileceği bir yeniden eğitim mekanizması oluşturmak için kullandık. Deneyin bir ayında, bir aylık sensör verilerini 3 aya kopyalayarak yeni bir model eğittik. Bu, model daha geniş bir dizi koşula maruz kaldığından yanlış pozitif oranları azaltmaya devam etti. Bu yeniden eğitimden sonra benzer bir yanlış pozitif oranında düşüş yaşandı: sistem tarafından modellenen durum, kullanıcıların gerçek hayatta yaşadıklarına daha yakındı. 3 ay sonra nihayet bu çoğaltma hilesini kullanmadan kullanabileceğimiz bir veri setimiz oldu.

Bundan sonra, her 3 ayda bir yeniden eğitim başlatacağız ve mümkün olan en kısa sürede, çevresel durumun mevsimselliğini hesaba katmak için 1 yıla kadar olan verileri kullanacağız. Bu sistemi diğer varlıklara dağıtırken, bu otomatikleştirilmiş süreci yeniden kullanabileceğiz ve sensör veri işlem hattımızı doğrulamak için ilk eğitimi kullanabileceğiz.

Model eğitildikten sonra modeli dağıttık ve Lookout for Equipment'a canlı veriler göndermeye başladık. Lookout for Equipment, eğitilen modele yeni veriler göndermek ve sonuçları toplamak için düzenli olarak (örneğin her saat) uyanan bir zamanlayıcı yapılandırmanıza olanak tanır.

Artık bir modeli nasıl eğiteceğimizi, iyileştireceğimizi ve dağıtacağımızı bildiğimize göre, son kullanıcılar için uygulanan operasyonel panolara bakalım.

Veri görselleştirme ve öngörüler

Son kullanıcıların, varlık kullanımlarını daha iyi hale getirmek için operasyonel verilerinden daha fazla değer elde etmenin bir yoluna ihtiyacı vardır. QuickSight ile panoyu IoT sistemimiz tarafından sağlanan ham ölçüm verilerine bağlayarak kullanıcıların belirli bir BHS'deki önemli ekipman parçalarını karşılaştırmasına ve karşılaştırmasına olanak sağladık.

Aşağıdaki panoda, kullanıcılar BHS'nin durumunu izlemek ve dönemsel metrik değişikliklerini elde etmek için kullanılan temel sensörleri kontrol edebilir.

Önceki grafikte, kullanıcılar her motor için ölçümdeki beklenmeyen dengesizlikleri görselleştirebilir (sıcaklık, yorulma, titreşim, sürtünme ve darbe için sol ve sağ grafikler). En altta, temel performans göstergeleri özetlenir, tahmin ve dönemsel dönem eğilimleri belirtilir.

Son kullanıcılar aşağıdaki amaçlarla bilgilere erişebilir:

• 2 saatten 24 saate kadar olan aralıklarla geçmiş verileri görüntüleyin.
• Harici entegrasyon için ham verileri CSV formatıyla çıkarın.
• Belirli bir süre boyunca varlık performansını görselleştirin.
• Operasyonel planlama için öngörüler üretin ve varlık kullanımını iyileştirin.
• Korelasyon analizi yapın. Aşağıdaki çizimde, kullanıcı çeşitli ölçümleri (motor yorgunluğuna karşı sıcaklık veya bagaj çıkışına karşı karusel hızı gibi) görselleştirebilir ve bir sonraki en iyi bakım eylemini daha iyi bilgilendirmek için bu panoyu kullanabilir.

Verilerdeki gürültüyü ortadan kaldırmak

Birkaç hafta sonra, Lookout for Equipment'ın yanlış pozitif olduğu düşünülen bazı olaylar yaydığını fark ettik.

Bu olayları analiz ederken, atlıkarınca motorunun hızında düzensiz düşüşler keşfettik.

Bakım ekibiyle görüştük ve bize bu duraklamaların ya acil durdurmalar ya da planlı duruş bakım faaliyetleri olduğunu söylediler. Bu bilgilerle, acil durdurmaları anormallik olarak etiketledik ve bunları Lookout for Equipment'a ilettik, planlı duruş süreleri ise bu döngü için normal davranış olarak kabul edildi.

Anormal verilerin kontrollü dış eylemlerden etkilenebileceği bu tür senaryoları anlamak, zaman içinde anormallik algılama modelinin doğruluğunu iyileştirmek için kritik öneme sahiptir.

Duman testi

Modeli yeniden eğittikten ve nispeten hiçbir anormallik elde ettikten birkaç saat sonra ekibimiz varlıkları fiziksel olarak vurguladı ve sistem tarafından anında tespit edildi. Bu, kullanıcılardan gelen yaygın bir istektir çünkü kendilerini sisteme ve sistemin nasıl tepki verdiğine alıştırmaları gerekir.

Panomuzu, son kullanıcıların tarihsel anormallikleri sınırsız bir süre ile görselleştirmesine olanak sağlayacak şekilde oluşturduk. Bir iş zekası hizmeti kullanmak, verilerini istedikleri gibi düzenlemelerine olanak tanır ve 24 saatlik bir süre boyunca çubuk grafikler veya pasta grafiklerin BHS'nin durumunu iyi bir şekilde görmenin en iyi yolu olduğunu bulduk. Kullanıcıların ihtiyaç duyduklarında görüntüleyebilecekleri panolara ek olarak, belirlenen bir e-posta adresine ve kısa mesajla gönderilen otomatik uyarılar oluşturduk.

Anormallik algılama modellerinden daha derin içgörüler elde etme

Gelecekte, Lookout for Equipment ile eğitilmiş anormallik algılama modellerinden daha derin içgörüler elde etmeyi amaçlıyoruz. Genişletilmiş bir widget seti oluşturmak için QuickSight'ı kullanmaya devam edeceğiz. Örneğin, veri görselleştirme widget'larının Lookout for Equipment için GitHub örnekleri modellerimizin ham çıktılarından daha fazla içgörü elde etmemizi sağlar.

Sonuçlar

Bagaj taşıma sistemlerinde reaktif bakım şu anlama gelir:

• Uzun bekleme süreleri veya hasarlı bagaj nedeniyle daha düşük yolcu memnuniyeti
• Kritik yedek parçaların planlanmamış arızaları ve envanter eksikliği nedeniyle daha düşük varlık kullanılabilirliği
• Daha yüksek bakım maliyetlerine ek olarak artan stok seviyeleri nedeniyle daha yüksek işletme giderleri

Karar verme döngüsüne güvenilir, tahmine dayalı analitiği dahil etmek için bakım stratejinizi geliştirmek, varlık operasyonunu iyileştirmeyi ve zorunlu kapatmalardan kaçınmaya yardımcı olmayı amaçlar.

İzleme ekipmanı 1 günde yerel olarak kuruldu ve IoT uzmanları tarafından tamamen uzaktan yapılandırıldı. Çözüme genel bakışta açıklanan bulut mimarisi daha sonra 90 gün içinde başarıyla devreye alındı. Hızlı uygulama süresi, son kullanıcıya sunulan faydaları kanıtlayarak, bakım stratejisinde hızlı bir şekilde insan tabanlı reaktiften (arızaları düzeltme) makine tabanlı, veri odaklı proaktif (duruş sürelerini önleme) geçişe yol açar.

Sonuç

Airis, CloudRail, Northbay Solutions ve AWS arasındaki iş birliği, King Khalid Uluslararası Havalimanı'nda yeni başarılara yol açtı (bkz. basın açıklaması daha fazla ayrıntı için). Riyad Havalimanı, dijital dönüşüm stratejisinin bir parçası olarak, yolcu biniş köprüleri ve HVAC sistemleri gibi diğer elektro-mekanik sistemleri kapsayacak şekilde daha fazla konuşlandırma planlıyor.

Bu gönderi hakkında yorumlarınız varsa, lütfen bunları yorumlar bölümünde belirtin. Bu çözüm veya uygulaması hakkında sorularınız varsa, lütfen şu adreste yeni bir ileti dizisi başlatın: yeniden:Gönder, AWS uzmanlarının ve daha geniş topluluğun sizi destekleyebileceği yer.

yazarlar hakkında

Moulham Zahabi havacılık projeleri tasarlama ve yönetme ve GCC bölgesindeki kritik havaalanı varlıklarını yönetme konusunda 11 yılı aşkın deneyime sahip bir havacılık uzmanıdır. Ayrıca, havaalanları ve lojistik merkezler için yenilikçi AI/ML çözümleri yoluyla havacılık endüstrisinin dijital dönüşümüne öncülük etmeyi amaçlayan Airis-Solutions.ai'nin kurucu ortaklarından biridir. Bugün Moulham, Suudi Sivil Havacılık Holding Şirketi'nde (Matarat) Varlık Yönetimi Müdürlüğü'nün başında bulunuyor.

Fauzan Han kamu sektörü müşterileriyle çalışan ve AWS iş yüklerini ve mimarilerini tasarlamak, dağıtmak ve yönetmek için rehberlik sağlayan bir Kıdemli Çözüm Mimarıdır. Fauzan, müşterilerin iş zorluklarını ele almak için HPC ve AI/ML alanında yenilikçi bulut teknolojilerini benimsemelerine yardımcı olma konusunda tutkulu. Fauzan, iş dışında doğada vakit geçirmekten hoşlanır.

Michael Hoarau AWS'de, ana bağlı olarak veri bilimcisi ve makine öğrenimi mimarı arasında geçiş yapan bir AI/ML Uzman Çözüm Mimarıdır. AI/ML gücünü endüstriyel müşterilerinin atölyelerine taşıma konusunda tutkulu ve anormallik saptamadan tahmini ürün kalitesine veya üretim optimizasyonuna kadar çok çeşitli makine öğrenimi kullanım durumları üzerinde çalıştı. o yayınladı zaman serisi analizi üzerine bir kitap 2022'de ve düzenli olarak bu konu hakkında yazıyor LinkedIn ve Orta. Müşterilerin bir sonraki en iyi makine öğrenimi deneyimlerini geliştirmelerine yardımcı olmadığı zamanlarda yıldızları gözlemlemekten, seyahat etmekten veya piyano çalmaktan keyif alıyor.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/machine-learning/deploy-a-predictive-maintenance-solution-for-airport-baggage-handling-systems-with-amazon-lookout-for-equipment/