การปรับปรุง HMI ของ Bailey INFI 90 Symphony ที่ทำงานบน OpenVMS Alphaให้ทันสมัย

การปรับปรุง HMI ให้ทันสมัยโดยไม่ต้องเปลี่ยนระบบ INFI 90 ทั้งหมด

ระบบ Bailey INFI 90 จำนวนมากยังคงทำงานได้อย่างน่าเชื่อถือเป็นเวลาหลายทศวรรษหลังจากติดตั้งครั้งแรก คอนโทรลเลอร์ โมดูลสื่อสาร ยูนิตเทอร์มิเนชัน และ I/O ภาคสนามของระบบอาจยังทำหน้าที่ควบคุมที่จำเป็นได้

ปัญหาด้านวงจรชีวิตที่เร่งด่วนที่สุดมักอยู่เหนือชั้นคอนโทรลเลอร์

สถานีผู้ปฏิบัติงานอาจพึ่งพาฮาร์ดแวร์ AlphaStation ที่เก่า อะแดปเตอร์กราฟิกที่ไม่รองรับแล้ว อุปกรณ์จัดเก็บข้อมูลรุ่นเก่า และสภาพแวดล้อมซอฟต์แวร์ OpenVMS Alpha รุ่นเก่า อะไหล่ทดแทนเริ่มจัดหาได้ยากขึ้น ขณะที่วิศวกร OpenVMS และ Bailey Symphony ที่มีประสบการณ์ก็มีจำนวนลดลง

ตัวอย่างที่พิจารณาในที่นี้ประกอบด้วยเวิร์กสเตชัน AlphaStation 255 จำนวนสี่เครื่อง แต่ละสถานีใช้งาน OpenVMS Alpha และรองรับฟังก์ชันอินเทอร์เฟซผู้ปฏิบัติงานของ Bailey Symphony สำหรับระบบควบคุมแบบกระจาย Bailey INFI 90

เป้าหมายไม่จำเป็นต้องเป็นการเปลี่ยน DCS ทั้งระบบ เป้าหมายที่ใช้งานได้จริงกว่าคือการลดการพึ่งพาฮาร์ดแวร์ AlphaStation ที่เก่าและล้าสมัย ขณะเดียวกันยังคงรักษาคอนโทรลเลอร์ที่มีเสถียรภาพ สายไฟภาคสนาม โมดูล I/O ลอจิกควบคุม และการปฏิบัติการของกระบวนการไว้

ความแตกต่างนี้เปลี่ยนแปลงกลยุทธ์การปรับปรุงให้ทันสมัย

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

มีแนวทางการปรับปรุงให้ทันสมัยที่เป็นไปได้หลายแนวทาง อย่างไรก็ตาม แต่ละแนวทางรักษาส่วนต่าง ๆ ของระบบเดิมไว้แตกต่างกัน

อีมูเลเตอร์ Alpha สามารถรักษาสภาพแวดล้อมซอฟต์แวร์ไว้ได้เกือบทั้งหมด การย้ายไปยัง OpenVMS x86 ยังคงรักษาตระกูลระบบปฏิบัติการเดิมไว้ แต่ต้องย้ายแอปพลิเคชัน การเปลี่ยน HMI ที่ใช้ OPC จะรักษาชั้นคอนโทรลเลอร์ไว้ พร้อมสร้างอินเทอร์เฟซผู้ปฏิบัติงานขึ้นใหม่ ส่วนกลยุทธ์การพัฒนาต่อยอดของ ABB สามารถปรับปรุงสถาปัตยกรรม Symphony ในภาพรวมเป็นระยะ ๆ ได้

ไม่ควรอธิบายแนวทางใดว่าเป็นเพียงการเปลี่ยนคอมพิวเตอร์เป็นพีซีแบบง่าย ๆ

รูปที่ 1. แนวทางการปรับปรุงให้ทันสมัยหลักสามแนวทางสามารถรักษาส่วนต่าง ๆ ของการลงทุนที่ติดตั้งไว้ใน Bailey INFI 90 และ Symphony ได้แตกต่างกัน

เหตุใดการโคลนดิสก์ AlphaStation จึงยังไม่เพียงพอ

การโคลนดิสก์มีประโยชน์สำหรับเก็บรักษาสภาพแวดล้อม OpenVMS Alpha ที่ติดตั้งไว้ โดยสามารถเก็บระบบปฏิบัติการ ไฟล์แอปพลิเคชัน การกำหนดค่าอุปกรณ์ บัญชีผู้ใช้ ซอฟต์แวร์ Bailey ฐานข้อมูล กราฟิก และการตั้งค่าเฉพาะของแต่ละไซต์ไว้ได้

อย่างไรก็ตาม การโคลนดิสก์ไม่ได้แปลงซอฟต์แวร์ Alpha ให้เป็นซอฟต์แวร์ x86

ระบบปฏิบัติการที่โคลนยังคงมีคำสั่งของโปรเซสเซอร์ Alpha อยู่ เคอร์เนล ตัวโหลดระบบ ไลบรารีระบบ แอปพลิเคชัน และไดรเวอร์ฮาร์ดแวร์สร้างขึ้นสำหรับสถาปัตยกรรม Alpha

พีซีสมัยใหม่ทั่วไปใช้โปรเซสเซอร์ x86-64 และยังมีคอนโทรลเลอร์สตอเรจ อุปกรณ์เครือข่าย โครงสร้างอินเทอร์รัปต์ ฮาร์ดแวร์กราฟิก อินเทอร์เฟซเฟิร์มแวร์ และบัสอุปกรณ์ต่อพ่วงที่แตกต่างกัน

VMware, VirtualBox, Hyper-V และไฮเปอร์ไวเซอร์ x86 ทั่วไปจะจำลองฮาร์ดแวร์ที่เข้ากันได้กับ x86 โดยปกติจะไม่แปลคำสั่งของโปรเซสเซอร์ Alpha เป็นคำสั่ง x86

ดังนั้น การนำอิมเมจดิสก์ OpenVMS Alpha ไปไว้ในเครื่องเสมือน x86 ทั่วไป จึงไม่ได้ทำให้อิมเมจนั้นบูตได้

เครื่องเสมือนอาจจัดเตรียมดิสก์เสมือน อะแดปเตอร์เครือข่ายเสมือน และอุปกรณ์กราฟิกเสมือน แต่ OpenVMS Alpha ยังคงต้องการโปรเซสเซอร์ Alpha และอุปกรณ์ยุค Alpha ที่รองรับ

ด้วยเหตุนี้ แนวคิดสองประการจึงต้องแยกจากกัน:

เวอร์ชวลไลเซชันโดยทั่วไปจะแสดงฮาร์ดแวร์เสมือนโดยใช้สถาปัตยกรรมโปรเซสเซอร์เดียวกับโฮสต์

การจำลองข้ามสถาปัตยกรรมจำลองโปรเซสเซอร์และสภาพแวดล้อมฮาร์ดแวร์อื่นด้วยซอฟต์แวร์

OpenVMS Alpha จำเป็นต้องใช้แนวทางที่สอง เมื่อไบนารี Alpha เดิมและระบบปฏิบัติการต้องคงเดิมโดยไม่มีการเปลี่ยนแปลง

ดังนั้น การโคลนดิสก์จึงใช้งานได้ในสามสถานการณ์ที่จำกัด

แนวทางแรกคือการกู้คืนไปยัง AlphaStation รุ่นเดียวกัน โดยใช้สตอเรจและอุปกรณ์ต่อพ่วงที่เข้ากันได้

แนวทางที่สองคือการกู้คืนไปยังระบบ Alpha อื่นที่รองรับ หลังจากดำเนินการเปลี่ยนอุปกรณ์และการกำหนดค่าที่จำเป็นแล้ว

แนวทางที่สามคือการกู้คืนเข้าสู่อีมูเลเตอร์ Alpha ที่จำลองสภาพแวดล้อมที่เข้ากันได้กับ AlphaServer หรือ AlphaStation

