การติดตั้งระบบ Historian อุตสาหกรรม: การเลือก RFP และ FAT/SAT สำหรับโรงงานไทย

“SCADA น่าจะมีข้อมูลย้อนหลังอยู่แล้ว แต่พอจะดึงค่าอุณหภูมิของวันที่เกิดของเสียเมื่อปีที่แล้ว กลับช้า ข้อมูลขาดหาย และไม่รู้ว่าเป็นแท็กไหน” นี่คือคำปรึกษาที่เราได้รับบ่อยจากฝ่ายควบคุมและเครื่องมือวัด (instrumentation) และฝ่าย IT ของโรงงานญี่ปุ่นในไทย ขอเริ่มจากข้อสรุป สิ่งที่ควรได้จากการติดตั้งระบบ Historian อุตสาหกรรม ไม่ใช่พื้นที่จัดเก็บจำนวนมาก แต่คือ “ข้อมูลอนุกรมเวลาที่เชื่อถือได้ มีบริบทกำกับ และนำกลับมาแสดงย้อนหลังได้ในภายหลัง” เพื่อให้ได้สิ่งนี้ ต้องตัดสินใจ 4 เรื่อง ได้แก่ (1) จำเป็นต้องมี Historian จริงหรือไม่ (2) จะเก็บอะไร ด้วยความแม่นยำเท่าใด และใช้เวลาประทับ (timestamp) จากจุดใด (3) จะวางไว้ที่ใดในเครือข่าย และ (4) จะยืนยันอะไรในการทดสอบรับมอบ การเปรียบเทียบผลิตภัณฑ์จะได้ผลดีกว่าหากทำหลังจากตัดสินใจ 4 เรื่องนี้แล้ว

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

ทำไมการติดตั้งระบบ Historian อุตสาหกรรมจึงเป็นประเด็นในตอนนี้

สิ่งที่ประกาศในงาน ICC 2026 เดือนกันยายน 2026

ในช่วงไม่กี่สัปดาห์ที่ผ่านมา มีประกาศเกี่ยวกับ Historian ที่น่าสังเกต บริษัท Inductive Automation ประกาศในข่าวประชาสัมพันธ์ลงวันที่ 23 กันยายน 2026 ว่า ในงานประชุมประจำปี ICC 2026 ที่จัดขึ้นที่เมืองแซคราเมนโต สหรัฐอเมริกา (ตามข้อมูลของบริษัท มีผู้เข้าร่วมมากกว่า 1,800 คน และมีมากกว่า 60 เซสชัน) บริษัทได้แสดงตัวอย่าง (preview) ของ “Enterprise Historian Module” ตัวใหม่สำหรับ TimescaleDB ในฐานะส่วนหนึ่งของเวอร์ชันถัดไป “Ignition 2027” พร้อมกันนั้น บริษัท Tiger Data ผู้พัฒนา TimescaleDB ได้เป็นพันธมิตรเชิงกลยุทธ์ โดยทั้งสองบริษัทจะร่วมกันพัฒนา “TimescaleDB for Ignition” และ Inductive Automation จะเป็นผู้จำหน่ายและให้การสนับสนุนโดยตรง

ตามบทความสรุปงานที่บริษัทเผยแพร่เมื่อ 30 กันยายน โมดูลนี้มีไว้เพื่อตอบสนองความต้องการด้านประสิทธิภาพการคิวรี ความพร้อมใช้งานสูง (high availability) และความจุในการจัดเก็บ Ignition 2027 มีกำหนดออกในเดือนกุมภาพันธ์ 2027 และระบุว่าจะเปลี่ยนไปใช้รูปแบบการออกเวอร์ชันปีละครั้ง นอกจากนี้ บริษัทอธิบายว่า Ignition 8.3 ซึ่งเป็นเวอร์ชันปัจจุบัน จะได้รับการสนับสนุนในฐานะเวอร์ชันสนับสนุนระยะยาว (LTS) จนถึงปี 2030 ทั้งหมดนี้เป็นประกาศของผู้ผลิต และ Enterprise Historian Module ยังอยู่ในขั้นแสดงตัวอย่าง ยังไม่มีการระบุวันที่เริ่มให้บริการหรือราคา

อนึ่ง Tiger Data คือบริษัทที่เปลี่ยนชื่อมาจากบริษัท Timescale เมื่อวันที่ 17 มิถุนายน 2025 ส่วนส่วนขยายฐานข้อมูลอนุกรมเวลาแบบโอเพนซอร์ส (ส่วนขยายของ PostgreSQL) ยังคงใช้ชื่อ “TimescaleDB” เช่นเดิม โปรดระวังอย่าสับสนระหว่างชื่อบริษัทกับชื่อผลิตภัณฑ์ ทั้งสองบริษัทยังได้ประกาศความร่วมมือในงาน Hannover Messe 2026 เมื่อวันที่ 20 เมษายน 2026 ด้วย และในประกาศฉบับนั้นได้ยกปัญหาของตลาด เช่น “ไลเซนส์แบบปิดที่คิดตามจำนวนแท็ก” และ “รูปแบบข้อมูลเฉพาะของผู้ผลิต” ขึ้นมา นี่เป็นคำกล่าวอ้างของบริษัทที่เกี่ยวข้องเอง แต่ก็สะท้อนว่า วิธีนับไลเซนส์และความง่ายในการนำข้อมูลออกมาใช้ ได้กลายเป็นประเด็นในการเลือก Historian

ความหมายสำหรับโรงงานในไทย

ประกาศนี้ไม่ใช่เหตุผลที่ต้องเปลี่ยนไปซื้ออะไรใหม่ทันที อย่างไรก็ตาม มีความเปลี่ยนแปลงที่ควรทำความเข้าใจไว้ คือทางเลือกของ Historian ไม่ได้มีเพียงสองทางว่า “ผลิตภัณฑ์เฉพาะทาง หรือฟังก์ชันข้อมูลย้อนหลังที่แถมมากับ SCADA” อีกต่อไป และโครงสร้างที่ใช้ฐานข้อมูลอนุกรมเวลาทั่วไปเป็นฐานด้านหลัง กำลังกลายเป็นทางเลือกอย่างเป็นทางการของผู้จำหน่ายซอฟต์แวร์อุตสาหกรรมด้วย

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

Historian อุตสาหกรรมคืออะไร: ต่างจากล็อกของ SCADA และฐานข้อมูลอนุกรมเวลาทั่วไปอย่างไร

นิยามโดย NIST และตำแหน่งในระบบควบคุม

คู่มือความปลอดภัย OT “SP 800-82 Rev.3” (กันยายน 2023) ของสถาบันมาตรฐานและเทคโนโลยีแห่งชาติสหรัฐอเมริกา (NIST) นิยาม Data Historian ในอภิธานศัพท์ว่าเป็น “ฐานข้อมูลแบบรวมศูนย์ที่สนับสนุนการวิเคราะห์ข้อมูลด้วยวิธีการควบคุมกระบวนการเชิงสถิติ (SPC)” เอกสารฉบับเดียวกันยกตัวอย่างโครงสร้างของศูนย์ควบคุม เช่น โครงสร้างที่ HMI เวิร์กสเตชันสำหรับงานวิศวกรรม และ Data Historian เชื่อมต่อกันผ่าน LAN และโครงสร้างที่ข้อมูลจาก PLC ถูกจัดเก็บใน Historian

การใช้งานไม่ได้จำกัดอยู่ที่ SPC เอกสารฉบับนี้ยังระบุว่า สิ่งที่เป็นลักษณะเฉพาะของเครือข่าย OT คือ Data Historian อาจเป็นแหล่งข้อมูลเหตุการณ์ “เสริม” ที่ช่วยเติมภาพสถานการณ์ของเหตุการณ์ทางไซเบอร์ได้ แต่เป็นเพียง “เสริม” เท่านั้น ไม่ได้หมายความว่าใช้แทนระบบเก็บล็อกด้านความปลอดภัยได้ ควรเข้าใจว่า Historian คือบันทึกที่ใช้ติดตามสิ่งที่เกิดขึ้นในโรงงานตามแกนเวลา ตั้งแต่การสอบสวนปัญหาคุณภาพ การวิเคราะห์ความผิดปกติของอุปกรณ์ การวิเคราะห์พลังงาน ไปจนถึงการทบทวนอุบัติเหตุ

ต่างจากล็อกของ SCADA อย่างไร

SCADA และ HMI ก็มีฟังก์ชันเก็บข้อมูลย้อนหลังสำหรับแสดงกราฟแนวโน้ม (trend) เช่นกัน บทความนี้แยกพิจารณาเป็น 3 แบบดังนี้

