Hiện đại hóa các HMI Bailey INFI 90 Symphony chạy trên OpenVMS Alpha

Hiện đại hóa HMI mà không thay thế toàn bộ hệ thống INFI 90

Nhiều hệ thống Bailey INFI 90 vẫn tiếp tục vận hành đáng tin cậy hàng chục năm sau khi được lắp đặt ban đầu. Bộ điều khiển, mô-đun truyền thông, bộ đầu cuối và I/O hiện trường của chúng vẫn có thể thực hiện các chức năng điều khiển cần thiết.

Vấn đề vòng đời cấp bách nhất thường nằm phía trên lớp bộ điều khiển.

Các trạm vận hành có thể phụ thuộc vào phần cứng AlphaStation đã cũ, bộ điều hợp đồ họa không còn được hỗ trợ, thiết bị lưu trữ lỗi thời và môi trường phần mềm OpenVMS Alpha cũ. Linh kiện thay thế ngày càng khó tìm, trong khi các kỹ sư giàu kinh nghiệm về OpenVMS và Bailey Symphony ngày càng khan hiếm.

Ví dụ được xem xét ở đây gồm bốn máy trạm AlphaStation 255. Mỗi máy chạy OpenVMS Alpha và lưu trữ các chức năng giao diện vận hành Bailey Symphony cho một hệ thống điều khiển phân tán Bailey INFI 90.

Mục tiêu không nhất thiết là thay thế toàn bộ DCS. Mục tiêu thực tế hơn là loại bỏ sự phụ thuộc vào phần cứng AlphaStation đã cũ, đồng thời bảo toàn các bộ điều khiển ổn định, hệ thống dây dẫn hiện trường, mô-đun I/O, logic điều khiển và hoạt động của quy trình.

Sự phân biệt đó làm thay đổi chiến lược hiện đại hóa.

Dự án chủ yếu là quá trình di chuyển giao diện vận hành và nền tảng điện toán. Dự án chỉ trở thành quá trình di chuyển toàn bộ DCS khi vòng đời bộ điều khiển, yêu cầu an ninh mạng, mục tiêu sản xuất hoặc điều kiện hỗ trợ khiến việc thay thế các lớp điều khiển bên dưới trở nên cần thiết.

Có một số hướng hiện đại hóa khả thi. Tuy nhiên, mỗi hướng bảo toàn những phần khác nhau của hệ thống hiện có.

Trình mô phỏng Alpha có thể bảo toàn gần như toàn bộ môi trường phần mềm. Di chuyển OpenVMS sang x86 bảo toàn họ hệ điều hành nhưng đòi hỏi phải di chuyển ứng dụng. Thay thế HMI dựa trên OPC bảo toàn lớp bộ điều khiển đồng thời xây dựng lại giao diện vận hành. Chiến lược phát triển ABB có thể hiện đại hóa toàn bộ kiến trúc Symphony theo từng giai đoạn.

Không nên mô tả bất kỳ hướng nào là việc thay thế PC đơn giản.

Hình 1. Ba hướng hiện đại hóa chính có thể bảo toàn các phần khác nhau của khoản đầu tư Bailey INFI 90 và Symphony hiện có.

Vì sao chỉ sao chép ổ đĩa AlphaStation là chưa đủ

Sao chép ổ đĩa hữu ích để bảo toàn môi trường OpenVMS Alpha đã cài đặt. Phương pháp này có thể lưu lại hệ điều hành, tệp ứng dụng, cấu hình thiết bị, tài khoản người dùng, phần mềm Bailey, cơ sở dữ liệu, đồ họa và các thiết lập dành riêng cho từng cơ sở.

Tuy nhiên, sao chép ổ đĩa không chuyển đổi phần mềm Alpha thành phần mềm x86.

Hệ điều hành được sao chép vẫn chứa các lệnh dành cho bộ xử lý Alpha. Nhân hệ điều hành, trình tải khởi động, thư viện hệ thống, ứng dụng và trình điều khiển phần cứng được xây dựng cho kiến trúc Alpha.

Một máy tính hiện đại tiêu chuẩn sử dụng bộ xử lý x86-64. Máy cũng có các bộ điều khiển lưu trữ, thiết bị mạng, cấu trúc ngắt, phần cứng đồ họa, giao diện firmware và các bus thiết bị ngoại vi khác.

VMware, VirtualBox, Hyper-V và các trình giám sát x86 thông thường sẽ ảo hóa phần cứng tương thích với x86. Chúng thường không dịch lệnh bộ xử lý Alpha thành lệnh x86.

Vì vậy, đưa một ảnh đĩa OpenVMS Alpha vào một máy ảo x86 thông thường không khiến ảnh đó có thể khởi động.

Máy ảo có thể cung cấp ổ đĩa ảo, bộ điều hợp mạng ảo và thiết bị đồ họa ảo. OpenVMS Alpha vẫn yêu cầu bộ xử lý Alpha và các thiết bị thời Alpha được hỗ trợ.

Đây là lý do hai khái niệm phải được phân biệt:

Ảo hóa thường cung cấp phần cứng ảo sử dụng cùng kiến trúc bộ xử lý với máy chủ.

Giả lập đa kiến trúc tái tạo một bộ xử lý và môi trường phần cứng khác bằng phần mềm.

OpenVMS Alpha yêu cầu phương án thứ hai khi các tệp nhị phân Alpha gốc và hệ điều hành phải được giữ nguyên.

Do đó, sao chép ổ đĩa chỉ khả thi trong ba trường hợp hạn chế.

Phương án thứ nhất là khôi phục trên cùng mẫu AlphaStation với bộ lưu trữ và thiết bị ngoại vi tương thích.

Phương án thứ hai là khôi phục sang một hệ thống Alpha khác được hỗ trợ sau khi hoàn tất các thay đổi cần thiết về thiết bị và cấu hình.

Phương án thứ ba là khôi phục vào một trình giả lập Alpha tái tạo môi trường AlphaServer hoặc AlphaStation tương thích.

Chỉ sao chép ổ đĩa không giải quyết được vấn đề kiến trúc. Môi trường đích vẫn phải hiểu và thực thi các lệnh máy Alpha.

Giả lập Alpha bảo toàn phần lớn nhất của khoản đầu tư hiện có

Giả lập Alpha thường là phương án ít gây gián đoạn nhất khi phần mềm Symphony hiện có phải tiếp tục hoạt động mà không cần thay đổi mã nguồn.

