Octatus Ana Platform: Argamos ve Enlogy Entegrasyonu Nasıl Tasarlanır?

Neden Octatus merkezde?

Octatus fiziksel varlıkların BIM, GIS ve dijital ikiz bağlamını birleştiren ana platformdur. Argamos ve Enlogy ise bu platforma entegre uzmanlık ürünleridir; üç eşit portal tasarlamak hedef değildir.

Merkezi kullanıcı deneyimi, bütün veri tabanlarının Octatus'a kopyalanmasını gerektirmez. Kullanıcı fiziksel varlıktan enerji durumuna ve BT servis etkisine ulaşabilmelidir.

Sorumluluk ve kaynak otoritesi

Octatus varlık, mekân ve birleşik görünümü yönetir. Argamos BT keşfi, CMDB, servis bağımlılıkları, ITSM ve SLA süreçlerinin; Enlogy ise enerji telemetrisi, SCADA ve PPC operasyonlarının uzmanlık kaynağıdır.

SCADA/PPC kontrol ve emniyet fonksiyonları Enlogy'nin yetki sınırında kalmalıdır. Octatus kontrolü yeniden uygulamamalıdır.

Kimlik ve olay sözleşmesi

BIM IFC GlobalId, Octatus varlık ID, Argamos CI ID ve Enlogy ölçüm noktası ID eşlemeleri ilişki kaydı, kaynak, kanıt, geçerlilik zamanı ve güven düzeyiyle tutulmalıdır.

Ölçüm, alarm, BT olayı ve servis kesintisi farklı olay türleridir. Kimlik federasyonu, tenant izolasyonu ve denetim izi ayrı kabul edilir.

Pilot kabulü

Seçilmiş varlıkta BIM nesnesinden Enlogy ölçümüne, Argamos CI bağımlılığına ve olay kaydına kadar uçtan uca iz doğrulanmalıdır.

Bu hedef mimaridir; tüm entegrasyonların üretimde tamamlandığına ilişkin iddia değildir.

Sahadan örnek: karar anında hangi bilgi gerekir?

Octatus ekipmanın fiziksel kimliği ve konumunu tutarken Argamos CI/servis, Enlogy ölçüm noktası ve OT durumunun yetkili kaynağıdır. Bir ekranın birleşik olması, tek veri tabanında tüm verilerin kopyalanmasını gerektirmez.

Bir kampüste enerji kesintisi bildirimi geldiğinde Octatus fiziksel trafo ve bina bağlamını gösterebilir; Enlogy enerji olayının kaynak sistemidir, Argamos ise etkilenebilecek BT servislerinin bağımlılıklarını yönetebilir. Üç ayrı kimlik alanı arasında doğrulanmış ilişki kurulmadıkça 'etkilenen servisler' listesi kesin sonuç olarak sunulmamalıdır.

Uygulama ve kabul kontrolü

API ve olay sözleşmelerinde kaynak kimliği, tenant, zaman damgası, ölçü birimi, veri kalitesi, sürüm ve geri alma davranışı tanımlanmalıdır.

Pilot olarak bir enerji fideri, bir bina ve sınırlı sayıda BT servisi seçilir. Enlogy olay kimliği, Octatus fiziksel varlık kimliği ve Argamos servis kimliği için örnek eşleme tablosu hazırlanır. Olay gecikmesi, eksik servis bağımlılığı ve yanlış fider bağlantısı ayrı test edilir. Kaynak sistemlerin kontrol yetkileri değiştirilmez.

Yatırım ve kapsam kararı nasıl verilir?

Üç ürünün entegrasyonunda en maliyetli hata bütün veri akışlarını ilk fazda zorunlu kabul etmektir. Önce tek bir enerji olayının fiziksel trafoya ve doğrulanmış BT servisine bağlandığı dar senaryo seçilir. Octatus varlık bağlamını, Enlogy enerji olayını ve Argamos servis bağımlılığını ayrı kaynaklarda tutar. Pilot kimlik eşlemesi ve gecikme hedeflerini karşılamıyorsa yeni konektör sayısını artırmak yerine veri sözleşmesi düzeltilmelidir.

