Logo Zephyrnet

Thiết bị IoT di động không thành công; Hãy chắc chắn rằng họ thất bại một cách duyên dáng

Ngày:

Thiết bị IoT di động không thành công
Minh họa: © IoT cho tất cả

Có một loại nghịch lý được tích hợp trong các triển khai IoT di động lớn. Ngay khi bạn gửi thiết bị của mình vào trường, bạn sẽ mất rất nhiều quyền kiểm soát đối với hiệu suất. Đôi khi, ít nhất, các kết nối trong thiết bị IoT di động của bạn sẽ không thành công. Bạn không thể kiểm soát những gì mọi người làm với thiết bị của bạn. Bạn không thể kiểm soát hành vi của người dùng và một số hành vi đó sẽ làm gián đoạn bất kỳ kết nối mạng nào. 

Nói về mạng, có một thứ khác mà bạn không thể kiểm soát. lớn cuối cùng, khảo sát toàn cầu của các nhà khai thác mạng di động (MNO) về chủ đề thất bại là từ năm 2016. Nhưng ngay cả những tin tức cũ cũng cho thấy giới hạn của cơ sở hạ tầng mạng. Trước đó, 30% phần trăm MNO phản hồi cho biết họ gặp sự cố mạng và sự cố dịch vụ tới ba lần một năm. Thậm chí, 34% thừa nhận có hơn 15 lần ngừng hoạt động hoặc “xuống cấp dịch vụ” mỗi năm. Gần đây hơn, JD Power nhận thấy các thiết bị di động phát triển nhanh chóng vào năm 2022 dẫn đến sự phổ biến rộng rãi hơn vấn đề về “chất lượng mạng". 

Kết nối di động rất tốt cho IoT và nó sẽ ngày càng tốt hơn khi các công nghệ mới như 5G New Radio trở nên phổ biến. Nhưng nó có thể sẽ không bao giờ là 100 phần trăm. Bạn có thể và nên thiết bị thiết kế cho kết nối nhất quán. Tuy nhiên, khi sản phẩm của bạn tung ra thị trường, hãy mong đợi điều bất ngờ. Nếu các nhà thiết kế IoT di động không thể ngăn chặn các lỗi kết nối, họ có thể lập trình các thiết bị bị lỗi một cách nhẹ nhàng. Đây là một cái nhìn thoáng qua về những gì có thể trông như thế nào.

“Ngay khi bạn đưa thiết bị của mình vào hiện trường, bạn sẽ mất rất nhiều quyền kiểm soát đối với hiệu suất. Thỉnh thoảng, ít nhất, các kết nối trong thiết bị IoT di động của bạn sẽ không thành công.”

-Eseye

Thiết kế cho sự thất bại duyên dáng

Trong bối cảnh lỗi kết nối IoT di động, duyên dáng nghĩa là gì? Bốn điều, thực sự. Chúng ta hãy lần lượt xem xét từng mục tiêu này. 

#1: Kết nối dự phòng

Như chúng tôi đã đề cập, mạng đôi khi bị lỗi. Nhưng khi một mạng bị lỗi, một thiết bị được thiết kế tốt có thể bị lỗi để sao lưu. Tùy thuộc vào thiết bị, bạn có thể bao gồm các chế độ chuyển đổi dự phòng chuyển sang WiFi, vệ tinh hoặc chỉ một mạng di động khác. Chuyển đổi dự phòng thành công sẽ giúp thiết bị của bạn tiếp tục hoạt động cho đến khi thiết bị có thể kết nối lại với mạng chính. Nhưng các kết nối dự phòng cũng có thể bị lỗi. Điều đó có thể nguy hiểm. Ví dụ, hình ảnh đèn giao thông thông minh tại một ngã tư đông đúc. Đó là lý do tại sao bạn cũng phải lập trình chương trình cơ sở cho một lớp bảo vệ khác, điều này đưa chúng ta đến mục tiếp theo trong danh sách của chúng ta.  

#2: Các chế độ lỗi mặc định

