Chi phí tiềm ẩn của độ trễ: Tại sao-thời gian phản hồi thực tế lại quan trọng trong kiểm soát nhóm

Hiện tượng: Khi bức tường rèm trở thành “Dây kéo mất răng”

Lúc đầu, đội vận hành nghi ngờ động cơ.

Dự án vừa bước vào giai đoạn thử nghiệm cuối cùng. Vào lúc 8:30 sáng các ngày trong tuần, hệ thống quản lý tòa nhà hạ rèm ở mặt tiền phía đông để cắt giảm lượng năng lượng mặt trời hấp thụ trước khi người ở đến. Lệnh rất đơn giản: vài trăm động cơ, cùng một vị trí đặt trước, cùng một thời điểm.

Mặt tiền không bao giờ di chuyển cùng nhau.

Hàng đầu tiên phản hồi gần như ngay lập tức. Những người khác theo sau một phần giây. Một số dừng lại, sau đó bắt kịp. Khi phần cuối cùng bắt đầu chuyển động thì phần đầu tiên đã dừng lại.

Từ bên trong tòa nhà, bạn hầu như không nhận thấy. Nhìn từ ngoài đường, bức tường rèm trông như một chiếc dây kéo bị mất răng.

Không có báo động. Mỗi động cơ đều vượt qua thử nghiệm chức năng riêng lẻ. Mạng vẫn hoạt động cả ngày.

Vậy tại sao hàng trăm động cơ có chức năng riêng lẻ không thể thực hiện một chuyển động đồng bộ?

Câu hỏi này xuất hiện thường xuyên hơn dự đoán của hầu hết các thông số kỹ thuật của dự án. Khi việc triển khai hệ thống che nắng có quy mô lên tới 50 hoặc 100 động cơ trên mỗi tòa nhà, khoảng cách giữa những gì một động cơ có thể làm một mình và những gì hệ thống có thể làm cùng nhau sẽ trở thành thước đo hiệu suất xác định.

Quan niệm sai lầm: Động cơ hầu như không bao giờ là vấn đề thực sự

Đây là một mô hình mà tôi đã thấy lặp lại trong nhiều dự án: động cơ bị đổ lỗi đầu tiên, được thay thế thứ hai và được minh oan thứ ba.

Kiểm tra chức năng riêng lẻ hoàn toàn sạch sẽ trên mỗi đơn vị. Đường cong mô-men xoắn nằm trong thông số kỹ thuật. Tốc độ di chuyển khớp với bảng dữ liệu. Mức độ tiếng ồn là tốt. Nhưng khi tất cả 200 động cơ nhận được lệnh nhóm, mặt tiền sẽ xếp tầng thay vì cố định vào vị trí như một bề mặt.

Vào thời điểm đó, thay thế động cơ là cách tốn kém nhất để biết rằng động cơ không bao giờ là vấn đề.

Cuộc điều tra hầu như luôn chuyển sang chuỗi truyền thông: BMS đến cổng, cổng vào mạng, mạng tới bộ điều khiển động cơ. Ngắt kết nối hàng tá động cơ khỏi nhóm và-kiểm tra lại. Nếu độ trễ hầu như không di chuyển thì nút cổ chai đang ở thượng nguồn.

Sự lan truyền của mili giây: Sự chậm trễ nhỏ có thể nhìn thấy được như thế nào

Toán học không thể tha thứ ở quy mô lớn.

Một động cơ khởi động muộn 100 mili giây - không ai nhìn thấy nó. Nhưng hãy trải rộng 100 mili giây đó cho ba trăm động cơ trên mười lăm tầng và độ trễ sẽ lan truyền. Các lệnh tấn công các phân đoạn mạng khác nhau vào những thời điểm khác nhau. Một phần giây ở cấp độ gói sẽ trở thành một làn sóng lăn qua mặt tiền.

Các kỹ sư vận hành có một cái tên không chính thức cho nó: hiệu ứng dây kéo. Cái tên này được đặt vì nó mô tả chính xác những gì bạn nhìn thấy.