Trình giả lập Alpha chạy trên phần cứng x86 hiện đại nhưng cung cấp cho OpenVMS một hệ thống Alpha ảo. Hệ điều hành và các ứng dụng gốc tiếp tục nhận diện một môi trường phần cứng tương thích với Alpha.

Các sản phẩm như CHARON-AXP được thiết kế cho mục đích này. Trình giả lập thay thế bộ xử lý Alpha vật lý, kiến trúc bộ nhớ, bộ điều khiển lưu trữ, bộ điều hợp Ethernet và các thiết bị được hỗ trợ khác bằng các thành phần tương đương do phần mềm định nghĩa.

Máy chủ x86 chạy Windows hoặc Linux làm môi trường máy chủ. Trình giả lập Alpha chạy trên môi trường máy chủ đó. Sau đó, OpenVMS Alpha chạy bên trong hệ thống Alpha được giả lập.

Cách tiếp cận này khác với việc chuyển OpenVMS sang x86.

Bản cài đặt OpenVMS Alpha gốc vẫn là một bản cài đặt Alpha. Các tệp nhị phân Bailey Symphony vẫn là tệp nhị phân Alpha. Trình giả lập sẽ dịch hoặc tái tạo hành vi phần cứng Alpha cần thiết.

Điều này có thể bảo toàn:

• Hệ điều hành OpenVMS Alpha đã cài đặt.

• Các ứng dụng Bailey Symphony hiện có.

• Đồ họa vận hành và cơ sở dữ liệu hiển thị.

• Cấu hình cảnh báo và các tệp lịch sử.

• Tài khoản người dùng và các quy trình lệnh.

• Các tiện ích hiện có dành riêng cho từng cơ sở.

• Các giao diện ứng dụng phụ thuộc vào môi trường Alpha.

• Các quy trình làm việc của người vận hành mà nếu không sẽ cần đào tạo lại.

Quá trình di chuyển trên thực tế thường bao gồm việc tạo một bản sao hoặc bản sao lưu đã được xác minh của các đĩa Alpha gốc. Dữ liệu đó được khôi phục vào các vùng chứa đĩa ảo do trình mô phỏng sử dụng.

Cấu hình trình mô phỏng phải tái tạo các đặc tính phù hợp của CPU, bộ nhớ, đĩa, mạng và thiết bị ngoại vi. Nhóm cũng có thể cần ánh xạ các cổng nối tiếp hoặc giao diện mạng vật lý thông qua hệ thống máy chủ.

Mô phỏng Alpha có thể giảm đáng kể sự phụ thuộc vào phần cứng vật lý lỗi thời. Nó cũng có thể đơn giản hóa việc sao lưu vì các tệp đĩa ảo có thể được sao chép bằng hạ tầng lưu trữ hiện đại.

Tuy nhiên, nên thận trọng khi sử dụng thuật ngữ “không thay đổi”.

Mã ứng dụng có thể không thay đổi, nhưng môi trường vẫn cần được thiết kế và kiểm tra. Phải kiểm tra ánh xạ thiết bị. Phải cấu hình các giao diện mạng. Phải rà soát giấy phép OpenVMS và giấy phép ứng dụng.

Trình mô phỏng cũng phải được kiểm thử với giao diện giao tiếp Bailey được sử dụng tại cơ sở.

Một ứng dụng OpenVMS chung có thể hoạt động chính xác trong khi giao diện DCS chuyên dụng bị lỗi vì phụ thuộc vào một bộ điều hợp mạng, giao diện bus, thiết bị nối tiếp hoặc đặc tính thời gian cụ thể.

Do đó, phải kiểm kê chính xác cấu hình AlphaStation 255 trước khi chọn cấu hình trình mô phỏng.

Giao diện Giao tiếp Bailey là Phép thử Mô phỏng Quan trọng

Câu hỏi quan trọng nhất về mô phỏng không phải là OpenVMS có hiển thị đến lời nhắc đăng nhập hay không.

Câu hỏi quan trọng là liệu trạm được mô phỏng có giao tiếp chính xác với hệ thống Bailey INFI 90 trong điều kiện vận hành đầy đủ hay không.

Giao diện có thể phụ thuộc vào Ethernet, giao tiếp nối tiếp, giao diện mạng Bailey hoặc phần cứng giao tiếp chuyên dụng. Cấu hình tại từng cơ sở có thể khác biệt đáng kể.

Trước khi quyết định sử dụng mô phỏng Alpha, các kỹ sư nên lập tài liệu về:

• Giao diện mạng vật lý được lắp đặt trong mỗi AlphaStation.

• Giao thức giao tiếp được sử dụng giữa Symphony và INFI 90.

• Tên thiết bị được gán trong OpenVMS.

• Địa chỉ mạng và định nghĩa nút.

• Các dịch vụ DECnet, TCP/IP, LAT hoặc độc quyền cần thiết.

• Cài đặt cổng nối tiếp khi áp dụng.

• Mọi khóa cấp phép bên ngoài hoặc thiết bị khóa phần cứng.

• Hành vi dự phòng và chuyển đổi dự phòng giữa các trạm vận hành.

• Các yêu cầu đồng bộ hóa thời gian.

• Các chức năng đồ họa và bàn phím được người vận hành sử dụng.

Nhà cung cấp trình mô phỏng có thể hỗ trợ các thiết bị Ethernet và lưu trữ Alpha phổ biến. Điều đó không tự động xác nhận khả năng hỗ trợ mọi giao diện Bailey độc quyền.

Nếu HMI hiện có phụ thuộc vào một bộ chuyển đổi vật lý chuyên dụng không thể ảo hóa, phương án sử dụng trình mô phỏng có thể cần một cổng giao tiếp thay thế.

Do đó, dự án nên bao gồm một bài kiểm thử trên băng thử, sử dụng một trạm đã sao chép và quyền truy cập vào một mạng Bailey đại diện.

Bài kiểm thử phải bao gồm nhiều hơn việc đọc tag tĩnh. Người vận hành nên xác minh các giá trị theo thời gian thực, lệnh, cảnh báo, xác nhận, biểu đồ xu hướng, điều hướng màn hình, in ấn, xử lý sự kiện và khả năng khôi phục của trạm.

