BİM KOORDİNASYONDA MODEL BİRLEŞTİRME STRATEJİSİ BELİRLEMEK

Model birleştirme stratejisi, disiplin modellerinin tek federe modelde doğru oturması için yazılım seçiminden önce karara bağlanan kurgudur: hangi dosya formatı taşınacak, koordinat sistemi nasıl hizalanacak, model nasıl bölünecek, kimin değişikliği federe modele ne zaman düşecek. Bu sayfa federe modelin ne olduğunu, NWF/NWD/NWC ayrımını, Append-Merge-Open kullanımını, paylaşılan-proje-gerçek dünya koordinatlarını, model bölme prensiplerini, haftalık koordinasyon ritmini ve native-IFC format tercihini ele alıyor. Bu kararlar proje başında BEP içinde yazıya geçmezse Navisworks açıp Append demek üç ayrı dünyayı aynı sahnede sergilemekten öteye geçmez.

1. FEDERE MODEL NEDİR VE NEDEN KURULUR?

Federe model, disiplin modellerinin koordinasyon ortamında bir araya getirilmiş, salt okunur birleşik halidir. Mimari Revit'te, statik Tekla Structures'ta, mekanik Revit MEP'te veya başka bir yazılımda yaşamaya devam ederken Navisworks, Solibri veya BIMcollab Zoom federe modeli üzerinden çakışmaları görür, raporlar ve disipline geri yollar. Federe model yeniden modellenmez; içinde sadece yorum yapılır.

Bu ayrım net olmazsa şöyle bir döngü kurulur: koordinatör Navisworks'te yorumladığı bir kanalı "düzelttim" sanır, bir hafta sonra disiplin modeli güncellenir, kanal eski yerine döner ve aynı çakışma raporda tekrar belirir. Türkiye'de büyük kamu yatırımlarında bu döngü maalesef sık görülür çünkü kim federe modelde, kim disiplin modelinde değişiklik yapar sorusu BEP içinde net cevaplanmamıştır.

2. NWF NWD NWC AYRIMI VE GÜNLÜK İŞ AKIŞI

Navisworks tarafında üç dosya uzantısı vardır; üçü de farklı amaca hizmet eder ve birini diğeriyle karıştırmak ofiste fark edilmesi günler süren bir iş kaybına yol açar.

• NWC (Navisworks Cache): Disiplin yazılımından (Revit, Tekla, ArchiCAD) çıkarılan, yalnız geometri ve özellik içeren, hafif önbellek dosyası. Disiplin modeli güncellendiğinde NWC yeniden üretilir. Salt okunur, yorum tutmaz.
• NWF (Navisworks File set): Federe çalışma dosyası. Geometriyi içermez, NWC'lere referans verir. Tüm çakışma testleri, kamera açıları, yorumlar ve görünüm setleri burada yaşar. Boyutu birkaç MB'tır.
• NWD (Navisworks Document): Yayın anının kar-tonesi. Geometri, çakışma sonuçları, yorumlar bir arada gömülüdür, dış referansa ihtiyacı yoktur. İşverene rapor olarak gider, Navisworks Freedom ile ücretsiz açılır.

Pratik kural net: koordinatör NWF üzerinde çalışır; her hafta NWC'ler güncellenir; sözleşmeye esas teslimler NWD olarak arşivlenir. Mimari ofiste e-posta zincirinde dolaşan tek bir devasa NWD görüyorsanız, bilin ki koordinasyon süreci tıkanmış demektir — NWF'siz koordinasyon, kayıtsız toplantı gibidir.

3. APPEND, MERGE, OPEN — HANGİSİ NE ZAMAN KULLANILIR?

Üç ayrı seçenek aynı menünün altındadır ama yaptıkları iş birbirine karıştığında federe modele gizli hatalar girer.

1. Open: Mevcut bir NWF veya NWD dosyasını açar. Üzerine başka model getirmek için kullanılmaz.
2. Append: Açık olan sahneye yeni bir disiplin modelini referans olarak ekler. Disiplin modeli güncellendiğinde NWF içindeki referans "Refresh" ile tazelenir. Federe model çalışması her zaman Append üzerinden kurulur.
3. Merge: İki ayrı NWF dosyasını ve her birinin yorumlarını/çakışma testlerini tek bir NWF'de birleştirir. Farklı koordinatörlerin paralel ürettiği federasyonu konsolide etmek için kullanılır; günlük model güncellemesi için değildir.

