ปรากฏการณ์: เมื่อกำแพงม่านกลายเป็น "ซิปที่ฟันหายไป"

ในตอนแรก ทีมงานทดสอบการใช้งานสงสัยว่ามอเตอร์
โครงการเพิ่งเข้าสู่การทดสอบขั้นสุดท้าย ทุกวันธรรมดาเวลา 8.30 น. ระบบการจัดการอาคารจะลดม่านบังตาด้านทิศตะวันออกลงเพื่อลดการรับแสงอาทิตย์ก่อนที่ผู้อยู่อาศัยจะมาถึง คำสั่งนั้นง่ายดาย: มอเตอร์หลายร้อยตัว ตำแหน่งที่กำหนดไว้ล่วงหน้าเดียวกัน ในเวลาเดียวกัน
ซุ้มไม่เคยขยับเข้าหากัน
แถวแรกตอบสนองแทบจะในทันที คนอื่นๆ ตามมาในเสี้ยววินาทีต่อมา ร่างบางหยุดแล้วตามทัน เมื่อถึงเวลาที่ส่วนสุดท้ายเริ่มเคลื่อนไหว ส่วนแรกก็หยุดไปแล้ว
จากภายในอาคารคุณแทบจะไม่สังเกตเห็น เมื่อมองจากถนน กำแพงม่านดูเหมือนซิปที่มีฟันหายไป
ไม่มีการปลุก มอเตอร์ทุกตัวผ่านการทดสอบการทำงานเป็นรายบุคคล เครือข่ายคงอยู่ตลอดทั้งวัน
แล้วเหตุใดมอเตอร์ที่ทำงานแยกกันหลายร้อยตัวจึงไม่สามารถดำเนินการเคลื่อนไหวแบบซิงโครไนซ์เพียงครั้งเดียวได้
คำถามนี้ปรากฏบ่อยกว่าข้อกำหนดโครงการส่วนใหญ่ที่คาดไว้ เนื่องจากการใช้บังแดดขยายขนาดเกิน 50 หรือ 100 มอเตอร์ต่ออาคาร ช่องว่างระหว่างสิ่งที่มอเตอร์สามารถทำได้โดยลำพังและสิ่งที่ระบบสามารถทำได้ร่วมกันจะกลายเป็นตัวชี้วัดประสิทธิภาพที่กำหนด
ความเข้าใจผิด: มอเตอร์แทบจะไม่เคยเป็นปัญหาเลย
นี่คือรูปแบบที่ฉันได้เห็นการเล่นซ้ำในหลายโปรเจ็กต์: มอเตอร์ถูกตำหนิก่อน ถูกแทนที่ที่สอง และถูกตัดสินในสาม
การทดสอบการทำงานส่วนบุคคลกลับมาสะอาดอีกครั้งในทุกหน่วย เส้นโค้งแรงบิดอยู่ในข้อกำหนด ความเร็วในการเดินทางตรงกับเอกสารข้อมูล ระดับเสียงก็โอเค แต่เมื่อมอเตอร์ทั้ง 200 ตัวได้รับคำสั่งแบบกลุ่ม ด้านหน้าจะลดหลั่นลงแทนที่จะจัดเป็นตำแหน่งเดียว
ณ จุดนั้น การเปลี่ยนมอเตอร์เป็นวิธีที่แพงที่สุดในการเรียนรู้ว่ามอเตอร์ไม่เคยมีปัญหา
การตรวจสอบมักจะเปลี่ยนไปสู่ห่วงโซ่การสื่อสาร: BMS ไปยังเกตเวย์, เกตเวย์ไปยังเครือข่าย, เครือข่ายไปยังตัวควบคุมมอเตอร์ ถอดมอเตอร์หลายสิบตัวออกจากกลุ่มและ-ทดสอบอีกครั้ง หากความล่าช้าแทบจะไม่ขยับเลย แสดงว่าคอขวดอยู่ที่ต้นน้ำ
การขยายพันธุ์ของมิลลิวินาที: ความล่าช้าเล็กๆ น้อยๆ ปรากฏให้เห็นได้อย่างไร
คณิตศาสตร์เป็นเรื่องที่ไม่อาจให้อภัยได้ในวงกว้าง
มอเตอร์ตัวหนึ่งสตาร์ทล่าช้า 100 มิลลิวินาที - ไม่มีใครเห็น แต่กระจาย 100 มิลลิวินาทีเดียวกันนั้นไปยังมอเตอร์สามร้อยตัวบนสิบห้าชั้น และความล่าช้าก็แพร่กระจาย คำสั่งส่งไปยังส่วนเครือข่ายที่แตกต่างกันในช่วงเวลาที่ต่างกัน เสี้ยววินาทีที่ระดับแพ็กเก็ตกลายเป็นคลื่นที่กลิ้งข้ามส่วนหน้าอาคาร
วิศวกรทดสอบการใช้งานมีชื่อที่ไม่เป็นทางการ: เอฟเฟกต์ซิป ชื่อนี้ติดอยู่เพราะมันอธิบายสิ่งที่คุณเห็นได้อย่างชัดเจน
สิ่งที่ต้องทำความเข้าใจคือเอฟเฟกต์ซิปเป็นอาการ ไม่ใช่การวินิจฉัย เมื่อคุณเห็น ที่ไหนสักแห่งระหว่างตัวควบคุมและมอเตอร์ จังหวะคำสั่งไม่สอดคล้องกัน หางานจริงที่ไหน
เหตุใดนักพัฒนาจึงทำสิ่งนี้อย่างจริงจัง
อาคารสำนักงานระดับพรีเมียมที่มีส่วนหน้าอาคารอัตโนมัติที่ไม่ประสานกัน เป็นปัญหาที่นอกเหนือไปจากวิศวกรรม ด้านหน้าเป็นส่วนหนึ่งของเอกลักษณ์ทางภาพของอาคาร เมื่อทำงาน ระบบอัตโนมัติจะมองไม่เห็น เมื่อไม่เป็นเช่นนั้น ผู้เช่าทุกคนบนชั้น 15 จะสังเกตเห็นก่อนดื่มกาแฟแก้วแรก
ฉันได้ยินคำร้องเรียนเดียวกันที่ใช้ถ้อยคำสองวิธีที่แตกต่างกันโดยสิ้นเชิง วิศวกรกล่าวว่า "เราเห็นความล่าช้าในกลุ่มมัลติคาสต์" ผู้จัดการสิ่งอำนวยความสะดวกกล่าวว่า "มู่ลี่ไม่ได้เคลื่อนมารวมกันอีกต่อไป" ปัญหาเดียวกันแต่ใช้ภาษาต่างกัน ทั้งสองติดตามกลับไปยังรากเดียวกัน
สำหรับนักพัฒนา ต้นทุนคือความน่าเชื่อถือ สำหรับผู้พักอาศัยคือความไว้วางใจในเทคโนโลยีของอาคาร สำหรับทีมรับหน้าที่ไล่ล่าผีเป็นเวลาที่ไม่อาจเรียกเก็บเงินได้
ต้นทุนพลังงาน: ทุกวินาทีที่ผ่านไปเพิ่มขึ้น
เซ็นเซอร์รับแสงกลางวันจะเริ่มทำงานที่เกณฑ์การฉายรังสีที่กำหนดไว้ล่วงหน้า มู่ลี่ควรปรับใช้ทันที แต่ถ้าคำสั่งกลุ่มใช้เวลา 800 มิลลิวินาทีในการแพร่กระจาย - ซึ่งไม่ใช่เรื่องผิดปกติในเครือข่ายยูนิคาสต์ขนาดใหญ่ - ทุก ๆ มิลลิวินาทีเหล่านั้นจะยอมให้รังสีดวงอาทิตย์กระทบกระจกภายในด้วยความเข้มเต็มที่
ความล่าช้าหนึ่งวินาทีโดยตัวมันเองไม่ได้เพิ่มอะไรที่สำคัญให้กับภาระการทำความเย็น แต่คูณวินาทีนั้นด้วยจำนวนเหตุการณ์ทริกเกอร์ต่อวัน ด้วยจำนวนวันในฤดูทำความเย็น ด้วยกระจกตารางเมตร และจำนวนนั้นก็เลิกเป็นเรื่องเล็กน้อยอีกต่อไป ด้านหน้าอาคารที่หันหน้าไปทางทิศตะวันตก-ในฤดูร้อนสามารถกระตุ้นให้เกิดการบังแดดได้หลายสิบครั้งต่อวันเมื่อมุมของดวงอาทิตย์เปลี่ยนไปและเมฆที่ปกคลุมผ่านไป การใช้งานล่าช้าทุกครั้งคือความร้อนที่ระบบ HVAC ต้องกำจัดออก
การศึกษาหลังการใช้อาคาร LBNL- ของอาคาร New York Times บันทึกไว้ว่าการบังแสงอัตโนมัติที่ผสานรวมกับการควบคุมการหรี่แสงในเวลากลางวัน- ช่วยลดการใช้พลังงานแสงสว่างต่อปีลง 56% ทั่วโซนปริมณฑล ผลลัพธ์ดังกล่าวถือว่าใช้งานได้ทันเวลา มู่ลี่ล่าช้าจะบ่อนทำลายเลขคณิตที่ทำให้การลงทุนแรเงาคืนทุน
นอกจากนี้ยังมีค่าใช้จ่ายรองภายในเครือข่ายด้วย เมื่อคำสั่งมาถึงล่าช้า ผู้ควบคุมจะส่งอีกครั้ง การส่งสัญญาณซ้ำจะใช้เวลาออกอากาศซึ่งควรจะพร้อมใช้งานในรอบคำสั่งถัดไป อัตราการลองซ้ำเล็กน้อยเป็นเรื่องปกติ - ทุกโปรโตคอลไร้สายคำนึงถึงสิ่งนี้ แต่ลองผสมอีกครั้ง กลุ่มที่เห็น 2% ลองอีกครั้งที่มอเตอร์ 50 ตัวอาจเห็น 8% ที่ 200 และเส้นโค้งการรับส่งข้อมูลไม่เป็นเชิงเส้น การลองใหม่แต่ละครั้งจะสร้างการรับส่งข้อมูลมากขึ้น ซึ่งทำให้เกิดการชนกันมากขึ้น ซึ่งทำให้เกิดการลองใหม่มากขึ้น วิศวกรที่วัดเวลาแฝงเมื่อเวลาผ่านไปมักจะพบว่าเครือข่ายกำลังอิ่มตัวอย่างช้าๆ
การเพิ่มมอเตอร์ไม่เพิ่มเวลาแฝงเชิงเส้น
ความเข้าใจผิดที่เกิดขึ้นอย่างต่อเนื่องประการหนึ่งในการอภิปรายโครงการคือการเพิ่มจำนวนมอเตอร์เป็นสองเท่าจะทำให้ความล่าช้าเป็นสองเท่า
ฉันเคยเห็นเครือข่าย 100 มอเตอร์ทำงานได้ดีกว่าเครือข่าย 60 มอเตอร์บนโปรโตคอลสแต็กเดียวกัน ฉันยังเห็นว่าเครือข่าย 250 มอเตอร์มีความเสถียรมานานหลายปี ในขณะที่เครือข่าย 120 มอเตอร์ในอาคารอื่นจำเป็นต้องทำการว่าจ้างใหม่ทุกๆ หกเดือน
ตัวแปรไม่ใช่จำนวนอุปกรณ์ ตัวแปรคือวิธีการออกแบบระบบการสื่อสาร: ตรรกะการจัดกลุ่ม ปริมาณงานของตัวควบคุม การเลือกโปรโตคอล โทโพโลยี ความถี่ในการอัพเดตสถานะ ไม่ว่าจะเปิดใช้งานการโพลหรือไม่ อาคารสองหลังที่มีมอเตอร์เดียวกัน เกตเวย์เดียวกัน และเฟิร์มแวร์เดียวกัน สามารถสร้างผลลัพธ์การทดสอบการใช้งานที่แตกต่างกันอย่างสิ้นเชิง หากหนึ่งในนั้นจัดกลุ่มมู่ลี่ทั้งหมดเป็นโซนเดียว และอีกอาคารถูกแบ่งพาร์ติชันตามการวางแนวด้านหน้าอาคาร
นี่คือสาเหตุที่ผู้ประกอบระบบที่มีประสบการณ์ตรวจสอบการกำหนดค่าเครือข่ายก่อนที่จะสัมผัสฮาร์ดแวร์
บันทึกบอกเล่าเรื่องราวที่แตกต่าง
ในโครงการหนึ่งที่ผลกระทบจากซิปรุนแรง ทีมงานดึงบันทึกการสื่อสารจากหนึ่งสัปดาห์ของรอบเช้าอัตโนมัติ
รูปแบบนั้นเกิดขึ้นทันที มอเตอร์ 001 ได้รับคำสั่งภายใน 12 มิลลิวินาที มอเตอร์ 200 ได้รับคำสั่งเดียวกันหลังจาก 940 มิลลิวินาที มอเตอร์ไม่ตอบสนองช้า - พวกเขาได้รับคำสั่งในเวลาที่ต่างกัน
การค้นพบนั้นเปลี่ยนแปลงการสืบสวนทั้งหมด ไม่ใช่ปัญหาการตอบสนองของมอเตอร์ มันเป็นปัญหาการกระจายคำสั่ง คอนโทรลเลอร์กำลังวนซ้ำผ่านอุปกรณ์ทีละตัวผ่านระบบยูนิคาสต์ และทุกเฟรมจะรอให้เฟรมก่อนหน้าได้รับการยอมรับก่อนที่จะส่งเฟรมถัดไป
มอเตอร์ 200 ตัว × ประมาณ 4.7 มิลลิวินาทีต่อเฟรม (คำนึงถึงเวลาออกอากาศ, CSMA/CA backoff และการตอบสนองของ ACK)=940 มิลลิวินาที คณิตศาสตร์ตรงกับความล่าช้าที่สังเกตได้เกือบจะทุกประการ
ตัวเลือกการสื่อสาร: หนึ่งคำสั่งเทียบกับการโทรส่วนบุคคลสองร้อยครั้ง
ความคล้ายคลึงที่มักเกิดขึ้นกับผู้มีส่วนได้ส่วนเสียของโครงการคือ: คุณต้องบอกคน 200 คนในอาคารเพื่อเข้าร่วมการประชุม คุณสามารถโทรศัพท์ทีละรายหรือประกาศผ่านระบบ PA ก็ได้ ผลลัพธ์เดียวกัน เวลาในการทำให้เสร็จแตกต่างอย่างสิ้นเชิง
การสื่อสารกลุ่มก็ทำงานในลักษณะเดียวกัน เครือข่ายแบบผู้รับเดียวจะสร้างแพ็กเก็ตเดี่ยวสำหรับมอเตอร์ทุกตัวและส่งตามลำดับ ทุกแพ็กเก็ตรอให้เคลียร์แพ็กเก็ตก่อนหน้า การหน่วงเวลาจะคิดเลขคณิตตามขนาดกลุ่ม
มัลติคาสต์สร้างหนึ่งเฟรมที่ส่งไปยังกลุ่มลอจิคัล มอเตอร์ทุกตัวในกลุ่มนั้นจะได้รับภายในหน้าต่างเกียร์เดียวกัน ความล่าช้าจะคงที่โดยไม่คำนึงถึงขนาดกลุ่ม - เวลาหนึ่งเฟรม ไม่ใช่เวลา N เฟรม
โปรโตคอล Matter ซึ่งดูแลโดย Connectivity Standards Alliance ระบุการสื่อสารแบบกลุ่มผ่าน Groups Cluster ID กลุ่มจะแมปกับชุดของโหนด Fabric และการส่งข้อมูลแบบหลายผู้รับเดียวจะเข้าถึงสมาชิกกลุ่มทั้งหมดพร้อมกัน นี่ไม่ใช่เทคนิคที่เป็นกรรมสิทธิ์ - ซึ่งถูกสร้างขึ้นในข้อกำหนดโปรโตคอล ความแตกต่างในทางปฏิบัติสำหรับการใช้งานมอเตอร์ 200 ตัวคือความแตกต่างระหว่างหนึ่งเฟรมและ 200 เฟรม
โทโพโลยีเครือข่าย: เหตุใดชั้นกายภาพจึงตัดสินใจผลลัพธ์
ตัวแปรอื่นที่กำหนดว่ามัลติคาสต์ใช้งานได้จริงในขนาดหรือไม่คือเลเยอร์เครือข่ายทางกายภาพ
ในโทโพโลยีแบบดาว - ซึ่งอธิบาย WiFi ส่วนใหญ่และการปรับใช้ Zigbee แบบเดิมจำนวนมาก - มอเตอร์ทุกตัวเชื่อมต่อโดยตรงกับจุดเข้าใช้งานส่วนกลางหรือผู้ประสานงาน เมื่อมอเตอร์ตัวหนึ่งตั้งอยู่หลังกำแพงรับแรงเฉือนคอนกรีตหรือตัวยก HVAC คุณภาพการเชื่อมต่อของมอเตอร์จะลดลงโดยไม่ขึ้นอยู่กับมอเตอร์ตัวอื่นๆ เครือข่ายชดเชยโดยการส่งซ้ำหรือลดอัตราข้อมูลสำหรับเส้นทางหนึ่ง ซึ่งกินเวลาออกอากาศที่ควรจะพร้อมใช้งานสำหรับคำสั่งกลุ่ม
เธรดใช้โมเดลอื่น มันสร้างตาข่าย: อุปกรณ์ที่จ่ายไฟหลัก-ทำหน้าที่เป็นเราเตอร์ การส่งต่อการรับส่งข้อมูลสำหรับอุปกรณ์ที่ใช้พลังงานจากแบตเตอรี่-ที่ไม่สามารถรักษา-ทางวิทยุได้ตลอดเวลา หากเส้นทางตรงไปยังมอเตอร์ 47 ถูกปิดกั้น เฟรมจะเส้นทางผ่านมอเตอร์ 32 และมอเตอร์ 18 เมชจะคำนวณเส้นทางใหม่อย่างต่อเนื่องตามตัวชี้วัดคุณภาพลิงค์ที่อัพเดตแบบเรียลไทม์ ไม่มีจุดล้มเหลวแม้แต่จุดเดียว ไม่มีสตรีมคำสั่งที่หยุดทำงานเพื่อรอการส่งสัญญาณใหม่ไปยังโหนดที่กำลังดิ้นรนหนึ่งโหนด
เกณฑ์มาตรฐานเครือข่ายแบบตาข่ายของ Silicon Labs ซึ่งดำเนินการในสำนักงานเชิงพาณิชย์ที่มีผู้เช่าซึ่งมีเครือข่าย WiFi และ Zigbee ที่ใช้งานได้ ให้การอ้างอิงที่เป็นอิสระ ในเครือข่ายขนาดใหญ่ที่มีเพย์โหลดปานกลาง: เวลาแฝงของเธรดอยู่ที่ประมาณ 100 ms, Zigbee แพร่กระจายไปที่ประมาณ 130 ms และ Bluetooth mesh ลดลงเกิน 250 ms ช่องว่างจะเพิ่มขึ้นตามขนาดเครือข่ายและเพย์โหลด ซึ่งเป็นเงื่อนไขที่สำคัญสำหรับการแรเงาเชิงพาณิชย์
นอกจากนี้ Thread ยังใช้ความคล่องตัวของความถี่: หากช่องสัญญาณ 2.4 GHz หนึ่งช่องอิ่มตัว เครือข่ายจะกระโดดไปยังช่องสัญญาณที่สะอาดขึ้นระหว่างการส่งสัญญาณ เลเยอร์แอปพลิเคชันมอเตอร์ไม่เคยเห็นการกระโดด ไม่ต้องลองอีกครั้ง ไม่มีความล่าช้าในการตอบสนอง นี่คือคุณสมบัติเธรดมาตรฐานที่ระบุในเลเยอร์ MAC ของ IEEE 802.15.4
ไม่ได้หมายความว่า Thread จะเป็นคำตอบที่ถูกต้องเสมอไป การก่อสร้างอาคาร ความหนาแน่นของอุปกรณ์ และคุณภาพการทดสอบการใช้งานยังคงมีอิทธิพลเหนือ สิ่งที่เธรดเปลี่ยนแปลงคือวิธีที่เครือข่ายลดระดับลงภายใต้โหลด - และสำหรับการปรับใช้แรเงาขนาดใหญ่ การย่อยสลายแบบค่อยเป็นค่อยไปเป็นสิ่งเดียวเท่านั้นที่สำคัญ
เมื่อส่วนหน้าดูช้า มอเตอร์คือสิ่งสุดท้ายที่ฉันตรวจสอบ
วิศวกรอาวุโสคนหนึ่งเคยพูดแบบนั้นกับฉันครั้งหนึ่ง และมันเป็นจริงทุกครั้งที่ฉันเห็นเอฟเฟกต์ซิปในสนาม
ประเด็นของเขาไม่ใช่ว่ามอเตอร์ไม่เคยล้มเหลว สาเหตุมาจากความล้มเหลวของมอเตอร์เป็นแบบไบนารี - ที่มอเตอร์สตาร์ทหรือไม่สตาร์ท การสื่อสารเสื่อมโทรมอย่างต่อเนื่อง - และจะแย่ลงเมื่อการจราจรเพิ่มขึ้น เมื่ออาคารเต็ม เมื่อระบบอื่นๆ ออนไลน์ การทดสอบการยอมรับจากโรงงานจะตรวจพบข้อบกพร่องของมอเตอร์ ไม่ค่อยตรวจพบปัญหาด้านการสื่อสารเนื่องจากสภาพแวดล้อมการทดสอบไม่มีความซับซ้อนของ RF เหมือนกับอาคารที่สร้างเสร็จซึ่งมีอุปกรณ์ 200 เครื่อง จุดเชื่อมต่อ WiFi 50 จุด และห้องมอเตอร์ลิฟต์ที่สร้าง EMI บรอดแบนด์ซึ่งอยู่ห่างออกไปสองชั้น
นี่คือสาเหตุที่ปัญหาการซิงโครไนซ์มักเกิดขึ้นระหว่างการใช้งาน ไม่ใช่ระหว่างการทดสอบเดินเครื่อง เครือข่ายใช้งานได้ดีเมื่อเป็นเพียงสิ่งเดียวที่ทำงานอยู่
วัดจุดสิ้นสุดที่ถูกต้อง
การสนทนาเกี่ยวกับเวลาแฝงมักจะเริ่มต้นด้วย "มอเตอร์เร็วแค่ไหน" รู้สึกเหมือนเป็นคำถามที่ถูกต้อง แต่จำกัดการตรวจสอบให้แคบลงเหลือเพียง 1% ของห่วงโซ่สัญญาณที่ผิด
มอเตอร์สามารถตอบสนองภายใน 8 มิลลิวินาทีหลังจากได้รับคำสั่ง หากคำสั่งใช้เวลา 900 มิลลิวินาทีกว่าจะมาถึง การลดเวลาตอบสนองของมอเตอร์จาก 8 ms เหลือ 6 ms ก็ไม่ทำให้คุณซื้ออะไรเลย
การวัดที่สำคัญคือตั้งแต่ต้นจนจบ-ถึง-: ช่วงเวลาจากตัวควบคุมที่ออกคำสั่งกลุ่มไปยังมอเตอร์แต่ละตัวที่เริ่มการเคลื่อนไหวทางกายภาพ ตัวเลขดังกล่าวจะจับตัวควบคุม สแตกเครือข่าย วิทยุ MCU ของมอเตอร์ และระยะกำลัง - ทุกอย่างที่อยู่ระหว่างคำสั่ง BMS และเอาท์พุตทางกล
เมื่อคุณติดตามจุดสิ้นสุด-ถึง- ภาพจะเปลี่ยนไป สองระบบที่ระบุเวลาตอบสนองของมอเตอร์เหมือนกันอาจแตกต่างกัน 800 มิลลิวินาทีตั้งแต่ต้นทาง-ถึง- เนื่องจากวิธีที่เครือข่ายกระจายคำสั่ง การเปรียบเทียบแผ่นข้อมูลจำเพาะไม่เคยเข้าใจเลย
เวลาแฝงโดยเฉลี่ยเป็นสิ่งเบี่ยงเบนความสนใจ
นี่คือกับดักที่ฉันเห็นวิศวกรตกอยู่ใน: พวกเขาเปรียบเทียบตัวเลขเวลาแฝงโดยเฉลี่ยและคิดว่าพวกเขาได้ตอบคำถามแล้ว
สองระบบ ทั้งสองรายงานโดยเฉลี่ย 18 มิลลิวินาที บนกระดาษเหมือนกัน ในการปรับใช้ สิ่งหนึ่งให้การตอบสนองที่สม่ำเสมอภายในย่านความถี่ที่แคบ อีกประการหนึ่งบางครั้งอาจเพิ่มขึ้นเป็น 80 หรือ 100 มิลลิวินาทีในระหว่างที่มีการจราจรหนาแน่น - และการเพิ่มขึ้นเหล่านั้น (ไม่ใช่ค่าเฉลี่ย) คือสิ่งที่ผู้คนเห็นเมื่อส่วนหน้าอาคารเคลื่อนที่
ตาไม่รับรู้ค่าเฉลี่ย มันรับรู้ถึงความผิดปกติ การพุ่งขึ้นอย่างรวดเร็ว 100 มิลลิวินาทีในกลุ่มมอเตอร์ 300 ตัว ทำให้เกิดความลังเลอย่างเห็นได้ชัดในส่วนหนึ่งของส่วนหน้าอาคาร และนั่นคือสิ่งที่เจ้าของอาคารจำได้ นี่คือเหตุผลที่วิศวกรทดสอบการใช้งานให้ความสำคัญกับเปอร์เซ็นไทล์ที่ 99 - หรือดีกว่านั้น ซึ่งก็คือเวลาแฝงสูงสุดที่สังเกตได้ - มากกว่าค่าเฉลี่ย ความสามารถในการคาดการณ์เหนือกว่าประสิทธิภาพสูงสุดทุกครั้ง

