Mühendislik ve tasarım

TEKNİK DEĞERLENDİRME / 01

Tasarım kararını model öğesine bağlamak

İyi bir mühendislik tasarım sistemi yalnızca son çizimi saklamaz; kararın hangi gereksinimden doğduğunu, hangi alternatiflerin incelendiğini ve hangi model öğesini etkilediğini de gösterir. Bir havalandırma kanalının güzergâhı değiştiğinde söz konusu karar sadece geometrik değildir: yangın zonu geçişleri, bakım erişimi, tavan kotu, elektrik kablo tavaları ve akustik koşullar aynı anda etkilenebilir. Bir kararın kapsamı, o kararın dayandığı veri ve sorumlu uzman birbirinden ayrılmadığında revizyon geçmişi anlaşılamaz hale gelir.

Octatus'un konumlandırıldığı fiziksel varlık bağlamı, BIM/GIS modeli ile mühendislik kayıtlarını aynı varlık referansında ilişkilendirmeyi hedefler. Tasarım oluşturma, hesaplama ve disipline özgü onay ise ilgili uzman araç ve ekiplerde yürütülebilir. Uygulamada her tasarım değişikliği için benzersiz bir değişiklik kimliği, etkilenen varlık listesi, kaynak model sürümü, değişiklik gerekçesi, inceleme durumu ve kabul kanıtı istenir. Böylece kullanıcı yalnızca yeni şekli değil, bu şekle neden ulaşıldığını da inceleyebilir.

TEKNİK DEĞERLENDİRME / 02

BIM bilgi modeli ve açık veri alışverişi

Bir BIM teslimi yalnızca üç boyutlu geometrinin görüntülenebildiği dosya değildir. Yapı elemanlarının sınıfları, mekânsal kapsama ilişkileri, sistem bağlantıları, malzeme bilgileri, özellik kümeleri ve kalıcı kimlikleri tasarım koordinasyonu için önem taşır. Örneğin bir mekanik cihazın IFC nesnesi olarak aktarılması yeterli olmayabilir; hangi havalandırma sistemine hizmet verdiği, hangi katta bulunduğu ve hangi teknik etiketi taşıdığı da korunmalıdır. IFC şemasının sunduğu zenginlik ile gerçek ihracat dosyasındaki bilginin kapsamı aynı şey değildir.

IFC 4.3, ISO 16739-1:2024 kapsamında binalara ek olarak altyapı uygulamalarını da daha kapsamlı destekler. Ancak belirli bir projede kullanılacak sürüm, gönderici ve alıcı yazılımların gerçek yetenekleriyle seçilmelidir. Kaynak model ve IFC modeli örnek varlıklar üzerinden karşılaştırılmalı; sınıf, tip, koordinat, birim, GlobalId, özellik ve ilişkilerdeki kayıplar kayıt altına alınmalıdır. Bir model dosyasının hatasız açılması, bilgi tesliminin başarılı olduğunu tek başına kanıtlamaz.

TEKNİK DEĞERLENDİRME / 03

Geometri, semantik ve koordinat kontrolü

BIM ve GIS modellerinin bir arada kullanıldığı projelerde geometrinin doğruluğu birden fazla düzeyde ele alınır. Önce modelin birim sistemi ve orijini, sonra proje koordinatları ile coğrafi referans sistemi arasındaki dönüşüm doğrulanır. Doğru görünen bir bina hacmi, yanlış datum veya eksen sırası nedeniyle harita üzerinde kaymış olabilir. Aynı şekilde farklı disiplinlerin modelleri görsel olarak yakın görünse bile birkaç santimetrelik sapma montaj ve bakım açıklıkları açısından kritik olabilir.

Semantik kontrol ise bir nesnenin yalnızca nerede durduğunu değil, neyi temsil ettiğini sorgular. Bir kapak, vana, damper veya elektrik panosunun yanlış sınıflandırılması sonraki iş akışlarının yanlış ekipmana yönlenmesine neden olabilir. Bu nedenle geometri, sınıflandırma, mekânsal kapsama, sistem bağlantısı ve kaynak sürüm doğrulamaları ayrı test aileleri olarak kurgulanır. Hata raporu, model öğesi kimliğiyle birlikte hata türünü ve çözüm sorumlusunu göstermelidir.