Yaygın hata: yeni disiplin modeli geldiğinde Append yerine Merge tıklamak. Sonuçta dosya iki kat büyür, eskimiş ve yeni geometri üst üste oturur, çakışma testleri sahte sonuç verir. Türk müteahhitlik pratiğinde bu hata özellikle alt yüklenicilerden gelen NWD'lerin merge edilmesinde sıkça karşımıza çıkar — alt yüklenicinin NWD'si NWC olarak Append edilmelidir, Merge değil.

4. KOORDİNATLAR — PAYLAŞILAN, PROJE VE GERÇEK DÜNYA

Modeller üst üste oturmuyorsa kabahatin en az %80'i koordinat ayarındadır. Üç farklı sıfır noktası vardır ve hangi sıfırdan çıktığınıza tüm disiplinlerin sözlü değil yazılı uyması gerekir.

• Internal Origin: Yazılımın iç sıfırı. Disiplinler arası anlaşmaya elverişsiz; her yazılımda farklı yere düşer.
• Project Base Point: Projenin kendi referans noktası — genelde yapının bir köşesi veya ana akstan bir nokta. Birleştirme çoğunlukla bu üzerinden yürür.
• Survey Point (Shared / Paylaşılan): Gerçek dünya koordinatı — UTM, ITRF veya halihazır harita üzerinden tanımlı nokta. Şantiye aplikasyonu, ruhsat, iş bitirme ve arazi modeli ile entegrasyon bu noktadan döner.

Navisworks tarafında her NWC export edilirken disiplin yazılımının export ayarında "Coordinates: Shared" seçilmelidir. Bir disiplin Internal ile export ederse Navisworks o modeli kendi (0,0,0)'ına yapıştırır ve federe modelde başka bir gezegene düşer. Çözüm sahnedeki NWC'ye sağ tık > Units and Transform menüsünden rotasyon ve öteleme manuel girilebilir ama bu geçici bir yamadır; doğru çözüm export ayarını disiplinin Revit/Tekla şablonunda düzeltmektir.

Türkiye'de İstanbul Havalimanı ve Çanakkale Köprüsü gibi büyük altyapı projelerinde koordinat hizalama, harita mühendisliği ekibinin ITRF-96 üzerinden tanımladığı bir aplikasyon noktasına bağlanır. Yapı tarafındaki Project Base Point ile harita tarafındaki Survey Point arasındaki dönüşüm matris matrisi BEP ekinde verilir; bu eksik olduğunda mimar binayı gerçek kuzey yerine proje kuzeyine göre kurar, gerçek dünya kotları kayar.

5. MODEL NASIL BÖLÜNÜR VE BOYUT NASIL YÖNETİLİR?

Tek bir 8 GB Revit dosyası federe modele girdiğinde Navisworks orta sınıf bir iş istasyonunda yarım saatte açılır, çakışma testi rapor üretmeden donar. Çözüm modelin baştan bölünmesidir; bölme stratejisi proje tipine göre değişir.

1. Disiplin bazlı bölme: Mimari, statik, mekanik, elektrik, sıhhi tesisat, sprinkler, zayıf akım — her disiplin ayrı disiplin modeli. Standart başlangıç.
2. Blok / kanat bazlı bölme: Hastane gibi çok bloklu projelerde her blok kendi mimari + statik + mekanik üçlüsüne ayrılır. A blok mimari, B blok mimari ayrı dosyalardır.
3. Kat veya zon bazlı bölme: Yüksek katlı yapılarda altyapı katı, bodrum, podyum, kule birbirinden ayrılır. AVM projelerinde ortak mekan zonu ile mağaza zonu ayrı tutulur.
4. Sistem bazlı bölme: Mekanikte HVAC, yangın, sıhhi ayrı dosyalar; elektrikte güç, aydınlatma, zayıf akım ayrı dosyalar. Çok katmanlı projede zorunlu.

Pratik sınır: tek bir Revit dosyası 250-300 MB üzerine çıkıyorsa bölme zamanı gelmiş demektir. NWC'ye dönüştüğünde 50-80 MB'lık dosyalar Navisworks tarafından kabul edilebilir; 200 MB üzeri NWC'ler federe modeli yavaşlatır. Türkiye'deki müteahhitlik ofislerinin BIM ekipleri genelde alt yüklenicilere model bölme protokolünü en başta vermeyi unutur, sonra 6. ayda yangın sistemi modelini tek dosyada yapan alt yüklenici hem federe modeli hem kendi tasarım sürecini tıkar.

6. HAFTALIK KOORDİNASYON RİTMİ

Model birleştirme bir kerelik kurulum değildir; haftalık ritimle yaşar. Türk müteahhitlik pratiğinde işleyen tipik bir döngü:

