Tự động ghi nhiệt độ và độ ẩm tại nhà máy Thái Lan: hướng dẫn RFP và FAT/SAT

Dẫn nhập: Chỉ với biểu đồ thì không thể trả lời “lô nào bị ảnh hưởng”

Một ngày nọ, bộ phận đảm bảo chất lượng gửi câu hỏi: “Đã xảy ra sai lệch nhiệt độ trong buồng ổn định nhiệt độ và độ ẩm, vậy lô sản phẩm nào bị ảnh hưởng?” Nhiều nhà máy cho rằng việc trình bày biểu đồ chuỗi thời gian nhiệt độ và độ ẩm là đã “quản lý” tốt, nhưng chỉ với biểu đồ thì không thể giải thích chính xác “lô nào, vào khung thời gian nào, đã bị phơi nhiễm sai lệch ở mức độ nào”. Việc tự động hóa ghi nhận không chỉ đơn thuần là “hiển thị trực quan” hay PoC (chứng minh khái niệm), mà cần thiết kế một “hệ thống ghi nhận” mà bên thứ ba có thể xem xét lại và giải thích dựa trên căn cứ sau này.

Đối tượng độc giả và ranh giới giữa “quản lý” và “giám sát”

Bài viết này dành cho các trưởng bộ phận mua hàng, chất lượng, kỹ thuật tại các nhà máy ở Thái Lan và Nhật Bản, đặc biệt là những người đang cân nhắc “tự động hóa ghi nhận nhiệt độ và độ ẩm” và chịu trách nhiệm chứng minh chất lượng sản phẩm, đáp ứng kiểm tra hoặc xử lý khiếu nại trong tương lai. Chủ đề ở đây không phải là “quản lý” hay “giám sát” nhiệt độ và độ ẩm, mà là tự động hóa “ghi nhận”. Trọng tâm là thiết kế và vận hành hệ thống ghi nhận “có thể giải trình sau này”, chứ không chỉ là giám sát thời gian thực hay phát cảnh báo.

Khởi điểm thiết kế ghi nhận: “Cần trả lời những câu hỏi chất lượng nào?”

Thiết kế tự động hóa ghi nhận nhiệt độ và độ ẩm nên bắt đầu từ câu hỏi “Cần trả lời những câu hỏi chất lượng nào?”. Ví dụ:

• “Lô này đã bị phơi nhiễm ngoài phạm vi nhiệt độ quy định trong bao nhiêu phút?”
• “Khi xảy ra sai lệch, ai đã xử lý và xử lý như thế nào?”
• “Dữ liệu này được lấy từ cảm biến nào, trạng thái hiệu chuẩn ra sao?”

Để trả lời các câu hỏi này, cần thiết kế sao cho có thể giải thích dựa trên “ghi nhận” sau này. Không chỉ là liệt kê biểu đồ hay số liệu, mà còn phải truy vết được “ngữ cảnh” và “nguồn gốc” của ghi nhận.

Lược đồ ghi nhận tối thiểu: Cần ghi nhận đến mức nào?

Trong tự động hóa ghi nhận nhiệt độ và độ ẩm, các mục ghi nhận tối thiểu (lược đồ) cần thiết như sau. Nếu thiếu các mục này, sẽ không thể giải thích hoặc đáp ứng kiểm tra sau này.

• ID cảm biến nguồn: Lấy từ cảm biến nào
• ID thiết bị/khu vực: Phòng, thiết bị, khu vực nào
• Giá trị đo & đơn vị: Nhiệt độ, độ ẩm, đơn vị
• Dấu thời gian nguồn: Thời điểm ghi nhận tại cảm biến
• Dấu thời gian nhận: Thời điểm hệ thống nhận dữ liệu
• Trạng thái/mã chất lượng: Tình trạng lỗi truyền thông, hết hạn hiệu chuẩn, giá trị bất thường, v.v.
• Trạng thái & phiên bản hiệu chuẩn: Số chứng nhận hiệu chuẩn và hạn hiệu lực tại thời điểm lấy dữ liệu
• Phiên bản giới hạn áp dụng: Đánh giá theo tiêu chuẩn quản lý nào (ví dụ: phiên bản SOP)
• Liên kết lô/lệnh sản xuất: Gắn với lô sản phẩm/lệnh sản xuất nào
• ID cảnh báo/hành động: ID cảnh báo và ghi nhận xử lý khi xảy ra sai lệch
• ID ingestion: Định danh quá trình nhập dữ liệu (để loại trừ gửi lại/trùng lặp)

Lược đồ này phù hợp với các quy định về dữ liệu lịch sử của OPC UA (OPC Foundation Historical Timestamps, StatusCode, Original Values) và hướng dẫn về tính toàn vẹn dữ liệu của FDA Tài liệu 10.

Ví dụ ghi nhận: Bảng mẫu về một sự kiện sai lệch

Dưới đây là ví dụ ghi nhận khi xảy ra sai lệch nhiệt độ trong buồng ổn định nhiệt độ và độ ẩm. Giá trị và ID chỉ là ví dụ minh họa, không đại diện cho ngưỡng hay tiêu chuẩn phổ quát.

Như vậy, bằng cách ghi nhận cả ID cảnh báo, ghi nhận xử lý (ID hành động), thông tin hiệu chuẩn, phiên bản tiêu chuẩn quản lý, liên kết với lô/lệnh sản xuất, có thể giải thích sau này “lô nào, gặp sai lệch nào, đã được xử lý ra sao”.

Vị trí lắp đặt cảm biến và chuỗi hiệu chuẩn: Thực tế về truy xuất nguồn gốc NIST

Lưu ý khi lắp đặt cảm biến

Vị trí lắp đặt cảm biến cần được quyết định cẩn trọng tùy theo sản phẩm và rủi ro quy trình. Ví dụ, trong buồng ổn định nhiệt độ và độ ẩm, có thể cần lắp nhiều điểm như “gần sản phẩm”, “nơi biến động nhiệt lớn nhất”, “hệ thống độc lập với cảm biến điều khiển”, v.v. (Thảo luận về mapping nhiệt độ của Vaisala). Tại nhà máy Thái Lan, cần xác nhận tính đại diện của giá trị đo tại các vị trí như cửa ra vào, cửa gió điều hòa, gần tường ngoài, đồng thời lưu lại lý do lắp đặt từng khu vực.

Chuỗi hiệu chuẩn và truy xuất nguồn gốc NIST