การโคลนเพียงอย่างเดียวไม่สามารถแก้ปัญหาด้านสถาปัตยกรรมได้ สภาพแวดล้อมเป้าหมายยังคงต้องเข้าใจและประมวลผลคำสั่งเครื่องของ Alpha ได้

การจำลอง Alpha ช่วยรักษามูลค่าการลงทุนเดิมไว้ได้มากที่สุด

โดยทั่วไป การจำลอง Alpha เป็นแนวทางที่ก่อให้เกิดการเปลี่ยนแปลงน้อยที่สุด เมื่อซอฟต์แวร์ Symphony เดิมต้องยังทำงานได้โดยไม่แก้ไขซอร์สโค้ด

อีมูเลเตอร์ Alpha ทำงานบนฮาร์ดแวร์ x86 รุ่นใหม่ แต่จะแสดงระบบ Alpha เสมือนให้ OpenVMS มองเห็น ระบบปฏิบัติการและแอปพลิเคชันเดิมจึงยังคงเห็นสภาพแวดล้อมฮาร์ดแวร์ที่เข้ากันได้กับ Alpha

ผลิตภัณฑ์อย่าง CHARON-AXP ได้รับการออกแบบมาเพื่อจุดประสงค์นี้ อีมูเลเตอร์จะแทนที่โปรเซสเซอร์ Alpha จริง สถาปัตยกรรมหน่วยความจำ คอนโทรลเลอร์สตอเรจ อะแดปเตอร์อีเทอร์เน็ต และอุปกรณ์อื่น ๆ ที่รองรับ ด้วยองค์ประกอบเทียบเท่าที่กำหนดด้วยซอฟต์แวร์

เซิร์ฟเวอร์ x86 ใช้ Windows หรือ Linux เป็นสภาพแวดล้อมโฮสต์ อีมูเลเตอร์ Alpha ทำงานอยู่เหนือโฮสต์ดังกล่าว จากนั้น OpenVMS Alpha จะทำงานอยู่ภายในระบบ Alpha ที่จำลองขึ้น

แนวทางนี้แตกต่างจากการพอร์ต OpenVMS ไปยัง x86

การติดตั้ง OpenVMS Alpha เดิมยังคงเป็นการติดตั้งบน Alpha ไบนารีของ Bailey Symphony ยังคงเป็นไบนารีสำหรับ Alpha อีมูเลเตอร์จะแปลหรือจำลองการทำงานของฮาร์ดแวร์ Alpha ที่จำเป็น

สิ่งนี้สามารถรักษาไว้ได้:

• ระบบปฏิบัติการ OpenVMS Alpha ที่ติดตั้งไว้

• แอปพลิเคชัน Bailey Symphony ที่มีอยู่

• กราฟิกของผู้ปฏิบัติงานและฐานข้อมูลการแสดงผล

• การกำหนดค่าการแจ้งเตือนและไฟล์ประวัติ

• บัญชีผู้ใช้และโพรซีเยอร์คำสั่ง

• ยูทิลิตีเฉพาะของไซต์ที่มีอยู่เดิม

• อินเทอร์เฟซของแอปพลิเคชันที่พึ่งพาสภาพแวดล้อม Alpha

• ขั้นตอนการทำงานของผู้ปฏิบัติงานซึ่งมิฉะนั้นจะต้องมีการฝึกอบรมใหม่

โดยทั่วไป การย้ายระบบในทางปฏิบัติมักเริ่มจากการสร้างอิมเมจหรือข้อมูลสำรองของดิสก์ Alpha เดิมที่ผ่านการตรวจสอบแล้ว จากนั้นกู้คืนข้อมูลดังกล่าวลงในคอนเทนเนอร์ดิสก์เสมือนที่อีมูเลเตอร์ใช้งาน

การกำหนดค่าอีมูเลเตอร์ต้องจำลองคุณลักษณะที่เหมาะสมของ CPU หน่วยความจำ ดิสก์ เครือข่าย และอุปกรณ์ต่อพ่วง ทีมงานอาจต้องแมปพอร์ตอนุกรมจริงหรืออินเทอร์เฟซเครือข่ายผ่านระบบโฮสต์ด้วย

การจำลอง Alpha สามารถลดการพึ่งพาฮาร์ดแวร์จริงที่ล้าสมัยได้อย่างมาก และยังช่วยให้การสำรองข้อมูลง่ายขึ้น เนื่องจากสามารถคัดลอกไฟล์ดิสก์เสมือนได้โดยใช้โครงสร้างพื้นฐานด้านการจัดเก็บข้อมูลสมัยใหม่

อย่างไรก็ตาม ควรใช้คำว่า “ไม่ต้องเปลี่ยนแปลงเลย” ด้วยความระมัดระวัง

โค้ดแอปพลิเคชันอาจไม่ต้องเปลี่ยนแปลง แต่สภาพแวดล้อมยังคงต้องผ่านงานวิศวกรรม ต้องตรวจสอบการแมปอุปกรณ์ ต้องกำหนดค่าอินเทอร์เฟซเครือข่าย และต้องทบทวนลิขสิทธิ์ OpenVMS รวมถึงลิขสิทธิ์แอปพลิเคชัน

นอกจากนี้ต้องทดสอบอีมูเลเตอร์กับอินเทอร์เฟซการสื่อสาร Bailey ที่ใช้งานอยู่ในไซต์ด้วย

แอปพลิเคชัน OpenVMS ทั่วไปอาจทำงานได้อย่างถูกต้อง ขณะที่อินเทอร์เฟซ DCS เฉพาะทางล้มเหลว เนื่องจากพึ่งพาอะแดปเตอร์เครือข่าย อินเทอร์เฟซบัส อุปกรณ์อนุกรม หรือพฤติกรรมด้านเวลาบางอย่างโดยเฉพาะ

ดังนั้นต้องจัดทำบัญชีการกำหนดค่า AlphaStation 255 ที่แน่นอนก่อนเลือกโปรไฟล์อีมูเลเตอร์

อินเทอร์เฟซการสื่อสาร Bailey คือการทดสอบการจำลองที่สำคัญ

คำถามที่สำคัญที่สุดเกี่ยวกับการจำลองไม่ใช่ว่า OpenVMS ไปถึงพรอมต์เข้าสู่ระบบได้หรือไม่

คำถามสำคัญคือ สถานีที่จำลองเสมือนสามารถสื่อสารกับระบบ Bailey INFI 90 ได้อย่างถูกต้องภายใต้สภาวะการทำงานเต็มรูปแบบหรือไม่

อินเทอร์เฟซดังกล่าวอาจพึ่งพา Ethernet การสื่อสารแบบอนุกรม อินเทอร์เฟซเครือข่าย Bailey หรือฮาร์ดแวร์สื่อสารเฉพาะทาง การกำหนดค่าของแต่ละไซต์อาจแตกต่างกันอย่างมาก

ก่อนตัดสินใจใช้การจำลอง Alpha วิศวกรควรจัดทำเอกสารเกี่ยวกับ:

• อินเทอร์เฟซเครือข่ายจริงที่ติดตั้งใน AlphaStation แต่ละเครื่อง

• โพรโทคอลการสื่อสารที่ใช้ระหว่าง Symphony และ INFI 90

• ชื่ออุปกรณ์ที่กำหนดไว้ภายใน OpenVMS

• ที่อยู่เครือข่ายและคำจำกัดความของโหนด

• บริการ DECnet, TCP/IP, LAT หรือบริการกรรมสิทธิ์ที่จำเป็น

• การตั้งค่าพอร์ตอนุกรม หากเกี่ยวข้อง

• คีย์ลิขสิทธิ์ภายนอกหรือดองเกิลฮาร์ดแวร์ใด ๆ

• พฤติกรรมด้านความซ้ำซ้อนและการสลับไปใช้ระบบสำรองระหว่างสถานีผู้ปฏิบัติงาน

