Triển khai historian công nghiệp: so sánh lựa chọn, RFP và FAT/SAT cho nhà máy Thái Lan

“SCADA lẽ ra phải có dữ liệu lịch sử, vậy mà khi muốn xuất nhiệt độ của ngày phát sinh hàng lỗi năm ngoái thì truy xuất chậm, dữ liệu bị thiếu, và không biết đó là tag nào.” Chúng tôi thường nhận được những trao đổi như vậy từ các anh chị phụ trách điều khiển và đo lường hoặc IT nhà máy tại các nhà máy của doanh nghiệp Nhật Bản ở Thái Lan. Xin nói kết luận trước: điều cần có được khi triển khai historian công nghiệp không phải là một vùng lưu trữ thật lớn, mà là “dữ liệu chuỗi thời gian đáng tin cậy, có ngữ cảnh đi kèm và có thể tái hiện về sau”. Để làm được điều đó, có 4 việc cần quyết định: (1) có thực sự cần historian hay không, (2) lưu những gì, với độ chính xác nào và theo mốc thời gian nào, (3) đặt historian ở đâu trong mạng, (4) xác nhận những gì trong thử nghiệm nghiệm thu. Việc so sánh sản phẩm sẽ suôn sẻ hơn nếu được thực hiện sau khi đã quyết định 4 việc này.

Ngoại trừ những con số có ghi nguồn, các con số như số tag, chu kỳ, lượng dữ liệu và dung lượng bộ đệm xuất hiện trong bài viết này là giá trị giả định do chính bài viết này đặt ra, dựa trên nhà máy mô hình được mô tả ở phần sau. Đây không phải số liệu trung bình ngành hay số liệu khảo sát. Ngoài ra, chức năng và kế hoạch của các sản phẩm được giới thiệu theo nội dung mà từng công ty đã công bố (công bố của nhà sản xuất). Tất cả đều không phải sản phẩm của TOMAS TECH, mà là sản phẩm của các công ty khác.

Vì sao lúc này việc triển khai historian công nghiệp được đặt ra

Những gì được công bố tại ICC 2026 vào tháng 9/2026

Vài tuần gần đây đã có những công bố đáng chú ý liên quan đến historian. Trong thông cáo báo chí ngày 23/9/2026, công ty Inductive Automation cho biết tại hội nghị thường niên ICC 2026 tổ chức ở Sacramento (Mỹ) (theo công ty này, có hơn 1,800 người tham dự và hơn 60 phiên), họ đã giới thiệu bản xem trước (preview) của “Enterprise Historian Module” mới dành cho TimescaleDB, như một phần của phiên bản kế tiếp “Ignition 2027”. Đồng thời, công ty Tiger Data, đơn vị phát triển TimescaleDB, trở thành đối tác chiến lược; hai công ty cùng phát triển “TimescaleDB for Ignition”, và sản phẩm này sẽ do Inductive Automation trực tiếp bán và hỗ trợ.

Theo bài tổng kết mà công ty này đăng ngày 30/9, module này nhằm đáp ứng các yêu cầu về hiệu năng truy vấn, tính sẵn sàng cao và dung lượng lưu trữ. Ignition 2027 dự kiến phát hành vào tháng 2/2027, và được cho là sẽ chuyển sang mô hình phát hành hằng năm. Công ty này cũng giải thích rằng Ignition 8.3 hiện hành, với tư cách phiên bản hỗ trợ dài hạn (LTS), sẽ được hỗ trợ đến năm 2030. Tất cả đều là công bố của nhà sản xuất, và Enterprise Historian Module mới ở giai đoạn xem trước. Ngày bắt đầu cung cấp và giá chưa được công bố.

Lưu ý thêm, Tiger Data là công ty đã đổi tên từ Timescale vào ngày 17/6/2025. Phần mở rộng cơ sở dữ liệu chuỗi thời gian mã nguồn mở (một phần mở rộng của PostgreSQL) vẫn tiếp tục mang tên “TimescaleDB”. Xin lưu ý không nhầm lẫn giữa tên công ty và tên sản phẩm. Hai công ty cũng đã công bố hợp tác tại Hannover Messe 2026 vào ngày 20/4/2026, và trong thông cáo đó, “giấy phép đóng tính theo từng tag” và “định dạng dữ liệu độc quyền” được nêu ra như những vấn đề của thị trường. Đây là quan điểm của chính các bên liên quan, nhưng nó cho thấy cách tính giấy phép và mức độ dễ dàng khi lấy dữ liệu ra đang trở thành điểm cần bàn khi lựa chọn historian.

Ý nghĩa đối với nhà máy tại Thái Lan

Công bố này không phải là lý do để thay thế ngay một thứ gì đó. Tuy nhiên, có một thay đổi đáng nắm bắt: lựa chọn historian không còn là hai phương án “sản phẩm chuyên dụng, hay chức năng lịch sử đi kèm SCADA”, và cấu hình dùng cơ sở dữ liệu chuỗi thời gian đa dụng ở phía sau đang dần trở thành một lựa chọn chính thức của cả các nhà cung cấp phần mềm công nghiệp.

Với những nhà máy sắp đưa historian vào, hoặc sắp thay thế cơ chế lưu lịch sử cũ, có thể cho rằng các quyết định như “triển khai bằng phiên bản hỗ trợ dài hạn hiện tại hay chờ phiên bản kế tiếp” và “có để dữ liệu bị khóa trong định dạng của một sản phẩm cụ thể hay không” đã trở nên cụ thể hơn trước. Nền tảng cho các quyết định đó là 4 việc cần quyết định mà bài viết này đề cập.

Historian công nghiệp là gì: khác biệt với nhật ký SCADA và cơ sở dữ liệu chuỗi thời gian đa dụng

Định nghĩa của NIST và vị trí trong hệ thống điều khiển

Trong phần thuật ngữ, hướng dẫn về bảo mật OT “SP 800-82 Rev.3” (tháng 9/2023) của Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST) định nghĩa data historian là “cơ sở dữ liệu tập trung hỗ trợ phân tích dữ liệu bằng các phương pháp kiểm soát quá trình bằng thống kê (SPC)”. Cùng tài liệu này nêu ví dụ về cấu hình trung tâm điều khiển, trong đó HMI, máy trạm kỹ thuật (engineering workstation) và data historian được kết nối qua mạng LAN, cũng như cấu hình trong đó dữ liệu của PLC được lưu vào historian.

Công dụng không chỉ giới hạn ở SPC. Tài liệu này cũng viết rằng, như một đặc thù của mạng OT, data historian có thể trở thành nguồn dữ liệu sự kiện “bổ trợ” giúp làm rõ tình huống của một sự cố an ninh mạng. Tuy nhiên, đó chỉ là “bổ trợ”, không có nghĩa là có thể thay thế hạ tầng nhật ký bảo mật. Nên hiểu historian là bản ghi để lần theo trục thời gian những gì đã xảy ra trong nhà máy, từ điều tra chất lượng, phân tích bất thường thiết bị, phân tích năng lượng cho đến rà soát lại sự cố.

Khác gì với nhật ký SCADA

SCADA và HMI cũng có chức năng lưu lịch sử để hiển thị xu hướng (trend). Bài viết này phân biệt 3 loại sau.

Nội dung của bảng là xu hướng chung do bài viết này tổng hợp, và khác biệt rất lớn tùy sản phẩm. Điều quan trọng không phải là loại nào ưu việt hơn, mà là “yêu cầu của doanh nghiệp mình nằm ở đâu”. Cách nghĩ về việc lựa chọn và nâng cấp bản thân SCADA được giải thích trong bài “SCADA cho nhà máy Thái Lan: RFP, FAT/SAT và TCO“.