Điều cần hiểu là hiệu ứng dây kéo là một triệu chứng, không phải là một chẩn đoán. Khi bạn nhìn thấy nó, ở đâu đó giữa bộ điều khiển và động cơ, thời gian lệnh không nhất quán. Tìm đâu là công việc thực tế.

Tại sao các nhà phát triển thực hiện việc này một cách nghiêm túc

Một tòa tháp văn phòng cao cấp với mặt tiền tự động di chuyển không đồng bộ đang gặp phải một vấn đề vượt xa cả kỹ thuật. Mặt tiền là một phần của bản sắc hình ảnh của tòa nhà. Khi nó hoạt động, sự tự động hóa là vô hình. Khi không, mọi người thuê nhà trên tầng 15 đều thông báo trước ly cà phê đầu tiên của họ.

Tôi đã nghe cùng một lời phàn nàn được diễn đạt theo hai cách hoàn toàn khác nhau. Các kỹ sư cho biết "chúng tôi đang nhận thấy độ trễ trong nhóm phát đa hướng." Các nhà quản lý cơ sở cho biết "những tấm rèm không còn di chuyển cùng nhau nữa." Cùng một vấn đề, ngôn ngữ khác nhau. Cả hai đều truy nguyên về cùng một gốc.

Đối với các nhà phát triển, cái giá phải trả là sự tín nhiệm. Đối với người cư ngụ, đó là niềm tin vào công nghệ của tòa nhà. Đối với đội vận hành, việc đuổi theo một con ma là khoảng thời gian không thể tính phí.

Chi phí năng lượng: Mỗi giây muộn sẽ tăng lên

Cảm biến ánh sáng ban ngày kích hoạt ở ngưỡng chiếu xạ đặt trước. Rèm nên được triển khai ngay lập tức. Nhưng nếu lệnh nhóm mất 800 mili giây để truyền thì - không có gì bất thường trong một mạng unicast lớn - thì mỗi mili giây đó sẽ cho phép bức xạ mặt trời chiếu vào kính bên trong ở cường độ tối đa.

Bản thân một giây chậm trễ không mang lại ý nghĩa gì cho tải làm mát. Nhưng nhân số giây đó với số sự kiện kích hoạt mỗi ngày, với số ngày trong mùa hạ nhiệt, với mét vuông kính, và con số sẽ không còn là chuyện nhỏ nữa. Mặt tiền-hướng Tây vào mùa hè có thể kích hoạt việc triển khai bóng hàng chục lần mỗi ngày khi góc mặt trời thay đổi và mây che phủ. Mỗi lần triển khai muộn đều là lượng nhiệt mà hệ thống HVAC hiện phải loại bỏ.

Nghiên cứu về tỷ lệ sử dụng bài đăng LBNL-của Tòa nhà Thời báo New York đã ghi lại rằng việc tạo bóng tự động được tích hợp với các điều khiển giảm độ sáng-ánh sáng ban ngày đã giúp giảm 56% mức sử dụng năng lượng chiếu sáng hàng năm trên các vùng chu vi. Kết quả đó giả định việc triển khai kịp thời. Những tấm rèm muộn làm suy yếu tính toán đã khiến khoản đầu tư che nắng được hoàn vốn.

Ngoài ra còn có một chi phí thứ cấp bên trong mạng. Khi lệnh đến muộn, bộ điều khiển sẽ truyền lại. Việc truyền lại sẽ tiêu tốn thời gian phát sóng cần có cho chu kỳ lệnh tiếp theo. Tốc độ thử lại nhỏ là bình thường - mọi giao thức không dây đều có vấn đề đó. Nhưng thử lại hợp chất. Một nhóm nhìn thấy 2% số lần thử lại ở 50 động cơ có thể thấy 8% ở 200 và đường cong lưu lượng không phải là tuyến tính. Mỗi lần thử lại sẽ tạo ra nhiều lưu lượng truy cập hơn, dẫn đến nhiều xung đột hơn, từ đó tạo ra nhiều lần thử lại hơn. Các kỹ sư đo độ trễ theo thời gian thường phát hiện ra rằng mạng đang dần bão hòa.

Việc thêm động cơ không thêm độ trễ một cách tuyến tính

