Machine Translated by Google

UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm

Tài liệu này mô tả quy trình thiết kế ứng dụng theo các quyết
định chính phải được thực hiện về cách kiến trúc một giải pháp NHỮNG ĐIỂM CHÍNH

mạng không dây.

• Ngăn xếp hoặc khung ứng dụng nào để
sử dụng?
Loạt bài Nguyên tắc cơ bản của Phòng thí nghiệm Silicon bao gồm các chủ đề mà người quản
lý dự án, người thiết kế ứng dụng và nhà phát triển nên hiểu trước khi bắt đầu làm việc • SoC, NCP hay RCP? •

trên một giải pháp mạng nhúng sử dụng chip Silicon Labs, ngăn xếp mạng như EmberZNet PRO Lựa chọn thiết kế Zigbee

hoặc Silicon Labs Bluetooth® và các công cụ phát triển liên quan . Các tài liệu này có thể
được sử dụng làm nơi bắt đầu cho bất kỳ ai cần giới thiệu về cách phát triển các ứng dụng
kết nối mạng ít dây hơn hoặc những người mới làm quen với môi trường phát triển của Phòng
thí nghiệm Silicon.

silabs.com | Xây dựng một thế giới kết nối hơn. Bản quyền © 2022 của Phòng thí nghiệm Silicon Phiên bản 2.5
 UG103.3: Nền tảng cơ bản về thiết kế phần
Machine Translated by Google
mềm

1. Bối cảnh

Phòng thí nghiệm Silicon đang phát triển các sản phẩm được thiết kế để đáp ứng nhu cầu của khách hàng khi chúng ta chuyển sang thế giới thiết bị trong nhà luôn được

kết nối, thường được gọi là IoT (Internet vạn vật). Ở cấp độ cao, các mục tiêu của IoT dành cho Phòng thí nghiệm Silicon là: • Kết nối tất cả các

thiết bị trong nhà với mạng tốt nhất trong lớp, cho dù với Zigbee, Thread, Bluetooth hay giá đỡ mới nổi khác
Hội chứng suy hô hấp cấp tiến triển.

• Tận dụng kiến thức chuyên môn của công ty về vi điều khiển thân thiện với năng lượng.

• Tăng cường các chip tín hiệu hỗn hợp, năng lượng thấp đã được

thiết lập. • Kích hoạt các dịch vụ đám mây và khả năng kết nối với điện thoại thông minh và máy tính bảng nhằm thúc đẩy tính dễ sử dụng và trải nghiệm chung cho người dùng
khách hàng.

Đạt được tất cả các mục tiêu này sẽ tăng tỷ lệ sử dụng và sự chấp nhận của người dùng đối với các thiết bị IoT trong Ngôi nhà được kết nối.

Khi phạm vi tùy chọn có sẵn cho người thiết kế ứng dụng tăng lên, tác động của các lựa chọn thiết kế ban đầu cũng tăng lên. Tài liệu này mô tả quy trình thiết kế ứng

dụng theo các quyết định chính phải được thực hiện về cách kiến trúc giải pháp làm việc mạng không dây. Các lựa chọn thiết kế cơ bản bao gồm: • Sử dụng công nghệ không

dây nào của Phòng thí nghiệm Silicon • Sử dụng thiết kế

SoC (hệ thống trên chip) hay thiết kế NCP (bộ đồng xử lý

mạng)
•
Nếu sử dụng mô hình NCP, cách chọn ứng dụng NCP và host tương thích

Các lựa chọn thiết kế khi phát triển giải pháp Zigbee bao gồm: • Cách tạo

mạng (hình thành, tham gia hoặc rời khỏi) • Mô hình bảo mật

nào sẽ được sử dụng • Loại tối ưu hóa định

tuyến nào sẽ được sử dụng trong mạng • Cách gửi thông báo qua mạng

Khi bạn đã cân nhắc những lựa chọn này, bạn có thể bắt đầu triển khai thiết kế hệ thống.

Lưu ý: Zigbee EmberZNet SDK 7.0 đã giới thiệu một kiến trúc dựa trên thành phần mới, cùng với Trình cấu hình dự án và các công cụ khác để thay thế cấu hình plugin và

AppBuilder. Nói chung, các thành phần phần mềm mới có thể so sánh với các plugin. Trừ khi được chỉ định một cách khôn ngoan khác, thuật ngữ 'thành phần' nên được hiểu

là chỉ plugin tương ứng, nếu bạn đang làm việc trong SDK 6.10.x trở xuống. Khi áp dụng, hướng dẫn cho cả phiên bản 7.0 trở lên và 6.10.x trở xuống đều được cung cấp.

Để biết thêm thông tin, hãy xem AN1301: Chuyển đổi từ Zigbee EmberZNet SDK 6.x sang SDK 7.x.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 2
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Lựa
Machine Translated by Google
chọn thiết kế chung

2. Lựa chọn thiết kế chung

Trước khi bắt đầu thiết kế không dây với các bộ vi điều khiển không dây của Phòng thí nghiệm Silicon, trước tiên bạn nên xem xét công nghệ kết nối mạng có
sẵn nào sẽ phù hợp nhất cho dự án của bạn. Khi bạn đã quyết định về giao thức mạng mà bạn muốn sử dụng cho thiết kế của mình, hãy xem xét liệu sản phẩm của bạn
sẽ phù hợp nhất với mô hình Hệ thống trên chip (SOC) hay mô hình Bộ đồng xử lý mạng (NCP) và đối với NCP, điều gì loại giao tiếp nối tiếp để sử dụng để điều
khiển bộ đồng xử lý.

2.1 Bạn nên sử dụng giao thức không dây nào

Phòng thí nghiệm Silicon cung cấp các ngăn xếp sau để phát triển trên dòng Gecko không dây:

• SDK Flex của Phòng thí nghiệm Silicon, bao gồm ngăn xếp “Kết nối” dựa trên IEEE 802.15.4 (được mô tả trong UG103.12: Tinh thần cơ bản về Kết nối của Phòng
thí nghiệm Silicon) cho các cấu trúc liên kết mạng “hình sao” nhiều chặng và Thư viện Giao diện Trừu tượng Vô tuyến (RAIL) cho các thiết kế thực sự độc
quyền với cấu hình RF tùy chỉnh (được mô tả trong UG103.13: Nguyên tắc cơ bản về RAIL).

• EmberZNet, ngăn xếp mạng lưới dựa trên Zigbee PRO, được mô tả chi tiết trong UG103.2: Nguyên tắc cơ bản về Zigbee. • Silicon Labs

Bluetooth® SDK, ngăn xếp kết nối mạng Bluetooth, được mô tả chi tiết trong UG103.14: Nguyên tắc cơ bản về Bluetooth® LE. • SDK lưới Bluetooth® của

Phòng thí nghiệm Silicon , người bạn đồng hành với SDK Bluetooth hỗ trợ mạng lưới Bluetooth.

Để hỗ trợ phát triển ứng dụng, đối với mỗi giao thức hoặc nền tảng, Phòng thí nghiệm Silicon cung cấp mã ứng dụng mẫu và hỗ trợ khác, chẳng hạn như khung ứng
dụng hoặc cấu trúc GATT được cấu hình sẵn. EmberZNet và thành phần Connect của Flex SDK đều chứa một hoặc nhiều khung ứng dụng. Các khung ứng dụng chứa một
phần mã do Phòng thí nghiệm Silicon cung cấp được lưu trữ trong các thư viện và thành phần. Silicon Labs cũng cung cấp Simplicity Studio, bao gồm các công
cụ cấu hình như Project Configurator hoặc Application Builder (AppBuilder) cho phép bạn cấu hình các thư viện và thành phần có trong khung ứng dụng để triển
khai devi.
ces.

Sau khi tự làm quen với các chi tiết của các giao thức này, sự lựa chọn của bạn trong số chúng có thể sẽ tùy thuộc vào nhu cầu của bạn về việc tuân thủ các
tiêu chuẩn, cấu trúc liên kết mạng, khả năng tương tác, dải tần số và thông lượng tin nhắn.

2.2 SoC, NCP hay RCP?

Việc lựa chọn mô hình thiết kế─mô hình SoC (hệ thống trên chip), mô hình NCP (bộ đồng xử lý mạng nối tiếp) hoặc mô hình RCP (bộ đồng xử lý vô tuyến)─là một lựa
chọn quan trọng. Nó chỉ ra các yêu cầu và ràng buộc của cả phần mềm và phần cứng. Sự lựa chọn này chi phối vị trí của ứng dụng so với chức năng ngăn xếp lõi.
Trong mô hình SoC, toàn bộ hệ thống (ngăn xếp và ứng dụng) nằm trên một chip duy nhất, trong khi ở mô hình NCP, quá trình xử lý ngăn xếp được thực hiện trong
một “bộ đồng xử lý” riêng biệt tương tác với bộ vi điều khiển của chính ứng dụng thông qua giao diện nối tiếp bên ngoài. Trong mô hình RCP, quá trình xử lý vô
tuyến được thực hiện trong một “bộ đồng xử lý” riêng biệt và lớp ứng dụng và mạng được xử lý trên một bộ vi điều khiển riêng biệt với giao tiếp thông qua
giao diện nối tiếp.

Hình dưới đây minh họa các thành phần khác nhau của ngăn xếp và ứng dụng cũng như cách chúng được tổ chức tương ứng với mô hình kiến trúc SoC, NCP hoặc RCP.

Hình 2.1. Tổ chức thành phần ngăn xếp và ứng dụng trong kiến trúc SoC, NCP và RCP

Mặc dù việc lựa chọn giữa các kiến trúc không được thực hiện một cách nhẹ nhàng, nhưng khung ứng dụng che giấu sự khác biệt ở một mức độ nào đó, đơn giản hóa
việc thay đổi từ kiến trúc này sang kiến trúc khác khi cần thiết hoặc hỗ trợ kết hợp các kiến trúc cho các sản phẩm khác nhau.

Lưu ý rằng các ứng dụng Đa giao thức động phải được xây dựng bằng mô hình SoC hoặc RCP.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 3
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Lựa
Machine Translated by Google
chọn thiết kế chung

2.2.1 Phương pháp tiếp cận hệ thống trên chip

Theo cách tiếp cận SoC, một chip đơn, chẳng hạn như một trong các IC trong danh mục Wireless Gecko (EFR32™), cung cấp tất cả chức năng ngăn xếp (bao gồm đèn flash,

RAM và bộ thu phát RF tích hợp) cũng như các thành phần lớp ứng dụng (ứng dụng cấu hình, cụm, quản lý thuộc tính và tương tác ngăn xếp). Chức năng ngăn xếp được

triển khai dưới dạng các tệp thư viện được biên dịch sẵn. Bạn liên kết với các tệp li brary đó cùng với mã liên quan đến ứng dụng của riêng bạn trong quá trình xây

dựng cuối cùng để tạo ra một hình ảnh nhị phân nguyên khối duy nhất bao gồm mọi thứ cần thiết cho một ứng dụng không dây hoạt động hoàn toàn. Khung ứng dụng, mặc dù

được cung cấp bởi Phòng thí nghiệm Silicon, được coi là một phần của Lớp ứng dụng.

Lưu ý: Mặc dù bộ nạp khởi động thường được sử dụng trong các thiết bị mạng không dây đã triển khai, phần sụn bộ nạp khởi động đó không phải là một phần của hình ảnh

nhị phân ic nguyên khối này. Tuy nhiên, Phòng thí nghiệm Silicon cung cấp các công cụ hậu xây dựng có thể được sử dụng để kết hợp thêm cả phần sụn ứng dụng và phần sụn

ngăn xếp thành một tệp bản ghi HEX duy nhất để dễ dàng phân phối và sản xuất. Để biết thêm thông tin về các tiện ích phần mềm này cho các ứng dụng EmberZNet PRO, vui

lòng tham khảo tài liệu UG107: Hướng dẫn tiện ích ISA3, UG162: Hướng dẫn tham khảo Simplicity Commander và tài liệu UG103.6: Nguyên tắc cơ bản về bộ nạp khởi động.

Trong cách tiếp cận phát triển SoC, ứng dụng, bao gồm cả khung ứng dụng, cùng tồn tại với ngăn xếp. Ứng dụng gọi các API (chức năng giao diện lập trình ứng dụng) được

cung cấp bởi các thư viện ngăn xếp và ngăn xếp kích hoạt các chức năng xử lý được triển khai bởi mã ứng dụng. Khung ứng dụng xử lý việc gọi các API này và triển khai

các chức năng xử lý cần thiết, sau đó bao bọc chúng trong các hàm gọi lại ứng dụng và API cấp cao hơn để đơn giản hóa quy trình thiết kế và giúp đảm bảo tuân thủ

giao thức
ance.

Do mô hình SoC chỉ yêu cầu một chip duy nhất, so với mô hình NCP và các kiến trúc thiết kế kế thừa yêu cầu nhiều IC, mô hình SoC có mức tiêu thụ điện năng thấp hơn,

chi phí BOM (hóa đơn vật liệu) thấp hơn và bố cục nhỏ hơn có thể. Ngoài ra, có thể đạt được sự tích hợp chặt chẽ hơn với phần mềm ngăn xếp và phần cứng vô tuyến