Việc hiệu chuẩn cảm biến đôi khi yêu cầu truy xuất nguồn gốc đến các tiêu chuẩn quốc gia như NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ), tuy nhiên, bản thân truy xuất nguồn gốc NIST không có nghĩa là “chứng chỉ được kết nối trực tiếp với NIST”, mà điều cốt lõi là “chuỗi hiệu chuẩn được ghi chép lại” (Truy xuất nguồn gốc đo lường theo NIST). Ở giai đoạn thiết kế, cần xác nhận phương pháp ghi nhận phạm vi đo, độ không đảm bảo, nội dung chứng chỉ của nhà cung cấp dịch vụ hiệu chuẩn sử dụng trong nước Thái Lan, cũng như số chứng chỉ và thời hạn hiệu lực.

Khu vực nhà máy Thái Lan và khác biệt vận hành do khí hậu

Tại nhà máy Thái Lan, cần xác nhận điều kiện vận hành theo mùa mưa/khô, sự xâm nhập không khí ngoài trời, điều kiện vận hành điều hòa tại từng vị trí lắp đặt. Mỗi khu vực có các điểm rủi ro khác nhau như “tường tiếp xúc không khí ngoài”, “khu vực nóng ẩm cao”, “dưới điều hòa”, v.v. Không nên sao chép thiết kế nhà máy Nhật Bản mà cần thiết kế khu vực dựa trên khí hậu, kết cấu nhà xưởng và thực tế vận hành tại địa phương.

Kiến trúc hệ thống: Từ cảm biến đến ghi nhận và xem xét lại

Hệ thống tự động hóa ghi nhận nhiệt độ và độ ẩm không chỉ đơn giản là cảm biến và hiển thị biểu đồ. Cần có cấu trúc nhiều lớp như sau:

1. Cảm biến / Logger

Quản lý vị trí lắp đặt, trạng thái hiệu chuẩn, ghi nhận giá trị đo và dấu thời gian.

1. Gateway

Thu thập dữ liệu từ cảm biến, quản lý lỗi truyền thông, loại trừ trùng lặp, đồng bộ thời gian.

1. Historian (CSDL ghi nhận)

Lưu trữ tất cả ghi nhận kèm lược đồ, hỗ trợ tìm kiếm và xem xét lại sau này.

1. Giao diện xem xét

Tìm kiếm ghi nhận, ghi nhận xử lý khi có cảnh báo, tham chiếu chứng nhận hiệu chuẩn, giao diện thân thiện cho bộ phận kiểm tra/chất lượng.

1. Liên kết QMS/MES

Liên kết với lô, lệnh sản xuất, ghi nhận xử lý sai lệch, quản lý tập trung hồ sơ chất lượng.

Giới hạn của OPC UA và đảm bảo metadata

Đặc tả Historical Access của OPC UA định nghĩa phương pháp xử lý dấu thời gian, mã trạng thái, giá trị gốc và lịch sử thay đổi (OPC UA Historical Timestamps, StatusCode, Original Values). Tuy nhiên, không phải tất cả các siêu dữ liệu đều được đảm bảo tự động. Ví dụ, số chứng chỉ hiệu chuẩn, ID lô hoặc ID hành động sẽ không thể đảm bảo chỉ với OPC UA nếu không xây dựng cơ chế ghi nhận và liên kết rõ ràng ngay từ khi thiết kế hệ thống.

Múi giờ, dấu thời gian và lệch đồng hồ

Xử lý dấu thời gian nguồn / máy chủ

Cần ghi nhận cả “dấu thời gian nguồn” do cảm biến ghi lại và “dấu thời gian nhận” do gateway hoặc historian gán khi nhận dữ liệu. Trong thực tế, rất nhiều trường hợp “thời điểm đo thực tế” và “thời điểm ghi nhận” không trùng nhau do trễ mạng, buffer, lệch đồng hồ cảm biến (clock drift), truyền dữ liệu trễ do mất kết nối tạm thời (OPC UA Historical Timestamps).

Ghi rõ múi giờ

Tại nhà máy Thái Lan, mặc định ghi nhận theo giờ Thái (UTC+7), nhưng nếu máy chủ hoặc cloud chạy theo giờ Nhật (UTC+9) hoặc UTC, thì việc ghi rõ múi giờ trong dấu thời gian là bắt buộc. Nếu không ghi rõ múi giờ, sẽ không thể giải thích chính xác sau này “sai lệch xảy ra lúc nào”, “lô nào bị ảnh hưởng”.

Xử lý lệch đồng hồ và truyền trễ

Nếu đồng hồ cảm biến hoặc gateway bị lệch, độ tin cậy của ghi nhận sẽ bị ảnh hưởng. Cần thực hiện đồng bộ thời gian định kỳ (NTP, v.v.), phát hiện và ghi nhận lệch đồng hồ, ghi nhận cả “thời điểm đo thực tế” và “thời điểm nhận” khi truyền trễ, ngay từ giai đoạn thiết kế.

Các điểm cần xác nhận chính khi duyệt thiết kế

• Lược đồ ghi nhận có đủ để trả lời các câu hỏi chất lượng sau này không?
• Việc ghi nhận và tham chiếu chứng nhận hiệu chuẩn, phiên bản tiêu chuẩn quản lý có dễ dàng không?
• Liên kết với lô, lệnh sản xuất đã được tự động hóa chưa?
• Quản lý dấu thời gian, múi giờ, lệch đồng hồ đã đủ chưa?
• Thiết kế đã bù đắp giới hạn của OPC UA và các giao thức khác chưa?
• Việc lắp đặt, vận hành đã phản ánh rủi ro khu vực, khí hậu đặc thù của nhà máy Thái Lan chưa?

(Tiếp theo ở PHẦN B)

Dữ liệu thiếu và chiến lược backfill

Trong quá trình tự động hóa ghi nhận nhiệt độ và độ ẩm, dữ liệu thiếu (missing data) là một rủi ro không thể tránh khỏi. Tại nhà máy, việc ghi nhận có thể bị gián đoạn do nhiều nguyên nhân như sự cố mạng, hỏng cảm biến, sự cố nguồn điện, v.v. Để đảm bảo tính toàn vẹn của ghi nhận, cần thiết kế rõ ràng phương án xử lý khi có dữ liệu thiếu và lựa chọn vận hành phù hợp với rủi ro của quy trình hoặc sản phẩm.

