Hệ thống dừng lại vào ngày bàn giao — vì sao chúng tôi tự làm nền tảng điều hành

Ngày quan trọng nhất trong hợp đồng làm theo đặt hàng là ngày bàn giao. Tổng hợp yêu cầu, phát triển, nghiệm thu đạt — hệ thống hoàn thành vào ngày đó. Và thường thì nó cũng dừng lại vào chính ngày đó.

Nếu chữ "dừng lại" nghe có vẻ phóng đại, hãy nghĩ về một màn hình giám sát được dựng năm năm trước. Bố cục vẫn đúng như ngày nghiệm thu. Trong khoảng thời gian đó, hiện trường đã thêm dây chuyền, đổi chính sách ra vào, gắn thêm hai mươi camera. Chỉ có hệ thống là vẫn ở lại năm 2021. Muốn dịch một cái nút cũng phải xin báo giá trước, mà công ty làm ra nó thì đã sang dự án khác từ lâu.

Đó là mức mặc định của ngành giám sát dựa trên vị trí. Ban đầu chúng tôi cũng làm theo cách đó.

"Câu chuyện ORBRO OS" là tập bài viết về việc chúng tôi đã thoát ra khỏi mức mặc định đó như thế nào. Bài này nói về lựa chọn nằm dưới cùng: thay vì làm một hệ thống cho từng dự án, tự xây một nền tảng.

I. Hệ thống dừng lại vào ngày bàn giao

Bản thân cách làm theo đặt hàng không sai. Nếu yêu cầu thực sự đặc thù thì phát triển riêng là đúng. Vấn đề là trong lĩnh vực giám sát dựa trên vị trí, phần lớn dự án thực chất đang làm lại cùng một thứ.

Một bộ máy vẽ vị trí lên bản đồ. Một màn hình để đăng ký thiết bị và xem trạng thái. Các quy tắc phát cảnh báo theo điều kiện. Một kho để tích dữ liệu và tra cứu. Những chức năng cùng bộ xương chỉ khác tên gọi được phát triển mới ở từng dự án, trở thành những mã nguồn không tương thích nhau và rải rác ở từng hiện trường.

Chi phí thực của cấu trúc này không phải phí phát triển. Đó là việc không hiện trường nào được chia phần cải tiến từ hiện trường khác. Tính năng tốt làm cho hiện trường A dừng lại ở hiện trường A. Cùng một lỗi phải sửa đúng bằng số hiện trường. Vài năm sau, bạn có mười hệ thống giống nhau nhưng không chia sẻ gì cả.

Tiêu chí	Phát triển riêng từng dự án	Nền tảng + ứng dụng (ORBRO OS)
Điểm bắt đầu	Mọi lần đều từ màn hình trống	Trên một lõi đã được kiểm chứng
Đáp ứng yêu cầu	Triển khai mới toàn bộ yêu cầu	Bật ứng dụng cần dùng, chỉ làm phần còn thiếu
Sau bàn giao	Hết hợp đồng là hết cập nhật	Cập nhật vẫn tiếp tục đến
Lan toả cải tiến	Chỉ áp dụng ở hiện trường đó	Thành tính năng chuẩn cho mọi khách hàng
Sửa lỗi	Lặp lại theo số hiện trường	Một lần, ngay tại lõi
Yêu cầu riêng của khách	Mổ lõi ra để sửa	Ứng dụng riêng trên API, lõi nguyên vẹn

Ở đây sẽ có một câu phản biện: "nền tảng dùng chung đó có vừa với hiện trường của chúng tôi không?" Một lo lắng chính đáng. Hai chương sau là câu trả lời.

II. "OS" không phải ẩn dụ, mà là kiến trúc

Đặt chứ OS vào tên là một quyết định thiết kế, không phải lối nói.

Ban đầu nó không như bây giờ. Màn hình thời đầu giống một web giám sát thông thường: có menu, bấm vào mục thì đổi trang. Chúng tôi bỏ menu đó đi và định nghĩa lại từng chức năng thành một ứng dụng có thể cài và xoá. Sau đó đặt thêm đa nhiệm và thanh tác vụ lên trên. Quyết định ấy là: biến màn hình giám sát thành một desktop, không phải một website.