• ข้อกำหนดด้านการซิงโครไนซ์เวลา

• ฟังก์ชันกราฟิกและแป้นพิมพ์ที่ผู้ปฏิบัติงานใช้งาน

ผู้จัดหาอีมูเลเตอร์อาจรองรับอุปกรณ์ Alpha Ethernet และอุปกรณ์จัดเก็บข้อมูลทั่วไป แต่ไม่ได้ยืนยันโดยอัตโนมัติว่าจะรองรับอินเทอร์เฟซ Bailey แบบกรรมสิทธิ์ทุกประเภท

หาก HMI เดิมพึ่งพาอะแดปเตอร์ฮาร์ดแวร์เฉพาะทางที่ไม่สามารถจำลองเสมือนได้ การใช้เส้นทางอีมูเลเตอร์อาจต้องมีเกตเวย์สื่อสารทางเลือก

ดังนั้นโครงการควรรวมการทดสอบบนโต๊ะโดยใช้สถานีที่โคลนไว้และมีสิทธิ์เข้าถึงเครือข่าย Bailey ที่เป็นตัวแทนของระบบจริง

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

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

OpenVMS x86-64 เป็นเส้นทางการย้ายระบบที่แตกต่างออกไป

OpenVMS รุ่นใหม่พร้อมใช้งานสำหรับสถาปัตยกรรม x86-64 และสามารถทำงานในสภาพแวดล้อมเวอร์ชวลไลซ์ที่ได้รับการรองรับบนเซิร์ฟเวอร์สมัยใหม่

สิ่งนี้ทำให้เกิดทางเลือกเพิ่มเติมในการย้ายระบบ ซึ่งไม่เคยมีให้ใช้ในช่วงการหารือเรื่องการปรับปรุงระบบ INFI 90 ในยุคก่อนหน้านี้

อย่างไรก็ตาม OpenVMS x86-64 ไม่สามารถเรียกใช้ไบนารี OpenVMS Alpha ได้โดยตรงเสมือนเป็นแอปพลิเคชัน x86 แบบเนทีฟ

ต้องย้ายสภาพแวดล้อมของแอปพลิเคชัน

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

คำถามสำคัญคือ ซอฟต์แวร์ Bailey Symphony ที่ติดตั้งอยู่นั้นมี OpenVMS รุ่นที่เข้ากันได้กับ x86 หรือไม่

หากผู้จำหน่ายซอฟต์แวร์ไม่เคยเปิดตัวแอปพลิเคชันดังกล่าวสำหรับ OpenVMS x86-64 การย้ายเฉพาะระบบปฏิบัติการจะไม่ช่วยรักษา HMI ไว้

โปรแกรมที่พัฒนาภายในไซต์อาจย้ายระบบได้ หากยังมีซอร์สโค้ดและสภาพแวดล้อมการสร้างอยู่ แอปพลิเคชันเชิงพาณิชย์แบบปิดโดยทั่วไปไม่สามารถสร้างใหม่ได้หากไม่ได้รับการสนับสนุนจากผู้จำหน่าย

เส้นทางนี้อาจยังใช้ได้จริงสำหรับเซิร์ฟเวอร์ข้อมูลแบบกำหนดเอง ระบบบันทึกข้อมูล เครื่องมือ ยูทิลิตี รายงาน และแอปพลิเคชันผสานรวมที่ทำงานอยู่ข้าง HMI ของ Symphony

มีโอกาสน้อยกว่าที่จะรักษาสภาพแวดล้อมผู้ปฏิบัติงาน Symphony แบบเก่าที่เป็นกรรมสิทธิ์ไว้ได้ หากไม่มีรุ่นแอปพลิเคชันที่ได้รับการรองรับ

การประเมินการย้าย OpenVMS x86 ควรระบุสิ่งต่อไปนี้:

• ไฟล์ปฏิบัติการและผลิตภัณฑ์เสริมทุกตัวที่ติดตั้งอยู่

• ซอร์สโค้ดและขั้นตอนการสร้างที่มีอยู่

• การพึ่งพาคอมไพเลอร์และรันไทม์

• ผลิตภัณฑ์ฐานข้อมูลและรูปแบบไฟล์

• ไลบรารีการสื่อสารที่เป็นกรรมสิทธิ์

• การพึ่งพากราฟิกหรือระบบหน้าต่าง

• ความพร้อมใช้งานของใบอนุญาตสำหรับ x86-64

• การเปลี่ยนแปลงที่จำเป็นเนื่องจากความแตกต่างของสถาปัตยกรรม

• สมมติฐานด้านประสิทธิภาพและการจับเวลา

เส้นทางนี้มีศักยภาพในระยะยาวมากกว่าการย้ายจาก Alpha ไปยังสถาปัตยกรรมฮาร์ดแวร์อื่นที่ยุติการพัฒนาแล้ว และสามารถนำเวิร์กโหลด OpenVMS ที่เข้ากันได้ไปใช้งานบนโครงสร้างพื้นฐานเวอร์ชวลไลเซชัน x86 ที่ยังได้รับการรองรับ

อย่างไรก็ตาม ควรอธิบายว่านี่เป็นโครงการย้ายแอปพลิเคชัน ไม่ใช่โครงการโคลนดิสก์

เหตุใดการย้ายระบบจาก Itanium จึงมักเป็นทางเลือกชั่วคราว

OpenVMS ยังได้รับการเปิดตัวสำหรับเซิร์ฟเวอร์ HPE Integrity ที่ใช้สถาปัตยกรรม Itanium

มีเครื่องมือการย้ายระบบและวิธีการทางวิศวกรรมสำหรับย้ายแอปพลิเคชัน Alpha บางส่วนไปยัง OpenVMS Integrity ซึ่งในอดีตเป็นเส้นทางที่ได้รับการรองรับสำหรับการย้ายออกจากฮาร์ดแวร์ Alpha ที่เริ่มล้าสมัย

อย่างไรก็ตาม ปัจจุบันฮาร์ดแวร์ Itanium เองก็เป็นแพลตฟอร์มรุ่นเก่า

การย้ายจาก Alpha ไปยัง Integrity อาจขจัดการพึ่งพาฮาร์ดแวร์ล้าสมัยรายการหนึ่ง แต่ก็สร้างการพึ่งพาอีกรายการหนึ่งขึ้นมา เซิร์ฟเวอร์ ชิ้นส่วน อินเทอร์เฟซระบบจัดเก็บข้อมูล และความเชี่ยวชาญเฉพาะทางที่เหมาะสมจะมีให้ใช้งานน้อยลงอย่างต่อเนื่อง

Itanium ยังคงมีความเกี่ยวข้องได้เมื่อหน้างานมีโครงสร้างพื้นฐาน Integrity ที่ได้รับการสนับสนุนอยู่แล้ว และอาจมีความเกี่ยวข้องเมื่อมีผลิตภัณฑ์แบบเลเยอร์ที่จำเป็นสำหรับ Integrity แต่ไม่มีสำหรับ x86-64

สำหรับโครงการปรับปรุงระบบใหม่ โดยทั่วไปควรประเมินแนวทางนี้ในฐานะเส้นทางความเข้ากันได้ระดับกลาง

กรณีศึกษาทางธุรกิจต้องอธิบายว่าเหตุใดการย้ายไปใช้ Integrity จึงเหมาะสมกว่าการจำลอง Alpha การย้าย OpenVMS ไปยัง x86 หรือการปรับแพลตฟอร์ม HMI ใหม่

การปรับแพลตฟอร์มด้วย OPC ช่วยคงชั้นควบคุมไว้

การปรับแพลตฟอร์มด้วย OPC จะแทนที่ชั้นอินเทอร์เฟซผู้ปฏิบัติงาน โดยคงคอนโทรลเลอร์ INFI 90 และ I/O ภาคสนามเดิมไว้

เซิร์ฟเวอร์การสื่อสารจะเชื่อมต่อกับระบบ Bailey และเผยแพร่แท็กกระบวนการไปยังแพลตฟอร์ม HMI หรือ SCADA รุ่นใหม่