khi mọi thứ nằm trên một chip duy nhất, cho phép kiểm soát chính xác và kịp thời hơn đối với các hành vi của ứng dụng liên quan đến hoạt động của ngăn xếp.

Tuy nhiên, một khi bạn đã cam kết với một mô hình SoC, bạn sẽ bị ràng buộc bởi các ràng buộc của các dịch vụ có sẵn trong dòng SoC đó.

Chúng bao gồm những điều sau: •

Các ràng buộc về bộ nhớ RAM và flash • Các ràng

buộc về chuỗi công cụ, chẳng hạn như yêu cầu sử dụng IAR Embedded Workbench cho ứng dụng đa giao thức động Zigbee/Bluetooth
cation

• Các hạn chế của HAL, chẳng hạn như số lượng thiết bị ngoại vi hạn chế của một loại nhất định hoặc thiếu thiết bị ngoại vi chuyên biệt có thể không thể thiếu đối với

thiết kế phần cứng của bạn

• Các ràng buộc về thời gian dựa trên việc phải chia sẻ CPU với ngăn xếp, ngăn xếp này có bộ yêu cầu riêng để duy trì IEEE
Tuân thủ 802.15.4 và giao thức

Nếu bất kỳ hạn chế nào trong số này gây cản trở quá nhiều, thì mô hình NCP có thể là một giải pháp thay thế hấp dẫn hơn.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 4
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Lựa
Machine Translated by Google
chọn thiết kế chung

2.2.2 Cách tiếp cận NCP với Giao thức nối tiếp

Lưu ý: Phần này không liên quan đến các mẫu Bluetooth SoC hoặc NCP. Để biết thêm thông tin, hãy tham khảo AN1042: Sử dụng ngăn xếp Bluetooth® của
Silicon Labs trong Chế độ đồng xử lý mạng và UG136: Hướng dẫn dành cho nhà phát triển ứng dụng Bluetooth® C của Silicon Labs.

Theo cách tiếp cận NCP, chip Silicon Labs với đèn flash, RAM và bộ thu phát RF tích hợp tự chạy hầu hết các chức năng ngăn xếp thông qua chương
trình cơ sở của bộ đồng xử lý được tải sẵn với khả năng cấu hình thời gian chạy, sau đó sử dụng giao diện nối tiếp như Giao diện ngoại vi nối
tiếp (SPI) hoặc Universal Bộ thu/Bộ phát không đồng bộ (UART) để giao tiếp với thiết bị thứ hai, được gọi là bộ xử lý “máy chủ”, trên đó chức
năng của lớp ứng dụng được “lưu trữ” riêng biệt với các thành phần ngăn xếp lõi. NCP có thể là một mạch tích hợp đặc biệt được thiết kế với I/O
hạn chế và giảm chức năng nhằm mục đích rõ ràng là hoạt động như một bộ đồng xử lý hoặc nó có thể là một bộ vi điều khiển có đầy đủ tính năng
tình cờ có chương trình cơ sở của bộ đồng xử lý được tải vào nó để làm cho nó hoạt động như một NCP.

Để tạo điều kiện giao tiếp giữa máy chủ của ứng dụng và NCP của ngăn xếp, Silicon Labs cung cấp hai bộ lệnh nối tiếp. Cái đầu tiên, được gọi là
EZSP (Giao thức nối tiếp EmberZNet), được sử dụng khi phát triển các giải pháp Zigbee (xem tài liệu UG100: Hướng dẫn tham khảo EZSP, để biết
thêm thông tin về EZSP.) Cái thứ hai, được gọi là Giao thức nối tiếp kết nối (CSP) được sử dụng khi phát triển Kết nối giải pháp

EZSP, hoạt động đồng bộ qua SPI hoặc không đồng bộ qua UART (có hoặc không có kiểm soát luồng), bắt chước API EmberZ Net PRO với các khung lệnh
dành riêng cho EZSP (đôi khi có thể khác một chút so với các đối tác dựa trên SoC của chúng trong EmberZ Net) và Các hàm xử lý liên quan đến
EmberZNet với các khung phản hồi gọi lại. Phòng thí nghiệm Silicon cung cấp mã nguồn trình điều khiển EZSP trừu tượng hóa các lệnh và phản hồi
nối tiếp này thành một bộ API và chức năng xử lý tương tự như các chức năng được sử dụng trong mô hình SoC. Khung ứng dụng đảm nhiệm việc gọi
các hàm API cần thiết và triển khai các hàm xử lý cần thiết, cho phép nhà thiết kế tập trung vào xử lý ứng dụng cấp cao hơn với API máy khách và
lệnh gọi lại khung.

Giao thức Nối tiếp Kết nối (CSP) được bộ xử lý ứng dụng Máy chủ sử dụng để tương tác với ngăn xếp Kết nối đang chạy trên NCP. Tin nhắn CSP được
gửi giữa Máy chủ và NCP qua giao diện UART. CSP là một giao thức nhị phân được gói gọn trong giao thức ASHv3. Để biết chi tiết về giao thức
ASHv3, hãy xem UG115: Tham khảo giao thức ASHv3.

Ưu điểm chính của nền tảng NCP là tính linh hoạt của nó. Bộ xử lý máy chủ có thể đơn giản như một bộ vi điều khiển 8 bit hoặc có thể phức tạp
như một máy tính 64 bit với bộ nhớ gigabyte và hệ điều hành Windows hoặc Linux. Điều này có nghĩa là thiết kế NCP rất phù hợp với các tình huống
trong đó thiết bị được thêm vào hoặc trang bị thêm cho hệ thống hiện có, sao cho chuyên môn và tài sản trí tuệ của OEM về phần mềm và phần cứng
có thể được tận dụng để tăng tốc chu trình thiết kế và đẩy nhanh thời gian đưa ra thị trường. Một ưu điểm khác của phương pháp NCP là máy chủ
có thể cung cấp nhiều tài nguyên hơn đáng kể (flash và RAM) và một bộ thiết bị ngoại vi khác cho ứng dụng so với các tùy chọn SoC có sẵn. Điều
này cho phép phát triển các ứng dụng phức tạp hơn với các tính năng mới và bảo vệ ứng dụng không vượt quá giới hạn của SoC khi các tính năng mới
quan trọng được thêm vào ứng dụng.

Việc tách xử lý ngăn xếp khỏi ứng dụng cho phép cài đặt các bản sửa lỗi và tính năng mới ở phía ngăn xếp với các bản cập nhật chương trình cơ
sở đơn giản cho NCP mà không nhất thiết yêu cầu bất kỳ thay đổi nào đối với chương trình cơ sở ứng dụng trên máy chủ. Việc tách rời này cũng
loại bỏ các ràng buộc về thời gian của CPU khi chia sẻ bộ xử lý với ngăn xếp. Vì chương trình cơ sở NCP quản lý trạng thái ngủ của NCP để giảm
thiểu hoạt động và mức tiêu thụ hiện tại của nó, chỉ bộ xử lý máy chủ cần hoạt động khi ứng dụng có các tác vụ không liên quan trực tiếp đến ngăn
xếp. Nếu mức tiêu thụ dòng điện hoạt động của bộ xử lý máy chủ thấp hơn so với SoC khi CPU hoạt động mà không có radio, thì tổng dòng điện mà
máy chủ và NCP tiêu thụ khi chạy các tác vụ ứng dụng không kết nối mạng có thể thực sự thấp hơn so với SoC trong một kịch bản có thể so sánh
được.

Nhược điểm chính của phương pháp NCP là việc bổ sung bộ xử lý thứ hai, máy chủ, làm tăng thêm chi phí và đặc tính thực của PCB, đồng thời có
thể ảnh hưởng đến mức tiêu thụ điện năng tổng thể của thiết bị. Một sự đánh đổi khác là việc tách ngăn xếp và xử lý ứng dụng có nghĩa là các
tương tác nhạy cảm với thời gian nhất định giữa ngăn xếp và ứng dụng không còn có thể xảy ra trong “thời gian thực” và thay vào đó phải xảy ra
dưới dạng thông báo về các quyết định do ngăn xếp đưa ra sau thực tế. Do đó, ứng dụng máy chủ có ít cơ hội hơn để quyết định kết quả của một số
quyết định nhất định khi chúng phát sinh. Thay vào đó, các “chính sách” được cấu hình trên NCP để hướng dẫn hành vi của ngăn xếp trong các tình huống đó.
Ngoài ra, do chương trình cơ sở NCP là chương trình cơ sở dựng sẵn do Silicon Labs cung cấp, nên nhà thiết kế ứng dụng sẽ mất một số quyền
kiểm soát đối với cách hoạt động của ngăn xếp và cách phân bổ tài nguyên bên trong của nó.

Khi bạn cam kết sử dụng phương pháp NCP, thì bạn phải quyết định sử dụng nền tảng máy chủ nào cho thiết kế. Nền tảng này có thể khác đối với các
giai đoạn tạo mẫu và thiết kế cuối cùng, tùy thuộc vào sự sẵn có của vật liệu và tính linh hoạt cần thiết trong các giai đoạn gỡ lỗi ban đầu. Khi
chọn nền tảng lưu trữ, hãy xem xét kiến thức chuyên môn hiện có của bạn cũng như các công cụ và tài nguyên sẵn có trên nền tảng đó, các yêu cầu
về chi phí và mức tiêu thụ điện năng của nền tảng đó cũng như dung lượng bộ nhớ khả dụng để phát triển ứng dụng, bao gồm mọi khoảng trống cần
thiết cho các cải tiến trong tương lai. Khi phát triển giải pháp Zigbee, bạn cũng nên xem xét nên sử dụng UART hay SPI để liên lạc EZSP. EZSP-
UART yêu cầu trình điều khiển phức tạp hơn, thường được thiết kế để sử dụng trong hệ điều hành tuân thủ POSIX, với logic phức tạp hơn và dung
lượng bộ nhớ lớn hơn trình điều khiển EZSP-SPI và thông lượng tối đa được hỗ trợ của nó không cao bằng. Tuy nhiên, việc triển khai EZSP-SPI yêu
cầu nhiều chân giao diện hơn so với thiết kế EZSP-UART. (Trình điều khiển SPI tương thích với Giao diện hệ điều hành di động (POSIX) dành cho
EZSP cũng có sẵn nhưng thường ít di động hơn trên các hệ điều hành Linux được nhúng so với trình điều khiển UART tương thích với POSIX.) Bởi
vì không phải tất cả các bộ vi điều khiển hoặc hệ điều hành đều hỗ trợ SPI, nên các hạn chế về kiến trúc tại máy chủ có thể ra lệnh lựa chọn thiết
kế này.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 5
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Lựa
Machine Translated by Google
chọn thiết kế chung

2.2.3 Cách tiếp cận RCP với Giao thức nối tiếp

Khi thiết lập RCP, RCP thực hiện ít chức năng hơn so với NCP, vì vậy chức năng này được kết nối bởi hai thành phần, Zigbeed Daemon và
Daemon Giao tiếp Đồng xử lý (CPCD). Zigbeed chạy ngăn xếp mạng Zigbee trên máy chủ. Nó được xây dựng với một lớp thích ứng Spinel dịch
giữa các nguyên mẫu MAC 802.15.4 và các thông điệp Spinel. Các thông báo Spinel từ Zigbeed được gửi tới CPCd, nơi chúng được đóng gói
và chuyển tiếp tới RCP. Zigbeed cũng mở một cổng nối tiếp ảo để giao tiếp với ứng dụng máy chủ bằng giao thức EZSP/ASH. Tiện ích dòng
lệnh socat được sử dụng để tạo hai cổng nối tiếp ảo (PTY) và liên kết chúng với nhau. Điều này cho phép ứng dụng máy chủ Zigbee được xây
dựng cho bộ đồng xử lý Zigbee NCP giao tiếp với Zigbeed không thay đổi.

Để biết thêm thông tin chi tiết về phương pháp RCP, hãy xem AN1333: Chạy đồng thời Zigbee, OpenThread và Bluetooth trên Máy chủ Li nux
với RCP đa giao thức.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 6
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Lựa
Machine Translated by Google
chọn thiết kế chung

2.2.4 Sự khác biệt trong thiết kế

Lưu ý: Phần này không liên quan đến các mẫu Bluetooth SoC hoặc NCP. Để biết thêm thông tin, hãy tham khảo AN1042: Sử dụng ngăn xếp Bluetooth®
của Silicon Labs trong Chế độ đồng xử lý mạng và UG136: Hướng dẫn dành cho nhà phát triển ứng dụng Bluetooth® C của Silicon Labs.

Bảng sau đây cho thấy một số khác biệt chính giữa ứng dụng SoC và ứng dụng máy chủ dựa trên NCP, theo chức năng.

Bảng 2.1. Sự khác biệt về chức năng, SoC so với NCP

Phương pháp Sự khác biệt

Quản lý các tham số ngăn xếp, chẳng hạn như kích thước bảng và giới hạn phân bổ cũng như dữ liệu mô tả điểm cuối, chẳng hạn như các cụm và
cấu hình hỗ trợ

SoC Chủ yếu được thiết lập thông qua các định nghĩa thời gian biên dịch được tích hợp tĩnh