Nếu logger có thể lưu giữ giá trị đo thực trong thời gian xảy ra sự cố mạng và gửi lại sau khi phục hồi, có thể giảm thiểu dữ liệu bị thiếu. Tuy nhiên, chỉ riêng đặc tả OPC UA Historical Access không tự động nhận diện dữ liệu đến muộn là “backfill”. Đối với dữ liệu được nạp hàng loạt lần đầu với thời điểm nguồn trong quá khứ, có trường hợp không tạo bản ghi thay đổi (OPC Foundation historical updates and original values). Vì vậy, ngoài thời điểm đo thực và thời điểm nhận, cần quy định thêm cờ đến trễ/ gửi lại đặc thù ứng dụng, ID sự kiện gốc, và xác nhận rằng các thông tin này được hiển thị và xuất ra trong thử nghiệm tiếp nhận từ khi mất kết nối đến khi phục hồi.

Ngược lại, nếu thiết bị hoặc hệ thống tại hiện trường không có bộ đệm cục bộ, dữ liệu trong thời gian mất kết nối sẽ không thể thu thập vật lý và sẽ để lại “khoảng trống” trên ghi nhận. Trong trường hợp này, việc ghi nhận rõ ràng khoảng thời gian thiếu dữ liệu (ví dụ, cờ “No Data” hoặc để trống có lý do) là điều không thể thiếu cho việc kiểm toán hoặc đánh giá chất lượng sau này. Không được “xóa bỏ” dữ liệu thiếu, mà phải lưu lại chính xác thực tế và thời gian thiếu dữ liệu để duy trì độ tin cậy trong đánh giá rủi ro quy trình hoặc xác định lô sản phẩm.

Phân biệt giá trị vô hiệu, thiếu, nội suy, dữ liệu gốc và căn cứ theo OPC UA

Trong tự động hóa ghi nhận nhiệt độ và độ ẩm, không chỉ thu thập giá trị mà còn phải phân biệt rõ “giá trị đó là gì”. Mô hình dữ liệu lịch sử của OPC UA cho phép gán “StatusCode” cho từng điểm dữ liệu, ghi lại tính hợp lệ và nguồn gốc của giá trị (OPC Foundation historical StatusCode).

• Giá trị không hợp lệ (Invalid): Những giá trị được xác định là bất thường do cảm biến sẽ không được dùng để đánh giá chất lượng, và sẽ được xử lý là không hợp lệ cùng với nguyên nhân. Nếu sử dụng StatusCode như Bad của OPC UA, cũng cần xác nhận thiết bị nào, trong điều kiện nào sẽ gán mã này.
• Thiếu dữ liệu (No Data): Đối với khoảng thời gian vật lý không có giá trị đo thực, không được phép điền giá trị như thể có dữ liệu. Cần thiết kế phân biệt giữa phản hồi NoData khi đọc và sự kiện thiếu dữ liệu mà ứng dụng lưu trữ.
• Giá trị nội suy (Interpolated): Giá trị được ước tính từ các giá trị trước và sau phải được phân biệt với giá trị đo thực. Trong OPC UA ReadAtTime, có quy định sử dụng InfoBits để chỉ ra Interpolated khi nội suy (OPC Foundation raw vs interpolated readings).
• Dữ liệu gốc (Raw): Nếu có giá trị ghi gốc tại thời điểm chỉ định, cùng trong đặc tả ReadAtTime, InfoBits sẽ chỉ ra Raw. Raw và Good có ý nghĩa khác nhau, do đó không thể mặc định dữ liệu gốc luôn là Good.

Việc phân biệt này là không thể thiếu khi xem lại ghi nhận, điều tra nguyên nhân sai lệch, hoặc chứng minh sự phù hợp với tiêu chuẩn. Ví dụ, khi xảy ra sai lệch nhiệt độ/độ ẩm trong quy trình, việc giá trị tại thời điểm đó là “dữ liệu gốc” hay “giá trị nội suy” sẽ ảnh hưởng lớn đến quyết định của bộ phận chất lượng và cách xử lý lô sản phẩm.

Mô phỏng khi mất kết nối mạng và bộ đệm cục bộ

Độ bền vững của ghi nhận dữ liệu khi mất kết nối mạng là một điểm đánh giá quan trọng trong thiết kế hệ thống. Ví dụ, một số hệ thống như Vaisala viewLinc có chức năng cho phép cảm biến hoặc thiết bị cục bộ lưu trữ dữ liệu nội bộ trong thời gian mất kết nối và tự động tải lên máy chủ khi kết nối được phục hồi (Vaisala viewLinc official product). Trong trường hợp này, khoảng trống dữ liệu được giảm thiểu và tính liên tục của ghi nhận được đảm bảo.

Tuy nhiên, không phải hệ thống nào cũng đảm bảo chức năng này. Trước khi triển khai, cần thực hiện kiểm tra mô phỏng mất kết nối mạng để xác nhận hành vi thực tế của hệ thống. Nếu không có bộ đệm cục bộ và dữ liệu trong thời gian mất kết nối bị mất hoàn toàn, nên để lại khoảng trống rõ ràng trên ghi nhận và không nên nội suy hoặc ước lượng sau này để đảm bảo an toàn trong quản lý rủi ro. Nếu dựa vào giá trị nội suy, nguy cơ bỏ sót sai lệch hoặc bất thường thực tế sẽ tăng cao.

Ghi nhận gốc, chỉnh sửa, người thao tác/lý do, dấu vết kiểm toán

Đối với ghi nhận nhiệt độ và độ ẩm, cần quy định yêu cầu bảo toàn bản ghi gốc và truy vết chỉnh sửa. OPC UA Historical Access quy định cơ chế xử lý giá trị thay đổi, giá trị gốc và thông tin thay đổi, nhưng việc triển khai và lưu trữ quản lý lịch sử, sự kiện kiểm toán cần được kiểm chứng theo sản phẩm và cấu hình sử dụng. Đặc biệt, khi nạp dữ liệu hàng loạt lần đầu với thời điểm trong quá khứ, có trường hợp không tạo bản ghi thay đổi (OPC Foundation historical updates and original values). Vì vậy, cần lưu lại giá trị trước và sau chỉnh sửa, người phụ trách, thời điểm, lý do dưới dạng bản ghi ứng dụng, và kiểm tra khả năng tái cấu trúc sau khi xuất dữ liệu.

Ví dụ, khi nhân viên hiện trường chỉnh sửa dữ liệu sau khi thay cảm biến hoặc hiệu chuẩn, cần ghi lại ai, khi nào, giá trị nào, lý do gì đã được sửa và lưu lại như một dấu vết kiểm toán (audit trail). Nhờ đó, có thể đáp ứng yêu cầu kiểm toán chất lượng hoặc truy xuất nguồn gốc sau này. Việc ghi lại lý do chỉnh sửa không chỉ là nhật ký thao tác mà còn là căn cứ để đánh giá rủi ro quy trình và ảnh hưởng đến chất lượng sản phẩm.

