Kentsel Dijital İkizler için BIM tabanlı bilgi yönetişimi çerçevesi, bir Urban Digital Twin uygulamasında hangi bilginin neden gerekli olduğunu, kim tarafından üretileceğini, hangi ayrıntı düzeyinde teslim edileceğini, nasıl doğrulanacağını ve karar desteğinde kullanılmadan önce nasıl izlenebilir tutulacağını ISO 19650 ilkeleri ile IDM, LIN, IFC ve IDS yapıları üzerinden birbirine bağlayan standart-güdümlü bir bilgi yönetimi yaklaşımıdır. Çalışmanın temel savı, güvenilir dijital ikiz “zekâsının” yalnız gelişmiş sensör, yapay zekâ veya görselleştirme araçlarından değil; uygun, eksiksiz, tutarlı, izlenebilir ve doğrulanmış bilgiden doğabileceğidir.

Çalışma yeni bir BIM, IFC, IDM, LIN veya IDS standardı önermemektedir. Özgün katkı, mevcut standart ve kavramları tek bir Digital Twin odaklı izlenebilirlik zincirinde birleştirmektir. Zincir organizasyonel amaçlardan başlar; Digital Twin kullanım senaryolarına, Organizational Information Requirements (OIR), Asset Information Requirements (AIR), Project Information Requirements (PIR), Exchange Information Requirements (EIR), Information Delivery Manual (IDM), Level of Information Need (LIN) ve son olarak makine tarafından denetlenebilir Information Delivery Specification (IDS) kurallarına ilerler.

Çerçeve, Timișoara kentini kullanan IoT destekli bir kentsel hava-kalitesi Digital Shadow demonstratörüyle açıklanmıştır. Demonstratör; coğrafi bağlam, sınırlı BIM tabanlı varlık bilgileri, hava durumu servisleri, hava-kalitesi API'leri, Unreal Engine tabanlı görselleştirme ve örnek IDS kontrollerini aynı ortamda ilişkilendirmektedir. Ancak sistem doğrulanmış bir atmosferik dağılım modeli, doğrulanmış emisyon envanteri, eğitilmiş tahmin modeli, tam sensör ağı veya fiziksel sisteme otomatik geri besleme içermemektedir.

Bu nedenle demonstratör gerçek ve tam bir operasyonel Urban Digital Twin değildir. Kaynak onu daha doğru biçimde Digital Shadow olarak sınıflandırmaktadır: fiziksel ve harici kaynaklardan dijital ortama veri akışı vardır; fakat dijital ortamdan fiziksel dünyaya otomatik kontrol, kapalı çevrim geri besleme veya otomatik aktüasyon yoktur.

Çalışma ayrıca gelecekte çerçevenin ampirik olarak değerlendirilebilmesi için 11 aday Information Quality Key Performance Indicator (IQ-KPI) tanımlamaktadır. Bunlar bilgi tamlığı, doğrulama başarısı, tutarlılık, metadata mevcudiyeti, güncellik, izlenebilirlik, sensör erişilebilirliği, sensör verisi geçerliliği, bilgi yeniden kullanımı, doğrulama istisnası ve bilgi sorunu çözüm süresini kapsamaktadır. Makaledeki sayısal KPI örneklerinin tamamı sentetiktir; gerçek bir proje performansı veya çerçevenin doğrulanmış başarısı değildir.

Kaynakta iki önemli matematiksel tutarsızlık bulunmaktadır. Formül (10)'un açıklaması 240 kontrolün 8'inin istisna olduğunu söylerken basılı denklem paydada 200 kullanmakta ve %3,3 sonucu vermektedir. Formül (11)'de 14 günlük toplam çözüm süresi 10 soruna bölünerek 1,4 gün sonucu verildiği halde denklemde ayrıca “×100” ifadesi bulunur. Verianla bu kaynak-içi farkları sessizce düzeltmemektedir.

Çalışmanın temel problemi nedir?

Kentsel Dijital İkizler; BIM, GIS, IoT, yapay zekâ, bulut bilişim, sensör ağları ve gerçek zamanlı görselleştirme gibi çok sayıda teknolojiyi aynı sistemde birleştirebilir. Ancak çok veri toplanması, tek başına güvenilir karar üretildiği anlamına gelmez. Aynı şehir hakkında milyarlarca veri noktası bulunabilir; fakat bu verilerin hangi karar için gerekli olduğu, ne kadar güncel olduğu, kaynağının ne olduğu, birbiriyle aynı anlamı taşıyıp taşımadığı ve doğrulama kurallarını karşılayıp karşılamadığı bilinmiyorsa veri hacmi güvenilir “zekâya” dönüşmez.

Çalışmanın çıkış noktası tam olarak budur. Yazarlar birçok Urban Digital Twin girişiminin güçlü 3B görselleştirmeye, sensör entegrasyonuna ve analitik araçlara sahip olmasına rağmen bilgi gereksinimlerinin tanımlanması, sorumlulukların belirlenmesi, semantik tutarlılık, izlenebilirlik ve doğrulama bakımından parçalı kaldığını belirtmektedir.

Bu nedenle araştırma, “hangi teknoloji kullanılmalı?” sorusundan önce “hangi kararın desteklenmesi gerekiyor ve bu karar için hangi bilgiye gerçekten ihtiyaç var?” sorusunu koymaktadır.

BIM burada yalnızca 3B model anlamına mı geliyor?

Hayır. Kaynak ISO 19650 yaklaşımına dayanarak Building Information Modelling'i (BIM) yalnız bina geometrisi üreten bir 3B çizim yöntemi olarak değil, yapılaşmış varlıkların yaşam döngüsü boyunca bilginin oluşturulmasını, paylaşılmasını ve yönetilmesini düzenleyen bir bilgi yönetimi çerçevesi olarak ele almaktadır.