Chương trình cơ sở của bạn phải bao gồm hướng dẫn về những việc cần làm khi kết nối bị mất một cách vô vọng. Trong ví dụ về đèn giao thông, các thiết bị có thể mặc định theo mẫu tiêu chuẩn, không thông minh nhưng có thể sử dụng được để ngăn ô tô giao nhau với giao lộ. Các chế độ lỗi an toàn sẽ trông khác nhau từ thiết bị này sang thiết bị khác. Bí quyết là dự đoán các tình huống trong thế giới thực và thiết kế hành vi cơ bản của thiết bị để giữ an toàn cho người dùng cho đến khi có thể thiết lập lại kết nối. 

#3: Ngăn chặn các sự cố mạng xếp tầng

Các thiết bị IoT được lập trình kém sẽ tồn tại dai dẳng nếu không có gì khác. Họ không chỉ phạm sai lầm; họ lặp lại chúng đến mức thảm họa. Giả sử nhiệt kế thông minh được lập trình để gửi thông báo thường xuyên hơn khi nhiệt độ tăng cao hơn. Sau đó, giả sử cảm biến bị hỏng và hệ thống diễn giải việc thiếu tín hiệu là nhiệt độ vô cực. Thiết bị đó có thể bắt đầu gửi thông báo mỗi giây; nó có thể gửi quá nhiều dữ liệu khiến mạng trở nên tắc nghẽn. Sau đó, các thiết bị khác có thể bắt đầu liên tục gửi lại các lần truyền không thành công của chính chúng. Cuối cùng, một thiết bị bỏ trốn duy nhất đó có thể gây ra một cơn bão tín hiệu làm sập toàn bộ mạng.  

Đó là một vấn đề đối với nền tảng kết nối, nhà thiết kế chương trình cơ sở hoặc cả hai. Ở đâu đó trong hệ thống, các thiết bị cần giới hạn tốc độ dữ liệu. Cho dù nguyên nhân của một cơn bão tín hiệu là gì, hiệu ứng sẽ không bao giờ là sự cố mạng theo tầng.    

#4: Phục hồi duyên dáng

Cuối cùng, các thiết bị phải kết nối lại với mạng mà không làm đứt mạng. Rủi ro thực sự, sau khi mất mạng, là cơn bão tín hiệu. Nếu 100,000 thiết bị cố gắng kết nối lại với mạng cùng một lúc, bạn sẽ gặp phải sự cố tắc nghẽn có thể bắt đầu lại sự cố giao thông. Cách đơn giản nhất để đảm bảo khôi phục nhanh chóng là lập trình các nỗ lực kết nối lại với dự phòng theo cấp số nhân. Một thiết bị có thể thử kết nối lại. Nếu kết nối không hoạt động lần đầu tiên, nó có thể thử lại. Nhưng giữa mỗi lần thử, có một bộ đệm thời gian chờ tăng theo cấp số nhân. Điều đó giúp ngăn chặn xung đột mạng dẫn đến bão tín hiệu.

Bao gồm các chuyên gia

Tất nhiên, chúng ta không thể nhấn mạnh đủ mức độ khác nhau của mỗi lần triển khai IoT. Các ví dụ chúng tôi thảo luận ở trên có thể hoặc không thể áp dụng cho dự án của bạn. Điều tốt nhất bạn có thể làm để tạo ra các sản phẩm IoT di động không thành công là trao đổi với các chuyên gia IoT đã được chứng minh. Bắt đầu với một danh sách các dịch vụ IoT mọi người tạo ra sản phẩm đều cần. Bạn có thể không ngăn được lỗi kết nối không thường xuyên, nhưng bạn có thể kiểm soát phản hồi của thiết bị—và hạn chế tác động đối với người dùng. Đó là nhiều hơn thiết kế tốt. Thật duyên dáng.

tại chỗ_img

Tin tức mới nhất

tại chỗ_img

Trò chuyện trực tiếp với chúng tôi (chat)

Chào bạn! Làm thế nào để tôi giúp bạn?