Ngoài ra, ngay cả khi có chỉnh sửa hoặc bổ sung, không được xóa vật lý ghi nhận gốc mà phải quản lý tập trung giá trị trước và sau chỉnh sửa cùng lý do. Nhờ vậy, có thể phát hiện sớm việc gian lận cố ý hoặc thao tác nhầm, đồng thời đảm bảo trách nhiệm giải trình khi kiểm toán.

Ngưỡng cảnh báo, quản lý phiên bản, phê duyệt, hành động khắc phục, đóng cảnh báo

Trong quản lý cảnh báo sai lệch nhiệt độ/độ ẩm, việc thiết lập ngưỡng (threshold) và quản lý phiên bản là rất quan trọng. Thiết lập ngưỡng khác nhau cho từng quy trình hoặc sản phẩm và ghi lại lịch sử thay đổi giúp xác định rõ tiêu chuẩn nào được áp dụng tại từng thời điểm.

Khi xảy ra cảnh báo, cần phân biệt rõ giữa “phê duyệt (acknowledgement)”, “hành động khắc phục (corrective action)” và “đóng cảnh báo (closure)”. Mô hình cảnh báo của OPC UA cho phép người vận hành thực hiện thao tác “phê duyệt” khi có cảnh báo và lưu lại ghi nhận (OPC Foundation alarm acknowledge method). Tuy nhiên, phê duyệt chỉ là ghi nhận việc “nhận biết”, còn việc hành động khắc phục thực tế (ví dụ kiểm tra hiện trường, điều chỉnh thiết bị) cần được quản lý riêng biệt.

Ghi nhận hành động khắc phục nên bao gồm người thực hiện, nội dung, thời gian, phân tích nguyên nhân gốc rễ, biện pháp phòng ngừa tái phát, v.v. Quản lý tập trung các thông tin này và để bộ phận chất lượng hoặc người chịu trách nhiệm thực hiện thao tác “đóng cảnh báo” sẽ giúp xác định rõ việc hoàn thành xử lý cảnh báo. Kết hợp với thông tin ngưỡng được quản lý phiên bản, có thể xem lại chính xác tiêu chuẩn nào đã bị vượt ngưỡng và các biện pháp đã được thực hiện sau đó.

Chuyển giao giữa các ca làm việc

Tại các nhà máy vận hành 24/24, việc xử lý cảnh báo hoặc xem xét ghi nhận thường kéo dài qua nhiều ca làm việc. Có nhiều trường hợp cảnh báo phát sinh nhưng ca đêm không thể xử lý và phải chuyển giao cho ca ngày. Hệ thống ghi nhận tự động cần thể hiện rõ trạng thái “chưa hoàn thành” của cảnh báo hoặc hành động khắc phục, đồng thời đảm bảo chuyển giao chắc chắn cho người phụ trách ca tiếp theo khi đổi ca.

Ví dụ, nếu không có hành động trong một khoảng thời gian nhất định sau khi cảnh báo phát sinh, hệ thống sẽ tự động thông báo cho cấp trên, hoặc tự động hiển thị danh sách cảnh báo chưa xử lý khi đổi ca. Sự hiện diện của chức năng chuyển giao (escalation) và thiết kế vận hành sẽ ảnh hưởng trực tiếp đến việc giảm thiểu rủi ro chất lượng. Khi thiết kế hệ thống, cần xác nhận khả năng thiết lập linh hoạt quy tắc chuyển giao dựa trên thực tế vận hành và cơ cấu nhân sự tại hiện trường.

“`

+——————-+——————-+——————-+

| Loại ghi nhận | Ví dụ | OPC UA Status |

+——————-+——————-+——————-+

| Dữ liệu gốc | 23.5°C, 55%RH | Good |

| Giá trị vô hiệu | Hỏng cảm biến | Bad |

| Thiếu dữ liệu | Mất kết nối mạng | No Data |

| Giá trị nội suy | Giá trị ước lượng | Interpolated |

+——————-+——————-+——————-+

“`

Kịch bản sai lệch độ ẩm trong sản xuất và trùng lặp ranh giới lô

Ví dụ thực tế, giả sử trong quá trình sản xuất một sản phẩm, độ ẩm tạm thời vượt quá giới hạn trên. Nếu việc sản xuất lô A kết thúc và ngay sau đó bắt đầu sản xuất lô B, sai lệch độ ẩm xảy ra đúng vào thời điểm chuyển giao giữa hai lô. Khi đó, cần xác định chính xác lô nào bị ảnh hưởng do thời gian sai lệch trùng với ranh giới hai lô.

Theo chính sách bảo thủ của bộ phận chất lượng, tất cả các lô liên quan đến thời gian sai lệch sẽ được “tạm giữ (hold)” và chỉ sau khi đánh giá chất lượng bổ sung hoặc kiểm tra lại mới quyết định “phát hành (release)”. Điều quan trọng ở đây là độ tin cậy của quyết định sẽ thay đổi lớn tùy thuộc vào việc ghi nhận là “dữ liệu gốc” hay có chứa “giá trị nội suy” hoặc “khoảng thiếu dữ liệu”. Ví dụ, nếu trong thời gian sai lệch lại xảy ra mất kết nối mạng khiến một phần dữ liệu bị “thiếu”, cần áp dụng biện pháp tạm giữ nghiêm ngặt hơn.

Trong các kịch bản như vậy, tính toàn vẹn và minh bạch nguồn gốc của ghi nhận là căn cứ cho quyết định chất lượng. Nếu ghi nhận trong thời gian sai lệch là “dữ liệu gốc” liên tục thì khác hoàn toàn với trường hợp có xen lẫn nội suy hoặc thiếu dữ liệu, cả về quyết định phát hành lô cuối cùng lẫn trách nhiệm giải trình với khách hàng.

Vai trò bảo mật, truy cập từ xa của nhà cung cấp, sao lưu/khôi phục, xuất dữ liệu/kiểm tra phát lại, thời gian lưu trữ