Một trong những quan niệm sai lầm dai dẳng hơn trong các cuộc thảo luận dự án là việc tăng gấp đôi số lượng động cơ sẽ làm tăng gấp đôi độ trễ.

Tôi đã thấy mạng 100 động cơ hoạt động tốt hơn mạng 60 động cơ trên cùng một ngăn xếp giao thức. Tôi cũng đã thấy mạng lưới 250 động cơ hoạt động ổn định trong nhiều năm trong khi mạng lưới 120 động cơ ở một tòa nhà khác cần hoạt động trở lại sau mỗi sáu tháng.

Biến không phải là số lượng thiết bị. Biến số này là cách kiến ​​trúc hệ thống truyền thông: logic nhóm, thông lượng bộ điều khiển, lựa chọn giao thức, cấu trúc liên kết, tần suất cập nhật trạng thái, liệu tính năng bỏ phiếu có được bật hay không. Hai tòa nhà có cùng động cơ, cùng cổng và cùng phần mềm có thể tạo ra kết quả vận hành hoàn toàn khác nhau nếu một trong số chúng nhóm tất cả các rèm thành một vùng duy nhất và vùng còn lại được phân chia theo hướng mặt tiền.

Đây là lý do tại sao các nhà tích hợp có kinh nghiệm kiểm tra cấu hình mạng trước khi chạm vào phần cứng.

Nhật ký đã kể một câu chuyện khác

Trong một dự án mà hiệu ứng dây kéo rất nghiêm trọng, nhóm đã lấy nhật ký liên lạc từ chu kỳ buổi sáng tự động trong một tuần.

Mô hình đã có ngay lập tức. Động cơ 001 nhận được lệnh trong vòng 12 mili giây. Động cơ 200 nhận được lệnh tương tự sau 940 mili giây. Động cơ không phản hồi chậm - chúng nhận lệnh vào những thời điểm khác nhau.

 

Phát hiện đó đã thay đổi toàn bộ cuộc điều tra. Đó không phải là vấn đề về phản ứng của động cơ. Đó là một vấn đề phân phối lệnh. Bộ điều khiển đang lặp qua từng thiết bị một qua unicast và mọi khung hình đều chờ khung trước đó được xác nhận trước khi khung tiếp theo được gửi.

200 động cơ × khoảng 4,7 mili giây trên mỗi khung hình (tính đến thời gian phát sóng, độ trễ CSMA/CA và quay vòng ACK)=940 mili giây. Phép toán khớp gần như chính xác với độ trễ quan sát được.

Lựa chọn giao tiếp: Một lệnh so với hai trăm cuộc gọi riêng lẻ

Sự tương tự thường xảy ra với các bên liên quan của dự án là: bạn cần yêu cầu 200 người trong tòa nhà tham dự một cuộc họp. Bạn có thể gọi điện cho từng người hoặc bạn có thể đưa ra một thông báo qua hệ thống PA. Kết quả tương tự. Thời gian hoàn thành hoàn toàn khác nhau.

Giao tiếp nhóm hoạt động theo cách tương tự. Mạng unicast tạo ra các gói riêng lẻ cho mỗi động cơ và gửi chúng một cách tuần tự. Mỗi gói chờ gói trước đó xóa. Độ trễ kết hợp một cách số học với kích thước nhóm.

Multicast tạo ra một khung được gửi đến một nhóm logic. Mọi động cơ trong nhóm đó đều nhận được nó trong cùng một cửa sổ truyền động. Độ trễ không đổi bất kể kích thước nhóm - một thời gian khung hình chứ không phải N thời gian khung hình.

Giao thức Matter do Liên minh Tiêu chuẩn Kết nối duy trì, chỉ định giao tiếp nhóm thông qua Cụm Nhóm của nó. ID nhóm ánh xạ tới một tập hợp các nút kết cấu và một đường truyền phát đa hướng duy nhất sẽ đến tất cả các thành viên trong nhóm cùng một lúc. Đây không phải là kỹ thuật độc quyền - nó được tích hợp vào đặc tả giao thức. Sự khác biệt thực tế khi triển khai 200 động cơ là sự khác biệt giữa một khung và 200 khung.

Cấu trúc liên kết mạng: Tại sao lớp vật lý quyết định kết quả