Bu ayrım önemlidir. Bir BIM modeli geometri, malzeme, sistem ilişkileri, ekipman özellikleri, mekânsal yapı ve işletme bilgilerini taşıyabilir. Urban Digital Twin ise bunlara ek olarak fiziksel dünya ile uygun sıklıkta senkronize edilen tarihsel ve güncel verileri, sensör akışlarını ve geleceğe ilişkin analizleri kullanabilir.

Dolayısıyla BIM ile Digital Twin aynı şey değildir. Çalışmada BIM, Digital Twin ekosisteminin güvenilir bilgi omurgasını oluşturan yapılardan biri olarak konumlandırılmaktadır.

Digital Twin ile Digital Shadow arasındaki fark nedir?

Digital Shadow, fiziksel veya harici kaynaklardan dijital ortama otomatik veya yarı otomatik veri akışı bulunan fakat dijital ortamdan fiziksel sisteme otomatik geri besleme ve aktüasyon bulunmayan tek yönlü bağlantılı dijital temsildir; tam Digital Twin ise daha ileri olgunlukta çift yönlü bağlantı, sürekli senkronizasyon ve uygun uygulamalarda fiziksel sisteme geri etki kapasitesi içeren operasyonel sistemdir.

Bu ayrım, çalışmanın en önemli yorum sınırlarından biridir. Makalenin hava-kalitesi uygulamasında bazı canlı veya dış kaynak verileri dijital ortama alınabilse de sistem fiziksel dünyayı otomatik kontrol etmemektedir. Bu nedenle görsel olarak gelişmiş bir şehir modeli oluşturulmuş olması onu tek başına tam Digital Twin yapmaz.

Araştırmanın merkezî önerisi

Çalışmanın tasarım önermesi şu mantığa dayanır: Digital Twin odaklı bilgi ortamının güvenilir analiz ve karar desteği sağlaması, bilgi gereksinimlerinin açık tanımlanması, bilgi değişimlerinin standartlaştırılması, sorumlulukların atanması ve teslim edilen bilginin doğrulanabilir olmasıyla daha olası hale gelir.

Bu önerme çalışmada ampirik olarak kanıtlanmış bir nedensel yasa değildir. Yazarlar bunu çerçevenin geliştirilmesini yönlendiren bir tasarım önermesi olarak kullanmaktadır. Operasyonel projelerde karşılaştırmalı biçimde test edilmesi gelecek çalışma olarak bırakılmıştır.

Araştırma amaçları

Araştırma soruları

Çerçeve nasıl geliştirildi?

Kaynak beş sıralı geliştirme adımı tanımlamaktadır:

1. Problem tanımlama ve literatür incelemesi: parçalı bilgi, birlikte çalışabilirlik sınırlılıkları, belirsiz sorumluluklar, düşük izlenebilirlik ve yetersiz doğrulama gibi tekrar eden Digital Twin problemlerinin belirlenmesi.
2. Standart ve spesifikasyon seçimi: ISO 19650, ISO 29481, ISO 7817, IFC ve IDS'nin yönetişim, süreç, bilgi içeriği, değişim ve kontrol işlevleri için seçilmesi.
3. İşlevsel eşleme: organizasyonel amacın bilgi üretimi ve doğrulamaya çevrilmesi.
4. Çerçeve sentezi: amaç, kullanım senaryosu, gereksinim, bilgi değişimi, LIN, makine tarafından okunabilir kontrol ve kalite geri bildiriminin tek bir sürekli süreçte birleştirilmesi.
5. Açıklayıcı uygulama: hava-kalitesi senaryosu üzerinden örnek OIR, AIR, PIR, EIR, IDM yapıları, izlenebilirlik matrisleri ve IDS kurallarının geliştirilmesi.

Çerçevenin beş tasarım ilkesi

ISO 19650 tabanlı bilgi yönetişimi zinciri nasıl çalışır?

Çalışmanın önerdiği zincirde organizasyon önce hedeflediği kararı ve Digital Twin kullanım senaryosunu tanımlar; bu amaç OIR, AIR, PIR ve EIR bilgi gereksinimlerine çevrilir, IDM bilgi alışverişinin kimler arasında ve nasıl yapılacağını tanımlar, LIN gerekli bilgi miktarı ve ayrıntısını sınırlar, IDS ise teslim edilen model ve varlık bilgilerinin makine tarafından doğrulanabileceği kuralları oluşturur.

OIR nedir?

Organizational Information Requirements (OIR), kurumun stratejik hedeflerini, iş süreçlerini ve kararlarını desteklemek için hangi bilgiye ihtiyaç duyduğunu tanımlar. Çalışmanın hava-kalitesi örneğinde düzenleyici eşiklere yaklaşan kirletici konsantrasyonlarının nerede ve ne zaman oluştuğunu belirlemek veya nüfus maruziyetini değerlendirmek gibi amaçlar OIR düzeyinde ele alınmaktadır.

AIR nedir?

Asset Information Requirements (AIR), bir varlığın işletilmesi, izlenmesi, bakımı ve optimizasyonu için gerekli bilgiyi tanımlar. Hava-kalitesi örneğinde sensörün benzersiz kimliği, coğrafi koordinatı, cihaz tipi, üreticisi, doğruluğu, kalibrasyon aralığı, bakım gereksinimleri, operasyonel durumu ve ölçtüğü parametreler AIR kapsamına girebilir.

PIR nedir?