Trong hệ thống tự động ghi nhận nhiệt độ và độ ẩm, cần định nghĩa quyền truy cập, xác nhận cảnh báo, chỉnh sửa, thay đổi cấu hình, sao lưu theo từng chức năng công việc. OPC UA có cơ chế về vai trò và kiểm toán, nhưng việc máy chủ thực hiện đầy đủ hoặc một phần cơ chế vai trò, cũng như lưu sự kiện kiểm toán ra đĩa, không được đảm bảo chỉ dựa vào đặc tả (OPC Foundation OPC UA security model). Cần xác nhận thao tác được phép hoặc bị từ chối với từng tài khoản thử nghiệm của hiện trường, chất lượng, bảo trì, IT/OT, đồng thời quy định điều kiện tiếp nhận về nơi lưu trữ, thời gian giữ, sao lưu và phát hiện chỉnh sửa đối với nhật ký kiểm toán.

Ngoài ra, ngay cả khi cần truy cập từ xa bởi nhà cung cấp, nên giới hạn phạm vi truy cập và quyền thao tác, đồng thời luôn lưu lại nhật ký truy cập. Ghi nhận thao tác trong quá trình bảo trì từ xa cũng cần được quản lý như một phần của dấu vết kiểm toán.

Chức năng sao lưu/khôi phục là không thể thiếu để bảo toàn ghi nhận khi xảy ra sự cố. Việc tích hợp quy trình lấy sao lưu định kỳ và kiểm tra tính toàn vẹn dữ liệu sau khi khôi phục (ví dụ kiểm tra phát lại dữ liệu xuất ra) sẽ giúp giảm thiểu tối đa rủi ro mất dữ liệu. Chức năng xuất dữ liệu cho phép xuất ghi nhận ra các định dạng như CSV hoặc PDF để phục vụ kiểm toán bên ngoài hoặc nộp cho khách hàng, nhưng khi xuất cũng cần làm rõ nguồn gốc dữ liệu (dữ liệu gốc, giá trị nội suy, khoảng thiếu dữ liệu).

Thời gian lưu trữ ghi nhận được xác định riêng biệt theo yêu cầu khách hàng, rủi ro quy trình hoặc sản phẩm. Ví dụ, đối với dược phẩm hoặc linh kiện độ tin cậy cao, có thể yêu cầu lưu trữ dài hạn nhiều năm, nhưng không phải ngành nào cũng có nghĩa vụ pháp lý như nhau. Việc thiết lập thời gian lưu trữ nên dựa trên vòng đời sản phẩm, hợp đồng khách hàng, chính sách chất lượng nội bộ, đồng thời tận dụng chức năng tự động xóa hoặc lưu trữ của hệ thống để cân bằng giữa gánh nặng vận hành và rủi ro.

Trong PART C tiếp theo, chúng tôi sẽ đi sâu hơn về các vấn đề thực tế khi triển khai/vận hành, điểm thiết kế theo rủi ro quy trình/sản phẩm, và ví dụ vận hành thực tiễn khi xem xét/kiểm toán.

Mẫu RFP: 12 Câu Hỏi Thực Tiễn

Khi xem xét triển khai hệ thống tự động ghi nhận nhiệt độ và độ ẩm, trong RFP (Yêu cầu đề xuất), điều quan trọng là phải đưa vào các yêu cầu cụ thể từ góc độ vận hành thực tế, kiểm toán và đảm bảo chất lượng, thay vì chỉ chú trọng đến thông số kỹ thuật hay giao diện dashboard. Dưới đây là 12 câu hỏi thực tiễn mà bạn nhất định phải xác nhận với nhà cung cấp để đảm bảo tính toàn vẹn của dữ liệu và kiểm soát rủi ro tại hiện trường.

1. Phương pháp và độ chính xác khi lấy dấu thời gian của dữ liệu ghi nhận

　Hệ thống sử dụng thời gian cục bộ của cảm biến, thời gian của máy chủ hay timestamp của OPC UA (Tài liệu 1)? Nếu có sai lệch thời gian, phương pháp hiệu chỉnh và ghi nhận được thực hiện như thế nào?

1. Quản lý lịch sử thay đổi dữ liệu và dấu vết kiểm toán

　Khi có sửa đổi, xóa hoặc nhập lại giá trị ghi nhận, hệ thống có ghi lại ai, khi nào, tại sao và bằng cách nào đã thay đổi để có thể xem lại sau này không (Tài liệu 3)?

1. Quy trình xử lý khi phát sinh giá trị bất thường hoặc báo động

　Khi có báo động, hệ thống thông báo như thế nào, cách xác nhận (acknowledge) báo động, ai và vào thời điểm nào đã xử lý được ghi nhận ra sao (6)?

1. Bảo toàn dữ liệu khi cảm biến hoặc kết nối bị ngắt

　Nếu cảm biến hoặc mạng bị ngắt tạm thời, phương pháp ghi nhận và phục hồi dữ liệu bị thiếu hoặc trễ được thực hiện như thế nào?

1. Phân biệt và ghi nhận dữ liệu trễ, dữ liệu buffer

　Khi cảm biến kết nối lại, có cờ riêng của ứng dụng để phân biệt dữ liệu đến muộn với giá trị thời gian thực không? Có thể xem riêng StatusCode về chất lượng giá trị không (Tài liệu 2)?

1. Lịch sử hiệu chuẩn và từ chối hiệu chuẩn sai

　Quản lý lịch sử hiệu chuẩn và chức năng tự động từ chối/ cảnh báo khi giá trị hiệu chuẩn nằm ngoài phạm vi quy định.

1. Lịch sử thay đổi ngưỡng (báo động) và phục hồi lại giá trị cũ

　Ghi nhận ai, khi nào, tại sao đã thay đổi ngưỡng báo động và quy trình phục hồi về giá trị cũ khi thiết lập sai.

1. Tái tạo báo cáo CSV/PDF và đảm bảo tính toàn vẹn

　Khi tái tạo báo cáo từ dữ liệu lịch sử để kiểm toán hoặc truy xuất lô, có đảm bảo trùng khớp với dữ liệu gốc không?

1. Chức năng tìm kiếm, trích xuất dữ liệu theo lô hoặc sản phẩm

　Có thể nhanh chóng trích xuất dữ liệu nhiệt độ, độ ẩm liên kết với lô sản xuất hoặc sản phẩm cụ thể không?

1. Tính nhất quán dữ liệu khi hệ thống gặp sự cố hoặc khởi động lại

　Sau khi phục hồi từ sự cố máy chủ hoặc mạng, hệ thống có thiết kế để không xảy ra mất dữ liệu hoặc ghi nhận trùng lặp không?

1. Quản lý quyền người dùng và nhật ký thao tác

　Có ghi nhận chi tiết ai đã thực hiện thao tác gì và giới hạn thao tác theo từng quyền không?