TEKNİK DEĞERLENDİRME / 04

Disiplinler arası koordinasyon ve çakışma yönetimi

Mimari, statik, mekanik, elektrik ve altyapı modelleri farklı disiplinlerin teknik kararlarını temsil eder. Koordinasyon çalışmasında geometrik çakışma bir başlangıç sinyalidir; fakat her çakışma aynı öneme sahip değildir. Bir asma tavan içindeki kablo tavası ile kanalın kesişmesi, taşıyıcı elemanda açılması önerilen delikle veya yangın damperinin bakım erişiminin kapanmasıyla aynı risk kategorisinde değerlendirilemez. Eşik, tolerans ve öncelik kriterleri disiplinlere göre belirlenmelidir.

İyi bir koordinasyon süreci, çakışmanın keşfi ile kapatılmasını birbirinden ayırır. Bulgu belirli model revizyonlarına, mekânsal konuma ve sorumlu ekibe bağlanır; önerilen düzeltme yeniden kontrol edilir. BCF gibi konu ve bulgu paylaşım yöntemleri, yazılımlar arasında değerlendirme bağlamını taşımaya yardımcı olabilir. Ancak koordinasyon toplantısında bir bulgunun kapatılmış görünmesi, güncel federasyon modelinin gerçekten düzeltildiği anlamına gelmez. Kabulde son model üzerinden tekrarlı test gerekir.

TEKNİK DEĞERLENDİRME / 05

Gereksinimden doğrulamaya dijital iz

Bir varlığın tasarımı yalnızca teknik çizimlerle başlamaz; performans, kapasite, güvenlik, erişilebilirlik, çevresel koşullar ve işletme gerekleri gibi gereksinimlerle şekillenir. Bu gereksinimler belirsiz veya ölçülemez yazıldığında sonradan hangi tasarım alternatifinin doğru olduğu tartışmalı hale gelir. Örneğin bir elektrik panosunun yedek kapasite hedefi, mekanik mahallin sıcaklık aralığı veya ekipmanın bakım açıklığı somut kabul kriterine bağlanmalıdır. Gereksinimin hangi model öğesi ve hangi doğrulama belgesiyle ilişkili olduğu önemlidir.

Birlikte geliştirilen Velocize, mühendislik yaşam döngüsü ve gereksinim izlenebilirliği uzmanlığına odaklanırken Octatus fiziksel model ve varlık ilişkileri bağlamında tamamlayıcı bir rol üstlenir. Ortak bir çözüm senaryosunda gereksinim, tasarım alternatifi, revizyon, test ve kabul kanıtı tek bir dijital iz üzerinde ilişkilendirilebilir. Bu anlatım bütün ürünler arası arayüzlerin hazır olduğunu veya doğrulanmış şekilde çalıştığını iddia etmez; bağlantı ve yetki kapsamı gerçek sürüm ve proje ihtiyaçlarıyla sınanmalıdır.

TEKNİK DEĞERLENDİRME / 06

Değişiklik yönetimi ve etki analizi

Bir tasarım değişikliğinin maliyeti, değiştirilmiş elemanın geometrik boyutundan daha büyük olabilir. Bir pompanın kapasitesi artırıldığında elektrik beslemesi, kablo kesiti, koruma ayarları, boru çapı, temel yükleri ve kontrol senaryosu yeniden değerlendirme gerektirebilir. Etki analizi yalnızca modelde görsel olarak komşu nesneleri aramakla sınırlı tutulursa önemli bağımlılıklar kaçırılabilir. Etkilenen sistemler, belgeler, hesap dosyaları ve saha iş emirleri ilişki türüne göre incelenmelidir.

Değişiklik talebinde mevcut durum, öneri, gerekçe, etkilenen disiplinler, risk, geri dönüş seçeneği ve karar sorumlusu bulunmalıdır. Ön inceleme ile onaylı tasarım birbirine karıştırılmamalıdır. Bir modelin güncel sürümüne erişmek kullanıcıların yanlışlıkla uygulamaya yetkili olduğu anlamına gelmez. Uygulama öncesinde hesap ve disiplin kontrolü, sonrasında saha doğrulaması ve as-built revizyonu gerekir. Böylece neyin tasarlandığı, neyin gerçekten uygulandığı ve neyin kabul edildiği ayrı kayıtlar olarak kalır.