เนื้อหาในตารางเป็นแนวโน้มทั่วไปที่บทความนี้จัดระเบียบไว้ และแตกต่างกันมากตามผลิตภัณฑ์ สิ่งสำคัญไม่ใช่ว่าแบบใดดีกว่า แต่คือ “ความต้องการของบริษัทของท่านอยู่ตรงไหน” แนวคิดในการเลือกและปรับปรุงตัว SCADA เองอธิบายไว้ใน “SCADA สำหรับโรงงานไทย: คู่มือ RFP, FAT/SAT และ TCO”

“เก็บได้” กับ “นำกลับมาแสดงย้อนหลังได้” ไม่เหมือนกัน

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

การเลือกและเปรียบเทียบ Historian: 3 ทางเลือกและวิธีอ่านแนวโน้มผลิตภัณฑ์

การตัดสินใจที่ 1: จำเป็นต้องมี Historian จริงหรือไม่

บทความนี้มองว่า หากสถานการณ์ต่อไปนี้ตรงกับโรงงานของท่านตั้งแต่ 2 ข้อขึ้นไป มีความเป็นไปได้สูงที่ฟังก์ชันข้อมูลย้อนหลังของ SCADA เพียงอย่างเดียวจะไม่เพียงพอแล้ว

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

ในทางกลับกัน หากวัตถุประสงค์คือมอนิเตอร์การเดินเครื่องของ 1 ไลน์ และระยะเวลาเก็บรักษาสั้นก็เพียงพอ บางกรณีการทบทวนการตั้งค่าข้อมูลย้อนหลังของ SCADA ก่อนอาจเร็วกว่า

กรณีใช้ฐานข้อมูลอนุกรมเวลาทั่วไป

ฐานข้อมูลอนุกรมเวลาทั่วไปมีทางเลือกมากขึ้น ตัวอย่างเช่น บริษัท InfluxData ประกาศการเปิดให้ใช้งานทั่วไป (GA) ของ “InfluxDB 3 Core” และ “InfluxDB 3 Enterprise” เมื่อวันที่ 15 เมษายน 2025 ตามข้อมูลของบริษัท Core เป็นโอเพนซอร์สภายใต้ไลเซนส์ MIT/Apache 2 และถูกวางตำแหน่งเป็น “เอนจินข้อมูลล่าสุดความเร็วสูงสำหรับงานเรียลไทม์” ส่วน Enterprise คือรุ่นที่เพิ่มความพร้อมใช้งานสูง read replica และ automatic failover เป็นต้น การที่ Core ถูกอธิบายว่าเป็น “สำหรับข้อมูลล่าสุด” เป็นประเด็นที่ต้องตรวจสอบเมื่อพิจารณาว่าจะใช้เป็น Historian สำหรับการจัดเก็บระยะยาวหรือไม่

TimescaleDB ซึ่งเป็นส่วนขยายของ PostgreSQL (พัฒนาโดยบริษัท Tiger Data) ก็เป็นหนึ่งในทางเลือกที่เป็นตัวแทนของฐานข้อมูลอนุกรมเวลาทั่วไป ดังที่กล่าวไปแล้ว บริษัท Inductive Automation ประกาศว่าจะนำ TimescaleDB เข้ามาเป็นทางเลือกหนึ่งของ Historian ของบริษัท

หากเลือกฐานข้อมูลทั่วไป ผู้ใช้จะต้องออกแบบและดูแลเองทั้งการเก็บข้อมูล แฟล็กคุณภาพ ข้อมูลที่มาไม่ตามลำดับ การเติมข้อมูลที่ขาดหาย การบีบอัด ระยะเวลาเก็บรักษา และการจัดการสิทธิ์ คาดว่าการที่ฝ่าย IT มีประสบการณ์และกำลังคนสำหรับงานนี้หรือไม่ จะเป็นจุดตัดสินที่สำคัญในการเลือก

ความเคลื่อนไหวของซอฟต์แวร์อุตสาหกรรมและผลิตภัณฑ์ Historian เฉพาะทาง

ในผลิตภัณฑ์ซอฟต์แวร์อุตสาหกรรมเองก็มีการปรับปรุงฟังก์ชัน Historian บริษัท Inductive Automation ออก Ignition 8.3 เมื่อวันที่ 16 กันยายน 2025 และประกาศว่าได้รวมชุด “Industrial Historian Solution Suite” ซึ่งประกอบด้วย Historian Core Module, SQL Historian Module และ Historian API สำหรับสร้าง Historian ของตนเอง ตามเอกสารของบริษัท Core Historian เป็นฐานข้อมูลที่ฝัง QuestDB ไว้ภายใน มีฟังก์ชันแบ่งพาร์ทิชัน ตัดข้อมูลซ้ำ จัดเก็บถาวร (archive) และสรุปรวมข้อมูล และเลือกวิธีจัดการข้อมูลเก่าได้จาก “None (เก็บไว้ไม่มีกำหนด)” “Prune (ลบพาร์ทิชันเก่า)” และ “Archive (ย้ายไปที่อื่น)” ส่วนการจัดสรรหน่วยความจำ ค่าเริ่มต้นคือ 10% ของหน่วยความจำทั้งหมดของระบบ เอกสารของบริษัท QuestDB อธิบายว่าสิ่งนี้มาแทนที่ Historian ภายในแบบเดิมที่ใช้ SQLite

ตัวอย่างของ Historian เฉพาะทาง บริษัท Canary Labs อธิบายบนเว็บไซต์ทางการว่า วิธีการจัดเก็บคือ “การบีบอัดแบบไม่สูญเสียข้อมูล (lossless compression)” และมี store-and-forward เป็นองค์ประกอบเฉพาะ ซึ่งส่งข้อมูลถึงปลายทางได้อย่างแน่นอนแม้ในสภาวะออฟไลน์ PI System ของบริษัท AVEVA เป็นผลิตภัณฑ์ที่มีกลไก exception (deadband) และการบีบอัดแบบ swinging door ซึ่งจะอธิบายต่อไป มีรายงานว่า AVEVA ได้เผยแพร่การปรับปรุง เช่น การประมวลผลข้อมูลที่มาไม่ตามลำดับ ใน PI Server 2024 R2

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

การตรวจสอบอินเทอร์เฟซมาตรฐาน

สิ่งที่ควรตรวจสอบเมื่อเลือกผลิตภัณฑ์คือมาตรฐานของวิธีดึงข้อมูลย้อนหลัง “OPC 10000-11 UA Part 11: Historical Access” ของ OPC Foundation เป็นข้อกำหนดที่กำหนดวิธีจัดเก็บและดึงข้อมูลไปยัง Historian หรือฐานข้อมูล ครอบคลุมแนวคิดของข้อมูลย้อนหลังของข้อมูลและเหตุการณ์ พฤติกรรมการสร้าง ดึง อัปเดต และลบข้อมูลที่จัดเก็บถาวรและหมายเหตุประกอบ (annotation) รวมถึงความปลอดภัยซึ่งรวมสิทธิ์การเข้าถึงและการตรวจสอบ (audit) เวอร์ชันล่าสุดคือ V1.05.04 (ออกเมื่อ 29 พฤศจิกายน 2024) สำหรับการสรุปรวม เช่น การประมาณค่าระหว่างจุด (interpolation) และค่าเฉลี่ยตามเวลา มีข้อกำหนด “Part 13: Aggregates” โดยเวอร์ชัน 1.05.07 (เผยแพร่เมื่อ 15 เมษายน 2026) อยู่บนเว็บไซต์อ้างอิงของ OPC Foundation

แม้ผลิตภัณฑ์จะเขียนว่า “รองรับ OPC UA” ก็อาจรองรับเพียงการอ่านและเขียนค่าปัจจุบัน โดยไม่รองรับการดึงข้อมูลย้อนหลัง (Part 11) ใน RFP ให้ยืนยันเป็นรายข้อว่ารองรับการดึงข้อมูลย้อนหลังและการสรุปรวมด้วยข้อกำหนดใด

จะเก็บอะไรอย่างไร: ทะเบียนแท็ก การสุ่มเก็บข้อมูล เวลา และ store-and-forward

ทะเบียนแท็กคือเอกสารออกแบบที่แท้จริง

ผลงานชิ้นแรกที่ควรจัดทำในการติดตั้ง Historian ไม่ใช่แผนผังโครงสร้างเซิร์ฟเวอร์ แต่คือทะเบียนแท็ก (tag register) อย่างน้อยทะเบียนควรมีข้อมูลต่อไปนี้

• ชื่อแท็ก และเป็นของอุปกรณ์ใดและเครื่องมือวัดตัวใด (ลำดับชั้นของอุปกรณ์)
• หน่วย ช่วงการวัด และความแม่นยำของเครื่องมือวัด
• รอบการเก็บข้อมูล (ช่วงเวลาการสแกน)
• การตั้งค่า deadband และการบีบอัด พร้อมเหตุผลประกอบ
• ระยะเวลาเก็บรักษา
• ความหมายของแฟล็กคุณภาพ
• คำอธิบาย (ภาษาญี่ปุ่น ภาษาอังกฤษ และภาษาไทย)

