Sebuah pasukan menerima fail IFC daripada perunding. Fail itu boleh dibuka. Model bangunan kelihatan lengkap. Tiada mesej ralat besar muncul.
Namun apabila fail digunakan, beberapa masalah mula timbul:
- kuantiti dinding tidak dapat diasingkan mengikut jenis;
- fire rating yang diminta tidak ditemui;
- sebahagian peralatan muncul sebagai objek generik;
- aras dan koordinat tidak sepadan dengan model disiplin lain; dan
- pengurus fasiliti tidak dapat mengenal pasti aset yang perlu disenggara.
Secara teknikal, satu fail telah dihantar. Dari sudut keputusan projek, pertukaran maklumat itu belum berjaya.
Artikel minggu lalu membincangkan mengapa tahap maklumat perlu bermula dengan tujuan, penerima dan keputusan. IFC ialah langkah seterusnya dalam rantaian itu: bagaimana maklumat yang telah ditentukan keperluannya bergerak antara aplikasi, organisasi dan peringkat projek tanpa bergantung kepada satu perisian proprietari.
Soalan yang betul bukan sekadar “Bolehkah fail IFC ini dibuka?” Soalannya ialah “Bolehkah penerima membuat keputusan yang dipersetujui menggunakan maklumat yang benar-benar sampai?”
IFC ialah model data, bukan nama lain bagi butang Export
IFC bermaksud Industry Foundation Classes. buildingSMART mentakrifkannya sebagai penerangan digital yang piawai bagi persekitaran binaan: satu standard terbuka, antarabangsa dan neutral vendor yang boleh digunakan merentas perisian, platform dan pelbagai tujuan. buildingSMART — Industry Foundation Classes
Di bawah permukaan, IFC bukan sekadar koleksi bentuk tiga dimensi. Skemanya boleh membawa:
- identiti dan jenis objek;
- atribut seperti bahan, prestasi dan sifat terma;
- hubungan ruang, sambungan dan pemilikan;
- proses, sumber dan kawalan; serta
- konteks yang menerangkan kedudukan sesuatu objek dalam projek dan fasiliti.
Standard antarabangsa semasa, ISO 16739-1:2024, menerangkan IFC sebagai standard terbuka bagi maklumat BIM yang dipertukarkan dan dikongsi antara aplikasi untuk bangunan serta infrastruktur sepanjang kitar hayat. Edisi ini merangkumi skema data, dokumentasi, definisi set sifat dan kuantiti, serta mekanisme struktur format pertukaran. ISO — ISO 16739-1:2024
Fail berakhiran .ifc ialah salah satu cara maklumat itu dihantar. IFC sendiri ialah struktur maklumat yang lebih luas. buildingSMART juga menerangkan bahawa data IFC boleh dikodkan dalam beberapa format dan dihantar melalui fail, perkhidmatan web atau pangkalan data. Oleh itu, menyamakan IFC dengan satu arahan Save As mengecilkan persoalan sebenar.
IFC tidak menjanjikan salinan sempurna model asal
Model native di dalam aplikasi pengarang dibina untuk menyokong fungsi aplikasi tersebut. Ia mungkin mengandungi sejarah suntingan, objek parametrik khusus vendor, kekangan reka bentuk, formula, paparan, keluarga atau hubungan dalaman yang tidak mempunyai padanan satu-ke-satu dalam skema pertukaran.
Apabila dieksport, maklumat dipetakan daripada struktur native kepada struktur IFC. Apabila diimport atau dibaca, aplikasi penerima mentafsir struktur IFC mengikut keupayaannya. Ini ialah proses terjemahan, bukan fotokopi.
Sebab itu dua perkara boleh berlaku serentak:
- geometri kelihatan hampir sama; dan
- data atau hubungan yang diperlukan untuk tugasan penerima tidak sampai dengan betul.
Sebaliknya, fail boleh mengandungi data yang berguna walaupun paparan geometrinya kelihatan lebih ringkas daripada model asal. Nilai pertukaran tidak patut diukur melalui persamaan visual semata-mata.
Tiga lapisan yang perlu sampai
Pertukaran IFC yang berguna lazimnya perlu memelihara tiga lapisan secara serentak.
1. Geometri
Bentuk, saiz, lokasi, orientasi, bukaan dan koordinat mesti cukup tepat untuk tujuan yang dinyatakan. Geometri yang sesuai untuk semakan ruang belum tentu cukup untuk fabrikasi.
2. Data alfanumerik
Jenis, klasifikasi, bahan, kod sistem, fire rating, status, pengeluar, aset, waranti dan parameter lain mesti dipetakan kepada entiti serta property set yang boleh dibaca oleh penerima.
3. Struktur dan hubungan
Objek perlu berada dalam hierarki projek, tapak, bangunan, aras, ruang dan sistem yang betul. Pintu tanpa hubungan kepada dinding atau ruang, peralatan tanpa sistem, atau elemen tanpa klasifikasi mungkin masih kelihatan di skrin tetapi kehilangan konteks operasinya.
| Tujuan pertukaran | Geometri yang kritikal | Data dan hubungan yang kritikal |
|---|---|---|
| Koordinasi | Lokasi, saiz, clearance, koordinat | Disiplin, sistem, status, identiti objek |
| Kuantiti | Dimensi dan pecahan objek yang konsisten | Jenis, bahan, klasifikasi, unit |
| Perolehan | Representasi yang cukup untuk mengenal pasti produk | Spesifikasi, prestasi, kod item, pakej kerja |
| Operasi | Lokasi aset dan hubungan dengan ruang atau sistem | Asset ID, serial, waranti, jadual servis, pengeluar |
Satu eksport tidak semestinya memenuhi semua tujuan ini. Kandungan minimum perlu ditetapkan bagi setiap pertukaran.
Sebelum export, bina kontrak pertukaran
Arahan “hantar IFC” terlalu umum. Ia tidak menjelaskan apa yang perlu dihantar, kepada siapa, bila, atau untuk keputusan apa.
Sekurang-kurangnya, pasukan perlu bersetuju tentang tujuh perkara berikut.
1. Tujuan dan penerima
Adakah fail digunakan untuk koordinasi, semakan pihak berkuasa, kuantiti, tender, simulasi, perolehan atau operasi? Siapa yang akan menggunakan fail itu dan dalam aplikasi apa?
2. Tarikh pertukaran dan status
Nyatakan milestone, revision, status CDE dan batas penggunaan. IFC yang diterbitkan untuk koordinasi tidak secara automatik menjadi arahan pembinaan.
3. Skema dan profil pertukaran
Nyatakan versi atau skema yang disokong oleh aliran kerja penerima—contohnya IFC2x3, IFC4 atau IFC4.3—serta Model View Definition jika berkaitan. ISO 16739 menerangkan MVD sebagai subset definisi IFC untuk menyokong satu atau lebih penghantaran maklumat. Versi paling baharu belum tentu pilihan terbaik jika aplikasi penerima tidak menyokong aliran tersebut secara konsisten.
4. Skop objek
Tentukan disiplin, zon, aras, kategori dan elemen yang termasuk atau dikecualikan. Jangan biarkan penapis eksport menjadi keputusan senyap seorang operator.
5. Keperluan geometri
Tetapkan toleransi lokasi, koordinat rujukan, unit, pecahan elemen, bukaan, ruang kosong dan perkara yang perlu boleh diukur.
6. Keperluan data
Senaraikan entiti, klasifikasi, property set, nama parameter, jenis data, unit, nilai wajib dan nilai yang dibenarkan. Information Delivery Specification (IDS) buildingSMART membolehkan sebahagian keperluan alfanumerik IFC ditulis dalam bentuk boleh dibaca manusia dan ditafsir komputer untuk semakan automatik. IDS 1.0 menjadi standard rasmi buildingSMART pada Jun 2024. buildingSMART — Information Delivery Specification
IDS membantu menyatakan objek, klasifikasi, bahan, sifat dan nilai yang perlu dihantar. Namun buildingSMART menjelaskan bahawa IDS tidak meliputi aspek geometri. Maka toleransi, bentuk, lokasi dan semakan visual atau spatial masih memerlukan kriteria lain.
7. Kaedah semakan dan penerimaan
Nyatakan siapa menyemak, alat yang digunakan, bukti yang perlu diserahkan, had ralat dan keadaan yang menyebabkan fail diterima atau ditolak.
Lima kegagalan lazim yang tersembunyi di sebalik model cantik
Klasifikasi tidak konsisten
Objek kelihatan sebagai dinding atau peralatan, tetapi kod klasifikasi kosong atau bercampur. Hasilnya, penerima tidak dapat menapis, mengira atau menghubungkan objek kepada spesifikasi dan kos secara konsisten.
Property mapping tidak lengkap
Parameter penting wujud dalam model asal tetapi tidak dipetakan kepada property set IFC yang dijangka. Kadangkala nilai dihantar di bawah nama tersuai yang tidak dikenali oleh aliran kerja penerima.
Entiti terlalu generik
Komponen khusus dieksport sebagai IfcBuildingElementProxy walaupun terdapat entiti yang lebih sesuai. Objek masih muncul secara visual, tetapi semantik yang diperlukan untuk pengelasan atau automasi menjadi lemah.
Koordinat dan unit tidak terkawal
Model boleh berada jauh daripada titik rujukan, berputar, berbeza aras, atau menggunakan unit yang ditafsir secara salah. Setiap fail mungkin betul apabila dibuka sendirian, tetapi gagal apabila digabungkan.
Eksport diuji dalam aplikasi asal sahaja
Membuka semula fail dalam aplikasi yang menghasilkan eksport boleh mengesahkan satu pusingan dalaman, tetapi tidak membuktikan aplikasi penerima akan mentafsir maklumat dengan cara yang sama.
Validasi perlu berlaku dalam tiga lapisan
Lapisan 1 — Pematuhan teknikal IFC
Semak sintaks fail, skema dan peraturan normatif. IFC Validation Service buildingSMART menyediakan semakan pematuhan terhadap sintaks STEP, skema IFC dan peraturan normatif IFC. Perkhidmatan itu juga menyatakan dengan jelas bahawa ia tidak menyemak peraturan khusus projek, organisasi atau negara. buildingSMART — IFC Validation Service
Lulus pada lapisan ini bermaksud struktur fail mematuhi standard yang diperiksa. Ia belum membuktikan kandungan memenuhi kehendak projek.
Lapisan 2 — Pematuhan keperluan penghantaran
Semak sama ada objek, klasifikasi, sifat, nilai, kuantiti dan hubungan yang dipersetujui benar-benar hadir. IDS boleh mengautomasi sebahagian semakan data. Keperluan geometri, koordinat, toleransi, naming dan aturan projek perlu diperiksa menggunakan kaedah tambahan.
Lapisan 3 — Kebolehgunaan penerima
Buka fail dalam sekurang-kurangnya satu aplikasi atau viewer bebas daripada aplikasi pengarang. Jalankan tugasan sebenar: federasi, penapisan, pengukuran, pengiraan kuantiti, carian aset atau eksport data. Jika penerima tidak boleh menyelesaikan keputusan yang dinyatakan, pertukaran belum berjaya walaupun fail itu sah dari segi teknikal.
Valid tidak semestinya lengkap. Lengkap tidak semestinya sesuai untuk tujuan. Ketiga-tiga perkara—valid, lengkap dan boleh digunakan—perlu dibuktikan secara berasingan.
Contoh acceptance criteria yang boleh diuji
| Kriteria | Bukti penerimaan |
|---|---|
| Skema | Fail menggunakan skema yang dipersetujui dan lulus semakan sintaks serta skema |
| Koordinat | Model berfederasi pada titik rujukan dan orientasi yang dipersetujui |
| Skop | Semua disiplin, aras dan kategori dalam senarai penghantaran hadir |
| Semantik | Objek kritikal menggunakan entiti dan jenis yang dipersetujui |
| Data | Sifat wajib hadir dengan jenis data, unit dan nilai yang sah |
| Hubungan | Objek berkait dengan aras, ruang dan sistem yang diperlukan |
| Kebolehgunaan | Penerima berjaya menjalankan use case yang dinyatakan |
| Rekod | Laporan validasi, revision dan keputusan penerimaan disimpan dalam CDE |
Kriteria seperti “fail boleh dibuka” terlalu rendah. Kriteria seperti “model lengkap” pula terlalu kabur. Acceptance criteria yang baik boleh diperiksa, direkod dan diulang.
Checklist ringkas sebelum penghantaran IFC
- Nyatakan use case, penerima dan keputusan yang hendak disokong.
- Sahkan skema, MVD atau profil pertukaran yang disokong kedua-dua pihak.
- Bekukan skop objek dan tetapan eksport yang diluluskan.
- Semak koordinat, orientasi, unit, aras dan pembahagian model.
- Semak pemetaan klasifikasi, entiti, jenis dan property set.
- Uji nilai wajib, unit dan format data terhadap keperluan.
- Jalankan semakan pematuhan teknikal IFC.
- Buka dan uji dalam aplikasi bebas serta aplikasi penerima jika tersedia.
- Rekod isu, pembetulan, revision dan keputusan penerimaan dalam CDE.
- Jangan gantikan fail yang diterbitkan tanpa aliran revision dan kebenaran yang jelas.
Pandangan AYDI
Interoperability bukan pertandingan mencari format fail paling popular. Ia ialah disiplin menyatakan apa yang perlu bergerak, mengekalkan maksudnya semasa terjemahan dan membuktikan bahawa penerima boleh menggunakannya.
Interoperability bukan diukur melalui kejayaan membuka fail. Ia diukur melalui kemampuan penerima membuat keputusan yang dinyatakan menggunakan maklumat yang benar-benar sampai.
Jangan bermula dengan tetapan eksport. Bermula dengan keputusan.
Kemudian tentukan maklumat minimum, struktur, skema, kaedah semakan dan bukti penerimaan yang diperlukan.
Barulah tekan Export.
Nota rujukan: Artikel ini merujuk halaman rasmi buildingSMART untuk IFC, IDS dan IFC Validation Service serta ISO 16739-1:2024. Status dan skop sumber disemak pada 15 September 2026. Keperluan projek, kemampuan aplikasi dan tetapan eksport masih perlu disahkan oleh pihak penghantar serta penerima bagi setiap pertukaran.