TIS 30162: หลักฐาน Interoperability สำหรับ IIoT ไทย

ผู้ที่ค้นหา TIS 30162 และความเข้ากันได้ของ Industrial IoT มักไม่ได้ต้องการเพียงรายชื่อโปรโตคอล แต่ต้องการรู้ว่าจะเปรียบเทียบเซนเซอร์ PLC เกตเวย์ SCADA และแพลตฟอร์มข้อมูลจากหลายผู้ขายอย่างไร และหลักฐานใดพิสูจน์คำว่า “เชื่อมต่อกันได้” ในสภาพการผลิตจริง บทความนี้แปลง มอก. 30162-2568 ให้เป็นข้อกำหนดใช้งานได้จริงสำหรับ RFP อุปกรณ์ IIoT แบบหลายผู้ขาย ตาราง interoperability, PoC และการยอมรับ FAT/SAT

ข้อสรุป: ใช้ มอก. 30162 เป็นแผนที่หาช่องว่าง ไม่ใช่สติกเกอร์รับรอง

ข้อมูลทางการของสำนักงานมาตรฐานผลิตภัณฑ์อุตสาหกรรมระบุว่า มอก. 30162-2568 เป็นมาตรฐานทั่วไป เริ่มใช้วันที่ 13 มีนาคม 2569 และเป็นการพิมพ์ซ้ำ ISO/IEC 30162:2022 ในระดับเหมือนกันทุกประการโดยใช้อังกฤษเป็นหลัก ขอบข่ายครอบคลุมแบบจำลองเครือข่ายสำหรับการเชื่อมต่อ IIoT การโต้ตอบของโปรโตคอลรับส่งข้อมูล การทำงานร่วมกันและการจัดการข้อมูลแบบกระจาย กรอบการเชื่อมต่อ transport, network และแนวปฏิบัติ

ต้องมีข้อสงวนที่ชัดเจน: TISI ระบุว่าเป็น มาตรฐานทั่วไป บทความนี้ไม่ได้กล่าวว่าอุปกรณ์ IIoT การนำเข้าหรือระบบโรงงานทุกชนิดต้องได้รับการรับรอง มอก. 30162 การอ้างอิงมาตรฐานหรือคำตอบ “รองรับ” ของผู้ขายไม่ใช่หลักฐานโดยอัตโนมัติว่าผลิตภัณฑ์ผ่านการรับรองหรือชุดอุปกรณ์นั้นทำงานร่วมกันได้ โปรดตรวจข้อบังคับ เงื่อนไขลูกค้า และหน้าที่ด้านการรับรองของผลิตภัณฑ์และการใช้งานจริงกับหน่วยงานหรือผู้เชี่ยวชาญที่เหมาะสม

ในการจัดซื้อ ให้แปลงมาตรฐานเป็นผลงานสี่รายการ:

1. แผนภาพขอบเขตว่าระบบใดต้องทำงานร่วมกับระบบใด
2. ตารางโปรโตคอล profile โมเดลข้อมูล identity เวลา หน่วย quality และ security
3. หลักฐานจากผู้ขาย เช่น configuration, sample, log, export และขั้นตอน lifecycle
4. ขั้นตอน ผลที่คาด และหลักฐานตัดสิน FAT/SAT รวมกรณีผิดปกติ

หากยังอยู่ช่วงสำรวจ interface หรือยังไม่ล็อก RFP สามารถ ติดต่อ TOMAS TECH ได้ เราช่วยกำหนด PoC แบบหลายผู้ขายขนาดเล็กและหลักฐานรับงานก่อนที่ shortlist ผลิตภัณฑ์จะแก้ไขได้ยาก

สิ่งที่ มอก. 30162-2568 และ ISO/IEC 30162:2022 ยืนยันได้

แค็ตตาล็อกทางการของ ISO ระบุ ISO/IEC 30162:2022 เป็นฉบับที่ 1 เผยแพร่เดือนกุมภาพันธ์ 2022 สถานะ Published จำนวน 44 หน้า ส่วน TISI ระบุว่ามาตรฐานไทยเป็น identical reprint โครงการในไทยจึงใช้คำศัพท์และขอบข่ายเดียวกับเอกสารสากลได้