หากชื่อแท็กยังเป็นแอดเดรสของ PLC ผ่านไปหลายปีจะไม่มีใครเข้าใจความหมาย การตั้งชื่อลำดับชั้นของอุปกรณ์และแท็กยังเกี่ยวข้องกับการออกแบบ topic เมื่อส่งข้อมูลด้วย MQTT ด้วย แนวคิดนี้อธิบายไว้ใน “การนำ MQTT Sparkplug B มาใช้ในโรงงานไทย: RFP, FAT/SAT และโครงการนำร่อง 90 วัน” นอกจากนี้ หากรายการอุปกรณ์ที่เป็นต้นทางของแท็กยังเป็นข้อมูลเก่า ก็จะสร้างทะเบียนแท็กไม่ได้ สำหรับการสำรวจอุปกรณ์ควบคุม ดูได้ที่ “การบริหารสินทรัพย์ OT: บัญชีสินทรัพย์ RFP และการรับมอบ 90 วันสำหรับโรงงานไทย”

กำหนดรอบการสุ่มเก็บข้อมูลจาก “วัตถุประสงค์การใช้งาน”

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

เก็บเวลาและคุณภาพไว้คู่กับค่า

การจะทำให้ข้อมูลนำกลับมาแสดงย้อนหลังได้ มีเงื่อนไขพื้นฐานคือ “ค่านั้นเป็นค่า ณ เวลาใด” ต้องถูกต้อง ความหมายของเวลาประทับจะเปลี่ยนไป ขึ้นอยู่กับว่าประทับที่ฝั่ง PLC หรือเซนเซอร์ ประทับที่เกตเวย์ หรือประทับเมื่อข้อมูลมาถึง Historian หากข้อมูลที่สื่อสารล่าช้าถูกประทับด้วยเวลาที่มาถึง ลำดับของสาเหตุและผลลัพธ์อาจดูสลับกัน คาดว่าสิ่งสำคัญคือการใช้แหล่งเวลาเดียวกันทั่วทั้งโรงงาน และเขียนในข้อกำหนดว่าเวลาประทับมาจากจุดใด หากจัดเก็บด้วยเวลาสากลเชิงพิกัด (UTC) แล้วแปลงเป็นเวลาท้องถิ่นของไทยเมื่อแสดงผล จะลดความสับสนเมื่อเปรียบเทียบข้อมูลกับฐานการผลิตในต่างประเทศหรือสำนักงานใหญ่

คุณภาพของค่าก็ต้องเก็บไว้ด้วย หากปฏิบัติต่อเซนเซอร์สายขาด การสื่อสารขาดหาย หรือค่าทดแทนที่ป้อนด้วยมือ เหมือนเป็นค่าปกติ ข้อสรุปของการวิเคราะห์จะผิดพลาด

ป้องกันข้อมูลขาดหายด้วย store-and-forward

เครือข่ายในโรงงานย่อมมีวันที่หยุดทำงาน สาเหตุมีหลากหลาย เช่น อุปกรณ์เสีย งานก่อสร้าง หรือลำดับการกลับมาทำงานหลังไฟดับ store-and-forward คือกลไกที่ฝั่งเก็บข้อมูล (เกตเวย์ edge หรือเซิร์ฟเวอร์เก็บข้อมูล) พักข้อมูลที่ส่งไม่ได้ไว้ชั่วคราว และเมื่อการสื่อสารกลับมา จะส่งข้อมูลโดยเริ่มจากข้อมูลเก่าที่สุดก่อน หากไม่มีกลไกนี้ ข้อมูลในช่วงที่การสื่อสารหยุดจะสูญหายไปอย่างถาวร

สิ่งที่ต้องระวังคือการจัดการข้อมูลที่มาถึงล่าช้า ตามเอกสารการบรรยายของบริษัท AVEVA ใน PI System “ข้อมูลที่มาไม่ตามลำดับ (out of order) จะข้ามการบีบอัด (bypass compression)” ผลิตภัณฑ์แต่ละตัวแตกต่างกันในเรื่องว่า สามารถใส่ข้อมูลที่มาถึงล่าช้าลงในตำแหน่งเวลาที่ถูกต้องได้หรือไม่ และเมื่อใส่แล้วการบีบอัดและการสรุปรวมจะเป็นอย่างไร วิธีประมาณความจุของบัฟเฟอร์จะกล่าวถึงในการประมาณการภายหลัง

หัวใจของการจัดเก็บข้อมูลกระบวนการผลิตระยะยาว: กำหนด deadband และการบีบอัดจากความแม่นยำของเครื่องมือวัด

Exception และการบีบอัด: ตัวอย่างของ AVEVA PI System

ประเด็นที่ถกเถียงกันมากที่สุดในการจัดเก็บระยะยาวคือการตั้งค่าเพื่อลดจำนวนข้อมูล ในที่นี้ขอยก PI System ของบริษัท AVEVA เป็นตัวอย่างที่มีการอธิบายวิธีการไว้ในเอกสารที่เปิดเผย (อ้างอิงจากเอกสารการบรรยายในงาน AVEVA World San Francisco ปี 2023 คำศัพท์เหล่านี้เป็นคำเฉพาะของ PI System และไม่สามารถนำไปใช้กับ Historian ของบริษัทอื่นโดยทั่วไปได้)

PI System มีกลไก 2 ขั้น ขั้นแรกคือ “Exception” ซึ่งเป็น deadband แบบง่ายสำหรับกรองสัญญาณรบกวน ทำงานเฉพาะใน PI Interfaces ที่อยู่ฝั่งเก็บข้อมูลเท่านั้น และช่วยลดจำนวนเหตุการณ์ (event) ที่ส่งออกไปเพื่อประหยัดแบนด์วิดท์ของเครือข่าย รายการตั้งค่า ได้แก่ ความกว้างของ deadband ในหน่วยทางวิศวกรรม (ExDev) สัดส่วนเทียบกับช่วงการวัด (ExDevPercent) และจำนวนวินาทีสูงสุดระหว่างเหตุการณ์ (ExMax) เอกสารฉบับเดียวกันมีหมายเหตุว่า AVEVA Adapters กรอง deadband ได้แต่จะไม่สนใจการตั้งค่า exception ของแท็ก และ PI Connectors จะไม่ทดสอบ exception กล่าวคือ แม้อยู่ในผลิตภัณฑ์เดียวกัน พฤติกรรมการลดจำนวนข้อมูลก็ต่างกันตามวิธีการเก็บข้อมูล นี่คือประเด็นที่ควรยืนยันใน RFP

ขั้นที่สองคือ “Compression” ซึ่งเป็นอัลกอริทึมที่เรียกว่า swinging door ช่วยลดปริมาณข้อมูลที่จัดเก็บ โดยตัดเฉพาะจุดที่สามารถสร้างกลับคืนได้อย่างปลอดภัยด้วยการประมาณค่าระหว่างจุด (interpolation) ในเอกสารมีการยกข้อความถึงวัตถุประสงค์ว่า “กรองสัญญาณรบกวนของเครื่องมือวัดและกระบวนการออก พร้อมกับบันทึกการเปลี่ยนแปลงที่สำคัญของกระบวนการไว้”

ทั้ง “ไม่ตั้งค่า” และ “ตั้งค่ามากเกินไป” ล้วนเป็นปัญหา

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

ตัวอย่างของผลลัพธ์ ระบุว่าสำหรับแท็กสถานะที่มีค่าเพียง 0 และ 1 สแกนทุก 1 วินาที และไม่ใช้ exception จำนวนเหตุการณ์ใน 48 ชั่วโมงคือ 172,800 เมื่อไม่บีบอัด และ 15 เมื่อบีบอัดในระดับต่ำสุด ตัวเลข 172,800 คือจำนวนจุดทั้งหมดของ 48 ชั่วโมง × 3,600 วินาที อย่างไรก็ตาม นี่เป็นตัวอย่างภายใต้เงื่อนไขเฉพาะ คือแท็กสถานะดิจิทัลที่มีค่าเพียง 0 และ 1 จึงไม่สามารถนำอัตราส่วนนี้ไปใช้กับค่าแอนะล็อกได้