“Lưu được” khác với “tái hiện được”

Giá trị của historian không nằm ở việc tích trữ được lượng lớn dữ liệu. Giá trị đó nằm ở chỗ, khi nửa năm sau phát hiện một vấn đề chất lượng, có thể tái hiện lại rằng vào ngày đó, giờ đó, tag nào mang giá trị gì, và giá trị đó có đáng tin cậy không (có phải do cảm biến bất thường hay mất kết nối không). Muốn vậy, không chỉ giá trị mà cả thời điểm chính xác, thông tin chất lượng (bình thường, thiếu dữ liệu, hay giá trị thay thế) và ý nghĩa của tag (thiết bị đo nào của thiết bị nào, đơn vị là gì) cũng phải được lưu lại cùng với giá trị. Đó là ý nghĩa của cụm “đáng tin cậy, có ngữ cảnh đi kèm và có thể tái hiện” trong bài viết này.

So sánh lựa chọn historian: 3 phương án và cách đọc xu hướng sản phẩm

Quyết định thứ nhất: có thực sự cần historian không

Bài viết này cho rằng, nếu có từ 2 tình huống trở lên trong số sau đây đúng với nhà máy của bạn, nhiều khả năng chỉ chức năng lịch sử của SCADA là không còn đủ.

• Muốn so sánh dữ liệu của nhiều dây chuyền, nhiều SCADA hoặc PLC trên cùng một trục thời gian
• Cần lưu dữ liệu quy trình trong nhiều năm để phục vụ điều tra chất lượng
• Không muốn đặt các truy vấn nặng phục vụ phân tích lên SCADA dùng cho vận hành
• Những người ở ngoài mạng điều khiển, như trụ sở chính hay bộ phận đảm bảo chất lượng, muốn xem dữ liệu
• Muốn bù lại phần dữ liệu bị thiếu về sau, kể cả khi mất kết nối truyền thông

Ngược lại, nếu mục đích là giám sát vận hành 1 dây chuyền và thời gian lưu giữ ngắn cũng được, thì có khi rà soát lại cài đặt lịch sử của SCADA trước sẽ nhanh hơn.

Trường hợp dùng cơ sở dữ liệu chuỗi thời gian đa dụng

Các lựa chọn cơ sở dữ liệu chuỗi thời gian đa dụng đang mở rộng. Ví dụ, ngày 15/4/2025, công ty InfluxData công bố cung cấp chính thức (GA) “InfluxDB 3 Core” và “InfluxDB 3 Enterprise”. Theo công ty này, Core là mã nguồn mở theo giấy phép MIT/Apache 2, được định vị là “engine dữ liệu gần đây tốc độ cao cho các ứng dụng thời gian thực”. Enterprise được cho là bổ sung thêm tính sẵn sàng cao, bản sao chỉ đọc (read replica), chuyển đổi dự phòng tự động (failover), v.v. Việc Core được mô tả là “dành cho dữ liệu gần đây” là điểm cần xác nhận khi cân nhắc có dùng nó làm historian lưu trữ dài hạn hay không.

TimescaleDB, một phần mở rộng của PostgreSQL (do công ty Tiger Data phát triển), cũng là một trong những lựa chọn tiêu biểu của cơ sở dữ liệu chuỗi thời gian đa dụng. Như đã nêu ở trên, công ty Inductive Automation đã công bố sẽ đưa nó vào các lựa chọn historian của mình.

Khi chọn cơ sở dữ liệu đa dụng, cần tự thiết kế và vận hành việc thu thập, cờ chất lượng, dữ liệu đến không theo thứ tự, bù dữ liệu bị thiếu, nén, thời gian lưu giữ và quản lý quyền truy cập. Có thể cho rằng bộ phận IT có kinh nghiệm và nhân lực cho việc đó hay không sẽ là ranh giới lớn trong việc lựa chọn.

Động thái của phần mềm công nghiệp và các sản phẩm historian chuyên dụng

Ở các sản phẩm phần mềm công nghiệp, chức năng historian cũng đang được xem xét lại. Công ty Inductive Automation đã phát hành Ignition 8.3 vào ngày 16/9/2025 và công bố bộ “Industrial Historian Solution Suite”, gồm Historian Core Module, SQL Historian Module, và Historian API để triển khai historian riêng. Theo tài liệu của công ty này, Core Historian là cơ sở dữ liệu tích hợp QuestDB, có các chức năng phân vùng (partition), loại bỏ trùng lặp, lưu trữ (archive) và tổng hợp, và có thể chọn cách xử lý dữ liệu cũ trong số “None (lưu vô thời hạn)”, “Prune (xóa các phân vùng cũ)” và “Archive (chuyển sang nơi khác)”. Mức phân bổ bộ nhớ mặc định được cho là 10% tổng bộ nhớ của hệ thống. Tài liệu của công ty QuestDB giải thích rằng đây là thành phần thay thế cho historian nội bộ dựa trên SQLite trước đây.

Với ví dụ về historian chuyên dụng, công ty Canary Labs giải thích trên trang web chính thức rằng phương thức lưu trữ của họ là “nén không mất dữ liệu (lossless)”, và lưu và chuyển tiếp (store-and-forward) là một thành phần chuyên biệt giúp truyền dữ liệu chắc chắn kể cả khi ngoại tuyến. PI System của công ty AVEVA là sản phẩm có ngoại lệ (deadband) và nén theo phương thức swinging door, sẽ được trình bày ở phần sau. AVEVA được cho là đã công bố các cải tiến như xử lý dữ liệu đến không theo thứ tự trong PI Server 2024 R2.

Đây là những ví dụ về lựa chọn có trên thị trường; ngoài ra còn nhiều sản phẩm khác. Ở đây chúng tôi không khuyến nghị hay đánh giá hơn kém. Điều cần xem khi so sánh không phải là các con số như mức tăng hiệu năng bao nhiêu lần hay giới hạn số tag, mà là sản phẩm đó với cấu hình đó có đáp ứng được “lưu cái gì, lưu thế nào, và nghiệm thu ra sao” được đề cập từ phần tiếp theo hay không.

Xác nhận giao diện tiêu chuẩn

Khi chọn sản phẩm, một điểm nên xác nhận là tiêu chuẩn về cách lấy dữ liệu lịch sử ra. “OPC 10000-11 UA Part 11: Historical Access” của OPC Foundation là đặc tả quy định cách lưu và truy xuất dữ liệu vào historian hoặc cơ sở dữ liệu, đề cập đến khái niệm lịch sử của dữ liệu và sự kiện, hành vi tạo, truy xuất, cập nhật, xóa dữ liệu đã lưu trữ và chú thích (annotation), cũng như bảo mật bao gồm quyền truy cập và kiểm toán. Phiên bản mới nhất là V1.05.04 (phát hành ngày 29/11/2024). Về việc xử lý các phép tổng hợp như nội suy hay trung bình theo thời gian, có đặc tả “Part 13: Aggregates”, và phiên bản 1.05.07 (công bố ngày 15/4/2026) được đăng trên trang tham chiếu của OPC Foundation.

Dù sản phẩm ghi là “hỗ trợ OPC UA”, vẫn có thể xảy ra trường hợp sản phẩm chỉ đọc ghi giá trị hiện tại, không hỗ trợ truy xuất lịch sử (Part 11). Trong RFP, cần xác nhận riêng sản phẩm hỗ trợ truy xuất lịch sử và tổng hợp theo đặc tả nào.

Lưu cái gì và lưu thế nào: sổ đăng ký tag, lấy mẫu, thời gian và lưu và chuyển tiếp (store-and-forward)

Sổ đăng ký tag mới là bản thiết kế thực sự