TEKNİK DEĞERLENDİRME / 07

Sürümleme, baz çizgisi ve konfigürasyon

Model dosyasının adına tarih eklemek kurumsal konfigürasyon yönetimi için yeterli değildir. Bir projede mimari modelin yeni sürümü, eski mekanik modelle birlikte inceleniyor olabilir; bu kombinasyonun geçerli koordinasyon baz çizgisi olup olmadığı açıkça belirtilmelidir. Baz çizgisi yalnızca dosya listesini değil, kullanılan hesap varsayımlarını, dış referansları, onay seviyesini ve bilgi teslim kapsamını da tanımlar. Denetim sırasında sonucu üreten model kombinasyonunun tekrar oluşturulabilmesi gerekir.

Konfigürasyon kayıtları her bileşenin kaynak sürümünü ve ilişkili kararları göstermelidir. Yeni revizyonu karşılaştırırken hangi öğelerin eklendiği, silindiği, taşındığı veya yeniden sınıflandırıldığı ayrı raporlanabilir. Farklı yazılımların IFC GlobalId değerlerini yeniden oluşturması gibi durumlarda kimlik sürekliliği ayrıca denetlenmelidir. Bir öğe kimliğinin değişmesi her zaman fiziksel varlığın değiştiğini göstermez; eşlemenin doğruluk düzeyi ve inceleme gereksinimi açık olmalıdır.

TEKNİK DEĞERLENDİRME / 08

IDS, bilgi gereksinimleri ve model kabulü

İşverenin ihtiyaç duyduğu veri proje başında belirtilmezse teslim aşamasında eksik bilgileri tamamlamak maliyetli olur. AIR ve EIR gibi bilgi gereksinimleri, hangi varlık sınıfı için hangi özelliğin, formatın, sorumluluğun ve teslim zamanının beklendiğini belirlemek için kullanılır. Bir mekanik ekipman için seri numarası işletmeye geçişte gerekliyken erken tasarım aşamasında henüz bilinemeyebilir. Bu fark, gereksinimlerin aşama ve bilgi olgunluğu seviyesine göre düzenlenmesini gerektirir.

buildingSMART Information Delivery Specification (IDS), belirli IFC bilgi gereksinimlerinin makinece kontrol edilebilir biçimde ifade edilmesine yardımcı olur. Nesne sınıfı, özellik, sınıflandırma ve bazı değer kuralları otomatik denetlenebilir; ancak bakım erişiminin sahada gerçekten mümkün olduğunu veya bir tasarımın tüm mevzuata uygun olduğunu yalnızca IDS ile kanıtlamak mümkün değildir. Bu nedenle kabul matrisi otomatik özellik testlerini, geometri kontrolünü, insan incelemesini ve gerektiğinde saha doğrulamasını birlikte içerir.

TEKNİK DEĞERLENDİRME / 09

Teknik hesaplar ve simülasyon sonuçları

Yapısal analiz, enerji modeli, CFD, elektrik yük akışı ve benzeri mühendislik hesapları, geometriye ek olarak malzeme modelleri, sınır koşulları ve uzman yöntemler ister. Bir IFC modeli hesaplama için yararlı kaynak olabilir; fakat doğrudan hesap modeline eşdeğer değildir. Örneğin bir enerji modeli termal zon ve kullanım takvimi gerektirirken elektriksel model bara bağlantısı, empedans ve kontrol parametreleri ister. Hesap geometrisi kaynak BIM'den türetilirken yapılan sadeleştirmeler açıkça belgelenmelidir.

Octatus ile simülasyon ilişkisinde önemli olan, hesap çıktısının hangi fiziksel varlık ve hangi tasarım revizyonu için üretildiğinin izlenebilir kalmasıdır. Çözücü seçimi ve uzman doğrulama ayrı aşamalardır. Sonuçlar senaryo kimliği, giriş veri paketi, hesap motoru ve sürümü, kabul sınırları ile birlikte saklanmalıdır. Aynı proje için iki alternatif simülasyon sonucunu karşılaştırırken kaynak koşulların eşit olup olmadığı kontrol edilmeden tek bir performans kazanımı yüzdesi ilan edilmemelidir.

