การตรวจสอบ · 2026-06-28 · 20 นาที

เครื่องมือตรวจสอบโมเดล IFC: คู่มือฉบับสมบูรณ์เรื่องการตรวจสอบความถูกต้อง คุณภาพโมเดล และ IDS

Q: ผ่านการตรวจสอบสคีมาระดับ 1 แล้ว ข้ามการตรวจสอบคุณภาพระดับ 2 ได้หรือไม่

ไม่ได้ ระดับ 1 และระดับ 2 วัดคุณลักษณะที่ต่างกันโดยสิ้นเชิง ไฟล์ที่ถูกต้องตามสคีมาอาจไม่มีชุดคุณสมบัติเลย ชื่อองค์ประกอบว่าง ไม่มีการจำแนกประเภท และไม่มีเมทาดาทาตาม ISO 19650 จนได้เพียง 20 คะแนนในการตรวจสอบคุณภาพ คุณจึงต้องตรวจทั้งสองระดับเสมอ ระดับ 1 หมายถึง “ไฟล์ถูกบรรจุหีบห่อมาอย่างถูกต้อง” ส่วนระดับ 2 หมายถึง “ของที่อยู่ข้างในตรงกับที่ร้องขอไว้”

คู่มือเครื่องมือตรวจสอบโมเดล IFC: สคีมา คุณภาพโมเดล (กฎ 44 ข้อ + Health Score) และ IDS คือการตรวจสอบสามชั้นที่เป็นอิสระต่อกัน การสับสนระหว่างสามชั้นนี้ทำให้การส่งมอบงานล้มเหลว บทความนี้แจกแจงครบทุกชั้นสำหรับผู้ประสานงาน BIM

เครื่องมือตรวจสอบโมเดล IFC: คู่มือฉบับสมบูรณ์เรื่องการตรวจสอบความถูกต้อง คุณภาพโมเดล และ IDS — IFC Viewer Online article cover

สรุปสั้น ๆ — การตรวจสอบความถูกต้องมีสามชั้นที่เป็นอิสระต่อกัน ระดับ 1 (ความสมบูรณ์ของไฟล์ IFC) ถามว่า ไฟล์ถูกต้องตามสคีมา IFC หรือไม่ ระดับ 2 (คุณภาพโมเดล) ถามว่า ข้อมูลครบถ้วนและใช้ประสานงานได้จริงหรือไม่ ระดับ 3 (IDS) ถามว่า ไฟล์เป็นไปตามข้อกำหนดด้านข้อมูลตามสัญญาของโครงการนี้หรือไม่ ต้องผ่านครบทั้งสามระดับก่อนการส่งมอบอย่างเป็นทางการ และการผ่านระดับหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกสองระดับเลย

3 — ชั้นการตรวจสอบที่เป็นอิสระต่อกัน
44 — กฎคุณภาพโมเดล
6 — facet ของ IDS (buildingSMART 1.0)
0 — ไบต์ที่ถูกอัปโหลด — ประมวลผลในเบราว์เซอร์เท่านั้น

ทุกการพูดคุยเรื่องการส่งมอบไฟล์ IFC มักไปชนกำแพงเดิมในที่สุด วิศวกรโครงสร้างบอกว่าไฟล์ผ่านการตรวจสอบแล้ว ผู้ประสานงาน BIM (BIM Coordinator) เห็นว่าชุดคุณสมบัติ (property set) หายไปครึ่งหนึ่งจึงถามว่าตรวจด้วยเครื่องมือตัวไหน ข้อกำหนดการแลกเปลี่ยนข้อมูล (EIR) ของผู้ว่าจ้างระบุข้อกำหนดแบบ IDS ที่ยังไม่มีใครตรวจเลย สภาพแวดล้อมข้อมูลร่วม (CDE) ปฏิเสธไฟล์ที่อัปโหลด สามสัปดาห์ต่อมา ทุกคนก็ยังสับสนว่าคำว่า “ถูกต้อง” หมายถึงอะไรกันแน่

ความสับสนนี้เข้าใจได้ เพราะคำว่า “การตรวจสอบความถูกต้อง” (validation) ครอบคลุมงานสามอย่างที่ต่างกันโดยสิ้นเชิงแต่ใช้ชื่อเดียวกัน การแยกแยะทั้งสามอย่างให้ชัดเจนจึงเป็นหนึ่งในสิ่งที่ส่งผลต่อโครงการมากที่สุดที่ผู้ประสานงาน BIM ทำได้

ปัญหาการตรวจสอบสามแบบที่ต่างกันโดยสิ้นเชิง

ลองนึกถึงการยื่นขออนุญาตก่อสร้าง เจ้าพนักงานควบคุมอาคารจะตรวจสามเรื่องแยกจากกัน คือ แบบอ่านได้ชัดเจนและครบถ้วนหรือไม่ (ความสมบูรณ์ของไฟล์) การออกแบบเป็นไปตามกฎหมายควบคุมอาคารหรือไม่ (คุณภาพและการปฏิบัติตามข้อกำหนด) และตรงกับโจทย์เฉพาะของผู้ว่าจ้างหรือไม่ (ข้อกำหนดของโครงการ) แบบที่อ่านได้ชัดเจนอาจละเลยข้อกำหนดด้านอัคคีภัยไปทั้งหมด แบบที่ผ่านข้อกำหนดด้านอัคคีภัยก็อาจไม่ตรงกับสเปกด้านเสียงของผู้ว่าจ้างเลย สิ่งเหล่านี้เป็นคำถามคนละข้อที่มีคำตอบคนละแบบ

ระดับ 1 — ความสมบูรณ์ของไฟล์ IFC

ไฟล์เป็น IFC ที่ถูกต้องตาม ISO 10303-21 และ ISO 16739-1 หรือไม่ GlobalId ไม่ซ้ำกันและมีรูปแบบถูกต้องหรือไม่ ลำดับชั้นเชิงพื้นที่สอดคล้องกันหรือไม่ เป็นการตรวจระดับสคีมาที่ให้ผลแบบผ่านหรือไม่ผ่าน

ระดับ 2 — คุณภาพโมเดล

ข้อมูลใช้ประสานงานได้จริงหรือไม่ ชุดคุณสมบัติมีค่าครบหรือไม่ องค์ประกอบตั้งชื่อตามรูปแบบที่กำหนดหรือไม่ มีการจำแนกประเภทหรือไม่ ระดับนี้คือสิ่งที่ชี้ขาดการส่งมอบจริง ไม่ใช่ความสอดคล้องกับสคีมา

ระดับ 3 — การตรวจสอบด้วย IDS

โมเดลเป็นไปตามข้อกำหนดด้านข้อมูลตามสัญญาของโครงการนี้หรือไม่ ข้อกำหนดจาก EIR และข้อกำหนดข้อมูลทรัพย์สิน (AIR) ถูกเข้ารหัสเป็นข้อกำหนดจำเพาะ (specification) ของ IDS ที่เครื่องอ่านได้ แล้วนำไปตรวจกับทุกองค์ประกอบทีละ facet

ทั้งสามชั้นนี้เป็นอิสระต่อกันโดยสิ้นเชิง ไฟล์อาจถูกต้องตามสคีมาในระดับ 1 แต่ใช้ประสานงานไม่ได้เลยเพราะไม่ได้ส่งออกชุดคุณสมบัติมาด้วย การตรวจ IDS อาจผ่านข้อกำหนดที่ประกาศไว้ทั้งหมด ขณะที่โมเดลมี GUID ซ้ำอยู่ 400 รายการ และ Health Score (คะแนนคุณภาพโมเดล) 91 ก็ไม่ได้บอกเลยว่าข้อกำหนดด้านอัตราการทนไฟของผู้ว่าจ้างถูกเข้ารหัสไว้และผ่านเกณฑ์หรือไม่ แต่ละชั้นตอบคำถามคนละข้อ และต้องผ่านครบทั้งสามชั้นก่อนการส่งมอบอย่างเป็นทางการ

ระดับ 1: ความสมบูรณ์ของไฟล์ IFC — ไฟล์นี้เป็น IFC ที่ถูกต้องหรือไม่

ระดับ 1 คือการตรวจสอบสคีมา ซึ่งตอบคำถามแบบใช่หรือไม่ใช่ว่า ไฟล์นี้เป็นไปตามสคีมา IFC (ISO 16739-1) และรูปแบบไฟล์กายภาพ (ISO 10303-21 STEP) หรือไม่ ตัวแยกวิเคราะห์ไฟล์ (parser) IFC ส่วนใหญ่ยอมรับไฟล์ที่ไม่ผ่านการตรวจระดับ 1 โดยไม่แจ้งเตือนใด ๆ เพราะถูกออกแบบมาให้ผ่อนปรน หากปฏิเสธอย่างเข้มงวดจะทำให้ขั้นตอนการทำงาน (workflow) จำนวนมากใช้การไม่ได้ ความผ่อนปรนนี้จึงซ่อนความเสียหายไว้จนกระทั่งปัญหาไปโผล่ที่กระบวนการปลายทาง