ตารางนี้ไม่แทนตัวมาตรฐาน แต่เป็นดัชนีสำหรับผู้ซื้อในการเปลี่ยนขอบข่ายกว้างให้เป็นเงื่อนไขที่สังเกตและทดสอบได้

เชื่อมต่อได้ไม่เท่ากับทำงานร่วมกันได้

ping สำเร็จ ส่ง MQTT ได้ หรือ browse OPC UA server ได้ เป็น milestone ที่สำคัญ แต่ยังไม่ใช่ interoperability ของโรงงาน ระบบปลายทางต้องตีความค่าได้ถูกต้อง ผูกกับ asset และเวลาที่ถูกต้อง ไม่สูญหายหรือนับซ้ำหลังการขัดข้อง และยังบำรุงรักษาได้เมื่อ certificate, firmware หรือ schema เปลี่ยน

เกตเวย์สองรุ่นอาจรองรับ MQTT 5.0 เหมือนกัน แต่ใช้ topic คนละโครงสร้างและไม่กำหนดหน่วย timestamp quality และ asset ID ส่วนผลิตภัณฑ์ OPC UA สองตัวก็ยังอาจต่างกันที่ NodeId, namespace, Companion Specification, EngineeringUnits, status และการจัดการ certificate

ถ้าชั้นใดไม่ชัด คำว่า “รองรับมาตรฐาน” ยังมีเงื่อนไข ต้องขอ version ข้อจำกัด option คู่ระบบที่เคยทดสอบ ส่วนที่ยังไม่ทดสอบ และวิธีแก้ ไม่ใช่เพียง Yes/No

วาดขอบเขต multi-vendor IoT ก่อนเลือกสินค้า

วางเซนเซอร์/เครื่องมือวัด PLC, edge gateway, industrial switch, broker, SCADA/historian และ MES/analytics จากซ้ายไปขวา ใส่ medium, protocol, profile, direction, data owner และ security boundary บนลูกศรทุกเส้น ไม่ว่าจะ cloud หรือ on-premises ต้องระบุว่าใครถือ raw data ใครแปลงเป็น canonical model และใครยืนยัน business event

ทำเครื่องหมายจุดแปลง เช่น Modbus register เป็น engineering value, vendor tag เป็น asset model, LoRaWAN payload decode หรือ OPC UA เป็น MQTT จุดเหล่านี้สร้างคุณค่าแต่เป็นจุดเสี่ยงของ byte order, sign, scale, unit, missing data, time และ quality จึงต้องมี owner, version, test case และ rollback

หากโจทย์หลักคือดึงสัญญาณจากเครื่องเก่า โปรดอ่าน แนวทาง IoT retrofit สำหรับเครื่องจักรเก่า หากกำลังเลือกแพลตฟอร์มควบคุมและมอนิเตอร์ โปรดดู คู่มือเลือก SCADA สำหรับโรงงานไทย บทความนี้เน้นขั้นต่อไป คือทำให้ interface หลายผู้ขายเขียนลงสัญญาและทดสอบรับงานได้

ตาราง interoperability ที่ต้องแนบกับ RFP อุปกรณ์ IIoT

กำหนดประเภทคำตอบ Supported, Configurable, Requires gateway, Custom development, Not supported และ Not tested แม้ตอบ Supported ก็ต้องอ้าง manual, configuration export, sample payload หรือ report แยก roadmap ออกจากความสามารถปัจจุบัน

ขอหลักฐานของ “ชุดอุปกรณ์” ไม่ใช่แค่โลโก้มาตรฐาน

ผลิตภัณฑ์ A และ B อาจอ้างมาตรฐานเดียวกันแต่เลือก optional profile, version, extension หรือ security default ต่างกัน ให้ถามว่าชุด A–B–C ที่เสนอสามารถทำ scenario ที่กำหนดได้หรือไม่และจะส่งหลักฐานใด

