IFC Nedir? Revit Dosyasından Farkı ve openBIM Gerçeği

IFC neden ortaya çıktı?

Industry Foundation Classes (IFC), bina ve altyapı verilerinin farklı yazılımlar arasında paylaşılması için geliştirilen, üreticiden bağımsız bir veri şemasıdır. ISO 16739-1:2024 ile yayımlanan IFC 4.3, yol, demiryolu ve diğer altyapı alanlarına ilişkin kapsamı genişletmiştir.

RVT gibi yerel proje dosyaları belirli bir uygulamanın düzenleme deneyimini ve özelliklerini taşır. IFC ise paylaşılabilir nesne türleri, öznitelikler ve ilişkiler üzerinden ortak anlam oluşturmayı hedefler. IFC dosyasını yerel dosyanın bire bir kopyası saymak doğru değildir.

IFC dosyası açılıyor olması yeterli mi?

Hayır. Geometrinin görünmesi, veri aktarımının eksiksiz olduğu anlamına gelmez. Dışa aktarımdan sonra nesne sınıfları, benzersiz kimlikler, kat/mekân ilişkileri, özellik kümeleri, birimler ve koordinat sistemleri kontrol edilmelidir.

Örneğin bir ekipman görsel olarak doğru yerde olsa da yanlış sınıflandırılmışsa envanter aramasında bulunamayabilir. Bir koordinat dönüşümü hatası ise kampüs veya altyapı GIS katmanlarıyla hizalamayı bozabilir.

IFC 2x3, IFC4 ve IFC4.3 nasıl seçilir?

En yeni sürüm her zaman her teslim zincirinde en iyi sonuç vermez. Alıcı yazılımın desteklediği şema, model görünümü, istenen nesne sınıfları ve doğrulama kuralları birlikte değerlendirilmelidir. IFC 4.3 özellikle altyapı bağlamında önemlidir; fakat mevcut proje teslim koşullarının yerine geçmez.

Pilot alışveriş yapın: örnek modeli dışa aktarın, bağımsız görüntüleyicide ve hedef sistemde açın, kritik nesneleri ve özellikleri karşılaştırın. Hata raporunu kaynak modele geri besleyin.

Octatus ile açık veri yaklaşımı

Octatus'un BIM/GIS anlatımında odak, IFC veya RVT kaynaklarından gelen öğelerin mekânsal ve operasyonel bağlamda değerlendirilebilmesidir. Belirli bir sürümün, dönüşümün veya düzenleme özelliğinin desteklendiği proje öncesinde doğrulanmalıdır; pazarlama metni tek başına uygunluk kanıtı değildir.

Kaynaklar: buildingSMART IFC standardı https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/ ; ISO 16739-1:2024 https://www.iso.org/standard/84123.html

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

IFC aktarımında geometri düzgün görünse bile ekipman sınıfı, özellik seti, birim, kat ilişkisi veya GlobalId değişmiş olabilir. Bu nedenle 'dosya açıldı' kabulü veri bütünlüğünü kanıtlamaz.

Bir işletme ekibi Revit modelinde AHU-12 olarak görünen klima santralini IFC tesliminde aradığında, yalnızca geometriyi bulmak yeterli değildir. İhracat sonrasında IfcDistributionElement sınıfı, GlobalId, ekipman etiketi ve bağlı mekânın korunup korunmadığı kontrol edilir. Kaybolan bir özellik, bakım planının yanlış varlığa bağlanmasına neden olabilir. Karar için kaynak RVT sürümü ile teslim IFC sürümü birlikte kaydedilir.

Uygulama ve kabul kontrolü

Kaynak modelden seçilen 20 kritik elemanın kimlikleri, sınıfları, özellikleri ve mekânsal ilişkileri hedef sistemde karşılaştırılmalı; kayıplar raporlanmalıdır.