vào tệp nhị phân của ứng dụng.

NCP Được quản lý bởi NCP nhưng được cấu hình bởi máy chủ trong thời gian
chạy sau khi khởi động NCP và trước khi tham gia vào bất kỳ hoạt động
mạng nào; khoảng thời gian này được gọi là giai đoạn “Cấu hình” và cho
phép cấu hình động NCP mà không cần xây dựng lại phần sụn của nó.

Ứng dụng phản ứng với các sự kiện

SoC Ứng dụng có thể phản ứng với các sự kiện, chẳng hạn như yêu cầu xác
thực bảo mật, thăm dò dữ liệu đến từ một đứa trẻ hoặc sửa đổi liên
kết từ xa, ngay lập tức và có thể xử lý các sự kiện trên cơ sở từng
trường hợp.

NCP Ứng dụng máy chủ định cấu hình các chính sách trước thời hạn để xác định
trước kết quả khai thác; thông báo là sau khi thực tế.

Bỏ phiếu (dành cho các thiết bị đầu cuối buồn ngủ cần thăm dò ý kiến mạng định kỳ)

Khung ứng dụng chăm sóc máy trạng thái bỏ phiếu, vì vậy sự khác biệt là không đáng kể.

SoC Ứng dụng kiểm soát thời điểm xảy ra mỗi cuộc thăm dò và chọn cách phản ứng
với kết quả của mỗi cuộc thăm dò.

NCP Ứng dụng máy chủ định cấu hình tỷ lệ thăm dò ý kiến và khả năng chịu lỗi.
NCP xử lý bỏ phiếu với tốc độ đã định cấu hình và chỉ thông báo cho máy
chủ lưu trữ khi tỷ lệ lỗi vượt quá ngưỡng đã định cấu hình.

Quản lý bộ đệm tin nhắn

Khung ứng dụng xử lý quản lý bộ đệm SoC, vì vậy sự khác biệt là không đáng kể.

SoC Ứng dụng chia sẻ bộ nhớ cho dữ liệu gói với ngăn xếp.
Bộ đệm tin nhắn được chia sẻ phải được ứng dụng phân bổ cho dữ
liệu tin nhắn gửi đi và bởi ngăn xếp cho dữ liệu tin nhắn đến hoặc
chuyển tiếp. Quy trình quản lý bộ đệm, bao gồm phân bổ/thỏa thuận
bộ đệm và xây dựng, có thể phức tạp và thường là nguồn gây ra lỗi
trong thiết kế ứng dụng SoC.

NCP NCP tự xử lý việc quản lý bộ đệm và chấp nhận/cung cấp dữ liệu tải
trọng thông báo dưới dạng một mảng đơn giản và một đối số độ dài.

Thêm và xóa chức năng vô tuyến và mạng lõi

SoC Khi thay đổi chức năng lõi (ngăn xếp) trong ứng dụng SoC, bạn chỉ cần
thêm hoặc xóa thư viện hoặc mã nguồn khỏi một ứng dụng. Điều này được
thực hiện dễ dàng bằng cách sử dụng khung ứng dụng bằng cách thay đổi
các thành phần được đưa vào.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 7
 UG103.3: Nguyên tắc cơ bản về thiết kế phần
Machine Translated by Google
mềm Lựa chọn thiết kế chung

Phương pháp Sự khác biệt

NCP Nếu bạn muốn thay đổi chức năng lõi (ngăn xếp) trong máy chủ cộng với
ứng dụng NCP, bạn phải thực hiện các thay đổi đối với cả tiến trình hoặc
ứng dụng máy chủ và chương trình cơ sở NCP. Điều này có thể gây trở
ngại nhỏ cho quá trình phát triển ứng dụng, nhưng Network Coproces sor
Application Framework cung cấp một giao diện để xây dựng các ứng dụng
NCP chỉ bao gồm các phần chức năng vô tuyến và mạng lõi được chọn.

2.3 Bảo mật

Một số khía cạnh bảo mật khác nhau phải được xem xét khi triển khai giải pháp IoT. UG103.5: Nền tảng bảo mật điểm cuối IoT sử dụng tám nguyên tắc
bảo mật của Liên minh ioXt làm cấu trúc để xem xét các khía cạnh đó. Tài liệu mô tả rõ ràng các giải pháp mà Phòng thí nghiệm Silicon cung cấp để
hỗ trợ bảo mật điểm cuối và những gì nhà sản xuất và nhà phát triển phải làm bên ngoài khuôn khổ của Phòng thí nghiệm Silicon. Các quyết định bao
gồm từ việc triển khai cơ sở hạ tầng cập nhật sản phẩm đến mức độ bảo mật mà ứng dụng cung cấp.
Ví dụ: hầu hết các giao thức đều cung cấp các mức bảo mật khác nhau, với sự đánh đổi giữa mức bảo mật và các tính năng khác, chẳng hạn như dễ hình
thành mạng. Các công cụ của Phòng thí nghiệm Silicon được thiết kế để hỗ trợ các mức bảo mật khác nhau do giao thức được đề cập cung cấp. Các
nhà thiết kế cần xem xét và quyết định mức độ được yêu cầu bởi các trường hợp sử dụng và ứng dụng cụ thể của họ. UG103.5: Tài liệu tâm lý về bảo
mật điểm cuối IoT cung cấp gợi ý cho tài liệu chi tiết hơn để giúp đưa ra các quyết định đó.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | số 8
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Zigbee
Machine Translated by Google
Design Choices

3. Lựa chọn thiết kế Zigbee

Mặc dù khung ứng dụng đơn giản hóa và trừu tượng hóa quy trình thiết kế, một số quyết định thiết kế phải được thực hiện như một phần của việc triển
khai. Các lựa chọn thiết kế sau đây được áp dụng khi phát triển các ứng dụng cho các giao thức Zigbee, bao gồm Zigbee PRO: • Mạng đơn hoặc Đa

mạng • Phương pháp khám phá / chạy

thử mạng • Phương pháp cung cấp và khám phá thiết

bị • Phương pháp thiết lập tuyến đường

• Phương thức gửi tin nhắn •

Khả năng tương thích của NCP và ứng dụng máy chủ

3.1 Mạng đơn so với Đa mạng

Một nút mạng duy nhất là một nút hình thành hoặc tham gia vào một mạng và phải rời khỏi mạng đó trước khi hình thành hoặc tham gia mạng thứ hai.
EmberZNet PRO 4.7 đã giới thiệu khả năng một nút đồng thời là một phần của nhiều mạng.

Lưu ý: Đối với EmberZNet PRO, hỗ trợ đa mạng được giới hạn ở hai mạng. Hơn hai mạng có thể được hỗ trợ trong tương lai.

Cho đến nay, bất kỳ thiết bị nào cũng yêu cầu hai chip vật lý là một phần của hai mạng. Chẳng hạn, một thiết bị được thiết kế để trở thành cổng kết nối
giữa HA (Tự động hóa gia đình) PAN (mạng khu vực cá nhân) và SE (Năng lượng thông minh) PAN sẽ tham gia mạng đầu tiên sử dụng chip thứ nhất và mạng thứ
hai sử dụng chip thứ hai . Ứng dụng phải quản lý hai phần cứng, dẫn đến tăng độ phức tạp cho phần cứng và nhà thiết kế ứng dụng.

Ngăn xếp đa mạng loại bỏ ánh xạ 1-1 giữa PAN logic và chip vật lý, mở rộng nó thành ánh xạ n-to-1. Một ứng dụng dành cho thiết bị có một chip đơn có
thể được thiết kế để trở thành một phần của nhiều PAN có thể chạy các cấu hình bảo mật khác nhau (ví dụ như HA và SE). Việc sử dụng một thay vì hai
chip giúp tiết kiệm chi phí nhờ giảm yêu cầu phần cứng và giảm độ phức tạp của thiết kế mã ứng dụng và phần cứng.

Một số ứng dụng vẫn yêu cầu cấu hình chip kép. Cấu hình này là cần thiết nếu thiết bị cần là điều phối viên hoặc bộ định tuyến trên hai mạng (xem thêm
chi tiết bên dưới) hoặc nếu ứng dụng cần hoạt động trên hai ngăn xếp khác nhau, chẳng hạn như EmberZNet PRO và Sili con Labs Connect.

Đa mạng trên một chip duy nhất đạt được bằng cách chia sẻ thời gian radio duy nhất của chip trên mạng. Nói cách khác, nút đa mạng đặt lại tất cả các
tham số vô tuyến giữa các mạng theo thuật toán lập lịch mạng.

Việc nút hoạt động đồng thời trên nhiều mạng là hoàn toàn minh bạch đối với ứng dụng. Các API cho phép ứng dụng chỉ định mạng nào mà một tập hợp các
lệnh gọi API được tham chiếu. Tương tự, các API cho phép ứng dụng hiểu cuộc gọi lại ngăn xếp có liên quan đến mạng nào. Xem tài liệu AN724: Thiết kế
cho nhiều mạng trên một chip đơn, để biết thêm chi tiết về API mạng kép.

Cả Khung ứng dụng Zigbee và Khung ứng dụng bộ đồng xử lý mạng đều cung cấp hỗ trợ mạng kép. Khung ứng dụng cung cấp nhiều lợi thế về độ phức tạp giảm,
chủ yếu liên quan đến cách khung quản lý liền mạch các ngữ cảnh mạng khác nhau.

Thông thường, một ngăn xếp nhiều mạng sẽ chuyển mạng hoặc dò lại radio trên một mạng khác, khi một gói gửi đi cần được gửi trên một mạng cụ thể. Trong
thời gian không truyền, radio luôn được điều chỉnh trên một trong các mạng, theo thuật toán lập lịch mạng nội bộ của ngăn xếp.

Có một số hạn chế đối với vai trò mà một nút có thể đảm nhận trên mạng. Vì một bộ điều phối hoặc một nút bộ định tuyến phải giữ cho đài liên tục lắng
nghe các gói đến, nên một nút đa mạng có thể là bộ điều phối hoặc bộ định tuyến chỉ trên một mạng, trong khi nó phải là một thiết bị đầu cuối không hoạt
động trên các mạng khác.

Lưu ý: Một nút có thể đảm nhận bất kỳ vai trò nào trên một mạng nhưng phải là thiết bị đầu cuối không hoạt động trên các mạng khác.

Các mạng mà một nút tham gia có thể nằm trên các kênh khác nhau, ID PAN khác nhau, ID ngắn khác nhau, cấu hình khác nhau, v.v. Tuy nhiên, một nút đa mạng
duy trì cùng một địa chỉ EUI64 trên các mạng mà nó tham gia. Các phần tiếp theo sẽ thảo luận chi tiết hơn về hai cấu hình cơ bản, cấu hình đầu tiên
trong đó nút đa mạng là bộ điều phối hoặc bộ định tuyến trên một và thiết bị đầu cuối không hoạt động trên tất cả các mạng khác và thứ hai là thiết bị
cuối không hoạt động trên tất cả các mạng .

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 9
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.1.1 Điều phối viên / Mạng bộ định tuyến + (các) mạng thiết bị đầu cuối buồn ngủ

Nút đa mạng là bộ điều phối/bộ định tuyến trên một mạng và là thiết bị đầu cuối không hoạt động trên các mạng khác sẽ dành phần lớn thời gian của nó
cho mạng điều phối/bộ định tuyến. Thuật toán lập lịch mạng liên tục đảm nhiệm việc chuyển đổi từ mạng này sang mạng khác sao cho nút luôn ở trên mạng
điều phối viên/bộ định tuyến trừ những khoảng thời gian ngắn. Cụ thể, nút tạm thời rời khỏi mạng điều phối viên/bộ định tuyến để hoàn thành một số
giao dịch nhất định trên mạng thiết bị đầu cuối buồn ngủ, chẳng hạn như thăm dò ý kiến/truy xuất dữ liệu từ nút gốc và/hoặc gửi dữ liệu tới nút gốc.
Các giao dịch này thường được bắt đầu ở lớp ứng dụng. Do đó, người thiết kế ứng dụng nên thiết kế ứng dụng sao cho nút không dành quá nhiều thời
gian cho mạng điều phối viên/bộ định tuyến. Việc một nút đa mạng quá bận trên mạng thiết bị đầu cuối buồn ngủ có thể ảnh hưởng nhất quán đến thông
lượng của nút và nói chung có thể làm chậm tất cả lưu lượng truy cập được định tuyến qua nút trên mạng điều phối viên/bộ định tuyến.

Trong tài liệu AN724: Thiết kế cho nhiều mạng trên một chip đơn, Phòng thí nghiệm Silicon cung cấp dữ liệu thu được từ các thử nghiệm mở rộng cho
thấy thời lượng trung bình của một số giao dịch dữ liệu và bỏ phiếu điển hình giữa thiết bị đầu cuối buồn ngủ và thiết bị mẹ của nó. Tài liệu này
cũng bao gồm một nghiên cứu chi tiết về cách hoạt động trên mạng thiết bị đầu cuối buồn ngủ ảnh hưởng đến thông lượng trên mạng điều phối viên/bộ
định tuyến. Với dữ liệu này, bạn có thể đưa ra các lựa chọn thiết kế có giáo dục dựa trên lượng lưu lượng mà nút đa mạng sẽ xử lý trên mạng không
hoạt động và lưu lượng này ảnh hưởng như thế nào đến hiệu suất của mạng điều phối/bộ định tuyến.