การตรวจความสมบูรณ์ระดับ 1 ครอบคลุมอะไรบ้าง

ความไม่ซ้ำของ GlobalId: ทุกเอนทิตีประเภท IfcRoot ต้องมี GlobalId ยาว 22 อักขระที่ไม่ซ้ำกัน โดยใช้ชุดอักขระ base-64 ของ IFC GlobalId ที่ซ้ำกันถือเป็นการละเมิดสคีมาที่ parser ยอมรับ แต่จะทำให้ขั้นตอนการทำงานด้วย BCF การจัดการเวอร์ชันใน CDE และทะเบียนทรัพย์สินสำหรับงานบริหารจัดการอาคาร (FM) เสียหายโดยไม่มีใครรู้ตัว
ความถูกต้องของรูปแบบ GlobalId: อักขระตัวแรกของ GlobalId ที่ถูกต้องเข้ารหัสได้เฉพาะค่า 0–3 เท่านั้น (สองบิตที่มีนัยสำคัญจาก UUID ขนาด 128 บิต) สคริปต์ที่ตัด UUID แบบตรง ๆ จะได้อักขระตัวแรกที่อยู่นอกช่วง ซึ่งผิดตามข้อกำหนด แม้ parser ส่วนใหญ่จะยอมรับ แต่เครื่องมือตรวจสอบที่เข้มงวดจะปฏิเสธ
ความครบถ้วนของลำดับชั้นเชิงพื้นที่: สคีมา IFC กำหนดให้มีลำดับ IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey โหนดที่ขาดหายไป (เช่น Building อยู่ใต้ Project โดยตรง หรือองค์ประกอบทางกายภาพอยู่ใน IfcSite) เป็นการละเมิดสคีมาที่ส่งผลจริงต่อกระบวนการปลายทาง
ความสมบูรณ์ของห่วงโซ่ IfcRelAggregates: เอนทิตีความสัมพันธ์ที่ประกอบกันเป็นผังโครงสร้างเชิงพื้นที่ต้องอ้างอิงถึงเอนทิตีที่มีอยู่จริง การอ้างอิงค้าง (dangling reference) ซึ่งความสัมพันธ์ชี้ไปยังเอนทิตีที่ถูกลบหรือไม่มีอยู่ จะทำให้การไล่ดูผังโครงสร้างใช้การไม่ได้ในทุกเครื่องมือปลายทาง
IfcRelContainedInSpatialStructure: องค์ประกอบทางกายภาพต้องอยู่ภายในองค์ประกอบเชิงพื้นที่ (โดยทั่วไปคือ IfcBuildingStorey) องค์ประกอบที่ไม่มีความสัมพันธ์การอยู่ในโครงสร้างเชิงพื้นที่คือองค์ประกอบกำพร้า (orphan element) ซึ่งมองไม่เห็นเมื่อไล่ดูตามโครงสร้างเชิงพื้นที่ในเครื่องมือส่วนใหญ่
มี IfcProject เพียงหนึ่งเดียว: ไฟล์ IFC ที่ถูกต้องทุกไฟล์ต้องมี IfcProject เพียงหนึ่งเดียวเป็นรากของลำดับชั้น โมเดลย่อยที่ไม่มี IfcProject อ่านได้โดยไม่เกิดข้อผิดพลาด แต่ไม่มีจุดยึดเชิงพื้นที่
ฟิลด์ส่วนหัว FILE_NAME และ FILE_DESCRIPTION: ส่วนหัวของไฟล์ STEP เก็บเมทาดาทาสำหรับการตรวจสอบย้อนกลับ ISO 19650-2 กำหนดให้ต้องกรอกฟิลด์เหล่านี้ แต่เครื่องมือส่วนใหญ่ปล่อยไว้เป็นสตริงว่าง
ความถูกต้องของเรขาคณิต: เมชแบบ non-manifold หน้าที่มีพื้นที่เป็นศูนย์ รูปทรงที่ทิศของ normal กลับด้าน และ B-rep ที่ตัดกันเอง ซึ่งสร้างเป็นรูปทรงตัน (solid) ที่ถูกต้องในเครื่องมือฝั่งผู้รับไม่ได้

สิ่งที่ระดับ 1 ไม่ได้ตรวจ

ชุดคุณสมบัติมีค่าครบหรือถูกต้องหรือไม่ — โมเดลที่ถูกต้องตามสคีมาแต่ไม่มี Pset เลยก็ยังผ่านระดับ 1
ชื่อองค์ประกอบเป็นไปตามรูปแบบการตั้งชื่อของโครงการหรือไม่
มีรหัสจำแนกประเภทหรือไม่ ถูกต้องหรือไม่ และสอดคล้องกันหรือไม่
เป็นไปตามข้อกำหนดด้านปริมาณตาม LOD (IfcElementQuantity ที่ LOD 300 ขึ้นไป) หรือไม่
โมเดลเป็นไปตามข้อกำหนดด้านข้อมูลเฉพาะโครงการหรือตามสัญญาใด ๆ หรือไม่

ความผิดพลาดด้านการตรวจสอบที่อันตรายที่สุดในงาน BIM คือ ทีมรัน buildingSMART Validation Service เห็นผลว่า “schema compliant” แล้วถือว่าโมเดลผ่านการตรวจสอบแล้ว ความสอดคล้องกับสคีมาไม่ได้บอกอะไรเกี่ยวกับคุณภาพข้อมูลเลย ไฟล์ที่ทุกองค์ประกอบมี Name='' และไม่มีชุดคุณสมบัติเลย ถือว่าถูกต้องตามสคีมาอย่างสมบูรณ์ แต่ใช้ประสานงานไม่ได้เลย

buildingSMART Validation Service สำหรับระดับ 1

buildingSMART IFC Validation Service (validate.buildingsmart.org) คือแหล่งอ้างอิงที่เชื่อถือได้สูงสุดสำหรับความสอดคล้องกับสคีมาในระดับ 1 เพราะใช้เอนจินเดียวกับที่ใช้รับรองซอฟต์แวร์ IFC ควรใช้เมื่อ คุณต้องรับรองไฟล์ IFC ที่ได้จากตัวส่งออก (exporter) ที่พัฒนาขึ้นเอง คุณกำลังแก้ปัญหาไฟล์ที่ parser แต่ละตัวอ่านได้ไม่เหมือนกัน หรือเมื่อสัญญามีข้อกำหนดให้ต้องมีใบรับรองสคีมาจาก buildingSMART อย่างชัดเจน

สิ่งที่บริการนี้ไม่ได้ทำ ได้แก่ การตรวจคุณภาพข้อมูล การตรวจรูปแบบการตั้งชื่อ การตรวจความครบถ้วนของชุดคุณสมบัติ การตรวจฟิลด์เมทาดาทาตาม ISO 19650 และการประเมินว่าโมเดลเป็นไปตามข้อกำหนดใด ๆ ของโครงการหรือไม่ บริการนี้เป็นเครื่องมือตรวจสคีมา ไม่ใช่ด่านตรวจก่อนส่งมอบงานของโครงการ

ตรวจไฟล์ IFC ที่ซับซ้อนจากงานจริง — ครบทั้งสามชั้นการตรวจสอบ

อาคารสำนักงานหลายชั้นที่ส่งออกจาก Revit เปิดแท็บการตรวจสอบ (Validation) เพื่อดูรายงานคุณภาพครบทั้ง 44 กฎพร้อม Health Score จากนั้นลองโหลดข้อกำหนดจำเพาะ IDS เพื่อดูการตรวจระดับ 3 บนโมเดลเดียวกัน

IFC4 · 14 MB

เปิดโปรแกรมดู IFC แบบอินเทอร์แอกทีฟ

ระดับ 2: การตรวจสอบคุณภาพโมเดล — ชั้นที่ชี้ขาดการส่งมอบจริง

การตรวจสอบคุณภาพโมเดลคือชั้นที่ผู้ประสานงาน BIM ส่วนใหญ่หมายถึงเมื่อพูดว่า “การตรวจสอบไฟล์ IFC” แม้จะไม่ค่อยเรียกมันว่าการตรวจสอบคุณภาพโมเดลก็ตาม ชั้นนี้ตอบคำถามเชิงปฏิบัติ เช่น มีข้อมูลอยู่ครบหรือไม่ ข้อมูลถูกต้องหรือไม่ สอดคล้องกันหรือไม่ และคนที่อยู่ปลายทางนำโมเดลนี้ไปใช้ประสานงาน วางแผนต้นทุน หรือใช้ในงาน FM ได้จริงหรือไม่

การตรวจสอบคุณภาพต่างจากระดับ 1 ตรงที่ไม่ได้ให้ผลแค่ผ่านหรือไม่ผ่าน แต่ละโมเดลมีโปรไฟล์คุณภาพที่ครอบคลุมหลายสิบมิติ Health Score (0–100) รวมมิติเหล่านี้เป็นตัวเลขเดียวที่เขียนลงในแผนการดำเนินงาน BIM (BEP) ได้ ติดตามได้ข้ามรีวิชัน และแนบไปกับใบนำส่ง (transmittal) เป็นหลักฐานคุณภาพของการส่งมอบได้