Pilot olarak bir mekanik katın IFC ihracatı seçilebilir. Kapı, ekipman, mekân ve sistem ilişkileri için kaynak model ile IFC çıktısı karşılaştırılır; nesne sayısı ve kimlik sürekliliği ayrı ölçülür. İhracat ayarları değiştirildiğinde aynı örneklem yeniden test edilir. Görsel olarak düzgün açılan bir modelin semantik olarak doğru olduğu varsayılmaz.

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

IFC yatırımında dönüştürücü yazılımın fiyatından önce veri kaybının maliyeti ölçülmelidir. Revit kaynağındaki on kritik ekipmanın IFC aktarımında GlobalId, sistem bağlantısı ve zorunlu özellikleri korunuyorsa sonraki disiplinlere geçilebilir. Nesne görünmesine rağmen ekipman kodu kayboluyorsa satın alma kararından önce ihracat profili ve hedef sistem yorumlaması düzeltilmelidir. Aynı örnek dosyanın her sürüm yükseltmesinde yeniden sınanması işletme bütçesine dahil edilmelidir.

IFC desteği satın alma kararında yalnızca 'dosya açıyor' ifadesiyle değerlendirilemez. Kurumun kullandığı IFC sürümü, koordinat bilgisi, özellik setleri ve disiplin nesneleri için örnek dosya hazırlanmalıdır. İki farklı görüntüleyicide aynı teslimin açılması faydalı olsa da gerekli alanların kayıpsız aktarımını ayrıca kanıtlamak gerekir.

IFC/openBIM: teknik veri modeli ve tasarım kararları

IFC'deki IfcProject, IfcBuilding, IfcBuildingStorey ve IfcSpace mekânsal hiyerarşiyi, eleman sınıfları ise fiziksel varlıkları temsil eder. Geometri doğruyken semantik yanlış olabilir.

IFC varlık eşlemesinde kaynak modelin yerel nesne kimliği, IFC GlobalId ve işletme varlık kodu ayrı sütunlarda tutulmalıdır. Bir model revizyonu sırasında nesne yeniden oluşturulursa GlobalId değişebilir; bakım kaydının yanlış nesneye taşınmaması için değişiklik incelemesi gerekir. İlişki kaydına kaynak dosya, dışa aktarma tarihi ve doğrulayan rol eklenmesi geriye dönük incelemeyi kolaylaştırır.

IFC/openBIM: standartlar ve birlikte çalışabilirlik sınırları

IFC2x3, IFC4 ve IFC4.3 arasında kaynak/hedef uygulama desteği, şema ve kullanım senaryosuna göre seçim yapın; IFC4.3 özellikle altyapı alanını genişletir.

openBIM yaklaşımı tek bir uygulamanın veri modelini evrensel kabul etmek değildir. IFC şeması hangi nesnelerin ve ilişkilerin taşınabileceğini tanımlar; belirli teslim gereksinimleri için IDS gibi makineyle kontrol edilebilir kurallar ayrıca kullanılabilir. IFC sürümleri arasında desteklenen özellikler değişebileceği için hedef sürüm ve teslim profili sözleşmede açıkça yazılmalıdır.

IFC/openBIM: gerçek işletme senaryosu ve hata türleri

Revit aile parametreleri IFC özelliklerine bire bir aktarılmayabilir. IDS veri gereksinimi kontrolüne, BCF koordinasyon sorunlarına hizmet eder.

Bir IFC ihracatında duvarlar doğru görünürken mekanik ekipmanın tip bilgisi boş kalabilir. Başka bir senaryoda modelin koordinat dönüşümü hatalı olduğundan GIS üzerinde bina yüzlerce metre kayar. Test setinde boş özellikler, yinelenen varlık kodları, yanlış birim, eksik mekân ilişkisi ve beklenmeyen koordinat değerleri bulunmalıdır. Bu kusurların hangisinin kabulü durduracağı önceden tanımlanır.

IFC/openBIM: pilot uygulama ve kabul kriterleri

Örnek 50 elemanda IFC sınıfı, GlobalId, asset ID, birim, özellik, kat/mahal ve sistem ilişkisini kaynak modelle karşılaştırın.