TEKNİK DEĞERLENDİRME / 10

İmalata uygunluk ve saha uygulanabilirliği

Tasarım incelemesi yalnızca hesap uygunluğu değildir; ekipmanın montajı, kaldırılması, servis erişimi ve sahada değiştirilebilirliği de değerlendirilmelidir. Tasarım modelinde bir vana yerinde görünse bile çevresindeki boşluk gerçek bakım prosedürüne uygun olmayabilir. Taşıyıcı sistem, tavan yüksekliği, şaft erişimi, iş güvenliği ve yangın bölümlendirmesi birlikte değerlendirilmediğinde sonradan yapılan düzeltmeler proje süresini ve maliyeti artırabilir.

Bu nedenle belirli varlık sınıfları için bakım ve montaj açıklıkları, yaklaşım yönleri, sökme güzergâhları ve müdahale alanları kontrol listesine eklenebilir. Gerekiyorsa saha taraması veya ölçülü fotoğraf ile tasarım varsayımları karşılaştırılır. Farklar kanıt olarak kayıt altına alınırken tarama bulutunun gizli sistem bağlantılarını veya ekipmanın teknik uygunluğunu otomatik doğrulamadığı belirtilir. Son kabul sorumluluğu ilgili proje ve disiplin ekipleriyle tanımlanmalıdır.

TEKNİK DEĞERLENDİRME / 11

Saha değişiklikleri ve as-built doğruluğu

İmalat sırasında ortaya çıkan saha koşulları tasarımın değişmesini gerektirebilir. Bir kanalın yer değiştirmesi, elektrik cihazının farklı marka ile tedarik edilmesi veya teknik odanın yerleşiminin değişmesi gibi durumlarda onaylı tasarım, sahadaki gerçek konfigürasyon ve as-built teslimi farklı zamanlarda güncellenir. Bunların tek bir model durumuymuş gibi gösterilmesi bakım ekiplerinin yanlış bilgiye dayanmasına neden olabilir.

Sağlıklı devir için sahadan gelen fotoğraf, ölçüm, kontrol formu ve iş emri, ilgili varlığın kalıcı kimliğiyle eşlenmelidir. Değişiklik doğrulanana kadar durum taslak veya bekleyen inceleme olarak gösterilmelidir. Bir ürünün güncel işletme görünümünde yalnızca son CAD dosyasını göstermesi gerçek durumu garanti etmez. Model revizyonlarının ve saha kanıtlarının ayrı kaynak otoriteleri olarak tutulması, uyuşmazlıkların araştırılmasına ve ilerideki yenileme işlerinin daha doğru planlanmasına yardımcı olur.

TEKNİK DEĞERLENDİRME / 12

Doküman ve veri yönetişimi

Mühendislik sürecinde çizimler, teknik şartnameler, hesap raporları, üretici dokümanları ve denetim kayıtları farklı kişilerce hazırlanır. Hangi belgenin taslak, paylaşılmış, yayımlanmış veya arşivlenmiş olduğu açık değilse kullanıcı yanlış dokümana dayanarak karar verebilir. Bilgi yönetimi, dosya depolamanın ötesinde yetki, sürüm, onay, yayımlama ve dağıtım kurallarını tanımlar. ISO 19650 serisi bu yaşam döngüsü boyunca bilgi yönetimi için çerçeve sunar.

Bir CDE yaklaşımında belge kimliği, sorumlu kuruluş, durum kodu, revizyon, teslim paketi ve kullanım amacı tanımlanır. Mühendislik modeli ile belge arasındaki bağlantı, belgenin her zaman güncel olduğu anlamına gelmez. Kullanıcının hangi sürümün onaylı olduğu ve yeni değişikliğin neden henüz yayımlanmadığını anlayabilmesi gerekir. Kullanıcı deneyimi tasarlanırken yalnızca en son yüklenen kaydı değil, kullanım yetkisi olan en son kabul edilmiş kaydı göstermek önemlidir.

TEKNİK DEĞERLENDİRME / 13

Güvenlik, yetki ve denetlenebilirlik