Hiệu năng cũng cần được kiểm thử trong các đợt cảnh báo dồn dập và khi hoạt động cập nhật tag ở cường độ cao.

OpenVMS x86-64 là một lộ trình chuyển đổi khác

OpenVMS hiện đại có sẵn cho kiến trúc x86-64. Nó có thể hoạt động trong các môi trường ảo hóa được hỗ trợ trên các máy chủ hiện đại.

Điều này tạo ra một lựa chọn chuyển đổi bổ sung, vốn chưa có trong nhiều cuộc thảo luận hiện đại hóa INFI 90 trước đây.

Tuy nhiên, OpenVMS x86-64 không trực tiếp chạy các tệp nhị phân OpenVMS Alpha như thể chúng là các ứng dụng x86 nguyên bản.

Môi trường ứng dụng phải được chuyển đổi.

Mã nguồn có thể cần được chuyển giao, rà soát, biên dịch lại, liên kết và kiểm thử cho x86-64. Các thư viện bên thứ ba và sản phẩm phân lớp cũng phải có sẵn cho phiên bản đích.

Câu hỏi cốt lõi là phần mềm Bailey Symphony đang cài đặt có phiên bản OpenVMS tương thích với x86 hay không.

Nếu nhà cung cấp phần mềm chưa từng phát hành ứng dụng đó cho OpenVMS x86-64, chỉ chuyển hệ điều hành sẽ không bảo toàn được HMI.

Các chương trình do đơn vị tự phát triển có thể chuyển đổi được khi vẫn còn mã nguồn và môi trường xây dựng. Thông thường không thể xây dựng lại các ứng dụng thương mại đóng nếu không có sự hỗ trợ của nhà cung cấp.

Lộ trình này vẫn có thể phù hợp với các máy chủ dữ liệu tùy chỉnh, hệ thống lưu trữ lịch sử, tiện ích, báo cáo và ứng dụng tích hợp chạy bên cạnh HMI Symphony.

Khả năng bảo toàn một môi trường vận hành Symphony độc quyền cũ mà không có bản phát hành ứng dụng được hỗ trợ là thấp hơn.

Một đánh giá chuyển đổi OpenVMS x86 cần xác định:

• Mọi tệp thực thi đã cài đặt và sản phẩm phân lớp.

• Mã nguồn và quy trình xây dựng hiện có.

• Các phần phụ thuộc vào trình biên dịch và môi trường chạy.

• Các sản phẩm cơ sở dữ liệu và định dạng tệp.

• Các thư viện truyền thông độc quyền.

• Các phần phụ thuộc vào đồ họa hoặc hệ thống cửa sổ.

• Khả năng cung cấp giấy phép cho x86-64.

• Những thay đổi bắt buộc do khác biệt về kiến trúc.

• Các giả định về hiệu năng và thời gian.

Lộ trình này có tiềm năng dài hạn cao hơn so với việc chuyển từ Alpha sang một kiến trúc phần cứng khác đã ngừng phát triển. Nó có thể đưa các khối lượng công việc OpenVMS tương thích lên hạ tầng ảo hóa x86 được hỗ trợ.

Tuy nhiên, cần mô tả đây là một dự án chuyển đổi ứng dụng, không phải dự án sao chép ổ đĩa.

Vì sao quá trình chuyển đổi Itanium thường chỉ là một giải pháp chuyển tiếp

OpenVMS cũng được phát hành cho các máy chủ HPE Integrity sử dụng kiến trúc Itanium.

Có các công cụ chuyển đổi và phương pháp kỹ thuật để chuyển một số ứng dụng Alpha sang OpenVMS Integrity. Trước đây, đây từng là một lộ trình được hỗ trợ để rời bỏ phần cứng Alpha đã cũ.

Tuy nhiên, ngày nay phần cứng Itanium bản thân đã là một nền tảng lỗi thời.

Việc chuyển từ Alpha sang Integrity có thể loại bỏ một phụ thuộc phần cứng lỗi thời nhưng lại tạo ra một phụ thuộc lỗi thời khác. Máy chủ, linh kiện, giao diện lưu trữ và chuyên môn chuyên ngành phù hợp sẽ ngày càng khó tìm.

Itanium vẫn có thể phù hợp khi cơ sở đã sở hữu hạ tầng Integrity được hỗ trợ. Itanium cũng có thể phù hợp khi một sản phẩm lớp cần thiết tồn tại cho Integrity nhưng không có cho x86-64.

Đối với một dự án hiện đại hóa mới, phương án này nhìn chung nên được đánh giá như một lộ trình tương thích trung gian.

Phân tích hiệu quả kinh doanh phải giải thích tại sao chuyển sang Integrity lại phù hợp hơn so với mô phỏng Alpha, chuyển đổi OpenVMS x86 hoặc tái nền tảng HMI.

Tái nền tảng bằng OPC giữ nguyên lớp điều khiển

Việc tái nền tảng bằng OPC thay thế lớp giao diện vận hành, đồng thời giữ nguyên các bộ điều khiển INFI 90 và I/O hiện trường.

Một máy chủ truyền thông kết nối với hệ thống Bailey và cung cấp các thẻ quy trình cho nền tảng HMI hoặc SCADA hiện đại.

HMI mới xử lý màn hình, cảnh báo, xu hướng, bảo mật, lệnh vận hành, báo cáo và các dịch vụ trạm làm việc.

Phương án này loại bỏ sự phụ thuộc vào ứng dụng vận hành Symphony gốc. Đồng thời, phương án này tránh nhu cầu chạy OpenVMS Alpha trên các trạm vận hành mới.

Kiến trúc thường bao gồm:

• Các bộ điều khiển và I/O Bailey INFI 90 hiện có.

• Một giao diện truyền thông Bailey tương thích.

• Một máy chủ dữ liệu OPC DA, OPC UA hoặc máy chủ dành riêng cho nhà cung cấp.

• Một nền tảng HMI hoặc SCADA hiện đại.

• Các trạm làm việc vận hành và kỹ thuật.

• Các dịch vụ lưu trữ lịch sử, báo cáo và phân tích cảnh báo tùy chọn.

Một ví dụ triển khai thực tế được đề cập trong tài liệu nguồn đã sử dụng máy chủ OPC RoviSys cùng với GE CIMPLICITY. Hệ thống được báo cáo là đã vận hành thành công, nhưng dự án yêu cầu xây dựng lại các màn hình vận hành và logic hoạt ảnh.