ในอีกด้านหนึ่ง กรณีศึกษาลูกค้าด้านน้ำมันและก๊าซนอกชายฝั่งในสหรัฐอเมริการะบุว่า แท็กมากกว่า 87% ไม่ได้ใช้ทั้ง exception และการบีบอัด และเซิร์ฟเวอร์ฝั่งบนบกเกิดความไม่เสถียรเป็นระยะ หลังจากจัดกลุ่มแท็ก กำหนดค่าใหม่จากความแม่นยำของเครื่องมือวัดและความเห็นของผู้ที่มีความรู้ในหน้างาน แล้วทดลองกับแท่นขุดนำร่อง (pilot rig) มีรายงานว่าเหตุการณ์ที่จัดเก็บลดลงประมาณ 94% นี่ก็เป็นผลจากการนำร่องของลูกค้าเพียงรายเดียว ไม่ใช่ผลทั่วไปของโรงงาน สิ่งที่ควรอ่านจากกรณีนี้ไม่ใช่ตัวเลขอัตราการลด แต่คือ “ทั้งการเก็บทุกจุดต่อไปเรื่อยๆ และการตั้งค่ามากเกินไปจนทำให้การเปลี่ยนแปลงหล่นหาย ต่างก็เป็นปัญหาทั้งคู่”

กำหนดโดยยึดความแม่นยำของเครื่องมือวัด และตรวจสอบความต่างจากข้อมูลต้นฉบับ

แล้วควรกำหนดค่าตั้งโดยยึดอะไร ในกรณีศึกษาโรงกลั่นน้ำมันในสหรัฐอเมริกาจากเอกสารฉบับเดียวกัน มีรายงานว่า เมื่อใช้การตั้งค่า exception และการบีบอัดแบบระมัดระวัง ความต่างสูงสุดจากข้อมูลต้นฉบับของแท็กทุกตัวที่นำมาวิเคราะห์ต่ำกว่าความแม่นยำในการวัดของเครื่องมือวัด สิ่งที่กรณีศึกษานี้แสดงคือแนวคิดที่ว่า “การเก็บการเปลี่ยนแปลงที่ละเอียดกว่าความแม่นยำที่เครื่องมือวัดวัดได้นั้นไม่มีความหมาย ในทางกลับกัน การลดจำนวนข้อมูลจนเกิดความต่างเกินความแม่นยำของเครื่องมือวัด คือการทำลายข้อมูล”

บทความนี้แนะนำขั้นตอนต่อไปนี้

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

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

ประมาณความจุของฐานข้อมูลอนุกรมเวลาสำหรับโรงงานด้วยโรงงานต้นแบบ (แบบจำลองสมมติ)

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

สมมติฐาน (โรงงานต้นแบบ H)

ปริมาณข้อมูลดิบ

จำนวนจุดที่ 1 แท็กสร้างขึ้นใน 1 วัน คือ 24 ชั่วโมง × 3,600 วินาที = 86,400 จุด (172,800 จุดในตัวอย่างของ AVEVA ข้างต้น เท่ากับจำนวนของ 2 วันนี้) สำหรับ 2,000 แท็ก จะได้ 2,000 × 86,400 = 172,800,000 จุดต่อวัน และใน 1 ปีจะได้ 172,800,000 × 365 = 63,072,000,000 จุดต่อปี

เมื่อแปลงเป็นไบต์ 1 วันคือ 172,800,000 จุด × 16 ไบต์ = 2,764,800,000 ไบต์ หรือประมาณ 2.76 GB ส่วน 1 ปีคือ 63,072,000,000 จุด × 16 ไบต์ = 1,009,152,000,000 ไบต์ หรือประมาณ 1,009 GB และ 10 ปีจะประมาณ 10,092 GB

ความแตกต่างตามอัตราการจัดเก็บ

ปริมาณที่ลดลงได้ด้วย deadband และการบีบอัด แตกต่างกันมากตามลักษณะของสัญญาณและการตั้งค่า ดังนั้น แทนที่จะคาดการณ์อัตราการลด บทความนี้จะกำหนดอัตราการจัดเก็บสมมติเพื่อการเปรียบเทียบ เพื่อให้เห็นภาพของปริมาณ

สิ่งที่อ่านได้จากตารางนี้คือ เพียงแค่ช่วงของอัตราการจัดเก็บที่สมมติขึ้น (10–100%) ความจุที่ต้องใช้ของโรงงานเดียวกันก็ต่างกันถึง 10 เท่า ปริมาณของการเก็บทุกจุด 1 ปี เท่ากับปริมาณของอัตราการจัดเก็บ 10% เป็นเวลา 10 ปี คาดว่าควรคำนวณการประมาณความจุใหม่จากอัตราการจัดเก็บที่วัดจริงด้วยแท็กสำหรับทดสอบ ไม่ใช่จากค่าในแคตตาล็อกของผลิตภัณฑ์ นอกจากนี้ยังต้องมีความจุสำหรับการสำรองข้อมูล (backup) และสำหรับ replica แยกต่างหากด้วย

ประมาณบัฟเฟอร์ของ store-and-forward

ถัดมาคือบัฟเฟอร์เมื่อการสื่อสารหยุดลง สมมติว่าอุปกรณ์เครือข่ายเสียในช่วงวันหยุดยาว และไม่มีใครสังเกตเห็นเป็นเวลา 72 ชั่วโมง จำนวนจุดที่สะสมในช่วงนี้คือ 2,000 แท็ก × 3,600 วินาที × 72 ชั่วโมง = 518,400,000 จุด คิดเป็นไบต์คือ 518,400,000 × 16 = 8,294,400,000 ไบต์ หรือประมาณ 8.29 GB หากเผื่อไว้ 2 เท่า ฝั่ง edge จะต้องมีบัฟเฟอร์ประมาณ 16.6 GB ขึ้นไป

ต้องประมาณเวลาที่ใช้ส่งข้อมูลที่สะสมไว้จนหมดหลังการสื่อสารกลับมาด้วย สมมติว่าความสามารถในการส่งออกของ edge คือ 10,000 จุดต่อวินาที ระหว่างนั้นยังมีข้อมูลใหม่เกิดขึ้น 2,000 จุดต่อวินาที ดังนั้นบัฟเฟอร์จะลดลงด้วยความเร็ว 8,000 จุดต่อวินาที 518,400,000 จุด ÷ 8,000 จุด = 64,800 วินาที หรือ 18 ชั่วโมง ช่วง 18 ชั่วโมงนี้คือช่วงที่ข้อมูลบน Historian ยังไม่ถูกเติมให้ครบ หากความสามารถในการส่งออก หรือความสามารถในการเขียนของฝั่ง Historian ไม่เพียงพอ ช่วงเวลานี้จะยาวขึ้นอีก

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

จะวาง Historian ไว้ที่ใด: OT, DMZ และเครือข่ายองค์กร

หลักการของ NIST: การสื่อสารระหว่างองค์กรกับ OT ต้องผ่านบริการใน DMZ

Historian ยังเป็นกลไกที่ทำให้บุคคลที่อยู่นอกเครือข่ายควบคุมใช้ข้อมูลของระบบควบคุมได้ ดังนั้น ตำแหน่งที่วางจึงเชื่อมโยงโดยตรงกับการออกแบบด้านความปลอดภัย

ตัวอย่างสถาปัตยกรรมความปลอดภัยของ NIST SP 800-82r3 วาง DMZ ไว้เพื่อแยกสภาพแวดล้อม OT ออกจากเครือข่ายองค์กร และกำหนดให้การสื่อสารทั้งหมดระหว่างระดับองค์กรกับระดับการจัดการการปฏิบัติการ (รวมถึงระดับ 3 ของ Purdue model) ต้องผ่านบริการที่อยู่ภายใน DMZ โดยอธิบายว่าระดับภาคสนาม (field level) ครอบคลุมอุปกรณ์ในระดับ 0–2 ของ Purdue model นอกจากนี้ยังระบุว่า เนื่องจาก DMZ เชื่อมต่อกับภายนอก บริการที่อยู่ภายใน DMZ จึงต้องได้รับการมอนิเตอร์และป้องกัน เพื่อไม่ให้ผู้โจมตีแทรกซึมเข้าสู่สภาพแวดล้อม OT โดยไม่มีใครรู้ตัว

ตัวอย่างการออกแบบของบทความนี้: Historian หลักฝั่ง OT และ replica สำหรับทั้งองค์กรใน DMZ

จากหลักการนี้ บทความนี้พิจารณาโครงสร้างต่อไปนี้เป็นตัวอย่างการออกแบบ ทั้งนี้ เป็นแนวคิดของบทความนี้ที่อนุมานจากหลักการของ NIST โดย NIST ไม่ได้กำหนดการวาง Historian ในรูปแบบนี้