Tasarım verileri tesisin kritik altyapısını, ekipman kapasitesini ve güvenlik sınırlarını açığa çıkarabilir. Bu nedenle proje yöneticisinin, disiplin mühendisinin, saha yüklenicisinin ve işletme personelinin aynı bilgiye aynı yetkiyle erişmesi çoğu zaman uygun değildir. Çok kiracılı kurulumlarda verinin tenant sınırının yalnızca kullanıcı arayüzünde değil, API, arama, dosya bağlantıları ve model ilişkileri üzerinden de korunması gerekir.

Özellikle tasarım değişikliği ve kabul işlemlerinde rol ayrımı önemlidir. Bir mühendisin değerlendirme yapabilmesi, o değişikliği tek başına yayımlama hakkı bulunduğu anlamına gelmez. Erişim ve onay olayları denetim kaydına eklenmeli; eski kaydın kim tarafından ve hangi tarihte değiştirildiği görülebilmelidir. Tasarım modelindeki güncelleme ile gerçek endüstriyel kontrol komutu arasında açık güvenlik sınırı olmalıdır.

TEKNİK DEĞERLENDİRME / 14

Açık API ve uzman ürün ailesi

Mühendislik verisi birden fazla kurumsal sistemle ilişkilendirilebilir. Octatus fiziksel bağlamı yönetirken Velocize gereksinim ve doğrulama izine, Enlogy enerji ve saha operasyonuna, Argamos BT altyapısı ve hizmet bağımlılıklarına odaklanan birlikte geliştirilmiş ürünlerdir. Bu ürünler birbirine sonradan eklenmiş üçüncü taraf eklentiler gibi değerlendirilmemelidir; fakat kendi veri otoritelerini ve uzman iş süreçlerini korurlar.

Örneğin veri merkezindeki bir UPS değişikliği mühendislik gereksiniminden başlayabilir, fiziksel yerleşim revizyonunu etkileyebilir, enerji işletmesinde yeni gözlem ve alarm eşikleri gerektirebilir, BT hizmet tarafında ise yedeklilik değerlendirmesine yol açabilir. Böyle bir senaryoda kullanıcı akışının tutarlı olması için ortak varlık kimliği, veri paylaşım sözleşmesi, olay kaynakları ve yetki matrisi gerekir. İlgili ürün bağlantılarının gerçek sürümlerde hazır olup olmadığı teknik keşif ve pilot kabulüyle doğrulanmalıdır.

TEKNİK DEĞERLENDİRME / 15

Teknik karar örneği: HVAC cihazı değişimi

Bir hastanede hava işleme ünitesinin daha yüksek debili modelle değiştirilmek istendiğini düşünelim. İlk aşamada bakım gerekçesi, hedef hava debisi, servis edilen mahaller ve kullanılabilir teknik hacim belirlenir. İkinci aşamada yeni ekipmanın fiziksel boyutları, ağırlığı ve elektrik gereksinimleri modele işlenir. Mekanik mühendis hava kanalı ve fan koşullarını incelerken elektrik mühendisi besleme gücü ve koruma koordinasyonuna bakar. Yapısal ekip ekipman taşıma koşullarını, yangın güvenliği ekibi ilgili zon gereksinimlerini değerlendirir.

Etki kaydı; etkilenen mahalleri, değişen ekipman etiketini, revize edilmiş teknik çizimleri, gerekli hesapları ve onayları ilişkilendirir. İşletme ekibi bakım penceresinde hangi klinik hizmetlerin etkilenebileceğini ayrıca inceler. İmalat sonrasında montaj fotoğrafları ve ölçümler as-built kaydına bağlanır. Bu örnek bir uygulama senaryosudur; Octatus'un bu adımların tümünü tek başına otomatik gerçekleştirdiği veya klinik güvenlik uygunluğu verdiği iddia edilmez.

TEKNİK DEĞERLENDİRME / 16

Teknik karar örneği: trafo ve fider revizyonu

Bir kampüste yeni yüklerin devreye girmesi mevcut trafoyu ve ana dağıtım panolarını etkileyebilir. İlk tasarım sorusu, hangi yüklerin nereden besleneceği ve hangi yedek kapasitenin korunacağıdır. BIM/GIS tarafında trafo odası, kablo güzergâhı ve fiziksel ekipman kimlikleri incelenirken elektriksel hesap modelinde bara, fider, empedans, yük ve koruma bileşenleri değerlendirilir. Fiziksel kablo güzergâhı ile elektriksel topolojinin birbirine karıştırılmaması gerekir.