Bu mimaride yatırım önceliği üç ürünü aynı anda bütün özellikleriyle devreye almak olmamalıdır. Önce fiziksel varlık grafı ve iki sistem arasında gerçekten gerekli sorgu akışı belirlenir. İkinci fazda yalnızca doğrulanmış BT servis ilişkileri eklenebilir. Veri kalitesi düşükken kapsamı büyütmek yanlış etki analizini ölçeklendirir.

Entegrasyon Mimarisi: teknik veri modeli ve tasarım kararları

Octatus fiziksel BIM/GIS bağlamını; Argamos CI/ITSM'yi; Enlogy enerji/OT'yi; Velocize mühendislik gereksinim ve kabul kanıtını yetkili kaynak olarak korur.

Federasyon yaklaşımında her uzman sistem kendi kayıtlarının otoritesini korur. Octatus fiziksel kimlik ve mekânsal ilişkileri, Enlogy enerji telemetrisi ve olayları, Argamos BT varlıkları ve servis bağımlılıklarını yönetir. API sözleşmelerinde kaynak kimliği, geçerlilik zamanı, veri kalitesi ve erişim yetkisi açıkça belirtilir. Aynı nesneye benzeyen kayıtlar otomatik birleştirilmez.

Entegrasyon Mimarisi: standartlar ve birlikte çalışabilirlik sınırları

IFC GlobalId, Octatus asset ID, Argamos CI ID, Enlogy point ID ve Velocize engineering item ID farklıdır; güven düzeyi ve geçerlilik zamanıyla eşleyin.

Entegrasyon tasarımında yalnızca REST veya MQTT kullanmak yeterli mimari karar değildir. Kimlik doğrulama, ağ sınırı, veri saklama, hata tekrarları ve şema sürümü her bağlantı için tanımlanır. Kaynak ürünün belirli bir API veya konektörü sunduğu, ilgili sürümde doğrulanmadan ilan edilmemelidir. Teknik şartname protokol adından çok gerekli veri sözleşmesini ve kabul testini tanımlar.

Entegrasyon Mimarisi: gerçek işletme senaryosu ve hata türleri

Olay sözleşmesinde tenant, kaynak, şema sürümü, zaman, birim, kalite ve idempotency anahtarı bulunsun. Yanlış eşlemeyi karantinaya alın.

Örnek hatada Enlogy fider olayı doğru gelir fakat Octatus içindeki trafo ilişkisi eski model sürümünden kalmıştır. Argamos servis grafı da son ağ değişikliğini içermiyorsa etki sonucu eksik olabilir. Testte yanlış bağlantı, zaman uyumsuzluğu ve yetki reddi ayrı gözlenir. Bilinmeyen etki 'etkilenmedi' olarak gösterilmez.

Entegrasyon Mimarisi: pilot uygulama ve kabul kriterleri

Enlogy SCADA/PPC güvenlik sınırını koruyun. UPS alarmı → fiziksel varlık → CI/servis olası etkisi senaryosunu kaynak kesintisi ve yanlış eşleme testleriyle doğrulayın.

Pilot kabulünde bir enerji olayının fiziksel varlığa ve doğrulanmış BT servisine kadar izlenebilirliği sınanır. Her adımın kaynak kaydı ve zaman damgası bulunmalıdır. Yetkisiz kullanıcının BT servis ayrıntılarını Octatus üzerinden görmemesi test edilir. Kontrol komutlarının uzman enerji sisteminde kalması ayrıca doğrulanır.

Entegrasyon Mimarisi: maliyet, ölçekleme ve yönetişim

Toplam maliyet hesabında üç ürünün lisansları veya işletme maliyetleri ayrı değerlendirilir; entegrasyon adaptörü, kimlik eşleme, güvenlik incelemesi ve sürüm yükseltme testleri eklenir. Tek ekran vaadiyle kaynak sistemlerin bakım maliyetini yok saymak doğru değildir. Veri otoritesini koruyan federasyon bazı senaryolarda kopyalama maliyetini azaltabilir.