Không nên hiểu ví dụ này là khuyến nghị sản phẩm tự động cho mọi hệ thống INFI 90.

Máy chủ được chọn phải hỗ trợ mạng Bailey cụ thể, các mô-đun truyền thông, thế hệ bộ điều khiển, số lượng thẻ, tốc độ cập nhật, yêu cầu dự phòng và các chức năng lệnh tại cơ sở.

Điều tương tự cũng áp dụng cho nền tảng HMI.

GE CIMPLICITY là một nền tảng HMI/SCADA doanh nghiệp khả thi. Các hệ thống khác cũng có thể phù hợp nếu cung cấp khả năng kết nối OPC, đồ họa, cảnh báo, lập trình lệnh, dự phòng, bảo mật và hỗ trợ vòng đời cần thiết.

Hình 2. Việc chuyển đổi dựa trên OPC giữ nguyên lớp điều khiển INFI 90, đồng thời thay thế môi trường vận hành Symphony cũ.

Kết nối OPC không chuyển đổi các màn hình hiện có

Máy chủ OPC cung cấp khả năng kết nối dữ liệu. Thông thường, máy chủ này không chuyển đổi các màn hình HMI cũ sang định dạng HMI mới.

Các màn hình Symphony gốc có thể chứa đồ họa tĩnh, ký hiệu động, thay đổi màu sắc, giá trị số, biểu đồ thanh, chỉ báo cảnh báo, nút điều hướng, điều khiển lệnh, xu hướng và các mẫu chức năng tùy chỉnh.

Các phần tử này phải được tái tạo trong HMI đích.

Các màn hình đơn giản có thể được vẽ lại trực tiếp. Các màn hình phức tạp có thể chứa các tập lệnh hoặc biểu thức ẩn không dễ nhận thấy ngay.

Kỹ sư phải hiểu cách mọi đối tượng hoạt ảnh nhận và xử lý dữ liệu.

Một ký hiệu van có thể không chỉ phụ thuộc vào một thẻ đầu ra. Màu sắc và vị trí của nó có thể phụ thuộc vào tín hiệu phản hồi mở, tín hiệu phản hồi đóng, trạng thái lệnh, trạng thái liên động, chất lượng liên lạc và chế độ thiết bị.

Một ký hiệu động cơ có thể sử dụng các thẻ riêng cho lệnh khởi động, tín hiệu phản hồi đang chạy, trạng thái dừng, trạng thái sự cố, điều khiển cục bộ, trạng thái bảo trì, các điều kiện cho phép và việc chặn cảnh báo.

Do đó, chỉ di chuyển phần đồ họa hiển thị có thể tạo ra một HMI trông chính xác nhưng hoạt động không đúng.

Nhóm di chuyển hệ thống phải ghi lại ý nghĩa chức năng đằng sau từng phần tử trên màn hình.

Công việc này bao gồm:

• Ánh xạ mọi đối tượng động đến nguồn dữ liệu của nó.

• Tái tạo các biểu thức hoạt ảnh.

• Xác minh việc xác nhận lệnh và bảo mật.

• Xây dựng lại điều hướng và hệ thống phân cấp màn hình.

• Tái tạo các lớp và mức độ ưu tiên của cảnh báo.

• Xác nhận đơn vị kỹ thuật và độ chính xác của số thập phân.

• Xây dựng lại các xu hướng lịch sử và thời gian thực.

• Kiểm thử các trạng thái liên lạc không hợp lệ, không chắc chắn và bị lỗi.

• Tái hiện thông báo và hướng dẫn cho người vận hành.

• Thay thế các phông chữ và ký hiệu không được hỗ trợ.

Do đó, khối lượng công việc được xác định bởi độ phức tạp của màn hình, không chỉ bởi số lượng màn hình.

HMI hiện đại không nên sao chép máy móc mọi màn hình cũ

Việc tái tạo thủ công tạo cơ hội cải thiện giao diện người vận hành.

Đồ họa HMI cũ thường sử dụng màu sáng cho thiết bị ở trạng thái bình thường, sơ đồ quy trình dày đặc, đường ống mang tính trang trí và cách chỉ báo cảnh báo không nhất quán.

Những quy ước này có thể từng hợp lý khi hệ thống ban đầu được phát triển. Tuy nhiên, chúng không phải lúc nào cũng lý tưởng đối với các thông lệ hiện nay trong phòng điều khiển.

Một dự án hiện đại hóa nên xem xét:

• Phân cấp màn hình.

• Khả năng hiển thị cảnh báo.

• Tính nhất quán trong điều hướng.

• Cách hiển thị trạng thái thiết bị.

• Việc sử dụng màu sắc.

• Khả năng truy cập xu hướng.

• Yêu cầu phản hồi của người vận hành.

• Độ phân giải màn hình và bố trí trạm làm việc.

• Khả năng tiếp cận và tính dễ đọc.

Các điều kiện vận hành bình thường nên được hiển thị một cách yên tĩnh về mặt thị giác. Màu sắc nổi bật nên dùng để xác định các trạng thái bất thường cần được chú ý.

Người vận hành phải có thể chuyển từ tổng quan nhà máy đến phân xưởng bị ảnh hưởng, mặt điều khiển thiết bị, xu hướng, lịch sử cảnh báo và màn hình chẩn đoán mà không phải điều hướng quá nhiều.

Tuy nhiên, thiết kế lại quá mức có thể tạo ra một rủi ro khác.

Người vận hành có thể đã sử dụng các màn hình ban đầu trong nhiều năm. Việc thay đổi mọi ký hiệu, màu sắc và đường dẫn điều hướng trong cùng một dự án có thể làm tăng yêu cầu đào tạo và rủi ro khi chuyển đổi.

Cách tiếp cận cân bằng vẫn giữ các mối quan hệ quy trình quen thuộc, đồng thời cải thiện cách hiển thị và điều hướng cảnh báo.

Trích xuất thẻ phải được xem là một hạng mục công việc kỹ thuật

Tài liệu nguồn nêu khả năng xuất dữ liệu thẻ Bailey sang CSV. Tài liệu không cung cấp quy trình phổ quát đã được xác nhận.

Do đó, không nên giả định rằng một lệnh xuất duy nhất sẽ tạo ra cơ sở dữ liệu HMI hoàn chỉnh và sạch.