Biến khác xác định liệu multicast có thực sự hoạt động ở quy mô lớn hay không là lớp mạng vật lý.

Trong cấu trúc liên kết hình sao - mô tả hầu hết WiFi và nhiều triển khai Zigbee kế thừa - mọi động cơ đều kết nối trực tiếp với điểm truy cập trung tâm hoặc điều phối viên. Khi một động cơ nằm phía sau bức tường cắt bê tông hoặc ống nâng HVAC, chất lượng liên kết của nó sẽ suy giảm độc lập với mọi động cơ khác. Mạng sẽ bù đắp bằng cách truyền lại hoặc giảm tốc độ dữ liệu cho một đường dẫn đó, điều này sẽ tiêu tốn thời gian phát sóng lẽ ra phải có cho các lệnh nhóm.

Thread sử dụng một mô hình khác. Nó xây dựng một mạng lưới: các thiết bị được cấp nguồn điện chính đóng vai trò như bộ định tuyến, chuyển tiếp lưu lượng truy cập cho các thiết bị chạy bằng pin không thể duy trì luôn-trên radio. Nếu đường dẫn trực tiếp đến động cơ 47 bị chặn, khung sẽ định tuyến qua động cơ 32 và động cơ 18. Lưới sẽ tính toán lại các đường dẫn liên tục dựa trên số liệu chất lượng liên kết được cập nhật theo thời gian thực. Không có điểm thất bại duy nhất. Không có luồng lệnh nào bị đình trệ chờ truyền lại đến một nút đang gặp khó khăn.

Điểm chuẩn mạng lưới của Phòng thí nghiệm Silicon, được thực hiện tại một văn phòng thương mại có người ở với mạng WiFi và Zigbee đang hoạt động, cung cấp một tài liệu tham khảo độc lập. Trong các mạng lớn có tải trọng vừa phải: Độ trễ luồng được giữ dưới khoảng 100 mili giây, Zigbee trải rộng đến khoảng 130 mili giây và lưới Bluetooth giảm xuống quá 250 mili giây. Khoảng cách ngày càng tăng theo quy mô mạng và tải trọng, chính xác là các điều kiện quan trọng đối với việc che bóng thương mại.

Thread cũng triển khai tính linh hoạt về tần số: nếu một kênh 2,4 GHz trở nên bão hòa, mạng sẽ chuyển sang kênh sạch hơn giữa các lần truyền. Lớp ứng dụng động cơ không bao giờ nhìn thấy bước nhảy. Không thử lại. Không có độ trễ tăng đột biến. Đây là tính năng Thread tiêu chuẩn được chỉ định ở lớp MAC IEEE 802.15.4.

Không có điều nào trong số này có nghĩa là Thread luôn là câu trả lời đúng. Xây dựng tòa nhà, mật độ thiết bị và chất lượng vận hành vẫn chiếm ưu thế. Những thay đổi của Thread là cách mạng xuống cấp khi tải - và đối với việc triển khai bóng lớn, sự xuống cấp nhẹ nhàng là loại duy nhất quan trọng.

Khi mặt tiền trông chậm, động cơ là thứ cuối cùng tôi kiểm tra

Một kỹ sư vận hành cấp cao đã từng nói với tôi điều đó và điều đó luôn đúng mỗi khi tôi nhìn thấy hiệu ứng dây kéo trên hiện trường.

Quan điểm của ông không phải là động cơ không bao giờ hỏng. Đó là lỗi động cơ ở dạng nhị phân - động cơ khởi động hoặc không. Sự suy giảm liên lạc diễn ra liên tục - nó trở nên tồi tệ hơn khi lưu lượng truy cập tăng lên, khi tòa nhà lấp đầy khi các hệ thống khác trực tuyến. Kiểm tra nghiệm thu tại nhà máy phát hiện các lỗi động cơ. Nó hiếm khi gặp phải các vấn đề về giao tiếp vì môi trường thử nghiệm không có độ phức tạp RF của một tòa nhà đã hoàn thiện với 200 thiết bị, 50 điểm truy cập WiFi và các phòng mô tơ thang máy tạo ra EMI băng thông rộng cách đó hai tầng.