Mở ORBRO OS bây giờ, địa chỉ trên trình duyệt gần như không đổi. Thay vào đó, các cửa sổ mở ra bên trong màn hình, chồng lên nhau và xếp vào thanh tác vụ. Bạn có thể đang xem vị trí tài sản trên bản đồ, mở thêm cửa sổ lịch sử ra vào, rồi chồng tiếp một cửa sổ camera lên. Không phải website để chuyển trang, mà là một desktop để đặt ứng dụng lên.

Lý do cấu trúc này quan trọng nằm dưới màn hình, không phải ở màn hình. Giống như hệ điều hành trừu tượng hoá phần cứng để ứng dụng không cần biết phần cứng, ORBRO OS trừu tượng hoá hạ tầng định vị và dữ liệu. Ứng dụng không cần biết có bao nhiêu anchor hay camera là model gì. Nghĩa là khi làm một tính năng mới, không phải làm lại bản đồ, xác thực và cảnh báo. Nhờ vậy số ứng dụng tăng nhanh. Và nó đã tăng thật.

III. 22 ứng dụng — giám sát hoàn thiện bằng việc bật lên

Khi mua điện thoại, không ai mua một máy đã cài sẵn mọi ứng dụng. Có hệ điều hành, rồi ta chọn ứng dụng. ORBRO OS cũng vậy. Hiện có 22 ứng dụng trong 5 nhóm, và hiện trường chỉ bật thứ mình cần. Ứng dụng có thể bật tắt theo từng workspace, nên chức năng không dùng sẽ không hề xuất hiện trên màn hình.

Cơ bản (5) — Dashboard, Device Manager, Setting, 3D View, Weather. Bộ xương mà hiện trường nào cũng cần.

Định vị (10) — Zone Manager, Zone Counting, Zone Effect, In-out Tracking, Reverse Tracking, Alert Zone, Access, Heatmap, Timeline, Record. Nhóm dày nhất và là trái tim của nền tảng. Vẽ khu vực, đếm người và tài sản ra vào khu vực đó, lần lại đường đi đã qua. Công nghệ nền được trình bày ở trang giới thiệu RTLS.

AI (4) — AI Event, AI RTLS, Multi Cam, LPR. AI Event phát hiện trong hình camera các tình huống như không đội mũ bảo hộ, người ngã, cháy, xâm nhạp khu vực nguy hiểm, va chạm. Nó liên kết với sản phẩm edge AI Event Manager để việc phân tích hình ảnh diễn ra ngay trên thiết bị edge tại hiện trường.

Phân tích dữ liệu (2) — Scan Insight, Nearby Search. Tra cứu và phân tích dữ liệu vị trí và tín hiệu đã tích luỹ. Nếu giám sát là việc nhìn vào hiện tại, phía này là việc chuẩn bị cho tiếp theo.

Dịch vụ (1) — SOP. Khi điều kiện được thỏa, quy trình ứng phó đã định sẽ hiện lên màn hình. Ứng dụng khiến không ai phải đi tìm sổ tay khi sự việc xảy ra.

Cùng một nền tảng, nhà máy và toà nhà văn phòng bật những tổ hợp hoàn toàn khác nhau. Nhà máy đặt Alert Zone, AI Event, Zone Counting lên trước; văn phòng lấy Access, Heatmap, Dashboard làm trọng tâm. Ngay khi chọn xong ứng dụng, nền tảng dùng chung trở thành hệ thống giám sát riêng của hiện trường đó. Bằng cấu hình, không phải bằng phát triển.

IV. Yêu cầu của một hiện trường trở thành tính năng chuẩn của mọi người

Có một nguyên tắc chúng tôi giữ suốt quá trình xây nền tảng: hấp thu yêu cầu của khách hàng thành tính năng chuẩn bất cứ khi nào có thể. Nói thì dễ, nên xin dẫn ba trường hợp đã xảy ra thực.

Một khách hàng vận hành không gian triển lãm yêu cầu được báo ngay khi có người bước vào một khu vực nhất định. Tính năng làm cho yêu cầu đó không dừng lại ở dạng riêng cho khách, mà được mài thành một ứng dụng tên Alert Zone. Nay nó là một trong 22 ứng dụng và mọi khách hàng đều có.

Một khách hàng vận hành công trường xây dựng lớn muốn hệ thống tự đẩy quy trình ứng phó ra khi có sự việc. Từ đó sinh ra ứng dụng SOP. Các tích hợp cảm biến không dây gắn kèm — chất lượng không khí, khí gửa, rò nước, nút khẩn cấp — giờ cũng là tiêu chuẩn.

