กลับไปยังบล็อก BIM และ IFC
ดิจิทัลทวิน · 2026-10-10 · 8 นาที
ดิจิทัลทวินเมืองคืออะไร: ตัวอย่างแบบเรียลไทม์ 3 แห่งที่คุณเปิดดูได้ทันที
ดิจิทัลทวินของเมืองคือโมเดล 3D ของสถานที่หนึ่งที่ยังคงเชื่อมต่อกับสิ่งที่เกิดขึ้นที่นั่น บทความนี้อธิบายว่าในทางปฏิบัติหมายถึงอะไร เลเยอร์ 5 ชั้นที่ประกอบขึ้นเป็นทวิน แต่ละชั้นมาจากไหน พร้อมตัวอย่างแบบเรียลไทม์ 3 แห่ง ได้แก่ บาร์เซโลนา เฮลซิงกิ และโตเกียว ที่ทำงานในเบราว์เซอร์ของคุณด้วยข้อมูลเปิด
ดิจิทัลทวินเมืองแบบเรียลไทม์ 3 แห่งเรียงกันใน IFC Viewer Online: จัตุรัสกาตาลุญญาในบาร์เซโลนา สถานีขนส่ง Elielinaukio ในเฮลซิงกิ และทางเข้าสถานีแห่งหนึ่งในโตเกียว แต่ละแห่งถูกระบายสีด้วยข้อมูลเปิดของเมืองนั้น
ดิจิทัลทวินเมือง (urban digital twin) คือโมเดล 3D ของส่วนหนึ่งของเมืองที่ยังคงเชื่อมต่อกับสิ่งที่เกิดขึ้นที่นั่น ตัวโมเดลบอกว่าอะไรอยู่ตรงไหน ทั้งพื้นดิน อาคาร ถนน และทรัพย์สินที่อยู่ในนั้น ส่วนการเชื่อมต่อบอกว่าสิ่งเหล่านั้นอยู่ในสถานะใดในขณะนี้ เช่น แท่นจอดจักรยานว่าง รถบัสจอดอยู่ที่ช่องจอด หรือรถไฟล่าช้า
Digital Twin Consortium นิยามดิจิทัลทวินว่าเป็น “ตัวแทนเสมือนของเอนทิตีและกระบวนการในโลกจริง ซึ่งซิงโครไนซ์ตามความถี่และความเที่ยงตรงที่กำหนด”[dtc] ความถี่คือส่วนที่โมเดลเมือง 3D ส่วนใหญ่ไม่มี คู่มือนี้แสดงให้เห็นว่าส่วนที่เหลือเป็นอย่างไร ผ่านทวิน 3 แห่งที่คุณเปิดดูได้ทันที แต่ละแห่งสร้างจากข้อมูลเปิดของเมืองนั้นและทำงานในเบราว์เซอร์
ประเด็นสำคัญ
- ดิจิทัลทวินคือโมเดลบวกกับการเชื่อมต่อแบบเรียลไทม์กับสถานที่ที่โมเดลนั้นจำลอง โมเดลเมือง 3D ที่ไม่มีการเชื่อมต่อนี้เป็นแผนที่ที่ดี แต่ไม่ใช่ทวิน
- ทวินของเมืองประกอบด้วยเลเยอร์ 5 ชั้นซ้อนกัน ได้แก่ พื้นดิน บริบทเมือง โมเดลทรัพย์สินแบบละเอียด การผูกข้อมูล (binding) และสถานะเรียลไทม์ แต่ละชั้นมาจากแหล่งที่ต่างกันและรีเฟรชตามจังหวะของตัวเอง
- เมื่อผู้เผยแพร่ข้อมูลอนุญาตคำขอจากเบราว์เซอร์ ทุกชั้นก็ทำงานในเบราว์เซอร์ของผู้เข้าชมได้ด้วยข้อมูลเปิด ไม่มีแพลตฟอร์ม และไม่มีเซิร์ฟเวอร์ของเรา
- บาร์เซโลนา เฮลซิงกิ และโตเกียวด้านล่างทำงานแบบเรียลไทม์ ทั้งแท่นจอดจักรยาน ช่องจอดรถบัส และทางเข้าสถานี ถูกระบายสีด้วยฟีดข้อมูลของแต่ละเมือง
อะไรทำให้โมเดลกลายเป็นทวิน
มีสามอย่าง และอย่างที่สามคือสิ่งที่คนมักข้ามไป:
- โมเดลของสถานที่จริง: เรขาคณิต อัตลักษณ์ (identity) และข้อมูลของสิ่งต่าง ๆ ในนั้น วางไว้ตรงตำแหน่งที่อยู่จริง
- การเชื่อมต่อกับสถานะปัจจุบันของสถานที่ ซึ่งรีเฟรชตามรอบเวลาที่กำหนดไว้ ทุกวินาทีสำหรับรถบัส ทุกนาทีสำหรับแท่นจอดจักรยาน และทุกชั่วโมงสำหรับคุณภาพอากาศ
- การนำสถานะนั้นไปใช้ เช่น แสดงบนโมเดล ตรวจสอบกับกฎที่ส่งการแจ้งเตือน และเก็บเป็นประวัติที่เล่นย้อนดูได้
หากไม่มีข้อที่สอง สิ่งที่คุณมีคือโมเดลเมือง 3D ซึ่งก็ยังมีประโยชน์ ญี่ปุ่นเผยแพร่โมเดลแบบเปิดของเมืองต่าง ๆ ผ่าน PLATEAU[plateau] เฮลซิงกิก็เผยแพร่โมเดลของตัวเอง[helsinki3d] ส่วนใหญ่อยู่ในมาตรฐานเปิด CityGML[citygml] โมเดลแบบนี้ต่างจากทวินอย่างไรทีละขั้น อธิบายไว้ใน BIM กับดิจิทัลทวินต่างกันอย่างไร
เลเยอร์ 5 ชั้นของทวินเมือง
เลเยอร์ 5 ชั้นของทวินบาร์เซโลนา ตั้งแต่ภูมิประเทศขึ้นไปจนถึงค่าที่อ่านได้แบบเรียลไทม์ ทุกตัวเลขมาจากไฟล์ฉากของทวินนี้
- พื้นดิน แบบจำลองความสูงที่ทุกอย่างวางอยู่ ในบาร์เซโลนาคือแบบจำลองภูมิประเทศความละเอียด 5 m ของ ICGC โมเดลจึงวางอยู่บนถนนพอดี แทนที่จะลอยอยู่เหนือถนนหรือจมลงไปใต้ถนน
- บริบทเมือง อาคารและถนนรอบทรัพย์สิน ในที่นี้มาจาก OpenStreetMap และวาดด้วยการฉายแผนที่ (projection) แบบเดียวกับโมเดล ขอบทางเท้าบนแผนที่จึงตรงกับขอบทางเท้าใน IFC
- โมเดลทรัพย์สิน สิ่งที่คุณต้องการรู้ข้อมูล ซึ่งจำลองไว้อย่างละเอียด ในที่นี้คือไฟล์ IFC 4.3 จำนวน 8 ไฟล์ ได้แก่ น้ำพุ สถานี Bicing พร้อมเสาแท่นจอด ทางเข้ารถไฟใต้ดิน และเครื่องชาร์จรถยนต์ไฟฟ้า แต่ละไฟล์วางตามค่าอ้างอิงพิกัดทางภูมิศาสตร์ (georeference) ของตัวเอง
- การผูกข้อมูล สิ่งที่เชื่อมฟีดเข้ากับองค์ประกอบ: แหล่งข้อมูลใด อุปกรณ์ใดในแหล่งนั้น องค์ประกอบ IFC ใด และใช้สีใดกับค่าใด หากไม่มีการผูกข้อมูล ข้อมูลเรียลไทม์ก็เป็นเพียงรายการตัวเลขที่อยู่ข้างโมเดล
- สถานะเรียลไทม์ ค่าที่อ่านได้ ซึ่งแต่ละรายการมีจังหวะของตัวเอง: Bicing ทุก 60 วินาที เครื่องชาร์จรถยนต์ไฟฟ้าทุก 5 นาที และคุณภาพอากาศทุก 15 นาที ค่าที่อ่านได้ซึ่งเก่ากว่าที่แหล่งข้อมูลกำหนดจะกลายเป็นสีเทา แทนที่จะถูกมองว่าเป็นข้อมูลล่าสุด
งานส่วนใหญ่และความล้มเหลวส่วนใหญ่อยู่ระหว่างเลเยอร์ เช่น โมเดลที่คลาดจากถนนของตัวเองไปไม่กี่เมตร การผูกข้อมูลที่หาองค์ประกอบไม่เจอเพราะแท่นจอดเป็นชิ้นส่วนของชุดประกอบ (assembly) หรือฟีดที่เวลาประทับ (timestamp) ไม่ได้หมายความอย่างที่เห็น กรณีศึกษาแต่ละกรณีด้านล่างอธิบายปัญหาหนึ่งในนั้น
ตัวอย่างแบบเรียลไทม์ 3 แห่ง
แต่ละตัวอย่างทำงานจากไฟล์ฉากไฟล์เดียวพร้อมข้อมูลเปิดของเมืองนั้น เปิดขึ้นมา คลิกที่องค์ประกอบใดก็ได้เพื่อดูข้อมูล และใช้ “สำรวจ” เพื่อไปยังจุดข้อมูลสดแต่ละจุด
บาร์เซโลนา: แท่นจอดจักรยานและเครื่องชาร์จรถยนต์ไฟฟ้า
จัตุรัสกาตาลุญญาแบบเรียลไทม์
โมเดล IFC 8 ชุดบนแผนที่ 3D ของบาร์เซโลนา แท่นจอด Bicing และช่องจอดของเครื่องชาร์จ Endolla เปลี่ยนสีตามฟีดของเมือง
เปิดโปรแกรมดู IFC แบบอินเทอร์แอกทีฟ
โมเดล IFC 8 ชุดที่อ้างอิงพิกัดทางภูมิศาสตร์แล้วรอบจัตุรัส โดยสถานี Bicing หมายเลข 65 และเครื่องชาร์จริมถนนผูกกับฟีดเรียลไทม์ของตัวเอง ส่วนการจราจรและคุณภาพอากาศแสดงเป็นเลเยอร์แผนที่ ขั้นตอนการสร้างทั้งหมด ตั้งแต่ฟีดไปจนถึงเสาแท่นจอดที่เปลี่ยนสี อยู่ใน ดิจิทัลทวินแบบเรียลไทม์ของจัตุรัสกาตาลุญญา
เฮลซิงกิ: รถบัสที่ช่องจอด
Elielinaukio ข้างสถานีกลางเฮลซิงกิ: ช่องจอดแต่ละช่องเปลี่ยนสีเมื่อรถบัสเข้าจอด รอ และเปิดประตู
โมเดล IFC 3 ชุด ได้แก่ สถานีรถไฟ มหาวิหาร และสถานีขนส่ง พร้อมช่องจอด 9 ช่องที่ผูกกับตำแหน่งยานพาหนะแบบเรียลไทม์ของ HSL ซึ่งส่งมาผ่าน MQTT ประมาณวินาทีละครั้งต่อรถหนึ่งคัน ทำไมใช้ MQTT ไม่ใช่ GTFS-Realtime และรหัสป้ายหยุดรถกลายเป็นช่องจอดได้อย่างไร อ่านได้ใน ดิจิทัลทวินสถานีขนส่งแบบเรียลไทม์ผ่าน MQTT
โตเกียว: ทางเข้าสถานีและป้ายรถราง
ทางออก A4 สถานีโทโจมาเอะ: สัญลักษณ์โทเอแสดงสถานะของสายโอเอโดะ ป้ายสถานีแสดงขบวนรถที่ชานชาลา และเสาป้ายรถเมล์แสดงรถบัสที่เพิ่งผ่านไป
สองสถานีที่ผูกกับข้อมูลเปิดของ ODPT ได้แก่ ตำแหน่งขบวนรถ สถานะการเดินรถ และฟีด GTFS-Realtime ของรถบัสโทเอ ซึ่งถอดรหัสบนหน้าเว็บ รายละเอียด รวมถึงสิ่งที่ ODPT บอกได้และบอกไม่ได้ อยู่ใน ดิจิทัลทวินสถานีในโตเกียวจากข้อมูลเปิด ODPT
ข้อมูลไปถึงโมเดลได้อย่างไร
สามช่องทางการรับส่งข้อมูล กฎเดียวกัน: เบราว์เซอร์อ่านฟีดได้ก็ต่อเมื่อผู้เผยแพร่ส่ง header CORS มาด้วย
ทุกคำขอส่งตรงจากเบราว์เซอร์ของผู้เข้าชมไปยังผู้เผยแพร่ข้อมูล ซึ่งทำได้ก็ต่อเมื่อผู้เผยแพร่ตอบกลับพร้อม header CORS ที่อนุญาตให้หน้าเว็บบนเว็บไซต์อื่นอ่านผลตอบกลับได้ ฟีดจักรยานและการชาร์จของบาร์เซโลนา สตรีม MQTT ของ HSL และเอนด์พอยต์สาธารณะของ ODPT ล้วนส่ง header นี้ แต่ฟีด GTFS-Realtime ของ HSL ไม่ส่ง ทวินเฮลซิงกิจึงใช้สตรีม MQTT แทน
ขีดจำกัดของทวินบนเบราว์เซอร์
- ข้อมูลส่วนตัวหรือข้อมูลที่ต้องใช้คีย์ ต้องมีเซิร์ฟเวอร์คั่นระหว่างเบราว์เซอร์กับแหล่งข้อมูล
- การจำลองที่ใช้การคำนวณหนัก โมเดลน้ำท่วม พลังงาน หรือการเคลื่อนที่ของฝูงชนทั้งย่าน ต้องใช้การประมวลผลมากเกินกว่าที่หน้าเว็บหนึ่งควรใช้
- การควบคุม ทวินที่สั่งเปิดปิดอุปกรณ์ต้องมีการยืนยันตัวตน บันทึกการตรวจสอบย้อนหลัง (audit trail) และการเชื่อมต่อที่เชื่อถือได้ ไม่ใช่ลิงก์สาธารณะ
- โทรศัพท์มือถือ ฉากเต็มรูปแบบผ่านการทดสอบบนเบราว์เซอร์เดสก์ท็อปแล้ว แต่บนโทรศัพท์ยังไม่ได้วัดผล
สร้างทวินจากโมเดลของคุณเอง
- วางไฟล์ IFC ของคุณบนแผนที่ เปิดไฟล์บนแผนที่ 3D แล้วตรวจดูว่าโมเดลไปอยู่ในตำแหน่งที่ควรอยู่หรือไม่: วิธีดู IFC บนแผนที่ 3D
- แก้ค่าอ้างอิงพิกัดทางภูมิศาสตร์หากโมเดลไม่ตรงตำแหน่ง โมเดลที่วางผิดที่ส่วนใหญ่ไม่มี IfcMapConversion หรือมีค่าที่ผิด: พิกัดและการอ้างอิงพิกัดทางภูมิศาสตร์ใน IFC
- เพิ่มฟีดและการผูกข้อมูล ชี้แหล่งข้อมูลอุปกรณ์ (device source) ไปยังฟีดที่ส่ง header CORS แล้วผูกเข้ากับองค์ประกอบตามคลาส IFC และชื่อ หรือตาม GlobalId
- แชร์ บันทึกเป็นไฟล์ฉากหรือบรรจุลงในลิงก์ แล้วฝังไว้ในที่ที่ผู้คนทำงานอยู่แล้ว: วิธีฝังโปรแกรมดู IFC
ดิจิทัลทวินเมืองคืออะไร: ตัวอย่างแบบเรียลไทม์ 3 แห่งที่คุณเปิดดูได้ทันที