IFC pilot kabul tablosu her zorunlu özellik için beklenen değer, kaynak model değeri, IFC çıktısı ve kontrol sonucunu içerir. Örnek olarak 40 mekanik ekipmanın seri numarası, sınıfı ve kat ilişkisi incelenebilir; örneklem büyüklüğü gerçek kapsamın riskine göre belirlenir. Hatalar kaynak modelleme, dışa aktarma ayarı veya hedef sistem yorumlaması olarak ayrıştırılmalıdır.

IFC/openBIM: maliyet, ölçekleme ve yönetişim

IFC tabanlı birlikte çalışabilirlikte maliyet yalnızca dönüştürme yazılımından oluşmaz. Kaynak modelin özellik temizliği, sınıf eşlemesi, farklı IFC sürümlerinin test edilmesi ve sonraki revizyonlarda regresyon kontrolü gerekir. Bir kere hazırlanmış başarılı örnek dosya, gelecekteki tüm disiplin teslimlerinin aynı kalitede olacağını garanti etmez.

Yaygınlaştırma kararı için önce kritik IFC nesnelerinde kimlik korunumu, zorunlu alan doluluğu ve mekânsal yerleşim doğruluğu ölçülür. Sonraki fazda elektrik ve mekanik disiplinler eklenirken yeni sınıf eşlemeleri için ayrı test paketleri hazırlanır. Ürün değerlendirmesinde kaynak yazılıma bağımlılık, lisans değişikliği ve açık formatta dışa aktarım imkânı da hesaba katılır.

IFC dosyasının içinde hangi nesneler vardır?

Bir IFC dosyasını yalnızca üç boyutlu geometri taşıyan bir paket gibi okumak yanlış bir başlangıçtır. Proje, saha, bina, kat ve mahal gibi mekânsal nesneler; yapı elemanları ve tesisat ekipmanları; bunların özellikleri, tipleri ve ilişkileri bir arada bulunabilir. IfcRelContainedInSpatialStructure gibi ilişkiler bir elemanın mekânsal bağlamını kurarken sistem ve bağlantı ilişkileri farklı şema yapılarıyla temsil edilir. Her export bu ilişkilerin tamamını üretmeyebilir.

İşletme için örnek bir fan-coil ünitesini ele alın. Görünür geometrisi doğru olsa bile cihazın hangi odaya hizmet ettiği, bağlı olduğu devre, üretici bilgisi ve kurumsal envanter kodu eksik olabilir. Bu nedenle ilk test 'model açılıyor mu?' değil 'hangi iş kararını hangi alanlarla destekliyor?' sorusu olmalıdır. Bir veri teslim sözlüğü oluşturulmalı; her alanın IFC içindeki karşılığı, kaynak uygulama parametresi ve doğrulama yöntemi yazılmalıdır.

IFC sürüm seçimi için karar tablosu

IFC2x3 uzun süredir kullanılan ve çok sayıda eski yazılım tarafından desteklenen bir şemadır. IFC4 bazı kavramsal ve teknik iyileştirmeler içerir. IFC4.3 ise özellikle yol, demiryolu, köprü ve benzeri altyapı alanlarına ilişkin modelleme kapsamını genişletir. Fakat şema sürümü ile uygulamanın o şemadaki nesneleri doğru okuyabilmesi farklı konulardır. Sözleşmede yalnızca 'IFC4 desteklenecek' demek yeterli değildir.

İki yazılım arasında veri alışverişi yapılacaksa her iki tarafta kullanılan sürümler, export/import seçenekleri, desteklenen varlık sınıfları, özellik kümeleri ve koordinat dönüşümleri test edilmelidir. Bir bina bakım projesinde eski bir CMMS entegrasyonu için IFC2x3 pratik olabilir; altyapı portföyünde IFC4.3 gereksinimleri ağır basabilir. Karar en yeni sürümü seçme refleksiyle değil, hedef kullanım senaryosu ve test edilmiş veri bütünlüğüyle verilmelidir.

Revit aileleri, parametre eşlemesi ve semantik kayıp