Đây là lý do tại sao các vấn đề về đồng bộ hóa thường xuất hiện trong quá trình sử dụng chứ không phải trong quá trình vận hành thử. Mạng vẫn ổn khi nó là thứ duy nhất đang chạy.

Đo điểm cuối phù hợp

Các cuộc trò chuyện về độ trễ hầu như luôn bắt đầu bằng "động cơ nhanh như thế nào?" Có vẻ như đó là một câu hỏi đúng, nhưng nó thu hẹp phạm vi điều tra sai 1% trong chuỗi tín hiệu.

Một động cơ có thể phản hồi trong 8 mili giây kể từ khi nhận được lệnh. Nếu lệnh mất 900 mili giây để đến, việc giảm thời gian phản hồi của động cơ từ 8 mili giây xuống 6 mili giây sẽ chẳng mang lại lợi ích gì cho bạn.

Phép đo quan trọng là từ đầu đến cuối: khoảng thời gian từ khi bộ điều khiển phát lệnh nhóm đến khi mỗi động cơ bắt đầu chuyển động vật lý. Con số đó bao gồm bộ điều khiển, ngăn xếp mạng, radio, MCU của động cơ và tầng nguồn - mọi thứ nằm giữa lệnh BMS và đầu ra cơ học.

Khi bạn theo dõi từ đầu đến cuối, hình ảnh sẽ thay đổi. Hai hệ thống xác định thời gian phản hồi của động cơ giống hệt nhau có thể khác nhau 800 ms từ đầu đến cuối do cách mạng phân phối lệnh. Việc so sánh bảng thông số kỹ thuật không bao giờ nắm bắt được nó.

Độ trễ trung bình là một sự mất tập trung

Đây là một cái bẫy mà tôi thấy các kỹ sư rơi vào: họ so sánh các con số về độ trễ trung bình và nghĩ rằng họ đã trả lời được câu hỏi.

Hai hệ thống, cả hai đều báo cáo tốc độ trung bình là 18 ms. Trên giấy tờ, giống hệt nhau. Trong quá trình triển khai, một hệ thống sẽ mang lại phản hồi nhất quán trong một phạm vi chặt chẽ. Cái còn lại thỉnh thoảng tăng vọt lên 80 hoặc 100 mili giây khi có mật độ giao thông đông đúc - và những mức tăng đột biến đó, không phải mức trung bình, là những gì mọi người nhìn thấy khi mặt tiền di chuyển.

Mắt không nhận biết được mức trung bình. Nó nhận thức được những ngoại lệ. Một xung đột biến 100 ms trong nhóm 300 động cơ sẽ tạo ra hiện tượng do dự rõ ràng ở một phần của mặt tiền và đó là điều mà chủ sở hữu tòa nhà ghi nhớ. Đây là lý do tại sao các kỹ sư vận hành lại chú ý nhiều hơn đến phân vị thứ 99 - hoặc tốt hơn là độ trễ quan sát được tối đa - so với giá trị trung bình. Khả năng dự đoán luôn đánh bại hiệu suất cao nhất.

 

Đo lường-thế giới thực: Những gì chúng tôi đo lường trên nền tảng của chính mình

Trước khi phát hành nền tảng kiểm soát hiện tại, nhóm kỹ thuật của chúng tôi đã chạy xác thực nội bộ để hiểu thời gian phản hồi thay đổi như thế nào theo quy mô nhóm.

Quá trình thiết lập: động cơ hình ống trên Vật chất-trên-Mạng luồng, điều kiện trong nhà ổn định, các lệnh nhóm lặp lại trên số lượng thiết bị ngày càng tăng. Mục tiêu không phải là đạt mức tối thiểu ấn tượng mà là để xác minh rằng độ trễ vẫn có thể dự đoán được khi nhóm phát triển.

Qua nhiều chu kỳ thử nghiệm với 100 động cơ, hầu hết các thiết bị bắt đầu di chuyển trong vòng 20 mili giây kể từ lệnh nhóm. Tốc độ đọc chậm nhất là khoảng 22 ms. Tỷ lệ truyền lại gói luôn ở mức dưới 0,5%.

