Một liên kết Modbus RTU giữa CompactLogix và DeltaV chỉ trao đổi vài chục giá trị nhưng vẫn có thể trở thành một trong những giao diện khó dự đoán nhất trong nhà máy. Giao thức thì đơn giản; ranh giới kỹ thuật thì không. Hầu hết sự cố bắt đầu trước khi đấu dây, khi không đội nào xác định rõ ai gửi yêu cầu, ai sở hữu lệnh, địa chỉ được biểu diễn như thế nào, hoặc mỗi hệ thống phải xử lý dữ liệu cũ ra sao.

Một tích hợp nối tiếp ổn định cần có một bên khởi tạo yêu cầu, hợp đồng thanh ghi được phê duyệt, các trạng thái chất lượng rõ ràng và một đoạn RS-485 được xây dựng đúng cách.

Quyết định thiết kế đầu tiên là kiến trúc. DeltaV có thể giao tiếp qua giao diện nối tiếp, trong khi CompactLogix thường cần một mô-đun giao tiếp gắn trong khung hoặc một gateway bên ngoài. Tài liệu dữ liệu Giao diện nối tiếp dòng M DeltaV của Emerson nêu rõ hỗ trợ Modbus RTU và Modbus ASCII. Tuy nhiên, vẫn cần xác nhận phiên bản mô-đun, firmware bộ điều khiển, firmware gateway và cấu trúc mạng được hỗ trợ đối với hệ thống đang lắp đặt.

Chỉ định một bên khởi tạo yêu cầu cho mỗi đoạn nối tiếp

Thuật ngữ Modbus truyền thống dùng master và slave. Tài liệu hiện nay thường dùng client và server. Trên một đoạn Modbus RTU, một client khởi tạo giao dịch và các server trả lời những yêu cầu được gửi đến chúng. Hai client độc lập không thể chia sẻ an toàn cùng một đường trục hai dây vì chúng không phối hợp thời điểm truyền với nhau.

Nếu DeltaV là client, phía CompactLogix phải cung cấp dữ liệu thông qua giao diện server Modbus. Chương trình PLC ghi các giá trị đã được phê duyệt vào vùng dữ liệu của gateway; gateway trả lời các lần thăm dò của DeltaV. Nếu PLC phải khởi tạo việc đọc và ghi, hãy sử dụng một cổng hoặc đường gateway riêng. Đừng cho rằng một thiết bị được mô tả là “hỗ trợ Modbus” có thể đồng thời đảm nhiệm cả hai vai trò.

Trang thông số kỹ thuật của Tổ chức Modbus phân biệt hướng dẫn triển khai nối tiếp hiện hành với tài liệu năm 1996 đã lỗi thời. Sự phân biệt này rất quan trọng khi đặc tả dự án chỉ ghi “sử dụng Modbus” mà không xác định lớp vật lý và các quy tắc triển khai.

Coi bản đồ thanh ghi là một hợp đồng giao diện

Một bản đồ thanh ghi hữu ích không chỉ là danh sách các tham chiếu 4xxxx. Mỗi điểm nên xác định offset giao thức, tham chiếu hiển thị, mã hàm, kiểu dữ liệu, thứ tự từ, thứ tự byte, hệ số tỷ lệ, đơn vị kỹ thuật, hướng đọc hoặc ghi, phạm vi hợp lệ, chu kỳ cập nhật, bên sở hữu nguồn và cách xử lý khi xảy ra lỗi. Hãy thêm số phiên bản và hồ sơ phê duyệt để cả hai hệ thống triển khai cùng một bản đồ.

Việc định địa chỉ cần được kiểm tra riêng. Một số công cụ cấu hình hiển thị thanh ghi giữ 40001 nhưng truyền offset bằng không. Một số công cụ khác yêu cầu trực tiếp offset bắt đầu từ không. Bản đồ ghi nhận cả hai dạng sẽ ngăn lỗi lệch một thanh ghi quen thuộc. Hãy kiểm tra bằng một mẫu dễ nhận biết trước khi nạp các giá trị vận hành.

Các giá trị nhiều thanh ghi cũng cần được xử lý rõ ràng tương tự. Một REAL 32 bit chiếm hai thanh ghi 16 bit, nhưng thứ tự thanh ghi có thể khác nhau giữa các sản phẩm. Hãy kiểm tra các mẫu bit đã biết thay vì dựa vào những nhãn như “big endian”, vì các nhóm đôi khi sử dụng thuật ngữ này theo những cách khác nhau. Số nguyên có dấu, số nguyên không dấu, cách đóng gói Boolean và các giá trị số nguyên có tỷ lệ cũng cần có quy tắc chuyển đổi được lập tài liệu.

Tách biệt lệnh, trạng thái và xác nhận

Không bao giờ để lệnh ghi từ DCS tác động trực tiếp lên một đầu ra vật lý. Hãy ghi lệnh vào vùng đệm bên trong CompactLogix. PLC phải xác thực chế độ, điều kiện cho phép, phạm vi, trình tự, độ mới và quyền sở hữu trước khi thay đổi trạng thái được điều khiển. Sau đó, PLC phải trả về trạng thái được chấp nhận, trạng thái bị từ chối hoặc mã lý do.