Yaygınlaştırma için ilk kampüs pilotundaki doğrulanmış ilişki türleri ve hata davranışları referans alınır. Yeni tesis eklendiğinde fider topolojisi, BT servis envanteri ve kullanıcı yetkileri yeniden sınanır. Üç ürünün birlikte gösterildiği bir demo, tüm konektörlerin üretimde hazır olduğu anlamına gelmez; entegrasyon durumu sürüm bazında raporlanır.

Federatif mimari neden tek veri tabanından farklıdır?

BIM/GIS, enerji/OT, BT servis yönetimi ve mühendislik yaşam döngüsü farklı veri türleri ve farklı otorite sınırları taşır. Bütün bilgiyi tek veri tabanına kopyalamak ilk bakışta kolay görünebilir; fakat güncellik, erişim yetkisi, revizyon ve sorumluluk sorunları yaratabilir. Federatif yaklaşımda kaynak sistemler yetkili kayıtlarını korur; Octatus fiziksel varlık ve mekânsal bağlam üzerinden bağlantı ve birleşik görünüm sağlayabilir.

Örneğin Enlogy'nin bir enerji ölçümünü, Argamos'un servis bağımlılığını ve Velocize'ın mühendislik onayını aynı şemaya zorla dönüştürmek yerine kaynak kimliği, ilişki türü, zaman ve veri kalitesi korunmalıdır. Birleşik görünüm, tek kontrol otoritesi anlamına gelmez. Mimari tasarımda hangi veri nerede üretilir, kim günceller, kim yalnızca okur soruları açıkça yanıtlanmalıdır.

Alan sınırları ve veri sahipliği matrisi

Octatus fiziksel varlık, BIM/GIS geometri ve mekânsal ilişkilerin bağlam katmanında konumlanır. Argamos BT CI/CMDB, keşif, izleme, servis ve SLA kayıtlarında; Enlogy enerji/OT telemetri ve ilgili operasyonlarda; Velocize gereksinim, tasarım revizyonu, doğrulama ve mühendislik onaylarında uzman sistem rolünü korur. Bu alanların sınırı müşteri mimarisine göre somutlaştırılmalıdır.

Örnek veri sahipliği tablosunda 'UPS konumu' için Octatus veya yetkili fiziksel envanter, 'UPS çıkış gücü' için Enlogy, 'UPS'e bağlı BT servisleri' için Argamos, 'UPS kapasite gereksinimi' için Velocize kaynak olarak gösterilebilir. Aynı alanın iki sistemde farklı değeri varsa sessiz üzerine yazma yerine uyuşmazlık kaydı ve onay süreci gerekir. Kaynak sistemin yetkisi sözleşmeyle tanımlanmalıdır.

Kimlik eşleme grafı ve ilişki semantiği

Bir UPS'in IFC GlobalId'si, Octatus asset ID'si, Argamos CI ID'si, Enlogy point ID'si ve Velocize engineering item ID'si birbirinden farklıdır. Bu kimlikleri isim benzerliği veya IP adresi üzerinden otomatik eşitlemek yanlış bağlantı üretebilir. Eşleme kaydı kaynak sistem, kaynak kimlik, hedef kimlik, ilişki türü, doğrulama kaynağı, güven düzeyi ve geçerlilik zamanı içermelidir.

İlişki türleri de açık tanımlanmalıdır: located_in mekânsal konumu, powered_by elektrik beslemesini, monitors ölçüm bağlantısını, depends_on servis bağımlılığını, verified_by test kanıtını ifade edebilir. Aynı iki varlık arasında birden fazla ilişki bulunabilir. İlişkinin yönü ve geçerliliği önemlidir. Kaynak sistem yeniden keşif yaptığında onaylı bağlantılar sessizce değiştirilmemeli, belirsizlikler inceleme kuyruğuna alınmalıdır.