Sản phẩm đầu ra cần làm đầu tiên khi triển khai historian không phải là sơ đồ cấu hình máy chủ, mà là sổ đăng ký tag (tag register). Sổ đăng ký cần có tối thiểu các thông tin sau.

• Tên tag, và tag đó thuộc thiết bị nào, thiết bị đo nào (phân cấp thiết bị)
• Đơn vị, dải đo, độ chính xác của thiết bị đo
• Chu kỳ thu thập (khoảng quét)
• Cài đặt vùng chết (deadband) và nén, cùng căn cứ của cài đặt đó
• Thời gian lưu giữ
• Ý nghĩa của cờ chất lượng
• Mô tả (tiếng Nhật, tiếng Anh, tiếng Thái)

Nếu tên tag cứ để nguyên là địa chỉ PLC, vài năm sau sẽ không còn ai hiểu ý nghĩa của nó. Cách đặt tên phân cấp thiết bị và tag cũng liên quan đến thiết kế topic khi gửi bằng MQTT. Cách nghĩ về vấn đề này được đề cập trong bài “Triển khai MQTT Sparkplug B tại nhà máy Thái Lan: RFP, FAT/SAT và thí điểm 90 ngày“. Ngoài ra, nếu danh sách thiết bị làm gốc cho các tag vẫn còn cũ thì cũng không lập được sổ đăng ký. Về việc kiểm kê thiết bị điều khiển, có thể tham khảo bài “Quản lý tài sản OT: sổ tài sản, RFP và nghiệm thu 90 ngày cho nhà máy Thái Lan“.

Chu kỳ lấy mẫu được quyết định từ “mục đích sử dụng”

Lấy tất cả các tag với chu kỳ ngắn nhất có vẻ an tâm, nhưng chỉ làm tăng dung lượng và tải truyền thông, và dữ liệu không được dùng đến cứ chồng chất. Chu kỳ được quyết định theo việc dữ liệu đó dùng để làm gì. Giá trị thay đổi chậm như nhiệt độ và giá trị cần bắt được biến động đột ngột như áp suất cần chu kỳ khác nhau. Với các trạng thái số (chạy hay dừng, cảnh báo, v.v.), có thể cho rằng trong nhiều trường hợp, chỉ ghi lại khi có thay đổi sẽ tự nhiên hơn là lấy theo chu kỳ cố định.

Lưu thời gian và chất lượng cùng với giá trị

Để dữ liệu có thể tái hiện về sau, tiền đề là “giá trị của thời điểm nào” phải chính xác. Ý nghĩa sẽ thay đổi tùy theo dấu thời gian (timestamp) được gắn ở phía PLC hoặc cảm biến, ở gateway, hay khi dữ liệu đến historian. Nếu dữ liệu bị trễ truyền thông lại được gắn thời điểm đến, thứ tự nguyên nhân và kết quả có thể trông như bị đảo ngược. Có thể cho rằng việc thống nhất nguồn thời gian trong nhà máy và ghi vào đặc tả rằng thời gian được gắn ở đâu là quan trọng. Nếu lưu theo Giờ Phối hợp Quốc tế (UTC) và chuyển sang giờ địa phương Thái Lan khi hiển thị, việc so sánh dữ liệu với các cơ sở ở nước ngoài hoặc trụ sở chính sẽ ít nhầm lẫn hơn.

Chất lượng của giá trị cũng được lưu cùng. Nếu xử lý đứt dây cảm biến, mất truyền thông, giá trị thay thế nhập tay, v.v. giống như giá trị bình thường, kết luận phân tích sẽ bị sai.

Ngăn thiếu dữ liệu bằng lưu và chuyển tiếp (store-and-forward)

Mạng nhà máy có lúc ngừng. Lý do rất đa dạng: hỏng thiết bị, thi công, thứ tự khởi động lại sau khi mất điện, v.v. Lưu và chuyển tiếp (store-and-forward) là cơ chế mà ở phía thu thập (gateway biên hoặc máy chủ thu thập), dữ liệu chưa gửi được sẽ được lưu tạm, và khi truyền thông phục hồi thì gửi đi theo thứ tự từ cũ đến mới. Nếu không có cơ chế này, dữ liệu trong khoảng thời gian mất truyền thông sẽ mất vĩnh viễn.

Điểm cần chú ý ở đây là cách xử lý dữ liệu đến muộn. Theo tài liệu thuyết trình của công ty AVEVA, trong PI System, “dữ liệu không theo thứ tự (out of order) sẽ bỏ qua bước nén”. Tùy sản phẩm mà khả năng đưa dữ liệu đến muộn vào đúng vị trí thời gian, và việc nén cũng như tổng hợp sẽ ra sao khi đưa vào, là khác nhau. Cách ước tính dung lượng bộ đệm sẽ được đề cập ở phần tính toán phía sau.

Mấu chốt của lưu trữ dữ liệu quy trình dài hạn: quyết định vùng chết và nén từ độ chính xác thiết bị đo

Ngoại lệ và nén: ví dụ của AVEVA PI System

Điều gây tranh luận nhiều nhất trong lưu trữ dài hạn là cài đặt lược bớt dữ liệu. Ở đây, chúng tôi lấy PI System của công ty AVEVA làm ví dụ, vì phương thức của nó được giải thích trong tài liệu công khai (theo tài liệu thuyết trình tại AVEVA World San Francisco năm 2023. Đây là thuật ngữ riêng của PI System và không thể khái quát hóa cho historian của các công ty khác).

PI System có cơ chế 2 giai đoạn. Giai đoạn thứ nhất, “ngoại lệ (Exception)”, là vùng chết (deadband) đơn giản để loại bỏ nhiễu, chỉ được thực hiện ở PI Interfaces phía thu thập, giúp giảm số sự kiện gửi đi và tiết kiệm băng thông mạng. Các mục cài đặt gồm độ rộng vùng chết theo đơn vị kỹ thuật (ExDev), tỷ lệ so với dải đo (ExDevPercent) và số giây tối đa giữa các sự kiện (ExMax). Cùng tài liệu này ghi chú rằng AVEVA Adapters có thể lọc vùng chết nhưng bỏ qua cài đặt ngoại lệ của tag, còn PI Connectors không thực hiện kiểm tra ngoại lệ. Nói cách khác, ngay trong cùng một sản phẩm, hành vi lược bớt dữ liệu cũng khác nhau tùy phương tiện thu thập. Đây là điểm cần xác nhận trong RFP.

Giai đoạn thứ hai, “nén (Compression)”, là thuật toán gọi là swinging door, giảm lượng dữ liệu lưu trữ bằng cách loại bỏ những điểm có thể tái hiện an toàn bằng nội suy. Tài liệu có trích dẫn mục đích là “loại bỏ nhiễu của thiết bị đo và quy trình, đồng thời ghi lại các thay đổi quan trọng của quy trình”.

Cả “không cài đặt” lẫn “cài đặt quá mức” đều là vấn đề

Cùng tài liệu này có ghi những điểm lưu ý dễ bị bỏ sót: giá trị mặc định không phải bằng không, và việc “tắt nén” không giống với việc “bật nén và đặt độ lệch bằng không”. Nếu bắt đầu vận hành với giá trị mặc định khi triển khai, có khả năng dữ liệu đang bị lược bớt ngoài ý muốn.

Về ví dụ hiệu quả, với tag trạng thái chỉ nhận 0 và 1, không dùng ngoại lệ, quét 1 giây, số sự kiện trong 48 giờ được cho là 172,800 khi không nén và 15 khi nén ở mức tối thiểu. 172,800 là toàn bộ số điểm của 48 giờ × 3,600 giây. Tuy nhiên, đây là ví dụ trong điều kiện cụ thể là tag trạng thái số chỉ nhận 0 và 1, không thể áp tỷ lệ này cho giá trị analog.

