Khai thác dữ liệu quá khứ là 1 thành phần quan trọng của SCADA, cho nên database rất quan trọng.
Vấn đề ở đây còn bao gồm cấu hình hệ thống SCADA. Đối với bài toán ở đây, có lẽ hệ thống bao gồm :
Hardware Driver ( & SuiteLink Interface ) -> Intouch ( Data Accquisition & processing + HMI ) -> Database -> Application using historian database ( Report ...)
1. Về nhu cầu database :
Period Report :
- Đặc điểm : báo cáo dữ liệu định kì
----------> data được lưu theo thời gian fix ( phù hợp với các thông số cộng dồn như sản lượng , hoặc các thông số mà mức độ biến động thấp : ví dụ nhiệt độ môi trường / mức nước hồ ... )
Advance Report
- Báo cáo kết hợp phân tích dữ liệu : min / max, các hàm tính toán, phương sai, kì vọng, tích phân , dự đoán xu hướng ...
-------------> cần các hàm tính toán và có thể nhu cầu truy xuất dữ liệu thời gian không hạn chế. Loại này có thể cần nguồn dữ liệu liên tục hoặc ko liên tục
Abnormal Report
- Báo cáo ( sự cố ) : tìm các điểm dữ liệu đặc biệt ( bao gồm nhiều point ) trong khoảng thời gian có thể không hạn chế. Điều này có thể còn bao gồm cả các ứng dụng Advance Alarm : SMS / Email Alarm ngay lập tức xuất alarm report cho người quản trị cấp cao. Loại này yêu cầu dữ liệu được lưu liên tục trong database
Các ứng dụng tính toán chuyên dụng ( ví dụ phân tích xu thế dữ liệu, nhận dạng đối tượng để hiệu chỉnh hệ thống và hỗ trợ vận hành, phân tích xác xuất hư hỏng - lập lịch bảo trì và nâng cấp ... ) : Cái này rõ ràng cần 1 database lưu dữ liệu liên tục thời gian dài.
2. Một vài vấn đề khi triển khai thực tế :
- Nhu cầu correcting data khi hệ thống lưu sai dữ liệu ( bao gồm các lỗi đường truyền / lỗi thiết bị ghi tự động / hệ tự động bị restart hoặc dừng trong 1 thời gian ) : 1 hệ thống được build bao gồm Main & back up + Manual . Trong bất kì trường hợp nào hệ thống cần có khả năng correcting data khi bị lỗi ( bao gồm khả năng nhập lại dữ liệu bằng tay từ hệ thống Manual hoặc đồng bộ dữ liệu từ hệ thống chạy tốt )
- Database có thể phải có năng lực đáp ứng nhiều Client, đảm bảo cho khả năng mở rộng tính năng của hệ thống.
- Với báo cáo : form mẫu có thể thay đổi , thêm bớt theo các thời kì khác nhau , cần xây dựng chiến lược database phù hợp với điều này
- Cơ chế bảo mật khi hệ thống được xây dựng trên nhiều máy
- Khả năng back-up / restore.
3.
Năng lực đáp ứng của Intouch :
- Csv / txt file = database :
(a) khả thi lưu data analog theo time fix, discrete data có thể lưu theo event datachange. Việc lưu dữ liệu analog theo data-change cá nhân mình thấy không khả thi lắm vì khi làm việc với nhiều dữ liệu có tốc độ biến đổi cao , intouch cứ phaỉ open/close file rất ì ạch
(b)Việc edit data trong file dùng script cần hết sức thận trọng, vì đây là bản chất các file string (cần quy định rõ số chữ số sau dấu phẩy ).
(c)Form mẫu file gần như fix , vì sau khi built project thì khi thay đổi form mẫu ( sau 6 tháng) sẽ liên quan tới code / license.
(d)Tại thời điểm ghi dữ liệu , intouch sẽ chiếm quyền điều khiển file ( database) .
Các hạn chế c,d có thể vượt qua bằng cách coi đó là raw database. Xây dựng 1 ứng dụng copy các file đó sang 1 thư mục khác để sử dụng. Các form mẫu có thể dùng excel link tới các file đó.
Trong đó đặc điểm a là không thể vượt qua.
Phù hợp với xây dựng các period report , các report ko đòi hỏi lưu dữ liệu liên tục và trong thời gian ngắn ( vài tháng ).
Nhược điểm : dung lượng lưu lớn ( ko có 1 tý nén nào )
Việc lưu database trên 1 máy khác gặp khó khăn về vấn đề bảo mật vì phải mở 1 thư mục share full control ( khi máy dính virut thì máy có share kia cũng đi theo )
- lưu vào cơ sở dữ liệu : ( theo chuẩn OBDC )
Cái này có lợi thế so với file ở khả năng cài database - intouch trên 2 máy khác nhau ( vấn đề bảo mật ) , vấn đề dung lượng cũng có cải thiện hơn. Dữ liệu analog mình thấy để ghi dữ liệu liên tục theo data-change thì hơi chậm . Còn nữa, vì sử dụng OBDC nên khi lượng point lớn thì cũng hơi ì ạch.
CSDL có ưu điểm giúp người quản trị hệ thống dễ hơn so với quản trị đống file.
4. Mạnh nhất thì như bạn nhthanh.tdh nói, chơi 1 database chuyên nghiệp ( Wonderware historian, PI historian ... ) : tuyệt vời trừ mỗi việc $ .
Vậy tùy thuộc yêu cầu hệ thống mà cân nhắc lựa chọn database thôi.
Vài ý kiến bàn về tư tưởng xây dựng database. Mong trao đổi với mọi người . Còn các vấn đề code, triển khai ( deadband, security,... ), các kĩ thuật thao tác khai thác ... cũng là các vấn đề khác nữa
p/s : nhân tiện về database. Mong các bác có thể giới thiệu năng lực và các chiến lược đối với hệ thống của SIemens, cũng như các hệ thống khác ( chắc là topic khác )
Đánh dấu