API sözleşmesi, sürümleme ve hata modeli

Sistemler arası API yalnızca URL ve JSON alanlarından oluşmaz. Kimlik doğrulama, tenant sınırı, şema sürümü, zaman biçimi, sayfalama, filtreleme, idempotency, hata kodları ve geriye dönük uyumluluk sözleşmenin parçasıdır. OpenAPI gibi makine tarafından okunabilir sözleşmeler istemci üretimi ve test otomasyonu için yararlı olabilir. Ancak doküman ile gerçek çalışma davranışı sözleşme testleriyle karşılaştırılmalıdır.

Örneğin bir varlık sorgusu yanlış tenant kimliğiyle geldiğinde veri sızdırmamalı; bilinmeyen asset ID için tanımlı hata üretmeli; tekrar gönderilen güncelleme aynı sonucu korumalıdır. API sürümü değiştiğinde eski istemcilerin hangi süre destekleneceği belirlenmelidir. Hata mesajları kullanıcıya anlaşılır olmalı, fakat iç ağ ayrıntıları veya gizli anahtarları açığa çıkarmamalıdır.

Olay akışı ve zaman semantiği

Telemetri ve alarm olayları farklı zaman davranışlarına sahiptir. Ölçümün saha zamanı, merkezi sisteme geliş zamanı ve işlendiği zaman aynı olmayabilir. Olaylar tekrar gelebilir veya sıra dışı teslim edilebilir. Entegrasyon sözleşmesinde event ID, kaynak, tenant, point/asset referansı, ölçüm birimi, kalite durumu, şema sürümü ve idempotency anahtarı değerlendirilmelidir.

Bir Enlogy point offline olayı, fiziksel ekipmanın arızalı olduğunu otomatik kanıtlamaz. Ağ kesintisi, cihaz kapanması veya veri kaynağı problemi farklı durumlardır. Octatus üzerinde varlık durumunu gösterirken gözlem ve çıkarım ayrı etiketlenmelidir. Argamos servis etkisi analizi de yedeklilik ve gerçek bağlantı ilişkileri doğrulanmadan kesin kesinti olarak sunulmamalıdır.

İçe alma, normalizasyon ve karantina

Kaynak sistemden gelen kayıt önce şema ve erişim kontrollerinden geçmeli, ardından kimlik eşleme ve veri kalitesi denetimi yapılmalıdır. Bilinmeyen birim, eksik tenant, mükerrer olay veya belirsiz varlık eşlemesi bulunan kayıtlar sessizce yanlış varlığa bağlanmamalıdır. Karantina kuyruğu, yeniden deneme politikası ve operatör inceleme ekranı tasarımda yer almalıdır.

Örneğin iki farklı tesisin aynı 'P-101' ekipman kodunu kullanması mümkündür. Tenant ve tesis bağlamı olmadan yapılan eşleme veri karışmasına yol açabilir. Kaynak sistemin tekrar gönderdiği olay idempotent işlenmeli; başarısız aktarım denetim izine alınmalıdır. Veri normalizasyonu sırasında orijinal ham kayıt referansı korunursa uyuşmazlık incelemesi kolaylaşır.

OT ile IT ağ segmentasyonu ve kontrol yetkisi

OT sistemleri saha kontrolü ve emniyet açısından farklı güvenlik gereksinimlerine sahiptir. Octatus'un birleşik arayüz sunması Enlogy SCADA/PPC kontrol yolunu devralması anlamına gelmez. Kontrol komutları, interlock, anahtarlama ve emniyet kritik işlemler yetkili OT katmanında kalmalıdır. Veri toplama için salt okunur arayüzler ve uygun ağ segmentasyonu tercih edilebilir.

Kurumsal BT, OT ve dış kullanıcı ağları arasında kimlik doğrulama, servis hesapları, mTLS, en az ayrıcalık ve denetim kontrolleri tasarlanmalıdır. Kapalı ağ gereksiniminde harita, lisans, güncelleme, destek ve hata raporlama dahil tüm dış bağımlılıklar gözden geçirilmelidir. Bir bağlantının teknik olarak mümkün olması, güvenlik değerlendirmesi olmadan üretimde açılabileceği anlamına gelmez.