การตรวจสอบคุณภาพ 44 กฎครอบคลุมอะไรบ้าง

กฎเชิงโครงสร้างหลัก (18)

GUID ซ้ำ องค์ประกอบกำพร้า การอยู่ในโครงสร้างเชิงพื้นที่ผิดที่ ความสัมพันธ์แบบ aggregate เสียหาย ไม่มี IfcProject ชื่อองค์ประกอบว่าง และการวางชั้นไม่ถูกต้อง กฎกลุ่มนี้คือสาเหตุที่ทำให้ CDE ปฏิเสธไฟล์บ่อยที่สุดในทางปฏิบัติ

โครงสร้างเชิงพื้นที่ + ส่วนหัวไฟล์ (11)

ฟิลด์เมทาดาทาตาม ISO 19650 บน IfcProject การกรอกผู้จัดทำและองค์กรใน FILE_NAME ตำแหน่งไซต์เทียบกับพิกัดร่วม (shared coordinates) การเชื่อมโยงองค์ประกอบกับชั้น และความครบถ้วนของชั้นอาคาร

LOD การจำแนกประเภท และ MEP (9)

การมี IfcElementQuantity ที่ LOD 300 ขึ้นไป IfcRelAssociatesClassification บนองค์ประกอบงานโครงสร้างและงานสถาปัตยกรรม การเชื่อมต่อของระบบในงานระบบ (MEP) และการใช้ proxy มากเกินไป (สัดส่วนของ IfcBuildingElementProxy เป็น % ของโมเดล)

เรขาคณิต + ความสมบูรณ์ของชั้น (6)

ความถูกต้องของกรอบขอบเขต (bounding box) ขององค์ประกอบ ลำดับระดับความสูงของชั้น องค์ประกอบที่อยู่ต่ำกว่าระนาบพื้นดิน ชั้นที่ไม่มีแผ่นพื้น ระยะเยื้องของจุดกำเนิดพิกัดจาก WCS และการตรวจสอบการชนกัน (clash detection) ซึ่งเป็นกฎเสริมที่ปิดไว้โดยค่าเริ่มต้น

Health Score: คุณภาพโมเดลในตัวเลขเดียว

Health Score ใช้การถ่วงน้ำหนักการหักคะแนนแบบลอการิทึม ข้อผิดพลาดด้านสคีมามีน้ำหนักเป็น 3 เท่าของคำเตือน และคำเตือนมีน้ำหนักเป็น 3 เท่าของรายการระดับแจ้งให้ทราบ (info) ประเด็นเดียวกันที่เกิดเป็นครั้งที่ 1,000 จะถูกหักคะแนนน้อยกว่าครั้งที่ 10 มาก วิธีนี้ป้องกันไม่ให้โมเดลขนาดใหญ่ที่มีองค์ประกอบหนาแน่นดูแย่กว่าโมเดลขนาดเล็กที่องค์ประกอบเบาบางอย่างไม่สมเหตุสมผล ทั้งที่มีความหนาแน่นของปัญหาเท่ากัน โมเดลที่มีคำเตือนเรื่องการตั้งชื่อ 800 รายการอาจได้ 83 คะแนน ขณะที่โมเดลที่มีการอ้างอิงเชิงพื้นที่เสียหาย 12 จุดได้ 41 คะแนน สิ่งที่กำหนดคะแนนคือความรุนแรง ไม่ใช่ปริมาณ

31/100 — วิกฤต — ล้มเหลวเชิงโครงสร้าง ห้ามส่งมอบ
58/100 — ต่ำ — ต้องแก้ไขอย่างมาก
74/100 — พอใช้ — ยอมรับได้เฉพาะการทบทวนภายใน
87/100 — ดี — พร้อมส่งเข้า CDE
96/100 — ดีเยี่ยม — คุณภาพระดับหมุดหมายตาม ISO 19650

ระบุทั้งเกณฑ์และเครื่องมือไว้ใน BEP ไม่ใช่เขียนแค่ “ตรวจสอบไฟล์ IFC” แต่ให้เขียนว่า “ตรวจสอบด้วย [ชื่อเครื่องมือ] ให้ได้ Health Score ≥ 80 โดยวัดก่อนอัปโหลด และแนบรายงานไปกับใบนำส่ง” ข้อกำหนดด้านคุณภาพที่คลุมเครือจะได้คุณภาพที่คลุมเครือ ส่วนข้อกำหนดที่เจาะจง วัดผลได้ และระบุชื่อเครื่องมือ จะได้หลักฐานที่ส่งมอบได้จริง

สิ่งที่การตรวจสอบคุณภาพโมเดลไม่ได้ทำ

ยืนยันข้อกำหนดด้านข้อมูลเฉพาะโครงการ — นั่นคือหน้าที่ของระดับ 3 (IDS) กฎคุณภาพเป็นการตรวจตามแนวปฏิบัติที่ดีทั่วไป ไม่ใช่ EIR ของคุณ
แก้ไขโมเดล — การตรวจสอบคุณภาพให้ผลเป็นรายงาน การแก้ไขต้องทำในซอฟต์แวร์สร้างโมเดล หรือหากเป็นการแก้คุณสมบัติและ GUID ก็ทำได้ในโปรแกรมแก้ไขคุณสมบัติ IFC
ออกใบรับรองความสอดคล้องกับสคีมาที่กระบวนการรับรองของ buildingSMART กำหนด — นั่นคือหน้าที่ของระดับ 1 ผ่าน buildingSMART Validation Service
บอกว่าโมเดลถูกต้องทางเรขาคณิตหรือไม่ — แม้จะมีการตรวจความสมบูรณ์ของเรขาคณิตอยู่บ้าง แต่เครื่องมือตรวจสอบคุณภาพไม่ใช่เครื่องมือตรวจสอบการชนกันหรือซอฟต์แวร์สร้างโมเดล BIM

ระดับ 3: การตรวจสอบด้วย IDS — ข้อกำหนดการแลกเปลี่ยนข้อมูลในรูปโค้ดที่เครื่องอ่านได้

IDS (Information Delivery Specification) คือมาตรฐานของ buildingSMART สำหรับเข้ารหัสข้อกำหนดด้านข้อมูลเฉพาะโครงการในรูปแบบ XML ที่เครื่องอ่านได้ IDS คือส่วนเชื่อมที่ขาดหายไประหว่าง EIR ซึ่งเป็นเอกสาร Word กับเอนจินตรวจสอบที่ตรวจโมเดลเทียบกับ EIR ได้อย่างเป็นระบบ IDS 1.0 ได้เป็นมาตรฐานอย่างเป็นทางการของ buildingSMART ในปี 2023

buildingSMART IDS คืออะไรกันแน่

ไฟล์ IDS คือเอกสาร XML ที่มีข้อกำหนดจำเพาะ (specification) ตั้งแต่หนึ่งรายการขึ้นไป แต่ละข้อกำหนดจำเพาะมีส่วนขอบเขตการใช้ (applicability) ซึ่งระบุว่าใช้กับองค์ประกอบใด และส่วนข้อกำหนด (requirements) ซึ่งระบุว่าองค์ประกอบเหล่านั้นต้องมีอะไรบ้าง เอนจินจะตรวจทุกองค์ประกอบในโมเดลที่ตรงกับขอบเขตการใช้ ยืนยันว่าเป็นไปตามข้อกำหนดครบทุกข้อ แล้วรายงานผลผ่านหรือไม่ผ่านแยกตามองค์ประกอบและตามข้อกำหนดจำเพาะ ผลลัพธ์ที่ได้คือหลักฐานการตรวจสอบ (audit trail) ที่เครื่องสร้างขึ้น ซึ่งแสดงการปฏิบัติตามสัญญา

ชุดทดสอบอ้างอิงของ buildingSMART มีกรณีทดสอบอย่างเป็นทางการ 100 กรณี ซึ่งกำหนดพฤติกรรมที่คาดหวังของเอนจิน IDS ทุกตัวที่เป็นไปตามมาตรฐาน กล่าวได้ว่ากรณีทดสอบเหล่านี้คือตัวมาตรฐานในรูปที่รันได้จริง เอนจิน IDS ที่ผ่านกรณีทดสอบครบทั้ง 100 กรณีจึงพิสูจน์แล้วว่าจะตีความข้อกำหนดจำเพาะในไฟล์ .ids ได้สอดคล้องกับมาตรฐาน

facet ทั้งหกของ IDS

