Hướng dẫn nâng cấp firmware 1756-L73: Quyết định giữa v19 và v21/v31

Thay thế một bộ điều khiển 1756-L73 bị hỏng và hiện đại hóa firmware của nó là hai công việc kỹ thuật khác nhau. Thay thế khẩn cấp nhằm khôi phục một ứng dụng đã biết với phạm vi thay đổi nhỏ nhất có thể. Việc di chuyển thay đổi phiên bản bộ điều khiển, định dạng dự án, công cụ kỹ thuật, và có thể cả hành vi hoặc trạng thái hỗ trợ của các thành phần được kết nối. Kết hợp hai công việc này trong một sự cố mất điện ngoài kế hoạch sẽ làm tăng rủi ro đúng vào lúc nhà máy có ít thời gian nhất để xử lý.

Quyết định nên bắt đầu từ mục tiêu bảo trì, không phải từ việc so sánh ba số phiên bản firmware. Hãy xác nhận mã sản phẩm và dòng bộ điều khiển đang lắp đặt, firmware hiện tại, phiên bản dự án, phần mềm kỹ thuật hiện có, bản sao lưu đã xác thực, các mô-đun chassis, mạng, đường truyền HMI hoặc OPC, motion, các tag được tạo và nhận, cùng các lệnh message. Firmware chỉ là một trong nhiều yếu tố phụ thuộc của hệ thống đó.

Bộ điều khiển thay thế phải phù hợp với dự án và kiến trúc xung quanh, không chỉ với mã sản phẩm in ở mặt trước.

Chọn phạm vi trước khi chọn phiên bản

Khôi phục khẩn cấp

Khi một bộ điều khiển sản xuất ổn định bị hỏng, khôi phục cùng phiên bản firmware chính và phiên bản dự án tương thích thường là phương án có ít thay đổi nhất. Cách này tránh chuyển đổi ứng dụng trong quá trình khắc phục sự cố và giữ nguyên các mối quan hệ đã biết giữa bộ điều khiển, HMI, hệ thống truyền thông và các mô-đun đang lắp đặt. “Cùng phiên bản” vẫn cần được xác minh: hãy xác nhận gói firmware chính xác hỗ trợ danh tính của bộ điều khiển và phần mềm hiện có có thể mở dự án gốc.

Di chuyển firmware theo kế hoạch

Việc di chuyển theo kế hoạch có thể giải quyết vòng đời của máy trạm kỹ thuật, các bất thường đã được ghi nhận liên quan đến ứng dụng, chính sách hỗ trợ, tiêu chuẩn hóa hoặc nhu cầu khôi phục dự án. Công việc này cần có gói thay đổi, đánh giá tính tương thích, kế hoạch dừng máy, các bài kiểm tra nghiệm thu và nguồn lực để quay lui. Một bộ điều khiển nạp firmware thành công chưa chứng minh rằng hệ thống điều khiển hoạt động đúng.

Sử dụng tài liệu của Rockwell làm bằng chứng theo từng phiên bản

Ghi chú phát hành ControlLogix Revision 19 của Rockwell nêu rõ 1756-L73 và xác định môi trường RSLogix 5000 liên quan, các phiên bản firmware được hỗ trợ, các bước chuẩn bị và những bất thường đã biết hoặc đã được khắc phục. Đây là cơ sở phù hợp để đánh giá một ứng dụng phiên bản 19, không phải bảng phiên bản chung được sao chép từ nền tảng khác.

Ghi chú phát hành ControlLogix Revision 21 đề cập đến thế hệ Studio 5000 đầu tiên cùng các cải tiến, hạn chế và bất thường theo từng phiên bản. Nhà máy cân nhắc phiên bản 21 nên đối chiếu các chi tiết đó với các tính năng và mô-đun thực tế của dự án, thay vì mặc định rằng phiên bản mới hơn luôn an toàn hơn.

Với mọi phiên bản đích mới hơn, bao gồm phiên bản 31, hãy xác minh mã sản phẩm, dòng, firmware, phiên bản Studio 5000, hệ điều hành, hồ sơ mô-đun và phần mềm liên quan chính xác trong Product Compatibility and Download Center của Rockwell tại thời điểm thực hiện. Không nên coi tuyên bố “L73 hỗ trợ v31” là một khẳng định chung tách rời khỏi dòng phần cứng và các tổ hợp phần mềm.

Firmware và bộ nhớ vật lý là hai thuộc tính khác nhau

Thay đổi firmware không lắp thêm bộ nhớ vật lý cho 1756-L73. Dung lượng bộ điều khiển là thuộc tính phần cứng được quy định theo mã sản phẩm và dòng. Tuy nhiên, mức sử dụng bộ nhớ của dự án có thể thay đổi sau khi chuyển đổi vì lệnh, tag, cấu trúc truyền thông, tài liệu và các dịch vụ firmware có thể được biểu diễn khác đi.