Project Information Requirements (PIR), sistemin tasarlanması, kurulması, doğrulanması ve sürdürülmesi için proje düzeyinde gereken bilgileri tanımlar. BIM ve GIS modeli, sensör yerleştirme stratejisi, IoT iletişim mimarisi, BIM–GIS–IoT entegrasyonu ve gelecek tahmin modellerinin veri/kalibrasyon ihtiyaçları bu gruptadır.

EIR nedir?

Exchange Information Requirements (EIR), hangi bilginin hangi taraflar veya sistemler arasında değiş tokuş edilmesi gerektiğini tanımlar. Örneğin sensör ölçümlerinin Digital Shadow platformuna aktarılması, meteoroloji servisinden veri alınması, BIM varlık bilgisinin paylaşılması, GIS bağlamının aktarılması ve IDS doğrulama raporlarının iletilmesi EIR örnekleridir.

IDM ne işe yarıyor?

Information Delivery Manual (IDM), yalnız “hangi bilgi lazım?” sorusuna değil, bu bilginin kim tarafından, kime, hangi süreçte, hangi tetikleyiciyle, hangi aşamada ve hangi amaçla aktarılacağını açıklayan operasyonel süreç yapısıdır. Çalışma ISO 29481 yaklaşımını kullanmaktadır.

Yazarlar IDM için süreç haritası, etkileşim haritası, transaction map ve exchange requirements yapılarından yararlanmaktadır. Böylece organizasyonel amaç ile teknik veri transferi arasında izlenebilir bir bağ kurulmaya çalışılır.

LIN neden “daha fazla ayrıntı” demek değildir?

Level of Information Need (LIN), ISO 7817 çerçevesinde bir kullanım senaryosu için gereken kadar bilgi istemeyi amaçlar. “Her şeyi mümkün olan en yüksek ayrıntıda üret” mantığının tersidir.

LIN üç tamamlayıcı bilgi boyutunu ayırır:

• Geometrik bilgi: konum, boyut, topoloji, mekânsal ilişki, biçim.
• Alfanümerik bilgi: özellikler, sınıflandırmalar, performans göstergeleri, operasyon parametreleri ve metadata.
• Dokümantasyon: raporlar, sertifikalar, bakım kayıtları, teknik şartnameler, kalibrasyon belgeleri ve diğer destekleyici kayıtlar.

Bu yaklaşımın amacı iki hatayı aynı anda önlemektir: karar için yetersiz bilgi üretmek ve hiçbir amaç taşımayan gereksiz bilgi üretip bakım yükünü büyütmek.

IDS ne yapıyor?

Information Delivery Specification (IDS), tanımlanmış bazı bilgi gereksinimlerini makine tarafından okunabilen kontrol kurallarına dönüştürür. IDS; zorunlu özellikleri, sınıflandırmaları, veri tiplerini, kabul edilebilir değerleri, ilişkileri ve gerekli belgeleri tanımlayabilir.

Kaynak IDS'yi özellikle model ve varlık bilgisinin beş kalite boyutunu denetlemek için kullanmaktadır:

1. Existence: gerekli bilgi gerçekten var mı?
2. Completeness: zorunlu tüm alan ve belgeler sağlanmış mı?
3. Consistency: sınıflandırma, adlandırma ve iş kuralları tutarlı mı?
4. Correctness: değerler tanımlı kısıtları karşılıyor mu?
5. Traceability: bilgi hangi gereksinimden, değişimden ve sorumlu aktörden geldiğine kadar izlenebiliyor mu?

Önemli sınır: IDS bu çalışmada özellikle IFC tabanlı model ve varlık bilgisinin kontrolüne yöneliktir. Canlı sensör akışındaki zaman damgası, eksik veri, API sürekliliği, ölçüm geçerliliği ve güncellik gibi operasyonel veri kontrolleri tamamlayıcı mekanizmalar gerektirir.

IFC'nin rolü nedir?

Industry Foundation Classes (IFC), yapılaşmış çevre bilgisini yazılım üreticisinden bağımsız ve nesne tabanlı biçimde temsil edebilen açık bilgi değişim şemasıdır. Geometri yanında özellik, sınıflandırma, varlık ilişkileri ve yaşam döngüsü bilgilerini de taşıyabilir.

Çalışmanın yaklaşımında IFC ortak bilgi dili, IDS ise bu dil içinde beklenen bilginin uygun biçimde teslim edilip edilmediğini kontrol eden makine-okunabilir doğrulama katmanıdır.

Birlikte çalışabilirlik yalnız dosya açabilmek midir?

Hayır. Kaynak üç ayrı birlikte çalışabilirlik boyutu tanımlamaktadır:

Örneğin bir IoT sensöründen gelen “22,4” değeri tek başına yeterli değildir. Bu değerin sıcaklık mı, PM2.5 mi olduğu; hangi birimde ölçüldüğü; hangi sensörden geldiği; sensörün hangi binaya/konuma bağlı olduğu; ne zaman ölçüldüğü ve ölçümün doğrulama statüsü bilinmelidir. Semantik bağ korunmadığında değer sistemler arasında aktarılabilir fakat anlamlı bilgiye dönüşmeyebilir.

Sürekli bilgi-kalitesi yönetişimi

Kaynak bilgi kalitesini proje tesliminde bir kez kontrol edilip tamamlanan bir özellik olarak görmemektedir. Digital Twin ortamında sensörler değişebilir, yeni veri kaynakları eklenebilir, model güncellenebilir, işletme hedefleri değişebilir ve eski bilgi geçerliliğini kaybedebilir.

Bilgi tanımı

Organizasyonel hedefler ve DT kullanım senaryoları OIR, AIR, PIR ve EIR yapılarına çevrilir. IDM, LIN ve IDS bu gereksinimleri operasyonel iş akışı, bilgi içeriği ve makine tarafından kontrol edilebilir kurallara dönüştürür.

