หนึ่งในหลักการพื้นฐานที่สุดของสถาปัตยกรรมคือ โครงสร้างจะแข็งแกร่งได้ก็ต่อเมื่อสร้างอยู่บนรากฐานที่มั่นคง ในปัจจุบัน องค์กรต่างๆ ต้องเผชิญกับความท้าทายเพิ่มเติมในการสร้างโครงสร้างพื้นฐานทางเทคโนโลยีที่ไม่เพียงแต่ต้องแข็งแกร่งเท่านั้น แต่ยังต้องมีความยืดหยุ่นอีกด้วย
อินเทอร์เน็ตยังคงเปลี่ยนรูปแบบการดำเนินธุรกิจอย่างต่อเนื่อง ภาคอุตสาหกรรมกำลังอยู่ในช่วงเปลี่ยนผ่าน ตลาดใหม่ๆ กำลังเปิดตัว และพฤติกรรมของผู้บริโภคก็กำลังเปลี่ยนแปลงไป แม้ว่าสถาปัตยกรรมระบบของคุณจะทำงานได้ดีในปัจจุบัน แต่ระบบนั้นมีความสามารถในการขยาย (Scalable) พอที่จะปรับตัวตามความเปลี่ยนแปลงที่ไม่คาดคิดหรือไม่?
องค์กรในภาคอุตสาหกรรมหลายแห่งกำลังตั้งคำถามนี้กับตัวเอง และมีจำนวนมากขึ้นเรื่อยๆ ที่เปลี่ยนมาใช้ Ignition โดย Inductive Automation® เป็นแพลตฟอร์มระบบอัตโนมัติสำหรับอุตสาหกรรม Ignition เป็นซอฟต์แวร์ SCADA ที่มีความสามารถในการขยายระบบได้อย่างโดดเด่น และสามารถนำไปติดตั้งใช้งานในสถาปัตยกรรมหลากหลายรูปแบบได้เนื่องจากมีโครงสร้างแบบโมดูลาร์ (Modular)
การสร้างระบบบนแพลตฟอร์มแบบโมดูลาร์
หากซอฟต์แวร์ SCADA แบบโมดูลาร์ฟังดูเป็นแนวคิดที่แปลกใหม่ ความหมายของมันอย่างง่ายๆ ก็คือ ผู้ใช้สามารถสร้างและปรับแต่งแพลตฟอร์ม Ignition ได้โดยการเพิ่มโมดูลซอฟต์แวร์เข้าไป ลองนึกถึงวิธีที่แอปพลิเคชันเพิ่มฟังก์ชันการทำงานเฉพาะด้านให้กับสมาร์ทโฟน หรือโปรแกรมเพิ่มฟังก์ชันให้กับ PC ในทำนองเดียวกัน โมดูลที่คุณเพิ่มเข้าไปในแพลตฟอร์ม Ignition จะเป็นตัวกำหนดสิ่งที่คุณสามารถทำได้ด้วยระบบนี้
ตัวแพลตฟอร์ม Ignition เองเป็น Industrial Application Server แบบ Web-based ที่มาพร้อมกับฟีเจอร์สำคัญมากมาย
มาพร้อมกับแอปพลิเคชัน Designer ในตัว ให้การเชื่อมต่อกับฐานข้อมูล (Database) รวมถึงการเชื่อมต่อแบบ OPC ที่ช่วยให้สามารถสื่อสารกับอุปกรณ์ที่แตกต่างกันได้นับพันรายการ มีฟีเจอร์ Store-and-Forward ตลอดจนฟีเจอร์ Alarming, Security และ Redundancy นอกจากนี้ยังมี Real-time Tag Database, Application Program Interface (API) และฟีเจอร์ทรงประสิทธิภาพอื่นๆ อีกมากมาย
แม้ว่าแพลตฟอร์มของ Ignition จะมีความสามารถมากมาย แต่สิ่งที่องค์กรอุตสาหกรรมส่วนใหญ่ใช้งาน Ignition นั้นทำผ่านการใช้โมดูล คุณสามารถใช้แพลตฟอร์ม Ignition เชื่อมต่อกับ PLC และฐานข้อมูลได้ แต่หากคุณต้องการบันทึกและแสดงผลข้อมูลจากการเชื่อมต่อเหล่านั้น เพื่อให้สามารถเข้าถึงได้จากอุปกรณ์ต่างๆ ในสถานที่ที่แตกต่างกัน หรือนำไปทำประโยชน์อื่นๆ คุณจำเป็นต้องเพิ่มโมดูลเฉพาะที่เกี่ยวข้องเข้าไป
โมดูลแต่ละตัวของ Ignition ทำหน้าที่เฉพาะด้านที่แตกต่างกัน และทั้งหมดทำงานร่วมกับแพลตฟอร์มและโมดูลอื่นของ Ignition ได้อย่างราบรื่น ทุกโมดูลของ Ignition จะได้รับการกำหนดค่า (Configure) บนแอปพลิเคชัน Designer เดียวกัน เมื่อคุณติดตั้งโมดูลลงบนเซิร์ฟเวอร์ Ignition ฟังก์ชันการทำงานของโมดูลนั้นจะอยู่บนเซิร์ฟเวอร์เครื่องนั้นๆ
เนื่องจาก Ignition รองรับการเพิ่มโมดูลได้ไม่จำกัด คุณจึงสามารถสร้างสถาปัตยกรรมระบบได้เกือบทุกรูปแบบ คุณสามารถติดตั้งใช้งาน Ignition ได้อย่างมีประสิทธิภาพ ไม่ว่าจะในไซต์เดียว หลายไซต์ หรือโฮสต์ไว้บน Cloud ซึ่งนี่เป็นเหตุผลสำคัญที่ทำให้ Ignition ได้รับการยอมรับและนำไปใช้ในองค์กรทุกขนาดจากหลากหลายอุตสาหกรรม
การจัดเก็บและแสดงผลข้อมูลของคุณ
ในบรรดาโมดูลมากมายที่ผู้ใช้สามารถเพิ่มเข้าไปในแพลตฟอร์ม Ignition ได้ มีโมดูลหลัก 2 ตัวที่มีความสำคัญเป็นพิเศษต่อความสามารถในการสร้างสถาปัตยกรรม SCADA ในรูปแบบต่างๆ นั่นคือ SQL Bridge Module และ Vision Module
SQL Bridge Module มีประโยชน์หลากหลาย โดยหน้าที่สำคัญที่สุดคือการเชื่อมต่อระหว่างข้อมูล OPC และฐานข้อมูล SQL โมดูลนี้ทำได้โดยผ่าน Historian ประสิทธิภาพสูงซึ่งทำหน้าที่บันทึกข้อมูลย้อนหลังลงในฐานข้อมูล และ Transaction Groups ที่ทำหน้าที่เคลื่อนย้ายข้อมูลแบบสองทาง (Bi-directional) ระหว่าง PLC และฐานข้อมูล
หากคุณรันเซิร์ฟเวอร์ Ignition ที่ติดตั้งเฉพาะ SQL Bridge Module เพียงอย่างเดียว คุณจะได้โซลูชัน Historian และการบันทึกข้อมูล (Data-logging) ที่ยอดเยี่ยม แต่คุณจะไม่มีวิธีในการมองเห็นหรือดูข้อมูลเหล่านั้น
Vision Module ทำหน้าที่นำการแสดงผลแบบกราฟิก (Visualization) มาสู่แพลตฟอร์ม Ignition โดยมี Web-launched Clients, แสดงข้อมูลย้อนหลัง ตลอดจนมีหน้าต่าง (Windows), ส่วนประกอบ (Components), เทมเพลต (Templates) และเครื่องมือออกแบบที่ช่วยให้คุณสร้างโปรเจกต์ได้
แม้จะใช้งานเพียงอย่างเดียว Vision Module ก็มีเครื่องมือมากมายให้ใช้งาน คุณสามารถใช้เพื่อสร้างแอปพลิเคชันส่วนหน้า (Frontend) สำหรับฐานข้อมูลที่ไม่มีการโต้ตอบกับ PLC หรือสร้างหน้าจอควบคุมสถานะแบบเรียลไทม์ที่เชื่อมต่อกับอุปกรณ์ต่างๆ นอกจากนี้ยังสามารถสร้างกราฟ แผนภูมิ และอื่นๆ ได้อีกด้วย อย่างไรก็ตาม หากแพลตฟอร์ม Ignition ของคุณมีเพียง Vision Module โดยไม่มี SQL Bridge Module คุณจะมีเพียงความสามารถในการแสดงผลข้อมูลแต่ไม่มีวิธีในการบันทึกข้อมูล
เมื่อคุณติดตั้งทั้ง SQL Bridge Module และ Vision Module ลงบนเซิร์ฟเวอร์เครื่องเดียวกัน Ignition จะทำหน้าที่ทั้งสองอย่าง ซึ่งหมายความว่าคุณสามารถบันทึกข้อมูลและแสดงผลข้อมูลทั้งหมดได้ในที่เดียว สิ่งนี้มอบตัวเลือกที่ทรงพลังมากมายในการสร้างสถาปัตยกรรมระบบที่กำหนดเองได้ตามต้องการ
เมื่อมีความเข้าใจพื้นฐานเกี่ยวกับแพลตฟอร์ม Ignition และโมดูลหลักบางตัวแล้ว เราก็สามารถพิจารณารูปแบบต่างๆ ที่นิยมใช้ในการติดตั้งใช้งาน Ignition ได้ ไม่ว่าคุณจำเป็นต้องสร้างอะไรในปัจจุบัน หรือต้องขยายระบบออกไปอย่างไรในอนาคต Ignition ขอมอบแนวทางที่นำไปใช้ได้จริงและมีความเป็นเอกภาพในการทำสิ่งเหล่านั้น
การติดตั้งใช้งาน Ignition Server เครื่องเดียว
สถาปัตยกรรมมาตรฐานของ Ignition คือการติดตั้ง Ignition Server เครื่องเดียวไว้ ณ ไซต์เดียว (Single-site) ซึ่งการปรับใช้แบบ Single-server / Single-site ที่ตัว Ignition และส่วนประกอบ (Components) ทั้งหมดถูกติดตั้งอยู่บนเครื่องเดียวนี้นั้น เป็นรูปแบบเริ่มต้นที่ผู้ใช้ Ignition ส่วนใหญ่นิยมใช้มากที่สุด
โมดูลที่มักใช้ในสถาปัตยกรรมมาตรฐาน ได้แก่ Vision, SQL Bridge, Reporting, Symbol Factory และ Alarm Notification ด้วยแพลตฟอร์มนี้ ผู้ใช้สามารถเชื่อมต่อกับ PLC และ Database ทั้งหมด ควบคุมสถานะแบบ Realtime, ทำระบบแจ้งเตือน (Alarming), ใช้กราฟิก Vector สำเร็จรูป, สร้างรายงานระดับมืออาชีพ, แสดงผลหน้าจอ HMI ที่ปรับแต่งให้เหมาะสม และอื่นๆ อีกมากมาย – ทั้งหมดนี้ทำได้บนเครื่องเดียวกัน
มันเป็นการตั้งค่าที่เรียบง่ายและลงตัวมาก: เพียงแค่จ่ายค่า License ของ Server เครื่องเดียว ผู้ใช้ก็จะมีศูนย์กลางในการติดตั้ง, กำหนดค่า (Configuration) และสำรองข้อมูล (Backup) สำหรับระบบ SCADA ทั้งหมดของทั้งโรงงาน/สถานประกอบการ หากคุณมีเพียงไซต์เดียว Server เครื่องเดียวก็สามารถให้บริการทุกฟังก์ชันที่คุณต้องการได้แล้ว
อย่างไรก็ตาม การมี Server เพียงเครื่องเดียวจะมีจุดเสี่ยงที่เรียกว่า Single Point of Failure (หากเครื่องนี้ดับ ระบบทั้งหมดจะล่ม) ทางที่ดีที่สุดคือควรตั้งค่า Server เป็นคู่แบบ Redundant เพื่อให้หาก Master Server เกิดความเสียหาย ตัว Backup Server จะเข้ามารับช่วงทำงานต่อทันที ซึ่งจะทำให้ระบบของคุณมีคุณสมบัติ Fault-tolerant (ทนทานต่อความผิดพลาด)
Ignition Server เครื่องเดียวยังสามารถนำไปใช้กับหลายไซต์ (Multiple Sites) ได้อีกด้วย ตัวอย่างเช่น หากองค์กรของคุณติดตั้ง Ignition ไว้ที่ไซต์หลัก (Central site) แล้วต้องการดูและควบคุมไซต์ทางไกล (Remote sites) อีกสองแห่งในพื้นที่อื่น คุณสามารถเชื่อมต่อทั้งสามไซต์เข้าด้วยกันผ่านเครือข่าย WAN ขององค์กรได้ ด้วย Ignition Server เพียงเครื่องเดียวที่เชื่อมต่อกับ PLC ในไซต์ทางไกลผ่าน WAN คุณจะสามารถรวบรวมข้อมูลจาก PLC ทุกเครื่องมาไว้ที่ Database เดียว ณ ไซต์หลักได้ ซึ่งน่าสนใจมากในมุมมองเรื่องต้นทุน เพราะคุณเก็บข้อมูลจากทั้งสามไซต์ได้โดยใช้ License เพียงใบเดียว
อย่างไรก็ตาม ข้อเสียของการใช้ Ignition Server เครื่องเดียวสำหรับหลายไซต์คือ หากเครือข่าย WAN ล่มจนทำให้ Server ที่ไซต์หลักหลุดการเชื่อมต่อจากไซต์ทางไกล ไซต์ทางไกลเหล่านั้นจะไม่สามารถเก็บข้อมูลย้อนหลัง (Historical Data) และไม่สามารถแสดงผลหน้าจอ (Visualization) ได้ ดังนั้น หากการเข้าถึงข้อมูลย้อนหลังและการแสดงผลหน้าจอที่ไซต์ทางไกลเป็นสิ่งที่จะต้องใช้งานได้ตลอดเวลา ขอแนะนำให้ใช้สถาปัตยกรรมที่มี Ignition Server มากกว่าหนึ่งเครื่อง
สถาปัตยกรรมมาตรฐานของ Ignition: หลายไซต์
(Multiple Sites)
เมื่อคุณขยายระบบให้ใหญ่ขึ้น คุณสามารถเลือกใช้สถาปัตยกรรมอื่นๆ ของ Ignition ที่เหมาะสมได้ หากองค์กรของคุณต้องการใช้ Ignition มากกว่าหนึ่งไซต์ ทางเลือกที่ดีที่สุดคือการติดตั้ง Ignition Server ประจำไว้ที่แต่ละไซต์ของคุณ
ข้อดีหลักของการมี Server ประจำอยู่แต่ละไซต์ คือไซต์ทางไกล (Remote sites) จะยังคงทำงานในฟังก์ชันที่จำเป็นต่อไปได้ แม้ว่าการเชื่อมต่อสื่อสารไปยัง Central Server จะหลุดไปก็ตาม นอกจากนี้ การใช้หลาย Server ยังให้ความยืดหยุ่นสูง โดยขึ้นอยู่กับ Modules ที่คุณเลือก Ignition Server แต่ละเครื่องในเครือข่ายสามารถทำหน้าที่เหมือนกันทุกประการ หรือจะแยกกันทำหน้าที่แตกต่างกันไปตามความเหมาะสมก็ได้ องค์กรของคุณสามารถเลือกได้ว่าจะรัน Module ไหนที่ไซต์ใด เพื่อให้ระบบทั้งหมดทำงานได้อย่างมีประสิทธิภาพสูงสุด
คุณสามารถปรับใช้สถาปัตยกรรม Ignition ได้หลากหลายรูปแบบที่ใช้หลาย Server ในหลายไซต์ โดยรูปแบบที่พื้นฐานที่สุดคือสถาปัตยกรรม Wide-Area SCADA หากองค์กรใช้ Wide-Area SCADA ใน 3 ไซต์ ก็จะมี Ignition Server 1 เครื่องประจำอยู่ที่แต่ละไซต์ โดย Server ทั้ง 3 เครื่องจะเชื่อมต่อกันผ่านเครือข่าย WAN ขององค์กร และติดตั้ง Module ชุดเดียวกันทั้งหมด เพื่อให้แต่ละไซต์สามารถใช้งานฟังก์ชันต่างๆ ของ Ignition ได้อย่างสมบูรณ์แบบ
ในมุมมองของผู้ปฏิบัติงาน (Operator) ตัว Ignition จะดูราบรื่นราวกับเป็นแอปพลิเคชันเดี่ยวที่ทำงานเป็นเนื้อเดียวกัน ทั้งที่ในความเป็นจริงระบบถูกกระจายตัวอยู่ตามไซต์ทั้งสาม ด้วยฟีเจอร์ที่เรียกว่า Client Retargeting ผู้ปฏิบัติงานจะสามารถสลับการทำงานจาก Project บน Ignition Server เครื่องหนึ่ง ไปยังอีก Project บน Ignition Server อีกเครื่องได้อย่างรวดเร็ว ทำให้การบริหารจัดการ Project ต่างๆ ที่กระจายอยู่ต่างพื้นที่ทำได้ง่ายขึ้นกว่าแต่ก่อนมาก
Wide-Area SCADA
การสลับจาก Project หนึ่งบน Ignition Server เครื่องหนึ่ง ไปยังอีก Project บน Ignition Server อีกเครื่อง
แต่หากในวันหนึ่งองค์กรของคุณตัดสินใจว่า ถึงเวลาที่ต้องเริ่มวิเคราะห์ข้อมูลข้ามไซต์ขึ้นมาล่ะ? นั่นแปลว่าข้อมูลจะไม่เพียงแค่ต้องถูกบันทึก (Log) ไว้ที่ฝั่ง Local เท่านั้น แต่ยังต้องถูก Log มาไว้ที่ศูนย์กลาง (Central) อีกด้วย
ในกรณีนี้ ขอแนะนำให้ใช้รูปแบบดัดแปลงของสถาปัตยกรรม Wide-Area SCADA ที่มีการเพิ่ม Central Database เข้ามา เพื่อให้ Ignition Server ทั้งสามเครื่องสามารถ Log ข้อมูลมาไว้ที่ศูนย์กลางได้
การบันทึกข้อมูลไปยังทั้ง Central Database และ Local Database พร้อมๆ กัน สามารถทำได้โดยการเพิ่ม Tag History Splitter Module ซึ่งการตั้งค่าในลักษณะนี้จะช่วยให้คุณดึง Insight จากข้อมูลได้ลึกซึ้งยิ่งขึ้น ไม่ว่าจะเป็นการเปรียบเทียบข้อมูลระหว่างไซต์ต่างๆ บน Trend เดียวกัน หรือการรวมข้อมูลจากทุก Database เข้าด้วยกันเพื่อสร้างเป็น Report ฉบับเดียว
Wide Area SCADA-Central Database
Central Database สามารถตั้งอยู่ที่ไซต์ใดก็ได้
Hub-and-Spoke: การเชื่อมต่อ Remote Sites จำนวนมากเข้ากับ Central Site
องค์กรที่มี Remote Sites จำนวนมาก เช่น บริษัทน้ำมันและก๊าซที่มีแท่นขุดเจาะ (Rigs) นับร้อยแห่งในภาคสนาม จำเป็นต้องมีวิธีที่น่าเชื่อถือและประหยัดในการบันทึกข้อมูล (Log ข้อมูล) จากทางไกล สถาปัตยกรรมแบบ Hub-and-Spoke เป็นรูปแบบสถาปัตยกรรมที่ใช้หลาย Server ซึ่งเหมาะอย่างยิ่งสำหรับองค์กรที่มี Remote Sites หลักร้อยหรือหลักพันแห่ง เพราะช่วยให้สามารถรวบรวมข้อมูลย้อนหลัง (Historical Data) จากไซต์ทางไกลหลายๆ แห่งมาไว้ที่ศูนย์กลางได้ ในขณะที่ยังคงควบคุมต้นทุนให้ต่ำลงได้โดยใช้จำนวน Modules ให้น้อยที่สุดในแต่ละไซต์
Hub ในสถาปัตยกรรมแบบ Hub-and-Spoke คือไซต์หลัก (Central site) ที่มี Ignition Server ซึ่งติดตั้ง Vision Module และ Reporting Module
Spokes คือไซต์ทางไกล (Remote sites) โดยแต่ละแห่งจะมีคอมพิวเตอร์สำหรับ Log ข้อมูลที่ติดตั้ง Ignition ไว้ และมีเพียง SQL Bridge Module และ OPC-UA Module เท่านั้น
ด้วยวิธีนี้ ไซต์ทางไกลจะเชื่อมต่อกับ PLC ในระดับ Local ทำให้ข้อมูลไม่สูญหายเมื่อการเชื่อมต่อกับ Central Hub หลุดไป นอกจากนี้ ฟีเจอร์ Store-and-forward ของ Ignition บนคอมพิวเตอร์บันทึกข้อมูลแบบ Embedded จะช่วยให้มั่นใจว่าข้อมูลจะถูกบันทึกไว้ที่ไซต์ทางไกลเสมอเมื่อการเชื่อมต่อล่ม และจะส่งต่อ (Forward) ข้อมูลเหล่านั้นกลับไปยัง Central Hub ทันทีเมื่อการเชื่อมต่อกลับคืนมา
การ Log ข้อมูลทั้งแบบ Local และ Remote ในสถาปัตยกรรม Hub-and-Spoke สามารถทำได้โดยการติดตั้ง Local Database และ Tag History Splitter Module ไว้ที่แต่ละไซต์
Hub & Spoke: Reliable Local & Remote Data Logging
องค์กรที่มี Remote Sites จำนวนมาก เช่น บริษัทน้ำมันและก๊าซที่มีแท่นขุดเจาะ (Rigs) นับร้อยแห่งในภาคสนาม จำเป็นต้องมีวิธีที่น่าเชื่อถือและประหยัดในการบันทึกข้อมูล (Log ข้อมูล) จากทางไกล สถาปัตยกรรมแบบ Hub-and-Spoke เป็นรูปแบบสถาปัตยกรรมที่ใช้หลาย Server ซึ่งเหมาะอย่างยิ่งสำหรับองค์กรที่มี Remote Sites หลักร้อยหรือหลักพันแห่ง เพราะช่วยให้สามารถรวบรวมข้อมูลย้อนหลัง (Historical Data) จากไซต์ทางไกลหลายๆ แห่งมาไว้ที่ศูนย์กลางได้ ในขณะที่ยังคงควบคุมต้นทุนให้ต่ำลงได้โดยใช้จำนวน Modules ให้น้อยที่สุดในแต่ละไซต์
Hub ในสถาปัตยกรรมแบบ Hub-and-Spoke คือไซต์หลัก (Central site) ที่มี Ignition Server ซึ่งติดตั้ง Vision Module และ Reporting Module
Spokes คือไซต์ทางไกล (Remote sites) โดยแต่ละแห่งจะมีคอมพิวเตอร์สำหรับ Log ข้อมูลที่ติดตั้ง Ignition ไว้ และมีเพียง SQL Bridge Module และ OPC-UA Module เท่านั้น
ด้วยวิธีนี้ ไซต์ทางไกลจะเชื่อมต่อกับ PLC ในระดับ Local ทำให้ข้อมูลไม่สูญหายเมื่อการเชื่อมต่อกับ Central Hub หลุดไป นอกจากนี้ ฟีเจอร์ Store-and-forward ของ Ignition บนคอมพิวเตอร์บันทึกข้อมูลแบบ Embedded จะช่วยให้มั่นใจว่าข้อมูลจะถูกบันทึกไว้ที่ไซต์ทางไกลเสมอเมื่อการเชื่อมต่อล่ม และจะส่งต่อ (Forward) ข้อมูลเหล่านั้นกลับไปยัง Central Hub ทันทีเมื่อการเชื่อมต่อกลับคืนมา
การ Log ข้อมูลทั้งแบบ Local และ Remote ในสถาปัตยกรรม Hub-and-Spoke สามารถทำได้โดยการติดตั้ง Local Database และ Tag History Splitter Module ไว้ที่แต่ละไซต์
Hub & Spoke with Vision & Alarming
Hosted Ignition Server
Cloud Hosting
Ignition สามารถใช้งานในสภาพแวดล้อมแบบ Hosted ผ่านระบบ Cloud ได้ด้วยเช่นกัน แนวทางแบบ Software-as-a-Service (SaaS) นี้กำลังได้รับความนิยมมากขึ้นเรื่อยๆ ในหมู่ End Users และ System Integrators เนื่องจากระบบบน Cloud มีประโยชน์ที่น่าสนใจหลายประการ เช่น การขยายขนาด (Scalability) ที่ทำได้ง่าย, การเข้าถึงข้อมูลผ่าน Internet ได้สะดวก และช่วยลดต้นทุนด้าน IT ลงได้
สถาปัตยกรรม Ignition บน Cloud ทำงานอย่างไร? โดยทั่วไป Integrator จะทำหน้าที่โฮสต์ตัว Ignition ไว้บน Server ของตัวเอง หรือใช้บริการ Cloud Computing (เช่น Amazon Web Services, Microsoft Azure หรือ Rackspace) เพื่อให้บริการ Runtime Clients แก่ลูกค้า โดย Integrator จะตั้งค่า Ignition Server แบบ Redundant 2 เครื่องบน Cloud พร้อมกับติดตั้ง Firewall และกำหนด Public IP Address ข้อมูลของลูกค้าจะถูกรวบรวมไว้บน Cloud จากนั้นลูกค้าก็สามารถเปิด Runtime Client และ Log in เข้ามาเพื่อดูหน้าจอ, รายงาน (Reports), แนวโน้มข้อมูล (Trends) รวมถึงฟีเจอร์อื่นๆ ที่ให้บริการอยู่บน Ignition Cloud Server จากที่ใดก็ได้
การที่จะโฮสต์ข้อมูลของลูกค้าได้นั้น Integrator จะต้องรวบรวมข้อมูลมาจาก PLC ของลูกค้าก่อน วิธีการที่ชาญฉลาดคือการติดตั้ง Ignition พร้อมกับ SQL Bridge Module ไว้ที่ไซต์ของลูกค้าแต่ละแห่ง เพื่อให้ข้อมูลถูก Log มายัง Database ในส่วนกลางที่โฮสต์โดย Integrator ส่วนอีกวิธีในการรวบรวมข้อมูลคือการเชื่อมต่อ Cloud Server ตรงไปยัง PLC ผ่านเสาสัญญาณโทรศัพท์ (Cell tower), ดาวเทียม, VPN ที่มีความปลอดภัย หรือใช้การดึงข้อมูลแบบ Polling หรือ Round-robin-type polling อย่างไรก็ตาม วิธีนี้อาจสร้างความกังวลด้านความปลอดภัย (Security) ให้กับลูกค้าบางรายได้
แม้ว่า Cloud Computing จะสามารถใช้งานร่วมกับ Ignition ได้ แต่ผู้ที่ปรับใช้สถาปัตยกรรมนี้ควรระมัดระวังเกี่ยวกับข้อมูลหรือระบบที่จะนำขึ้นไปไว้บน Cloud ทางที่ดีที่สุดคือไม่ควรสั่งการควบคุม (Control) บน Cloud เพื่อป้องกันไม่ให้เกิดความเสี่ยงที่อาจมีใครบางคนเข้ามากดเปิดหรือปิดส่วนต่างๆ ของระบบคุณผ่าน Internet
การสร้างสถาปัตยกรรมแบบใดก็ได้ที่คุณต้องการ
ไม่ว่าจะใช้สถาปัตยกรรมรูปแบบใดก็ตาม — ไม่ว่าจะเป็น Cloud-based, Hub-and-Spoke หรือ Wide-Area SCADA — Modules ที่ติดตั้งบน Ignition Server ควรได้รับการเลือกสรรตามความต้องการของลูกค้าเป็นหลัก ทั้ง End Users และ Integrators ควรพิจารณาอย่างรอบคอบว่าไซต์นั้นๆ จำเป็นต้องแสดงค่าแบบ Real-time หรือไม่, จุดใดที่ต้อง Log ข้อมูลย้อนหลัง (Historical Data), จุดใดที่ต้องการความต่อเนื่องของระบบอย่างวิกฤต (Redundancy) และอื่นๆ
ทุกองค์กรมีความต้องการเฉพาะตัวที่แตกต่างกัน ซึ่ง Ignition เปิดโอกาสให้คุณสามารถสร้างสถาปัตยกรรมรูปแบบใดก็ได้ ตั้งแต่ระบบ Data Logger แบบง่ายๆ ไปจนถึงเครือข่าย SCADA ที่ครอบคลุมไซต์นับพันแห่งซึ่งกระจายอยู่ต่างพื้นที่กัน และรูปแบบอื่นๆ ทั้งหมดในระหว่างนั้น ด้วยการดึงศักยภาพของแพลตฟอร์ม Ignition ที่เป็นแบบ Modular มาใช้ ทุกองค์กรจะสามารถค้นพบจุดที่ลงตัวที่สุด (Sweet Spot) ระหว่างการขยายขนาดได้ง่าย (Scalability), ความคุ้มค่าด้านราคา (Affordability), ฟังก์ชันการใช้งานที่ครบครัน (Functionality) และความปลอดภัยของระบบ (Security)