Revit gibi modelleme uygulamalarında kullanılan aileler, paylaşılan parametreler ve kategori yapıları IFC şemasındaki sınıf ve özelliklerle tam örtüşmeyebilir. Örneğin üreticiye özgü bir mekanik ekipman ailesinin 'Nominal Flow' alanı dışa aktarım sırasında başka adla çıkabilir veya hiç aktarılmayabilir. Aynı şekilde tip parametresi ile örnek parametresi arasındaki fark kaybolursa tüm ekipmanlar yanlış kapasiteyle görünebilir.

Bu riski azaltmak için kaynak parametre → IFC sınıfı/özelliği → hedef sistem alanı eşleme matrisi hazırlanmalıdır. Her satırda birim, boş değer davranışı, veri türü ve hata seviyesi bulunmalıdır. Export öncesinde sınıflandırma ve kimlik alanları doğrulanmalı, export sonrasında seçilmiş elemanlar kaynakla karşılaştırılmalıdır. Özellikle tesisat ekipmanlarının sistem ilişkileri ve bağlantı portları, yalnızca görsel kontrolde fark edilmeyen kayıp alanlarıdır.

GlobalId ve işletme varlık kimliği aynı değildir

IFC GlobalId, model öğesini dosya ve uygulamalar arasında tanımlamak için tasarlanmış bir kimliktir. Bununla birlikte eleman yeniden oluşturulduğunda, export mantığı değiştiğinde veya modeller birleştirildiğinde kimlik sürekliliği bozulabilir. İşletmenin fiziksel ekipman kimliği ise yıllar boyunca bakım, garanti, parça ve arıza geçmişine bağlanır. Dolayısıyla GlobalId'yi tek başına kalıcı bakım kimliği saymak güvenilir değildir.

Önerilen çözüm kurumsal asset ID, kaynak model ID, IFC GlobalId ve gerekiyorsa seri numarası için ayrı alanlar tutmaktır. Eşleme kaydı kaynak, revizyon, geçerlilik zamanı ve doğrulayan kişiyi içermelidir. P-101 fonksiyonel pompa pozisyonuna yeni bir fiziksel pompa takıldığında eski seri numarasıyla yeni cihazın geçmişi birbirine karıştırılmamalıdır. Bu ayrım, özellikle uzun ömürlü tesislerde model yenileme ve sistem geçişi sırasında kritik hale gelir.

IDS ile makine tarafından denetlenebilir gereksinimler

Information Delivery Specification, belirli IFC nesnelerinde hangi sınıflandırmaların, özelliklerin veya değer koşullarının bulunması gerektiğini ifade etmek için kullanılabilir. Örneğin belirli pompa sınıfındaki bütün elemanlarda varlık kodu, üretici ve tasarım debisi zorunlu tutulabilir. Bu, teslimatın öznel görsel incelemeden ölçülebilir veri denetimine taşınmasına yardımcı olur. Ancak IDS kuralının geçmesi fiziksel sahadaki verinin doğru olduğunu tek başına kanıtlamaz.

Bir teslimat kontrolünde önce zorunlu alanların makineyle varlığı ve biçimi test edilir; ardından seçilen kritik varlıkların gerçek etiketleri ve saha belgeleriyle eşleşmesi incelenir. Birimlerin doğru olması da önemlidir: litre/saniye ile metreküp/saat değerleri dönüşüm olmadan karşılaştırılırsa yanlış hata veya yanlış başarı sonucu üretilebilir. IDS kurallarının sürümü, hangi sözleşme gereksinimini karşıladığı ve başarısız testlerin düzeltme süreci raporlanmalıdır.

BCF ile model sorunlarının yaşam döngüsü

BIM Collaboration Format, modelde belirli elemanlara veya görünümlere bağlı koordinasyon sorunlarının paylaşılmasına yardımcı olur. Örneğin bir kanal ile kiriş arasındaki çakışma için sorun kaydı açılabilir; ilgili disiplin, sorumlu, durum, görünüm ve açıklama birlikte tutulabilir. BCF bir veri gereksinimi şeması değildir; IFC dosyasının semantik doğruluğunu da tek başına garanti etmez. IDS ve BCF farklı kontrol katmanlarında değer üretir.