Entity: จำกัดขอบเขตการใช้หรือข้อกำหนดตามประเภทเอนทิตีของ IFC (IFCWALL, IFCDOOR, IFCBEAM) และระบุ predefined type เพิ่มได้ตามต้องการ นี่คือตัวกรองที่ข้อกำหนดจำเพาะส่วนใหญ่ใช้เป็นจุดเริ่มต้น
Attribute: ตรวจค่าแอตทริบิวต์ของ IFC ที่อยู่บนเอนทิตีโดยตรง ได้แก่ Name, Description, ObjectType, Tag และ PredefinedType แอตทริบิวต์เป็นคนละส่วนกับชุดคุณสมบัติ และตรวจด้วยวิธีที่ต่างกัน
Property: ตรวจคุณสมบัติที่ระบุชื่อภายในชุดคุณสมบัติที่ระบุชื่อ (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal) เป็น facet ที่ใช้บ่อยที่สุด รองรับการจำกัดชนิดข้อมูลและการจับคู่ค่ากับรูปแบบ (pattern matching)
Classification: ตรวจว่าองค์ประกอบมีการอ้างอิงการจำแนกประเภทผ่าน IfcRelAssociatesClassification ไม่ว่าจะเป็น Uniclass 2015, OmniClass, NBS หรือระบบที่กำหนดขึ้นเอง และจำกัดชื่อระบบจำแนกประเภทกับรูปแบบของรหัสได้
Material: ตรวจว่าองค์ประกอบมีการกำหนดวัสดุผ่าน IfcMaterial, IfcMaterialLayerSet หรือ IfcMaterialConstituentSet และจำกัดชื่อวัสดุได้ตามต้องการ ซึ่งมีประโยชน์กับข้อกำหนดด้านอัตราการทนไฟหรือด้านความยั่งยืน
PartOf: ตรวจว่าองค์ประกอบอยู่ในความสัมพันธ์เชิงพื้นที่หรือเชิงตรรกะที่กำหนด เช่น อยู่ภายในชั้น ถูกรวม (aggregate) เข้ากับระบบของอาคาร หรืออยู่ในอาคารที่ระบุ เป็น facet ที่ใช้บังคับให้องค์ประกอบบางประเภทเป็นไปตามลำดับชั้นเชิงพื้นที่

<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
  <ids:info>
    <ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
    <ids:description>Fire safety and classification requirements.</ids:description>
    <ids:ifcVersion>IFC4</ids:ifcVersion>
  </ids:info>
  <ids:specifications>

    <!-- All walls must carry a fire rating property -->
    <ids:specification name="Wall FireRating required" minOccurs="1">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property dataType="IFCLABEL">
          <ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
          <ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
        </ids:property>
      </ids:requirements>
    </ids:specification>

    <!-- Structural walls must carry a Uniclass 2015 classification -->
    <ids:specification name="Structural wall classification" minOccurs="0">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
          <ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:classification>
          <ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
        </ids:classification>
      </ids:requirements>
    </ids:specification>

  </ids:specifications>
</ids:ids>

จาก EIR สู่ IDS: ขั้นตอนการแปลงที่ทีมส่วนใหญ่ข้ามไป

EIR ระบุว่าผู้ว่าจ้างต้องการข้อมูลอะไร ส่วน IDS เข้ารหัสข้อกำหนดเหล่านั้นเพื่อให้เครื่องตรวจได้ การแปลงจาก EIR เป็น IDS คือขั้นตอนที่แทบไม่มีใครทำ เพราะต้องอาศัยคนที่เข้าใจทั้งข้อกำหนดด้านข้อมูลและสคีมา XML ของ IDS ดีพอจะเขียนข้อกำหนดจำเพาะที่ทดสอบสิ่งที่ EIR ร้องขอไว้พอดี ไม่มากและไม่น้อยกว่านั้น

ผลที่ตามมาคือ ทีมมักข้าม IDS ไปทั้งหมดแล้วพึ่งการทบทวนด้วยมือแบบไม่เป็นทางการตอนส่งมอบ หรือไม่ก็ใช้ไฟล์ IDS แบบทั่วไปที่ไม่ได้สะท้อน EIR จริงของโครงการ ทั้งสองทางล้วนสร้างความมั่นใจที่ผิด ๆ การตรวจ IDS ที่ผ่านเมื่อเทียบกับข้อกำหนดจำเพาะแบบทั่วไป ไม่ได้บอกอะไรเลยว่าข้อกำหนดเฉพาะของผู้ว่าจ้างของคุณได้รับการตอบสนองแล้วหรือไม่

IDS ตรวจเฉพาะสิ่งที่คุณระบุไว้เท่านั้น หากไฟล์ .ids ของคุณกำหนดให้ผนังต้องมี FireRating แต่ EIR ยังกำหนดให้ประตูต้องมี IsExternal องค์ประกอบโครงสร้างทุกชิ้นต้องมีรหัส Uniclass และแผ่นพื้นต้องมี IfcElementQuantity ด้วย โดยที่คุณไม่ได้เขียนข้อกำหนดจำเพาะเหล่านั้นไว้ เอนจิน IDS จะรายงานว่าผ่านข้อกำหนดทั้งหมด ขณะที่ EIR อีกครึ่งหนึ่งยังไม่ได้ถูกตรวจเลย การตรวจ IDS จึงมีคุณภาพได้ไม่เกินไฟล์ .ids ที่ใช้ขับเคลื่อนการตรวจ

IDS แบบโปรไฟล์: จุดเริ่มต้นที่ใช้ได้จริง

ไม่ใช่ทุกทีมที่เขียน IDS ขึ้นใหม่ตั้งแต่ต้น แนวทางที่ใช้ได้จริงคือดูแลคลังโปรไฟล์ IDS ที่นำกลับมาใช้ซ้ำได้ เช่น โปรไฟล์สำหรับงานสถาปัตยกรรมช่วง Stage 3 โปรไฟล์สำหรับงานระบบ MEP ช่วง Stage 4 และโปรไฟล์สำหรับการส่งมอบงานโครงสร้าง แต่ละโปรไฟล์ครอบคลุมข้อกำหนดที่พบบ่อยที่สุดของช่วงงานและสาขานั้น แล้วเพิ่มเติมข้อกำหนดเฉพาะของผู้ว่าจ้างเป็นรายโครงการ โปรไฟล์ IDS โหลดเข้าเอนจินตรวจสอบได้โดยตรงและนำมาประกอบกันได้ คุณสามารถรันไฟล์ .ids หลายไฟล์กับโมเดลเดียวกันแล้วรวมผลลัพธ์เข้าด้วยกัน

ทั้งสามระดับทำงานร่วมกันอย่างไร — ไปป์ไลน์การตรวจสอบ

ทั้งสามชั้นประกอบกันเป็นด่านตรวจคุณภาพ (quality gate) ที่โมเดลต้องผ่านไปตามลำดับ แต่ละระดับมีรอบการตรวจต่างกัน ระดับ 1 รันทุกครั้งที่ส่งออก (เป็นการตรวจเบื้องต้น) ระดับ 2 รันก่อนอัปโหลดเข้า CDE ทุกครั้ง (เป็นด่านตรวจคุณภาพ) ส่วนระดับ 3 รันก่อนถึงหมุดหมายการส่งมอบอย่างเป็นทางการ (เป็นการตรวจตามสัญญา) การรันผิดลำดับทำให้เสียเวลาเปล่า เพราะไม่มีประโยชน์อะไรที่จะรัน IDS กับไฟล์ที่ลำดับชั้นเชิงพื้นที่เสียหาย


  ┌──────────────────────────────────────────────────────┐
  │  EXPORT IFC from authoring tool                      │
  │  (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…)     │
  └───────────────────────┬──────────────────────────────┘
                          │
                          ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 1 — IFC Integrity                             │
  │  • GlobalId uniqueness & format (leading char 0–3)   │
  │  • Spatial hierarchy: Project→Site→Building→Storey   │
  │  • IfcRelAggregates chain integrity                  │
  │  • IfcRelContainedInSpatialStructure (no orphans)    │
  │  • Exactly one IfcProject                            │
  │  • FILE_NAME header traceability fields              │
  └─────────┬────────────────────────────────────────────┘
  Fail ◄────┤  Fix in authoring tool (or IFC property editor)
            │  Pass
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 2 — Model Quality (44 rules)                  │
  │  • Naming conventions / empty element names          │
  │  • Property set completeness (Pset_WallCommon etc.)  │
  │  • ISO 19650 metadata (IfcProject.LongName etc.)     │
  │  • Classification presence and consistency           │
  │  • LOD quantity sets, proxy audit, MEP connectivity  │
  │  → Health Score 0–100                                │
  └─────────┬────────────────────────────────────────────┘
  Score<80 ◄┤  Fix properties / names in IFC editor or authoring tool
            │  Score ≥ 80
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 3 — IDS Validation                            │
  │  • Project-specific EIR / AIR requirements           │
  │  • .ids specification(s) for this milestone          │
  │  • Six facets: entity, attribute, property,          │
  │    classification, material, partOf                  │
  └─────────┬────────────────────────────────────────────┘
  Fail ◄────┤  Fix per IDS issue report → export BCF → remediate
            │  All requirements met
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  DELIVER TO CDE                                      │
  │  Attach: Health Score report + IDS pass certificate  │
  └──────────────────────────────────────────────────────┘

ตารางเปรียบเทียบ: ระดับ 1 ระดับ 2 และระดับ 3