Sử dụng phần mềm kỹ thuật đích để ước tính dự án sau chuyển đổi, sau đó duy trì khoảng dự phòng vận hành cho các chỉnh sửa trực tuyến và thay đổi trong tương lai. Nên sử dụng Tài liệu hướng dẫn sử dụng bộ điều khiển ControlLogix 5570 và 5560 chính thức cho các yêu cầu về phần cứng, lưu trữ, lắp đặt và vận hành. Tránh các bảng không chính thức gán dung lượng bộ nhớ vật lý khác nhau cho cùng một bộ điều khiển ở các phiên bản firmware khác nhau.

Lập danh mục tính tương thích

Bắt đầu bằng danh mục chassis và mạng. Ghi lại mã sản phẩm, dòng và firmware của bộ điều khiển; các mô-đun truyền thông và mô-đun chuyên dụng; firmware mô-đun; electronic keying; bộ điều hợp I/O từ xa; trục motion; các mối quan hệ an toàn; biến tần; và cấu hình mạng. Bao gồm các công cụ lập lịch và cấu hình DeviceNet hoặc ControlNet nếu những mạng cũ này vẫn đang được sử dụng.

Tiếp theo, lập sơ đồ chuỗi phần mềm: phiên bản RSLogix 5000 hoặc Studio 5000 gốc, các thành phần FactoryTalk Linx hoặc RSLinx, phiên bản HMI hoặc SCADA, máy chủ OPC, hồ sơ add-on, tệp EDS, công cụ biến tần và mọi tiện ích của OEM. Phiên bản bộ điều khiển không tự quyết định việc mọi HMI có phải nâng cấp hay không. Tính tương thích phụ thuộc vào trình điều khiển truyền thông, tập tính năng và tổ hợp được hỗ trợ thực tế.

Cuối cùng, lập sơ đồ các giao diện ứng dụng. Xác định các tag được tạo và nhận, lệnh MSG, các rack từ xa, thiết bị EtherNet/IP của bên thứ ba, motion, đồng bộ thời gian, hệ thống lưu trữ dữ liệu lịch sử, hệ thống batch và các liên động bên ngoài. Bộ sưu tập Allen-Bradley ControlLogix giúp xác định các thành phần nền tảng, trong khi bộ sưu tập hệ thống PLC và PAC cung cấp bối cảnh cho các kiến trúc đa nền tảng. Hồ sơ tại nhà máy và tài liệu của nhà sản xuất vẫn là cơ sở chính thức về tính tương thích.

Duy trì phương án quay lui thực tế

Trước khi chuyển đổi, hãy lưu tệp ACD gốc bằng đúng phiên bản phần mềm ban đầu và xác nhận rằng có thể mở tệp. Ghi lại mã sản phẩm, dòng và firmware hiện tại của bộ điều khiển, các đường truyền thông, cài đặt IP hoặc mạng, trạng thái thẻ SD và cấu hình chassis. Xuất các tài sản hỗ trợ không được chứa đầy đủ trong dự án bộ điều khiển, bao gồm cấu hình HMI, mạng, biến tần và thiết bị của bên thứ ba.

Tạo một bản sao chuyển đổi riêng. Không ghi đè lên dự án duy nhất đang được biết là hoạt động tốt. Chuyển đổi tiến không đảm bảo có thể tự động chuyển đổi lùi. Vì vậy, một phương án quay lui đáng tin cậy phải bao gồm gói firmware tương thích ban đầu, phần mềm kỹ thuật ban đầu, tệp ACD gốc, thông tin xác thực hoặc giấy phép truy cập, cùng quy trình khôi phục truyền thông và các thiết bị không thuộc bộ điều khiển.

Chuyển đổi dự án là một thay đổi kỹ thuật có kiểm soát; tệp đã chuyển đổi không bao giờ được thay thế bản gốc duy nhất có thể khôi phục.

Xem xét ứng dụng đã chuyển đổi trước khi nạp firmware

Mở bản sao bằng phần mềm đích và ghi lại các thông báo chuyển đổi. Xem xét thuộc tính bộ điều khiển, hồ sơ mô-đun, electronic keying, truyền thông, motion, các lệnh add-on, kiểu dữ liệu, các mối phụ thuộc về an toàn hoặc dự phòng, cùng mọi thay đổi hành vi của lệnh được nêu trong ghi chú phát hành. Xác nhận rằng các hồ sơ add-on bắt buộc và phần mềm hỗ trợ đã được cài đặt và phê duyệt.