• Historian หลัก (primary): วางไว้ฝั่ง OT (ระดับการจัดการการปฏิบัติการ) เก็บข้อมูลจาก PLC และ SCADA เป็นข้อมูลต้นฉบับสำหรับการเดินเครื่องและการสอบสวนปัญหาคุณภาพ
• replica สำหรับทั้งองค์กร: วางไว้ใน DMZ รับข้อมูลจาก Historian หลัก ผู้ใช้ฝั่งเครือข่ายองค์กร เช่น สำนักงานใหญ่ ฝ่ายประกันคุณภาพ และทีมวิเคราะห์ จะเข้าถึงได้เฉพาะ replica นี้เท่านั้น
• เครือข่ายองค์กร: ระบบ BI และ ERP เป็นต้น ดึงข้อมูลจาก replica ใน DMZ และไม่เชื่อมต่อกับ Historian ฝั่ง OT โดยตรง

คาดว่าเมื่อจัดโครงสร้างเช่นนี้ แม้จะมีคิวรีหนักๆ มาจากฝั่งองค์กร ก็จะส่งผลกระทบต่อ Historian หลักที่สนับสนุนการเดินเครื่องได้ยาก และยังลดจำนวนช่องทางเข้าสู่ฝั่ง OT ได้ด้วย

จุดอ่อนที่แฝงอยู่ใน “การทำสำเนาอัตโนมัติแบบเชื่อมต่อตรง”

สิ่งที่ควรระวังคือ ตัวกลไกการทำสำเนาข้อมูลเองก็อาจกลายเป็นช่องทางของการโจมตีหรือความผิดพลาดได้ NIST SP 800-82r3 ยก “การเชื่อมโยงข้อมูลที่ไม่เหมาะสม” เป็นตัวอย่างของช่องโหว่ โดยระบุว่า database link ที่ทำสำเนาข้อมูลของ Data Historian ไปยังฐานข้อมูลอื่นโดยอัตโนมัติ หากกำหนดค่าไม่เหมาะสม อาจกลายเป็นช่องโหว่ที่เปิดให้มีการเข้าถึงโดยไม่ได้รับอนุญาตหรือการแก้ไขข้อมูลโดยมิชอบ

คาดว่าแม้จะสะดวก ก็ควรหลีกเลี่ยงการออกแบบที่สร้างลิงก์โดยตรงจากฐานข้อมูล BI หรือ ERP ฝั่ง IT ไปยัง Historian ฝั่ง OT และควรเขียนทิศทางการทำสำเนา การสื่อสารที่ใช้ การยืนยันตัวตน และการมอนิเตอร์ ไว้ในเอกสารออกแบบ หากต้องการรับประกันทางกายภาพว่าข้อมูลไหลจาก OT ไป IT ทางเดียวเท่านั้น ก็มีทางเลือกคือ data diode แนวคิดนี้สรุปไว้ใน “การเลือก Data Diode สำหรับโรงงานไทย: แนวทางเชื่อมข้อมูล OT ไป IT ทางเดียว”

การป้องกันตัวเซิร์ฟเวอร์ Historian

เซิร์ฟเวอร์ Historian ส่วนใหญ่ทำงานบน Windows หรือ Linux ทั่วไป NIST SP 800-82r3 ระบุว่า ระบบทั่วไปที่ใช้เป็นเวิร์กสเตชันสำหรับงานวิศวกรรม Data Historian โน้ตบุ๊กสำหรับงานบำรุงรักษา และเซิร์ฟเวอร์สำรองข้อมูล เป็นต้น โดยทั่วไปสามารถป้องกันได้เช่นเดียวกับอุปกรณ์ IT เช่น การแจกจ่ายอัปเดตจากเซิร์ฟเวอร์แอนตี้ไวรัสที่วางไว้ภายในเครือข่ายควบคุม (มีข้อจำกัดด้วยคำว่า “โดยทั่วไป” และไม่สามารถขยายการปฏิบัติแบบเดียวกันไปยังอุปกรณ์ควบคุม เช่น PLC ได้) ควรกำหนดไว้ตั้งแต่ตอนติดตั้งว่า ใครจะเป็นผู้อัปเดต OS จัดการบัญชีผู้ใช้ และสำรองข้อมูล ด้วยขั้นตอนใด

ความถูกต้องสมบูรณ์ของข้อมูล (data integrity) และ audit trail ในอุตสาหกรรมที่อยู่ภายใต้การกำกับ

โรงงานที่ผลิตสินค้าสำหรับตลาดสหรัฐอเมริกา เช่น ยา เครื่องมือแพทย์ และอาหาร และจัดการบันทึกอิเล็กทรอนิกส์ที่อยู่ภายใต้การกำกับของสำนักงานคณะกรรมการอาหารและยาสหรัฐอเมริกา (FDA) อาจมีข้อกำหนดเพิ่มเติมในการจัดการข้อมูลของ Historian กฎระเบียบกลางของสหรัฐอเมริกา 21 CFR §11.10 กำหนดให้ผู้ที่สร้าง แก้ไข ดูแลรักษา หรือส่งบันทึกอิเล็กทรอนิกส์ในระบบปิด (closed system) ต้องมีขั้นตอนและการควบคุมเพื่อรับรองความแท้จริงและความครบถ้วนของบันทึกอิเล็กทรอนิกส์ หนึ่งในนั้นคือข้อ (e) ซึ่งกำหนดให้มี audit trail ที่ปลอดภัย สร้างโดยคอมพิวเตอร์ และมีเวลาประทับ เพื่อบันทึกวันเวลาของการป้อนข้อมูลและการดำเนินการของผู้ปฏิบัติงานที่สร้าง แก้ไข หรือลบบันทึกอิเล็กทรอนิกส์ไว้อย่างเป็นอิสระ

นี่เป็นกฎระเบียบของ FDA สหรัฐอเมริกา และจำกัดเฉพาะกรณีที่จัดการบันทึกที่อยู่ภายใต้การกำกับของ FDA ไม่ใช่ข้อผูกพันทางกฎหมายทั่วไปของโรงงานในไทย อย่างไรก็ตาม สำหรับโรงงานที่เข้าข่าย เมื่อมีการแก้ไขข้อมูลของ Historian ในภายหลัง (การแก้ไขด้วยมือ การเติมข้อมูลที่ขาดหาย การเพิ่มหมายเหตุประกอบ เป็นต้น) การที่ระบบเก็บบันทึกได้ว่าใคร เปลี่ยนอะไร เมื่อใด จะกลายเป็นข้อกำหนดในการเลือกผลิตภัณฑ์ OPC UA Part 11 ที่กล่าวไปแล้วก็ครอบคลุมความปลอดภัยซึ่งรวมสิทธิ์การเข้าถึงและการตรวจสอบด้วย สำหรับคำถามว่าเข้าข่ายหรือไม่ และมีข้อกำหนดอะไรบ้าง โปรดยืนยันเป็นรายกรณีกับฝ่ายประกันคุณภาพหรือผู้เชี่ยวชาญ

12 รายการที่ควรเขียนใน RFP ระบบ Historian

รายการต่อไปนี้คือสิ่งที่ควรเขียนไว้เป็นอย่างน้อยใน RFP (เอกสารขอข้อเสนอ) ของ Historian เมื่อขอใบเสนอราคาจากผู้ผลิตหรือบริษัทผู้วางระบบ