Các nguồn thông tin về thẻ có thể bao gồm:

• Cơ sở dữ liệu cấu hình Symphony.

• Các định nghĩa màn hình hiện có.

• Cấu hình bộ điều khiển và hồ sơ kỹ thuật.

• Cơ sở dữ liệu của máy chủ giao tiếp Bailey.

• Chức năng duyệt của máy chủ OPC.

• Tệp cấu hình cảnh báo.

• Cơ sở dữ liệu lịch sử.

• Danh sách thẻ được in hoặc lưu trữ.

• Bảng tính kỹ thuật tại cơ sở.

Duyệt OPC có thể là điểm khởi đầu thực tế sau khi máy chủ thiết lập giao tiếp với hệ thống Bailey.

Nó có thể cung cấp tên thẻ, mã định danh mục, mô tả, chất lượng và giá trị hiện tại. Một số máy chủ cũng hỗ trợ xuất không gian tên đã duyệt.

Tuy nhiên, không gian tên OPC có thể không bao gồm mọi trường cần thiết cho HMI mới.

Mức độ ưu tiên của cảnh báo, giới hạn kỹ thuật, nhóm hiển thị, ghi chú của người vận hành, bảo mật lệnh và các mối quan hệ thiết bị có thể được lưu trữ ở nơi khác.

Một số máy chủ OPC cung cấp các thẻ bằng những tên được tạo tự động, khác với tên Symphony ban đầu.

Dự án nên xây dựng một danh mục thẻ được kiểm soát, chứa ít nhất:

• Tên thẻ ban đầu.

• Tên thẻ HMI mới.

• Mã định danh mục OPC.

• Mô tả.

• Kiểu dữ liệu.

• Quyền đọc hoặc ghi.

• Đơn vị kỹ thuật.

• Thông tin thu phóng.

• Giới hạn và mức độ ưu tiên của cảnh báo.

• Tốc độ cập nhật.

• Màn hình liên quan.

• Trạng thái xác thực.

• Kết quả kiểm thử.

Danh mục chính này sẽ trở thành hồ sơ đối soát giữa hệ thống cũ và hệ thống mới.

Số lượng thẻ không phải là yêu cầu giao tiếp duy nhất

Kiểm thử duyệt thành công không chứng minh rằng kiến trúc OPC có thể hỗ trợ toàn bộ HMI.

Kỹ sư phải đánh giá số lượng thẻ đang hoạt động, tốc độ cập nhật được yêu cầu, tần suất thay đổi, hoạt động cảnh báo, lưu lượng lệnh và khả năng dự phòng của máy chủ.

Một hệ thống có thể chứa hàng chục nghìn thẻ đã cấu hình. Tại một thời điểm, chỉ một phần trong số đó có thể đang hoạt động trên các màn hình của người vận hành.

Máy chủ và HMI nên được kiểm thử trong các điều kiện thực tế.

Các kiểm tra hiệu năng quan trọng bao gồm:

• Thời gian cần thiết để mở một màn hình phức tạp.

• Độ trễ giữa thay đổi tại hiện trường và hoạt ảnh trên HMI.

• Phân phối cảnh báo trong các đợt sự kiện dồn dập.

• Thu thập xu hướng ở tốc độ lấy mẫu yêu cầu.

• Thời gian thực thi lệnh và nhận phản hồi.

• Khôi phục sau khi mạng bị gián đoạn.

• Chuyển đổi dự phòng giữa các máy chủ dự phòng.

• Hành vi sau khi khởi động lại bộ điều khiển.

• Trạng thái chất lượng khi giao tiếp bị lỗi.

• Mức sử dụng CPU, bộ nhớ và mạng.

Các lệnh cần được đặc biệt chú ý.

Đọc giá trị qua OPC có thể tương đối đơn giản. Ghi giá trị một cách an toàn đòi hỏi kiểm soát truy cập, xác thực lệnh, xác nhận phản hồi và xử lý đúng các lỗi giao tiếp.

Nhóm nên kiểm thử mọi loại lệnh của người vận hành, không chỉ một thẻ đại diện.

ABB Symphony Plus cung cấp lộ trình phát triển rộng hơn

Thay thế OPC không phải là lựa chọn duy nhất đối với một hệ thống Bailey đang được lắp đặt.

ABB tiếp tục định vị Symphony Plus là nền tảng phát triển cho các hệ thống Bailey, INFI 90, Harmony Rack và Symphony cũ hơn.

Việc hiện đại hóa ABB theo từng giai đoạn có thể bảo toàn một số phần của kiến trúc điều khiển và I/O hiện có, đồng thời đưa vào các thành phần vận hành, kỹ thuật, mạng, bộ điều khiển hoặc I/O mới hơn.

Lựa chọn này có thể hấp dẫn khi tổ chức muốn có chiến lược vòng đời do nhà cung cấp hỗ trợ thay vì thay thế HMI độc lập.

Dự án có thể hiện đại hóa môi trường vận hành trước. Bộ điều khiển và I/O có thể tiếp tục được sử dụng cho đến khi vòng đời hoặc giá trị vận hành của chúng đủ để biện minh cho việc thay thế.

Các giai đoạn sau có thể xử lý phần liên lạc, bộ điều khiển, công cụ kỹ thuật và giao diện hiện trường.

Kiến trúc chuyển đổi chính xác phụ thuộc vào thế hệ hệ thống được lắp đặt.

Các hệ thống Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony và Symphony Plus không sử dụng cùng một giao diện.

Tên mô-đun và thuật ngữ mạng phải được xác minh từ bản vẽ tại cơ sở và danh mục phần cứng.

Các tổ chức đang duy trì lớp điều khiển hiện có cũng có thể xem xét các linh kiện ABB Bailey INFI 90 và Network 90 hiện có khi lập kế hoạch dự phòng, hỗ trợ vòng đời và hiện đại hóa theo từng giai đoạn.

Liên kết nội bộ này có liên quan vì các dự án hiện đại hóa thường yêu cầu hệ thống cũ tiếp tục hoạt động trong giai đoạn kỹ thuật, kiểm thử và chuyển đổi theo từng bước.

Duy trì các bộ điều khiển dự phòng, mô-đun liên lạc, bộ nguồn và mô-đun I/O phù hợp có thể giảm rủi ro trong quá trình chuyển đổi đó.