Cơ chế bắt tay lệnh đặc biệt hữu ích cho các thao tác khởi động, dừng, đặt giá trị và đặt lại. Một số thứ tự hoặc bit yêu cầu được đảo trạng thái cho phép bên nhận phân biệt yêu cầu mới với giá trị còn lại trong thanh ghi. Phản hồi xác nhận nên cho biết số thứ tự đã xử lý và trạng thái kết quả. Điều này ngăn việc khôi phục giao tiếp phát lại một lệnh cũ.

Xây dựng lớp RS-485 phù hợp với nhà máy thực tế

Hãy sử dụng đường trục nối chuỗi thay vì cấu trúc hình sao. Chỉ kết thúc hai đầu vật lý, giữ các nhánh rẽ ngắn, duy trì đúng cực tính dây dẫn và đặt điện trở phân cực tại một vị trí được kiểm soát theo hướng dẫn sử dụng thiết bị. Việc nối đất lớp chống nhiễu phải tuân theo thiết kế nối đất của cơ sở và hướng dẫn của thiết bị; các kết nối tùy tiện có thể tạo ra vấn đề điện áp chế độ chung thay vì khắc phục chúng.

Mọi nút phải dùng cùng tốc độ baud, parity, số bit dừng và chế độ đóng khung. Modbus RTU và Modbus ASCII không thể cùng tồn tại trên một đoạn mạng. DF1 cũng không thể đơn giản được trộn vào đường trục Modbus. Một gateway chuyển đổi giao thức tạo ra hai mạng riêng biệt, với thời gian, chẩn đoán và trách nhiệm riêng.

Thời gian thăm dò cần có ngân sách rõ ràng. Hãy tính độ dài yêu cầu, độ dài phản hồi dự kiến, tốc độ baud, thời gian xử lý của server, khoảng trễ giữa các khung, số lần thử lại và thời gian chờ. Khi phù hợp, hãy nhóm các thanh ghi liên tiếp. Một server im lặng không nên buộc mọi điểm đang hoạt động bình thường phải chờ qua nhiều lần thử lại kéo dài. Hãy ghi nhận thời gian quét trong điều kiện bình thường và khi một server bị ngắt kết nối.

Cung cấp chất lượng cùng với mỗi khối giá trị

Một con số có vẻ đáng tin có thể nguy hiểm hơn một lỗi rõ ràng. Mỗi khối trao đổi nên bao gồm trạng thái sức khỏe giao tiếp, thời điểm thành công gần nhất, độ tuổi dữ liệu và ngưỡng dữ liệu cũ được xác định trước. Bên sử dụng phải biết giá trị là hiện hành, được giữ lại, được thay thế hay không hợp lệ.

Giá trị dự phòng phụ thuộc vào rủi ro của quy trình. Một số giá trị trạng thái có thể được xóa khi mất kết nối. Các phép đo khác có thể được giữ lại để người vận hành tham khảo nhưng bị chặn khỏi điều khiển tự động. Lệnh có thể cần chuyển sang trạng thái an toàn khi lỗi, giữ nguyên hoặc chuyển quyền điều khiển về cục bộ. Những quyết định này phải thuộc về phân tích mối nguy, không phải mặc định của gateway.

Chạy thử từ đường truyền đến tác động của quy trình

Bắt đầu với mạng được cô lập khỏi các lệnh vận hành. Xác minh cực tính, kết thúc đường truyền, phân cực và cài đặt nối tiếp. Đọc một khối chẩn đoán nhỏ, sau đó kiểm tra các mẫu số nguyên và số thực đã biết. Xác nhận căn chỉnh địa chỉ và thứ tự từ. Đo thời gian quét bình thường, chủ động tạo thời gian chờ và xác nhận trạng thái dữ liệu cũ xuất hiện tại nơi người vận hành và logic có thể nhìn thấy.

Tiếp theo, kiểm tra từng lệnh qua toàn bộ đường đi: yêu cầu từ DCS, truyền qua gateway, xác thực của PLC, tác động đầu ra, phản hồi và xác nhận. Bao gồm các yêu cầu bị từ chối, giá trị ngoài phạm vi, mất giao tiếp trong khi giao dịch, việc tắt bật nguồn và quá trình khôi phục. Đọc thành công dữ liệu thực tế không có nghĩa là giao diện điều khiển đã được nghiệm thu.

Phần cứng giao diện liên quan được tập hợp trong bộ sưu tập ProSoft. Các thiết bị hệ thống máy chủ tổng quát hơn xuất hiện trong DCS và hệ thống điều khiển. Việc lựa chọn nên dựa trên các yêu cầu về bộ điều khiển, firmware, cổng, cách ly và môi trường được hỗ trợ, thay vì chỉ dựa vào tên giao thức.

Góc nhìn kỹ thuật

Modbus RTU vẫn hữu ích cho việc trao đổi dữ liệu có giới hạn và thay đổi chậm. Điểm yếu của nó là không có ngữ cảnh ngữ nghĩa tích hợp. Giao thức không thể cho bên nhận biết rằng một thanh ghi đã cũ, một lệnh không an toàn hoặc hệ số tỷ lệ đã thay đổi sau bảo trì. Những cơ chế bảo vệ đó phải được thiết kế vào hợp đồng thanh ghi và logic ứng dụng.

Vì vậy, giao diện tốt nhất không phải là giao diện có bản đồ lớn nhất. Đó là giao diện mà quyền sở hữu, thời gian, chất lượng, phương án dự phòng và bằng chứng kiểm thử vẫn dễ hiểu nhiều năm sau. Điều đó biến một kết nối nối tiếp đơn giản thành một ranh giới hệ thống điều khiển dễ bảo trì.