Bilgi üretimi

Bilgi BIM yazılımlarından, GIS platformlarından, IoT cihazlarından, operasyonel veritabanlarından, bakım sistemlerinden, kurumsal uygulamalardan veya harici veri sağlayıcılarından gelebilir. Kaynakların kalite, güvenilirlik ve güncellenme sıklığı aynı olmadığı için üretim aşamasında yönetişim gereksinimleri önemlidir.

Bilgi doğrulaması

IDS tabanlı otomatik kontroller ve gerektiğinde alan uzmanı incelemeleriyle tamlık, tutarlılık, doğruluk, izlenebilirlik ve iş kurallarına uyum değerlendirilir. Dinamik verilerde zaman damgası bütünlüğü, güncelleme sıklığı, ölçüm belirsizliği, kaynak geçmişi ve operasyon eşikleri gibi özellikler ayrıca önemlidir.

Bilgi tüketimi

Doğrulanmış bilgi; dashboard, simülasyon, yapay zekâ, analitik model veya karar destek sistemlerinde kullanılabilir. Ancak teknik doğrulamadan geçmiş bir veri, değişen karar gereksinimleri nedeniyle yine de işlevsel olarak yetersiz olabilir. Kaynak bu nedenle “fit-for-purpose”, yani amaca uygunluk kavramını merkezde tutmaktadır.

Geri bildirim

Bilgiyi kullanan kişiler, modeller ve sistemler eksik alanları, tekrar eden kalite sorunlarını veya artık yetersiz kalan gereksinimleri belirleyebilir. Bu geri bildirim OIR, AIR, PIR, EIR, IDM, LIN ve IDS yapılarını güncellemek için kullanılmalıdır.

Aday Information Quality KPI'ları

Sentetik KPI örneği neden gerçek sonuç değildir?

Yazarlar 20 izleme varlığı ve varlık başına 10 zorunlu bilgi öğesi varsayan tamamen sentetik bir sensör-onboarding örneği kurmaktadır. Toplam 200 gerekli değer varsayılır. Bu sayılar gerçek Timișoara sensör performansından, gerçek bir BIM tesliminden veya uygulanan bir Digital Twin projesinden ölçülmemiştir.

Formüllerin amacı yalnız gelecekte gerçek veri kullanıldığında göstergelerin nasıl hesaplanabileceğini göstermektir.

Formül (1): Bilgi Tamlık Oranı

\[ ICOR=\frac{184}{200}\times100=92\% \]

200 zorunlu değerin 184'ü mevcut ve sözdizimsel olarak kabul edilebilir varsayılmıştır. Pay mevcut/uygun değer sayısını, payda gerekli toplam değer sayısını gösterir. Sonuç %92'dir. Bu değer sentetik örneğe aittir.

Formül (2): Doğrulama Başarı Oranı

\[ VSR=\frac{216}{240}\times100=90\% \]

240 makine-okunabilir kontrolün 216'sının geçtiği varsayılmıştır. Gösterge, belirlenen kontrollerin ne kadarının başarıyla sağlandığını ölçer.

Formül (3): Bilgi Tutarlılık Oranı

\[ ICSR=\frac{172}{184}\times100=93.5\% \]

184 teslim edilmiş değerin 172'sinin sensör kaydı, varlık modeli ve izleme veritabanı arasında kimlik, sınıflandırma, birim ve değer açısından tutarlı olduğu varsayılmıştır.

Formül (4): Metadata Mevcudiyet Oranı

\[ MAR=\frac{18}{20}\times100=90\% \]

20 varlığın 18'inde gerekli provenance metadata'sının bulunduğu varsayılmıştır. Bu metadata, verinin kaynağı, zamanı, sorumlu kuruluşu veya statüsü gibi bilginin güvenilirliğini değerlendirmeyi mümkün kılan bağlamsal kayıtlardır.

Formül (5): Veri Güncelliği Uyum Oranı

Kaynakta sayısal yapı 17 uygun kayıt / 20 varlık ve sonuç %85 olarak verilmiştir:

\[ DFCR=\frac{17}{20}\times100=85\% \]

Kaynak gösterim notu: PDF'nin basılı Formül (5)'inde çarpma işareti bozuk bir karakter olarak görünmektedir. 17/20 oranı ve %85 sonucu matematiksel olarak “×100” işlemiyle uyumludur. Verianla kaynakta görülen bu tipografik sorunu gizlememektedir.

Formül (6): İzlenebilirlik Kapsamı

\[ TC=\frac{176}{200}\times100=88\% \]

200 gerekli değerin 176'sının gereksinim ID'si, exchange ID'si, nesne ID'si, doğrulama kuralı ID'si ve provenance kaydına kadar izlenebildiği varsayılmıştır.

Formül (7): Sensör Erişilebilirlik Oranı

\[ SAR=\frac{5472}{5760}\times100=95\% \]

20 sensörün 24 saat boyunca her 5 dakikada bir veri göndermesi beklendiğinde kaynak örneği toplam 5760 gözlem beklemektedir. 5472 gözlem alındığı varsayılır ve sentetik erişilebilirlik %95 olur.

Formül (8): Sensör Verisi Geçerlilik Oranı

\[ SDVR=\frac{5280}{5472}\times100=96.5\% \]

5472 alınmış gözlemin 5280'inin eksik değer, birim, izin verilen aralık, zaman damgası ve sensör durumu kontrollerini geçtiği varsayılmıştır.

Formül (9): Bilgi Yeniden Kullanım Oranı

\[ IRR=\frac{14}{20}\times100=70\% \]

20 izleme varlığından 14'üne ait bilginin en az bir sonraki süreç, sistem, analiz veya kararda yeniden kullanıldığı varsayılmaktadır.