ถ้ามี certificate หรือรายงานภายนอก ให้ดู scope รุ่น firmware, profile, issuer และอายุเอกสาร แต่เอกสารไม่แทน network, asset model, load และ disruption ของโรงงาน ยืนยัน configuration ใน FAT และทำซ้ำส่วนที่ขึ้นกับ site ใน SAT

เขียน OPC UA interoperability ให้เฉพาะเจาะจง

OPC UA ครอบคลุม Client/Server, PubSub, information model, security และ discovery คำว่า “มี OPC UA” จึงกว้างเกินไป Client/Server ต้องระบุ role, endpoint, policy, identity, subscription, sampling, monitored item, history, method และ event ที่ใช้ PubSub ต้องระบุ message mapping, encoding, transport, broker, topic, metadata, security, PublisherId และ DataSetWriter

ข้อมูลทางการ OPC UA Part 14 ระบุ mapping เช่น UDP, MQTT และ AMQP ดังนั้นคำว่า “ใช้ MQTT” ยังไม่บอก profile หรือ encoding ของ OPC UA PubSub ในอีกด้าน proprietary MQTT payload ไม่ได้แปลว่าใช้ไม่ได้เสมอ หาก schema, semantics, versioning, security และ replay ชัดและตอบโจทย์ได้ ให้ประเมินคุณค่าของมาตรฐานจาก mapping และ re-test ที่ลดลง

ใน information model ให้ตรวจ BrowseName, DataType, EngineeringUnits, range, status, source/server timestamp และ asset hierarchy ไม่ใช่แค่ NodeId หากใช้ Companion Specification ต้องระบุชื่อ version, subset และ vendor extension

MQTT คือทางขนส่ง ส่วน topic และ payload คือสัญญาข้อมูล

OASIS MQTT 5.0 ทำให้ publish/subscribe messaging เป็นมาตรฐาน แต่การต่อ broker ได้ไม่ทำให้ความหมายข้อมูลโรงงานเป็นมาตรฐาน RFP ต้องครอบคลุม client ID, topic naming, wildcard, QoS, retained message, session expiry, will, message expiry, user properties, packet limit, authorization, TLS และ certificate rotation

ให้ version กับ topic/payload ตัวอย่างเช่น v1/site/{site}/asset/{asset}/telemetry พร้อม eventTime, sequence, value, unit, quality, source นี่เป็นเพียงตัวอย่าง ไม่ใช่ topic บังคับของ มอก. 30162

QoS 1 หรือ 2 ไม่ได้ทำให้ business transaction exactly-once ใน gateway, broker, consumer และ database โดยอัตโนมัติ ต้องกำหนด event ID, sequence, idempotency และ reprocessing ส่วน retained message มีประโยชน์กับ state แต่ต้องป้องกัน state เก่าหรือ command เก่าถูกตีความเป็น event ใหม่

อ่านกิจกรรม mapping LoRaWAN กับ OPC UA อย่างไร

OPC Foundation และ LoRa Alliance เปิดตัว working group ร่วมสำหรับ mapping LoRaWAN ไปยัง OPC UA information model อย่างเป็นทางการเมื่อวันที่ 13 พฤษภาคม 2026 ทิศทางนี้สำคัญ เพราะเชื่อม edge connectivity ที่ประหยัดพลังงานกับข้อมูลอุตสาหกรรมที่มีความหมาย

ประกาศนี้ไม่ได้พิสูจน์ว่าอุปกรณ์ LoRaWAN ทุกตัวทำงานกับ OPC UA โดยอัตโนมัติ ยังต้องตรวจ device profile, payload codec, unit, asset identity, หน้าที่ gateway/network server, uplink/downlink, confirmed message, offline behaviour และ mapping version พร้อม baseline version ที่ใช้จริง

แยก monitoring ความถี่ต่ำออกจาก control ข้อจำกัด latency, duty cycle, coverage, battery, retry และ downlink ไม่หายไปเพราะมี information model ที่ดี

ออกแบบ secure onboarding พร้อม semantics และ lifecycle