HMI ใหม่จะจัดการจอแสดงผล สัญญาณเตือน แนวโน้ม ความปลอดภัย คำสั่งของผู้ปฏิบัติงาน รายงาน และบริการเวิร์กสเตชัน

แนวทางนี้ยกเลิกการพึ่งพาแอปพลิเคชันผู้ปฏิบัติงาน Symphony เดิม และยังหลีกเลี่ยงความจำเป็นในการใช้งาน OpenVMS Alpha บนสถานีผู้ปฏิบัติงานใหม่

โดยทั่วไปสถาปัตยกรรมจะประกอบด้วย:

• คอนโทรลเลอร์และ I/O ของ Bailey INFI 90 ที่มีอยู่เดิม

• อินเทอร์เฟซการสื่อสารของ Bailey ที่เข้ากันได้

• เซิร์ฟเวอร์ข้อมูล OPC DA, OPC UA หรือเซิร์ฟเวอร์เฉพาะของผู้จำหน่าย

• แพลตฟอร์ม HMI หรือ SCADA รุ่นใหม่

• เวิร์กสเตชันสำหรับผู้ปฏิบัติงานและวิศวกร

• บริการฮิสทอเรียนนเสริม การจัดทำรายงาน และการวิเคราะห์สัญญาณเตือน

ตัวอย่างหน้างานที่อ้างถึงในเอกสารต้นฉบับใช้เซิร์ฟเวอร์ OPC ของ RoviSys ร่วมกับ GE CIMPLICITY ระบบที่รายงานว่าสามารถทำงานได้สำเร็จ แต่โครงการจำเป็นต้องสร้างจอแสดงผลสำหรับผู้ปฏิบัติงานและลอจิกแอนิเมชันขึ้นใหม่

ไม่ควรตีความตัวอย่างนี้ว่าเป็นคำแนะนำผลิตภัณฑ์โดยอัตโนมัติสำหรับการติดตั้ง INFI 90 ทุกกรณี

เซิร์ฟเวอร์ที่เลือกต้องรองรับเครือข่าย Bailey โมดูลการสื่อสาร รุ่นของคอนโทรลเลอร์ จำนวนแท็ก อัตราการอัปเดต ข้อกำหนดด้านระบบสำรอง และฟังก์ชันคำสั่งเฉพาะที่หน้างาน

เช่นเดียวกันกับแพลตฟอร์ม HMI

GE CIMPLICITY เป็นหนึ่งในแพลตฟอร์ม HMI/SCADA ระดับองค์กรที่เป็นไปได้ ระบบอื่นก็อาจใช้งานได้เช่นกัน หากรองรับการเชื่อมต่อ OPC กราฟิก สัญญาณเตือน สคริปต์ ระบบสำรอง ความปลอดภัย และการสนับสนุนตลอดวงจรการใช้งานตามที่ต้องการ

รูปที่ 2 การย้ายระบบโดยใช้ OPC จะคงชั้นควบคุม INFI 90 ไว้ พร้อมแทนที่สภาพแวดล้อมผู้ปฏิบัติงาน Symphony รุ่นเก่า

การเชื่อมต่อ OPC ไม่ได้แปลงหน้าจอที่มีอยู่

เซิร์ฟเวอร์ OPC ช่วยให้เชื่อมต่อข้อมูลได้ โดยปกติจะไม่แปลงจอแสดงผล HMI รุ่นเก่าเป็นรูปแบบ HMI ใหม่

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

องค์ประกอบเหล่านี้ต้องสร้างขึ้นใหม่ใน HMI เป้าหมาย

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

วิศวกรต้องเข้าใจว่าวัตถุแบบเคลื่อนไหวทุกชิ้นรับและประมวลผลข้อมูลของตนอย่างไร

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

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

ดังนั้น การย้ายเฉพาะกราฟิกที่มองเห็นได้อาจทำให้เกิด HMI ที่ดูถูกต้องแต่ทำงานไม่ถูกต้อง

ทีมย้ายระบบต้องจัดทำเอกสารอธิบายความหมายเชิงหน้าที่เบื้องหลังองค์ประกอบแต่ละรายการบนหน้าจอ

งานนี้ประกอบด้วย:

• การจับคู่วัตถุแบบไดนามิกทุกชิ้นกับแหล่งข้อมูล

• การสร้างนิพจน์แอนิเมชันขึ้นใหม่

• การตรวจสอบการยืนยันคำสั่งและความปลอดภัย

• การสร้างการนำทางและลำดับชั้นของหน้าจอขึ้นใหม่

• การสร้างคลาสและลำดับความสำคัญของสัญญาณเตือนขึ้นใหม่

• การยืนยันหน่วยทางวิศวกรรมและความละเอียดของทศนิยม

• การสร้างกราฟแนวโน้มย้อนหลังและแบบเรียลไทม์ขึ้นใหม่

• การทดสอบสถานะการสื่อสารที่ไม่ถูกต้อง ไม่แน่นอน และล้มเหลว

• การสร้างข้อความและคำแนะนำสำหรับผู้ปฏิบัติงานขึ้นใหม่

• การแทนที่ฟอนต์และสัญลักษณ์ที่ไม่รองรับ

ดังนั้น ความพยายามจึงถูกกำหนดโดยความซับซ้อนของหน้าจอ ไม่ใช่เพียงจำนวนหน้าจอ

HMI รุ่นใหม่ไม่ควรคัดลอกหน้าจอเดิมทุกหน้าจอโดยไม่ไตร่ตรอง

การสร้างขึ้นใหม่ด้วยตนเองเปิดโอกาสให้ปรับปรุงส่วนติดต่อผู้ปฏิบัติงาน

กราฟิก HMI รุ่นเก่ามักใช้สีสว่างกับอุปกรณ์ที่ทำงานปกติ แผนภาพกระบวนการที่หนาแน่น เส้นท่อเพื่อการตกแต่ง และการแสดงสัญญาณเตือนที่ไม่สอดคล้องกัน

แนวปฏิบัติเหล่านี้อาจเหมาะสมเมื่อมีการพัฒนาระบบเดิม แต่ไม่เหมาะที่สุดเสมอไปสำหรับแนวปฏิบัติในห้องควบคุมปัจจุบัน

โครงการปรับปรุงระบบควรทบทวน:

• ลำดับชั้นของหน้าจอ

• การมองเห็นสัญญาณเตือน

• ความสอดคล้องของการนำทาง

• การแสดงสถานะอุปกรณ์

• การใช้สี

• การเข้าถึงกราฟแนวโน้ม

• ข้อกำหนดด้านการตอบสนองของผู้ปฏิบัติงาน

• ความละเอียดหน้าจอและการจัดวางเวิร์กสเตชัน

• การเข้าถึงและความสามารถในการอ่าน

สภาวะการทำงานปกติควรดูสงบในเชิงภาพ สีที่โดดเด่นควรใช้ระบุสถานะผิดปกติที่ต้องให้ความสนใจ

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

อย่างไรก็ตาม การออกแบบใหม่มากเกินไปก็อาจก่อให้เกิดความเสี่ยงอีกประการหนึ่ง

ผู้ปฏิบัติงานอาจใช้หน้าจอเดิมมาหลายปี การเปลี่ยนสัญลักษณ์ สี และเส้นทางการนำทางทั้งหมดในโครงการเดียวกัน อาจเพิ่มข้อกำหนดด้านการฝึกอบรมและความเสี่ยงในการเปลี่ยนระบบ

แนวทางที่สมดุลจะคงความสัมพันธ์ของกระบวนการที่คุ้นเคยไว้ พร้อมปรับปรุงการแสดงผลสัญญาณเตือนและการนำทาง

การดึงแท็กต้องได้รับการจัดการเป็นชุดงานวิศวกรรม

เนื้อหาต้นทางระบุถึงความเป็นไปได้ในการส่งออกข้อมูลแท็กของ Bailey เป็น CSV แต่ไม่ได้ให้ขั้นตอนสากลที่ยืนยันแล้ว