İyi bir sorun kapatma sürecinde 'çözüldü' durumunun ardından yeni model revizyonunda düzeltmenin gerçekten bulunduğu doğrulanmalıdır. Sadece yorumun kapanması yeterli değildir. Model nesnesinin kimliği değişmişse sorunla yeni nesne arasındaki bağ yeniden kurulmalıdır. Koordinasyon toplantılarında sorun sayısı kadar yeniden açılan sorun oranı, çözüm süresi ve sonraki teslimata taşınan kritik hatalar da izlenebilir.

IFC kabul testinin beş katmanı

Birinci katman dosya bütünlüğü ve şema doğrulamasıdır: dosya bozuk mu, sürüm beklenen mi, birimler tanımlı mı? İkinci katman mekânsal doğruluktur: bina, kat, mahal ve koordinat ilişkileri beklenen yerde mi? Üçüncü katman nesne semantiğidir: sınıflar, tipler ve kimlikler doğru mu? Dördüncü katman özellik ve ilişkileridir: zorunlu alanlar ve sistem bağlantıları korunmuş mu? Beşinci katman iş sürecidir: hedef uygulama bu verilerle doğru karar verebiliyor mu?

Kabul örneklemi yalnızca rastgele seçilmiş kolay elemanlardan oluşmamalıdır. Kritik pompalar, panolar, karmaşık MEP bağlantıları, çok katlı ilişkiler ve özel parametreli nesneler dahil edilmelidir. Her test için beklenen sonuç, hata sınıfı, tolerans ve düzeltme sorumlusu tanımlanır. Bir dosyanın ikinci bir uygulamada açılması faydalı çapraz kontroldür, fakat kapsamlı semantik testin yerine geçmez.

Koordinat, birim ve büyük dosya performansı

IFC içindeki yerel yerleşimler, proje referansı ve varsa jeoreferans bilgisi birlikte yorumlanmalıdır. Bir modelin doğru yerde görünmesi için X/Y kadar Z referansı ve birim dönüşümü de kontrol edilmelidir. Büyük dosyalarda geometri dönüştürme, indeksleme ve tarayıcıya aktarım maliyeti önemlidir. Her kullanıcıya tüm modelin tam çözünürlükte gönderilmesi hem ağ hem bellek açısından verimsiz olabilir.

Octatus benzeri platformlarda kaynak IFC dosyasını saklama, geometriyi görselleştirme için işleme ve semantik varlık bilgisini sorgulama farklı katmanlar olarak tasarlanabilir. Kaynak dosyanın hash'i, dönüşüm sürümü, tenant ve yayın tarihi izlenmelidir. Performans testi gerçek model büyüklüğünde yapılmalı; ilk yükleme, kat filtresi, varlık araması ve model revizyonu sonrası yeniden indeksleme süreleri ayrı ölçülmelidir.

Tedarikçi bağımsızlığı ve veri çıkış planı

openBIM yaklaşımının önemli motivasyonlarından biri veriyi tek bir üretici yazılımına kilitlemeden paylaşabilmektir. Fakat yalnızca IFC export düğmesinin bulunması tam taşınabilirlik anlamına gelmez. Özel sınıflandırmalar, doküman bağlantıları, onay kayıtları ve bakım kimlikleri ayrı veri tabanlarında tutuluyorsa çıkış senaryosu bunları da kapsamalıdır. Bir kurum, sistem değiştirirken hangi bilgiyi hangi açık biçimde alacağını baştan bilmelidir.

Teknik şartnamede kaynak model, IFC teslimatı, özellik sözlüğü, eşleme tabloları, doküman referansları ve revizyon geçmişi için teslim koşulları tanımlanabilir. Ayrıca veri taşıma denemesi yapılarak bir başka uygulamada örnek varlıkların yeniden kurulabildiği doğrulanmalıdır. Veri dışa aktarımı erişilebilir olsa bile lisans bitiminden sonra bağlantılı dosyaların kaybolması veya kimliklerin yeniden üretilememesi operasyonel bağımlılık yaratabilir.