Sự gia tăng diễn ra suôn sẻ - không có vách đá, không có điểm nào mà hiệu suất đột nhiên bị giảm sút. Điều đó quan trọng hơn những con số tuyệt đối. Một hệ thống xuống cấp dần dần khi chịu tải có thể được triển khai một cách tự tin ở mọi quy mô. Một hệ thống hoạt động tốt ở 40 động cơ và hỏng ở 80 động cơ là một thảm họa đang chờ xảy ra.

Đây là các số-môi trường được kiểm soát. Các tòa nhà thực tế có khung thép, kính-E thấp, mạng Wi-Fi cạnh tranh và người cư trú mang theo thiết bị di động khi đi lại. Kết quả hiện trường sẽ khác nhau. Việc xác thực chỉ đơn giản xác nhận rằng kiến ​​trúc - multicast trên lưới - có quy mô theo cách mà toán học dự đoán.

Mặt cơ học: Ngay cả sự giao tiếp hoàn hảo cũng không thể che giấu được sự dung sai

Giao tiếp thu hút sự chú ý vì đó là nơi tồn tại của hầu hết độ trễ của nhóm. Nhưng ngay cả với việc phân phối lệnh hoàn hảo - mọi động cơ nhận cùng một khung tại cùng một thời điểm - đồng bộ hóa vẫn có thể bị hỏng ở cấp độ cơ học.

Dung sai của cụm hộp số, sự thay đổi tải trước của ổ trục, thời điểm nhả phanh, độ đồng tâm của trục đầu ra -, tất cả những điều này đều ảnh hưởng đến tốc độ động cơ chuyển từ trạng thái đứng yên sang quay sau khi nhận được lệnh điện. Riêng sự khác biệt là một vài mili giây, vô hình. Trên hàng trăm động cơ trên cùng một mặt tiền, chúng tích tụ thành những mảng loạng choạng đáng chú ý.

Đây là lý do tại sao tính nhất quán trong sản xuất không phải là một cuộc trò chuyện riêng biệt với hiệu suất giao tiếp. Hai hợp chất. Quy trình sản xuất của chúng tôi giữ các bộ phận truyền động chính ở sai số ± 0,05 mm trên ổ trục và biên dạng bánh răng. Dung sai đó ảnh hưởng trực tiếp đến độ lặp lại cơ học mà vòng điều khiển phần sụn phụ thuộc vào.

Dung sai chặt chẽ hơn có nghĩa là phản hồi vị trí của bộ mã hóa thực sự đạt đến vị trí mà động cơ mong đợi. Dung sai lỏng lẻo hơn có nghĩa là vòng điều khiển liên tục điều chỉnh - tăng vọt, kéo lùi, dao động vi mô- - đốt cháy năng lượng và trong văn phòng yên tĩnh, nó sẽ trở nên có thể nghe được khi tiếng ồn săn lùng ở giới hạn dừng lại. Độ chính xác của truyền thông và độ chính xác cơ học là hai nửa của cùng một vấn đề.

Thiết kế vùng xảy ra trước khi kéo dây đầu tiên

Hầu hết các lỗi đồng bộ hóa đều được thiết kế trong dự án trước khi bắt đầu mua sắm.

Lỗi phổ biến nhất là nhóm theo tầng vì đó là cách tổ chức các bản vẽ kiến ​​trúc. Nó cảm thấy tự nhiên. Nhưng mặt trời không tôn trọng ranh giới sàn. Mặt tiền phía đông chịu tải buổi sáng; mặt tiền phía tây chịu tải vào buổi chiều. Nếu mọi người mù trên một tầng đều nhận được mọi lệnh bất kể mặt trời có chiếu vào phía tòa nhà hay không thì lưu lượng truy cập mạng sẽ tăng cao mà không có lý do chức năng.

Cách tiếp cận đơn giản hơn: nhóm theo hướng mặt tiền trước, chia nhỏ theo tầng trong mỗi hướng thứ hai. Khu phía Đông. Khu phía Tây. Khu phía bắc. Khu phía Nam. Mỗi nhóm phát đa hướng chỉ chứa các động cơ luôn di chuyển cùng nhau - cùng mức tiếp xúc với năng lượng mặt trời, cùng logic lệnh. Lưu lượng truy cập nhóm giảm. Áp lực hàng đợi giảm xuống. Độ trễ giảm xuống.