ดังนั้นจึงไม่ควรสันนิษฐานว่าคำสั่งส่งออกเพียงคำสั่งเดียวจะสร้างฐานข้อมูล HMI ที่ครบถ้วนและสะอาดพร้อมใช้งาน

แหล่งข้อมูลแท็กที่เป็นไปได้ ได้แก่:

• ฐานข้อมูลการกำหนดค่า Symphony

• คำจำกัดความหน้าจอที่มีอยู่

• เอกสารการกำหนดค่าคอนโทรลเลอร์และวิศวกรรม

• ฐานข้อมูลเซิร์ฟเวอร์สื่อสารของ Bailey

• ฟังก์ชันเรียกดูของเซิร์ฟเวอร์ OPC

• ไฟล์การกำหนดค่าสัญญาณเตือน

• ฐานข้อมูลประวัติ

• รายการแท็กที่พิมพ์หรือจัดเก็บถาวร

• สเปรดชีตทางวิศวกรรมของไซต์

การเรียกดู OPC สามารถเป็นจุดเริ่มต้นที่ใช้งานได้จริง หลังจากเซิร์ฟเวอร์สร้างการสื่อสารกับระบบ Bailey ได้แล้ว

เนมสเปซดังกล่าวอาจแสดงชื่อแท็ก ตัวระบุรายการ คำอธิบาย คุณภาพ และค่าปัจจุบันได้ เซิร์ฟเวอร์บางรายยังรองรับการส่งออกเนมสเปซที่เรียกดูได้ด้วย

อย่างไรก็ตาม เนมสเปซ OPC อาจไม่มีข้อมูลทุกฟิลด์ที่ HMI ใหม่ต้องใช้

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

เซิร์ฟเวอร์ OPC บางรายแสดงแท็กโดยใช้ชื่อที่สร้างขึ้น ซึ่งแตกต่างจากชื่อ Symphony เดิม

โครงการควรจัดทำทะเบียนแท็กที่มีการควบคุม โดยอย่างน้อยต้องมีข้อมูลดังนี้:

• ชื่อแท็กเดิม

• ชื่อแท็ก HMI ใหม่

• ตัวระบุรายการ OPC

• คำอธิบาย

• ชนิดข้อมูล

• สิทธิ์การอ่านหรือเขียน

• หน่วยทางวิศวกรรม

• ข้อมูลการสเกล

• ขีดจำกัดและลำดับความสำคัญของสัญญาณเตือน

• อัตราการอัปเดต

• หน้าจอที่เกี่ยวข้อง

• สถานะการตรวจสอบยืนยัน

• ผลการทดสอบ

เอกสารหลักนี้จะเป็นบันทึกสำหรับกระทบยอดระหว่างระบบเดิมกับระบบใหม่

จำนวนแท็กไม่ใช่ข้อกำหนดด้านการสื่อสารเพียงอย่างเดียว

การทดสอบเรียกดูที่สำเร็จไม่ได้พิสูจน์ว่าสถาปัตยกรรม OPC สามารถรองรับ HMI ทั้งระบบได้

วิศวกรต้องประเมินจำนวนแท็กที่ทำงานอยู่ อัตราการอัปเดตที่ร้องขอ ความถี่ของการเปลี่ยนแปลง กิจกรรมของสัญญาณเตือน ปริมาณการรับส่งคำสั่ง และความซ้ำซ้อนของเซิร์ฟเวอร์

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

ควรทดสอบเซิร์ฟเวอร์และ HMI ภายใต้เงื่อนไขที่ใกล้เคียงการใช้งานจริง

การตรวจสอบประสิทธิภาพที่สำคัญประกอบด้วย:

• เวลาที่ต้องใช้ในการเปิดหน้าจอที่ซับซ้อน

• ความล่าช้าระหว่างการเปลี่ยนแปลงที่หน้างานกับแอนิเมชันบน HMI

• การส่งสัญญาณเตือนระหว่างช่วงที่มีเหตุการณ์จำนวนมาก

• การเก็บข้อมูลแนวโน้มตามอัตราการสุ่มตัวอย่างที่กำหนด

• เวลาในการดำเนินการคำสั่งและการตอบกลับ

• การกู้คืนหลังเครือข่ายขัดข้อง

• การสลับการทำงานระหว่างเซิร์ฟเวอร์สำรอง

• พฤติกรรมหลังรีสตาร์ตคอนโทรลเลอร์

• สถานะคุณภาพระหว่างการสื่อสารล้มเหลว

• โหลดของ CPU หน่วยความจำ และเครือข่าย

คำสั่งต่าง ๆ ต้องได้รับการใส่ใจเป็นพิเศษ

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

ทีมควรทดสอบคำสั่งของผู้ปฏิบัติงานทุกประเภท ไม่ใช่เพียงแท็กตัวแทนหนึ่งรายการ

ABB Symphony Plus มอบเส้นทางการพัฒนาต่อยอดที่กว้างขึ้น

การเปลี่ยน OPC ไม่ใช่เส้นทางเดียวสำหรับระบบ Bailey ที่ติดตั้งอยู่

ABB ยังคงวางตำแหน่ง Symphony Plus ให้เป็นแพลตฟอร์มต่อยอดสำหรับการติดตั้ง Bailey, INFI 90, Harmony Rack และ Symphony รุ่นเก่า

การปรับปรุงระบบ ABB แบบเป็นระยะอาจคงบางส่วนของสถาปัตยกรรมระบบควบคุมและ I/O ที่ติดตั้งไว้ พร้อมเพิ่มส่วนประกอบใหม่สำหรับผู้ปฏิบัติงาน วิศวกรรม เครือข่าย คอนโทรลเลอร์ หรือ I/O

แนวทางนี้อาจน่าสนใจเมื่อองค์กรต้องการกลยุทธ์วงจรชีวิตที่ผู้จำหน่ายให้การสนับสนุน แทนการเปลี่ยน HMI อย่างเป็นอิสระ

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

ระยะถัดไปสามารถจัดการด้านการสื่อสาร คอนโทรลเลอร์ เครื่องมือทางวิศวกรรม และอินเทอร์เฟซภาคสนามได้

สถาปัตยกรรมการย้ายระบบที่แน่นอนขึ้นอยู่กับรุ่นของระบบที่ติดตั้ง

การติดตั้ง Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony และ Symphony Plus ไม่ได้ใช้อินเทอร์เฟซแบบเดียวกันทั้งหมด

ต้องตรวจสอบชื่อโมดูลและคำศัพท์เครือข่ายจากแบบแปลนหน้างานและบัญชีฮาร์ดแวร์

องค์กรที่ดูแลเลเยอร์ควบคุมเดิมยังสามารถตรวจสอบ ส่วนประกอบ ABB Bailey INFI 90 และ Network 90 ที่มีอยู่ได้เมื่อวางแผนความครอบคลุมของอะไหล่ การสนับสนุนตลอดวงจรชีวิต และการปรับปรุงระบบแบบเป็นระยะ

ลิงก์ภายในนี้เกี่ยวข้อง เนื่องจากโครงการปรับปรุงระบบมักต้องให้ระบบเดิมยังคงทำงานระหว่างการวิศวกรรม การทดสอบ และการเปลี่ยนระบบเป็นระยะ

การบำรุงรักษาคอนโทรลเลอร์ โมดูลสื่อสาร แหล่งจ่ายไฟ และโมดูล I/O สำรองที่เหมาะสม สามารถลดความเสี่ยงในช่วงเปลี่ยนผ่านดังกล่าวได้

HMI แบบกำหนดเองหรือโอเพนซอร์สเป็นไปได้ แต่ต้องมีผู้รับผิดชอบ

สามารถพัฒนา HMI แบบกำหนดเองได้โดยใช้เฟรมเวิร์กซอฟต์แวร์โอเพนซอร์สหรือเชิงพาณิชย์