Mặt khác, trong một trường hợp khách hàng dầu khí ngoài khơi ở Mỹ, được cho là hơn 87% số tag không dùng cả ngoại lệ lẫn nén, và máy chủ phía đất liền định kỳ trở nên không ổn định. Theo báo cáo, sau khi phân loại tag, quyết định cài đặt mới dựa trên độ chính xác thiết bị đo và ý kiến của những người am hiểu tại hiện trường, rồi thử trên một giàn khoan thí điểm, số sự kiện lưu trữ đã giảm khoảng 94%. Đây cũng là kết quả thí điểm của một khách hàng duy nhất, không phải hiệu quả chung cho nhà máy. Điều cần rút ra từ đây không phải là con số tỷ lệ giảm, mà là “cả việc tiếp tục lưu toàn bộ điểm lẫn việc cài đặt quá mức làm rơi mất các thay đổi đều có vấn đề”.

Quyết định dựa trên độ chính xác thiết bị đo và kiểm chứng sai lệch so với dữ liệu gốc

Vậy giá trị cài đặt được quyết định dựa trên cơ sở nào? Trong trường hợp một nhà máy lọc dầu ở Mỹ trong cùng tài liệu, theo báo cáo, kết quả của việc dùng cài đặt ngoại lệ và nén ở mức thận trọng là ở tất cả các tag được phân tích, sai lệch lớn nhất so với dữ liệu gốc đều nhỏ hơn độ chính xác đo của thiết bị đo. Điều trường hợp này cho thấy là cách nghĩ: “Lưu các thay đổi nhỏ hơn mức chính xác mà thiết bị đo đo được là vô nghĩa. Ngược lại, việc lược bớt tạo ra sai lệch vượt quá độ chính xác của thiết bị đo là đang làm hỏng dữ liệu.”

Bài viết này khuyến nghị quy trình sau.

1. Phân loại tag theo loại thiết bị đo và mục đích sử dụng (điều tra chất lượng, phân tích điều khiển, năng lượng, v.v.)
2. Ghi độ chính xác của thiết bị đo vào sổ đăng ký tag, và dựa vào đó quyết định giá trị tạm thời cho độ rộng vùng chết và nén
3. Với các tag thử nghiệm, lưu song song dữ liệu thô toàn bộ điểm và dữ liệu sau khi lược bớt
4. Tính sai lệch lớn nhất so với dữ liệu gốc khi nội suy dữ liệu đã lược bớt, và xác nhận xem có nằm trong phạm vi độ chính xác của thiết bị đo không
5. Với các tag quan trọng liên quan đến chất lượng, cùng những người am hiểu tại hiện trường xác nhận bằng mắt trên đồ thị xu hướng rằng các thay đổi đột ngột không bị rơi mất
6. Nếu không có vấn đề, mở rộng sang các tag cùng nhóm phân loại

Cũng cần lưu ý rằng phương thức khác nhau tùy sản phẩm. Có sản phẩm nêu “nén không mất dữ liệu (lossless)” không lược bớt, cũng có sản phẩm theo phương thức bỏ đi các điểm có thể tái hiện bằng nội suy. Điều quan trọng không phải phương thức nào tốt hơn, mà là xác nhận trong thử nghiệm nghiệm thu rằng phương thức và cài đặt của sản phẩm đã chọn có giữ được độ chính xác mà doanh nghiệp muốn lưu hay không.

Ước tính dung lượng cơ sở dữ liệu chuỗi thời gian bằng mô hình nhà máy (mô hình giả định)

Tất cả các con số từ đây trở đi đều là giá trị giả định do bài viết này tự đặt ra. Đây không phải hiệu năng sản phẩm hay mức trung bình ngành. Hãy dùng như một khuôn mẫu tính toán và thay bằng số tag và chu kỳ của doanh nghiệp bạn.

Tiền đề (nhà máy mô hình H)

Lượng dữ liệu thô

Số điểm mà 1 tag tạo ra trong 1 ngày là 24 giờ × 3,600 giây = 86,400 điểm (172,800 điểm trong ví dụ của AVEVA nêu trên tương ứng với 2 ngày của con số này). Với 2,000 tag là 2,000 × 86,400 = 172,800,000 điểm/ngày, và 1 năm là 172,800,000 × 365 = 63,072,000,000 điểm/năm.

Quy ra byte, 1 ngày là 172,800,000 điểm × 16 byte = 2,764,800,000 byte, khoảng 2.76 GB; 1 năm là 63,072,000,000 điểm × 16 byte = 1,009,152,000,000 byte, khoảng 1,009 GB; 10 năm là khoảng 10,092 GB.

Khác biệt theo tỷ lệ lưu trữ

Mức giảm nhờ vùng chết và nén thay đổi rất lớn tùy tính chất tín hiệu và cài đặt. Vì vậy, thay vì dự đoán tỷ lệ giảm, chúng tôi đặt các tỷ lệ lưu trữ tạm thời để so sánh và nắm cảm giác về khối lượng.

Điều đọc được từ bảng này là chỉ riêng biên độ của tỷ lệ lưu trữ đặt tạm (10–100%) cũng đã khiến dung lượng cần thiết cho cùng một nhà máy chênh nhau 10 lần. Lượng lưu toàn bộ điểm trong 1 năm và lượng lưu với tỷ lệ 10% trong 10 năm là như nhau. Có thể cho rằng ước tính dung lượng nên được tính lại từ tỷ lệ lưu trữ đo thực tế trên các tag thử nghiệm, chứ không phải từ giá trị trong catalog sản phẩm. Ngoài ra, dung lượng cho bản sao lưu (backup) và bản sao (replica) cũng cần tính riêng.

Ước tính bộ đệm lưu và chuyển tiếp (store-and-forward)

Tiếp theo là bộ đệm khi truyền thông bị ngừng. Giả định rằng trong kỳ nghỉ dài ngày, thiết bị đường truyền bị hỏng và trong 72 giờ không ai nhận ra. Số điểm tích lại trong khoảng thời gian này là 2,000 tag × 3,600 giây × 72 giờ = 518,400,000 điểm, quy ra byte là 518,400,000 × 16 = 8,294,400,000 byte, khoảng 8.29 GB. Nếu tính dư gấp 2 lần, phía biên (edge) sẽ cần bộ đệm khoảng 16.6 GB trở lên.

Cũng cần ước tính thời gian để gửi hết dữ liệu đã tích lại sau khi truyền thông phục hồi. Nếu giả định năng lực gửi của thiết bị biên là 10,000 điểm mỗi giây, thì vì trong lúc đó vẫn phát sinh 2,000 điểm dữ liệu mới mỗi giây, tốc độ giảm của bộ đệm là 8,000 điểm mỗi giây. 518,400,000 điểm ÷ 8,000 điểm = 64,800 giây, tức là mất 18 giờ. 18 giờ này là khoảng thời gian mà trên historian dữ liệu vẫn chưa được lấp đầy. Nếu năng lực gửi hoặc năng lực ghi phía historian không đủ, thời gian này còn kéo dài hơn.

Từ phép tính này, có thể thấy những điều cần xác nhận trong thử nghiệm nghiệm thu: “chịu được mất kết nối bao nhiêu giờ”, “sau khi phục hồi thì bao nhiêu giờ đuổi kịp”, và “trong thời gian đó, dữ liệu đến không theo thứ tự có được đưa vào đúng thời điểm, việc nén và tổng hợp có bị sai lệch không”.

Đặt historian ở đâu: OT, DMZ và mạng doanh nghiệp

