IDS: Bagaimana Menukar Keperluan Maklumat kepada Semakan Model Automatik?

Sebuah pasukan projek menerima arahan berikut dalam spreadsheet:

Semua pintu kebakaran mesti mempunyai klasifikasi, fire rating dan nombor aset yang lengkap.

Arahan itu kelihatan jelas. Namun apabila lima orang menyemak model, lima tafsiran boleh muncul:

• adakah semua pintu termasuk, atau hanya pintu dalam zon tertentu?
• nama parameter yang betul ialah Fire Rating, FireRating atau istilah lain?
• adakah nilai 60, 60 min dan FR60 dianggap sama?
• adakah nombor aset wajib pada peringkat reka bentuk, tender atau penyerahan operasi?
• apakah bukti bahawa semua objek telah disemak secara konsisten?

Checklist manual masih berguna untuk menetapkan kehendak dan merekod keputusan. Masalah bermula apabila ayat yang sama bergantung pada tafsiran manusia, carian visual dan tetapan perisian yang berbeza.

Artikel SembangBIM sebelum ini membincangkan dua perkara yang berkait rapat: level of information need perlu bermula dengan tujuan, manakala pertukaran IFC perlu dinilai berdasarkan maklumat yang benar-benar sampai. Information Delivery Specification (IDS) menyambungkan kedua-duanya dengan menjadikan sebahagian keperluan IFC boleh diuji secara automatik.

Apa sebenarnya IDS?

IDS ialah standard buildingSMART untuk menyatakan keperluan maklumat dalam bentuk yang boleh ditafsir komputer. Fail .ids boleh digunakan bersama model IFC untuk memeriksa sama ada objek yang berkenaan mempunyai data yang diwajibkan, dilarang atau dibenarkan.

IDS 1.0 diluluskan sebagai standard rasmi buildingSMART pada 1 Jun 2024. Setakat semakan pada 22 September 2026, buildingSMART masih menyenaraikan versi 1.0 sebagai standard akhir, sementara penambahbaikan untuk versi akan datang sedang dikumpulkan.

Namun IDS bukan:

• alat untuk menghasilkan model;
• pengganti IFC;
• jaminan bahawa reka bentuk itu betul;
• pemeriksa semua aspek geometri; atau
• butang automatik yang membaiki data yang gagal.

Peranan IDS lebih khusus: ia memformalkan keperluan alfanumerik berasaskan IFC supaya pengarang dan penerima boleh menggunakan set peraturan yang sama.

Daripada keperluan kepada keputusan

Automasi tidak sepatutnya bermula dengan membuka perisian IDS. Ia bermula dengan keputusan yang perlu disokong.

IDS bukan pengganti kepada keperluan maklumat. Ia ialah salah satu cara untuk mengekod bahagian keperluan yang sesuai bagi semakan mesin.

Bagaimana satu peraturan IDS dibina?

Secara konsep, setiap spesifikasi mempunyai dua bahagian.

1. Applicability: objek mana yang tertakluk?

Pasukan perlu menentukan populasi objek yang hendak diuji. Contohnya:

• semua objek IfcDoor;
• pintu yang mempunyai klasifikasi tertentu;
• pintu dalam bahagian atau sistem tertentu; atau
• gabungan beberapa syarat tersebut.

Jika skop terlalu luas, perisian akan melaporkan objek yang tidak berkaitan. Jika terlalu sempit, objek yang sepatutnya diperiksa mungkin terlepas tanpa amaran.

2. Requirements: apakah yang objek itu perlu patuhi?

IDS boleh menyatakan syarat berkaitan perkara seperti:

• entiti IFC dan jenis yang sesuai;
• klasifikasi;
• atribut;
• property serta property set;
• bahan;
• hubungan partOf;
• kewujudan atau ketiadaan maklumat;
• jenis data; dan
• nilai tepat, senarai nilai, julat atau pola yang dibenarkan.