Formül (10): Doğrulama İstisna Oranındaki kaynak tutarsızlığı

Kaynak metni 240 doğrulama kontrolünün 8'inin resmen kabul edilmiş istisna olarak kaydedildiğini söylemektedir. Ancak basılı denklem şu yapıda görünür:

\[ VER=\frac{8}{200}\times100=3.3\% \]

Bu satır kendi içinde matematiksel olarak tutarlı değildir: \(8/200\times100=4\%\) olur. Kaynak açıklamasındaki 240 paydası kullanılırsa \(8/240\times100\approx3.3\%\) elde edilir. Verianla burada kaynak denklemini sessizce değiştirmemekte; metin, basılı payda ve raporlanan sonuç arasındaki farkı açıkça göstermektedir.

Formül (11): Ortalama Bilgi Sorunu Çözüm Süresindeki kaynak tutarsızlığı

Kaynak 10 bilgi sorununun açılış ve kapanışları arasındaki toplam sürenin 14 gün olduğunu belirtir ve basılı formülü şu şekilde verir:

\[ MIIRT=\frac{14}{10}\times100=1.4\ \text{gün} \]

Bu denklem de yazıldığı haliyle matematiksel olarak tutarlı değildir. \(14/10=1.4\) gün sonucu doğrudur; fakat “×100” uygulanırsa sonuç 140 olur. Bu nedenle basılı “×100” ifadesi raporlanan 1,4 günlük sonuçla uyuşmamaktadır. Verianla kaynakta olmayan bir “düzeltilmiş resmî denklem” üretmemektedir.

Bu KPI'ların hiçbiri henüz doğrulanmış genel performans göstergesi değildir. Yazarlar her gösterge için proje-özel kabul eşiğinin gerçek uygulamada tanımlanması gerektiğini ve göstergelerin duyarlılık, bağımsızlık ve güvenilirliğinin ampirik olarak incelenmesi gerektiğini belirtmektedir.

Çalışmanın Yöntemi ve Bulguları

Hava-kalitesi demonstratörünün amacı

IoT destekli kentsel hava-kalitesi uygulamasının amacı çerçevenin belirli parçalarının teknik olarak nasıl bir araya getirilebileceğini göstermektir. Uygulama gerçek kirletici konsantrasyonlarını tahmin etmeyi, hava-kalitesi mevzuatına uyumu kanıtlamayı veya çevresel/karar desteği performansını ölçmeyi hedeflememektedir.

Dolayısıyla bu bölüm bir ampirik vaka çalışması değil, worked illustration / teknik uygulanabilirlik demonstrasyonu olarak değerlendirilmelidir.

Demonstratörün coğrafi bağlamı

Proof-of-concept ortamı için Romanya'daki Timișoara kenti seçilmiştir. Şehir geometrisinin oluşturulmasında Cesium for Unreal yaklaşımı kullanılarak coğrafi referanslı arazi, uydu görüntüsü ve 3D Tiles tabanlı kent bağlamının Unreal Engine ortamına aktarılabileceği gösterilmiştir.

Çalışma özellikle yüksek doğruluk gerektiren okul, hastane, ulaşım merkezi veya kritik altyapı gibi bölgelerde gelecekte IFC, CityGML, LiDAR, UAV fotogrametrisi veya kadastro verileriyle daha ayrıntılı geometri eklenebileceğini tartışmaktadır. Bu ileri düzey veri bütünleştirmeleri mevcut demonstratörde doğrulanmış sonuçlar değildir.

Kullanılan başlıca yazılım ve veri bileşenleri

Hangi meteorolojik değişkenler ele alınıyor?

Kaynak, hava durumu API'lerinden sıcaklık, bağıl nem, atmosfer basıncı, rüzgâr hızı, rüzgâr yönü, yağış ve güneş radyasyonu gibi çevresel değişkenlerin alınabileceğini belirtmektedir. Bu değişkenler gerçek atmosferik dağılım modellemesinde önemli olsa da mevcut demonstratör bu verilerden doğrulanmış kirletici konsantrasyon tahmini üretmemektedir.

Hangi kirleticiler demonstratör bağlamında geçiyor?

Proof-of-concept mimarisinde izleme bağlamı için PM1, PM2.5, PM10, NO ve CO2 örnekleri kullanılmaktadır. AQICN API'nin sunabildiği daha geniş veri kümesi içinde PM2.5, PM10, NO2, SO2, CO ve O3 gibi kirletici göstergeleri de yer almaktadır.

Appendix B'deki örnek IDS listesi ayrıca PM1, PM2.5, PM10, NO, NO2, SO2, CO, CO2, O3 ve VOC gibi parametrelerin yanında sıcaklık, bağıl nem, rüzgâr hızı ve rüzgâr yönü için de makine-okunabilir sınırlı değer kümeleri göstermektedir.

Niagara Fluids ile yapılan şey gerçek CFD midir?

Hayır. Unreal Engine içindeki Niagara Fluids sistemi içe aktarılan kent geometrisi çevresinde akış benzeri görsel davranışlar üretebilir. Geometri Signed Distance Field veya çarpışma sınırı olarak kullanılabilir ve dış hava verisinden gelen makro rüzgâr vektörü görsel akışı etkileyebilir.

Ancak kaynak açıkça bu çıktının bilimsel olarak kalibre edilmiş veya doğrulanmış atmosferik dağılım çözümü olmadığını belirtmektedir. Görsel, paydaşların gelecekte doğrulanmış CFD veya tahmin modellerinden gelebilecek sonuçların mekânsal olarak nasıl gösterilebileceğini anlamasına yönelik açıklayıcı bir katmandır.

