Kiến trúc Canary Historian: collector, store and forward, Views, Axiom và cách tính license

Canary System của Canary Labs là một historian quá trình (process historian) gồm collector riêng, dịch vụ store and forward, cơ sở dữ liệu chuỗi thời gian, lớp mô hình tài sản Views và các ứng dụng đọc dữ liệu. Bài này dựa trên tài liệu của chính Canary để giải thích dữ liệu đi từ nhà máy vào Historian ra sao, từng phần nên đặt ở đâu trên mạng nhà máy, người dùng đọc dữ liệu bằng gì và Canary tính license thế nào. Historian nói chung làm gì và so sánh với FactoryTalk Historian, AVEVA PI System, Ignition: xem bài Historian là gì.

Canary System gồm những phần nào

Trang sản phẩm của Canary liệt kê các phần sau:

Dữ liệu vào bằng đường nào: collector

Kho kiến thức của Canary liệt kê mỗi loại nguồn một collector:

• OPC UA và OPC DA theo chuẩn của OPC Foundation, có deadband, chu kỳ cập nhật, metadata và biến đổi dữ liệu;
• MQTT theo đặc tả Sparkplug B 2.2 và 3.0, đọc được cả payload JSON, nhiều broker, có TLS;
• SQL: Microsoft SQL Server, MySQL và Oracle, đọc từ một bảng hàng đợi theo chu kỳ đặt trước, không đọc thẳng bảng sản xuất;
• file CSV, nhập khi file tới;
• CygNet, qua .NET API của CygNet;
• module cho Ignition của Inductive Automation, ghi tag Ignition vào một hoặc nhiều Historian của Canary;
• gRPC hoặc Web API để tự viết collector.

Canary ghi rõ collector không tính license, đi kèm Canary System. Tag chỉ vào được Historian qua một trong các collector này, nên câu hỏi thiết kế đầu tiên là dữ liệu đang nằm trong phần mềm nào của nhà máy. Với PLC Allen-Bradley, xem bài Đưa dữ liệu PLC Allen-Bradley vào Canary.

Store and forward: mất mạng thì dữ liệu đi đâu

Mỗi collector giao giá trị cho một dịch vụ store and forward, dịch vụ này đẩy tiếp tới dịch vụ store and forward đi cặp với Historian. Hai bên nói chuyện bằng gRPC; khi collector nằm ở máy khác, Canary mô tả một cổng gRPC duy nhất là 55291 giữa hai bên. Nếu mất kết nối, dịch vụ phía collector ghi đệm dữ liệu ra đĩa cục bộ. Mặc định nó ngừng ghi giá trị mới khi đĩa chỉ còn 4.000 MB trống. Khi kết nối trở lại, nó đẩy bù dữ liệu đã đệm vào Historian rồi xóa bộ đệm. Dịch vụ này cũng theo dõi kết nối và báo cho người quản trị khi một DataSet ngừng nhận dữ liệu.

Cùng bài đó có hai quy tắc ảnh hưởng tới thiết kế. Collector OPC UA và OPC DA từ chối giá trị có thời điểm cũ hoặc trùng thời điểm, nên chúng dùng cho dữ liệu đang chạy, không dùng để nạp lại dữ liệu cũ; các collector khác có thể bật cho phép chèn dữ liệu. Và khi hai collector OPC cùng ghi một bộ tag để dự phòng, store and forward giữ giá trị tới trước cho mỗi thời điểm ("first-in-wins").

Mỗi phần chạy ở đâu

Bài kiến trúc của Canary đưa ra nhiều cách bố trí:

Canary cũng ghi các phần có thể bố trí theo các cấp Purdue / ISA-95, Publisher và ODBC server đặt ở cấp 3 hoặc 4, và khi có hơn khoảng 50 client đồng thời thì nên chạy Views riêng cho người dùng Axiom và cho API hay ứng dụng bên thứ ba.

Đọc dữ liệu: Views, Axiom và các client khác

Client không đọc thẳng Historian. Views là cửa vào: nó kiểm soát quyền truy cập của client, gom được nhiều Historian lại, và giữ Virtual Views, tức mô hình tài sản gom các tag thô theo thiết bị và khu vực. Axiom là client của Canary cho dashboard và trend, Excel Add-in đưa cùng dữ liệu đó vào bảng tính, còn Calcs & Events kết nối qua Views, tính KPI hoặc phát hiện sự kiện rồi ghi kết quả ngược lại qua store and forward; sự kiện mặc định lưu trong một cơ sở dữ liệu SQLite cục bộ. Phần mềm khác đọc qua ODBC server hoặc Read API.

Canary tính license thế nào

Trang giá của Canary mô tả cách tính:

• license theo số tag, một tag là một chuỗi giá trị theo thời gian (còn gọi là point);
• client Axiom và Excel không giới hạn, cả với license vĩnh viễn và thuê bao;
• license vĩnh viễn trả một lần, CustomerCare (bản mới, bản vá bảo mật, hỗ trợ) gia hạn hằng năm; license thuê bao đã gồm CustomerCare;
• Canary còn có private cloud do hãng vận hành và các phần thêm như ODBC Connector.

Bài này không ghi giá. Đầu vào mà báo giá nào cũng cần là số tag đáng tin: bao nhiêu tag sẽ ghi bây giờ và trong vài năm tới.

Cần thống nhất gì trước khi cài

• Danh sách và số lượng tag, chia theo nguồn (OPC server, MQTT broker, gateway Ignition, bảng SQL).
• Mỗi collector và dịch vụ store and forward đi kèm đặt ở máy nào, còn bao nhiêu đĩa trống để đệm.
• Luật firewall giữa các cấp: cổng gRPC giữa các dịch vụ store and forward (55291) và các kết nối mà client cần để tới Views.
• Historian có cần dự phòng không, bao nhiêu client sẽ kết nối cùng lúc.
• Tag sẽ chia vào DataSet và Virtual Views ra sao, để chốt tên và mô hình tài sản trước khi dữ liệu bắt đầu tích lại.

TDL tiếp cận thế nào

TDL Industrial Automation là Canary Certified Partner, có tên trên trang đối tác của Canary tại Việt Nam. Các việc historian TDL đã làm đến nay là trên nền Rockwell Automation, ví dụ FactoryTalk View SE với FactoryTalk Historian ở nhà máy thức ăn thủy sản FeedOne của Vĩnh Hoàn. Với một dự án Canary, chúng tôi bắt đầu từ danh sách tag và mạng nhà máy: PLC và máy chủ SCADA nào đang giữ dữ liệu, collector và store and forward chạy được ở đâu, firewall đang tách các cấp nào. Dịch vụ SCADA và historian: SCADA, HMI và tích hợp dữ liệu nhà máy.