1. วัตถุประสงค์และผู้ใช้: จะใช้เพื่ออะไร เช่น การสอบสวนปัญหาคุณภาพ การวิเคราะห์อุปกรณ์ พลังงาน การทบทวนอุบัติเหตุ และใครเป็นผู้ดู
2. ทะเบียนแท็ก: จำนวนแท็ก ชนิดข้อมูล หน่วย ความแม่นยำของเครื่องมือวัด ลำดับชั้นของอุปกรณ์ และภาษาของคำอธิบาย
3. วิธีการเก็บข้อมูลและอุปกรณ์เป้าหมาย: ชนิดของ PLC, SCADA และเครื่องมือวัด รวมถึงวิธีการสื่อสาร และสำหรับแต่ละวิธีการเก็บข้อมูล การตั้งค่า deadband หรือ exception มีผลหรือไม่
4. รอบการเก็บข้อมูล วิธีการ deadband และการบีบอัด และวิธีตั้งค่า: วิธีการ (ลดจำนวนข้อมูล หรือ lossless) ค่าเริ่มต้น วิธีบันทึกเหตุผลของการตั้งค่า สิทธิ์และประวัติการเปลี่ยนแปลง
5. เวลาและคุณภาพ: ประทับเวลาที่จุดใด แหล่งเวลา ระบบเวลาที่ใช้จัดเก็บ (UTC หรือเวลาท้องถิ่น) และชนิดของแฟล็กคุณภาพ
6. store-and-forward: ความจุของบัฟเฟอร์ ระยะเวลาขาดการเชื่อมต่อที่ทนได้ ความสามารถในการส่งออกหลังกู้คืน และการจัดการข้อมูลที่มาไม่ตามลำดับ
7. ระยะเวลาจัดเก็บและความจุ: ระยะเวลาเก็บรักษา การจัดการข้อมูลเก่า (ลบหรือจัดเก็บถาวร) และเหตุผลของการประมาณความจุ
8. การวางระบบและเครือข่าย: โครงสร้างของ Historian หลักฝั่ง OT และ replica ใน DMZ ทิศทางและวิธีการทำสำเนา และเส้นทางการเข้าถึงจากภายนอก
9. การนำข้อมูลออก: การรองรับการดึงข้อมูลย้อนหลังของ OPC UA (Part 11) และการสรุปรวม (Part 13) วิธีส่งออกไปยังระบบอื่น เช่น SQL, API, CSV และจะไม่ถูกขังอยู่ในรูปแบบเฉพาะหรือไม่
10. วิธีนับไลเซนส์และเวอร์ชันในอนาคต: นับตามจำนวนแท็ก จำนวนการเชื่อมต่อ หรือจำนวนเซิร์ฟเวอร์ การจัดการเมื่อขยายระบบ ระยะเวลาสนับสนุนระยะยาว และการย้ายไปเวอร์ชันถัดไป
11. audit trail และความปลอดภัย: บันทึกการแก้ไขข้อมูล บัญชีผู้ใช้และสิทธิ์ ขั้นตอนการอัปเดต OS และการสำรองข้อมูล (หากอยู่ภายใต้การกำกับ ให้รวมข้อกำหนดนั้นด้วย)
12. การสนับสนุนในประเทศและเกณฑ์ FAT/SAT: ช่องทางบำรุงรักษาในประเทศไทย คำอธิบายเป็นภาษาไทย เวลาตอบสนองเมื่อเกิดเหตุขัดข้อง รายการทดสอบและเกณฑ์ผ่าน และขอบเขตการเข้าร่วมสังเกตการณ์

ข้อที่สำคัญเป็นพิเศษคือข้อ 3, 4 และ 6 หากไม่เขียนข้อ 3 จะมารู้ตัวหลังติดตั้งว่า แม้ชื่อผลิตภัณฑ์เดียวกัน พฤติกรรมการลดจำนวนข้อมูลก็ต่างกันตามวิธีการเก็บข้อมูล หากไม่เขียนข้อ 4 การลดจำนวนข้อมูลโดยไม่ได้ตั้งใจจะดำเนินต่อไปด้วยค่าเริ่มต้น หากไม่เขียนข้อ 6 แม้ข้อมูลในช่วงที่การสื่อสารขาดหายจะสูญไป ก็ไม่มีใครรับผิดชอบได้ และข้อ 10 ซึ่งในสภาพที่เวอร์ชันและโครงสร้างของผลิตภัณฑ์เปลี่ยนแปลงไปเรื่อยๆ ดังเช่นประกาศในงาน ICC 2026 ครั้งนี้ จะเป็นตัวกำหนดว่าในอีก 5 ปีหรือ 10 ปีข้างหน้า จะยังนำข้อมูลออกมาได้หรือไม่ การวางตำแหน่ง Historian ในภาพรวมของการเก็บข้อมูลการผลิตทั้งองค์กร สรุปไว้ใน “เก็บข้อมูลการผลิตในโรงงานไทย: PoC 90 วันและ RFP”

สิ่งที่ต้องยืนยันใน FAT SAT ระบบ Historian

ในการทดสอบก่อนส่งออกจากโรงงานผู้ผลิต (FAT) และการทดสอบ ณ หน้างานหลังติดตั้ง (SAT) ให้ยืนยันภายใต้เงื่อนไขของบริษัทของท่านเองว่า “ข้อมูลไม่ขาดหาย ไม่เสียหาย เวลาถูกต้อง ดึงออกมาได้เมื่อต้องการ และกู้คืนได้แม้สูญหาย” ไม่ใช่ยืนยันจากค่าในแคตตาล็อก

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

ประเด็นเฉพาะของไทยและอาเซียน

มาตรการปรับปรุงประสิทธิภาพของ BOI

ใน “มาตรการปรับปรุงประสิทธิภาพการผลิตเพื่อยกระดับสู่อุตสาหกรรมที่ทันสมัยและยั่งยืน (Smart and Sustainable Industry)” ของคู่มือการส่งเสริมการลงทุนของสำนักงานคณะกรรมการส่งเสริมการลงทุน (BOI) (ฉบับปี 2023) สำหรับการปรับปรุงประสิทธิภาพของกิจการที่มีอยู่ (ไม่ว่าจะได้รับการส่งเสริมจาก BOI หรือไม่) มีการแสดงสิทธิประโยชน์โดยมีเงื่อนไขเงินลงทุนตั้งแต่ 1 ล้านบาทขึ้นไป (ไม่รวมค่าที่ดินและทุนหมุนเวียน) มาตรการการนำเทคโนโลยีดิจิทัลมาใช้ได้รับการยกเว้นภาษีเงินได้นิติบุคคล 3 ปี (วงเงินไม่เกิน 50% ของเงินลงทุน) และการปรับเปลี่ยนสู่ Industry 4.0 ตามแผนที่ได้รับความเห็นชอบจาก สวทช. (NSTDA) ได้รับการยกเว้นภาษีเงินได้นิติบุคคล 3 ปี (วงเงินไม่เกิน 100% ของเงินลงทุน) ข้อกำหนดของการนำเทคโนโลยีดิจิทัลมาใช้ ได้แก่ การนำซอฟต์แวร์หรือระบบสารสนเทศที่เชื่อมโยงข้อมูลของอย่างน้อย 3 ฟังก์ชันทั้งภายในและภายนอกองค์กรมาใช้ หรือการใช้ AI, machine learning, big data หรือการวิเคราะห์ข้อมูล เป็นต้น และในบางกรณีต้องลงทุนในซอฟต์แวร์ที่พัฒนาหรือปรับปรุงโดยผู้ประกอบการในประเทศไทยที่ได้รับการรับรอง นอกจากนี้ยังมีประเภทกิจการที่ไม่เข้าข่ายด้วย

อย่างไรก็ตาม นี่เป็นเอกสารฉบับปี 2023 บทความนี้ยังไม่สามารถยืนยันได้ว่า ณ เดือนตุลาคม 2026 มาตรการนี้ยังเปิดรับคำขออยู่หรือไม่ และเงื่อนไขเปลี่ยนแปลงไปหรือไม่ การติดตั้ง Historian จะเข้าข่ายได้หรือไม่ โปรดตรวจสอบประกาศรับคำขอฉบับล่าสุด และยืนยันเป็นรายกรณีกับ BOI หรือผู้เชี่ยวชาญ

พระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ของไทย

ตามบทวิเคราะห์ของสำนักงานกฎหมาย Tilleke & Gibbins (1 สิงหาคม 2025) พระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ของไทย (พ.ศ. 2562 หรือ ค.ศ. 2019) ปัจจุบันใช้บังคับกับหน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล และองค์กรที่ถูกกำหนดให้เป็นโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) ภาคส่วนของ CII ได้แก่ ความมั่นคงของรัฐ บริการภาครัฐที่สำคัญ การธนาคารและการเงิน เทคโนโลยีสารสนเทศ โทรคมนาคม การขนส่งและโลจิสติกส์ พลังงานและสาธารณูปโภค และสาธารณสุข โดยภาคการผลิตไม่ได้อยู่ในภาคส่วนปัจจุบัน องค์กร CII ต้องรายงานเหตุการณ์ครั้งแรกภายใน 24 ชั่วโมง ในร่างแก้ไขที่เผยแพร่เมื่อเดือนกรกฎาคม 2025 มีการเสนอให้เพิ่ม “industrial work” ด้วย แต่ยังอยู่ในขั้นร่าง และบทความนี้ยังไม่สามารถยืนยันได้ว่าผ่านเป็นกฎหมายแล้วหรือไม่

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

สิ่งที่ควรระวังในการใช้งานในพื้นที่

ต่อจากนี้เป็นแนวคิดของบทความนี้ ในโรงงานไทย มักพบว่าพนักงานเดินเครื่องและผู้รับผิดชอบงานบำรุงรักษาดูข้อมูลเป็นภาษาไทย พนักงานชาวญี่ปุ่นที่ประจำอยู่ดูเป็นภาษาญี่ปุ่น และสำนักงานใหญ่หรือฐานการผลิตในต่างประเทศดูเป็นภาษาอังกฤษ การที่ระบบเก็บคำอธิบายแท็กได้ 3 ภาษา และสลับภาษาของหน้าจอและรายงานได้หรือไม่ จะเป็นตัวกำหนดว่า Historian นั้นจะถูกใช้งานจริงหรือไม่ นอกจากนี้ ควรตรวจสอบก่อนติดตั้งด้วยว่า มีทีมบำรุงรักษาที่รับมือได้ในพื้นที่เมื่อเกิดเหตุขัดข้องหรือไม่ และขั้นตอนการกลับมาทำงานหลังไฟดับเขียนเป็นภาษาไทยไว้หรือไม่