Bu nedenle Unreal Engine'in yüksek kare hızında hacimsel görselleştirme yapabilmesi, onun bilimsel CFD çözücüsünün doğruluğuna sahip olduğu anlamına gelmez.

Üç kirletici davranış deseni

Kaynak üç basitleştirilmiş görsel davranış kategorisi kullanmaktadır:

• Yere yakın birikim — havadan daha ağır davranış için açıklayıcı desen.
• Rüzgârla ağırlıklı yatay taşınım — havaya yaklaşık nötr yoğunluk yaklaşımı.
• Artmış düşey yükselme — havadan daha hafif davranışı temsil eden açıklayıcı desen.

Bu kategoriler gerçek düzenlenmiş kirleticilere doğrudan atanamaz. Gerçek atmosferik dağılım; emisyon sıcaklığı, çıkış hızı, parçacık büyüklüğü, moleküler özellikler, atmosferik kararlılık, türbülans, şehir morfolojisi, kimyasal dönüşüm, çökelme ve meteoroloji gibi çok sayıda etkene bağlıdır.

Kaynak Şekil 14'te gösterilen kirletici parçacıkları ve emisyon bilgileri hipotetiktir. Referans verilen endüstriyel tesisten ölçülmüş gerçek emisyonları temsil etmez ve kurulu filtrasyon/arıtma teknolojilerinin etkisini hesaba katmaz.

API verisi nasıl platforma giriyor?

Kaynakta OpenWeatherMap için HTTP isteği oluşturan, JSON biçimli yanıtı alan ve gerekli meteorolojik alanları ayrıştıran Blueprint iş akışı gösterilmektedir.

AQICN tarafında ise seçilen istasyon konumu ve kimlik doğrulama tokenı ile API isteği oluşturulur; JSON yanıtındaki IAQI bölümü ayrıştırılır. Sistem belirli birkaç kirleticiyi kod içine sabitlemek yerine mevcut alan adlarını dolaşarak dönen parametreleri Key–Value çiftlerinden oluşan özel bir ST_AQIParameter yapısına dönüştürmektedir.

Key, PM10, O3, SO2, nem, sıcaklık, basınç veya rüzgâr hızı gibi parametre kimliğini; Value ise API'den gelen ilgili ölçümü temsil eder.

Demonstratör mimarisi

IDS örneğinde gerçekten ne doğrulanıyor?

Kaynağın Appendix B bölümünde buildingSMART IDS 1.0 genel yapısına uygun örnek XML verilmektedir. Örneğin IFCSENSOR varlığı için sensör adı, benzersiz Tag, sensör tipi, operasyon durumu ve sorumlu kuruluş gibi bilgiler zorunlu özellikler olarak tanımlanabilir.

Başka bir örnek spesifikasyonda sensörün ölçtüğü parametre ve beklenen ölçüm birimi kontrol edilir. Kaynak listesi PM1, PM2.5, PM10, NO, NO2, SO2, CO, CO2, O3, VOC, sıcaklık, bağıl nem, rüzgâr hızı ve rüzgâr yönü gibi değerleri; µg/m³, mg/m³, ppm, ppb, °C, %, m/s ve derece gibi birimleri örneklemektedir.

Bina nesneleri için ise bina kimliği, fonksiyon, kullanım türü, tahmini kullanıcı sayısı, işletme programı, havalandırma tipi, enerji kaynağı, otopark kapasitesi, araç erişim tipi, kat sayısı ve sensör varlığı gibi bağlamsal bilgilerin kontrol edilebileceği gösterilmektedir.

Buradaki IDS XML, gerçek bir belediye veya yetkili kurum tarafından onaylanmış nihai hava-kalitesi bilgi standardı değildir. Çalışmanın önerdiği çerçeveyi göstermek için hazırlanmış açıklayıcı örnektir.

Düzenleyici çerçeve neden bilgi yönetişiminin parçası?

Appendix A, Avrupa Birliği'nin hava kalitesi, endüstriyel emisyonlar, ulusal emisyon azaltımları, kamusal raporlama ve mekânsal veri birlikte çalışabilirliğiyle ilgili düzenleyici yapılarını OIR geliştirilmesi için bağlamsal girdi olarak ele almaktadır.

Temel mantık şudur: bir karar destek sistemi yalnız “PM2.5 değeri” istememelidir. Mevzuat ölçüm birimini, ortalama süresini, konumu, veri kaynağını, doğrulama statüsünü, raporlama gereksinimini ve hangi eşiğin hangi düzenlemeye göre anlamlı olduğunu etkileyebilir.

Ancak kaynak Appendix A'nın kapsamlı hukuk analizi olmadığını açıkça belirtir. Düzenleyici tablo, gelecekteki bir DT bilgi gereksinim sisteminde hangi hukuki yükümlülüklerin veri gereksinimi doğurabileceğini göstermek içindir.

Çalışmanın desteklediği sonuçlar

• Digital Twin uygulamalarında güvenilir analiz için bilgi gereksinimlerinin teknoloji seçiminden önce açıkça tanımlanabileceği yapılandırılmış bir yönetişim zinciri kurulabilir.
• ISO 19650 bilgi gereksinimleri, IDM, LIN, IFC ve IDS kavramları tek bir DT odaklı izlenebilirlik sürecinde ilişkilendirilebilir.
• IDM aktör, sorumluluk ve bilgi değişim süreçlerini; LIN gerekli bilgi kapsamını; IDS ise belirli model/varlık bilgilerinin makine-okunabilir kontrolünü tanımlamak için birlikte kullanılabilir.
• Seçili BIM, GIS, API ve hava-kalitesi bilgileri Unreal Engine tabanlı ortak görsel ortamda teknik olarak birleştirilebilir.
• Digital Shadow demonstratörü, bazı bilgi akışlarının ve entegrasyon ilişkilerinin teknik uygulanabilirliğini açıklayabilmektedir.
• Aday IQ-KPI'lar gelecekte gerçek projelerde bilgi ekosisteminin belirli kalite özelliklerini ölçmek için değerlendirilebilecek bir başlangıç yapısı sağlamaktadır.