Ngưỡng quy mô: Khi mạng không dây cần đối tác có dây

Có một thời điểm mà mạng không dây thuần túy bắt đầu cần thảo luận về khả năng dự phòng có dây và theo kinh nghiệm của chúng tôi, điểm đó nằm ở khoảng 500 động cơ trên một mạng tòa nhà.

Dưới 300, lưới Thread được thiết kế tốt-có thể xử lý việc kiểm soát nhóm mà không gây kịch tính. Trong khoảng từ 300 đến 500, mật độ lưới cần được chú ý: lập kế hoạch cho ít nhất một thiết bị có khả năng định tuyến-cho mỗi 15 đến 20 điểm cuối để đảm bảo tính đa dạng của đường dẫn định tuyến khi có vật cản xuất hiện.

Trên 500, độ phức tạp trong hoạt động sẽ thay đổi. Các bản cập nhật chương trình cơ sở ở quy mô đó sẽ làm bão hòa mạng không dây nếu bạn không cẩn thận. Việc vận hành thiết bị mất nhiều thời gian hơn. Xác suất thống kê của sự kiện phân vùng dạng lưới - trong đó một tập hợp con thiết bị tạm thời mất kết nối với bộ định tuyến viền - tăng theo số lượng nút ngay cả khi chất lượng liên kết trung bình là tuyệt vời.

Ở ngưỡng đó, việc thêm đường trục có dây RS-485 làm đường dẫn song song để phân phối chương trình cơ sở và chuyển đổi dự phòng không phải là sự thừa nhận rằng mạng không dây là không đáng tin cậy. Phải thừa nhận rằng trong một tòa nhà 500 động cơ, sự kiện phân vùng trong trình tự tích hợp báo cháy không phải là điều bạn muốn giải thích với AHJ. Con đường có dây là bảo hiểm.

Bệnh viện, sân bay và tòa nhà chính phủ có xu hướng chỉ định kiến ​​trúc kết hợp bất kể số lượng động cơ, vì chi phí ngừng hoạt động trong những môi trường đó khiến cho việc sao lưu có dây trở thành sai số làm tròn trên tổng ngân sách dự án. Viện Công nghiệp Xây dựng đã ghi lại rằng chi phí làm lại - bao gồm cả việc vận hành lại hệ thống - trung bình là 12,4% chi phí lắp đặt dự án. Đường trục liên lạc dự phòng tốn một phần nhỏ so với việc chạy thử lại 500 động cơ sau khi xảy ra sự cố mạng tiềm ẩn sau{6}}có người sử dụng.

Năm câu hỏi quan trọng trước khi đăng xuất

Sau đủ chu kỳ vận hành, những câu hỏi tương tự tiếp tục xuất hiện. Chúng không bao giờ nói về mô-men xoắn hoặc RPM.

"Mọi động cơ đều vượt qua bài kiểm tra riêng lẻ. Tại sao cả nhóm trông chậm chạp?"

Bạn đang xem vấn đề phân phối lệnh chứ không phải vấn đề về động cơ. Kiểm tra xem bộ điều khiển có đang truyền từng lệnh một hay không. Kiểm tra tần suất cập nhật trạng thái. Kiểm tra xem tất cả các động cơ có nằm trong một nhóm quá khổ hay không. Trong hầu hết các trường hợp, việc chuyển sang địa chỉ nhóm multicast sẽ giải quyết được độ trễ hiển thị mà không cần chạm vào một động cơ nào.

"Nếu một động cơ bị hỏng, liệu nó có làm hỏng cả nhóm không?"

Nó không nên. Mỗi động cơ phản ứng độc lập với cùng một khung multicast. Một động cơ chết duy nhất - Lỗi MCU, đoản mạch tụ điện, kẹt cơ - vẫn tự chết. 199 còn lại thực hiện lệnh bình thường. Nếu một động cơ rời khỏi mạng hoàn toàn, bảng điều khiển quản lý sẽ gắn cờ động cơ đó là không{7}}phản hồi và nó sẽ tự động tham gia lại nhóm khi kết nối được khôi phục. Sự tách biệt này là một yêu cầu khó khăn đối với bất kỳ nền tảng kiểm soát cấp sản xuất nào-.