Bir revizyon talebi bağlantı noktası veya kesici konumunu değiştiriyorsa yeni tek hat şemasıyla yük akışı varsayımlarının tutarlılığı kontrol edilir. Kablo geçişi yangın bölmelerini etkiliyorsa ilgili disiplin yeniden inceler. Etki kayıtları saha keşfi ve imalat belgeleriyle tamamlanır. Hesap çıktıları uzman araçların üretimidir; dijital ikiz içindeki rol bunların ilgili varlığa ve onaylı modele izlenebilir biçimde bağlanmasıdır.

TEKNİK DEĞERLENDİRME / 17

Teknik teslimat ve kabul kontrol listesi

Bir proje başlamadan önce hangi bilgilerin kabul edileceği yazılı hale getirilmelidir. En azından varlık kapsamı, model ayrıntı düzeyi, koordinat sistemi, dosya sürümü, kimlik eşlemesi, zorunlu özellikler, disiplin sorumluları, değişiklik prosedürü ve saha doğrulama örneklemi tanımlanır. Gereksinimlerin yalnızca teknik terimler olarak listelenmesi yeterli değildir; her gereksinim için kanıt türü, kontrol yöntemi ve başarı ölçütü belirlenmelidir.

Örnek kabul matrisinde modelin açılabilmesi bir testtir; IFC sınıflarının korunması başka bir testtir. Mimari ve mekanik modellerin doğru koordinatlarda birleşmesi, ekipman etiketinin işletme envanterindeki kayıtla eşlenmesi, değişiklik geçmişinin izlenebilmesi ve yetkisiz kullanıcının onay verememesi ayrı ayrı değerlendirilmelidir. Hatalı bir örneğin düzeltilmesi tek başına bütün projenin doğru olduğunu kanıtlamaz; kapsamlı ve önceden kararlaştırılmış örneklem kullanılır.

TEKNİK DEĞERLENDİRME / 18

Kademeli uygulama planı ve başarı ölçütleri

Yüksek yatırım ve veri dönüşümü gerektiren projelerde tüm tesisin aynı anda modellenmesi yerine ölçülebilir bir pilotla başlamak daha güvenilir olabilir. Pilot olarak belirli bir teknik kat, enerji dağıtım hattı veya bina seçilebilir. İlk fazda kaynakların ve sorumluların envanteri oluşturulur; ikinci fazda varlık kimliği ve model tutarlılığı test edilir; üçüncü fazda gerçek bir değişiklik senaryosu yürütülür. Bu yaklaşım, henüz doğrulanmamış varsayımların bütün kuruma yayılmasını önler.

Başarı ölçütleri yalnızca işlenen dosya sayısı veya ekrandaki üç boyutlu görüntü kalitesiyle belirlenmemelidir. Kimliği doğrulanan kritik ekipman oranı, doğru sistem bağlantısı, kapatılan çakışmaların yeniden testte geçiş oranı, değişiklik inceleme süresi, eksik bilgi oranı ve onaylı kanıta erişim gibi ölçümler kullanılabilir. Tüm iyileşmelerin platformdan kaynaklandığı varsayılmamalı; süreç, veri temizliği ve ekip eğitiminin etkisi de ayrıştırılmalıdır.

TEKNİK DEĞERLENDİRME / 19

Yapay zekâ destekli mühendislikte sınırlar

Yapay zekâ, geniş teknik doküman havuzlarında arama, model öğelerine ilişkin açıklamaların hazırlanması ve değişiklik kayıtlarının sınıflandırılması gibi işlerde yardımcı olabilir. Ancak kaynak doküman yanlışsa veya varlık eşlemesi eksikse sistem çok tutarlı görünen yanlış öneriler sunabilir. Bu nedenle teknik bir cevapta kaynak belge, ilgili model sürümü, kullanıcı yetkisi ve belirsizlik düzeyinin görünür olması gerekir. Üretilen metin mühendislik hesabı veya resmi proje onayı yerine geçmez.