Nguyên tắc của NIST: liên lạc giữa doanh nghiệp và OT đi qua các dịch vụ trong DMZ

Historian cũng là cơ chế để những người ở ngoài mạng điều khiển sử dụng dữ liệu của hệ thống điều khiển. Vì vậy, đặt nó ở đâu gắn trực tiếp với thiết kế bảo mật.

Ví dụ về kiến trúc bảo mật trong NIST SP 800-82r3 đặt một vùng phi quân sự (DMZ) để tách môi trường OT và mạng doanh nghiệp, và cho rằng mọi liên lạc giữa cấp doanh nghiệp và cấp quản lý vận hành (bao gồm cấp 3 của mô hình Purdue) đều đi qua các dịch vụ bên trong DMZ. Cấp hiện trường được giải thích là bao gồm các thiết bị ở cấp 0–2 của mô hình Purdue. Hơn nữa, vì DMZ kết nối với bên ngoài, tài liệu cho rằng các dịch vụ trong DMZ phải được giám sát và bảo vệ để kẻ tấn công không thể xâm nhập vào môi trường OT mà không bị phát hiện.

Ví dụ thiết kế của bài viết này: historian chính phía OT và bản sao toàn công ty trong DMZ

Từ nguyên tắc này, bài viết này xem xét cấu hình sau như một ví dụ thiết kế. Xin lưu ý rằng đây là cách nghĩ của bài viết này được suy ra từ nguyên tắc của NIST, chứ NIST không chỉ định bố trí historian theo dạng này.

• Historian chính (primary historian): đặt ở phía OT (cấp quản lý vận hành), thu thập dữ liệu từ PLC và SCADA. Là bản gốc cho vận hành và điều tra chất lượng
• Bản sao (replica) dành cho toàn công ty: đặt trong DMZ, nhận dữ liệu từ historian chính. Người dùng phía mạng doanh nghiệp như trụ sở chính, đảm bảo chất lượng, nhóm phân tích chỉ truy cập vào bản sao này
• Mạng doanh nghiệp: các hệ thống như BI và ERP lấy dữ liệu từ bản sao trong DMZ. Không kết nối trực tiếp với historian phía OT

Làm như vậy, có thể cho rằng dù phía doanh nghiệp gửi truy vấn nặng, historian chính hỗ trợ vận hành cũng khó bị ảnh hưởng, và số lối vào phía OT cũng có thể giảm bớt.

Điểm yếu ẩn trong “sao chép tự động kết nối trực tiếp”

Điều cần chú ý là bản thân cơ chế sao chép dữ liệu cũng có thể trở thành đường tấn công hoặc đường phát sinh sai sót. NIST SP 800-82r3 nêu “liên kết dữ liệu không phù hợp” như một ví dụ về lỗ hổng, và cho rằng các liên kết cơ sở dữ liệu (database link) tự động sao chép dữ liệu của data historian sang cơ sở dữ liệu khác, nếu không được cấu hình phù hợp, có thể trở thành lỗ hổng cho phép truy cập trái phép hoặc giả mạo dữ liệu.

Có thể cho rằng không nên chỉ vì tiện lợi mà thiết kế liên kết trực tiếp từ cơ sở dữ liệu BI hay ERP phía IT vào historian phía OT, mà nên ghi vào tài liệu thiết kế hướng sao chép, giao thức sử dụng, xác thực và giám sát. Nếu muốn đảm bảo về mặt vật lý chỉ có một chiều từ OT sang IT, cũng có lựa chọn là data diode. Cách nghĩ về vấn đề này được sắp xếp trong bài “Chọn data diode cho nhà máy Thái Lan: hướng dẫn truyền dữ liệu OT sang IT một chiều“.

Bảo vệ bản thân máy chủ historian

Trong nhiều trường hợp, máy chủ historian chạy trên Windows hoặc Linux đa dụng. NIST SP 800-82r3 cho rằng các hệ thống đa dụng được dùng cho máy trạm kỹ thuật, data historian, máy tính xách tay bảo trì, máy chủ sao lưu, v.v. nhìn chung có thể được bảo vệ giống như thiết bị IT, chẳng hạn bằng cách phân phối bản cập nhật từ máy chủ diệt virus đặt trong mạng điều khiển (có kèm giới hạn “nhìn chung”. Không thể mở rộng cách xử lý tương tự cho các thiết bị điều khiển như PLC). Cần quyết định ngay khi triển khai ai sẽ thực hiện cập nhật hệ điều hành, quản lý tài khoản và sao lưu, theo quy trình nào.

Toàn vẹn dữ liệu và nhật ký kiểm toán (audit trail) trong các ngành chịu quản lý

Ở các nhà máy xử lý hồ sơ điện tử thuộc đối tượng quản lý của Cục Quản lý Thực phẩm và Dược phẩm Hoa Kỳ (FDA), như dược phẩm, thiết bị y tế, thực phẩm, v.v. dành cho thị trường Mỹ, có trường hợp việc xử lý dữ liệu historian phải đáp ứng thêm yêu cầu. Quy định liên bang Hoa Kỳ 21 CFR §11.10 yêu cầu những người tạo, sửa đổi, duy trì hoặc truyền hồ sơ điện tử trong hệ thống khép kín (closed system) phải có quy trình và biện pháp kiểm soát để đảm bảo tính xác thực và tính toàn vẹn của hồ sơ điện tử. Một trong số đó, mục (e) nêu việc dùng nhật ký kiểm toán an toàn, do máy tính tạo ra và có gắn dấu thời gian, để ghi lại một cách độc lập ngày giờ của các thao tác nhập và hành động của người vận hành khi tạo, sửa đổi hoặc xóa hồ sơ điện tử.

Đây là quy định của FDA Hoa Kỳ và chỉ giới hạn trong trường hợp xử lý hồ sơ thuộc đối tượng quản lý của FDA. Đây không phải nghĩa vụ pháp lý chung cho các nhà máy ở Thái Lan. Tuy nhiên, ở những nhà máy thuộc đối tượng, việc khi sửa dữ liệu historian về sau (sửa nhập tay, bù dữ liệu bị thiếu, thêm chú thích, v.v.) có lưu lại được ai đã thay đổi gì, khi nào hay không sẽ trở thành yêu cầu khi lựa chọn sản phẩm. OPC UA Part 11 đã nêu ở trên cũng đề cập đến bảo mật bao gồm quyền truy cập và kiểm toán. Việc có thuộc đối tượng hay không và cần đáp ứng những gì, xin vui lòng xác nhận riêng với bộ phận đảm bảo chất lượng hoặc chuyên gia.

12 mục cần ghi trong RFP hệ thống historian

Dưới đây là các mục tối thiểu nên ghi trong RFP (hồ sơ mời đề xuất) cho historian khi đề nghị nhà sản xuất hoặc công ty tích hợp hệ thống báo giá.