1. Đảm bảo truy xuất nguồn gốc đo lường (metrological traceability)

　Phương pháp quản lý chứng chỉ hiệu chuẩn và chuỗi truy xuất nguồn gốc của cảm biến (Tài liệu 9).

Những câu hỏi này là các yêu cầu cụ thể để hiện thực hóa “ghi nhận đầy đủ và có thể kiểm tra lại”, chứ không chỉ đơn thuần là “giám sát nhiệt độ, độ ẩm”. Hãy so sánh câu trả lời của nhà cung cấp và xác nhận xem có phù hợp với rủi ro thực tế và yêu cầu kiểm toán của nhà máy không.

So Sánh Đề Xuất Nhà Cung Cấp: Đánh Giá Qua Bộ Dữ Liệu Mẫu và Demo

Nhiều nhà cung cấp thường nhấn mạnh vào thiết kế dashboard hoặc đồ thị đẹp mắt, nhưng tính toàn vẹn của dữ liệu và khả năng xử lý sự cố thực tế không thể đánh giá chỉ qua giao diện. Khi so sánh sau khi nhận được phản hồi RFP, các phương pháp sau rất hiệu quả.

Kiểm Tra Bằng Bộ Dữ Liệu Mẫu

• Cung cấp dữ liệu thô thực tế từ cảm biến nhiệt độ, độ ẩm (bao gồm dữ liệu thiếu, bất thường, trễ) để nhập, ghi nhận và tạo báo cáo trên hệ thống của từng nhà cung cấp.
• Bao gồm các kịch bản cố ý ngắt cảm biến, lệch thời gian, phát sinh và phục hồi báo động để so sánh cách ghi nhận, hiển thị và lưu vết kiểm toán.

Thao Tác Thực Tế Trên Môi Trường Demo

• Yêu cầu nhà cung cấp trình diễn toàn bộ quy trình từ phát sinh báo động, xử lý, sửa đổi ghi nhận, tái tạo báo cáo để kiểm tra tính dễ sử dụng, dấu vết và tính nhất quán dữ liệu.
• Kiểm tra cả hành vi khi chuyển đổi quyền người dùng, thao tác sai hoặc thao tác không hợp lệ.

Thông qua các kiểm tra này, bạn có thể xác định hệ thống có đảm bảo “tính toàn vẹn và kiểm toán được của ghi nhận” chứ không chỉ đơn thuần là “giám sát”. Tham khảo thêm tại “Các điểm cần lưu ý khi chọn hệ thống giám sát nhiệt độ, độ ẩm (phiên bản nhà máy Thái Lan 2026)”.

Các Trường Hợp Kiểm Tra Chi Tiết FAT/SAT

Khi triển khai hệ thống, việc thiết kế các trường hợp kiểm tra chi tiết trong FAT (Factory Acceptance Test) và SAT (Site Acceptance Test) để giả lập các rủi ro thực tế là không thể thiếu.

1. Ngắt và Kết Nối Lại Cảm Biến

• Ngắt và kết nối lại cảm biến; kiểm tra khoảng thiếu dữ liệu, cờ đến muộn, thời điểm đo gốc và thời điểm hệ thống nhận dữ liệu vẫn được lưu sau khi phục hồi.

2. Lệch và Hiệu Chỉnh Dấu Thời Gian

• Cố ý làm lệch thời gian trên cảm biến, kiểm tra tính nhất quán với timestamp ghi nhận trên máy chủ và ghi nhận lịch sử hiệu chỉnh (Tài liệu 1).

3. Xử Lý Dữ Liệu Trễ, Dữ Liệu Buffer

• Kiểm tra giá trị nhận sau khi mất kết nối có được ghi và tìm kiếm như dữ liệu đến muộn hay không. Đồng thời kiểm tra riêng cách phân biệt giá trị thô và giá trị nội suy (Tài liệu 12).

4. Phát Sinh và Xác Nhận Báo Động (Acknowledge)

• Kiểm tra phát sinh báo động khi vượt ngưỡng, thao tác xác nhận báo động của người dùng và ghi nhận lịch sử (6).

5. Thay Đổi Giá Trị Ghi Nhận và Dấu Vết Kiểm Toán

• Thực hiện sửa đổi, xóa giá trị ghi nhận và kiểm tra xem giá trị trước/sau, người thực hiện, lý do, thời gian có được lưu vết kiểm toán không.

6. Từ Chối Giá Trị Hiệu Chuẩn Không Hợp Lệ

• Khi nhập giá trị hiệu chuẩn ngoài phạm vi quy định, hệ thống có tự động từ chối và cảnh báo không.

7. Tính Nhất Quán Dữ Liệu Sau Sự Cố Mạng

• Cưỡng chế dừng và khởi động lại máy chủ/mạng, kiểm tra có xảy ra mất dữ liệu hoặc ghi nhận trùng lặp không.

8. Tái Tạo Báo Cáo CSV/PDF, Tìm Kiếm Theo Lô

• Tái tạo báo cáo theo khoảng thời gian hoặc lô bất kỳ, kiểm tra có trùng khớp với dữ liệu gốc và chứng minh được khi kiểm toán không.

9. Thay Đổi Ngưỡng và Phục Hồi

• Thay đổi hoặc thiết lập sai ngưỡng, kiểm tra thao tác phục hồi về giá trị cũ và ghi nhận lịch sử.

10. Quyền Người Dùng và Nhật Ký Thao Tác

• Kiểm tra giới hạn thao tác theo từng quyền và lưu vết đầy đủ mọi thao tác.

(Hình 3: Danh sách các trường hợp kiểm tra chính của hệ thống tự động ghi nhận nhiệt độ, độ ẩm cần xác minh trong FAT/SAT)

Cần thực hiện đầy đủ các trường hợp kiểm tra này và xác nhận cùng lúc giữa các bộ phận hiện trường, đảm bảo chất lượng và IT để đảm bảo mọi ghi nhận, dấu vết kiểm toán và khả năng tái tạo báo cáo đều được đảm bảo. Tham khảo thêm về cơ chế ghi nhận dữ liệu chi tiết tại “Các điểm thực tiễn khi ghi nhận dữ liệu thiết bị đo lường (phiên bản nhà máy Thái Lan 2026)”.

Làm Rõ Ownership/RACI, Quản Lý Thay Đổi, Hiệu Chuẩn/Thay Thế, Cập Nhật Ngưỡng và Phục Hồi

Làm Rõ Ownership/RACI