Có thể sử dụng HMI tùy chỉnh hoặc mã nguồn mở, nhưng cần có trách nhiệm sở hữu

Có thể phát triển HMI tùy chỉnh bằng các framework phần mềm mã nguồn mở hoặc thương mại.

Tài liệu nguồn đề cập đến một máy chủ chạy trên VMS cùng một máy khách hiện đại dựa trên Qt. Các kiến trúc kiểu này có thể tách kết nối dữ liệu phía máy chủ khỏi máy khách vận hành.

Lựa chọn này có thể mang lại sự linh hoạt và tránh phụ thuộc vào một nhà cung cấp HMI duy nhất.

Lựa chọn này cũng có thể trở thành một cam kết phát triển phần mềm dài hạn.

Tổ chức phải sở hữu hoặc duy trì:

• Máy chủ liên lạc.

• Cơ sở dữ liệu tag.

• Ứng dụng máy khách.

• Framework đồ họa.

• Xử lý cảnh báo.

• Tích hợp hệ thống lưu trữ dữ liệu lịch sử.

• Xác thực người dùng.

• Cập nhật an ninh mạng.

• Triển khai và kiểm soát phiên bản.

• Tài liệu và đào tạo.

Qt, Python, C++, các công nghệ web hoặc những framework khác đều có thể tạo ra các giao diện công nghiệp đủ năng lực. Khó khăn không nằm ở việc vẽ đồ họa quy trình.

Khó khăn nằm ở việc tạo ra một hệ thống vận hành đáng tin cậy, hoạt động chính xác khi xảy ra lỗi liên lạc, khởi động lại máy chủ, tình trạng tràn ngập cảnh báo, thay đổi người dùng và các điều kiện bất thường của nhà máy.

Chỉ nên lựa chọn nền tảng tùy chỉnh khi tổ chức có đội ngũ kỹ thuật có khả năng duy trì lâu dài hoặc một đơn vị tích hợp đáng tin cậy trong dài hạn.

Giấy phép có thể quyết định một phương án kỹ thuật có khả thi hay không

Phần mềm công nghiệp kế thừa thường sử dụng các cơ chế cấp phép gắn với mã định danh phần cứng, địa chỉ Ethernet, cơ sở dữ liệu giấy phép, khóa bảo mật hoặc khóa ủy quyền do nhà cung cấp cấp.

Một hệ thống được nhân bản có thể khởi động chính xác nhưng từ chối khởi chạy ứng dụng Symphony vì danh tính phần cứng ảo đã thay đổi.

Danh mục di trú phải bao gồm:

• Giấy phép hệ điều hành OpenVMS.

• Giấy phép ứng dụng Bailey Symphony.

• Giấy phép cơ sở dữ liệu.

• Giấy phép mạng và truyền thông.

• Giấy phép trình mô phỏng.

• Giấy phép HMI và số lượng điểm OPC.

• Giấy phép hệ thống lưu trữ dữ liệu lịch sử.

• Các tùy chọn dự phòng.

• Giấy phép máy khách kỹ thuật.

• Giấy phép máy khách thời gian chạy.

Cần có xác nhận bằng văn bản trước khi lựa chọn nền tảng cuối cùng.

Khả năng tương thích kỹ thuật nhưng không có giấy phép hợp pháp thì không tạo ra một giải pháp có thể triển khai.

An ninh mạng phải được thiết kế ngay từ đầu cho hệ thống thay thế

Các hệ thống AlphaStation cũ thường được lắp đặt trước khi các thực hành an ninh mạng công nghiệp hiện đại trở thành tiêu chuẩn.

Chúng có thể hoạt động trên các mạng cô lập với quyền truy cập từ xa hạn chế. Việc thay thế chúng bằng máy chủ Windows, máy khách SCADA hiện đại, máy chủ OPC và hạ tầng Ethernet sẽ làm thay đổi bề mặt tấn công.

Kiến trúc mới nên xác định các vùng mạng riêng biệt cho mạng điều khiển, máy chủ, kỹ thuật và doanh nghiệp.

Tường lửa chỉ nên cho phép các đường truyền thông cần thiết. Quyền truy cập từ xa nên sử dụng cơ chế xác thực và ghi lại hoạt động được quản lý.

Tài khoản vận hành nên tuân theo quyền hạn dựa trên vai trò. Các chức năng kỹ thuật không nên khả dụng từ mọi máy khách HMI.

Quyền ghi OPC nên bị giới hạn ở các thẻ và trạm thực sự cần quyền này.

Thiết kế cũng nên giải quyết các vấn đề sau:

• Cập nhật bản vá hệ điều hành.

• Phần mềm chống vi-rút hoặc kiểm soát ứng dụng.

• Sao lưu và khôi phục.

• Đồng bộ hóa thời gian.

• Ghi nhật ký bảo mật.

• Kiểm soát phương tiện lưu trữ di động.

• Hỗ trợ từ xa của nhà cung cấp.

• Quản lý chứng chỉ cho OPC UA.

• Quản lý vòng đời tài khoản.

Các biện pháp kiểm soát an ninh mạng không được ngăn cản nhân viên vận hành ứng phó trong các sự cố của nhà máy. Thiết kế phải cân bằng giữa bảo vệ, tính sẵn sàng và hoạt động mang tính xác định.

Việc di trú nên bắt đầu bằng danh mục dựa trên bằng chứng

Trước khi lựa chọn phương án, các kỹ sư nên lập tài liệu chi tiết về hệ thống hiện tại.

Danh mục phải bao gồm cả bốn AlphaStation và xác định liệu cấu hình của chúng có thực sự giống hệt nhau hay không.

Ghi chú:

• Mẫu AlphaStation và cấu hình bộ xử lý.

• Dung lượng bộ nhớ.

• Loại đĩa và các ổ đĩa logic.

• Phiên bản OpenVMS và mức bản vá.

• Phiên bản phần mềm Bailey đã cài đặt.

• Các sản phẩm phân lớp và cơ sở dữ liệu.

• Phần cứng đồ họa và độ phân giải màn hình.

• Bộ điều hợp mạng.

• Giao diện nối tiếp.

• Phần cứng truyền thông Bailey.

• Tên và địa chỉ nút.

• Quy trình lệnh khởi động.

• Tệp giấy phép.

• Quy trình dự phòng.

• Dự phòng trạm vận hành.

• Máy in được kết nối và thiết bị bên ngoài.