หากพิจารณาไปถึงการเชื่อมต่อกับข้อมูลของหลายโรงงาน หรือของระบบอื่นนอกเหนือจาก Historian (MES คุณภาพ และการบำรุงรักษา) ก็มีแนวคิดที่วางตำแหน่ง Historian เป็น “ชิ้นส่วนที่รับผิดชอบข้อมูลส่วนหนึ่ง” โปรดอ่าน “Industrial Data Fabric สำหรับโรงงาน: RFP และการตรวจรับ” ประกอบด้วย

แผน 90 วันสำหรับการติดตั้งระบบ Historian อุตสาหกรรม

วันที่ 0–30: จัดระเบียบวัตถุประสงค์การใช้งานและสำรวจทะเบียนแท็ก

กำหนดว่าจะใช้ Historian เพื่ออะไร เช่น การสอบสวนปัญหาคุณภาพ การวิเคราะห์อุปกรณ์ พลังงาน และระบุผู้ใช้ทั้งหมด จากนั้นจัดทำรายการอุปกรณ์และแท็กเป้าหมาย แล้วบันทึกหน่วย ความแม่นยำของเครื่องมือวัด รอบที่จำเป็น และระยะเวลาเก็บรักษาลงในทะเบียน การตัดสินใจเบื้องต้นของการตัดสินใจที่ 1 ว่าข้อมูลย้อนหลังของ SCADA เพียงพอหรือไม่ จะสร้างด้วยฐานข้อมูลอนุกรมเวลาทั่วไป หรือจะติดตั้ง Historian เฉพาะทาง ก็ทำในขั้นนี้ด้วย

วันที่ 31–60: วัดจริงด้วยแท็กสำหรับทดสอบ

เลือกแท็กตัวแทนหลายสิบจุด แล้วจัดเก็บข้อมูลดิบทุกจุดคู่กับข้อมูลที่ผ่าน deadband และการบีบอัด ยืนยันร่วมกับผู้ที่มีความรู้ในหน้างานว่าความต่างสูงสุดจากข้อมูลต้นฉบับอยู่ภายในความแม่นยำของเครื่องมือวัดหรือไม่ และการเปลี่ยนแปลงสำคัญไม่หล่นหายหรือไม่ พร้อมกันนั้น ให้หยุดการสื่อสารโดยเจตนา เพื่อทดสอบว่า store-and-forward เติมข้อมูลที่ขาดหายได้หรือไม่ และเวลาถูกต้องหรือไม่ จากนั้นใช้อัตราการจัดเก็บที่ได้ในขั้นนี้ จัดทำการประมาณความจุฉบับของบริษัทของท่านใหม่

วันที่ 61–90: RFP เกณฑ์ FAT/SAT และการตัดสินใจสั่งซื้อ

จากผลการวัดจริง กำหนด RFP 12 รายการ และรายการทดสอบกับเกณฑ์ผ่านของ FAT/SAT ให้ชัดเจน แล้วขอใบเสนอราคาจากหลายบริษัทภายใต้เงื่อนไขเดียวกัน ตกลงเรื่องการวางระบบ (ฝั่ง OT และ replica ใน DMZ) และการออกแบบเครือข่าย ร่วมกับผู้รับผิดชอบ IT ของโรงงานและความปลอดภัยสารสนเทศ การเลือกเวอร์ชันของผลิตภัณฑ์ (จะติดตั้งด้วยเวอร์ชันสนับสนุนระยะยาวปัจจุบัน หรือรอเวอร์ชันถัดไป) ก็ตัดสินใจในขั้นนี้ หลังจากตรวจสอบระยะเวลาสนับสนุนที่แต่ละบริษัทเผยแพร่แล้ว

ผลงานที่ควรมีพร้อมในมือเมื่อสิ้นสุด 90 วัน มี 6 รายการ ได้แก่ (1) นิยามวัตถุประสงค์การใช้งานและผู้ใช้ (2) ทะเบียนแท็ก (พร้อมความแม่นยำ รอบ ระยะเวลาเก็บรักษา และเหตุผลของการบีบอัด) (3) บันทึกความคลาดเคลื่อนจากการบีบอัดและการทดสอบการขาดการเชื่อมต่อด้วยแท็กสำหรับทดสอบ (4) การประมาณความจุฉบับของบริษัทของท่านเอง (5) การออกแบบการวางระบบและเครือข่าย และ (6) RFP และเกณฑ์ FAT/SAT

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

Historian อุตสาหกรรมคืออะไร? ต่างจากการจัดเก็บข้อมูลของ SCADA อย่างไร?

Historian อุตสาหกรรมคือกลไกสำหรับจัดเก็บข้อมูลกระบวนการของโรงงานตามแกนเวลาในระยะยาว และนำไปใช้วิเคราะห์ NIST SP 800-82r3 นิยามว่าเป็นฐานข้อมูลแบบรวมศูนย์ที่สนับสนุนการควบคุมกระบวนการเชิงสถิติ ฟังก์ชันข้อมูลย้อนหลังของ SCADA มีวัตถุประสงค์หลักเพื่อแสดงกราฟแนวโน้มบนหน้าจอการเดินเครื่อง และบางครั้งจำกัดเฉพาะแท็กของ SCADA นั้น หรือมีระยะเวลาเก็บรักษาค่อนข้างสั้น หากต้องการเก็บข้อมูลจากหลายไลน์และหลายระบบในระยะยาว โดยแยกเป็นอิสระจากการเดินเครื่อง Historian จะเป็นตัวเลือกที่ควรพิจารณา

ควรเลือกระหว่าง Historian กับฐานข้อมูลอนุกรมเวลาทั่วไปอย่างไร?

ฐานข้อมูลอนุกรมเวลาทั่วไปมีความยืดหยุ่นสูง แต่ต้องออกแบบและดูแลเองทั้งการเก็บข้อมูล แฟล็กคุณภาพ ข้อมูลที่มาไม่ตามลำดับ การบีบอัด ระยะเวลาเก็บรักษา และการจัดการสิทธิ์ ส่วน Historian เฉพาะทางมีจุดเด่นคือมักมีฟังก์ชันเหล่านี้มาในตัวผลิตภัณฑ์ ให้ตัดสินจากปัจจัย เช่น ฝ่าย IT มีประสบการณ์และกำลังคนในการดูแลฐานข้อมูลอนุกรมเวลาหรือไม่ และไม่ต้องการขังข้อมูลไว้ในรูปแบบของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งหรือไม่ ระยะหลังนี้ ผู้จำหน่ายซอฟต์แวร์อุตสาหกรรมก็ได้ประกาศโครงสร้างที่ใช้ฐานข้อมูลอนุกรมเวลาทั่วไปเป็นฐานด้านหลังด้วย

ในการจัดเก็บข้อมูลกระบวนการผลิตระยะยาว ควรกำหนดการบีบอัดและ deadband อย่างไร?

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

ควรวาง Historian ไว้ที่ใดในเครือข่าย?

ตัวอย่างการออกแบบของบทความนี้คือ วาง Historian หลักไว้ฝั่ง OT วาง replica สำหรับทั้งองค์กรไว้ใน DMZ และให้ผู้ใช้ในเครือข่ายองค์กรเข้าถึงได้เฉพาะ replica นี่เป็นแนวคิดที่อนุมานจากหลักการของ NIST SP 800-82r3 ที่ว่าการสื่อสารระหว่างองค์กรกับ OT ต้องผ่านบริการใน DMZ โดย NIST ไม่ได้กำหนดการวางระบบแบบนี้ นอกจากนี้ NIST ยังยก database link ที่ทำสำเนาข้อมูลของ Historian ไปยังฐานข้อมูลอื่นโดยอัตโนมัติ เป็นตัวอย่างของสิ่งที่อาจกลายเป็นช่องโหว่หากกำหนดค่าไม่เหมาะสม

ใน RFP และ FAT/SAT ของ Historian ควรยืนยันอะไรบ้าง?

ใน RFP ให้เขียนเรื่องทะเบียนแท็ก พฤติกรรมการลดจำนวนข้อมูลตามแต่ละวิธีการเก็บข้อมูล วิธีการบีบอัดและค่าเริ่มต้น เวลาและคุณภาพ ความจุของ store-and-forward และข้อมูลที่มาไม่ตามลำดับ ระยะเวลาจัดเก็บ การวางระบบ วิธีนำข้อมูลออก วิธีนับไลเซนส์และการสนับสนุนระยะยาว audit trail และการสนับสนุนในพื้นที่ ใน FAT/SAT ให้ยืนยันการเติมข้อมูลที่ขาดหายหลังการสื่อสารขาด ความคลาดเคลื่อนจากการบีบอัด ความถูกต้องของเวลา แฟล็กคุณภาพ ประสิทธิภาพของคิวรี ความตรงกันของ replica การกู้คืนจากข้อมูลสำรอง และการกลับมาทำงานหลังไฟดับ