Keperluan juga boleh menggunakan cardinality untuk membezakan perkara yang wajib, pilihan atau dilarang. Ini jauh lebih jelas daripada arahan umum seperti “lengkapkan data pintu”.

Contoh: satu pintu, satu keputusan yang jelas

Bayangkan pasukan fasiliti perlu mengenal pasti pintu kebakaran yang akan dimasukkan ke dalam daftar aset. Sebelum penyerahan, projek bersetuju dengan peraturan ilustrasi berikut:

Nama set dan nilai tersuai dalam contoh ini mesti diganti dengan pemetaan sebenar projek. IDS tidak menentukan sendiri istilah projek; pasukan masih perlu menyelaraskan istilah, struktur IFC dan tanggungjawab pengisian.

Apabila fail IFC diperiksa, laporan boleh menunjukkan dengan tepat:

• pintu yang tiada FireRating;
• nilai yang tidak termasuk dalam senarai dibenarkan;
• AssetID yang tidak mengikut pola;
• objek yang salah klasifikasi; dan
• jumlah objek yang lulus atau gagal bagi setiap spesifikasi.

Ini mengubah perbincangan daripada “model nampak belum lengkap” kepada isu yang boleh dikenal pasti, diberikan kepada pemilik dan diuji semula.

Apa yang IDS tidak boleh buktikan?

Batas utama IDS ialah geometri. buildingSMART menerangkan IDS sebagai standard untuk maklumat alfanumerik IFC; ia tidak meliputi aspek geometri.

Dalam contoh pintu tadi, IDS tidak membuktikan bahawa:

• daun pintu berayun ke arah yang betul;
• pintu bertembung dengan dinding, peralatan atau laluan;
• lebar bukaan sebenar dalam geometri memenuhi keperluan akses;
• lokasi pintu berada dalam toleransi yang dipersetujui;
• simbol dan rupa grafik betul; atau
• reka bentuk kebakaran telah diluluskan oleh pihak berkuasa.

Jika lebar pintu dihantar sebagai property atau quantity, IDS boleh memeriksa nilai data itu. Tetapi ia tidak semestinya mengukur geometri dan membuktikan bahawa bentuk model sepadan dengan nilai tersebut. Perbezaan ini penting: data yang lulus tidak secara automatik mengesahkan geometri.

Tiga lapisan semakan yang tidak patut dicampurkan

Lapisan 1 — Kesahan teknikal IFC

Semak sintaks, skema dan peraturan normatif IFC. IFC Validation Service buildingSMART menjalankan semakan jenis ini, tetapi tidak menyemak peraturan khusus projek, organisasi atau negara.

Lapisan 2 — Pematuhan keperluan data

Semak IFC terhadap IDS: adakah objek yang disasarkan mempunyai entiti, klasifikasi, property, bahan, hubungan dan nilai yang dipersetujui?

Lapisan 3 — Geometri dan kebolehgunaan

Jalankan semakan koordinasi, lokasi, toleransi, bentuk dan tugasan sebenar penerima. Ini mungkin melibatkan pemeriksaan visual, clash detection, peraturan geometri, simulasi atau semakan profesional.

Sebuah model boleh lulus satu lapisan dan gagal pada lapisan lain. Keputusan penerimaan perlu menyatakan lapisan yang telah diperiksa, alat yang digunakan dan batas keputusan itu.

Aliran kerja projek yang praktikal