บทความ Cloud Initiative เดือนมิถุนายน 2026 ของ OPC Foundation อธิบายการใช้ OPC UA Client/Server หรือ OPC UA PubSub over MQTT เป็น northbound interface และเน้น structured information model กับ semantic onboarding ประเด็นเชิงปฏิบัติคือ protocol และความหมาย asset ต้องออกแบบร่วมกัน ส่วน certificate, buffer, monitoring และ remote lifecycle ต้องกำหนดแยกตามผลิตภัณฑ์และโรงงาน ไม่ควรสรุปเป็นข้อกำหนดสากลจากหน้าเดียว

ขอให้ผู้ขายสาธิต onboarding ของ device ใหม่: identity มาจากไหน ใครอนุมัติ ownership, trust ถูกสร้างอย่างไร เชื่อมกับ asset record ใด และกรณีผิดพลาดถูก quarantine ที่ไหน ตรวจการพึ่ง default password, shared certificate, token ถาวร หรือการคัดลอก secret ด้วยมือ

W3C Web of Things Thing Description 1.1 ช่วยอธิบาย metadata และ interface แบบ machine-readable แต่ไม่กำหนด asset hierarchy, quality rule หรือ maintenance owner ของโรงงานทั้งหมด จึงต้องระบุผู้สร้าง ความน่าเชื่อถือ version, update, mapping และ retirement

ความหมายเจ็ดข้อของ distributed-data interoperability

1. Identity: serial, asset, line, station, tag, product และ lot
2. Time: event/source/ingest time, timezone, clock source, precision
3. Value: datatype, scale, precision, range, unit, conversion, rounding
4. Quality: good/bad/uncertain, sensor fault, stale, manual, estimated, missing
5. Context: mode, recipe, work order, tool, operator, changeover
6. Lineage: raw, decoded, converted, aggregated, corrected
7. Version: schema, mapping, firmware, configuration, master data

ค่าอุณหภูมิ 30.0 ยังไม่พอถ้าไม่มีหน่วย เวลาต้นทาง quality, asset และ mapping version แม้ quality=good ก็อาจมีความหมายเฉพาะ vendor จึงต้องมี canonical mapping และ negative test

หากต้องออกแบบระบบเก็บข้อมูลภาพรวม โปรดดู คู่มือ PoC/RFP ระบบเก็บข้อมูลการผลิตในไทย ตารางในบทความนี้เจาะลึกส่วน interface acceptance

FAT/SAT ต้องรับรองวิธีล้มและวิธีฟื้น ไม่ใช่แค่หน้าจอที่ต่อได้

FAT ตรวจชุดที่ทำซ้ำได้ในสภาพแวดล้อมผู้ขาย SAT เพิ่มไฟฟ้า สาย switch, VLAN, firewall, radio, DNS/NTP, certificate และระบบปลายทางของ site ต้อง inject failure แล้วบันทึกการตรวจพบ สถานะ และการฟื้นตัว

30 นาทีเป็นตัวอย่าง ไม่ใช่ข้อกำหนดของ มอก. 30162 ต้องกำหนดจาก process tolerance, event rate, buffer และคุณภาพสื่อสาร

แยกคำว่า zero data loss เป็นแต่ละจุด

ถามว่าครอบคลุม boundary และ fault ใด Sensor ดับอาจไม่สร้าง measurement, edge buffer อาจหายเมื่อไฟดับ, broker อาจเก็บได้แต่ consumer ล้มก่อน database commit วาด source measurement, acquisition, local queue, acknowledgement, broker persistence, consumer และ commit คำว่า “ไม่สูญหาย” รับได้เมื่อระบุ event, retention, peak rate, fault, exclusion และวิธีพิสูจน์

เงื่อนไข network, security และ maintainability

อย่าสร้าง compatibility ด้วยการเปิด port กว้างหรือใช้ credential เดียวทั้งโรงงาน เชื่อม asset inventory, zone/conduit, allowed flow, identity, certificate lifecycle, remote access, log, backup และ vulnerability notification กับ interface requirement

