Endüstriyel IoT

IT/OT Yakınsaması: Kültür, Mimari ve Ortak Bir Veri Katmanı

IT OT yakınsaması ağları birleştirmekten çok, birbirinden çok farklı iki ekibe aynı güvenilir veriyi sunmakla ilgilidir. Bu yazı kültürel uçurumu, teknik yapı taşlarını ve MQTT üzerine kurulu pratik bir ortak namespace modelini ele alıyor.

Ortak bir veri katmanıyla birbirine bağlanan IT ofisi ve OT fabrika sahası, IT OT yakınsamasını gösteriyor
Bunu kendi MQTT broker’ınızda çalıştırınFree planla özel, yönetilen bir MQTT broker alın ve hazır kod örnekleriyle başlayın.
Ücretsiz deneyin Kod örnekleri Kart gerekmez

IT OT yakınsaması, bilgi teknolojisini (iş sistemleri, bulut, analitik) ve operasyonel teknolojiyi (PLC'ler, SCADA, makineler) ortak bir temel üzerinde buluşturarak ikisinin de aynı veriyle çalışmasını sağlama sürecidir. Bu yazıda iki dünyanın neden bu kadar farklı geliştiğini, teknik ve kültürel tarafta gerçekte neyin değişmesi gerektiğini ve ortak bir MQTT namespace'inin, iki tarafın önceliklerinden de ödün vermeden IT ve OT ekiplerine tesisin tek bir canlı görünümünü nasıl sunduğunu öğreneceksiniz.

Birbirinden Uzaklaşan İki Dünya

Operasyonel teknoloji fabrika sahasında büyüdü. Görevi, fiziksel bir prosesi her saniye, onlarca yıl boyunca güvenli şekilde çalışır tutmaktır. Bir fırını kontrol eden PLC aynı programı on beş yıl boyunca çalıştırabilir ve bu bir başarı sayılır. Değişiklik risktir; bir kesinti ekipmana zarar verebilir veya insanları yaralayabilir.

Bilgi teknolojisi ise ofiste büyüdü. Görevi, iş bilgisini güvenli ve verimli biçimde işlemektir. Sistemler her ay yamalanır, birkaç yılda bir yenilenir; bir kesinti pahalıdır ama nadiren tehlikelidir. Değişiklik olağandır ve güncel kalmak güvenliğin bir parçasıdır.

Hiçbir bakış açısı yanlış değildir. Her biri, arızanın farklı sonuçlarına göre optimize edilmiştir. Yakınsama projelerindeki sürtüşmenin büyük kısmı, insanların bir dünyanın kurallarını diğerine uygulamasından kaynaklanır.

Boyut IT öncelikleri OT öncelikleri
Birinci kaygı Verinin gizliliği Prosesin erişilebilirliği ve emniyeti
Tipik yaşam döngüsü 3 ila 5 yıl 15 ila 30 yıl
Yama Düzenli, çoğunlukla otomatik Nadir, duruşlara göre planlanır
Protokoller HTTP, SQL, REST, bulut API'leri Modbus, Profinet, OPC UA, üreticiye özel protokoller
Veri biçimi İşlemler, belgeler, kayıtlar Sürekli sinyaller, durumlar, olaylar
Kesinti toleransı Planlı bakım pencereleri Dakika başına üretim kaybıyla ölçülür
Değişikliği kim yapar IT yöneticileri, DevOps Kontrol mühendisleri, entegratörler

IT/OT Yakınsaması Gerçekte Ne Anlama Gelir?

Yakınsama çoğu zaman "PLC'leri kurumsal ağa bağlamak" olarak yanlış anlaşılır. OT mühendislerini tedirgin eden versiyon budur ve haklıdırlar. Doğru yapıldığında IT OT yakınsaması daha dar kapsamlı üç şey demektir:

  1. Ortak veri. Üretim verisi iş sistemlerine güvenilir biçimde akar; siparişler ve reçeteler gibi iş bağlamı da operasyonun erişimine açılır.
  2. Ortak uygulamalar. Güvenlik, kimlik yönetimi, izleme ve değişiklik yönetimi, her tarafın kısıtlarına uyarlanarak tutarlı biçimde uygulanır.
  3. Ortak insanlar. Ekipler birbirlerinin önceliklerini anlar ve entegrasyon katmanının sahipliğini birlikte üstlenir.

Yakınsamanın gerektirmediği şey ise düz bir ağdır. Purdue modeli ve IEC 62443 bölgeleri hâlâ geçerlidir. Entegrasyon tanımlı bir sınırda, genellikle bir endüstriyel DMZ'de gerçekleşir ve tesis ağı segmentli kalır. Purdue modeli ile ISA-95 karşılaştırmamız bu katmanların birbiriyle nasıl ilişkili olduğunu açıklıyor.

Teknik Yapı Taşları

Noktadan noktaya entegrasyonlar yerine olay güdümlü veri

IT'ye OT verisine erişim sağlamanın geleneksel yolu noktadan noktaya entegrasyondur: MES, SCADA'yı sorgular; ERP, historian'ı sorgular; bir raporlama aracı historian'ın yazdığı veritabanını okur. Her bağlantı özeldir, kırılgandır ve onu kim kurduysa ona aittir. Yeni bir tüketici eklemek, yeni bir entegrasyon demektir.

Publish/subscribe mesajlaşma bunu değiştirir. Her OT kaynağı verisini bir kez broker'a yayımlar. Her IT tüketicisi ihtiyaç duyduğu veriye abone olur. OT tarafı kimin dinlediğini bilmek zorunda kalmaz, IT tarafının da tesise bağlantı açmasına gerek olmaz. Broker'ın rolü sizin için yeniyse bir MQTT broker'ın ne yaptığına göz atın.

Ortak dil olarak Unified Namespace

Broker tek başına veriyi anlaşılır kılmaz. Unified Namespace (UNS) yapı katar: her değer, ISA-95 hiyerarşisine dayanan öngörülebilir bir topic'te yaşar; örneğin connectmq/acme/plant1/assembly/line2/press04/state. OT mühendisi fiziksel konumu tanır. IT geliştiricisi kararlı, belgelenmiş bir API görür. İkisi de aynı topic'i okur. Unified Namespace nasıl kurulur rehberimiz tasarımı adım adım anlatıyor.

Yalnızca dışa doğru bağlantı

OT gateway'leri broker'a TLS üzerinden dışarı doğru bağlanır; IT tüketicileri de dışarı doğru bağlanır. Tesise hiçbir gelen port açılmaz. OT güvenlik ekibinin desteğini kazanmak için en önemli özellik budur. Bu model endüstriyel DMZ'de MQTT yazımızda ayrıntılı olarak ele alınıyor.

Veri katmanının net sahipliği

Topic adlandırma kurallarının, payload kurallarının, erişim kimlik bilgilerinin ve veri kalitesinin bir sahibi olmalıdır. Olgun kuruluşlarda bu, IT ile OT arasında konumlanan bir endüstriyel DataOps işlevine dönüşür. Daha fazlası için endüstriyel DataOps genel bakışımızı okuyun.

Örnek: İki Ekibin Aynı Canlı Veriyi Okuması

Yakınsamanın pratikte nasıl göründüğü şöyle: Bir OT gateway'i makine durumunu retained message olarak UNS'e yayımlar. Bir IT geliştiricisi, PLC'ye veya gateway'e hiç dokunmadan bu durumu bir iş uygulamasına aktarmak için birkaç satır Python yazar.

Önce public broker'da deneyin. "OT tarafı" olarak retained bir durum yayımlayın:

mosquitto_pub -h broker.connectmq.com -p 1883 -i ot-sim-$RANDOM -r \
  -t connectmq/demo/itot42/plant1/assembly/line2/press04/state \
  -m '{"state":"RUNNING","order":"WO-1182","ts":"2026-10-16T09:12:00Z"}'

Ardından "IT tarafı" abonesini çalıştırın:

import json
import uuid
import paho.mqtt.client as mqtt

TOPIC = "connectmq/demo/itot42/plant1/+/+/+/state"

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(TOPIC, qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    area, line, machine = parts[4], parts[5], parts[6]
    data = json.loads(msg.payload)
    # Bir iş sistemine aktarın; burada yalnızca bir satır yazdırıyoruz
    print(f"{area:10} {line:6} {machine:8} {data['state']:8} order={data.get('order')}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"it-app-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Abone, bağlanır bağlanmaz retained durumu alır, ardından her değişikliği gerçekleştiği anda alır. OT mühendisi aynı topic'te bir masaüstü MQTT explorer açıp tam olarak aynı mesajı görebilir. Yakınsamanın gündelik hâli bu ortak görünümdür. Üretimde her iki taraf da broker'ın 8883 portunda kendi kimlik bilgilerini kullanır ve gerçek tesis verisi, herkesin okuyabildiği public bir alana asla gönderilmez.

Yakınsamayı Kalıcı Kılan Kültürel Adımlar

Teknoloji işin kolay yarısıdır. Şu uygulamalar insan tarafına yardımcı olur:

  1. Bir OT problemiyle başlayın. Tesisin önemsediği bir kullanım senaryosu seçin; örneğin darboğaz makinesindeki plansız duruşlar. Yalnızca raporlamaya hizmet eden, IT güdümlü projeler nadiren OT desteği alır.
  2. Edge'in sahipliğini OT'ye bırakın. Hangi PLC'den neyin, hangi hızda ve hangi modda okunacağına kontrol mühendisleri karar verir. Tüketicilerin sahibi IT'dir.
  3. Sınırda uzlaşın. OT sorumluluğunun nerede bittiğini (genellikle gateway'in dışa giden bağlantısında) ve IT'ninkinin nerede başladığını yazılı hâle getirin.
  4. Tek bir sözlük kullanın. Topic adlarındaki ISA-95 hiyerarşisi, iki ekibe sahalar, alanlar, hatlar ve makineler için ortak kelimeler sağlar.
  5. İnsanları eşleştirin. Bir IT geliştiricisini ve bir kontrol mühendisini aynı pilot projeye koyun. İki hafta birlikte çalışmak, herhangi bir atölye çalışmasından daha fazlasını sağlar.
  6. Değişiklik pencerelerine saygı gösterin. Gateway güncellemeleri IT'nin yama günlerini değil, OT bakım takvimlerini izler.

Yönetilen Bir Broker Nerede Yardımcı Olur?

Ortak veri katmanı güvenli, sürekli erişilebilir ve bakımlı olmalıdır; bu klasik bir IT işidir. Onu tesis donanımında çalıştırmak bu işi, genellikle istemeyen OT'ye yükler. Yönetilen bir MQTT broker, iki ekibin buluşabileceği tarafsız bir alandır. ConnectMQ ISA-95 ve Unified Namespace topic'lerini otomatik olarak algılar, cihazları ISA-95 seviyesine göre gruplanmış şekilde gösterir, kullanan ekipler için Sparkplug B'yi çözer ve hem bir kontrol mühendisinin hem de bir geliştiricinin kullanabileceği canlı bir topic explorer sunar. Katı veri yerleşimi kurallarına sahip kuruluşlar ConnectMQ BYOC'yi kendi bulut hesaplarında çalıştırabilir. Barındırma modellerini daha geniş biçimde karşılaştırmak için bulut MQTT broker rehberimize, endüstriyel resmin tamamı için ise MQTT ile Endüstriyel IoT rehberine bakın.

ConnectMQ'da IT ve OT'ye Tek Bir Namespace Verin

app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun. Bir makinenin durumunu ISA-95 topic ağacına yayımlayın, iki ekibe de birer kimlik bilgisi verin ve konuşmanın birbiriyle yarışan tablolardan değil, ortak veriden başlamasını sağlayın.

Sık Sorulan Sorular

IT OT yakınsaması en basit hâliyle nedir?

İş sistemlerinin ve tesis sistemlerinin, güvenlik ve değişiklik için ortak uygulamalarla aynı veriden çalışmasını sağlamaktır. Ağları birleştirmek veya PLC'lerin kontrolünü IT'ye vermek anlamına gelmez.

IT/OT yakınsaması siber riski artırır mı?

Ağları düzleştirerek yapılırsa artırabilir. Segmentasyon, bir DMZ üzerinden yalnızca dışa doğru bağlantılar ve client başına kimlik bilgileriyle yapıldığında, plansız entegrasyonlara kıyasla genellikle görünürlüğü ve güvenliği artırır.

MQTT, IT/OT yakınsaması için neden popüler?

Client'lar broker'a dışarı doğru bağlanır, dolayısıyla tesise gelen port açmak gerekmez. Publish/subscribe ayrıca birçok IT tüketicisinin ek entegrasyon olmadan aynı OT verisini kullanmasına olanak tanır.

Unified Namespace'in sahibi kim olmalı?

İdeal olarak ortak bir ekip veya bir endüstriyel DataOps işlevi. Edge'den neyin yayımlandığının sahibi OT, tüketicilerin sahibi IT, adlandırma kuralları ve payload standartlarının sahibi ise ortak ekiptir.

İlgili yazılar

CODESYS MQTT Client: PLC Değişkenlerini Bir Broker'a Yayınlama

CODESYS IIoT MQTT Client kütüphanesini PLC değişkenlerini JSON olarak yayınlayacak şekilde yapılandırın, broker.connectmq.com üzerinde doğrulayın, ardından kimlik bilgileri ve TLS içeren özel bir broker'a geçin.

6 dk okuma

Tüm yazılar →

Özel MQTT broker’ınız birkaç tık uzağınızda

Hesabınızı oluşturun, broker kimlik bilgilerinizi alın ve ilk cihazınızı bağlayın — kurulacak, yamalanacak ya da ölçeklendirilecek sunucu yok.