1. Nyatakan keputusan. Tentukan use case, penerima, milestone dan tujuan data.
2. Pilih maklumat minimum. Elakkan meminta semua data hanya kerana ia mungkin berguna suatu hari nanti.
3. Selaraskan istilah. Tetapkan nama, definisi, unit, sumber klasifikasi dan senarai nilai terkawal.
4. Petakan kepada IFC. Tentukan entiti, atribut, property set, jenis data dan hubungan yang tepat.
5. Tulis serta uji IDS lebih awal. buildingSMART mengesyorkan IDS disediakan sebelum penghasilan data supaya pengarang mengetahui kehendak sejak awal.
6. Uji satu sampel kecil. Gunakan beberapa objek lulus dan gagal untuk memastikan peraturan serta perisian memberi hasil yang dijangka.
7. Semak sebelum penghantaran. Pengarang menjalankan IDS sebagai pre-flight check, membaiki isu dan mengeksport semula IFC.
8. Sahkan struktur IFC. Jalankan semakan teknikal IFC sebelum semakan khusus projek.
9. Jalankan IDS dan semakan geometri. Simpan laporan secara berasingan supaya jenis kegagalan tidak bercampur.
10. Rekod keputusan dalam CDE. Kaitkan laporan, revision, pengecualian dan status penerimaan dengan penghantaran yang betul.

Kegagalan lazim semasa melaksanakan IDS

Menulis IDS daripada model sedia ada

Jika pasukan hanya menyalin struktur model semasa, kesilapan dan kompromi lama boleh bertukar menjadi “keperluan”. Mulakan dengan tujuan, bukan keadaan model.

Meminta terlalu banyak data terlalu awal

Ribuan semakan yang tidak berkaitan dengan keputusan semasa hanya menghasilkan bunyi. Keperluan perlu sepadan dengan milestone dan pihak yang bertanggungjawab.

Mengabaikan pemetaan eksport

Data mungkin betul dalam aplikasi pengarang tetapi hilang atau berubah tempat semasa eksport IFC. Uji fail yang benar-benar dihantar, bukan model asal sahaja.

Tidak menyelaraskan nilai

60, 60 min, 60-minute dan FR60 boleh membawa maksud yang serupa kepada manusia tetapi berbeza kepada mesin. Gunakan istilah dan senarai nilai yang dipersetujui.

Menganggap laporan lulus sebagai kelulusan reka bentuk

IDS membuktikan pematuhan kepada peraturan data yang ditulis—tidak lebih daripada itu. Peraturan yang salah, tidak lengkap atau terlalu sempit masih boleh menghasilkan laporan hijau.

Checklist sebelum IDS dijadikan acceptance gate

• Adakah setiap spesifikasi mempunyai tujuan dan pemilik yang jelas?
• Adakah applicability menangkap semua objek yang patut diperiksa tanpa memasukkan objek tidak berkaitan?
• Adakah istilah, klasifikasi, property set, jenis data, unit dan nilai telah dipersetujui?
• Adakah peraturan diuji menggunakan sampel lulus, gagal dan kes pinggir?
• Adakah aplikasi pengarang, pengeksport IFC dan pemeriksa IDS diuji sebagai satu aliran?
• Adakah semakan geometri dan profesional ditetapkan secara berasingan?
• Adakah ambang penerimaan, pengecualian dan proses pembetulan direkodkan?
• Adakah laporan dikaitkan kepada revision IFC yang tepat dalam CDE?

Pandangan AYDI

Keperluan yang hanya boleh dibaca belum tentu boleh diperiksa secara konsisten. Automasi bermula apabila kehendak projek diterjemahkan kepada peraturan yang jelas, boleh diuji dan mempunyai pemilik.

IDS tidak menjadikan keperluan yang kabur lebih bijak. Ia menjadikan kekaburan lebih mudah dikesan—sebelum maklumat sampai kepada penerima.

Mulakan dengan keputusan. Tentukan maklumat minimum. Petakan kepada IFC. Gunakan IDS untuk bahagian yang boleh diuji oleh mesin, dan kekalkan semakan geometri serta pertimbangan profesional di tempat yang sepatutnya.

Nota rujukan: Status IDS 1.0, skop semakan alfanumerik dan batas IFC Validation Service disemak terhadap sumber rasmi buildingSMART pada 22 September 2026. Contoh pintu ialah ilustrasi editorial; nama set, nilai dan acceptance criteria mesti diselaraskan dengan keperluan sebenar setiap projek.

---