เนื้อหาต้นฉบับกล่าวถึงเซิร์ฟเวอร์ที่ทำงานบน VMS พร้อมไคลเอนต์สมัยใหม่ที่ใช้ Qt สถาปัตยกรรมลักษณะนี้สามารถแยกการเชื่อมต่อข้อมูลฝั่งเซิร์ฟเวอร์ออกจากไคลเอนต์ของผู้ปฏิบัติงานได้

แนวทางนี้ให้ความยืดหยุ่นและช่วยหลีกเลี่ยงการพึ่งพาผู้จำหน่าย HMI รายใดรายหนึ่ง

เส้นทางนี้อาจกลายเป็นภาระผูกพันด้านการพัฒนาซอฟต์แวร์ระยะยาวได้เช่นกัน

องค์กรต้องเป็นเจ้าของหรือดูแลรักษาสิ่งต่อไปนี้:

• เซิร์ฟเวอร์การสื่อสาร

• ฐานข้อมูลแท็ก

• แอปพลิเคชันไคลเอนต์

• เฟรมเวิร์กกราฟิก

• การประมวลผลการแจ้งเตือน

• การผสานรวมกับฮิสทอเรียน

• การยืนยันตัวตนผู้ใช้

• การอัปเดตความมั่นคงปลอดภัยทางไซเบอร์

• การนำไปใช้งานและการควบคุมเวอร์ชัน

• เอกสารและการฝึกอบรม

Qt, Python, C++, เทคโนโลยีเว็บ หรือเฟรมเวิร์กอื่น ๆ สามารถสร้างอินเทอร์เฟซอุตสาหกรรมที่มีประสิทธิภาพได้ ความยากไม่ได้อยู่ที่การวาดกราฟิกกระบวนการ

ความยากอยู่ที่การสร้างระบบสำหรับผู้ปฏิบัติงานที่เชื่อถือได้และทำงานได้อย่างถูกต้องเมื่อเกิดการสื่อสารขัดข้อง การรีสตาร์ตเซิร์ฟเวอร์ การแจ้งเตือนจำนวนมาก การเปลี่ยนแปลงผู้ใช้ และสภาวะผิดปกติของโรงงาน

ควรเลือกแพลตฟอร์มแบบกำหนดเองเฉพาะเมื่อองค์กรมีทีมวิศวกรรมที่ดูแลได้อย่างยั่งยืน หรือตัวผสานระบบระยะยาวที่เชื่อถือได้

ลิขสิทธิ์สามารถเป็นตัวกำหนดได้ว่าแนวทางทางเทคนิคนั้นใช้งานได้จริงหรือไม่

ซอฟต์แวร์อุตสาหกรรมรุ่นเก่ามักใช้กลไกการให้สิทธิ์ใช้งานที่ผูกกับตัวระบุฮาร์ดแวร์ ที่อยู่ Ethernet ฐานข้อมูลลิขสิทธิ์ ดองเกิล หรือคีย์การอนุญาตที่ผู้จำหน่ายออกให้

ระบบที่โคลนอาจบูตได้อย่างถูกต้อง แต่ปฏิเสธที่จะเริ่มแอปพลิเคชัน Symphony เนื่องจากข้อมูลระบุฮาร์ดแวร์เสมือนมีการเปลี่ยนแปลง

รายการทรัพย์สินสำหรับการย้ายระบบควรรวม:

• ลิขสิทธิ์ระบบปฏิบัติการ OpenVMS

• ลิขสิทธิ์แอปพลิเคชัน Bailey Symphony

• ลิขสิทธิ์ฐานข้อมูล

• ลิขสิทธิ์เครือข่ายและการสื่อสาร

• ลิขสิทธิ์โปรแกรมจำลอง

• ลิขสิทธิ์จำนวนจุด HMI และ OPC

• ลิขสิทธิ์ระบบจัดเก็บข้อมูลประวัติ

• ตัวเลือกความซ้ำซ้อน

• ลิขสิทธิ์ไคลเอ็นต์วิศวกรรม

• ลิขสิทธิ์ไคลเอ็นต์รันไทม์

ควรขอการยืนยันเป็นลายลักษณ์อักษรก่อนเลือกแพลตฟอร์มขั้นสุดท้าย

ความเข้ากันได้ทางเทคนิคโดยไม่มีสิทธิ์ใช้งานตามกฎหมาย ไม่ได้ทำให้โซลูชันนั้นพร้อมนำไปใช้งาน

ต้องออกแบบความมั่นคงปลอดภัยทางไซเบอร์ไว้ในระบบทดแทน

ระบบ AlphaStation รุ่นเก่ามักติดตั้งก่อนที่แนวปฏิบัติด้านความมั่นคงปลอดภัยทางไซเบอร์สำหรับอุตสาหกรรมสมัยใหม่จะกลายเป็นมาตรฐาน

ระบบเหล่านี้อาจทำงานบนเครือข่ายแยกเดี่ยวที่มีการเข้าถึงระยะไกลอย่างจำกัด การแทนที่ระบบเหล่านี้ด้วยเซิร์ฟเวอร์ Windows ไคลเอ็นต์ SCADA สมัยใหม่ เซิร์ฟเวอร์ OPC และโครงสร้างพื้นฐาน Ethernet จะเปลี่ยนพื้นผิวการโจมตี

สถาปัตยกรรมใหม่ควรกำหนดโซนเครือข่ายแยกสำหรับการควบคุม เซิร์ฟเวอร์ วิศวกรรม และองค์กร

ไฟร์วอลล์ควรอนุญาตเฉพาะเส้นทางการสื่อสารที่จำเป็น การเข้าถึงระยะไกลควรใช้การยืนยันตัวตนและการบันทึกที่มีการจัดการ

บัญชีผู้ปฏิบัติงานควรใช้สิทธิ์ตามบทบาท ฟังก์ชันทางวิศวกรรมไม่ควรพร้อมใช้งานจากไคลเอ็นต์ HMI ทุกเครื่อง

ควรจำกัดสิทธิ์การเขียน OPC เฉพาะแท็กและสถานีที่จำเป็นต้องใช้สิทธิ์ดังกล่าว

การออกแบบควรครอบคลุมประเด็นต่อไปนี้ด้วย:

• การติดตั้งแพตช์ระบบปฏิบัติการ

• โปรแกรมป้องกันไวรัสหรือการควบคุมแอปพลิเคชัน

• การสำรองและกู้คืนข้อมูล

• การซิงโครไนซ์เวลา

• การบันทึกเหตุการณ์ด้านความปลอดภัย

• การควบคุมสื่อแบบถอดได้

• การสนับสนุนระยะไกลจากผู้จำหน่าย

• การจัดการใบรับรองสำหรับ OPC UA

• การจัดการวงจรชีวิตบัญชี

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

การย้ายระบบควรเริ่มต้นด้วยรายการทรัพย์สินที่อ้างอิงหลักฐาน

ก่อนเลือกแนวทาง วิศวกรควรจัดทำเอกสารรายละเอียดของระบบที่มีอยู่

รายการทรัพย์สินควรรวม AlphaStation ทั้งสี่เครื่อง และระบุว่าการกำหนดค่าของแต่ละเครื่องเหมือนกันอย่างแท้จริงหรือไม่

บันทึก:

• รุ่น AlphaStation และการกำหนดค่าโปรเซสเซอร์

• ความจุหน่วยความจำ

• ประเภทดิสก์และโวลุ่มเชิงตรรกะ

• เวอร์ชันและระดับแพตช์ของ OpenVMS

• เวอร์ชันซอฟต์แวร์ Bailey ที่ติดตั้ง

• ผลิตภัณฑ์แบบเลเยอร์และฐานข้อมูล

• ฮาร์ดแวร์กราฟิกและความละเอียดหน้าจอ

• อะแดปเตอร์เครือข่าย

• อินเทอร์เฟซอนุกรม

• ฮาร์ดแวร์สื่อสาร Bailey