1. Mục đích sử dụng và người dùng: dùng để làm gì (điều tra chất lượng, phân tích thiết bị, năng lượng, rà soát lại sự cố, v.v.) và ai sẽ xem
2. Sổ đăng ký tag: số tag, kiểu dữ liệu, đơn vị, độ chính xác thiết bị đo, phân cấp thiết bị, ngôn ngữ mô tả
3. Phương tiện thu thập và thiết bị đối tượng: loại PLC, SCADA, thiết bị đo và phương thức truyền thông. Với từng phương tiện thu thập, cài đặt vùng chết và ngoại lệ có hiệu lực hay không
4. Phương thức và cách cài đặt chu kỳ, vùng chết, nén: phương thức (lược bớt hay không mất dữ liệu), giá trị mặc định, cách lưu lại căn cứ cài đặt, quyền thay đổi và lịch sử thay đổi
5. Thời gian và chất lượng: gắn dấu thời gian ở đâu, nguồn thời gian, hệ thời gian khi lưu (UTC hay giờ địa phương), các loại cờ chất lượng
6. Lưu và chuyển tiếp (store-and-forward): dung lượng bộ đệm, thời gian mất kết nối chịu được, năng lực gửi sau khi phục hồi, cách xử lý dữ liệu đến không theo thứ tự
7. Thời gian lưu trữ và dung lượng: thời gian lưu giữ, cách xử lý dữ liệu cũ (xóa, lưu trữ archive), căn cứ ước tính dung lượng
8. Bố trí và mạng: cấu hình historian chính phía OT và bản sao trong DMZ, hướng và phương thức sao chép, đường truy cập từ bên ngoài
9. Lấy dữ liệu ra: hỗ trợ truy xuất lịch sử (Part 11) và tổng hợp (Part 13) của OPC UA, cách xuất sang hệ thống khác như SQL, API, CSV. Có bị khóa trong định dạng độc quyền hay không
10. Cách tính giấy phép và các phiên bản tương lai: tính theo số tag, số kết nối hay số máy chủ, cách xử lý khi mở rộng, thời gian hỗ trợ dài hạn và việc chuyển sang phiên bản kế tiếp
11. Nhật ký kiểm toán và bảo mật: ghi lại việc sửa dữ liệu, tài khoản và quyền, quy trình cập nhật hệ điều hành và sao lưu (với trường hợp thuộc đối tượng quản lý thì là các yêu cầu tương ứng)
12. Hỗ trợ tại chỗ và tiêu chí FAT/SAT: đầu mối bảo trì trong nước Thái Lan, giải thích bằng tiếng Thái, thời gian xử lý khi có sự cố, hạng mục thử nghiệm và tiêu chí đạt, phạm vi chứng kiến

Đặc biệt quan trọng là mục 3, 4 và 6. Nếu không ghi mục 3, sau khi triển khai bạn mới nhận ra rằng dù cùng tên sản phẩm, hành vi lược bớt dữ liệu lại khác nhau tùy phương tiện thu thập. Nếu không ghi mục 4, việc lược bớt ngoài ý muốn sẽ tiếp diễn với giá trị mặc định. Nếu không ghi mục 6, dù dữ liệu trong khoảng thời gian mất truyền thông bị mất, cũng không ai chịu trách nhiệm được. Ngoài ra, mục 10 quyết định việc 5 năm, 10 năm sau có mang được dữ liệu ra hay không, trong bối cảnh phiên bản và cấu hình sản phẩm liên tục thay đổi như công bố tại ICC 2026 lần này. Cách định vị historian trong tổng thể cách thu thập dữ liệu sản xuất toàn công ty được sắp xếp trong bài “Thu thập dữ liệu sản xuất: PoC 90 ngày và RFP tại Thái Lan“.

Những gì cần xác nhận trong FAT/SAT hệ thống historian

Trong thử nghiệm trước khi xuất xưởng (FAT) và thử nghiệm tại hiện trường sau khi lắp đặt (SAT), điều cần xác nhận theo điều kiện của doanh nghiệp mình không phải là giá trị trong catalog, mà là “dữ liệu không bị thiếu, không bị hỏng, thời gian chính xác, lấy ra được khi cần, và khôi phục được nếu bị mất”.

Giá trị số của tiêu chí đạt khác nhau tùy mục đích sử dụng của nhà máy, nên cần quyết định ở giai đoạn RFP. Đặc biệt, “khôi phục” là hạng mục thường chỉ được lập kế hoạch mà chưa thử lần nào. Vì dữ liệu historian không thể lấy lại về sau, có thể cho rằng giá trị của việc thực sự xác nhận khả năng khôi phục là rất lớn.

Các vấn đề đặc thù của Thái Lan và ASEAN

Biện pháp nâng cao hiệu quả của BOI

Trong “Biện pháp nâng cấp hướng tới ngành công nghiệp thông minh và bền vững” thuộc hướng dẫn ưu đãi đầu tư (bản năm 2023) của Ủy ban Đầu tư Thái Lan (BOI), các ưu đãi được nêu cho việc nâng cao hiệu quả của hoạt động kinh doanh hiện có (bất kể đã được BOI ưu đãi hay chưa), với điều kiện giá trị đầu tư từ 1,000,000 baht trở lên (không bao gồm đất và vốn lưu động). Biện pháp đưa công nghệ số vào sử dụng được cho là miễn thuế thu nhập doanh nghiệp trong 3 năm (mức trần là 50% giá trị đầu tư), còn việc chuyển đổi sang Industry 4.0 theo kế hoạch được NSTDA phê duyệt là miễn thuế thu nhập doanh nghiệp trong 3 năm (mức trần là 100% giá trị đầu tư). Các yêu cầu đối với việc đưa công nghệ số vào sử dụng được nêu bao gồm việc đưa vào phần mềm hoặc hệ thống thông tin kết nối dữ liệu của ít nhất 3 chức năng bên trong và bên ngoài tổ chức, hoặc ứng dụng AI, học máy, dữ liệu lớn, phân tích dữ liệu, v.v.; trong một số trường hợp, cần đầu tư vào phần mềm do doanh nghiệp được chứng nhận trong nước Thái Lan phát triển hoặc cải tiến. Cũng có những ngành không thuộc đối tượng.

Tuy nhiên, đây là tài liệu bản năm 2023, và chúng tôi chưa xác nhận được tại thời điểm tháng 10/2026 biện pháp này còn đang nhận hồ sơ hay không, điều kiện có thay đổi hay không. Việc triển khai historian có thể thuộc đối tượng hay không, xin vui lòng kiểm tra hướng dẫn mới nhất và xác nhận riêng với BOI hoặc chuyên gia.

Luật An ninh mạng của Thái Lan

Theo bài phân tích của công ty luật Tilleke & Gibbins (ngày 1/8/2025), Luật An ninh mạng của Thái Lan (Phật lịch 2562, tức năm 2019) hiện áp dụng cho các cơ quan nhà nước, các cơ quan giám sát và quản lý, và các tổ chức hạ tầng thông tin trọng yếu (CII) được chỉ định. Các lĩnh vực CII gồm an ninh quốc gia, dịch vụ công trọng yếu, ngân hàng và tài chính, IT, viễn thông, vận tải và logistics, năng lượng và tiện ích công cộng, y tế công cộng; ngành chế tạo không nằm trong các lĩnh vực hiện hành. Các tổ chức CII phải báo cáo ban đầu về sự cố trong vòng 24 giờ. Trong dự thảo sửa đổi được công bố vào tháng 7/2025, việc bổ sung “industrial work” cũng đã được đề xuất, nhưng đó mới là giai đoạn dự thảo, và bài viết này chưa xác nhận được việc dự thảo đã được thông qua sau đó hay chưa.

Luật này không áp đặt nghĩa vụ trực tiếp cho các nhà máy chế tạo thông thường của doanh nghiệp Nhật Bản. Tuy nhiên, trong trường hợp nhà máy có cơ sở năng lượng hoặc tiện ích công cộng, hoặc tùy theo động thái sửa đổi trong tương lai, vẫn có khả năng chịu ảnh hưởng. Việc có áp dụng hay không, xin vui lòng xác nhận riêng với chuyên gia. Vì dữ liệu historian cũng có thể trở thành bản ghi giúp làm rõ tình huống khi xảy ra sự cố, có thể cho rằng đây là một trong những căn cứ để cân nhắc khi quyết định thời gian lưu trữ và độ chính xác của thời gian.

Những điểm cần lưu ý trong vận hành tại chỗ