Argamos ile BT servis bağımlılığı

Argamos BT envanteri, konfigürasyon öğeleri, keşif ve servis bağımlılıklarını yönetebilir. Octatus ise bu CI'ların bulunduğu bina, oda, rack veya fiziksel besleme ilişkilerini gösterebilir. Örneğin bir sunucu cluster'ının hangi odada bulunduğu ile hangi uygulama servislerini desteklediği farklı bilgi kaynaklarından gelir. Bu bilgilerin birleşmesi olay etki analizini zenginleştirebilir.

Ancak CI keşif kayıtları değişken olabilir: sanal makineler taşınabilir, IP adresleri değişebilir ve geçici iş yükleri oluşabilir. Fiziksel varlık ile mantıksal CI arasında bire bir ilişki varsayılmamalıdır. Servis bağımlılığı doğrulama zamanı ve güven düzeyi tutulmalıdır. Operatöre olası etki ile doğrulanmış kesinti ayrı gösterilmelidir.

Enlogy ile enerji ve OT bağlamı

Enlogy enerji üretim, ölçüm ve operasyon süreçlerinden veri sağlayabilir. Octatus bu verileri fiziksel tesis, ekipman ve mekânsal model üzerinde bağlamsallaştırabilir. Bir inverter alarmının hangi sahada, hangi trafoda ve hangi ekipmanla ilişkili olduğunu göstermek bakım koordinasyonunu kolaylaştırabilir. Ancak gerçek enerji akışı, ölçüm kalitesi ve kontrol yetkisi uzman OT sisteminde kalmalıdır.

Bir saha cihazının iletişimi kesildiğinde son geçerli ölçüm güncelmiş gibi gösterilmemelidir. Point ID ile fiziksel asset ID eşlemesi kontrol edilmelidir. Aynı tesisin farklı logger veya ölçüm kaynaklarından gelen verileri birim ve zaman bakımından normalize edilmelidir. Enerji kontrol komutlarının Octatus üzerinden kontrolsüz yürütülmesi tasarım hedefi olmamalıdır.

Velocize ile mühendislik digital thread

Velocize gereksinim, disiplinler arası mühendislik, değişiklik ve konfigürasyon yönetimi ile doğrulama kanıtlarını izleyebilir. Octatus fiziksel varlık kaydıyla bu mühendislik öğeleri arasında kontrollü bağlantı kurabilir. Böylece bir cihazın yalnızca güncel konumu değil, hangi gereksinim ve tasarım kararına bağlı olduğu da incelenebilir. Bu bağlam özellikle büyük sermaye projelerinde revizyon ve kabul süreçlerini destekler.

Örneğin bir UPS'in kapasitesi tasarım değişikliğiyle artırılmış olabilir. Mühendislik onayının tamamlanması sahadaki fiziksel değişikliğin gerçekleştiği anlamına gelmez. Gereksinim baseline'ı, tasarım revizyonu, satın alma, montaj ve SAT kabulü ayrı olaylar olarak tutulmalıdır. Yetkili onay akışı Velocize içinde kalırken Octatus ilişkili varlık görünümünü sağlayabilir.

UPS alarmından olası servis etkisine uçtan uca örnek

Enlogy yetkili kaynaktan UPS alarmı üretir ve olay kaynak kimliği ile zaman damgasını taşır. Octatus eşleme katmanı alarmı doğru fiziksel UPS'e bağlar; bina, oda ve besleme ilişkilerini gösterir. Argamos UPS'e bağımlı olabilecek rack, sunucu ve uygulama servislerini listeler. Velocize ilgili tasarım gereksinimi ve kabul testine bağlantı sağlayabilir.