• ชื่อและที่อยู่ของโหนด

• ขั้นตอนคำสั่งเริ่มต้นระบบ

• ไฟล์ลิขสิทธิ์

• ขั้นตอนการสำรองข้อมูล

• ความซ้ำซ้อนของสถานีปฏิบัติการ

• เครื่องพิมพ์และอุปกรณ์ภายนอกที่เชื่อมต่อ

• การเก็บรักษาข้อมูลย้อนหลังและข้อมูลสัญญาณเตือน

ทีมควรเก็บภาพหน้าจอของทุกจอแสดงผลด้วย ควรบันทึกสถานะแบบไดนามิกเมื่อทำได้

บันทึกสถานะปกติ หยุดทำงาน กำลังทำงาน มีสัญญาณเตือน ถูกยับยั้ง อยู่ในโหมดท้องถิ่น แมนนวล อัตโนมัติ และการสื่อสารล้มเหลว

หลักฐานนี้จำเป็นเมื่อทดสอบหน้าจอใหม่

ระบบทดสอบเป็นสิ่งจำเป็น

ไม่ควรทดสอบเส้นทางการปรับปรุงระบบใดเป็นครั้งแรกบนระบบการผลิตจริง

สภาพแวดล้อมสำหรับการทดสอบควรจำลองสถาปัตยกรรมที่ติดตั้งไว้ได้เพียงพอ เพื่อยืนยันการสื่อสารและฟังก์ชันของผู้ปฏิบัติงาน

สำหรับโครงการอีมูเลเตอร์ ระบบทดสอบควรมีสภาพแวดล้อม OpenVMS Alpha ที่โคลนไว้และการกำหนดค่าอีมูเลเตอร์ที่เสนอ

สำหรับโครงการ OPC ควรรวมเซิร์ฟเวอร์การสื่อสารที่เลือก ซอฟต์แวร์ HMI กราฟิกตัวแทน และการเข้าถึงโหนดทดสอบ Bailey ที่ปลอดภัยหรือแหล่งข้อมูลจำลอง

การทดสอบบนระบบทดสอบควรตรวจสอบ:

• การบูตระบบและการเริ่มต้นแอปพลิเคชัน

• การสื่อสารกับระบบ Bailey

• จำนวนแท็กที่เข้าถึงได้ทั้งหมด

• การดำเนินการอ่านและเขียน

• การปรับสเกลแท็กและหน่วยทางวิศวกรรม

• การสร้างและการรับทราบสัญญาณเตือน

• การเก็บรวบรวมแนวโน้ม

• ภาพเคลื่อนไหวบนหน้าจอ

• ความปลอดภัยของคำสั่ง

• ฟังก์ชันเครื่องพิมพ์และรายงาน

• พฤติกรรมเมื่อเซิร์ฟเวอร์เริ่มการทำงานใหม่

• พฤติกรรมเมื่อเครือข่ายล้มเหลว

• ความซ้ำซ้อนและการสลับไปใช้ระบบสำรองเมื่อขัดข้อง

• การกู้คืนข้อมูลสำรอง

• เวลาตอบสนองของผู้ปฏิบัติงาน

ผลการทดสอบควรมีผู้ปฏิบัติงาน วิศวกรควบคุม วิศวกรซ่อมบำรุง และตัวแทนด้านความมั่นคงปลอดภัยไซเบอร์ร่วมรับรอง

การทำงานแบบขนานช่วยลดความเสี่ยงในการสลับระบบ

ควรคง AlphaStation เดิมไว้ให้พร้อมใช้งานระหว่างการติดตั้งระบบทดแทนในระยะแรก

HMI ใหม่สามารถทำงานแบบขนานได้ ขณะที่วิศวกรเปรียบเทียบค่า สัญญาณเตือน แนวโน้ม และคำสั่ง

การทำงานแบบขนานช่วยให้ระบุความไม่ตรงกันได้ก่อนถอดสถานีเดิมออก

ทีมควรตรวจสอบให้สอดคล้องกันในเรื่อง:

• ค่ากระบวนการที่แสดง

• ตัวบ่งชี้สถานะ

• ลำดับความสำคัญของสัญญาณเตือน

• เวลาประทับของสัญญาณเตือน

• ผลลัพธ์ของคำสั่ง

• ค่าของแนวโน้ม

• โหมดของอุปกรณ์

• คุณภาพการสื่อสาร

• สิทธิ์ด้านความปลอดภัย

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

ความแตกต่างทุกประการควรได้รับการอธิบายและอนุมัติ

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

การเลือกเส้นทางการย้ายระบบที่ถูกต้อง

เลือกการจำลอง Alpha เมื่อ:

แอปพลิเคชัน Symphony เดิมต้องคงไว้โดยไม่มีการเปลี่ยนแปลง ไม่สามารถเข้าถึงซอร์สโค้ดได้ กราฟิกของผู้ปฏิบัติงานมีความซับซ้อน ต้องลดการฝึกอบรมใหม่ให้น้อยที่สุด และสถาปัตยกรรมอีมูเลเตอร์สามารถรองรับอินเทอร์เฟซการสื่อสารของ Bailey ได้

เลือกการย้าย OpenVMS ไปยัง x86 เมื่อ:

แอปพลิเคชันที่จำเป็นมีให้ใช้งานสำหรับ x86-64 หรือสามารถสร้างใหม่ได้ ซอร์สโค้ดและความรู้ด้านวิศวกรรมยังคงมีอยู่ องค์กรต้องการคง OpenVMS ไว้ขณะย้ายไปยังสภาพแวดล้อม x86 ที่มีการสนับสนุน

เลือกการปรับแพลตฟอร์มใหม่ด้วย OPC เมื่อ:

คอนโทรลเลอร์ INFI 90 และชั้น I/O ยังคงเชื่อถือได้ องค์กรต้องการแพลตฟอร์ม HMI ที่ทันสมัย และมีทรัพยากรด้านวิศวกรรมสำหรับสร้างและตรวจสอบจอแสดงผล การแจ้งเตือน แท็ก และตรรกะคำสั่งขึ้นใหม่

เลือกแนวทางวิวัฒน์ระบบของ ABB เมื่อ:

องค์กรต้องการโครงการปรับปรุงระบบให้ทันสมัยที่ครอบคลุมยิ่งขึ้นและได้รับการสนับสนุนจากผู้จำหน่าย ระยะต่อไปอาจรวมถึงระบบผู้ปฏิบัติงาน เครื่องมือวิศวกรรม อินเทอร์เฟซเครือข่าย คอนโทรลเลอร์ และ I/O

เลือก HMI แบบพัฒนาเฉพาะเมื่อ:

องค์กรมีข้อกำหนดเฉพาะทาง และสามารถรองรับการพัฒนาซอฟต์แวร์ การทดสอบ ความมั่นคงปลอดภัยทางไซเบอร์ และการบำรุงรักษาตลอดวงจรชีวิตได้ในระยะยาว

คงระบบเดิมไว้ชั่วคราวเมื่อ:

อินเทอร์เฟซสำหรับการย้ายระบบยังไม่ชัดเจน ข้อมูลสำรองไม่สมบูรณ์ การให้สิทธิ์ใช้งานยังไม่ได้ข้อยุติ ฐานข้อมูลแท็กไม่พร้อมใช้งาน และการทดสอบบนแท่นทดสอบยังไม่สามารถจำลองเส้นทางการสื่อสารของ Bailey ได้

แผนปรับปรุงระบบให้ทันสมัยแบบแบ่งระยะในทางปฏิบัติ

ระยะที่ 1: รักษาสภาพแวดล้อมเดิม

สร้างข้อมูลสำรองอิมเมจที่ตรวจสอบแล้วของ AlphaStation ทุกเครื่อง บันทึกข้อมูลฮาร์ดแวร์ ซอฟต์แวร์ เครือข่าย การให้สิทธิ์ใช้งาน และรายละเอียดการเริ่มระบบ ทดสอบการกู้คืนเมื่อทำได้