So sánh mức sử dụng bộ nhớ và tài nguyên của dự án. Xác minh rằng các tag, chương trình, routine, mô-đun, định nghĩa trục, đường dẫn MSG và các kết nối được tạo hoặc nhận vẫn còn đầy đủ. Nếu quá trình di chuyển đi qua nhiều phiên bản chính, cần đặc biệt chú ý đến các tính năng được bổ sung, thay đổi hoặc loại bỏ giữa hai điểm đầu cuối. Một dự án không báo lỗi chuyển đổi vẫn cần được xem xét chức năng.

Kiểm soát thao tác firmware

Sử dụng quy trình và gói firmware được Rockwell hỗ trợ cho đích đã xác minh. Đảm bảo nguồn điện ổn định và đường truyền thông tin cậy, đưa bộ điều khiển ra khỏi nhiệm vụ sản xuất, đồng thời tuân thủ các bước chuẩn bị trong ghi chú phát hành. Xác nhận cách xử lý thẻ SD và cài đặt nạp không biến đổi trước khi thực hiện; một image hoặc chế độ nạp ngoài dự kiến có thể làm hỏng trình tự khôi phục mong muốn.

Sau khi nạp firmware, đọc lại phiên bản thực tế của bộ điều khiển trước khi tải xuống. Chỉ tải dự án đúng phiên bản đích đã được xem xét. Ghi lại các cảnh báo và trạng thái bộ điều khiển. Không tuyên bố thành công chỉ vì bộ điều khiển chuyển sang chế độ Run.

Kiểm tra nghiệm thu phải bao quát toàn bộ đường truyền điều khiển

Trạng thái I/O và thiết bị

Xác minh các đầu vào và đầu ra cục bộ và từ xa, việc scale, chất lượng kênh, lỗi mô-đun, trạng thái được lệnh và hành vi an toàn khi có sự cố. Xác nhận rằng các đầu ra vẫn bị khóa cho đến khi các điều kiện khởi động của nhà máy được đáp ứng.

Truyền thông

Kiểm tra các tag được tạo và nhận, lệnh MSG, việc đọc và ghi từ HMI và SCADA, kết nối OPC, dữ liệu historian, các rack từ xa, biến tần và thiết bị của bên thứ ba. Kiểm tra cả việc cập nhật bình thường lẫn hành vi khi hết thời gian chờ hoặc khôi phục.

Trình tự, cảnh báo và motion

Thực hiện các permissive quan trọng, chuyển đổi trình tự, cảnh báo first-out, lệnh của người vận hành và hành vi reset. Khi có motion, hãy tuân theo các ghi chú phát hành Rockwell và quy trình an toàn máy áp dụng, sau đó xác thực việc homing, các giới hạn, sự phối hợp và khôi phục lỗi trong điều kiện được kiểm soát.

Chu kỳ nguồn và khả năng quay lui

Kiểm chứng hành vi khởi động mong muốn sau một chu kỳ tắt mở nguồn có kiểm soát, bao gồm các cài đặt thẻ SD hoặc bộ nhớ không biến đổi. Xác nhận rằng các tài sản quay lui đã ghi chép vẫn có sẵn và bản sao lưu cuối cùng khớp với bộ điều khiển đang chạy.

Cách định hướng giữa v19, v21 và v31

Phiên bản 19 là mục tiêu khôi phục hợp lý khi khớp với một dự án sản xuất đã được xác thực và máy trạm kỹ thuật được hỗ trợ. Tuổi đời của phiên bản là một mối lo về vòng đời, nhưng chỉ riêng tuổi đời không chứng minh rằng di chuyển khẩn cấp sẽ an toàn hơn.

Phiên bản 21 có thể được đánh giá như một bước chuyển có chủ đích sang thế hệ Studio 5000. Lợi ích và các bất thường của phiên bản này nên được đánh giá dựa trên ghi chú phát hành chính thức và việc dự án thực tế sử dụng các tính năng kết nối HMI, tài liệu, motion và truyền thông như thế nào.

Phiên bản 31 hoặc một nền tảng mới hơn khác thuộc về quyết định hiện đại hóa theo kế hoạch. Chỉ chọn phiên bản đích sau khi dữ liệu tương thích hiện tại xác nhận chính xác phần cứng L73 và phần mềm xung quanh. Khoảng cách phiên bản càng lớn thì phạm vi cần xem xét càng rộng, ngay cả khi quá trình chuyển đổi thành công.

Vì vậy, quyết định đúng phụ thuộc vào điều kiện chứ không mang tính phổ quát: khôi phục tương đương khi mục tiêu duy nhất được cho phép là khôi phục sau sự cố; di chuyển khi nhà máy có thể xác minh các yếu tố phụ thuộc, kiểm tra toàn bộ ứng dụng và quay lui. Cách tiếp cận này xem firmware là một lớp được kiểm soát của hệ thống sản xuất, thay vì một con số cần tối đa hóa.