IFC pilotu için 60 günlük uygulama planı

İlk iki haftada kullanım senaryosu, zorunlu varlık sınıfları ve kaynak uygulama sürümleri belirlenir. Üçüncü ve dördüncü haftada parametre eşleme matrisi, örnek export ve otomatik doğrulama kuralları hazırlanır. Beşinci ve altıncı haftada hedef uygulamada kimlik, özellik, koordinat ve ilişki kontrolleri yapılır. Son iki haftada sorunlar düzeltilir, ikinci export alınır ve kabul raporu hazırlanır. Süre örnektir; karmaşık tesislerde daha uzun gerekebilir.

Pilot çıktıları yalnızca bir IFC dosyası ve ekran görüntüsü olmamalıdır. Kaynak-hedef karşılaştırma tablosu, test sonuçları, bilinen veri kayıpları, düzeltme sorumluları, kimlik stratejisi ve yeniden üretilebilir export ayarları teslim edilmelidir. Bu yaklaşım, büyük ölçekli dönüşüme geçmeden önce veri kaybının nerede oluştuğunu gösterir ve sonraki entegrasyon maliyetini daha gerçekçi hesaplamayı sağlar.

Hata sınıflandırması ve yeniden teslim kuralları

Kritik hata, yanlış elektrik besleme ilişkisi veya yanlış varlık kimliği gibi işletme güvenliğini etkileyen durumları kapsayabilir. Majör hata, zorunlu ekipman özelliğinin veya mahal ilişkisinin eksik olmasıdır. Minör hata ise kullanım senaryosunu engellemeyen biçimsel tutarsızlık olabilir. Hata sınıfları işverenin risk değerlendirmesiyle belirlenmeli; tüm eksikler aynı ağırlıkta sayılmamalıdır.

Her bulgu için kaynak dosya, nesne kimliği, beklenen sonuç, gerçekleşen sonuç, ekran görüntüsü veya makine raporu, düzeltme sorumlusu ve tekrar test tarihi kaydedilir. Yeni export alındığında yalnızca düzeltilen eleman değil, daha önce geçen örneklerden bir bölüm de yeniden test edilir. Böylece bir parametre eşleme düzeltmesinin başka nesne sınıflarını bozması önlenebilir.

IFC yönetiminde değişiklik ve revizyon farkı

Bir IFC dosyasının yeni sürümünde değişen nesneleri bulmak, yalnızca iki dosyanın boyutunu veya tarihini karşılaştırmakla mümkün değildir. Nesne ekleme, silme, özellik güncelleme, geometri değişimi ve ilişki değişimi ayrı sınıflardır. Bir nesnenin GlobalId'si değişmişse sistem bunu her zaman fiziksel ekipman değişimi olarak yorumlamamalıdır.

Revizyon karşılaştırması kurumsal varlık kimliği, model kimliği ve gerektiğinde mekânsal/özellik benzerliği üzerinden kontrollü yapılabilir. Belirsiz eşlemeler otomatik kabul edilmemeli, incelemeye gönderilmelidir. Onaylı yayın sırasında hangi varlık kayıtlarının güncellendiği ve hangilerinin reddedildiği raporlanmalıdır. Bu yöntem uzun ömürlü tesislerde yanlış bakım geçmişi aktarımını azaltır.

Yönetici için nihai karar ölçütü

Bir IFC entegrasyonunu satın alma kararı, yalnızca modelin ekranda görünmesine göre verilmemelidir. Kritik varlıkların kimliği, sınıflandırması, birimleri ve sistem ilişkileri hedef uygulamada güvenilir biçimde korunuyorsa ve bu sonuç tekrarlanabilir testlerle kanıtlanabiliyorsa çözüm işlevsel değer üretmeye başlar.