Lưu ý rằng ngay cả khi nút hoạt động như một thiết bị đầu cuối buồn ngủ trên hầu hết các mạng, nếu nó cũng là một bộ điều phối/bộ định tuyến trên
bất kỳ mạng nào, thì nó sẽ không thể tiết kiệm năng lượng bằng cách tắt radio tạm thời (chế độ ngủ) .

3.1.2 Nhiều mạng thiết bị Sleepy End

Một nút đa mạng là một thiết bị cuối buồn ngủ trên tất cả các mạng không cần phải luôn bật đài của nó. Nút có thể thăm dò với tỷ lệ bỏ phiếu khác nhau
trên mỗi mạng. Nút có thể ngủ miễn là không có hoạt động nào trên bất kỳ mạng nào.

3.2 Khám phá mạng / Chạy thử

Vận hành đề cập đến quá trình đưa các thiết bị vào mạng. Nếu bạn đã đọc phần thảo luận về quy trình tham gia mạng trong tài liệu UG103.2: Nguyên tắc
cơ bản về Zigbee, bạn có thể nhớ rằng trừ khi một thiết bị đóng vai trò là điều phối viên cho PAN, thiết bị đó phải yêu cầu tham gia mạng hiện có và
việc tham gia đó thiết bị phải quét một hoặc nhiều kênh để định vị các mạng khả dụng. Tuy nhiên, vì bộ điều phối mạng có một số kênh vô tuyến để chọn
trong việc hình thành PAN của nó và vì PAN ID và PAN mở rộng của mạng thường được chọn ngẫu nhiên, nên ứng dụng của bạn thường yêu cầu một số cơ
chế thông minh hoặc bên ngoài để hỗ trợ phát hiện và chạy thử công việc mạng . Các nhiệm vụ bao gồm giúp đảm bảo rằng thiết bị có thể tham gia đúng
mạng hoặc nhận cài đặt mạng mong muốn từ một số nguồn bên ngoài và đảm bảo rằng thiết bị có thể bị xóa khỏi mạng khi kết nối nhầm mạng hoặc thiết bị
đang bị đã chuyển sang cài đặt mới. Tương tự như vậy, nếu bạn đang thiết kế một thiết bị có thể hoạt động như một điều phối viên Zigbee PAN, điều
quan trọng là phải xem xét các cách mà bạn có thể giảm bớt quá trình lựa chọn mạng cho các thiết bị muốn vào mạng của điều phối viên của bạn.