Từ đây là cách nghĩ của bài viết này. Ở các nhà máy tại Thái Lan, không hiếm trường hợp nhân viên vận hành và bảo trì xem dữ liệu bằng tiếng Thái, nhân viên người Nhật biệt phái xem bằng tiếng Nhật, còn trụ sở chính và các cơ sở ở nước ngoài xem bằng tiếng Anh. Việc có thể lưu mô tả tag bằng 3 ngôn ngữ hay không, và có thể chuyển đổi ngôn ngữ của màn hình và báo cáo hay không, sẽ quyết định historian đó có được sử dụng hay không. Ngoài ra, việc có đội ngũ bảo trì xử lý được tại chỗ khi có sự cố hay không, và quy trình khởi động lại sau mất điện có được viết bằng tiếng Thái hay không, cũng là những điểm nên xác nhận trước khi triển khai.

Nếu tính đến việc kết nối dữ liệu của nhiều nhà máy, hoặc của các hệ thống ngoài historian (MES, chất lượng, bảo trì) để sử dụng, cũng có cách nghĩ định vị historian như “một thành phần đảm nhận một phần dữ liệu”. Xin tham khảo thêm bài “Industrial Data Fabric cho sản xuất: RFP và nghiệm thu“.

Kế hoạch 90 ngày triển khai historian công nghiệp

Ngày 0–30: sắp xếp mục đích sử dụng và kiểm kê sổ đăng ký tag

Quyết định historian sẽ dùng để làm gì (điều tra chất lượng, phân tích thiết bị, năng lượng, v.v.) và liệt kê người dùng. Trên cơ sở đó, lập danh sách thiết bị và tag đối tượng, ghi vào sổ đăng ký đơn vị, độ chính xác thiết bị đo, chu kỳ cần thiết và thời gian lưu giữ. Quyết định tạm thời cho quyết định thứ nhất (chức năng lịch sử của SCADA là đủ, xây dựng bằng cơ sở dữ liệu chuỗi thời gian đa dụng, hay đưa historian chuyên dụng vào) cũng được thực hiện ở giai đoạn này.

Ngày 31–60: đo thực tế trên các tag thử nghiệm

Chọn vài chục tag tiêu biểu, lưu song song dữ liệu thô toàn bộ điểm và dữ liệu đã áp dụng vùng chết và nén. Cùng những người am hiểu tại hiện trường xác nhận sai lệch lớn nhất so với dữ liệu gốc có nằm trong độ chính xác thiết bị đo không, và các thay đổi quan trọng có bị rơi mất không. Đồng thời, chủ động ngắt truyền thông để thử xem phần dữ liệu thiếu có được lấp bằng lưu và chuyển tiếp không, thời gian có chính xác không. Từ tỷ lệ lưu trữ thu được ở đây, lập lại bản ước tính dung lượng cho doanh nghiệp mình.

Ngày 61–90: RFP, tiêu chí FAT/SAT và quyết định đặt hàng

Dựa trên kết quả đo thực, chốt 12 mục của RFP cùng các hạng mục thử nghiệm và tiêu chí đạt của FAT/SAT, rồi lấy báo giá từ nhiều công ty theo cùng điều kiện. Thống nhất với người phụ trách IT nhà máy và an toàn thông tin về bố trí (phía OT và bản sao trong DMZ) và thiết kế mạng. Cách chọn phiên bản sản phẩm (triển khai bằng phiên bản hỗ trợ dài hạn hiện tại hay chờ phiên bản kế tiếp) cũng được quyết định ở đây, sau khi xác nhận thời gian hỗ trợ mà từng công ty công bố.

Các sản phẩm đầu ra nên có trong tay vào cuối 90 ngày gồm 6 điểm: (1) định nghĩa mục đích sử dụng và người dùng, (2) sổ đăng ký tag (kèm độ chính xác, chu kỳ, thời gian lưu giữ và căn cứ nén), (3) hồ sơ sai số nén và thử nghiệm mất kết nối trên các tag thử nghiệm, (4) bản ước tính dung lượng cho doanh nghiệp mình, (5) thiết kế bố trí và mạng, (6) RFP và tiêu chí FAT/SAT.

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

Historian công nghiệp là gì? Khác gì với việc lưu dữ liệu của SCADA?

Historian công nghiệp là cơ chế lưu trữ dài hạn dữ liệu quy trình của nhà máy theo trục thời gian để dùng cho phân tích. NIST SP 800-82r3 định nghĩa nó là cơ sở dữ liệu tập trung hỗ trợ kiểm soát quá trình bằng thống kê. Chức năng lịch sử của SCADA có mục đích chính là hiển thị xu hướng trên màn hình vận hành, và có khi đối tượng chỉ giới hạn ở các tag của SCADA đó, hoặc thời gian lưu giữ khá ngắn. Nếu muốn lưu dữ liệu của nhiều dây chuyền, nhiều hệ thống trong thời gian dài, độc lập với vận hành, historian sẽ là một ứng viên.

Phân biệt lựa chọn historian và cơ sở dữ liệu chuỗi thời gian đa dụng như thế nào?

Cơ sở dữ liệu chuỗi thời gian đa dụng có độ tự do cao, nhưng doanh nghiệp cần tự thiết kế và vận hành việc thu thập, cờ chất lượng, dữ liệu đến không theo thứ tự, nén, thời gian lưu giữ và quản lý quyền truy cập. Đặc điểm của historian chuyên dụng là thường có sẵn các chức năng này dưới dạng sản phẩm. Việc lựa chọn được quyết định dựa trên các yếu tố như bộ phận IT có kinh nghiệm vận hành cơ sở dữ liệu chuỗi thời gian và nhân lực hay không, có muốn tránh để dữ liệu bị khóa trong định dạng của một sản phẩm cụ thể hay không. Gần đây, các nhà cung cấp phần mềm công nghiệp cũng đã công bố cấu hình dùng cơ sở dữ liệu chuỗi thời gian đa dụng ở phía sau.

Khi lưu trữ dữ liệu quy trình dài hạn, quyết định nén và vùng chết (deadband) như thế nào?

Quyết định dựa trên độ chính xác của thiết bị đo. Với các tag thử nghiệm, đặt dữ liệu toàn bộ điểm cạnh dữ liệu đã lược bớt, xác nhận sai lệch lớn nhất giữa giá trị nội suy và dữ liệu gốc có nằm trong phạm vi độ chính xác thiết bị đo không, các thay đổi quan trọng có bị rơi mất không, rồi mới mở rộng. Giá trị mặc định của sản phẩm có thể không phải bằng không, và tùy phương tiện thu thập mà cài đặt có thể không có hiệu lực, nên tránh bắt đầu với giá trị mặc định.

Nên đặt historian ở đâu trong mạng?

Ví dụ thiết kế của bài viết này là cấu hình đặt historian chính ở phía OT, đặt bản sao dành cho toàn công ty trong DMZ, và người dùng mạng doanh nghiệp chỉ truy cập vào bản sao. Đây là cách nghĩ được suy ra từ nguyên tắc của NIST SP 800-82r3 rằng liên lạc giữa doanh nghiệp và OT đi qua các dịch vụ trong DMZ, chứ NIST không chỉ định bố trí này. Ngoài ra, NIST cũng nêu các liên kết cơ sở dữ liệu tự động sao chép dữ liệu historian sang cơ sở dữ liệu khác như một ví dụ có thể trở thành lỗ hổng nếu không được cấu hình phù hợp.

Cần xác nhận những gì trong RFP và FAT/SAT của hệ thống historian?