ประเด็น	L1: ความสมบูรณ์ของไฟล์ IFC	L2: คุณภาพโมเดล	L3: การตรวจสอบด้วย IDS
คำถามที่ตอบ	ไฟล์ถูกต้องตามสคีมา IFC หรือไม่	ข้อมูลใช้ประสานงานได้จริงหรือไม่	เป็นไปตามข้อกำหนดด้านข้อมูลของโครงการหรือไม่
มาตรฐาน	ISO 10303-21 (STEP), ISO 16739-1 (IFC)	แนวปฏิบัติที่ดีด้าน BIM และบรรทัดฐานตาม ISO 19650	buildingSMART IDS 1.0 (สคีมา XML)
ผู้กำหนด	buildingSMART (สคีมาตายตัว)	ทีม BIM / EIR (กฎที่ตกลงกันในโครงการ)	ผู้ว่าจ้าง / เจ้าของงาน (กำหนดรายโครงการ)
ผลลัพธ์	ผ่าน / ไม่ผ่าน + รายการข้อผิดพลาดด้านสคีมา	Health Score 0–100 + รายการประเด็นที่พบเรียงตามความสำคัญ	ผ่าน / ไม่ผ่าน แยกตามข้อกำหนดจำเพาะ
ใช้แทนระดับอื่นได้หรือไม่	ไม่ได้	ไม่ได้	ไม่ได้ — ต้องใช้ครบทั้งสามระดับ
รอบการตรวจ	ทุกครั้งที่ส่งออก IFC	ก่อนอัปโหลดเข้า CDE	ก่อนถึงหมุดหมายการส่งมอบ
ผ่านระดับนี้แต่ไม่ผ่านระดับอื่นได้หรือไม่	ไม่มี Pset ไม่มีชื่อ → ผ่าน L1 แต่ไม่ผ่าน L2	ขาดอัตราการทนไฟ (ตามข้อกำหนด IDS) → ไม่ผ่าน L3	GUID ซ้ำ ลำดับชั้นเชิงพื้นที่เสียหาย
ตัวอย่างเครื่องมือ	bSmart Validator, IFC Viewer Online	IFC Viewer Online, Solibri, IfcOpenShell	IFC Viewer Online (เอนจิน IDS), Solibri

ควรใช้ buildingSMART Validation Service เมื่อใด — การประเมินอย่างตรงไปตรงมา

buildingSMART IFC Validation Service ตรวจไฟล์เทียบกับสคีมาอย่างเป็นทางการด้วยเอนจินที่แบ่งเป็นหลายส่วน ได้แก่ ไวยากรณ์ของไฟล์กายภาพ STEP กฎ EXPRESS ของสคีมา IFC กฎข้อเสนอแบบไม่เป็นทางการ (informal proposition) ที่ได้มาจากข้อกำหนดของมาตรฐาน และกฎข้อจำกัดเชิงบรรทัดฐาน (normative) ของ IFC บริการนี้คือเครื่องมืออ้างอิงสำหรับความสอดคล้องกับสคีมาในระดับ 1

ควรใช้เมื่อ

รับรองไฟล์ IFC จากตัวส่งออกที่พัฒนาขึ้นเอง: ตัวตรวจของ buildingSMART ให้ผลอ้างอิงที่ใช้ในการรับรองซอฟต์แวร์ ในบริบทของการรับรอง ไม่มีผลจากเครื่องมืออื่นใดใช้แทนได้
วินิจฉัยความไม่สอดคล้องกันของ parser: เมื่อไฟล์เปิดได้ปกติในเครื่องมือหนึ่งแต่เกิดข้อผิดพลาดในอีกเครื่องมือหนึ่ง ตัวตรวจของ buildingSMART จะชี้ได้ว่าพฤติกรรมแบบใดถูกต้องตามสคีมา ซึ่งมีประโยชน์ในการวินิจฉัยปัญหา แม้ไฟล์นั้นจะใช้งานได้ตามปกติในด้านอื่นก็ตาม
สัญญากำหนดไว้: ข้อกำหนดการจัดซื้อจัดจ้างบางฉบับระบุให้ความสอดคล้องกับสคีมาตามเกณฑ์ของ buildingSMART เป็นเงื่อนไขของการส่งมอบ ในกรณีนี้ ใบรับรองจากบริการอย่างเป็นทางการคือสิ่งที่ทำให้เป็นไปตามข้อสัญญานั้น
ตรวจสอบตัวไฟล์ IDS เอง: ตัวตรวจสคีมา IDS ของ buildingSMART ตรวจว่าไฟล์ .ids ของคุณเป็นเอกสาร IDS ที่ถูกต้องหรือไม่ ซึ่งเป็นคนละเรื่องกับการนำไฟล์นั้นไปรันกับโมเดล

อย่าใช้แทนสิ่งต่อไปนี้

การตรวจสอบคุณภาพโมเดล — บริการนี้ไม่ได้ตรวจความครบถ้วนของชุดคุณสมบัติ รูปแบบการตั้งชื่อ การจำแนกประเภท หรือกฎคุณภาพข้อมูลใด ๆ
การตรวจสอบเฉพาะโครงการ — ความสอดคล้องกับสคีมาไม่ได้บอกอะไรเลยว่าโมเดลเป็นไปตาม EIR ของผู้ว่าจ้างหรือไม่
การยืนยันความพร้อมก่อนส่งเข้า CDE — โมเดลที่ถูกต้องตามสคีมาแต่มี Pset ว่างและไม่มีชื่อองค์ประกอบ จะผ่านตัวตรวจของ buildingSMART แต่ไม่ผ่านด่านตรวจคุณภาพที่มีความหมายใด ๆ

buildingSMART Validation Service ต้องอัปโหลดไฟล์ขึ้นไปตรวจ สำหรับโมเดลที่มีข้อมูลทรัพย์สินที่อ่อนไหว ข้อมูลผู้อยู่อาศัย หรือเมทาดาทาที่ถือเป็นข้อมูลส่วนบุคคลตามกฎหมายคุ้มครองข้อมูลของสหภาพยุโรป (GDPR) ให้ตรวจสอบก่อนใช้งานว่าการอัปโหลดไปยังบริการของบุคคลที่สามเป็นไปตามข้อกำหนดด้านการจัดการข้อมูลของโครงการหรือไม่

เครื่องมือตรวจสอบ IFC บนคลาวด์ กับเครื่องมือตรวจสอบ IFC บนเบราว์เซอร์

ความแตกต่างระหว่างการตรวจสอบบนคลาวด์ (อัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ระยะไกล) กับการตรวจสอบบนเบราว์เซอร์ (ประมวลผลไฟล์ภายในเครื่องด้วย WebAssembly) สำคัญกว่าที่ทีมส่วนใหญ่ตระหนัก โดยเฉพาะในโครงการภาครัฐ โครงการด้านการป้องกันประเทศ และโครงการเชิงพาณิชย์ที่มีข้อมูลอ่อนไหว

การตรวจสอบบนเบราว์เซอร์

ไฟล์ IFC ไม่ออกจากอุปกรณ์เลย
สอดคล้องกับ GDPR ตั้งแต่การออกแบบ — ไม่มีการถ่ายโอนข้อมูล
ใช้งานออฟไลน์ได้ ทั้งตอนลงหน้างานและในเครือข่ายที่ถูกจำกัด
ไม่มีโควตาการอัปโหลดหรือข้อจำกัดขนาดไฟล์
ได้ผลทันที — ไม่มีความหน่วงจากการรับส่งข้อมูลผ่านเครือข่าย
ประสิทธิภาพคงที่ ไม่ขึ้นกับภาระของเซิร์ฟเวอร์
ไม่ต้องมีบัญชี คีย์ API หรือการสมัครสมาชิก
ใช้งานได้ในเครือข่ายที่ภาครัฐจำกัดการเข้าถึง

การตรวจสอบบนคลาวด์

อัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ระยะไกลเพื่อประมวลผล
ต้องมีข้อตกลงการประมวลผลข้อมูล (DPA) เพื่อให้เป็นไปตาม GDPR
เหมาะกับไปป์ไลน์ตรวจสอบอัตโนมัติแบบ CI/CD
มีบันทึกการตรวจสอบ (audit log) ส่วนกลางครอบคลุมทุกโครงการและทุกทีม
เชื่อมต่อผ่าน API และ webhook เพื่อทำให้การส่งมอบเป็นอัตโนมัติ
ขยายระบบในแนวนอนได้เพื่อประมวลผลโมเดลจำนวนมากเป็นชุด
รันแบบ headless ได้โดยไม่ต้องเปิดเบราว์เซอร์
สืบค้นผลลัพธ์จากการรันย้อนหลังได้

กรณีที่การตรวจสอบบนคลาวด์เหมาะสม