• Pazartesi 17:00: Tüm disiplinler güncel NWC'lerini CDE'nin Shared alanına yükler. Dosya adı revizyon kodu taşır (örn. PRJ-A-MIM-MOD-R03-S2.nwc).
• Salı sabahı: Koordinatör NWF'yi açar, Refresh ile tüm NWC'leri tazeler, çakışma testlerini yeniden koşar.
• Salı öğleden sonra: Yeni çakışmalar gruplanır, BCF paketi halinde disiplinlere e-posta veya BIMcollab üzerinden dağıtılır.
• Çarşamba - Perşembe: Disiplinler kendi modellerini günceller, BCF yorumlarına cevap verir.
• Cuma 10:00: Tüm ekiple koordinasyon toplantısı. Ekranda federe model açık, açık kalan çakışmalar tartışılır, karar verilir.
• Cuma 17:00: Hafta sonu için NWD yayını üretilir, müteahhit ve müşavirin onayı için CDE'ye konur.

Bu ritmi bozan en yaygın iki şey: disiplinin Pazartesi'ye yetiştiremeyeceği bir revizyonu "Salı akşamı yüklerim" demesi ve koordinatörün Çarşamba günü "ek bir tarama daha yaptım" diye sıra dışı BCF yollaması. Ritim sapınca disiplin model versiyonlarının senkronizasyonu çözülür. Süreci uçtan uca işleyebilecek bir BIM koordinatörü yetiştirmek isteyen ofisler için kapsamlı bir BIM koordinasyon eğitimi programı gerçek proje senaryoları üzerinden bu döngüyü oturtmaya yardımcı olur.

7. FORMAT TERCİHİ NATIVE Mİ IFC Mİ OLMALI?

İki ekol vardır: Native ekol disiplin dosyasını doğrudan (Revit'ten RVT, Tekla'dan IFC olmayan native uzantı) Navisworks'e bağlar; tüm aileler, parametreler, malzeme tanımları korunur. Open BIM ekolü ise federe modeli IFC üzerinden kurar; ISO 16739 standardındaki IFC formatı yazılım bağımsızlığı sağlar ama her export'ta veri kaybı riski vardır.

Türkiye'de kamu projeleri (Şehir Hastaneleri, KKTC altyapı yatırımları, metro projeleri) genelde IFC zorunluluğu getirir çünkü işveren tek yazılıma bağımlı kalmak istemez. Özel sektör müteahhitlik projelerinde ise Autodesk ekosistemi (Revit + Navisworks) baskın olduğunda native bağlantı tercih edilir. Hibrit yaklaşım da yaygın: ana disiplinler native, alt yüklenici disiplinleri (cephe, asansör, mutfak ekipmanı) IFC ile entegre edilir.

IFC tercihinde dikkat edilecek noktalar:

• IFC versiyonu BEP'te yazılı (IFC2x3 Coordination View 2.0 hâlâ en güvenli ortak payda, IFC4 Reference View daha zengin).
• Her disiplinin IFC export ayarları ofis şablonunda standartlaştırılmış olmalı.
• Her IFC teslim öncesi disiplin tarafından kendi Solibri / BIMcollab model checker'ından geçirilmiş olmalı.
• Pset (Property Set) seçimi yangın direnci, ısı iletim katsayısı, malzeme markası gibi koordinasyon ve teslim kriterlerine göre yapılmalı.

8. BAŞLAMADAN ÖNCE YANITLANACAK ALTI SORU

Koordinasyon yazılımı satın alınmadan önce ofiste ve işveren tarafıyla yazıya bağlanması gereken kararlar:

1. Federe model native mi, IFC mi, hibrit mi kurulacak? Hangi IFC versiyonu?
2. Proje koordinat sistemi nedir, Project Base ile Survey Point arasındaki dönüşüm nasıl tanımlı?
3. Disiplin modelleri nasıl bölünecek — blok, kat, sistem? Tek dosya üst sınırı kaç MB?
4. NWF kimde, NWC'ler nereye yüklenecek, NWD yayın takvimi nedir?
5. Çakışma önceliklendirme matrisi (kritik / önemli / bilgi amaçlı) nasıl tanımlı? Hangi disiplin hangi çakışmaya kaç günde cevap verir?
6. Koordinasyon ritmi nedir, toplantı günü/saati sabit mi, BCF iş akışı hangi platformda yürür?

Bu altı sorunun yazılı cevabı olan BEP belgesi olmadan başlatılan koordinasyon süreci, hangi yazılım seçilirse seçilsin, üçüncü ayında yeniden başa dönmek zorunda kalır. Doğru sıra net: önce strateji, sonra şablon, sonra yazılım.