Khi tìm hiểu giải pháp phát hiện cháy bằng camera IP, doanh nghiệp thường được xem demo. Theo đó, nhà cung cấp sử dụng một đoạn video quay sẵn có cảnh khói/ lửa, và phần mềm AI sẽ tiến hành phân tích và khoanh vùng những điểm có dấu hiệu khói/lửa. Những đoạn video đó thường rõ nét, đủ sáng dễ dàng nhận thấy. Camera trong nhà máy/xưởng sản xuất/kho thì khác: góc quay xa, ca đêm thiếu sáng, có hơi nước, bụi bay. Vì vậy demo chưa cho biết hệ thống có dùng được ở nhà máy của mình hay không. Trước khi đầu tư, doanh nghiệp cần biết thêm ba điều:
- AI có nhận ra khói/lửa trên chính camera của nhà máy mình không?
- Cảnh báo tới điện thoại người phụ trách sau bao lâu?
- Hơi nước, bụi có làm hệ thống báo nhầm không?
Để trả lời ba câu này, doanh nghiệp cần chạy thử nghiệm thực tế (PoC) cho giải pháp phát hiện cháy bằng camera IP trước khi quyết định đầu tư.
PoC (Proof of Concept) là giai đoạn chạy thử phần mềm AI phát hiện khói/lửa ngay trên camera và nhà xưởng của doanh nghiệp, trước khi quyết định triển khai. Mục tiêu và cách chấm điểm được hai bên thống nhất từ đầu. Trong lúc thử, doanh nghiệp cần đo 7 điều: phát hiện được bao nhiêu, bỏ sót những gì, cảnh báo nhanh hay chậm, có báo nhầm không, xử lý thế nào khi camera mất tín hiệu, cảnh báo có tới đúng người không, và hệ thống có chạy ổn định khi bật nhiều camera cùng lúc không.
PoC phát hiện cháy bằng camera IP triển khai thế nào? Demo phát hiện khói/lửa đã đủ chưa?
Video demo chỉ chứng minh AI có thể nhận ra khói/lửa. PoC mới cho biết AI hoạt động tốt đến đâu trên camera và nhà xưởng của anh chị, kèm số liệu đo được và cả những trường hợp hệ thống chưa xử lý tốt. Nhờ đó, anh chị có đủ căn cứ để đánh giá hiệu quả trước khi quyết định triển khai.
Phân biệt demo, PoC và nghiệm thu triển khai
| Giai đoạn | Câu hỏi cần trả lời | Đầu ra |
|---|---|---|
| Demo | Giải pháp có thể nhận diện dấu hiệu khói/lửa không? | Minh họa năng lực |
| PoC | Giải pháp đáp ứng yêu cầu đến đâu trong phạm vi thử nghiệm của doanh nghiệp? | Kết quả đo, giới hạn và điều kiện áp dụng |
| Nghiệm thu triển khai | Hệ thống bàn giao có đáp ứng các tiêu chí đã thỏa thuận không? | Biên bản và bằng chứng đối chiếu |
Vuốt ngang để xem đầy đủ nội dung bảng.
Cách phân biệt này dùng để làm rõ khái niệm trong bài viết. Phạm vi thực tế của từng giai đoạn tùy theo thỏa thuận của mỗi dự án.
PoC cần kiểm chứng cả chuỗi từ camera đến người nhận
Hình ảnh camera → AI phát hiện → Xác nhận sự kiện → Gửi cảnh báo → Người phụ trách tiếp nhận
Nhận ra khói/lửa trên màn hình mới kiểm chứng một mắt xích đầu tiên. Một hệ thống nhận diện tốt vẫn có thể không tạo ra giá trị nếu bước xác nhận quá chậm, cảnh báo gửi sai người hoặc thiếu thông tin để xác minh.
Với CW AI FireVision, chuỗi này gồm: phần mềm nhận luồng video từ camera IP, mô hình AI xác định vùng nghi ngờ, hệ thống theo dõi diễn biến và đánh giá rủi ro trước khi chuyển sự kiện sang trạng thái Confirmed, rồi gửi cảnh báo kèm camera, vị trí, thời gian, mức độ nguy hiểm, ảnh chụp và video tới người phụ trách. PoC cần đo được từng mắt xích.
Trước khi lập kế hoạch thử nghiệm, doanh nghiệp nên xác định điều kiện triển khai AI phát hiện khói/lửa trên camera IP hiện có.
Trước khi chạy PoC, cần thống nhất phạm vi và điều kiện nào?
Trước khi chạy PoC, cần chốt ba việc: thử ở khu vực nào, với những camera nào; dùng cấu hình nào (ghi lại để đối chiếu sau này); và kết quả thế nào thì được coi là đạt. Cả ba phải thống nhất trước khi xem kết quả, để PoC là một bài kiểm tra có tiêu chí rõ ràng, không chỉ là một buổi demo kéo dài.
Chọn khu vực thử theo rủi ro và điều kiện quan sát
Khu vực thử nên là nơi có rủi ro thật và đại diện cho điều kiện sẽ triển khai sau này. Cần ghi rõ:
• Khu vực cần giám sát và dấu hiệu mong muốn phát hiện (khói, lửa hay cả hai).
• Camera được dùng, góc nhìn, khoảng cách tới vùng rủi ro, vật cản và ánh sáng.
• Điều kiện ngày/đêm, ca sản xuất và các nguồn nhiễu thường gặp tại khu vực.
• Phạm vi nằm ngoài khả năng quan sát của camera hoặc ngoài phạm vi đánh giá lần này.
Ghi lại cấu hình để kết quả có thể đối chiếu
Kết quả PoC chỉ có ý nghĩa khi biết nó được tạo ra trong cấu hình nào. Cần lưu: camera ID, độ phân giải, tốc độ khung hình đầu vào và xử lý, vùng giám sát, cấu hình máy chủ, phiên bản phần mềm và mô hình, ngưỡng cảnh báo. Với FSM-AI, cần ghi thêm thời gian xác thực và ngưỡng rủi ro đã cấu hình cho từng camera.
Nếu thay đổi cấu hình trong quá trình PoC, phải đánh dấu thời điểm thay đổi và đánh giá riêng kết quả trước và sau.
Chốt tiêu chí đạt trước khi xem kết quả
Mỗi tiêu chí cần đủ sáu thành phần:
Chỉ số → Cách đo → Ngưỡng mục tiêu → Điều kiện áp dụng → Bằng chứng → Người xác nhận
Không có một mức “đạt chuẩn” chung cho mọi nhà máy. Phòng điện cần ưu tiên cảnh báo sớm, trong khi khu nhiều hơi nước có thể ưu tiên hạn chế báo giả. Ngưỡng cần được thống nhất theo rủi ro và yêu cầu vận hành của từng khu vực.
Xây dựng bộ tình huống kiểm thử PoC như thế nào?
Bộ thử cần ba nhóm tình huống: có dấu hiệu khói/lửa, không cháy nhưng dễ gây nhầm, và lỗi hạ tầng. Thiếu bất kỳ nhóm nào, kết quả PoC sẽ chỉ phản ánh một phần hiệu quả thực tế.
Tình huống có dấu hiệu khói/lửa
Bao phủ các điều kiện nằm trong phạm vi đã thống nhất: vị trí xuất hiện trong khung hình, khoảng cách tới camera, kích thước dấu hiệu trong ảnh, ánh sáng và mức độ bị che khuất.
Tình huống không cháy nhưng dễ gây nhầm
Ví dụ: hơi nước, bụi, sương, ánh hàn, phản xạ hoặc ánh đèn. Nên chọn theo môi trường thực tế của khu vực thử, thay vì dùng một danh sách chung. Có thể tham khảo các nguồn nhiễu và cơ chế hạn chế cảnh báo giả của FSM-AI để xây dựng nhóm tình huống không cháy.
Tình huống lỗi hạ tầng và gián đoạn vận hành
Mất luồng video, hình ảnh đóng băng, mất kết nối kênh cảnh báo, khởi động lại máy chủ và khôi phục kết nối.
Cần phân biệt rõ hai cách thử:
• Video ghi sẵn: kiểm tra thuật toán trên dữ liệu xác định, có thể lặp lại để so sánh cấu hình.
• Luồng trực tiếp: kiểm tra thêm độ trễ và vận hành toàn chuỗi, từ camera tới người nhận.
Không dùng kết quả từ video phát lại để đại diện cho toàn bộ hiệu quả thực địa. Các tình huống thử phải được tổ chức an toàn và được bộ phận phụ trách an toàn của doanh nghiệp phê duyệt.
7 tiêu chí cần đo khi PoC AI phát hiện khói/lửa
Bảy tiêu chí gồm khả năng phát hiện, sự kiện bỏ sót, độ trễ cảnh báo, cảnh báo giả, phát hiện mất luồng, tiếp nhận cảnh báo và độ ổn định khi chạy tải thực tế. Mỗi tiêu chí cần có cách đo và bằng chứng đi kèm.
| Tiêu chí | Cách đánh giá đề xuất | Bằng chứng cần lưu |
|---|---|---|
| 1. Khả năng phát hiện | Số sự kiện hợp lệ được phát hiện / tổng số sự kiện hợp lệ trong bộ thử | Video gốc, nhãn sự kiện, log |
| 2. Sự kiện bỏ sót | Liệt kê sự kiện không được phát hiện; phân tích theo điều kiện | Clip, cấu hình, nguyên nhân |
| 3. Độ trễ cảnh báo | Đo từ dấu hiệu nhìn thấy trên video đến lúc tạo sự kiện và lúc cảnh báo tới nơi nhận | Timestamp đồng bộ |
| 4. Cảnh báo giả | Số sự kiện cảnh báo giả trên tổng camera-giờ giám sát hợp lệ | Log đã phân loại, thời gian quan sát |
| 5. Phát hiện mất luồng | Thời gian nhận biết gián đoạn, thông báo lỗi và khả năng phục hồi | Nhật ký lỗi, thời điểm khôi phục |
| 6. Tiếp nhận cảnh báo | Cảnh báo đến đúng nơi nhận, có đủ thông tin và ghi nhận xác nhận | Log gửi/nhận, ảnh giao diện |
| 7. Độ ổn định khi chạy tải thực tế | Theo dõi số luồng, tài nguyên, gián đoạn và thay đổi độ trễ | Log vận hành, cấu hình máy chủ |
Vuốt ngang để xem đầy đủ nội dung bảng.
1. Đo khả năng phát hiện theo sự kiện
Cần định nghĩa trước thế nào là một sự kiện hợp lệ và cửa sổ thời gian được tính là phát hiện thành công. Đếm theo sự kiện, không đếm theo từng khung hình. Nếu bộ thử có các nhóm khác nhau, tách kết quả khói và lửa, ngày và đêm, vì một tỷ lệ gộp chung có thể che mất điểm yếu.
2. Phân tích sự kiện bỏ sót
Không chỉ ghi một tỷ lệ tổng. Với từng sự kiện bị bỏ sót, cần chỉ ra nó xảy ra ở đâu, trong điều kiện nào, và có thể khắc phục bằng chỉnh camera, chỉnh cấu hình hay cần bổ sung giải pháp khác. Đây thường là phần mang lại nhiều thông tin nhất cho quyết định triển khai.
3. Đo độ trễ từ thời điểm nào?
Độ trễ là khoảng thời gian từ lúc khói/lửa xuất hiện trên camera đến lúc người phụ trách biết có sự cố. Để biết chậm ở khâu nào, hãy chia quãng thời gian này thành 4 mốc:
| Mốc | Chuyện gì xảy ra | Ví dụ dễ hình dung |
|---|---|---|
| T0 – Khói xuất hiện | Khói/lửa bắt đầu nhìn thấy được trên video (hai bên thống nhất cách xác định) | Làn khói đầu tiên hiện ra ở góc kho |
| T1 – Phần mềm xác nhận | Phần mềm xác nhận đây là sự cố và tạo cảnh báo | Hệ thống chuyển sự kiện sang trạng thái “đã xác nhận” |
| T2 – Cảnh báo tới nơi | Cảnh báo hiện lên điện thoại hoặc máy tính người nhận | Điện thoại bảo vệ trực đổ thông báo |
| T3 – Người nhận phản hồi | Người phụ trách bấm xác nhận đã xem | Bảo vệ bấm “đã nhận” |
Vuốt ngang để xem đầy đủ nội dung bảng.
Lưu ý T0 không đồng nghĩa với thời điểm đám cháy thực sự bắt đầu. Cần đồng bộ đồng hồ giữa các hệ thống hoặc xác định sai lệch thời gian trước khi đo, và báo cáo cả phân bố độ trễ thay vì chỉ chọn lần nhanh nhất.
Với hệ thống có bước xác nhận như FSM-AI, T1 là lúc sự kiện chuyển sang Confirmed. Vì vậy T1 − T0 bao gồm cả thời gian xác thực mà doanh nghiệp cấu hình, và nên được đọc cùng kết quả cảnh báo giả để thấy rõ sự đánh đổi giữa tốc độ và độ chắc chắn.
Từ 4 mốc này, đo được 3 khoảng thời gian, mỗi khoảng trả lời một câu hỏi:
• Từ T0 đến T1: phần mềm mất bao lâu để nhận ra và xác nhận sự cố?
• Từ T0 đến T2: từ lúc có khói đến lúc người phụ trách nhận được cảnh báo mất bao lâu? Đây là con số quan trọng nhất.
• Từ T2 đến T3: người nhận phản hồi nhanh hay chậm? Khoảng này đánh giá quy trình của con người, không phải phần mềm.
Khi đo, cần lưu ý:
• T0 là lúc khói nhìn thấy được trên camera, không phải lúc đám cháy thật sự bắt đầu.
• Đồng hồ trên camera, máy chủ và điện thoại phải khớp giờ trước khi đo, nếu không kết quả sẽ sai.
• Ghi lại kết quả của tất cả các lần thử, không chỉ chọn lần nhanh nhất.
• Với CW AI FireVision, khoảng T0 đến T1 bao gồm cả thời gian hệ thống theo dõi thêm để xác nhận, do doanh nghiệp tự cấu hình. Nên đọc con số này cùng kết quả báo nhầm: xác nhận nhanh hơn thì cảnh báo sớm hơn, nhưng cũng dễ báo nhầm hơn.
4. Đo cảnh báo giả theo camera-giờ
Cảnh báo giả/camera-giờ = Tổng sự kiện cảnh báo giả ÷ Tổng giờ giám sát hợp lệ của các camera
Ví dụ cách đọc: 5 camera chạy 10 giờ hợp lệ tương ứng 50 camera-giờ. Cần quy định cách gộp các thông báo lặp của cùng một sự kiện, để một lần nhiễu kéo dài không bị đếm thành nhiều cảnh báo giả. Không có báo giả trong một khoảng thử ngắn không đồng nghĩa với không bao giờ báo giả.
5. Kiểm tra mất luồng và khôi phục
Phân biệt mất video, video đóng băng và mất internet, vì mỗi loại ảnh hưởng khác nhau. Đánh giá riêng khả năng phân tích nội bộ và khả năng gửi thông báo qua từng kênh. Với FSM-AI, mỗi camera được xử lý độc lập, nên PoC nên kiểm tra thêm: khi một luồng gặp sự cố, các camera còn lại có tiếp tục được phân tích bình thường hay không.
6. Kiểm tra cảnh báo có đến đúng người không
Kiểm tra từng cảnh báo có đủ camera/vị trí, thời gian, hình ảnh hoặc clip, trạng thái gửi và xác nhận hay không, và có đến đúng người theo khu vực, ca trực đã cấu hình không. Nếu có cơ chế chuyển cấp khi người nhận đầu tiên không phản hồi, đưa cơ chế này vào phạm vi thử.
7. Kiểm tra độ ổn định với số camera dự kiến
Chạy đồng thời số luồng dự kiến triển khai, theo dõi tài nguyên xử lý của máy chủ, độ trễ và các lần gián đoạn. Kết quả cần nêu rõ thời gian và điều kiện quan sát. Một hệ thống chạy tốt với vài camera chưa chắc giữ được độ trễ khi số luồng tăng lên.
Hồ sơ PoC cần có những bằng chứng nào?
Hồ sơ PoC cần đủ sáu tài liệu: protocol thử nghiệm, danh mục bộ thử, nhật ký thực thi, bằng chứng đối chiếu, danh sách loại trừ và báo cáo kết luận. Thiếu hồ sơ, kết quả PoC khó được tin cậy khi trình lên ban giám đốc.
| Tài liệu | Nội dung tối thiểu |
|---|---|
| Protocol thử nghiệm | Mục tiêu, phạm vi, kịch bản, cách đo, tiêu chí đạt |
| Danh mục bộ thử | Mã tình huống, nguồn video, nhãn, điều kiện, phân nhóm |
| Nhật ký thực thi | Timestamp, cấu hình, phiên bản, kết quả từng lần |
| Bằng chứng đối chiếu | Video gốc, log, ảnh/clip cảnh báo |
| Danh sách loại trừ | Trường hợp loại trừ và lý do; thống nhất trước khi tổng hợp |
| Báo cáo kết luận | Kết quả, hạn chế, việc cần chỉnh và khuyến nghị triển khai |
Vuốt ngang để xem đầy đủ nội dung bảng.
Không loại các ca khó sau khi đã thấy kết quả để làm đẹp số liệu. Nếu cấu hình được điều chỉnh trong PoC, cần đánh giá lại trên dữ liệu chưa dùng để tinh chỉnh khi có thể, tránh tình trạng cấu hình chỉ tốt trên đúng bộ thử đã biết trước.
Với FSM-AI, ảnh chụp và video cảnh báo được trích xuất từ khung hình gốc, tách khỏi lớp hiển thị có khung đánh dấu, nên có thể dùng trực tiếp làm bằng chứng đối chiếu trong hồ sơ.
Khi nào nên triển khai, điều chỉnh hoặc kéo dài PoC?
Triển khai khi đạt tiêu chí và đã có quy trình tiếp nhận; điều chỉnh khi vấn đề xác định được nguyên nhân; kéo dài khi chưa đủ dữ liệu cho điều kiện quan trọng. Kết quả PoC chỉ áp dụng cho phạm vi đã kiểm chứng.
| Kết luận đề xuất | Căn cứ |
|---|---|
| Triển khai trong phạm vi đã kiểm chứng | Đạt tiêu chí, đủ bằng chứng và có quy trình tiếp nhận |
| Điều chỉnh rồi kiểm thử lại | Có vấn đề xác định được về camera, cấu hình hoặc kênh cảnh báo |
| Bổ sung thời gian hoặc tình huống thử | Chưa đủ dữ liệu cho ca đêm, nguồn nhiễu hoặc điều kiện quan trọng |
| Chưa phù hợp tại khu vực đang xét | Điều kiện quan sát hoặc kết quả không đáp ứng yêu cầu sau đánh giá |
Vuốt ngang để xem đầy đủ nội dung bảng.
Kết quả PoC tại một khu vực không tự động đại diện cho khu vực khác có điều kiện quan sát khác. AI phân tích hình ảnh là lớp hỗ trợ cảnh báo; không dùng kết quả PoC để tuyên bố thay thế hệ thống PCCC.
Bắt đầu PoC CW AI FireVision trên camera IP hiện có như thế nào?
Qua bốn bước: khảo sát camera và khu vực ưu tiên, thống nhất phạm vi và tiêu chí, triển khai thử và ghi nhận bằng chứng, rồi đối chiếu kết quả để chọn phương án tiếp theo.
1. Khảo sát camera và khu vực ưu tiên. Xác định camera dùng được ngay, camera cần chỉnh và khu vực có rủi ro cao nhất.
2. Thống nhất phạm vi, tình huống và tiêu chí đánh giá. Chốt bộ thử, cách đo và ngưỡng đạt cho từng khu vực.
3. Triển khai thử, ghi nhận bằng chứng. Kết nối CW AI FireVision với luồng video của camera đã chọn, chạy các tình huống và lưu nhật ký theo protocol.
4. Đối chiếu kết quả và xác định phương án tiếp theo. Triển khai, điều chỉnh, kéo dài hoặc dừng tại khu vực đang xét.
Doanh nghiệp có thể tìm hiểu giải pháp CW AI FireVision phát hiện và cảnh báo khói/lửa trước khi thống nhất cấu hình và phạm vi thử nghiệm.
AI CAMERA READINESS ASSESSMENT
Camera hiện có của doanh nghiệp đã sẵn sàng cho PoC?
Đặt lịch để CO-WELL Asia khảo sát và đánh giá hệ thống camera hiện hữu, cũng như tư vấn khu vực ưu tiên, kiến trúc sơ bộ theo nhu cầu của doanh nghiệp. và phạm vi PoC phù hợp.
- Đánh giá camera hiện có
- Xác định khu vực ưu tiên
- Đề xuất kiến trúc và phạm vi PoC
CW AI FireVision là lớp phát hiện sớm bằng hình ảnh, bổ sung bên cạnh hệ thống PCCC hiện hữu, không thay thế các thiết bị và quy trình PCCC bắt buộc theo quy định của cơ quan chức năng.
Câu hỏi thường gặp về PoC camera AI phát hiện khói/lửa
Demo phát hiện được lửa đã đủ nghiệm thu chưa?
Chưa đủ để kết luận hiệu quả vận hành. Demo chỉ cho thấy khả năng nhận diện. Doanh nghiệp cần kiểm tra thêm phạm vi áp dụng, báo giả, sự kiện bỏ sót, độ trễ và việc cảnh báo có đến đúng người hay không.
Đo độ trễ cảnh báo từ lúc nào?
Từ lúc dấu hiệu khói/lửa bắt đầu nhìn thấy được trong video, theo quy tắc gán nhãn đã thống nhất. Nên tách hai mốc: lúc hệ thống tạo sự kiện và lúc cảnh báo đến nơi nhận, để biết độ trễ nằm ở phần phân tích hay phần truyền tin.
PoC cần chạy bao lâu?
Phụ thuộc vào các điều kiện cần bao phủ (ngày/đêm, ca sản xuất, nguồn nhiễu) và lượng bằng chứng cần thu thập. Không nên áp một số ngày chung cho mọi dự án; thời lượng nên được chốt cùng phạm vi và tiêu chí.
Có thể PoC bằng video ghi sẵn không?
Có thể dùng cho một phần kiểm thử, đặc biệt khi cần lặp lại để so sánh cấu hình. Tuy nhiên vẫn cần thử trên luồng trực tiếp để đánh giá độ trễ và vận hành toàn chuỗi từ camera tới người nhận.
Chạy PoC không thấy báo nhầm lần nào, vậy sau này hệ thống có chắc chắn không báo nhầm?
Chưa chắc. Có thể trong thời gian thử, hệ thống chưa gặp đủ các tình huống dễ gây nhầm như hơi nước, bụi hay ánh hàn. Vì vậy khi kết luận về báo nhầm, cần ghi rõ đã thử bao lâu, trên bao nhiêu camera và với những nguồn nhiễu nào.
Đạt PoC có thể mở rộng ngay cho toàn bộ camera không?
Chưa nên. Kết quả PoC chỉ áp dụng cho phạm vi đã kiểm chứng. Trước khi mở rộng, cần đánh giá các camera mới, tải xử lý của máy chủ và điều kiện quan sát ở các khu vực chưa thử.