Vận hành hệ thống tự động ghi nhận nhiệt độ, độ ẩm liên quan đến nhiều bộ phận: hiện trường, đảm bảo chất lượng, IT, bảo trì thiết bị. Hãy sử dụng ma trận RACI (Responsible, Accountable, Consulted, Informed) để phân chia vai trò như sau:

• Responsible (Chịu trách nhiệm thực hiện): Kiểm tra hàng ngày, xử lý báo động (nhân viên hiện trường)
• Accountable (Chịu trách nhiệm cuối cùng): Đảm bảo tính toàn vẹn ghi nhận, xử lý kiểm toán (bộ phận đảm bảo chất lượng)
• Consulted (Tư vấn): Cài đặt hệ thống, xử lý sự cố (IT, bảo trì thiết bị)
• Informed (Thông báo): Ban lãnh đạo, kiểm toán viên

Quản Lý Thay Đổi, Hiệu Chuẩn, Thay Thế

• Ghi nhận khi hiệu chuẩn/thay thế: Quản lý tập trung lịch sử hiệu chuẩn/thay thế cảm biến trên hệ thống, lưu kèm chứng chỉ hiệu chuẩn và thông tin truy xuất nguồn gốc (Tài liệu 9).
• Cập nhật ngưỡng và phục hồi: Mọi thay đổi ngưỡng báo động phải lưu lịch sử, có quy trình phục hồi ngay khi thiết lập sai.

Quản Lý Thay Đổi Trong Quá Trình Vận Hành

• Khi thay đổi cấu hình hệ thống hoặc cập nhật phần mềm, cần ghi nhận nội dung thay đổi, người thực hiện, lý do, thời gian và có quy trình phê duyệt trước.

Các Giai Đoạn Triển Khai, Tiêu Chí Nghiệm Thu, Các Điểm Cần Xác Nhận Với Nhà Cung Cấp

Các Giai Đoạn Triển Khai

1. Xác định yêu cầu, lập RFP: Làm rõ rủi ro hiện trường, yêu cầu kiểm toán
2. Chọn nhà cung cấp, kiểm tra demo: So sánh bằng dữ liệu mẫu, demo thực tế
3. FAT/SAT: Kiểm tra chi tiết theo các trường hợp kiểm tra
4. Triển khai hiện trường, đào tạo: Đào tạo thao tác, hoàn thiện quy trình vận hành
5. Vận hành chính thức, kiểm toán: Định kỳ rà soát ghi nhận, đáp ứng kiểm toán

Tiêu Chí Nghiệm Thu (Acceptance Criteria)

• Vượt qua tất cả các trường hợp kiểm tra FAT/SAT
• Đảm bảo tính toàn vẹn ghi nhận, dấu vết kiểm toán, khả năng tái tạo báo cáo
• Dữ liệu nhất quán trong mọi kịch bản vận hành: hiệu chuẩn, thay đổi ngưỡng, phục hồi sự cố
• Quản lý quyền người dùng, nhật ký thao tác đầy đủ

Các Điểm Cần Xác Nhận Với Nhà Cung Cấp

• Hệ thống hỗ trợ và quy trình phục hồi khi gặp sự cố
• Phương pháp quản lý chứng chỉ hiệu chuẩn, truy xuất nguồn gốc
• Quản lý thay đổi, thông báo trước khi cập nhật phần mềm
• Bảo toàn dữ liệu, sao lưu khi vận hành lâu dài

Từ Điển Dữ Liệu và Điều Kiện Biên Cần Quyết Định Trước Khi Triển Khai

Nếu dự kiến mở rộng liên kết dữ liệu sang các công đoạn sau, cần định nghĩa riêng mã định danh không đổi và tên hiển thị cho từng điểm đo, thay vì chỉ dùng tên điểm đo. Ví dụ, nếu tên kho thay đổi do cải tiến hiện trường, cần lưu lịch sử liên kết giữa ID thiết bị, ID vùng, ID cảm biến để không làm dữ liệu cũ bị hiểu nhầm là điểm đo khác. Khi thay cảm biến, từ ngày thay sẽ chuyển sang ID cảm biến mới, nhưng vẫn tham chiếu theo chuỗi thời gian của cùng một vùng, đồng thời đánh dấu ranh giới thay đổi. Phân biệt rõ giá trị nào là đo vật lý, giá trị nào là tính toán để hiển thị. Nếu không cung cấp từ điển này khi mua sắm, mỗi nhà cung cấp sẽ dùng đơn vị, mức ID khác nhau, sau này không thể tích hợp tìm kiếm theo lô.

Cũng cần làm rõ điểm phát sinh ghi nhận. Nếu cảm biến có thời gian đo, logger gán thời gian khi nhận, hay gateway gán khi nhập, thì ý nghĩa trường “thời gian” sẽ khác nhau. Để đối chiếu thời gian lưu lô sau này, cần quy định phương pháp đồng bộ đồng hồ, cách giám sát độ chính xác và lệch thời gian, cách xử lý khi phát hiện lệch. OPC UA có timestamp nguồn và máy chủ, nhưng không phải thiết bị nào cũng lưu cả hai. Nên lấy mẫu ghi nhận thực tế trong FAT để xác nhận timestamp nào thể hiện sự kiện đo.

Kết nối với lô cũng không nên chỉ dựa vào “cùng ở trong một phút”. Cần xác nhận có lấy được sự kiện nhập/xuất kho, đưa vào/rút khỏi thiết bị, tạm dừng/tiếp tục lệnh sản xuất không. Nếu thiếu thời gian ranh giới, không thể thu hẹp phạm vi ảnh hưởng. Bộ phận chất lượng nên đặt phạm vi giả định bảo thủ và quy trình xác nhận lại bằng ghi nhận hiện trường để tránh hệ thống đánh giá sai là an toàn. Kết quả đo và sự kiện lô có thể nằm ở hai hệ thống khác nhau, nên ngoài màn hình truy vấn, cần đảm bảo có thể quay lại bản ghi gốc của cả hai.

Ghi Nhận Thử Nghiệm Làm Bằng Chứng Nghiệm Thu

Trong tài liệu hướng dẫn thử nghiệm FAT, ngoài thao tác và kết quả mong đợi, cần lưu lại cấu hình thực tế khi thực hiện: loại cảm biến và firmware, phiên bản gateway và server, cài đặt thời gian, phương thức kết nối, quyền tài khoản test, phiên bản ngưỡng. Ngay cả cùng một thử nghiệm “ngắt mạng”, kết quả sẽ khác nếu ngắt giữa cảm biến và gateway hay giữa gateway và server. Ảnh chụp màn hình thử nghiệm không đủ để giải thích sự trùng khớp với dữ liệu gốc, nên cần lưu cùng lúc ID sự kiện thử nghiệm, file xuất dữ liệu, nhật ký thao tác.

