Kasu:
- Võimalus analüüsida selliste protokollide kaadri/paketi struktuuri nagu I2C/SPI/UART ja TCP/IP, MQTT koos AI toega
- Võimalus kitsendada protokolli vigu (ajastus, adresseerimine, kontrollsumma) kui AI-ga hüpoteese
- Võimalus kontrollida tehisintellekti protokolli tõlgendust standarddokumendi, analüsaatori (loogika/paketi) mõõtmise abil
Protokoll on reeglite kogum, milles kaks seadet teineteise mõistmiseks kokku lepivad: millise kiirusega, millises järjekorras, millises formaadis nad räägivad. See, kas temperatuuriandur räägib mikrokontrolleriga I2C kaudu või seade räägib pilvserveriga TCP/IP ja MQTT kaudu, põhineb protokollil. Selles üksuses näete, kuidas kasutada tehisintellekti protokollikaadrite/pakettide analüüsimiseks, protokollivigade kitsendamiseks ja sidepinust arusaamiseks (kihid üksteise peal, alates füüsilisest kihist kuni rakenduseni). AI on võimas protokollide selgitamisel ja hüpoteeside genereerimisel; kuid mida liin tegelikult teeb, seda teavad ainult selle analüsaatori mõõtmine (loogiline analüsaator, protokolli/paketianalüsaator) ja standarddokument.
Manustatud jadaprotokollid: I2C, SPI, UART
Tahvlil olevad kiibid räägivad tavaliselt kolme jadaprotokolliga:
- UART: kaks rida (TX/RX), kellarida puudub; Mõlemad pooled peavad olema seadistatud samale kiirusele (baudikiirus). Lihtne, kuid sünkroonimine sõltub kiirusest.
- SPI: kella (SCLK), andmete sisend/väljund (MOSI/MISO) ja vali (CS) read; Kiire, täisdupleks, kuid vajab rohkem kontakte. Kella polaarsus/faas (CPOL/CPHA) peab mõlemal küljel ühtima.
- I2C: kaks rida (SDA/SCL), aadressipõhine, mitu seadet samal real; tõmbetakistid ja ühismaa seisukord. Aeglane, kuid ökonoomne.
AI selgitab väga hästi, kuidas need protokollid töötavad, nende raamistiku struktuur ja tüüpilised rikete põhjused. Loetleb süstemaatiliselt võimalikud põhjused (vale aadress, puuduv tõmme, kiiruse mittevastavus, ühismaanduse puudumine, liinivaidlus, kaabli pikkus/mahtuvus), kui I2C-seade ei reageeri. Kuid milline neist on reaalne, saab aru loogikaanalüsaatoriga joont mõõtes ja SDA/SCL laineid vaadates; AI esitab hüpoteesi, mõõtmine otsustab.
Näpunäide: jadaprotokolli tõrke korral paluge tehisintellektil "reastada võimalikud põhjused kõige tõenäolisemast kuni kõige tõenäolisemini ja kõik, mida ma analüsaatoris näen, kinnitatakse". Nii muudate mõõtmise sihipäraseks; Selle asemel, et proovida iga põhjust ükshaaval, viib analüsaatori vaade teid õigesse haru.
Võrguprotokollid: TCP/IP, UDP, MQTT, CoAP
Kihilised protokollid tulevad mängu, kui seadmed ühenduvad võrgu ja pilvega. TCP/IP-pinn on sisuliselt kihiline: füüsiline/andmeside (Ethernet, Wi-Fi), võrk (IP: adresseerimine ja marsruutimine), transport (TCP: usaldusväärne, järjestikune, vooga juhitav / UDP: kiire, usaldusväärne) ja rakendus (HTTP, MQTT, CoAP). Põhimõisted:
- TCP vs UDP: TCP kompenseerib kahju ja tagab tellimuse, kuid lisab latentsusaega ja üldkulusid; UDP on kiire, kuid sellel puudub tarnegarantii (telemeetria jaoks eelistatakse reaalajas heli/videot).
- MQTT: kerge IoT sõnumsideprotokoll, mis töötab koos avaldamise ja tellimise mudeliga; sõnumside teemade kaudu maakleri kaudu. QoS tasemed määravad kohaletoimetamise tagamise.
- CoAP: HTTP-laadne UDP-põhine kerge protokoll piiratud seadmete jaoks.
AI analüüsib nende protokollide kaadrite/pakettide struktuuri, aitab teil tõlgendada Wiresharki (paketianalüsaatori) jäädvustust ja vaatab läbi MQTT teemakujunduse. Kuid seda, milline on tegelik liiklus, kontrollitakse pakettide hõivamise abil ja serveri käitumist kontrollitakse tõelise testimisega.
Kontrollsumma, CRC ja raamimine
Enamik protokolle kasutab kontrollsummat ehk CRC-d (Cyclic Redundancy Check) kontrollimaks, et andmed pole rikutud: saatja arvutab andmetest välja kontrollväärtuse, vastuvõtja teeb sama arvutuse ja võrdleb. AI kirjeldab ja kirjutab koodi CRC/kontrollsumma arvutamiseks, kuid sellised detailid nagu polünoomi valik, endiaalsus, algväärtus jne on standardile omased; Tehisintellekti loodud CRC-koodi tuleb sõna-sõnalt võrrelda protokolli ametliku määratlusega ja kontrollida tuntud testvektoriga.
kolm minikarpi
Juhtum 1 – mittetäielik ülestõmbamine. Meeskond ei saa töölaual I2C andurit käivitada; ei kinnita seadme aadressi (ei ACK). AI loetleb kõige tõenäolisema põhjusena puuduva tõmbetakisti ja ühisaluse. SDA liini loogilise analüsaatoriga vaadates on näha, et signaal ei saa täielikult kõrgele tasemele jõuda; Side algab siis, kui lisatakse tõmbetakistid. Õppetund: AI tõi esile kõige tõenäolisema põhjuse, analüsaator kinnitas seda.
Juhtum 2 – vale SPI-režiim. Insener loeb jaburaid andmeid SPI-seadmest. AI soovitab võimaliku põhjusena kella polaarsuse/faasi (CPOL/CPHA) mittevastavust. Analüsaatoris näib, et kell proovib teistmoodi kui serv, mida seade eeldab; Režiimi parandamisel muutuvad andmed tähendusrikkaks. Õppetund: SPI-i sümptom "andmed, kuid jama" on enamasti režiimi mittevastavus; mõõtmine teeb selle selgeks.
Juhtum 3 – MQTT QoS-i arusaamatus. Praktikant saadab MQTT kaudu telemeetria, kuid näeb, et mõned sõnumid on kadunud ja küsib AI-lt. AI väidab, et QoS 0 on "kõige rohkem üks kord, kohaletoimetamine pole garanteeritud"; Selgitab, et kohaletoimetamise tagamiseks on nõutav QoS 1/2, kuid see toob kaasa üldkulusid ja viivitusi. Praktikant lülitub telemeetria kriitilisuse põhjal QoS 1-le ja kontrollib maakleri käitumist reaalse testimisega. Õppetund: selgitage AI-protokolli valikut; Õige valik tehakse vastavalt taotlusele ja kontrollitakse testimisega.
Kopeeritavad viipade mallid
PROTOKOLI RIKE NAVIGATSIOONI MALL"[I2C/SPI/UART/TCP/MQTT] suhtlusel on järgmine sümptom: [sümptom]. Järjesta võimalikud põhjused KÕIGE TÕenäolisemalt vähima tõenäoliseni. Iga põhjuse puhul: (1) miks see seda sümptomit põhjustab, (2) kõik, mida ma näen, on analüsaatoril KINNITATUD/Mõõtmine on KINNITATUD. ÄRGE TEHA lõplikku diagnoosi;
FRAMEWORK/PACKET ANALÜÜSI MALL "Jagage järgmine [I2C/SPI/UART baidimassiivi / paketihõive] sisu väljadeks ja kirjeldage iga välja (aadress, käsk, andmed, kontrollsumma/CRC, lipp). Esitage selgelt oma eeldus endisuse ja bitijärjestuse kohta. Pange tähele, et ma pean teie kommentaari kinnitama ametliku [vektorandmed] ja kirjeldusega.]."
CRC/KONTROLLSUMMA KONTROLLIMALL"Kirjeldage [protokolli] CRC/kontrollsumma arvutamist: polünoom, algväärtus, bitijärjekord, lõplik
PROTOKOLI VALIMISMALL"Tehke transpordi-/rakendusprotokolli võrdlus järgmise rakenduse jaoks: [nõue: tarnegarantii, latentsus, võimsus, ribalaius, seadme piirang]. Võrrelge TCP/UDP ja MQTT/CoAP/HTTP suvandeid nende kriteeriumidega. ÄRGE KEHENDAGE selget valikut; tasakaalustage iga valik ja kinnitage, et valik peaks olema tegelik testimine."
Nõrk viip / Tugev viip
NÕRK VIIPA: "I2C ei tööta, miks?"
TUGEV VIIP: "Minu I2C-andur ei anna ACK-i (aadressi ei kinnitata). Loetlege võimalikud põhjused, alustades kõige tõenäolisemast: ülestõmbumine, ühine maandus, vale aadress, kiirus, kaabli mahtuvus, tüli. Iga põhjuse jaoks kirjutage kõik, mida ma loogikaanalüsaatori SDA/SCL-s näen, kinnitatakse, kõik, mida näen, on kõrvaldatud. Ei taha kitsendada loendit, mida ma saan diagnoosida."
Nõrk viip annab üheainsa oletuse; Võimas viip pakub diagnostilist kaarti, mida saab mõõtmiseks kitsendada, tellida ja kontrollida.
Protokolli võrdlustabel
protokolli
Tüüp
tugev külg
kontrollimise tööriist
UART
Seeria, ilma kellata
Lihtne, kaks rida
Loogiline analüsaator
SPI
Seeria, kellaga
Kiire, täisdupleks
Loogiline analüsaator (CPOL/CPHA)
I2C
Jada, adresseeritav
Palju seadmeid, vähe kontakte
Analüsaator (ACK, ülestõmbamine)
TCP
võrk, transport
Usaldusväärne, korras
Paketianalüsaator (Wireshark)
UDP
võrk, transport
Kiire, madal latentsusaeg
paketianalüsaator
MQTT
Rakendus
Kerge, pubi/sub, QoS
Maakleri logi + pakettide püüdmine
Ettevaatust. Tehisintellekti tõlgendamine protokollihõive on kiire, kuid AI võib valesti eeldada bitijärjestust või välja piiri. Kontrollige iga analüüsi protokolli ametliku kirjelduse ja teadaoleva testivektori suhtes.
Levinud vead
- Selle muutmine tehisintellekti ennustuse põhjal ilma vea põhjust mõõtmata. Analüsaatori vaade juhatab teid õige põhjuseni.
- CPOL/CPHA vastavuse eiramine SPI-s. "Andmeid on, kuid see on jama" on sageli režiimide ühildumatus.
- Unustades tõmbamise ja ühisosa I2C-l. See on "üldse mittetöötamise" kõige levinum põhjus.
- Eeldades CRC parameetreid. Polünoom, algus, bitijärjestus on standardile omased; Seda kontrollitakse testvektoriga.
- Segane MQTT QoS tarnegarantiiga. QoS 0 ei garanteeri; Valik tehakse ja testitakse vastavalt taotlusele.
Kokkuvõttes
Selles üksuses olete kasutanud tehisintellekti võimsa abivahendina selliste protokollide selgitamisel nagu I2C/SPI/UART ja TCP/IP, MQTT, kaadri-/paketianalüüs ja tõrkepõhjuste süstemaatiline kitsendamine. Kuid protokollid on täpsed ja standarditega seotud: selle, mida liin tegelikult teeb, määrab loogika/paketianalüsaator, analüüsi täpsuse määrab formaalne definitsioon ja testvektor, rikke põhjus määratakse mõõtmisega. Suunake AI andma "kõige tõenäolisem põhjus ja mõõtmine selle kinnitamiseks"; Las analüsaator ja standard otsustavad.
Rakenduse ülesanne
Valige jadaprotokolli tõrke stsenaarium (nt I2C ACK puudub). Taotlege tehisintellektilt järjestikust ja mõõtmistega kontrollitavat diagnostilist kaarti malliga „protokolli vea kitsendamine”. Seejärel võtke näidisbaitide massiiv (nt anduri lugemisraam) ja eraldage see mustriga "Frame/packet parsing" ning pange tähele endisuse eeldust. Lõpuks kontrollige CRC-koodi tuntud testvektori suhtes malliga "CRC/kontrollsumma kinnitamine".
kontrollnimekiri
- [ ] Kinnitasin tõrke põhjuse analüsaatoriga mõõtmise, mitte AI ennustusega.
- [ ] Loetlesin SPI-l CPOL/CPHA, I2C-l aadressi/tõmbamise/ühise maapealse juhtimise.
- [ ] Võrdlesin kaadri/paketi sõelumist ametliku protokolli definitsiooniga.
- [ ] Kontrollisin testvektoriga CRC/kontrollsumma parameetreid.
- [ ] Tegin transpordi/rakenduse protokolli valiku vastavalt nõudele ja testisin seda reaalse testimisega.
- [ ] Olen õigesti tõlgendanud MQTT QoS tarnegarantii tähendust.