ไปป์ไลน์ CI/CD อัตโนมัติ: เมื่อต้องการให้การตรวจสอบเริ่มทำงานเองทุกครั้งที่มีการคอมมิตหรืออัปโหลดโมเดล คล้ายกับที่ทีมซอฟต์แวร์รันการทดสอบอัตโนมัติทุกครั้งที่ push โค้ด กรณีนี้ API บนคลาวด์ที่มี webhook คือสถาปัตยกรรมที่เหมาะสม
การตรวจสอบทั้งองค์กร: เมื่อผู้จัดการ BIM ต้องการบันทึกส่วนกลางของการตรวจสอบทุกครั้งในหลายโครงการและหลายทีม บริการคลาวด์รวบรวมข้อมูลและดูแนวโน้มข้ามการรันแต่ละครั้งได้ ในแบบที่เครื่องมือซึ่งทำงานแยกเครื่องทำไม่ได้
การประมวลผลเป็นชุด: การตรวจคลังโมเดลที่มีอยู่แล้ว เช่น ไฟล์ IFC ทั้งหมดที่ส่งเข้า CDE ในช่วงสองปีที่ผ่านมา ทำได้จริงด้วยโหมดประมวลผลเป็นชุดบนคลาวด์ แต่ไม่สมเหตุสมผลที่จะทำด้วยมือในเบราว์เซอร์
โมเดลที่ไม่มีข้อมูลอ่อนไหว: สำหรับโครงการที่ข้อกำหนดด้านการจัดการข้อมูลไม่ได้ห้ามการอัปโหลดขึ้นคลาวด์ เครื่องมือตรวจสอบบนคลาวด์ให้การเชื่อมต่อกับ CI/CD ที่เครื่องมือบนเบราว์เซอร์เทียบไม่ได้

กรณีที่การตรวจสอบบนเบราว์เซอร์เป็นทางเลือกที่ดีกว่า

โครงการภาครัฐและด้านการป้องกันประเทศ: โมเดลของโครงสร้างพื้นฐานสาธารณะ สถานที่ด้านการทหาร และทรัพย์สินที่ต้องรักษาความปลอดภัย มักมีข้อจำกัดด้านการจัดการข้อมูลที่ห้ามอัปโหลดไปยังบริการของบุคคลที่สาม การตรวจสอบบนเบราว์เซอร์จึงเป็นทางเลือกเดียวที่เป็นไปตามข้อกำหนด
โครงการที่อยู่อาศัยและเชิงพาณิชย์ที่มีข้อมูลอ่อนไหว: โมเดล BIM มักมีข้อมูลผู้อยู่อาศัย ที่อยู่ของเจ้าของ และเมทาดาทาของทรัพย์สินที่ถือเป็นข้อมูลส่วนบุคคลตามมาตรา 4 ของ GDPR การประมวลผลข้อมูลเหล่านี้บนเซิร์ฟเวอร์ของบุคคลที่สามโดยไม่มี DPA ที่ถูกต้องและไม่มีฐานทางกฎหมายรองรับ ถือว่าไม่เป็นไปตามกฎหมาย
การใช้งานที่หน้างานและภาคสนาม: ไฟล์ IFC ขนาด 200 MB ที่อัปโหลดผ่านเครือข่าย 4G จะช้าและไม่เสถียร การตรวจสอบบนเบราว์เซอร์ประมวลผลไฟล์ภายในเครื่องได้ในไม่กี่วินาที โดยไม่ขึ้นกับแบนด์วิดท์ขาอัปโหลด
ตรวจเบื้องต้นก่อนอัปโหลดขึ้นคลาวด์: แม้ทีมจะใช้เครื่องมือตรวจสอบบนคลาวด์เป็นด่านตรวจอย่างเป็นทางการ การตรวจบนเบราว์เซอร์ก่อนจะจับปัญหาที่เห็นได้ชัดได้โดยไม่ต้องอัปโหลด ช่วยลดทั้งค่าใช้จ่ายการใช้งานคลาวด์และจำนวนครั้งที่ต้องอัปโหลด

มาตรา 4 ของ GDPR นิยามข้อมูลส่วนบุคคลไว้อย่างกว้าง ครอบคลุมถึงชื่อผู้ใช้อาคาร ที่อยู่ของเจ้าของ และบางครั้งรวมถึงรหัสอ้างอิงทรัพย์สิน หากรหัสนั้นเชื่อมโยงกลับไปยังบุคคลที่ระบุตัวตนได้ ก่อนอัปโหลดไฟล์ IFC ไปยังบริการคลาวด์ใด ๆ ให้ตรวจสอบว่าโมเดลมีข้อมูลส่วนบุคคลหรือไม่ และองค์กรของคุณมีฐานทางกฎหมายที่ถูกต้อง มี DPA ที่ลงนามแล้ว และมีมาตรการคุ้มครองการถ่ายโอนข้อมูลที่เหมาะสมหรือไม่

ความผิดพลาดด้านการตรวจสอบ 6 ข้อที่ทีม BIM มักทำ — และความหมายที่แท้จริง

ความผิดพลาดข้อ 1: “ผ่าน IDS แล้ว โมเดลใช้ได้”

IDS ตรวจเฉพาะสิ่งที่ข้อกำหนดจำเพาะในไฟล์ .ids ประกาศไว้เท่านั้น หากไฟล์ของคุณกำหนดให้ผนังต้องมี FireRating แต่ EIR ยังกำหนดให้ประตูต้องมี IsExternal องค์ประกอบโครงสร้างต้องมีรหัส Uniclass และแผ่นพื้นต้องมีชุดปริมาณ (quantity set) ด้วย โดยที่สิ่งเหล่านั้นไม่ได้เขียนไว้ในข้อกำหนดจำเพาะ เอนจินจะรายงานว่าผ่านข้อกำหนดทั้งหมด ขณะที่ EIR อีกครึ่งหนึ่งยังไม่ได้ถูกตรวจ การผ่าน IDS คือการยืนยันตามสัญญาเทียบกับข้อกำหนดจำเพาะฉบับหนึ่งโดยเฉพาะ ไม่ใช่ใบรับรองคุณภาพโดยรวม

ความผิดพลาดข้อ 2: “ตัวตรวจของ buildingSMART บอกว่าไฟล์ถูกต้อง”

ความถูกต้องตามสคีมาคือเกณฑ์ขั้นต่ำ ไม่ใช่เพดาน ไฟล์ที่ทุกองค์ประกอบมี Name='' และไม่มีชุดคุณสมบัติเลยถือว่าถูกต้องตามสคีมาอย่างสมบูรณ์ โมเดลที่ไม่มี IfcElementQuantity ไม่มีการจำแนกประเภท และองค์ประกอบทางกายภาพทุกชิ้นวางอยู่ใน IfcSite โดยตรงแทนที่จะอยู่ในชั้น ก็ถูกต้องตามสคีมาอย่างสมบูรณ์เช่นกัน การผ่านตัวตรวจของ buildingSMART หมายความว่าไฟล์ STEP มีรูปแบบถูกต้อง แต่ไม่ได้บอกอะไรเลยว่าข้อมูลใช้งานได้จริงหรือไม่

ความผิดพลาดข้อ 3: “เปิดในโปรแกรมดูไฟล์ได้ แสดงว่าไม่มีปัญหา”

โปรแกรมดูไฟล์ IFC (IFC viewer) ถูกออกแบบมาให้ผ่อนปรน เพราะสร้างขึ้นเพื่อแสดงเรขาคณิตไม่ว่าคุณภาพข้อมูลจะเป็นอย่างไร โปรแกรมดูที่ไม่ยอมเปิดไฟล์ที่ผิดสคีมาหรือมีข้อมูลไม่ครบคงใช้งานไม่ได้ การที่เรขาคณิตแสดงผลได้ถูกต้องไม่ได้บอกอะไรเลยเกี่ยวกับความครบถ้วนของชุดคุณสมบัติ รูปแบบการตั้งชื่อ ความคงที่ของ GUID การจำแนกประเภท หรือมิติคุณภาพใด ๆ ในทั้ง 44 ข้อ การดูไฟล์จึงเป็นคนละเรื่องกับการตรวจสอบไฟล์โดยสิ้นเชิง

ความผิดพลาดข้อ 4: ตรวจแค่เรขาคณิต ไม่สนใจข้อมูลคุณสมบัติ

สิ่งที่หลายคนทำโดยอัตโนมัติคือเปิดไฟล์ IFC ดูโมเดล 3 มิติ แล้วถ้าอาคารดูถูกต้องก็ถือว่าไฟล์เสร็จแล้ว แต่เรขาคณิตคิดเป็นเพียงราว 30% ของสิ่งที่ทำให้ไฟล์ IFC มีประโยชน์ ชุดคุณสมบัติ การจำแนกประเภท ชื่อองค์ประกอบ การกำหนด Type และชุดปริมาณ คือสิ่งที่ระบบ FM ฝ่ายบริหารต้นทุน และทะเบียนทรัพย์สินใน CDE นำไปใช้จริง ไฟล์ที่เรขาคณิตถูกต้องแต่ชุดคุณสมบัติว่างเปล่าจะไม่ผ่านการส่งมอบ

