Ignition คือ ชุดเครื่องมือสำหรับการพัฒนา (Development Toolkit) ที่มาพร้อมการให้สิทธิ์ใช้งานแบบไม่จำกัด (Unlimited Licensing) และมอดูลที่หลากหลาย ช่วยให้คุณสร้างโซลูชันการทำงานได้อย่างอิสระ โครงการ Ignition สามารถเป็นได้ตั้งแต่ระบบเก็บข้อมูลขนาดเล็กสำหรับ Tag ไม่กี่รายการ ไปจนถึงโซลูชันระดับองค์กรขนาดใหญ่ที่มีอุปกรณ์หลายร้อยเครื่อง Tag เป็นแสนๆ รายการ และ Visualization Client ผู้ใช้งานหลายร้อยเครื่อง
ดังนั้น การเลือกสถาปัตยกรรม (Architecture) และขนาดของเซิร์ฟเวอร์ (Sizing) ให้ถูกต้องและเหมาะสมจึงมีความสำคัญอย่างยิ่ง เพื่อให้โครงการทำงานได้ตามเป้าหมาย และรองรับการขยายตัวในอนาคตได้อย่างมีประสิทธิภาพ
ก่อนจะลงลึกในเรื่องสถาปัตยกรรมประเภทต่างๆ สิ่งสำคัญแรกคือต้องทำความเข้าใจเกี่ยวกับ Ignition Editions แต่ละรุ่นก่อน:
รุ่นต่างๆ ของ Ignition (Ignition Editions)
1. Ignition (Standard)
เป็นแพลตฟอร์มหลักที่ครอบคลุมการใช้งานส่วนใหญ่ มีชุดไดรเวอร์สำหรับเชื่อมต่ออุปกรณ์และฐานข้อมูลที่หลากหลาย ทำหน้าที่เป็นศูนย์กลางเชื่อมโยงทุกระบบในโรงงานเข้าด้วยกันเพื่อการบูรณาการแบบครบวงจร
2. Ignition Edge
เป็นเวอร์ชันขนาดเบาและประหยัดทรัพยากร (Lightweight & Lean) ออกแบบมาสำหรับติดตั้งบนอุปกรณ์ภาคสนาม (Field Devices) หรืออุปกรณ์ OEM ที่อยู่บริเวณขอบของเครือข่าย (Edge Network)
3. Ignition Cloud Edition
เป็นเวอร์ชันที่ออกแบบตามสถาปัตยกรรมคลาวด์ แตกต่างจากรุ่น Standard และ Edge ที่ติดตั้งแบบซอฟต์แวร์ทั่วไป โดย Cloud Edition จะให้บริการผ่าน Marketplace ของผู้ให้บริการคลาวด์ชั้นนำ เช่น Amazon Web Services (AWS) และ Microsoft Azure
นอกจากรูปแบบการจัดจำหน่ายแล้ว Cloud Edition ยังมีความแตกต่างสำคัญอื่นๆ เช่น ลักษณะการเชื่อมต่ออุปกรณ์ และความละเอียดในการเลือกใช้วิธีการบริหารจัดการมอดูล (Module Granularity)
ปัจจัยที่มีผลต่อประสิทธิภาพและขนาดของระบบ
ประสิทธิภาพและการกำหนดขนาดฮาร์ดแวร์ของ Ignition ขึ้นอยู่กับปัจจัยหลักดังนี้:
จำนวนการเชื่อมต่ออุปกรณ์ (Device Connections)
ประเภทของ PLC / Driver ที่ใช้งาน
จำนวน Tag ในระบบ
ความถี่ในการดึงข้อมูล Tag (Polling Rate เช่น ทุก 1 วินาที, 5 วินาที, 1 นาที ฯลฯ)
อัตราการเปลี่ยนแปลงของค่า Tag ต่อวินาที (% Change Rate)
จำนวนผู้ใช้งานที่เชื่อมต่อพร้อมกัน (Concurrent Visualization Clients)
ปริมาณข้อมูลเข้า/ออกของ SQL Database (Historian, Alarm Journal ฯลฯ)
รูปแบบการติดตั้ง (Physical Machine, Virtual Machine ฯลฯ)
เครือข่ายและค่าความหน่วง (Network & Latency)
ฟีเจอร์ของ Ignition ที่ส่งผลต่อภาระงานเซิร์ฟเวอร์
ฟีเจอร์ที่คุณเลือกใช้ใน Ignition จะดึงพลังประมวลผล (CPU) และหน่วยความจำ (RAM) ของเซิร์ฟเวอร์ไปใช้งาน ตัวอย่างเช่น:
การสื่อสารและส่งข้อมูล: Device Communication, OPC-UA (ทั้ง Client และ Server)
การประมวลผล Tag: OPC Tags, Expression Tags, SQL Query Tags
ระบบข้อมูลประวัติ: Historian (ทั้งการบันทึก Storage และการเรียกดู Retrieval)
ระบบแจ้งเตือน: Alarming (Status, Journal, Notification Pipelines)
การประมวลผลข้อมูล: Transaction Groups (โดยเฉพาะกรณีมีจำนวนมาก)
การประมวลผลอัตโนมัติ: การออกรายงาน PDF ตามเวลา (Scheduled Reports), Sequential Function Charts (SFC)
สคริปต์การทำงาน: Tag Change Scripts และสคริปต์ที่รันบน Gateway (Timer, Message Handlers ฯลฯ)
การแสดงผล (Visualization Clients):
จำนวน Tag ที่แสดงผลบนหน้าจอ
คำสั่งดึงข้อมูล (Polling Queries) เช่น Tag Historian, Alarming, Custom Queries
จำนวน Gateway Requests
การทำงานขั้นสูง: Gateway Network (Remote Services, EAM), ฟังก์ชัน MES, การส่งข้อมูลเข้า MQTT หรือ Cloud Injection
Ignition ถูกออกแบบมาให้ทำงานแบบ Multithreaded อย่างเต็มรูปแบบ จึงรองรับการตั้งค่าฟีเจอร์ที่หลากหลายข้างต้นได้เป็นอย่างดีหากอยู่ในขอบเขตที่เหมาะสม
Architectures
ตัวอย่างสถาปัตยกรรมพื้นฐาน (Basic Architecture Examples)
Single Gateway
เป็นสถาปัตยกรรมพื้นฐานที่พบได้บ่อยที่สุดของ Ignition ประกอบด้วย Ignition Gateway แบบ On-premise เพียงเครื่องเดียว เชื่อมต่อไปยัง SQL Database, PLCs และ Clients โดยฟังก์ชันการทำงานทั้งหมดจะถูกตั้งค่าอยู่บน Gateway เดียวกันนี้
แม้ว่า Licensing ของ Ignition จะเป็นแบบ Unlimited แต่ขีดความสามารถจะขึ้นอยู่กับขนาดและสเปกของ Hardware เป็นหลัก หากใช้ Hardware ที่มีประสิทธิภาพสูงขึ้น Ignition จะสามารถรองรับ Device Connections, Tags และ Clients ได้มากขึ้น
Scale-Out Architecture
สำหรับระบบขนาดใหญ่ การแยกภาระงาน (Load) ระหว่างงานฝั่ง Back-End และ Front-End โดยใช้ Ignition หลายเครื่อง จะช่วยบริหารจัดการระบบได้ง่ายขึ้น เหมาะสำหรับระบบขนาดใหญ่ที่อยู่ใน Site เดียวกัน (หากระบบกระจายอยู่หลายพื้นที่หรือคนละ Site มักจะนิยมใช้ Hub and Spoke Architecture มากกว่า)
ในโครงสร้างแบบ Scale-Out Architecture จะแบ่งการทำงานดังนี้:
Back-End Gateway: ทำหน้าที่จัดการการเชื่อมต่อและการสื่อสารกับ PLCs และ Devices ทั้งหมด
Front-End Gateway: ทำหน้าที่รองรับ Clients และแสดงผลข้อมูลที่ดึงมาจาก Back-End Gateway
การทำงานรูปแบบนี้อาศัย Gateway Network ในการเชื่อมต่อ Gateways เข้าด้วยกัน และแชร์ Tags ผ่าน Remote Tag Providers ทั้งนี้ สถาปัตยกรรมแบบ Scale-Out สามารถปรับใช้ได้ไม่ว่าจะติดตั้งแบบ On-premise ทั้งหมด หรือเป็นแบบ Hybrid ร่วมกับ Cloud Provider
Gateway Network
Gateway Network ช่วยให้คุณสามารถเชื่อมต่อหลาย Gateways เข้าด้วยกันผ่าน Wide Area Network (WAN) และเปิดใช้ฟีเจอร์แบบกระจายศูนย์ (Distributed Features) ระหว่าง Gateway ได้
คุณสมบัติหลักของ Gateway Network:
มีช่องทางส่งข้อมูล Dedicated HTTP Data Channel ที่รองรับการรับส่งข้อความได้หลาย Stream
สามารถตั้งค่า Node ให้ทำหน้าที่เป็น Proxy แทน Node อื่นได้
ระบบความปลอดภัยที่สามารถจำกัด Connection ขาเข้า โดยใช้ Whitelist หรือการอนุมัติแบบ Manual Approval รวมถึงสามารถ Disable Connection ขาเข้าทั้งหมดได้
รองรับ SSL Mode เมื่อเปิดใช้งาน จะต้องมีการส่ง SSL Certificate เพื่อยืนยันตัวตน โดยระบบจะไม่ยอมรับ Connection จนกว่า SSL Certificate จะได้รับอนุมัติ และสามารถตั้งค่าให้เรียกตรวจทั้ง Client Certificate และ Server Certificate ได้
Enterprise Administration
มอดูล Enterprise Administration Module (EAM) ใช้ Gateway Network ในการส่ง Message และ Transfer File รวมถึงเฝ้าระวังการเชื่อมต่อในเครือข่าย หากการสื่อสารขัดข้อง EAM จะรายงานผ่าน Alarm Events และ System Tags
บริการแบบกระจายศูนย์ (Distributed Services)
Remote Realtime Tag Providers: ช่วยให้สามารถ Read/Write ข้อมูล Tags จาก Ignition Server ฝั่ง Remote ได้ เหมาะสำหรับ Front-End Server ที่ต้องการดึงข้อมูล Tags จาก Back-End โดยรองรับทั้งการอ่าน/เขียนค่า Tag, การดู Alarm และการ Query ข้อมูล Historical
Remote Historical Tag Providers: สามารถส่งข้อมูล Historical ไปบันทึกลง SQL Database บน Ignition Server อีกเครื่องได้ และรองรับการ Query ข้อมูล Historical ระยะไกลเมื่อไม่มีการเชื่อมต่อตรงกับ SQL Database
Remote Alarming: ส่งการแจ้งเตือน Alarm ไปยัง Ignition Server เครื่องอื่น เหมาะสำหรับกรณีที่ระบบ Email, Voice หรือ SMS ถูกตั้งค่าไว้ที่ Central Ignition Server เพียงเครื่องเดียว
Remote Alarm Journal: ส่งประวัติ Alarm History ไปจัดเก็บลง SQL Database บน Ignition Server เครื่องอื่น
Remote Audit Logs: ส่ง Audit Logs ไปจัดเก็บลง SQL Database บน Ignition Server เครื่องอื่น
Security Zones และ Service Security
สามารถตั้งค่า Security Zones เพื่อล็อกหรือป้องกันการเข้าถึงบางส่วนของ Gateway ภายใน Gateway Network รวมถึงกำหนดระดับความปลอดภัย (Service Level Security) ในแต่ละระบบ เพื่อระบุว่ายินยอมให้ Remote Ignition Gateway ดำเนินการอะไรได้บ้าง
ตัวอย่าง Scale-Out Architecture
One Back-End Gateway / One Front-End Gateway
สถาปัตยกรรมรูปแบบนี้จะแบ่งภาระงานออกเป็น Ignition Gateway จำนวน 2 เครื่อง โดยแบ่งหน้าที่ตามการประมวลผลชัดเจน:
Back-End Gateway: ทำหน้าที่สื่อสารกับ PLCs และประมวลผลงานฝั่ง Back-End ทั้งหมด เช่น การดึงค่า Real-time (Polling live values), Historian และ Alarming รวมถึงรับผิดชอบการจัดเก็บข้อมูล (Logging) ลงใน SQL Database
Front-End Gateway: ทำหน้าที่จัดการ Visualization Clients ทั้งหมด (ทั้ง Vision และ Perspective) รวมถึงเชื่อมต่อไปยัง SQL Database เพื่อดึงข้อมูลประวัติ (Query Historical Data) มาแสดงผลบนหน้าจอผู้ใช้งาน
ข้อดีของสถาปัตยกรรมนี้
รองรับภาระงานได้มากขึ้น: การแยก Gateway ออกเป็น 2 เครื่อง ช่วยเพิ่มขีดความสามารถให้รองรับ Device Connections, Tags และ Clients ได้มากกว่าการใช้ Gateway เดียว
ขยายระบบได้ง่าย (Scalability): เมื่อโครงการเติบโตขึ้นในอนาคต คุณสามารถขยายระบบต่อเติมได้ทันที โดยการเพิ่ม Back-End Gateways หรือ Front-End Gateways ได้อย่างยืดหยุ่น
One OPC UA Gateway / One Back-End Gateway / One Front-End Gateway
สถาปัตยกรรมแบบแยก Dedicated OPC UA Gateway
สถาปัตยกรรมรูปแบบนี้มีการนำ Dedicated OPC UA Gateway เข้ามาทำหน้าที่จัดการการสื่อสารกับ PLCs ทั้งหมดโดยเฉพาะ ซึ่งเป็นการแยกบทบาทการทำงานของ OPC UA ออกมาจาก Gateway หลักอย่างชัดเจน
รองรับ Devices ได้มากขึ้น: การแยก OPC UA ออกมา ช่วยให้ระบบสามารถเชื่อมต่อและสื่อสารกับอุปกรณ์จำนวนมากได้อย่างมีประสิทธิภาพ
ลดภาระของ Back-End Gateway: ตัว Back-End Gateway จะทำหน้าที่เน้นประมวลผลเฉพาะการเปลี่ยนแปลงของค่า Tags (Tag value changes) เท่านั้น
ขยายระบบได้ง่าย (Scalability): คุณสามารถรองรับ Tags จำนวนมหาศาล ทั้งในส่วนของ History และ Alarming ได้อย่างสะดวก เพียงแค่เพิ่ม OPC UA Gateways เข้ามาเพื่อดูแลกลุ่ม PLCs ชุดใหม่ๆ ที่เพิ่มเข้ามาในระบบ
Two Back-End Gateways / One Front-End Gateway
ด้วยสถาปัตยกรรมนี้ คุณจะมี Ignition Back-End Gateways จำนวน 2 เครื่องที่ทำหน้าที่สื่อสารกับ PLCs คนละชุดกัน ซึ่งช่วยให้รองรับการเชื่อมต่อกับ Devices และ Tags ได้เป็นจำนวนมาก ตัวอย่างเช่น สามารถจัดการข้อมูลได้ประมาณ 250,000 Tags จาก 200 Devices และยังสามารถขยายระบบด้วยการเพิ่ม Back-End Gateways ตามความจำเป็นได้อย่างง่ายดาย
แนวทางปฏิบัติที่ดีที่สุดสำหรับ Tag Provider (Tag Provider Best Practice)
เมื่อใช้ Scale-Out Architecture สิ่งสำคัญอย่างยิ่งคือต้องตั้งชื่อ Tag Providers ให้เหมาะสม และใช้ชื่อที่ตรงกันทั้งในฝั่ง Back-End และ Front-End Gateways ควรหลีกเลี่ยงการใช้ Default Provider ที่ติดมากับการติดตั้งมาตรฐาน
แนวทางที่นิยมทำคือ การสร้าง Realtime Tag Provider ขึ้นมาใหม่บน Back-End Gateway โดยตั้งชื่อให้สื่อถึงหน้าที่ของ Back-End Gateway เครื่องนั้นเพื่อไม่ให้สับสนกับเครื่องอื่น จากนั้นบน Front-End Gateway ให้สร้าง Remote Tag Provider โดยใช้ชื่อเดียวกันกับ Back-End Server เพื่อให้การอ้างอิงข้อมูลสอดคล้องกันทั้งสองฝั่ง
เส้นทางอ้างอิง Tag (Tag Paths)
ขอแนะนำให้ใช้ Fully-Qualified Tag Paths ในโปรเจกต์ของคุณเสมอ โดยเฉพาะกับ Visualization Templates และ Screens เนื่องจาก Fully-Qualified Path จะช่วยให้ Ignition ทราบตำแหน่งที่แน่นอนของ Tag ซึ่งรวมถึงชื่อของ Tag Provider ด้วย
ตัวอย่าง Non-Fully-Qualified Tag Path (เส้นทางที่ไม่ระบุ Provider):
Path/to/my/tag
หากใช้ Path รูปแบบนี้ ระบบจะไม่ทราบว่า Tag นำมาจาก Tag Provider ใด ส่งผลให้โปรเจกต์ของ Ignition ต้องดึงข้อมูลผ่าน Default Tag Provider ของโปรเจกต์เพียงอย่างเดียว
ตัวอย่าง Fully-Qualified Tag Path (เส้นทางที่ระบุ Provider ชัดเจน):
[TagProviderName]Path/to/my/tag
สังเกตได้ว่าใน Path จะมีการระบุชื่อ Tag Provider ไว้อย่างชัดเจน วิธีนี้ช่วยให้คุณสามารถส่งค่า Parameter เข้าไปใน Visualization Template เพื่อเปลี่ยนทั้ง Tag Provider และ Tag Path ได้อย่างยืดหยุ่น ทำให้ชี้ไปยัง Tag ใดๆ จาก Provider ตัวใดก็ได้ในระบบ
Full Scale-Out With Load Balancer
ข้อดีที่สุดของ Scale-Out Architecture คือสามารถขยายระบบ (Scale Up) ของ Ignition ได้อย่างง่ายดายเมื่อระบบของคุณเติบโตขึ้น โดยสามารถเพิ่ม Front-End Gateways เพื่อช่วยรองรับจำนวน Clients ที่เพิ่มขึ้น และใช้ Load Balancer ในการจัดสรรและกระจาย Clients ไปยังแต่ละเครื่องโดยอัตโนมัติ
เมื่อใช้งาน Load Balancer สิ่งสำคัญอย่างยิ่งคือต้องเปิดใช้งานฟังก์ชัน “Sticky” Sessions เพื่อให้มั่นใจว่า Connection ของผู้ใช้จะมีความเสถียรและต่อเนื่องกับเครื่องเดิมอย่างน้อย 1 ชั่วโมง โดย Front-End Gateway จำเป็นต้องทำงานแบบ Stateless โดยสมบูรณ์ เนื่องจากบทบาทหน้าที่คือการดึงข้อมูลทั้งหมดมาจาก Back-End Gateways และบริการ SQL Database เท่านั้น
การนำสถาปัตยกรรมนี้มาใช้ ร่วมกับการกำหนดจำนวน Front-End Gateways ที่เหมาะสม จะทำให้ระบบสามารถรองรับ Concurrent Clients ได้มากถึงหลักพันเครื่อง พร้อมทั้งรองรับ Devices และ Tags จำนวนมหาศาลได้อย่างมีประสิทธิภาพ
ตัวอย่างของ Load Balancers:
F5 Load Balancer
HAProxy
AWS / Azure LB
Hub and Spoke
Hub and Spoke Architecture ประกอบด้วย 2 ส่วนหลัก ดังนี้:
ส่วน Hub: คือ Ignition Cloud Edition Gateway ที่มาพร้อมมอดูลต่างๆ เช่น Perspective, MQTT (และอื่นๆ) ทำงานร่วมกับบริการ Database ของ Cloud Provider
ส่วน Spoke: ประกอบด้วย Ignition Gateway (ไม่ว่าจะเป็นรุ่น Edge หรือ standard) ที่เชื่อมต่อเข้ากับ Field Devices ภาคสนาม พร้อมมอดูล OPC UA และ SQL Bridge Modules โดยเน้นรับหน้าที่ทำ Data Logging เป็นหลัก
แต่ละ Site จะทำงานเป็นอิสระจากกันอย่างสมบูรณ์ โดยมีระบบ History, Alarms และ Clients เป็นของตัวเอง ในขณะที่ Ignition Cloud Edition Gateway ฝั่ง Hub จะทำหน้าที่รวบรวมข้อมูล (Data Consolidation) จากทุกๆ Sites เข้าด้วยกัน เพื่อเปิดมุมมองให้ผู้ใช้เห็นภาพรวมทั้งหมดขององค์กรได้อย่างมีประสิทธิภาพ
Elastic
การเชื่อมต่อ Ignition Cloud Edition Gateway เข้ากับ Standard Ignition Gateway ช่วยให้องค์กรสามารถสร้าง Elastic Enterprise Architecture ที่ปรับเปลี่ยนขนาดตามความต้องการใช้งานจริง (Scale on demand) ได้อย่างยืดหยุ่น โดยใช้ Public Cloud หรือ Private Cloud ขององค์กรเอง
เนื่องจาก AWS และ Azure เป็นผู้ให้บริการโฮสต์ Ignition Cloud Edition ผู้ใช้งานจึงไม่ต้องรับภาระในการดูแลรักษา Cloud Server Hardware ซึ่งช่วยให้คุณสามารถเพิ่มหรือลดทรัพยากรจัดเก็บข้อมูล (Storage) รวมถึงกำลังการประมวลผล (Cloud Computing Power) ได้ตามความต้องการตลอดเวลา
สิ่งนี้ช่วยขจัดความจำเป็นในการลงทุนซื้อ Server Hardware ล่วงหน้า ทำให้สามารถพัฒนาและติดตั้งใช้งาน Enterprise Applications พร้อมทั้งขยายสถาปัตยกรรมของระบบได้อย่างรวดเร็วยิ่งขึ้น
การวางสถาปัตยกรรมสำหรับ Ignition SCADA ไม่มีคำว่า "รูปแบบที่ดีที่สุด" มีเพียง "รูปแบบที่เหมาะสมที่สุด" กับโจทย์และเป้าหมายขององค์กรคุณเท่านั้น แม้จุดเด่นของ Ignition คือให้สิทธิ์ใช้งานแบบไม่จำกัด (Unlimited Licensing) แต่ประสิทธิภาพสูงสุดจะเกิดขึ้นได้ก็ต่อเมื่อมีการประเมินขนาดฮาร์ดแวร์ (Sizing) และเลือกวางโครงสร้างระบบได้อย่างถูกต้องตั้งแต่เริ่มต้น ไม่ว่าจะเป็น Single Gateway ขนาดเล็ก หรือระบบ Scale-Out / Hub & Spoke ระดับองค์กร การวางรากฐานที่รัดกุมจะช่วยลดภาระงานของระบบ ลดต้นทุนการดูแลรักษาระยะยาว และทำให้ระบบ SCADA ของคุณพร้อมขยายตัวรับความท้าทายใหม่ๆ ในอนาคตได้อย่างมั่นใจ