Ở SAT, thử nghiệm trên tòa nhà và vận hành thực tế: xác nhận cảm biến lắp đúng vị trí, tên thiết bị khớp với hiển thị, báo động không bị bỏ qua khi bàn giao ca. Khi có sự cố mạng, kiểm tra hiện trường phát hiện bất thường thế nào, thông tin gì chuyển cho người phục hồi, ai sẽ rà soát thời gian mất dữ liệu sau này. Nghiệm thu không chỉ dừng ở “có giá trị trên màn hình”, mà phải đảm bảo với lô và khoảng thời gian chỉ định, người khác có thể tái dựng lại giá trị gốc, bất thường, xử lý, trạng thái hiệu chuẩn.

Sau khi vận hành, các thao tác như tháo điểm đo khi hiệu chuẩn, thay cảm biến, thay đổi ngưỡng đều làm thay đổi ngữ cảnh ghi nhận. Phiếu thay đổi cần ghi rõ lý do, người phê duyệt, thời gian áp dụng, phạm vi thiết bị/sản phẩm bị ảnh hưởng, cấu hình trước/sau, quy trình phục hồi. Dù dấu vết kiểm toán có trong phần mềm, nếu không liên kết với ghi nhận giấy tại hiện trường thì chuỗi giải thích sẽ bị đứt. Nên quy định rõ từng bộ phận chất lượng, bảo trì, IT/OT, sản xuất phải lưu lại những ghi nhận nào, và định kỳ thử truy vết một sự kiện thực tế để kiểm tra.

FAQ (Câu Hỏi Thường Gặp)

Q1. Khác biệt giữa hệ thống giám sát nhiệt độ, độ ẩm và hệ thống tự động ghi nhận là gì?

A. Hệ thống giám sát chủ yếu để nắm bắt trạng thái thời gian thực, còn hệ thống tự động ghi nhận thì lưu lại đầy đủ “ai, khi nào, bằng cách nào” đã ghi nhận, sửa đổi, xử lý với dấu vết kiểm toán, cho phép kiểm tra và chứng minh lại sau này – đây là điểm khác biệt cốt lõi.

Q2. Có bắt buộc phải tuân thủ yêu cầu về tính toàn vẹn dữ liệu của FDA không?

A. Hướng dẫn về tính toàn vẹn dữ liệu của FDA chỉ áp dụng cho CGMP dược phẩm tại Mỹ. Luật áp dụng, hợp đồng, yêu cầu khách hàng cần xác nhận riêng cho từng sản phẩm và đối tác. Các khái niệm về dấu vết kiểm toán ở đây không mặc nhiên là nghĩa vụ pháp lý cho mọi nhà máy Thái Lan.

Q3. Làm sao đảm bảo tính nhất quán ghi nhận khi hiệu chuẩn hoặc thay cảm biến?

A. Quản lý tập trung lịch sử hiệu chuẩn/thay thế trên hệ thống, liên kết chứng chỉ hiệu chuẩn và thông tin truy xuất nguồn gốc (Tài liệu 9) để chứng minh tính hợp lệ khi kiểm toán.

Q4. Nếu có sửa đổi hoặc thao tác sai với dữ liệu ghi nhận, phát hiện như thế nào?

A. Mọi thao tác sửa đổi/xóa dữ liệu đều phải lưu lại người thực hiện, lý do, thời gian dưới dạng dấu vết kiểm toán, cho phép kiểm tra và truy vết sau này (Tài liệu 3).

Q5. Khi hệ thống gặp sự cố hoặc mất mạng, dữ liệu ghi nhận sẽ ra sao?

A. Nếu thiết bị có chức năng lưu cục bộ và gửi lại sau khi phục hồi, có thể thiết kế để nhận diện dữ liệu trễ. Nếu không có, cần ghi rõ dữ liệu thiếu và không dùng giá trị ước đoán để lấp chỗ trống. Cần kiểm tra thực tế trên thiết bị và cấu hình mạng trong FAT/SAT.

Tổng Kết & Liên Hệ TOMAS TECH

Việc lựa chọn và triển khai hệ thống tự động ghi nhận nhiệt độ, độ ẩm đòi hỏi chuyển đổi từ “giám sát” sang “ghi nhận đầy đủ, có thể kiểm tra lại”. Để đáp ứng rủi ro hiện trường và kiểm toán chất lượng, cần làm rõ yêu cầu thực tiễn ngay từ RFP, so sánh nghiêm ngặt đề xuất nhà cung cấp bằng dữ liệu mẫu và demo thực tế.

Khi liên hệ với TOMAS TECH, vui lòng chia sẻ quy trình cần áp dụng, cảm biến hiện có, ví dụ ghi nhận, vị trí thông tin lô, thời điểm dự kiến mua sắm. Chúng tôi sẽ hỗ trợ làm rõ yêu cầu và các điểm cần xác nhận về kết nối, vận hành tại hiện trường.

Để được tư vấn chi tiết, khảo sát hiện trường hoặc yêu cầu demo, vui lòng liên hệ qua Biểu mẫu liên hệ TOMAS TECH.

Tài Liệu Tham Khảo

1. https://reference.opcfoundation.org/specs/OPC-10000-11/4.5
2. https://reference.opcfoundation.org/specs/OPC-10000-11/6
3. https://reference.opcfoundation.org/specs/OPC-10000-11/4.4
4. https://reference.opcfoundation.org/specs/OPC-10000-9/5.7.3
5. https://www.vaisala.com/en/products/software/viewlinc
6. https://docs.vaisala.com/r/M212315EN-C/en-US/GUID-E738FA55-CB57-4BE6-8331-C811E10AB988/GUID-46424254-8FC3-4883-AEA9-2946CD88252F/GUID-8A1D9588-D668-45FD-8662-C7F01317869A
7. https://www.vaisala.com/sites/default/files/documents/viewLinc-Continuous-Monitoring-System-Brochure-B211555EN.pdf
8. https://www.vaisala.com/en/blog/2023-07/temperature-mapping-study-design-duration-intervals
9. https://www.nist.gov/metrology/metrological-traceability
10. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers
11. https://reference.opcfoundation.org/specs/OPC-10000-2/4
12. https://reference.opcfoundation.org/specs/OPC-10000-11/6.5.5.2