ความผิดพลาดข้อ 5: ตรวจสอบเพียงครั้งเดียวตอนใกล้ถึงกำหนดส่ง

การมองว่าการตรวจสอบเป็นขั้นตอนสุดท้ายก่อนส่งงานเข้า CDE หมายความว่าคุณต้องแก้ปัญหาภายใต้แรงกดดันโดยไม่มีเวลาเผื่อ โมเดลที่พบประเด็นจากการตรวจสอบ 800 รายการในวันก่อนถึงกำหนดส่ง จะถูกส่งไปทั้งที่รู้ว่ามีปัญหา หรือไม่ก็ส่งไม่ทันกำหนด รอบการตรวจที่ถูกต้องคือ ระดับ 1 หลังการส่งออกทุกครั้ง ระดับ 2 ก่อนการทบทวนภายในทุกครั้ง (อย่างน้อยสัปดาห์ละครั้ง) และระดับ 3 สองสัปดาห์ก่อนถึงหมุดหมายอย่างเป็นทางการแต่ละครั้ง

ความผิดพลาดข้อ 6: มองข้ามความคงที่ของ GUID เมื่อส่งออกซ้ำ

GUID ที่ซ้ำกันภายในไฟล์เดียวเป็นปัญหาระดับ 1 ที่เครื่องมือตรวจสอบทุกตัวตรวจพบได้ แต่ความไม่คงที่ของ GUID เมื่อส่งออกซ้ำ ซึ่งองค์ประกอบเดิมได้ GlobalId ใหม่ทุกครั้งที่ส่งออกโมเดล เป็นสิ่งที่การตรวจสอบทีละไฟล์มองไม่เห็น เมื่อ GlobalId เปลี่ยนไประหว่างรีวิชัน ความคิดเห็นใน BCF การอ้างอิงองค์ประกอบใน CDE และแท็กทรัพย์สินในระบบ FM ทุกรายการจะกลายเป็นการอ้างอิงค้างโดยไม่มีใครรู้ตัว ปัญหานี้ต้องตรวจด้วยการเปรียบเทียบสองรีวิชันและตรวจการตั้งค่าการส่งออก ไม่ใช่แค่ตรวจสอบทีละไฟล์

ขั้นตอนการตรวจสอบที่ใช้ได้จริงสำหรับผู้ประสานงาน BIM

หลังส่งออก IFC ทุกครั้ง: รันการตรวจระดับ 1 ซึ่งใช้เวลาไม่ถึง 30 วินาทีในเครื่องมือตรวจสอบบนเบราว์เซอร์ตัวใดก็ได้ แก้ GlobalId ที่ซ้ำ องค์ประกอบกำพร้า และลำดับชั้นเชิงพื้นที่ที่ขาดตอน ก่อนที่ปัญหาจะสะสมพอกพูนข้ามรีวิชัน
ก่อนการทบทวนภายในทุกครั้ง (รายสัปดาห์หรือทุกสปรินต์): รันการตรวจสอบคุณภาพระดับ 2 แบบเต็ม แล้วดูแนวโน้มของ Health Score หากคะแนนลดลงเรื่อย ๆ ข้ามรีวิชัน แสดงว่ามีประเด็นใหม่เกิดขึ้น ให้หาต้นตอให้เจอก่อนที่จะกลายเป็นปัญหาซ้ำซาก
เมื่อได้รับโมเดลของสาขาใดก็ตามจากบุคคลภายนอก: รันระดับ 1 และระดับ 2 ก่อนนำไปรวมเป็นโมเดลรวม (federated model) โมเดลที่คุณได้รับอาจมีปัญหาที่จะติดเข้ามาในโมเดลประสานงานของคุณด้วย ให้ตรวจพบทันที ไม่ใช่หลังจากประสานงานบนโมเดลรวมที่เสียหายไปแล้วสามสัปดาห์
สองสัปดาห์ก่อนการส่งมอบตามหมุดหมายอย่างเป็นทางการทุกครั้ง: รันครบทั้งสามระดับ ตั้งเป้า Health Score ≥ 80 ก่อนตรวจ IDS เวลาสองสัปดาห์ทำให้แก้ไขได้โดยไม่ต้องเร่งรีบ แจ้งปัญหาแต่เนิ่น ๆ อย่าใช้เวลาเผื่อจนหมด
ก่อนอัปโหลดเข้า CDE: รันระดับ 2 และระดับ 3 แล้วแนบใบรับรอง Health Score และรายงานผลการผ่าน IDS ไปกับใบนำส่ง วิธีนี้สร้างหลักฐานการตรวจสอบที่มีเอกสารยืนยัน และทำให้ผู้จัดการข้อมูล (information manager) มีทุกอย่างที่ต้องใช้ในการตรวจรับงาน
หลังอัปเกรดเวอร์ชันซอฟต์แวร์สร้างโมเดลหรือเปลี่ยนการตั้งค่าการส่งออก: สร้างค่าฐาน (baseline) ของความคงที่ของ GUID ขึ้นใหม่ โดยเปรียบเทียบไฟล์ที่ส่งออกสองครั้งติดกัน การอัปเกรด Revit หรือการเปลี่ยนการตั้งค่าการส่งออกอาจเปลี่ยนวิธีสร้าง GlobalId ไปโดยไม่มีใครรู้ตัว

ทำให้รอบการตรวจเป็นระบบอัตโนมัติ: ตั้งการแจ้งเตือนในปฏิทินแบบเกิดซ้ำสำหรับการตรวจระดับ 2 ก่อนการประชุมประสานงานทุกครั้ง ให้ถือว่า Health Score ที่ลดลงเป็นประเด็นที่ต้องจัดการภายในสปรินต์ ไม่ใช่เรื่องฉุกเฉินก่อนส่งมอบ ทีมที่มาถึงหมุดหมายการส่งมอบพร้อมคะแนนสูงคือทีมที่ตรวจทุกสัปดาห์ ไม่ใช่ทีมที่ตรวจครั้งเดียวในคืนก่อนส่ง

เคล็ดลับจากผู้เชี่ยวชาญ

จัดลำดับตามคะแนนที่ถูกหัก ไม่ใช่ตามจำนวน

อย่าแก้ประเด็นตามลำดับปริมาณ ให้แก้ตามลำดับผลกระทบต่อ Health Score ฟิลด์เมทาดาทาของ IfcProject ที่ขาดไปสามฟิลด์อาจทำให้เสีย 15 คะแนน ขณะที่คำเตือนเรื่องการตั้งชื่อ 800 รายการอาจทำให้เสียรวมกันเพียง 8 คะแนน ใช้การแจกแจงตามระดับความรุนแรงเพื่อจัดลำดับตามผลกระทบ

ล็อกการตั้งค่าการส่งออกไว้ในเทมเพลต

ทุกครั้งที่ตั้งค่าการส่งออกใหม่ด้วยมือ ก็มีความเสี่ยงที่การตั้งค่าจะคลาดเคลื่อนไปจากเดิม ให้สร้างชุดการตั้งค่าส่งออก IFC แบบตั้งชื่อไว้ในซอฟต์แวร์สร้างโมเดล บันทึกไว้ในเทมเพลตของโครงการ และระบุการตั้งค่าที่กำหนดไว้ใน BEP การตั้งค่าที่คลาดเคลื่อน (configuration drift) คือต้นเหตุของปัญหาการส่งออกแบบ “ครั้งก่อนยังใช้ได้อยู่เลย” เกือบทั้งหมด

แปลง EIR เป็น IDS ตั้งแต่เริ่มโครงการ

แปลงข้อกำหนดที่สำคัญที่สุดใน EIR เป็นข้อกำหนดจำเพาะ IDS ภายในสองสัปดาห์แรกของโครงการ แม้จะเป็นไฟล์ .ids เพียงบางส่วนที่มีข้อกำหนดจำเพาะแค่ห้าหรือหกรายการ ก็ยังดีกว่าการทบทวน EIR ทั้งหมดด้วยมือตอนส่งมอบ และช่วยจับช่องว่างของข้อมูลที่เกิดขึ้นอย่างเป็นระบบได้ตั้งแต่เนิ่น ๆ ขณะที่ยังแก้ไขได้ด้วยต้นทุนต่ำ

ตรวจโมเดลของแต่ละสาขาก่อนนำมารวม

ในโมเดลรวม ปัญหาจากโมเดลของสาขาหนึ่งอาจบดบังหรือส่งผลร่วมกับปัญหาจากอีกสาขาหนึ่ง ตรวจให้ข้อมูลตั้งต้นสะอาด แล้วจึงรวมโมเดลที่สะอาดเข้าด้วยกัน หากตรวจสอบเฉพาะโมเดลประสานงานหลังรวมแล้ว จะระบุได้ยากขึ้นว่าประเด็นใดมาจากผู้จัดทำรายใด

คำถามที่พบบ่อย

ผ่านระดับ 1 แล้ว ข้ามระดับ 2 ได้หรือไม่