Bu zincirde kullanıcıya 'kesin servis kesintisi' demek için ek doğrulama gerekir. Yedekli UPS, transfer anahtarı veya farklı besleme hattı servisi ayakta tutabilir. Alarmın kalitesi, gerçek bağlantı topolojisi ve güncel durum kontrol edilmelidir. Operatörün hangi kanıta dayanarak karar verdiği kayıt altına alınmalıdır. Böylece entegrasyon gösterişli bir pano yerine denetlenebilir iş kararı üretir.

Fazlı uygulama, kabul ve maliyet

İlk faz veri sahipliği, sistem sürümleri, erişim sınırları ve üç kritik kullanım senaryosunun keşfidir. İkinci faz kimlik eşleme ve salt okunur varlık ilişkilerini kurar. Üçüncü faz ölçüm, alarm ve servis bağımlılıklarını bağlar. Dördüncü faz doğrulanmış etki analizi ve iş akışlarını değerlendirir. Kontrol otomasyonu ancak ayrı risk analizi ve yetkilendirme sonrasında ele alınmalıdır.

Kabul testlerinde tenant izolasyonu, yanlış eşleme, tekrarlanan olay, gecikmiş veri, kaynak kesintisi, API sürüm uyumsuzluğu ve geri alma davranışı sınanmalıdır. Toplam maliyet adaptör geliştirme, veri temizliği, saha doğrulaması, güvenlik, eğitim ve sürekli bakım kalemlerini içermelidir. Başarı yalnızca bağlantı sayısı değil, doğru varlık eşleme oranı ve operatör karar süresi gibi göstergelerle ölçülmelidir.

Entegrasyon gözlemlenebilirliği ve operasyon desteği

Dağıtık entegrasyonda bir API'nin cevap vermesi veri zincirinin doğru çalıştığını garanti etmez. Kaynak gecikmesi, kimlik eşleme başarısızlığı, şema hatası, karantina kuyruğu büyümesi ve son başarılı senkronizasyon zamanı izlenmelidir. Her adaptör için sağlık göstergesi, hata sınıfları, yeniden deneme politikası ve sorumlu operasyon ekibi tanımlanmalıdır.

Bir UPS alarmı Octatus üzerinde görünmüyorsa sorun kaynak sistemde, ağ geçidinde, kimlik eşlemede veya kullanıcı yetkisinde olabilir. Korelasyon kimliği ve denetim izleri bu zincirin incelenmesini kolaylaştırır. Operatör ekranı yalnızca son hata mesajını değil, etkilenen kayıt sayısını ve çözüm adımını da gösterebilmelidir.

Kurumsal satın alma ve mimari karar kayıtları

Müşteri birden fazla ürünü entegre ederken ürün sınırları ve bakım sorumlulukları sözleşmede açık olmalıdır. Hangi adaptörün kim tarafından geliştirileceği, sürüm uyumluluğunun nasıl test edileceği, API değişikliklerinde kimin aksiyon alacağı ve destek SLA'larının nasıl işleyeceği önceden kararlaştırılmalıdır. Birleşik arayüz sunulması tüm sistemlerin aynı tedarikçi tarafından yönetildiği anlamına gelmez.

ADR kayıtları kimlik stratejisi, veri sahipliği, olay sözleşmesi, tenant sınırı, OT güvenlik modeli, saklama süresi ve rollback kararlarını açıklamalıdır. Pilot sonrası genişleme kararında entegrasyonun bakım maliyeti ve kaynak sistemlerin değişim sıklığı değerlendirilmelidir. İş değeri doğrulanmadan çok sayıda adaptörü aynı anda geliştirmek teknik borcu artırabilir.

Yönetim kararı için son doğrulama

Entegrasyon projesi tamamlandı sayılmadan önce her kaynak sistemin veri otoritesi, API sözleşmesi, kimlik eşlemesi, hata ve kesinti davranışı, tenant izolasyonu ve denetim izi test edilmelidir. Mimari sunumun tutarlı olması gerçek saha verisinin doğru bağlandığını tek başına kanıtlamaz.