Pelnas:
- Galimybė analizuoti tokių protokolų, kaip I2C/SPI/UART ir TCP/IP, MQTT su AI palaikymu, kadrų/paketų struktūrą
- Galimybė susiaurinti protokolo klaidas (laikas, adresas, kontrolinė suma) kaip hipotezes naudojant AI
- Galimybė patikrinti AI protokolo interpretaciją standartiniu dokumentu, analizatoriaus (logikos/paketo) matavimu
Protokolas yra taisyklių rinkinys, pagal kurį du įrenginiai susitaria, kad suprastų vienas kitą: kokiu greičiu, kokia tvarka, kokiu formatu jie kalbėsis. Ar temperatūros jutiklis susisiekia su mikrovaldikliu per I2C, ar įrenginys susisiekia su debesies serveriu per TCP/IP ir MQTT, yra pagrįstas protokolu. Šiame skyriuje pamatysite, kaip naudoti dirbtinį intelektą analizuojant protokolų kadrus / paketus, susiaurinti protokolo klaidas ir suprasti ryšių krūvą (sluoksnius vienas ant kito, nuo fizinio sluoksnio iki programos). AI yra galingas aiškindamas protokolus ir generuodamas hipotezes; bet ką iš tikrųjų daro linija, žino tik jos analizatoriaus matavimas (loginis analizatorius, protokolo/paketų analizatorius) ir standartinis dokumentas.
Įterptieji nuoseklieji protokolai: I2C, SPI, UART
Plokštėje esantys lustai paprastai kalba su trimis serijiniais protokolais:
- UART: dvi linijos (TX/RX), nėra laikrodžio linijos; Abi pusės turi būti nustatytos vienodu greičiu (bodo sparta). Paprasta, bet sinchronizavimas priklauso nuo greičio.
- SPI: Laikrodis (SCLK), duomenų įvestis/išvestis (MOSI/MISO) ir pasirinkimo (CS) linijos; Greitas, dvipusis, bet reikia daugiau kaiščių. Laikrodžio poliškumas/fazė (CPOL/CPHA) turi sutapti iš abiejų pusių.
- I2C: dvi linijos (SDA/SCL), pagrįstos adresu, keli įrenginiai toje pačioje linijoje; traukimo rezistoriai ir bendros žemės būklė. Lėtas, bet ekonomiškas.
AI labai gerai paaiškina, kaip veikia šie protokolai, jų sistemos struktūra ir tipinės gedimų priežastys. Sistemingai išvardijamos galimos priežastys (netinkamas adresas, trūkstamas ištraukimas, greičio neatitikimas, bendro įžeminimo nebuvimas, linijos ginčas, kabelio ilgis / talpa), kai I2C įrenginys nereaguoja. Bet kuris iš jų yra tikras, galima suprasti išmatavus liniją loginiu analizatoriumi ir pažvelgus į SDA/SCL bangas; AI pateikia hipotezę, o matavimas nusprendžia.
Patarimas: jei serijinis protokolas sugenda, paprašykite AI „surūšiuoti galimas priežastis nuo labiausiai tikėtinų iki mažiausiai tikėtinų, ir viskas, ką matau analizatoriuje, pasitvirtina“. Tokiu būdu matavimas bus tikslingas; Užuot bandę kiekvieną priežastį po vieną, analizatoriaus rodinys nukreipia jus į tinkamą šaką.
Tinklo protokolai: TCP/IP, UDP, MQTT, CoAP
Sluoksniuoti protokolai pradeda veikti, kai įrenginiai prisijungia prie tinklo ir debesies. TCP/IP paketas iš esmės yra sluoksniuotas: fizinis / duomenų ryšys (Ethernet, Wi-Fi), tinklas (IP: adresas ir maršruto parinkimas), transportavimas (TCP: patikimas, nuoseklus, srauto valdomas / UDP: greitas, nepatikimas) ir programa (HTTP, MQTT, CoAP). Pagrindinės sąvokos:
- TCP vs UDP: TCP kompensuoja nuostolius ir garantuoja užsakymą, tačiau įveda delsą ir pridėtines išlaidas; UDP yra greitas, bet neturi pristatymo garantijos (realaus laiko garso / vaizdo teikiama pirmenybė telemetrijai).
- MQTT: lengvas IoT pranešimų protokolas, veikiantis su publikavimo ir prenumeratos modeliu; pranešimų siuntimas temomis per tarpininką. QoS lygiai nustato pristatymo užtikrinimą.
- CoAP: HTTP panašus, UDP pagrįstas lengvas protokolas, skirtas ribotiems įrenginiams.
AI analizuoja šių protokolų kadrų / paketų struktūrą, padeda interpretuoti Wireshark (paketų analizatoriaus) fiksavimą ir peržiūri MQTT temos dizainą. Bet koks yra tikrasis srautas, patikrinama fiksuojant paketus, o serverio elgsena patikrinama atliekant tikrus testus.
Kontrolinė suma, CRC ir kadravimas
Dauguma protokolų naudoja kontrolinę sumą arba CRC (Cyclic Redundancy Check), kad patikrintų, ar duomenys nėra sugadinti: siuntėjas iš duomenų apskaičiuoja patikrinimo reikšmę, gavėjas atlieka tą patį skaičiavimą ir lygina. AI aprašo ir įrašo CRC/kontrolinės sumos skaičiavimo kodą, tačiau tokios detalės kaip daugianario pasirinkimas, endiškumas, pradinė vertė ir kt. yra būdingi standartui; AI sugeneruotas CRC kodas turi būti pažodžiui lyginamas su oficialiu protokolo apibrėžimu ir patikrintas pagal žinomą bandymo vektorių.
trys mini dėklai
1 atvejis – neužbaigtas prisitraukimas. Komanda negali paleisti I2C jutiklio duonos lentoje; nepripažįsta įrenginio adreso (be ACK). AI kaip labiausiai tikėtiną priežastį nurodo trūkstamą traukimo rezistorių ir bendrą pagrindą. Žvelgiant į SDA liniją su loginiu analizatoriumi, matosi, kad signalas negali pilnai pasiekti aukšto lygio; Ryšys prasideda, kai pridedami traukimo rezistoriai. Pamoka: AI pabrėžė labiausiai tikėtiną priežastį, analizatorius tai patvirtino.
2 atvejis – netinkamas SPI režimas. Inžinierius skaito beprasmiškus duomenis iš SPI įrenginio. AI kaip galimą priežastį siūlo laikrodžio poliškumo/fazės (CPOL/CPHA) neatitikimą. Atrodo, kad analizatoriuje laikrodis ima mėginį kitaip nei kraštas, kurio tikisi įrenginys; Pataisius režimą, duomenys tampa reikšmingi. Pamoka: SPI simptomas „duomenys, bet nesąmonė“ dažniausiai yra režimo neatitikimas; matavimas tai aiškiai parodo.
3 atvejis – MQTT QoS nesusipratimas. Stažuotojas siunčia telemetriją per MQTT, bet pamato, kad kai kurie pranešimai prarasti, ir klausia AI. AI teigia, kad QoS 0 yra „daugiausiai vieną kartą, pristatymas negarantuojamas“; Paaiškina, kad norint garantuoti pristatymą reikalingas QoS 1/2, tačiau tai sukelia pridėtines išlaidas ir vėlavimą. Stažuotojas persijungia į QoS 1, remdamasis telemetrijos kritiškumu, ir patikrina brokerio elgesį realiais testais. Pamoka: paaiškinkite AI protokolo parinktį; Teisingas pasirinkimas atliekamas pagal paraišką ir patikrinamas testuojant.
Kopijuojami raginimo šablonai
PROTOKOLO TRIKIMO NAVIGACIJOS ŠABLONAS"[I2C/SPI/UART/TCP/MQTT] bendravimas turi tokį požymį: [simptomas]. Įvertinkite galimas priežastis nuo GALIMYBĖS iki Mažiausiai tikėtinos. Dėl kiekvienos priežasties: (1) kodėl tai rodo šį simptomą, (2) viskas, ką matau analizatoriuje, yra PATVIRTINTA, matoma,3.MED. NENUSTATYK galutinės diagnozės, atsiranda sprendimų medis.
FRAMEWORK / PACKET ANALIZĖS ŠABLONAS "Suskaidykite toliau pateiktą [I2C/SPI/UART baitų masyvo / paketų fiksavimo] turinį į laukus ir apibūdinkite kiekvieną lauką (adresas, komanda, duomenys, kontrolinė suma/CRC, vėliavėlė). Aiškiai nurodykite savo prielaidą dėl endiškumo ir bitų tvarkos. Atkreipkite dėmesį, kad turiu patikrinti jūsų komentarą su oficialiu protokolo duomenimis ir testtepas.."
CRC / KONTROLINĖS SUMOS PATIKRINIMO ŠABLONIS"Apibūdinkite [protokolo] CRC / kontrolinės sumos skaičiavimą: polinomas, pradinė reikšmė, bitų tvarka, galutinis
PROTOKOLO PASIRINKIMO ŠABLONAS"Palyginkite šios programos transportavimo / taikomosios programos protokolus: [reikalavimas: pristatymo garantija, delsa, galia, pralaidumas, įrenginio apribojimas]. Palyginkite TCP/UDP ir MQTT/CoAP/HTTP parinktis su šiais kriterijais. NEPRITEIKITE aiškaus pasirinkimo; subalansuokite kiekvieną parinktį ir patvirtinkite, kad pasirinkimas turi būti patikrintas."
Silpnas raginimas / Stiprus raginimas
Silpnas raginimas: "I2C neveikia, kodėl?"
STIPRUS RAŠYMAS: "Mano I2C jutiklis nepatvirtina (adresas nepatvirtintas). Išvardykite galimas priežastis, pradedant nuo labiausiai tikėtinų: ištraukimas, bendras įžeminimas, neteisingas adresas, greitis, kabelio talpa, ginčas. Dėl kiekvienos priežasties parašykite viską, ką matau loginio analizatoriaus SDA/SCL, yra patvirtinta, viskas, ką matau, pašalinta. Nenoriu susiaurinti matavimo sąrašo, kad galiu diagnozuoti.";
Silpnas raginimas pateikia vieną spėjimą; Galingas raginimas pateikia diagnostinį žemėlapį, kurį galima susiaurinti iki matavimo, užsakyti ir patikrinti.
Protokolų palyginimo lentelė
protokolas
Tipas
stiprioji vieta
tikrinimo įrankis
UART
Serija, be laikrodžio
Paprasta, dvi eilutės
Loginis analizatorius
SPI
Serijinis, su laikrodžiu
Greitas, pilnas dvipusis
Loginis analizatorius (CPOL/CPHA)
I2C
Serijinis, adresuojamas
Daug įrenginių, keli kaiščiai
Analizatorius (ACK, prisitraukimas)
TCP
tinklas, transportas
Patikimas, tvarkingas
Paketų analizatorius („Wireshark“)
UDP
tinklas, transportas
Greitas, mažas delsimas
paketų analizatorius
MQTT
Taikymas
Lengvas, pub/sub, QoS
Brokerio žurnalas + paketų fiksavimas
Įspėjimas: AI interpretuojant protokolo fiksavimą yra greitas, tačiau AI gali neteisingai priimti bitų tvarką arba lauko ribą. Patikrinkite kiekvieną analizę pagal oficialų protokolo aprašymą ir žinomą testo vektorių.
Dažnos klaidos
- Pakeisti jį remiantis AI prognozėmis, neįvertinant gedimo priežasties. Analizatoriaus vaizdas veda prie tinkamos priežasties.
- Nepaisoma CPOL/CPHA atitikties SPI. „Yra duomenų, bet tai nesąmonė“ dažnai yra režimo nesuderinamumas.
- Pamiršus prisitraukimą ir bendrą pagrindą I2C. Tai dažniausia „visiškai neveikianti“ priežastis.
- Darant prielaidą, kad CRC parametrai. Polinomas, pradžia, bitų tvarka yra būdingi standartui; Tai patikrinama naudojant testo vektorių.
- Paini MQTT QoS su pristatymo garantija. QoS 0 negarantuoja; Pasirinkimas atliekamas ir išbandomas pagal paraišką.
Apibendrinant
Šiame skyriuje AI naudojote kaip galingą pagalbą aiškindami tokius protokolus kaip I2C/SPI/UART ir TCP/IP, MQTT, kadrų/paketų analizę ir sistemingai susiaurindami gedimų priežastis. Tačiau protokolai yra tikslūs ir susieti su standartais: tai, ką linija iš tikrųjų daro, nustato loginis / paketų analizatorius, analizės tikslumas nustatomas pagal formalų apibrėžimą ir bandymo vektorių, gedimo priežastis nustatoma matavimu. Nurodykite AI nurodyti „labiausiai tikėtiną priežastį ir matavimą, kad tai patvirtintų“; Tegul analizatorius ir standartas nusprendžia.
Taikymo užduotis
Pasirinkite serijinio protokolo gedimo scenarijų (pvz., nėra I2C ACK). Prašyti nuoseklaus ir matavimais patikrinamo diagnostikos žemėlapio iš AI naudodami „protokolo gedimo susiaurėjimo“ šabloną. Tada paimkite pavyzdinį baitų masyvą (pvz., jutiklio skaitymo rėmelį) ir padėkite tarpą su šablonu „Rėmelio/paketo analizavimas“ ir atkreipkite dėmesį į baigtumo prielaidą. Galiausiai patikrinkite CRC kodą pagal žinomą bandymo vektorių naudodami šabloną „CRC/kontrolinės sumos patvirtinimas“.
kontrolinis sąrašas
- [ ] Gedimo priežastį patvirtinau analizatoriaus matavimu, o ne AI numatymu.
- [ ] SPI išvardijau CPOL/CPHA, I2C – adresas/pull-up/bendras žemės valdymas.
- [ ] Palyginau kadrų/paketų analizavimą su oficialiu protokolo apibrėžimu.
- [ ] Patikrinau CRC/kontrolinės sumos parametrus su bandymo vektoriumi.
- [ ] Transportavimo/aplikacijos protokolo pasirinkimą padariau pagal reikalavimą ir išbandžiau jį realiu testavimu.
- [ ] Teisingai išaiškinau MQTT QoS pristatymo garantijos reikšmę.