ไม่ได้ ระดับ 1 และระดับ 2 วัดคุณลักษณะของไฟล์ที่ต่างกันโดยสิ้นเชิง ไฟล์ที่ถูกต้องตามสคีมา (ระดับ 1) อาจไม่มีชุดคุณสมบัติเลย ชื่อองค์ประกอบว่าง ไม่มีการจำแนกประเภท และไม่มีเมทาดาทาตาม ISO 19650 จนได้เพียง 20 คะแนนในการตรวจสอบคุณภาพ (ระดับ 2) คุณจึงต้องตรวจทั้งสองระดับเสมอ ให้มองว่าระดับ 1 หมายถึง “ไฟล์ถูกบรรจุหีบห่อมาอย่างถูกต้อง” ส่วนระดับ 2 หมายถึง “ของที่อยู่ในหีบห่อตรงกับที่ร้องขอไว้”

IDS ใช้แทน buildingSMART Validation Service ได้หรือไม่

ไม่ได้ IDS ตรวจสอบข้อกำหนดด้านข้อมูลเฉพาะโครงการ (ระดับ 3) ส่วน buildingSMART Validation Service ตรวจสอบความสอดคล้องกับสคีมา (ระดับ 1) ทั้งสองทำงานคนละระดับโดยสิ้นเชิงและตอบคำถามคนละข้อ โมเดลที่ผ่าน IDS แต่ไม่ผ่านการตรวจสอบสคีมาถือเป็นความขัดแย้งทางตรรกะ เพราะความสมบูรณ์ในระดับ 1 เป็นเงื่อนไขเบื้องต้นที่ทำให้การตรวจสอบระดับ 3 มีความหมาย

สำหรับการส่งมอบงาน BIM ทั่วไป ควรให้ความสำคัญกับ facet ใดของ IDS ก่อน

Property facet ครอบคลุมข้อกำหนดใน EIR จากงานจริงราว 70–80% เพราะผู้ว่าจ้างส่วนใหญ่ต้องการให้กรอกค่าชุดคุณสมบัติที่เจาะจงบนประเภทองค์ประกอบที่เจาะจง Classification ครอบคลุมส่วนที่เหลือเกือบทั้งหมดสำหรับโครงการที่ใช้ระบบ Uniclass หรือ OmniClass ส่วน Entity facet ปรากฏในข้อกำหนดจำเพาะแทบทุกฉบับในฐานะตัวกรองขอบเขตการใช้ ขณะที่ Material และ PartOf ใช้กับข้อกำหนดตามสัญญาเฉพาะเรื่อง ให้เริ่มจาก Entity + Property เพิ่ม Classification หาก EIR ของคุณกำหนดไว้ แล้วค่อยขยายต่อจากนั้น

ตรวจสอบไฟล์ IFC โดยไม่ต้องอัปโหลดไปที่ใดเลยได้หรือไม่

ได้ เครื่องมือตรวจสอบที่ทำงานบนเบราว์เซอร์จะประมวลผลไฟล์ทั้งหมดภายในเบราว์เซอร์ของคุณด้วย WebAssembly ข้อมูลของไฟล์ IFC ไม่ออกจากอุปกรณ์ของคุณแม้แต่ไบต์เดียว กฎคุณภาพทั้ง 44 ข้อ การคำนวณ Health Score และเอนจิน IDS ทั้งหมดทำงานฝั่งไคลเอนต์ สำหรับโมเดลที่มีข้อจำกัดด้านการจัดการข้อมูล เช่น ทรัพย์สินของภาครัฐ ข้อมูลที่อยู่อาศัยที่อ่อนไหว หรือโครงสร้างพื้นฐานด้านการป้องกันประเทศ นี่มักเป็นทางเลือกเดียวที่เป็นไปตามข้อกำหนด

ควรกำหนดเกณฑ์ Health Score ไว้ใน BEP ที่เท่าใด

≥ 80 คือเกณฑ์มาตรฐานสำหรับการส่งงานเข้า CDE และการประสานงานด้านการออกแบบ ≥ 90 สำหรับการส่งงานช่วงพัฒนาแบบ (design development) ระดับ LOD 300 ขึ้นไป และการส่งงานตามหมุดหมายอย่างเป็นทางการตาม ISO 19650 ส่วน ≥ 70 ยอมรับได้สำหรับการทบทวนภายในช่วงแนวคิดการออกแบบ หากต่ำกว่า 60 แสดงว่าโมเดลมีปัญหาคุณภาพเชิงโครงสร้าง และไม่ควรส่งให้บุคคลภายนอกใด ๆ ไม่ว่าในกรณีใด

เครื่องมือเพียงตัวเดียวครอบคลุมการตรวจสอบทั้งสามระดับได้หรือไม่

บางเครื่องมือทำได้ IFC Viewer Online ครอบคลุมระดับ 1 (กฎความสมบูรณ์ของไฟล์ รวมถึงการตรวจ GUID ลำดับชั้น และส่วนหัวไฟล์) ระดับ 2 (การตรวจสอบคุณภาพ 44 กฎพร้อม Health Score) และระดับ 3 (เอนจิน IDS 1.0 ที่ผ่านการทดสอบกับกรณีทดสอบอย่างเป็นทางการของ bSI ครบทั้ง 100 กรณี) Solibri ครอบคลุมระดับ 2 และระดับ 3 ด้วยเอนจินกฎที่ซับซ้อนกว่า แต่ไม่ได้ประมวลผลบนเบราว์เซอร์ buildingSMART Validation Service ครอบคลุมเฉพาะระดับ 1 ส่วน IfcOpenShell เขียนสคริปต์ให้ตรวจระดับ 1 และระดับ 2 ได้

สรุป

ถูกต้องตามสคีมาไม่ได้แปลว่าถูกต้องตามโครงการ และถูกต้องตามโครงการก็ไม่ได้แปลว่าเป็นไปตาม EIR ต้องใช้การตรวจสอบครบทั้งสามชั้น และการเหมารวมทั้งสามชั้นเป็นเรื่องเดียวกันคือต้นเหตุของความล้มเหลวในการส่งมอบอย่างเป็นทางการเกือบทั้งหมด
บล็อก IFC Viewer

ระดับ 1: รันทุกครั้งที่ส่งออก

ความสมบูรณ์ตามสคีมา ความไม่ซ้ำและรูปแบบของ GlobalId และลำดับชั้นเชิงพื้นที่ ใช้เวลา 30 วินาที และจับความล้มเหลวเชิงโครงสร้างที่ทำให้ BCF การจัดการเวอร์ชันใน CDE และทะเบียนทรัพย์สิน FM ที่ปลายทางเสียหายโดยไม่มีใครรู้ตัว

ระดับ 2: ด่านตรวจของการส่งเข้า CDE ทุกครั้ง

กฎคุณภาพ 44 ข้อ Health Score รูปแบบการตั้งชื่อ ความครบถ้วนของชุดคุณสมบัติ และเมทาดาทาตาม ISO 19650 กำหนดเกณฑ์ ≥ 80 ไว้ใน BEP และ EIR ของคุณ ชั้นนี้คือสิ่งที่ทำให้โมเดลใช้งานได้จริง ไม่ใช่แค่อ่านไฟล์ได้

ระดับ 3: ยืนยันก่อนถึงหมุดหมายทุกครั้ง

ข้อกำหนดจำเพาะ IDS ที่เข้ารหัส EIR และ AIR ของคุณในรูปแบบที่เครื่องอ่านได้ แปลงข้อกำหนดสำคัญตั้งแต่เริ่มโครงการ ไม่ใช่สัปดาห์ก่อนส่งมอบ การผ่าน IDS คือหลักฐานการตรวจสอบตามสัญญาที่มีเอกสารยืนยัน

รันการตรวจสอบคุณภาพแบบเต็มกับโมเดลปัจจุบันของคุณ ใช้เวลาไม่ถึง 30 วินาทีในเบราว์เซอร์ใดก็ได้ และไม่มีการอัปโหลดใด ๆ จากนั้นอ่านคู่มือ IFC Health Score เพื่อทำความเข้าใจวิธีคำนวณคะแนนและเกณฑ์ที่ควรกำหนดใน BEP หากต้องแก้ค่าคุณสมบัติหรือ GUID ในไฟล์ที่ได้รับมา คู่มือโปรแกรมแก้ไขไฟล์ IFC ออนไลน์ฟรี อธิบายการแก้ไขคุณสมบัติแบบไม่ทำลายข้อมูลเดิม (non-destructive) โดยไม่ต้องย้อนกลับไปแก้ในซอฟต์แวร์สร้างโมเดล และสำหรับความล้มเหลวเชิงโครงสร้างที่พบบ่อยที่สุดซึ่งทำให้ไม่ผ่านระดับ 1 ดูได้ที่ข้อผิดพลาดในการตรวจสอบไฟล์ IFC ที่พบบ่อยที่สุด 7 ข้อ

เครื่องมือตรวจสอบโมเดล IFC: คู่มือฉบับสมบูรณ์เรื่องการตรวจสอบความถูกต้อง คุณภาพโมเดล และ IDS