"Không dây có thực sự đáng tin cậy trong tháp-và-kính bằng thép không?"

Có, nếu giao thức và cấu trúc liên kết được chọn cho môi trường đó. Kiến trúc lưới của Thread định tuyến xung quanh các vật cản thay vì phụ thuộc vào một điểm truy cập xuyên qua chúng. Tính linh hoạt của tần số sẽ thoát khỏi các kênh bão hòa mà không cần đến lớp ứng dụng. Điểm chuẩn của Silicon Labs được trích dẫn trước đó đã chạy trong một văn phòng đang hoạt động có WiFi và Zigbee cạnh tranh về thời gian phát sóng - chứ không phải phòng thí nghiệm được bảo vệ - và Thread có độ trễ thấp nhất trong tất cả các điều kiện thử nghiệm.

Điều đó có nghĩa là không có giao thức nào loại bỏ nhu cầu thực hiện khảo sát RF trước khi cài đặt trên quy mô lớn. Tòa nhà có lớp phủ cửa sổ Low{2}}E mạ kim loại hoạt động khác với tòa nhà có kính trong. Cấu trúc vách thạch cao-trên-khung thạch cao hoạt động khác với bê tông đổ và cốt thép. Lưới xử lý vật cản tốt hơn ngôi sao. Nó không làm cho vật lý trở thành tùy chọn.

"Có phải độ trễ thấp hơn luôn tốt hơn không?"

Chỉ khi nó cũng nhất quán. Một hệ thống cung cấp 18 ms mỗi lần tạo ra một mặt tiền đồng nhất rõ ràng. Một hệ thống có thể đạt tốc độ 10 mili giây trong điều kiện lý tưởng nhưng tăng vọt lên 80 mili giây khi lưu lượng truy cập tăng tạo ra một mặt tiền trông có vẻ lo lắng. Đối với chủ sở hữu tòa nhà, khả năng dự đoán là điều mà người cư trú nhận thấy. Bảng thông số kỹ thuật tối thiểu là những gì kỹ sư bán hàng nói đến tại cuộc họp đấu thầu. Chúng hiếm khi giống nhau.

Trước khi bắt đầu dự án tiếp theo

Bài học được lặp đi lặp lại trong các dự án che nắng lớn rất đơn giản: các vấn đề về đồng bộ hóa hầu như không bao giờ bắt nguồn từ động cơ.

Vào thời điểm hiệu ứng dây kéo hiện rõ từ đường phố, nguyên nhân sâu xa đã âm thầm tích lũy trong hệ thống thông tin liên lạc hàng tuần hoặc hàng tháng. Đội ngũ vận hành có kinh nghiệm biết điều này. Họ kiểm tra cấu hình mạng trước khi yêu cầu phần cứng thay thế.

Năm câu hỏi quan trọng:

Các lệnh được phân phối bằng multicast hay unicast?

Có bao nhiêu thiết bị chia sẻ mỗi đường truyền thông?

Bao nhiêu trạng thái bỏ phiếu không cần thiết được kích hoạt?

Độ trễ có thể dự đoán được khi số lượng thiết bị tăng lên không?

Có thể cách ly một lỗi giao tiếp đơn lẻ không?

Trả lời chính xác năm câu hỏi đó sẽ có tác động nhiều hơn đến hiệu suất mặt tiền so với bất kỳ thông số kỹ thuật động cơ nào trên biểu dữ liệu.

Thời gian phản hồi không thực sự là một thước đo động cơ. Nó là một thước đo hệ thống. Khi các tòa nhà thương mại thúc đẩy sự tích hợp chặt chẽ hơn giữa bóng râm, ánh sáng và HVAC, khả năng thực hiện lệnh theo thời gian trên hàng trăm điểm cuối đang trở thành con số hiệu suất xác định liệu khoản đầu tư tự động hóa có đáng thực hiện hay không. Động cơ hiếm khi bị tắc nghẽn. Kiến trúc giữa chúng hầu như luôn luôn như vậy.