Bir ekipman değişikliğinde yapay zekâ geçmiş bakım kayıtlarından benzer arızaları önerebilir; fakat yeni cihazın fiziksel uyumu, elektriksel koruması ve mevzuata uygunluğu yetkili mühendislerce doğrulanmalıdır. Gelecekteki otomasyon seviyeleri tartışılırken öneri oluşturma, hesap başlatma ve uygulamaya geçme izinleri birbirinden ayrılmalıdır. Denetlenebilir ürün tasarımı, açıklanamayan otomatik değişiklikler yerine kontrollü insan onayı ve test kanıtı üretmeyi amaçlar.

TEKNİK DEĞERLENDİRME / 20

Metraj, miktar çıkarımı ve BOM yönetimi

Modelden metraj üretme fikri doğru bilgi yapısıyla güçlü bir karar desteğine dönüşebilir. Bununla birlikte bir elemanın geometrisinden hesaplanan hacim veya yüzey alanı, sözleşmede kullanılacak nihai iş kalemi miktarı ile her zaman aynı değildir. Bir duvarın brüt alanı ile açıklıklar düşüldükten sonraki net alanı farklıdır; bir boru hattının model uzunluğu ise montaj payları veya bağlantı elemanlarını içermeyebilir. Aynı varlık, farklı disiplin modellerinde iki kez temsil edilmiş olabilir. Bu nedenle miktar çıkarımı için kapsam ve hesaplama kuralı açık olmalıdır.

Uygulamada her iş kalemi bir sınıflandırmaya, kaynak model öğelerine, ölçüm birimine ve hesap kuralına bağlanır. Model sürümü değiştiğinde artan ve azalan miktarlar ayrı raporlanabilir. Satın alma kararında kullanılacak BOM veya BOQ için mühendis ve maliyet uzmanının kontrolü gerekir; ham model çıktısı kendiliğinden onaylı keşif değildir. Bu ayrım tasarım değişikliklerinin bütçe etkisini izlerken özellikle önem taşır.

TEKNİK DEĞERLENDİRME / 21

LOIN ve bilginin amaca uygun olgunluğu

Bütün projelerde bütün nesneleri en yüksek geometrik ayrıntıyla modellemek hem pahalı hem de çoğu zaman gereksizdir. Erken tasarımda bir havalandırma santralinin yaklaşık boyutu ve kapasitesi yeterli olabilirken imalat öncesinde bağlantı ağızları, bakım açıklıkları ve taşıma gereksinimleri kritik hale gelir. İşletmeye devir aşamasında ise ekipmanın gerçek seri numarası, üreticisi, garanti kaydı ve bakım dokümanına erişim daha değerli olabilir. Dolayısıyla geometrik ayrıntı, alfanümerik bilgi ve belge gereksinimleri birbirinden bağımsız olgunlaşır.

Level of Information Need (LOIN) yaklaşımı bilgi kapsamının kullanım amacıyla uyumlu belirlenmesine yardımcı olur. Projede hangi kararın hangi aşamada verileceği yazılmalı ve buna göre varlık sınıfları için zorunlu alanlar belirlenmelidir. Eksik olan ama o aşamada henüz beklenmeyen bilgi ile teslim şartına aykırı eksik bilgi aynı hata gibi raporlanmamalıdır. Böylece bilgi kalitesi ölçümleri gerçek karar ihtiyacını yansıtır.

TEKNİK DEĞERLENDİRME / 22

Arayüz yönetimi ve disiplin sorumlulukları

Büyük ölçekli tesis projelerinde teknik risklerin önemli bir bölümü tek bir disiplinin içinde değil, disiplinler arasındaki arayüzlerde ortaya çıkar. Mekanik ekip bir cihaz için elektrik gücü ihtiyacını belirlerken elektrik ekibi koruma düzenini tasarlar; otomasyon ekibi kumanda ve geri bildirim sinyallerini tanımlar. Her ekip kendi çizimini doğru üretse bile ortak arayüz gereksinimi yanlış anlaşılmış olabilir. Bu nedenle arayüzlerin yalnızca çizgi bağlantısı değil, teknik sözleşme olarak da temsil edilmesi gerekir.