Một khách hàng vận hành bãi tập kết ngoài trời muốn quét mã vạch để nhập xuất vật liệu. Với một nền tảng định vị, mã vạch là yêu cầu xa lạ. Cái này cũng vào thành tiêu chuẩn. Quản lý tài sản bằng mã vạch và tích hợp máy quét PDA trở thành tính năng chính thức, và những khách hàng có kho khác dùng nguyên như vậy.

Cả ba trường hợp, khách đề xuất thì nhận được điều mình muốn, còn khách không đề xuất thì nhận được tính năng mình chưa từng đề xuất.

Tất nhiên có những yêu cầu không thể hấp thu. Màn hình chỉ tồn tại trong quy định nghiệp vụ của công ty đó, luồng phê duyệt chỉ tổ chức đó dùng. Khi đó chúng tôi không mổ lõi, mà đặt một ứng dụng riêng cho khách đó lên API mà nền tảng đã mở. Cách này giữ được đồng thời sự ổn định của lõi và tính đặc thù của hiện trường; nội bộ chúng tôi gọi đó là mô hình hybrid.

Lý do chúng tôi có thể chịu trách nhiệm cho cả cấu trúc này đến cùng là vì mọi tầng đều do chúng tôi làm. Phần cứng thẻ định vị, thiết bị edge đặt tại hiện trường, và phần mềm giám sát bên trên đều do một công ty thiết kế. Chúng tôi không ngồi trên hệ sinh thái của một tập đoàn nào, nên khi có vấn đề thì sửa được ở bất kỳ tầng nào, và làm gì tiếp cũng do chúng tôi quyết.

V. Dữ liệu không ra khỏi hiện trường

ORBRO OS được triển khai tại chỗ. Không phải một sản phẩm cloud "có hỗ trợ" triển khai tại chỗ — nó được thiết kế với tiền đề máy chủ nằm bên trong hiện trường.

Lý do là điều kiện của các hiện trường B2B trong nước. Cơ quan công và nhà máy thường có yêu cầu tách mạng và kiểm tra an ninh, nên việc đưa dữ liệu ra cloud bên ngoài tự thân đã không khả thi. Vị trí người lao động và hình ảnh camera đặc biệt nhạy cảm. Ở những hiện trường như vậy, triển khai tại chỗ không phải một lựa chọn mà là điều kiện để được vào.

Những hiện trường phù hợp cuối cùng đều là những nơi cùng hỏi một câu: cái gì đang ở đâu. Nhà máy phải xem an toàn và luồng di chuyển của người lao động, kho phải theo tài sản và luồng hàng, văn phòng quản lý ra vào và hiệu quả sử dụng không gian, chính quyền địa phương phải nắm tình hình địa bàn trên một màn hình. Yêu cầu khác nhau hết, nhưng câu hỏi nền thì giống, và trên đó chỉ cần đặt những tổ hợp ứng dụng khác nhau.

Lời kết

Lý do chúng tôi tự làm nền tảng điều hành rất đơn giản. Vì với cách làm lại từ đầu ở từng hiện trường, không hiện trường nào có thể sở hữu một hệ thống liên tục tốt lên.

ORBRO OS không có ngày bàn giao. Chỉ có ngày phát hành. Kể từ ngày bỏ menu để chuyển sang cơ chế ứng dụng, trong hơn một năm chúng tôi đã phát hành gần ba mươi lần.

Hãy nghĩ lại về khách hàng đã xin cảnh báo khu vực nguy hiểm ở trên. Họ yêu cầu một ứng dụng. Trong khoảng thời gian đó, trên màn hình của họ đã có thêm hai mươi một ứng dụng họ không yêu cầu. Mã vạch, quy trình ứng phó, phát hiện sự kiện qua hình ảnh — ban đầu đều là yêu cầu đến từ hiện trường khác. Điều đó không xảy ra ở một hệ thống đứng yên trên màn hình của năm năm trước.

Những bài tiếp theo sẽ đi qua từng nhóm ứng dụng lấp đầy nền tảng này: mười ứng dụng định vị làm thành lớp dày nhất, các ứng dụng AI đọc hiện trường mà không cần ai ngồi xem, và những ứng dụng cơ bản đỡ toàn bộ phía trên. Nếu muốn xem màn hình trước, chúng tôi luôn sẵn sàng cho một buổi demo và trao đổi triển khai.