การจัดการ certificate ต้องครอบคลุม issuance, revocation, expiry alert, renewal, trust-list distribution, clock error, replacement และ factory reset ระบบที่ต่อได้วันส่งมอบแต่หยุดเมื่อ renewal ครั้งแรกยังไม่ครบด้าน operation Remote support ควรมี request, approval, time limit, MFA, recording และ closure

ทดสอบ backup configuration แบบเข้ารหัส restore ข้าม firmware ที่รองรับ secret และ identity ของเครื่องทดแทน ขั้น decommission ต้องลบ certificate และ broker credential เก่า

PoC 90 วันสำหรับระบบหลายผู้ขาย

วัน 1–15: ขอบเขตและข้อจำกัด

สำรวจ asset, signal, network, upper use, outage window และ security owner สิ่งที่ไม่รู้ให้ระบุว่าไม่รู้ ไม่สมมติว่ารองรับ

วัน 16–30: matrix และ data contract

เก็บคำตอบผู้ขายด้วยคอลัมน์เดียวกัน ตกลง identity, time, unit, quality, schema, security, buffer และรับ sample payload/configuration export

วัน 31–60: normal flow และ semantics

ไล่ค่าจาก sensor ถึง screen/DB เทียบ raw กับ canonical รวม product change, run/stop, sensor fault, manual override

วัน 61–75: disruption, version, security, recovery

สร้าง network outage, broker stop, gateway reboot, certificate failure, clock skew, schema change, duplicate, out-of-order แล้วบันทึก buffer, alarm, replay และ operator action

วัน 76–90: SAT, TCO และ Go/No-Go

จัด gap เป็น product, configuration, gateway, custom development, operation รวม licence, engineering, certificate, monitoring, upgrade re-test และ EOL migration ใน TCO 5 ปี

ตัวอย่างคะแนน RFP

นี่เป็นตัวอย่าง ไม่ใช่คะแนนที่มาตรฐานกำหนด ให้ตั้ง mandatory gate แยกสำหรับ default credential, encryption, export, audit, safe disconnected state และ loss/replay ที่ตกลง

ความผิดพลาดที่พบบ่อยและเงื่อนไขสัญญา

อย่ารับชื่อโปรโตคอลโดยไม่มี version, profile, role, encoding, policy และ model อย่าซ่อน transformation ใน gateway ที่ไม่มีเอกสาร ต้องส่ง source/target mapping, unit, quality, time, owner และ test อย่าจบ PoC ใน lab ที่สะอาด ต้องทำเงื่อนไข site ใน SAT อย่ารับเพียง initial connection โดยไม่ทดสอบ certificate, firmware, schema และ application change

กำหนด ownership และ exit ของ raw/canonical/aggregated data, configuration, mapping และ log รวมรูปแบบ ความถี่ และค่าใช้จ่าย export การถอนระบบต้อง revoke credential, reset device, retire certificate, จัดการ cloud copy และ re-import ไปยังระบบแทน

ผลงานตั้งแต่ Concept ถึง Exit

ผูกทุกคำตอบกับเลข RFP, design decision และ test ID คำว่า “ทำได้” จึงตรวจย้อนกลับไปยัง config, version, licence, development และ acceptance record ได้

FAQ: มอก. 30162 และ industrial IoT interoperability

มอก. 30162-2568 เป็นใบรับรองบังคับสำหรับ IIoT ทุกชนิดหรือไม่

ข้อมูล TISI ระบุว่าเป็นมาตรฐานทั่วไป บทความนี้ไม่กล่าวว่ามีหน้าที่รับรองแบบสากลสำหรับทุกอุปกรณ์ โปรดตรวจผลิตภัณฑ์ กฎวิทยุ/สื่อสาร สัญญาลูกค้า และ use case เฉพาะ

RFP ควรตรวจคำว่า “รองรับ TIS 30162” อย่างไร

ขอรุ่น firmware, edition, scope, profile, exclusion และ report แล้วพิสูจน์ semantics, disruption, security และ change ของชุดจริงใน FAT/SAT