ระยะที่ 2: ระบุสถาปัตยกรรมการสื่อสาร

จัดทำเอกสารอย่างละเอียดว่าสถานี Symphony แต่ละสถานีสื่อสารกับ INFI 90 อย่างไร ยืนยันว่าอินเทอร์เฟซสามารถจำลองหรือแทนที่ด้วยเซิร์ฟเวอร์ที่รองรับได้หรือไม่

ระยะที่ 3: สร้างโครงการพิสูจน์แนวคิด

ทดสอบสถานีที่โคลนหนึ่งสถานีบนอีมูเลเตอร์ Alpha หรือเชื่อมต่อเซิร์ฟเวอร์ OPC หนึ่งเครื่องกับโหนด Bailey ตัวแทนหนึ่งโหนด

ระยะที่ 4: จัดทำฐานข้อมูลหลักของแท็ก

ตรวจสอบแท็กของคอนโทรลเลอร์ ตัวระบุรายการ OPC หน่วยทางวิศวกรรม คำสั่ง การแจ้งเตือน และการใช้งานจอแสดงผลให้ตรงกัน

ระยะที่ 5: สร้างจอแสดงผลตัวแทนขึ้นใหม่

เลือกหน้าจอหลายหน้าที่มีข้อกำหนดด้านแอนิเมชัน การแจ้งเตือน คำสั่ง และแนวโน้มข้อมูลแตกต่างกัน

ระยะที่ 6: ทดสอบการยอมรับระบบบนแท่นทดสอบให้เสร็จสมบูรณ์

ทดสอบการโหลดแท็กทั้งหมด การสื่อสารขัดข้อง การรีสตาร์ตเซิร์ฟเวอร์ การแจ้งเตือนจำนวนมาก พฤติกรรมของคำสั่ง และการกู้คืนข้อมูลสำรอง

ระยะที่ 7: ติดตั้งระบบแบบขนาน

ใช้งาน HMI ใหม่และเก่าควบคู่กัน เปรียบเทียบค่าและการตอบสนองของผู้ปฏิบัติงาน

ระยะที่ 8: ดำเนินการเปลี่ยนระบบโดยมีพยานรับรอง

ใช้ขั้นตอนการทดสอบที่ได้รับอนุมัติ เก็บ AlphaStation ไว้ให้พร้อมใช้งานเป็นระบบสำรอง

ระยะที่ 9: เลิกใช้ฮาร์ดแวร์รุ่นเก่าอย่างค่อยเป็นค่อยไป

อย่าทำลายอิมเมจ ต้นฉบับ บันทึกการกำหนดค่า ใบอนุญาต หรือฮาร์ดแวร์เดิม จนกว่าจะเสร็จสิ้นการยอมรับระบบในระยะยาว

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

สามารถโคลนดิสก์ของ OpenVMS AlphaStation ไปยังพีซีรุ่นใหม่โดยตรงได้หรือไม่

ไม่ได้ อิมเมจนี้มีโค้ดเครื่องสำหรับ Alpha และต้องใช้ฮาร์ดแวร์ที่เข้ากันได้กับ Alpha พีซี x86 รุ่นใหม่ไม่สามารถบูตอิมเมจนี้ได้โดยตรง ต้องกู้คืนอิมเมจลงบนฮาร์ดแวร์ Alpha ที่เข้ากันได้หรืออีมูเลเตอร์ Alpha

VMware หรือ VirtualBox สามารถรัน OpenVMS ได้หรือไม่

สามารถรัน OpenVMS รุ่น x86-64 ที่รองรับได้ แต่ไม่สามารถแปลงการติดตั้ง OpenVMS Alpha เดิมให้เป็นแอปพลิเคชัน x86 ได้ OpenVMS Alpha จำเป็นต้องใช้อีมูเลชัน Alpha

สามารถคงจอแสดงผล Symphony เดิมไว้ได้หรือไม่

โดยปกติสามารถรักษาไว้ได้เมื่อสภาพแวดล้อม Alpha ทั้งหมดทำงานภายใต้โปรแกรมจำลองที่เข้ากันได้ แต่โดยทั่วไปต้องสร้างขึ้นใหม่ด้วยตนเองเมื่อย้ายไปยังแพลตฟอร์ม HMI อื่น

เซิร์ฟเวอร์ OPC ส่งออกแท็ก Bailey ทุกแท็กโดยอัตโนมัติหรือไม่

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

GE CIMPLICITY เป็น HMI ทดแทนเพียงตัวเดียวหรือไม่

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

การย้ายจาก Alpha ไปยัง Itanium ยังคุ้มค่าหรือไม่

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

คอนโทรลเลอร์และ I/O ของ INFI 90 สามารถติดตั้งใช้งานต่อไปได้หรือไม่

ได้ หากยังคงมีความน่าเชื่อถือและสถาปัตยกรรมการสื่อสารที่เลือกใช้รองรับ HMI สามารถปรับปรุงให้ทันสมัยแยกจากการเปลี่ยนคอนโทรลเลอร์และ I/O ได้

ควรถอด AlphaStation รุ่นเก่าทันทีหลังเปลี่ยนระบบหรือไม่

ไม่ควรถอดออกทันที ควรเก็บไว้เป็นทางเลือกสำรองที่ผ่านการทดสอบ จนกว่าสภาพแวดล้อมผู้ปฏิบัติงานใหม่จะผ่านการยอมรับด้านการทำงาน ประสิทธิภาพ และการปฏิบัติงาน

โซลูชันที่ถูกต้องขึ้นอยู่กับสิ่งที่ต้องรักษาไว้

ข้อผิดพลาดทางเทคนิคหลักในแผน HMI รุ่นเก่าจำนวนมาก คือการมองว่าสถานีผู้ปฏิบัติงานเป็นเพียงพีซีทั่วไป

AlphaStation ที่ใช้ OpenVMS Alpha และ Bailey Symphony คือสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ที่สมบูรณ์ ซึ่งสถาปัตยกรรมโปรเซสเซอร์ ระบบปฏิบัติการ ส่วนเชื่อมต่อการสื่อสาร ไบนารีของแอปพลิเคชัน ใบอนุญาต กราฟิก และการเชื่อมต่อกับระบบควบคุมต่างพึ่งพาซึ่งกันและกัน

การโคลนดิสก์ช่วยรักษาข้อมูลไว้ แต่ไม่ได้แปลงสภาพแวดล้อมนั้นให้ทำงานบนสถาปัตยกรรมอื่น

การจำลองระบบ Alpha เป็นแนวทางที่ตรงที่สุด เมื่อจำเป็นต้องให้การติดตั้ง Symphony ทั้งหมดยังคงทำงานต่อไปโดยไม่เปลี่ยนแปลง

OpenVMS x86-64 เป็นแนวทางระบบปฏิบัติการสมัยใหม่ เมื่อสามารถย้ายหรือสร้างแอปพลิเคชันขึ้นใหม่ได้

การปรับแพลตฟอร์ม OPC เป็นแนวทางที่ใช้งานได้จริง เมื่อชั้นควบคุม INFI 90 ยังคงมีคุณค่า แต่ควรเปลี่ยนชั้นผู้ปฏิบัติงาน

การพัฒนาต่อยอด ABB Symphony Plus สามารถมอบกลยุทธ์แบบเป็นขั้นตอนที่ครอบคลุมกว่า เมื่อองค์กรต้องการปรับปรุงให้ทันสมัยมากกว่าเฉพาะ HMI

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

ไม่มีการเปลี่ยนระบบที่ไม่ต้องใช้ความพยายามเลย อย่างไรก็ตาม มีแนวทางการย้ายระบบแบบควบคุมได้หลายรูปแบบ ซึ่งช่วยปกป้องการลงทุนด้านการควบคุมกระบวนการที่มีอยู่เดิม พร้อมลดการพึ่งพาฮาร์ดแวร์ AlphaStation ที่เก่าแล้ว