Çalışmanın desteklemediği sonuçlar

• Önerilen çerçevenin bilgi kalitesini gerçek projede iyileştirdiği kanıtlanmamıştır.
• Çerçevenin proje maliyetini düşürdüğü veya teslim süresini kısalttığı gösterilmemiştir.
• Çerçevenin yapay zekâ veya tahmin doğruluğunu artırdığı gösterilmemiştir.
• Digital Shadow demonstratörü gerçek kirletici konsantrasyonlarını hesaplamamaktadır.
• Niagara görselleri doğrulanmış CFD veya atmosferik dağılım sonuçları değildir.
• Kaynakta gösterilen emisyonlar referans verilen tesisin doğrulanmış gerçek emisyonları değildir.
• Sentetik IQ-KPI yüzdeleri gerçek proje performansı değildir.
• Demonstratör düzenleyici uyumu kanıtlamamaktadır.
• Sistem vatandaş maruziyetini gerçek verilerle hesaplamamaktadır.
• Otomatik fiziksel kontrol veya kapalı çevrim aktüasyon uygulanmamıştır.
• Çerçevenin başka kullanım alanlarına doğrudan genellenebilirliği henüz test edilmemiştir.

Çalışmanın güçlü yönleri

Çalışmanın en güçlü yönü “daha fazla teknoloji” yaklaşımından uzaklaşıp karar amacı ile bilgi gereksinimi arasındaki izlenebilirliği merkeze almasıdır. OIR → DTUC → AIR/PIR/EIR → IDM → LIN → IDS zinciri, bir verinin neden istendiğini ve hangi doğrulama kuralına kadar izlenebildiğini açıklaştırmaya çalışmaktadır.

İkinci güçlü yön, BIM, GIS, IoT ve API entegrasyonunun yalnız teknik veri transferi olarak değil; semantik ve organizasyonel birlikte çalışabilirlikle beraber ele alınmasıdır.

Üçüncü güçlü yön ise yazarların demonstratörün sınırlarını açıkça tanımlamasıdır. Sistem “Digital Twin” hedefi içerisinde anlatılsa da mevcut teknik uygulamanın daha doğru sınıflandırmasının Digital Shadow olduğu belirtilmiştir.

Başlıca sınırlılıklar

Operasyonel doğrulama yoktur: Çerçeve gerçek proje üzerinde baz süreçle karşılaştırılmamıştır.

KPI değerleri sentetiktir: 92%, 90%, 93,5%, 88% veya diğer değerler gerçek saha verisi değildir.

Doğrulanmış emisyon envanteri yoktur: Endüstriyel kaynakların görselleştirilen kirletici bilgileri hipotetiktir.

Kalibre atmosferik dağılım modeli yoktur: Niagara Fluids çıktıları görsel iletişim içindir.

Tam sensör ağı yoktur: Demonstratör bütün kenti kapsayan doğrulanmış operasyonel izleme ağı değildir.

Eğitilmiş tahmin modeli yoktur: Gelecekteki AI veya tahmin kabiliyeti mimari düzeyde tartışılmıştır.

Otomatik geri besleme yoktur: Dijital ortam fiziksel dünyaya otomatik kontrol komutu göndermemektedir.

Karar kalitesi karşılaştırması yoktur: Çerçeveyi kullanan ve kullanmayan süreçlerin karar sonuçları karşılaştırılmamıştır.

Transfer edilebilirlik doğrulanmamıştır: Hava-kalitesi dışındaki altyapı bakımı, enerji yönetimi veya acil müdahale gibi ikinci bir alan üzerinde ampirik test gerekmektedir.

Gelecek araştırmalar nasıl yapılmalı?

Kaynak gelecekte çerçevenin gerçek bir operasyonel projede test edilmesini önermektedir. Böyle bir değerlendirmede baz süreç ile yönetişim çerçevesi kullanılan süreç karşılaştırılmalı; bilgi tamlığı, doğrulama performansı, izlenebilirlik, sorun çözüm süresi, model kullanılabilirliği ve karar kalitesi gibi ölçütler gerçek veriyle değerlendirilmelidir.

Hava-kalitesi uygulaması için doğrulanmış emisyon envanteri, kalibre sensör verisi, kabul görmüş atmosferik dağılım veya CFD modelleri, belirsizlik analizi, nüfus maruziyet verileri ve gerçek ölçümlerle model karşılaştırması gerekmektedir.

Yazarlar ayrıca altyapı bakımı, enerji yönetimi veya acil müdahale gibi ikinci bir uygulama alanında test yapılmasını, böylece çerçevenin yalnız hava-kalitesi demonstratörüne özgü olup olmadığının değerlendirilmesini önermektedir.

Kaynak ve Yöntem Notu

Özgün başlık: A BIM-Based Framework Proposal for Reliable Information Governance in Urban Digital Twins

Yazarlar: Andrei Crisan; Sorin Herban; Massimiliano Pepe; Jan Karlshøj; Valerio Baiocchi; Bogdan Runceanu.

Yazar sırası: Kaynaktaki sıra aynen korunmuştur.

Sorumlu yazar: Sorin Herban.

Kurum 1: Department of Steel Structures and Structural Mechanics, Politehnica University Timisoara, Timișoara, Romania.

Kurum 2: Department of Overland Communication Ways, Foundation and Cadastral Survey, Politehnica University Timisoara, Timișoara, Romania.