• Lưu giữ dữ liệu lịch sử và dữ liệu cảnh báo.

Nhóm cũng nên thu thập ảnh chụp màn hình của mọi màn hình hiển thị. Khi có thể, hãy ghi lại các trạng thái động.

Ghi lại các trạng thái bình thường, dừng, đang chạy, có cảnh báo, bị vô hiệu hóa, cục bộ, thủ công, tự động và mất truyền thông.

Bằng chứng này rất cần thiết khi kiểm thử các màn hình mới.

Bắt buộc phải có hệ thống kiểm thử trên bàn

Không nên lần đầu kiểm thử bất kỳ lộ trình hiện đại hóa nào trên hệ thống sản xuất đang vận hành.

Môi trường kiểm thử nên tái tạo đủ kiến trúc đã cài đặt để xác thực chức năng truyền thông và vận hành.

Đối với một dự án giả lập, môi trường kiểm thử phải chứa một môi trường OpenVMS Alpha được sao chép và cấu hình trình giả lập được đề xuất.

Đối với một dự án OPC, hệ thống nên bao gồm máy chủ truyền thông được chọn, phần mềm HMI, đồ họa đại diện và quyền truy cập vào một nút kiểm thử Bailey an toàn hoặc nguồn dữ liệu mô phỏng.

Kiểm thử trên bàn nên xác minh:

• Khởi động hệ thống và khởi chạy ứng dụng.

• Truyền thông với hệ thống Bailey.

• Tổng số thẻ có thể truy cập.

• Thao tác đọc và ghi.

• Chia tỷ lệ thẻ và đơn vị kỹ thuật.

• Tạo và xác nhận cảnh báo.

• Thu thập xu hướng.

• Hoạt ảnh hiển thị.

• Bảo mật lệnh.

• Chức năng máy in và báo cáo.

• Ứng xử khi máy chủ khởi động lại.

• Ứng xử khi mạng gặp sự cố.

• Tính dự phòng và chuyển đổi dự phòng.

• Khôi phục bản sao lưu.

• Thời gian phản hồi của người vận hành.

Kết quả kiểm thử nên được đại diện vận hành, kỹ thuật điều khiển, bảo trì và an ninh mạng chứng kiến.

Vận hành song song giảm rủi ro chuyển đổi

Các AlphaStation ban đầu nên tiếp tục khả dụng trong giai đoạn triển khai ban đầu của hệ thống thay thế.

HMI mới có thể vận hành song song trong khi các kỹ sư so sánh giá trị, cảnh báo, xu hướng và lệnh.

Vận hành song song cho phép xác định các điểm không khớp trước khi loại bỏ trạm cũ.

Nhóm nên đối chiếu:

• Giá trị quy trình được hiển thị.

• Chỉ báo trạng thái.

• Mức độ ưu tiên cảnh báo.

• Dấu thời gian cảnh báo.

• Kết quả lệnh.

• Giá trị xu hướng.

• Chế độ thiết bị.

• Chất lượng truyền thông.

• Quyền bảo mật.

Không phải mọi khác biệt đều là lỗi. Hệ thống mới có thể sử dụng cách chia tỷ lệ hoặc cách hiển thị cảnh báo được cải tiến.

Mọi khác biệt vẫn phải được giải thích và phê duyệt.

Các trạm cũ phải vẫn có thể khôi phục cho đến khi HMI mới vượt qua bài kiểm tra nghiệm thu tại hiện trường có chứng kiến và một giai đoạn vận hành được thống nhất.

Lựa chọn phương án di chuyển phù hợp

Chọn phương án giả lập Alpha khi:

Ứng dụng Symphony hiện tại phải được giữ nguyên. Không có mã nguồn. Đồ họa vận hành phức tạp. Cần giảm thiểu việc đào tạo lại. Giao diện truyền thông Bailey có thể được kiến trúc trình giả lập hỗ trợ.

Chọn phương án di chuyển OpenVMS x86 khi:

Các ứng dụng bắt buộc đã có sẵn cho x86-64 hoặc có thể được xây dựng lại. Mã nguồn và kiến thức kỹ thuật vẫn còn. Tổ chức muốn duy trì OpenVMS đồng thời chuyển sang một môi trường x86 được hỗ trợ.

Chọn tái nền tảng OPC khi:

Bộ điều khiển và các lớp I/O của INFI 90 vẫn đáng tin cậy. Tổ chức muốn có một nền tảng HMI hiện đại. Có sẵn nguồn lực kỹ thuật để xây dựng lại và xác thực màn hình, cảnh báo, tag và logic lệnh.

Chọn lộ trình tiến hóa ABB khi:

Tổ chức muốn có một chương trình hiện đại hóa rộng hơn được nhà cung cấp hỗ trợ. Các giai đoạn tương lai có thể bao gồm hệ thống vận hành, công cụ kỹ thuật, giao diện mạng, bộ điều khiển và I/O.

Chọn HMI tùy chỉnh khi:

Tổ chức có các yêu cầu chuyên biệt và có thể hỗ trợ việc phát triển phần mềm, kiểm thử, an ninh mạng và bảo trì vòng đời trong dài hạn.

Tạm thời duy trì hệ thống hiện có khi:

Các giao diện di chuyển vẫn chưa rõ ràng. Bản sao lưu chưa đầy đủ. Vấn đề cấp phép chưa được giải quyết. Cơ sở dữ liệu tag không có sẵn. Việc kiểm thử trên bàn chưa thể tái tạo đường truyền thông Bailey.

Kế hoạch hiện đại hóa thực tế theo từng giai đoạn

Giai đoạn 1: Bảo toàn môi trường hiện có.

Tạo bản sao lưu image đã xác minh cho từng AlphaStation. Ghi lại thông tin phần cứng, phần mềm, mạng, cấp phép và khởi động. Kiểm thử việc khôi phục ở mọi nơi có thể.

Giai đoạn 2: Xác định kiến trúc truyền thông.

Ghi lại chính xác cách mỗi trạm Symphony giao tiếp với INFI 90. Xác nhận liệu giao diện này có thể được mô phỏng hoặc thay thế bằng máy chủ được hỗ trợ hay không.

Giai đoạn 3: Xây dựng bản thử nghiệm khả thi.

Kiểm thử một trạm đã sao chép trên trình mô phỏng Alpha hoặc kết nối một máy chủ OPC với một nút Bailey đại diện.