การวัดโลกจริง-: สิ่งที่เราวัดบนแพลตฟอร์มของเราเอง
ก่อนที่จะเปิดตัวแพลตฟอร์มควบคุมปัจจุบัน ทีมวิศวกรของเราได้ทำการตรวจสอบภายในเพื่อทำความเข้าใจว่าเวลาตอบสนองจะปรับขนาดตามขนาดกลุ่มอย่างไร
การตั้งค่า: มอเตอร์แบบท่อบนเครือข่ายเธรด-บน-สภาพภายในอาคารที่เสถียร คำสั่งกลุ่มซ้ำๆ เพื่อเพิ่มจำนวนอุปกรณ์ วัตถุประสงค์ไม่ใช่เพื่อให้ถึงขั้นต่ำที่น่าประทับใจ - แต่เป็นการตรวจสอบว่าเวลาในการตอบสนองยังคงสามารถคาดเดาได้เมื่อกลุ่มเติบโตขึ้น
ในการทดสอบหลายรอบด้วยมอเตอร์ 100 ตัว หน่วยส่วนใหญ่เริ่มเคลื่อนที่ภายใน 20 มิลลิวินาทีของคำสั่งกลุ่ม การอ่านช้าที่สุดคือประมาณ 22 ms การส่งสัญญาณแพ็คเก็ตซ้ำนั้นต่ำกว่า 0.5% ตลอด
|
มอเตอร์ |
การตอบสนองโดยทั่วไป |
|
20 |
~9 มิลลิวินาที |
|
40 |
~11 มิลลิวินาที |
|
60 |
~13 มิลลิวินาที |
|
80 |
~16 มิลลิวินาที |
|
100 |
< 20 ms |
การเพิ่มขึ้นเป็นไปอย่างราบรื่น - ไม่มีหน้าผา ไม่มีจุดที่ประสิทธิภาพพังกะทันหัน นั่นสำคัญกว่าจำนวนสัมบูรณ์ ระบบที่ค่อยๆ ลดลงภายใต้ภาระงานสามารถนำไปใช้งานได้อย่างมั่นใจในทุกขนาด ระบบที่ทำงานได้ดีกับมอเตอร์ 40 ตัวและพังเมื่ออายุ 80 ถือเป็นหายนะในการทดสอบการใช้งานที่รอจะเกิดขึ้น
สิ่งเหล่านี้เป็นตัวเลขควบคุม-สภาพแวดล้อม อาคารจริงมีโครงเหล็ก กระจก Low-E เครือข่าย WiFi ของคู่แข่ง และผู้คนที่เดินไปมาพร้อมกับอุปกรณ์เคลื่อนที่ ผลลัพธ์ของสนามจะแตกต่างกันไป การตรวจสอบความถูกต้องยืนยันว่าสถาปัตยกรรม - มัลติคาสต์บนเมช - ปรับขนาดตามที่คณิตศาสตร์คาดการณ์ไว้
ด้านกลไก: แม้แต่การสื่อสารที่สมบูรณ์แบบก็ไม่สามารถปกปิดความคลาดเคลื่อนได้
การสื่อสารได้รับความสนใจเนื่องจากเป็นที่ที่กลุ่มส่วนใหญ่อาศัยอยู่ แต่ถึงแม้จะมีการส่งคำสั่งที่สมบูรณ์แบบ - มอเตอร์ทุกตัวที่ได้รับเฟรมเดียวกันในเวลาเดียวกัน - การซิงโครไนซ์ยังคงสามารถหยุดทำงานในระดับกลไกได้
ความคลาดเคลื่อนของชุดกระปุกเกียร์ ความแปรผันของพรีโหลดแบริ่ง จังหวะเวลาปลดเบรก ความร่วมศูนย์ของเพลาเอาท์พุต - ทั้งหมดนี้ส่งผลต่อความเร็วของมอเตอร์ในการเปลี่ยนจากหยุดนิ่งไปเป็นหมุนหลังจากได้รับคำสั่งทางไฟฟ้า ความแตกต่างเป็นรายบุคคลเพียงไม่กี่มิลลิวินาทีซึ่งมองไม่เห็น มอเตอร์หลายร้อยตัวบนด้านหน้าอาคารเดียว พวกมันสะสมจนเดินโซเซอย่างเห็นได้ชัด
นี่คือเหตุผลว่าทำไมความสม่ำเสมอในการผลิตจึงไม่ใช่การสนทนาที่แยกจากประสิทธิภาพการสื่อสาร ทั้งสองสารประกอบ กระบวนการผลิตของเราเก็บส่วนประกอบของระบบส่งกำลังหลักไว้ที่ ±0.05 มม. บนเบาะนั่งลูกปืนและโปรไฟล์เกียร์ พิกัดความเผื่อดังกล่าวส่งผลโดยตรงต่อความสามารถในการทำซ้ำเชิงกลที่ลูปควบคุมเฟิร์มแวร์ขึ้นอยู่กับ
ค่าพิกัดความเผื่อที่เข้มงวดมากขึ้นหมายความว่าการตอบสนองตำแหน่งของตัวเข้ารหัสจะลงสู่ตำแหน่งที่มอเตอร์คาดหวังไว้จริงๆ พิกัดความเผื่อที่น้อยลงหมายความว่าลูปควบคุมจะแก้ไข - การยิงเกิน การดึงกลับ การสั่นแบบไมโคร - - อย่างต่อเนื่อง ซึ่งจะเผาผลาญพลังงาน และในสำนักงานที่เงียบสงบ จะได้ยินเสียงเมื่อมีเสียงล่าสัตว์เมื่อถึงขีดจำกัดหยุด ความแม่นยำในการสื่อสารและความแม่นยำทางกลถือเป็นสองครึ่งหนึ่งของปัญหาเดียวกัน
การออกแบบโซนเกิดขึ้นก่อนที่จะดึงสายแรก
ความล้มเหลวในการซิงโครไนซ์ส่วนใหญ่ได้รับการออกแบบไว้ในโปรเจ็กต์ก่อนที่จะเริ่มการจัดซื้อ
ข้อผิดพลาดที่พบบ่อยที่สุดคือการจัดกลุ่มตามพื้นเพราะนั่นคือวิธีการจัดระเบียบแบบสถาปัตยกรรม มันให้ความรู้สึกเป็นธรรมชาติ แต่ดวงอาทิตย์ไม่เคารพขอบเขตของพื้น ซุ้มด้านทิศตะวันออกรับภาระในตอนเช้า ด้านหน้าอาคารด้านทิศตะวันตกรับภาระในช่วงบ่าย หากคนตาบอดบนพื้นทุกคนได้รับคำสั่งทุกคำสั่ง ไม่ว่าดวงอาทิตย์จะตกกระทบด้านข้างอาคารหรือไม่ก็ตาม การรับส่งข้อมูลเครือข่ายจะขยายตัวเพิ่มขึ้นโดยไม่มีเหตุผลในการทำงาน
แนวทางที่ง่ายกว่า: จัดกลุ่มตามการวางแนวด้านหน้าอาคารก่อน แบ่งย่อยตามพื้นภายในแต่ละการวางแนววินาที โซนตะวันออก. โซนตะวันตก. โซนภาคเหนือ. โซนใต้. กลุ่มมัลติคาสต์แต่ละกลุ่มมีเพียงมอเตอร์ที่เคลื่อนที่ด้วยกันเสมอ - ค่าแสงดวงอาทิตย์เท่ากัน ลอจิกคำสั่งเดียวกัน ปริมาณการใช้ข้อมูลของกลุ่มลดลง แรงกดดันต่อคิวลดลง เวลาแฝงลดลง
เกณฑ์มาตราส่วน: เมื่อระบบไร้สายต้องการพันธมิตรแบบใช้สาย
มีจุดที่ระบบไร้สายบริสุทธิ์เริ่มต้องการการสนทนาเกี่ยวกับระบบสำรองแบบใช้สาย และจากประสบการณ์ของเรา จุดนั้นอยู่ที่มอเตอร์เกิน 500 ตัวบนเครือข่ายอาคารเดียว
ต่ำกว่า 300 Thread mesh ที่ได้รับการออกแบบมาอย่างดี-จะจัดการการควบคุมแบบกลุ่มโดยไม่มีดราม่า ความหนาแน่นของเมชระหว่าง 300 ถึง 500 ต้องการความสนใจ: วางแผนสำหรับอุปกรณ์ที่รองรับเราเตอร์อย่างน้อยหนึ่งเครื่อง-ต่อจุดสิ้นสุด 15 ถึง 20 จุด เพื่อให้ความหลากหลายของเส้นทางการกำหนดเส้นทางยังคงอยู่เมื่อมีอุปสรรคเกิดขึ้น
สูงกว่า 500 ความซับซ้อนในการดำเนินงานเปลี่ยนไป การอัปเดตเฟิร์มแวร์ในระดับนั้นจะทำให้เครือข่ายไร้สายอิ่มตัวหากคุณไม่ระวัง การทดสอบการทำงานของอุปกรณ์ใช้เวลานานกว่า ความน่าจะเป็นทางสถิติของเหตุการณ์พาร์ติชัน mesh - โดยที่ชุดย่อยของอุปกรณ์สูญเสียการเชื่อมต่อกับเราเตอร์ขอบชั่วคราว - เพิ่มขึ้นตามจำนวนโหนด แม้ว่าคุณภาพลิงก์โดยเฉลี่ยจะดีเยี่ยมก็ตาม
ที่เกณฑ์ดังกล่าว การเพิ่มแบ็คโบนแบบมีสาย RS-485 เป็นพาธคู่ขนานสำหรับการแจกจ่ายเฟิร์มแวร์และเฟลโอเวอร์ไม่ใช่การยอมรับว่าระบบไร้สายไม่น่าเชื่อถือ เป็นการรับทราบว่าในอาคารที่มีมอเตอร์ 500 ตัว เหตุการณ์พาร์ติชันระหว่างลำดับการรวมสัญญาณเตือนไฟไหม้ไม่ใช่สิ่งที่คุณต้องการอธิบายให้ AHJ เส้นทางแบบใช้สายเป็นการประกัน
โรงพยาบาล สนามบิน และอาคารของรัฐมีแนวโน้มที่จะระบุสถาปัตยกรรมไฮบริดโดยไม่คำนึงถึงจำนวนมอเตอร์ เนื่องจากต้นทุนของการหยุดทำงานในสภาพแวดล้อมเหล่านั้นทำให้การสำรองข้อมูลแบบใช้สายมีข้อผิดพลาดในการปัดเศษของงบประมาณโครงการทั้งหมด สถาบันอุตสาหกรรมการก่อสร้างได้บันทึกว่าต้นทุนการทำงานซ้ำ - รวมถึงการว่าจ้างระบบใหม่ - โดยเฉลี่ย 12.4% ของต้นทุนโครงการที่ติดตั้ง แบ็คโบนการสื่อสารที่ซ้ำซ้อนมีค่าใช้จ่ายเศษเสี้ยวของการแนะนำมอเตอร์ 500 ตัวใหม่ หลังจากที่ปัญหาเครือข่ายแฝงปรากฏขึ้นหลัง-มีคนใช้งาน
คำถามห้าข้อที่สำคัญก่อนการลงชื่อออก
หลังจากรอบการทดสอบเดินเครื่องเพียงพอแล้ว คำถามเดิมๆ ก็ยังคงปรากฏอยู่เรื่อยๆ พวกมันไม่เคยเกี่ยวกับแรงบิดหรือ RPM
“มอเตอร์ทุกตัวผ่านการทดสอบเฉพาะตัว ทำไมกลุ่มถึงดูช้า?”
คุณกำลังดูปัญหาการกระจายคำสั่ง ไม่ใช่ปัญหาเกี่ยวกับมอเตอร์ ตรวจสอบว่าคอนโทรลเลอร์กำลังส่งคำสั่งแบบยูนิคาสต์ทีละรายการหรือไม่ ตรวจสอบความถี่ในการอัพเดตสถานะ ตรวจสอบว่ามอเตอร์ทั้งหมดอยู่ในกลุ่มขนาดใหญ่กลุ่มเดียวหรือไม่ ในกรณีส่วนใหญ่ การเปลี่ยนไปใช้การกำหนดแอดเดรสกลุ่มแบบหลายผู้รับจะช่วยแก้ไขความล่าช้าที่มองเห็นได้โดยไม่ต้องสัมผัสมอเตอร์ตัวเดียว
“ถ้ามอเตอร์ตัวหนึ่งเสีย มันจะพังกลุ่มไหม?”
มันไม่ควร มอเตอร์แต่ละตัวตอบสนองต่อเฟรมมัลติคาสต์เดียวกันอย่างเป็นอิสระ มอเตอร์เสียเพียงตัวเดียว - MCU ขัดข้อง ตัวเก็บประจุลัดวงจร การติดขัดของกลไก - ยังคงตายอยู่โดยตัวมันเอง อีก 199 คนดำเนินการคำสั่งตามปกติ หากมอเตอร์หลุดออกจากเครือข่ายโดยสิ้นเชิง แดชบอร์ดการจัดการควรตั้งค่าสถานะเป็นไม่-ตอบสนอง และควรเข้าร่วมกลุ่มอีกครั้งโดยอัตโนมัติเมื่อการเชื่อมต่อกลับคืนมา การแยกส่วนนี้เป็นข้อกำหนดที่ยากสำหรับแพลตฟอร์มการควบคุมเกรด-ที่ใช้งานจริง
"ระบบไร้สายเชื่อถือได้จริงหรือไม่ในหอคอยเหล็ก-และ-แก้ว"
ใช่ หากเลือกโปรโตคอลและโทโพโลยีสำหรับสภาพแวดล้อมนั้น สถาปัตยกรรมแบบตาข่ายของ Thread กำหนดเส้นทางไปรอบๆ สิ่งกีดขวาง แทนที่จะขึ้นอยู่กับจุดเชื่อมต่อจุดเดียวที่เจาะทะลุสิ่งกีดขวางเหล่านั้น ความคล่องตัวของความถี่จะกระโดดออกจากช่องสัญญาณที่อิ่มตัวโดยไม่เกี่ยวข้องกับเลเยอร์แอปพลิเคชัน เกณฑ์มาตรฐานของ Silicon Labs ที่อ้างถึงก่อนหน้านี้ทำงานในสำนักงานที่มี WiFi และ Zigbee แข่งขันกันเพื่อชิงเวลาออกอากาศ - ไม่ใช่ห้องปฏิบัติการที่มีการป้องกัน - และ Thread มีเวลาในการตอบสนองต่ำที่สุดในทุกสภาวะการทดสอบ
อย่างไรก็ตาม ไม่มีโปรโตคอลใดที่จะขจัดความจำเป็นในการสำรวจ RF ก่อน-การติดตั้งในวงกว้างได้ อาคารที่เคลือบหน้าต่างด้วยโลหะ Low-E มีพฤติกรรมแตกต่างจากอาคารที่มีกระจกใส โครงสร้างผนังสำเร็จรูป-บน-การก่อสร้างแบบสตั๊ดมีลักษณะแตกต่างจากคอนกรีตเทและเหล็กเส้น ตาข่ายรองรับสิ่งกีดขวางได้ดีกว่าแบบดาว มันไม่ได้ทำให้ฟิสิกส์เป็นทางเลือก
"เวลาแฝงที่ต่ำกว่าจะดีกว่าเสมอหรือไม่"
เฉพาะในกรณีที่สอดคล้องกันเท่านั้น ระบบที่ให้เวลา 18 มิลลิวินาทีทุกครั้งจะสร้างส่วนหน้าอาคารที่สม่ำเสมออย่างเห็นได้ชัด ระบบที่สามารถใช้เวลาถึง 10 มิลลิวินาทีภายใต้สภาวะที่เหมาะสม แต่จะเพิ่มขึ้นเป็น 80 มิลลิวินาทีเมื่อมีการจราจรเพิ่มขึ้น ทำให้เกิดส่วนหน้าที่ดูวิตกกังวล สำหรับเจ้าของอาคาร ความสามารถในการคาดการณ์คือสิ่งที่ผู้อยู่อาศัยสังเกตเห็น เอกสารข้อมูลจำเพาะขั้นต่ำคือสิ่งที่วิศวกรฝ่ายขายพูดถึงในการประชุมประมูล พวกเขาไม่ค่อยเหมือนกัน
ก่อนเริ่มโครงการต่อไป
บทเรียนที่ทำซ้ำในโครงการแรเงาขนาดใหญ่นั้นเป็นเรื่องง่าย: ปัญหาการซิงโครไนซ์แทบไม่เคยเริ่มต้นที่มอเตอร์เลย
เมื่อมองเห็นเอฟเฟกต์ซิปจากถนน สาเหตุที่แท้จริงก็สะสมอยู่ในระบบการสื่อสารอย่างเงียบ ๆ เป็นเวลาหลายสัปดาห์หรือหลายเดือน ทีมว่าจ้างที่มีประสบการณ์จะรู้เรื่องนี้ดี พวกเขาตรวจสอบการกำหนดค่าเครือข่ายก่อนที่จะสั่งฮาร์ดแวร์ทดแทน
คำถามห้าข้อที่สำคัญ:
คำสั่งถูกแจกจ่ายโดย multicast หรือ unicast หรือไม่?
มีอุปกรณ์กี่เครื่องที่ใช้เส้นทางการสื่อสารแต่ละเส้นทางร่วมกัน
เปิดใช้งานการสำรวจสถานะที่ไม่จำเป็นมากน้อยเพียงใด
เวลาแฝงสามารถคาดเดาได้เมื่อจำนวนอุปกรณ์เพิ่มขึ้นหรือไม่
ความล้มเหลวในการสื่อสารเพียงครั้งเดียวสามารถแยกออกจากกันได้หรือไม่?
การตอบคำถามห้าข้อเหล่านี้อย่างถูกต้องจะมีผลกระทบต่อประสิทธิภาพของส่วนหน้าอาคารมากกว่าข้อกำหนดของมอเตอร์ใดๆ ในเอกสารข้อมูล
เวลาตอบสนองไม่ใช่ตัวชี้วัดของมอเตอร์จริงๆ มันเป็นระบบเมตริก ในขณะที่อาคารพาณิชย์ผลักดันไปสู่การบูรณาการที่เข้มงวดมากขึ้นระหว่างการแรเงา แสงสว่าง และ HVAC ความสามารถในการดำเนินการคำสั่งตามกำหนดเวลาบนอุปกรณ์ปลายทางหลายร้อยจุดกำลังกลายเป็นตัวเลขประสิทธิภาพที่กำหนดว่าการลงทุนด้านระบบอัตโนมัตินั้นคุ้มค่าหรือไม่ มอเตอร์ไม่ค่อยมีปัญหาคอขวด สถาปัตยกรรมระหว่างพวกเขาเกือบจะเป็นเสมอ