Arayüz kayıtlarında kaynak ve hedef sistem, sinyal veya fiziksel bağlantı türü, kapasite, birim, tasarım sorumlusu ve kabul kriteri bulunmalıdır. Örneğin bir cihazın nominal besleme gücü ile kalkış akımı aynı teknik gereksinim değildir. Şemada bulunan bir kontrol noktası sahada kablolanmış veya test edilmiş sayılmaz. Arayüz değişikliği olduğunda hangi ekiplerin yeniden inceleme yapması gerektiği kurallara bağlanmalıdır. Bu kayıtlar Velocize tarafındaki mühendislik yaşam döngüsüyle ve Octatus'un fiziksel varlık bağlamıyla ilişkilenebilecek doğal bir ortak senaryo oluşturur.

TEKNİK DEĞERLENDİRME / 23

Tedarikçi verisi, malzeme onayı ve değişiklik riski

Mühendislik modeli çoğunlukla tasarım niyetini temsil eder; satın alınan ürün ise marka, seri, boyut, ağırlık ve performans açısından tasarım varsayımlarından ayrılabilir. Eşdeğer ürün önerisinin yalnızca katalogdaki nominal kapasiteye bakılarak kabul edilmesi risklidir. Montaj açıklığı, bakım erişimi, elektrik bağlantısı, kontrol protokolü ve çevresel koşullar yeniden değerlendirilmelidir. Önerilen değişiklik daha ucuz olsa bile tasarımda ve işletmede ek maliyet yaratabilir.

Tedarikçi teknik dokümanı ilgili varlık tipiyle bağlanırken teklif, onaylı ürün ve sahada takılı gerçek cihaz ayrımı korunmalıdır. Malzeme onay sürecinde tasarımcı, yüklenici ve varlık sahibinin sorumlulukları ayrı tanımlanır. Ürün eşdeğerliği disiplin uzmanı onayına bağlıdır; modelde katalog bilgisini güncellemek tek başına teknik kabul sağlamaz. Kurulum sonrasında seri numarası ve üretim bilgisi as-built varlık kaydına geçmeli, eski tasarım varsayımının yerini neden aldığı izlenebilmelidir.

TEKNİK DEĞERLENDİRME / 24

Teknik şartname ve yazılım değerlendirme soruları

Kuruluşlar mühendislik ve tasarım için dijital platform seçerken yalnızca üç boyutlu görüntü performansına veya desteklenen dosya uzantılarının sayısına odaklanmamalıdır. Esas soru, belirli kararların hangi kanıtlarla destekleneceği ve farklı ekiplerin mevcut sistemlerini değiştirmeden nasıl birlikte çalışacağıdır. Müşteri, model revizyonu ve varlık kimliklerinin nasıl korunduğunu, yetki sınırlarının nerede uygulandığını, kaynak veri kaybının nasıl raporlandığını ve başarısız aktarımların nasıl geri alındığını sormalıdır. Kapalı dosya biçimlerinden açık verilere geçişte kayıp riski önceden test edilmelidir.

Teknik şartname örnek kabul senaryoları içermelidir: farklı iki disiplin modelinin aynı koordinatlarda birleştirilmesi, bir ekipmanın kaynağına kadar izlenmesi, revizyon farkının tespiti, onaylanmamış çizime erişimin engellenmesi ve IFC özelliklerinin seçilen örneklemde korunması gibi. Ürün ailesindeki her bileşenin işlevsel kapsamı ayrıca sorulmalı; entegrasyon iddiaları çalışan prototip veya belgeli test ile doğrulanmalıdır. Böylece değerlendirme yalnızca satış sunumuna değil, tekrar edilebilir teknik kanıta dayanır.

Sık sorulan sorular

Standartlar ve teknik kaynaklar

Resmî kaynaklar, bilgi modeli ve mühendislik teslimlerinin değerlendirilmesi için başlangıç noktalarıdır. Kullanılacak sürüm ve proje sözleşmesi ayrıca kontrol edilmelidir.

• buildingSMART — Industry Foundation Classes (IFC) ↗
• buildingSMART — IFC 4.3.2.0 resmi şema dokümantasyonu ↗
• buildingSMART — Information Delivery Specification (IDS) ↗
• ISO — ISO 19650-1:2018 bilgi yönetimi ilkeleri ↗