Trong RFP, hãy ghi sổ đăng ký tag, hành vi lược bớt dữ liệu theo từng phương tiện thu thập, phương thức nén và giá trị mặc định, thời gian và chất lượng, dung lượng lưu và chuyển tiếp và dữ liệu đến không theo thứ tự, thời gian lưu trữ, bố trí, cách lấy dữ liệu ra, cách tính giấy phép và hỗ trợ dài hạn, nhật ký kiểm toán, và hỗ trợ tại chỗ. Trong FAT/SAT, hãy xác nhận việc bù dữ liệu bị thiếu sau khi mất truyền thông, sai số nén, độ chính xác của thời gian, cờ chất lượng, hiệu năng truy vấn, sự khớp nhau của bản sao, khôi phục từ bản sao lưu, và khởi động lại sau mất điện.

Chi phí của historian là bao nhiêu?

Chi phí thay đổi rất lớn tùy cách tính giấy phép (số tag, số kết nối, số máy chủ, v.v.), dung lượng lưu trữ và cấu hình máy chủ, loại và số lượng thiết bị đối tượng thu thập, có bản sao trong DMZ hay không, việc liên kết với hệ thống hiện có, và phạm vi thử nghiệm nghiệm thu. Vì không có thông tin gốc về giá, bài viết này không ước tính số tiền, nhưng dung lượng có thể ước tính từ số tag × chu kỳ × tỷ lệ lưu trữ như mô hình giả định trong bài. Cách chắc chắn là trước hết lập sổ đăng ký tag, đo thực tỷ lệ lưu trữ trên các tag thử nghiệm, rồi mới so sánh báo giá. Việc có thể thuộc đối tượng của biện pháp ưu đãi BOI hay không, xin vui lòng xác nhận riêng với BOI hoặc chuyên gia.

Tóm tắt

• Giá trị của historian công nghiệp không nằm ở lượng lưu trữ, mà ở việc lưu lại được “dữ liệu chuỗi thời gian đáng tin cậy, có ngữ cảnh đi kèm và có thể tái hiện về sau”.
• Quyết định đầu tiên là chức năng lịch sử của SCADA là đủ, xây dựng bằng cơ sở dữ liệu chuỗi thời gian đa dụng, hay đưa historian chuyên dụng vào. So sánh sản phẩm là việc sau đó.
• Bản thiết kế thực sự là sổ đăng ký tag. Chu kỳ quyết định từ mục đích sử dụng, quyết định thời gian được gắn ở đâu, và lưu cờ chất lượng cùng với giá trị. Ngăn thiếu dữ liệu khi mất kết nối bằng lưu và chuyển tiếp (store-and-forward).
• Vùng chết (deadband) và nén được quyết định dựa trên độ chính xác thiết bị đo, kiểm chứng sai lệch so với dữ liệu gốc trên các tag thử nghiệm rồi mới mở rộng. Không bắt đầu với giá trị mặc định.
• Trong mô hình giả định, dữ liệu thô của 2,000 tag với chu kỳ 1 giây là khoảng 1,009 GB mỗi năm. Khi đặt tỷ lệ lưu trữ tạm thời trong khoảng 10–100%, dung lượng chênh nhau 10 lần. Cũng cần ước tính bộ đệm cho 72 giờ mất kết nối và thời gian đuổi kịp sau khi phục hồi.
• Về bố trí, có thể xem xét ví dụ thiết kế gồm historian chính phía OT và bản sao trong DMZ. Tránh sao chép tự động kết nối trực tiếp.
• Khi nghiệm thu, xác nhận việc bù dữ liệu bị thiếu, sai số nén, thời gian, hiệu năng truy vấn và khôi phục theo điều kiện của doanh nghiệp mình.

TOMAS TECH nhận tư vấn cho các nhà máy của doanh nghiệp Nhật Bản tại Thái Lan, từ giai đoạn cân nhắc như sắp xếp mục đích sử dụng historian, kiểm kê sổ đăng ký tag, xác nhận sai số nén trên các tag thử nghiệm và ước tính dung lượng, đến lập RFP, thiết kế bố trí mạng, chứng kiến FAT/SAT và liên kết với SCADA hoặc hệ thống quản lý sản xuất hiện có. Ngay cả ở giai đoạn “chưa đến lúc chọn sản phẩm, nhưng muốn biết nên bắt đầu sắp xếp từ đâu”, bạn cũng có thể thoải mái liên hệ với chúng tôi qua biểu mẫu liên hệ.

Tài liệu tham khảo

• NIST “SP 800-82 Rev.3 Guide to Operational Technology (OT) Security” (tháng 9/2023): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
• AVEVA (Brent Bregenzer) “Exception, Compression, and their Impacts on PI System Performance” (tài liệu thuyết trình tại AVEVA World San Francisco năm 2023): https://cdn.osisoft.com/osi/presentations/2023-AVEVA-San-Francisco/UC23NA-3PGK04-AVEVA_Bregenzer_Brent-Exception-Compression-and-their-Impacts-On-PI-System-Performance.pdf
• OPC Foundation “OPC 10000-11 UA Part 11: Historical Access” (ngày 29/11/2024): https://opcfoundation.org/developer-tools/documents/view/168
• OPC Foundation “OPC 10000-13 UA Part 13: Aggregates” (ngày 15/4/2026): https://reference.opcfoundation.org/Core/Part13/v105/docs/
• Inductive Automation “Inductive Automation Releases Ignition 8.3” (ngày 16/9/2025): https://inductiveautomation.com/news/inductive-automation-releases-ignition-83
• Tài liệu Inductive Automation “Core Historian (QuestDB)”: https://www.docs.inductiveautomation.com/docs/8.3/ignition-modules/tag-historian/tag-history-providers/internal-historian-questdb
• QuestDB “Ignition 8.3”: https://questdb.com/docs/integrations/other/ignition/
• InfluxData “InfluxData announces InfluxDB 3 OSS GA” (ngày 15/4/2025): https://www.influxdata.com/blog/influxdata-announces-influxdb-3-OSS-GA
• Tiger Data “Timescale becomes Tiger Data” (ngày 17/6/2025): https://www.tigerdata.com/blog/timescale-becomes-tigerdata
• Trang web chính thức của Canary Labs: https://www.canarylabs.com/
• Tài liệu AVEVA “PI Server 2024”: https://docs.aveva.com/category/pi-server-2024
• Cornell Law School LII “21 CFR § 11.10 Controls for closed systems”: https://www.law.cornell.edu/cfr/text/21/11.10
• BOI “Measure for Industrial Upgrades towards Smart and Sustainable Industry” (trích hướng dẫn ưu đãi đầu tư 2023): https://www.boi.go.th/upload/content/Smart_and_Sustainable_Industry.pdf
• Tilleke & Gibbins “Major Draft Amendments to Thai Cybersecurity Act Released for Public Hearing” (ngày 1/8/2025): https://www.tilleke.com/insights/major-draft-amendments-to-thai-cybersecurity-act-released-for-public-hearing/
• Inductive Automation “Inductive Automation Reveals Ignition 2027 and Strategic Growth Initiatives at ICC 2026” (ngày 23/9/2026): https://inductiveautomation.com/news/inductive-automation-reveals-ignition-2027-and-strategic-growth-initiatives-at-icc-2026
• Inductive Automation “ICC 2026 Recap: Three Days of Innovation Unleashed” (ngày 30/9/2026): https://inductiveautomation.com/blog/icc-2026-recap-three-days-of-innovation-unleashed
• GlobeNewswire “Inductive Automation and Tiger Data Collaborate to Modernize the Industrial Historian Market” (ngày 20/4/2026): https://www.globenewswire.com/news-release/2026/04/20/3277103/0/en/inductive-automation-and-tiger-data-collaborate-to-modernize-the-industrial-historian-market.html