Giai đoạn 4: Tạo danh mục tag chính.

Đối chiếu các tag của bộ điều khiển, mã định danh mục OPC, đơn vị kỹ thuật, lệnh, cảnh báo và cách sử dụng màn hình.

Giai đoạn 5: Xây dựng lại các màn hình đại diện.

Chọn một số màn hình có các yêu cầu khác nhau về hoạt ảnh, cảnh báo, lệnh và xu hướng.

Giai đoạn 6: Hoàn tất nghiệm thu trên bàn kiểm thử.

Kiểm thử việc tải đầy đủ các tag, lỗi truyền thông, khởi động lại máy chủ, các đợt cảnh báo dồn dập, hành vi lệnh và khôi phục bản sao lưu.

Giai đoạn 7: Triển khai song song.

Vận hành đồng thời HMI mới và cũ. So sánh các giá trị và phản hồi của người vận hành.

Giai đoạn 8: Thực hiện chuyển đổi có giám sát.

Sử dụng quy trình kiểm thử đã được phê duyệt. Giữ các AlphaStation sẵn sàng làm phương án dự phòng.

Giai đoạn 9: Dần loại bỏ phần cứng cũ.

Không được hủy các image, bản ghi cấu hình, giấy phép hoặc phần cứng gốc cho đến khi hoàn tất nghiệm thu dài hạn.

Câu hỏi thường gặp

Có thể sao chép trực tiếp ổ đĩa của OpenVMS AlphaStation sang một PC hiện đại không?

Không. Image này chứa mã máy Alpha và yêu cầu phần cứng tương thích với Alpha. Một PC x86 hiện đại không thể khởi động trực tiếp image này. Image phải được khôi phục trên phần cứng Alpha tương thích hoặc trình mô phỏng Alpha.

VMware hoặc VirtualBox có thể chạy OpenVMS không?

Chúng có thể chạy các bản phát hành OpenVMS x86-64 được hỗ trợ. Chúng không chuyển đổi một bản cài đặt OpenVMS Alpha cũ thành ứng dụng x86. OpenVMS Alpha yêu cầu trình mô phỏng Alpha.

Có thể bảo toàn các màn hình Symphony nguyên bản không?

Thông thường có thể bảo toàn chúng khi toàn bộ môi trường Alpha chạy trong một trình mô phỏng tương thích. Khi chuyển sang một nền tảng HMI khác, thường phải tạo lại chúng thủ công.

Máy chủ OPC có tự động xuất mọi thẻ Bailey không?

Không nhất thiết. Việc duyệt OPC có thể cung cấp một không gian tên hữu ích, nhưng cấu hình cảnh báo, mối quan hệ giữa các màn hình, lệnh, mô tả và siêu dữ liệu kỹ thuật có thể cần được trích xuất và đối chiếu bổ sung.

GE CIMPLICITY có phải là HMI thay thế duy nhất không?

Không. Đây là một nền tảng khả thi và xuất hiện trong ví dụ thực tế được cung cấp cùng nguồn. Lựa chọn cuối cùng nên phụ thuộc vào khả năng hỗ trợ truyền thông, dự phòng, cấp phép, an ninh mạng, nguồn lực kỹ thuật và yêu cầu của người vận hành.

Việc chuyển đổi từ Alpha sang Itanium còn đáng thực hiện không?

Điều này có thể hợp lý khi phần mềm cần thiết chỉ có sẵn cho các hệ thống Integrity hoặc khi hạ tầng Integrity hiện có đã được hỗ trợ. Nhìn chung, đây là lộ trình chuyển tiếp hơn là chiến lược hiện đại hóa dài hạn tối ưu.

Các bộ điều khiển và I/O INFI 90 có thể tiếp tục được lắp đặt không?

Có, khi chúng vẫn đáng tin cậy và kiến trúc truyền thông được lựa chọn hỗ trợ chúng. Việc hiện đại hóa HMI có thể được hoàn tất riêng, không phụ thuộc vào việc thay thế bộ điều khiển và I/O.

Có nên tháo bỏ ngay các AlphaStation cũ sau khi chuyển đổi không?

Không. Chúng nên tiếp tục sẵn sàng làm phương án dự phòng đã được kiểm thử cho đến khi môi trường vận hành mới vượt qua nghiệm thu chức năng, hiệu năng và vận hành.

Giải pháp đúng phụ thuộc vào những gì cần được bảo toàn

Sai lầm kỹ thuật chính trong nhiều kế hoạch HMI cũ là coi trạm vận hành như một máy tính thông thường.

Một AlphaStation chạy OpenVMS Alpha và Bailey Symphony là một môi trường phần cứng và phần mềm hoàn chỉnh. Kiến trúc bộ xử lý, hệ điều hành, giao diện truyền thông, tệp nhị phân ứng dụng, giấy phép, đồ họa và các kết nối với hệ thống điều khiển phụ thuộc lẫn nhau.

Sao chép ổ đĩa bảo toàn dữ liệu. Việc này không chuyển đổi môi trường đó sang một kiến trúc khác.

Mô phỏng Alpha là lộ trình trực tiếp nhất khi cần duy trì nguyên trạng toàn bộ hệ thống Symphony.

OpenVMS x86-64 cung cấp lộ trình chuyển sang hệ điều hành hiện đại khi các ứng dụng có thể được di chuyển hoặc xây dựng lại.

Tái nền tảng OPC là một lộ trình thực tế khi lớp điều khiển INFI 90 vẫn còn giá trị nhưng lớp vận hành cần được thay thế.

Việc chuyển đổi sang ABB Symphony Plus có thể cung cấp chiến lược theo từng giai đoạn rộng hơn khi tổ chức muốn hiện đại hóa vượt ra ngoài HMI.

Quyết định cuối cùng nên dựa trên việc kiểm kê đã được xác minh, nghiên cứu giao diện truyền thông, rà soát giấy phép, thử nghiệm proof of concept, kiểm thử trên bàn và nghiệm thu vận hành có chứng kiến.

Không có phương án thay thế nào hoàn toàn không tốn công sức. Tuy nhiên, có một số lộ trình chuyển đổi được kiểm soát, giúp bảo vệ khoản đầu tư hiện có vào hệ thống điều khiển quy trình đồng thời loại bỏ sự phụ thuộc vào phần cứng AlphaStation đã cũ.