ค่าใช้จ่ายของ Historian เป็นอย่างไร?

ค่าใช้จ่ายแตกต่างกันมากตามวิธีนับไลเซนส์ (จำนวนแท็ก จำนวนการเชื่อมต่อ จำนวนเซิร์ฟเวอร์ เป็นต้น) ความจุและโครงสร้างเซิร์ฟเวอร์ ชนิดและจำนวนของอุปกรณ์เป้าหมายที่เก็บข้อมูล การมีหรือไม่มี replica ใน DMZ การเชื่อมต่อกับระบบที่มีอยู่ และขอบเขตของการทดสอบรับมอบ บทความนี้ไม่มีข้อมูลราคาจากแหล่งปฐมภูมิ จึงไม่ได้ประมาณเป็นจำนวนเงิน แต่ความจุสามารถประมาณได้จากจำนวนแท็ก × รอบการเก็บข้อมูล × อัตราการจัดเก็บ ดังเช่นแบบจำลองสมมติในเนื้อหา วิธีที่แน่นอนคือ เริ่มจากจัดทำทะเบียนแท็ก วัดอัตราการจัดเก็บจริงด้วยแท็กสำหรับทดสอบ แล้วจึงเปรียบเทียบใบเสนอราคา สำหรับคำถามว่าจะเข้าข่ายมาตรการส่งเสริมของ BOI หรือไม่ โปรดยืนยันเป็นรายกรณีกับ BOI หรือผู้เชี่ยวชาญ

สรุป

• คุณค่าของ Historian อุตสาหกรรมไม่ได้อยู่ที่ปริมาณการจัดเก็บ แต่อยู่ที่การเก็บ “ข้อมูลอนุกรมเวลาที่เชื่อถือได้ มีบริบทกำกับ และนำกลับมาแสดงย้อนหลังได้ในภายหลัง”
• การตัดสินใจแรกคือ ข้อมูลย้อนหลังของ SCADA เพียงพอหรือไม่ จะสร้างด้วยฐานข้อมูลอนุกรมเวลาทั่วไป หรือจะติดตั้ง Historian เฉพาะทาง การเปรียบเทียบผลิตภัณฑ์มาทีหลัง
• เอกสารออกแบบที่แท้จริงคือทะเบียนแท็ก กำหนดรอบจากวัตถุประสงค์การใช้งาน กำหนดว่าจะประทับเวลาที่จุดใด และเก็บแฟล็กคุณภาพไว้คู่กับค่า ป้องกันข้อมูลขาดหายเมื่อการเชื่อมต่อขาดด้วย store-and-forward
• กำหนด deadband และการบีบอัดโดยยึดความแม่นยำของเครื่องมือวัด ตรวจสอบความต่างจากข้อมูลต้นฉบับด้วยแท็กสำหรับทดสอบก่อนขยายผล และไม่เริ่มใช้งานด้วยค่าเริ่มต้น
• ในแบบจำลองสมมติ ข้อมูลดิบของ 2,000 แท็ก รอบ 1 วินาที มีประมาณ 1,009 GB ต่อปี หากสมมติอัตราการจัดเก็บไว้ที่ 10–100% ความจุจะต่างกัน 10 เท่า ควรประมาณบัฟเฟอร์สำหรับการขาดการเชื่อมต่อ 72 ชั่วโมง และเวลาจนตามทันหลังกู้คืนด้วย
• สำหรับการวางระบบ ตัวอย่างการออกแบบที่พิจารณาได้คือ Historian หลักฝั่ง OT และ replica ใน DMZ ควรหลีกเลี่ยงการทำสำเนาอัตโนมัติแบบเชื่อมต่อตรง
• ในการรับมอบ ให้ยืนยันการเติมข้อมูลที่ขาดหาย ความคลาดเคลื่อนจากการบีบอัด เวลา ประสิทธิภาพของคิวรี และการกู้คืน ภายใต้เงื่อนไขของบริษัทของท่านเอง

TOMAS TECH ให้คำปรึกษาแก่โรงงานญี่ปุ่นในไทย ตั้งแต่ขั้นพิจารณา เช่น การจัดระเบียบวัตถุประสงค์การใช้งาน Historian การสำรวจทะเบียนแท็ก การตรวจสอบความคลาดเคลื่อนจากการบีบอัดด้วยแท็กสำหรับทดสอบ และการประมาณความจุ ไปจนถึงการจัดทำ RFP การออกแบบการวางระบบในเครือข่าย การเข้าร่วมสังเกตการณ์ FAT/SAT และการเชื่อมต่อกับ SCADA หรือระบบบริหารการผลิตที่มีอยู่ แม้อยู่ในขั้นที่ “ยังไม่ถึงขั้นเลือกผลิตภัณฑ์ แต่อยากรู้ว่าควรเริ่มจัดระเบียบจากอะไร” ก็สามารถติดต่อเราได้ผ่านแบบฟอร์มติดต่อ

แหล่งอ้างอิง

• NIST “SP 800-82 Rev.3 Guide to Operational Technology (OT) Security” (กันยายน 2023): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
• AVEVA (Brent Bregenzer) “Exception, Compression, and their Impacts on PI System Performance” (เอกสารการบรรยาย AVEVA World San Francisco ปี 2023): https://cdn.osisoft.com/osi/presentations/2023-AVEVA-San-Francisco/UC23NA-3PGK04-AVEVA_Bregenzer_Brent-Exception-Compression-and-their-Impacts-On-PI-System-Performance.pdf
• OPC Foundation “OPC 10000-11 UA Part 11: Historical Access” (29 พฤศจิกายน 2024): https://opcfoundation.org/developer-tools/documents/view/168
• OPC Foundation “OPC 10000-13 UA Part 13: Aggregates” (15 เมษายน 2026): https://reference.opcfoundation.org/Core/Part13/v105/docs/
• Inductive Automation “Inductive Automation Releases Ignition 8.3” (16 กันยายน 2025): https://inductiveautomation.com/news/inductive-automation-releases-ignition-83
• Inductive Automation เอกสาร “Core Historian (QuestDB)”: https://www.docs.inductiveautomation.com/docs/8.3/ignition-modules/tag-historian/tag-history-providers/internal-historian-questdb
• QuestDB “Ignition 8.3”: https://questdb.com/docs/integrations/other/ignition/
• InfluxData “InfluxData announces InfluxDB 3 OSS GA” (15 เมษายน 2025): https://www.influxdata.com/blog/influxdata-announces-influxdb-3-OSS-GA
• Tiger Data “Timescale becomes Tiger Data” (17 มิถุนายน 2025): https://www.tigerdata.com/blog/timescale-becomes-tigerdata
• Canary Labs เว็บไซต์ทางการ: https://www.canarylabs.com/
• AVEVA เอกสาร “PI Server 2024”: https://docs.aveva.com/category/pi-server-2024
• Cornell Law School LII “21 CFR § 11.10 Controls for closed systems”: https://www.law.cornell.edu/cfr/text/21/11.10
• BOI “Measure for Industrial Upgrades towards Smart and Sustainable Industry” (ส่วนหนึ่งของคู่มือการส่งเสริมการลงทุน 2023): https://www.boi.go.th/upload/content/Smart_and_Sustainable_Industry.pdf
• Tilleke & Gibbins “Major Draft Amendments to Thai Cybersecurity Act Released for Public Hearing” (1 สิงหาคม 2025): https://www.tilleke.com/insights/major-draft-amendments-to-thai-cybersecurity-act-released-for-public-hearing/
• Inductive Automation “Inductive Automation Reveals Ignition 2027 and Strategic Growth Initiatives at ICC 2026” (23 กันยายน 2026): https://inductiveautomation.com/news/inductive-automation-reveals-ignition-2027-and-strategic-growth-initiatives-at-icc-2026
• Inductive Automation “ICC 2026 Recap: Three Days of Innovation Unleashed” (30 กันยายน 2026): https://inductiveautomation.com/blog/icc-2026-recap-three-days-of-innovation-unleashed
• GlobeNewswire “Inductive Automation and Tiger Data Collaborate to Modernize the Industrial Historian Market” (20 เมษายน 2026): https://www.globenewswire.com/news-release/2026/04/20/3277103/0/en/inductive-automation-and-tiger-data-collaborate-to-modernize-the-industrial-historian-market.html