Kurum 3: Department of Engineering and Geology (InGeo), “G. d’Annunzio” University of Chieti-Pescara, Pescara, Italy.

Kurum 4: Department of Civil and Mechanical Engineering, Digital Building Technologies, Technical University of Denmark, Lyngby, Denmark.

Kurum 5: Department of Civil, Building and Environmental Engineering, Sapienza University of Rome, Rome, Italy.

Kurum 6: Faculty of Law, Transilvania University of Brasov, Brasov, Romania.

Eş katkı: Kaynağın yazar katkıları bölümünde altı yazarın çalışmanın kavramsallaştırılması ve tasarımı, verilerin analizi ve yorumlanması ve makalenin yazımına eşit katkı verdiği belirtilmektedir. Bununla birlikte ilk sayfada ayrı bir “eş birinci yazar” işareti bulunmamaktadır.

Dergi: Urban Science.

Yayınevi: MDPI, Basel, Switzerland.

Makale türü: Article; standart-güdümlü kavramsal çerçeve geliştirme ve teknik demonstrasyon çalışması.

Cilt / sayı / makale numarası: 10(7), 416.

DOI: 10.3390/urbansci10070416

Gönderim tarihi: 16 Haziran 2026.

Revizyon tarihi: 13 Temmuz 2026.

Kabul tarihi: 16 Temmuz 2026.

Yayın tarihi: 19 Temmuz 2026.

Hakemlik durumu: Urban Science dergisinde yayımlanmış hakemli araştırma makalesi.

Lisans: Creative Commons Attribution (CC BY).

Resmî bağlantı: DOI 10.3390/urbansci10070416 üzerinden MDPI Urban Science makale kaydı.

Anahtar kelimeler: BIM; digital twin; urban development; information governance; digital shadow.

Temel standart ve teknik yapılar: ISO 19650, ISO 29481, ISO 7817, IFC, IDM, LIN ve IDS.

Ana bilimsel katkı: Mevcut BIM ve bilgi-yönetimi kavramlarını yeni standartlar olarak sunmak yerine, organizasyonel amaçtan bilgi tanımına, bilgi değişimine, doğrulamaya ve kalite geri bildirimine uzanan tek bir Digital Twin odaklı izlenebilirlik zincirinde birleştirmek.

Demonstratör türü: IoT destekli kentsel hava-kalitesi Digital Shadow demonstratörü.

Demonstrasyon coğrafyası: Timișoara, Romania.

Başlıca teknik bileşenler: Unreal Engine 5.7; Cesium for Unreal v2.27.0; BIM/IFC; GIS; Bonsai; REST API; JSON; Blueprint; Python tabanlı ara katmanlar; OpenWeatherMap, Open-Meteo, Meteostat, uRADMonitor ve AQICN gibi dış veri servisleri.

Demonstratörün yapmadığı işlemler: doğrulanmış atmosferik dağılım modellemesi, doğrulanmış kirletici tahmini, gerçek nüfus maruziyeti analizi, otomatik fiziksel aktüasyon, kapalı çevrim kontrol ve ampirik karar-kalitesi karşılaştırması.

IQ-KPI durumu: Önerilen 11 gösterge aday değerlendirme ölçütleridir; ampirik olarak doğrulanmış genel performans göstergeleri değildir.

Matematiksel kaynak notu: Formül (5)'te çarpma işareti tipografik olarak bozuk görünmektedir. Formül (10)'da açıklama 8/240 kontrolü tarif ederken basılı payda 200'dür ve raporlanan %3,3 değeri basılı payda ile uyuşmamaktadır. Formül (11)'de 14/10 sonucu 1,4 gün iken basılı denklemde ayrıca ×100 bulunmaktadır. Verianla bu kaynak-içi tutarsızlıkları sessizce düzeltmemiştir.

Veri erişilebilirliği: Çalışma Cesium, Google Maps ve belirtilen hava/hava-kalitesi servisleri üzerinden erişilen kamuya açık kaynakları kullanmıştır. Ampirik proje veri seti, doğrulanmış emisyon envanteri, kişisel veri veya hassas veri üretilmediği belirtilmektedir. Örnek IDS XML Appendix B'de verilmiş, sentetik KPI girdileri ve hesapları ana metinde raporlanmıştır. Ayrı bir .ids eki, sentetik veri seti veya harici veri deposu sunulmamıştır.

Finansman: Kaynak “This research received no external funding” beyanında bulunmaktadır.

Proje/teşekkür notu: Kaynak ayrıca araştırmanın Erasmus+ Programme BIM Enabled DTs (BIM2in), proje numarası 2024-1-RO01-KA220-HED-000249147 kapsamında kısmen gerçekleştirildiğini belirtmektedir. Bu ifade finansman beyanından ayrı olarak Teşekkür bölümünde yer almaktadır.

Üretken yapay zekâ kullanımı: Yazarlar makale hazırlığı sırasında kaynakta “openAI, ChatGPT 5.5/Google, and Gemini 3.5” biçiminde belirtilen araçları görüntü üretimi, metin çevirisi, dilbilgisi düzeltme ve metin açıklama amaçlarıyla kullandıklarını; çıktıları inceleyip düzenlediklerini ve yayın içeriğinin sorumluluğunu üstlendiklerini beyan etmektedir.

Çıkar çatışması: Yazarlar çıkar çatışması olmadığını beyan etmektedir.

Temel yorum sınırı: Çalışmanın ana çıktısı doğrulanmış bir yönetişim çözümü veya ölçülmüş performans artışı değil; gerçek projelerde ileride test edilebilecek yapılandırılmış bir bilgi-yönetişimi çerçevesi ve değerlendirme altyapısıdır.