Lưu ý: Nếu bạn đang thiết kế một ứng dụng để sử dụng trong hồ sơ ứng dụng Zigbee PRO chính thức, công khai (chẳng hạn như Tự động hóa gia đình),
Sili con Labs khuyên bạn nên xem lại bản sửa đổi được xuất bản mới nhất của đặc tả hồ sơ ứng dụng Zigbee phù hợp (có được từ http ://www.zigbee.org)
cho thiết kế mục tiêu của bạn, để đảm bảo rằng nó đáp ứng mọi yêu cầu dành riêng cho hồ sơ hoặc các phương pháp hay nhất để chạy thử.

3.2.1 Đơn giản hóa việc lựa chọn mạng thông qua ID PAN mở rộng hoặc Mặt nạ kênh

Mặc dù lựa chọn PAN ID mở rộng bởi điều phối viên của PAN nói chung là ngẫu nhiên, việc triển khai mạng độc quyền có thể sử dụng một bitmask cụ thể
của PAN ID mở rộng như một cách để tăng cường lựa chọn mạng cho các thiết bị tham gia. Trong mô hình này, điều phối viên tạo thành một mạng trong
mặt nạ ID PAN mở rộng đã thỏa thuận này, sao cho các thiết bị tham gia có thể quét các kênh để tìm PAN mở và giới hạn những kênh nằm ngoài phạm vi ID
PAN mở rộng đã định cấu hình. Tuy nhiên, phương pháp tăng cường lựa chọn mạng này không khả thi đối với các thiết bị muốn tương tác trên các cấu
hình Zigbee PRO công khai với các thiết bị từ nhiều nhà sản xuất. Bởi vì các cấu hình ứng dụng Zigbee PRO công khai thường không giới hạn lựa chọn ID
PAN mở rộng của chúng, thiết bị của nhà cung cấp khác có thể sử dụng ID PAN mở rộng bên ngoài bitmask giới hạn mà bạn đã chọn.

Tương tự, mặc dù mạng Zigbee 2,4 GHz có thể chiếm bất kỳ kênh nào trong số 16 kênh khác nhau, nhưng thiết bị tham gia có thể giới hạn mặt nạ kênh để
quét. Mạng dự kiến có thể là một thiết kế độc quyền trong đó điều phối viên đã chọn giới hạn việc lựa chọn kênh của mình chỉ với một vài kênh trong
mặt nạ được cấu hình sẵn. Ngoài ra, cấu hình ứng dụng dựa trên một hoặc nhiều điểm cuối của các thiết bị được bao gồm có thể yêu cầu hạn chế lựa chọn
kênh của mạng đối với một nhóm kênh cụ thể. Chẳng hạn, cả cấu hình ứng dụng Zigbee PRO SE và HA đều yêu cầu ưu tiên đó được cung cấp khi tạo mạng
cho các kênh bên ngoài phân bổ kênh Wi-Fi được sử dụng phổ biến nhất (kênh 1, 6 và 11 trong phạm vi IEEE802.11), trong đó cho phép thiết bị tham gia
giới hạn quá trình quét kênh của nó đối với các kênh Zigbee 11, 14, 15, 19, 20, 24 và 25. Lưu ý rằng Khung ứng dụng Zigbee sử dụng thành phần Tìm
mạng (nếu được bật) để định cấu hình mặt nạ kênh cho thiết bị khi tham gia hoặc hình thành một mạng lưới. Nếu sử dụng Trình tạo ứng dụng để định cấu
hình ứng dụng của bạn, hãy nhớ xem lại Mặt nạ kênh và các cài đặt tham số vô tuyến khác trong hộp thoại cấu hình cho thành phần Tìm mạng. Nếu bạn
không sử dụng thành phần Tìm mạng hoặc ứng dụng của bạn không dựa trên Khung ứng dụng Zigbee, mã ứng dụng của bạn cần sử dụng phương pháp riêng để
đảm bảo rằng mặt nạ kênh ưu tiên và bất kỳ tham số mạng ưu tiên nào khác được thực thi trong quá trình quét, tham gia hoặc hình thành các mạng lưới.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 10
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Zigbee
Machine Translated by Google
Design Choices

3.2.2 Kiểm soát phép tham gia

Các thiết bị muốn tham gia mạng thường chỉ xem xét những PAN mở cho thiết bị mới (nói cách khác, chúng cho phép tham gia) và các thiết
bị không được đặt vĩnh viễn cờ allowJoining, có nguy cơ không đạt kiểm tra tuân thủ Zigbee PRO đối với hồ sơ công khai và hồ sơ dành
riêng cho nhà sản xuất (MSP). Do đó, các thiết bị, đặc biệt là bộ điều phối PAN, phải đảm bảo rằng chúng có thể kích hoạt cờ allowJoining
cục bộ trong ít nhất một khoảng thời gian giới hạn khi cần thêm thiết bị mới vào mạng. Việc kích hoạt này thường phải đến từ một số kích
thích bên ngoài, điều này sẽ phụ thuộc vào khả năng vật lý của thiết bị. Nếu một nút hoặc giao diện nối tiếp có sẵn cho thiết bị, đây
thường là một kích thích thích hợp để kích hoạt allowJoining. Tuy nhiên, nếu thiết bị không có đầu vào bên ngoài để hoạt động như tác
nhân kích thích này, thì các phương pháp khác phải được xem xét. Một khả năng là để thiết bị kích hoạt allowJoining trong một khoảng
thời gian giới hạn khi bật nguồn lần đầu tiên. Một tùy chọn khác là kích hoạt allowJoining khi nút nhận được một thông báo cụ thể qua
mạng.

Đối với phương pháp thứ hai, mặc dù ứng dụng có thể thực hiện thay đổi cục bộ đối với trạng thái allowJoining của chính nó thông qua
lệnh gọi cục bộ tới API emberPermitJoining() hoặc lệnh allowJoining EZSP, nhưng cũng có thể gửi một yêu cầu tiêu chuẩn thông qua ZDO (Đối
tượng thiết bị Zigbee), được ngăn xếp triển khai nội tại, tới nút Zigbee để yêu cầu nút này thay đổi trạng thái allowJoining . Khi nhận
được Yêu cầu tham gia giấy phép ZDO qua mạng cho điểm cuối 0 (ZDO) trên hồ sơ ứng dụng 0x0000 (Cấu hình thiết bị Zigbee), ngăn xếp sẽ tự
động thay đổi trạng thái cho phép tham gia trên thiết bị. Unicast hoặc quảng bá yêu cầu này cung cấp một cách tiêu chuẩn để thay đổi quyền
tham gia mạng từ xa cho một số hoặc tất cả các thiết bị tương ứng. Để biết mã mẫu triển khai yêu cầu này, vui lòng tham khảo API
emberPermitJoiningRequest() có trong tệp “app/util/zigbee-frame work/zigbee-device-common.h” từ bản cài đặt EmberZNet PRO của bạn.

Sau khi mạng chứa ít nhất một nút trong phạm vi của thiết bị tham gia cho phép tham gia, thiết bị tham gia sẽ có thể phát hiện thiết bị
đó là có thể tham gia thông qua lệnh gọi lại emberNetworkFoundHandler() / ezspNetworkFoundHandler() gốc của ngăn xếp hoặc lệnh gọi lại
emberJoinableNetworkFoundHandler() gốc của ngăn xếp được cung cấp bởi tiện ích form-and-join có trong app/util/common/form-and-join.h,
được kiến trúc AFV2 sử dụng. (Xem thành phần “Tìm kiếm mạng” hoặc thành phần "Chỉ đạo mạng" của Khung ứng dụng Zigbee để biết cách triển
khai được đề xuất.)

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 11
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.2.3 Tránh hậu quả ngoài ý muốn trong quá trình chạy thử

Sau khi thiết bị tham gia của bạn tìm thấy một mạng có thể tham gia và cố gắng tham gia vào mạng đó, ứng dụng hoặc trình cài đặt phải xác định xem
đó có phải là mạng "chính xác" hay không, nghĩa là mạng dự kiến chứ không phải một số PAN tùy ý khác nằm trong phạm vi và cho phép tham gia. Quá
trình tham gia và xác thực tiếp theo, bao gồm việc lấy khóa mã hóa lớp NWK (mạng) hiện tại cho PAN, có thể thất bại theo nhiều cách khác nhau, ngay
cả khi tham gia mạng dự định. Do đó, việc loại trừ vĩnh viễn các mạng đã thử tham gia nhưng xảy ra lỗi khi tham gia/xác thực không nhất thiết là
phương pháp hay nhất. Tương tự như vậy, tùy thuộc vào kỳ vọng bảo mật của thiết bị tham gia của bạn, thiết bị đó có thể tham gia thành công vào
một mạng thực sự không phải là mạng chính xác, do đó, việc thiết lập vĩnh viễn vào mạng chỉ vì ngăn xếp gửi tín hiệu EMBER_NETWORK_UP, cho biết
rằng thiết bị đã được kết nối thành công và được xác thực vào mạng, cũng có thể không đủ. Các tiêu chí thích hợp để xác định xem mạng đã thử có
phải là mạng chính xác hay không sẽ khác nhau dựa trên các yêu cầu thiết kế của bạn, đặc biệt là khi có liên quan đến bảo mật.

Nếu bạn đang thiết kế một thiết bị để sử dụng trong mạng Zigbee PRO SE (Năng lượng thông minh), thì cần phải có quy trình ủy quyền trước phức tạp
trước khi thiết bị có thể vào mạng thành công. Xem tài liệu AN1233: Bảo mật Zigbee để biết thêm thông tin. Giả sử rằng yêu cầu ủy quyền trước đã
được đáp ứng trong mạng mục tiêu, việc vô tình tham gia sai mạng hầu như không thể xảy ra vì thiết bị tham gia sẽ không chấp nhận phân phối khóa
NWK nếu nó không được mã hóa hoặc được mã hóa bằng một APS khác (Ứng dụng hỗ trợ) phím liên kết.

Tuy nhiên, ngay cả với mô hình bảo mật SE, nút tham gia vẫn có thể cần tính đến thực tế là một liên kết không đáng tin cậy hoặc sự cố giao tiếp
khác, đặc biệt nếu nó liên quan đến trung tâm tin cậy của PAN, có thể gây ra việc gửi khóa NWK từ trung tâm tin cậy. trung tâm bị lỗi, ngay cả
trong mạng chính xác. Do đó, nếu một mạng có thể tham gia được phát hiện nhưng quá trình tham gia và xác thực sau đó không thành công với
EmberStatus của EMBER_NO_NETWORK_KEY_RECEIVED (có nghĩa là khóa NWK không đến thành công), EMBER_JOIN_FAILED (có thể biểu thị rằng Phản hồi của
Hiệp hội cho việc tham gia không được nhận thành công), hoặc EMBER_NO_BEACONS (có nghĩa là Yêu cầu liên kết trên mạng đã chọn không nhận được câu
trả lời), bạn có thể muốn thử lại quy trình tham gia trên PAN đó ngay lập tức hoặc sau đó, trong trường hợp lần thử đầu tiên không thành công do
một số gián đoạn tạm thời. Nếu quá trình kết nối hoặc xác thực tiếp tục không thành công trên PAN đã chọn, hãy cân nhắc thử tham gia một mạng có
thể tham gia khác, miễn là thiết bị của bạn có sẵn mạng này, vì lỗi có thể là dấu hiệu cho thấy đây đơn giản là mạng sai.

Trong các mạng sử dụng mô hình bảo mật HA (Tự động hóa gia đình) với khóa liên kết APS được định cấu hình sẵn, phổ biến được sử dụng để truyền
khóa NWK được tạo ngẫu nhiên, có nguy cơ vô tình tham gia nhầm mạng nếu có nhiều mạng có thể tham gia xảy ra trong phạm vi của thiết bị tham gia,
vì cài đặt bảo mật giữa các mạng này là chung cho gần như tất cả các mạng HA chứ không phải là duy nhất cho mỗi nút đến. Lưu ý rằng các mạng HA
có thể sử dụng một khóa liên kết được cấu hình sẵn khác, nhưng khóa này bằng cách nào đó phải được liên lạc với nút mới trước khi nó tham gia
mạng. Do đó, bạn nên hết sức cẩn thận trong thiết kế ứng dụng của mình để đảm bảo rằng, khi bạn nhập PAN thành công, đó thực sự là ứng dụng mong
muốn. Điều này thường liên quan đến một số loại quy trình “tham gia và xác minh” cho từng mạng khả dụng chấp nhận thiết bị của bạn, nghĩa là gửi
một số loại tin nhắn qua mạng được xác định rõ với phản hồi dự kiến để cho biết việc tham gia đúng mạng; phản hồi này có thể là một thông báo vô
tuyến khác hoặc có thể là một số loại hành vi có thể phát hiện được bởi một phần khác của hệ thống.

Một ví dụ về từng phương pháp được mô tả trong bảng sau, bắt đầu khi một nút mới tham gia mạng ứng cử viên:

Bảng 3.1. Phương pháp tham gia và xác minh

Kích hoạt sự kiện Thành công Ngoại lệ

ví dụ 1

Nút gửi yêu cầu Mô tả đối sánh ZDO quảng bá Phản hồi mô tả đối sánh ZDO nhận được từ một Lọc kết quả tìm thấy; nút chuyển đến ứng cử
cho một hoặc nhiều cụm mục tiêu quan trọng đối hoặc nhiều nút từ xa. viên mạng tiếp theo.

với hoạt động của nút.

Hãy cẩn thận:

Vì quy trình xác minh này chỉ phát hiện các thiết bị hỗ trợ các cụm mong muốn, nên quy trình có thể thành công khi nút tham gia đã vào một mạng
có cùng loại mô hình bảo mật và cùng loại khả năng của cụm như mạng dự kiến. Ví dụ: thiết bị mở cửa nhà để xe có thể tham gia một mạng tùy ý có
cửa nhà để xe để điều khiển, nhưng không phải là mạng dự định. Nếu điều này xảy ra, hệ thống phải bằng cách nào đó phát hiện tình trạng và
hướng dẫn nút mới rời khỏi mạng hiện tại và tìm một mạng khác.

Quá trình này chỉ thành công khi ít nhất một nút khác có dịch vụ phù hợp đã được tham gia vào mạng. Điều này đưa ra một yêu cầu vận hành
cho thứ tự các thiết bị phải được kết nối, yêu cầu này phải được thông báo cho trình cài đặt.

ví dụ 2

Bước 1: Nút gửi Yêu cầu mô tả khớp ZDO Nút nhận được Phản hồi mô tả đối sánh ZDO Không phản hồi; nút chuyển đến ứng cử viên công
unicast tới điều phối viên mạng (ID nút từ điều phối viên. việc mạng tiếp theo.

0x0000), cố gắng khớp một thiết bị có hỗ trợ

cho cụm máy chủ Nhận dạng ZCL.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 12
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

Kích hoạt sự kiện Thành công Ngoại lệ

Bước 2: Nút gửi lệnh Nhận dạng ZCL tới điều phối Điều phối viên tự xác định chính nó với hệ thống Nhận dạng không nhận được trong một khung thời gian
viên trên điểm cuối phù hợp. theo một số cách có thể phát hiện được. dự kiến; hệ thống tác động lên nút để nó rời khỏi

mạng và chuyển sang ứng viên tiếp theo.

Hãy cẩn thận

Ngoài các hướng dẫn cần thiết cho hệ thống, phương pháp này phụ thuộc vào việc có thể truy cập điều phối viên bất cứ khi nào một nút được kết nối với mạng. Đây

thường là trường hợp, vì điều phối viên thường hoàn thành vai trò của trung tâm tin cậy để cung cấp xác thực trung tâm cho mỗi nút mới.

Phương pháp này cũng yêu cầu phải có sẵn một số kích thích có thể truy cập hệ thống trên nút tham gia để cho phép nó thay đổi mạng.

ví dụ 3

Trung tâm tin cậy của PAN nhận lệnh gọi Trung tâm tin cậy của PAN thông báo cho hệ thống Hệ thống không nhận được dấu hiệu như mong đợi;
lại TrustCenterJoinHandler cho thiết bị tham gia. thông qua các chỉ dẫn hình ảnh hoặc âm thanh trên hệ thống tác động lên nút để nó rời khỏi mạng
Trung tâm tin cậy hoặc một số giao diện người dùng và chuyển sang ứng viên tiếp theo.
chuyên dụng như PC được nối mạng.

Hãy cẩn thận

Ví dụ này không yêu cầu ứng dụng của nút tham gia gửi thêm bất kỳ thông báo nào, giúp đơn giản hóa đáng kể thiết kế hoa hồng cho ứng dụng của nút tham gia. Tuy

nhiên, nó dựa vào trí thông minh và khả năng nhất định tại thiết bị trung tâm tin cậy của PAN. Việc sử dụng phương pháp này liên quan đến việc hợp tác với

người thiết kế nút trung tâm tin cậy (điều phối viên) dự kiến cho hệ thống của bạn.

Việc lựa chọn một trong các phương pháp trên, hoặc một số biến thể của chúng, có thể sẽ phụ thuộc vào khả năng của các thiết bị trong hệ thống của bạn, tầm quan trọng

của khả năng tương tác giữa nhiều nhà cung cấp trong thiết kế của bạn, độ trễ dự kiến của quy trình chạy thử và mức độ tinh vi. của những người cài đặt sẽ chạy thử

thiết bị của bạn.

Zigbee cung cấp một cụm vận hành trong ZCL, tạo điều kiện thuận lợi cho việc cài đặt qua mạng các thông số vận hành nhất định vào một thiết bị. Tuy nhiên, tại thời điểm

viết bài này, cả cấu hình HA và SE đều không yêu cầu triển khai cụm này ở phía máy khách hoặc máy chủ trong các loại thiết bị của nó, cũng như việc sử dụng cụm này

chưa được thử nghiệm như một phần của các sự kiện kiểm tra khả năng tương tác Zigbee cho các cấu hình này. Việc sử dụng cụm chạy thử chỉ khả thi trong các mạng mà

bạn có thể đảm bảo rằng nút tham gia có hỗ trợ phía máy chủ cho cụm chạy thử và ít nhất một thiết bị trong hệ thống có hỗ trợ phía máy khách để gửi lệnh chạy thử. Ngoài

ra, vì cụm vận hành thử dựa trên tin nhắn Zigbee, điều này đòi hỏi phải ở trong một mạng ngay từ đầu, nên bạn sẽ cần thiết kế một kế hoạch để thiết bị của bạn tham gia

mạng vận hành tạm thời nơi có một công cụ vận hành có thể cung cấp các yêu cầu cần thiết. thông số. Mặc dù khung ứng dụng cho phép sử dụng cụm chạy thử của ZCL, nhưng

việc triển khai cụm đó, nếu muốn, là trách nhiệm của nhà phát triển ứng dụng.

3.2.4 Cơ Chế Nghỉ Phép

Nhiều nhà thiết kế đã suy nghĩ cẩn thận về quy trình lựa chọn mạng và sau đó bỏ qua việc cung cấp cách để hệ thống gỡ cài đặt thiết bị khỏi mạng hiện tại rồi cài đặt

thiết bị đó vào một mạng mới. Như các ví dụ vận hành ở trên cho thấy, việc bật một số cách để thiết bị khởi tạo thủ công hoặc tự động một hành động emberLeaveNetwork()

và có thể tìm một mạng mới sau khi nghỉ phép hoàn tất, thường là cần thiết để hỗ trợ cài đặt và cài đặt lại thành công các thiết bị Zigbee theo ý muốn của chúng các

mạng.

Nếu điều này không thể được thực hiện trong phần cứng hoặc phần mềm của chính thiết bị tham gia, thì cơ chế Yêu cầu nghỉ phép của ZDO, được ngăn xếp tự động thực hiện,

có thể là một giải pháp thay thế khả thi, vì nó cho phép một nút khác trong PAN, chẳng hạn như nút của mạng. bộ điều khiển, để hướng dẫn một thiết bị rời khỏi mạng. Để

biết mã mẫu triển khai lệnh ZDO Leave Request, hãy tham khảo API emberLeaveRequest() có trong tệp “app/util/zigbee-framework/zigbee-device-common.h” từ bản cài đặt

EmberZNet PRO của bạn.

3.3 Khám phá và cung cấp thiết bị

Khi bạn đã kết nối thiết bị của mình với đúng mạng, thiết bị cần một số cách để được ghép nối với các nút khác trong PAN cung cấp các dịch vụ liên quan (nói cách khác,

các thiết bị phía máy khách được ghép nối với một hoặc nhiều thiết bị phía máy chủ thiết bị). Quá trình ghép nối các thiết bị có liên quan với nhau trong PAN để liên

lạc ở cấp ứng dụng được gọi là "cung cấp". Ngược lại, "ủy thác" liên quan đến việc liên kết các thiết bị với nhau để liên lạc ở cấp độ ngăn xếp mạng. Khi bạn kiến

trúc thiết kế của mình, hãy xem xét cách bạn sẽ khám phá thiết bị nào và bao nhiêu thiết bị trong PAN của bạn cung cấp các dịch vụ (cụm) quan tâm và bạn sẽ cung cấp các

thiết bị liên quan đó cho nhau bằng phương tiện nào. Lưu ý rằng quy trình cấp phép thực tế thường kết thúc với một hoặc nhiều thiết bị có liên quan, mỗi thiết bị đăng

ký (các) thiết bị đối tác vào bảng liên kết, bảng địa chỉ của nó hoặc một số cơ chế lưu trữ tùy chỉnh được thiết kế để ghi nhớ đối tác được cấp phép, để các thông báo

có thể được được gửi đến đích đó.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 13
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.3.1 Khi nào khám phá và cung cấp

Thông thường, các nhà thiết kế ứng dụng tạo ứng dụng của họ để thực hiện một số loại khám phá thiết bị và cố gắng cung cấp ngay sau khi quá trình chạy thử thiết bị hoàn

tất (nghĩa là ngay sau khi thiết bị trực tuyến). Tuy nhiên, vì các thiết bị tham gia cùng một lúc, có nghĩa là một bên của quá trình cung cấp thường trực tuyến trước

bên còn lại, nên bạn có thể sẽ cần phải có một cơ chế được khởi tạo bởi logic máy trạng thái phần mềm, ngắt bên ngoài hoặc một số kết nối không dây. kích thích, để bắt

đầu cung cấp sau này trong vòng đời của thiết bị trong mạng.

Các phương pháp cung cấp khác nhau được mô tả trong các phần tiếp theo, với những ưu điểm và nhược điểm của từng phương pháp.

Lưu ý: Nếu bạn đang thiết kế một ứng dụng để sử dụng trong hồ sơ ứng dụng Zigbee PRO chính thức, công khai chẳng hạn như Zigbee 3.0, Silicon Labs khuyên bạn nên xem

lại bản sửa đổi được xuất bản mới nhất của đặc tả hồ sơ ứng dụng Zigbee PRO thích hợp (có được từ http:// www.zigbee.org) cho thiết kế mục tiêu của bạn để đảm bảo rằng

mọi yêu cầu dành riêng cho hồ sơ hoặc các phương pháp cung cấp tốt nhất đều được thiết kế của bạn đáp ứng.

3.3.2 Phương pháp xác định và nhóm

Phương pháp này có thể được sử dụng để cung cấp một-một hoặc cung cấp một-nhiều, giữa một thiết bị nguồn duy nhất (thường là máy khách cho các cụm đang được cung cấp)

và một hoặc nhiều thiết bị đích (thường là máy chủ cho các cụm đang được cung cấp) . Nó liên quan đến việc đưa từng nút mục tiêu vào chế độ Nhận dạng thông qua việc

nhận lệnh Nhận dạng từ một số thiết bị hoặc thông qua một số kích thích bên ngoài. Sau đó, nút nguồn sẽ gửi lệnh “Thêm nhóm nếu xác định” (một lệnh máy khách bắt buộc

trong cụm Xác định của ZCL) dưới dạng phát sóng, sao cho tất cả các nút hiện đang ở chế độ nhận dạng tự thêm vào nhóm được chỉ định thông qua bảng nhóm do ZCL duy trì

Groups cụm máy chủ. Khi các thiết bị đích thuộc về một nhóm duy nhất, thiết bị nguồn có thể trực tiếp gửi phát đa hướng đến nhóm (EmberOutgoingMessageType của

EMBER_OUTGOING_DIRECT) hoặc bằng cách tạo liên kết Multicast cho nhóm mục tiêu rồi gửi các lệnh đi qua liên kết đó (EMBER_OUTGOING_VIA_BINDING).

Ưu điểm: • Cho

phép cung cấp đồng thời một thiết bị cho nhiều mục tiêu. • Chỉ yêu cầu một thông báo qua

mạng (lệnh Thêm nhóm nếu nhận dạng) nếu tất cả các thiết bị đích hỗ trợ phương pháp cục bộ để được đặt vào chế độ Nhận dạng.

• Có thể được thực hiện trong một khoảng thời gian dài hoặc ngắn, vì Thời gian xác định được sử dụng trong lệnh Xác định có thể được đặt rất nhỏ hoặc lớn. • Có

thể đưa thiết bị vào chế độ nhận dạng để chúng sẵn sàng cung cấp theo cách này qua mạng nếu cần, vì vậy hoạt động với các thiết bị không có kích thích cục bộ (nút hoặc

giao diện người dùng khác).

• Nếu không thể yêu cầu nút nguồn gửi lệnh Thêm nhóm nếu nhận dạng theo cách thủ công, thì nút nguồn có thể được đưa vào chế độ nhận dạng và được thêm vào nhóm để

liên kết phát đa hướng được tạo tự động (như một phần của logic bảng nhóm), để sử dụng trong giao tiếp với các mục tiêu.

Nhược điểm: • Thiết

bị mục tiêu phải hỗ trợ Nhóm máy chủ và Xác định cụm máy chủ. • Các thiết bị mục tiêu có

thể yêu cầu kích thích cục bộ chẳng hạn như nhấn nút để vào chế độ nhận dạng, trừ khi một thiết bị khác trong hệ thống

có thể được yêu cầu gửi lệnh Xác định tới các thiết bị quan tâm cụ thể.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 14
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.3.3 Phương pháp nhấn nút

Phương pháp này liên quan đến việc nhấn một nút trên một hoặc nhiều thiết bị để khiến thiết bị đó phát ra thông báo mà các thiết bị khác có thể nhận ra là tín hiệu để

tham gia cung cấp với thiết bị này khi thích hợp hoặc chuyển sang trạng thái nhận một thông báo cụ thể trong một cửa sổ thời gian cụ thể khiến nó tham gia vào việc cung

cấp với người gửi. Ví dụ: một công tắc đèn cần kết nối với một hoặc nhiều đèn có thể sử dụng một lần nhấn nút để chuyển sang trạng thái mà trong 30 giây tiếp theo, bất

kỳ thông báo “Thêm vào công tắc” nào được gửi bởi đèn sẽ khiến công tắc đăng ký mục nhập ràng buộc cho những công tắc đó. đèn. Tương tự, một lần nhấn nút (hoặc kích

thích khác) có thể được sử dụng để khiến các thông báo “Thêm vào công tắc” này được truyền đi bởi mỗi đèn.

Ưu điểm: • Rất

linh hoạt trong việc triển khai tùy theo hành động nào xảy ra khi nhấn nút và thời gian các trạng thái cung cấp nhất định kéo dài, điều này

lần lượt ảnh hưởng đến thời gian cho phép quá trình cung cấp.

• Có thể được sử dụng để cung cấp một-một hoặc một-nhiều. • Không yêu cầu

sự tham gia của bất kỳ thiết bị bên thứ ba nào (những thiết bị không thuộc hai bên của quy trình cung cấp). • Cho phép người dùng/người

cài đặt kiểm soát rõ ràng quy trình cung cấp thông qua tương tác thủ công. • Không cần bất kỳ hỗ trợ cụm đặc biệt

nào. • Có thể được sử dụng cùng với các phương pháp

cung cấp khác có liên quan đến tương tác thủ công, chẳng hạn như phương pháp Xác định và Nhóm.

Nhược điểm: • Một

hoặc cả hai bên của việc cung cấp yêu cầu kích thích cục bộ, chẳng hạn như một nút, để tham gia vào quá trình này. • Có thể liên

quan đến giao thức nhắn tin độc quyền (ví dụ: thông báo “Thêm vào chuyển đổi” độc quyền được thảo luận trong ví dụ trên) hoặc hành vi dành riêng cho ứng dụng cần thực

hiện, làm giảm cơ hội tương tác giữa các nhà cung cấp. • Việc cấp phép giữa các thiết bị không phù hợp có thể xảy ra nếu

nhiều quy trình cấp phép đang diễn ra đồng thời (chẳng hạn như nếu nhiều trình cài đặt đang thực hiện việc cấp phép bằng nút nhấn trên cùng một mạng vào cùng một thời

điểm).

3.3.4 Phương thức yêu cầu bộ mô tả đối sánh

Trong phương pháp này, một thiết bị đang tìm cách khám phá một đối tác cụ thể để cung cấp truy vấn một hoặc nhiều nút thông qua giao dịch Bộ mô tả đối sánh ZDO để tìm

đối tác cung cấp phù hợp dựa trên thông tin mô tả của các nút khác (hồ sơ ứng dụng, số nhận dạng thiết bị, ID cụm và hỗ trợ máy khách/máy chủ) cho từng điểm cuối của

chúng. Trong một tình huống điển hình liên quan đến phương pháp này, một thiết bị khách cho một cụm cụ thể (cụm X), được định cấu hình trên cấu hình ứng dụng Y, gửi

Yêu cầu bộ mô tả đối sánh ZDO dưới dạng quảng bá tới mạng, với thông tin bộ mô tả chỉ định điểm cuối với sự hỗ trợ của máy chủ cho cụm X trên cấu hình Y. Tất cả các nút

nhận được yêu cầu này sẽ tự động xử lý thông báo bằng cách sử dụng mã được tích hợp trong mọi ngăn xếp Zigbee PRO tiêu chuẩn, bằng cách cố gắng so khớp mô tả điểm cuối

được truy vấn với một bộ mô tả điểm cuối trên một trong các điểm cuối của chính chúng. Nếu một hoặc nhiều điểm cuối trên thiết bị được truy vấn phù hợp với tiêu chí

được yêu cầu, thì thiết bị được truy vấn sẽ phản hồi bằng Phản hồi mô tả đối sánh ZDO đơn sóng có chứa danh sách các điểm cuối phù hợp với yêu cầu. Sau đó, thiết bị

đã thực hiện truy vấn có thể phân tích cú pháp các câu trả lời và quyết định (và bao nhiêu) đối tác tiềm năng mà nó sẽ tự cung cấp.

Thuận lợi:

• Cung cấp khả năng ghép nối dựa trên một bộ tiêu chí hỗ trợ cụm cụ thể. • Không yêu cầu

sự tương tác của bên thứ ba để tạo điều kiện ghép nối (so với Phương thức liên kết thiết bị cuối). • Sử dụng các khung ZDO tiêu

chuẩn cho truy vấn và phản hồi, cho phép giải pháp có thể tương tác mà không cần phân tích cú pháp đặc biệt đối với truy vấn và phản hồi. Stack tự động xử lý các truy

vấn ZDO. • Truy vấn có thể là quảng bá hoặc unicast.

Nhược điểm: •

Thường dựa vào quảng bá để tìm tất cả các nút, điều này không đáng tin cậy 100% và tiêu tốn băng thông mạng. • Khi được gửi dưới dạng

truyền phát, Yêu cầu mô tả đối sánh ZDO chỉ có thể được gửi đến địa chỉ truyền phát Rx-On-When-Idle, nghĩa là

Không thể phát hiện ra các thiết bị đầu cuối buồn ngủ (Rx off when Idle) bằng phương pháp này.

• Ứng dụng yêu cầu một số logic bên trong hoặc giao diện người dùng để đánh giá người trả lời truy vấn và quyết định cái nào và cách thức

nhiều thiết bị nó sẽ tự cung cấp.

• Phản hồi của Bộ mô tả phù hợp có thể không chứa EUI64 của người gửi, vì vậy việc cung cấp dựa trên địa chỉ dài (chứ không phải ID nút động, 16 bit) có thể yêu cầu

giao dịch Yêu cầu địa chỉ IEEE ZDO unicast bổ sung để truy vấn EUI64 của nút đối tác.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 15
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.3.5 Phương pháp yêu cầu bộ mô tả đơn giản

Phương thức Yêu cầu mô tả đơn giản tương tự như phương thức Yêu cầu mô tả phù hợp ở chỗ nó sử dụng các truy vấn ZDO tiêu chuẩn để tìm hiểu về cấu hình điểm
cuối của nút đích (cấu hình, cụm, hỗ trợ máy chủ/máy khách, v.v.). Tuy nhiên, khi Yêu cầu bộ mô tả so khớp được gửi dưới dạng phát sóng hoặc phát một hướng để
thử so khớp các tiêu chí hỗ trợ cụm trên thiết bị nhận, thì Yêu cầu bộ mô tả khớp đơn giản chỉ được gửi dưới dạng unicast đến một điểm cuối cụ thể của nút
đích và tạo ra một danh sách đầy đủ của các cụm máy khách và máy chủ được hỗ trợ có sẵn trên điểm cuối đó của mục tiêu. Yêu cầu này có thể được sử dụng lặp đi
lặp lại trên mỗi điểm cuối có sẵn của nút đích để khám phá tất cả các hỗ trợ cụm có thể có trên các điểm cuối. Yêu cầu điểm cuối hoạt động ZDO thường được sử
dụng làm tiền thân cho các giao dịch Bộ mô tả đơn giản ZDO để thiết bị truy vấn có thể biết có bao nhiêu điểm cuối hợp lệ tồn tại tại nút đích và số điểm cuối
của chúng. Mặc dù phương pháp này mang lại thông tin đầy đủ hơn so với phương pháp Yêu cầu mô tả đối sánh, nhưng nó cũng kém hiệu quả hơn và do đó thường
không thực tế để sử dụng khi cần truy vấn một số lượng lớn thiết bị. Phương pháp này hữu ích nhất khi thiết bị truy vấn không chắc nó sẽ cung cấp cụm nào cho
thiết bị đích; sau khi biết cụm nào khả dụng trên thiết bị đối tác, nó có thể chọn trong số các cụm đó khi hoàn tất quy trình cung cấp.

Thuận lợi:

• Cung cấp khả năng ghép nối dựa trên một bộ tiêu chí hỗ trợ cụm cụ thể. • Không yêu

cầu sự tương tác của bên thứ ba để tạo điều kiện ghép nối. • Sử dụng các

khung ZDO tiêu chuẩn cho truy vấn và phản hồi, cho phép giải pháp có thể tương tác mà không cần phân tích cú pháp đặc biệt đối với truy vấn và phản hồi. Stack
tự động xử lý các truy vấn ZDO.

• Không phụ thuộc vào cơ chế quảng bá. • Không

yêu cầu thiết bị truy vấn biết cụm nào được mong đợi trên thiết bị đích.

Nhược điểm: • Yêu

cầu nhiều giao dịch qua lại (một giao dịch lệnh/phản hồi cho mỗi điểm cuối, cộng với một giao dịch cho Yêu cầu điểm cuối đang hoạt động để đánh giá số lượng
điểm cuối khả thi) để khám phá dữ liệu điểm cuối của mục tiêu. Mặc dù mức tiêu thụ băng thông tương đối thấp đối với các giao dịch này, nhưng độ trễ trong
quá trình hoàn tất quy trình cung cấp có thể là đáng kể, đặc biệt nếu có nhiều điểm cuối trên mục tiêu.

• Ứng dụng yêu cầu một số logic bên trong hoặc giao diện người dùng để giải mã các nút cần truy vấn và phải làm gì với phản hồi
dữ liệu khi nó đến.

• Phản hồi mô tả đơn giản có thể không chứa EUI64 của người gửi, vì vậy việc cung cấp dựa trên địa chỉ dài (chứ không phải ID nút động, 16 bit) có thể yêu cầu
giao dịch Yêu cầu địa chỉ IEEE ZDO unicast bổ sung để truy vấn EUI64 của nút đối tác.
Lưu ý: Nhiều thiết bị sẽ bao gồm EUI64 của chúng trong phản hồi ZDO khi yêu cầu là unicast với tùy chọn Nguồn EUI64 APS được bật, đây là hành vi mặc định
cho ngăn xếp EmberZNet PRO.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 16
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.3.6 Phương pháp công cụ cung cấp

Trong phương pháp này, thiết bị của bên thứ ba (không phải một trong các nút được cung cấp) lấy thông tin về một số hoặc tất cả các thiết bị trong mạng và sau
đó cung cấp giao diện người dùng để cho phép người cài đặt/quản trị viên của mạng cung cấp thiết bị cho nhau theo bất kỳ cách nào. cách mà anh ta cho là phù hợp.
Thông tin thiết bị này có thể được lấy thông qua một trong các quy trình khám phá ZDO được mô tả trong các phần trước (Yêu cầu bộ mô tả đơn giản hoặc Yêu cầu
bộ mô tả khớp) hoặc bằng một số phương tiện độc quyền hơn (tương tự như cách thông tin thiết bị được cung cấp bởi bộ tập trung mạng trong Quảng cáo thiết bị
phương pháp).

Công cụ cung cấp có thể là một thiết bị dành riêng cho vai trò này hoặc cũng có thể thực hiện các vai trò trung tâm khác trong mạng, chẳng hạn như bộ tập trung
mạng, bộ điều phối PAN, công cụ chạy thử hoặc cổng. Do công cụ cung cấp có khả năng giao tiếp với nhiều thiết bị khác nhau trong mạng, nên Silicon Labs khuyên bạn
nên làm cho nút này hoạt động như một bộ tập trung mạng để có sẵn các tuyến đến các nút khác mà không yêu cầu một loạt khám phá tuyến, điều này có thể gánh nặng
cho mạng và tăng độ trễ.

Sau khi công cụ quyết định thiết bị nào sẽ được cấp phép cho nhau, nó thường sử dụng Yêu cầu liên kết ZDO cho thiết bị đích để cài đặt mục nhập bảng liên kết để
liên lạc với thiết bị đối tác.

Thuận lợi:

• Cung cấp khả năng ghép nối dựa trên đầu vào của người dùng để cung cấp tính linh hoạt tối đa.

• Không yêu cầu bất kỳ thông tin tình báo nào ngoài hỗ trợ ZDO tiêu chuẩn trong ngăn xếp trong các thiết bị được cung cấp để khám phá thông tin. tất cả thông tin
gence nằm trong nút công cụ cung cấp.

• Các thiết bị được cấp phép không cần phải thức để tự cấp phép, vì vậy quá trình cấp phép có thể diễn ra khi một trong các thiết bị được cấp phép đang ở chế độ
ngủ.

• Các thiết bị không cần phải lo lắng về việc khám phá lại các nút để cung cấp khi các nút mới vào mạng, vì công cụ này có thể lấy
quan tâm đến điều này.

Nhược điểm: • Yêu

cầu một công cụ đặc biệt (thiết bị chuyên dụng hoặc bộ chức năng bổ sung trên thiết bị hiện có) với giao diện người dùng tùy chỉnh
để thuận tiện cho việc cung cấp.

• Công cụ cung cấp định kỳ cần thu thập thông tin từ các thiết bị để tránh xung đột với việc cung cấp của chính thiết bị đó
hành vi cư xử.

3.3.7 Khám phá địa chỉ

Vì việc cung cấp thường liên quan đến việc tạo mục nhập bảng liên kết hoặc bảng địa chỉ, dựa trên EUI64 cho các thiết bị theo dõi, nên các nút liên quan đến việc
cung cấp nên nỗ lực để có được EUI64 của các thiết bị đối tác của họ để tạo điều kiện thuận lợi cho việc tạo mục nhập bảng này. Ví dụ: khi sử dụng phương thức
Quảng cáo trên thiết bị, sẽ rất hữu ích nếu bao gồm EUI64 của nhà quảng cáo để ngăn không cho người nhận phát hiện ra điều này sau này, nếu người nhận chọn tự
cung cấp cho nhà quảng cáo. Một ví dụ khác, khi sử dụng các phương thức yêu cầu ZDO, chẳng hạn như các phương thức Yêu cầu mô tả đơn giản và Yêu cầu mô tả
khớp, khi có thể, yêu cầu phải chứa EUI64 nguồn của thiết bị yêu cầu để người nhận có thể phản hồi bằng cách cung cấp địa chỉ EUI64 của nó trong khung phản hồi,
cho phép cung cấp mượt mà hơn.

3.4 Thiết lập tuyến đường

Trong nhiều mạng, một lượng lớn dữ liệu được chuyển đến một nút duy nhất được chỉ định để lưu trữ dữ liệu hoặc chuyển dữ liệu sang hệ thống hoặc mạng khác. Hành
vi này phổ biến nhất trong các mạng cảm biến lớn, nơi thông tin được thu thập từ nhiều thiết bị và được tổng hợp tại một số điểm trung tâm.

Định tuyến nhiều-một (MTOR) cho phép một điểm tổng hợp (một “bộ tập trung” trong thuật ngữ Zigbee) cung cấp cho mọi thiết bị trên mạng một tuyến đến bộ tập trung
mà không cần từng nút phải khám phá riêng lẻ. Hơn nữa, MTOR cung cấp một phương tiện để truyền tải đến bộ tập trung tuyến đường riêng của mỗi nút đến bộ tập
trung đó. Điều này cho phép bộ tập trung thu thập một số hoặc tất cả các bản ghi tuyến đường này theo quyết định của nó, một kỹ thuật được gọi là "định tuyến
nguồn". MTOR hoạt động cùng với định tuyến nguồn để cho phép giao tiếp hai chiều giữa bộ tập trung và các nút khác mà không yêu cầu khám phá các tuyến mới hoặc
cập nhật tại thời điểm gửi tin nhắn.

3.4.1 Bối cảnh - Định tuyến nhiều tới một

Trong giai đoạn đầu phát triển của Zigbee, rõ ràng là một kiểu giao tiếp phổ biến trong các ứng dụng mạng không dây nhúng là nhiều đối một, trong đó có tới hàng
trăm thiết bị có thể giao tiếp với một cổng trung tâm. Tại Phòng thí nghiệm Silicon, đôi khi chúng tôi sử dụng thuật ngữ "tập hợp" để chỉ mẫu này và thuật ngữ "tập
hợp" cho nút cổng.

Lưu ý: Để biết thêm thông tin, hãy xem đặc tả Zigbee, tài liệu #053474. Các phần lưu ý bao gồm: 3.4.1.9 Trường khung con định tuyến nguồn, 3.5.5 Lệnh ghi tuyến,
3.7.3.3.1 Khởi tạo khung dữ liệu định tuyến nguồn và 3.7.3.3.2 Chuyển tiếp khung dữ liệu định tuyến nguồn.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 17
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.4.2 Cách hoạt động trong Zigbee PRO

Phần này trình bày ngắn gọn chi tiết về cách tập hợp hiện được chỉ định trong lớp mạng Zigbee PRO.

Bộ tập trung (ví dụ: cổng) thiết lập các tuyến đến chính nó bằng cách gửi yêu cầu tuyến nhiều-một. Đây chỉ là một yêu cầu định tuyến thông
thường được gửi đến một địa chỉ quảng bá đặc biệt. Nó báo hiệu lớp mạng của các nút nhận để tạo các tuyến đường vào thay vì tuyến đường
điểm-điểm. Không có phản hồi tuyến đường nào được gửi đi; khung lệnh ghi tuyến đường được mô tả bên dưới phục vụ mục đích tương tự về
mặt khái niệm.

Khi một thiết bị gửi unicast đến bộ tập trung, lớp mạng sẽ đảm nhận việc gửi khung lệnh ghi tuyến đến bộ tập trung trước. Khi gói bản ghi
tuyến đường được định tuyến đến bộ tập trung, các nút chuyển tiếp sẽ nối các ID ngắn của chúng vào khung lệnh. Bằng cách lưu trữ tuyến
đường thu được từ tải trọng bản ghi tuyến đường, bộ tập trung được cung cấp thông tin cần thiết để cung cấp các gói tuyến đường theo
hướng ngược lại.

Định tuyến nguồn được thực hiện bằng cách thêm một khung con vào khung mạng và thiết lập một bit trong trường điều khiển khung mạng. Khi
các rơle nhận được, chặng tiếp theo được đọc từ khung con thay vì bảng định tuyến cục bộ. Một cuộc gọi lại ứng dụng trên bộ tập trung sẽ
chèn khung con tuyến đường nguồn vào các xác nhận unicast hoặc APS gửi đi nếu cần.

Việc duy trì tuyến đường được thực hiện bởi ứng dụng bộ tập trung gửi lại yêu cầu tuyến đường nhiều-một đặc biệt.

Bạn có thể tìm thêm thông tin trong hướng dẫn tham khảo API trực tuyến và trong nhiều bài viết Câu hỏi thường gặp có sẵn trên Cổng thông tin Sup của Phòng thí
nghiệm Silicon.

3.5 Gửi tin nhắn

Phần này cung cấp một cái nhìn tổng quan về chủ đề này. Nếu bạn muốn biết thêm thông tin chi tiết, vui lòng tham khảo tài liệu UG105: Lập
trình ứng dụng nâng cao với API Stack và HAL.

Việc xử lý thông báo khác nhau tùy thuộc vào việc bạn đang sử dụng mô hình SOC hay NCP. Tuy nhiên, bất kể mô hình nào, nhiều chi tiết và
quyết định liên quan đến việc xử lý thông báo đều giống nhau. Nói chung, việc xử lý thư rơi vào hai nhiệm vụ chính: • Tạo

thư • Xử lý thư đến

Phần mềm ngăn xếp EmberZNet PRO xử lý hầu hết các công việc cấp thấp cần thiết trong việc xử lý thư. Hình dưới đây minh họa nơi ứng dụng
tương tác với hệ thống trong việc xử lý tin nhắn. Tuy nhiên, trong khi lớp APS xử lý cấu trúc khung APS, ứng dụng vẫn có trách nhiệm thiết
lập tiêu đề APS trên các thư gửi đi và phân tích cú pháp tiêu đề APS trên các thư gửi đến.

Hình 3.1. Mối quan hệ ứng dụng/hệ thống trong quá trình xử lý tin nhắn

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 18
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.5.1 Gửi tin nhắn

Ba loại tin nhắn cơ bản có thể được gửi: •

Unicast — được gửi đến một ID nút cụ thể dựa trên mục nhập bảng địa chỉ (ID nút cũng có thể được ứng dụng cung cấp theo cách thủ công
Nếu cần)

• Truyền phát — được gửi đến tất cả các thiết bị, tất cả các thiết bị không ngủ hoặc tất cả các thiết bị không phải ZED (Thiết bị đầu

cuối Zigbee) • Đa tuyến — được gửi đến tất cả các thiết bị chia sẻ cùng một ID nhóm

Trước khi gửi một tin nhắn, bạn phải xây dựng một tin nhắn. Khung thông báo thay đổi tùy theo loại thông báo và mức độ bảo mật.
Do phần lớn khung thông báo được tạo ra bên ngoài ứng dụng nên yếu tố chính cần được xem xét là kích thước tối đa của tải trọng thông
báo bắt nguồn từ ứng dụng của bạn.

Bảng sau đây hiển thị API chi tiết để gửi các loại thông báo phổ biến nhất.

Bảng 3.2. Chức năng nhắn tin API

API EmberZNet API khung ứng dụng Sự miêu tả

emberGửiUnicast ( emberAfSendUnicast( Gửi tin nhắn unicast theo thông số kỹ

Loại EmberOutgoingMessageType, Loại EmberOutgoingMessageType, thuật của Zig bee PRO.
int16u indexOrDestination, int16u indexOrDestination,
*
EmberApsKhung apsFrame, EmberApsFrame *apsFrame,
tin nhắn EmberMessageBuffer ) int8u messageLength,
int8u* message )

emberSendBroadcast ( emberAfSendBroadcast Gửi tin nhắn quảng bá theo thông số kỹ

EmberNodeId đích, ( đích int16u, thuật của Zigbee PRO. Tin nhắn sẽ được
*
EmberApsFrame apsFrame, bán EmberApsFrame *apsFrame, gửi đến tất cả các nút trong bán kính
kính int8u, int8u messageLength, bước nhảy của người gửi. Bán kính
tin nhắn EmberMessageBuffer ) int8u* message ) bằng 0 được chuyển đổi thành EMBER_MAX_HOPS.

emberSendMulticast ( emberAfSendMulticast( int16u Gửi một tin nhắn phát đa hướng đến tất
*
EmberApsFrame apsFrame, bán multicastId, cả các điểm cuối chia sẻ ID phát đa hướng
*
kính int8u, Độ dài tin nhắn apsFrame, cụ thể và nằm trong số bước nhảy được chỉ
int8u nonmemberRadius, EmberApsFrame int8u, định của người gửi.

tin nhắn EmberMessageBuffer ) tin nhắn int8u* )

Lưu ý: Xin lưu ý rằng tài liệu API trực tuyến bao quát hơn tài liệu được hiển thị ở đây. Luôn tham khảo tài liệu API trực tuyến để biết
thông tin chính xác.

Trong mọi trường hợp được minh họa ở trên, bộ đệm tin nhắn chứa tin nhắn. Thông thường, ứng dụng cấp phát bộ nhớ cho bộ đệm này (dưới
dạng bội số của 32 byte). Bạn có thể tự động tìm hiểu xem bộ đệm này có thể lớn đến mức nào, từ đó xác định kích thước tối đa của tin
nhắn sẽ được gửi. Hàm emberMaximumApsPayloadLength(void) trả về kích thước tối đa của tải trọng mà lớp con hỗ trợ ứng dụng sẽ chấp nhận,
tùy thuộc vào mức độ bảo mật được sử dụng. Điều này có nghĩa là: • Việc xây dựng thông báo

của bạn liên quan đến việc cung cấp các đối số cho hàm emberSend... loại thông báo thích hợp . • Sử dụng

emberMaximumApsPayloadLength(void) để xác định mức độ lớn của thông điệp của bạn. • Việc thực

thi chức năng emberSend... sẽ khiến tin nhắn của bạn được gửi đi.

Thông thường, hàm emberSend... trả về một giá trị. Kiểm tra tài liệu API trực tuyến để biết thêm thông tin.

Mặc dù nhiệm vụ gửi tin nhắn hơi phức tạp nhưng nó cũng rất nhất quán. Thách thức trong việc thiết kế ứng dụng của bạn là theo dõi các
giá trị đối số và thông báo sẽ được gửi. Một số thư có thể phải được gửi trong một phần phân đoạn và một số có thể phải được gửi lại
nếu xảy ra lỗi. Ứng dụng của bạn phải giải quyết hậu quả của những khả năng này.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 19
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm
Machine Translated by Google
Zigbee Design Choices

3.5.2 Nhận tin nhắn

Không giống như gửi tin nhắn, nhận tin nhắn là một quá trình cởi mở hơn. Ứng dụng được thông báo khi nhận được một tin nhắn, nhưng ứng
dụng phải quyết định phải làm gì với nó và cách phản hồi nó. Các ứng dụng dựa trên Khung ứng dụng Zigbee sử dụng nhiều chức năng gọi lại
khác nhau dành cho lệnh hoặc phản hồi cụ thể được biểu thị bằng thông báo, chẳng hạn như emberAfReadAttributesResponseCallback hoặc
emberAfDemandResponseLoadControlClusterLoadControlEventCallback. Xem UG391: Hướng dẫn dành cho nhà phát triển khung ứng dụng Zigbee dành
cho SDK 6.x trở xuống hoặc UG491: Hướng dẫn dành cho nhà phát triển khung ứng dụng Zigbee dành cho SDK 7.0 trở lên, để biết chi tiết về
cách khung xử lý các thông báo đến và về các lệnh gọi lại có sẵn để xử lý những thông báo này trong ứng dụng của bạn.

Cũng cần lưu ý rằng ngăn xếp không phát hiện hoặc lọc các gói trùng lặp trong lớp APS. Nó cũng không đảm bảo giao hàng mes sage theo
thứ tự. Các cơ chế này cần được thực hiện bởi ứng dụng.

Trong trường hợp của SoC, ngăn xếp xử lý cơ chế nhận và lưu trữ tin nhắn. Nhưng trong trường hợp của NCP, thông điệp được chuyển trực
tiếp đến máy chủ. Máy chủ phải xử lý việc nhận và lưu trữ tin nhắn ngoài việc phản ứng với nội dung tin nhắn.

Trong mọi trường hợp, ứng dụng phải phân tích thông báo thành các phần cấu thành của nó và quyết định phải làm gì với thông tin. Lưu ý
rằng khung ứng dụng, như một phần của ứng dụng, thực hiện hầu hết việc phân tích cú pháp thông báo. Khung ứng dụng vẫn cung cấp cho nhà
phát triển ứng dụng sự linh hoạt và kiểm soát hoàn toàn đối với quá trình nhận tin nhắn. Thông báo có thể được chia thành hai loại lớn:
thông báo lệnh hoặc dữ liệu. Các thông báo lệnh liên quan đến hoạt động của mục tiêu với tư cách là một thành viên chức năng của mạng
(bao gồm cả các lệnh quản lý). Thông báo dữ liệu là thông tin cho ứng dụng, mặc dù chúng có thể xử lý chức năng của thiết bị mà nút được
giao tiếp, chẳng hạn như cảm biến nhiệt độ.

3.5.3 Xác nhận Tin nhắn

Khi một tin nhắn được nhận, giao thức mạng tốt sẽ xác nhận việc nhận tin nhắn. Điều này được thực hiện tự động trong phần mềm ngăn xếp ở
lớp MAC với Liên kết ACK, không yêu cầu ứng dụng thực hiện hành động nào. Hình dưới đây cho thấy nút A gửi tin nhắn đến nút D.

Hình 3.2. Liên kết ACK

Các ứng dụng nhận được một cuộc gọi lại khi quá trình phân phối hoàn tất. Cuộc gọi lại cho biết thành công hay thất bại của việc phân
phối dựa trên việc nhận hoặc thiếu ACK, APS [end-to-end] ACK nếu được yêu cầu hoặc MAC [link] ACK nếu không. ) Do đó, nhà phát triển có
thể đọc thành công hay thất bại của quy trình phân phối và tùy ý thử lại quá trình phân phối ở cấp ứng dụng, nếu muốn.

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 20
 UG103.3: Nguyên tắc cơ bản về thiết kế phần mềm Zigbee
Machine Translated by Google
Design Choices

3.6 Khả năng tương thích của NCP và ứng dụng máy chủ

Điều rất quan trọng là đảm bảo rằng ứng dụng NCP có chức năng cốt lõi cần thiết để bộ xử lý máy chủ có thể dựa vào NCP để thực hiện các chức năng
mạng của nó. Ví dụ: nếu một ứng dụng máy chủ cần có khả năng gửi một loại tin nhắn, thì NCP phải có hỗ trợ để xử lý loại lệnh EZSP đó từ bộ xử lý
máy chủ.

Khả năng tương thích được xác định khác nhau, tùy thuộc vào việc bạn đang xây dựng hình ảnh NCP tùy chỉnh hay sử dụng một trong các hình ảnh
chương trình cơ sở dựng sẵn của Phòng thí nghiệm Silicon. Nếu bạn đang xây dựng một hình ảnh NCP tùy chỉnh với Khung ứng dụng Bộ đồng xử lý
mạng, thì bạn cần bao gồm các thành phần thư viện chứa chức năng mà ứng dụng máy chủ của bạn muốn thực hiện Nếu một ứng dụng máy chủ nhận được
nhiều giá trị lỗi EZSP_ERROR_INVALID_FRAME_ID từ NCP, hãy xây dựng lại hình ảnh để bao gồm thư viện có liên quan đến các lệnh này.

Thay vào đó, nếu bạn đang sử dụng hình ảnh chương trình cơ sở dựng sẵn, thì quá trình này sẽ đơn giản hơn. Các dịch vụ dựng sẵn hiện tại bao gồm
các hình ảnh NCP chuyển qua toàn bộ encom có thể xử lý chính xác bất kỳ khung EZSP nào được gửi từ máy chủ được xây dựng bằng Khung ứng dụng Zigbee.

Bảng sau đây được thiết kế để giúp ghép nối ứng dụng máy chủ với ứng dụng NCP phù hợp (ZAF = Zigbee Application Framework).

Bảng 3.3. Khả năng tương thích của ứng dụng máy chủ và NCP

Ứng dụng máy chủ

Mạng Zigbee PRO + Zigbee PRO kép

Ứng dụng NCP (tên hình ảnh) Mạng Zigbee PRO đơn (ZAF) (ZAF)

Ứng dụng NCP tùy chỉnh (Network Cop rocessor ĐÚNG ĐÚNG

Application Framework)
Chức năng trong ứng dụng máy chủ phải được Chức năng trong ứng dụng máy chủ phải được
nhân đôi với các thành phần tương ứng nhân đôi với các thành phần tương ứng
trong cấu hình NCP. trong cấu hình NCP. Đối với cấu hình máy
chủ đa mạng, thư viện công việc đa mạng
phải được bao gồm trong cấu hình NCP.

Các ứng dụng NCP toàn diện (ncp-spi, ncp- ĐÚNG ĐÚNG

uart)

silabs.com | Xây dựng một thế giới kết nối hơn. Phiên bản 2.5 | 21
Machine Translated by Google

Thông minh. Đã kết nối.

Thân thiện với năng lượng.

Danh mục IoT Chất Hỗ trợ & Cộng đồng

www.silabs.com/products lượng www.silabs.com/quality www.silabs.com/community

từ chối trách nhiệm

Phòng thí nghiệm Silicon dự định cung cấp cho khách hàng tài liệu chuyên sâu, chính xác và mới nhất về tất cả các thiết bị ngoại vi và mô-đun có sẵn cho những người cố vấn triển khai hệ thống
và phần mềm đang sử dụng hoặc có ý định sử dụng các sản phẩm của Phòng thí nghiệm Silicon. Dữ liệu mô tả đặc điểm, các mô-đun và thiết bị ngoại vi có sẵn, kích thước bộ nhớ và địa chỉ bộ nhớ
đề cập đến từng thiết bị cụ thể và các thông số “Điển hình” được cung cấp có thể và thực sự khác nhau trong các ứng dụng khác nhau. Các ví dụ ứng dụng được mô tả ở đây chỉ nhằm mục đích minh
họa. Silicon Labs có quyền thực hiện các thay đổi mà không cần thông báo thêm đối với thông tin sản phẩm, thông số kỹ thuật và mô tả ở đây và không đưa ra bảo đảm về tính chính xác hoặc tính
đầy đủ của thông tin được bao gồm. Không cần thông báo trước, Silicon Labs có thể cập nhật chương trình cơ sở của sản phẩm trong quá trình sản xuất vì lý do bảo mật hoặc độ tin cậy. Những
thay đổi như vậy sẽ không làm thay đổi thông số kỹ thuật hoặc hiệu suất của sản phẩm. Silicon Labs sẽ không chịu trách nhiệm về hậu quả của việc sử dụng thông tin được cung cấp trong tài liệu
này. Tài liệu này không ngụ ý hoặc cấp rõ ràng bất kỳ giấy phép nào để thiết kế hoặc chế tạo bất kỳ mạch tích hợp nào. Các sản phẩm không được thiết kế hoặc cho phép sử dụng trong bất kỳ thiết
bị Cấp III nào của FDA, các ứng dụng cần có sự chấp thuận trước khi tiếp thị của FDA hoặc Hệ thống Hỗ trợ Sự sống mà không có sự đồng ý cụ thể bằng văn bản của Phòng thí nghiệm Silicon. “Hệ
thống hỗ trợ sự sống” là bất kỳ sản phẩm hoặc hệ thống nào nhằm hỗ trợ hoặc duy trì sự sống và/hoặc sức khỏe, nếu không thành công, có thể dẫn đến thương tích cá nhân nghiêm trọng hoặc tử
vong. Các sản phẩm của Silicon Labs không được thiết kế hoặc ủy quyền cho các ứng dụng quân sự. Trong mọi trường hợp, các sản phẩm của Silicon Labs sẽ không được sử dụng làm vũ khí hủy diệt
hàng loạt bao gồm (nhưng không giới hạn ở) vũ khí hạt nhân, sinh học hoặc hóa học hoặc tên lửa có khả năng mang những vũ khí đó. Phòng thí nghiệm Silicon từ chối tất cả các bảo đảm rõ ràng và
ngụ ý và sẽ không chịu trách nhiệm hoặc trách nhiệm pháp lý đối với bất kỳ thương tích hoặc thiệt hại nào liên quan đến việc sử dụng sản phẩm của Phòng thí nghiệm Silicon trong các ứng dụng trái phép
Lưu ý: Nội dung này có thể chứa thuật ngữ xúc phạm hiện đã lỗi thời. Silicon Labs đang thay thế các điều khoản này bằng ngôn ngữ bao gồm bất cứ khi nào có thể. Để biết thêm thông tin, hãy truy
cập www.silabs.com/about-us/inclusive-lexicon-project

Thông tin nhãn hiệu

Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® và logo Silicon Labs®, Bluegiga®, Bluegiga Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo và sự kết
hợp của chúng , “bộ vi điều khiển thân thiện với năng lượng nhất thế giới”, Redpine Signals®, WiSeConnect , n-Link, ThreadArch®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS
Studio, Precision32®, Simplicity Studio®, Telegesis , Telegesis Logo®, USBXpress® , Zentri, logo Zentri và Zentri DMS, Z-Wave® và các nhãn hiệu khác là nhãn hiệu hoặc nhãn hiệu đã đăng ký của
Silicon Labs. ARM, CORTEX, Cortex-M3 và THUMB là các nhãn hiệu hoặc nhãn hiệu đã đăng ký của ARM Holdings. Keil là nhãn hiệu đã đăng ký của ARM Limited. Wi-Fi là nhãn hiệu đã đăng ký của Wi-Fi
Alliance. Tất cả các sản phẩm hoặc tên thương hiệu khác được đề cập ở đây là thương hiệu của chủ sở hữu tương ứng.

Phòng thí nghiệm Silicon Inc.

400 Tây Cesar Chavez
Austin, TX 78701
Hoa Kỳ

www.silabs.com