OPC UA ทำให้ multi-vendor IoT plug-and-play หรือไม่

ไม่โดยอัตโนมัติ ต้องตรงกันด้าน role, profile, version, model, namespace, unit, quality, certificate และ operation

MQTT 5.0 รับประกันว่า data ไม่หายหรือไม่

ไม่ QoS ครอบคลุม delivery บางส่วน แต่ sensor, edge, broker, consumer, DB ยังต้องมี buffer, persistence, event ID, dedup, replay และ monitoring

เอกสารแนบ IIoT RFP ที่สำคัญที่สุดคืออะไร

Boundary diagram, interface inventory, interoperability matrix, data contract และ FAT/SAT test case ทำให้เปรียบเทียบคำกล่าวของผู้ขายด้วยหลักฐานเดียวกัน

จำเป็นต้องทำทั้ง FAT และ SAT หรือไม่

ทั้งสองมีหน้าที่ต่างกัน FAT ใช้ทดสอบชุดอุปกรณ์และกรณีผิดปกติซ้ำได้ในสภาพแวดล้อมที่ควบคุมของผู้ขาย ส่วน SAT ใช้ยืนยันไฟฟ้า สาย network, radio, แหล่งเวลา certificate และการเชื่อมต่อระบบปลายทางที่ขึ้นกับหน้างาน กำหนดขอบเขตของแต่ละขั้นตามความเสี่ยงของโครงการ และอย่าถือว่าขั้นหนึ่งแทนอีกขั้นได้โดยอัตโนมัติ

สรุป: เปลี่ยนเลขมาตรฐานเป็นหลักฐานที่เปรียบเทียบได้

มอก. 30162-2568 เป็น identical reprint ของ ISO/IEC 30162:2022 และเป็นมาตรฐานทั่วไปที่ครอบคลุม protocol interaction, distributed-data interoperability, connectivity framework, transport, network และ guidance ใช้เป็นโครงสร้างค้นหาสิ่งที่ยังไม่ตัดสิน ไม่ใช่ทางลัดเพื่อกล่าวอ้างการรับรอง

ทำ boundary และ conversion ให้เห็น กำหนด version, profile, model, identity, time, unit, quality, security และ lifecycle แล้วทดสอบ OPC UA, MQTT, LoRaWAN หรือ WoT เป็นชุด FAT/SAT ต้องรวม version ที่ไม่รองรับ bad value, clock skew, outage, replay, certificate, update และ export เก็บ config, payload, log และ reconciliation เป็นหลักฐานรับงาน

หากต้องการ mapping หกขอบข่ายของ TIS 30162 เข้ากับรายการ interface และสร้าง RFP กับหลักฐานรับงานที่เปรียบเทียบผู้ขายได้ โปรด ติดต่อ TOMAS TECH ตั้งแต่ช่วงที่ architecture และ shortlist ยังปรับได้

แหล่งข้อมูลวิจัย

• TISI, มอก. 30162-2568: https://a.tisi.go.th/t/?n=9612
• ISO, ISO/IEC 30162:2022: https://www.iso.org/standard/53282.html
• OPC Foundation / LoRa Alliance: https://opcconnect.opcfoundation.org/2026/06/opc-foundation-and-lora-alliance-join-forces-to-map-lorawan-to-opc-ua/
• OPC Foundation Cloud Initiative: https://opcconnect.opcfoundation.org/2026/06/cloud-corner-june-2026/
• OPC Foundation, OPC UA Part 14: https://profiles.opcfoundation.org/document/15
• W3C, WoT Thing Description 1.1: https://www.w3.org/TR/wot-thing-description11/
• OASIS, MQTT 5.0: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

ตรวจสอบแหล่งข้อมูลในเดือนกันยายน 2026 เนื้อหานี้เป็นข้อมูลเทคนิคและการจัดซื้อทั่วไป ไม่ใช่คำปรึกษาด้านกฎหมาย กฎระเบียบ หรือการรับรอง โปรดตรวจข้อกำหนดสำหรับผลิตภัณฑ์ สัญญา และโรงงานแต่ละแห่ง